The SMF provides CLI for configuring NRF endpoints for nnrf-nfm (NF Management).

Note	For NF management, you can configure only the nnrf-nfm service.

The CLI configuration allows configuring multiple endpoints under each endpoint profile. The SMF uses the priority and capacity parameters to load balance between these endpoints. Primary, secondary, and tertiary hosts [ip:port] can be configured within each endpoint. Both IPv4 and IPv6 addresses can be specified. If both are specified, then the IPv4 address is preferred.

A URI uniquely identifies a resource. In the 5GC SBI APIs, when a resource URI is an absolute URI, its structure is specified as follows:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart} 

Note	In this release of the specification, both HTTP and HTTPS scheme URIs are allowed. See the 3GPP TS 33.501, subclause 13.1 for more information on security of service-based interfaces.

" apiRoot " is a concatenation of the following parts: scheme ("http" or "https")

• fixed string "://"

• authority (host and optional port) as defined in IETF RFC 3986

• an optional deployment-specific string (API prefix) that starts with a "/" character [api-root in CLI]

To configure the NRF endpoints for different services supported by NRF, use the following sample configuration.

config 
   group nrf mgmt mgmt_name  
      service type nrf nnrf-nfm  
         endpoint-profile epprofile_name 
            priority priority_value 
            capacity capacity 
            api-root api_string 
            api-uri-prefix uri_prefix_string 
            uri-scheme { http | https } 
            endpoint-name ep_name { capacity capacity | primary ip-address 
            { ipv4 ipv4_address | ipv6 ipv6_address | port port_num}  
            | secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address 
            | port port_num } | tertiary ip-address { ipv4 ipv4_address 
            | ipv6ipv6_address | port port_num } } 
            version [ uri-version version_num full version version_num ] 
            end 

NOTES:

• group nrf mgmt mgmt_name : Show the NRF self-management group configurations.

• api-root api_string : Specify the deployment-specific service API prefix that is used within the { apiRoot }.

• api-uri-prefix uri_prefix_string : Specify the {apiName}. If not configured, it takes the standard API name for the service as per the specification.

• capacity capacity : Specify the profile capacity.

• endpoint-name ep_name { capacity capacity | primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } } : Specify the endpoint name. You can configure the primary, secondary, and tertiary hosts (IP: Port) within each endpoint for NF server failover handling. The server failover configuration accepts both the IPv4 and IPv6 addresses. However, the SMF gives preference to the IPv4 address.

• capacity capacity : Specify the node capacity for the endpoint. capacity must be an integer in the range of 0-65535.

• The endpoint selection for sending the message is based on probabilistic load-balancing algorithm (IETF RFC 2782) using the priority and capacity parameters.

• primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the primary endpoint IPv4 address, IPv6 address, or port.

• secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the secondary endpoint IPv4 address, IPv6 address, or port.

• tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the tertiary endpoint IPv4 address, IPv6 address, or port.

• priority priority_value : Specify the priority for the service to select the appropriate profile using the load-balancing logic. priority must be an integer in the range of 0-65535.

• uri-scheme { http | https } : Specify the URI scheme as http or https .

• version [ uri-version version_num full version version_num ] : Specify the api/version. The full version format is <Major-version>.<Minor-version>.<patch-version>.[alpha-<draft-number>].

The SMF supports the deregistration of Network Function (NF) Repository Function (NRF), wherein the NF deregister service operation of the SMF removes the profile of a network function that is registered in the NRF.

The SMF starts the NF deregister service operation in the following scenarios:

• When the Service Based Interface (SBI) endpoint is not configured and all the rest endpoints stop functioning.

• When all the configured SBI endpoints VIP IP and N11 VIP IPs are offline.

Note	SMF can't perform NRF deregistration when all the REST endpoints abruptly stop functioning. Only the REST endpoints can perform registration or deregistration of NRF.

The NF deregister service operation deletes the specific resource based on its NF instance ID. The NF deregistration starts when the Uniform Resource Identifier (URI) receives a request to delete a specific NF instance.

The recommended SMF shutdown process involves the following steps:

1. All N11 and SBI VIP IPs are marked as offline. After these endpoints appear offline, the NF deregistration request is sent to the NRF. The NRF notifies the peer NFs, such as AMF, about the SMF shutdown and its unavailability for traffic.

2. Wait for a grace period to allow convergence and perform a "system mode shutdown" to stop all the pods.

When the endpoint SBI is not configured, the system deletes the rest-ep pod immediately and avoids proper convergence. Implementing the system mode shutdown without taking the SBI and N11 VIP IPs offline also avoids convergence.

The NF Heartbeat feature enables the NFs to notify the NRF that the NF is operational. Each NF registered with the NRF contacts the NRF periodically by invoking the NF Update service operation. The time interval at which the NRF is contacted is deployment-specific and is returned by the NRF to the SMF as a result of a successful registration.

SMF sends the NF status and load parameter as part of NF heartbeat to NRF. SMF provides a CLI to configure the interval between periodic NF heartbeat. If the heartbeat value is configured in the NF registration response, the same value is used instead of another configured value.

This section describes how to configure the NRF heartbeat interval.

config 
   group nf-mgmt nf_mgt_name 
      hearbeat interval  hearbeat_interval 
   end 

NOTES:

• group nf-mgmt nf_mgt_name : Specify the group name of NF management.

• hearbeat interval hearbeat_interval : Specify the interval of hearbeat between the heartbeats. The value of heartbeat interval is in seconds.

  Note	If NRF returns a different heartbeat interval value as part of NF registration response or heartbeat response, the same value is used for subsequent heartbeats.

The SMF uses the NRF-provided Subscription service to subscribe to NF status changes that the NF receives as a discovery response. This feature helps in updating the cached NF discovery responses.

The SMF honors only the notification changes in load, capacity, status at the NF level, and at the service level. It ignores all other parameter changes in the notification.

After the successful subscription for notification service, the SMF receives notifications of registration and deregistration of NF Instances, or notifications of NF profile changes for a given NF Instance.

The SMF supports the "NFProfile" field and "ChangeItem" field in the "NotificationData". If the notification event type is set to "NF_PROFILE_CHANGED", the SMF receives notification about the profile-level changes or a list of individual change items for the NFProfile parameters along with nfInstanceUri.

The "ChangeItem" field includes the following parameters:

• op—Indicates the type of change that happens to the resource.

• path—Contains the JSON pointer value which indicates the target location within the resource.

• from—Indicates the path of the JSON element that is moved or copied to the location indicated by the "path" attribute. It is present if the "op" attribute is of value "MOVE".

• origValue—Indicates the original value at the target location within the resource specified in the "path" attribute.

• newValue—Indicates a new value at the target location within the resource specified in the "path" attribute.

Note	The SMF currently supports only the ADD, REPLACE, and REMOVE operations as part of the "op" parameter.

The following is an example of the notification payload sent from the NRF when an NF instance has changed its profile by updating the IP address value and the TCP port for the first endpoint of the first NF service.

Example 1:

{
  "event": "NF_PROFILE_CHANGED",
  "nfInstanceUri": ".../nf-instances/4947a69a-f61b-4bc1-b9da-47c9c5d14b64",
  "profileChanges": [
    {
      "op": "REPLACE",
      "path": "/nfServices/0/ipEndPoints/0/ipAddress", ===> Change ipAddress to ipv4Address
      "newValue": "209.165.201.10"
    },
    {
      "op": "REPLACE",
      "path": "/nfServices/0/ipEndPoints/0/port",
      "newValue": 8080
    }
  ] 

Example 2:

{
"event": "NF_PROFILE_CHANGED",
"nfInstanceUri": ".../nf-instances/4947a69a-f61b-4bc1-b9da-47c9c5d14b64",
"nfProfile": <Newly updated complete profile> 
} 

This feature uses the NF Subscribe service to subscribe to changes on the status of NF instances that the NF receives as discovery responses. The SMF sends a subscription for the response validity period for each of the NF profiles that it receives in the discovery response. The SMF checks if an existing NF instance subscription time needs an extension or not depending on the current response time validity. If a subscription needs an extension, a subscription PATCH is sent with the extended validity time.

During subscription, the NRF may respond with a modified validity time. This validity time might differ from the SMF validity time request. In such a scenario, the SMF tracks the required subscription time and the actual subscription time returned by the NRF.

The SMF periodically (every two minutes) checks in database if there is any subscription with the actual subscription time ending soon (as in next five minutes) but has required validity time more than the actual validity time. In this scenario, the SMF sends a PATCH subscription to extend the subscription validity time.

The SMF fills the Status Notification URI based on the interface NRF configuration that is specified in the configuration. The notification VIP IP and VIP port are used to frame the status notification URI.

http://{nrfinterface.vip-ip}:{ nrfinterface.vip-port}/{notifResourceURI} 

On status notification, the SMF updates the local cache and the external cache (cache pod) with the changed attributes.

This section describes how to configure the NRF for subscription and notification.

Note	For the subscription and notification to work, it is mandatory to configure the NRF interface within SBI interface.

When discovery is done with NRF, a subscription message for the discovered NF instances is sent. The SMF fills the Status Notification URL based on the NRF interface configuration that is specified in the configuration. The notification VIP IP and VIP port are used to frame the status notification URL. The SMF uses the URL that is included in the subscription request message for status notifications.

To configure the NRF interface, vip-ip, vip-port, and loopback port to open the server endpoints for the NF status notification, use the following sample configuration.

config 
   instance instance-id gr_instance_id 
      endpoint sbi 
         replicas replica_num 
            vip-ip ip_address 
         interface nrf 
            vip-ip ip_address 
            vip-port port_number 
            loopbackPort port_number 
            end 

NOTES:

• interface nrf : Specify the interface as NRF.

• vip-ip ip_address : Specify the virtual IP address of the virtual host. The SMF uses this as the listening IP address for the status notification.

• vip-port port_number : Specify the port number of the virtual host. The SMF uses this as the listening port for the status notification.

• loopbackPort port_number : Specify the internal port number of the loopback host. The SMF uses this port for the NF status notification.

This feature complies to 3GPP TS 29.510, Version 16.4.0.

The SMF invokes the NF Update service operation when there are changes to the NF registration parameters due to the SMF profile configuration change.

The NF Update service updates the NF profile that was previously registered in the NRF by providing the updated profile of the requesting NF to the NRF.

The update operation can be one of the following:

• A whole NF profile update (complete replacement of the existing profile with a new profile)

• An update to only a subset of the NF profile parameters (adding, deleting, or replacing services to the NF profile)

This section describes the NF profile update procedure.

This section describes the call flow associated with this feature.

The NF Discovery feature complies with the following standards:

• 3GPP TS 29.510 version 15.4.0 (2019-07) – 5G; 5G System; Network function repository services; Stage 3

The NRF Discovery feature has the following limitations:

• The cache maintained is local to the library. In case of deployment with multiple replicas of REST-EP, if two Discovery or Send messages with the same discovery filter land on different pods, then both the pods trigger NF discovery.

• This feature supports only the UDM, PCF, CHF, and AMF discovery, and load balancing. It does not support UPF discovery.

To register an NRF, use the following sample configuration.

config 
nssai name nssai_name 
    sst sst ssd ssd 
    dnn dnn_name_value  
    end 

NOTES:

• nssai name nssai_name : Configure the NSSAI name value for the slice. The nssai_name value must be a string.

Note	SMF supports a maximum of 512 slices to be sent toward NRF.

Configuration Example

The following is an example configuration of the NRF registration.

nssai name slice1  
 sst 02
 sdt Abf123
 dnn [ dnn1 intershat intershat1 intershat2 intershat3 intershat4 intershat5 intershat6 intershat7 starosupf ]
exit

nssai name slice2  
 sst 02
 sdt Abf124
 dnn [ dnn1 intershat intershat1 intershat2 intershat3 intershat4 intershat5 intershat6 intershat7 starosupf ]
exit

To configure the NRF discovery, use the following sample configuration:

config 
   profile network-element [ amf amf_profile_name| chf chf_profile_name | pcf pcf_profile_name | udm udm_profile_name | upf upf_profile_name ] 
      query-params requester-snssais 
      exit 

NOTES:

• query-params requester-snssais : Specify the list of Single Network Slice Selection Assistance Information (S-NSSAIs) as the query parameter in the NF discovery request towards the NRF.

Configuration Example

The following is an example configuration.

config
   profile network-element udm udm1
      query-params requester-snssais
      exit
   profile network-element pcf pcf1
      query-params requester-snssais
      exit
   profile network-element chf chf1
      query-params requester-snssais
      exit
   profile network-element upf upf1
      query-params requester-snssais
      exit
   profile network-element amf amf1
      query-params requester-snssais
      exit

To configure the NF endpoints for AMF, CHF, PCF, and UDM, use the following sample configuration:

config 
   profile nf-client { nf-type { amf amf-profile | chf chf-profile | pcf pcf-profile | udm udm-profile } nf_profile_name } 
   end 

NOTES:

• profile nf-client { nf-type { amf amf-profile | chf chf-profile | pcf pcf-profile | udm udm-profile } nf_profile_name } : Specify the required NF client profiles and provide the local configuration for any of the following configured NFs:

  • amf : Enable the AMF local configuration

  • chf : Enable the CHF local configuration

  • pcf : Enable the PCF local configuration

  • udm : Enable the UDM local configuration

    For example, if you are configuring the amf amf-profile keyword, this command enables the AMF local configuration. The same approach applies for the other configured NFs.

    nf_profile_name must be an alphanumeric string representing the corresponding NF client profile name.

• You can configure multiple NF profiles within a given service.

• To disable the configuration, use the no profile nf-client { nf-type { amf amf-profile | chf chf-profile | pcf pcf-profile | udm udm-profile } nf_profile_name } command.

To pair a discovery group with NF types, use the following sample configuration.

config 
   profile nf-pair nf-type nf_type 
      nrf-discovery-group nrfdisc_group_name 
      end 

NOTES:

• nf-type nf_type : Specify the NF client type value as SMF.

• nrf-discovery-group nrfdisc_group_name : Specify the NRF discovery group name. Discovery group is the logical link to the NRF endpoint groups (nrf-group). For each NF type, you can associate a discovery group and the locality information.

The SMF provides CLI for configuring NF endpoints for nnrf-nfd (NF discovery).

Note	For a discovery group, you can configure only the nnrf-disc service.

The CLI configuration allows configuring multiple endpoints under each endpoint profile. The SMF uses the priority and capacity parameters to load balance between these endpoints. All endpoints under an endpoint profile share the session context. That is, when selecting an endpoint profile for initial message of a session, then the SMF sends the subsequent messages (for example, update, delete, and so on) of the session to any of the endpoints in the endpoint profile.

Primary, secondary, and tertiary hosts [ip:port] can be configured within each endpoint. Both IPv4 and IPv6 addresses can be specified. If both are specified, then the IPv4 address is preferred.

SMF provides APIs to discover and send a message to an NF matching a set of filter parameters.

A URI uniquely identifies a resource. In the 5GC SBI APIs, when a resource URI is an absolute URI, the structure is specified as follows:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart} 

apiRoot is a concatenation of the following parts:

• scheme ("http" or "https")

  Note	Both HTTP and HTTPS scheme URIs are allowed. See the 3GPP TS 33.501, subclause 13.1 for more information on security of service-based interfaces.

• fixed string "://"

• authority (host and optional port) as defined in IETF RFC 3986

• an optional deployment-specific string (API prefix) that starts with a "/" character [api-root in CLI]

To configure the NRF endpoints for different services supported by NRF, use the following sample configuration:

config 
   group nrf discovery discovery_name 
      service type nrf nnrf-disc  
         endpoint-profile 
            name  epprofile_name 
            api-root api_string 
            api-uri-prefix uri_prefix_string 
            uri-scheme { http | https } 
            endpoint-name ep_name { capacity capacity | primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address| port  port_num } | tertiary ip-address { ipv4 ipv4_address| ipv6 ipv6_address | port port_num } } 
            version [ uri-version version_num full version version_num ] 
            end 

NOTES:

• group nrf discovery discovery_name : Configure the NRF discovery group.

• api-root api_string : Specify the deployment-specific service API prefix that is used within the { apiRoot }.

• api-uri-prefix uri_prefix_string : Specify the {apiName}. If not configured, it takes the standard API name for the service as per the specification.

• endpoint-name ep_name { capacity capacity | primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } } : Specify the endpoint name. You can configure the primary, secondary, and tertiary hosts (IP: Port) within each endpoint for NF server failover handling. The server failover configuration accepts both the IPv4 and IPv6 addresses. However, the SMF gives preference to the IPv4 address.

  • capacity capacity : Specify the node capacity for the endpoint. capacity must be an integer in the range of 0-65535.

  • The endpoint selection for sending the message is based on probabilistic load-balancing algorithm (IETF RFC 2782) using the priority and capacity parameters.

  • primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the primary endpoint IPv4 address, IPv6 address, or port.

  • secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the secondary endpoint IPv4 address, IPv6 address, or port.

  • tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the tertiary endpoint IPv4 address, IPv6 address, or port.

  • priority priority_value : Specify the priority for the service to select the appropriate profile using the load-balancing logic. priority must be an integer in the range of 0-65535.

• uri-scheme { http | https } : Specify the URI scheme as http or https .

• version [ uri-version version_num full version version_num ] : Specify the API URI version. The full version format is <Major-version>.<Minor-version>.<patch-version>.[alpha-<draft-number>].

The SMF provides locality aware NF discovery.

A pair profile has the locality values configured with NF type as SMF. A locality has the following values:

• client—Specify the client locality information.

• geo-server—Specify the geo-service locality information.

• preferred-server—Specify the preferred server locality information.

For a profile selection, only the preferred-server and geo-server locality values are considered. Following are the scenarios of these locality values configuration:

• If both the preferred-server and geo-server locality values are configured, then the profiles, which exist in discovery response, matching these locality values are selected. In addition, the profiles with empty locality value are selected. Any other profile with locality other than preferred-server and geo-server locality values are not considered.

• If only the preferred-server locality value is configured, then the profiles, which exist in discovery response, matching this value is selected. In addition, the profiles with an empty locality value are selected. Any other profile with locality other than preferred-server locality value is not considered.

• If only geo-server locality value is configured then the profiles, which exist in discovery response, matching this geo-server locality value is selected. In addition, the profiles with empty locality value is selected. Any other profile with locality other than geo-server locality value is not considered.

• If both preferred-server and geo-server locality values are not configured then all the profiles, which exist in discovery response, are selected.

To configure the locality for NF types, use the following sample configuration.

config 
   profile nf-pair nf-type nf_type 
      locality { client client_name | geo-server geoserver_name | preferred-server prefserver_name } 
      end 

NOTES:

• client client_name : Specify the client locality information. Client locality is the SMF locality and is a mandatory parameter.

• preferred-server prefserver_name : Specify the preferred server locality information. The preferred server locality is the locality that should be considered as the locality of preference during the corresponding NF discovery.

• geo-server geoserver_name : Specify the geo-server locality information. The geo-server locality is the geo redundant site for the preferred locality and is generally used as the next best server locality after preferred locality, during NF discovery.

  Note	geo-server geoserver_name is not fully qualified.

To configure the locality for SMF, use the following sample configuration.

This is a mandatory configuration if the SMF performs the NF discovery using the NRF.

config 
   profile SMF SMF_profile_name 
      locality value 
      end 

NOTES:

• locality value : Specify the SMF locality. value must be an alphanumeric string representing the deployed SMF locality. By default, this CLI command is disabled.

• To disable this configuration, use the no locality value command.

To configure the NF profile that the configured Data Network Name (DNN) uses, use the following sample configuration.

config 
   profile dnn dnn_profile_name 
      network-element-profiles { amf | chf | pcf | udm } nf_profile_name 
      end 

NOTES:

• network-element-profiles { amf | chf | pcf | udm } nf_profile_name : Specify one or more NF types, such as AMF, CHF, PCF, and UDM as the network element profile. nf_profile_name must be an alphanumeric string representing the corresponding network element profile name.

• This is an optional configuration. By default, this CLI command is disabled.

• You can configure multiple profiles within a given service.

• To disable the configuration, use the no network-element-profiles { amf | chf | pcf | udm } nf_profile_name command.

This section describes how to define the locality of the NF endpoints. For the NF endpoint selection, the SMF first considers the preferred locality that is configured with the profile nf-pair CLI command. The admin determines the preferred locality based on the proximity of the locality and the network function. The SMF then uses the geo-server locality configurations as the next preferred locality for the NF discovery. For information on the profile nf-pair command, see Configuring Locality for NF Types in the NRF Selection per Peer NF Type section.

The SMF selects the other locality endpoints if the profile nf-pair CLI command does not include the preferred server locality configuration, or if the profile nf-client CLI command does not include the endpoint configured with the preferred server or geo-server locality. For the other locality endpoint selection, the SMF uses the priority configuration within the locality CLI command.

To define the locality of the NF endpoints, use the following sample configuration.

config 
   profile nf-client { nf-type { amf amf-profile | chf chf-profile | pcf pcf-profile | udm udm-profile } nf_profile_name } 
      locality locality_name [ priority priority | service name type service_types { endpoint-profile epprofile_name } ] 
      end 

NOTES:

• locality locality_name : Specify the locality of the NF endpoint. The SMF uses the locality configurations (that is, the preferred server locality and geo-server locality) to select the appropriate NF endpoints.

• priority priority : Specify the priority for the locality configuration.

• service name type service_types : Specify the configured NF service types. The service types vary depending on the configured service.

  • AMF service supports "namf-comm" as peer communication type.

  • PCF service supports "npcf-am-policy-control" as peer communication type.

  • UDM service supports "nudm-sdm" and "nudm-uecm" as peer communication type.

  • SMF service supports "nsmf-pdusession" as peer communication type.

  • EIR service supports "n5g-eir-eic" as peer communication type.

  • NSSF service supports "nnssf-nsselection" as peer communication type.

  • SMSF service supports "nsmsf-sms" as peer communication type.

  • LMF service supports "nlmf-loc" as peer communication type.

  • GMLC service supports "ngmlc-loc" as peer communication type.

  • AUSF service supports "nausf-auth" as peer communication type.

• endpoint-profile epprofile_name : Specify the endpoints at a per NF service level. The NF specific services are available within the locality configuration.

• You can configure multiple endpoints per profile name for the configured NF.

This section describes how to configure the NF endpoint profiles within the service and its associated parameters.

The CLI configuration allows configuring multiple endpoints under each endpoint profile. The SMF uses the priority and capacity parameters to load balance between these endpoints. All endpoints under an endpoint profile share the session context. That is, when selecting an endpoint profile for initial message of a session, then the SMF sends the subsequent messages (for example, update, delete, and so on) of the session to any of the endpoints in the endpoint profile.

SMF provides APIs to discover and send a message to an NF matching a set of filter parameters.

A URI uniquely identifies a resource. In the 5GC SBI APIs, when a resource URI is an absolute URI, the structure is specified as follows:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart} 

apiRoot is a concatenation of the following parts:

• scheme ("http" or "https")

  Important

  Both HTTP and HTTPS scheme URIs are allowed. See 3GPP TS 33.501, subclause 13.1 for more information on security of service-based interfaces.

• fixed string "://"

• authority (host and optional port) as defined in IETF RFC 3986

• an optional deployment-specific string (API prefix) that starts with a "/" character [api-root in CLI]

To configure the NF endpoint profiles within the service and its associated parameters, use the following sample configuration:

config 
   profile nf-client { nf-type { amf amf-profile | chf chf-profile | pcf pcf-profile | udm udm-profile }  nf_profile_name } 
      locality locality_name [ priority priority | service name type service_type ] 
         endpoint-profile epprofile_name 
            api-root api_string 
            api-uri-prefix uri_prefix_string 
            capacity capacity 
            endpoint-name ep_name { capacity capacity | primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num }| secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address| port  port_num } | tertiary ip-address { ipv4 ipv4_address| ipv6 ipv6_address | port port_num } } 
            priority priority_value 
            uri-scheme { http | https } 
            version [ uri-version version_num full version version_num ] 
            end 

NOTES:

• api-root api_string : Specify the deployment-specific service API prefix that is used within the { apiRoot }.

• api-uri-prefix uri_prefix_string : Specify the {apiName}. If not configured, it takes the standard API name for the service as per the specification.

• capacity capacity : Specify the profile capacity.

• endpoint-name ep_name { capacity capacity | primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } | tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } } : Specify the endpoint name. You can configure the primary, secondary, and tertiary hosts (IP: Port) within each endpoint for NF server failover handling. The server failover configuration accepts both the IPv4 and IPv6 addresses. However, the SMF gives preference to the IPv4 address.

  • capacity capacity : Specify the node capacity for the endpoint. capacity must be an integer in the range of 0–65535.

    The endpoint selection for sending the message is based on probabilistic load balancing algorithm (IETF RFC 2782) using the priority and capacity parameters.

  • primary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the primary endpoint IPv4 address, IPv6 address, or port.

  • secondary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the secondary endpoint IPv4 address, IPv6 address, or port.

  • tertiary ip-address { ipv4 ipv4_address | ipv6 ipv6_address | port port_num } : Specify the tertiary endpoint IPv4 address, IPv6 address, or port.

• priority priority_value : Specify the priority for the service to select the appropriate profile using the load balancing logic. priority must be an integer in the range 0–65535.

• uri-scheme { http | https } : Specify the URI scheme as http or https .

• version [ uri-version version_num full version version_num ] : Specify the API URI version. The full version format is <Major-version>.<Minor-version>.<patch-version>.[alpha-<draft-number>].

The Network Repository Function (NRF) deployment can be logically segmented as global, regional, and so on, for a reliable network management. You can accomplish this segmentation by specifying different NRF endpoint groups for the discovery of different network functions.

For example, the SMF interacts with Region 1 NRF endpoints for management and SMF discovery. For UDM, CHF, and PCF discovery, the SMF communicates with the global NRF endpoints.

The following figure illustrates the NRF deployment.

This section describes how to configure the NRF selection per peer NF type.

The SMF provides caching support for discovered caching profiles. It uses the NF discovery (nnrf-disc) function to discover profiles, such as AMF, UDM, PCF, and CHF. The received discovery response is associated with validity time. SMF caches the discovery response and uses the same response for future NF selections until the cache is valid. This caching support helps in reducing the number of NRF interactions during an ongoing session.

The SMF maintains the cache data in a cache pod. It uses the cache pod to share the NF discovery cache across multiple instances of SBI pods. The SBI pod periodically updates the cache pod on receiving an NF discovery response. All SBI pods refresh its cache data periodically with the help of the cache pod.

If a message is sent to an NF that meets a specific criterion, the SMF looks up the cache data for further processing. During a cache lookup:

• On a cache hit without an expired entry, the selected cached NF response sends a message for an endpoint selection.

• On a cache hit with an expired entry, the SMF sends NF discovery requests to the NRF to fetch a new list of NF discovery responses.

• If there is a cache miss, the SMF sends NF discovery request to the NRF to retrieve a new list of NF discovery responses.

The SMF follows a priority order for different NF selection options. The SMF prioritizes the NF discovered from the NRF over the local configuration. The SMF uses the locally configured NFs when the NF discovery response has no valid NFs.

Depending on the deployment, the preferred server and geo locality server are configured for each of the NFs. The general rule is to select NFs in the preferred server locality followed by NFs in the geo locality server in case the preferred server NFs fail.

For each NF, the SMF provides an option to configure preferred and geo server locality through the profile nf-pair parameter. For more details, see Configuring Locality for NF Types in the NRF Selection per Peer NF Type section.

In addition, each NF discovery response comes with associated validity time. The SMF caches this NF discovery response and uses it to fetch subsequent sessions.

The SMF performs the NF discovery in the following conditions:

• The NF discovery response cache has no matching entries.

• The NF discovery response cache has matching entries, but the validity has expired.

The SMF follows this sequence for NF selection if an NRF discovery group is configured:

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 SMF, 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 Selection per Peer NF Type section.) For each NF, the query parameters are configurable. (For more details, see Configuring Network Element Profile Parameters for the NF in the NRF Selection per Peer NF Type section). The NRF returns all the NFs matching the query criteria. When available, 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. However, 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 available for the query filter in its NF discovery cache

   • If matching entries are available in its NF discovery cache. However, these entries have expired validity.

     The retention of an expired cache entry is configuration-based. If the expired cache entry is available 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. 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.

This section describes how to configure the support for Fallback to Static IP Address.