8.2 Restoration procedures for MB-UPF failure with or without restart

23.5273GPP5G SystemRelease 18Restoration proceduresTS

8.2.1 General

When an MB-UPF fails, all its PFCP session contexts of the MBS sessions and all its PFCP associations affected by the failure may be lost.

The MB-SMF and MB-UPF may support the procedures specified in this clause to restore the multicast and broadcast MBS sessions affected by the failure.

8.2.2 Restoration Procedure for MB-UPF Restart

The MB-UPF should ensure that:

– when multicast transport is used on N3mb and/or N19mb, any N3mb and/or N19mb Low Layer Source Specific Multicast (LL SSM) addresses used by the MB-UPF before the MB-UPF restart are not immediately reused after the MB-UPF restart; and

– when unicast transport is used on N6mb and/or Nmb9, any N6mb and/or Nmb9 ingress tunnel addresses used by the MB-UPF before the MB-UPF restart are not immediately reused after the MB-UPF restart.

NOTE 1: This avoids inconsistent addresses allocation throughout the network and enable the restoration of PFCP sessions of MBS sessions affected by the failure. How this is ensured is implementation specific.

During or immediately after an MB-UPF Restart, the MB-UPF shall place a local UPF Recovery Time Stamp value in all Heartbeat Request/Response messages.

Immediately after the re-establishment of a PFCP association between the MB-SMF and the MB-UPF, the MB-SMF may start restoring the PFCP sessions of the affected MBS sessions in the MB-UPF, by following PFCP requirements for establishing a PFCP session over N4mb as specified in clause 5.34.2 of 3GPP TS 29.244 [4], with the following modifications:

– the MB-SMF shall include the MBS Restoration Indication in the PFCP Session Establishment Request message to indicate to the MB-UPF that this is a request to restore the PFCP session of an existing MBS session;

– If multicast transport is used on N3mb and/or N19mb, the MB-SMF shall additionally provide, in the Multicast Transport Information for N3mb and/or N19mb IE in the PFCP Session Establishment Request, the N3mb and/or N19mb LL SSM address and GTP-U Common TEID (C-TEID) that was previously used for the MBS session, and the MB-UPF shall allocate the same N3mb and/or N19mb LL SSM address and C-TEID to the PFCP session if possible. The MB-SMF shall not set the PLLSSM flag in the MBSN4mbReq-Flags IE in the PFCP Session Establishment Request.

– If unicast transport is used on N6mb and/or Nmb9, the MB-SMF shall additionally provide, in the "Local Ingress Tunnel" IE in the Create PDR IE or Create Tunnel Endpoint IE (for the downlink PDRs) in the PFCP Session Establishment Request, the N6mb and/or Nmb9 ingress tunnel address that was previously used for the MBS session, and the MB-UPF shall allocate the same N6mb and/or Nmb9 ingress tunnel address if possible. The MB-SMF shall not set the CHOOSE bit to "1" in the "Local Ingress Tunnel" IE".

If multicast transport is used on N3mb and/or N19mb and the MB-UPF cannot accept the requested N3mb and/or N19mb LL SSM address, or if unicast transport is used on N6mb and/or Nmb9 and the UPF cannot accept the requested N6mb and/or Nmb9 ingress tunnel address, because the requested address is not available at the MB-UPF, the MB-UPF shall reject the PFCP Session Establishment Request with the cause "PFCP session restoration failure due to requested resource not available". The MB-SMF may then proceed as specified for the restoration procedure for MB-UPF failure without restart, but possibly using the same or a different MB-UPF.

NOTE 2: The cause "PFCP session restoration failure due to requested resource not available" corresponds to scenarios where the requested address is no longer available at the MB-UPF, i.e. it cannot be assigned to any PFCP session, due to e.g. the address having been decommissioned by OAM from the MB-UPF or e.g. the address being no longer operational due to a partial hardware failure at the MB-UPF. This cause is not to be used for scenarios where the requested address would be available at the MB-UPF but would have been re-assigned to a different PFCP session, which is a scenario that is not expected to happen based on the requirements specified above.

8.2.3 Restoration Procedure for MB-UPF failure without Restart

Upon detecting that an MB-UPF fails without restart, the MB-SMF may restore the MBS sessions that were served by the failed MB-UPF by selecting an alternative MB-UPF and by restoring the PFCP sessions of the MBS sessions in the alternative MB-UPF, following PFCP requirements for establishing an N4mb PFCP session as specified in clause 5.34.2 of 3GPP TS 29.244 [4] with the following additions:

– the MB-SMF shall request the alternative MB-UPF to join the multicast tree towards the Source Specific Multicast (SSM) address information earlier provided by AF/AS or MBSTF, if multicast transport is used over N6mb and/or Nmb9;

– the MB-SMF shall request the alternative MB-UPF to allocate a new N6mb and/or Nmb9 ingress tunnel address, if unicast transport is used over N6mb and/or Nmb9;

– the MB-SMF shall request the alternative MB-UPF to allocate a new N3mb and/or N19mb LL SSM address and C-TEID, if multicast transport is used over N3mb and/or N19mb; and

– for each N3mb and/or N19mb endpoint expected to receice the MSB session data, the MB-SMF shall request the alternative MB-UPF to send data towards the N3mb and/or N19mb endpoint’s DL F-TEID, if unicast transport is used over N3mb and/or N19mb.

For each MBS session, during the PFCP session establishment, the alternative MB-UPF will assign:

– a new N3mb and/or N19mb LL SSM address and C-TEID, if multicast transport is used on N3mb and/or N19mb; and/or

– a new N6mb and/or Nmb9 ingress tunnel address, if unicast transport is used on N6mb and/or Nmb9.

Then, for each MBS session:

– if multicast transport is used on N3mb:

– the MB-SMF shall update the AMFs handling the multicast or broadcast MBS session, or location dependent component of the MBS session, about the new N3mb LL SSM address and C-TEID by sending:

– an Namf_MBSCommunication_N2MessageTransfer request (Multicast Session Update Request including the new MB-UPF LL SSM address and C-TEID) for a multicast MBS session; and/or

– an Namf_MBSBroadcast ContextUpdate Request (Broadcast Session Modification Request including the new MB-UPF LL SSM address and C-TEID) for a broadcast MBS session.

– the AMFs shall forward the above information towards the NG-RAN nodes handling the MBS session (using the Multicast Session Update and Broadcast Session Modification procedures respectively);

– the NG-RAN nodes shall join delivery from the new multicast transport address to receive MBS session data from the new MB-UPF and leave delivery from the previous multicast address in use for the MBS session.

– if multicast transport is used on N19mb, for a multicast MBS session:

– the MB-SMF shall update the SMF handling the multicast MBS session, or location dependent component of the MBS session, about the new N19mb LL SSM address and C-TEID by sending an Nmbsmf_MBSSession_ContextStatusNotify request including an " MULT_TRANS_ADD_CHANGE" event and the new N19mb LL SSM address and C-TEID used for the MBS data delivery over N19mb;

– the SMF shall update the UPF terminating the N19mb tunnel about the new LL SSM address and C-TEID;

– the UPF shall join delivery from the new multicast transport address to receive MBS session data from the new MB-UPF and leave delivery from the previous multicast address in use for the MBS session.

– if unicast transport is used on N6mb and/or Nmb9:

– the MB-SMF shall update the AF/NEF/MBSF about the new N6mb/Nmb9 ingress tunnel address to use for sending MBS data for a given MBS session, or location dependent component of the MBS session, by sending an Nmbsmf_MBSSession_StatusNotify request including an "Ingress Tunnel Address Change" event and the new N6mb/Nmb9 ingress tunnel address;

– the AF/MBSF shall start sending MBS data to the new N6mb/Nmb9 ingress tunnel address.

Figures 8.2.3-1 and 8.2.3-2 depict the call flows for the case of a broadcast MBS session and a multicast MBS session respectively.

Figure 8.2.3-1: Broadcast MBS session restoration upon MB-UPF failure without restart

Figure 8.2.3-2: Multicast MBS session restoration upon MB-UPF failure without restart