Method, system, and computer-readable medium for reporting reservation load to a network function in a communication network

Abstract

Disclosed are a method, a system, and a computer-readable medium for reporting a reservation load to a network function in a communication network. One method includes determining, by an NF service producer, a current computational load metric value for the NF service producer operating in the communication network, and detecting a number of active sessions supported by the NF service producer. The method further includes deriving a reservation computational load metric value corresponding to a predicted number of subsequent service requests in the NF service producer based on the number of active sessions and a predicted reservation load percentage value, and calculating an adjusted reported computational load metric value that is a sum of the current computational load metric value and the reservation computational load metric value.

Description

Technical Field

[0001] Claim of Priority This application claims the benefit of priority of U.S. Patent Application No. 17 / 751,572, filed on May 23, 2022, the entire disclosure of which is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to a reserved load handling method for avoiding overload conditions and request rejections in a network function (NF) service producer in a fifth generation (5G) communication network. More particularly, the subject matter described herein relates to a method, system, and computer-readable medium for reporting reserved load to a network function in a communication network.

Background Art

[0003] Background In a telecommunications network, a service endpoint is an address on a network node that uniquely identifies an entity that provides a service to a service consumer. A service endpoint can include an Internet Protocol (IP) address, or a combination of an IP address and a transport layer port number, and is also referred to as an IP endpoint.

[0004] In a fifth generation (5G) telecommunications network, a network node that provides a service is called a producer network function (NF). A network node that consumes a service is called a consumer NF. A network function can be both a producer NF and a consumer NF depending on whether it is consuming or providing a service.

[0005] A given producer NF may have multiple service endpoints. The producer NF registers with the Network Function Repository Function (NRF). The NRF maintains the NF profiles of available NF instances and the services they support. A consumer NF may subscribe to receive information about the producer NF instances registered with the NRF. Once registered, an NF instance in the 5G network can establish a session with one or more Network Exposure Functions (NEF). Note that the NEF is a 3rd Generation Partnership Project (3GPP (registered trademark)) network function that provides a means for securely exposing services and the capabilities provided by the producer network functions that offer services to the network.

[0006] At present, 3GPP enables the use of a load metric indicator that specifies the current computational load level of an NF instance. For example, the current computational load of an NF instance can be reported as a percentage within the range of 0 to 100% via a load control information (LCI) header, where 0 means there is no computational load (or 0% load) in the reporting NF instance, and 100% indicates that the maximum load exists in the reporting NF instance (i.e., the NF instance has reached 100% load and / or further load is not desirable). In many scenarios, both the actual computation and the use of the load metric indicator by the NF instance are implementation-specific. In many cases, the reported load parameters reported by the NF service producer can be used (along with other parameters) for NF service selection decisions and / or load distribution queries made by the NF service consumer. For example, if the computational load level at a given point in time in the NF service producer is reported as "low level", the NF service consumer is likely to select that NF service producer for resource creation mainly based on the current load level information of the NF service producer (e.g., the SMF selects the PCF for session creation). After being selected by the NF service consumer, the NF service producer is usually also configured to receive subsequent messages regarding the already accepted sessions and / or contexts. In some cases, the previously selected NF service producer may become unable to handle the reception and processing of these subsequent messages, thereby causing an undesirable delay in the services provided to the subscribed NF service consumer. From the perspective of these subsequent messages, reporting only the current load level is usually insufficient for the NF service consumer to protect itself against the possibility of future overload in the serving NF producer.

[0007] Therefore, there is a need for an improved method and system for reporting reservation load to network functions in a communication network. SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0008] Overview Disclosed are a method, a system, and a computer-readable medium for reporting reservation load to network functions in a communication network. One method includes determining, by an NF service producer, a current compute load metric value for the NF service producer operating in a communication network, and detecting a number of active sessions supported in the NF service producer. The method further includes deriving a reserved compute load metric value corresponding to a predicted number of subsequent service requests in the NF service producer based on the number of active sessions and a predicted reservation load percentage value, and calculating an adjusted reported compute load metric value that is a sum of the current compute load metric value and the reserved compute load metric value.

[0009] According to another aspect of the method described herein, the reserved compute load metric is adjusted by a weight modifier to obtain a weighted reserved compute load metric value.

[0010] According to another aspect of the method described herein, one or more report messages including the adjusted reported compute load metric value are generated.

[0011] According to another aspect of the method described herein, the one or more report messages are sent to respective one or more consumer service network functions.

[0012] According to another aspect of the methods described herein, each of one or more reporting messages includes a load control information (LCI) header that includes an adjusted reported compute load metric value.

[0013] According to another aspect of the methods described herein, one or more reporting messages are sent to respective one or more network function repository functions (NRFs).

[0014] According to another aspect of the methods described herein, each of one or more reporting messages includes an NfProfile section that includes an adjusted reported compute load metric value.

[0015] According to another aspect of the disclosed subject matter described herein, in a communication network, one system for reporting a reservation load to a network function is supported by at least one processor and memory and includes an NF service producer and a load management engine implemented by at least one processor configured to determine a current compute load metric value for the NF service producer operating in the communication network and to detect a number of active sessions supported by the NF service producer. The load management engine is also configured to derive a reserved compute load metric value corresponding to a predicted number of subsequent service requests at the NF service producer based on the number of active sessions and a predicted reservation load percentage value, and to calculate an adjusted reported compute load metric value that is the sum of the current compute load metric value and the reserved compute load metric value.

[0016] According to another aspect of the system described herein, a reserved compute load metric is adjusted by a weight modifier to obtain a weighted reserved compute load metric value.

[0017] According to another aspect of the system described herein, the load management engine is configured to generate one or more report messages that include an adjusted reported computational load metric value.

[0018] According to another aspect of the system described herein, the load management engine is configured to send one or more report messages to respective ones of one or more consumer service network functions.

[0019] According to another aspect of the system described herein, each of the one or more report messages includes a load control information header that includes an adjusted reported computational load metric value.

[0020] According to another aspect of the system described herein, the load management engine is configured to send one or more report messages to respective ones of one or more network function repository functions.

[0021] According to another aspect of the system described herein, each of the one or more report messages includes an NfProfile section that includes an adjusted reported computational load metric value.

[0022] The subject matter described in this specification can be implemented in hardware, software, firmware, or any combination thereof. Accordingly, the terms "function," "node," or "module," as used in this specification, mean hardware, which can also include software and / or firmware components for implementing the described features. In one exemplary embodiment, the subject matter described in this specification can be implemented using one or more computer-readable media storing computer-executable instructions that, when executed by a computer's processor, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described in this specification include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. Additionally, the computer-readable media for implementing the subject matter described in this specification can be disposed on a single device or computing platform, or can be distributed across multiple devices or computing platforms.

[0023] Here, the subject matter described in this specification will be described with reference to the accompanying drawings.

Brief Description of the Drawings

[0024]

Figure 1

Figure 2

Figure 3

Figure 4

[0025] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for reporting a reservation load to a network function in a communication network. In some embodiments, the disclosed subject matter provides a mechanism that enables an NF service producer to report a reservation compute load metric along with a current compute load metric value. Note that a subscriber NF service consumer can utilize the reservation compute load metric value to better evaluate the likelihood that a related NF service producer can provide services to the NF service consumer without experiencing excessive compute load and / or processing. Here, reference is made in detail to various embodiments of the subject matter described herein, examples of which are shown in the accompanying drawings. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or similar components.

[0026] FIG. 1 is a block diagram showing an exemplary 5G system network architecture, e.g., a home 5G core (5GC) network. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located within the same home public land mobile network (PLMN). As described above, the NRF 100 maintains profiles of available producer NF service instances and the services they support, enabling a consumer NF or SCP to subscribe to new / updated NF service instances and receive notification of their registration. The SCP 101 may also support service discovery and selection of NF instances. The SCP 101 may perform load distribution of connections between a consumer NF and a producer NF. In addition, using the methodologies described herein, the SCP 101 may perform preferred NF location-based selection and routing.

[0027] The NRF100 is a repository of NF instances or service profiles. To communicate with an NF instance, a consumer NF or SCP has to obtain an NF service profile or NF instance from the NRF100. The NF or service profile may be a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. In FIG. 1, any of the nodes (other than the NRF100) can be either a consumer NF or a producer NF, based on whether it is requesting or providing a service. In the illustrated example, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations within the network, an Integrated Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. The nodes shown in FIG. 1 further include a Session Management Function (SMF) 108 that manages sessions between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 performs authentication services for user devices such as a User Equipment (UE) 114 that requests access to the network.

[0028] The Network Slice Selection Function (NSSF) 116 provides network slicing services to devices that request access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an Application Programming Interface (API) for application functions that request information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs a function similar to the Service Capability Exposure Function (SCEF) in a 4G network.

[0029] The Radio Access Network (RAN) 120 connects the UE 114 to the network via a wireless link. The Radio Access Network 120 may be accessed using a g-NodeB (gNB) (not shown in FIG. 1) or other wireless access points. The User Plane Function (UPF) 122 may support various proxy functionalities for user plane services. One example of such proxy functionality is the Multipath Transmission Control Protocol (MPTCP) proxy functionality. The UPF 122 may also support a performance measurement function, which may be used by the UE 114 to obtain network performance measurements. Also shown in FIG. 1 is a Data Network (DN) 124, through which the UE accesses data network services such as Internet services.

[0030] The Security Edge Protection Proxy (SEPP) 126 filters incoming traffic from another PLMN and performs topology hiding for traffic going out from the home PLMN. The SEPP 126 may communicate with the SEPP within the external PLMN that manages the security for the external PLMN. Thus, traffic between NFs in different PLMNs may cross two SEPP functions, one for the home PLMN and the other for the external PLMN. In some embodiments, the SEPP is a gateway device positioned at the edge of the network.

[0031] The SEPP 126 may utilize the N32-c interface and the N32-f interface. The N32-c interface is a control plane interface between two SEPPs that can be used to perform an initial handshake (e.g., a TLS handshake) and negotiate various parameters for the N32-f interface connection and related message transfer. The N32-f interface is a transfer interface between two SEPPs that can be used to transfer various communications (e.g., 5GC requests) between a consumer NF and a producer NF after applying application-level security protection.

[0032] Figure 2 is a block diagram illustrating an exemplary NF 200 configured to report reservation load to network functions in a communication network, according to an embodiment of the subject matter described herein. The NF 200 can represent any suitable single or multiple entities (e.g., one or more nodes, devices, or computing platforms) for performing various aspects or functions described herein, such as determining a reservation capacity load and reporting it to other network functions in a communication network. In some embodiments, the NF 200 can include one or more functions defined by 3GPP and / or related functionality. For example, the NF 200 can include an NF service producer, etc.

[0033] Referring to FIG. 2, NF200 can include one or more communication interfaces 202 for communicating messages over a communication environment, such as one or more communication networks. For example, the communication interface 202 can include one or more communication interfaces for communicating with various entities in a home network (e.g., a home public land mobile network (H-PLMN)), a visited network (e.g., a visited public land mobile network (V-PLMN)), and / or other network functions operating in a 5G communication network.

[0034] In some embodiments, NF200 can include a load management engine (LME) 204. The load management engine 204 can be any suitable entity (e.g., software executed on at least one processor) for performing various operations related to determining a capacity load and reporting it to other network functions. For example, the load management engine 204 can: i) determine a current computational load metric value for an NF service producer operating in a communication network, ii) detect the number of active sessions supported in the NF service producer, iii) derive a reserved computational load metric value corresponding to the expected number of subsequent service requests in the NF service producer based on the number of active sessions and a predicted reserved load percentage value, and iv) be configured to calculate an adjusted reported computational load metric value that is the sum of the current computational load metric value and the reserved computational load metric value. The manner in which the load management engine performs these functions will be described in more detail below (see, for example, the descriptions of FIGS. 3 and 4).

[0035] In some embodiments, the load management engine 204 can include implementation logic configured to determine the current computational load level of the NF 200, which can be a NF service producer (e.g., represented as a current computational load metric value). It should be noted that the load management engine 204 can consider various parameters to calculate the current computational load level of the NF. For example, the load management engine 204 can be configured to calculate the computational load level by considering various resources such as CPU utilization, memory usage, disk utilization, etc. Further, the load management engine 204 can determine how these parameters are being utilized at the time of reporting. Based on these evaluations, the load management engine 204 can determine the current computational load metric value by evaluating the percentage (A%) of the underlying computational resources used to process the current traffic rate.

[0036] In addition, the load management engine is further configured to determine the number of active sessions currently supported by the NF 200, e.g., a NF service producer. It should be noted that the number of active sessions supported by the NF service producer can be used to calculate the reserved capacity load (e.g., a reserved computational load metric value) of the NF service producer.

[0037] In some embodiments, the load management engine 204 is adapted to determine the reservation load capacity of the NF service producer. For example, the load management engine can determine a predetermined percentage (R%) of active sessions (and / or contexts and / or resources) that represent the predicted reservation capacity load of the NF service producer. In some embodiments, this percentage is referred to as the reservation calculation load metric value. For example, if the NF service producer (i.e., NF200) supports 50,000 active sessions and a given operator parameter indicates that subsequent request messages reach 10% of the currently supported active sessions (i.e., the predicted reservation load percentage value), the load management engine 204 can be configured to calculate a reservation calculation load metric value that represents the rate (e.g., number of sessions per second or number of sessions per minute) at which subsequent messages associated with the active sessions are received over a given period (e.g., over 24 hours). In some embodiments, the 10% parameter value is defined based on the traffic mix typically received in the operator network. In such a scenario, the reservation calculation load metric value equals a rate of 5,000 sessions per second (i.e., 10% of 50,000 active sessions).

[0038] In some embodiments, the load management engine 204 is also configured to determine a weight modifier parameter (W%) associated with the reservation capacity load. Note that a weight modifier is used to set an appropriate weight to the reservation capacity load (i.e., the reservation calculation load metric value).

[0039] After each of the current computational load metric value, the reserved computational load metric value, and the weight modifier parameter has been determined by the load management engine 204, an adjusted reported computational load metric value can be determined. In some embodiments, the adjusted reported computational load metric value can be determined using the lower of [A%+(R%*W%)] or 100%. In particular, the load management engine 204 can determine the adjusted reported computational load metric value represented by the following operation.

[0040] min(A%+(R%*W%),‘100%’) For example, if the sum of the actual load percentage and the weighted reservation load is less than 100%, the load management engine 204 will report the calculated value as the reported load (i.e., the adjusted reported computational load metric value). If the calculated value exceeds 100%, the load management engine will instead report 100% as the adjusted reported computational load metric value.

[0041] In FIG. 2, NF200 and / or the load management engine 204 can access (e.g., read and / or write information to) the data storage 206. The data storage 206 can be any suitable entity (e.g., a computer-readable medium or memory) for storing a predetermined weight modifier, computational load determination logic, and / or any other predetermined network operator value.

[0042] It will be understood that FIG. 2 and its associated description are for illustrative purposes and that NF200 can include additional and / or different modules, components or functionality.

[0043] FIG. 3 shows an exemplary process for determining an adjusted reported load level. In particular, FIG. 3 shows an NF service consumer 322, an NF service producer 324, and an NRF 326 operating in a communication network. Note that the NF service producer 324 includes a load management engine (LME) 330 that can be configured to perform one or more of the operations described herein.

[0044] In block 302, the NF service producer 324 and / or the load management engine 330 are configured to determine a current compute load metric value representative of the compute load being received at the NF service producer 324. In some embodiments, the current compute load metric value can be expressed as an active load parameter (A%) that can represent a percentage representation of the current compute load being received by the NF service producer 324. For example, the load management engine 330 can determine that the current incoming traffic rate being processed by the NF service producer is 20,000 session requests per second (i.e., 20K / sec) and represents 40% of the maximum compute load handling capacity of the NF service producer 324. This numerical rate represents the total incoming message load received by the NF service producer, i.e., note that it represents the initial session / resource creation request message and subsequent session / resource request messages (associated with the initial creation request message). In some embodiments, the current incoming traffic rate is determined by a predetermined moving average (e.g., a rate determined over a period of the last 24 hours). Thus, the load management engine 330 can designate the determined value of 40% as the current load parameter "A%" (i.e., the parameter representing the current compute load metric value).

[0045] As described above, the current load level of the NF service provider instance (i.e., the current compute load metric value) can be evaluated using the implementation logic provisioned and / or included in the load management engine 330. Thus, the load management engine 330 can be configured to consider various operation metrics and parameters to reflect the current compute load level of the NF service producer 324. In some examples, the load management engine 330 can calculate the current compute load level by evaluating the various usage levels of the resources (CPU, memory, network bandwidth and processing latency, disk usage, etc.) underlying the NF being utilized by the NF service producer 324 at the time of reporting.

[0046] In block 303, the NF service producer 324 and / or the load management engine 330 are configured to determine or detect the number of active sessions currently supported by the NF service producer 324. In some embodiments, the load management engine 330 can utilize the implementation logic described above to confirm the number of active sessions supported in the NF service producer. For example, the load management engine 330 can determine that the NF service producer 324 is currently supporting 50,000 active sessions, which can include the sum of session creation request messaging and / or resource creation request messaging (e.g., SM associations accepted by the PCF from the SMF for the Npcf_SMPolicyControl_Create service operation) received but not yet terminated by the NF service producer.

[0047] In block 304, the NF service producer 324 and / or the load management engine 330 are configured to derive a reserved compute load metric value (e.g., a reservation load parameter). Note that this reserved compute load metric value is related to the active sessions and can represent predicted active sessions, contexts, and / or resources (i.e., predicted message traffic for existing sessions) that are subsequently received by the NF service producer 324. In some embodiments, the load management engine 330 can be configured to derive this value by applying a predetermined reservation load parameter (R%) (or predicted reservation load percentage value) to the active session load. For example, the load management engine 330 can determine that there is a 10% chance of receiving follow-up service requests for currently accepted active sessions (i.e., 50,000 active sessions) supported by the NF service producer based on operator network / traffic mix data. The predetermined 10% reservation load parameter (R%) is applied by the load management engine to the 50,000 active sessions, and as a result, a predicted traffic rate of 5,000 sessions per second is obtained. In some embodiments, 5K sessions / second is referred to as the "reservation capacity" or "predicted capacity". If 40% of the NF service producer's maximum compute load handling capacity is consumed when handling 20K incoming sessions per second, 10% additional capacity is required to handle the "reservation capacity" of 5K sessions (i.e., (40% / 20K)*5K = 10%). Here, the 10% parameter is referred to as the "reservation capacity load" or "predicted load" (i.e., the reservation load parameter, R%).

[0048] In block 306, the NF service producer 324 and / or the load management engine 330 are configured to determine a reservation load weight modifier parameter (W%). In some embodiments, the weight modifier parameter is a parameter value predefined by a network administrator. The weight modifier parameter can represent a mechanism by which an operator can assign different weights (or importance) to reservation compute load metric values. Note that the operator can specify or set the weight modifier parameter to be equal to any value in the range of 0% to 100%. For example, if the load management engine is configured to assign a 50% weight modifier to a reservation compute load metric value that reaches 10%, the resulting weighted reservation compute load metric value will be 5% (i.e., 50% * 10%). In some embodiments, the calculation and / or utilization of the weight modifier parameter is an optional function and / or feature.

[0049] In block 308, the NF service producer 324 and / or the load management engine 330 are configured to determine an adjusted reported compute load metric value. In some embodiments, the load management engine 330 can utilize the current load (e.g., the current compute load metric value), the reserved load (e.g., the reserved compute load metric value), and / or the weighted percentage value (e.g., the weight modifier) as input parameters for calculating the adjusted reported compute load metric value. For example, the load management engine 330 can utilize the formula min(A%+R%*W%,‘100’) shown above to determine the adjusted reported compute load metric value. Note that the adjusted reported compute load metric value can be determined to be equal to the lower of 40%+10%*50% (which is 40%+5% = 45%) as previously calculated in step 306. Note that since 45% is less than 100%, the load management engine 330 is configured to utilize 45% in this example. If the weight modifier is not applied (i.e., the reserved compute load metric value is not used), the adjusted reported compute load metric value is 40% (i.e., 40%+0%). If the entire weight modifier is applied (i.e., all reserved compute load metric values should be used / considered), the adjusted reported compute load metric value is 50% (i.e., 40%+10%).

[0050] After determining the adjusted reported compute load metric value, the NF service producer 324 can then receive a service request message 310 from the NF service consumer 322. Note that the service request message 310 can be any message from the NF service consumer that requests an NF service from the receiving NF service producer 324.

[0051] In response to receiving a service request message 310 from the NF service consumer 322, the NF service producer 324 and / or the load management engine 330 can be configured to proactively report current load capacity information and predicted load capacity information (i.e., the adjusted reported calculated load metric value) to the requesting NF service consumer in addition to the available NF service information. For example, the NF service producer 324 and / or the load management engine 330 can be configured to send a service response message 312 containing the adjusted reported calculated load metric value as a load metric parameter to the NF service consumer 322 (e.g., via an LCI header).

[0052] Although not fully within the scope of the disclosed subject matter, the NF service consumer 322 can utilize the adjusted reported calculated load metric value to evaluate whether the transmitting NF service producer 324 is an appropriate service provider and / or in any other manner. For example, the NF service consumer 322 can utilize the adjusted reported calculated load metric value to perform load distribution management operations in the communication network and make NF service producer selections.

[0053] In some embodiments, the NF service producer 324 and / or the load management engine 330 are configured to report the adjusted reported calculated load metric value to other NF instances such as the NRF and the NF service consumer without being triggered by an NF service request message. For example, the NF service producer 324 and / or the load management engine 330 can be configured to send a load report message 314 to the NRF 326 without a prompt and / or trigger (e.g., load information included in the NfProfile).

[0054] Figure 4 shows a flowchart illustrating method 400 for reporting reservation load to network functions in a communication network. In some embodiments, the exemplary method 400 described herein, or a portion thereof (e.g., an operation or step), can be executed in or by a network function and / or a module or engine supported by the network function (e.g., a load management engine).

[0055] In step 402, a current compute load metric value for an NF service producer operating in the communication network is determined. In some embodiments, the load management engine is configured to utilize implementation logic to determine the current compute load level at the NF service producer. Note that the NF service producer can calculate the compute load level at the NF service producer considering different parameters. For example, the load management engine can be configured to calculate the compute load level by considering various resources such as CPU utilization, memory usage, disk utilization, etc. Further, the load management engine can determine how these parameters are being utilized at the time of reporting. Based on these evaluations, the load management engine can determine the current compute load metric value.

[0056] In step 404, the number of active sessions supported at the NF service producer is detected. In some embodiments, the load management engine can include implementation logic for verifying the number of active sessions supported at the NF service producer. For example, the load management engine can determine that the NF service producer is currently supporting 50,000 active sessions, which can include the sum of session creation requests, resource creation requests, and any subsequent related messaging.

[0057] In step 406, based on the number of active sessions and the predicted reservation load percentage value, a reservation calculation load metric value corresponding to the predicted subsequent service request number in the NF service producer is derived. In some embodiments, the load management engine can be configured to determine, based on the traffic mix of the operator network, that the NF service producer will receive approximately 10% of subsequent service request messages per second for the currently active sessions supported over a predetermined period (e.g., the next 24 hours). For example, if it is determined (e.g., in step 404) that 50,000 active sessions are currently supported, the reservation rate representing the predicted subsequent traffic for the existing sessions will be equal to 5000 sessions per second (i.e., 10% of 50,000 active sessions). In some embodiments, this value is referred to as the reservation calculation load metric value, which can be based on the number of active sessions and the predicted reservation load percentage value and the predicted number of subsequent service requests in the NF service producer.

[0058] In step 408, a calculated adjusted reported calculation load metric value that is the sum of the current calculation load metric value and the reservation calculation load metric value is calculated. In some embodiments, the load management engine can utilize the determined current calculation load metric value, the reservation calculation load metric value, and / or (optional) weight modifiers as input parameters for calculating the adjusted reported calculation load metric value. For example, the load management engine 330 can utilize the formula min(A%+R%*W%,‘100’) shown above to determine the adjusted reported calculation load metric value.

[0059] In some embodiments, each NF service producer can be configured to calculate an adjusted reported computational load metric value (or reserved capacity) in its own way (i.e., each reserved load can be calculated in a different form for each NF service instance). Some exemplary configurations include "PercentageReqForActiveSession", which involves the load management engine determining the predicted number of requests for active sessions currently being served by the NF service producer instance. Note that this process will provide the reserved capacity for calculating the reserved load. Further, the network operator can derive this value from its traffic mix or other analysis data available through internal or external sources. To disable the function, the operator can set this to 0 (e.g., via the load management engine). A second configuration for calculating the reserved capacity includes the "WeightageReservedCapacity" configuration, which represents a weighted value of the reserved computational load relative to the actual computational load. To disable this weight modifier feature, the operator can set this to 0.

[0060] Similarly, the load management engine can be configured to publish reserved capacity to the NRF or LCI using the "IncludeReservedCapacityToLoad" configuration. When set to "true", the reported load (i.e., the adjusted reported computed load metric value) includes the reserved load (in the NRF and LCI). However, when this configuration is set to "false", the actual reported computed load (in the NRF or LCI) is the actual computed load, while the current computed load metric value (actual load) is published in the custom header, along with the LCI (i.e., using the LCI configuration and structure), but as a custom header, for example, together with 3gpp-Sbi-Lci (for publishing the load value). The load management engine can also publish a custom header "vendor-reserved-Lci" (for the actual computed load and reserved capacity).

[0061] For simplicity, when configuring the load management engine to calculate the reserved compute load metric of the NF service producer, the network operator can select one of the following options. First, the load management engine can have "WeightedReservedLoad" set to 100%, while "PercentageReqForActiveSession" is adjusted to obtain the adjusted reserved load (i.e., the adjusted reported computed load value). Alternatively, the load management engine can have "PercentageReqForActiveSession" set to 100%, while "WeightedReservedLoad" is adjusted to obtain the adjusted reserved load. Additionally, the load management engine can have each of "PercentageReqForActiveSession" and "WeightedReservedLoad" appropriately set to obtain the adjusted reserved load (as described above).

[0062] It should be noted that the NF instances, load management engines, and / or functions described herein can be configured by or facilitated by dedicated computing devices. Further, the load management engines and / or functionality described herein can improve the technical field of network function communication by providing a mechanism by which an NF service consumer can more reliably select an NF service producer based on a combination of current and predicted computing loads. Accordingly, load distribution between an NF service producer and corresponding network communications can be utilized more effectively.

[0063] Furthermore, there are several other advantages to utilizing reservation load information as described above. For example, the probability that an NF service producer reaches an overload condition is significantly reduced. As proposed by 3GPP specifications, an NF service consumer can select an NF service producer with a lower computing load value. By considering predicted / expected traffic flows for existing sessions in the calculation of the reported load, an NF service producer will avoid frequently receiving overload conditions.

[0064] Similarly, the disclosed subject matter can reduce traffic rejection and improve performance. Since an NF service producer considers potential messages for already accepted sessions, the load management engine can help maintain bandwidth and processing capacity. Thus, use of the disclosed subject matter leads to a reduction in the number of message rejections (e.g., caused by overload conditions), and thus, results in improved throughput and performance.

[0065] The disclosure of each of the following references is hereby incorporated by reference in its entirety. References 1. 1.3 rdGeneration Partnership Project; Technical Specification 5G; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 16) 3GPP TS 29.500 V16.7.0 (2021-04) 2. 3 rd Generation Partnership Project; Technical Specification 5G; 5G System; Network function repository services; Stage 3 (Release 16) 3GPP TS 29.510 V16.8.0 (2021-08) It will be understood that the various details of the subject matter disclosed herein can be changed without departing from the scope of the subject matter disclosed herein. Further, the above description is for illustrative purposes only and not for purposes of limitation.

Claims

1. 1. A method for reporting reservation load to a Network Function (NF) in a communication network, comprising: determining, by a NF service producer, a current calculated load metric value for the NF service producer operating in the communication network; Detecting the number of active sessions supported at the NF service producer; deriving a reservation calculation load metric value corresponding to a predicted number of subsequent service requests at the NF service producer based on the number of active sessions and a predicted reservation load percentage value; and calculating an adjusted reported computational load metric value that is the sum of the current computational load metric value and the reserved computational load metric value.

2. The method of claim 1 , wherein the reservation computation load metric value is adjusted by a weight modifier to obtain a weighted reservation computation load metric value.

3. The method of claim 1 or claim 2, comprising generating one or more reporting messages including the adjusted reported computational load metric values.

4. The method of claim 3 , comprising sending the one or more reporting messages to one or more consumer service network functions, respectively.

5. The method of claim 3 , wherein each of the one or more reporting messages includes a Load Control Information (LCI) header that includes the adjusted reported calculated load metric value.

6. The method of claim 3 , comprising sending the one or more reporting messages to one or more Network Function Repository Functions (NRFs), respectively.

7. The method of claim 6 , wherein each of the one or more reporting messages includes an NfProfile section that includes the adjusted reported computational load metric value.

8. 1. A system for reporting reservation load to a network function (NF) in a communication network, comprising: an NF service producer supported by at least one processor and memory; a load management engine implemented by the at least one processor; The load management engine determining current computed load metric values ​​for the NF service producers operating in the communication network; Detecting the number of active sessions supported at the NF service producer; deriving a reservation calculation load metric value corresponding to a predicted number of subsequent service requests at the NF service producer based on the number of active sessions and a predicted reservation load percentage value; and calculating an adjusted reported computational load metric value that is the sum of the current computational load metric value and the reserved computational load metric value.

9. The system of claim 8 , wherein the reservation calculation load metric value is adjusted by a weight modifier to obtain a weighted reservation calculation load metric value.

10. The system of claim 8 or claim 9, wherein the load management engine is configured to generate one or more reporting messages including the adjusted calculated reported load metric values.

11. The system of claim 10 , wherein the load management engine is configured to send the one or more reporting messages to one or more consumer service network functions, respectively.

12. The system of claim 10 , wherein each of the one or more reporting messages includes a Load Control Information (LCI) header that includes the adjusted reported calculated load metric value.

13. The system of claim 10 , wherein the load management engine is configured to transmit the one or more reporting messages to one or more Network Function Repository Functions (NRFs), respectively.

14. The system of claim 13 , wherein each of the one or more reporting messages includes an NfProfile section that includes the adjusted reported computational load metric value.

15. When executed by at least one processor of a computer, the computer determining, by a network function (NF) service producer, current computed load metric values ​​for said NF service producers operating in a communication network; Detecting the number of active sessions supported at the NF service producer; deriving a reservation calculation load metric value corresponding to a predicted number of subsequent service requests at the NF service producer based on the number of active sessions and a predicted reservation load percentage value; and calculating an adjusted reported computational load metric value that is the sum of the current computational load metric value and the reserved computational load metric value.

16. 16. The computer readable program of claim 15, wherein the reservation calculation load metric value is adjusted by a weight modifier to obtain a weighted reservation calculation load metric value.

17. 17. The computer readable program of claim 15 or claim 16, wherein the steps include generating one or more reporting messages that include the adjusted reported computational load metric values.

18. 20. The computer readable program of claim 17, wherein said steps include sending said one or more reporting messages to respective one or more consumer service network functions.

19. 20. The computer-readable program of claim 17, wherein each of the one or more reporting messages includes a Load Control Information (LCI) header that includes the adjusted reported calculated load metric value.

20. 20. The computer readable program of claim 17, wherein said step includes sending said one or more reporting messages to respective one or more Network Function Repository Functions (NRFs).

Images