6 Restoration Procedures related to Service-Based Interfaces

23.5273GPP5G SystemRelease 18Restoration proceduresTS

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

6.1 General

A NF may detect a failure or a restart of a peer NF or NF service using the NRF as specified in clause 6.2.

A NF may also detect a restart of a peer NF or NF service by receiving recovery time information in signalling exchanged with that peer NF or NF service.

When NF (Service) Set is deployed in the network as specified in clauses 5.21.3 and 6.3.1.0 of 3GPP TS 23.501[9], an NF Service Producer in a NF (Service) Set creates resource contexts and the context data is shared by all the NF (Service) instances pertaining to the same NF (Service) set, i.e. the resource context is bound to the NF (Service) Set. So, requests targeting the resource may be served by any NF (Service) Instance within the NF (Service) set, unless the shared contexts are lost (which is further referenced in this specification as "the NF (Service) Set has failed or restarted").

In order to enable peer NFs to detect the loss of the resource contexts, i.e. the "restart of the NF (Service) Set or NF instance", and trigger appropriate restoration procedures, the NF Service Producer may provide a recovery timestamp associated to the highest resiliency level that it supports for the resource context, i.e. the binding entity with which the context data is shared (bound). Binding entities are sorted from the highest to the lowest resilience levels as follows: an NF Set, NF Instance, NF service set or NF service instance. The NF Service Producer may signal this recovery timestamp and its corresponding binding entity, in direct HTTP signalling or via the NRF.

NOTE 1: Signalling the recovery timestamp of an NF (Service) Set or an NF (Service) Instance via the NF profile in the NRF does not require the support of Binding Indication.

NOTE 2: Signalling the recovery timestamp and its corresponding binding entity in direct HTTP signalling requires the use of a Binding Indication (i.e. "3gpp-sbi-binding" HTTP header, see clause 5.2.3.2.6 of 3GPP TS 29.500 [10]). When multiple binding entities are present in a Binding Indication, the binding entity with the highest resiliency level is associated with the recovery timestamp; otherwise (if there is only one binding entity in a Binding Indication), the recovery timestamp is associated with that binding entity in the Binding Indication.

A NF may prioritize the contexts to restore based on operator’s policy.

A NF should control/regulate the load induced on a peer NF or NF service when performing the restoration procedures.

The restoration procedures initiated when detecting a failure or a restart are not specified in this release.

6.2 NF (NF Service) Failure and Restart Detection using the NRF

6.2.1 General

This clause describes optional procedures that may be supported by NFs to detect the failure or restart of a NF or a NF service using the NRF.

6.2.2 NF (NF Service) Failure

Figure 6.2.2-1 describes a NF failure scenario and how other NFs can be notified of this failure.

Figure 6.2.2-1: NF Failure Detection and Notification

1. NF A subscribes to the NRF to receive notifications of changes of the NF B Profile, as specified in 3GPP TS 29.510 [7].

2. A NF failure occurs at NF B.

3. The NRF detects that NF B is no longer operative using the NF Heart-Beat procedure as specified in clause 5.2.2.3.2 of 3GPP TS 29.510 [7]. The NRF changes the NFStatus of NF B to SUSPENDED.

4. The NRF notifies NFs having subscribed to receive notifications of changes of the NF B Profile that the NFStatus of NF B is changed to SUSPENDED.

5. NF A may trigger appropriate restoration or clean-up actions, if it cannot communicate with NF B.

Figure 6.2.2-2 describes a NF service failure scenario and how other NFs can be notified of this failure.

Figure 6.2.2-2: NF Service Failure Detection and Notification

1. NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.

2. A NF Service failure occurs at NF B. NF B (other than the failed NF Service) is still operative.

3. NF B (or OAM) updates its NF Profile in the NRF, by setting the NFServiceStatus of the failed NF Service to SUSPENDED.

4. The NRF notifies NFs having subscribed to receive notifications of changes of NF B Profile that the NF Service status of the failed NF service of NF B is changed to SUSPENDED.

5. NF A triggers appropriate restoration or clean-up actions, if it cannot communicate with the NF B service.

6.2.3 NF (NF Service) Restart

Figure 6.2.3-1 describes a NF restart scenario and how other NFs can be notified of this restart.

Figure 6.2.3-1: NF Restart Detection and Notification

1. NF B (or OAM) registers NF B Profile to the NRF. The NF B Profile may include the recoveryTime attribute, if a restart of NF B results in losing contexts.

NF B Profile may include the recoveryTime attribute of the NF Set to which NF B pertains to, when NF B pertains to an NF Set, i.e. when the resource contexts created in the NF B is bound to the NF Set, i.e. resource contexts are accessible by all NF Instances within the NF Set.NOTE 1: The restart of an NF Set indicates that resource contexts bound to the NF Set (i.e. that are accessible by all NF Instances within the NF Set) have been lost.2 NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.

3. NF B restarts.

4. If contexts are lost during the restart, NF B (or OAM) updates the recoveryTime in its NF Profile in the NRF.

NF B Profile shall update the recoveryTime attribute of the NF Set to which NF B pertains to, if the whole NF Set has restarted and NF B has registered the recoveryTime for that NF Set.

5. The NRF notifies NFs having subscribed to receive notifications of changes of NF B Profile about the updated recoveryTime of the NF B Profile or updated recoveryTime of NF Set to which the NF B pertains to.

6. NF A may consider that all the resources created in the NF B before the NF B recovery time as have been lost. NF A triggers then appropriate restoration or clean-up actions.

Figure 6.2.3-2 describes a NF service restart scenario and how other NFs can be notified of this restart.

Figure 6.2.3-2: NF Service Restart Detection and Notification

1. NF B (or OAM) registers its NF B Profile (and its services) to the NRF. The NF B Profile may include the recoveryTime attribute for the NF Services it supports, if a restart of a NF B service results in losing contexts. The NF B Profile may include the recoveryTime attribute of either the NF Service Set, NF Instance or NF Set to which the NF Service Instance pertains to, when the resource context for the NF Service created in NF B is bound to NF Service Set, or NF Instance, or NF Set respectively, i.e. accessible by all NF Service Instances within an NF Service Set, NF Instance or NF Set respectively (see clause 6.3.1.0 of 3GPP TS 23.501 [9]).

NOTE 2: The restart of an NF Service Set indicates that the resource contexts bound to the NF Service Set (i.e. accessible by all NF Service Instances within the NF Service Set) have been lost.

2 NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.

3. A NF B service restarts.

4. If contexts are lost during the service restart, NF B (or OAM) updates the recoveryTime of the corresponding NF Service in the NRF. NF B (or OAM) shall update the recoveryTime attribute of the NF Service Set, NF Instance or NF Set to which the NF Service Instance pertains to, when the whole NF Service Set, NF Instance or NF Set has restarted respectively.

5. The NRF notifies NFs having subscribed to receive notifications of changes of the NF B Profile about the updated recoveryTime of the NF B Service or updated recoveryTime of the NF B Service Set, NF Instance or NF Set.

6. NF A may consider that all the resources created in the NF B service before the NF B service recovery time as have been lost. NF A triggers then appropriate restoration or clean-up actions.

6.3 NF Service Producer Restart Detection using direct signalling between NFs

6.3.1 General

This clause describes an optional procedure that may be supported by NFs to detect the restart of a peer NF service using direct signalling between NFs.

6.3.2 NF Service Producer Restart

Figure 6.3.2-1 describes a NF Service restart scenario of an NF Service Producer and how the NF Service Consumer can detect this restart.

Figure 6.3.2-1: NF Service Producer Restart Detection

1. NF A (NF Service Consumer) requests to create a resource in the NF B (NF Service Producer).

2. If the request is accepted, and if NF B implements the procedure specified in this clause, NF B shall return its NF B service instance ID in the response, and NF A shall associate the created resource with the NF B service instance if no Binding Indication is received from NF B.

In the response message, the NF B that supports this procedure may include the recovery timestamp in the Binding Indication (i.e. in the "3gpp-sbi-binding" HTTP header). An NF A that supports this procedure shall associate the created resource with the binding entity and the recovery timestamp as specified in clause 6.1.

3. A NF service produced by NF B restarts, e.g. an NF Service Instance in NF B, an NF Service Set in NF B, NF B or the NF Set to which NF B pertains has restarted.

4-5. NF B Service Producer may include its last recovery timestamp in responses it sends to the NF A Service Consumer, if the restart of the NF service resulted in losing contexts and e.g. if the NF service has restarted recently.

6. NF A may consider that all the resource contexts are lost, which were created in the NF B service instance before the updated recovery timestamp, if the recovery timestamp was associated to the NF B service instance.

If the recovery timestamp was associated to an NF Service Set, NF Instance or NF Set, NF A may consider that all the resource contexts are lost, which were created in these binding entities before the recovery, as indicated in the received recovery timestamp.

NF A may trigger then appropriate restoration or clean-up actions.

NOTE 1: The recovery time signalled in this procedure is equivalent to the recovery time of the NF service of Figure 6.2.3-2. For an entire NF restart scenario, this procedure can be applied by each NF service instance of the NF.

NOTE 2: This procedure enables the detection of a restart of a peer NF service when sending signalling towards that NF Service. It can fasten the detection of a restart of a peer NF service when frequent signalling occurs towards that peer NF Service.

NOTE 3: In some use cases, NF A is not aware of the NF B Service Instance ID when creating the resource, e.g. a V-SMF just receives the H-SMF URI from the AMF to create a PDU session resource in H-SMF. Besides, for APIs supporting distributed collections (e.g. SMF), the response can contain a different Service Instance ID (that need not be registered in the NRF) than the one selected by NF A for sending the request.

6.4 NF Service Consumer Restart Detection using direct signalling between NFs

6.4.1 General

This clause describes an optional procedure that may be supported by NFs to detect the restart of a peer NF Service Consumer by NF Service Producer using direct signalling between NFs.

When NF (Service) Set is deployed in the network as specified in clause 5.21.3 and 6.3.1.0 of 3GPP TS 23.501[9], an NF Service Consumer in an NF (Service) Set may create a session context for callback (corresponding to the resource context in the NF Service Producer) when invoking a NF Service and the session context data is shared by all NF (Service) instances pertaining to the same NF (Service) set, i.e. the context is bound to the NF (Service) Set. So, any NF (service) instance within the NF (service) set is able to receive notifications or callback request from the NF Service Producer, unless the shared contexts are lost (which is further referenced in this specification as "the NF (Service) Set has failed or restarted").

In order to enable peer NF Service Producers to detect the loss of the session contexts in the NF Service Consumer, i.e. the "restart of the NF (Service) Set or NF instance", and trigger appropriate restoration procedures, the NF Service Consumer may provide a recovery timestamp associated to the highest resiliency level it supports for the context, i.e. the binding entitiy with which the context data is shared (bound). Binding entities are sorted from the highest to the lowest resilience levels as follows: an NF Set, NF Instance, NF service set or NF service instance. The NF Service Consumer may signal this recovery timestamp in direct HTTP signalling, using a Binding Indication.

6.4.2 NF Service Consumer Restart

Figure 6.4.2-1 describes a NF Service Consumer restart scenario and how the NF Service Producer can detect this restart.

Figure 6.4.2-1: NF Service Consumer Restart Detection

1. NF A (NF Service Consumer) requests to create a resource in the NF B (NF Service Producer). If NF A implements the procedure specified in this clause, it shall include a Consumer Id together with the last recovery timestamp in the request. The Consumer Id shall be identical for all service requests triggered by the NF service consumer for that service and shall be globally unique (e.g. using UUID).

If NF A includes Binding Indication(s) (i.e. in the "3gpp-sbi-binding" HTTP header) in the request, NF A may include the recovery timestamp for the higher level binding entity indicated in the Binding Indication with the scope set to "callback" (see clause 5.2.3.2.6 of 3GPP TS 29.500 [10]).

2. If resource creation is successful, NF B as service producer shall store the received Consumer Id and recovery timestamp and associate the created resource with it.

An NF B that supports this procedure shall associate the callback resource and the recovery timestamp to the higher level binding entity indicated in the received Binding Indication (with the scope set to "callback").

If the Service Request contains Binding Indication(s) with the scope set to "other service", the NF B may use the binding information and associated recovery timestamp to detect whether resources that NF B has created in NF A have been lost, according to the principles specified in clause 6.3.2.

3. The NF service consumer in NF A restarts.

4. The NF service consumer in NF A shall include its last recovery timestamp together with the Consumer Id in the request when invoking service provided by NF B. The same Consumer Id shall be used after restarting.

If NF A includes Binding Indication(s) in the request, NF A shall include the updated recovery timestamp for the higher level binding entity to which the callback resource context is bound in the Binding Indication with the scope set to "callback".

5. NF B as NF service producer may compare the received recovery timestamp with previous stored and detect the NF service consumer has restarted, if the received recovery timestamp is newer than the previous one.

The consumer Id for the resource or the Binding Indication with the scope set to "callback" may be updated if another service consumer took over the usage of the resource. e.g. if a new consumer Id is received during a service operation of a resource. NF B as NF service producer shall consider the service consumer handling the resource has changed and associate the resource with the new consumer Id or according to the new Binding Indication and with the corresponding recovery timestamp.

6. NF B may consider that the contexts in NF A corresponding to all the resources associated with the consumer Id or all resources bound to the entity (with which the recovery timestamp is associated) and the previous stored recovery time stamp have been lost. NF B triggers then appropriate restoration or clean-up actions.

NOTE 1: This procedure is only supported by NF services that support signalling the recovery timestamp attribute.

NOTE 2: This procedure can be used when the resource is exclusively used by an NF service consumer.

NOTE 3: This procedure enables the detection of a restart of a peer NF service consumer when sending signalling towards that NF service producer. It is helpful if the NF A as a pure service consumer without registration of its profile in NRF. If NF A does have a profile registered in NRF, it also can fasten the detection of a restart of a peer NF service consumer when frequent signalling occurs towards that peer NF Service.

6.5 NF Service Producer Instance Reselection

6.5.1 General

An NF Instance of an NF Service Producer may expose several service instances of the same NF Service (e.g., an UDM instance may expose several service instances of the "Nudm_SubscriberDataManagement" service).

An NF Service Consumer may discover, while an SCP shall be able to discover, via NRF Nnrf_NFDiscovery service, all available NF Service Instances for a given NF Service and select one of them.

6.5.2 NF Service Instance Reselection when a (Routing) Binding Indication is available

When using the Binding procedures specified in clause 6.12 of 3GPP TS 29.500 [10], Binding Indications and Routing Binding Indications include the Binding level and one or more Binding entity IDs representing all NF service instances that are capable to serve service requests targeting the resource, i.e. that share the same resource contexts.

When a Binding Indication or a Routing Binding Indication is available for a target resource, NF Service Instance selection and re-selection shall be supported as specified in clause 6.12 of 3GPP TS 29.500 [10].

6.5.3 NF Service Instance Reselection when a (Routing) Binding Indication is not available

If a formerly selected NF Service Instance becomes unavailable, the NF Service Consumer may, while the SCP shall be able to select a different instance of a same NF Service in:

– the same NF Instance, if the NF Instance indicates in its NF Profile that it supports the capability to persist their resources in shared storage inside the NF Instance, and if the new NF Service Instance offers the same major service version; or

– the same NF Set or NF Service Set, if the NF (service) instance indicates in its NF Profile that it belongs to an NF Set or an NF Service Set.

If so, the NF Service Consumer may, while the SCP shall be able to invoke service operations in the newly selected NF Service Instance by means of replacing the addressing parameters with those of the new service instance, and the new NF Service Instance in the NF Service Producer shall produce the same result as if the service request would have been successfully delivered to the former NF Service Instance.

NOTE 1: In some scenarios, the newly selected NF Service Producer might not produce the exact same result as the former NF Service Producer would have produced for the service request, e.g. when the former NF Service Producer failed before it could update a change in the resource context to the USDF.

For indirect communication, if the NF service consumer delegates target NF service instance reselection to the SCP (when the target NF service instance is not reachable), the NF Service Consumer shall include at least one of the 3gpp-Sbi-Discovery-target-nf-instance-id, 3gpp-Sbi-Discovery-target-nf-set-id, 3gpp-Sbi-Discovery-target-nf-service-set-id, 3gpp-Sbi-Discovery-amf-region-id and 3gpp-Sbi-Discovery-amf-set-id headers, and it should also include at least the following information in its request to the SCP:

– the target NF type, the service name, and the requested S-NSSAI in the corresponding "3gpp-Sbi-Discovery-*" request header(s) (see clause 6.10.3.2 of 3GPP TS 29.500 [10]).

NOTE 2: This is to allow the SCP to discover and reselect a target NF service instance from the target NF instance or target NF (service) set for the corresponding service request and supporting the requested S-NSSAI, e.g. when the NF service producer supports different NF service instances serving different network slices. Likewise, other "3gpp-Sbi-Discovery-*" request header(s), e.g. target-plmn-list, can also be included for the same purpose.

NOTE 3: The inclusion of the 3gpp-Sbi-Discovery-target-nf-instance-id in an HTTP request enables the SCP to discover the profile of the target NF instance and to possibly reselect a different target NF service instance from the same NF instance or from a different NF instance in the same set.

If so, the SCP shall use the information provided by the NF service consumer to perform a NF service discovery procedure and reselect a NF (service) producer instance as specified in the preceding bullets, if possible and if the target NF Service Instance indicated in the "3gpp-Sbi-Target-apiRoot" header or target URI is not reachable.

NOTE 4: This reselection mechanism is applicable only for the request/response service semantics, but not for notify/callback requests.

If the NF instance does not indicate in its NF Profile the support of the capability to persist their resources in shared storage across service instances of the same NF Service, inside the NF Instance, and if it does not indicate in its NF Profile that it belongs to an NF Set or an NF Service Set, the NF Service Consumer or SCP may still reselect any of the exposed service instances, but it shall not assume that the resources created in the former service instance are still valid.

6.6 NF Service Consumer Instance Reselection

6.6.1 General

When NF (Service) Set is deployed in the network as specified in clauses 5.21.3 and 6.3.1.0 of 3GPP TS 23.501[9], an NF Service Consumer in an NF (Service) Set may create a session context for callback (corresponding to the resource context in the NF Service Producer) when invoking a NF Service and the session context data is shared by all NF (Service) instances pertaining to the same NF (Service) set, i.e. the context is bound to the NF (Service) Set.

An NF Service Producer may, while the SCP shall be able to discover, via NRF Nnrf_NFDiscovery service, all available NF (Service) Instances within the NF (service) set that are capable to receive the notifications or callback requests and select one of them.

NOTE: When an NF service consumer changes, if the new NF service consumer does not support handling the notification or callback requests as described above, the new NF service consumer updates NF service producers with new URI as specified in clause 6.5.3.2 of 3GPP TS 29.500 [10].

6.6.2 NF Service Consumer Instance Reselection when a (Routing) Binding Indication is available

When using the Binding procedures specified in clause 6.12 of 3GPP TS 29.500 [10], Binding Indications and Routing Binding Indications include the Binding level and one or more Binding entity IDs representing all NF service consumer instances that are capable to receive the notifications or callback requests targeting the session context for callback (corresponding to the resource context in the NF Service Producer). See also clause 6.5.3.2 of 3GPP TS 29.500 [10].

When a Binding Indication or a Routing Binding Indication is available for a target context, NF Service Consumer selection and re-selection shall be supported as specified in clause 6.12 of 3GPP TS 29.500 [10].

6.6.3 NF Service Consumer Instance Reselection when a (Routing) Binding Indication is not available

When the target NF Service Consumer becomes unavailable, the NF Service Producer may, while the SCP shall be able to select a different instance of the Service Consumer which is capable to receive the notifications or callback requests targeting the session context for callback (corresponding to the resource context in the NF Service Producer) in:

– the same consumer NF instance, using an alternate endpoint address information if any is configured at the NF instance level, or at the NF service instance level when the name of the NF service to which these notifications are to be sent is known and the (consumer) NF instance registered in its NF Profile that it is capable to persist its resources in shared storage across NF service instances of the same NF Service;

– the same NF (service) Set or a backup NF Service Consumer if applicable.

NOTE 1: When binding procedures are not supported, the NF Service Consumer can provide in certain APIs the name of the NF service to which these notifications are to be sent. This service can be one of the service produced by the NF (if this NF Service Consumer can also serve as a NF Service Producer) and registered in the NRF, or a custom service registered in the NRF for the purpose of receiving these notifications). See clause 6.5.2.2 of 3GPP TS 29.500 [10].

NOTE 2: When the AMF serves as a NF Service Consumer, it can indicate to the NF Service Producer its backup AMF. See clause 5.21.2 of 3GPP TS 23.501 [9].

NOTE 3: NF Service Consumer Reselection when a (Routing) Binding Indication is not available is only supported when the NF Service Producer has the target NF Service Consumer information available, e.g. for APIs where the NF Service Consumer can communicate its NF Instance Id to the NF Service Producer in the service request message.

If so, the NF Service Producer may, while the SCP shall be able to send the notification or callback request to the newly selected NF Service Consumer Instance by means of replacing the addressing parameters with those of the newly selected instance.

For indirect communication, if the NF service producer delegates target NF consumer instance reselection to the SCP (when the target NF consumer instance is not reachable), the NF service producer should include the target NF type (i.e. the type of the NF service consumer) in the corresponding "3gpp-Sbi-Discovery-*" request header, and may also include other 3gpp-Sbi-Discovery-*" headers in a notification or callback request, , to enable the SCP to reselect a different NF service consumer instance as specified in the preceding bullets, if possible and if the NF service consumer instance indicated in the "3gpp-Sbi-Target-apiRoot" header or target URI is not reachable.

6.7 Restoration of Profiles related to UDR

6.7.1 General

This clause describes an optional procedure that may be supported by UDR, UDR consumers (i.e. UDM, PCF, and NEF), and UDM consumers (e.g. AMF, SMF, SMSF, AUSF, NEF…) to re-synchronize profiles in UDR to those in UDR consumers and UDM consumers. When UDR detects corruption, loss, or inconsistency in temporary data stored in UDR, the UDR indicates it to its consumers. UDR should also send notifications to its consumers upon restart based on the deployment policy. If the UDR consumer is UDM, the UDM indicates it to its consumers. Then, those consumers initiate necessary procedures directly or via UDM towards UDR, so that related profiles are re-synchronized and adverse impacts on operator’s service can be minimized.

NOTE 1: Notification can also be sent on other occasions than data corruption based on local policy.

Temporary data stored in UDR subject to restoration may be identified within the notification sent to UDR consumers and UDM consumers either by:

– Reset-ID (plus PLMN ID of the UDR): Reset-IDs of temporary data associated to SUPI ranges or GPSI ranges are assigned by UDR in an implementation specific way; e.g. a Reset-ID may identify a hardware resource and may contain a reset-counter. The Reset-ID is provided to UDR consumers and UDM consumers in the response of a request that has created temporary data (i.e. a resource) in UDR.

– SUPI or GPSI ranges.

– DNNs/S-NSSAIs (plus PLMN ID of the UDR).

– UDR or UDM Group ID (plus PLMN ID of the UDR).

– PLMN ID of the UDR.

The identifiers used in notifications are optional to be included when sent by UDR or by UDR consumers, but it is recommended that the notification includes some type of identifier to narrow down as much as possible the set of affected profiles. In particular, the notification to UDM consumers in PLMNs different from the PLMN of the UDM shall contain at least one of the identifiers. For the receivers of the notifications, all identifiers shall be supported.

If multiple identifiers are included in the notification, the set of affected profiles shall consider as a logical "AND" between all the included identifiers.

The notification sent to UDR consumers and UDM consumers also includes the following time values:

– lastReplicationTime: The last time when UDR replicated the temporary data identified to be potentially lost or corrupted, i.e. before the situation causing the potential data inconsistency occurred.

– recoveryTime: The time when UDR started working properly after the situation causing the potential data inconsistency occurred.

Resources related to temporary data stored in UDR are associated in the corresponding user profile stored at UDR consumers or UDM consumers with a timestamp of the time they were created or last modified; i.e. lastSynchronizationTime. Temporary data in UDR created or updated between the lastReplicationTime and the recoveryTime may be inconsistent with profiles in UDR consumers and UDM consumers. In order to avoid inconsistency of time due to different timezones, lastReplicationTime, recoveryTime and lastSynchronizationTime shall be identified using UTC.

UDR consumers and UDM consumers define callbackUri for data restoration in their NF profile. This is an endpoint to receive notification when potential UDR data inconsistency occurs. In addition, UDR consumers may inform their identity to UDR. Additionally, UDM consumers may inform their dataRestorationCallbackUri to UDM during registration in UDM (e.g. for AMF, SMF, SMSF); if so, such callback URI shall be the same as the URI registered by the UDM consumer in its NF Profile in NRF, and it shall be a same URI for the entire consumer’s NF Instance (i.e., the UDM consumer shall not indicate different callback URIs per each UE registration).

When the UDR detects a potential data inconsistency of temporary data, the UDR notifies the UDR consumers of the potential data inconsistency event using the callbackUri of the UDR consumer.

The UDM may notify UDM consumers within its PLMN using the callbackUri included in the NF profile of the UDM consumer in NRF. This is, a UDM that receives a notification from UDR can discover the callbackURI of e.g. AMFs, SMFs, SMSFs or AUSFs within its PLMN and forward the notification to all of them. The UDM may also notify UDM consumers using the callbackUri if provided by UDM consumers during its registration in UDM based on local configuration.

NOTE 2: The option for UDM consumers to provide its dataRestorationCallbackUri during registration in UDM, and such UDM using these callbackUris to send subsequent notifications, is particularly beneficial to support roaming users connecting via UDM consumers in PLMNs different from the PLMN of the UDM (e.g. AMF, SMSF, and SMF in Local Break Out scenarios), since it avoids the task for UDM to perform an inter-PLMN service discovery.

The notification to UDR consumers and UDM consumers includes optionally the identifier of the temporary data subject to restoration (e.g. Reset-IDs), the lastReplicationTime and the recoveryTime. The UDR consumer or UDM consumer may then initiate the restoration of the temporary data identified to be potentially lost or corrupted when the last synchronization time recorded at consumer falls between the lastReplicationTime and the recoveryTime as provided by the producer, i.e. UDR or UDM.

6.7.2 Procedure

Figure 6.7.2-1 describes the procedure for restoration of profiles related to UDR.

Figure 6.7.2-1: Restoration of Profiles related to UDR

0. UDR consumers and UDM consumers define callbackUri for data restoration in the NF profile registered in NRF.

1. UDR consumers store temporary data in UDR. The UDR consumers may set its identity in the request to UDR, when accessing it for the first time. The UDR stores the received identity and creates for the UDR consumer a subscription on notification for the potential UDR data inconsistency. The UDR may provide to the UDR consumer the Reset-ID if assigned by the UDR for the temporary data stored in UDR.

The UDM stores temporary data in UDR as requested by its consumers. UDM consumers may set dataRestorationCallbackUri in the request of their registration to UDM. In this case, the UDM stores the dataRestorationCallbackUri locally and creates for the UDM consumer a subscription on notification for the potential UDR data inconsistency. If received from UDR, the UDM also provides the Reset-ID assigned by the UDR to UDM consumers.

When an NF other than UDM creates or updates a resource directly or via UDM in UDR, the NF sets or stores lastSynchronizationTime in a relevant profile. If the NF receives a Reset-ID directly or via UDM from UDR, the NF stores it in the profile.

2. UDR detects corruption, loss, or inconsistency in temporary data caused due to certain scenarios (e.g. failure and restart of the UDR, or migration of the data from an old UDR to a new UDR).

NOTE 1: The UDR can recover consistency by different means, e.g. by reloading data from its back-up.

3. UDR queries NRF based on the identity stored in step 1 and discovers callbackUri for data restoration in UDR consumers’ NF profiles. If no UDR consumer impacted by the restoration event provided its identity in step 1, the UDR discovers via NRF the callbackUri of one suitable UDR consumer instance to send the notification to. The UDR sends Nudr_DR_Notification request to the callbackUri to notify potential UDR data inconsistency. The Nudr_DR_Notification request may contain temporary data identifier(s) (e.g. Reset-IDs) and an impacted period (i.e. lastReplicationTime and recoveryTime).

4. If UDR consumer is UDM, the UDM forwards the notification to UDM consumers. The UDM finds callbackUri for data restoration for UDM consumers within its PLMN in UDM consumers’ NF profiles through querying NRF. Optionally, the UDM may find callbackUri for data restoration for UDM consumers (especially UDM consumers outside its PLMN) if provided by the UDM consumer during UDM consumer registration in UDM and locally stored in UDM in step1.

5. When a UDR consumer other than UDM (e.g. PCF, NEF) or a UDM consumer (e.g. AMF, SMF, SMSF) finds that a stored profile is affected by the potential loss or corruption of data, and that the last synchronization time of the profile falls into the impacted period in the notification, then the NF judges that the profile requires re-synchronization.

UDR consumers other than UDM (e.g. PCF, NEF) initiates the re-synchronization of the impacted resources using Nudr_DataRepository service operations.

UDM consumers initiate the re-synchronization for each impacted UE using different service operations depending on the UDM consumer type. UDM consumers shall include a flag ("udrRestartInd") indicating that the request is due to a re-synchronization event.

– UDM consumers that register in UDM start re-synchronization by sending Nudm_UECM_Registration request for each impacted UE.

In order to prevent storing obsolete registration information for a given user coming from UDM consumers that trigger resynchronization for the same user, UDM consumers may include the stored last synchronization time within the re-synchronization request. The lastSynchronizationTime provided by the UDM consumer may be used in UDM to compare it with current data stored in UDR and ensure that the registration from the most recent UDM consumer is kept (see step 7). However, if the UDM consumer ensures that its resynchronization is the most recent, accurate and correct (e.g. if the AMF triggers resynchronization upon detection of UE activity), the UDM consumer shall not include the lastSynchronizationTime within the resynchronization request and the UDM stores the UDM consumer registration in the UDR without further processing.

– UDM consumers that subscribe to notification of subscription data changes in UDM start re-synchronization of these subscriptions in UDM by sending Nudm_SDM_Subscribe request for each impacted UE and subscription.

– AUSF starts re-synchronization by sending Nudm_UEAuthentication_ResultConfirmation request containing the stored last synchronization timestamp of the authentication for each impacted UE.

– NEF starts re-synchronization of the subscription to exposure events in UDM by sending Nudm_EE_ModifySubscription request for each impacted UE and subscribed event.

6. The UDR consumers and UDM consumers locally adjusts invocation timing of each of those procedures, in order not to cause congestion in the system. The NF invokes necessary procedures.

UDM consumers select a UDM instance to send the re-synchronization signalling as defined in 3GPP TS 23.501 [9]. This is, the UDM consumer may not send the re-synchronization signalling to the UDM instance from which the UDM consumer received the notification.

7. If UDM receives Nudm_UECM_Registration request containing the "udrRestartInd" flag, the UDM overwrites the related profile in the UDR, or creates it if not available. If the registration request includes a lastSynchronizationTime, the related profile in UDR is overwritten only if the lastSynchronization time received from the UDM consumer is not older than the registration time stored in UDR before resynchronization. In this case, if the UDM replaces or creates the related profile in UDR, the UDM sets the registration time to the current time.

If UDM receives Nudm_SDM_Subscribe request containing the "udrRestartInd" flag the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.

If UDM receives Nudm_UEAuthentication_ResultConfirmation request containing the "udrRestartInd" flag, the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.

If UDM receives Nudm_EE_ModifySubscription request containing the "udrRestartInd" flag, the UDM sends a corresponding request to UDR, the UDR overwrites the related profile in the UDR or creates it if not available in UDR.

6.8 Restoration Procedures for Home Routed PDU Sessions or PDU sessions with an I-SMF

6.8.1 General

This clause specifies requirements in the AMF, the V/I-SMF and the (H-)SMF to restore Home Routed PDU Sessions or PDU sessions with an I-SMF.

During a PDU session establishment and update procedure, the V/I-SMF or the (H-)SMF shall:

– set the "Peer NF SET based Reselection"(PSETR) feature bit in the SupportedFeatures attribute if it supports the (re)selection of an alternative peer SMF using the binding indication of the resource/session contexts or based on the NF profile of the peer SMF;

– set the "Deployed Local SMF Set" (DLSET) feature bit in the SupportedFeatures attribute if the PDU session resource is not bound exclusively to the specific V/I-SMF or (H-)SMF NF service instance, i.e. if there is at least one alternative SMF service instance (in the same or a different SMF instance) that can take it over if the current serving SMF service instance becomes no longer operational (e.g. fails).

NOTE 1: A SMF can set the DLSET flag to "1" if it indicates in its NF Profile that it supports the capability to persist its resources in shared storage inside the NF Instance, i.e. if another SMF service instance with the SMF instance can take over the resource context even when NF (service) set is not deployed locally.

In the service request or response message towards the (new) AMF, the V/I-SMF shall set the "DLSET" feature bit if the PDU session resource can be taken over by an alternative V-SMF Service Instance. The V/I-SMF shall set the "anchorSmfPsetrSupportInd" attribute to "true" in the Update SM Context Response message towards the new AMF if the (H-)SMF supports the "PSETR" feature.

NOTE 2: The AMF needs to know if the V/I-SMF supports the DLSET feature and if the (H-)SMF supports the PSETR to take proper restoration actions when there is a V/I-SMF failure. See clause 6.8.2. The AMF can alternatively learn whether the (H-)SMF supports the PSETR feature when doing the SMF discovery/selection during the PDU Session Establishment procedure.

NOTE 3: The V/I-SMF indicates more generally all the features it supports to the AMF in the service request/response, including also setting the "PSETR" feature bit if it is able to reselect an alternative (H-)SMF when it detects the peer (H-)SMF has failed, but the AMF is not required to use this indication.

The requirements specified in subsequent clauses shall also be applied for N16a reference point by replacing the V-SMF with I-SMF, and H-SMF with SMF.

6.8.2 V-SMF failure

When the H-SMF detects the failure of the V-SMF, it shall retrieve all PDU sessions associated with the failed V-SMF and perform the following procedure for those PDU sessions:

– if the H-SMF supports the PSETR feature:

– if the V-SMF supports the DLSET feature, the H-SMF shall keep the PDU session and should reselect an alternative V-SMF service instance, e.g. when it needs to send any request message to the V-SMF;

– if the V-SMF doesn’t support the DLSET feature, the H-SMF shall delete the affected PDU sessions locally.

– if the H-SMF does not support the PSETR feature:

– the H-SMF shall delete the affected PDU sessions.

When the AMF detects the failure of the V-SMF, it shall retrieve all PDU sessions associated with the failed V-SMF and perform the following procedure for those PDU sessions:

– if the H-SMF supports the PSETR feature and if the V-SMF supports the DLSET feature, the AMF shall keep the PDU session and should reselect an alternative V-SMF service instance, e.g. when it needs to send any request message to the V-SMF.

– if the H-SMF doesn’t support the PSETR feature while the V-SMF supports the DLSET feature, the AMF shall keep the PDU sessions, and may reselect an alternative V-SMF service instance to request the selected alternative V-SMF to delete the PDU session towards the UE and the UPF. The V-SMF may request the UE to reactivate the PDU session.

– for any other cases, the AMF may release the affected PDU session(s) locally and/or notify the UE about the release of the PDU session.

6.8.3 H-SMF failure

When the V-SMF detects the failure of the H-SMF, it shall retrieve all PDU sessions associated with the failed H-SMF and perform the following procedure for those PDU sessions:

– if the V-SMF does not support the PSETR feature, the V-SMF may release the affected PDU sessions towards the AMF and UE, and may request the UE to reactivate the PDU session;

– if the V-SMF supports the PSETR feature:

– if the H-SMF supports the DLSET feature, the V-SMF shall keep the PDU session and may reselect an alternative H-SMF service instance, e.g. when it needs to send any request message to the H-SMF;

– if the H-SMF doesn’t support the DLSET feature, the V-SMF may release the PDU session towards the AMF and UE, and the V-SMF may request UE to reactivate the PDU session.