6 Functionalities and features

23.2473GPPArchitectural enhancements for 5G multicast-broadcast servicesRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Authorization to MBS service

6.1.1 AF authorization to the service for multicast and broadcast

The AF should be authorized by the 5GC for delivering MBS data to the 5GC and/or interacting with the 5GC. For signalling exchange with the 5GC, the NEF perform authorization to the external AF for determination of whether the interaction with the 5GC is allowed or not.

6.1.2 UE authorization to the service for multicast

The following authorizations are defined:

a) Whether the UE is authorized to use the Multicast service in the PLMN.

b) The authorization for a UE of receiving the content of a specific multicast MBS session.

A Multicast MBS session may be "open to any UEs".

NOTE 1: UE authorization for a specific Multicast MBS session can be implicitly performed when UE is configured for a specific Multicast MBS session, e.g. via Service Announcement for public safety use case.

NOTE 2: The authorization mentioned by a) is required even if an authorization according to b) is available. If the UE is not authorized to use the Multicast service by the PLMN, the UE is not authorized to join any multicast MBS Session even if the Multicast MBS session is "open to any UEs".

For a Multicast MBS session, it is required that the 5GC authorizes the UE based on the MBS subscription data and whether the Multicast MBS session is "open to any UEs", which are preconfigured, or provided by the AF (see clause 7.2.9).

The procedure for UE authorization is a part of UE join procedure and is described in clause 7.2.1.3.

6.2 Local MBS service and Location dependent MBS service

6.2.1 General

A Local MBS service is an MBS service provided in one MBS service area. A location dependent MBS service is an MBS service provided in several MBS service area(s). An MBS service area is identified by a cell list or a tracking area list. The MBS service area could be geographical area information or civic address information, and NEF/MBSF translates the location information to Cell ID list or TAI list as MBS service area, see clause 7.1.1.2.

The MBS service area may be updated by the AF for both multicast MBS sessions and broadcast MBS sessions as specified in clause 7.1.1.6.

For more details, refer to clause 7.2.4 for multicast MBS session and refer to clause 7.3.4 for broadcast MBS session.

6.2.2 Local MBS service

For a local MBS service, only UEs within the MBS service area may receive content data, while UEs outside the MBS service area are not allowed to receive location specific content. For multicast MBS service, UEs outside the MBS service area are not allowed to join the MBS service, and the network shall not deliver location specific content anymore to the UEs moved out of the MBS service area. Depending on policy, for the multicast MBS service the network may remove UEs outside the MBS service area of the MBS session from the MBS Session Context after a grace period. The SMF may subscribe at the AMF to notifications about "UE moving in or out of a subscribed "Area Of Interest"" event.

For multicast communication, local MBS may be supported via 5GC Individual MBS traffic delivery towards RAN nodes not supporting MBS. If the SMF obtains a notification that the UE is no longer in the MBS service area, the SMF terminates the 5GC Individual MBS traffic delivery towards the UE.

The UE shall be able to obtain service area information of the local multicast service via MBS service announcement or via NAS signalling (UE Session Join Accept/Reject including Cell ID list or TAI list). If the UE Session Join procedure fails due to the UE being outside the MBS service area, the UE does not attempt to join the Multicast MBS session again until the UE moves inside the MBS service area. When the UE Session Join succeeds and if the Multicast MBS session is inactive, the UE does not perform monitoring the session activation notification and any other information related to the Multicast MBS session identified by an MBS Session ID over the radio if outside the MBS service area.

NOTE: Broadcast communication service is the service provided simultaneously to all UEs in a geographical area, therefore for broadcast it is naturally a local MBS service.

6.2.3 Location dependent MBS service

A location dependent MBS is identified by MBS Session ID, and provided in several MBS service areas. The location dependent MBS service enables distribution of different content data to different MBS service areas. The same MBS Session ID is used but a different Area Session ID is used for each MBS service area. The Area Session ID is used, in combination with MBS Session ID, to uniquely identify the service area specific part of the content data of the MBS service within 5GS. The network supports the location dependent content distribution for the location dependent MBS services, while UEs are only aware of the MBS Session ID (i.e. UEs are not required to be aware of the Area Session IDs). When UE moves to a new MBS service area, content data from the new MBS service area shall be delivered to the UE, and the network ceases to deliver the content data from the old MBS service areas to the UE. For multicast MBS service, UEs outside all MBS service areas of the location dependent MBS session are not allowed to join the MBS service. When UE moves out of an MBS service area and there is no other MBS service area for the MBS session, the network ceases to deliver the content data to the UE. Depending on policy, for the multicast MBS service the network may remove UEs outside all MBS service areas of the location dependent MBS Session from the multicast MBS Session Context after a grace period The SMF may subscribe at the AMF to notifications about UE moving in or out of all MBS service areas of the location dependent MBS session.

For multicast communication towards an NG-RAN supporting MBS, the NG-RAN node handles mobility of UEs within the MBS session between MBS service areas served by the same NG-RAN without interaction with SMF.

For multicast communication, location dependent MBS services may be supported via 5GC Individual MBS traffic delivery towards RAN nodes not supporting MBS. If the SMF determines that the UE is in another MBS service area of the Multicast MBS session, the SMF configures the UPF to send multicast data relating to the new MBS service area towards the UE.

Information about different MBS service areas for a location dependent MBS service may be provided by one or several AFs or may be configured. Different ingress points for location dependent points for the MBS session are supported for different MBS service area dependent content of the MBS session; different MB-SMFs and/or MB-UPF may be assigned for different MBS service areas in an MBS session. When the different MB-SMFs are assigned for different MBS service areas in an MBS session, the same TMGI is allocated for this MBS session.

The Area Session ID is allocated by MB-SMF in MBS Session creation procedure. MB-SMF allocates Area Session ID for each MBS services area which is unique within the MBS session. MB-SMF needs to further ensure there is no MBS service area overlapping with other MBS service areas that share the same MBS Session ID.

NOTE 1: In this release, deployments topologies with specific SMF Service Areas are not supported, as a result, location dependent service using multicast communication is not supported when a UE moves outside its SMF service area.

NOTE 2: For location dependent service provided in different MBS service areas within the same SMF service area, it is assumed that one MB-SMF is used for an MBS Session.

NOTE 3: An example of Location dependent MBS is a nationwide weather forecast service with local weather reports.

NOTE 4: Area Session ID is equivalent to Flow ID as specified in TS 23.246 [8].

6.2.4 Void

6.2.5 Void

6.3 Mobility support of MBS service

6.3.1 Mobility of Multicast MBS session

The mobility of multicast MBS service is supported when:

– The UE moves from a NG-RAN node that supports MBS to a target NG-RAN node that supports MBS; or

– The UE moves from a NG-RAN node that supports MBS to a target NG-RAN node that does not support MBS and vice versa.

During the mobility from a NG-RAN node that supports MBS to a target NG-RAN node that supports MBS, or between a NG-RAN node that supports MBS and a target NG-RAN node that does not support MBS, minimization of data loss should be supported, see clause 7.2.3.5 for details.

To support Handover from NG-RAN node that supports MBS to a target NG-RAN node that supports MBS:

– If the shared delivery for the MBS session has not been established towards target NG-RAN, the target NG-RAN establishes the shared delivery for the MBS Session with MB-SMF and MB-UPF.

To support Handover from NG-RAN node that supports MBS to a target NG-RAN node that does not support MBS:

– mapping information about unicast QoS flows for multicast data transmission and the information of associated multicast QoS flows are provided to the NG-RAN node. This is already performed during the PDU session modification procedure for the PDU session associated with the MBS session when the UE joins the MBS Session;

– during the handover procedure, the delivery method is switched from 5GC Shared MBS traffic delivery method to 5GC Individual MBS traffic delivery method, i.e. the N3 tunnel of the PDU Session for 5GC Individual MBS traffic delivery needs to be established towards the target NG-RAN node. The SMF realizes that the target NG-RAN node does not support MBS.

– the SMF and the MB-SMF shall activate the GTP tunnel between the UPF and the MB-UPF for 5GC Individual MBS traffic delivery method, if needed.

To support Handover from a NG-RAN node that does not support MBS to a target NG-RAN node that supports MBS:

– The PDU sessions, including the one associated with the MBS session and used for 5GC Individual MBS traffic delivery, are handed over to the target NG-RAN node.

– SMF triggers mode switch, i.e. from 5GC Individual MBS traffic delivery method to 5GC shared MBS traffic delivery method.

– When the MBS Session Context is given to the target NG-RAN node by the SMF, if the shared delivery for the MBS session has not been established towards target NG-RAN, the target NG-RAN establishes the shared delivery for the MBS Session with MB-SMF and MB-UPF.

– The 5GC terminates the 5GC Individual MBS traffic delivery and changes to the 5GC shared MBS traffic delivery.

6.3.2 Mobility of Broadcast MBS session

The UE receives the same Broadcast MBS service in the target NG-RAN if the same MBS session is established with 5GC Shared MBS traffic delivery method in the target NG-RAN node.

NOTE: When the UE moves into NG-RAN node not supporting MBS within the Broadcast MBS service area, how the UE get the same content via application level is out scope of this specification.

6.4 Subscription to multicast services

6.4.1 General

The UDM stores the subscription information to give the user permission to use multicast services, which include the MBS subscription data for a UE in UE subscription data.

At any time, the operator may change the subscription for multicast services in the UDM.

The MBS subscription data in UE subscription data contains the following information:

– Whether the UE is authorized to use the multicast MBS service.

– MBS Session ID(s) of the Multicast MBS session(s) that the UE is allowed to join.

NOTE: The MBS Session ID applies only for MBS session which is not "open to any UEs".

The MBS subscription data is provided by the UDM to the SMF during or after the establishment procedure of PDU Session associated with Multicast MBS session(s) using Nudm_SDM service for subscription data type "MBS subscription data" as defined in clause 7.2.1.2.

During multicast session join procedure, the SMF retrieves MBS Session information from the MB-SMF, and authorizes the MBS Session join request for the UE based on MBS subscription data of the UE received from UDM and the Any UE indication (i.e. whether the Multicast MBS session is "open to any UEs") received from MB-SMF as described in clause 7.2.1.3.

The UDR stores the MBS data, which may be updated by the UDM or the AF/NEF as specified in clause 4.15.6.2 of TS 23.502 [6], i.e. AF may provision Multicast MBS Session Authorization information for the MBS as described in clause 7.2.9.

6.4.2 MBS subscription data in UDM

The information stored in the UDM as defined in clause 5.2.3.3.1 of TS 23.502 [6] is extended as follows:

– MBS subscription data for a UE as part of UE subscription data, as defined in Table 6.4.2-1, with keys defined in Table 6.4.2-2.

Table 6.4.2-1: MBS subscription data type

Subscription data type	Field	Description
MBS subscription data	MBS allowed	Indicates whether the UE is authorized to use the multicast MBS service.
	MBS Session ID(s)	Identifies the MBS Session(s) that the UE are allowed to join.

Table 6.4.2-2: MBS subscription data type keys

Subscription Data Types	Data Key	Data Sub Key
MBS Subscription data	SUPI	–

6.4.3 MBS information in UDR

The MBS information may be stored in the UDR by the UDM as part of the subscription data, as defined in clause 5.2.12.2.1 of TS 23.502 [6].

1. MBS data as defined in Tables 6.4.2-1, with keys defined in Table 6.4.3-1.

Table 6.4.3-1: MBS data type keys

Data Set	Data Subset	Data Key	Data Sub Key
Subscription Data	MBS authorization data	SUPI	–

6.5 Identifiers

6.5.1 MBS Session ID

The MBS session ID is used to identify a Multicast/Broadcast MBS Session by the 5G system on external interface towards AF and between AF and UE, and towards the UE.

MBS Session ID may have the following types:

– TMGI (for broadcast and multicast MBS sessions);

– source specific IP multicast address (for multicast MBS sessions).

If a multicast MBS session is provided within an SNPN, the multicast MBS session can still be identified by a (globally unique) source specific IP multicast address or TMGI. In 5GS internal signalling the PLMN ID, included in TMGI, is complemented with the NID to identify an SNPN.

Source specific IP multicast address or TMGI may be used as MBS Session ID in NAS messages exchange between a UE and a CN when the UE requests to join/leave a Multicast MBS session. For multicast MBS sessions that the UE joined with a source specific IP multicast address, a TMGI is also allocated by 5GC and is sent to the UE and used in other signalling messages between RAN, CN and UE. Details see clause 7.2.1.3.

The UE shall be able to obtain at least one MBS Session ID via MBS service announcement.

For multicast MBS sessions, a source specific IP multicast address can be assigned by external AFs.

6.5.2 Temporary Mobile Group Identity

TMGI (Temporary Mobile Group Identity) is defined in TS 23.003 [12] and is used to be able to identify a broadcast MBS Session or a multicast MBS session.

In SNPN (Stand-alone Non-Public Network), TMGI is used together with NID (Network Identifier) defined in TS 23.003 [12] to identify an MBS Session.

6.5.3 Source Specific IP Multicast Address

The source specific IP multicast address is used to identify an Multicast MBS session and consists of two IP addresses, one is an IP unicast address used as source address in IP packets for identifying the source of the multicast service (e.g. AF/AS), the other is an IP multicast address used as destination address in related IP packets for identifying a multicast communication service associated with the source.

6.5.4 MBS Frequency Selection Area ID

The MBS Frequency Selection Area (FSA) ID is used for broadcast MBS session to guide the frequency selection of the UE.

MBS FSA ID identifies a preconfigured area within, and in proximity to, which the cell(s) announces the MBS FSA ID and the associating frequency (details see TS 38.300 [9]). MBS FSA ID and their mapping to frequencies are provided to RAN nodes via OAM.

Based on this configuration, RAN nodes announce in SIBs over the radio interface information about the MBS FSA IDs and frequencies.

When a broadcast MBS session is created, the AF may provide MBS FSA ID(s) based on the business agreement. If the AF does not provide MBS FSA ID(s), the MB-SMF determines MBS FSA ID(s) based on configured mapping from MBS service area and/or broadcast MBS session information (e.g. application ID) to MBS FSA ID(s) and sends the determined MBS FSA ID(s), to the AF (optionally via NEF).

NOTE: The same MBS FSA ID(s) can be assigned to multiple Broadcast MBS sessions.

The MBS FSA ID(s) of a broadcast MBS session are communicated in the service announcement towards the UE. The UE compares those MBS FSA IDs(s) with the MBS FSA ID(s) in SIBs for frequency selection.

During MBS Session Start for Broadcast in clause 7.3.1 and MBS Session Update for Broadcast in clause 7.3.3, the MB-SMF may include the MBS FSA ID(s) for the MBS session and send them to the NG-RAN nodes via the AMF. The NG-RAN nodes may then use those MBS FSA ID(s) to determine cells/frequencies within the MBS service area to broadcast MBS session data. For details, see TS 38.300 [9] and TS 38.413 [15].

6.6 QoS Handling for Multicast and Broadcast services

For MBS services, the network shall support QoS control per MBS session.

The 5G QoS model and parameters as defined in TS 23.501 [5] clause 5.7 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;

NOTE 1: For multicast communication service, the UE-AMBR applies for associated PDU Session.

– Session-AMBR if provided is enforced at MB-UPF but not communicated to NG-RAN.

NOTE 2: Whether Session-AMBR is required in addition to the MBS service data flow bit rate is determined by operator policy and/or agreement with the service provider.

– For broadcast MBS session, the QoS rule and QoS Flow level QoS parameters are not provided to UE.

NOTE 3: For broadcast MBS session, the associated QoS Flow(s) are not applicable.

– 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.

NOTE 4: The UE does not need to know a QoS Flow within the PDU session is mapped from MBS QoS Flow.

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.

NOTE 5: When there is a need to apply 5GC Individual MBS traffic delivery, the Session-AMBR of the associated PDU Session can be configured with a sufficiently high value to cater for MBS Session-AMBR.

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.

NOTE 6: What information is included in the request from AF to MBSF requires collaboration with SA WG4.

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.

6.7 User plane management

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.

Figure 6.7‑1: Schematic showing user plane data transmission

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 [23].

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.

NOTE: This PDR is also containing the MBS Session ID to enable a single detection of the incoming MBS data for multiple PDU sessions at the UPF.

– 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 [17] for the details of user plane handling.

6.8 Interworking with MBMS over E-UTRAN for public safety services

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 [8] 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.

6.9 MBS Session Context

6.9.1 MBS Session Context

The MBS Session Context contains all information describing a particular MBS session in the 5GS and is created in each node involved in the delivery of the MBS data.

The content of the Multicast MBS Session Context is described in Table 6.9.1-1.

Table 6.9.1-1: Multicast MBS Session Context

Parameter	Description	NG-RAN	AMF	SMF	MB-SMF
State	State of MBS session (‘Active’ or ‘Inactive’ or ‘Configured’)	X (note 2)		X (note 2)	X
SSM (source specific IP multicast address)	IP multicast address identifying the MBS session.			X (note 1)	X (note 1)
TMGI	Temporary Mobile Group Identity allocated to the MBS Session.	X	X	x	X
Area Session Identifier	Used for MBS session with location dependent content. When present, the Area Session Identifier together with the TMGI uniquely identify the MBS Session in a specific MBS service area.	X (note 1)	X	X (note 1)	X (note 1)
MB-SMF	The MB-SMF that handles the MBS session.		X	X
QoS information	QoS information of the MBS session.	X		X	X
MBS Service Area	Area over which the MBS session data is distributed (i.e. Cell ID list or TAI list).	X (note 1)		X (note 1)	X (note 1)
NG-RAN Node ID(s)	NG-RAN nodes which are involved in the Multicast MBS session		X		X (note 1, note 4)
AMF	The AMF(s) which are selected for the MBS session	X			X
IP multicast and source address for data distribution	IP addresses identifying the SSM user plane transport for shared delivery between MB-UPF and NG-RAN and for individual delivery between MB-UPF and UPF when the IP multicast transport is used.	X (note 1)		X (note 1)	X (note 1)
SMF	The SMF(s) that manages the associated PDU session.				X
UE ID	ID identifying the UE that successfully join the Multicast MBS session. For NG-RAN it is NGAP UE ID and for SMF it is SUPI.	X (note 3)		X (note 3)
IP address for distribution	The IP addresses and TEID of NG-RAN used for the user plane between NG-RAN and MB-UPF and between MB-UPF and UPF when Point to Point tunnel is used.	X (note 1)		X (note 1)	X (note 1, note 4)
TEID for data distribution	The tunnel ID used for receiving the multicast data for shared delivery by NG-RAN and for individual delivery by UPF	X		X	X (note 1, note 4)
PCF	The MB-PCF that provides policy control for the MBS session.				X (note 1)
NOTE 1: It is an optional parameter. NOTE 2: The value ‘Configured’ is not applicable for NG-RAN and SMF. NOTE 3: the UE ID is available within the UE Context which contains the MBS information. NOTE 4: The Parameter needs to be stored in deployments with shared NG-U termination(s) if unicast transport is used.

In Broadcast MBMS mode, an MBS Session Context is created in the NG-RAN, AMF, MB-SMF and MBSF as a result of the MBS Session Start procedure.

The content of the Broadcast MBS Session Context is described in Table 6.9.1-2.

Table 6.9.1-2: Broadcast MBS Session context

Parameter	Description	NG-RAN	AMF	MB-SMF
TMGI	Temporary Mobile Group Identity allocated to the MBS Session.	X	X	X
Area Session Identifier	Used for MBS session with location dependent content. When present, the Area Session Identifier together with the TMGI uniquely identify the MBS Session in a specific MBS service area.	X (note 1)	X (note 1)	X (note 1)
AMF	The AMF(s) which are selected for the MBS session	X		X
MB-SMF	The MB-SMF that handles the MBS session.		X
QoS information	QoS information for the MBS Session, including the QoS parameters of QoS flows.	X		X
MBS Service Area	Area over which the MBS session data is distributed (i.e. Cell ID list or TAI list).	X	X	X
NG-RAN Node ID(s)	NG-RAN nodes which are selected for the Broadcast MBS session		X
IP multicast address for data distribution	IP addresses identifying the user plane transport used for shared delivery between MB-UPF and NG-RAN when the IP multicast transport is used.	X (note 1)		X (note 1)
NG-RAN IP Address for data distribution	The IP address of NG-RAN used for the user plane between NG-RAN and MB-UPF when Point to Point tunnel is used.	X (note 1)		X (note 1)
TEID for data distribution	The tunnel ID used for receiving the broadcast data for shared delivery by NG-RAN	X		X
PCF	The PCF that provides policy control for the MBS session.			X (note 1)
MBS FSA ID	MBS Frequency Selection Area (FSA) ID is used for broadcast MBS sessions to guide the frequency selection of the UE.	X		X
NOTE 1: It is an optional parameter.

6.10 Policy control for Multicast and Broadcast services

6.10.1 General

The policy and charging control framework as defined in TS 23.503 [7] applies to Multicast and Broadcast services in the following aspects:

– MBS Session binding: MBS Session binding is the association of an AF Session information to one and only one MBS Session. The PCF shall perform the session binding based on the MBS Session ID, i.e. TMGI or source specific IP multicast address.

– QoS Flow binding: For an MBS Session, QoS Flow binding is the association of a PCC rule to a QoS Flow within an MBS Session. The MB-SMF performs QoS Flow binding for an MBS Session in the same way as the SMF for a PDU Session.

– MBS policy information consists of:

– PCC rules for MBS Session are used to provide policy for QoS flows: The following PCC rule parameters defined in Table 6.3.1 of TS 23.503 [7] are applicable for MBS:

– Rule identifier.

– Service data flow detection: Precedence, Service data flow template (only for IP PDU traffic).

– Policy Control: 5G QoS Identifier (5QI), DL-maximum bitrate, DL-guaranteed bitrate, ARP, Priority Level, Averaging Window, Maximum Data Burst Volume.

– Policy information can also be applicable for an entire MBS session. The following parameters defined for a PDU session in Table 6.4.1 of TS 23.503 [7] are applicable for an entire MBS session:

– Authorized Session-AMBR.

– Explicitly signalled QoS Characteristics.

– Policy Control Request Triggers for MBS Session are used to define the conditions when the MB-SMF shall interact again with the PCF to request an update of the policy information for the MBS session by providing information on the condition(s) that have been met. The following Policy Control Request Triggers are defined for MBS:

– MBS Session Update.

6.10.2 MBS Session policy control data in UDR

The policy control profile information may optionally be provided by the UDR at MBS Session establishment, using Nudr service for Data Set "Policy Data" and Data Subset "MBS Session policy control data", with the source specific multicast address used as MBS session ID or with AF Application identifier as data key is described in Table 6.10.2-1.

Table 6.10.2-1: MBS Session policy control information

Information element name	Description	Category
5QI(s)	Allowed 5QI(s) for a PCC rule of an MBS session (NOTE 1)	Optional
ARP	Highest ARP for any PCC rule of an MBS session (NOTE 1)	Optional
Session-AMBR	Maximum Session-AMBR for all nonGBR QoS Flows of an MBS session (NOTE 1)	Optional
GBR	Maximum aggregated bitrate that can be provided across all GBR QoS Flows for an MBS session (NOTE 1)	Optional
NOTE 1: This information element may be used to decide whether to authorize received MBS Service Information.

6.11 Service Announcement

Service Announcement provides the UE with descriptions specifying the multicast or broadcast services to be delivered as part of MBS 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.

NOTE 1: A Source Specific IP Multicast Address as MBS Session ID indicates a Multicast MBS session.

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.

If the MBS Session is 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.

NOTE 2: For multicast, AF or MBSF provides Service Announcement only after the MBS information is available to 5GC or the start time need be included, to avoid potential rejection sent by SMF of the MBS session join request.

NOTE 3: The MBS Service related information, e.g. default PLMN ID, DNN and S-NSSAI can be pre-configured in the UE.

NOTE 4: If DNN and S-NSSAI information is not provided in the service announcement or pre-configured, how UE determines the PDU session to join the MBS Session is implementation specific.

If the MBS Session is broadcast, the Service Announcement may include the MBS FSA ID(s) and optional frequency information associated with the broadcast MBS session.

The Service Announcement may be provided to a UE by AF or MBSF, or may be retrieved by the UE from those entities.

NOTE 5: How the UE can get the Service Announcement from other entities is not specified.

NOTE 6: Service announcement can comply with TS 26.502 [18] and TS 23.289 [21] or follow an application specific format.

6.12 Paging strategy handling

Compared to the paging strategy handling specified in clause 5.4.3 of TS 23.501 [5], 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.

6.13 MBS Security function

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 [20].

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 3GPP scope.

The following additions for MBS multicast control plane procedures in the present specification apply if the MBS security function for multicast as defined in TS 33.501 [20] is used:

– The multicast session security context, as defined in TS 33.501 [20], 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.

NOTE 1: If no MSK but only the MTK is to be updated, the session update described in the previous bullet is not triggered and the MTK is updated as defined in TS 33.501 [20].

NOTE 2: Interaction between MBSF and MBSTF will be defined in TS 33.501 [20] and TS 26.502 [18].

NOTE 3: Clause 9.1 defines the services for supporting security function for control plane procedure. The additions to the user plane procedure to support the security function for multicast and broadcast can be used as defined in TS 33.501 [20].

6.14 MBS Service Information

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.

In addition, MBS Service Information may be optionally sent from AF/NEF/MBSF to the PCF based on network configuration.

NOTE: Depending on deployment scenarios specified in Annex A, AF, NEF or MBSF interacts with MB-SMF, and optionally that AF, NEF or MBSF interacts with PCF.

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.

6.15 Group Message Delivery

The Group Message Delivery feature allows AFs to deliver a payload to a group of UEs located in a particular geographical area when MBS broadcast is used, which enables efficient group message delivery. The AF can request group message delivery as specified in clause 7.5.1. The AF may recall or replace a previously submitted group message as described in clause 7.5.2.

Group Message Delivery utilizes the Object Delivery Method in MBSTF specified in TS 26.502 [18]. The Object Delivery Method in MBSTF is equivalent to the File Delivery Method in eMBMS. The Object Delivery Method can benefit from Application Layer Forward Error Correction (AL-FEC) to achieve the reliable delivery, which is essential for group message delivery.

The NEF is responsible to handle Group Message Delivery request from the AF. It transforms the group message into a file and determine the meta data information of the file. In control plane, it performs Application Service Provisioning including MBS User Service creation and MBS User Data Ingest Session creation, which triggers the MBS session creation and MBS session start for broadcast towards 5GC and NR. In user plane, it is responsible for ingesting the file to the MBSTF, so that MBSTF can deliver the file to UE via 5GC shared traffic delivery and NR broadcast.

NOTE: The AF can invoke the Nmbsmf service operations offered by the MB-SMF (optionally via the NEF) for Transport Only Mode, as supported in Rel-17.