Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.527  Word version:  18.3.0

Top   Top   Up   Prev   Next
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…

 

6  Restoration Procedures related to Service-Based Interfacesp. 19

6.1  Generalp. 19

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 TS 23.501, 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.
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
Up

6.2  NF (NF Service) Failure and Restart Detection using the NRFp. 19

6.2.1  Generalp. 19

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

Figure 6.2.2-1 describes a NF failure scenario and how other NFs can be notified of this failure.
Reproduction of 3GPP TS 23.527, Fig. 6.2.2-1: NF Failure Detection and Notification
Up
Step 1.
NF A subscribes to the NRF to receive notifications of changes of the NF B Profile, as specified in TS 29.510.
Step 2.
A NF failure occurs at NF B.
Step 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 TS 29.510. The NRF changes the NFStatus of NF B to SUSPENDED.
Step 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.
Step 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.
Reproduction of 3GPP TS 23.527, Fig. 6.2.2-2: NF Service Failure Detection and Notification
Up
Step 1.
NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.
Step 2.
A NF Service failure occurs at NF B. NF B (other than the failed NF Service) is still operative.
Step 3.
NF B (or OAM) updates its NF Profile in the NRF, by setting the NFServiceStatus of the failed NF Service to SUSPENDED.
Step 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.
Step 5.
NF A triggers appropriate restoration or clean-up actions, if it cannot communicate with the NF B service.
Up

6.2.3  NF (NF Service) Restartp. 21

Figure 6.2.3-1 describes a NF restart scenario and how other NFs can be notified of this restart.
Reproduction of 3GPP TS 23.527, Fig. 6.2.3-1: NF Restart Detection and Notification
Up
Step 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.
Step 2.
NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.
Step 3.
NF B restarts.
Step 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.
Step 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.
Step 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.
Reproduction of 3GPP TS 23.527, Fig. 6.2.3-2: NF Service Restart Detection and Notification
Up
Step 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 TS 23.501).
Step 2.
NF A subscribes to the NRF to receive notifications of changes of the NF B Profile.
Step 3.
A NF B service restarts.
Step 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.
Step 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.
Step 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.
Up

Up   Top   ToC