Once an inbound connection is obtained, the client sends a request message over the wire. The message starts with a HEADERS frame containing the Pseudo-Header Fields identifying the request target. The ":method" pseudo-header is always present. When sending a request directly to an origin server or to a proxy, other than a CONNECT or server-wide OPTIONS request, a client shall include the below pseudo-headers:

• ":scheme".
• ":authority".
• ":path" includes the path and query components of the target URI. The path includes the optional deployment-specific string of the Resource URI or Custom operation URI "apiRoot" part.

When sending a CONNECT request to a proxy, a client shall include the ":authority" pseudo-header. The ":scheme" and ":path" ones shall be absent. When sending a server-wide OPTIONS request to an origin server or to a proxy, a client shall include the below pseudo-headers:

• ":scheme".
• ":authority".
• ":path" set with the value "*".

For HTTP/2 request messages where the target URI authority component designates an origin server in the same PLMN as the client, the ":authority" HTTP/2 pseudo-header field shall be set to: Where the uri-host shall be:

• FQDN of the target NF service; or
• IP address of the target NF service

The FQDN of the target NF service need not contain the PLMN identifier.

This clause specifies details of the Load Control based on LCI Header solution (LC-H). The solution extends the Load Control based on load signalled via the NRF solution by enabling a direct exchange of the LCI between the NF Service Producer and NF Service Consumer. Support for the LC-H solution is optional, but if the feature is supported, the requirements specified in the following clauses shall apply. An NF Service Producer that supports the LC-H feature shall signal its load information as further specified in this clause. An NF Service Consumer supporting the LC-H feature shall utilize the load information, for a given scope, that is received with the most recent timestamp from the NRF or from the NF Service Producer via direct signalling, to adaptively balance the load across the candidate NF Service Producers according to their effective load e.g. when creating a resource at an NF Service Producer. An SCP/SEPP that supports the LC-H feature may additionally piggyback its LCI with a scope set to the SCP FQDN/SEPP FQDN, in HTTP request or response messages, as further specified in this clause. An HTTP client supporting the LC-H feature shall utilize the load information of the SCP/SEPP, which is received with the most recent timestamp, to adaptively balance the load across the available SCPs/SEPPs to reach the HTTP server. In scenarios with multiple SCPs or with SCP(s) and SEPPs between the NF service producer and the NF service consumer, an SCP or SEPP that receives in a service response or in a notification request an LCI with a scope set to an SCP or SEPP FQDN, shall remove this LCI header when forwarding the message to the next hop, and shall perform load control to adaptively balance the load across the available next hop SCPs/SEPPs for the subsequent service requests according to the received LCI information. The SCPs and SEPPs shall forward LCI headers with a scope set to NF Producer received in a service response or notification request when forwarding the message to the next hop. The NF consumer shall perform the load control to adaptively balance the load across the available NF Producers for the subsequent service requests according to the received LCI information. A SEPP may advertize its own LCI information to a next hop NF or SCP in the same PLMN, and/or to the peer SEPP based on operator's policy. In the latter case, LCI may be advertized in N32-f signalling; when PRINS is used over N32-f, the LCI header for the SEPP FQDN shall be inserted in the outer N32-f message, i.e. not within the N32-f payload.

LCI shall be conveyed within the 3gpp-Sbi-Lci HTTP header. When conditions for generating an LCI are met, an NF Service Producer, SCP or SEPP shall include the 3gpp-Sbi-Lci header, or LCI header, see clause 5.2.3.2.10) to its peer entities (NF Service Consumers). The LCI header shall be piggybacked on a signalling message that is sent to the NF Service Consumer. The NF Service Producer, SCP or SEPP shall send the 3gpp-Sbi-Lci header, regardless of whether the peer NF Service Consumer supports the feature (see clause 6.3.3.5). The header is ignored by the NF Service Consumer if the latter does not support the LC-H feature.

How often or when the sender conveys the LCI is implementation specific. The sender shall ensure that new or updated Load Control Information is conveyed to the target receivers with an acceptable delay, such that the purpose of the information (i.e. the effective load balancing) is achieved. Considering the processing requirement of the receiver of the LCI (e.g. handling of the new information), the sender should refrain from advertising every small variation (e.g. with the granularity of 1 or 2), in the Load Metric which does not result in useful improvement in NF service producer selection logic at the receiver. A larger variation in the Load Metric, e.g. 5 or more units, should be considered as reasonable enough for advertising the new Load Control Information.