How it Works

The SMF follows this sequence for NF selection:

  1. It looks up the local cache (NF discovery response cache) for the NF

  2. If the NF is a valid entry (not expired), it uses that entry. Else, SMF proceeds to Step 3.

  3. The SMF reaches NRF for discovery [see, NRF Discovery (Priority 1)]. Else, SMF moves to Step 4.

  4. If SMF cannot use the NRF for discovery, it uses the expired NF cache [see, Expired NF Cache ( Priority 2)]. If expired NF cache is not available, SMF moves to Step 5.

  5. If SMF does not find the NF in the local cache nor is it able to get it in the NRF discovery response, it uses the locally-configured NF [see, NF Local configuration (Priority 3)].

The priority order for NF selection is as follows:

  1. NRF Discovery (Priority 1)

    The SMS uses the NRF-provided, NF discovery service to discover NFs like AMF, UDM, and PCF. The SMF sets the preferred locality as provided in the "profile nf-pair " configuration in the discovery query. (For more details about the "profile nf-pair nf-type " CLI configuration, see Configuring Locality for NF Types in the NRF Interface per Endpoint section.) For each NF, the query parameters are configurable. (For more details, see Configuring Network Element Profile Parameters for the NFin the NRF Interface per Endpoint section) The NRF returns all the NFs matching the query criteria. When present, the NRF prefers NF profiles with a locality attribute that matches the preferred-locality. The NRF could return more NFs in the response, which are not matching the preferred target NF location. This occurs when there is no NF profile that is found matching the preferred target NF location. To avoid this, the NRF could set a lower priority for any additional NFs on the response not matching the preferred target NF location than those matching the preferred target NF location. The locality-aware NF selection logic of SMF is as follows:

    1. If the NF has both the preferred and geo locality server configurations, all the NFs in the response that are matching these are cached. SMF ignores the balance NFs. The load-balancing logic first selects the preferred locality NFs. If the preferred locality NFs fail, SMF picks the geo locality NFs for a retry. If N retry is allowed, N-1 retries are on the preferred locality and the last retry is on the geo locality NF. If the N-1 endpoints are unavailable in the preferred locality, SMF attempts all the endpoints of the preferred locality. Else, SMF picks up the geo locality endpoints for the remaining retries. Multiple retries on the same host (port) is not attempted.

    2. If the NF has only the preferred locality configuration, all the NFs in the response that match the preferred locality are cached. The load-balancing logic selects the endpoints from these NFs.

    3. If the NF does not have the preferred locality or geo locality configuration, then SMS caches all the discovery response NFs. The load-balancing logic selects from these NFs.

      Note
      • The load-balancing logic is based on priority, capacity, and load. The logic is similar to server selection as defined in IETF RFC 2782. But the weight is considered as "capacity * (100 - load)".

      • If SMF selects the NRF-discovered NFs (in any of the three cases), even when all attempts to reach preferred and geo locality fail, the SMF does not fall back to the local configuration NFs for a retry.

  2. Expired NF Cache (Priority 2)

    The SMF performs an NF discovery only in the following scenarios:

    • If the matching entries are not present for the query filter in its NF discovery cache

    • If matching entries are present in its NF discovery cache but the validities of these entries have expired

      The retention of an expired cache entry is configuration-based. If the expired cache entry is present and the NRF is not reachable or returns an error, then SMF uses the expired cache entry for NF selection. You can configure the SMF to control the cache entry usage with the following options:

      • Invalidate the cache entry on expiration of validity.

      • Use the invalidated cache entry for a configurable time period (timeout) and fallback to the static configuration after the timeout expires.

      Note

      The SMF controls the cache entry usage - only when the NRF is down - through these options. The configurations are based on the profile nf-pair . Additionally, the SMF provides flexibility in configuring different cache usage rule for different NFs. For instance, the SMF always uses the expired cache to discover PCF when the NRF is down. But, for discovering the UDM, the SMF uses the expired cache for a timeout period of 10 milliseconds (ms) when the NRF is down.

  3. NF Local Configuration (Priority 3)

    The locally configured NFs are the last option for NF endpoint selection. (For more details, see the Local Configuration for NF Management section.) The local configuration too considers the preferred and geo server locality for NF selection. The priority order is as follows:

    1. If the preferred server is configured for the NF [ in profile nf-pair ], SMF selects the NF endpoints under the preferred locality, first. The load-balancing logic is applicable for endpoint profiles and endpoints within the locality as per the configured priority and capacity values.

    2. If the geo locality is configured for the NF [ in profile nf-pair ], SMF selects the NF endpoints under the geo locality as the fallback option. That is, if the preferred server locality NF endpoints fail or preferred server locality endpoints are not configured. The load-balancing logic is applicable for endpoint profiles and endpoints within the locality as per the configured priority and capacity values.

    3. If the preferred server and geo locality server are not applicable, SMF picks up the locality based on the priority that is configured for each locality in the local NF configuration. The load-balancing logic is applicable for endpoint profiles and endpoints within the locality as per the configured priority and capacity values.

      Note

      The priority under locality is applicable only if the preferred and geo locality servers are not applicable.

      The failure template is configurable for each of the NFs. Also, the message type in the template can set the retry count and action for the possible HTTP return codes. For a sample configuration, see the Configuring the Fallback to Static IP Address Support Feature section.