8.3 Restoration procedures for NG-RAN failure with or without restart
23.5273GPP5G SystemRelease 18Restoration proceduresTS
8.3.1 General
When an NG-RAN fails with or without restart, all its MBS session contexts may be lost, causing the interruption in the delivery of MBS data over the radio interface.
Restoration procedures for NG-RAN failure with or without restart are optional to support.
8.3.2 Broadcast MBS session restoration Procedure for NG-RAN failure with restart
8.3.2.1 General
MBS sessions affected by an NG-RAN failure with restart may be restored by the AMF as specified in clause 8.3.2.2 or by the MB-SMF as specified in clause 8.3.2.3.
8.3.2.2 Broadcast MBS session restoration by AMF
The procedure specified in this clause may be supported to restore a broadcast MBS session affected by an NG-RAN restart.
The AMF handling a broadcast MBS session is responsible for restoring the MBS session in a restarted NG-RAN, as shown in Figure 8.3.2.2-1.
NOTE 1: An NG-RAN restart is transparent to the MB-SMF (i.e. the restoration procedure does not cause any signaling to the MB-SMF) when multicast transport is used over N3mb.
NOTE 2: This procedure can also be used in other scenarios where an existing MBS session needs to be started in a new NG-RAN, e.g. an NG-RAN that is reconfigured by OAM to support a new TA that is part of the MBS service area of an existing MBS session.
Figure 8.3.2.2-1: Broadcast MBS session restoration by AMF upon NG-RAN restart
1. The AMF stores the last N2 MBS SM container (i.e. MBS Session Setup or Modification Request Transfer IE defined in 3GPP TS 38.413 [11]) received from the MB-SMF during the establishment of the broadcast MBS session or during a broadcast MBS session update. When unicast transport is used over N3mb, the MB-SMF stores the RAN-ID together with the DL F-TEID received from each NG-RAN.
NOTE 3: The N2 MBS SM container contains all the information to establish the broadcast MBS session (e.g. transport layer address if multicast transport is used over N3mb, QoS flows).
2. The NG-RAN restarts, causing the broadcast MBS service interruption.
3. The AMF detects that the NG-RAN has restarted (e.g. upon receiving NG Setup Request message) and that it serves at least one TAI or one cell being part of the MBS service area of an existing MBS session (or one of the MBS services areas of the MBS session in case of location dependent content).
4. The AMF re-establishes the broadcast MBS session in the restarted NG-RAN, by sending an NGAP Broadcast Session Setup Request including the last N2 (NGAP) MBS Session Setup or Modification Request Transfer IE that was stored.
The NG-RAN establishes the broadcast MBS session and returns a response to the AMF. If unicast transport is used over N3mb, the NG-RAN response includes the DL F-TEID assigned by the NG-RAN to receive the MBS data from the MB-UPF within the N2 (NGAP) MBS Session Setup or Modification Response Transfer IE of the NGAP Broadcast Session Setup Response message. In deployments where multiple NG-RAN nodes share a common user plane entity and unicast transport is used over N3mb, the NG-RAN response may include an existing DL F-TEID signalled by other NG-RAN nodes during shared delivery setup.
The NG-RAN joins the delivery of the broadcast MBS session if multicast transport is used over N3mb.
5. If an N2 MBS SM Container (i.e. N2 (NGAP) MBS Session Setup or Modification Response Transfer IE) was received from the NG-RAN in step 4, the AMF sends an Namf_MBSBroadcast_ContextStatusNotify Request to the MB-SMF including the N2 MBS SM Container and the RAN-ID of the NG-RAN .
6. The MB-SMF modifies the PFCP session of the MBS session in the MB-UPF to start distributing MBS data towards the DL GTP-U F-TEID received from the NG-RAN, and to stop doing so towards the earlier DL GTP-U F-TEID that was used by the same NG-RAN before the NG-RAN restart.
This step shall be skipped in deployments where multiple NG-RAN nodes share a common user plane entity, unicast transport is used over N3mb, and the MB-SMF that supports handling shared NG-U terminations determines that the DL F-TEID signalled by restarted NG-RAN node is already associated with other NG-RAN nodes.
8.3.2.3 Broadcast MBS session restoration by MB-SMF
The procedure specified in this clause may be supported to restore a Broadcast MBS session affected by an NG-RAN restart.
When the AMF detects an NG-RAN restart, or a (new) NG-RAN is deployed to serve a TAI that is part of the MBS session service area, e.g. using NG Setup Request message, as specified in 3GPP TS 38.413 [11], it shall report such event to the MB-SMF for each of MBS session(s) affected by this event, to enable the MB-SMF to (re)start the MBS session(s) in the concerning NG-RAN as further described in the Figure 8.3.2.3-1.
The MB-SMF shall run the following restoration procedure for each of Broadcast MBS sessions which were established in the restarted NG-RAN or a (new) NG-RAN.
Figure 8.3.2.3-1: Broadcast MBS session restoration by MB-SMF upon NG-RAN failure with restart
1. The NG-RAN has failed with restart.
2. The AMF detects the NG-RAN has failed with restart, e.g., upon receiving NG Setup Request message.
3. The AMF sends Namf_MBSBroadcast_ContextStatusNotify Request message to the MB-SMF for each affected MBS session including the MBS Session ID, the NG-RAN ID and an indication of the event, either NG-RAN restart, or NG-RAN failure without restart, or a (new) NG-RAN getting into service to serve a TAI that is part of the MBS session service area.
3a. The MB-SMF receives a PFCP Node Report Request message from the MB-UPF to report NG-RAN has failed with restart or a PFCP Session Report Request message from the MB-UPF to report receiving GTP-U Error Indication for each affected MBS session when unicast transport was used for N3mb interface.
4. The MB-SMF returns a "204 No Content" response.
5. The MB-SMF modifies the PFCP sessions corresponding to the affected MBS sessions to remove the NG-RAN DL F-TEID for unicast transport over N3mb.
6. The MB-SMF sends Namf_MBSBroadcast_ContextUpdate Request message to the AMF to (re)start the MBS session in the related NG-RAN including the MBS Session Setup or Modification Request Transfer IE and the NG-RAN ID received in the step 3.
If the notification is triggered due to receiving the PFCP Node Report Request message or the PFCP Session Report Request message from the MB-UPF as specified in step 3a, and the MB-SMF that supports handling shared NG-U terminations determines that multiple NG-RAN nodes share the restarted user plane entity, the Namf_MBSBroadcast_ContextUpdate Request message may include multiple corresponding NG-RAN IDs.
7. The AMF sends the N2 MBS Session Setup Request message to the NG-RAN node(s) including the MBS Session Setup or Modification Request Transfer IE.
8. The MBS session is created/restored in the NG-RAN node(s).
9. The NG-RAN node(s) joins the delivery of the broadcast MBS session if multicast transport is used over N3mb.
10. The NG-RAN node(s) responds with the N2 MBS Session Setup Response message including a MBS Session Setup or Modification Transfer IE if a Shared NG-U Unicast TNL Information needs to be allocated for unicast transport over N3mb interface.
11. The AMF responds with Namf_MBSBroadcast_ContextUpdate Response message with a MBS Session Setup or Modification Response Transfer IE if received.
12. The MB-SMF modifies the PFCP sessions corresponding to the MBS sessions to provision the new NG-RAN DL F-TEID if received in step 10.
8.3.2.4 Selecting an alternative AMF for a Broadcast MBS Session at AMF failure
When the AMF selected by the MB-SMF to start a Broadcast MBS Session fails without restart, to support the restoration procedure to restore an Broadcast MBS Session in a restarted NG-RAN as specified in 8.3.2.2 and 8.3.2.3, another AMF in the same AMF set needs to be selected to become the serving AMF for this broadcast MBS session and to be responsible for restoration. This may be done by one of the following solutions:
– another AMF is selected in the same AMF set by an AMF implementation specific mechanism, and this AMF sends a Namf_MBSBroadcast_ContextStatusNotify Request message to the MB-SMF to notify this optionally containing an updated binding indication; or
– when the MB-SMF detects that the AMF which was handling the Broadcast MBS session has failed without restart and no Namf_MBSBroadcast_ContextStatusNotify Request is received from any AMF of the AMF set as described in the first bullet, the MB-SMF may reselect an alternative AMF by sending a Namf_MBSBroadcast_ContextUpdate Request message with an indication that the alternative AMF needs not trigger any NGAP message to deliver the N2 container – MBS Session Setup or Modification Request Transfer, but just to store it for future potential NG-RAN restoration.
Figure 8.3.2.4-1 Selecting an alternative AMF at AMF failure.
1. A Broadcast MBS Session has been established in the network.
2. The AMF1 has failed without restart.
3. Alternative A: another AMF2 in the same AMF set is selected by an AMF implementation specific mechanism.
4. The AMF2 sends Namf_MBSBroadcast_ContextStatusNotify to the MB-SMF that the AMF2 becomes the AMF controlling the Broadcast MBS Session context.
5. The MB-SMF acknowledges the notification and will send subsequent signalling message for this Broadcast MBS Session via the AMF2.
6. Alternative B: the MB-SMF detects that the AMF1 has failed without restart either via HTTP/2 PING Frame for directly connected, or via notifications from the NRF for the NF Status Change when it has subscribed such event, and that no Namf_MBSBroadcast_ContextStatusNotify Request is received from any AMF of the AMF set as described in Alternative A.
7. The MB-SMF selects an alternative AMF pertaining to the same AMF set using the Binding Indication provided by the old AMF or using the NF profile of the old AMF.
8. The MB-SMF sends a Namf_MBSBroadcast_ContextUpdate Request including a MBS Session ID, the corresponding MBS Service Area, a MBS Session Setup or Modification Request Transfer, and sets the "noNgapSignallingInd" to "true" to request the AMF2 to be the AMF for the Broadcast MBS Session to handle subsequent MBS session signaling and be responsible for triggering restoration procedures for NG-RAN failure with or without restart. The AMF may consider to not trigger any NGAP signalling towards NG-RANs covering the MBS service area.
NOTE 1: Upon receiving any subsequent NGAP Broadcast MBS Session signalling from an alternative AMF, the NG-RAN will send any later NG-RAN initiated MBS session signalling towards this alternative AMF.
NOTE 2: If the AMF does not trigger any NGAP signaling towards NG-RANs covering the MBS service area, before receiving any subsequent NGAP Broadcast MBS Session signalling from an alternative AMF, a NG-RAN can initiate a NGAP Broadcast MBS Session signaling procedure (e.g. Broadcast MBS Session Release Required) to a third AMF, e.g. AMF3, in which case the NG-RAN expects a response from AMF3. However, this does not affect that the AMF2 is the AMF responsible for the Broadcast MBS Session, e.g. to handle subsequent Namf_MBSBroadcast_ContextUpdate request messages or to restore the Broadcast MBS session at a NG-RAN restart. How the NGAP initiated Broadcast MBS Session signaling is handled between AMF3 and AMF2 is implementation specific (e.g. to update the broadcast MBS session context that the MBS session has been stopped in the NG-RAN).
9. The AMF responds the Namf_MBSBroadcast_ContextUpdate Request message.
10. The AMF2 continues with the procedures as specified in clauses 8.3.2.2 and 8.3.2.3.
8.3.3 Broadcast MBS session restoration Procedure for NG-RAN failure without restart
The procedure specified in this clause may be supported to restore a Broadcast MBS session affected by an NG-RAN failure without restart.
When the AMF detects NG-RAN failure without restart, e.g. using SCTP path failure detection mechanism, it shall report such event to the MB-SMF for each of MBS session(s) affected by this failure, to enable the MB-SMF to remove the DL F-TEID allocated by the failed NG-RAN in the MB-UPF when unicast transport is used over N3mb interface.
Figure 8.3.3-1: Broadcast MBS session restoration by MB-SMF upon NG-RAN failure without restart
0. A Broadcast MBS session is created in a NG-RAN, the NG-RAN ID is inserted by the AMF in the N2MbsSmInfo attribute included in the Namf_MBSBroadcast_ContextCreate Response message to the MB-SMF and the MB-SMF stores the NG-RAN ID together with the DL F-TEID allocated by the NG-RAN when unicast transport is used over N3mb interface.
1. The NG-RAN has failed without restart.
2. The AMF detects the NG-RAN has failed without restart e.g. using SCTP path failure detection mechanism.
3. The AMF sends Namf_MBSBroadcast_ContextStatusNotify Request message to the MB-SMF for each affected MBS session including the MBS Session ID, the NG-RAN ID and an indication of the NG-RAN failure without restart event.
3a. The MB-SMF receives a PFCP Node Report Request message from the MB-UPF to report NG-RAN has failed without restart for each affected MBS session when unicast transport was used for N3mb interface.
4. The MB-SMF returns a "204 No Content" response.
5. The MB-SMF modifies the PFCP sessions corresponding to the affected MBS sessions to remove the NG-RAN DL F-TEID in case NG-RAN failure without restart for unicast transport over N3mb.
The MB-SMF executes step 5 upon receiving either the notification from the AMF or from the MB-UPF.
If the restoration procedure is triggered due to notification from AMF as specified in step 3, this step may be skipped in deployments where multiple NG-RAN nodes share a common user plane entity, unicast transport is used over N3mb, and the MB-SMF that supports handling shared NG-U terminations determines that the DL F-TEID is associated with other NG-RAN nodes too.
8.3.4 Multicast MBS session restoration Procedure for NG-RAN failure with or without restart
The procedure specified in this clause may be supported to restore a Multicast MBS session affected by an NG-RAN failure with or without restart.
When a UPF detects the NG-RAN failure with or without restart using Echo Request and Echo Response message which is sent towards the IP address in the DL F-TEID allocated by the failed NG-RAN, or upon receiving GTP-U Error Indication, it shall report such event to the SMF to enable the SMF to derive UEs who have joined the MBS sessions which are affected by the NG-RAN failure and initiates the restoration procedure for each of Multicast MBS session which were activated in the failed NG-RAN as described in Figure 8.3.4-1.
When unicast transport is used over N3mb interface for 5GC Shared MBS traffic delivery, the MB-UPF detects the NG-RAN failure with or without restart using Echo Request and Echo Response message which is sent towards the IP address in the DL F-TEID allocated by the failed NG-RAN, or upon receiving GTP-U Error Indication, it shall report such event to the MB-SMF, so that the MB-SMF removes the DL-TEID allocated by the failed NG-RAN.
Figure 8.3.4-1: Multicast MBS session restoration upon NG-RAN failure with or without restart
1. The NG-RAN has failed with or without restart.
2. The UPF receive GTP-U Error Indication when the NG-RAN recovers from its restart for 5GC Individual MBS traffic delivery.
2a. The MB-UPF receives GTP-U Error Indication when the NG-RAN recovers from its restart for unicast transport over N3mb for 5GC Shared MBS traffic delivery.
3. The UPF sends Echo Request message towards the NG-RAN using the IP address included in the DL F-TEID, thus the UPF detects the NG-RAN has failed with or without restart.
3a. The MB-UPF sends Echo Request message towards the NG-RAN using the IP address included in the DL F-TEID for unicast transport over N3mb, thus the MB-UPF detects the NG-RAN has failed with or without restart.
4. The UPF sends PFCP Session Report Request messages to the SMF to report receiving of GTP-U Error Indication message, or sends a PFCP Node Report Request message to the SMF to report the GTP-U path failure towards the NG-RAN or the remote GTP-U entity has restarted.
5. The SMF sends PFCP Session Modification Request message to request the UPF to remove DL-FTEID allocated by the failed NG-RAN and buffer the MBS session data for 5GC Individual MBS traffic delivery, except for an NG-RAN restart if the UPF has already removed the DL F-TEID on its own as specified in clause 5.5.
6. The MB-UPF sends PFCP Session Report Request messages to the MB-SMF to report receiving of GTP-U Error Indication message, or sends a PFCP Node Report Request message to the MB-SMF to report the GTP-U path failure towards the NG-RAN or the remote GTP-U entity has restarted, for unicast transport for N3mb.
7. The MB-SMF sends PFCP Session Modification Request message to request the MB-UPF to remove DL-FTEID allocated by the failed NG-RAN, except for an NG-RAN restart if the MB-UPF has already removed the DL F-TEID on its own as specified in clause 5.5.
8a. The SMF may wait for UEs who have joined the MBS session(s) which are affected by the NG-RAN failure to trigger a Service Request procedure to re-establish the user plane resource and then restore the Multicast MBS session in NG-RAN.
8b. Alternatively, the SMF may derive UEs who have joined the MBS session(s) which are affected by the NG-RAN failure (i.e. with a DL F-TEID matching the IP address of the NG-RAN node’s to restore the MBS service and perform step 9.
9. When step 8b applies, the SMF continues with the MBS session activation procedure as specified in clause 7.2.5.2 of 3GPP TS 23.247 [12] starting from step 3 to restore the MBS sessions for affected UEs for each MBS session.