Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3…   5.2.3.3…   5.2.4…   6…   6.4…   6.5…   6.6…   6.7…   6.10…   6.11…   A…

 

6  General Functionalities in Service Based Architecturep. 64

6.1  Routing Mechanismsp. 64

6.1.1  Generalp. 64

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 5 of RFC 7230 is almost followed with some differences due to the adoption of HTTP/2 and to some 5G system specificities.
Up

6.1.2  Identifying a target resourcep. 64

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).

6.1.3  Connecting inboundp. 64

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 5.2 of 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.
Up

6.1.4  Pseudo-header settingp. 64

6.1.4.1  Generalp. 64

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 "*".
Up

6.1.4.2  Routing within a PLMNp. 65

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:
":authority" = uri-host [":" port] as specified in Section 8.1.2.3 of RFC 7540, excluding the [userinfo "@"] information as specified in Section 3.2 of RFC 3986].
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.
Up

6.1.4.3  Routing across PLMNp. 65

6.1.4.3.1  General |R16|p. 65
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:
":authority" = uri-host [":" port] as specified in Section 8.1.2.3 of RFC 7540, excluding the [userinfo "@"] information as specified in Section 3.2 of RFC 3986.
Where the uri-host shall be:
  • 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 6.1.4.3.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 6.1.4.3.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).
Up
6.1.4.3.2  Use of telescopic FQDN between NFs and SEPP within a PLMN |R16|p. 66
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.
Up
6.1.4.3.3  Use of 3gpp-Sbi-Target-apiRoot between NFs and SEPP within a PLMN |R16|p. 66
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.
Up
6.1.4.3.4  Routing between SEPPs |R16|p. 67
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 5.3.2.4 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.
Up

6.1.5  Host headerp. 67

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

6.1.6  Message forwardingp. 67

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.

6.2  Server-Initiated Communicationp. 67

6.2.1  General |R17|p. 67

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 TS 29.501, clause 5.3.7.
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.
Up

6.2.2  Subscription on behalf of NF Service Consumer |R17|p. 68

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 the following information in the "3gpp-Sbi-Consumer-Info" header:
  • 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.
When the target NF is an AMF, the source AMF should forward the information in the received "3gpp-Sbi-Consumer-Info" header 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.
Up

6.2.3  Notification error handling |R18|p. 69

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.
Up

6.3  Load Controlp. 69

6.3.1  General |R16|p. 69

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.
Up

6.3.2  Load Control based on load signalled via the NRF |R16|p. 69

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.
Up

6.3.3  Load Control based on LCI Header |R16|p. 69

6.3.3.1  Generalp. 69

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.
Up

6.3.3.2  Conveyance of Load Control Informationp. 70

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.
Up

6.3.3.3  Frequency of Conveyancep. 70

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.
Up

6.3.3.4  Load Control Informationp. 70

6.3.3.4.1  General Descriptionp. 70
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 6.3.3.4.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 or SEPP 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 5.2.3.2.10 for the complete list of parameters).
Up
6.3.3.4.2  Load Control Timestampp. 71
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, SCP or SEPP (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, SCP or SEPP), then the receiver shall discard the newly received LCI whilst continuing to apply the load control procedures according to the previously stored value.
Up
6.3.3.4.3  Load Metricp. 71
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.
6.3.3.4.4  Scope of LCIp. 71
6.3.3.4.4.1  Introduction p. 71
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.
6.3.3.4.4.2  Scope of LCI signalled by an NF Service Producer p. 71
6.3.3.4.4.2.1  Generalp. 71
The LCI sent by an NF Service Producer shall include one of the parameters defined in Table 6.3.3.4.4.2.1-1.
Parameter Value LCI scope (i.e. LCI applies to) Examples
NF-InstanceNF Instance IDAll services of the NF instance identified by the NF Instance ID.NF-Instance: 54804518-4191-46b3-955c-ac631f953ed8
NF-SetNF Set IDAll services of all NF instances of the NF set identified by the NF Set ID.NF-Set: set1.udmset.5gc.mnc012.mcc345
NF-Service-Instance (and NF-Inst)NF Service Instance ID (and NF Instance ID)The service instance identified by the NF Service Instance ID and the NF instance Id (if available) or the last known NF instance ID.NF-Service-Instance: serv1.smf1; NF-Inst: 54804518-4191-46b3-955c-ac631f953ed8
NF-Service-SetNF Service Set IDAll service instances of the NF service set identified by the NF service set ID.NF-Service-Set: setxyz.snnsmf-pdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345
 
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).
Up
6.3.3.4.4.2.2  Additional scope parameters for S-NSSAI/DNN based load control by SMFp. 72
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 6.3.3.4.4.2.2.1-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).
See Table 6.3.3.4.4.2.2.1-1.
Parameter Value LCI scope (i.e. LCI applies to) Examples
S-NSSAIOne or more S-NSSAI values DNN(s) from indicated S-NSSAI(s), for the service(s) of NF instance(s) as defined in Table 6.3.3.4.4.2.1-1. S-NSSAI: %7B%22sst%22%3A 1%2C %22sd%22%3A %22A08923%22%7D; DNN: internet.mnc012.mcc345.gprs
DNNOne or more DNN values
NOTE 1:
Both the S-NSSAI and DNN parameters shall be present. The S-NSSAI and DNN parameters shall be provided with either the NF-Instance, NF-Set, NF-Service-Instance or NF-Service-Set parameter (see Table 6.3.3.4.4.2.1-1).
NOTE 2:
The S-NSSAI parameter in the Example corresponds to the JSON encoding: {"sst": 1, "sd": "A08923"} (see clause 5.2.3.1).
 
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).
Up
6.3.3.4.4.3  Scope of LCI signalled by an SCP p. 73
The LCI sent by an SCP shall include one of the parameters defined in Table 6.3.3.4.4.3-1.
Parameter Value LCI scope (i.e. LCI applies to) Examples
SCP-FQDNSCP FQDNSCP identified by the SCP FQDNSCP-FQDN: scp1.example.com
Up
6.3.3.4.4.4  Scope of LCI signalled by an SEPP p. 73
The LCI sent by an SEPP shall include one of the parameters defined in Table 6.3.3.4.4.4-1.
Parameter Value LCI scope (i.e. LCI applies to) Examples
SEPP-FQDNSEPP FQDNSEPP identified by the SEPP FQDNSEPP-FQDN: sepp1.example.com
Up
6.3.3.4.5  S-NSSAI/DNN Relative Capacityp. 73
When applying S-NSSAI/DNN based load control (see clause 6.3.3.4.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).
Up

6.3.3.5  LC-H feature supportp. 74

6.3.3.5.1  Indicating supports for the LC-H featurep. 74
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 6.1.6.2.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 6.2.6.2.3 in TS 29.510).
Up
6.3.3.5.2  Utilizing the LC-H feature support indicationp. 74
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 5.2.2.5 in TS 29.510).

Up   Top   ToC