NR system enables resource efficient delivery of multicast/broadcast services (MBS).
For broadcast communication service, the same service and the same specific content data are provided simultaneously to all UEs in a geographical area (i.e., all UEs in the broadcast service area as defined in TS 23.247 are authorized to receive the data). A broadcast communication service is delivered to the UEs using a broadcast session. A UE can receive a broadcast communication service in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state.
For multicast communication service, the same service and the same specific content data are provided simultaneously to a dedicated set of UEs (i.e., not all UEs in the multicast service area as defined in TS 23.247 are authorized to receive the data). A multicast communication service is delivered to the UEs using a multicast session. A UE can receive a multicast communication service in RRC_CONNECTED state with mechanisms such as PTP and/or PTM delivery, as defined in clause 126.96.36.199. HARQ feedback/retransmission can be applied to both PTP and PTM transmission.
The overall NG-RAN architecture specified in clause 4 applies for NR MBS. MBS multicast can only be supported in MCG side in NE-DC and NR-DC scenarios, i.e., only for MN-terminated MCG MRB; the configuration of MBS broadcast on SCG is not supported for the UE.
The QoS model for NR MBS can be found in TS 23.247.
Figure 16.10.3-1 and Figure 16.10.3-2 depict the downlink Layer 2 architecture for multicast session and broadcast session respectively, where MBS protocol stack comprises the same layer 2 sublayers as described in clause 6 with the following differences:
SDAP sublayer provides only the following functionalities:
Mapping between an MBS QoS flow and an MRB;
Transfer of user plane data.
PDCP sublayer provides only the following functionalities:
Transfer of user plane data;
Maintenance of PDCP SNs;
Header compression and decompression using the ROHC protocol or EHC protocol;
Reordering and in-order delivery;
For a multicast session, gNB provides one or more of the following multicast MRB configuration(s) to the UE via dedicated RRC signalling:
Multicast MRB with DL only RLC-UM or bidirectional RLC-UM configuration for PTP transmission;
Multicast MRB with RLC-AM entity configuration for PTP transmission;
Multicast MRB with DL only RLC-UM entity for PTM transmission;
Multicast MRB with two RLC-UM entities, one DL only RLC-UM entity for PTP transmission and the other DL only RLC-UM entity for PTM transmission;
Multicast MRB with three RLC-UM entities, one DL RLC-UM entity and one UL RLC-UM entity for PTP transmission and the other DL only RLC-UM entity for PTM transmission;
Multicast MRB with two RLC entities, one RLC-AM entity for PTP transmission and the other DL only RLC-UM entity for PTM transmission.
For a multicast session, gNB may change the MRB type using RRC signalling.
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:
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.
A UE can receive data of MBS multicast session only in RRC_CONNECTED state. If the UE which joined a multicast session is in RRC_CONNECTED state and when the multicast session is activated, the gNB sends RRCReconfiguration message with relevant MBS configuration for the multicast session to the UE.
When there is (temporarily) no data to be sent to the UEs for a multicast session, the gNB may move the UE to RRC IDLE/INACTIVE state. gNBs supporting MBS use a group notification mechanism to notify the UEs in RRC IDLE/INACTIVE state when a multicast session has been activated by the CN or the gNB has multicast session data to deliver. Upon reception of the group notification, the UEs reconnect to the network. 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 once the UE leaves this multicast session.
If the UE in RRC IDLE state that joined an MBS multicast session is camping on gNB not supporting MBS, the UE may be notified about multicast session activation or data availability by CN-initiated paging where CN pages each UE individually, as described in clause 9.2.5. If the UE in RRC INACTIVE state that joined MBS multicast session is camping on gNB not supporting MBS, the UE may be notified about data availability individually by RAN-initiated paging, as described in clause 9.2.5.
Mobility procedures for multicast reception allow the UE to continue receiving multicast service(s) via PTM or PTP in a new cell after handover.
During handover preparation phase, the source gNB transfers to the target gNB about the MBS multicast sessions the UE has joined in the UE context information. To support provision of local multicast service with location dependent content as specified in TS 23.247, for each active multicast session, service area information per Area Session ID may be provided to the target gNB.
The source gNB may propose data forwarding for some MRBs to minimize data loss and may exchange the corresponding MRB PDCP Sequence Number with the target gNB during the handover preparation:
The lossless handover for multicast service is supported for the handover between MBS supporting cells if the UE is configured with PTP RLC AM entity in target cell MRB of a UE, regardless of whether the UE is configured with PTP RLC AM entity in the source cell or not.
In order to support lossless handover for multicast service, the network has to ensure DL PDCP COUNT value synchronization and continuity between the source cell and the target cell. Furthermore, data forwarding from the source gNB to the target gNB and/or PDCP status report provided by a UE for an MRB for multicast session can be used during lossless handover.
For each multicast session with ongoing user data transmission for which no MBS Session Resources exist at the target gNB, the target gNB triggers the setup of MBS user plane resources towards the 5GC using the NGAP Distribution Setup procedure. If unicast transport is used, the target gNB provides the DL tunnel endpoint to be used to the MB-SMF. If multicast transport is used, the target gNB receives the IP multicast address from the MB-SMF.
During handover execution, the MBS configuration decided at target gNB is sent to the UE via the source gNB within an RRC container as specified in TS 38.331. When the UE connects to the target gNB, the target gNB sends an indication that it is an MBS-supporting node to the SMF in the Path Switch Request message (Xn handover) or Handover Request Acknowledge message (NG handover).
Upon successful handover completion, the source gNB may trigger the release of the MBS user plane resources towards the 5GC using the NGAP Distribution Release procedure for any multicast session for which there is no remaining joined UE in the gNB.
During an MBS multicast session, at mobility from an MBS-supporting cell to an MBS non-supporting cell, the target gNB sets up PDU Session Resources mapped to the MBS multicast Session. The 5GC infers from the absence of an "MBS-support" indication from gNB in the Path Switch Request message (Xn handover) or Handover Request Acknowledge message (NG handover) that MBS multicast data packets delivery has to be switched to 5GC individual MBS traffic delivery as specified in TS 23.247. If data forwarding is applied, the source gNB infers from the handover preparation response message that the target gNB does not support MBS and changes the QFI(s) in the forwarded packets to the associated PDU Session QFI(s) if respective mapping information is available. The source gNB may be aware that the target gNB is non-MBS supporting already before Handover Preparation.
For mobility from MBS non-supporting cell to MBS-supporting cell, the existing Xn/NG handover procedures apply. The 5GC infers from the presence of the "MBS-support" indicator from gNB in the Path Switch Request message (Xn handover) or in the Handover Request Acknowledge message (NG handover) that MBS multicast data packets delivery can be switched from 5GC Individual MBS traffic delivery to 5GC Shared MBS traffic delivery. After Xn handover, the SMF triggers switching MBS multicast data packets delivery from 5GC Individual to 5GC Shared MBS traffic delivery by providing MBS Session IDs joined by the UE to the target gNB by means of the PDU Session Resource Modification procedure. And for NG handover, the SMF provides the MBS Session IDs joined by the UE to the target gNB by means of NGAP Handover Request. Minimization of data loss and duplication avoidance may be applied by means of identical MBS QFI SNs received over both the shared NG-U and the unicast NG-U tunnels.
Mobility from a multicast-supporting cell to a multicast non-supporting cell can be achieved by switching the MRB to a DRB in the source gNB before a handover.
The gNB may use RRCReconfiguration message to configure or reconfigure a multicast MRB, e.g., add/release/modify the MRB's RLC entities as described in clause 16.10.3. In order to minimize the data loss due to MRB reconfiguration, gNB may configure UE to send a PDCP status report during reconfiguration which results in MRB type change.
For multicast service, gNB may deliver Multicast MBS 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.
The following DRX configurations for PTM/PTP transmission 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.
A common frequency resource configured by SRB 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, but multicast scheduling may have specific characteristics (e.g., PDCCH, PDSCH and SPS configurations).
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.
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.
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 a MCCH change notification, it acquires the updated MCCH in the same MCCH modification period where the change notification is sent.
UE can 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.
Mobility principles builds on existing functionality including functions described in clause 9.2.
NR MBS supports MBS frequency layer prioritization for MBS broadcast sessions. The gNBs may be configured with the MBS FSA ID(s) supported by each of their cells. The gNBs may exchange this information with their neighbours within Xn Setup messages and subsequent Xn Configuration Update messages to help with frequency layer prioritization.
Mobility procedures for MBS reception allow the UE to start or continue receiving MBS service(s) when changing cells. The gNB may indicate in the MCCH the list of neighbour cells providing the same MBS broadcast service(s) as provided in the serving cell. This allows the UE, e.g., to request unicast reception of the service before moving to a cell not providing the MBS broadcast service(s) using PTM transmission. To avoid the need to read MBS broadcast related system information and potentially MCCH on neighbour frequencies, the UE is made aware of which frequency is providing which MBS broadcast services via PTM, through the combination of the following MBS related information:
User Service Description (USD), as defined in TS 26.346;
In RRC_IDLE and RRC_INACTIVE, the UE applies the normal cell reselection rules with the following modifications:
the UE which is receiving or interested to receive MBS broadcast service(s) via PTM and can only receive these MBS broadcast service(s) via PTM while camping on the frequency providing these MBS broadcast service(s) is allowed to make this frequency highest priority when the conditions described in TS 38.304 are met;
when the MBS broadcast service(s) which the UE is interested in are no longer available (after the end of the session) or the UE is no longer interested in receiving the service(s), the UE no longer prioritises the frequency providing these MBS broadcast service(s).
To ensure service continuity of MBS broadcast, the UE in RRC_CONNECTED state may send MBS Interest Indication to the gNB, consisting of the following information:
List of MBS frequencies UE is interested to receive, sorted in decreasing order of interest;
Priority between the reception of all listed MBS frequencies and the reception of any unicast bearer;
List of MBS broadcast services the UE is interested to receive, in case SIB20 is scheduled by the UE's PCell.
MBS Interest Indication information reporting can be implicitly enabled/disabled by the presence of SIB21.
The gNB may use this information, together with the information about the UE's capabilities (e.g., supported band combinations), when providing an RRC configuration and/or downlink assignments to the UE, to allow the UE to receive the MBS services the UE is interested in. MBS Interest Indication information can be exchanged between source gNB and target gNB during handover.
A common frequency resource 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, but broadcast scheduling may have specific characteristics (e.g., PDCCH and PDSCH configurations).
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.
In case of a disaster, a radio access network can experience outage, which can result in that UEs belonging to the network experience service interruptions. For this scenario, another network not affected by the disaster, which during non-disaster situations is considered by the UEs as a forbidden network, can allow roaming of the UEs belonging to the network experiencing such disaster service interruptions. Such roaming is referred to as disaster roaming. This is further described in clause 5.40 of TS 23.501 and clause 3.10 of TS 23.122.
To allow such disaster roaming, a cell can broadcast a list of PLMNs with disaster conditions for which disaster roaming is offered. Disaster roaming service is provided only for the area that covers the area with disaster condition.
Further, to be able to control the load that disaster roaming UEs put on a cell, the cell can broadcast access control parameters applicable specifically for disaster roaming UEs. Access attempts of disaster roaming UEs are based on Access Identity 3. The network can for example set the access control parameters for Access Identity 3 so that access attempts of disaster roaming UEs are more likely to be barred compared to non-disaster roaming UEs.