Methods, systems, and computer-readable media for Hypertext Transfer Protocol (HTTP) stream tuning for load and overload control

Abstract

A method for HTTP stream tuning during load and overload control includes determining a load / overload level at a first network node (NF). The method further includes determining an initial value for the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter. The method also includes publishing the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to a second network node (NF) sending traffic to the first NF. The method further includes determining that the load / overload level of the first NF has changed. In response to determining that the load / overload level has changed, the method further includes adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of the change. The method also includes publishing the adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to the second NF.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 203,693, filed March 16, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This document describes topics related to load and overload control in communication networks. More specifically, it describes methods, systems, and computer-readable media for HTTP stream tuning for load and overload control. Background Technology

[0004] In 5G telecommunications networks, network functions that provide services are referred to as producer network functions (NFs) or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or both consumes and produces services. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0005] A given producer NF can have multiple service endpoints, where a service endpoint is a contact point used for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of Internet Protocol (IP) address and port number, or by a fully qualified domain name that resolves to an IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Store (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services, or directly routes traffic to the destination producer NF instance.

[0008] Besides SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Secure Edge Protection Proxy (SEPP). The SEPP is a network node used to protect control plane traffic exchanged between different 5G Public Terrestrial Mobile Networks (PLMNs). The SEPP performs message filtering, policing, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] One problem in 5G communication networks is the ineffective mechanism for preventing consumer NFs from overloading producer NFs. For example, existing 3GPP-defined procedures allow NF service producers to signal load information to service consumers. However, load information is optional and can be ignored by the service consumer. Furthermore, load information can be sent as low-priority messages that may not reach the service consumer or arrive in time to prevent the producer NF from becoming overloaded. 3GPP also mentions that producer NFs can use TCP and HTTP procedures for overload control. However, TCP procedures are connection-specific, and while HTTP procedures are mentioned, no methods are described for dynamically adjusting load and overload control thresholds to address changing network needs. Therefore, NF service producer resources may become overwhelmed, leading to retries to alternative NF service producers on the consumer NF side, wasting network and NF service consumer resources.

[0010] Therefore, in view of these and other difficulties, there is a need for improved methods, systems and computer-readable media for throttling traffic from NF service consumers. Summary of the Invention

[0011] A method for Hypertext Transfer Protocol (HTTP) stream tuning during load and overload control includes determining a load / overload level at a first network function (NF) including at least one processor and memory. The method further includes determining an initial value for an HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter. The method further includes publishing the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to a second NF that sends traffic to the first NF. The method further includes determining that the load / overload level of the first NF has changed. The method further includes adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of the change in load / overload level in response to determining that the load / overload level has changed. The method further includes publishing the adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to the second NF.

[0012] According to another aspect of the subject matter described herein, the first NF includes the producer NF and the second NF includes the consumer NF that sends traffic to the producer NF.

[0013] According to another aspect of the subject matter described herein, the first NF includes a producer NF and the second NF includes a service communication agent (SCP) or a secure edge protection agent (SEPP) that sends traffic to the producer NF.

[0014] According to another aspect of the subject matter described herein, the first NF includes a Service Communication Agent (SCP) or a Secure Edge Protection Agent (SEPP) and the second NF includes a consumer NF that sends traffic to the SCP or SEPP.

[0015] According to another aspect of the subject described in this article, determining the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter involves calculating the initial value based on the expected transaction rate per second of the second NF and the round-trip time for message passing between the first and second NFs.

[0016] According to another aspect of the subject matter described herein, determining initial values ​​based on the expected transaction rate and round-trip time involves using the following equation to determine the initial values:

[0017]

[0018] Where MaxConStrms is the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, RTT is the round-trip time between the first NF and the second NF, and RequestRate is the expected request rate from the second NF.

[0019] According to another aspect of the subject matter described in this article, determining that the load / overload level has changed includes determining that the load / overload level has increased.

[0020] According to another aspect of the topic described in this article, adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter involves reducing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires and repeating this reduction until the minimum flow count for the current load / overload level is reached.

[0021] According to another aspect of the subject matter described in this article, determining that the load / overload level has changed includes determining that the load / overload level has decreased.

[0022] According to another aspect of the topic described in this article, adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter involves increasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires and repeating this increase until the maximum flow count of the current load / overload level is reached.

[0023] According to another aspect of the subject matter described herein, a system for tuning a Hypertext Transfer Protocol (HTTP) stream during load and overload control is provided. The system includes a first network function (NF) including at least one processor and memory. The system also includes a load / overload controller implemented by the at least one processor, configured to determine a load / overload level of the first NF, determine an initial value for the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, publish the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to a second NF, determine that the load / overload level of either the first or second NF has changed, adjust the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of the change in load / overload level in response to the determination that the load / overload level has changed, and publish the adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to the second NF.

[0024] According to another aspect of the subject matter described herein, the load / overload controller is configured to determine the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the expected transaction rate per second of the second NF and the round-trip time of message passing between the first and second NFs.

[0025] According to another aspect of the subject matter described herein, the load / overload controller is configured to determine the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter using the following equation:

[0026]

[0027] Where MaxConStrms is the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, RTT is the round-trip time between the first NF and the second NF, and RequestRate is the expected request rate from the second NF.

[0028] According to another aspect of the subject described in this article, the load / overload controller is configured to determine that the load / overload level has increased.

[0029] According to another aspect of the subject described in this article, the load / overload controller is configured to adjust the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by decreasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires, and repeat this decrease until the minimum flow count of the current load / overload level is reached.

[0030] According to another aspect of the subject matter described in this article, the load / overload controller is configured to determine that the load / overload level has decreased.

[0031] According to another aspect of the subject described in this article, the load / overload controller is configured to adjust the value of the HTTPSETTINGS_MAX_CONCURRENT_STREAMS parameter by increasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires, and repeat this increase until the maximum flow count of the current load / overload level is reached.

[0032] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions controlling a computer to perform steps when executed by a computer's processor. The steps include determining a load / overload level at a first network function (NF) including at least one processor. The steps also include determining an initial value for a Hypertext Transfer Protocol (HTTP) SETTINGS_MAX_CONCURRENT_STREAMS parameter. The steps further include publishing the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to a second NF that sends traffic to the first NF. The steps also include determining that the load / overload level of the first NF has changed. The steps further include adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of the change in load / overload level in response to determining that the load / overload level has changed. The steps also include publishing the adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to the second NF.

[0033] The subjects described herein can be implemented using software in conjunction with hardware and / or firmware. For example, the subjects described herein can be implemented as software executed by a processor. In one exemplary embodiment, the subjects described herein can be implemented using a non-transitory computer-readable medium having computer-executable instructions stored thereon, which, when executed by a computer's processor, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subjects described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subjects described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0034] Figure 1 This is a network diagram illustrating an exemplary 5G system network architecture;

[0035] Figure 2 This is a message flow diagram illustrating an example message exchanged during the load / overload control process as defined by 3GPP.

[0036] Figure 3 This diagram illustrates the timing of the round-trip time (RTT) that can be used to determine the value of SETTINGS_MAX_CONCURRENT_STREAMS to achieve the expected request rate from the consumer NF.

[0037] Figure 4 This is a flowchart illustrating an exemplary process for setting the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter during load and overload control;

[0038] Figure 5 This is a diagram illustrating the adjustment of SETTINGS_MAX_CONCURRENT_STREAMS based on load / overload levels;

[0039] Figure 6 This is a flowchart illustrating an exemplary process for dynamically adjusting the SETTINGS_MAX_CONCURRENT_STREAMS parameter during load and overload control; and

[0040] Figure 7 This is a block diagram illustrating an exemplary producer NF, SCP, or SEPP for dynamically adjusting the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter during load and overload control. Detailed Implementation

[0041] Figure 1This is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Household Public Land Mobile Network (HPLMN). As described above, NRF 100 maintains profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 also supports service discovery and producer NF instance selection. SCP 101 can perform load balancing for connections between consumer and producer NFs.

[0042] NRF 100 is a repository of service profiles for NF or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain an NF or service profile or a producer NF instance from NRF 100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. An 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.

[0043] exist Figure 1 In this context, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether they request a service, provide a service, or request and provide a service. In the illustrated example, the NFs include a PCF 102 that performs policy-related operations in the network, a UDM function 104 that manages user data, and an application function (AF) 106 that provides application services.

[0044] Figure 1 The NF illustrated also includes a Session Management Function (SMF) 108 that manages the session between Access and Mobility Management Function (AMF) 110 and PCF 102. AMF 110 performs mobility management operations similar to those performed by the Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for User Equipment (UE) seeking network access, such as User Equipment (UE) 114.

[0045] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and features associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0046] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access the radio access network 120. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions that can be used by the UE 114 to obtain network performance measurements. Figure 1 The diagram also illustrates data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0047] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the external PLMN that manages the security of the external PLMN. Therefore, traffic between NFs in different PLMNs may pass through two SEPP functions, one for the local PLMN and the other for the external PLMN.

[0048] As mentioned above, one problem that arises in 5G networks is the lack of effective mechanisms for load and overload control. 3GPP TS29.500 defines the load and overload control procedures to be used by NF service providers. For example, Section 6.3.1 of 3GPP TS29.500 specifies:

[0049] • Load control enables NF service producers to send their load information either via NRF to NF service consumers (as defined in Section 6.3.2) or directly to NF service consumers (as defined in Section 6.3.3). The load information reflects the operational status of the NF service producer's resources.

[0050] • Load control allows for better load balancing among NF service producers, thus attempting to prevent overload in the first place (precautionary measure). Load control will not trigger overload mitigation operations even if an NF service producer reports high load.

[0051] In the paragraph quoted above, 3GPP TS29.500 defines the process by which NF service producers notify NF service consumers of load conditions. Figure 2 The diagram illustrates these two load control mechanisms. Figure 2In the message flow diagram, in line 1, consumer NF 200 sends a discovery request to NRF 100. It is assumed that producer NF 202 has previously registered with NRF 100. In line 2, NRF 100 responds to the discovery request with the NF profile of producer NF 202. The NF profile includes the payload information of producer NF 202. This corresponds to the first mechanism described above regarding 3GPP TS29.500 for transmitting payload information to consumer NFs during service discovery. In line 3, consumer NF 200 sends a Service-Based Interface (SBI) service request to producer NF 202. In line 4, producer NF 202 sends an SBI service response to consumer NF 200. The SBI service response may include payload control information specified or carried in the header of the SBI service response. As will be described in more detail below, one problem with these two mechanisms is that the consumer NF 200 may ignore load information or load control information and may still overwhelm the resources of the producer NF 202.

[0052] Overload control for 5G networks is defined in Section 6.4 of 3GPP TS29.500. In Section 6.4.1, 3GPP TS29.500 specifies the following:

[0053] • Service-based interfaces use TCP-based HTTP / 2 to communicate between NF services. TCP provides transport-level congestion control mechanisms as specified in IETF RFC 5681

[16] , which can be used for congestion control (i.e., hop-by-hop) between two TCP endpoints. HTTP / 2 also provides flow control mechanisms and limits on flow concurrency, which can be configured for connection-level congestion control as specified in IETF RFC 7540[7].

[0054] In the paragraph quoted above, 3GPP TS29.500 mentions that TCP and HTTP / 2 provide flow control mechanisms, but does not define a process for combining these mechanisms to dynamically control the message rate of a consumer NF.

[0055] One issue with using existing 3GPP-defined load control mechanisms in 5G networks is the slow speed of the aforementioned NRF-based load information publishing model, as it requires three nodes (producer NF, NRF, and consumer NF) to respond to the load level of the producer NF. To address this, 3GPP TS29.500 recommends optional Load Control Information (LCI) and Overload Control Information (OCI) headers that can be published directly from either the producer NF or consumer NF (also applicable to notification paths). 3GPP TS29.500 recommends that load and overload indicators be carried on top of responses to service requests or notifications for endpoints. This means that the processing of load and overload information in response messages is controlled by the value of 3gpp-Sbi-Message-Priority and the flow priority attribute. One problem with carrying LCI and OCI information on existing response messages with message-based or flow-based priorities is that message-based or flow-based priorities may be low, and low priority means that messages may be rejected at intermediate nodes if they become congested. Furthermore, the processing of low-priority messages is delayed at the consumer NF because other high-priority responses are processed first. Furthermore, because load and overload indicators are optional data, the consumer NF ignores them. Because the consumer NF ignores these indicators, the producer NF cannot expect the consumer NF to throttle the load on the producer NF. When the consumer NF continuously loads the producer NF, causing an overload, the producer NF has no choice but to throttle the traffic. This process wastes resources and delays traffic processing.

[0056] An example of resources wasted due to producer NF overload is processing resources at the consumer NF. Another example is network resources between the consumer and producer NFs. Producer NF processing resources can also be wasted on deciding to reject messages from the consumer NF. Consumer NF and network resources can be further wasted by the consumer NF needing to retry service requests via a backup producer NF.

[0057] Developing overload avoidance and control strategies to reduce the number of rejections will bring the following benefits:

[0058] Better utilization of network and computing resources; and

[0059] Consumer NF can enable higher throughput with better latency for the SBI interface in 5G networks.

[0060] The proposed solution described in this paper allows the producer NF to specify the maximum number of concurrent HTTP / 2 streams it will allow, thereby forcing the consumer NF to throttle traffic. The producer NF dynamically adjusts the maximum number of concurrent HTTP / 2 streams to maintain the desired load level at the producer NF. This mechanism works seamlessly with the load and overload procedures defined in 3GPP above. Using concurrent HTTP / 2 streams to control the load of the producer NF complements the 3GPP-defined solution and forces the consumer NF to reduce traffic based on the producer NF's load / overload level.

[0061] This article describes a method for controlling the message rate of a consumer function node (NF) using HTTP concurrent stream parameters. The HTTP / 2 specification (IETF RFC 7540) allows endpoints to control “concurrent streams” at runtime. This means that an HTTP / 2 server (i.e., the producer NF) can control the number of active / open streams that an HTTP / 2 client (i.e., the consumer NF) can have for a given connection. This article describes a mechanism for an HTTP / 2 server to manipulate the maximum number of allowed concurrent streams during load and overload conditions.

[0062] Section 5.1.2 of IETF RFC 7540 stipulates the following:

[0063] Peers can use the SETTINGS_MAX_CONCURRENT_STREAMS parameter within the SETTINGS frame (see Section 6.5.2) to limit the number of concurrent active streams. The maximum concurrent stream setting is per endpoint and applies only to the peer receiving the setting.

[0064] ...

[0065] Endpoints must not exceed the limits set by their peers.

[0066] ...

[0067] Endpoints that wish to reduce the value of SETTINGS_MAX_CONCURRENT_STREAMS to below the number of currently open streams can either close streams exceeding the new value or allow streams to complete.

[0068] In the paragraph quoted above, IETF RFC 7540 indicates that endpoints can set and use the SETTINGS_MAX_CONCURRENT_STREAMS parameter to control the maximum number of open streams allowed on a peer endpoint. Section 6.5 of IETF RFC 7540 specifies the following:

[0069] SETTINGS frames must be sent by both endpoints at the start of the connection, and It can be used during the lifetime of the connection. Send from either endpoint at any other time. (Emphasis added.)

[0070] In Section 6.5, IETF RFC 7540 indicates that SETTINGS frames carrying the SETTINGS_MAX_CONCURRENT_STREAMS parameter must be sent at the start of a connection, but can be sent by the endpoint at other times during the connection's lifetime. The subject described herein allows the producer NF to initialize the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the expected processing latency at the producer NF, and then adjust the SETTINGS_MAX_CONCURRENT_STREAMS parameter to control the consumer NF's loading of the producer NF.

[0071] The HTTP / 2 SETTINGS_MAX_CONCURRENT_STREAMS parameter can be used to control the message rate of the consumer NF. Figure 3 This is a timing diagram illustrating the minimum, average, and maximum message round-trip time (RTT) between the client and server applications. Figure 3 In this model, the minimum RTT is 50ms, the average RTT is 65ms, and the maximum RTT is 100ms. For a minimum RTT of 50ms, a stream created at t0 will be responded to and processed at t50. Therefore, if the number of concurrent streams from the consumer NF reaches the value equal to the SETTINGS_MAX_CONCURRENT_STREAMS parameter within the 50ms window, the consumer NF cannot send further requests until the producer NF responds at t50. Thus, by controlling the maximum number of concurrent streams, the producer NF can control the rate of traffic from the consumer NF on a given connection. For example, if the SETTINGS_MAX_CONCURRENT_STREAMS parameter is set to 32, the maximum request rate can be calculated as follows:

[0072]

[0073] Equation 1 is written in general form and solved by SETTINGS_MAX_CONCURRENT_STREAMS to obtain:

[0074]

[0075]

[0076] According to Equation 2, if the RTT and the expected request rate are known, then the value of MaxConStrms can be calculated, which is the value of SETTINGS_MAX_CONCURRENT_STREAMS.

[0077] Table 1 below illustrates how the maximum request rate from the client (consumer NF) on a single HTTP / 2 connection can be defined using the SETTINGS_MAX_CONCURRENT_STREAMS parameter from the server / producer NF:

[0078]

[0079]

[0080] Table 1: Maximum Possible Request Rate Given Maximum Concurrent Flow Settings and RTT Value

[0081] For each RTT and SETTINGS_MAX_CONCURRENT_STREAMS parameter value, the maximum message rate in Table 1 is calculated using the same calculation as Equation 1 above. Therefore, based on the SBI service request processing latency at the producer NF, if the producer NF adjusts the SETTINGS_MAX_CONCURRENT_STREAMS parameter value, then the producer NF can control the amount of traffic flowing from the consumer NF.

[0082] This article describes recommended strategies that producer NFs can follow to adjust the HTTP / 2 SETTINGS_MAX_CONCURRENT_STREAMS value for consumer NFs. The solutions described also apply to intermediate nodes, such as SCPs or SEPPs, to control the rate of traffic from consumer NFs. If implemented at an SCP or SEPP, the SETTINGS_MAX_CONCURRENT_STREAMS parameter of the consumer NF can be adjusted based on the load or overload level of the SCP or SEPP.

[0083] As mentioned above Figure 3 As indicated in Table 1, HTTP / 2 concurrent flow manipulation can help the producer NF control traffic flow. However, there can be "N" different consumer NFs connected to the producer NF, and each consumer NF can establish "M" HTTP / 2 connections with the producer NF. Therefore, using a fixed value for the SETTINGS_MAX_CONCURRENT_STREAMS parameter to avoid congestion during connection establishment is not a feasible option for the producer NF.

[0084] Regardless of the number of connections, the following rules still apply:

[0085] More traffic means more message processing, which in turn means higher resource utilization.

[0086] Increased traffic processing leads to an increase in the average message processing time (due to waiting for computation and other resources). Therefore, as traffic increases (beyond the break-even point), the average processing time for requests and responses will increase. Consequently, the average processing time and / or load / overload level (based on CPU utilization and / or other parameters) can be used by the producer NF to determine when and by how much to adjust the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter.

[0087] The value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter cannot be static. The topic described in this article allows producer NFs to dynamically adjust (increase or decrease) the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter, enabling consumer NFs to adjust their flow rates accordingly.

[0088] The topics described in this paper can be inspired by TCP's slow-start behavior during congestion. However, the topics described in this paper are not a direct application of TCP congestion control behavior, i.e., the producer NF dynamically adjusts (increases or decreases) the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter as the load level and / or RTT at the producer NF changes.

[0089] The following steps can be performed by the producer NF or intermediate nodes to control the load / overload at the producer NF or intermediate nodes using the SETTINGS_MAX_CONCURRENT_STREAMS parameter. Figure 4 The flowchart is explained in the text.

[0090] 1. Determine the load / overload level of the individual producer's NF service ( Figure 4 (Step 400 in the document). The load / overload level of the producer NF service instance can be an aggregation of CPU load / overload level, average request / response processing time, and other parameters such as queue depth. The topics described herein are not limited to any particular method used to define the load / overload level of the producer NF. If load / overload control is implemented at an intermediate node (SCP or SEPP), then the load / overload level used to trigger the load / overload control processing described herein can be the CPU load / overload level of the intermediate node, average request / response processing time, queue depth, etc.

[0091] 2. Determine the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter for a connection to a given NF service instance / source IP address. Figure 4 Step 402 in the middle.

[0092] Using the expected processing time (i.e., RTT) and the maximum supported message rate, calculate the initial value of SETTINGS_MAX_CONCURRENT_STREAMS, as mentioned above. Figure 3 As described in Table 1.

[0093] 3. When a consumer NF connects to a producer NF to access a service, the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter is published to the consumer NF. Figure 4 Step 404 in the middle.

[0094] If a consumer NF is allowed to consume multiple services from a producer NF on a single connection, then the maximum supported message rate is the sum of the rates of the services that the consumer NF is allowed to consume.

[0095] If the node being throttled is an SCP or SEPP, then step 404 will be implemented by issuing an initial value for the SETTINGS_MAX_CONCURRENT_STREAMS parameter to the SCP or SEPP.

[0096] 4. Determine whether the load or overload status of the producer NF (or intermediate node) has increased or decreased to a new level. Figure 4 Step 406 in the above steps, and if so, then adjust the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of change of the load / overload level (i.e., whether the level is increasing or decreasing). Figure 4 Step 408 in the process.

[0097] When the service provided by the producer NF (or intermediate node) reaches a higher load / overload level, perform the following actions:

[0098] When a regular interval / timer (referred to as "CT" in Table 2) expires, the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter is reduced by a fixed percentage (referred to as "D" in Table 2 below) until the lower limit (referred to as "M" in Table 2) is reached or the system is removed from the current load / overload level.

[0099] For example, when the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter is 8000 and the producer NF moves from L0 to load level L1, the value of SETTINGS_MAX_CONCURRENT_STREAMS PARAMETER is reduced by 5% every 10 seconds until the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter reaches 6000 or the producer NF moves out of L1.

[0100] When the producer NF (or intermediate node) moves to a lower load / overload level, perform the following actions:

[0101] After a regular interval / timer (referred to as "RT" in Table 2) expires, the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter is increased by a certain percentage (referred to as "D" in Table 2) until the maximum increase is reached (referred to as "M" in Table 2).

[0102] For example, when the producer NF moves from level L2 to level L1, the SETTINGS_MAX_CONCURRENT_STREAMS parameter is increased by 5% every 8 seconds (this is the rate of decline of level L1) until the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter reaches 6000.

[0103] For a given service (at the producer NF or intermediate node) and considering the load / overload levels of four configurations (L1 to L4), Table 2 illustrates the parameters that can be used to adjust the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter.

[0104]

[0105]

[0106] Table 2: Adjustment control parameters for SETTINGS_MAX_CONCURRENT_STREAMS

[0107] The values ​​in Table 2 are shown for illustrative purposes only and can be adjusted based on parameters such as the processing latency of the producer NF, the maximum number of transactions per second (TPS) per connection, and the capacity of the producer NF.

[0108] Table 3 below illustrates examples of the parameters in Table 2, populated with exemplary values ​​based on a producer NF or intermediate node with a processing latency of 100ms and a maximum flow rate of 5000 TPS per connection. According to Equation 1 above, the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter is set to 500 (500*100 / 1000). Based on this initial value and configuration, the flow adjustments for various load / overload levels will be as follows:

[0109] LO D M CD = D * initial value CM = M * initial value 0 0.01 1 5 500 1 0.02 0.2 10 400 2 0.03 0.2 15 300 3 0.05 0.3 25 150 4 0.07 0.1 35 100

[0110] Table 3: Example values ​​for adjusting the SETTINGS_MAX_CONCURRENT_STREAMS parameter

[0111] As mentioned above, CT is a timer for the current LO level, used to reduce the number of concurrent flows when the producer NF enters a (higher) congestion level. RT is a timer for the current LO level, used to increase the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter when the producer NF or intermediate nodes move to a lower / normal congestion level. Figure 5 This is a diagram illustrating the adjustment of the message rate at the producer NF based on the data in Table 3.

[0112] Figure 6 This is a more detailed flowchart illustrating the process of adjusting the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter. Figure 6 In this context, OldLoLevel and NewLoLevel refer to objects used to store the current load level and its corresponding CT, RT, CD, and CM values. (See reference) Figure 6In step 600, the process begins with the current count of concurrent flows and the objects OldLoLevel and NewLoLevel that store the current values ​​of the CT, RT, CD, and CM variables. Control then proceeds to step 602, where the process includes determining whether the current load / overload level is less than a new load / overload level. This determination is made by the producer NF or intermediate node based on load metrics set by the network operator (e.g., processing capacity, queue depth, memory utilization, etc.). If the current load / overload level is less than the new load / overload level, this means that the load on the producer NF or intermediate node has increased beyond one of the thresholds defined for increasing the level, and control proceeds to step 604, where the process includes determining whether the current flow count is greater than NewLoLevel.CM, which stores the maximum change value for each trigger value for the new level (see column 5 in Tables 2 and 3). If the current flow count is greater than NewLoLevel.CM, the number of flows can be reduced, and control proceeds to step 606, where the current flow count is reduced by the amount of NewLoLevel.CD, which stores the percentage change for each trigger value for the new level (see column 4 in Tables 2 and 3). Control then proceeds to step 608, where the value of the variable SETTINGS_MAX_CONCURRENT_STREAMS is set to the value of the current flow count variable after being reduced in step 606. Executing step 608 involves adjusting the SETTINGS_MAX_CONCURRENT_STREAMS parameter by sending a message to one or more consumer NFs, thereby providing one or more consumer NFs with a new setting for the SETTINGS_MAX_CONCURRENT_STREAMS parameter value to achieve the desired reduction in concurrent flows, which reduces the processing load on the producer NF or intermediate nodes. Control then proceeds to step 610, where the process waits for the NewLoLevel.CT timer to expire before returning to step 604. In step 604, given a lower limit determined for the current load / overload level, the process determines whether a further reduction in maximum concurrent flow can occur. If no further reduction can occur, control proceeds to step 612, where the process terminates.

[0113] Returning to step 602, if OldLoLevel is not less than NewLoLevel, control proceeds to step 614, where it is determined whether the current flow count can be increased (because the producer NF is in recovery mode). If the current flow count can be increased, control proceeds to step 616, where the flow count is increased by the amount NewLoLevel.CD defined for the new level. Control then proceeds to step 618, where the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter, after being increased in step 616, is set to the value of the CurrentStreamCount variable. The producer NF communicates the new value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter to one or more consumer NFs or one or more intermediate nodes, which in turn reduce the number of concurrent flows to the new value, which begins to increase the traffic load on the producer NF or intermediate nodes. Control then proceeds to step 620, where the process waits for the NewLoLevel.RT timer to expire. When the timer expires, control returns to step 614, where it is determined whether the flow count can be further increased, given the maximum value defined for the current load / overload level. If the current flow count can be increased, then repeat steps 616-620. If the flow count cannot be increased further, then the process ends.

[0114] At higher values of the LO level, the values of "D", "CT", and "M" can be set aggressively, i.e., the decrease in the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter for a lower "LO" level can be at a lower rate relative to the higher rate at the higher "LO" level. At early load / overload levels, instead of quickly closing the "flow gate", "hold and move" to cut off the flow. At higher load / overload levels, "slow down" faster to ensure system stability. At a given level, an RT value lower than the CT value helps to aggressively increase the number of concurrent streams when congestion is alleviated. For example, when the system moves from L0 to L1, the CT drives the interval during which the number of concurrent streams decreases. When the system moves from L2 to L1, the RT drives the interval during which the number of concurrent streams increases. Keeping RT > CT helps to increase the number of concurrent streams faster. If desired, the network operator can set RT = CT or RT < CT (for very slow recovery). The value of "M" can be determined based on the maximum number of TPS that the producer NF wants to support per connection at a given LO level. This solution can be further enhanced to add an additional limit to the number of HTTP / 2 connections from a given consumer NF at a given LO level. With this enhancement, the producer NF and intermediate nodes can effectively control the TPS that a given consumer or intermediate node can achieve at a specific load / overload level. This is a complement to the proposed solution for controlling the overall traffic on multiple connections from the consumer NF or intermediate nodes.

[0115] In the case where the producer NF is connected to the consumer NF via SCP or SEPP, the load / overload and other parameters can be calculated based on the aggregation of the load / overload levels of all services provided by the producer NF (e.g., the minimum load / overload level of all producer NF services). Similarly, considering all services provided by the producer NF, the maximum TPS per connection can be based on the sum of the maximum TPS that the producer NF can provide.

[0116] When combined with the tuning of the SETTINGS_MAX_CONCURRENT_STREAMS parameter, the LCI / OCI notification will force the consumer NF to slow down and / or send only higher-priority traffic to the producer NF. If any consumer NF ignores the LCI / OCI header data, then the consumer NF will be forced to throttle the traffic due to a lower number of concurrent streams per connection.

[0117] Figure 7 is a block diagram illustrating an example of a producer NF, SCP, or SEPP 202, 101, or 126 that performs load / overload control using the SETTINGS_MAX_CONCURRENT_STREAMS parameter as described above. Refer to Figure 7The producer NF, SCP, or SEPP 202, 101, or 126 includes at least one processor 700 and memory 702. A load / overload control data structure 704 may be stored in memory 702. The load / overload control data structure 704 may include data structures, such as those shown in Tables 1 and 2 above, for controlling the adjustment of the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the current load / overload level, changes in the level, and the direction of the change in the level. The load / overload controller 706 may be implemented using computer-executable instructions stored in memory 702 and executable by processor 700. The load / overload controller 706 may perform the steps described herein for adjusting the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the current load / overload level, changes in the level, and the direction of the change in the level.

[0118] The publicly available information in each of the following references is incorporated into this paper in its entirety through citation.

[0119] References

[0120] 1.3GPP TS 29.500 V16.7.0(2020-12); 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of the Service Based Architecture; Stage 3 (Release 17).

[0121] 2.3GPP TS 29.510 V17.0.0(2020-12); 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; NetworkFunction Repository Services; Stage 3 (Release 17).

[0122] 3. Belshe et.al, “Hypertext Transfer Protocol Version 2 (HTTP / 2),” IETFRFC 7540 (May 2015).

[0123] 4.TCP Congestion Control,https: / / en.wikipedia.org / wiki / TCP_congestion_control(last edited March 4,2021)

[0124] It should be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes, as the subject matter described herein is defined by the claims set forth below.

Claims

1. A method for tuning a Hypertext Transfer Protocol (HTTP) stream during load and overload control, the method comprising: At the first network function (NF), which includes at least one processor and memory: Determine the load / overload level of the first NF; Determine the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter; The initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is published to the second NF that sends traffic to the first NF; It has been determined that the load / overload level of the first NF has changed; In response to the determination that the load / overload level has changed, the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is adjusted based on the load / overload level and the direction of the change in load / overload level; as well as The adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is published to the second NF.

2. The method of claim 1, wherein the first NF includes a producer NF and the second NF includes a consumer NF that sends traffic to the producer NF.

3. The method of claim 1, wherein the first NF includes a producer NF and the second NF includes a service communication proxy (SCP) or a secure edge protection proxy (SEPP) that sends traffic to the producer NF.

4. The method of claim 1, wherein the first NF includes a Service Communication Proxy (SCP) or a Secure Edge Protection Proxy (SEPP) and the second NF includes a consumer NF that sends traffic to the SCP or SEPP.

5. The method of any of the preceding claims, wherein determining the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter comprises calculating the initial value based on the expected transaction rate per second of the second NF and the round-trip time of message passing between the first NF and the second NF.

6. The method of claim 5, wherein determining the initial value based on the expected transaction rate and round-trip time includes determining the initial value using the following equation: Where MaxConStrms is the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, RTT is the round-trip time between the first NF and the second NF, and RequestRate is the expected request rate from the second NF.

7. The method of any of the preceding claims, wherein determining that the load / overload level has changed includes determining that the load / overload level has increased.

8. The method of claim 7, wherein adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter comprises decreasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires and repeating the decrease until the minimum flow count of the current load / overload level is reached.

9. The method of any of the preceding claims, determining that the load / overload level has changed includes determining that the load / overload level has decreased.

10. The method of claim 9, wherein adjusting the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter comprises increasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires and repeating the increase until the maximum flow count of the current load / overload level is reached.

11. A system for tuning a Hypertext Transfer Protocol (HTTP) stream during load and overload control, the system comprising: The first network function (NF) includes at least one processor and memory; as well as A load / overload controller, implemented by the at least one processor, is configured to determine the load / overload level of a first NF, determine the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, publish the initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to a second NF that sends traffic to the first NF, determine that the load / overload level of either the first NF or the second NF has changed, adjust the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the load / overload level and the direction of the change in load / overload level in response to the determination that the load / overload level has changed, and publish the adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter to the second NF.

12. The system of claim 11, wherein the first NF includes a producer NF and the second NF includes a consumer NF that sends traffic to the producer NF.

13. The system of claim 11, wherein the first NF includes a producer NF and the second NF includes a service communication proxy (SCP) or a secure edge protection proxy (SEPP) that sends traffic to the producer NF.

14. The system of claim 11, wherein the first NF includes a Service Communication Agent (SCP) or a Secure Edge Protection Agent (SEPP) and the second NF includes a consumer NF that sends traffic to the SCP or SEPP.

15. The system of any one of claims 11 to 14, wherein the load / overload controller is configured to determine the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter based on the expected transaction rate per second of the second NF and the round-trip time of message passing between the first NF and the second NF.

16. The system of claim 15, wherein the load / overload controller is configured to determine the initial value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter using the following equation: Where MaxConStrms is the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter, RTT is the round-trip time between the first NF and the second NF, and RequestRate is the expected request rate from the second NF.

17. The system of any one of claims 11 to 16, wherein the load / overload controller is configured to determine that the load / overload level has increased.

18. The system of claim 17, wherein the load / overload controller is configured to adjust the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by decreasing the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by a fixed amount when the timer expires, and repeat the decrease until the minimum flow count of the current load / overload level is reached.

19. The system of any one of claims 11 to 18, wherein the load / overload controller is configured to determine that the load / overload level has decreased, and in response to the expiration of a timer, adjust the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter by increasing the value by a fixed amount and repeating the increase until the maximum flow count of the current load / overload level is reached.

20. A non-transitory computer-readable medium having stored executable instructions thereon, the executable instructions controlling the computer to perform steps when executed by a computer's processor, the steps including: At the first network function (NF), which includes at least one processor and memory: Determine the load / overload level of the first NF; Determine the initial value of the Hypertext Transfer Protocol (HTTP) SETTINGS_MAX_CONCURRENT_STREAMS parameter; The initial value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is published to the second NF that sends traffic to the first NF; It has been determined that the load / overload level of the first NF has changed; In response to the determination that the load / overload level has changed, the value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is adjusted based on the load / overload level and the direction of the change in load / overload level; as well as The adjusted value of the HTTP SETTINGS_MAX_CONCURRENT_STREAMS parameter is published to the second NF.

Images