Method, system, and computer-readable medium for rule-based overload control for 5G services

Abstract

A method for rule-based overload control for 5G services includes configuring overload message processing rules at an intermediate or producer network function (NF), at least some of the rules including a destination network name (DNN), a network subscription, a network location, or a network slice identification parameter, or any parameter / attribute defined by 3GPP / vendor, as a rule selection criterion. The method includes a guaranteed processing bandwidth of the intermediate or producer NF along with at least some of the overload message processing rules, receiving a first message at the intermediate or producer NF, determining that an overload condition exists, identifying that the first message includes a parameter that matches the rule selection criterion for one of the overload message processing rules, determining that a portion of the guaranteed processing bandwidth of the intermediate or producer NF for the matching overload message processing rule is available to process the first message, receiving the first message, and updating a message count for the overload message processing rule.

Description

[Technical field]

[0001] Priority application This application claims the benefit of priority to U.S. patent application Ser. No. 16 / 914,231 (filed June 26, 2020), which is a continuation-in-part of U.S. patent application Ser. No. 16 / 601,371 (filed October 14, 2019), the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to providing overload control in communication networks. More particularly, the subject matter described herein relates to providing rule-based overload control for 5G services. [Background technology]

[0003] background In 5G telecommunications networks, 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 consumes or provides a service.

[0004] A given producer NF may have many service endpoints, where a service endpoint is a combination of an IP address and a port number on the network node hosting the producer NF. Producer NFs register with a Network Function Repository Function (NRF). The NRF maintains NF profiles of available NF instances and their supported services. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0005] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the service communication proxy (SCP). An SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the service communication proxy, which load balances traffic between producer NF service instances that provide the required service or routes traffic directly to the destination producer NF.

[0006] In addition to SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include security edge protection proxies (SEPPs), service gateways, and nodes in a 5G service mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G PLMNs (Public Land Mobile Networks). Thus, SEPPs perform message filtering, policing, and topology hiding for all API messages.

[0007] A Service Gateway is a node that sits in front of a group of producer NFs offering a given service. A Service Gateway can load balance incoming service requests among the producer NFs offering the service in a similar way as an SCP.

[0008] A service mesh is the name for a group of intermediate proxy nodes that enable communication between producer NFs and consumer NFs. A service mesh may include one or more SCPs, SEPPs, and service gateways.

[0009] One problem with the existing 3GPP service architecture is that while message priority and congestion handling are defined in the 3GPP NF, all nodes between the consumer NF and the producer NF cannot register themselves as 5G NFs, e.g., intermediate proxies, service gateways between sites of the same vendor, etc. Thus, the consumer NF can only see the load of the target producer NF. There are no guidelines from 3GPP to define the behavior on the intermediate nodes. Also, 3GPP has not defined an overload handling mechanism in intermediate proxy nodes, such as SCPs, SEPPs, service gateways, or service meshes, to avoid starvation for low priority services. For example, if an SCP is handling traffic between a producer NF and a consumer NF and the producer NF is not overwhelmed, the traffic may proceed without invoking a congestion control procedure in the SCP. However, the sum of the traffic from the consumer NFs to the producer NF may overwhelm the SCP. Without a mechanism for handling traffic congestion in the SCP or other intermediate proxy nodes, such nodes may become congested and drop traffic for low priority services.

[0010] A further problem that may arise at an intermediate or producer NF is that a consumer NF may not set 5G message priority values ​​correctly or consistently so that traffic may be treated as desired by the network operator. For example, the 3GPP architecture relies on the consumer NF to set 5G message priority parameters in message headers, and when the same message type is sent to different destination network names (DNNs) or network slices, identified by a single network slice selection assistance information (S-NSSAI), the consumer NF may have difficulty setting the priority parameters to appropriate values. Because the consumer NF cannot be relied upon to set the 5G priority parameters reliably or uniformly, the 5G message priority parameters set by the consumer NF cannot be trusted alone as a basis for handling messages during overload conditions, because doing so may lead to service disruption for certain services.

[0011] Therefore, there is a need for a method, system, and computer-readable medium for rule-based overload control for 5G services. Summary of the Invention [Means for solving the problem]

[0012] overview A method for rule-based overload control for 5G services includes configuring overload message processing rules at an intermediate or producer network function (NF), at least some of the rules including a destination network name (DNN) or a network slice, subscription or location identification parameter as a rule selection criterion. The rules may include any other parameters or attributes defined by 3GPP or a vendor. The method further includes associating at the intermediate or producer NF a guaranteed processing bandwidth of the intermediate or producer NF with at least some of the overload message processing rules. The method further includes receiving a first message at the intermediate or producer NF. The method further includes the intermediate or producer NF determining that an overload condition exists. The method further includes the intermediate or producer NF identifying that the first message includes a parameter that matches a rule selection criterion for one of the overload message processing rules. The method further includes the intermediate or producer NF determining that a portion of the intermediate or producer NF's guaranteed processing bandwidth for the matching overload message processing rule is available to process the first message. The method further includes the intermediate or producer NF processing the first message using the portion of the intermediate or producer NF's guaranteed processing bandwidth for the matching overload message processing rule and updating a message count for the overload message processing rule.

[0013] According to another aspect of the subject matter described herein, configuring overload message handling rules includes configuring rules to treat messages of the same service type differently based on DNN or network slice, subscription, or location identification parameters, or 3GPP or vendor defined attributes / parameters.

[0014] According to another aspect of the subject matter described herein, configuring overload message processing rules includes configuring rules to treat messages of the same service type differently based on a defined parameter or combination of parameters.

[0015] According to another aspect of the subject matter described herein, associating the guaranteed processing bandwidth of an intermediate or producer NF with at least some of the overload message processing rules includes associating at least some of the overload message processing rules with buckets and configuring a message count corresponding to the guaranteed bandwidth for each rule along with each rule's corresponding bucket.

[0016] According to another aspect of the subject matter described herein, a method for providing rule-based overload control for 5G services includes tracking guaranteed bandwidth utilization for each rule by maintaining a count of the number of messages that match the rule for each bucket.

[0017] According to another aspect of the subject matter described herein, a method for providing rule-based overload control for 5G services includes creating dynamic overload message handling rules using information obtained from the response message, and using the dynamic overload message handling rules to ensure that messages related to a common session are processed by a common processor of an intermediate or producer NF.

[0018] According to another aspect of the subject matter described herein, the intermediate or producer NF may include a security edge protection proxy (SEPP), a service communication proxy (SCP), or a service mesh node.

[0019] According to another aspect of the subject matter described herein, the intermediate or producer NF comprises a producer NF.

[0020] According to another aspect of the subject matter described herein, a method for providing rules-based overload control for 5G services includes configuring, at an intermediate or producer NF, an unguaranteed bandwidth bucket that can be used to track the bandwidth of the intermediate or producer NF available for messages that do not match one of the configured overload message processing rules for which the guaranteed bandwidth of the intermediate or producer NF is configured.

[0021] According to another aspect of the subject matter described herein, a method for providing rule-based overload control for 5G services includes receiving a second message at an intermediate or producer NF, determining that the second message does not match one of the overload message processing rules for which a guaranteed bandwidth of the intermediate or producer NF is configured, determining that unguaranteed bandwidth is available for processing the second message using a non-guaranteed bandwidth bucket, and processing the message using the non-guaranteed bandwidth.

[0022] A system for rule-based overload control for 5G services includes an intermediate or producer network function (NF) including at least one processor. The system further includes an overload control configuration interface associated with the intermediate or producer NF to provide for configuring overload message processing rules used by the intermediate or producer NF to manage processing of messages during an overload condition, at least some of the rules including a destination network name (DNN) or a network slice, a subscription or location identification parameter or any other parameter as a rule selection criterion, and for associating a guaranteed bandwidth service with at least some of the overload message processing rules. The system further comprises an overload controller realized by the intermediate or producer NF for receiving the first message, determining that an overload condition exists, identifying that the first message includes parameters that match rule selection criteria for one of the overload message processing rules, determining that a portion of the guaranteed bandwidth for the matching overload message processing rule is available for processing the first message, forwarding the first message for further processing by the intermediate or producer NF, and updating a message count for the matching overload message processing rule.

[0023] According to another aspect of the subject matter described herein, the overload control configuration interface provides for configuration of rules to treat messages of the same service type differently based on a DNN or network slice identification parameter or any other parameter.

[0024] According to another aspect of the subject matter described herein, the overload control configuration interface provides for configuration of rules to treat messages of the same service type differently based on 3GPP or vendor defined attributes / parameters.

[0025] According to another aspect of the subject matter described herein, the overload control configuration interface provides for associating at least some of the overload message processing rules with buckets and for configuring a message count corresponding to a guaranteed bandwidth for each rule along with each rule's corresponding bucket.

[0026] According to another aspect of the subject matter described herein, the overload controller tracks the utilization of the guaranteed bandwidth for each rule by maintaining a count of the number of messages that match the rule for each bucket.

[0027] According to another aspect of the subject matter described herein, the overload controller creates dynamic overload message processing rules using information obtained from the response message, and uses the dynamic overload message processing rules to ensure that messages related to a common session are processed by a common processor of an intermediate or producer NF.

[0028] According to another aspect of the subject matter described herein, the overload control configuration interface provides for configuration of an unguaranteed bandwidth bucket that can be used to track the bandwidth of an intermediate or producer NF available for messages whose guaranteed bandwidth does not match one of the configured overload message processing rules.

[0029] According to another aspect of the subject matter described herein, the overload controller is configured to receive a second message, determine that the second message does not match one of the overload message processing rules for which a guaranteed bandwidth of the intermediate or producer NF is configured, determine that unguaranteed bandwidth is available for processing the second message using an unguaranteed bandwidth bucket, and forward the second message for further processing using the unguaranteed bandwidth.

[0030] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon that, when executed by a processor of the computer, control the computer to perform steps. The steps include configuring overload message processing rules at an intermediate or producer network function (NF), at least some of the rules including a destination network name (DNN) or a network slice, a subscription or location identification parameter, or a 3GPP or vendor-defined attribute / parameter as a rule selection criterion. The steps further include associating at the intermediate or producer NF a guaranteed processing bandwidth of the intermediate or producer NF with at least some of the overload message processing rules. The steps further include receiving a first message at the intermediate or producer NF. The steps further include the intermediate or producer NF determining that an overload condition exists. The steps further include the intermediate or producer NF identifying that the first message includes a parameter that matches a rule selection criterion for one of the overload message processing rules. The steps further include the intermediate or producer NF determining that a portion of the intermediate or producer NF's guaranteed processing bandwidth for the matching overload message processing rule is available to process the first message. The steps further include the intermediate or producer NF processing the first message using the portion of the intermediate or producer NF's guaranteed processing bandwidth for the matching overload message processing rule and updating a message count for the overload message processing rule.

[0031] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "module" as used herein refer to hardware that may also include software and / or firmware components to implement the described features. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium that stores computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform or distributed across multiple devices or computing platforms.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS The subject matter described herein will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0033] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G network architecture. [Diagram 2] FIG. 1 illustrates 5G network functions connected through intermediate proxy nodes, such as a service mesh. [Diagram 3] FIG. 1 is a network diagram illustrating potential congestion that may occur at intermediate proxy nodes between 5G network functions. [Figure 4] FIG. 1 is a block diagram illustrating network functions for implementing 5G rule-based overload control. [Diagram 5] FIG. 1 illustrates an exemplary data structure for implementing 5G rule-based overload control. [Figure 6] 1 is a flowchart illustrating an example process for 5G rule-based overload control. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for rule-based overload control for 5G services. FIG. 1 is a block diagram illustrating an example 5G system network architecture. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same Home Public Land Mobile Network (HPLMN). As mentioned above, the NRF 100 may maintain a profile of available producer NF service instances and their supported services, allowing consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of their registration. The SCP 101 may also support service discovery and selection of producer NFs. In addition, the SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

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

[0036] In FIG. 1, any node (other than SCP 101 and NRF 100) can be a consumer NF or a producer NF depending on whether they are requesting or providing a service. In the illustrated example, the node includes a Policy Control Function (PCF) 102 that performs policy related operations in the network, a User Data Management (UDM) Function 104 that manages user data, and an Application Function (AF) 106 that provides application services. The node shown in FIG. 1 further includes a Session Management Function (SMF) 108 that manages a session between an Access and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs operations similar to mobility management operations performed by a Mobility Management Entity (MME) in a 4G network. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE) seeking access to the network, such as the UE 114.

[0037] The Network Slice Selection Function (NSSF) 116 provides network slice services for devices that want to access specific network functions and features associated with the network slice. The Network Publish Function (NEF) 118 provides application programming interfaces (APIs) for application functions that want to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs functions similar to the Service Capability Publish Function (SCEF) in 4G networks.

[0038] The Radio Access Network (RAN) 120 connects the UE 114 to a network via a wireless link. The Radio Access Network 120 may be accessed using a gNodeB (gNB) (not shown in FIG. 1) or other wireless access points. The User Plane Function (UPF) 122 may support various proxy functions for user plane services. One example of such a proxy function is a Multi-Path Transmission Control Protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that 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.

[0039] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. The SEPP 126 can communicate with a SEPP in a foreign PLMN, which manages the security of 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. As mentioned above, the SEPP is an example of an intermediate proxy node that can be overwhelmed if proper congestion control and / or bandwidth reservation procedures are not implemented at the intermediate proxy node.

[0040] Guaranteed traffic bandwidth for messages that match overloaded message processing rules In 5G deployment architecture, 3GPP Releases 15 and 16 recommend proxy nodes such as SCPs or SEPPs between client / consumer NFs and server / producer NFs. Proxy nodes such as SCPs provide transport and routing functionality between N consumer NFs and M producer NFs, where N and M are integers. Similarly, network operators can deploy their own service mesh / intermediate gateway / controller nodes between 5G NFs. Service mesh / intermediate gateway / proxy nodes help to perform most common activities among various services, e.g., monitoring, overload control, traffic management, service discovery, etc. In 5G, each producer NF can publish its load level to the NRF. Consumer NFs can be reactive to register about such changes and adjust their traffic rates.

[0041] One problem with the existing 3GPP network architecture is that not all nodes between consumer NFs and producer NFs can register themselves as 5G NFs. These nodes that cannot register include intermediate proxies, service gateways, etc. between sites of the same vendor. Since intermediate proxy nodes cannot register with the NRF as 5G NFs, consumer nodes may not know the load on the intermediate proxy nodes and may overwhelm the intermediate proxy nodes. Similarly, the NRF provides notifications to service consumers that allow the consumers to see the load of the target producer nodes. However, since intermediate proxy nodes cannot register as service producers, there are no guidelines from 3GPP for responding to such notifications or defining the behavior on intermediate proxy nodes for issuing such notifications.

[0042] Even if an operator plans the capacity of its intermediate proxy nodes, signaling storms from rogue services / NFs may overload intermediate networks / nodes / routes. Therefore, a service mesh (or intermediate proxy such as SCP / SEPP) needs to configure policies that guarantee guaranteed traffic bandwidth for a given NF service messaging. The subject matter described herein includes enhancements in service mesh / SCP / SEPP / intermediate gateways, etc. for guaranteed serviceability of multiple services during congestion / overload conditions of intermediate proxy nodes. The subject matter described herein also includes enhancements in producer NFs that provide for rule-based overload control by producer NFs. Therefore, in the following description, the term "intermediate or producer NF" is used to refer to intermediate nodes such as SCPs, SEPPs, or service meshes, or producer NFs, where the rule-based overload control described herein is realized.

[0043] Regardless of shared or dedicated network, intermediate proxy nodes need a way to ensure guaranteed serviceability for messages that match operator-specified overloaded message handling rules. Without guaranteed serviceability, messaging between two nodes may exceed the capacity of the service mesh / intermediate proxy node, thus affecting the functionality of the intermediate proxy node and other services.

[0044] FIG. 2 illustrates how traffic between end nodes can overwhelm an intermediate NF, such as a service mesh. In FIG. 2, the AMF 110 is connected to a UDM 104 and another NF 200 via a service mesh 202. The AMF 200 provides a service Svc-X. The UDM 104 provides a service Svc-Y. The NF 200 provides a service Svc-Z. Messaging between Svc-X and Svc-Y may exhaust the capacity of the intermediate proxy node 202 (during a data storm or other such scenario). As a result, Svc-X → Svc-Z and Svc-Y → Svc-Z services may be adversely affected.

[0045] 5G does not provide guidance regarding the message priority to be used for messages within a given service. Per 3GPP TS 29.500, all messages without a client-defined priority shall have a default priority of 24. Also, it is extremely difficult for a vendor / operator to drive / assign a priority per service message, which can fairly justify its priority compared to other services in other NFs.

[0046] At the same time, to ensure stability of intermediate proxy nodes during data storm / overload conditions, operators set throttling policies that reject low priority messages once system capacity exceeds a certain point.

[0047] The following are examples of policies that may be implemented at intermediate proxy nodes when system capacity exceeds a certain point.

[0048] I. Reject all messages with priority ≧15 if system computational resource utilization is above 60%.

[0049] II. If system computing resource utilization exceeds 80%, reject all messages with priority ≧7.

[0050] While such policies can be useful, they do not take into account what happens to services with low priority messages / traffic during congestion events.

[0051] Another problem that arises when all lower priority messages are rejected in a congestion situation is that a priority-based threshold may cause a given service to be cut off if all messages of the given service are of a lower priority. For example, in FIG. 2, if all messages of service Svc-Z have the default priority and an intermediate proxy node becomes overloaded, all messages for service Svc-Z will be rejected, preventing service Svc-Z from being offered in the network.

[0052] In 5G deployments, there is the possibility of a many-to-many mapping between NFs (Network Functions) and services, i.e., a given NF may provide multiple services and a service may be provided by multiple NF instances.

[0053] FIG. 3 is a network diagram illustrating an example in which multiple producer NFs provide services to multiple consumer NFs. In the illustrated example, the consumer NFs are consumer NFs or AMFs 110a-110c. The producer NFs are UDM 104 and NF instance 200. The producer NFs and consumer NFs are connected via an intermediate proxy node 202. In an example, it may be assumed that 10 AMF instances and 10 UDM instances are running. Each UDM instance may be capable of handling 10 Kbps of traffic. However, multiple AMF instances running service Svc-X may flood the intermediate proxy node 202 with messaging destined for service Svc-Y provided or hosted by each instance of UDM 104. In addition, the intermediate proxy node 202 may require a policy to ensure that messaging for service Svc-Z can be provided by rejecting messages related to Svc-X and Svc-Y. Messages for service Svc-Z may have any priority, but there should not be a complete denial of service for service Svc-Z, even if service Svc-Z messages have a lower priority than messaging related to other services.

[0054] In 5G deployments, HTTP connections are on-demand. Therefore, it is conceivable that Svc-X in AMF instance 1 can instantiate multiple connections with intermediate proxy nodes to distribute traffic over multiple connections. For example, there may be 10 connections between Svc-X in AMF instance 1 and SCP / SEPP nodes. Thus, the overall traffic generated by a given Svc-X instance (10K for Svc-Y and 1K for Svc-Z) will be spread across 10 connections, i.e., each connection handles only 1.1K.

[0055] Therefore, performing ingress control based on the source service or per connection is not a viable option for a network implementing a service mesh, due to the multiple, and even on-demand, connections for the ingress traffic of the service.

[0056] Similarly, an intermediate proxy node may have ten connections to each instance of the UDM and may be connected to ten different instances of the UDM. Therefore, performing egress control based on the target node or per connection is not a viable option for a service mesh or an intermediate NF.

[0057] In addition to the problems in the intermediate proxy node, the producer NF and the services implemented by the producer NF may cause service disruptions to the consumer NF during overload events if the messaging and / or the producer NF are not properly configured to provide guaranteed bandwidth for messages that comply with the overload message handling rules. Generally, during overload events, there will be a discard policy to drop messages based on the local policy of the node to ensure node stability and functional processing. Generally, the discard policy is based on message priority. For example, when the load level is Y, discarded messages have a priority <X. This concept is based on the fact that the consumer or the sender selects the correct or appropriate message priority when sending a message to the producer or the end application.

[0058] In the case of the 5G architecture, 3GPP TS29.500 describes the 3gpp-Sbi-Message-Priority header that carries the 5G service message priority. According to TS29.500, 0 is the highest priority. However, the setting of the value of the 3gpp-Sbi-Message-Priority parameter is left as an implementation detail of the consumer NF.

[0059] The following use cases in 5G networks make it very difficult (if not impossible) to set discard policies based only on message priority: For example, when the same type of Service Based Interface (SBI) messages contain information about different DNNs, network slices, Subscriber Identities (SUPIs), locations, etc. (and this list is long and when additional models are enabled for vertical application layers, i.e., Service Enablement Architecture Layer (SEAL) for 5G or Vehicle-to-Everything (V2X) support). Since different DNNs, slices, etc. have different use cases to solve, to protect messages related to a given use case, consumer NFs must use different message priorities to guarantee QoS. Thus, consumer NFs cannot use a flat policy to assign priority "X" to all similar message types on a given service interface.

[0060] For example, when the SMF sends an SmPolicy Create Context message to the PCF (see 3GPP TS29.512), the SmPolicy Create Context message includes a DNN and an S-NSSAI. When an SMF instance processes messages for different DNNs or S-NSSAIs, it is difficult for the SMF to determine the message priority to be assigned to a given SmPolicy Create Context. Therefore, it is complex to enable such fine-grained policies in the consumer NF to set the correct priority for a given service message.

[0061] Even if an operator solves that problem by creating such a policy, it is highly unlikely that all consumer NFs will uniformly support the corresponding implementation. Intermediate (e.g., SCP / SEPP) and producer NFs may serve dedicated or shared sets of DNNs, network slices, SUPIs, etc. Thus, rejection of messages during overload conditions based on priority may lead to denial of service. Even if a consumer NF enables complex policies and sets appropriate priorities, when an intermediate or producer NF discards messages based on priority, the discarding of messages based on priority may trigger conditions that lead to denial of service for a particular set of DNNs / network slices / SUPIs, etc.

[0062] Denial of service attacks can have serious consequences for network operators. For example, when a PCF is overloaded, an operator may not want to shut down 100% of the traffic for a given DNN / network slice, etc. An operator cannot expect consumer NFs to inject the correct message priority to avoid denial of service. Therefore, custom policies need to be configured on a given node that provide guaranteed processing of messages that match traffic rules even during overload conditions. Since this problem is general to all intermediate and producer NF nodes, the solution described herein can be applied to all intermediate nodes (e.g., SCP / SEPP) and producer NFs (3GPP-defined or non-3GPP-defined) to guarantee guaranteed service at a given node even when the given node is overloaded.

[0063] The subject matter described herein includes an overload controller that tracks load levels at an intermediate or producer NF and applies rule-based overload control using overload message processing rules to identify guaranteed bandwidth for messages whose parameters match a particular rule. FIG. 4 illustrates an example of an NF, which may be an intermediate or producer NF, that includes an overload controller that provides guaranteed bandwidth for messages that match the overload processing rules. With reference to FIG. 4, the NF 400 includes at least one processor 402 and memory 404. The NF 400 also includes one or more service instances 406 that provide 3GPP or non-3GPP defined services. For example, the service instances 406 may provide any of the 3GPP defined services illustrated in FIG. 1 or non-3GPP defined services not illustrated in FIG. 1. The NF 400 also includes an overload controller 408 implemented at the service level and / or at the NF or node level to provide guaranteed bandwidth for messages that match the overload message processing rules. The NF 400 further includes an overload control configuration interface 410 that provides for configuring overload message processing rules used by intermediate or producer NFs to manage the processing of messages during overload conditions. At least some of the rules include a destination network name (DNN) or a network slice, subscription, or location identification parameter as a rule selection criterion. The overload control configuration interface 410 may also provide for associating a guaranteed bandwidth service with at least some of the overload message processing rules.

[0064] The above referenced parent application describes a solution that provides guaranteed traffic serving a given service. This applies for 5G and non-5G traffic. The solution details of that application can be applied to solve guaranteed service provisioning based not only on service name but also on any 5G defined parameters such as DNN, network slice, SUPI range, etc.

[0065] Any suitable mechanism may be used to detect an overload condition at an intermediate or producer NF. For example, an overload detection algorithm may consider the node's CPU utilization, the node's memory utilization, the incoming traffic rate, etc. The subject matter described herein includes defining a policy for selecting messages to be allowed / rejected during overload control. The solution may be applied in 5G NFs such as PCF, NRF, SCP, SEPP, or in non-3GPP defined NFs. The solution allows any operator to define custom policies to provide guaranteed service on a given node even during an overload condition. This helps operators support serviceability for different customer types, network locations, and other factors. Examples of customer types and other factors that may receive guaranteed bandwidth support in an overload condition include: Premium customers, ·Emergency call, - A specific DNN, A specific network slice, ·etc. Overall, the use cases enabled by the subject matter described herein for handling various traffic patterns (even during node overload / congestion) are limitless and of great value to network operators.

[0066] Figure 5 illustrates an example of message processing that may be performed by the overload controller 408. With reference to Figure 5, on a given node (intermediate or producer NF), the following configuration may be performed via the overload control configuration interface 410 shown in Figure 4: Create a bucket, say bucket X.

[0067] · Attach a bucket size, say 5K, to the bucket (the bucket size indicates how many messages matching a given rule are guaranteed to be processed).

[0068] Create rules for which guaranteed service support is required. For example: method=post,service=npcf-smpolicycontrol, dnn=“device.abc.com” · Associate the rule with a bucket. · Apply guaranteed service processing as described below and in the parent application. In FIG. 5, buckets 500, 502, and 504 are associated with overflow message processing rules X, Y, and Z, respectively. Each bucket 500, 502, and 504 is configured with a message processing capacity (bucket size) that indicates the number of messages matching the rule that the node or service is guaranteed to pass during an overload condition. In the illustrated example, bucket 500 is configured with a capacity of 5000 messages, bucket 502 is configured with a capacity of 10,000 messages, and bucket 504 is configured with a message processing capacity of 3000 messages. Overflow bucket 506 is used to handle the processing of messages from buckets 500, 502, and 504 when processing the messages would exceed the processing capacity of one of buckets 500, 502, and 504. Messages whose processing is managed by bucket 506 may be processed based on an overload policy. For example, an overload policy may indicate that only high priority messages are passed, and messages whose processing is managed by bucket 506 may be processed or dropped based on the priority of the messages.

[0069] In one of the processing examples illustrated in Figure 5, 8000 incoming messages that match rule X for bucket 500 arrive at a node. Bucket 500 is configured to provide guaranteed processing bandwidth for 5000 of the messages. Thus, 3000 of the messages that match the rules for bucket 500 will be processed using the rules for overflow bucket 506. Similar processing and overflow is performed in buckets 502 and 504, with each bucket providing guaranteed message processing bandwidth for messages up to the message processing volume configured for each bucket. Messages that exceed the configured processing volume for each bucket are processed using the rules defined for overflow bucket 506.

[0070] Example of an overflow message processing rule Based on the type of node to which the solution is applied / enabled, the network operator can use the overload control configuration interface 410 to configure the overload message handling rules used by the overload controller 408. For example, if the overload control scope is an SCP / SEPP (through which almost all 5G inter-NF communication messages pass), the operator may configure matching rules for any producer NF to which the SCP / SEPP is allowed to forward messages. Two examples of rules that may be configured for access by the overload controller 408 are: method=post, service=npcf-smpolicycontrol, dnn=“device.abc.com” method=post, service=nudm-sdm, supirange={AB} The above rules are posted in a rules database accessible by the overload controller 408. In the first rule example, the "method=post" portion of the rule definition defines the type of method the rule is applied to. The "service=nfcp-smpolicycontrol" portion of the rule definition defines the type of service the rule is applied to, which in this case is session management policy control destined for a PCF. The third portion of the rule definition, "dnn=device.abc.com", specifies service independent parameters such that the rule is specific to a particular destination network name, which in this example is device.abc.com. In the second rule example, the service portion of the rule definition identifies the rule as applying to user data management or subscriber data management services. The service independent range portion of the rule defines a SUPI range for the rule definition, which makes the rule applicable to define guaranteed bandwidth service during overload for messages with a particular SUPI range, but not for all messages of the same service type.

[0071] If the overload control scope is a given producer NF, the rule may be limited to the set of services offered by that producer NF, e.g., for a PCF NF instance, a network operator may configure a rule that matches the set of services supported by that PCF NF instance. The following two rule definitions can be used to provide guaranteed bandwidth at the producer NF level for messages that match the rule parameters: method=post, service=npcf-smpolicycontrol, dnn="device.abc.com" method=post, service=npcf-am-policy-control, supi="imsi-1234567890" If the overload control scope is a producer NF service instance, the rule may be limited to only that specific service, e.g. for a PCF policy service. The following rule definition can be used to provide guaranteed bandwidth for messages at the NF service instance level: method=post, service=npcf-am-policy-control, supi="imsi-1234567890" As described in the parent application, guaranteed bandwidth services are provided using buckets, which are data structures used to count the number of messages that match a given rule, with the buckets having a bucket size whose size corresponds to the guaranteed bandwidth represented by each bucket. When configuring a rule, the solution described herein also allows the network operator to specify whether subsequent messages that match the rule shall be automatically processed using the same bucket and corresponding processor as the initial matching message. For example, for the following rule, subsequent messages for GET / PUT / PATCH / DELETE shall be automatically associated with the corresponding bucket and processor (with which the initial message was associated): method=post, service=npcf-smpolicycontrol, dnn="device.abc.com" To also enable support of guaranteed service support for subsequent messages, the overload controller 408 obtains information about the created resource from the initial message. The 5G service architecture mandates that the producer NF specifies the created resource reference in the location header of the response message. The overload controller 408 creates a dynamic rule using the identification of the created resource from the location header of the response message and attaches it to the bucket with which the initial message is associated. For subsequent messages, the dynamic rule ensures that messages related to a common session are processed by the same processor of the intermediate or producer NF. The overload controller 408 can be extended to create a dynamic rule using the identification of the created resource from the response body and attach it to the bucket with which the initial message is associated.

[0072] Such dynamic rules need to be deleted upon consumer NF deletion of the corresponding resources (created by the initial message for which the guaranteed traffic bandwidth is configured) from the intermediate or producer NF. The network operator still has the option to configure static rules for the initial message and subsequent messages. Configuring static rules eliminates the need for the overload controller 408 to manage dynamic rules.

[0073] Tables 1 and 2 below show examples of static and dynamic rules that may be configured in an intermediate or producer NF.

[0074] [Table 1]

[0075] [Table 2]

[0076] In Table 1, each rule is associated with one of buckets 500, 502, and 504. Each rule is also marked as to whether dynamic rule generation is configured for processing subsequent messages. Table 2 shows the dynamic rules that are generated for subsequent messages that match the corresponding static rule in Table 1. For example, the first dynamic rule in Table 2 includes the fully qualified domain name of the producer NF that responded to the initial message that matches the first rule in Table 1.

[0077] Function Processing Flow The following steps may be used to configure and use an intermediate or producer NF to provide rule-based overload control.

[0078] 1. A network operator defines buckets, rules, and creates associations between buckets and rules.

[0079] The operator also configures, for each rule, whether subsequent messages of that rule are automatically processed by the overload controller 408 using the same bucket.

[0080] This information is stored in a persistent database. 2. When a message is received by a node, it checks the message parameters against the configured static and dynamic rules to determine if the message matches the processing rules for any of its buckets.

[0081] Dynamic rules are added in step 4. · Execute the overload control procedures described herein (if available, process the message using the guaranteed bandwidth for the matching rule, or process the message using the rules defined for the overflow bucket).

[0082] 3. If the message is allowed to be processed and a matching rule was found in the previous step, check whether subsequent message processing for that rule needs to be tracked.

[0083] If subsequent message processing needs to be tracked, store a reference to the bucket index along with the HTTP request context and forward the message to the service instance that processes the message and provides the given service.

[0084] 4. The response message travels through the reverse path as the initial message, so the overload controller also sees the response message.

[0085] If the request context indicates that subsequent message processing should be handled (as marked in step 3), create a dynamic rule as follows: URI: URI for the created resource, Bucket: bucketId If the request message is for a DELETE resource, remove the rule from the dynamic table.

[0086] Table 3, shown below, shows examples of guaranteed traffic bandwidth rates for traffic matching different overload message handling rules that may be implemented by an intermediate or producer NF. The rates in Table 3 correspond to the relative bucket capacities assigned to the buckets shown in FIG. 5.

[0087] [Table 3]

[0088] In Table 3, each rule, Rule-X, Rule-Y, and Rule-Z, has a guaranteed bandwidth service rate that is a percentage of the reserved capacity of the intermediate or producer NF. For each rule, a percentage of the reserved capacity of the intermediate or producer NF that will be used exclusively by messages that match the given rule when the intermediate or producer NF is in an overloaded state, even if the messages that match the given rule are of lower priority than messages of other services that are rejected by the intermediate proxy node. For example, if a message for Rule-X is received at the intermediate proxy node with a priority of 10, the message for Rule-X may be processed under the guaranteed bandwidth of Rule-X, and another non-guaranteed message with a higher priority (higher priority means a lower numerical priority value according to 3GPP) may be rejected by the intermediate or producer NF. In Table 3, a message matching rule X is guaranteed 5% of the reserved capacity of the intermediate or producer NF, a message matching rule Y is guaranteed 10% of the reserved capacity of the intermediate or producer NF, and a message matching rule Z is guaranteed 3% of the reserved capacity of the intermediate or producer NF.

[0089] In this model, the network operator configures the following: 1. Overall capacity of intermediate or producer NF. For example, the overall capacity of an intermediate or producer NF is 100K.

[0090] 2. Guaranteed Bandwidth for Each Rule For example, for an overall capacity of 100K intermediate or producer NFs, the guaranteed bandwidth or GTB (based on Table 3) would be: Rule X: 5K Rule-Y:10K Rule Z:3K Therefore, regardless of message priority across multiple service message types (passing through intermediate proxy nodes or processed by producer NFs), messages matching each rule (with configured guaranteed bandwidth services) will have a guaranteed / guaranteed allocated capacity on the intermediate or producer NF.

[0091] Message processing details: The following are functional details that may be realized by intermediate proxy nodes such as SCPs, SEPPs, service meshes, or producer NFs that provide guaranteed traffic bandwidth for messages that match certain overloaded message processing rules.

[0092] 1. Check for an overload condition of the intermediate or producer NF. If the intermediate or producer NF is not overloaded, no further checks are required. The message should be allowed to pass through or be processed by the intermediate or producer NF as part of the unguaranteed bandwidth. This is the case when processing the normal functionality of the intermediate or producer NF (during a non-overload scenario).

[0093] 2. If an intermediate or producer NF is in an overload state, it checks whether the received message matches one of the overload message handling rules.

[0094] If a message matches one of the overload message processing rules and there is still available bandwidth, then forward the message (regardless of message priority) to the service instance for processing. Only messages that do not match one of the overload message processing rules will be throttled based on priority.

[0095] b. If overloaded message processing rules and corresponding buckets are configured and there is no bandwidth available for a given message that matches one of the rules, then do the following: i. If there is a message in the matching bucket with a lower priority (i.e., lower than the priority of the current message), then allow that message out of the guaranteed bandwidth of that bucket. Matching buckets allow for fine-grained logic to allow higher priority messages, among other messages, to match the rule.

[0096] For example, for a message matching a given rule, P5 may be the highest priority message of all messages for that rule, so during an overload, P5 messages for that rule must be allowed (up to the configured bandwidth for messages matching that rule, even though an overload policy may be rejecting P3 messages for messages matching other rules).

[0097] ii. If there are no messages of lower or same priority in the bucket, the message processing procedure is the same as for a service without a rule configured (see details in step c).

[0098] c. If no overload message processing rules are configured, the message will run through the non-guaranteed bandwidth bucket, and thus the message will be accepted / rejected based on the system overload policy (overload policy accepts / rejects messages based on message priority and system overload level).

[0099] i. If the overload policy allows the message to pass, the message will be processed.

[0100] ii. If not, the message will be rejected. With this approach, messages whose parameters match the overload control rules will have guaranteed message processing bandwidth up to the configured amount, even during data storms or other anomalies in the network.

[0101] Some message processing rules can be categorized and identified using the PATH / URI specified by 3GPP in the corresponding network function specification. Other rules, such as those shown above, may require network slice and DNN identification parameters so that the priority can be configured correctly. This approach can also be applied to non-5G messages based on the PATH / URI and other custom attributes in the request header or body. Thus, network operators should be able to configure guaranteed traffic bandwidth for any rule-matching type of traffic passing through the respective node. This approach can also be applied to provide guaranteed traffic bandwidth to a given producer (based on FQDN, network slice identifier, DNN, etc.). This is useful in use cases managing emergency services and other premium customers. For messages without an assigned priority, operators can specify a default message priority. (According to 3GPP TS 29.500, all 5G Core (5GC) messages without a client-defined priority shall have a default priority of 24). Alternatively, network operators can determine the relative message priority based on the network slice and / or DNN identification parameters.

[0102] An intermediate or producer NF that achieves guaranteed bandwidth using overload message handling rules may also achieve the following types of tracking / monitoring to enforce the guaranteed bandwidth:

[0103] For messages with configured overloaded message processing rules, track the rate at which messages of a given priority are processed under each matching rule; Track the overall message rate and compare it to the overall traffic capacity of intermediate or producing NFs; Tracks non-guaranteed bandwidth message rates for individual priority messages.

[0104] Table 4, shown below, illustrates examples of message rates that may be tracked at an intermediate or producer NF to achieve guaranteed traffic bandwidth for messages that match overload message processing rules.

[0105] [Table 4]

[0106] In Table 4, it can be seen that the traffic rate for each of Rule-X, Rule-Y, and Rule-Z is tracked. In addition, the rate of each allowed message priority within a given rule is also tracked. For example, for Rule-X, the message rates of priorities P0 and P5 are tracked. This represents that a 1K traffic rate of P0 and P5 priority messages is allowed through the Rule-X bucket. Note that rules that are not defined as having guaranteed bandwidth will not have a guaranteed bandwidth rate configured.

[0107] In addition to tracking message rates for messages with guaranteed bandwidth service as described above, an intermediate proxy node may also track message rates based on priority for non-guaranteed bandwidth traffic. Table 5 below shows an example non-guaranteed bandwidth traffic that may be tracked by an intermediate or producer NF.

[0108] [Table 5]

[0109] In Table 5, message rates for non-guaranteed bandwidth traffic are tracked for all allowed message priorities.

[0110] Another metric that may be tracked by an intermediate or producer NF node implementing a guaranteed traffic bandwidth service is the aggregate message rate of non-guaranteed and guaranteed bandwidth traffic. Table 6 below shows the aggregate message rate that may be tracked by such an intermediate or producer NF node.

[0111] [Table 6]

[0112] Table 6 shows the sum of all traffic rates in Tables 4 and 5, which is the total rate of traffic currently being processed by an intermediate or producer NF node. Such a rate may be compared to the overall message capacity of the node to determine if the node is overloaded. For example, a network operator may configure the overload trigger state of a node to be 80% of the total capacity. If a node is capable of processing 100k messages / s and an engineered overload threshold is defined at 80k, then a rate of 83k in Table 6 would indicate that the node is overloaded and trigger a guaranteed traffic bandwidth service as described herein.

[0113] For a simplified explanation of guaranteed bandwidth services, the following example in Table 7 assumes that the overload policy rejects messages at 100% node capacity. However, rejection of messages from non-guaranteed bandwidth buckets can be applied using an overload policy with multiple throttle levels and message priority mappings (messages up to a certain priority level will be rejected at a certain system overload level).

[0114] [Table 7-1]

[0115] [Table 7-2]

[0116] [Table 7-3]

[0117] In scenario 1 of Table 7, a message is received from service A which does not have a guaranteed bandwidth service configured. Therefore, the message will be processed according to the policy defined for the non-guaranteed traffic bandwidth bucket. The priority of the message is 4. In this example, assume that there are messages in the non-guaranteed traffic bandwidth bucket with a priority lower than 4 and there is bandwidth available. Therefore, the message will be passed on or processed and the count for non-guaranteed bandwidth traffic for priority P4 will be updated.

[0118] In Scenario 2 of Table 7, another message for Rule A is received. As in Example 1, there is no guaranteed bandwidth service configured for the message, so the message will be passed on or processed according to the policy defined for the non-guaranteed traffic bandwidth bucket. In Scenario 2, the message has a priority of 18. Assume that there are no messages in the non-guaranteed bandwidth bucket with a priority lower than 18. Thus, the message will be passed on or processed if there is bandwidth available for a non-guaranteed traffic bandwidth message of priority 18. If such bandwidth is not available, the message is rejected.

[0119] In scenario 3, a message is received with priority 18 for Rule A. However, assume that the system is running at 100% capacity: there is no guaranteed bandwidth service configured for Rule A, there are no lower priority messages in progress in the non-guaranteed traffic bandwidth bucket, and there is no available system capacity, so the message will be rejected.

[0120] In scenario 4 of Table 7, a priority 20 message is received for rule X. Guaranteed bandwidth service is configured for rule X. It is also assumed that there is an available quota within the guaranteed rate for rule X. Therefore, the message will be passed on or processed and the rate for priority 20 traffic for rule X will be updated.

[0121] In scenario 5 of Table 7, a message of priority 20 for rule X is received. In this example, assume that the system is operating at 100% capacity, but there is available quota within the guaranteed rate for messages of rule X. Thus, the message will be passed on or processed, and the quota will be updated for priority 20 and rule X. Note that when the system is operating at 100% capacity, the system will reject messages in the unguaranteed traffic bandwidth bucket even if the messages in the unguaranteed traffic bandwidth bucket have a higher priority than would be allowed within the reserved quota for a given service.

[0122] In scenario 6 of Table 7, a message of priority 4 is received for rule-Y. It is also assumed that the rule-Y guaranteed capacity is exhausted. However, there is a message with a priority lower than 4 in the guaranteed traffic bandwidth bucket of rule-Y. Therefore, the message will be allowed from the guaranteed traffic bandwidth bucket for rule-Y, and the guaranteed traffic bandwidth traffic rate for priority P4 will be updated for rule-Y. Any lower priority messages matching rule-Y will be processed under the unguaranteed traffic bandwidth. If necessary, they will be rejected.

[0123] In scenario 7 of Table 7, a message having priority 6 is received for rule-Y. It is also assumed that rule-Y guaranteed capacity is exhausted and there are no lower priority messages in the guaranteed traffic bandwidth bucket for rule-Y. Therefore, the message will be processed from the non-guaranteed traffic bandwidth bucket. The message will be processed or rejected based on the policy defined for the non-guaranteed traffic bandwidth bucket.

[0124] In scenario 8, it is assumed that the system is operating at 100% capacity and a message with priority 6 is received for rule-Y. It is also assumed that rule-Y guaranteed capacity is exhausted and there are no lower priority messages in the guaranteed traffic bandwidth bucket for rule-Y. Therefore, the message will be processed from the non-guaranteed traffic bandwidth bucket. The message will be allowed or denied based on its priority and the policy configured for the non-guaranteed traffic bandwidth bucket.

[0125] In scenario 9, assume that a message is running at 100% capacity. A message of priority 18 is received for rule-Y. It is also assumed that rule-Y guaranteed capacity is exhausted and there are no lower priority messages in the guaranteed traffic bandwidth bucket for rule-Y. Therefore, the message will be processed from the non-guaranteed traffic bandwidth bucket. In this example, it is assumed that there are no lower priority messages in the non-guaranteed traffic bandwidth bucket because the system is running at 100% capacity and there is no additional buffer space to process the message, so the message will be rejected.

[0126] 6 is a flowchart illustrating an example process for providing rule-based overload control at an intermediate or producer NF. Referring to FIG. 6, in step 600, the process includes configuring overload message processing rules at the intermediate or producer NF, at least some of which include a parameter that identifies a DNN or network slice, subscription, or location, or any other attribute defined by 3GPP or a vendor, as a rule selection criterion. For example, a network operator or NF vendor may configure overload control rules for an intermediate or producer NF that specify a DNN, S-NSSAI, SUPI, or other parameter as a selection criterion.

[0127] In step 602, the process includes associating a guaranteed bandwidth service at an intermediate or producer NF with at least some of the overload message processing rules. For example, a network operator or NF vendor may configure a reserved portion of the NF's bandwidth for some or all of the overload control rules. When the NF is in an overload state, a message matching one of the rules will be processed using the guaranteed bandwidth reserved for the node.

[0128] In step 604, a message is received at an intermediate or producer NF. For example, the intermediate or producer NF may receive a message related to a 5G transaction, such as a service request for a service, from a network function, such as a PCF.

[0129] In step 606, it is determined that an overload condition exists. The overload condition may be an overload condition of the entire intermediate or proxy NF, or an overload condition affecting one of many services provided by the intermediate or producer NF. For example, the message may be received at an SCP, a SEPP, a service mesh node, or a producer NF, such as a PCF or UDM. An "overload condition" means that utilization of the intermediate or producer NF has exceeded an operator-defined threshold, such as 80% of the available capacity to process messages.

[0130] In step 608, the process includes the intermediate or producer NF identifying that the message includes parameters that match rule selection criteria for one of the overload message processing rules. For example, the intermediate or producer NF may determine that the message includes a DNN, S-NSSAI, or other parameter or combination of parameters that match selection criteria provisioned for one of the overload message processing rules.

[0131] In step 610, the process includes the intermediate or producer NF determining that a portion of the guaranteed bandwidth for the matching rule is available to process the message. For example, if the message includes parameters that match one of the overload message processing rules, step 610 may include reading the message count for that rule and determining that the message count is less than the message count threshold for the guaranteed bandwidth for that particular rule.

[0132] In step 612, the process includes processing the message using the guaranteed bandwidth for the matching rule and updating a message count for that rule. For example, if the node is an intermediate node, e.g., an SCP, or a SEPP or a service mesh, processing the message may include forwarding the message to a producer NF. If the node is a producer NF, processing the message may include processing the message according to a service provided by the NF type. For example, if the producer NF is a PCF, processing the message may include responding to a policy request from a consumer NF. Updating the message count may include updating a count associated with a bucket corresponding to the rule.

[0133] The subject matter described herein allows operators to provide guaranteed bandwidth to messages associated with different DNNs or network slices without having to rely on consumer NFs to correctly set 5G message priority parameters. Guaranteed bandwidth handling can be selectively applied to DNNs or network slices, allowing messages of the same type to be treated differently.

[0134] The disclosure of each of the following references is incorporated herein by reference in its entirety. reference: 3GPP TS 29.500, Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage 3 (Release 16) V16.0.0, (2019-06). 3GPP TS 29.510, Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16) V16.0.0 (2019-06). 3GPP TS 29.512, Technical Specification Group Core Network and Terminals; 5G System, Session Management Policy Control Service, Stage 3, (Release 16) V16.4.0 (2020-03) 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. Further, the foregoing description is for purposes of illustration only, and not for purposes of limitation.

Claims

1. 1. A method for rule-based overload control for 5G services, comprising: configuring overload message handling rules in an intermediate node or a producer Network Function (NF), at least some of the overload message handling rules including a Destination Network Name (DNN) or a network slice, subscription or location identification parameter as a rule selection criterion, the method further comprising: - associating, at said intermediate node or producer NF, a guaranteed processing bandwidth of said intermediate node or producer NF with at least some of said overload message processing rules; Receiving a first message at the intermediate node or producer NF; said intermediate node or producer NF determining that an overload condition exists; said intermediate node or producer NF identifying that said first message includes parameters that meet said rule selection criteria for one of said overload message processing rules; determining by the intermediate node or producer NF that a portion of the guaranteed processing bandwidth of the intermediate node or producer NF for the matching overloaded message processing rule is available for processing the first message; The method includes the intermediate node or producer NF processing the first message using a portion of the guaranteed processing bandwidth of the intermediate node or producer NF for the matching overload message processing rule.

2. 2. The method of claim 1, wherein configuring the overload message handling rules includes configuring rules to treat messages of the same service type differently based on the DNN or network slice, subscription, or location identification parameters.

3. The method of claim 1 , wherein configuring the overloaded message processing rules comprises configuring rules that treat messages of the same service type differently based on a defined parameter or combination of parameters.

4. The method according to any one of claims 1 to 3, wherein associating the guaranteed processing bandwidth of the intermediate node or producer NF with at least some of the overload message processing rules comprises associating at least some of the overload message processing rules with buckets and configuring a message count corresponding to the guaranteed bandwidth for each rule together with the corresponding bucket of each rule.

5. A method according to any one of claims 1 to 4, comprising creating dynamic overload message handling rules using information obtained from response messages, and using said dynamic overload message handling rules to ensure that messages relating to a common session are processed by a common processor of said intermediate node or producer NF.

6. The method according to any one of claims 1 to 5, wherein the intermediate node or producer NF comprises a security edge protection proxy (SEPP), a service communication proxy (SCP), or a service mesh node.

7. The method according to any one of claims 1 to 6, wherein the intermediate node or producer NF comprises a producer NF.

8. The method of any one of claims 1 to 7, comprising configuring, at the intermediate node or producer NF, a non-guaranteed bandwidth bucket that can be used to track the bandwidth of the intermediate node or producer NF available for messages that do not match one of the overload message processing rules for which the guaranteed bandwidth of the intermediate node or producer NF is configured.

9. receiving a second message at the intermediate node or producer NF; determining that the second message does not match one of the overload message processing rules for which the guaranteed bandwidth of the intermediate node or producer NF is configured; determining that unguaranteed bandwidth is available for the second message using the unguaranteed bandwidth bucket; and processing the message using the non-guaranteed bandwidth.

10. A system for rule-based overload control for 5G services, comprising: An intermediate node or producer network function (NF) including at least one processor; an overload control configuration interface for configuring overload message processing rules associated with the intermediate node or producer NF and used by the intermediate node or producer NF to manage processing of messages during an overload condition, at least some of the overload message processing rules including a destination network name (DNN) or a network slice, subscription or location identification parameter as a rule selection criterion, and for associating a guaranteed bandwidth service with at least some of the overload message processing rules; an overload controller realized by the intermediate node or producer NF for receiving a first message, determining that an overload condition exists, identifying that the first message includes parameters that match the rule selection criteria for one of the overload message processing rules, determining that a portion of the guaranteed bandwidth service for the matching overload message processing rule is available to process the first message, and forwarding the first message for further processing by the intermediate node or producer NF.

11. A computer readable program for causing a processor to carry out the method according to any one of claims 1 to 9.

Images