Content for TS 23.527 Word version: 19.0.0

1… 4… 4.4… 4.5… 4.7… 5… 6… 6.3… 6.6… 7… 8… 8.3… 8.3.2.4 8.3.3… 8.4… 9…

6.6 NF Service Consumer Instance Reselection 6.6.1 General 6.6.2 NF Service Consumer Instance Reselection when a (Routing) Binding Indication is available 6.6.3 NF Service Consumer Instance Reselection when a (Routing) Binding Indication is not available 6.7 Restoration of Profiles related to UDR 6.7.1 General 6.7.2 Procedure 6.7.3 UDR Restoration during Subscriber Data Migration 6.8 Restoration Procedures for Home Routed PDU Sessions or PDU sessions with an I-SMF 6.8.1 General 6.8.2 V-SMF failure 6.8.3 H-SMF failure
...

6.6 NF Service Consumer Instance Reselection |R16| p. 29

6.6.1 General p. 29

When NF (Service) Set is deployed in the network as specified in clauses 5.21.3 and 6.3.1.0 of TS 23.501, 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.

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

When using the Binding procedures specified in clause 6.12 of TS 29.500, 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 TS 29.500.

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 TS 29.500.

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

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.

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. If the Callback URI included a prefix it shall be removed from the notification URI when using an alternate Consumer NF Service Instance and the callback URI prefix of the new Consumer NF Service Instance (if any) shall be added.

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. If the Callback URI included a prefix, the NF service producer should also include the callback URI Prefix in the 3gpp-Sbi-Request-Info header.

6.7 Restoration of Profiles related to UDR |R17| p. 30

6.7.1 General p. 30

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.

This procedure may also be used for Subscriber Data Migration, which is the process to move, in an orderly and controlled manner, temporary subscription data (context data) managed by an origin UDR to a target UDR system, usually as a result of the migration of static (provisioned) subscriber data between those UDR systems. This case is described in clause 6.7.3.

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. In the case of subscriber data migration procedure, this value indicates the time when a UDR started subscriber data migration.
recoveryTime: The time when UDR started working properly after the situation causing the potential data inconsistency occurred. In the case of subscriber data migration procedure, this value indicates the time when traffic switch was enforced for a subscriber data migration procedure (e.g. the NFProfile update into NRF).

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.

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 p. 32

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

Reproduction of 3GPP TS 23.527, Fig. 6.7.2-1: Restoration of Profiles related to UDR

Figure 6.7.2-1: Restoration of Profiles related to UDR

Step 0.

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

Step 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.

Step 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).

Step 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).

Step 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.

Step 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.

Step 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 TS 23.501. This is, the UDM consumer may not send the re-synchronization signalling to the UDM instance from which the UDM consumer received the notification.

Step 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.7.3 UDR Restoration during Subscriber Data Migration |R19| p. 34

During operation of a PLMN, it is a common task to have to re-allocate subscriber's data records across subscriber servers/databases, due to multiple reasons such as, e.g., subscriber re-distribution, network re-dimensioning / scaling-out, replacement / swap of legacy databases (e.g. 4G UDC systems), etc.

The migration of the temporary data (context data) to the target UDR system may be realized by triggering the restoration of profiles related to UDR.

Additionally, network traffic shall be properly routed to the target UDR handling the new subscribers, affecting in many cases the traffic from 5GC to UDR consumers, i.e. UDM/PCF. For example, when subscribers are re-allocated to a new UDR group Id and also to a new UDM/PCF group Id, UDM/PCF consumers shall switch traffic related to the migrated subscribers to UDM/PCF instances in the new UDM/PCF group Id. In those cases, UDR rediscovery and/or UDM/PCF rediscovery is required to guarantee proper traffic routing.

The procedures followed to support subscriber data migration includes both traffic switch and recovery of temporary data in the target UDR (data re-synchronization). These procedures are initiated via OAM once the network has been properly configured, e.g. once static data has been provisioned in the target UDR for the migrated subscribers and other network functions (e.g. NRF and UDR supporting the NF Group ID mapping service), have been configured according to the new subscriber distribution.

Depending on the network deployment, data re-synchronization, traffic switch with rediscovery or both may be required for the data migration service. For example, in case UDM hides UDR network topology, traffic switch is not necessary for the UDM consumers, or in case temporary data is recovered from origin UDR but subscribers are distributed to a new UDM/UDR/PCF group, traffic switch with rediscovery without data re-synchronization shall be requested to UDM consumers. In case both are required, UDM/PCF/UDR consumers shall execute the traffic switch before the re-synchronization of the impacted resources is initiated.

For data migration, the restoration procedures described in Figure 6.7.2-1 are used with the following adaptations. The notification to UDR consumers and UDM/PCF consumers may specifically include:

SUPI or GPSI ranges and PLMNId of the UDR: to identify the migrated subscribers
NF Re-discovery indication: to indicate traffic switch with NF rediscovery is required due to subscriber reallocation in a different NF group Id.
No resynchronization required: to indicate temporary data does not need to be restored in UDR after subscriber reallocation in a different NF group Id

When UDM/PCF/UDR consumers receive a NF rediscovery indication, it means the relationship between the migrated User and UDM/PCF/UDR GroupId has changed, so UDM/PCF/UDR consumers shall use the user identity to discover and select UDM/PCF/UDR instances serving the affected users in the new UDM/PCF/UDR Group Id, discarding the UDM/PCF/UDR Group Id previously available in the UE context, if any. AMF may additionally update the UDM/PCF group Id information in other NFs in case that information is changed in the UE context as a result of the new UDM/PCF selection.

6.8 Restoration Procedures for Home Routed PDU Sessions or PDU sessions with an I-SMF |R16| p. 35

6.8.1 General p. 35

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).

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.

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 p. 35

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 p. 36

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.