3GPP 23.501 v20.2.0 — the document's own text
5.21.2.2.1 AMF planned removal procedure with UDSF deployed
Taught in 27. Overload, energy, deployment and the rest (The 5G system architecture, in depth).
An AMF can be taken graciously out of service as follows:
- If an UDSF is deployed in the network, then the AMF stores the context for registered UE(s) in the UDSF. The UE context includes the AMF UE NGAP ID that is unique per AMF set. In order for the AMF planned removal procedure to work graciously, 5G-S-TMSI shall be unique per AMF Set. If there are ongoing transactions (e.g. N1 procedure) for certain UE(s), AMF stores the UE context(s) in the UDSF upon completion of an ongoing transaction.
- The AMF deregister itself from NRF indicating due to AMF planned removal.
NOTE 1: It is assumed that the UE contexts from the old AMF include all event subscriptions with peer CP NFs.
NOTE 2: Before removal of AMF the overload control mechanism can be used to reduce the amount of ongoing transaction.
An AMF identified by GUAMI(s) shall be able to notify the 5G-AN that it will be unavailable for processing transactions by including GUAMI(s) configured on this AMF. Upon receipt of the indication that an AMF(identified by GUAMI(s)) is unavailable, 5G-AN shall take the following action:
- 5G-AN should mark this AMF as unavailable and not consider the AMF for selection for subsequent N2 transactions until 5G-AN learns that it is available (e.g. as part of discovery results or by configuration).
- During NGAP Setup procedure, the AMF may include an additional indicator that the AMF will rebind or release the NGAP UE-TNLA-binding on a per UE-basis for UE(s) in CM-CONNECTED state. If that indicator is included and the 5G-AN supports timer mechanism, the 5G-AN starts a timer to control the release of NGAP UE-TNLA-binding. For the duration of the timer or until the AMF releases or re-binds the NGAP UE-TNLA-binding the AN does not select a new AMF for subsequent UE transactions. Upon timer expiry, the 5G-AN releases the NGAP UE UE-TNLA-binding(s) with the corresponding AMF for the respective UE(s), for subsequent N2 message, the 5G-AN should select a different AMF from the same AMF set when the subsequent N2 message needs to be sent.
NOTE 3: For UE(s) in CM-CONNECTED state, after indicating that the AMF is unavailable for processing UE transactions and including an indicator that the AMF releases the NGAP UE-TNLA-binding(s) on a per UE-basis, the AMF can either trigger a re-binding of the NGAP UE associations to an available TNLA on a different AMF in the same AMF set or use the NGAP UE-TNLA-binding per UE release procedure defined in TS 23.502 [3] to release the NGAP UE-TNLA-binding on a per UE-basis while requesting the AN to maintain N3 (user plane connectivity) and UE context information.
NOTE 4: The support and the use of timer mechanism in 5G-AN is up to implementation.
- If the instruction does not include the indicator, for UE(s) in CM-CONNECTED state, 5G-AN considers this as a request to release the NGAP UE-TNLA-binding with the corresponding AMF for the respective UE(s) while maintaining N3 (user plane connectivity) and UE context information. For subsequent N2 message, the 5G-AN should select a different AMF from the same AMF set when the subsequent N2 message needs to be sent.
- For UE(s) in CM-IDLE state, when it subsequently returns from CM-IDLE state and the 5G-AN receives an initial NAS message with a 5G S-TMSI or GUAMI pointing to an AMF that is marked unavailable, the 5G-AN should select a different AMF from the same AMF set and forward the initial NAS message. If the 5G-AN can't select an AMF from the same AMF set, the 5G-AN selects another new AMF as described in clause 6.3.5.
An AMF identified by GUAMI(s) shall be able to instruct other peer CP NFs, subscribed to receive such a notification, that it will be unavailable for processing transactions by including GUAMI(s) configured on this AMF. If the CP NFs register with NRF for AMF unavailable notification, then the NRF shall be able to notify the subscribed NFs to receive such a notification that AMF identified by GUAMI(s) will be unavailable for processing transactions. Upon receipt of the notification that an AMF (GUAMI(s)) is unavailable, the other CP NFs shall take the following actions:
- CP NF should mark this AMF (identified by GUAMI(s)) as unavailable and not consider the AMF for selection for subsequent MT transactions until the CP NF learns that it is available (e.g. as part of NF discovery results or via NF status notification from NRF).
- Mark this AMF as unavailable while not changing the status of UE(s) associated to this AMF (UE(s) previously served by the corresponding AMF still remain registered in the network) and AMF Set information.
- For the UE(s) that were associated to the corresponding AMF, when the peer CP NF needs to initiate a transaction towards the AMF that is marked unavailable, CP NF should select another AMF from the same AMF set (as in clause 6.3.5) and forward the transaction together with the old GUAMI. The new AMF retrieves UE context from the UDSF. If CP NF needs to send a notification to new AMF which is associated with a subscription from the old AMF, the CP NF shall exchange the old AMF information embedded in the Notification Address with the new AMF information and use that Notification Address for subsequent communication.
NOTE 5: If the CP NF does not subscribe to receive AMF unavailable notification (either directly from the AMF or via NRF), the CP NF may attempt forwarding the transaction towards the old AMF and detect that the AMF is unavailable after certain number of attempts. When it detects unavailable, it marks the AMF and its associated GUAMI(s) as unavailable. CP NF should select another AMF from the same AMF set (as in clause 6.3.5) and forward the transaction together with the old GUAMI. The new AMF retrieves UE context from the UDSF and process the transaction.
Following actions should be performed by the newly selected AMF:
- When there is a transaction with the UE the newly selected AMF retrieves the UE context from the UDSF based on SUPI, 5G-GUTI or AMF UE NGAP ID and processes the UE message accordingly and updates the 5G-GUTI towards the UE, if necessary. For UE(s) in CM-CONNECTED state, it may also update the NGAP UE association with a new AMF UE NGAP ID towards the 5G-AN and replace the GUAMI in the UE context stored at the 5G-AN with the new GUAMI associated with the newly selected AMF if the 5G-GUTI has been updated. The AMF also informs the NG-RAN of the new UE Identity Index Value (derived from the new 5G-GUTI).
- When there is a transaction with the UE, the new selected AMF updates the peer NFs (that subscribed to receive AMF unavailability notification from old AMF), with the new selected AMF information.
- If the new AMF is aware of a different AMF serving the UE (by implementation specific means) it forwards the uplink N2 signalling of the UE to that AMF directly if necessary, the 5G-AN shall be able to receive the message from a different AMF, or it rejects the transaction from the peer CP NFs with a cause to indicate that new AMF has been selected, the peer CP NFs resend the transaction to the new AMF.
NOTE 6: This bullet above addresses situations where 5G-AN node selects an AMF and CP NFs select another AMF for the UE concurrently. It also addresses the situation where CP NFs select an AMF for the UE concurrently
- If the UE is in CM-IDLE state and the new AMF does not have access to the UE context, the new AMF selects one available AMF from the old AMF set as described in clause 6.3.5. The selected AMF retrieves the UE context from the UDSF and provides the UE context to the new AMF. If the new AMF doesn't receive the UE context then the AMF may force the UE to perform Initial Registration.