6.13 SBI messages correlation for network troubleshooting

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

6.13.1 General

The procedures defined in this clause provide means for correlating 5GC internal SBI messages (request or response) with a UE identity, by network management tools or probes that are used for network performance analysis and troubleshooting.

The procedures are optional to support. When supported, the use of these procedures is dependent on operator’s policy, regulatory guidelines and security considerations.

6.13.2 SBI messages correlation using UE identifier

6.13.2.1 General

The procedure enables network analytics tools or probes, to easily identify messages that were exchanged for a given UE. When supported and configured to be used by operator’s policy, an NF service consumer or NF service producer may include the UE identity in 3gpp-Sbi-Correlation-Info header, to identify the UE related to the HTTP request or response, as further defined in clause 6.13.2.2.

When included in an HTTP request or response, the 3gpp-Sbi-Correlation-Info header should contain at least one UE identifier, and no more than one of each type of UE identifier (ctype).

The NF should comply with 5GC SBI interface specific and security requirements while selecting a UE identifier to be included in the 3gpp-Sbi-Correlation-Info header. Additionally, based on operator’s policy and regulatory requirements some UE identifiers may be not be allowed in the 3gpp-Sbi-Correlation-Info header for certain HTTP request or response messages.

6.13.2.2 Principles

An HTTP client originating a request may include in the request the 3gpp-Sbi-Correlation-Info header containing the UE identity that is related to the request. The HTTP client should include the SUPI in the 3gpp-Sbi-Correlation-Info header when it is available. If the SUPI is not available, the header should contain a UE identity that is known to the NF and is the most appropriate for the message context.

Upon receipt of a request that includes the 3gpp-Sbi-Correlation-Info header, the HTTP server, if it supports this header, may include the header in the response sent to the HTTP client, with the same UE identity that was contained in the 3gpp-Sbi-Correlation-Info header of the received HTTP request. If the HTTP request creates a subscription to notifications and the HTTP server supports this header, it should store the UE identifier received in the header and should include the header containing the stored UE identifier in subsequent callback notification requests.

The HTTP server may include the 3gpp-Sbi-Correlation-Info header in a successful response even when the header is not included in the request received from the HTTP client.

In an HTTP error response, the HTTP server may include the same UE identifier that was received in the 3gpp-Sbi-Correlation-Info header of the HTTP request or should not include the 3gpp-Sbi-Correlation-Info header if the header was not included in the HTTP request.

When forwarding a request or response that includes the 3gpp-Sbi-Correlation-Info header, the SCP should forward this header unmodified. For NF Discovery and (re)selection in indirect communication with or without Delegated Discovery, if the service request is received including the 3gpp-Sbi-Correlation-Info header, the SCP should include this header unmodified when it initiates a NF Discovery Request to the NRF. In indirect communication with or without Delegated Discovery, if the SCP reselects an alternative NF, the SCP should also include this header unmodified when it sends the HTTP request to the alternative NF service instance. In an inter-PLMN scenario, the SEPP may remove the header based on operator policies and regulatory requirements.

6.13.3 SBI messages correlation using NF Peer Information

6.13.3.1 General

The procedure enables network elements (such as NFs, SCPs, SEPPs, network analytics tools or probes, etc.), to obtain source and destination information of messages that were exchanged between a specified pair of NF (Service) instances. An NF as HTTP client or NF as HTTP server should include the NF (Service) instance IDs in 3gpp-Sbi-NF-Peer-Info header, to identify the HTTP requests or responses between the given pair of NF (Service) instances, as further defined in clause 6.13.3.2.

6.13.3.2 Principles

An HTTP client originating a request should include in the request the 3gpp-Sbi-NF-Peer-Info header containing the Source NF (Service) instance ID and if available the Destination NF (Service) instance ID.

Upon receipt of a request that includes the 3gpp-Sbi-NF-Peer-Info, the HTTP server should insert the header in the response sent to the HTTP client, with source and destination peer info corresponding to the destination and source peer info in the request respectively (i.e. swap the received source and destination peer info in the response). The HTTP server should include the 3gpp-Sbi-NF-Peer-Info header in a response even when the header is not included in the request received from the HTTP client.

If the destination peer information provided by HTTP client in the request does not match the information of the HTTP server (e.g. due to the HTTP server having updated its NF (Service) instance ID), the HTTP server should include the updated NF (Service) instance ID values in the response header sent to HTTP client.

When forwarding a request or response that includes the 3gpp-Sbi-NF-Peer-Info header, the SCP should forward this header and may update the destination peer info if the receiver NF is (re)selected; the SCP shall also update the srcscp/dstscp components, based on the source and destination SCP of the forwarded HTTP request or response, as described in clause 5.2.3.2.21; the SEPP shall also update the dstscp component (if SEPP relays the request towards an SCP).

In an inter-PLMN scenario, the SEPP may remove the header based on operator policies. If an SCP or SEPP generates an error response to a request including this header, the SCP and SEPP should insert the header in the response with source peer info containing the information of the SCP or SEPP, and with destination peer info containing the source peer info in the request respectively.