Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 29.500  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3.2…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.10.12…   6.11…   A   B   C   D… 
6.5 Support of Stateless NFs  6.5.1 General  6.5.2 Stateless AMFs  6.5.2.1 General  6.5.2.2 AMF as service consumer  6.5.2.3 AMF as service producer  6.5.3 Stateless NFs (for any 5GC NF type)  6.5.3.1 General  6.5.3.2 Stateless NF as service consumer  6.5.3.3 Stateless NF as service producer 
...

 

6.5  Support of Stateless NFs  p. 89

6.5.1  General  p. 89

A NF may become stateless by decoupling the "compute" resource and "storage" resource as specified in clause 4.1 of TS 23.501.

6.5.2  Stateless AMFs  p. 89

6.5.2.1  General  p. 89

AMF may become stateless by storing the UE related information in the UDSF. Procedures for AMF planned removal or the AMF auto-recovery are specified in clauses 5.21.2.2 and 5.21.2.3 of TS 23.501.

6.5.2.2  AMF as service consumer  p. 89

1)
When the AMF subscribes to notifications from another NF Service Producer, the AMF shall provide its GUAMI to the NF Service Producer to enable the latter to discover AMFs within the AMF set, or information about a backup AMF, in addition to Callback URI in the subscription resource.
The AMF may also provide the name of the AMF service to which these notifications are to be sent (this service shall be one of the service produced by the AMF and registered in the NRF or a custom service registered in the NRF for the purpose of receiving these notifications);
2)
A NF service producer may also use the Nnrf_NFDiscovery service to discover AMFs within an AMF set or backup AMF.
If the AMF provided the name of its service (see bullet 1), the NF Service Producer shall look up for the same AMF service from the AMFs within the AMF set or from backup AMF, and use endpoint addresses (i.e. IP addresses, transport and port information, or FQDN) and callback URI prefix (if any) of that service to send notifications (see bullet 6). Otherwise, the notifications shall be sent to an endpoint address registered in the NF Profile of the AMF.
3)
An NF service producer may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service.
4)
An NF service producer may become aware of AMF changes (at the time of the AMF change or subsequently when sending signalling to the AMF) via Namf_Communication service AMFStatusChange Notifications, via HTTP Error response from the old or a wrongly selected new AMF, via link level failures (e.g. no response from the AMF), or via a notification from the NRF that the AMF has deregistered. The HTTP error response may be a 3xx redirect response pointing to a new AMF.
5)
When becoming aware of an AMF change, and the new AMF is not known, the NF service producer shall select an AMF within the AMF set or the possibly earlier received backup AMF.
6)
When becoming aware of an AMF change, the NF service producer shall
  • use the default notification URI of the default notification subscription of the reselected AMF (as specified in clause 6.10.5.2), if this is a default notification from a default notification subscription; otherwise
  • replace the authority part and callback URI prefix (if any) of the Notification URI with new AMF information; when replacing the authority, if the port number or and callback URI prefix are not available for the new AMF, e.g. when the NF instance level information of the new AMF is to be used, the port number and callback URI prefix (if any) in old Notification URI should be reused in the alternative notification URI.
The NF service producer shall then use that URI in subsequent communication.
7)
Each AMF within the AMF set shall be prepared to receive notifications from the NF service producer, by either handling the notification to the Notification URI constructed according to bullet 6 with the own address as authority part and callback URI prefix (if any), or by replying with an HTTP 3xx redirect pointing to a new AMF, or by replying with another HTTP error.
8)
The NF service producer shall be prepared to receive updates to resources of the related service from any AMF within the set.
9)
If the UE moves to an AMF from a different AMF Set, or to an AMF from the same AMF set that does not support handling the notification as specified in bullet 7, the new AMF should update peer NFs with the new callback URI for the notification.
Up

6.5.2.3  AMF as service producer  p. 90

1)
When AMF receives request to establish a service, it may provide information about a backup AMF in a suitable resource.
2)
NF service consumer may also use the Nnrf_NFDiscovery service to discover AMFs within an AMF set.
3)
An NF service consumer may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service.
4)
An NF service consumer may become aware of AMF changes (at the time of the AMF change or subsequently when sending signalling to the AMF) via Namf_Communication service AMFStatusChange Notifications, via Error response from the old or a wrongly selected new AMF, via link level failures (e.g. no response from the AMF), or via a notification from the NRF that the AMF has deregistered. The HTTP error response may be a 3xx redirect response pointing to a new AMF.
5)
When becoming aware of an NF service consumer change, the NF service producer or SCP shall
  • use the default notification URI of the default notification subscription of the reselected NF service consumer (as specified in clause 6.10.5.2), if this is a default notification from a default notification subscription; otherwise
  • replace the authority and callback URI Prefix (if any) part of the Notification/Callback URI with the new NF service consumer information; when replacing the authority, if the port number or and callback URI prefix are not available for the new NF service consumer, e.g. when the NF instance level information of the new NF service consumer is to be used, the port number and callback URI prefix (if any) in old Notification URI should be reused in the alternative notification URI.
The NF service producer or SCP shall then use that URI in subsequent communications, as specified in clause 6.6 of TS 23.527.
6)
When becoming aware of an AMF change, the NF service consumer shall exchange the apiRoot of resource URIs with new AMF's apiRoot and shall use that URI in subsequent communication.
7)
Each AMF within the AMF set shall be prepared to receive updates for resources from the NF service consumer, by either handling the updates to the resource URIs constructed according to step 6 with its ownapiRoot, or by replying with an HTTP 3xx redirect pointing to a new AMF, or by replying with another HTTP error.
8)
For a service that includes notifications from the AMF, the NF service consumer shall be prepared to receive for the service notifications from any AMF within the set.
Up

6.5.3  Stateless NFs (for any 5GC NF type) |R16|  p. 91

6.5.3.1  General  p. 91

An NF may become stateless by storing its contexts as unstructured data in the UDSF.An UDM, PCF and NEF may also store own structured data in the UDR. An UDR and UDSF cannot become stateless.
An NF may also be deployed such that several stateless network function instances are present within a set of NF instances. Additionally, within an NF, an NF service may have multiple instances grouped into a NF Service Set if they are interchangeable with each other because they share the same context data. See clause 5.21 of TS 23.501.
A UDM / AUSF / UDR / PCF group may consist of one or multiple UDM / AUSF / UDR / PCF sets.
Up

6.5.3.2  Stateless NF as service consumer  p. 91

1)
When the NF service consumer subscribes (explicitly or implicitly) to notifications from another NF service producer, the NF service consumer may provide a binding indication to the NF service producer as specified in clause 6.3.1.0 of TS 23.501 and clause 4.17.12.4 of TS 23.502, to enable the related notifications to be sent to an alternative NF service consumer within the NF (service) set, in addition to providing the Callback URI in the subscription resource. The NF service consumer may provide the NRF API URI(s) in 3gpp-Sbi-Nrf-Uri-Callback header which can be used for reselection of NF service consumer.
2)
A NF service producer or SCP may use the Nnrf_NFDiscovery service to discover NF service consumers within an NF (service) set. If the NRF API URI(s) was received in the 3gpp-Sbi-Nrf-Uri-Callback header in bullet 1, the NRF NFDiscovery API URI should be used for the reselection.
3)
An NF service producer may become aware of a NF service consumer change, via receiving an updated binding information (i.e. when the binding entity corresponding to the binding level is changed) in a HTTP request message, or via an Error response to a notification, via link level failures (e.g. no response from the NF), or via a notification from the NRF that the NF service consumer has deregistered. The HTTP error response may be a 3xx redirect response pointing to a new NF service consumer.
4)
When becoming aware of an NF service consumer change, and if the new NF service consumer is not known, the NF service producer shall select a new NF service consumer as specified in clause 6.6 of TS 23.527. If binding information is available and the binding mechanism is supported by the NF service producer, the reselection should be based on the binding information, as specified in clause 6.6.2 of TS 23.527, in clause 6.3.1.0 of TS 23.501 and in clause 4.17.12.4 of TS 23.502. If binding information is not available or the binding mechanism is not supported by the NF service producer, the reselection is performed as specified in clause 6.6.3 of TS 23.527.
5)
When becoming aware of an NF service consumer change, the NF service producer or SCP shall
  • use the default notification URI of the default notification subscription of the reselected NF service consumer (as specified in clause 6.10.5.2), if this is a default notification from a default notification subscription; otherwise
  • replace the authority and callback URI Prefix (if any) part of the Notification/Callback URI with the new NF service consumer information; when replacing the authority, if the port number or and callback URI prefix are not available for the new NF service consumer, e.g. when the NF instance level information of the new NF service consumer is to be used, the port number and callback URI prefix (if any) in old Notification URI should be reused in the alternative notification URI.
The NF service producer or SCP shall then use that URI in subsequent communications, as specified in clause 6.6 of TS 23.527.
6)
When the NF service consumer is changed, and if the new NF service consumer does not support handling notifications as specified in the above bullet 5, the new NF service consumer should update the NF service producers with the new Notification URI. For explicit subscriptions, this is achieved by updating the existing subscription or creating a new subscription, depending on the NF service producer's API. For implicit subscriptions, this is carried out via a service update request message.
7)
The new NF service consumer may include an updated binding indication in a service request or notification response message to the NF service producer.
8)
Each NF service consumer within the NF (service) set shall be prepared to receive notifications from the NF service producer, either by handling the notifications to the Notification URI constructed according to the above bullet 5 with its own address as authority part and callback URI Prefix (if any), by handling the notifications to the Notification URI notified in the above bullet 6, or by replying with an HTTP 3xx redirect pointing to a new NF service consumer or with another HTTP error.
9)
The NF service producer shall be prepared to receive updates to resources of the related service from any NF service consumer within the NF (service) set.
10)
If an SCP detects that the target NF service consumer of a notification/callback request is not available, the SCP shall reselect a new NF service consumer based on the Routing Binding Indication and/or 3gpp-Sbi-Discovery headers, if such information has been provided by the NF service producer in the notification/callback request. See clause 6.6 in TS 23.527.
Up

6.5.3.3  Stateless NF as service producer  p. 93

1)
When the NF service producer receives a request to establish a service, it may provide binding information as specified in clause 6.3.1.0 of TS 23.501 and clause 4.17.12 of TS 23.502 to establish a binding between the NF service consumer and the NF service producer for subsequent related requests.
2)
The NF service consumer or SCP may use the Nnrf_NFDiscovery service to discover NF service producers within an NF (service) set.
3)
An NF service consumer may become aware of a NF service producer change, by receiving an updated binding information (i.e. when the binding entity corresponding to the binding level is changed) in a HTTP request message, or via an Error response from the old or a selected new NF service producer, via link level failures (e.g. no response from the NF), or via a notification from the NRF that the NF has deregistered. The HTTP error response may be a 3xx redirect response pointing to a new NF.
4)
When becoming aware of an NF service producer change, and if the new NF service producer is not known, the NF service consumer shall select a new NF service producer, as specified in clause 6.5 of TS 23.527. If binding information is available and the binding mechanism is supported by the NF service consumer, the reselection should be based on the binding information, as specified in clause 6.12 of this specification (see also clause 6.5.2 of TS 23.527) and in clause 6.3.1.0 of TS 23.501. If binding information is not available or the binding mechanism is not supported by the NF service consumer, the reselection is performed as specified in clause 6.5.3 of TS 23.527.
5)
When becoming aware of an NF service producer change, the NF service consumer or SCP shall replace the apiRoot of the resource URI with the new NF service producer's apiRoot and shall use that URI in subsequent communications as specified in clause 6.5 of TS 23.527.
6)
When the NF service producer changes, the new NF service producer may include an updated binding indication in a notification/callback request sent to the NF service consumer. The new NF service producer may also generate a new resource URI and return it to the NF service consumer upon reception of a service request related to the resource from that NF service consumer, e.g. the new NF service producer may reply with an HTTP 3xx redirect status code pointing to the new location of the resource.
7)
Each NF service producer within the NF (service) set shall be prepared to receive updates for resources from the NF service consumer, either by handling the updates to the resource URIs constructed according to the above bullet 5 with its own apiRoot, by handling the updates to the resource URIs notified in the above bullet 6, by replying with an HTTP 3xx redirect pointing to a new NF service producer, or by replying with another HTTP error.
8)
For a service that includes notifications from the NF service producer, the NF service consumer shall be prepared to receive for that service notifications from any NF service producer within the NF (service) set.
9)
If an SCP detects that the target NF service producer is not available, the SCP shall reselect a new NF service producer based on the Routing Binding Indicationand/or 3gpp-Sbi-Discovery headers, if such information has been provided by the NF service consumer in the request. See clause 6.5 in TS 23.527.
Up

Up   Top   ToC