H NF Distribution Guidelines between NRF Instances for Single-set and Multi-set based Deployments

NF Consumers generate discovery traffic toward the NRF. Both NF Consumers and NF Producers generate NRF management and NF Access token traffic. As the networks scale by adding NFs, supporting more traffic, or transitioning from single-set to multi-set georedundancy deployments, NF distribution can become uneven. Due to this, certain NRF sites or sets may reach an overload condition, leading to performance variations.

This section provides the guidelines to define a structured approach for assigning Network Functions (NFs) to NRF instances and NRF sets for achieving balanced traffic distribution, efficient resource utilization, and resilience in both single-set and multi-set deployments (using the Growth feature).

In a single-set deployment, all NRF instances operate as one logical entity, and all NFs register and perform service discovery within that same set. When deployed across multiple geographic sites, geo-redundancy ensures service availability during site failures, while georeplication synchronizes NF registration data between sites. This model maintains a unified logical architecture while providing high availability and consistent discovery behavior.

In a multi-set deployment, all NRF instances operate as one logical entity which are organized into multiple logical sets, and all NFs register to a specific set and perform service discovery across the sets. When deployed across geographic sites, geo-redundancy ensures availability of each individual set. If georeplication is enabled it maintains data consistency within that set. For more details about multi-set deployment, see Enhanced NRF Set Based Deployment (NRF Growth).

The following NF distribution guidelines are defined to ensure balanced and resilient deployments.

  • Distribution based on NF
    • Single-set: Distributing NF Consumers and NF Producers between the NRF instances in the set so that Ingress traffic (management, discovery, and access token) towards each NRF instance remains balanced.

      For example, NF-1, NF-2, and NF-3, which belong to same nfSet should be configured with distinct NRFs of an NRF set (NRF-A, NRF-B and NRF-C) as their primary NRF so that the traffic generated towards the NRFs by the NFs remains balanced. That is, NF-1's primary NRF is NRF-A, NF-2's primary NRF is NRF-B and NF-3's primary NRF is NRF-C.

    • Multi-set: Distributing NF Consumers and NF Producers between the NRF instances across multiple NRF sets so that the Ingress traffic (management, discovery, and access token) towards each NRF set remains balanced.
      For example:
      • 4 NFs in a single set - 2 in first set and 2 in second set.
      • 3 NF in a single set, 2 in first set and 1 in second set.

        Note:

        This does not provide an even distribution but a better distribution with respect to resiliency.
      • Multiple NF sets, and each set having 3 or 4 NFs, distribute the NFs in such a way that all the NF counts remain balanced across each NRF instance.
  • Distribution based on Traffic

    If NFs in a set have different capacities and NFs are not generating the same quantum of traffic, then while distributing them in different NRF instances, the quantum of traffic has to be considered so that the traffic distribution between the NRF instances remains balanced.

    • Single-set: Distributing NF Consumers and NF Producers between the NRF instances in the set based on the traffic quantum generated by each NF, so that the ingress traffic towards each NRF instance remains balanced even when NFs produce unequal traffic.

      For example: NF-1, NF-2, and NF-3 which belongs to the same nfSet generate different ingress traffic towards NRF (that is, NF-1 generates high traffic, NF-2 generates medium traffic, and NF-3 generates low traffic). They should be configured with Primary NRFs in a way that balances the overall traffic per NRF instance rather than distributing NFs evenly by count.

      For example, configure:
      • NF-1’s Primary NRF as NRF-A
      • NF-2’s Primary NRF as NRF-B
      • NF-3’s Primary NRF as NRF-B (or NRF-C, depending on NRF capacity or target balance)
      so that the combined traffic directed towards each NRF instance remains balanced (for example, Do not place the high-traffic NFs on the same NRF instance).
    • Multi-set: Distributing NF Consumers and NF Producers between the NRF instances across multiple NRF sets based on the traffic quantum generated by each NF, so that the ingress traffic towards each NRF set (and NRF instances within the sets) remains balanced, even when NFs have different capacities and generate different traffic volumes.
      For example, consider two NRF sets (different failure domains), each with three NRF instances:
      • NRF Set-1: NRF-A, NRF-B, NRF-C
      • NRF Set-2: NRF-D, NRF-E, NRF-F
      Assume there are six NFs in the same nfSet, each generating different ingress traffic like (management, discovery, access-token):
      • NF-1: high traffic
      • NF-2: high traffic
      • NF-3: medium traffic
      • NF-4: medium traffic
      • NF-5: low traffic
      • NF-6: low traffic
      They should be configured with Primary NRFs based on traffic quantum so that the total ingress traffic per NRF set (and per instance within the set) stays balanced and should not be split by NF count.
      For example, configure Primary NRFs as:
      • NF-1 → NRF-A (Set-1)
      • NF-2 → NRF-D (Set-2)
      • NF-3 → NRF-E (Set-2)
      • NF-4 → NRF-B (Set-1)
      • NF-5 → NRF-C (Set-1)
      • NF-6 → NRF-F (Set-2)
      This spreads the high traffic NFs across different NRF sets, and places the medium or low traffic NFs to keep the overall ingress load balanced across both NRF sets and their instances.
  • Multi-Set Awareness

    This focuses on deploying and configuring NRF to avoid distributing all NF registrations and discovery traffic within a single NRF set or failure domain. It improves resiliency and continuity by spreading NF Consumers and NF Producers across multiple NRF sets (and their instances). With this approach, an NRF instance or full set failure impacts only a subset of NFs, while the remaining NFs continue operating via other NRF sets.

    • Single-set: Multi-set awareness requires spreading NFs across multiple NRF sets and failure domains, which is not possible in a single-set deployment.
    • Multi-set: NF Consumers and NF Producers are distributed across NRF sets (and instances) so that NFs are split across multiple failure domains. Configure Primary (and Secondary or alternate) NRF associations such that NFs are not concentrated in one set, and ensure failover paths exist to another NRF set if an instance or an entire set becomes unavailable.
      For example: Consider a scenario where instances within an NF set (such as, NF1, NF2, and NF3 from NF set 1) are distributed across two NRF GR sets:

      Note:

      • As part of this distribution, ensure Primary, Secondary and Tertiary NRFs for an NF are configured with NRFs of a single set and does not spread across multiple NRF Sets.
      • Incase, Virtual FQDN is configured for NRF, ensure the resolved Primary, Secondary and Tertiary NRFs belongs to a single NRF Set.

      Figure H-1 Multi Set Awareness


      Multi Set Awareness

      • NF1 is primarily mapped to NRF121 (part of NRF GR set 2), with secondary and tertiary fallback options pointing to NRF122 and NRF123 in the second set.
      • NF2 is mapped primarily to NRF112 (in NRF GR set 1), with fallback options to NRF113 and NRF111 in the first set.
      • NF3 follows a similar mapping, with primary and backup associations distributed across both NRF GR sets.

      This distribution ensures that if an entire NRF GR set fails, only part of the NF set is affected, while the remaining instances connected to other NRF GR sets continue operating.