Content for  TS 38.300  Word version:  18.3.0

There are two delivery modes as specified in TS 23.247:

• 5GC Shared MBS traffic delivery;
• 5GC Individual MBS traffic delivery.

As specified in TS 23.247, if the gNB supports MBS, the network shall use the 5GC Shared MBS traffic delivery in which case an MBS Session Resource context for a multicast session is setup in the gNB when the first UE joins the multicast session. For 5GC Shared MBS traffic delivery mode, shared NG-U resources are used to provide MBS user data to the gNB. The gNB initiates the Multicast Distribution Setup procedure towards the 5GC, to allocate shared NG-U resources for a multicast session. In case multiple MBS session areas as specified in TS 23.247 are associated with the same multicast session for location dependent MBS services, multiple NG-U shared resources are established for the same multicast session per MBS Area Session ID served by the gNB. A shared NG-U resource applies one of the following transport options:

• unicast transport;
• multicast transport.

For 5GC Shared MBS traffic delivery an MBS Session Resource comprises one or several MRBs. If minimisation of data loss is applied for a given MRB, synchronisation of allocation of PDCP COUNT values is applied by either or a combination of the following methods:

• derivation of the PDCP COUNT values by means of a DL MBS QFI Sequence Number provided on NG-U. Synchronisation in terms of MBS QoS flow to MRB mapping and PDCP SN size of the corresponding MRB among gNBs are achieved by means of network implementation.
• deployment of a Shared NG-U Termination at NG-RAN, shared among gNBs, which comprises a common entity for assignment of PDCP COUNT values. Synchronisation in terms of MBS QoS flow to MRB mapping and PDCP SN size of the corresponding MRB among gNBs may be achieved by means of network implementation.

If PDCP COUNT values are derived from a DL MBS QFI Sequence Number provided on NG-U and only one QoS Flow is mapped to an MRB, the gNB shall set the PDCP COUNT value of PDCP PDU to the value of the DL MBS QFI Sequence Number provided with the received packet over NG-U. If PDCP COUNT values are derived from a DL MBS QFI Sequence Number provided on NG-U and multiple QoS Flows are mapped to an MRB, the gNB may derive the PDCP COUNT value of the PDCP PDU from the sum of the DL MBS QFI Sequence Numbers of the QoS Flows mapped to this MRB. As specified in TS 23.247, the gNB may receive from the 5GC MBS Assistance Information associated with a multicast MBS session for a UE, which assists the gNB in configuring the UE properly. The MBS Assistance Information indicates that the UE is expected to require dedicated resources very frequently. Based on this information, the gNB may decide the RRC state of the UE. The QoS requirements of the multicast session apply regardless of the RRC state within which the UE receives multicast session data.

A UE can be configured to receive data of MBS multicast session only in RRC_CONNECTED state or RRC_INACTIVE state. To receive the multicast service, the UE needs to perform MBS Session Join procedure as specified in TS 23.247. It is up to gNB to decide whether the UE receives data of MBS multicast session in RRC_CONNECTED state or RRC_ INACTIVE state. The gNB moves the UE from RRC_CONNECTED state to RRC_INACTIVE state via RRCRelease message, and moves the UE from RRC_INACTIVE state to RRC_CONNECTED state via group notification or UE-specific paging. If the UE which joined a multicast session is in RRC_CONNECTED state and when the multicast session is activated, the gNB may send RRCReconfiguration message with relevant MBS configuration for the multicast session to the UE. If the gNB configures the UE to receive the MBS multicast session in RRC_INACTIVE state, the gNB may provide the PTM configuration via RRCRelease message for the MBS multicast session as well as information about which multicast service(s) can be continued to be received in RRC_INACTIVE state. The UE does not suspend MRBs of the multicast session indicated to be continued to be received in RRC_INACTIVE state. Multicast MCCH is used in case a cell supports updating PTM configuration or providing PTM configuration to UEs in RRC_INACTIVE state moved from other cells. Otherwise, multicast MCCH can be optionally present. A notification mechanism is used to announce the change of the multicast MCCH contents due to multicast session modification or session deactivation or due to neighbouring cell information modification. The scheduling information for multicast MCCH reception is provided via SIB24 and optionally via RRCRelease message. When there is temporarily no data to be sent to the UEs for a multicast session that is active, the gNB may move the UE to RRC_INACTIVE state. When an MBS multicast session is deactivated, the gNB may move the UE in RRC_CONNECTED state to RRC_IDLE or RRC_INACTIVE state. For UEs receiving data of MBS multicast session in RRC_INACTIVE state, the gNB notifies the UE to stop monitoring PDCCH addressed by corresponding G-RNTI via RRCRelease message or multicast MCCH when there is temporarily no data to be sent or when the session is deactivated. gNBs supporting MBS use a group notification mechanism to notify the UEs in RRC_IDLE or RRC_INACTIVE state when a multicast session has been activated by the CN. gNBs supporting MBS use a group notification mechanism to notify the UEs in RRC_INACTIVE state when the session is already activated and the gNB has multicast session data to deliver. If the UE receiving data of MBS multicast session in RRC_INACTIVE state in a cell is notified to stop monitoring PDCCH addressed by G-RNTI for all the joined multicast sessions, the UE does not monitor PDCCH addressed by Multicast MCCH-RNTI until the group notification is received. Upon reception of the group notification that does not indicate multicast reception in RRC_INACTIVE state, the UEs reconnect to the network or resume the connection and transition to RRC_CONNECTED state from either RRC_IDLE state or RRC_INACTIVE state. Upon reception of the group notification that indicates to allow the multicast reception in RRC_INACTIVE state, the UE stays in RRC_INACTIVE state and behaves as specified in TS 38.331. If the UE is notified by both group notification and the UE-specific paging, the UE follows the UE-specific paging and goes to RRC_CONNECTED state. The group notification is addressed with P-RNTI on PDCCH, and the paging channels are monitored by the UE as described in clause 9.2.5. Paging message for group notification contains MBS session ID which is utilized to page all UEs in RRC_IDLE and RRC_INACTIVE states that joined the associated MBS multicast session, i.e., UEs are not paged individually. The UE stops monitoring for group notifications related to a specific multicast session, i.e., stops checking for the MBS session ID in the Paging message, when the UE enters RRC_CONNECTED state. The UE does not monitor for group notifications for these cases, i.e., once this UE leaves this multicast session or the network requests the UE to leave, or the network releases the multicast session. If the UE in RRC_IDLE state that joined an MBS multicast session is camping on the gNB not supporting MBS, the UE may be notified by CN-initiated paging where CN pages each UE individually due to session activation or data availability, as described in clause 9.2.5. If the UE in RRC_INACTIVE state that joined MBS multicast session is camping on the gNB not supporting MBS, the UE may be notified individually by RAN-initiated paging due to session activation or data availability, as described in clause 9.2.5.

For multicast service, gNB may deliver MBS multicast data packets using the following methods:

• PTP Transmission: gNB individually delivers separate copies of MBS data packets to each UEs independently, i.e., gNB uses UE-specific PDCCH with CRC scrambled by UE-specific RNTI (e.g., C-RNTI) to schedule UE-specific PDSCH which is scrambled with the same UE-specific RNTI.
• PTM Transmission: gNB delivers a single copy of MBS data packets to a set of UEs, e.g., gNB uses group-common PDCCH with CRC scrambled by group-common RNTI to schedule group-common PDSCH which is scrambled with the same group-common RNTI.

If a UE is configured with both PTM and PTP transmissions, a gNB dynamically decides whether to deliver multicast data by PTM leg and/or PTP leg for a given UE based on the protocol stack defined in clause 16.10.3, based on information such as MBS Session QoS requirements, number of joined UEs, UE individual feedback on reception quality, and other criteria. The same QoS requirements apply regardless of the decision. PTP transmission is not supported for MBS multicast session data reception for UEs in RRC_INACTIVE state. SPS is not supported for MBS multicast session data reception for UEs in RRC_INACTIVE state.

UE can be configured to receive MBS multicast data either from a PCell or a single SCell at a time.

The following DRX configurations for PTM/PTP transmission by RRC_CONNECTED UEs are possible:

• For PTM transmission, multicast DRX is configured per G-RNTI/G-CS-RNTI which is independent of UE-specific DRX;
• For PTP transmission, UE-specific DRX is reused, i.e., UE-specific DRX is used for both unicast transmission and PTP transmission of MBS multicast. For PTM retransmission via PTP, UE monitors PDCCH scrambled by C-RNTI/CS-RNTI during UE-specific DRX's Active Time.

The following DRX configuration for PTM transmission by RRC_INACTIVE UEs is possible:

• For PTM transmission, multicast DRX is configured per G-RNTI.

A CFR configured by RRCReconfiguration message is defined for multicast scheduling as an 'MBS frequency region' with a number of contiguous PRBs confined within and with the same numerology as the DL BWP, and multicast scheduling may have specific characteristics (e.g., PDCCH, PDSCH and SPS configurations). The CFR for the multicast reception in RRC_INACTIVE state and the CFR for broadcast can be configured differently. If one CFR is not completely contained within the other CFR, the UE in RRC_INACTIVE state is not required to receive both broadcast and multicast simultaneously. Slot-level repetition is optionally supported for multicast MTCH reception in RRC_INACTIVE state. The maximum number of MIMO layers is one for MBS multicast scheduling for UEs in the RRC_INACTIVE state. Two HARQ-ACK reporting modes are defined for MBS:

• For the first HARQ-ACK reporting mode, the UE generates HARQ-ACK information with ACK value when a UE correctly decodes a transport block or detects a DCI format indicating an SPS PDSCH release; otherwise, the UE generates HARQ-ACK information with NACK value.
• For the second HARQ-ACK reporting mode, the UE does not transmit a PUCCH that would include only HARQ-ACK information with ACK values.

HARQ-ACK feedback for multicast can be enabled or disabled by higher layer configuration per G-RNTI or per G-CS-RNTI and/or indication in the DCI scheduling multicast transmission. HARQ feedback is not supported for MBS multicast session data reception for UEs in RRC_INACTIVE state.

For delivery of location dependent contents of a broadcast session, Area Session ID is included in the NGAP broadcast session resource setup procedure associated with MBS service area information and per Area Session ID NG-U tunnels are established. The 5GC may also provide information to the NG-RAN node whether the broadcast session is intended to be received by only (e)RedCap UEs, only UEs that are neither RedCap UEs nor eRedCap UEs or any kind of UEs. The NG-RAN may take this into account when configuring MBS session resources.

MBS broadcast can be received by UEs in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state. A UE can receive the MBS configuration for broadcast session (e.g., parameters needed for MTCH reception) via MCCH in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state. The parameters needed for the reception of MCCH are provided via System Information. The following principles govern the MCCH structure:

• MCCH provides the list of all broadcast services with ongoing sessions transmitted on MTCH(s) and the associated information for broadcast session includes MBS session ID, associated G-RNTI scheduling information and information about neighbouring cells providing certain service on MTCH(s). MCCH content is transmitted within periodically occurring time domain windows, referred to as MCCH transmission window defined by MCCH repetition period, MCCH window duration and radio frame/slot offset;
• MCCH uses a modification period and MCCH contents are only allowed to be modified at each modification period boundary; a notification mechanism is used to announce the change of MCCH contents due to broadcast session start, modification or stop and due to neighbouring cell information modification;
• When the UE receives an MCCH change notification, it acquires the updated MCCH in the same MCCH modification period where the change notification is sent.

UE can be configured to receive MBS broadcast data and MCCH either from a PCell or a single SCell at a time. Meanwhile, dedicated RRC signalling is used for providing SIB20 of the SCell i.e., while in RRC_CONNECTED state, UEs need not acquire broadcast SIB20 directly from the SCells.

Via MCCH, the UE can be configured with a PTM DRX configuration for G-RNTI reception. One PTM DRX configuration can be mapped to more than one G-RNTI.

For broadcast service, gNB may deliver Broadcast MBS data packets using the following method:

• PTM Transmission: gNB delivers a single copy of MBS data packets to a set of UEs, e.g., gNB uses group-common PDCCH with CRC scrambled by group-common RNTI to schedule group-common PDSCH which is scrambled with the same group-common RNTI.

A CFR configured by SIB is defined for broadcast scheduling as an 'MBS frequency region' with a number of contiguous PRBs with a bandwidth equal to or larger than CORESET0, with the same numerology as CORESET0, and broadcast scheduling may have specific characteristics (e.g., PDCCH and PDSCH configurations). The NG-RAN node may configure an additional RedCap CFR when the bandwidth of the configured default CFR exceeds the (e)RedCap UE capability. A UE only monitors one CFR at a time. An (e)RedCap UE monitors the RedCap CFR, if configured, otherwise the (e)RedCap UE monitors the default CFR, if the bandwidth of the default CFR is within the UE capability. The NG-RAN node ensures that a UE does not receive two DCIs simultaneously (i.e., one associated with the RedCap CFR and another associated with the default CFR) with the same G-RNTI or the same MCCH-RNTI. The maximum number of MIMO layers is one for MBS broadcast scheduling. RB-level rate matching, and RE-level rate matching around LTE-CRS configured by higher layer signalling are supported for MCCH and MTCH. Slot-level repetition is supported for MTCH. HARQ-ACK feedback is not supported for MBS broadcast. Only dynamic scheduling is supported for MBS broadcast.

If the UE in RRC_CONNECTED state is receiving or interested to receive an MBS broadcast service from a non-serving cell as described in TS 38.306 , the UE may use MBS Interest Indication message to inform the serving gNB about the parameters used for the non-serving cell broadcast reception as described in TS 38.331. The gNB may enable the sending of the MBS Interest Indication by including an indication in SIB1. The UE may indicate to the serving cell the UE capability for receiving MBS broadcast service from a non-serving cell. It is up to gNB implementation to consider the MBS Interest Indication and the UE capability for receiving MBS broadcast service from a non-serving cell, if indicated, when scheduling the UE. In case the UE only reports the frequency for broadcast service reception from the non-serving cell in MBS Interest Indication due to some parameters (e.g., SCS, bandwidth) not being available, the UE may transmit updated MBS Interest Indication once the parameters are available to the UE. It is up to network implementation on how to enable the UE to acquire these parameters from the non-serving cell.

NGAP supports resource sharing efficient scheme for broadcast delivery in RAN sharing. Such scheme enables the gNB to identify broadcast MBS sessions from different PLMNs providing identical content. The identification is based on information provided by the involved 5GCs in the Associated Session ID as specified in TS 23.247. If in the MBS Broadcast Setup Request message an Associated Session ID is received from a 5GC participating in RAN sharing, the gNB uses it to determine whether MBS Session resources can be shared with a broadcast MBS session(s) associated with the same Associated Session ID requested from another 5GC participating in RAN sharing. The identification of MBS Broadcast Sessions providing identical content may also be based on implementation specific configuration as specified in TS 23.247. The gNB applying this resource efficiency scheme:

• may decide whether NG-U resources are established towards all involved 5GCs or only some of them;
• resolves different QoS requirements or different S-NSSAIs received from the participating 5GCs in an implementation specific way.

The gNB may also trigger the NGAP Broadcast Session Transport procedure towards one 5GC participating in RAN sharing to set up NG-U resources to maintain NG-U connectivity as specified in TS 23.247.