Server Header

The SMF includes "Server" header in all the error responses to peer NF for information on the source of error. Following is the format of this header:

UDM:"nf-instance-id"

For example, UDM:"54804518-4191-46b3-955c-ac631f953ed8"

On receiving an error response, SMF as a client, extracts the NFType from the "Server" header and triggers the SCP failure handling. If you have configured the Model D and if the "Server" header indicates the NF peer, then the SMF ignores the "retry" failure handling action. If you have configured "retry-fallback" as SCP failure handling, then SMF falls back to the local configuration without any retry action. After the SMF fallback, any failure is handled according to the NF failure handling configuration.

Note
  • If the "Server" header is not received or a timeout occurs, the SCP failure handling is applied.

  • In case of timeout from a peer, the SCP populates the "Server" header with its own FQDN and the "504" error code is returned with the problem details including the cause, which is set to "TARGET_NF_NOT_REACHABLE". In this case too, the SCP failure handling is applied. Based on the configuration, SCP tries all the available peer NFs. If the SCP doesn't find any available peer NF, the SCP responds with the "504" error code and "TARGET_NF_NOT_REACHABLE" cause. However, there is a possibility that other SCPs may be able to reach the peer. If a use case to not try another SCP exists in such a case, an operator can configure the retry value to 0.

  • In case of NF discovery errors between SCP and NRF, the SCP can set the cause as "NRF_NOT_REACHABLE" or "NF_DISCOVERY_ERROR". In such cases, the SMF falls back to Model-A, if configured.