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 clause 5 of IETF RFC 7230 is almost followed with some differences due to the adoption of HTTP/2 and to some 5G system specificities.
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 clause 5.2 of IETF RFC 7230. 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 7230.
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:
"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:
In order to reach the correct target NF service in the right PLMN and for HTTP/2 request messages where the target URI authority component designates an origin server not in the same PLMN as the client, the ":authority" HTTP/2 pseudo-header shall contain the FQDN including the PLMN ID.
The ":authority" pseudo-header field in the HTTP/2 request message shall be set to:
FQDN of the target NF service or the FQDN (authority) part of a callback URI or a specified link relation
The FQDN of the target NF service or the FQDN (authority) part of a callback URI or a specified link relation shall contain the PLMN identifier.
The format of the FQDN of target NF service is specified in clause 28.5 of TS 23.003.
To allow for TLS protection between the SEPP and Network Functions within a PLMN, the SEPP shall support:
TLS wildcard certificate for its domain name and generation of telescopic FQDN, as specified in clause 13.1 of TS 33.501 and in clause 188.8.131.52.2; and
forwarding HTTP requests originated by NFs within the SEPP's PLMN towards the remote PLMN using the 3gpp-Sbi-Target-apiRoot header as specified in clause 184.108.40.206.3.
Both solutions for TLS protection between the SEPP and Network Functions within a PLMN may be used concurrently in a PLMN, e.g. in the transient phase where not all NFs of the PLMN have been upgraded to support the 3gpp-Sbi-Target-apiRoot header but when the PLMN operator would like to use the solution based on the 3gpp-Sbi-Target-apiRoot header with upgraded NFs. In this case, the SEPP should skip converting URIs into telescopic FQDNs (and use the solution based on 3gpp-Sbi-Target-apiRoot header) in:
HTTP responses received from the remote PLMN (e.g. including the FQDN of the target NF service) when the corresponding HTTP request contains a 3gpp-Sbi-Target-apiRoot header;
HTTP requests received from the remote PLMN (e.g. including callback URIs) using SEPP policies based on the target URI (i.e. target FQDN).
When using TLS wildcard certificate and telescopic FQDN between the SEPP and NFs within the SEPP's PLMN, the SEPP on the HTTP/2 client side shall form the telescopic FQDN, as specified in TS 23.003, for the following cases:
FQDN of the target NF service in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN;
FQDN of the target NF service in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;
FQDN (authority) part of callback URI of NF service resources in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;
FQDN (authority) part of callback URI of NF service resources in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN;
FQDN (authority) part of link relation URI of NF service resources in VPLMN is modified into a telescopic FQDN by the SEPP in the HPLMN;
FQDN (authority) part of link relation URI of NF service resources in HPLMN is modified into a telescopic FQDN by the SEPP in the VPLMN.
When using the 3gpp-Sbi-Target-apiRoot header between the SEPP and NFs within the SEPP's PLMN, HTTP requests between the NFs and the SEPP shall be routed as specified in clause 6.10.2 for indirect communications, with the SEPP taking the role of the SCP.
When sending an HTTP request targeting a URI with an authority of a remote PLMN, NFs shall include the 3gpp-Sbi-Target-apiRoot header in the HTTP request, containing the apiRoot of the target URI in the remote PLMN, and shall set the apiRoot in the request URI to the apiRoot of the SEPP (or to the apiRoot of the SCP if the communication between the NF and SEPP goes through an SCP). The apiRoot of the SEPP (or SCP) may include an optional deployment-specific string of the SEPP (or SCP).
An SCP that receives an HTTP request targeting a URI with an authority of a remote PLMN shall route the HTTP request towards the SEPP as specified in clause 6.10.2 for indirect communications, i.e. the SCP shall forward the 3gpp-Sbi-Target-apiRoot header in the HTTP request it forwards to the SEPP, containing the apiRoot of the target URI in the remote PLMN, and it shall set the apiRoot in the request URI to the apiRoot of the SEPP.
If the SEPP receives an HTTP request from a NF with a request URI containing a telescopic FQDN and with a 3gpp-Sbi-Target-apiRoot header, the SEPP shall ignore the 3gpp-Sbi-Target-apiRoot header and route the request using the telescopic FQDN.
The 3gpp-Sbi-Target-apiRoot header shall not be used between SEPPs if PRINS security is negotiated between the SEPPs. The apiRoot of the Request URI of the HTTP request encapsulating the protected message shall be set to the apiRoot of the remote SEPP. See clause 220.127.116.11 of TS 29.573.
If TLS security is negotiated between the SEPPs and at least one SEPP does not indicate support of the 3gpp-Sbi-Target-apiRoot header when negotiating the security policy, the SEPP shall use a pre-established TLS connection towards the other SEPP to forward the HTTP/2 messages sent by the NF service producers and NF service consumers, as is without reformatting. Additionally,
if the NF uses the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target apiRoot to the sending SEPP, the sending SEPP shall remove the 3gpp-Sbi-Target-apiRoot header and set the apiRoot of the request URI it forwards on the N32-f interface to the apiRoot received in the 3gpp-Sbi-Target-apiRoot header from the HTTP client;
if the NF uses a telescopic FQDN in the HTTP Request to convey the target apiRoot to the sending SEPP, or if TLS is not used between the NF and the sending SEPP, the sending SEPP shall set the apiRoot of the Request URI in the HTTP Request towards the remote SEPP to the apiRoot of the target NF derived from the telescopic FQDN or from the request URI respectively.
If TLS security is negotiated between the SEPPs and both SEPPs indicate support of the 3gpp-Sbi-Target-apiRoot header when negotiating the security policy, HTTPS shall be used to forward messages between SEPPs. The sending SEPP shall replace the apiRoot of the Request URI in the HTTP Request with the apiRoot of the receiving SEPP before forwarding the HTTP Request on the N32 interface. Additionally,
if the NF uses the 3gpp-Sbi-Target-apiRoot HTTP header in the HTTP Request to convey the target apiRoot to the sending SEPP, the sending SEPP shall forward the 3gpp-Sbi-Target-apiRoot header unmodified in the HTTP request towards the remote SEPP;
if the NF uses a telescopic FQDN in the HTTP Request to convey the target apiRoot to the sending SEPP, or if TLS is not used between the NF and the sending SEPP, the sending SEPP shall insert the 3gpp-Sbi-Target-apiRoot header in the HTTP request towards the remote SEPP and set it to the apiRoot of the target NF derived from the telescopic FQDN or from the request URI respectively.
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 payload 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.
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.
Load control enables an NF Service Producer to signal its load information to NF Service Consumers, either via the NRF (as defined in clause 6.3.2) or directly to the NF Service Consumer (as defined in clause 6.3.3). The load information reflects the operating status of the resources of the NF Service Producer.
Load control allows for better balancing of the load across NF Service Producers, so as to attempt to prevent their overload in first place (preventive action). Load control does not trigger overload mitigation actions, even if the NF Service Producer reports a high load.
This clause specifies details of the Load Control based on load signalled via the NRF solution.
During NF discovery procedures (see clause 4.17.4 and 4.17.5 of TS 23.502), the NRF may provide the NF instance and/or the NF service instance information with the NF capacity information advertised during NF Service Registration and/or NF Service Update procedures (see clause 4.17.1 and 4.17.2 of TS 23.502 and clause 6.2.6 of TS 23.501). The NRF may also provide load information of the NF instance and/or the NF service instance in NF discovery response.
The NF service consumer that is discovering the NF service producer, may use the available information (e.g. NF capacity information, load information) to select the appropriate NF instance as specified in TS 29.510.
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 thefollowing 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 that supports the LC-H feature may additionally piggyback its LCI with a scope set to the SCP 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, which is received with the most recent timestamp, to adaptively balance the load across the available SCPs to reach the HTTP server.
LCI shall be conveyed within the 3gpp-Sbi-Lci HTTP header. When conditions for generating an LCI are met, an NF Service Producer or SCP shall include the 3gpp-Sbi-Lci header, or LCI header, see clause 18.104.22.168.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 or SCP shall send the 3gpp-Sbi-Lci header, regardless of whether the peer NF Service Consumer supports the feature (see clause 22.214.171.124). 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.
A NF Service Producer may include one or more LCI header(s) in a service response or in a notification/callback request message sent to a NF Service Consumer. An NF Service Producer may report LCI with different scopes, e.g.:
to report LCIs for an NF service instance, an NF service set and/or an NF instance;
to report LCIs at the level of an SMF (service) instance or SMF (service) set, and for specific S-NSSAI/DNNs;
to report LCIs for different S-NSSAI/DNNs of an SMF (service) instance or SMF (service) set.
A NF Service Producer may also include LCI header(s) with different scopes in different messages, e.g. an SMF may report LCI for the SMF instance first, and then report LCI for both the SMF instance and for specific S-NSSAI/DNN(s), if S-NSSAI/DNN based load control is enabled.
An NF Service Consumer that receives LCI headers with different scopes, in the same message or in different messages, shall handle each LCI independently from each other. For instance, if an NF Service Consumer receives one LCI with the scope of an NF (Service) Set and then another LCI with the scope of an NF (Service) instance that pertains to the NF (Service) Set, the NF Service Consumer shall store the latter LCI and also consider that the former LCI is still valid for the NF (Service) Set.
For S-NSSAI/DNN based load control (see clause 126.96.36.199.4.2.2), when signalling LCI for an SMF (service) instance or an SMF (service) set in a message, the SMF shall always include the full set of load control information applicable to the SMF (service) instance or SMF (service) set, i.e. LCI for the SMF (service) instance or the SMF (service) set level and/or LCI for specific S-NSSAI/DNNs, even if only a subset of the LCI has changed; these LCIs shall contain the same Load Control Timestamp.
An SCP may additionally include one LCI in a service request or response, or in a notification request or response, sent towards a NF Service Consumer or NF Service Producer.
Each LCI shall always include the Timestamp, Load Metric and Scope parameters (see clause 188.8.131.52.10 for the complete list of parameters).
The Timestamp parameter indicates the time when the LCI was generated. It shall be used by the receiver of the LCI to properly collate out-of-order LCI, e.g. due to HTTP/2 stream multiplexing, prioritization and flow control, and to determine whether the newly received load control information has changed compared to load control information previously received for the same scope.
The receiver shall overwrite any stored load control information of a peer NF, NF set, NF service, NF service set or SCP (according to the scope of the new received LCI) with the newly received load control information, if the new load control information is more recent than the stored information. For instance, for S-NSSAI/DNN based load control, if the receiver had stored LCI for a peer SMF instance and LCI for a specific S-NSSAI/DNN of that SMF instance, it shall overwrite these LCIs with the new LCI received in a message carrying LCI for the same SMF instance.
If the newly received LCI has the same or an older Timestamp as the previously received LCI for the same scope (e.g. from the same NF, NF Set, NF Service, NF Service Set or SCP), then the receiver shall discard the newly received LCI whilst continuing to apply the load control procedures according to the previously stored value.
The Load Metric shall indicate the current load level for the scope of the LCI, e.g. current load level of the NF instance if the scope indicated in the LCI indicates an NF instance, as a percentage within the range of 0 to100, where 0 means no or 0% load and 100 means maximum or 100% load reached (i.e. no further load is desirable). The computation of the load metric is implementation specific.
The scope of LCI indicates the applicability of the LCI, i.e. it identifies the components of the LCI sender to which the LCI relates to.
The following clauses provide a detailed description of the parameters that define the scope of the LCI header.
If an NF Service Consumer receives more than one LCI with overlapping scopes, i.e. one with NF (service) instance scope and another with NF (service) Set scope, the NF Service Consumer should perform load balancing considering the LCI received with the finer scope for each candidate NF instance or NF service instance (i.e. in this example the load of the NF (service) instance).
It is optional for the SMF to support S-NSSAI/DNN based load control. When supported, the following requirements shall apply.
S-NSSAI/DNN level load control refers to advertising of the load information at S-NSSAI and DNN level granularity and selection of the target SMF service instance based on this information. It helps to achieve an evenly load balanced network at S-NSSAI/DNN granularity by the use of the dynamic load information provided within the Load Control Information with the S-NSSAI/DNN scope. Only an SMF may advertise S-NSSAI/DNN level load information.
The "Load Metric" shall indicate the current resource utilization for the indicated S-NSSAI/DNN(s), as a percentage, as compared to the total resources configured for the indicated S-NSSAI/DNNs s at the SMF.
When performing S-NSSAI/DNN based load control, the LCI scope shall indicate, in addition to either an NF-Instance, NF-Set, NF-Service-Instance or NF-Service-Set (see Table 184.108.40.206.220.127.116.11-1), the combinations of S-NSSAI and DNN for which the LCI sender wants to advertise the load information using the following parameters:
the S-NSSAI parameter, indicating one or more S-NSSAI values; and
the DNN parameter, indicating one or more DNN values from the indicated S-NSSAI(s).
An SMF shall advertise S-NSSAI/DNN based load control for at most 10 DNNs.
The SMF may advertise load information for different DNNs of one or more S-NSSAIs in a single LCI header (if the same LCI information, e.g. load metric or relative capacity, applies to all the DNNs of the S-NSSAI(s)) or in up to 10 LCI headers (if different LCI information needs to be advertised for different DNNs).
When applying S-NSSAI/DNN based load control (see clause 18.104.22.168.4.2.2), the LCI shall include the S-NSSAI/DNN relative capacity indicating the resources configured for the combinations of S-NSSAIs and DNNs reported in the LCI, compared to the total resources configured at the SMF (service) instance or SMF (service) set, as a percentage.
This parameter enables the NF selecting an SMF service instance to determine the available resources for a given S-NSSAI/DNN for different candidate SMF service instances (considering the static capacity of the SMF service instance, the S-NSSAI/DNN relative capacity and the load of the S-NSSAI/DNN).
When registering with the NRF (NFRegister) or updating the NRF (NFUpdate), an NF that supports the LC-H feature shall indicate the feature support (see clause 22.214.171.124.2 in TS 29.510).
When an NF Service Consumer queries an NRF (NFDiscover) to discover services offered by NF Service Producers, the NRF shall indicate to the NF Service Consumer, if the NF Service Producers support the LC-H feature (see clause 126.96.36.199.3 in TS 29.510).
When selecting an NF Service Producer that supports the LC-H feature, the NF Service Consumer should not subscribe at the NRF to notifications triggered by the changes in the load of the selected NF Service Producer (see clause 188.8.131.52 in TS 29.510).