Patent ID: 12256321

DETAILED DESCRIPTION

The subject matter described herein relates to methods, systems, and computer readable media for reporting a reserved load to a network function in a communications network. In some embodiments, the disclosed subject matter affords a mechanism that permits an NF service producer to report a reserved compute load metric value along with a current compute load metric value. Notably, a subscriber NF service consumer can utilize the reserved compute load metric value to better assess the likelihood that the associated NF service producer can service the NF service consumer without experiencing excessive compute loads and/or processing. Reference will now be made in detail to various embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

FIG.1is a block diagram illustrating an example 5G system network architecture, e.g., a home 5G core (5GC) network. The architecture inFIG.1includes an NRF100and a service communication proxy (SCP)101, which may be located in the same home public land mobile network (PLMN). As described above, NRF100may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated NF service instances. SCP101may also support service discovery and selection of NF instances. SCP101may perform load balancing of connections between consumer and producer NFs. In addition, using the methodologies described herein, SCP101may perform preferred NF location based selection and routing.

NRF100is a repository for NF or service profiles of NF instances. In order to communicate with a NF instance, a consumer NF or an SCP must obtain the NF service profile or the NF instance from NRF100. The NF or service profile is 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. InFIG.1, any of the nodes (other than NRF100) can be either consumer NFs or producer NFs, depending on whether they are requesting or providing services. In the illustrated example, the nodes include a policy control function (PCF)102that performs policy related operations in a network, a unified data management (UDM) function104that manages user data, and an application function (AF)106that provides application services. The nodes illustrated inFIG.1further include a session management function (SMF)108that manages sessions between access and mobility management function (AMF)110and PCF102. AMF110performs mobility management operations similar to those performed by a mobility management entity (MME) in 4G networks. An authentication server function (AUSF)112performs authentication services for user devices, such as user equipment (UE)114, seeking access to the network.

A network slice selection function (NSSF)116provides network slicing services for devices seeking to access specific network capabilities and characteristics associated with a network slice. A network exposure function (NEF)118provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs attached to the network. NEF118performs similar functions to the service capability exposure function (SCEF) in 4G networks.

A radio access network (RAN)120connects UE114to the network via a wireless link. Radio access network120may be accessed using a g-Node B (gNB) (not shown inFIG.1) or other wireless access point. A user plane function (UPF)122can support various proxy functionality for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. UPF122may also support performance measurement functionality, which may be used by UE114to obtain network performance measurements. Also illustrated inFIG.1is a data network (DN)124through which UEs access data network services, such as Internet services.

Security edge protection proxy (SEPP)126filters incoming traffic from another PLMN and performs topology hiding for traffic exiting the home PLMN. SEPP126may communicate with a SEPP in a foreign PLMN which manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN. In some embodiments, the SEPP is an gateway device positioned on the edge of a network.

SEPP126may utilize an N32-c interface and an N32-f interface. An N32-c interface is a control plane interface between two SEPPs usable for performing an initial handshake (e.g., a TLS handshake) and negotiating various parameters for an N32-f interface connection and related message forwarding. An N32-f interface is a forwarding interface between two SEPPs usable for forwarding various communications (e.g., 5GC requests) between a consumer NF and a producer NF after applying application level security protection.

FIG.2is a block diagram illustrating an example NF200configured for reporting a reserved load to network functions in a communications network according to an embodiment of the subject matter described herein. NF200may represent any suitable entity or entities (e.g., one or more node(s), device(s), or computing platform(s)) for performing various aspects or functionalities described herein, e.g., determining and reporting a reserved capacity load to other network functions in a communication network. In some embodiments, NF200may include one or more 3GPP defined functions and/or related functionality. For example, NF200may include a NF service producer or the like.

Referring toFIG.2, NF200may include one or more communications interface(s)202for communicating messages via a communications environment, e.g., one or more communications networks. For example, communications interface(s)202may include one or more communications interfaces for communicating with various entities in a home network (e.g., home public land mobile network (H-PLMN)), a visited network (e.g., a visited public land mobile network (V-PLMN)), and/or with other network functions operating in a 5G communications network.

In some embodiments, NF200may include a load management engine (LME)204. Load management engine204may be any suitable entity (e.g., software executing on at least one processor) for performing various operations associated with determining and reporting capacity loads to other network functions. For example, load management engine204may be configured for i) determining a current compute load metric value for the NF service producer operating in a communications network, ii) detecting a number of active sessions supported at the NF service producer, iii) deriving 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 predictive reserved load percentage value, and iv) calculating an adjusted reported compute load metric value amounting to a sum of the current compute load metric value and the reserved compute load metric value. The manner in which the load management engine performs these functions is described in greater detail below (e.g., see description ofFIGS.3and4).

In some embodiments, load management engine204may include implementation logic that is configured to determine the current compute load level (e.g., which may be represented as a current compute load metric value) of NF200, which may be a NF service producer. Notably, the load management engine204is able to account for different parameters to calculate the NF's current compute load level. For example, the load management engine204can be configured to calculate the compute load level by considering various resources, such as CPU utilization, memory usage, disk utilization, and the like. Further, the load management engine204can determine how these parameters are being utilized at the time of reporting. Based on these assessments, the load management engine204can determine a current compute load metric value by assessing the percentage (A %) by which the underlying compute resources are used to process the current traffic rate.

In addition, the load management engine is also further configured to determine the number of active sessions currently being supported by NF200, e.g., an NF service producer. Notably, the number of active sessions supported by the NF service producer can be used to calculate a reserved capacity load (e.g., a reserved compute load metric value) of the NF service producer.

In some embodiments, the load management engine204is adapted to determine the reserved load capacity of the NF service producer. For example, the load management engine may determine a predefined percentage (R %) of the active sessions (and/or contexts and/or resources) that represent a predicted reserved capacity load of the NF service producer. In some embodiments, this percentage is termed the reserved compute load metric value. For example, if the NF service producer (i.e., NF200) is supporting 50,000 active sessions and a predefined operator parameter indicates that subsequent request messages amounts to 10% (i.e., a predictive reserved load percentage value) of the active sessions currently supported, the load management engine204may be configured to calculate a reserved compute load metric value that represents a rate (e.g., sessions per second or sessions per minute) in which subsequent messages associated with the active sessions are to be received over a predefined period (e.g., over 24 hours). In some embodiments, a 10% parameter value is defined and based on the traffic mix typically experienced in the operator network. In such a scenario, the reserved computed load metric value would equal a rate of 5000 sessions per second (i.e., 10% of 50,000 active sessions).

In some embodiments the load management engine204is also configured to determine a weightage modifier parameter (W %) associated with the reserved capacity load. Notably, the weightage modifier is used to set an appropriate weight to the reserve capacity load (i.e., reserved compute load metric value).

After each of the current compute load metric value, reserved compute load metric value, and weightage modifier parameter is determined by the load management engine204, the adjusted reported compute load metric value can be determined. In some embodiments, the adjusted reported compute load metric value can be determined using the lower value of either [A %+(R %*W %)] or 100%. In particular, the load management engine204can determine an adjusted reported compute load metric value that is represented by the operation:
min(A%+(R%*W%),‘100%’)

For example, if the sum of the actual load percentage and the weighted reserved load is less than 100%, then the load management engine204will report the calculated value as the reported load (i.e., adjusted reported compute load metric value). If the calculated value is greater than 100%, the load management engine will instead report 100% as the adjusted reported compute load metric value.

InFIG.2, NF200and/or load management engine204may access (e.g., read from and/or write information to) data storage206. Data storage206may be any suitable entity (e.g., a computer readable medium or memory) for storing predetermined weightage modifiers, compute load determination logic, and/or any other predefined network operator values.

It will be appreciated thatFIG.2and its related description are for illustrative purposes and that NF200may include additional and/or different modules, components, or functionality.

FIG.3illustrates an exemplary process for determining an adjusted reported load level. In particular,FIG.3depicts an NF service consumer322, a NF service producer324, and a NRF326operating in a communications network. Notably, NF service producer324includes a load management engine (LME)330, which may be configured to execute one or more of the operations described herein.

In block302, NF service producer324and/or load management engine330is configured to determine a current compute load metric value that is representative of the compute load being experienced at NF service producer324. In some embodiments, the current compute load metric value can be represented as an active load parameter (A %), which may denote a percentage representation of the current compute load that is being experienced at NF service producer324. For example, the load management engine330may determine that the current ingress traffic rate being processed by the NF service producer is 20,000 session requests per second (i.e., 20K/sec) and represents a 40% of the maximum compute load processing capabilities of NF service producer324. Notably, this numerical rate represents the total ingress message load received by the NF service producer, i.e., represents the initial create session/resource request messages and subsequent session/resource request messages (associated with the initial create request messages). In some embodiments, the current ingress traffic rate is determined via a predefined moving average (e.g., rate determined over the last 24 hour period). Accordingly, the load management engine330may designate the 40% determined value as the current load parameter ‘A %’ (i.e., a parameter representing current compute load metric value).

As indicated above, the current load level (i.e., current compute load metric value) of an NF service provider instance can be assessed using implementation logic provisioned and/or included in load management engine330. Thus, the load management engine330may be configured to consider different operating metrics and parameters to reflect the current compute load level of NF service producer324. In some instances, load management engine330may calculate a current compute load level by assessing various use levels of the NF's underlying resources (such as CPU, memory, network bandwidth and processing latency, disk utilization, etc.) that are being utilized by the NF service producer324at reporting time.

In block303, NF service producer324and/or load management engine330is configured to determine or detect the number of active sessions currently being supported by the NF service producer324. In some embodiments, load management engine330can utilize the aforementioned implementation logic to ascertain the number of active sessions supported at the NF service producer. For example, load management engine330can determine NF service producer324is presently supporting 50,000 active sessions, which may include the sum of create session request messaging and/or create resource request messaging that are accepted by the NF service producer and are not yet terminated (e.g., SM associations accepted by PCF from SMF for Npcf_SMPolicyControl_Create Service Operation).

In block304, NF service producer324and/or load management engine330is configured to derive a reserved compute load metric value (e.g., a reserved load parameter). Notably, this reserved compute load metric value may represent the predicted active sessions, context, and/or resources (i.e., the predictive message traffic for existing sessions) that are related to the active sessions and that are subsequently received by the NF service producer324. In some embodiments, load management engine330may be configured to derive this value by applying a predefined reserved load parameter (R %) (or predictive reserved load percentage value) to the active session load. For example, load management engine330may determine that, based on operator network/traffic mix data, there is a 10% chance of receiving subsequent (or follow-up) service requests for the currently accepted active sessions supported by the NF service producer (i.e., the current 50,000 active sessions). The predetermined 10% reserved load parameter (R %) is applied by the load management engine to the 50,000 active sessions, which then results in a determination of a predictive traffic rate of 5000 sessions per second. In some embodiments, the 5K sessions/second is referred to as the ‘reserved capacity’ or ‘predictive capacity’. If 40% of the maximum compute load processing capabilities of the NF service producer is consumed when handling an ingress 20K sessions per second, then in order to handle a ‘reserved capacity’ of 5K sessions, an additional capacity of 10% is required (i.e., (40%/20K)*5K=10%). Here, the 10% parameter is referred to as the ‘reserved capacity load’ or “predictive load’ (i.e., reserved load parameter, R %)

In block306, NF service producer324and/or load management engine330is configured to determine a weightage modifier parameter (W %) of the reserved load. In some embodiments, the weightage modifier parameter is a parameter value that is predefined by a network administrator. The weightage modifier parameter may represent a mechanism by which the operator can assign different weightings (or importance) to the reserved compute load metric value. Notably, an operator can designate or set the weightage modifier parameter to be equal to any value ranging from 0% to 100%. For example, if the load management engine has been configured to assign a 50% weightage modifier to the reserved compute load metric value amounting to 10%, then the resulting weighted reserved compute load metric value will be 5% (i.e., 50%*10%). In some embodiments, the calculation and/or utilization of the weightage modifier parameter is an optional functionality and/or feature.

In block308, NF service producer324and/or load management engine330is configured to determine the adjusted reported compute load metric value. In some embodiments, load management engine330can utilize the current load (e.g., current compute load metric value), reserved load (e.g., reserved compute load metric value), and/or weighted percentage values (e.g., weightage modifier) as input parameters for calculating the adjusted reported compute load metric value. For example, load management engine330may utilize a min(A %+R %*W %, ‘100’) formula indicated above to determine the adjusted reported compute load metric value. Notably, the adjusted reported compute load metric value may be determined to be equal to the lesser of 40%+10%*50% (as previously calculated in step306), which amounts to 40%+5%=45%. Notably, 45% is less than 100%, so the load management engine330would be configured to utilize 45% in this example. If no weightage modifier was applied (i.e., no reserved compute load metric value is to be used), then the adjusted reported compute load metric value would be 40% (i.e., 40%+0%). If the entire weightage modifier is to be applied (i.e., all of the reserved compute load metric value should be used/considered), then the adjusted reported compute load metric value would be 50% (i.e., 40%+10%).

After determining the adjusted reported compute load metric value, NF service producer324may subsequently receive a service request message310from NF service consumer322. Notably, service request message310can be any message from a NF service consumer that requests an NF service from the receiving NF service producer324.

In response to receiving service request message310from NF service consumer322, NF service producer324and/or load management engine330may be configured to proactively report the current and predicted load capacity information (i.e., adjusted reported compute load metric value) to the requesting NF service consumer (in addition to available NF service information). For example, NF service producer324and/or load management engine330may be configured to send, to NF service consumer322, a service response message312that includes the adjusted reported compute load metric value as a load metric parameter (e.g., via LCI header).

Although not entirely within the scope of the disclosed subject matter, NF service consumer322can utilize the adjusted reported compute load metric value to assess whether the sending NF service producer324is an appropriate service provider and/or for any other manner. For example, NF service consumer322can utilize the adjusted reported compute load metric value to perform load balancing management actions in the communications network as well as to conduct NF service producer selections.

In some embodiments, NF service producer324and/or load management engine330is configured to report the adjusted reported compute load metric value to other NF instances, such as NRFs and NF service consumers without being triggered by a NF service request message. For example, NF service producer324and/or load management engine330may be configured to a send a report load message314to NRF326(e.g., load information included in NfProfile) without any prompting and/or trigger.

FIG.4illustrates a flow diagram illustrating a method400for reporting a reserved load to network functions in a communications network. In some embodiments, example method400described herein, or portions (e.g., operations or steps) thereof, may be performed at or performed by a network function, and/or a module or engine (e.g., load management engine) supported by the network function.

In step402, a current compute load metric value is determined for the NF service producer operating in a communications network. In some embodiments, a load management engine is configured to utilize implementation logic to determine the current compute load level of the at the NF service producer. Notably, the NF service producer is able to account for different parameters to calculate the compute load level at the NF service producer. 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, and the like. Further, the load management engine can determine how these parameters are being utilized at the time of reporting. Based on these assessments, the load management engine can determine a current compute load metric value.

In step404, a number of active sessions supported at the NF service producer is detected. In some embodiments, the load management engine can include implementation logic to ascertain the number of active sessions supported at the NF service producer. For example, the load management engine can determine NF service producer is presently supporting 50,000 active sessions, which may include the sum of create session requests, create resource requests, and any subsequent related messaging.

In step406, 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 predictive reserved load percentage value is derived. In some embodiments, the load management engine can be configured to determine, based on the operator network's traffic mix, that the NF service producer will receive approximately 10% subsequent service request message per second with respect to the currently active session supported over a predefined period (e.g., the next 24 hours). For example, if 50,000 active sessions were determined to be currently supported (e.g., in step404), then a reserved rate representative of the predictive subsequent traffic for the existing sessions would be equal to 5000 sessions per second (i.e., 10% of 50,000 active session). In some embodiments, this value is referred to as the reserved compute load metric value, which may be based on the predicted number of subsequent service requests at the NF service producer based on the number of active session and a predictive reserved load percentage value.

In step408, calculating an adjusted reported compute load metric value amounting to a sum of the current compute load metric value and the reserved compute load metric value. In some embodiments, the load management engine can utilize the determined current compute load metric value, reserved compute load metric value, and/or (optional) weightage modifier as input parameters for calculating the adjusted reported compute load metric value. For example, load management engine330may utilize a min(A %+R %*W %, ‘100’) formula indicated above to determine the adjusted reported compute load metric value.

In some embodiments, each NF service produce can be configured to calculate the adjusted reported compute load metric value (or reserved capacity) in a unique manner (i.e., each reserved load can be calculated differently for each NF service instance). Some example configurations include ‘PercentageReqForActiveSession’, which entails the load management engine determining a predictive number of requests for active sessions currently accepted by the NF service producer instance. Notably, this will process will provide a reserved capacity to compute the reserved load. Further, a network operator can derive this value from its traffic mix or other analytical data available through internal or external source. To disable the feature, operator can set it to 0 (e.g., via the load management engine). A second configuration for calculating the reserved capacity includes the ‘WeightageReservedCapacity’ configuration, which represents the weighted value of reserved compute load with respect to the actual compute load. To disable this weightage modifier feature, operator can set it to 0.

Likewise, the load management engine can be configured to publish the reserved capacity toward an NRF or LCI using the ‘IncludeReservedCapacityToLoad’ configuration. When set to ‘true’, the reported load (i.e., adjusted reported compute load metric value) includes reserved load (at NRF and LCI). However, when this configuration is set to ‘false’, the actual reported compute load (at NRF or LCI) is the real compute load, whereas current compute load metric value (actual load) along with the reserved compute load metric value (reserved capacity) is published in a custom header along with LCI (i.e., using construct and structure of LCI, but as a custom header, e.g., along with 3gpp-Sbi-Lci (to publish load value). The load management engine can also publish the custom header “vendor-reserved-Lci” (for actual compute load and reserved capacity).

For simplification, a network operator may choose one of the following options when configuring the load management engine to calculate the reserved compute load metric of the NF service producer. First, the load management engine may have ‘WeightedReservedLoad’ set to 100% while ‘PercentageReqForActiveSession’ is adjusted to obtain the adjusted reserved load (i.e., adjusted reported compute load value). Alternatively, the load management engine may have ‘PercentageReqForActiveSession’ set to 100% while ‘WeightedReservedLoad’ is adjusted to obtain the adjusted reserved load. Further, the load management engine may have each of ‘PercentageReqForActiveSession’ and ‘WeightedReservedLoad’ appropriately set to obtain the adjusted reserved load (as described above).

It should be noted that the NF instance(s), load management engine, and/or functionality described herein may constitute or be facilitated by a special purpose computing device. Further, the load management engine and/or functionality described herein can improve the technological field of network function communications by providing a mechanism by which NF service consumers can more reliably select an NF service producer based on the combination of a current compute load and a predicted compute load. Accordingly, the load balancing among NF service producers and corresponding network communications will be more efficiently utilized.

Further, there are other several benefits for utilizing the reserved load information as described above. For example, the probability that the NF service producer reaches an overload condition is significantly reduced. As suggested by 3GPP standards, an NF service consumer can select an NF service producer with lower compute load value. By considering the predicted/expected traffic flow for existing sessions in the calculation of the reported load, the NF service producer will avoid experiencing overload conditions on a frequent basis.

Similarly, the disclosed subject matter can lower traffic rejections and increase performance. Since the NF service producer accounts for potential messages for already accepted sessions, the load management engine can help reserve bandwidth and processing capability. Thus, use of the disclosed subject matter will lead to lower the number of message rejections (e.g., caused by overload conditions) and hence result in improved throughput and performance.

The disclosure of each of the following references is incorporated herein by reference in its entirety.

REFERENCES

1. 3rdGeneration 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. 3rdGeneration 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 various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.