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

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; 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, 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);

– 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 or Nmb9 (i.e. if no N6mb or Nmb9 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;

– 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 unicast transport over N6mb or Nmb9; 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 or Nmb9.

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

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.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, 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 MBS session data 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 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 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 in this UPF; the SMF may provide this information even if there are already other PDU sessions associated with the MBS session in this UPF; – one or more new DL PDR(s) including:

– the MBS Session Identifier, or a Traffic Endpoint IE which is including the MBS Session Identifier; 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 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; otherwise

– the Local F-TEID set to the "N19mb DL F-TEID" for the MBS Session which is known by the SMF.

– multiple DL PDRs may be provisioned and associated with different QERs to apply different QoS treaments for different service data flows within the MBS session.

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

When a PDU Session should be no longer be associated with the MBS session (e.g. the PDU session leaves the MBS session, or when switching to 5GC Shared MBS traffic delivery), 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".

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 receiving the MBS session data for a given MBS session, 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.

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 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 for which it serves as MB-UPF by determining whether a specific PFCP session has been established for the MBS session (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 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 shall not contain an N6mb / N9mb address or IP multicast addressing information;

NOTE 1: Only the PFCP session created for the MBS session as specified in clause 5.34.2.2 can contain a N6mb / N9mb 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, 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.