Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3   4.3.4   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2   4.11.3…   4.12…   4.12.6…   4.12a   4.12b   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…

 

4.17  Network Function Service Framework Procedure
4.17.1  NF service Registration
NOTE 1:
The term "NF service consumer" in this clause refers to the consumer of the NRF services and should not be confused with the role of the NF (consumer or producer).
Up
Step 1.
NF service consumer, i. e. an NF instance sends Nnrf_NFManagement_NFRegister Request message to NRF to inform the NRF of its NF profile when the NF service consumer becomes operative for the first time. See clause 5.2.7.2.2 for relevant NF profile parameters
NOTE 2:
NF service consumer's NF profile is configured by OAM system.
Step 2.
The NRF stores the NF profile of NF service consumer and marks the NF service consumer available.
NOTE 3:
Whether the NF profile sent by NF service consumer to NRF needs to be integrity protected by the NF service consumer and verified by the NRF is to be decided by SA3.
Step 3.
The NRF acknowledge NF Registration is accepted via Nnrf_NFManagement_NFRegister response.
Up
4.17.2  NF service updateWord-p. 347
Up
Step 1.
NF service consumer i.e. an NF instance sends Nnrf_NFManagement_NFUpdate Request message (the updated NF profile of NF service consumer) to NRF to inform the NRF of its updated NF profile (e.g. with updated capacity) when e.g. triggered after a scaling operation. See clause 5.2.7.2.3 for relevant input and output parameters.
NOTE:
The updated NF profile of NF instance are configured by OAM system.
Step 2.
The NRF updates the NF profile of NF service consumer.
Step 3.
The NRF acknowledge NF Update is accepted via Nnrf_NFManagement_NFUpdate response.
NOTE 4:
When the NF service consumer registers to NRF via the SCP, the NF Service registration procedure can also be used by the SCP to derive the relation among NF instances, e.g. whether they belong to a specific NF Set.
Up
4.17.3  NF service deregistrationWord-p. 348
Up
Step 1.
NF service consumer i.e. an NF instance sends Nnrf_NFManagement_NFDeregister Request message to NRF to inform the NRF of its unavailability when e.g. it's about to gracefully shut down or disconnect from the network.
Step 2.
The NRF marks the NF service consumer unavailable. NRF may remove the NF profile of NF service consumer according to NF management policy.
Step 3.
The NRF acknowledge NF Deregistration is accepted via Nnrf_NFManagement_NFDeregister response.
Up
4.17.4  NF/NF service discovery by NF service consumer in the same PLMN
Up
Step 1.
The NF service consumer intends to discover services available in the network based on service name and target NF type. The NF service consumer invokes Nnrf_NFDiscovery_Request (Expected NF service Name, NF Type of the expected NF instance, NF type of the NF consumer) from an appropriate configured NRF in the same PLMN. The parameter may include optionally producer NF Set ID, NF Service Set ID, SUPI, Data Set Identifier(s), External Group ID (for UDM, UDR discovery), UE's Routing Indicator (for UDM and AUSF discovery), S-NSSAI, NSI ID if available, and other service related parameters. In addition, for AMF discovery, the parameters may include AMF Region ID, AMF Set ID, TAI. The NF service consumer may indicate a preference for target NF location in the Nnrf_NFDiscovery_Request. A complete list of parameters is provided in service definition in clause 5.2.7.3.2.
NOTE 1:
The NF service consumer indicates its NF location for preference for target NF location.
NOTE 2:
The use of NSI ID within a PLMN depends on the network deployment.
NOTE 3:
The need for other service related parameters depends on the NF type of the expected NF instance(s) and refer to the clause 6.3 " Principles for Network function and Network Function Service discovery and selection" in TS 23.501. It is up to NF implementation whether one or multiple NF service instances are registered in the NRF.
Step 2.
The NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instance(s) are deployed in a certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice.
Step 3.
If allowed, the NRF determines a set of NF instance(s) matching the Nnrf_NFDiscovery_Request and internal policies of the NRF and sends the NF profile(s) of the determined NF instances. Each NF profile containing at least the output required parameters (see clause 5.2.7.3.2) to the NF service consumer via Nnrf_NFDiscovery_Request Response message.
If the target NF is UDR, UDM or AUSF, if SUPI was used as optional input parameter in the request, the NRF shall provide the corresponding UDR, UDM or AUSF instance(s) that matches the optional input SUPI. Otherwise, if SUPI is not provided in the request, the NRF shall return all applicable UDR instance(s) (e.g. based on the Data Set Id, NF type), UDM instance(s) or AUSF instance(s) (e.g. based on NF type) and if applicable, the information of the range of SUPI(s) and/or Data Set Id each UDR instance is supporting.
If the target NF is CHF, if SUPI, GPSI or PLMN ID was used as optional input parameter in the request, the NRF shall provide the corresponding CHF instance(s) that matches the optional input SUPI, GPSI or PLMN ID. The NRF shall provide the primary CHF instance and the secondary CHF instance pair(s) together. Otherwise, if neither SUPI/PLMN ID nor GPSI is provided in the request, the NRF shall return all applicable CHF instance(s) and if applicable, the information of the range of SUPI(s), GPSI(s) or PLMN ID(s).
If the NF service consumer provided a preferred target NF location, the NRF shall not limit the set of discovered NF instances or NF service instance(s) to the target NF location, e.g. the NRF may provide NF instance(s) or NF service instance(s) for which location is not the preferred target NF location if no NF instance or NF service instance could be found for the preferred target NF location.
Up
4.17.5  NF/NF service discovery across PLMNs in the case of discovery made by NF service consumerWord-p. 349
In the case that the NF service consumer intends to discover the NF/NF service in home PLMN, the NRF in serving PLMN needs to request "NF Discovery" service from NRF in the home PLMN. The procedure is depicted in the figure below:
Up
Step 1.
The NF service consumer in the serving PLMN invokes Nnrf_NFDiscovery_Request (Expected Service Name, NF type of the expected NF, home PLMN ID, serving PLMN ID, NF type of the NF service consumer) to an appropriate configured NRF in the serving PLMN. The request may also include optionally producer NF Set ID, NF Service Set ID, S-NSSAI, NSI ID if available, and other service related parameters. A complete list of parameters is provided in service definition in clause 5.2.7.3.2.
NOTE 1:
The use of NSI ID within a PLMN depends on the network deployment.
Step 2.
The NRF in serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID, and it requests "NF Discovery" service from NRF in home PLMN according the procedure in Figure 4.17.4-1 to get the expected NF profile(s) of the NF instance(s) deployed in the home PLMN. As the NRF in the serving PLMN triggers the "NF Discovery" on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the Discovery Request message it sends to the hNRF.
The hNRF may further query an appropriate local NRF in the home PLMN based on the input information received from NRF of the serving PLMN. The FQDN of the local NRF or Endpoint Address of local NRF's NF Discovery service in the home PLMN may be configured in the hNRF or may need to be discovered based on the input information.
Step 3.
The NRF in serving PLMN provides same as step 3 in clause 4.17.4 applies.
Up
4.17.6  SMF Provisioning of available UPFs using the NRFWord-p. 350
4.17.6.1  General
This clause describes the provisioning of available UPFs in SMF using the NRF as documented in TS 23.501, clause 6.3.3.
This optional node-level step takes place prior to selecting the UPF for PDU Sessions and may be followed by N4 Node Level procedures defined in clause 4.4.3 where the UPF and the SMF exchange information such as the support of optional functionalities and capabilities.
As an option, UPF(s) may register in the NRF. This registration phase uses the Nnrf_NFManagement_NFRegister operation and hence does not use N4.
For the purpose of SMF provisioning of available UPFs, the SMF uses the Nnrf_NFManagement_NFStatusSubscribe, Nnrf_NFManagement_NFStatusNotify and Nnrf_NFDiscovery services to learn about available UPFs.
NOTE 1:
The protocol used by UPF to interact with NRF is described in TS 29.510
UPFs may be associated with UPF Provisioning Information in the NRF. The UPF Provisioning Information consists of:
  • a list of (S-NSSAI, DNN);
  • UE IPv4 Address Ranges and/or IPv6 Prefix Range(s) per (S-NSSAI, DNN); and
  • NOTE 2:
    The above information can be used by the SMF for UPF selection when static IP address/prefix allocation is required for a UE.
  • a SMF Area Identity the UPF can serve. The SMF Area Identity allows limiting the SMF provisioning of UPF(s) using NRF to those UPF(s) associated with a certain SMF Area Identity. This can e.g. be used if an SMF is only allowed to control UPF(s) configured in NRF as belonging to a certain SMF Area Identity.
  • the supported ATSSS steering functionality, i.e. whether MPTCP functionality or ATSSS-LL functionality or both are supported.
The SMF Area Identity and UE IPv4 Address Ranges and/or IPv6 Prefix Range(s) are optional in the UPF Provisioning Information.
Up
4.17.6.2  SMF provisioning of UPF instances using NRF
This procedure applies when a SMF wants to get informed about UPFs available in the network and supporting a list of parameters.
Up
The following takes place when an SMF expects to be informed of UPFs available in the network:
Step 1.
The SMF issues a Nnrf_NFManagement_NFStatusSubscribe Service Operation providing the target UPF Provisioning Information it is interested in.
Step 2.
The NRF issues Nnrf_NFManagement_NFStatusNotify with the list of all UPFs that currently meet the SMF subscription. This notification indicates the subset of the target UPF Provisioning Information that is supported by each UPF.
The following takes place when a new UPF instance is deployed:
Step 3.
At any time a new UPF instance is deployed.
Step 4.
The UPF instance is configured with the NRF identity to contact for registration and with its UPF Provisioning Information. An UPF is not required to understand the UPF Provisioning Information beyond usage of this information to register in step 5.
Step 5.
The UPF instance issues an Nnrf_NFManagement_NFRegister Request operation providing its NF type, the FQDN or IP address of its N4 interface, and the UPF Provisioning Information configured in step 4.
Step 6.
Alternatively (to steps 4 and 5) OAM registers the UPF on the NRF indicating the same UPF Provisioning Information as provided in step 5. This configuration mechanism is out of scope of this specification.
Step 7.
Based on the subscription in step 1, the NRF issues Nnrf_NFManagement_NFStatusNotify to all SMFs with a subscription matching the UPF Provisioning Information of the new UPF
Up
4.17.7  NF/NF service status subscribe/notify in the same PLMNWord-p. 352
Up
Step 1.
The NF service consumer subscribes to be notified of newly registered/updated/deregistered NF instances along with its NF services. The NF service consumer invokes Nnrf_NFManagement_NFStatusSubscribe Request from an appropriate configured NRF in the same PLMN.
Step 2.
The NRF authorizes the Nnrf_NFManagement_NFStatusSubscribe Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to subscribe to the status of the target NF instance(s) or NF service instance(s).
Step 3.
If allowed, the NRF acknowledges the execution of Nnrf_NFManagement_NFStatusSubscribe Request.
Step 4.
NRF notifies about newly registered/updated/deregistered NF instances along with its NF services to the subscribed NF service consumer.
NOTE 1:
The NF service consumer unsubscribes to receive NF status notifications by invoking Nnrf_NFManagement_NFStatusUnSubscribe service operation.
NOTE 2:
When the NF or NF service intance becomes unavailable, the NRF invokes Nnrf_NFManagement_NFStatusNotify service to notify the NF service consumer based on the subcription.
Up
4.17.8  NF/NF service status subscribe/notify across PLMNs
In the case that the NF service consumer intends to subscribe to the status of NF/NF service instance(s) in home PLMN, the NRF in serving PLMN needs to request "NF status subscribe" service from NRF in the home PLMN. The notification is sent from the NRF in the home PLMN to the NF service consumer in the serving PLMN without the involvement of the NRF in the serving PLMN. The procedure is depicted in the figure below:
Up
NOTE 1:
The NRF in the home PLMN communicates with the NRF and the NF consumer in the serving PLMN via the SEPPs in the respective PLMNs. For the sake of clarity, SEPPs are not depicted in the flow.
Step 1.
The NF service consumer in the serving PLMN invokes Nnrf_NFManagement_NFStatusSubscribe Request from an appropriate configured NRF in the serving PLMN.
Step 2.
The NRF in serving PLMN identifies NRF in home PLMN (hNRF) based on the home PLMN ID, and it requests Nnrf_NFManagement_NFStatusSubscribe service from NRF in home PLMN. As the NRF in the serving PLMN triggers the Nnrf_NFManagement_NFStatusSubscribe service on behalf of the NF service consumer, the NRF in the serving PLMN shall not replace the information of the service requester NF, i.e. NF consumer ID, in the status subscribe Request message it sends to the hNRF.
Step 3.
The NRF in serving PLMN acknowledges the execution of Nnrf_NFManagement_NFStatusSubscribe Request to the NF consumer in the serving PLMN.
Step 4.
NRF in the home PLMN notifies about newly registered/updated/deregistered NF instances along with its NF services to the subscribed NF service consumer in the serving PLMN.
NOTE 2:
The NF service consumer unsubscribes to receive NF status notifications by invoking Nnrf_NFManagement_NFStatusUnSubscribe service operation.
NOTE 3:
When the NF or NF service intance becomes unavailable, the NRF in the home PLMN invokes Nnrf_NFManagement_NFStatusNotify service to notify the NF service consumer in the serving PLMN based on the subcription.
Up

Up   Top   ToC