Hierarchical NRF Deployment in the Same PLMN

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

5G-NRF

Applicable Platform(s)

SMI

Feature Default Setting

Not Applicable

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

2026.01

Feature Description

NRF is designed to be deployed in a hierarchical manner to support operator specific deployment models. Operators can deploy multiple NRF instances in the network according to geography, slicing, or any other criteria. This feature enables routing of Nnrf requests to an alternate NRF instance when the primary NRF instance that receives a request from an NF consumer is unavailable.

The NRF Hierarchy and Multiple NRF Support in the same PLMN feature enables NRF to provide the following functionality:

  • Support NRF registration, profile update and sending heart-beat message to another NRF.

  • Support routing of subscription requests with NfInstanceIdCond to an appropriate NRF that can serve the request.

  • Support routing of NF Discovery requests to an appropriate NRF that can serve the request.

How it Works

The following sections describe how the NRF Hierarchy and Multiple NRF Support in the same PLMN feature works.

NRF as Child Node

  1. NRF performs registration or update with another NRF through registration or full profile update procedure with nfType as nrf and providing the nrfInfo.

  2. NRF sends the heartbeat message (NF patch update) within the heartbeat interval, which was received as part of nfProfile during registration.

  3. On receiving the NFStatusSubscribtion request (HTTP PUT), if it detects that there is no nfProfile, which exists for the subscrCond with nfInstaceIdCond mentioned in the subscriptionData, NRF sends the NFStatusSubscribtion request to parent NRF.

  4. On receiving the success or failure message for the subscription from parent NRF, it sends the response to the NF service consumer.

  5. On receiving the NFDiscovery request (HTTP PUT), if it detects that there is no nfProfile, which exists with the mentioned query parameters, NRF sends the the NFDiscovery request to parent NRF.

  6. On receiving the success or failure message for the discovery from parent NRF, it sends the response to the NF service consumer.

NRF as Parent Node

  1. On receiving the NFStatusSubscribtion request (HTTP PUT), if it detects that there is no nfProfile, which exists for the subscrCond with nfInstaceIdCond mentioned in the subscriptionData, NRF forwards the NFStatusSubscribtion request to one of the child NRF.

  2. On receiving the success or failure message for the subscription from child NRF, it sends the response to the NRF from which the request was initiated.

  3. On receiving the NFDiscovery request (HTTP PUT), if it detects that there is no nfProfile, which exists with the mentioned query parameters, NRF sends the NFDiscovery request to one of the child NRF.

  4. On receiving the success or failure message for the discovery from parent NRF, it sends the response to the NRF from which the request was initiated.

NFDiscovery

NRF REST Endpoint

  1. The NRF Rest endpoint receives the NFDiscovery request over HTTP2/JSON. The HTTP method is GET and the URL is {apiRoot}/nnrf-disc/v1/nf-instances?<query-parameters> with no body.

    Note: The default value, /root, is a configurable parameter.

  2. On receiving the request, it is validated to check if the parameters and their value and type are allowed for discovery. If the validation fails, the response is sent with status 400 (BAD REQUEST).

  3. The NFDiscovery request is transformed into protobuf format and sent toward the service engine for processing.

  4. On receiving the request from NRF Service pod, the NRF Rest Endpoint creates an HTTP2/json message.

  5. If the received request contains the target NRF URI, the rest endpoint initiates the request with the URI (while sending to child NRF).

  6. If the received request does not contain the target NRF URI, the rest endpoint prepares the URI by taking the URI of the NRF to which the current NRF would have registered and initiates the request with the URI (while sending to parent NRF).

  7. It sends back the response to NRF Engine as received from the parent or child NRF.

NRF Service Engine

  1. On reception of the request from the NRF Rest endpoint, it checks if the policy configuration is present for the queried nfType.

  2. If the policy is not present, the NRF never forwards the discovery request.

  3. If check-and-send flag is disabled for the configured policy of nfType, NRF sends the discovery request to the Rest endpoint.

  4. If check-and-send flag is enabled and no profile found matching using the query parameters locally, it checks the nrfInfo of registered NRFs to derive the child NRF by using the snssai/nfinstanceid/nfInfo query parameter.

  5. If it finds any NRF matching the above query parameter, it prepares the URI using the services of that nrfProfile and fills the target NRF before sending the discovery request to the Rest endpoint.

  6. If it finds more than one NRF matching the query parameter, it selects that NRF, which is having less load.

  7. If it receives response with no profile from the rest endpoint or if it does not find any child NRF matching the query parameter, it sends the discovery request to the rest endpoint with no target NRF.

  8. After receiving the success or failure response from the Rest endpoint, NRF service endpoint responds to the earlier requested message received from the rest endpoint.

NFRegistration or NFUpdate

NRF REST Endpoint

  1. As soon as the NRF boots up, it prepares and send the registration request to the NRF whose address is configured as part of the Ops Center configuration.

  2. For the initial registration and for every interval of nrf-get-update-timer, rest-endpoint sends the request to get the updated records from the nrf-service.

  3. Once it gets the response, it fills the nrfInfo and other required fields, for example, snssai, nsi.

  4. After preparing the update message, it sends the NRF update to the parent NRF if there is a change in NRF profile with last time it had sent.

  5. At any time, if registration or heart-beat fails with the primary NRF, it tries to connect to the secondary NRF if it’s configured as part of the Ops Center configuration.

NRF Service Engine

  1. As soon as nrf-service receives the get request from the nrf rest-endpoint, it gets all the records for the corresponding cdl id

    .

  2. Once it gets all the data, it prepares the nrfInfo based on the records it had retrieved along with snssai and nsi.

  3. After preparing the message, it sends the response to the REST endpoint.

NFStatusSubscribe

NRF REST Endpoint

  1. The NRF Rest endpoint receives the NFStatusSubscribe request over HTTP2/JSON. The HTTP method is POST and the URL is /root/nnrf-nfm/v1/subscriptions. The body of request message contains the SubscriptionData in JSON format.

Note: The default value, /root, is a configurable parameter.

  1. On receiving the request, it is validated to check whether the mandatory field is present, and the parameters and their values and types are valid. If the validation fails, the response is sent with status 400 Bad Request.

  2. The NFStatusSubscribe request is transformed into Protobuf format and sent toward the service engine for processing.

  3. On receiving the request from NRF Service pod, the NRF Rest Endpoint creates an HTTP2/json message.

  4. If the received request contains the target NRF URI, the rest endpoint initiates the request with the URI (while sending to child NRF).

  5. If the received request doesn’t contain the target NRF URI, the rest endpoint prepares the URI by taking the URI of the NRF to which the current NRF has registered and initiates the request with the URI (while sending to parent NRF).

  6. It sends back the response to NRF Engine as received from the parent or child NRF.

NRF Service Engine

  1. On reception of the request from the NRF Rest endpoint, it checks if any profile matches with the provided subscrCond with nfIsnatanceIdCond in the SubscriptionData.

  2. If no profile found matching the subscrCond locally, it checks the nrfInfo of registered NRFs to derive the child NRF whether the nfInstanceId is present or not.

  3. If nfInstanceId is present in any nrfInfo, it prepares the URI using the services of that nrfProfile and fill the target NRF before sending the SubscriptionRequest to the Rest endpoint.

  4. If nfInstanceId is not present in any nrfInfo, sends the SubscriptionRequest to the Rest endpoint.

  5. After receiving the success or failure response from the Rest endpoint, NRF service endpoint responds to the earlier requested message received from the rest endpoint.

Call Flows

The following sections describe the call flows that is associated with this feature.


Note

In a hierarchical NRF (multi-NRF) deployment, the NF discovery and subscription messages are a part of the outgoing messages, which are forwarded between the child and parent NRF.

NRF as Child Node with Forwarding

NFStatusSubscribe Success Call Flow

This section describes the successful NFStatusSubscribe call flow for an NRF functioning as a child node with forwarding.

Figure 1. NFStatusSubscribe Success Call Flow
NFDiscovery Success Call Flow

This section describes the successful NFDiscovery call flow for an NRF functioning as a child node with forwarding.

Figure 2. NFDiscovery Success Call Flow

NRF as Parent Node with Forwarding

NFStatusSubscribe Success Call Flow

This section describes the successful NFStatusSubscribe call flow for an NRF functioning as a parent node with forwarding.

Figure 3. NFStatusSubscribe Success Call Flow
NFDiscovery Success Call Flow

This section describes the successful NFDiscovery call flow for an NRF functioning as a parent node with forwarding.

Figure 4. NFDiscovery Success Call Flow

Configuring the NRF Hierarchy and Multiple NRF Support Feature

The following sections describe how to configure the NRF Hierarchy and Multiple NRF Support feature.

Pre-requisite

To forward subscription or discovery from child NRF to the parent NRF or from parent NRF to child NRF, child NRF must be registered with the parent NRF.

NRF Ops Center Configuration

This section describes the configuration parameters for this feature.

  1. nrfClient configuration provides the NRF server endpoint configuration for NRF to NRF registration. See a sample CLI configuration below. 

    group nf-mgmt group_name 
nrf-mgmt-group group_name 
locality locality_name 
heartbeat interval interval_period (in seconds) 
exit
group nrf discovery group_name 
nrf-type SHARED
service type nrf nnrf-disc
endpoint-profile
name endpoint_profile_name 
uri-scheme http
version
uri-version uri_version_number ('v' concatenated with a number) 
full-version full_version_number 
exit
exit
endpoint-name endpoint_name 
priority priority_number 
primary ip-address ipv4 or ipv6 IPv4 or IPv6_address 
primary ip-address port port_number 
secondary ip-address ipv4 or ipv6 IPv4 or IPv6_address 
secondary ip-address port port_number 
exit
exit
exit
exit
group nrf mgmt group_name 
nrf-type SHARED
service type nrf nnrf-nfm
endpoint-profile
name endpoint_profile_name 
uri-scheme http
version
uri-version uri_version_number ('v' concatenated with a number) 
full-version full_version_number 
exit
exit
endpoint-name endpoint_name 
priority priority_number 
primary ip-address ipv4 or ipv6 IPv4 or IPv6_address 
primary ip-address port port_number 
secondary ip-address ipv4 or ipv6 IPv4 or IPv6_address 
secondary ip-address port port_number 
exit
exit
exit
exit

    Note

    The child NRF uses heartbeat messages to detect the failure of a parent NRF. The maximum time to detect a failure of the parent NRF and switch to a secondary NRF depends on the configured heartbeat timer value. This condition might cause failure in message forwarding until the switch-over happens. To reduce the number of such failures, configure a lower heartbeat timer value between the child and parent NRF.

    The suggested heartbeat time interval between the NRF child and parent is 10 seconds.

    For more information, contact your Cisco Account representative.

  2. Configuration parameter nrf-hierarchy-enabled for enabling or disabling the nrf hierarchy feature for both discovery and subscription. By default, it is disabled.

  3. nrf-get-update-timer is the interval in which nrf-rest endpoint gets the updated records from the nrf-service to send the NRF update to the parent NRF. The default value is 60 seconds.

  4. Forwarding policy for forwarding the discovery to its parent NRF is driven by following configuration parameters. The nf-type corresponds to the target-nf-type of discovery query parameter. See a sample CLI configuration below. 

    nrf-profile profile-settings policy UDM
check-and-send true
rule nf-info-query external-group-identity
exit
rule nf-info-query gpsi
exit
rule nf-info-query group-id-list
exit
rule nf-info-query routing-indicator
exit
rule nf-info-query supi
exit
rule snssai-type 1
sst 2
sd ABF123
exit
rule nsi nsi-100
exit
exit

Note

For forwarding of discovery request to its parent NRF, above mentioned policy should be provided along with the nrf-hierarchy-enabled flag as true. When provided, it forwards all the discovery request for the respective nfType if the check-and-send flag is disabled. If check-and-send flag is enabled in the discovery forwarding policy, then the NRF forwards the discovery request only when it does not find any profile matching the query parameter locally and the discovery query parameter contains at least one parameter mentioned in the policy rule.