MBS - NR Multicast and Broadcast Services

Release 15 and 16 NR had no way to send one packet to many UEs. Every UE got its own copy on its own PDSCH, scheduled with its own C-RNTI. That is fine for web browsing, but not for a live video stream, a software update to a million devices, or a group call for public safety. Release 17 added MBS (Multicast and Broadcast Services) for this. Release 18 then extended it, and the main Release 18 addition is multicast reception in RRC_INACTIVE.

MBS is not a separate radio system on top of NR. It reuses the normal NR physical layer, the normal L2 stack and the normal cell. What it adds is a set of group-common pieces. There is a group RNTI (G-RNTI), there are group-common logical channels (MTCH and MCCH), and there is a new radio bearer type (MRB). There is also a way to switch a UE between a group copy, PTM (Point-to-Multipoint), and its own copy, PTP (Point-to-Point). This page goes through these pieces, first for broadcast, then for multicast, and then the Release 18 changes.

• Why MBS in NR ?
• Broadcast versus multicast
• Protocol architecture and MRB
• Logical channels, RNTIs, DCI and CFR
• Broadcast - SIB20, MCCH and MTCH
• Multicast in RRC_CONNECTED
• PTM and PTP switching
• Multicast in RRC_INACTIVE - Release 18
• Other Release 18 enhancements
• Reference

Why MBS in NR ?

Why did NR need a new feature for this, when LTE already had eMBMS ? LTE eMBMS was built around MBSFN. Several cells transmitted the same signal in special MBSFN subframes, with a long CP, and the UE combined them like multipath. That gave good coverage, but it needed its own subframe type, its own reference signals and its own core network entities. My impression is that commercial deployment stayed limited.

NR MBS in Release 17 and 18 took a different path. It is a single-cell scheme. Each cell sends the group transmission on a normal PDSCH, with a normal DMRS and a normal slot structure. The only new thing on the air is that the PDCCH CRC and the PDSCH scrambling use a group RNTI instead of a UE RNTI. So a gNB can mix MBS and unicast in the same slot, and a UE needs very little new physical layer to receive it. The cost is that NR MBS does not get the multi-cell combining gain of MBSFN.

The second difference is that NR MBS was designed for both multicast and broadcast from the start. LTE eMBMS, and the single-cell SC-PTM added in Release 13, had no HARQ feedback and no RAN-level member list. NR multicast is closer to a unicast service. The UE joins a session, and the network knows who the members are. So the network can use HARQ feedback, and it can switch a UE to its own PTP copy when the group copy does not reach it.

• Single-cell PTM: one group-common PDCCH and PDSCH per cell, with no MBSFN area and no special subframe type.
• Reuse of unicast: the same numerology, BWP concept, DMRS and HARQ as unicast. The new parts are mostly in RRC and MAC.
• Two service types: broadcast for everyone in an area, and multicast for a group of UEs that joined a session.
• Core network: the 5GC side, including MB-SMF and MB-UPF, is defined in TS 23.247. This page stays on the RAN side.

Broadcast versus multicast

What is the real difference between the two ? In both cases the same content goes to several UEs at once. The difference is who is allowed to receive it, and that decides almost everything else. In broadcast, all UEs in the broadcast service area are authorized, so the network does not need to know who is listening. In multicast, only the UEs that joined the session are authorized, so the network keeps a member list and can treat each member individually.

The table below puts the main consequences side by side. The rows come from 38.300 clause 16.10, with the Release 18 changes for RRC_INACTIVE included.

• Broadcast in idle and inactive is Release 17: a UE does not need a connection to watch a broadcast. What Release 18 added in RRC_INACTIVE is multicast.
• Multicast can mix with unicast: because the network knows the members, it can serve one member by PTP and the rest by PTM, and nobody sees a difference in QoS.
• Dual connectivity: in NR-DC and NE-DC, multicast is supported only on the MCG side, and broadcast cannot be configured on the SCG.

Protocol architecture and MRB

How does one PDCP stream reach a UE both as a group copy and as its own copy ? NR solves this with a new bearer type, the MBS Radio Bearer (MRB). An MRB has one SDAP entity and one PDCP entity, like a DRB. The difference is below PDCP. A multicast MRB can have one or two legs, and each leg is an RLC entity. The PTM leg is a DL-only RLC-UM entity that receives the group transmission. The PTP leg is a normal RLC entity that receives the UE's own copy.

The SDAP and PDCP of an MRB are reduced versions. SDAP only maps MBS QoS flows to the MRB. PDCP keeps SN maintenance, ROHC or EHC, reordering and duplicate discarding. 38.300 lists no ciphering or integrity protection for the MRB PDCP. Reordering and duplicate discarding are the important functions here, because the same PDCP PDU can arrive through both legs. Figure 1 shows the multicast case.

Figure 1. A multicast MRB with both legs. The two legs share one PDCP entity, so the UE can receive the same PDCP PDU over PTM, PTP or both and still deliver it once and in order.

38.300 clause 16.10.3 lists the multicast MRB types that a gNB can configure in RRC_CONNECTED. Six combinations are allowed:

• PTP only: one DL-only RLC-UM entity or one bidirectional RLC-UM entity.
• PTP only, AM: one RLC-AM entity.
• PTM only: one DL-only RLC-UM entity.
• Split, UM and UM: one DL-only RLC-UM for PTP and one DL-only RLC-UM for PTM.
• Split, three UM entities: DL RLC-UM and UL RLC-UM for PTP, and one DL-only RLC-UM for PTM.
• Split, AM and UM: one RLC-AM for PTP and one DL-only RLC-UM for PTM. This is the type that allows lossless handover, as explained in PTM and PTP switching.

A broadcast MRB is simpler. It always has one DL-only RLC-UM entity for PTM, and it is configured by broadcast RRC signalling. In RRC_INACTIVE, a multicast MRB is also reduced to the PTM-only type. In RRC, a multicast MRB is added with MRB-ToAddMod-r17 in RadioBearerConfig, and each RLC leg points to its MRB with MulticastRLC-BearerConfig-r17 inside RLC-BearerConfig.

Following is based on 38.331 v19.4.0 (Release 19)

MRB-ToAddMod-r17 ::=                    SEQUENCE {
    mbs-SessionId-r17                       TMGI-r17                                                OPTIONAL,   -- Cond MRBSetup
    mrb-Identity-r17                        MRB-Identity-r17,
    mrb-IdentityNew-r17                     MRB-Identity-r17                                        OPTIONAL,   -- Need N
    reestablishPDCP-r17                     ENUMERATED{true}                                        OPTIONAL,   -- Need N
    recoverPDCP-r17                         ENUMERATED{true}                                        OPTIONAL,   -- Need N
    pdcp-Config-r17                         PDCP-Config                                             OPTIONAL,   -- Cond PDCP
    ...
}

MulticastRLC-BearerConfig-r17 ::=           SEQUENCE {
    servedMBS-RadioBearer-r17                   MRB-Identity-r17,
    isPTM-Entity-r17                            ENUMERATED {true}                                   OPTIONAL    -- Need S
}

• mbs-SessionId-r17: the TMGI of the multicast session that the MRB carries. The TMGI is the session identifier that also appears in group paging.
• mrb-Identity-r17: 1 to 512, a separate space from the DRB identity. Up to 32 multicast MRBs can be added (maxMRB-r17).
• mrb-IdentityNew-r17: changes the identity of an existing MRB when it needs to change, for example as a result of a handover.
• isPTM-Entity-r17: marks the RLC entity as the PTM leg. When absent, the entity is the PTP leg. A PTM RLC entity can use the extended logical channel identity logicalChannelIdentityExt-r17 (320 to 65855).

Logical channels, RNTIs, DCI and CFR

Once the bearer exists, how does the UE find its group transmission on the air ? Four things are needed. The UE needs logical channels for data and control, and an RNTI that marks the PDCCH as a group grant. It also needs a DCI format, and a frequency region where the group PDCCH and PDSCH live. MBS defines all four, and they are summarised here before the broadcast and multicast procedures use them.

There are two new logical channels, and both map to DL-SCH. MTCH carries MBS data by PTM, for both multicast and broadcast. MCCH carries the control information for one or more MTCHs. Broadcast MCCH and multicast MCCH are independent channels, and multicast MCCH is used only for multicast reception in RRC_INACTIVE. The PTP leg of a multicast MRB uses the ordinary DTCH.

The RNTI values are from 38.321 Table 7.1-1, and the DCI mapping from 38.212 clause 7.3.1.5. DCI 4_0 is a small fixed format sized on CORESET 0, with a 2-bit MCCH change notification field when it carries MCCH-RNTI or Multicast MCCH-RNTI. DCI 4_1 is also compact, but it has NDI, a HARQ process number, DAI, a PUCCH resource indicator and a HARQ timing field, because multicast in RRC_CONNECTED can use HARQ feedback. DCI 4_2 is the configurable multicast format, comparable to DCI 1_1. The field details are in the DCI page, and the full RNTI list in the RNTI page.

The last piece is the CFR (Common Frequency Resource), which 38.300 calls an MBS frequency region. It is a set of contiguous PRBs with the same numerology as the BWP it belongs to, and the group PDCCH and PDSCH are confined to it. The CFR exists because the UEs of one group may sit on different dedicated BWPs, while a group transmission can be only in one place.

• Broadcast CFR: configured in SIB20 by cfr-ConfigMCCH-MTCH-r17. It is at least as wide as CORESET 0 and uses its numerology. When absent, the CFR equals CORESET 0.
• Multicast CFR in RRC_CONNECTED: configured per DL BWP by cfr-ConfigMulticast in RRCReconfiguration. When it has no location and bandwidth, the CFR is the whole DL BWP.
• Multicast CFR in RRC_INACTIVE: configured in SIB24 by cfr-ConfigMCCH-MTCH-r18. It can differ from the broadcast CFR. If neither CFR fully contains the other, the UE is not required to receive broadcast and multicast at the same time.
• Multiple G-RNTIs: a UE can have up to 16 G-RNTI configurations (maxG-RNTI-r17), and different services can share a G-RNTI or use different ones.

Broadcast - SIB20, MCCH and MTCH

How does a UE in RRC_IDLE find a broadcast service with no dedicated signalling at all ? It has to learn everything from what the cell broadcasts, and NR uses a three-step chain for this. SIB20 tells the UE where and when MCCH is sent. MCCH lists the sessions, each with its G-RNTI and scheduling. The UE then monitors that G-RNTI for MTCH. Figure 2 shows the chain.

Figure 2. Broadcast acquisition chain. The UE never receives dedicated signalling, so every parameter for MTCH comes from SIB20 and MCCH.

SIB20 carries the MCCH configuration and the broadcast CFR. MCCH is not sent in every slot. It is sent in an MCCH transmission window, which starts in radio frames where SFN mod repetition period equals the offset, and lasts for mcch-WindowDuration slots. MCCH content can change only at a modification period boundary, which works like the SI modification period.

Following is based on 38.331 v19.4.0 (Release 19)

SIB20-r17 ::=SEQUENCE {
    mcch-Config-r17                MCCH-Config-r17,
    cfr-ConfigMCCH-MTCH-r17        CFR-ConfigMCCH-MTCH-r17 OPTIONAL,  -- Need S
    lateNonCriticalExtension       OCTET STRING            OPTIONAL,
    ...,
    [[
    cfr-ConfigMCCH-MTCH-RedCap-r18 CFR-ConfigMCCH-MTCH-r17 OPTIONAL,  -- Need S
    mcch-ConfigRedCap-r18          MCCH-Config-r17         OPTIONAL   -- Need S
    ]]
}

MCCH-Config-r17 ::= SEQUENCE {
    mcch-RepetitionPeriodAndOffset-r17   MCCH-RepetitionPeriodAndOffset-r17,
    mcch-WindowStartSlot-r17             INTEGER (0..79),
    mcch-WindowDuration-r17              ENUMERATED {sl2, sl4, sl8, sl10, sl20, sl40,sl80, sl160}     OPTIONAL, -- Need S
    mcch-ModificationPeriod-r17          ENUMERATED {rf2, rf4, rf8, rf16, rf32, rf64, rf128, rf256,
                                         rf512, rf1024, rf2048, rf4096, rf8192, rf16384, rf32768, rf65536}
}

The MCCH message itself is MBSBroadcastConfiguration. Its main content is a list of sessions, and each session entry is an MBS-SessionInfo-r17. Note that the G-RNTI is mandatory in each entry, because a broadcast session cannot be received without one.

Following is based on 38.331 v19.4.0 (Release 19)

MBSBroadcastConfiguration-r17-IEs ::= SEQUENCE {
    mbs-SessionInfoList-r17               MBS-SessionInfoList-r17                                              OPTIONAL,   -- Need R
    mbs-NeighbourCellList-r17             MBS-NeighbourCellList-r17                                            OPTIONAL,   -- Need S
    drx-ConfigPTM-List-r17                SEQUENCE (SIZE (1..maxNrofDRX-ConfigPTM-r17)) OF DRX-ConfigPTM-r17   OPTIONAL,   -- Need R
    pdsch-ConfigMTCH-r17                  PDSCH-ConfigBroadcast-r17                                            OPTIONAL,   -- Need S
    mtch-SSB-MappingWindowList-r17        MTCH-SSB-MappingWindowList-r17                                       OPTIONAL,   -- Need R
    lateNonCriticalExtension              OCTET STRING                                                         OPTIONAL,
    nonCriticalExtension                  MBSBroadcastConfiguration-v1900-IEs                                  OPTIONAL
}

MBS-SessionInfo-r17 ::=          SEQUENCE {
    mbs-SessionId-r17                TMGI-r17,
    g-RNTI-r17                       RNTI-Value,
    mrb-ListBroadcast-r17            MRB-ListBroadcast-r17,
    mtch-SchedulingInfo-r17          DRX-ConfigPTM-Index-r17                      OPTIONAL, -- Need S
    mtch-NeighbourCell-r17           BIT STRING (SIZE(maxNeighCellMBS-r17))       OPTIONAL, -- Need S
    pdsch-ConfigIndex-r17            PDSCH-ConfigIndex-r17                        OPTIONAL, -- Need S
    mtch-SSB-MappingWindowIndex-r17  MTCH-SSB-MappingWindowIndex-r17              OPTIONAL  -- Cond MTCH-Mapping
}

• mbs-SessionInfoList-r17: up to 1024 sessions (maxNrofMBS-Session-r17). Each session has up to 4 broadcast MRBs (maxNrofMRB-Broadcast-r17).
• mtch-SchedulingInfo-r17: an index into drx-ConfigPTM-List-r17. One PTM DRX configuration can serve several G-RNTIs, so the UE wakes up only when the MTCH it wants can be scheduled.
• mbs-NeighbourCellList-r17 and mtch-NeighbourCell-r17: the list names neighbour cells, and the per-session bitmap says which of them carry the same session. An empty list means no neighbour carries these sessions. An absent list means the UE cannot conclude anything.
• mtch-SSB-MappingWindowList-r17: for beam sweeping. The MTCH can be repeated in windows mapped to SSBs, so a UE reads the copy sent on its own beam.
• pdsch-ConfigMTCH-r17: PDSCH parameters for MTCH. When absent, the UE uses the ones in pdsch-ConfigMCCH.

The remaining question is mobility. A broadcast UE in RRC_IDLE uses normal cell reselection, with one change. It may treat the frequency carrying its broadcast service as the highest priority, as long as the service is ongoing and it is still interested. To know which frequency carries what, the UE uses the USD (User Service Description) from the application layer and SIB21, which maps frequencies to MBS FSAIs (Frequency Selection Area Identities). In RRC_CONNECTED, the UE sends MBSInterestIndication over SRB1, with its MBS frequencies, the services it wants, and whether broadcast has priority over unicast. The gNB can then choose a configuration that keeps the broadcast frequency within the UE's reception capability. SIB21 being present enables this indication.

Multicast in RRC_CONNECTED

Multicast starts from the core network. The UE joins a multicast session with NAS signalling, as defined in TS 23.247. The session can be joined while it is inactive, and the session is activated later when the content source has data. So the RAN has to solve two things: how to reach the members when the session becomes active, and how to configure them once they are connected.

For the first, NR uses group notification. The Paging message, addressed with P-RNTI, can carry the TMGI of a multicast session instead of a UE identity. Every member UE in RRC_IDLE or RRC_INACTIVE that sees its TMGI then connects or resumes. The UE is therefore not paged individually. A UE camping on a gNB that does not support MBS falls back to individual paging, CN-initiated in RRC_IDLE or RAN-initiated in RRC_INACTIVE. For the second, the gNB sends RRCReconfiguration with the MRB, the CFR and the G-RNTI configuration. The paging details are in the Paging page.

Following is based on 38.331 v19.4.0 (Release 19)

MBS-RNTI-SpecificConfig-r17 ::=        SEQUENCE {
    mbs-RNTI-SpecificConfigId-r17          MBS-RNTI-SpecificConfigId-r17,
    groupCommon-RNTI-r17                   CHOICE {
        g-RNTI                                 RNTI-Value,
        g-CS-RNTI                              RNTI-Value
    },
    drx-ConfigPTM-r17                      SetupRelease { DRX-ConfigPTM-r17 }                          OPTIONAL,   -- Need M
    harq-FeedbackEnablerMulticast-r17      ENUMERATED {dci-enabler, enabled}                           OPTIONAL,   -- Need S
    harq-FeedbackOptionMulticast-r17       ENUMERATED {ack-nack, nack-only}                            OPTIONAL,   -- Cond HARQFeedback
    pdsch-AggregationFactor-r17            ENUMERATED {n2, n4, n8}                                     OPTIONAL    -- Cond G-RNTI
}

• groupCommon-RNTI-r17: each entry is one G-RNTI or one G-CS-RNTI. Up to 16 entries per UE.
• drx-ConfigPTM-r17: multicast DRX per G-RNTI or G-CS-RNTI, independent of the UE-specific DRX. The PTP leg follows the normal UE DRX.
• harq-FeedbackEnablerMulticast-r17: enabled turns HARQ feedback on for this RNTI, while dci-enabler lets each DCI decide.
• harq-FeedbackOptionMulticast-r17: ack-nack is the first HARQ-ACK reporting mode, where the UE reports both values. The value nack-only is the second mode, where the UE does not send a PUCCH that would carry only ACKs.
• pdsch-AggregationFactor-r17: slot repetition of a multicast PDSCH for this G-RNTI.

NACK-only feedback is the part that makes multicast HARQ scale. With 1000 UEs in a group, ACK/NACK feedback means 1000 PUCCHs per transport block. With NACK-only, only the UEs that failed transmit. 38.213 clause 18 defines how each UE selects its PUCCH resource, but as far as I can see it does not require different UEs to get different resources. My understanding is that a gNB may give a group one shared NACK resource and only detect energy on it, but that is an implementation choice, not something the spec describes.

• One cell at a time: with CA, the UE receives multicast from the PCell or from one SCell at a time.
• Codebook: MulticastConfig-r17 in PhysicalCellGroupConfig can set a separate HARQ-ACK codebook list for multicast. NACK-only does not work with the semi-static codebook.
• Processing limits: in RRC_CONNECTED, PDSCHs scheduled by G-RNTI, G-CS-RNTI or MCCH-RNTI count against the same per-slot PDSCH capability as unicast (38.214 clause 5.1).

PTM and PTP switching

Why would a network send a separate PTP copy to a member when a PTM copy is already on the air ? Because a PTM transmission is planned for the group, not for each UE. Its MCS and beam have to work for the weakest UE that the gNB wants to serve. A UE at the cell edge or behind a building may not decode it. Sending that UE its own copy, with its own link adaptation and beam, is cheaper than lowering the PTM MCS for everyone.

So 38.300 lets the gNB decide dynamically, per UE, whether to deliver data by the PTM leg, the PTP leg or both. The inputs are the session QoS, the number of joined UEs, the individual feedback on reception quality and other criteria. The decision is invisible above PDCP, because both legs end in the same PDCP entity. There are three levels of switching, from fast to slow.

• Per transport block: a PTM transport block that a UE NACKs can be retransmitted to that UE by PTP. The UE monitors C-RNTI/CS-RNTI in its own DRX Active Time for this. In MAC, a G-RNTI transmission and a C-RNTI retransmission can use the same HARQ process (38.321 clause 5.3.1).
• Per packet: with a split MRB, the gNB can send any PDCP PDU on either leg or on both. PDCP reordering and duplicate discarding at the UE handle the result.
• Per bearer type: the gNB can change the MRB type with RRCReconfiguration, for example from PTM-only to split. It can ask the UE for a PDCP status report during the change to limit data loss.

The same idea also helps at handover. The source gNB sends the joined sessions to the target in the UE context. If the target does not yet have MBS resources for the session, it sets them up towards the 5GC with the NGAP Distribution Setup procedure. Lossless handover is possible only when the UE has a PTP RLC-AM entity in the target cell, and the network keeps the PDCP COUNT values synchronised between source and target. Data forwarding and a PDCP status report can be used, as for a DRB.

If the target cell does not support MBS at all, the 5GC switches the session to individual delivery. The target sets up PDU session resources for it, so the content arrives as unicast in a normal DRB. The source can avoid a full configuration at the target by switching the MRB to a DRB before the handover. The general handover procedure is in the Handover page.

• PTM/PTP is a gNB decision: the UE does not request a leg. It reports HARQ feedback and, where configured, a PDCP status report.
• RLC-AM PTP leg: needed for lossless handover. An MRB without it can lose packets at handover.
• Shared versus individual delivery: 5GC Shared MBS traffic delivery feeds one stream per session to the gNB. 5GC Individual MBS traffic delivery sends a copy per UE through the PDU session, and it is used towards gNBs without MBS support.

Multicast in RRC_INACTIVE - Release 18

In Release 17, every UE receiving multicast had to stay in RRC_CONNECTED. For a group call with a few members that is fine. For a large group in one cell, it is a problem. Each connected UE uses its own context, its own measurement configuration and its own PUCCH and SRS resources, and the cell may run out of connections. Release 18 therefore lets a UE receive multicast in RRC_INACTIVE by PTM, in a way that looks much like broadcast.

The cost is a reduced feature set. In RRC_INACTIVE there is no PTP leg, no SPS, no HARQ feedback, and only one MIMO layer. Slot-level repetition of MTCH is optional. The gNB decides which state the UE receives in, and the 5GC can help with MBS Assistance Information, which says whether the UE is expected to need dedicated resources very frequently. Figure 3 shows the flow.

Figure 3. Multicast reception in RRC_INACTIVE. The PTM configuration comes either with RRCRelease for the cell where the UE was released, or from SIB24 and multicast MCCH in any other cell.

The release step carries the configuration. The field multicastConfigInactive-r18 is in the Release 18 extension of SuspendConfig in RRCRelease. It holds two containers: an MBSMulticastConfiguration for the current cell, and a SIB24 for the current cell. If the UE then selects the same cell, it applies the PTM configuration directly. The UE does not suspend the MRBs of the sessions that continue in RRC_INACTIVE, which is the important difference from a normal release.

Following is based on 38.331 v19.4.0 (Release 19)

MulticastConfigInactive-r18::=         SEQUENCE {
    inactivePTM-Config-r18                 OCTET STRING (CONTAINING MBSMulticastConfiguration-r18)     OPTIONAL, -- Need S
    inactiveMCCH-Config-r18                OCTET STRING (CONTAINING SystemInformation)                 OPTIONAL  -- Need N
}

SIB24-r18 ::= SEQUENCE {
    multicastMCCH-Config-r18       MCCH-Config-r17         OPTIONAL,  -- Need S
    cfr-ConfigMCCH-MTCH-r18        CFR-ConfigMCCH-MTCH-r17 OPTIONAL,  -- Need S
    lateNonCriticalExtension       OCTET STRING            OPTIONAL,
    ...
}

• inactivePTM-Config-r18: the sessions that can be received in RRC_INACTIVE and, optionally, their PTM configuration in this cell. If absent, the UE considers that all its joined sessions can be received in RRC_INACTIVE.
• inactiveMCCH-Config-r18: a SystemInformation container. Only SIB24 is allowed in it, so the UE gets the multicast MCCH schedule without reading the SIB.
• SIB24-r18: reuses the Release 17 MCCH-Config and CFR structures, so the multicast MCCH has the same window and modification period logic as broadcast MCCH.

The multicast MCCH message is MBSMulticastConfiguration. It is built on the broadcast MCCH message, with additions for a member UE that may leave PTM reception.

Following is based on 38.331 v19.4.0 (Release 19)

MBSMulticastConfiguration-r18-IEs ::= SEQUENCE {
    mbs-SessionInfoListMulticast-r18      MBS-SessionInfoListMulticast-r18                                     OPTIONAL,   -- Need R
    mbs-NeighbourCellList-r18             MBS-NeighbourCellList-r17                                            OPTIONAL,   -- Need S
    drx-ConfigPTM-List-r18                SEQUENCE (SIZE (1..maxNrofDRX-ConfigPTM-r17)) OF DRX-ConfigPTM-r17   OPTIONAL,   -- Need R
    pdsch-ConfigMTCH-r18                  PDSCH-ConfigBroadcast-r17                                            OPTIONAL,   -- Need S
    mtch-SSB-MappingWindowList-r18        MTCH-SSB-MappingWindowList-r17                                       OPTIONAL,   -- Need R
    thresholdMBS-List-r18                 SEQUENCE (SIZE (1..maxNrofThresholdMBS-r18)) OF ThresholdMBS-r18     OPTIONAL,   -- Need R
    lateNonCriticalExtension              OCTET STRING                                                         OPTIONAL,
    nonCriticalExtension                  SEQUENCE {}                                                          OPTIONAL
}

ThresholdMBS-r18 ::=                  SEQUENCE {
    rsrp-r18                              RSRP-Range                                                           OPTIONAL,   -- Need R
    rsrq-r18                              RSRQ-Range                                                           OPTIONAL    -- Need R
}

MBS-SessionInfoMulticast-r18 ::=   SEQUENCE {
    mbs-SessionId-r18                  TMGI-r17,
    g-RNTI-r18                         RNTI-Value                                   OPTIONAL, -- Need R
    mrb-ListMulticast-r18              MRB-ListMulticast-r18                        OPTIONAL, -- Need R
    mtch-SchedulingInfo-r18            DRX-ConfigPTM-Index-r17                      OPTIONAL, -- Need S
    mtch-NeighbourCell-r18             BIT STRING (SIZE(maxNeighCellMBS-r17))       OPTIONAL, -- Need S
    pdsch-ConfigIndex-r18              PDSCH-ConfigIndex-r17                        OPTIONAL, -- Need S
    mtch-SSB-MappingWindowIndex-r18    MTCH-SSB-MappingWindowIndex-r17              OPTIONAL, -- Cond MTCH-Mapping
    thresholdIndex-r18                 INTEGER (0..maxNrofThresholdMBS-1-r18)       OPTIONAL, -- Need R
    pdcp-SyncIndicator-r18             ENUMERATED {true}                            OPTIONAL, -- Cond RRCRelease
    stopMonitoringRNTI-r18             ENUMERATED {true}                            OPTIONAL, -- Cond G-RNTI
    ...
}

• g-RNTI-r18 is optional here: in the broadcast entry the G-RNTI is mandatory. In the multicast entry it can be absent, for example when the session is joined but has nothing to send in this cell.
• thresholdMBS-List-r18 and thresholdIndex-r18: a per-session RSRP and/or RSRQ threshold. When the serving cell falls below it, the UE resumes the connection, so the network can serve it by PTP or move it.
• stopMonitoringRNTI-r18: tells the UE to stop monitoring the G-RNTI, when there is temporarily no data or the session is deactivated. If it stops for all its sessions, the UE also stops monitoring the Multicast MCCH-RNTI until a group notification arrives.
• pdcp-SyncIndicator-r18: present only in the copy sent with RRCRelease. It says that all cells in the RNA keep the same PDCP COUNT for this session, so after reselection the UE does not reset its PDCP state variables.
• mrb-ListMulticast-r18: the PTM-only MRB configuration. Unlike the broadcast MRB, the PDCP SN can be 12 or 18 bits.

The last piece is the wake-up. When the session is activated, or when there is new data after a pause, the gNB sends a group notification by paging. In Release 18 the paging record list has a parallel PagingGroupList-v1800, and each GroupPaging-r18 entry can carry inactiveReceptionAllowed-r18. With this flag, the member UE stays in RRC_INACTIVE and starts PTM reception. Without it, the UE resumes the connection. UE-specific paging overrides group notification, so a UE paged both ways goes to RRC_CONNECTED. The RRC_INACTIVE state itself is described in the RRC Inactive page.

Other Release 18 enhancements

Release 18 also changed a few things outside multicast in RRC_INACTIVE. They are smaller, but they appear in configurations and logs from Release 18 networks. Most of them make MBS work for UE types and deployments that Release 17 did not consider. The field suffixes tell which release a field belongs to.

• RedCap CFR: SIB20 can carry cfr-ConfigMCCH-MTCH-RedCap-r18 and mcch-ConfigRedCap-r18. A broadcast CFR can be wider than a RedCap UE supports, so the network can add a narrower one. A UE monitors only one CFR at a time, and the gNB makes sure that one G-RNTI or MCCH-RNTI is never scheduled in both CFRs at the same time.
• Broadcast from a non-serving cell: a connected UE can receive broadcast from a cell that is not its serving cell. It reports the parameters of that reception through mbs-NonServingInfoList-r18 in MBSInterestIndication, so the serving gNB can schedule unicast around it. SIB1 enables this report.
• Shared processing: 38.300 clause 16.10.6.7 describes how a UE shares its processing between unicast and broadcast. The UE capability tells the gNB whether it can receive the two FDMed in the same slot (38.214 clause 5.1).
• RAN sharing: a gNB shared by several PLMNs can detect broadcast sessions with identical content, using the Associated Session ID in NGAP, and send it once. 38.300 clause 16.10.6.8 describes it. The clause does not state the release, and this page does not verify it against the NGAP version history.

Release 19 continues the work. One visible example is mbs-SessionAreaList-r19 in MBS-SessionInfo-v1900, which ties a broadcast session to intended service areas. It is outside the scope of this page.

• The pattern across releases: Release 17 built the group delivery and the PTM/PTP framework. Release 18 moved more UEs out of RRC_CONNECTED and extended MBS to more UE types.
• Where to look in a log: SIB20 and MBSBroadcastConfiguration for broadcast; RRCReconfiguration with MRB-ToAddMod-r17 for connected multicast; RRCRelease with multicastConfigInactive-r18, SIB24 and MBSMulticastConfiguration for inactive multicast.

The release overviews are in the Release 17 and Release 18 pages.

Reference

• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 16.10, Multicast and Broadcast Services
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clauses 5.9 and 5.10, SIB20, SIB21, SIB24, MBSBroadcastConfiguration, MBSMulticastConfiguration, MBSInterestIndication
• 3GPP TS 38.321 V19.4.0 : NR; Medium Access Control (MAC) protocol specification. Table 7.1-1, RNTI values
• 3GPP TS 38.212 : NR; Multiplexing and channel coding. Clause 7.3.1.5, DCI formats 4_0, 4_1 and 4_2
• 3GPP TS 38.213 V19.4.0 : NR; Physical layer procedures for control. Clause 18, Multicast Broadcast Services
• 3GPP TS 38.214 V19.4.0 : NR; Physical layer procedures for data. Clause 5.1
• 3GPP TS 23.247 : Architectural enhancements for 5G multicast-broadcast services
• RNTI, DCI, Paging, RRC Inactive, Handover, HARQ (ShareTechnote)