The NF Register and Deregister service operations enable NRF to process the NF registration or deregistration request from any of the NF and store it in, or remove it from, the database.

This section describes how NF Registration and Deregistration feature works.

The NFUpdate service operation enables an NF instance to partially update or completely replace the parameters of its NF profile in the NRF. It also enables an NF instance to add or delete its services.

The NFUpdate feature provides the following functionality:

• NRF handles PATCH request with Add, Delete, and Replace operations for all the service operation parameters.

• NRF validates the PATCH request after receiving it and enables patch operations, which are based on the input parameters, value range, and so on.

• NRF validates the input parameters, which are validated as part of NF Registration.

• NRF uses PUT request to discard and completely replace the old NF profile with a new profile.

• NRF performs the following validations to update an NF profile:

  • The delete operation of mandatory parameters of an NF profile is not allowed.

The update request is a HTTP PATCH request to the resource URI, which contains the NF instance ID. The body of the PATCH request contains the list of operations (add, delete, or replace), which is applied to the NF Profile of the NF instance. These operations may be directed to individual parameters of the NF Profile or to the list of services and their parameters as offered by the NF Instances.

NRF REST Endpoint

1. The NRF Rest endpoint receives the following types of Update requests:

   1. The NF Profile Partial Update request over HTTP2/JSON-PATCH+JSON. The HTTP method is PATCH and the URL is {apiRoot}/nnrf-nfm/v1/nf-instances/{nfInstanceID} and the body contains PATCH data in JSON format.

   2. The NF Profile Complete Update request over HTTP2 request with content type header application/JSON. The HTTP method is PUT and the URL is {apiRoot}/nnrf-nfm/v1/nf-instances/{nfInstanceID}(NFProfile) and the body contains the complete NF profile data in JSON format.

   Note: The default value, {apiRoot}, is a configurable parameter.

2. On receiving the request, NRF validates the input message format. If the validation fails, the response is sent with status 400 (BAD REQUEST).

3. If the validation succeeds, then the NF Profile Partial Update request is transformed into Protobuf format and sent toward the service engine for processing.

4. The service engine sends a response toward the endpoint after processing the request. The response is then transformed from Protobuf format to JSON format.

5. The response is then converted to OpenAPI format and sent toward the NF. If it’s a successful response, then the response message contains the updated NF profile with the status code as 200 (OK). Else, if it’s a failure, the error code is sent back to the client along with problem details.

NRF Service Engine

1. The NRF Service Engine receives the Protobuf-based request from the REST endpoint through the IPC system.

2. On receiving the request, NRF validates the PATCH request.

3. NRF fetches the NF profile based on nfInstanceId as primary key, and then apply the patch locally.

4. If patch operations are successful, then NRF validates the parameters, which are validated as part of NF Registration.

5. If complete NF profile validation (after patch operations) is:

   • Successful - NRF updates the NF profile in DB, and the service engine sends response code 200 (OK) to the REST endpoint along with updated NF profile.

   • Unsuccessful - The service engine sends a response message with an error code to the REST endpoint, which depends on the type of failure:

     • No NF profile is available for given nfInstanceID : 404 (Not Found)

     • Any validation failure: 400 (Bad Request)

     • Invalid path in the PATCH update request - 404 (Not Found)

The NF Heart-Beat service operation enables each NF that has previously registered in NRF to contact the NRF periodically (Heart-Beat). The NF invokes the NFUpdate service operation, in order to show that the NF is still active.

The NF Heart-Beat feature provides the following functionality:

• NRF handles NF Heart-Beat PATCH Requests with Replace operation for the following parameter:

  • nfStatus

• NRF handles the start, restart, and expiry for Heart-Beat timer.

• NRF configures the Hear-Beat timer differently for the NFs with different NF types.

• NRF configures the Heart-Beat service operation with the default level as NF type. If the service operation is not configured as NF type, then NRF configures the Heart-Beat timer as global.

• If NRF modifies the Heart-Beat interval value of any registered NF instance, it returns the new value to the registered NF. The service engine sends the new value in the response message of the next periodic Heart-Beat interaction that is received from the NFs. Until then, NRF applies the Heart-Beat check procedure according to the initial interval value.

The Heart-Beat request contains a NF PATCH Request with multiple input parameters such as NF ID, type of update (replace), path (/nfStatus), and value (REGISTERED, SUSPENDED or UNDISCOVERABLE). After NRF validates the request, it sends the request to the DB to update the NF instance. Upon successfully updating the NF instance, NRF sends a NF PATCH Success response to the NF instance.

NRF REST Endpoint

1. The NRF Rest endpoint receives the NF Heart-Beat request over HTTP2/JSON-PATCH+JSON. The HTTP method is PATCH and the URL is root/nnrf-nfm/v1/nf-instances/{nfInstanceID} and the body contains Patch Data in JSON format.

2. On receiving the request, NRF validates the input message format. If the validation fails, the response is sent with status 400 (BAD REQUEST).

3. If the validation succeeds, then the NF Heart-Beat request is transformed into Protobuf format and sent toward the service engine for processing.

4. The service engine sends a response toward the endpoint after processing the request. The response is then transformed from Protobuf format to JSON format.

5. The response is then converted to OpenAPI format and sent toward the NF. If it’s a successful response, then the response message contains the status code as 204 (No Content). Else, if it’s a failure, the error code is sent back to the client along with problem details.

NF Heart-Beat Purge Timer Expiry

1. DB sends the Timer Expiry notification with DBRecord as body, which is received as a new transaction at REST endpoint.

2. The REST endpoint converts the Timer Expiry notification into Protobuf format and sends it toward the service engine for processing. The REST endpoint sends the message as an asynchronous call because it does not expect any response from NRF service engine.

NRF Service Engine

1. The NRF service engine receives the Protobuf-based request from the REST endpoint through the IPC system.

2. On receiving the request, NRF validates the PATCH request.

3. NRF fetches the NF profile based on nfInstanceId as primary key, and then apply the patch locally.

4. If complete NF profile validation (after patch operations) is:

   • Successful -

     1. NRF updates the NF profile in DB, and the service engine sends response code 204 (No Content) to the REST endpoint.

     2. NRF starts or restarts NF Heart-Beat timer (period is NF Heart-Beat timer + Heart-Beat Grace Time). If NF Profile Purge timer is started already, then it is overwritten with NF Heart-Beat timer + Heart-Beat Grace Time).

   • Unsuccessful – The service engine sends a response message with an error code to the REST endpoint, which depends on the type of failure:

     • No NF profile is available for given nfInstanceID : 404 (Not Found)

     • Any validation failure: 400 (Bad Request)

NF Heart-Beat Purge Timer Expiry

1. The NRF service engine receives the TimerExpiry Protobuf-based request from the REST endpoint through the IPC system.

2. The body contains primary key of the NF profile to which the timer is associated. The service engine fetches the NF profile using the same key.

• If no NF profile is available, then the service engine ignores the request.

• If an NF profile is found, then the service engine processes the request based on the following conditions:

  • If the timer is Heart-Beat timer, then the service engine updates the DB with NFStatus in the NF profile as Suspended. After this update, the service engine starts the NF Profile Purge timer.

  • If the timer is NF Profile purge timer, then the service engine deletes the NF profile from DB.

1. NRF configures Heart-Beat timers as both global and NF type levels.

2. To configure Heart-Beat service operation, the default level is NF type. If the service operation is not configured as NF type, then NRF configures the Heart-Beat timer as global. During registration, NRF sends the response message with the same Heart-Beat timer value in NF Profile or the newly configured value, whichever is lesser.

3. If the Heart-Beat interval value of any registered NF instance is modified, NRF returns the new value to the registered NF. The service engine sends the new value in the response message of the next periodic Heart-Beat interaction received from the NFs. NRF sends the response message with the updated NF profile and code as 200 (OK). Until then, NRF applies the Heart-Beat check procedure according to the initial interval value.

   Note:

   • NF Heart-Beat request is same as NF Profile Partial Update, but with limited parameters, NFStatus and Load.

   • If NRF sends NFStatus and Load along with other parameters, it’s treated as partial update request. The response message contains the updated NF profile and code as 200 (OK). Also, NRF handles the Heart-Beat timer like a Heart-Beat Request.

The NFStatusSubscribe service operation enables an NF instance to subscribe to notifications for profile or status changes of other NF instances. The NFStatusUnSubscribe service operation enables an NF instance to unsubscribe the subscriptions registered in the NRF already.

The NFStatusNotify service operation enables the NRF to notify changes in status of NF instances to a subscriber of NF status. The service operation also provides information regarding newly registered and de-registered NFs.

The NFStatusSubscribe, NFStatusUnSubscribe, and NFStatusNotify feature enables NRF to provide the following functionality:

• Process the request to subscribe from an NF and store the subscription details in the DB.

• Process the request to unsubscribe from an NF and remove the subscription details from the DB.

• Update the subscription details in DB (204 No Content).

• Support subscription in the same PLMN.

• Authorize the NF client, which requests a subscription based on reqNfType, reqFqdn, and reqSnssais.

• Support subscription for all the conditions.

• Support notification for all NotificationEventTypes.

• Support notification for any update in all parameters.

• Support notification for the update of NF Profile for complete replacement (PUT request).

• Support the update of subscription. The NRF assigns a validity time different from the value suggested by the NF Service Consumer. The response code is 200 OK.

• Support a flag, which sends the full NF profile in the notification during NF profile PATCH update. This flag must be enabled for the option to work properly.

• Support subscriptions for notification condition for both monitoredAttributes and unmonitoredAttributes.

• Support not to trigger “NF_PROFILE_CHANGED” notification for any change in the allowedPlmns, allowedNfTypes, allowedNfDomains, and allowedNssais parameters.

• Support not to include allowedPlmns, allowedNfTypes, allowedNfDomains, and allowedNssais parameters in the profile change notification.

The following sections describe how the NFStatusSubscribe, NFStatusUnsubscribe, and NFStatusNotify feature works.

The NFListRetrieval service operation enables NRF to retrieve a list of NF profiles, which are currently registered with NRF.

For NFListRetrieval service operation, the NRF supports GET request with the following input filter parameters:

• nfType: The type of NF instance to filter the search result for NF instances.

• limit: Maximum number of list items that can be returned in the GET request.

The NFProfileRetrieval service operation retrieves the NF profile, which matches the NF Instance ID specified in the URI.

For NFListRetrieval service operation, the NRF service engine retrieves all the NF profile records from CDL DB based on the nfType parameter used in the GET request. If the limit parameter is used in the GET request after NRF service engine retrieves the NF profiles, the number of search results is limited up to that count.

For NFProfileRetrieval service operation, the NRF service engine retrieves the NF profile records from CDL DB based on the NF Instance IDs along with the necessary validations and error handling.

The NF CLI enables NRF to retrieve a list of NF profiles and delete stale NF profiles.

This NF CLI provides the following functionality:

• NRF supports CLI command to retrieve an NF profile with a specific NF instance ID.

• NRF supports CLI command to retrieve the list of all NF profiles currently registered. This CLI command is used for debugging purpose.

• NRF supports CLI command to delete stale NF profiles. When an NF re-registers with a new instance ID after recovery, this functionality is used to delete a stale NF profile, which cannot be deleted by the NF.

This section describes the sequence of operation.

NRF Ops Center

1. A product-call-back framework enables NRF to add a backend code for a CLI command whenever it’s required.

2. The NFProfileRetrieval procedure retrieves the NF instance details based on the NF instance ID.

3. The NFDeregistration procedure deletes the NF profile from NRF based on the NF instance ID.

   Note: To maintain integrity and reduce errors in its function, NRF does not support a command to delete all NF Profiles together. To delete all the NF Profiles together, use search instance all option to retrieve all the NF Profiles based on their NF instance ID. Then, NRF can delete NF Profiles based on the search result.

NRF REST Endpoint

1. The NRF Rest endpoint receives a request from an NF with URL as {apiRoot}/nnrf-nfm/v1/nf-instances-all.

   Note: The default value, {apiRoot}, is a configurable parameter.

2. On receiving the request, NRF Rest endpoint transforms the message into Protobuf format and sends it toward the service engine for processing.

3. The service engine sends a response toward the endpoint after processing the request. The response is then transformed from Protobuf format to JSON format.

4. The response is then converted to OpenAPI format and sent toward the NF. If it’s a successful response, then the response message contains the updated NF profile with the status code as 200 (OK). Else, if it’s a failure, the error code is sent back to the client along with problem details.

NRF Service Engine

1. The NRF Service Engine receives the Protobuf-based request from the REST endpoint through the IPC system.

2. On receiving the request, NRF fetches all the available profiles from CDL.

3. If the fetch operation is successful:

   • NF profiles unavailable - The service engine sends response code 204 (No Content) to the REST endpoint.

   • NF profiles available - The service engine sends response code 200 (OK) to the REST endpoint along with updated NF profiles.

   • Unsuccessful – If there is an error, the service engine sends a response message with error code 500 along with the problem details to the REST endpoint.

This configurable NRF feature enables deep validation of API request parameters for all procedures. NRF primarily performs deep validation of service requests at the API REST endpoints.

Deep validation for the information elements (IEs) includes the following conditions:

• Verify the presence of mandatory IEs in the API-based service request.

• Verify the following criteria in the service request:

  • IE range checks

  • IE enumerations (enum) checks

  • Conditional IE checks

  • Description compliance checks

  • IE syntax checks

NRF REST Endpoint

1. The NRF REST endpoint receives the API-based service request over HTTP2/JSON.

2. On receiving the request, NRF validates the input message for the following criteria:

   • Presence of Mandatory IEs in the service request.

   • IE range checks for all the IEs in the service request.

   • Enum checks for all the IEs in the service request.

   • Conditional checks for all the IEs in the service request.

   • Checks for compliance to description and syntax of all the IEs in the service request.

   If the validation fails, the response is sent with status 400 (BAD REQUEST) and the corresponding error details.

3. If the validation succeeds, then the call flow is same as per the service operation process mentioned for the corresponding features.

Note

The IpEndPoint data-type can only contain a maximum of either one ipv4Address or ipv6Address. However the presence of either ipv4Address or ipv6Address in the data-type is not mandatory. If the Range data-types, for example, SupiRange have all three attributes (start, end and pattern) present, deep validation of attributes that contain such data-types fails.

NRF Service Engine

1. The NRF service engine performs deep validation of those IEs in service requests, which cannot be validated by the NRF API REST endpoint.

2. If the validation succeeds, then the call flow is same as per the service operation process mentioned for the corresponding features.

Note	The discovery query parameter, service-names must contain an array of unique service names for the NRF to provide the list of profiles in response to a query. The discovery query parameters, Supi and Gpsi comply with the regex pattern mentioned in 3GPP TS 29.510.

To configure deep validation of API request parameters for all procedures, use the following sample configuration:

Note	It is not recommended to enable this feature in a performance environment handling high TPS. For more details about the performance impact, contact your Cisco account representative.

config 
   nrf-profile profile-settings { enable-deep-validation { false | true } 
   exit 

NOTES:

• enable-deep-validation { false | true } : E nable or disable the Deep Validation feature.

  Default Value: false .