The following is an example configuration of the retransmission for the Namf_Communication EBI Assignment message:

config 
   profile nf-client-failure nf-type amf  
      profile failure-handling FHAMF  
      service name type namf-comm  
         message type AmfCommEBIAssignment  
         status-code httpv2 504  
         retransmit 1  
         retransmit interval 1000  
         retry 1  
         action retry-and-continue 
      exit 
   exit 

The CHF server failure occurs when the selected CHF sends failure response or sends no response. For a CHF server failure, the NF library sends status code that is based on the failure template. This template is associated with the CHF network profile. The smf-service sends the profile information to smf-rest-ep while sending the IPC message.

The failure template is configured with the list of HTTP error codes and the associated failure actions and retry count, as required. This feature supports the failure actions:

• Retry and Continue—For this failure action, NF library attempts until the configured number of times before fallback. After the configured number of times complete, the NF library falls back to the lower priority CHF server IP address. If a failure or no response is received from the CHF server, the "continue" action is returned to the smf-service.

• Terminate—For this failure action, NF library does not attempt to send a message to other CHF servers. The library sends a reply to smf-service with the action as "terminate". For the "terminate" failure action, the smf-service deletes the session.

• Continue—For this failure action, the smf-service continues the session and sends the charging message to the offline CHF server. This server is configured as part of the local static CHF profile that is meant for offline purposes. In addition, the failure handling profile for offline CHF is configured.

Note	For the "continue" failure action, you can configure the offline CHF server at SMF in a separate profile. SMF will use this profile after the CHF server failure. If the offline CHF server is not confgured, the session is continued without imposing any charging.

After CHF server failure, when the SMF continues, it converts the ongoing charging services as follows:

• Converts the services with both online and offline charging method to the offline charging method.

• Converts the services with online charging method to the offline charging method.

• No change for the services with the offline charging method.

The following table lists the mapping of failure actions with the associated HTTP cause code. Based on the network requirements, you can change the mapping.

The following table lists the application error result codes with the associated SMF failure handling action.

The following table lists the Rating Group-level error result codes with the associated SMF failure handling action.

This section describes the call flows that are associated with CHF failure handling.

The following table describes the SMF behaviour on receiving different failures (Continue, Ignore, and Terminate) in CDR-(I/U/T).

The offline failover support for charging feature complies with the following standards:

• 3GPP TS 32.255, version 15.3.0

• 3GPP TS 32.290, version 15.4.0

• 3GPP TS 32.291, version 15.3.0

The offline failover support for charging feature has the following limitation:

• Session Level limits are mandatory from CHF or you must configure them locally. As per the 3GPP specification, the last linked URR can’t be removed when the online URR needs to be delinked from the offline URR.

The CHF failure handling at Rating Group and application levels feature has the following limitations:

• In vSMF, only the terminate action for the application error is applicable.

• The drop-data action is supported only for the online charging.

• If multiple Rating Groups return an error and if one of the errors has the terminate action configured, then the PDU session is terminated.

• If multiple Rating Groups return an error and if the Rating Group mapping to the default flow has the delete-flow action configured, then the PDU session is terminated.

• If multiple PCC rules and Rating Groups are mapped to a single flow, then any Rating Group error that is configured for delete-flow action, results in the deletion of the entire flow.

• For multiple Rating Groups mapped to a single flow, multiple Rating Groups result in failure in the following scenarios:

  • If the terminate action is configured, then this action takes the highest priority.

  • If both the delete-flow and drop-data actions are configured, then the delete-flow action takes the higher priority.

  • If both the convert-to-offline and drop-data actions are configured, then drop-data takes the higher priority.

You can configure the HTTP status code with the corresponding action for the CHF Create, Update, or Release messages. Based on the configuration of the Failure Handling profile, the SMF takes an action when the CHF server failure occurs.

To configure the failure handling profile, use the following sample configuration:

config 
   profile nf-client-failure nf-type chf 
      profile failure-handling fh_profile_name 
         service name type servicename_type 
            message type messagetype_value 
               status-code httpv2 statuscode_value  
                  action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value 
                  exit 

NOTES:

• profile nf-client-failure nf-type chf : Specify the name of the network function that is required after the NF client failure.

• profile failure-handling fh_profile_name : Specify the name of the profile for failure handling.

• service name type servicename_type : Specify the name of the service type. servicename_type can be one of the following values for CHF:

  • nchf-convergedcharging

  • nchf-spendinglimitcontrol

• message type messagetype_value : Specify the value for the type of message. messagetype_value can be one of the following values for CHF:

  • ChfConvergedchargingCreate

  • ChfConvergedchargingUpdate

  • ChfConvergedchargingDelete

• status-code httpv2 statuscode_value : Specify the status code as per the configured failure template. statuscode_value must be an integer in the range of 0–599. Use either '-' or ' as separator for the range of status codes.

• action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value : Specify the failure action and the number of retry attempts. retry_value must be an integer in the range of 1–10.

To configure the offline client profile and offline failure handling profile for the selected CHF server, use the following sample configuration:

config 
   profile network-element chf chf_name 
      nf-client-profile nf_client_profile_name 
      failure-handling-profile fh_profile_name 
      nf-client-profile-offline offline_server_profile_name 
      failure-handling-profile-offline fh_profile_offline_name 
      exit 

NOTES:

• profile network-element chf chf_name : Specify the name of the CHF server.

• nf-client-profile nf_client_profile_name : Specify the name of the NF client profile.

• failure-handling-profile fh_profile_name : Specify the name of the failure handling profile.

• nf-client-profile-offline offline_server_profile_name : Specify the NF client profile name for the offline server.

• failure-handling-profile-offline fh_profile_offline_name : Specify the failure handling profile name for the offline server.

This section describes how the SMF handles message-level failures and the corresponding HTTP status code-based failures.

The SMF initiates the following messages:

• PcfSmpolicycontrolCreate

• PcfSmpolicycontrolUpdate

• PcfSmpolicycontrolDelete

During the PDU session lifecycle, the SMF exchanges the messages at various stages with the PCF. Depending on the HTTP status code configured in the NRF failure profile, the SMF takes one of the following actions:

• Ignore

• Continue

• Terminate

To configure the PCF failure handling profile with action, use the following sample configuration:

config 
   profile nf-client-failure nf-type pcf 
      profile failure-handling fhprofile_name 
         service name type servicename_type 
            message type messagetype_value 
               status-code httpv2 status_code 
               action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value 
               exit 

NOTES:

• profile failure-handling fhprofile_name : Specify the failure handling profile name.

• service name type servicename_type : Specify the PCF service name type. servicename_type can be one of the following values:

  • npcf-am-policy-control

  • npcf-bdtpolicycontrol

  • npcf-eventexposure

  • npcf-policyauthorization

  • npcf-smpolicycontrol

  • npcf-ue-policy-control

• message type messagetype_value : Specify the message type. messagetype_value can be one of the following values:

  • PcfAmfPolicyControlCreate

  • PcfSmpolicycontrolCreate

  • PcfSmpolicycontrolDelete

  • PcfSmpolicycontrolUpdate

• status-code httpv2 status_code : Specify the HTTPv2 status code. status_code must be an integer in the range of 0–599, separated by either '-' or ','.

• action { continue | retry-and-continue | retry-and-ignore | retry-and-terminate } retry retry_value : Specify the action and the number of retry attempts. retry_value must be an integer in the range of 1–10.

To configure the association of FH profile in PCF, use the following sample configuration:

config 
   profile network-element pcf pcf_profile_name 
      nf-client-profile nf_profile_name 
      failure-handling-profile fh_profile_name 
      exit 

NOTES:

• nf-client-profile nf_profile_name : Specify the NF client profile name.

• failure-handling-profile fh_profile_name : Specify the failure handling profile name.

To configure the secondary and tertiary IP addresses, use the following sample configuration:

config 
   profile nf-client nf-type pcf 
      pcf-profile pcfprofile_name 
         locality locality_name 
            service name type npcf-smpolicycontrol 
               endpoint-profile endpointprofile_name 
                  endpoint-name endpoint_name 
                     primary ip-address { ipv4 primary_ipv4_address | ipv6 primary_ipv6_address | port primary_port_number } 
                     secondary ip-address { ipv4 secondary_ipv4_address | ipv6 secondary_ipv6_address | port secondary_port_number } 
                     tertiary ip-address { ipv4 tertiary_ipv4_address | ipv6 tertiary_ipv6_address | port tertiary_port_number } 
                     end 

NOTES:

• primary ip-address ipv4 primary_ipv4_address : Specify the IPv4 address of primary endpoint.

• primary ip-address ipv6 primary_ipv6_address : Specify the IPv6 address of primary endpoint.

• primary ip-address port primary_port_number : Specify the port number of primary endpoint.

• secondary ip-address ipv4 secondary_ipv4_address: Specify the IPv4 address of secondary endpoint.

• secondary ip-address ipv6 secondary_ipv6_address : Specify the IPv6 address of secondary endpoint.

• secondary ip-address port secondary_port : Specify the port number of secondary endpoint.

• tertiary ip-address ipv4 tertiary_ipv4_address : Specify the IPv4 address of tertiary endpoint.

• tertiary ip-address ipv6 tertiary_ipv6_address : Specify the IPv6 address of tertiary endpoint.

• tertiary ip-address port tertiary_port_number : Specify the port number of tertiary endpoint.

This feature supports the following statistics:

• PcfSmpolicyControlCreate

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• PcfSmPolicyControlUpdate

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• PcfSmpolicyControlDelete

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• PolicyUpdateNotifyReq

  • Number of accepted requests

  • Number of rejected requests

  • Number of skipped requests

• PolicyDeleteReq

  • Number of accepted requests

  • Number of rejected requests

  • Number of skipped requests

• PolicyUpdateRequest

  • Number of accepted requests

  • Number of rejected requests

  • Number of skipped requests

• Gauge counter for number of subscribers with policy type local/pcf.

Use the following sample configuration to configure the UDM failure handling profile with action.

config 
   profile nf-client-failure nf-type udm 
      profile failure-handling fh_profile_name 
         service name type { nudm-ee | nudm-pp | nudm-sdm | nudm-ueau 
         | nudm-uecm } 
         message type { UdmRegistrationReq | UdmSdmGetUESMSubscriptionData 
         | UdmSdmSubscribeToNotification | UdmSubscriptionReq 
         | UdmUecmRegisterSMF | UdmUecmUnregisterSMF |  
         UdmSdmUnsubscribeToNotification } 
            status-code httpv2 0 
               action { continue | retry-and-continue | retry-and-ignore 
              | retry-and-terminate | terminate } 
              end 

To configure the association of FH profile in the UDM, use the following sample configuration:

config 
   profile network-element udm udm_profile_name 
      nf-client-profile nf_profile_name 
      failure-handling-profile fh_profile_name 
      failure-handling-profile-rat nr 
         failure-handling-profile fh_profile_name 
         exit 

NOTES:

• failure-handling-profile-rat nr : Specify the failure handling profile specific to RAT type.

• failure-handling-profile fh_profile_name : Specify the failure handling network profile name. fh_profile_name must be a string.

Verifying the RAT-based FH Profile

This section describes how to verify RAT-based FH profile in the UDM.

Use the show running-config profile network-element udm udm_profile_name command to verify the feature configuration details.

The following is an example output.

nf-client-profile UP1
   failure-handling-profile FH1
   failure-handling-profile-rat nr
      failure-handling-profile FH4
      exit
exit

In this example, FH1 is the default failure handling profile. However, if the RAT type is configured as nr , then the failure handling profile FH4 is used.

To configure secondary and tertiary IP addresses, use the following sample configuration:

config 
   profile nf-client nf-type udm 
      udm-profile udmprofile_name 
         locality LOC 
            service name type { nudm-ee | nudm-pp | nudm-sdm | nudm-ueau | nudm-uecm } 
               endpoint-profile epprofile_name 
                  endpoint-name endpoint_name 
                     primary ip-address { ipv4 primary_ipv4_address | ipv6 primary_ipv6_address | port primary_port_number } 
                     secondary ip-address { ipv4 secondary_ipv4_address | ipv6 secondary_ipv6_address | port secondary_port_number } 
                     tertiary ip-address { ipv4 tertiary_ipv4_address | ipv6 tertiary_ipv6_address | port tertiary_port_number } 
                     end 

NOTES:

• primary ip-address ipv4 primary_ipv4_address : Specify the IPv4 address of primary endpoint.

• primary ip-address ipv6 primary_ipv6_address : Specify the IPv6 address of primary endpoint.

• primary ip-address port primary_port_number : Specify the port number of primary endpoint.

• secondary ip-address ipv4 secondary_ipv4_address: Specify the IPv4 address of secondary endpoint.

• secondary ip-address ipv6 secondary_ipv6_address : Specify the IPv6 address of secondary endpoint.

• secondary ip-address port secondary_port : Specify the port number of secondary endpoint.

• tertiary ip-address ipv4 tertiary_ipv4_address : Specify the IPv4 address of tertiary endpoint.

• tertiary ip-address ipv6 tertiary_ipv6_address : Specify the IPv6 address of tertiary endpoint.

• tertiary ip-address port tertiary_port_number : Specify the port number of tertiary endpoint.

To configure response timeout for fail-open support over the UDM interface (N10), use the following sample configuration:

config 
   profile network-element udm udm_profile_name 
      response-timeout timeout_value 
      exit 

NOTES:

• response-timeout timeout_value : Specify the response timeout in milliseconds. timeout_value must be an integer in the range of 1000-30000.

  Default: 4000

Verifying the Response Timeout Configuration

The following is an example configuration.

[unknown] smf# show running-config profile network-element udm
profile network-element udm udm1
nf-client-profile UP1
failure-handling-profile FH4
query-params [ dnn ]
response-timeout 2000
exit
[unknown] smf#

The following statistics are supported for all the UDM message status with status as Attempted/Success/Skipped/Failed for all UDM services and message combination.

udm_msg_processing_status{app_name="SMF",cluster="Local",data_center="DC"
,instance_id="1",msg_status="attempted",rat_type="nr",service_name="smfservice",
udm_end_point="",udm_msg="UdmSmSubscription”} 1

udm_msg_processing_status{app_name="SMF",cluster="Local",data_center="DC",
instance_id="1",msg_status="skipped",rat_type="nr",service_name="smfservice",udm_end_point="",
udm_msg="UdSmSubscription"} 1

The SMF maintains the following statistics in support of the UDM Failure Handling feature.

• Nudm_UECM_Registration

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• Nudm_UECM_DeRegistration

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• Nudm_SDM_Get

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• Nudm_SDM_Subscribe

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

• Nudm_SDM_Unsubscribe

  • Number of ignore responses

  • Number of continue responses

  • Number of terminate responses

The "udm_msg_processing_status" statistic in smf-service tracks the number of UDM messages with status as—Attempted, Success, Skipped, and Failed.

For example:

udm_msg_processing_status
{app_name="SMF",cluster="Local",data_center="DC",instance_id="1",msg_status="attempted",
rat_type="nr",
service_name="smf-service",udm_end_point="",udm_msg="UdmSmSubscription"} 1
udm_msg_processing_status
{app_name="SMF",cluster="Local",data_center="DC",instance_id="1",msg_status="skipped",
rat_type="nr",
service_name="smf-service",udm_end_point="",udm_msg="UdSmSubscription"} 1

To configure the UPF failure handling profile, use the following sample configuration:

config 
   profile failure-handling fh_profile_name 
      interface pfcp message { N4SessionEstablishmentReq | N4SessionModificationReq | N4SessionReportReq } 
         cause-code cause_ID 
         action { ignore | retry-terminate { max-retry retry_value } | terminate } 
         end 

NOTES:

• profile failure-handling fh_profile_name : Specify the UPF failure handling profile name.

• interface pfcp message { N4SessionEstablishmentReq | N4SessionModificationReq | N4SessionReportReq } : Specify the failure handling for N4SessionEstablishmentReq (for new sessions), N4SessionModificationReq messages (for existing sessions), and N4 Session Report Request.

  .

  Note	UPF reselection is not applicable for message type N4SessionModificationReq because the session is already active on a UPF.

• cause-code cause_ID : Specify the error codes that the SMF receives in the failure response message from the UPF.

  For the N4SessionEstablishmentReq and N4SessionModificationReq message types, the cause_ID must be one of the following values:

  • pfcp-entity-in-congestion : Specify this cause code when the UPF is congested.

  • reject : Specify this option to handle the cause codes in the failure response message from UPF. The cause codes are not configured by using the CLI commands available for this feature.

  • no-response-received : Specify this option to determine the scenarios where SMF does not receive any response from UPF.

  • FHT does not support the following cause codes, which are configured with their default behaviour:

    • request-reject-unspecified

    • cond-ie-missing

    • invalid-length

    • invalid-fw-policy

    • invalid-fteid-alloc-opt

    • no-established-pfcp-assoc

    • rule-creation-mod-failure .

  For the N4SessionReportReq message type, the cause_ID must be an integer in the range of 2– 255. Separate the cause code value using either '-' or ',' or both. For example, cause-code 72-74,76,78-100

  When the N4SessionReportReq keyword is configured, the SMF triggers the Session Deletion Request followed by the rejection of Session Report. The UPF responds to the delete request and clears the session gracefully.

• action { ignore | retry-terminate { max-retry retry_value } | terminate } : Specify the action to perform based on the error cause code received in the failure response message from the UPF.

  • ignore —Specify to ignore the session. This FH action is applicable for N4SessionReportReq message type.

  • retry-terminate max-retry retry_value —Specify number of retry attempts to an alternate UPF. If the retry attempt fails, the session is terminated. This FH action is applicable for N4SessionEstablishmentReq message type.

    Default value: 2

    Maximum value: 5

    Note	If all the UPFs are in congested state, the call fails even if the action is set to continue .

  • terminate —Specify to terminate the session. This FH action is applicable for N4SessionEstablishmentReq, N4SessionModificationReq, and N4SessionReportReq message types.

    You can configure different failure handling conditions based on the procedures applicable only for the N4SessionModificationReq message type. To configure the conditions, use the following command:

    action terminate condition { handover-execution | handover-preparation | modify | idft | handover-cancel }

    Configuring the condition command is optional.

    Note	The SMF allows configuration of one or more conditions for failure handling of N4 session modifications.

    The SMF either terminates or allows the existing session to continue according to the configured conditions. For example, if any of the handover execution procedures fail during N4 modification, the SMF terminates the session.

    The cause codes 0-255 are supported. Precedence of the cause codes are in the following order:

    1. Predefined string

    2. Number

    3. Range

    4. Reject

    Reject is the default cause code.

    The following table describes the configuration for cause codes:

    Table 12. Configuration for Cause Codes

    Cause code	Configuration
    0-63	Corresponding template configuration
    64-255	reject

Verifying the UPF Failure Handling Configuration

Use the show running-config command to view the configuration.

The following is an example output of the command.

show running-config profile failure-handling interface pfcp
profile failure-handling FH1
 interface pfcp message N4SessionEstablishmentReq
  cause-code pfcp-entity-in-congestion action retry-terminate max-retry 2
  cause-code system-failure action terminate
  cause-code service-not-supported action terminate
  cause-code no-resource-available action retry-terminate max-retry 3
  cause-code no-response-received action retry-terminate max-retry 1
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionModificationReq
  cause-code mandatory-ie-incorrect action terminate
  cause-code session-ctx-not-found action terminate
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionReportReq
  cause-code 69 action terminate
  cause-code 72-74,76,78-100 action terminate
 exit
exit
 

To configure the failure profile association, use the following sample configuration.

config 
   profile upf-group  upf_group_name 
      failure-profile failure_profile_name 
      end 

NOTES:

• profile upf-group upf_group_name : Specify the UPF group name.

• failure-profile failure_profile_name : Specify the UPF failure profile name.

The SMF supports the following disconnect reasons as part of “smf_disconnect_stats”:

• smf_sess_pdn_rel_peer_request_reject — This disconnect reason is applicable for 4G and WiFi calls.

• smf_sess_pdu_rel_peer_request_reject — This disconnect reason is applicable for 5G calls.