Content for TS 23.527 Word version: 18.4.0
6.3 NF Service Producer Restart Detection using direct signalling between NFs
6.3.1 General
6.3.2 NF Service Producer Restart
6.4 NF Service Consumer Restart Detection using direct signalling between NFs
6.4.1 General
6.4.2 NF Service Consumer Restart
6.5 NF Service Producer Instance Reselection
6.5.1 General
6.5.2 NF Service Instance Reselection when a (Routing) Binding Indication is available
6.5.3 NF Service Instance Reselection when a (Routing) Binding Indication is not available
...
...
6.3 NF Service Producer Restart Detection using direct signalling between NFs p. 23
6.3.1 General p. 23
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 p. 24
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.
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.
6.4 NF Service Consumer Restart Detection using direct signalling between NFs p. 25
6.4.1 General p. 25
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.
6.4.2 NF Service Consumer Restart p. 25
Figure 6.4.2-1 describes a NF Service Consumer restart scenario and how the NF Service Producer can detect this restart.
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.
6.5 NF Service Producer Instance Reselection p. 27
6.5.1 General |R16| p. 27
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. 27
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.
6.5.3 NF Service Instance Reselection when a (Routing) Binding Indication is not available |R16| p. 27
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.
- 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).
