Content for  TS 23.247  Word version:  18.7.0

For MBS services, the network shall support QoS control per MBS session. The 5G QoS model and parameters as defined in clause 5.7 of TS 23.501 also apply to multicast/broadcast communication services with the following differences:

• Reflective QoS is not applicable;
• Wireline access network specific 5G QoS parameters do not apply to MBS services;
• Alternative QoS Profile is not applicable;
• QoS Notification Control is not applicable;
• UE-AMBR is not applicable;
• Session-AMBR if provided is enforced at MB-UPF but not communicated to NG-RAN.
• For broadcast MBS session, the QoS rule and QoS Flow level QoS parameters are not provided to UE.
• For multicast MBS sessions, the QoS rule and QoS Flow level QoS parameters of MBS QoS Flow are not provided to UE.
• For multicast MBS sessions, the handling of QoS rule and QoS Flow level QoS parameters of the associated QoS Flow(s) is the same as for other QoS Flow without UL in a PDU Session.

The network shall support one or multiple QoS flows, which can be either GBR or non-GBR, for an MBS session. If 5GC Individual MBS traffic delivery method is used to deliver multicast data packets, the network may use dedicated QoS Flows for multicast data packets in a PDU session. For the associated QoS Flow in the PDU session, the SMF uses the same QoS parameters (e.g. 5QI) provided by MB-SMF. These dedicated QoS Flows shall be kept separate from QoS Flows unrelated to multicast even if the same 5QI and other QoS parameters are assigned. The MB-SMF may obtain QoS information for multicast and broadcast MBS session in different ways depending on the deployment and use cases. If dynamic PCC is not deployed:

• When an MBS session is started, the MB-SMF is provided with service requirements including QoS information. If MBSF is not used, the service requirement is provided to the MB-SMF by the AF (directly or via the NEF). If the MBSF is used, the MBSF receives request from the AF (or via the NEF) and decides the related QoS requirements (e.g. considering support for FEC) and provides them to the MB-SMF. The MB-SMF determines the QoS profiles and QoS for N4 rules for the MBS session with QoS parameters of the MBS QoS flows, and provides related information to the RAN and the MB-UPF respectively.

If dynamic PCC is deployed:

• It is the PCF that generates policy rules for MBS Session based on the received service requirement and provides the policy rules to the MB-SMF. The MB-SMF, based on the policy rules from the PCF, determines to create, and/or modify MBS QoS Flow(s) including providing QoS information to NG-RAN and MB-UPF, and providing packet detection and forwarding information to MB-UPF.

The MB-UPF acts as the MBS Session Anchor of an MBS session, and if the MBSTF is involved in the MBS session, then the MBSTF acts as the media anchor of the MBS traffic. The MB-UPF receives only one copy of MBS data packets from AF or MBSTF. The user plane between MB-UPF and AF, may use either multicast transport or a unicast tunnel for the MBS session (depending on application and capabilities of control interface). If the transport network does not support multicast transport, the user plane uses a unicast tunnel for the MBS Session. The user plane between MBSTF and AF may use a unicast tunnel, multicast transport or other means (e.g. HTTP download from external CDN). The user plane between MBSTF and MB-UPF uses a unicast tunnel for the MBS session. If a unicast tunnel is used for the MBS Session between MB-UPF and AF or MBSTF, after receiving the downlink MBS data, the MB-UPF forwards the downlink MBS data without the received outer IP header and tunnel header information. The user plane from the MB-UPF to NG-RAN(s) (for 5GC Shared MBS traffic delivery) and the user plane from the MB-UPF to UPFs (for 5GC Individual MBS traffic delivery) may use multicast transport via a common GTP-U tunnel per MBS session, or use unicast transport via separate GTP-U tunnels at NG-RAN or at UPF per MBS session in the following way

• For 5GC Shared MBS traffic delivery (i.e. MB-UPF delivers user plane data to NG-RAN supporting MBS), if the transport network supports IP multicast, the NG-RAN node uses multicast transport via a common GTP-U tunnel per MBS session, otherwise unicast transport via separate GTP-U tunnel per MBS session per NG-RAN node is used.
• For 5GC Individual MBS traffic delivery (i.e. MB-UPF delivers user plane data to UPF), if the transport network supports IP multicast and the UPF supports reception of multicast data over N19mb, UPF use multicast transport via a common GTP-U tunnel per MBS session, otherwise unicast transport via separate GTP-U tunnel per MBS session per UPF is used.

If the user plane uses unicast transport, the transport layer destination is the IP address of the NG-RAN or UPF, each NG-RAN or UPF allocates the tunnel separately and multiple GTP-U tunnels are used for the MBS Session. If the user plane uses multicast transport, a common GTP-U tunnel is used for both RAN and UPF nodes. The GTP-U tunnel is identified by a common tunnel ID and an IP multicast address as the transport layer destination, both assigned by 5GC. The above is depicted in Figure 6.7-1. There could be more than one NG-RANs or UPFs that are involved in the MBS traffic delivery.

The MB-SMF instructs the MB-UPF to receive packets related to an MBS session. MB-UPF transmits the MBS data with the sequence number for each MBS QoS Flow as defined in TS 29.281. For shared delivery, if unicast transport over N3mb applies, the MB-SMF instructs MB-UPF to replicate the received MBS packets and forward them towards multiple RAN nodes via separate GTP tunnel. For shared delivery, if multicast transport over N3mb applies, the MB-SMF instructs the MB-UPF to replicate the received MBS data and forwards the data via a single GTP tunnel. For individual delivery, the MBS data received by the MB-UPF is replicated towards the UPF(s) where individual delivery is performed in the following way:

• The MB-SMF configures the MB-UPF to receive packets related to an MBS session, to replicate those packets and forward them towards multiple UPFs via GTP tunnels if unicast transport over N19mb is applied, or via a single GTP tunnel if multicast transport over N19mb is applied.
• The SMF(s) instructs the UPF to receive packets related to a Multicast MBS session from an MB-UPF over N19mb, to replicate those packets and to forward them in multiple PDU sessions.

For the MB-SMF and MB-UPF, packet detection, replication and forwarding for an MBS session is realized by using for each MBS session one PDR that detects the incoming MBS packets and points to one FAR that describes the forwarding of the data towards multiple destinations (UPFs or RAN nodes):

• A PFCP session is created when the MBS Session is started, regardless of multicast or unicast transport over N3mb and N19mb.
• For Multicast transport over N3mb and N19mb, the destination in the FAR contains the MB-UPF IP Multicast Distribution Info.
• For unicast transport over N3mb and N19mb, the FAR in the PFCP session may contain multiple destinations represented by the NG-RAN N3mb Tunnel Info and UPF N19mb Tunnel Info (if applicable).

For the SMF and the UPF (for 5GC individual delivery), packet detection, replication and forwarding for an MBS session is realized by PDR and FAR of the PDU session in which the UE has joined the MBS session:

• The SMF instructs the UPF to associate the PFCP session of the PDU session with an MBS session.
• A new PDR with Source Interface "Core" is used to detect MBS data from N19mb.
• For unicast transport over N19mb, the SMF requests UPF to allocate N19mb Tunnel Info if not allocated.
• For multicast transport over N19mb, the SMF includes the low layer source specific multicast address information and C-TEID to UPF.
• If the SMF wants to maintain the MBS data reception over N19mb but suspends the delivery of the data to the UE's PDU session, the Action of FAR set to "drop" (e.g. when the UE is switching from 5GC Individual delivery to 5GC Shared delivery due to the UE moving from MBS non-supporting NG-RAN to MBS supporting NG-RAN). Otherwise the SMF remove the related PDR and FAR.

See TS 29.244 for the details of user plane handling.

In order to minimize the interruption of services, upon mobility for MBS service from NR/5GC to E-UTRAN/EPC and vice versa, the following applies:

• If the same MBS service is provided via eMBMS in E-UTRAN and MBS, interworking is supported at service layer.
• The UE is always configured with a common TMGI regardless of whether the UE is discovering the MBMS/MBS service via E-UTRAN or NR, for both multicast and broadcast MBS services.
• When the UE camps on NR and uses a multicast MBS service, the UE joins a multicast MBS session and uses procedures as defined in clause 7.2 for MBS reception for the TMGI. When the UE camps on E-UTRAN, the UE uses procedures as defined in TS 23.246 for MBMS reception for the TMGI.
• The session context for multicast MBS service transferring is not handed over to E-UTRAN during mobility from 5GS to EPS.

Service Announcement provides the UE with descriptions specifying the multicast or broadcast services to be delivered as part of MBS Session. The Service Announcement may be encoded as defined in TS 26.517 or use application specific formats outside the scope of 3GPP. Service Announcement information may be delivered to the UE via application specific means or as defined in TS 26.502, using one of the following methods:

• Pre-configured at UE side;
• Via an MBS Session; or
• Via a regular PDU Session.

The Service Announcement includes the MBS Session ID(s), which is represented by TMGI or a Source Specific IP Multicast Address, for the service. When the MBS Session ID is Source Specific IP Multicast Address, the Service Announcement may include the PLMN ID of the PLMN and NID for an SNPN in which the service is delivered. The Service Announcement includes an MBS Service Type, which indicates whether the MBS Session for the service is multicast or broadcast. For local MBS service, the Service Announcement may include the MBS service area. The MBS service area used by AF can be Cell ID list, TAI list, geographical area information or civic address information. Amongst them, Cell ID list and TAI list shall only be used by AFs who reside in trust domain, and when the AFs are aware of such information. The service announcement may contain a start time and/or a sequence of scheduled activation times (e.g. a first time and a periodicity) of the MBS session when the AF may activate the MBS session (for multicast only) and transmit MBS data as described in clause 6.16. When the AF decides that the start time and/or scheduled activation times for the MBS session need to be updated and the UE is unreachable (e.g. due to power saving function), the AF can send service announcement containing the updated time information to the UE at the old start time (if earlier than the new start time) or next scheduled activation time previously provided to the UE for the MBS session via multicast or broadcast. If the MBS Session is for multicast, the Service Announcement may include the DNN and S-NSSAI of the PDU Session to indicate which PDU Session is associated with the MBS Session. If the MBS Session is for broadcast, the Service Announcement may include the MBS FSA ID(s) and optional frequency information associated with the broadcast MBS session and may also include an indication that the MBS Session is intended for RedCap UEs, for non-RedCap UEs or both for RedCap UEs and non-RedCap UEs as defined in TS 26.502. The Service Announcement may be provided to a UE by AF or MBSF, or may be retrieved by the UE from those entities.

Compared to the paging strategy handling specified in clause 5.4.3 of TS 23.501, the following additional functionality for multicast MBS service applies:

• At multicast MBS Session Activation, the SMF may provide the most demanding ARP and 5QI of all MBS QoS Flow within the MBS session to the AMF.
• The AMF may take the received ARP and 5QI into consideration in paging differentiation.

Security function may be used to protect MBS related signalling/data. Detailed descriptions of security requirements, procedures and handling for 5G Multicast/Broadcast Service (MBS) are provided in TS 33.501. MBS security function is implemented in the MBSF/MBSTF so that it can be applied only when MBSF/MBSTF are used (i.e. Configuration option 2 and 3). For configuration option 1 how to support MBS security is out of scope of this specification. The following additions to the MBS procedures for multicast Session in the present specification apply if the functionalities of MBS security for control plane procedure for multicast as defined in TS 33.501 is used:

• The multicast session security context, as defined in TS 33.501, is used to protect MBS traffic of an MBS session. During the session establishment and when a UE joins, the multicast session security context contains MSK and MTK.
• The UEs in the MBS session use the received multicast session security context to process the protected MBS traffic.
• MBSF distributes the multicast session security context to the MB-SMF via the Nmbsmf_MBSSession_Create Request or Nmbsmf_MBSSession_Update Request message.
• The SMF interacts with the MB-SMF to obtain the multicast session security context. The MB-SMF provides the security context in the Nmbsmf_MBSSession_ContextStatusSubscribe response message and in the Nmbsmf_MBSSession_ContextStatusNotify request message.
• If the UE is authorized to join the Multicast MBS session, the SMF shall provide the multicast session security context to the UE in N1 SM container if it received the multicast session security context from the MB-SMF.
• When the MSK needs to be updated, MBSF shall send the updated multicast session security context to the MB-SMF, and then the MB-SMF shall trigger the session update as specified in clause 7.2.6 to provide the updated multicast session security context to the UEs in the related MBS session. The updated multicast session security context shall contain an updated MSK and may contain an updated MTK in addition.

MBS Service Information is a set of information used by the AF to describe an MBS session. It is directly conveyed from the AF to the MB-SMF or indirectly via NEF and/or MBSF. For a location dependent MBS Session, the same MBS Service Information should be provided by the AF for each MBS Service Area. In addition, MBS Service Information may be optionally sent from AF/NEF/MBSF to the PCF based on network configuration. The MBS Service Information consists of an optional AF Application Identifier, an optional Session-AMBR and the description of one or more data flows/media components. For each data flow/media component, the following information may be provided:

• Flow description; and
• one of the following:
• Media information (Media type, Media format, bandwidth) with optional Priority indicator;
• QoS requirements (5G QoS parameters (i.e. 5QI, ARP, GBR, MBR) or QoS reference).

The following MBS Service Information is mandatory to be supported: 5G QoS parameters (i.e. 5QI, ARP, GBR, MBR) and optional Session-AMBR for one data flow/media component. Additional MBS Service Information is optional to be supported.

Group Message Delivery via MBS Session is a feature that allows an AF to deliver a payload to a group of UEs located in a particular geographical area via a broadcast MBS Session, e.g. for Machine-Type communication. The AF may request to deliver group message and the AF may also request to recall (i.e. cancel) or replace a previously submitted group message. If some UEs of the group are RedCap UEs, the Target UE Classes is provided as described in TS 26.502, to provide the information be used as "NR RedCap UE information" specified in clause 6.19. Group Message Delivery utilizes the Object Distribution Method in MBSTF specified in TS 26.502. The Object Distribution Method can benefit from Application Layer Forward Error Correction (AL-FEC) to achieve reliable delivery. In Group Message Delivery via MBS Session, the NEF is responsible for handling the group message delivery request from the AF, that is, the NEF transforms the group message into a file and determines the meta data information of the file. Over control plane, the NEF provisions Application Service (i.e. MBS User Service creation and MBS User Data Ingest Session creation as specified in TS 26.502), which then triggers the MBS session creation towards 5GC and NG-RAN. Over user plane, the NEF is responsible for ingesting the file to the MBSTF, which then delivers the file to the UE(s) via 5GC Shared MBS traffic delivery.

MBS provide means to deliver data over MBS Session to multiple UEs at the same time. However, for UEs using power saving functions, e.g. MICO (Mobile Initiated Connection Only) mode with Active Time, or extended DRX (Extended Discontinuous Reception) as defined in clause 5.31.7 of TS 23.501, the UEs are usually unreachable for long periods of time. Moreover, different UEs are likely to be reachable at different times. If a UE becomes unreachable for unicast data transfer due to its using power saving functions, the UE may still be involved in MBS specific operations, e.g. activation/deactivation of the MBS service, MBS data transfer reception, reception of service announcement (if needed). To receive MBS data, those UEs need to wake up at coordinated times when the MBS data is to be transmitted. The UE is informed via the service announcement about a start time and/or a sequence of scheduled activation times (e.g. a first time and a periodicity) of the MBS Session when the AF may activate the MBS Session and transmit MBS data, as described in clause 6.11. The AF may send data starting either at the start time or at any scheduled activation times. If the AF sends data using an multicast MBS Session at a scheduled activation time, it shall first activate the multicast MBS Session at that scheduled activation time.

To provide multicast MBS service to more UEs in a cell, the NG-RAN may decide to move some UE(s) receiving multicast MBS data from RRC_CONNECTED to RRC_INACTIVE state if the UE(s) is capable to receiving MBS data in RRC_INACTIVE state. The decision in NG-RAN may use the following information provided from 5GC:

• Existing MBS session QoS parameters, e.g. the most demanding ARP and 5QI of all MBS QoS Flow within the MBS session.
• MBS assistance information for the MBS session, the MBS assistance information for the MBS session is an optional parameter and associated with one MBS session, which consists of an indication that the UE is preferred to be kept in connected when the related MBS session that the UE joined is active. When the NG-RAN node receives this information, the NG-RAN may determine to keep the UE in RRC_CONNECTED state even if the MBS session data is supported to be received in RRC_INACTIVE state.

The MBS session QoS parameters (e.g. ARP and 5QI) are provided to NG-RAN by the MB-SMF during user plane establishment for shared delivery. The NG RAN node indicates to the 5GC when a UE joins and during Xn handover in N2 SM related information that it supports MBS multicast with reception in RRC_INACTIVE state. Per the MBS session that the UE joined, the related "MBS assistance information for the MBS session" is provided to NG-RAN by the SMF if the MBS assistance information is available in the SMF and the MBS session that the UE joined is included in the MBS assistance information. The SMF gets from the UDM the "MBS assistance information", which is provisioned by the AF via the NEF to the UDM as part of the MBS subscription data and includes all the MBS session ID(s), where the UE is preferred to be kept connected when the related MBS session that the UE joined is active (as specified in clause 6.4). The SMF provides the "MBS assistance information for the MBS session" to the NG-RAN as part of the associated PDU session information within the N2 SM information in the procedures where the associated PDU session information need be sent to NG-RAN node, e.g. PDU Session modification for UE joining, handover procedure as detailed in clause 7.2.1.3 and clause 7.2.3.8.1, respectively. When an MBS session is to be activated, if there are UE(s) that joined the MBS session, the 5GC activates the MBS Session in the NG-RANs serving the joined UE(s). When the NG-RAN triggers the group paging to activate the MBS session and decides to enable Multicast MBS session data reception for UE with RRC_INACTIVE state, it also indicates that the MBS session data is allowed to be received in RRC_INACTIVE state. Hence the joined UEs in RRC_INACTIVE state in the cells, where the delivered MBS session is allowed to be received in RRC_INACTIVE state, may be able to stay in RRC_INACTIVE state and receive MBS Session data. When a UE in RRC_INACTIVE state is receiving ongoing MBS session data, if the UE moves to a new cell within the RNA, or if the UE moves outside the current RNA but within the current Registration Area, or if the UE moves out of the current Registration Area, the UE should be able to receive the MBS session data if applicable in the new area.

In network sharing scenario as specified in clause 5.18 of TS 23.501, the same MBS broadcast service may be delivered via multiple operators' CN participating in the network sharing to a shared NG-RAN, and the shared NG-RAN nodes may broadcast the MBS data only once for resource efficiency. When the AF creates multiple broadcast MBS sessions via multiple CNs to deliver the same content, the shared NG-RAN allocates radio resource for one of broadcast MBS Sessions instead of allocating radio resource for all the broadcast MBS Sessions. The NG-RAN determines the broadcast MBS sessions delivering the same content in one of the following ways:

• Based on the Associated Session ID (see clause 6.5.5) provided by the AF to the NG-RAN via 5GCs when creating broadcast MBS sessions.
• Based on the association of MBS session identifiers (i.e. TMGIs) configured in NG-RAN, the shared NG-RAN nodes can determine that the multiple broadcast MBS sessions are transmitting the same content for the same MBS service. For the location dependent MBS session, the existing MBS session identifiers are used to identify multiple broadcast MBS Sessions via different CNs delivering the same content. The MB-SMF should be able to accept MBS session creation with TMGIs without prior allocation of those TMGIs.

For a location dependent MBS session (see Clauses 6.2.3), the AF(s) that create the location dependent MBS sessions towards the participating PLMNs shall supply MBS Service Areas mapped to the same shared radio cells (but that may also be mapped to different non-shared radio cells). For location dependent broadcast services, the shared NG-RAN is required to determine that the multiple broadcast MBS Sessions via different CNs deliver the same content for location-dependent MBS session with additionally considering the MBS Service Area. Illustrated in Figure 6.18-1 is an example that the AF creates broadcast MBS Sessions via 5GC Operators A, B and C respectively to deliver the same content and N3mb unicast transport is used from 5GC to the NG-RAN. Based on operator policy, the NG-RAN node decides towards which operator(s)' 5GC(s) to establish N3mb tunnel(s), i.e. towards only one, some or all operators' 5GC(s). If N3mb multicast transport is used (not shown in Figure 6.18-1), the NG-RAN node decides which multicast group(s) (i.e. LL SSM(s)) to join. Over the Uu interface, the NG-RAN allocates radio resource for only one of the established broadcast MBS Sessions regardless of the number of N3mb tunnels established to deliver the MBS packets.

TS 38.300 defines the NR RedCap UEs that can only support limited bandwidth and have lower complexity compared to non-RedCap UEs. In order to allocate the appropriate radio resource as defined in TS 38.331, NG-RAN needs to be able to determine whether the broadcast MBS session is intended only for NR RedCap UEs, for both NR RedCap UEs and non-RedCap UEs, or only for non-RedCap UEs. The "NR RedCap UE information" parameter comprises an indication for a broadcast MBS session that can take the following values: "MBS session expected to be received only by RedCap UEs", "MBS session expected to be received both by RedCap UEs and non-RedCap UEs", or "MBS session expected to be received only by non-RedCap UEs". The "NR RedCap UE Information" parameter is provided by the AF to the NEF/MBSF and the MB-SMF as part of MBS Session Creation. The MB-SMF then forwards the "NR RedCap UEs Information" parameter in N2 SM Information to the NG-RAN via the AMF in MBS Session Start procedure defined in clause 7.3.1. The "NR RedCap UE Information" parameter may be updated by the AF to the NEF/MBSF and the MB-SMF as part of MBS Session Update. The MB-SMF then forwards the updated information to the NG-RAN via the AMF in MBS Session Update procedure defined in clause 7.3.3.

Quality of Experience (QoE) measurement collection (QMC) may be supported in 5GS as described in clause 5.25.3 of TS 23.501. QMC may also be supported to measure the QoE related to the reception of MBS multicast and broadcast sessions as specified in clause 21 of TS 38.300.