5.34 Support of 5G Multicast and Broadcast Service

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

5.34.1 General

This clause specifies N4mb and N4 specific requirements to support 5G Multicast and Broadcast Service.

Stage 2 requirements for the support of 5G Multicast and Broadcast Service is specified in clause 6.7 of 3GPP TS 23.247 [72] and clause 5.8.2.11 of 3GPP TS 23.501 [28].

5.34.2 N4mb requirements

5.34.2.1 General

This clause specifies N4mb specific requirements to support 5G Multicast and Broadcast Service.For a location dependent MBS service (see clause 6.2.3 of 3GPP TS 23.247 [72]), the MB-SMF shall establish one PFCP session per MBS session and MBS Session Area, following the requirements specified in clause 5.34.2.2.

NOTE: A 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.

5.34.2.2 Instructing the MB-UPF to forward MBS data using multicast and/or unicast transport

When the MB-SMF receives an MBS Session Create Request from a NEF/MBSF to configure an MBS session, the MB-SMF shall select an MB-UPF and request that MB-UPF to allocate relevant user plane resource for the MBS session, or for the MBS session and MBS Service Area for a location dependent MBS service; to do so, the MB-SMF shall send a PFCP Session Establishment Request message to the MB-UPF to setup a PFCP session for the MBS Session, or for the MBS session and MBS Service Area for a location dependent MBS service, including the following information in the PFCP Session Establishment Request message:

– the MBS Session Identifier identifying the MBS session (i.e. TMGI or SSM address);

– the Area Session ID, for a location dependent MBS service;

– a JMBSSM (Join MBS Session SSM) indication in the MBSN4mbReq-Flags IE to request the MB-UPF to join the multicast tree towards the Source Specific Multicast (SSM) address information provided by AF/AS or MBSTF for the MBS Session where the SSM is provided in the IP Multicast Addressing Info IE in the corresponding downlink PDR, if multicast transport applies over N6mb (i.e. if no N6mb ingress tunnel is requested to be allocated);

– a PLLSSM (Provide Low Layer Source Specific Multicast address) indication in the MBSN4mbReq-Flags IE to request the MB-UPF to provide a lower layer SSM address (i.e. multicast destination address and related source IP address) and a GTP-U Common Tunnel EndPoint Identifier (C-TEID), if multicast transport applies over N3mb or N19mb. During a restoration procedure for an MB-UPF restart however the MB-SMF shall not set the PLLSSM flag (see clause 8.2.2 in 3GPP TS 23.527 [40]);

– for each MBS QoS flow:

– a Create PDR IE to provision a downlink PDR with PDI or a Create Tunnel Endpoint IE containing either:

– a "Local Ingress Tunnel" IE with the CHOOSE bit set to "1" to request the MB-UPF to allocate an ingress tunnel for Nmb9, or for N6mb if unicast transport is used over N6mb (MB-UPF shall assign a single ingress tunnel address, regardless of the number of MBS QoS flows); or

– an IP Multicast Addressing Info IE to request the MB-UPF to retrieve the MBS session data from the IP Multicast Address, when using multicast transport over N6mb.

– a Create QER IE to provision a QER (associated with the PDR including the above PDI or Traffic EndPoint ID) instructing the MB-UPF to insert the QFI of the MBS QoS flow in user plane packets and possibly requesting the MB-UPF to apply specific QoS treatments; the IQFISN (Insert DL MBS QFI Sequence Number) flag in the Create QER IE shall be set to "1" to request the MB-UPF to insert the DL MBS QFI Sequence Number in the PDU session container in user plane packets;

– a Create FAR IE to provision a FAR (associated with the PDR including the above PDI or Traffic EndPoint ID) with the Apply Action set to "FSSM" with an MBS Multicast Parameters IE, when multicast transport is used over N3mb or N19mb, to forward the packets to the low layer SSM address when it is allocated; otherwise, the apply action shall be set to "DROP".

The MBS Session Identifier, Area Session ID (for a location dependent MBS service) and the MBSN4mbReq-Flags are included in the group IE "MBS Session N4mb Control Information" at the PFCP message level.

The MB-UPF shall return the allocated ingress tunnel information in the Created PDR IE or Created Traffic Endpoint IE and provide the Low Layer SSM address if requested.

For an MBS session using unicast transport over N3mb or N19mb, when one or more NG-RAN node(s) and/or PSA UPF(s) provides a downlink GTP-U F-TEID (i.e. IP address and tunnel endpoint identifier) to receive the MBS session data, the MB-SMF shall send a PFCP Session Modification Request or a PFCP Session Establishment Request message to change the FAR with the Apply Action set to "MBSU" together with one or more Add MBS Unicast Parameters to instruct the MB-UPF to forward and replicate MBS Session data towards the one or more GTP-U DL tunnels terminating at the NG-RAN(s) and/or PSA UPF(s).

NOTE: FAR with the Apply Action set to "MBSU" together with one or more Add MBS Unicast Parameters is sent with a PFCP Session Establishment Request message during the restoration procedures, as specified in 3GPP TS 23.527 [40], see e.g. clauses 8.2.2 and 8.2.3.

For an MBS session using multicast transport over N3mb or N19mb, if the "FSSM" flag is set in the Apply Action, the MB-UPF shall forward the MBS session data using the Low Layer Source Specific Multicast address (i.e. destination IP multicast address and related source IP address) and C-TEID it allocated to the MBS session.

Both the "FSSM" and "MBSU" flags shall be set in the Apply Action IE if the MB-UPF is requested to forward MBS data using both multicast and unicast transport over N3mb or N19mb.

5.34.2.3 Detecting and reporting user plane (in)activity of an MBS session

As specified in clauses 7.2.5.2 and 7.2.5.3 of 3GPP TS 23.247 [72], the MB-SMF may instruct the MB-UPF to detect and report when user plane inactivity or activity is detected for an MBS session, in order to deactive or activate the MBS session (see also clause 5.34.2.4).

User plane inactivity detection and reporting for an MBS session shall be supported as specified in clause 5.11.

User plane activity detection and reporting for an MBS session shall be supported as specified in clauses 5.2.3.1, i.e. by setting the NOCP flag in the Apply Action IE of the FAR and by the MB-UPF sending a PFCP Session Report Request including a Downlink Data Report IE identifying the PDR(s) for which downlink packets have been received.

5.34.2.4 Activation and Deactivation of a Multicast MBS session

Activation and Deactivation of a Multicast MBS session is specified in clauses 7.2.5.2 and 7.2.5.3 of 3GPP TS 23.247 [72].At deactivation of a Multicast MBS Session, e.g. triggered by receiving an user plane inactivity report from the MB-UPF, or by receiving an MBS session deactivation request from the AF, the MB-SMF shall send a PFCP Session Modification Request message to request the MB-UPF:

– to stop forwarding the MBS session data and:

– to report the receipt of subsequent DL MBS session data, by setting the Apply Action IE from "FSSM and/or MBSU" to "BUFF and NOCP" in the FAR of the PFCP session corresponding to the MBS session, if the activation of the MBS session is to be triggered upon receiving DL data report from the MB-UPF; or

– to change the Apply Action IE from "FSSM and/or MBSU" to "DROP" or "BUFF" in the FAR of the PFCP session corresponding to the MBS session, if the deactivation is requested by the AF;

– optionally, to delete all unicast DL N3mb F-TEIDs and all unicast DL N19mb F-TEIDs, i.e. to delete all the information earlier received in all the Add MBS Unicast Parameters IEs, by setting the "DETEID" flag to "1" in the PFCPSMReq-Flags, if the MB-SMF stores N3mb F-TEIDs and N19mb F-TEIDs and does not want to keep these F-TEIDs in the MB-UPF when the MBS session is deactivated. Otherwise, MB-UPF will keep all unicast DL N3mb F-TEIDs and all unicast DL N19mb F-TEIDs when the MBS session is deactivated.

At the (re)activation of a Multicast MBS Session, e.g. triggered by receiving the DL data report from the MB-UPF, or by receiving an MBS session activation request from the AF, the MB-SMF shall send a PFCP Session Modification Request message:

– requesting the MB-UPF to forward the MBS session data towards NG-RANs and/or UPFs, by setting the Apply Action IE from "BUFF" (with or without NOCP") or "DROP" to "FSSM and/or MBSU" in the FAR of the PFCP session;

– provisioning all unicast NG-RAN DL N3mb F-TEIDs and UPF N19mb F-TEID (which are stored and were possibly updated in the MB-SMF) in the Add MBS Unicast Parameters IEs to request the MB-UPF to forward one copy of the MBS session data to these DL tunnels when the unicast transport is used, if all the DL N3mb and N19mb F-TEIDs were deleted during the MBS session deactivation procedure; and

– optionally including a User Plane Inactivity Timer IE to provision or update the user plane inactivity timer to request the MB-UPF to report user plane inactivity, if the deactivation of the MBS session is to be triggered upon user plane inactivity report from the MB-UPF.

5.34.3 N4 requirements

5.34.3.1 General

This clause specifies the N4 requirements for the support of multicast MBS services using 5GC Individual MBS traffic delivery. The MBS data may be delivered from the MB-UPF to the UPF using multicast or unicast transport. It is optional for both the SMF and the UPF to support the multicast MBS service. The following requirements shall apply if the SMF and UPF support the MBSN4 feature (see clause 8.2.25).

NOTE 1: There is no impact on N4 to support broadcast MBS services in the 5GS.

NOTE 2: For an MBS session (or an MBS session towards an MBS service area for location dependent MBS), there is only one MB-SMF (set) and one MB-UPF.

For a given multicast MBS session, or for a given multicast MBS session and MBS Service Area for a location dependent MBS service, only a single copy of MBS Session data is delivered from the MB-UPF to the UPF. The UPF shall allocate only one N19mb downlink tunnel to receive the MBS session data for the MBS session, or for the MBS session and MBS Service Area for a location dependent MBS service, if unicast transport applies over N19mb or the UPF shall join the multicast group to receive MBS session data if multicast transport applies over N19mb.

5.34.3.2 Instructing the UPF to forward (or stop forwarding) multicast MBS data to associated PDU sessions

When a PDU session needs to be associated with an MBS session (e.g. when a UE requests to join a multicast MBS session, 5GC Individual MBS traffic delivery is used and the request is accepted by the SMF), the SMF shall associate the PDU session with the multicast MBS session by sending a PFCP Session Establishment or Modification Request message to the UPF, for the PFCP session corresponding to the PDU session, with the following information:

– the MBS Session N4 Control Information IE including the MBS Session Identifier, the Area Session ID, for a location dependent MBS service and, if IP multicast transport applies over N19mb (i.e. a multicast transport address has been received from the MB-SMF):

– the Multicast Transport Information IE for the given MBS session containing the Low Layer Source Specific Multicast address, i.e. the Multicast address and the source IP address and the GTP-U Common TEID which have been allocated by the MB-UPF for the MBS session, when the SMF considers it is the first PDU session to be associated with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) in this UPF; the SMF may provide this information even if there are already other PDU sessions associated with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) in this UPF;

– one or more new DL PDR(s) including:

– the MBS Session Identifier, the Area Session ID (for a location dependent MBS service), or a Traffic Endpoint IE which is including the MBS Session Identifier, and the Area Session ID (for a location dependent MBS service); this information shall be used by the UPF to:

– determine whether the UPF already receives the MBS session data, or if instead it needs to allocate a new N19mb DL tunnel (when using IP unicast transport over N19mb) or send an IGMP JOIN request to join the multicast tree (when using IP multicast transport over N19mb) to receive the MBS session data; the UPF shall allocate the same N19mb DL Tunnel ID when the SMF requests the UPF to allocate a DL F-TEID for N19mb and multiple UE/PDU sessions are already associated with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) in the UPF (e.g. PDU sessions controlled by other SMFs, or when multiple PDU sessions served by the same SMF need to be associated concurrently with the MBS session).

– identify the list of PDU sessions (served by the UPF) towards which any DL packet received for this MBS session shall be distributed;

– if unicast transport is used over N19mb:

– a local F-TEID to be allocated at the UPF, with the CHOOSE flag set to "1" in the "Local F-TEID" IE in the PDI IE or Create Traffic Endpoint IE, if the SMF has no "N19mb DL F-TEID" information available for the MBS Session, e.g. for the first PDU Session in the SMF to be associated with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service); otherwise

– the Local F-TEID set to the "N19mb DL F-TEID" for the MBS Session (or for the MBS session and Area Session ID for a location dependent MBS service) which is known by the SMF.

– multiple DL PDRs may be provisioned and associated with different QERs to apply different QoS treaments for different multicast QoS flows within the MBS session. For each multicast QoS flow, the SMF may instruct the UPF to modify the QFI of downlink packets of the multicast QoS flow (received from the MB-UPF) to the QFI assigned by the SMF for the Associated (unicast) QoS flow, by associating a DL PDR including the QFI of the multicast QoS flow with a QER including the QFI IE set to the QFI of the Associated QoS flow.

– the new DL PDR(s) may be associated with an (existing) Forwarding Action Rule to forward the received MBS session data to the UE via existing downlink N3/N9 tunnel, or with a new Forwarding Action Rule with the Apply Action set to "Drop" if the SMF wishes to maintain the MBS data reception over N19mb but suspends the delivery of the data to the UE’s PDU session, e.g. when the UE is switching between 5GC Individual MBS traffic delivery and 5GC Shared MBS traffic delivery due to the UE moving back and forth between MBS non-supporting NG-RAN and MBS supporting NG-RAN.

The UPF shall respond with a PFCP Session Establishment or Modification Response message to the SMF, and the UPF shall include an MBS Session N4 Information IE if any of the following information needs to be reported:

– the allocated "N19mb DL Tunnel ID" if it was requested;

– an NN19DT (New N19mb Downlink Tunnel) indication in the MBSN4Resp-Flags IE indicating if the N19mb DL F-TEID has been newly allocated by the UPF or if a N19mb DL F-TEID had already been allocated by the UPF for the MBS session (or for the MBS session and Area Session ID for a location dependent MBS service), when the "N19mb DL Tunnel ID" is present; this information allows the SMF to determine if it needs to report this N19mb DL Tunnel ID to the MB-SMF;

– an indication "JMTI"(Joined N19mb Multicast Tree Indication) in the MBSN4Resp-Flags IE indicating if the UPF has joined the multicast tree from MB-UPF, if the Multicast Transport Information was included in the request message.

NOTE: The indications "JMTI" and "NN19DT" are defined to help the SMF to determine if it needs to communicate with the MB-SMF, e.g., to report the newly allocated N19mb DL TEID in order to let the MB-SMF inform the MB-UPF to send a copy of MBS Session data to the UPF. The indication "JMTI" indicates to the SMF that no N19mb DL TEID needs to be allocated.

If unicast transport is used over N19mb and if the NN19DT (New N19mb Downlink Tunnel) indication is not set in the MBSN4Resp-Flags IE within the PFCP Session Establishment or Modification Response (i.e. if the MBSN4Resp-Flags IE is present and the NN19DT indication is not set, or if the MBSN4Resp-Flags IE is absent), the SMF shall assume that the UPF had already allocated the N19mb DL TEID earlier than the PFCP Session Establishment or Modification Request.

When a PDU Session should be no longer be associated with the MBS session, or with the MBS session and Area Session ID for a location dependent MBS service, (e.g. the PDU session leaves the MBS session, or when switching to 5GC Shared MBS traffic delivery), or when the MBS session to which the PDU session is associated is being deactivated, the SMF shall send a PFCP Session Modification Request message to remove the DL PDR(s) that were created to receive the MBS session data, unless the SMF decides to keep the UPF receiving MBS Session data from N19mb, in which case the PDR shall be associated with a FAR set to drop packets. In the former case, when all the DL PDR(s) that were created to receive the MBS session data have been removed, the UPF shall consider that the PFCP session (PDU session) is no longer associated with the MBS session (i.e. the UPF shall delete, from its PFCP session context, the MBS Session N4 Control Information corresponding to the MBS session).

In the PFCP Session Modification Response message, the UPF shall include the indication "N19DTR" (N19mb Downlink Tunnel Removal) in the MBSN4Resp-Flags IE indicating the N19mb DL Tunnel is to be removed if the UPF was requested to remove the DL PDRs of the MBS session for the PFCP session and this was the last PFCP session associated with the N19mb DL Tunnel in the UPF. This tells the SMF that it shall request the MB-SMF to inform the MB-UPF to stop sending MBS Session data towards this N19mb DL Tunnel.

The UPF shall also set the indication "N19DTR" (N19mb Downlink Tunnel Removal) in the MBSN4Resp-Flags IE indicating the N19mb DL Tunnel is to be removed in the PFCP Session Deletion Response message when the SMF deleted the last PFCP session who was associated with the N19mb DL Tunnel in the UPF.

When the MBS session to which the PDU session is associated is being re-activated, the SMF shall send a PFCP Session Modification Request message to the UPF:

– including the MBS Session N4 Control Information IE and re-creating the DL PDR(s) of the MBS QoS flows, following the same requirements as described above for associating the PDU session with the MBS session, if the SMF removed the DL PDR(s) that were created to receive the MBS session data when the MBS session was deactivated; or

– associating the DL PDR(s) of the MBS QoS flows with the FAR provisioned with the N3 DL F-TEID to forward packets, if the SMF decided to keep the UPF receiving MBS Session data from N19mb by associating these DL PDR(s) with a FAR set to drop packets when the MBS session was deactivated.

During a restoration procedure for an MB-UPF failure without Restart (see clause 8.2.3 of 3GPP TS 23.527 []), if multicast transport is used over N19mb:

– the SMF shall instruct the UPF to use the new Low Layer Source Specific Multicast address, i.e. the Multicast address and the source IP address and the GTP-U Common TEID which have been allocated by the new MB-UPF for the MBS session, by sending a PFCP Session Modification Request message with the MBS Session N4 Control Information IE including the MBS Session Identifier, the Area Session ID (for a location dependent MBS service) and the Multicast Transport Information IE containing the new LL SSM address and GTP-U Common TEID;

– upon receipt of such a request, the UPF shall send an IGMP JOIN request to join the multicast tree to receive the MBS session data from the new MB-UPF and it shall leave delivery from the previous multicast address that was in use for the MBS session. The UPF shall set the indication "JMTI"(Joined N19mb Multicast Tree Indication) in the MBSN4Resp-Flags IE in the PFCP Session Modification Response to indicate that the UPF has joined the multicast tree from MB-UPF.

When receiving the MBS session data for a given MBS session, or for a given MBS session and Area Session ID for a location dependent MBS service, either from the N19mb DL Tunnel allocated for this MBS Session (where the packets shall be identified by N19mb DL TEID) when unicast transport is used, or from the low layer Multicast transport address (where the packets shall be identified by the low layer Multicast transport address) when multicast transport is used, the UPF shall replicate the MBS Session data to all PFCP sessions which are associated with the MBS Session, or with the MBS session and Area Session ID for a location dependent MBS service.

The UPF shall forward the MBS DL QFI Sequence Number in the PDU Session Container (see 3GPP TS 38.415 [34]) of MBS data packets received from the MB-UPF unmodified.

5.34.3.3 Instructing a combined UPF/MBS-UPF to forward multicast MBS data to associated PDU sessions

The procedures and requirements to instruct a combined UPF/MB-UPF to associate a PDU session with an MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) for which it serves as the MB-UPF shall be as specified in clauses 5.34.2.2 and 5.34.3.2, with the following additions:

– the combined UPF/MB-UPF may determine that the PDU session is being associated with an MBS session (or with an MBS session and Area Session ID for a location dependent MBS service) for which it serves as MB-UPF by determining whether a specific PFCP session has been established for the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service), as specified in clause 5.34.2.2;

– the SMF shall instruct the combined UPF/MB-UPF to associate the PDU session with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) as specified in clause 5.34.3.2, as if the UPF and MB-UPF were not combined; this means in particular that the DL PDR of the PFCP session of the PDU session to be associated with the MBS session (or with the MBS session and Area Session ID for a location dependent MBS service) shall not contain an N6mb / Nmb9 address or IP multicast addressing information;

NOTE 1: Only the PFCP session created for the MBS session (or for the MBS session and Area Session ID for a location dependent MBS service) as specified in clause 5.34.2.2 can contain a N6mb / Nmb9 address or IP multicast addressing information.

– it is an implementation choice for such combined UPF/MB-UPF to allocate a (possibly virtual / internal) N19mb DL Tunnel ID (i.e. IP address and TEID) or to indicate to the SMF that it has joined the low layer multicast group assigned by the MB-UPF for the MBS session (or for the MBS session and Area Session ID for a location dependent MBS service), and the combined UPF/MB-UPF shall respond to the SMF accordingly, as if it is the UPF and MB-UPF were not combined;

– if the combined UPF/MB-UPF returns a N19mb DL Tunnel ID with the NN19DT (New N19mb Downlink Tunnel) indication set to 1, the SMF shall request the MB-SMF to (or the combined SMF/MB-SMF shall) instruct the MB-UPF to forward and replicate MBS Session data towards the (possibly virtual / internal) N19mb DL Tunnel ID as specified in clause 5.34.2.2, as if the UPF and MB-UPF were not combined.

NOTE 2: The SMF, MB-SMF or a combined SMF/MB-SMF need not implement any additional logic when communicating with a combined UPF/MB-UPF.