5.21 Architectural support for virtualized deployments

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.21.0 General

5GC supports different virtualized deployment scenarios, including but not limited to the options below:

– A Network Function instance can be deployed as distributed, redundant, stateless, and scalable NF instance that provides the services from several locations and several execution instances in each location.

– This type of deployments would typically not require support for addition or removal of NF instances for redundancy and scalability. In the case of an AMF this deployment option may use enablers like, addition of TNLA, removal of TNLA, TNLA release and rebinding of NGAP UE association to a new TNLA to the same AMF.

– A Network Function instance can also be deployed such that several network function instances are present within a NF set provide distributed, redundant, stateless and scalability together as a set of NF instances.

– This type of deployments may support for addition or removal of NF instances for redundancy and scalability. In the case of an AMF this deployment option may use enablers like, addition of AMFs and TNLAs, removal of AMFs and TNLAs, TNLA release and rebinding of NGAP UE associations to a new TNLA to different AMFs in the same AMF set.

– The SEPP, although not a Network Function instance, can also be deployed distributed, redundant, stateless, and scalable.

– The SCP, although not a Network Function instance, can also be deployed distributed, redundant, and scalable.

Also, deployments taking advantage of only some or any combination of concepts from each of the above options is possible.

5.21.1 Architectural support for N2

5.21.1.1 TNL associations

5G-AN node shall have the capability to support multiple TNL associations per AMF, i.e. AMF name.

An AMF shall provide the 5G-AN node with the weight factors for each TNL association of the AMF.

The AMF shall be able to request the 5G-AN node to add or remove TNL associations to the AMF.

The AMF shall be able to indicate to the 5G-AN node the set of TNL associations used for UE-associated signalling and the set of TNL associations used for non-UE associated signalling.

NOTE: The TNL association(s) indicated for UE-associated and non-UE associated signalling can either be overlap or be different.

5.21.1.2 NGAP UE-TNLA-binding

While a UE is in CM-Connected state the 5G-AN node shall maintain the same NGAP UE-TNLA-binding (i.e. use the same TNL association and same NGAP association for the UE) unless explicitly changed or released by the AMF.

An AMF shall be able to update the NGAP UE-TNLA-binding (i.e. change the TNL association for the UE) in CM-CONNECTED state at any time. The NGAP UE-TNLA-binding can also be updated when a UE-specific NGAP message initiated by AMF is received via a new TNL association.

An AMF shall be able to update the NGAP UE-TNLA-binding (i.e. change the TNL association for the UE) in response to an N2 message received from the 5G-AN by triangular redirection (e.g. by responding to the 5G-AN node using a different TNL association).

An AMF shall be able to command the 5G-AN node to release the NGAP UE-TNLA-binding for a UE in CM-CONNECTED state while maintaining N3 (user-plane connectivity) for the UE at any time.

5.21.1.3 N2 TNL association selection

The 5G-AN node shall consider the following factors for selecting a TNL association for the AMF for the initial N2 message e.g. N2 INITIAL UE MESSAGE:

– Availability of candidate TNL associations.

– Weight factors of candidate TNL associations.

The AMF may use any TNL association intended for non-UE associated signalling for initiation of the N2 Paging procedure.

5.21.2 AMF Management

5.21.2.1 AMF Addition/Update

The 5G System should support establishment of association between AMF and 5G-AN node.

A new AMF can be added to an AMF set and association between AMF and GUAMI can be created and/or updated as follows:

– AMF shall be able to dynamically update the NRF with the new or updated GUAMI(s) to provide mapping between GUAMI(s) and AMF information. Association between GUAMI(s) and AMF is published to NRF. In addition, to deal with planned maintenance and failure, an AMF may optionally provide backup AMF information, i.e. it act as a backup AMF if the indicated GUAMI associated AMF is unavailable. It is assumed that the backup AMF and the original AMF are in the same AMF set as they have access to the same UE context. Based on that information one GUAMI is associated with an AMF, optionally with a backup AMF used for planned removal and/or another (same or different) backup AMF used for failure.

– Upon successful update, the NRF considers the new and/or updated GUAMI(s) for providing AMF discovery results to the requester. Requester can be other CP network functions.

– The new AMF provides its GUAMI to 5G-AN and 5G-AN store this association. If the association between the same GUAMI and another AMF exists in the 5G-AN (e.g. due to AMF planned removal), the previously stored AMF is replaced by the new AMF for the corresponding GUAMI association.

Information about new AMF should be published and available in the DNS system. It should allow 5G-AN to discover AMF and setup associations with the AMF required. N2 setup procedure should allow the possibility of AMFs within the AMF Set to advertise the same AMF Pointer and/or distinct AMF Pointer value(s) to the 5G-AN node.

To support the legacy EPC core network entity (i.e. MME) to discover and communicate with the AMF, the information about the AMF should be published and available in the DNS system. Furthermore, GUMMEI and GUAMI encoding space should be partitioned to avoid overlapping values in order to enable MME discover an AMF without ambiguity.

5.21.2.2 AMF planned removal procedure

5.21.2.2.1 AMF planned removal procedure with UDSF deployed

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.

5.21.2.2.2 AMF planned removal procedure without UDSF

An AMF can be taken graciously out of service as follows:

– The AMF can forward registered UE contexts, UE contexts grouped by the same GUAMI value, to target AMF(s) within the same AMF set, including the source AMF name used for redirecting UE’s MT transaction. The UE context includes the per AMF Set unique AMF UE NGAP ID. 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 forwards the UE context(s) to the target AMF 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 shall be able to instruct the 5G-AN that it will be unavailable for processing transactions by including GUAMI(s) configured on this AMF and its corresponding target AMF(s). The target AMF shall be able to update the 5G-AN that the UE(s) served by the old GUAMI(s) are now served by target AMF. The target AMF provides the old GUAMI value that the 5G-AN can use to locate UE contexts served by the old AMF. Upon receipt of the indication that an old AMF is unavailable, 5G-AN shall take the following action:

– During NGAP Setup, the AMF may include an additional indicator that the AMF will rebind or release the NGAP UE-TNLA-binding on per UE-basis. 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(s). 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 transactions. Upon timer expiry, the 5G-AN releases the NGAP UE-TNLA-binding(s) with the corresponding AMF for the respective UE(s), for subsequent N2 message, the 5G-AN uses GUAMI which points to the target AMF that replaced the old unavailable AMF, to forward the N2 message to the corresponding target AMF(s).

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 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 within 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 UE-TNLA-binding(s) 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 uses GUAMI based resolution which points to the target AMF that replaced the old unavailable AMF, to forward the N2 message to the corresponding target AMF(s).

– 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, based resolution the 5G-AN uses 5G S-TMSI or GUAMI which points to the target AMF that has replaced the old unavailable AMF and, the 5G-AN forwards N2 message.

An AMF 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 and its corresponding target AMF(s). The target AMF shall update the CP NF that the old GUAMI(s) is now served by target AMF. The old AMF provides the old GUAMI value to target AMF and the target AMF can use to locate UE contexts served by the old 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 (along with the corresponding target AMF(s)) that AMF identified by GUAMI(s) will be unavailable for processing transactions. Upon receipt of the notification that an AMF is unavailable, the other CP NFs shall take the following action:

– Mark this AMF and its associated GUAMI(s) 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 and the old unavailable AMF was replaced by the target AMF, CP NF should forward the transaction together with the old GUAMI to the target AMF(s). 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 with 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.

The following actions should be performed by the target AMF:

– To allow AMF process ongoing transactions for some UE(s) even after it notifies unavailable status to the target AMF, the target AMF keeps the association of the old GUAMI(s) and the old AMF for a configured time. During that configured period, if target AMF receives the transaction from the peer CP NFs and cannot locate UE context, it rejects the transaction with old AMF name based on that association, and the indicated AMF is only used for the ongoing transaction. The peer CP NFs resend the transaction to the indicated AMF only for the ongoing transaction. For subsequent transactions, peer CP NFs should use the target AMF. When the timer is expired, the target AMF deletes that association information.

– When there is a transaction with the UE the target AMF uses SUPI, 5G-GUTI or AMF UE NGAP ID to locate UE contexts and processes the UE transactions 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).

– Target AMF shall not use old GUAMI to allocate 5G-GUTI for UE(s) that are being served by Target AMF.

5.21.2.3 Procedure for AMF Auto-recovery

In order to try and handle AMF failure in a graceful manner (i.e. without impacting the UE), AMF can either back up the UE contexts in UDSF, or per GUAMI granularity in other AMFs (serving as backup AMF for the indicated GUAMI).

NOTE 1: Frequency of backup is left to implementation.

For deployments without UDSF, for each GUAMI the backup AMF information (in association to the GUAMI) is configured in the AMF. The AMF sends this information to 5G-AN and other CP NFs during the N2 setup procedure or the first (per NF) interaction with other CP NFs.

In the case that an AMF fails and the 5G-AN/peer CP NFs detect that the AMF has failed, or the 5G-AN/peer CP NFs receives notification from another AMF in the same AMF set that this AMF has failed, following actions are taken:

– The OAM deregister the AMF from NRF indicating due to AMF failure.

– 5G-AN marks this AMF as failed and not consider the AMF for selection until explicitly notified.

– For UE(s) in CM-CONNECTED state, 5G-AN considers failure detection or failure notification as a trigger to release the NGAP UE-TNLA-binding(s) with the corresponding AMF for the respective UE(s) while maintaining N3 (user plane connectivity) and other UE context information. For subsequent N2 message, if the backup AMF information of the corresponding failed AMF is not available the 5G-AN should select a different AMF (as in clause 6.3.5) from the same AMF set when the subsequent N2 message needs to be sent for the UE(s). If no other AMF from the AMF set is available, then it can select an AMF (implementation dependent) from the same AMF Region as in clause 6.3.5. If backup AMF information of the corresponding failed AMF is available, the 5G-AN forwards the N2 message to the backup AMF.

NOTE 2: One AMF in the AMF set may be configured to send this failure notification message.

– 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 S-TMSI or GUAMI pointing to an AMF that is marked failed, if the backup AMF information of the corresponding failed AMF is not available the 5G-AN should select a different AMF from the same AMF set and forward the initial NAS message. If no other AMF from the AMF set is available, then it can select an AMF (implementation dependent) from the same AMF Region as in clause 6.3.5. If backup AMF information of the corresponding failed AMF is available, the 5G-AN forwards the N2 message to the backup AMF.

– Peer CP NFs consider this AMF as unavailable while retaining the UE context.

– For the UE(s) that were associated to the corresponding AMF, when the peer CP NF needs to initiate a transaction towards the AMF, if backup AMF information of the corresponding failed AMF is not available, CP NF should select another AMF from the same AMF set and forward the transaction together with the old GUAMI. If neither the backup AMF nor any other AMF from the AMF set is available, then CP NF can select an AMF from the same AMF Region as in clause 6.3.5. If backup AMF information of the corresponding failed AMF is available, the CP NF forwards transaction to the backup AMF. 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.

– When the 5G-AN or CP NFs need to select a different AMF from the same AMF set,

– For deployments with UDSF, any AMF from the same AMF set can be selected.

– For deployments without UDSF, the backup AMF is determined based on the GUAMI of the failed AMF.

Following actions should be taken by the newly selected AMF:

– For deployments with UDSF, when there is a transaction with the UE the newly selected AMF retrieves the UE context from the UDSF using SUPI, 5G-GUTI or AMF UE NGAP ID and it processes the UE message accordingly and updates the 5G-GUTI towards the UE, if necessary.

– For deployments without UDSF, backup AMF (the newly selected AMF), based on the failure detection of the old AMF, instructs peer CP NFs and 5G-AN that the UE contexts corresponding to the GUAMI of the failed AMF is now served by this newly selected AMF. The backup AMF shall not use old GUAMI to allocate 5G-GUTI for UE(s) that are being served by Target AMF. The backup AMF uses the GUAMI to locate the respective UE Context(s).

– When there is a transaction with the UE, the new AMF updates the peer NFs (that subscribed to receive AMF unavailability notification from old AMF) with the new AMF information.

– If the new AMF is aware of a different AMF serving the UE (by implementation specific means) it redirects the uplink N2 signalling to that AMF, or reject the transaction from the peer CP NFs with a cause to indicate that new AMF has been selected. The peer CP NFs may wait for the update from the new AMF and resend the transaction to the new AMF.

NOTE 3: This bullet above addresses situations where 5G-AN node selects an AMF and other CP NFs select an AMF for the UE concurrently. It also addresses the situation where CP NFs select an AMF for the UE concurrently.

NOTE 4: It is assumed that the UE contexts from the old AMF include all event subscriptions with peer CP NFs.

– If the UE is in CM-CONNECTED state, the new AMF 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.

NOTE 5: The above N2 TNL association selection and AMF management is applied to the selected PLMN.

5.21.3 Network Reliability support with Sets

5.21.3.1 General

A Network Function instance can be deployed such that several network function instances are present within an NF Set to provide distribution, redundancy and scalability together as a Set of NF instances. The same is also supported for NF Services. This can be achieved when the equivalent NFs and NF Services share the same context data or by Network Function/NF Service Context Transfer procedures as specified in clause 4.26 of TS 23.502 [3].

NOTE: A NF can be replaced by an alternative NF within the same NF Set in the case of scenarios such as failure, load balancing, load re-balancing.

Such a network reliability design shall work in both communication modes, i.e. Direct Communication and Indirect Communication. In the Direct Communication mode, the NF Service consumer is involved in the reliability related procedures. In Indirect Communication mode, the SCP is involved in the reliability related procedures.

5.21.3.2 NF Set and NF Service Set

Equivalent Control Plane NFs may be grouped into NF Sets, e.g. several SMF instances are grouped into an SMF Set. NFs within a NF Set are interchangeable because they share the same context data, and may be deployed in different locations, e.g. different data centres.

In the case of SMF, multiple instances of SMFs within an SMF Set need to be connected to the same UPF:

– If the N4 association is established between a SMF instance and an UPF, each N4 association is only managed by the related SMF instance.

– If only one N4 association is established between a SMF Set and an UPF, any SMF in the SMF Set should be able to manage the N4 association with the UPF.

Furthermore, for a given UE and PDU Session any SMF in the SMF Set should be able to control the N4 session with the UPF (however, at any given time, only one SMF in the SMF Set will control the UPF for a given UE’s PDU Session).

A Control Plane NF is composed of one or multiple NF Services. Within a NF a NF service may have multiple instances. These multiple NF Service instances can be grouped into NF Service Set if they are interchangeable with each other because they share the same context data.

NOTE: The actual mapping of instances to a given Set is up to deployment.

5.21.3.3 Reliability of NF instances within the same NF Set

The NF producer instance is the NF instance which host the NF Service Producer. When the NF producer instance is not available, another NF producer instance within the same NF Set is selected.

For Direct Communication mode, the NF Service consumer may subscribe to status change notifications of NF instance from the NRF. If the NF Service consumer is notified by the NRF or detects by itself (e.g. request is not responded) that the NF producer instance is not available anymore, another available NF producer instance within the same NF Set is selected by the NF Service consumer.

For Indirect Communication mode, the SCP or NF Service consumer may subscribe to status change notifications of NF instance from the NRF and selects another NF producer instance within the same NF Set if the original NF producer instance serving the UE is not available anymore.

NOTE: It is up to the implementation on how the SCP knows a NF producer instance is not available anymore.

5.21.3.4 Reliability of NF Services

When multiple NF Service instances within a NF Service Set are exposed to the NF Service consumer or SCP and the failure of NF Service instance is detected or notified by the NRF, i.e. it is not available anymore, the NF Service consumer or SCP selects another NF Service instance of the same NF Service Set within the NF instance, if available. Otherwise the NF Service consumer or SCP selects a different NF instance within the same NF Set.

NOTE: The NF Producer instance can change the NF Service instance in the response to the service request.

When multiple NF Service instances within a NF Service Set are exposed to the NF Service consumer or SCP as a single NF Service, the reliability, i.e. the selection of an alternative NF Service instance is handled within the NF instance.

5.21.4 Network Function/NF Service Context Transfer

5.21.4.1 General

Network Function/NF Service Context Transfer Procedures allow transfer of Service Context of a NF/NF Service from a Source NF/NF Service Instance to the Target NF/NF Service Instance e.g. before the Source NF/NF Service can gracefully close its NF/NF Service. Service Context Transfer procedures are supported as specified in clause 4.26 of TS 23.502 [3].

Source NF / OA&M system determines when Source NF needs to transfer UE contexts to an NF in another NF set. Source NF should initiate this only for UE(s) that are not active in order to limit and avoid impacting services offered to corresponding UE(s).