Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.527  Word version:  17.4.1

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.6…   7…   8…   8.3…   8.3.2.4   8.3.3…

 

6  Restoration Procedures related to Service-Based Interfacesp. 17

6.1  Generalp. 17

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

6.2.1  Generalp. 17

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

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

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

6.3  NF Service Producer Restart Detection using direct signalling between NFsp. 21

6.3.1  Generalp. 21

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 Restartp. 22

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.
Reproduction of 3GPP TS 23.527, Fig. 6.3.2-1: NF Service Producer Restart Detection
Up
Step 1.
NF A (NF Service Consumer) requests to create a resource in the NF B (NF Service Producer).
Step 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.
Step 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.
Step 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.
Step 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.
Up

6.4  NF Service Consumer Restart Detection using direct signalling between NFsp. 23

6.4.1  Generalp. 23

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

6.4.2  NF Service Consumer Restartp. 23

Figure 6.4.2-1 describes a NF Service Consumer restart scenario and how the NF Service Producer can detect this restart.
Reproduction of 3GPP TS 23.527, Fig. 6.4.2-1: NF Service Consumer Restart Detection
Up
Step 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 TS 29.500).
Step 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.
Step 3.
The NF service consumer in NF A restarts.
Step 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".
Step 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.
Step 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.
Up

6.5  NF Service Producer Instance Reselectionp. 25

6.5.1  General |R16|p. 25

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 or SCP may 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 |R16|p. 25

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

6.5.3  NF Service Instance Reselection when a (Routing) Binding Indication is not available |R16|p. 25

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

Up   Top   ToC