Content for &nbsp; TS 23.502 &nbsp; Word version:&nbsp; 19.1.0

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

The NRF stores the NF profile of NF service consumer and marks the NF service consumer available.

Figure 4.17.2-1: NF Service Update procedure

The NRF acknowledge NF Registration is accepted via Nnrf_NFManagement_NFRegister response.

4.17.2 NF service update p. 556

Reproduction of 3GPP TS 23.502, Fig. 4.17.2-1: NF Service Update procedure

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.

The NRF updates the NF profile of NF service consumer.

Figure 4.17.3-1: NF Service Deregistration procedure

The NRF acknowledge NF Update is accepted via Nnrf_NFManagement_NFUpdate response.

4.17.3 NF service deregistration p. 556

Reproduction of 3GPP TS 23.502, Fig. 4.17.3-1: NF Service Deregistration procedure

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.

The NRF marks the NF service consumer unavailable. NRF may remove the NF profile of NF service consumer according to NF management policy.

Figure 4.17.4-1: NF/NF service discovery in the same PLMN

The NRF acknowledge NF Deregistration is accepted via Nnrf_NFManagement_NFDeregister response.

4.17.4 NF/NF service discovery by NF service consumer in the same PLMN p. 557

Reproduction of 3GPP TS 23.502, Fig. 4.17.4-1: NF/NF service discovery in the same PLMN

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 and Home Network Public Key identifier (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.

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.

Figure 4.17.5-1: NF/NF service discovery across PLMNs

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. For the scenario when NF instance(s) reside in a target PLMN as specified in clause 4.2.3 and clause 6.2.6.1 of TS 23.501, the NRF in HPLMN may further query a NRF in that target PLMN. 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, if configured in CHF instance profile. 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.

4.17.4a NF/NF service discovery by NF service consumer in the same SNPN |R17| p. 558

The NF/NF service discovery by NF service consumer in the same SNPN follows the same principles as NF/NF service discovery by NF service consumer in the same PLMN, see clause 4.17.4. The following additions apply:

If the target NF is AUSF or NSSAAF and the Nnrf_NFDiscovery_Request includes a Home Network Identifier (HNI) in the form of a realm and the HNI belongs to a CH with AAA Server or a DCS with AAA Server, the NRF provides the AUSF or NSSAAF in the same SNPN, based on the NF profile as specified in clause 6.2.6.2 of TS 23.501.
If the target NF is UDM and the Nnrf_NFDiscovery_Request includes a Home Network Identifier (HNI) in the form of a realm and the HNI belongs to a CH with AAA Server, the NRF provides the UDM in the same SNPN, based on the NF profile as specified in clause 6.2.6.2 of TS 23.501.

4.17.5 NF/NF service discovery across PLMNs in the case of discovery made by NF service consumer p. 558

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:

Reproduction of 3GPP TS 23.502, Fig. 4.17.5-1: NF/NF service discovery across PLMNs

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.

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 to 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 another NRF (e.g. a local NRF within the home PLMN or a NRF in a target PLMN for the scenario where NF instances which reside in that target PLMN can be used for traffic from certain UEs as specified in clause 4.2.4 and clause 6.2.6.1 of TS 23.501) based on the input information received from NRF of the serving PLMN. The Endpoint Address(es) of the NF Discovery service(s) of this NRF may be configured in the hNRF or may need to be discovered based on the input information. For further information about NRF-NRF interactions, see clauses 5.3.2.2.4 and 5.3.2.2.5 of TS 29.510.

Figure 4.17.5a-1: NF/NF service discovery across SNPN and Credentials Holder

The NRF in serving PLMN provides same as step 3 in clause 4.17.4 applies.

4.17.5a NF/NF service discovery between SNPN and Credentials Holder hosting AUSF/UDM or between SNPN and DCS hosting AUSF/UDM |R17| p. 559

Reproduction of 3GPP TS 23.502, Fig. 4.17.5a-1: NF/NF service discovery across SNPN and Credentials Holder

In the case of a UE accessing SNPN using credentials from a Credentials Holder hosting AUSF/UDM, similar procedure can be used for service discovery across PLMNs as specified in clause 4.17.5 with the difference as below:

The Serving PLMN is replaced by SNPN and Home PLMN is replaced by CH;
In step 1:
- the Home PLMN ID in Nnrf_NFDiscovery_Request is replaced by identification for the Credentials Holder, i.e.:
  - the realm in the case of Network Specific Identifier based SUCI/SUPI; or
  - the MCC and MNC in the case of an IMSI based SUCI/SUPI;
  NOTE:
  When IMSI based SUPI is used for a UE of a CH, the IMSI is assumed to be globally unique and assigned by the owner of a PLMN ID containing MCC and MNC of the IMSI as defined in TS 23.501.
- the Serving PLMN ID is replaced by SNPN ID (i.e. PLMN ID and NID);
In step 2, the NRF in SNPN identifies NRF in CH based on the identification for the Credentials Holder.

In the case of a UE accessing ON-SNPN using Default UE credentials from a DCS hosting AUSF/UDM, a similar procedure can be used than for service discovery across PLMNs as specified in clause 4.17.5, with the difference as below:

The Serving PLMN is replaced by SNPN and Home PLMN is replaced by DCS;
In step 1:
- the Home PLMN ID in Nnrf_NFDiscovery_Request is replaced by identification for the DCS, i.e.:
  - the realm in the case of Network Specific Identifier based SUCI/SUPI;
- the Serving PLMN ID is replaced by SNPN ID (i.e. PLMN ID and NID);
In step 2, the NRF in SNPN identifies NRF in DCS based on the identification for the DCS.

4.17.6 SMF Provisioning of available UPFs using the NRF p. 560

4.17.6.1 General p. 560

This clause describes the provisioning of available UPFs in SMF using the NRF as documented in clause 6.3.3 of TS 23.501.

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.

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 MPQUIC functionality, or any combination of them is supported.
the supported UPF event exposure service and supported Event IDs, e.g. local notification of QoS Monitoring to AF or e.g. events for data collection to NWDAF by Nupf_EventExposure_Notify.
the supported functionality associated with high data rate low latency services, eXtended Reality (XR) and interactive media services, specified in clause 5.37 of TS 23.501 (for example, ECN marking for L4S, specified in clause 5.37.3 of TS 23.501, PDU Set Marking, specified in clause 5.37.5 of TS 23.501, UE power saving management, specified in clause 5.37.8 of TS 23.501).
the supported operator configurable UPF capabilities as described in clause 5.8.2.21 of TS 23.501.
the support of NAT information exposure functionality (see clause 6.2.3 of TS 23.501).
the support of IP or MAC filter-based packet detection functionality (see clause 6.2.3 of TS 23.501).

The SMF Area Identity and UE IPv4 Address Ranges and/or IPv6 Prefix Range(s) are optional in the UPF Provisioning Information.

4.17.6.2 SMF provisioning of UPF instances using NRF p. 560

This procedure applies when a SMF wants to get informed about UPFs available in the network and supporting a list of parameters.

Reproduction of 3GPP TS 23.502, Fig. 4.17.6.2-1: SMF provisioning of UPF instances using NRF procedure

Figure 4.17.6.2-1: SMF provisioning of UPF instances using NRF procedure

The following takes place when an SMF expects to be informed of UPFs available in the network:

The SMF issues a Nnrf_NFManagement_NFStatusSubscribe Service Operation providing the target UPF Provisioning Information it is interested in.

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:

Figure 4.17.7-1: NF/NF service status subscribe/notify in the same PLMN

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

4.17.7 NF/NF service status subscribe/notify in the same PLMN p. 562

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.

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

Figure 4.17.8-1: NF/NF service status subscribe/notify across PLMNs

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.

4.17.8 NF/NF service status subscribe/notify across PLMNs p. 562

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:

The NF service consumer in the serving PLMN invokes Nnrf_NFManagement_NFStatusSubscribe Request from an appropriate configured NRF in the serving PLMN.

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.