This clause specifies the generic routing mechanisms in the 5GC. Specific requirements to support Indirect communication are further defined in clause 6.10. For HTTP message routing between Network Functions, the message routing mechanism as specified in Section 7 of RFC 9110 is almost followed with some differences due to the adoption of HTTP/2 and to some 5G system specificities.

The target resource is identified by a target URI (e.g. a Resource URI, a Custom operation URI or a Callback URI as defined in clause 4.4 of TS 29.501).

If the request is not satisfied by a local cache, then the client shall connect to an authority server for the target resource or to a proxy. If a proxy is applicable for the target URI, the client connects inbound by establishing (or reusing) a connection to that proxy as defined in Section 7.3.2 of RFC 9110. For connecting inbound to an authority not in the same PLMN, the client connects to the Security Edge Protection Proxy. If no proxy is applicable, then the client connects directly to an authority server for the target resource as defined in RFC 9110.

Clients that generate HTTP/2 requests shall use the ":authority" pseudo-header field instead of the Host header field.

An HTTP/2 proxy shall use the ":authority" pseudo-header field to connect inbound to the origin server or another proxy if the request cannot be satisfied by the proxy cache. An HTTP/2 proxy may also use other headers and/or content to connect inbound to the origin server or another proxy if the request cannot be satisfied by the proxy cache.

The Subscribe-Notify service operations shall be supported between NFs as specified in clause 7.1.2 of TS 23.501. Subscribe-Notify service operations require bidirectional communication between the NFs when the server needs to initiate communication with the client. Subscribe-Notify service operations shall be supported with two TCP connections, one per direction, as follows:

• NF service consumer acts as an HTTP client and NF service producer acts as an HTTP server when NF service consumer subscribes to NF service producer's notifications;
• NF service producer acts as an HTTP client and NF service consumer acts as an HTTP server when NF service producer delivers notifications to NF service consumer.

As described in TS 23.501, the Subscribe-Notify interaction requires the NF Service Consumer to provide a "notification endpoint" and a "notification correlation ID"; those are also called "callback URI" in the context of the present Technical Specification, and the authority of the "callback URI" is the HTTP endpoint where the notifications shall be delivered by the NF Service Producer. As indicated in TS 23.501, the interaction between NF Service Consumer and NF Service Producer may not occur, or may occur via interactions on a different service or API, prior to the notification sent by the NF Service Producer (e.g. for Implicit Subscriptions, or for Default Notifications); in that case, the notification is called "standalone notification", and shall be specified as described in clause 5.3.7 of TS 29.501. For notifications sent in Direct Communication scenarios, if the authority of the callback URI contains an FQDN, the NF Service Producer shall use DNS as resolution mechanism in order to setup the TCP connection with the NF Service Consumer; for notifications sent in Indirect Communication scenarios, see clause 6.10.7.

When an NF service consumer subscribes to an intermediate NF for events which may be detected and reported directly by target NF (e.g. an NEF subscribes to Location Reporting event at AMF via UDM and AMF directly reports to the NEF), the NF service consumer may include the "3gpp-Sbi-Consumer-Info" header in the subscription creation request to indicate the supported API versions, features and accepted encodings of the service on the target NF. When subscribing to the target NF and requiring the target NF to directly report to NF service consumer, the intermediate NF shall invoke the highest API version at the target NF which is supported by the NF service consumer (if indicated) and the intermediate NF. The intermediate NF shall include all received "3gpp-Sbi-Consumer-Info" header(s) in the subscription creation request sent to the target NF. If the target NF received this header in event subscription creation, the target NF shall generate the request body according to the supported feature(s) and accepted encodings of the NF service consumer for notifications directly sent to the NF service consumer. Based on operator policy, the NF service consumer may provide a default inter-PLMN or intra-PLMN callback URI in a subscription request to the intermediate NF. The NF Service Consumer may also include, for each provided service, the following information in the "3gpp-Sbi-Consumer-Info" header(s):

• the intraPlmnCallbackRoot parameter containing the callback root for receiving intra-PLMN notifications, and
• the interPlmnCallbackRoot parameter containing the callback root for receiving inter-PLMN notifications.

Upon receiving a subscription request including the above information in the "3gpp-Sbi-Consumer-Info" header, the intermediate NF should check if the target NF is in VPLMN or HPLMN and adapt the callback Root of the callback URI according to the information received from the NF service consumer. For instance, if the NF service consumer included an inter-PLMN callback URI in the subscription request:

• if the target NF is in HPLMN, then the intermediate NF should replace the callback Root of the callback URI in the subscription request with the provided intraPlmnCallbackRoot while sending the subscription creation request to the target NF; and
• if the target NF is in VPLMN, then the intermediate NF shall not change the notification/callback URI.

In either case, the Intermediate NF should then forward the "3gpp-Sbi-Consumer-Info" header in the subscription creation request sent to the target NF. If the intermediate NF expects to receive notifications from the target NF (e.g. the UDM may provide the callback URI to receive subscription change event notifications from the AMF when subscribing to AMF events on behalf of the NEF), to enable the target NF to use, e.g., the proper callback URI, the supported features, the intermediate NF may provide the "3gpp-Sbi-Consumer-Info" header for itself in the subscription creation request to the target NF. If it does so, the intermediate NF shall include the intermediate NF indication parameter in the header. When the target NF is an AMF, the source AMF should forward the information in the received "3gpp-Sbi-Consumer-Info" header(s) to the target AMF during inter-AMF mobility. If the target AMF received intraPlmnCallbackRoot and interPlmnCallbackRoot parameters in the "3gpp-Sbi-Consumer-Info" header information from the source AMF, the target AMF should determine the PLMN of the NF Service Consumer and adapt the callback root of the callback URI correspondingly.

The following requirements apply unless specified otherwise for a given API, An NF Service Producer that sends a notification request should consider that the subscription is no longer valid and terminate the subscription, if it receives any of the following response codes and application errors:

• "400 Bad Request" with the application error "RESOURCE_CONTEXT_NOT_FOUND"; or
• "404 Not Found" with the application error "SUBSCRIPTION_NOT_FOUND".

An NF Service Producer should not keep on sending notification requests to an NF service consumer and may consider that the subscription is no longer valid and terminate the subscription, if it receives one or more "404 Not Found" responses without application errors or with other application errors.