4.17 Network Function Service Framework Procedure

23.5023GPPProcedures for the 5G System (5GS)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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

Figure 4.17.1-1: NF Service Registration procedure

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.

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.

3. The NRF acknowledge NF Registration is accepted via Nnrf_NFManagement_NFRegister response.

4.17.2 NF service update

Figure 4.17.2-1: NF Service Update procedure

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.

2. The NRF updates the NF profile of NF service consumer.

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.

4.17.3 NF service deregistration

Figure 4.17.3-1: NF Service Deregistration procedure

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.

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

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

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

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

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 [2]. It is up to NF implementation whether one or multiple NF service instances are registered in the NRF.

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.

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, 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

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 in TS 23.501 [2].

– 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 in TS 23.501 [2].

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

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:

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

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.

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.

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

Figure 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 [2].

– 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

4.17.6.1 General

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

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 [37]

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

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

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:

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

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:

3 At any time a new UPF instance is deployed.

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.

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.

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.

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

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

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.

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

3. If allowed, the NRF acknowledges the execution of Nnrf_NFManagement_NFStatusSubscribe Request.

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

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:

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

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.

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

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.

3. The NRF in serving PLMN acknowledges the execution of Nnrf_NFManagement_NFStatusSubscribe Request to the NF consumer in the serving PLMN.

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

4.17.9 Delegated service discovery when NF service consumer and NF service producer are in same PLMN

Figure 4.17.9-1: Delegated NF service discovery when NF service consumer and NF service producer are in same PLMN

1. The NF service consumer intends to communicate with an NF service producer. The NF service consumer sends the service request to an SCP. The request may include discovery and selection parameters necessary to discover and select a NF service producer instance. The discovery and selection parameters are included in the request by the NF service consumer in a way that the SCP does not need to parse the request body.

2. The SCP may perform discovery upon the request either by interacting with an NRF using Nnrf_NFDiscovery service NRF or may use information collected during the previous interactions with an NRF (by the Nnrf_NFDiscovery service or Nnrf_NFManagement_NFStatusNotify service operation). The SCP together with the NRF authorizes the request. The SCP selects the target NF service producer.

NOTE 1: If the discovery and selection parameters in the request include a UE identity, e.g. SUPI or IMPI/IMPU, the SCP can resolve the requested NF’s Group ID corresponding to the UE identity and then invoke the Nnrf_NFDiscovery service, as defined in clause 6.3.1 of TS 23.501 [2].

3. If the NF service consumer is authorized to communicate with the NF service producer, the SCP forwards the request to the selected NF service producer according to the configuration of the Network Slice, e.g. the expected NF instances are only reachable by NFs in the same network slice.

4. The NF service producer sends a response to the SCP. If the request in step 3 creates a resource in the NF service producer, such as depicted in Figure 4.17.9-1, the NF service producer responds with resource information identifying the created resource.

5. The SCP routes the response to the NF service consumer.

If the NF service consumer receives a resource address, it uses it for subsequent requests regarding the concerned resource. Otherwise, the procedure ends here.

6. On a subsequent operation on the created resource, the NF service consumer addresses the resource via the resource address returned by the NF service producer at step 4.

7. The SCP resolves the NF service producer address and selects a target NF service producer instance. The SCP then routes the request to the selected NF service producer instance. See the clause 6.3.1.0 of TS 23.501 [2] for the details of selection of a target NF service producer instance by SCP.

8. The SCP delivers the request to the NF service producer.

9. The NF service producer sends a response to the SCP. The NF service producer may respond with an updated resource information different to the one received in the previous response.

10. The SCP sends a response to the NF service consumer. If the resource information was updated, the NF service consumer uses the received resource information for subsequent operations (requests) on the resource.

NOTE 2: In the similar manner of handling the resource information, a binding indication may be also provided by the NF service producer and used for the subsequent requests of the NF service consumer. See more details in clause 4.17.12.

4.17.10 Delegated service discovery when NF service consumer and NF service producer are in different PLMNs

Figure 4.17.10-1: Delegated NF service discovery when NF service consumer and NF service producer are in different PLMNs

1. The NF service consumer intends to communicate with an NF service producer. The NF service consumer sends the request to an SCP. The request includes at least the source PLMN ID and the target PLMN ID in the discovery and selection parameters necessary for the SCP to discover and select a NF service producer instance. The discovery and selection parameters are included in the request by the NF service consumer in a way that the SCP does not need to parse the request body.

2. The SCP recognises that the request is for a NF service producer in another PLMN. SCP interacts with NRF using the Nnrf_NFDiscovery service.

3. NRF in PLMN-1 and NRF in PLMN 2 interact using the Nnrf_NFDiscovery service. See step 2 in clause 4.17.5.

4. SCP gets Nnrf_NFDiscovery service response with NF profile(s).

5. SCP selects a NF service producer instance in PLMN-2.

6. SCP forwards the request to the selected NF service producer instance in PLMN-2.

Alternatively, SCP may send the discovery request directly to the NRF in PLMN-2, if it has the relevant NRF address and is authorized by the NRF in PLMN-2. Thus step 2 goes from SCP to NRF in PLMN-2 and step 4 goes from NRF in PLMN-2 to SCP and step 3 is omitted.

4.17.11 Indirect Communication without delegated discovery Procedure

This clause provides the call flow for indirect communication model without delegated discovery.

Figure 4.17.11-1: Procedure for Indirect Communication without delegated discovery

The NF/NF service discovery procedure is defined in clauses 4.17.4 and 4.17.5. In a successful discovery the NF service consumer gets the NF profile(s) matching the search criteria provided in the Nnrf_NFDiscovery_Request message.

1. When the NF Service Consumer needs to send a Service Request and has obtained an endpoint address for the appropriate resources of the NF service producer from the reply to a previous service operation, the NF Service Consumer should indicate that endpoint address as target for the Service Request. Otherwise, if the NF Service Consumer has stored results from the Discovery Procedure, the NF Service Consumer selects an appropriate NF Producer / NF Service Producer instance from the list of NF profiles provided by the NRF. The NF Service Consumer considers the NF and NF service parameters (e.g. TAI, S-NSSAI, locality, priority etc) in the NF profiles. The NF Service consumer requests service from the NF Service producer by sending a service request message to the NF service producer via the SCP and the NF Service Consumer may provide a Routing Binding Indication with the same contents as the previously received Binding Indication.

2. If the Routing Binding Indication is provided by the NF Service Consumer, SCP (re-)selects as specified in Table 6.3.1.0‑1 of TS 23.501 [2] and routes the service request to target accordingly. If the Routing Binding Indication is not provided by the NF Service Consumer, then the SCP routes the service request based on routing information available.

3. The NF Service Producer responds via SCP.

4. SCP forwards the response.

4.17.12 Binding between NF service consumer and NF service producer

4.17.12.1 General

This clause describes the procedures to establish binding between the NF service consumer and producer.

Direct Communication or Indirect Communication procedures may be used between the Consumer and Producer. In the case of Indirect Communication, an SCP is located between the Consumer and Producer.

4.17.12.2 Binding created as part of service response

When the NF service consumer communicates with the NF service producer, the producer may return a binding indication to the consumer. The consumer stores the received binding indication and uses it for the subsequent requests concerning the data context.

Figure 4.17.12.2-1: Binding created as part of service response

1. If Direct Communication is used, the NF service consumer selects the NF service producer and sends the request to the selected NF service producer. If Indirect Communication without delegated discovery is used, the NF service consumer selects the NF service producer set or instance and sends the request to the selected NF service producer via the SCP; if the NF serviver consumer only selects the NF service producer set, it provides the necessary selection parameters and the SCP selects the NF service producer instance. If Indirect Communication with delegated discovery is used, the NF service consumer sends the request to the SCP and provides within the service request to the SCP the discovery and selection parameters necessary to discover and select a NF service producer.

2. The NF service producer sends a response to the NF service consumer. In the response the NF service producer may include a binding indication. If the NF service consumer receives a resource information and binding indication as specified in Table 6.3.1.0-1 of TS 23.501 [2], it uses them for subsequent requests regarding the concerned resource. Otherwise, the procedure ends here.

3. The NF service consumer uses the binding indication and resource information received in the previous step for subsequent requests regarding the concerned resource. If indirect communication with delegated discovery is used, the NF service consumer includes a Routing Binding Indication with the same contents as the received Binding Indication. If indirect communication without delegated discovery is used, the NF service consumer also includes the Routing Binding Indication with the same contents as the received Binding Indication unless the NF service consumer performs a reselection. The SCP shall route the service request using the Routing Binding Indication and resource information sent from the NF service consumer.

4. The NF service producer sends a response to the consumer. The NF service producer may respond with an updated binding indication, different to the one received in the previous response.

4.17.12.3 Binding created as part of service request

If the NF service consumer can also be as a NF service producer for later communication from the contacted producer, a service request sent to the producer may include binding indication.

NOTE: This clause only applies to an AMF, V-SMF or I-SMF as NF service consumer sending requests to an SMF and to an AMF as NF service consumer sending requests to an I-SMF or V-SMF, in step 1 unless further usage has been defined in stage 3. Implicit subscriptions are not described in this clause.

Figure 4.17.12.3-1: Binding created as part of service request

1. Instance A, as an NF service consumer sends a service request using either Direct Communication or Indirect communication via SCP and Instance B is selected as NF service producer. If Instance A can also be NF service producer for later communication for the concerned data context, it may include binding indication referring to NF service instance, NF service set, NF instance or NF Set as specified in Table 6.3.1.0-1 of TS 23.501 [2] in the request sent to the NF service producer; the binding indication shall be associated with an applicability indicating "other service" and include the service name. In this case, if indirect communication is used, the SCP sends to the Instance B the service request including the binding indication.

2. Instance B as the NF service producer sends a response to the NF service consumer.

3. When Instance B as NF service consumer needs to invoke the service provided by Instance A, Instance B sends a request using the binding indication received in step 1 as described in Steps 3-4 in Figure 4.17.12.2-1 with the following difference:

– Based on the received binding indication, if delegated discovery is not used, the Instance B may need to discover the corresponding endpoint address of the Instance A.

4.17.12.4 Binding for subscription requests

Binding for notifications can be created as part of an explicit or implicit subscription request. In this case, illustrated in Figure 4.17.12.4-1, the subscription request may include a Binding Indication 1 referring to NF service instance, NF service Set, NF instance or NF Set and additionally includes a service name of the NF service consumer as specified in Table 6.3.1.0-1 of TS 23.501 [2]. The NF Service Set ID, NF service instance ID and service name relate to the service of a NF service consumer that will handle the notification.

For direct communication, the NF service producer selects the target for the related notifications using the notification endpoint received in the subscription request. If the notification endpoint included in the subscription is not reachable, the Binding Indication received is used to discover an alternative notification endpoint, as specified in Table 6.3.1.0-1 of TS 23.501 [2].

For indirect communication, the NF service producer includes the notification endpoint received in the subscription and may include a Routing Binding Indication with the same contents as the received Binding Indication. If the notification endpoint included in the subscription is not reachable, the SCP selects the target for the related notifications using the received Routing Binding Indication as specified in Table 6.3.1.0-1 of TS 23.501 [2].

If the Binding Indication for Notifications needs to be updated, the NF service consumer may initiate a new Subscription request to the NF service producer with an updated Binding Indication or may include the Binding Indication in the acknowledgment of a Notification. A Subscription request may also contain updated Notification Correlation ID and Notification Target Address.

Binding for the subscription resource at the NF service producer can also be created: The Subscription Response message may contain a Binding Indication 2 referring to NF service instance, NF instance or NF Set of the NF service producer.

For direct communication, the NF service consumer selects the target for the related request to the producer, such as the request to update the subscription shown in Figure 4.17.12.4-1, using the received Binding Indication 2 as specified in Table 6.3.1.0-1 of TS 23.501 [2].

For indirect communication with delegated discovery, the NF service consumer includes a Routing Binding Indication with the same contents as the received Binding Indication 2. For indirect communication without delegated discovery, the NF service consumer also includes the Routing Binding Indication with the same contents as the received Binding Indication 2 unless it performs a reselection. The SCP selects the target for the related request using the received Routing Binding Indication 2 as specified in Table 6.3.1.0-1 of TS 23.501 [2].

If the Binding Indication for Subscription needs to be updated, the NF service producer may provide an updated binding indication in a notification request to the NF service consumer or in the response to a subsequent subscription update request from the NF service consumer.

Figure 4.17.12.4-1: Binding in a subscription request

Figure 4.17.12.4-2: Binding during subscription via another network function

An NF service consumer may subscribe via another network function. For example, NF_A may subscribe to NF_B on behalf of NF_C. NF_A additionally subscribe to subscription related events. In this case, both the binding indication from NF_C and NF_A are provided to the NF service producer NF_B. The Binding Indication for notifications to subscription related events shall be associated with an applicability indicating "subscription events".

The NF_C’s binding indication is used for reselection of a notification endpoint, which is used for event notification. The NF_A’s binding indication is used for reselection of a notification endpoint, which is used for subscription change event notification.

4.17.13 NRF bootstrapping procedure

Figure 4.17.13-1: Bootstrapping procedure

1. NF service consumer (e.g. v-NRF) sends a Nnrf_Bootstrapping_Get request to the configured address of the Bootstrapping Service instance.

2. NRF responds with all the Service Instances of the NRF and their endpoint addresses. This also contains if the NRF is part of an NF Set.