Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  16.4.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

6.5  Support of Stateless NFs
6.5.1  General
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
6.5.2.1  General
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
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) 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 exchange the authority part of the Notification URI with new AMF information and shall 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, 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 producerWord‑p. 52
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 AMF change, and the new AMF is not known, the NF service consumer 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 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 that service notifications from any AMF within the set.
Up
6.5.3  Stateless NFs (for any 5GC NF type) |R16|Word‑p. 53
6.5.3.1  General
A NF may become stateless by storing its contexts in the UDSF, or in the UDR for UDM, PCF, NEF.
A NF may also be deployed such that several stateless network function instances are present within a set of NF instances. Additionally, within a NF a 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
1)
When the NF service consumer subscribes 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 within the NF set, in addition to providing the Callback URI in the subscription resource.
2)
A NF service producer or SCP may use the Nnrf_NFDiscovery service to discover NFs within an NF set.
3)
An NF service producer may become aware of a NF service consumer change, via receiving an updated binding information, 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 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 consumer change, and the new NF service consumer is not known, the NF service producer shall select an NF according to the binding indication as specified in clause 6.3.1.0 of TS 23.501 and clause 4.17.12.4 of TS 23.502.
5)
When becoming aware of an NF service consumer change, the NF service producer or SCP shall exchange the authority part of the Notification URI with new NF service consumer information and shall use that URI in subsequent communication.
6)
When the NF service consumer is changed, and the new NF service consumer does not support handling the notifications as specified in bullet 5, the new NF service consumer should update NF service producers with the new Notification URI. For explicit subscriptions, the NF service consumer should update the subscription or create a new subscription with the new callback URI, depending on the NF service producer's API. For implicit subscriptions, the new Notification URI is carried in a service update request message.
7)
Each NF within the NF set shall be prepared to receive notifications from the NF service producer, by either handling the notifications to the Notification URI constructed according to bullet 5 with the own address as authority part, or by handling the notifications to the Notification URI notified in bullet 6, or by replying with an HTTP 3xx redirect pointing to a new NF or with another HTTP error.
8)
The NF service producer shall be prepared to receive updates to resources of the related service from any NF within the set.
Up
6.5.3.3  Stateless NF as service producer
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 NFs within an NF set or NF services within a NF service set.
3)
An NF service consumer may become aware of a NF service producer change, by receiving an updated binding information, or via an Error response from the old or a selected new NF, 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 a NF service producer change, and the new NF service producer is not known, the NF service consumer or SCP shall select an NF or NF service according to the binding information as specified in clause 6.3.1.0 of TS 23.501.
5)
When becoming aware of a NF service producer change, the NF service consumer or SCP shall exchange the apiRoot of resource URIs with new NF service producer's apiRoot and shall use that URI in subsequent communication.
6)
When the NF service producer changes, the new NF service producer may update the Subscription Correlation ID by sending a notification to the NF service consumer. The new NF service producer may 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 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 5 with its own apiRoot, or by handling the updates to the resource URIs notified in step 6, or by replying with an HTTP 3xx redirect pointing to a new NF, 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 set.
Up

Up   Top   ToC