Methods, systems, and computer-readable media for rule-based overload control for 5g services

Abstract

A method for rule-based overload control for 5G services includes configuring overload message handling rules at an intermediate or producer network function (NF), where at least some of the rules include a destination network name (DNN), network subscription, network location, or 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 having at least some of the overload message handling 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 handling rules, determining that a portion of the guaranteed processing bandwidth of the intermediate or producer NF for the matched overload message handling rule is available to process the first message, processing the first message, and updating a message count for the overload message handling rule.

Description

[0001] Priority application

[0002] This application claims priority to U.S. Patent Application Serial No. 16 / 914231, filed June 26, 2020, which is a continuation in part of U.S. Patent Application Serial No. 16 / 601371, filed October 14, 2019, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This article describes the topic of providing overload control in communication networks. More specifically, this article describes the topic of providing rule-based overload control for 5G services. Background Technology

[0004] In 5G telecommunications networks, network nodes that provide services are called producer network functions (NFs). Network nodes that consume services are called consumer NFs. A network function can be either a producer NF or a consumer NF, depending on whether it is consuming or providing services.

[0005] A given producer NF may have many service endpoints, where a service endpoint is a combination of IP address and port number on the network node hosting the producer NF. The producer NF registers with the Network Functions Store (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.

[0006] 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 then load balances traffic among producer NF service instances providing the required services or routes traffic directly to the destination producer NF.

[0007] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include Secure Edge Protection Proxies (SEPPs), serving gateways, and nodes in the 5G serving mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G PLMNs (Public Land Mobile Networks). Therefore, SEPPs perform message filtering, policing, and topology hiding on all API messages.

[0008] A service gateway is a node located in front of a set of producer NFs providing a given service. The service gateway can load balance incoming service requests among producer NFs providing services in a manner similar to SCP.

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

[0010] One problem with the existing 3GPP service architecture is that while message prioritization and congestion handling are defined at the 3GPP NF level, no node between the consumer and producer NFs can register itself as a 5G NF; these include intermediary proxies, service gateways between the same vendor sites, etc. Therefore, the consumer NF can only see the load of the target producer NF. 3GPP has not defined guidelines regarding the behavior of intermediary nodes. Furthermore, 3GPP has not defined overload handling mechanisms at intermediary proxy nodes (such as SCPs, SEPPs, service gateways, or service meshes) to avoid service scarcity for low-priority services. For example, if the SCP is handling traffic between the producer and consumer NFs, and the producer NF is not overloaded, traffic can continue without invoking the congestion control process at the SCP. However, the total traffic from the consumer NF to the producer NF can overwhelm the SCP. If there is no mechanism at the SCP or other intermediary proxy nodes to handle traffic congestion, these nodes may become congested and drop traffic for low-priority services.

[0011] An additional problem that arises at intermediate or producer NFs is that consumer NFs may fail to correctly or consistently set 5G message priority values ​​so that network operators can handle traffic as expected. For example, the 3GPP architecture relies on consumer NFs setting 5G message priority parameters in the message header, and when the same message type is sent to different destination network names (DNNs) or network slices identified by a single network slice selection auxiliary information (S-NSSAI), consumer NFs may experience difficulty setting appropriate priority parameters. Because consumer NFs cannot reliably or uniformly set 5G priority parameters, the 5G message priority parameters set by consumer NFs cannot be used alone as the basis for handling messages under overload conditions, as doing so could lead to denial of service for some services.

[0012] Therefore, there is a need for rule-based overload control methods, systems, and computer-readable media for 5G services. Summary of the Invention

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

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

[0015] According to another aspect of the topic described in this article, configuring overload message handling rules includes configuring rules to perform different processing on messages of the same service type based on predetermined parameters or combinations of parameters.

[0016] 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 handling rules includes associating at least some of the overload message handling rules with a bucket and configuring a message count corresponding to the guaranteed bandwidth for each rule and its corresponding bucket.

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

[0018] 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 response messages and using the dynamic overload message handling rules to ensure that messages related to shared sessions are processed by the shared processor of the intermediate or producer NF.

[0019] According to another aspect of the subject matter described herein, intermediate or producer NFs may include Security Edge Protection Agent (SEPP), Service Communication Agent (SCP), or Service Mesh Node.

[0020] According to another aspect of the subject matter described in this article, the intermediate or producer NF includes the producer NF.

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

[0022] 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 handling rules for which the intermediate or producer NF is configured with guaranteed bandwidth, determining that unguaranteed bandwidth is available for the second message using an unguaranteed bandwidth bucket, and processing the message using the unguaranteed bandwidth.

[0023] A rule-based overload control system for 5G services includes an intermediate or producer network function (NF) comprising at least one processor. The system also includes an overload control configuration interface associated with the intermediate or producer NF for providing overload message handling rules for configuring the intermediate or producer NF to dominate message processing during overload conditions. At least some of the rules include a destination network name (DNN) or network slice, subscription or location identification parameters, or any other parameters as rule selection criteria, and are used to associate guaranteed bandwidth service with at least some of the overload message handling rules. The system also includes an overload controller implemented by the intermediate or producer NF for receiving a first message, determining that an overload condition exists, identifying that the first message includes parameters matching the rule selection criteria for one of the overload message handling rules, determining that a portion of the guaranteed bandwidth used to match the overload message handling rules is available to process the first message, forwarding the first message for further processing by the intermediate or producer NF, and updating the message count used to match the overload message handling rules.

[0024] In another aspect of the subject matter described herein, the overload control configuration interface provides the configuration of rules for different processing of messages of the same service type based on DNN or network slice identification parameters or any other parameters.

[0025] According to another aspect of the topic described herein, the overload control configuration interface provides configuration of rules for different processing of messages of the same service type based on attributes / parameters defined by 3GPP or vendors.

[0026] According to another aspect of the subject matter described herein, the overload control configuration interface provides the ability to associate at least some of the overload message handling rules with a bucket and configure a message count corresponding to the bandwidth guaranteed for each rule and its corresponding bucket.

[0027] According to another aspect of the topic described in this article, the overload controller tracks the bandwidth utilization guaranteed for each rule by keeping a count of the number of messages matching the rule for each bucket.

[0028] According to another aspect of the topic described herein, the overload controller uses information obtained from response messages and creates dynamic overload message handling rules to ensure that messages related to the shared session are processed by the shared processor of the intermediate or producer NF.

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

[0030] 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 handling rules for which the intermediate or producer NF is configured with guaranteed bandwidth, determine that the unguaranteed bandwidth is available to process the second message using an unguaranteed bandwidth bucket, and forward the second message to further process the message using the unguaranteed bandwidth.

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

[0032] The subject matter described herein can be implemented in hardware, software, firmware, or any combination thereof. Thus, as used herein, the terms “function,” “node,” or “module” refer to hardware used to implement the described features, which may also include software and / or firmware components. In one exemplary embodiment, the subject matter described herein can be implemented using a 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 subject matter 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 subject matter described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0033] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

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

[0035] Figure 2 This is a diagram illustrating the functionality of a 5G network connected via intermediate proxy nodes such as a service mesh.

[0036] Figure 3This is a network diagram illustrating potential congestion that may occur at intermediate proxy nodes between 5G network functions.

[0037] Figure 4 This is a block diagram illustrating network functions for overload control based on 5G rules.

[0038] Figure 5 This is a schematic diagram illustrating an exemplary data structure for implementing overload control based on 5G rules; and

[0039] Figure 6 This is a flowchart illustrating an example process for overload control based on 5G rules. Detailed Implementation

[0040] This article describes methods, systems, and computer-readable media for rule-based overload control for 5G services. Figure 1 This 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 selection. Furthermore, SCP 101 can load balance connections between consumer and producer NFs.

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

[0042] exist Figure 1 In this context, any node (excluding SCP 101 and NRF 100) can be either a consumer NF or a producer NF, depending on whether it is requesting or providing services. In the example shown, the nodes include 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. Figure 1The node shown also includes a Session Management Function (SMF) 108, which manages the session between Access and Mobility Management Functions (AMF) 110 and PCF 102. AMF 110 performs mobility management operations similar to those performed by a 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 UE 114.

[0043] 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.

[0044] Radio Access Network (RAN) 120 connects 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. 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. UPF 122 can also support performance measurement functions that can be used by UE 114 to obtain network performance measurements. Figure 1 The diagram also shows a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0045] 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. As mentioned above, SEPP is an example of an intermediate proxy node, which can become overwhelmed if proper congestion control and / or bandwidth reservation procedures are not implemented at the intermediate proxy node.

[0046] Guaranteed bandwidth for message matching overload message handling rules

[0047] In 5G deployment architectures, 3GPP Releases 15 and 16 recommend proxy nodes, such as SCPs or SEPPs, which sit between client / consumer NFs and server / producer NFs. Proxy nodes, such as SCPs, provide transport and routing functions 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 facilitate the performance of common activities across various services, such as monitoring, overload control, traffic management, service discovery, etc. In 5G, each producer NF can publish its load level to the NRF. Consumer NFs can subscribe to such changes and adjust their traffic rates accordingly.

[0048] One issue with the existing 3GPP network architecture is that not all nodes between consumer and producer NFs can register themselves as 5G NFs. These unregisterable nodes include intermediary proxies, service gateways between the same vendor sites, etc. Because intermediary proxies cannot register as 5G NFs with the NRF, consumer nodes may be unaware of the load on intermediary proxies, potentially overwhelming them. Similarly, the NRF provides notifications to service consumers, allowing them to view the load on target producer nodes. However, because intermediary proxies cannot register as service producers, 3GPP has not defined guidelines regarding the behavior of intermediary proxies in responding to or issuing such notifications.

[0049] Even if the operator has planned the capacity of its intermediate proxy nodes, signaling storms from rogue services / NFs can overload intermediate networks / nodes / routes. Therefore, when using service meshes (or intermediate proxies, such as SCPs / SEPPs), policies need to be implemented to ensure guaranteed traffic bandwidth for message delivery of a given NF service. The topics described in this paper include enhancements to service meshes / SCPs / SEPPs / intermediate gateways to guarantee the severability of multiple services during congestion / overload conditions at intermediate proxy nodes. The topics also include enhancements in producer NFs that provide rule-based overload control for producer NFs. Therefore, in the following description, the term "intermediate or producer NF" will be used to refer to intermediate nodes (such as SCPs, SEPPs, or service meshes), or producer NFs where rule-based overload control as described herein is implemented.

[0050] Whether in a shared or private network, intermediate proxy nodes require a way to ensure the maintainability of messages that match the operator's overload message handling rules. Without guaranteed maintainability, message passing between two nodes may exceed the capacity of the service mesh / intermediate proxy node, potentially impacting the functionality of the intermediate proxy node and other services.

[0051] Figure 2 The diagram illustrates how traffic between end nodes overwhelms intermediate NFs, such as service meshes. Figure 2 In this configuration, AMF110 is connected to UDM 104 and another NF 200 via service mesh 202. AMF 200 provides service Svc-X. UDM 104 provides service Svc-Y. NF 200 provides service Svc-Z. Message passing between Svc-X and Svc-Y may exhaust the capacity of intermediate broker node 202 (during data storms or other such scenarios). Therefore, Svc-X->Svc-Z and Svc-Y->Svc-Z services may be adversely affected.

[0052] 5G does not provide guidelines on message prioritization within a given service. According to 3GPP TS29.500, all messages without client-defined priorities should have a default priority of 24. Furthermore, it is extremely difficult for vendors / operators to drive / assign priorities for each service message, making it fair to justify priorities compared to other services in other NFs.

[0053] Meanwhile, to ensure the stability of intermediate proxy nodes during data storms / overloads, operators have implemented a throttling strategy that rejects low-priority messages when system capacity exceeds a certain point.

[0054] The following is an example of a strategy that can be implemented on intermediate proxy nodes when the system capacity exceeds a certain point.

[0055] I. When the system's computing resource utilization exceeds 60%, reject all messages with a priority >= 15.

[0056] II. When the system's computing resource utilization exceeds 80%, reject all messages with a priority >= 7.

[0057] While such strategies may be useful, they fail to consider what happens to services with low-priority messages / traffic during congestion events.

[0058] Another problem that arises when all lower-priority messages are rejected under congestion conditions is that if all messages for a given service are low-priority, then a priority-based threshold might starve that service. For example, in Figure 2In this scenario, if all messages for the Svc-Z service have a default priority and the intermediate broker node becomes overloaded, then all messages for the Svc-Z service will be rejected, thus preventing the service from being provided on the network.

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

[0060] Figure 3 This is a network diagram illustrating an example of multiple producer NFs providing services to multiple consumer NFs. In the example shown, the consumer NFs are AMFs 110a to 110c. The producer NFs are UDM 104 and NF instance 200. The producer and consumer NFs are connected via intermediate proxy node 202. In one example, it can be assumed that 10 AMF instances and 10 UDM instances are running. Each UDM instance may be able to handle 10 kilobits per second of traffic. However, multiple AMF instances running service Svc-X may flood intermediate proxy node 202 due to the delivery of service Svc-Y messages to each instance of UDM 104. Furthermore, intermediate proxy node 202 may need a strategy to ensure that message delivery 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 be no complete denial of service for service Svc-Z, even if service Svc-Z messages have a lower priority than message delivery related to other services.

[0061] In 5G deployments, HTTP connections are on-demand. Therefore, AMF-Instance 1's Svc-X can instantiate multiple connections with intermediate proxy nodes to distribute traffic across these connections. For example, there might be 10 connections between AMF-Instance 1's SVC-X and the SCP / SEPP nodes. Thus, the total traffic initiated by a given Svc-X instance (10K for Svc-Y and 1K for Svc-Z) will be distributed across the 10 connections, meaning each connection handles only 1.1K.

[0062] Therefore, performing ingress control based on the source service or per connection is not a viable option for networks implementing service meshes, because ingress traffic for services involves multiple connections or even on-demand connections.

[0063] Similarly, an intermediate proxy node might have 10 connections to each instance of the UDM, and might be connected to 10 different instances of the UDM. Therefore, performing exit control based on the target node or per connection is not a viable option for service mesh or intermediate NFs.

[0064] In addition to the issues at the intermediate proxy nodes, if the message passing and / or the producer NF are not properly configured to provide guaranteed bandwidth for messages that match the overload message handling rules, then the producer NF and the services implemented by the producer NF can cause the consumer NF to experience a denial of service during an overload event. Generally, during an overload event, in order to ensure node stability and functional processing, there will be a discard policy that discards messages based on a node's local policy. Generally, the discard policy is based on message priority. For example, when the load level is Y, messages with a priority < X are discarded. This concept is based on the fact that the consumer or initiator selects the correct or appropriate message priority when sending a message to the producer or the final application.

[0065] For the 5G architecture, 3GPP TS 29.500 describes the 3gpp-Sbi-Message-Priority header, which carries the 5G service message priority. According to TS 29.500, 0 is the highest priority. However, the setting of the value of the 3gpp-Sbi-Message-Priority parameter is reserved as an implementation detail of the consumer NF.

[0066] The following use cases in the 5G network make it very difficult (if not impossible) to set the discard policy based solely on message priority. For example, when service-based interface (SBI) messages of the same type contain information about different DNNs, network slices, subscription permanent identifiers (SUPI), locations, etc. (and this list is long, with additional models enabled for the vertical application layer, i.e., the service-enabled architecture layer (SEAL) or 5G-enabled vehicle-to-everything (V2X)). Since different DNNs, slices, etc. have different use cases to solve, in order to protect the messages related to a given use case, the consumer NF must use different message priorities to ensure QoS. Therefore, the consumer NF cannot use a flat policy to assign the priority "X" to all similar message types on a given service interface.

[0067] For example, when the SMF sends a SmPolicy create context message to the PCF (see 3GPP TS 29.512), the SmPolicy create context message contains the DNN and S-NSSAI. When the SMF instance handles messages for different DNNs or S-NSSAIs, it is challenging for the SMF to decide the message priority that should be assigned to a given SmPolicy create context. Therefore, enabling such fine-grained policies at the consumer NF to set the correct priority for a given service message is complex.

[0068] Even if operators address the issue by creating such policies, it's unlikely that all consumer NFs will uniformly support the corresponding implementation. Intermediate (e.g., SCP / SEPP) and producer NFs can serve dedicated or shared sets of DNNs, network slices, SUPIs, etc. Therefore, rejecting messages under priority-based overload conditions can lead to service rejection. Even if consumer NFs enable sophisticated policies to set appropriate priorities, priority-based message dropping when intermediate or producer NFs drop messages can still trigger situations that lead to service rejection for a set of DNNs / network slices / SUPIs, etc.

[0069] Denial-of-service attacks can have severe consequences for network operators. For example, when a PCF is overloaded, an operator may not want to shut down 100% of traffic for a given DNN / network slice, etc. Operators cannot expect consumer NFs to be filled with the correct message priorities to avoid denial of service. Therefore, it is necessary to configure custom policies on a given node that provide guaranteed processing of messages that match traffic rules, even during overload conditions. Since the problem is common to all intermediate and producer NF nodes, the solution described in this paper can be applied to all intermediate nodes (e.g., SCP / SEPP) and producer NFs (3GPP defined or non-3GPP defined) to ensure guaranteed service at a given node, even if the node is under overload conditions.

[0070] The topics described in this article include overload controllers that track load levels at intermediate or producer NFs and apply rule-based overload control, where overload message handling rules are used to identify guaranteed bandwidth for messages whose parameters match specific rules. Figure 4 The diagram illustrates an example of an overload NF, which can be an intermediate NF or a producer NF, and includes an overload controller that provides guaranteed bandwidth for messages matching overload handling rules. (Reference) Figure 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, service instance 406 can provide... Figure 1 The 3GPP-defined services shown are Figure 1Any service not shown in the diagram that is not defined by 3GPP. NF 400 also includes an overload controller 408 implemented at the service level and / or the NF or node level for providing guaranteed bandwidth for messages that match overload message handling rules. NF 400 also includes an overload control configuration interface 410, which provides configuration of overload message handling rules used by intermediate or producer NFs to govern message processing during overload conditions. At least some of the rules include a destination network name (DNN) or network slice, subscription, or location identification parameter as a rule selection criterion. Overload control configuration interface 410 can also provide the ability to associate guaranteed bandwidth service with at least some of the overload message handling rules.

[0071] The parent application cited above describes a solution for providing guaranteed traffic service for a given service. This applies to both 5G and non-5G traffic. The solution details of this application can be based not only on the service name, but also on any 5G-defined parameters (such as DNN, network slicing, SUPI range, etc.) to ensure guaranteed service.

[0072] Overload conditions at intermediate or producer NFs can be detected using any suitable mechanism. For example, overload detection algorithms can consider node CPU utilization, node memory utilization, ingress traffic rate, etc. The topics described in this paper include defining policies for selecting which messages(s) should be allowed / denied during overload control. This solution can be applied to 5G NFs (such as PCF, NRF, SCP, SEPP) or non-3GPP defined NFs. This solution enables any operator to define custom policies to provide guaranteed service on a given node, even during overload conditions. This helps operators support maintainability across different customer types, network locations, and other factors. Examples of customer types and other factors that can receive guaranteed bandwidth support during overload conditions include:

[0073] • High-quality customers

[0074] Emergency call,

[0075] • Specific DNN,

[0076] • Specific network slices

[0077] ·etc.

[0078] In summary, the use cases enabled by the topics described in this article for handling various traffic patterns (even during node overload / congestion) are limitless and of high value to network operators.

[0079] Figure 5 The illustration shows an example of message handling that can be performed by the overload controller 408. (Reference) Figure 5At a given node (intermediate or producer NF), it is possible to achieve this via... Figure 4 The overload control configuration interface 410 shown performs the following configuration:

[0080] • Create a bucket, for example, bucket X.

[0081] • Attach the bucket size to the bucket, for example, 5K (the bucket size indicates the number of messages that match the given rules and are guaranteed to be processed).

[0082] • Create one or more rules that require guaranteed service support, for example:

[0083] ·method=post,service=npcf-smpolicycontrol,dnn="device.abc.com"

[0084] Associate rules with buckets.

[0085] • Apply the guaranteed service handling as described below and in the parent application.

[0086] exist Figure 5 In this example, buckets 500, 502, and 504 are associated with overflow message handling rules X, Y, and Z, respectively. Each bucket 500, 502, and 504 is configured with a message processing capacity (bucket size) indicating the number of messages that match the rules that guarantee the passage of a node or service during overload conditions. In the example shown, bucket 500 is configured with a capacity of 5,000 messages, bucket 502 with a capacity of 10,000 messages, and bucket 504 with a message processing capacity of 3,000 messages. When processing messages from buckets 500, 502, and 504 would exceed the processing capacity of one of the buckets 500, 502, and 504, overflow bucket 506 is used to handle these messages. Messages dominated by bucket 505 can be processed based on an overload policy. For example, an overload policy might instruct that only high-priority messages be delivered, and the processing of messages dominated by bucket 506 could be based on message priority or discarded.

[0087] exist Figure 5In one of the processing examples shown, 8000 ingress messages matching rule X of bucket 500 arrive at the node. Bucket 500 is configured to provide guaranteed processing bandwidth for 5000 of its messages. Therefore, the 3000 messages matching the rules for bucket 500 will be processed using the rules for overflow bucket 506. Similar processing and overflows are performed in buckets 502 and 504, where each bucket provides guaranteed message processing bandwidth up to the maximum message processing capacity configured for each bucket. Messages exceeding the processing capacity configured for each bucket are processed using the rules defined for overflow bucket 506.

[0088] Example Overflow Message Handling Rules

[0089] Based on the type of node for which this solution is applied / enabled, network operators can configure overload message handling rules used by overload controller 408 using overload control configuration interface 410. For example, when the overload control scope is SCP / SEPP (where almost all 5G inter-NF communication messages pass through), the operator can configure matching rules for any producer NF that allows SCP / SEPP to forward messages. Two examples of rules that can be configured for access by overload controller 408 are as follows:

[0090] method=post,service=npcf-smpolicycontrol,dnn="device.abc.com"

[0091] method=post,service=nudm-sdm, supirange={AB}

[0092] The rules mentioned above are published to a rule database accessible to the overload controller 408. In the first rule example, the "method=post" section of the rule definition defines the type of method by which the rule is applied. The "service=nfcp-smpolicycontrol" section of the rule definition defines the type of service to which the rule is applied; in this case, the type is session management policy control for PCF. The third part of the rule definition, "dnn=device.abc.com," specifies a service-independent parameter so 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 section of the rule definition identifies the rule as an application to a user data management or subscriber data management service. The service-independent scope section of the rule defines a SUPI scope for the rule definition, which makes the rule applicable during overload to define a guaranteed bandwidth service for all messages with a specific SUPI scope but not the same service type.

[0093] When the overload control scope is a given producer NF, rules can be restricted to the set of services provided by that producer NF. For example, for a PCF NF instance, a network operator can configure rules that match 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:

[0094] method=post,service=npcf-smpolicycontrol,dnn="device.abc.com"

[0095] method=post,service=npcf-am-policy-control,supi="imsi-1234567890"

[0096] When overload control is applied to the producer NF service instance, rules can be limited to that specific service, such as the PCF Smpolicy service. The following rule definitions can be used to provide guaranteed bandwidth for messages at the NF service instance level:

[0097] method=post,service=npcf-am-policy-control,supi="imsi-1234567890"

[0098] As described in the parent application, buckets are used to provide guaranteed bandwidth service. A bucket is a data structure used to count the number of messages that match a given rule, and its size is designed to correspond to the guaranteed bandwidth represented by each bucket. When configuring rules, the solution described herein also allows network operators to specify whether the same bucket and corresponding processor should be used to automatically process subsequent messages matching a rule as the initial matching message. For example, for the following rule, subsequent messages for GET / PUT / PATCH / DELETE should be automatically associated with the corresponding bucket and processor (to which the initial message is associated): method=post,service=npcf-smpolicycontrol,dnn="device.abc.com"

[0099] To also enable guaranteed service support for subsequent messages, the overload controller 408 obtains information about the resources created from the initial message. The 5G service architecture requires the producer NF to specify a reference to the created resource in the location header of the response message. The overload controller 408 uses the identifier of the resource created from the location header of the response message to create dynamic rules and appends them to the bucket associated with the initial message. For subsequent messages, the dynamic rules ensure that messages related to the shared session are processed by the same processor of the intermediate or producer NF. The overload controller 408 can be extended to use the identifier of the resource created from the response body to create dynamic rules and append them to the bucket associated with the initial message.

[0100] When a consumer NF removes a corresponding resource from an intermediate or producer NF (created by an initial message configured with guaranteed bandwidth), such dynamic rules need to be deleted. Network operators still have the option to configure static rules for initial and subsequent messages. Configuring static rules eliminates the need for the overload controller 408 to manage dynamic rules.

[0101] Tables 1 and 2 below illustrate examples of static and dynamic rules that can be configured in intermediate or producer NFs.

[0102]

[0103]

[0104] Table 1: Static rules for guaranteed bandwidth configuration

[0105]

[0106] Table 2: Dynamic Rules Configured for Messages Matching Static Rules. 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 for processing subsequent messages is configured. Table 2 illustrates the dynamic rules generated for subsequent messages that match the corresponding static rules in Table 1. For example, the first dynamic rule in Table 2 contains the fully qualified domain name of the producer NF that responds to the initial message that matches the first rule in Table 1.

[0107] Functional processing flow

[0108] The following steps can be used to configure and use intermediate or producer NFs to provide rule-based overload control.

[0109] 1. Network operators define (one or more) buckets, (one or more) rules, and create associations between buckets and rules.

[0110] • The operator also configures for each rule whether subsequent messages for that rule will be automatically processed by the overload controller 408 using the same storage bucket.

[0111] This information is stored in a permanent database.

[0112] 2. When a node receives a message, it checks the message parameters against the configured static and dynamic rules and determines whether the message matches the processing rules of any bucket.

[0113] • Dynamic rules will be added in step 4.

[0114] • Run the overload control process as described in this document (if available, process messages using the bandwidth guaranteed for the matching rules, or using the rules defined for the overflow bucket).

[0115] 3. If message processing is permitted and a matching rule was found in the previous step, then check whether it is necessary to track subsequent message processing for that rule.

[0116] If it is necessary to track subsequent message processing, then store a reference to the bucket index and the HTTP request context, and forward the message to the service instance that processes the message to provide the given service.

[0117] 4. Since the response message travels through the reverse path as the initial message, the overload controller will also see the response message.

[0118] • If the context of the request indicates that subsequent message processing is required (as marked in step 3), then create the following dynamic rule:

[0119] • URI: The URI used for the created resource; Bucket: bucketId

[0120] • If the request message is for a DELETE resource, then remove the rule from the dynamic table.

[0121] Table 3 below illustrates examples of guaranteed traffic bandwidth rates for matching different overload message handling rules, which can be implemented by intermediate or producer NFs. The rates in Table 3 are related to the traffic assigned to... Figure 5 The corresponding storage bucket capacity is shown in the diagram.

[0122]

[0123] Table 3: Guaranteed bandwidth rates for different rules

[0124] In Table 3, each of Rules-X, Rule-Y, and Rule-Z has a guaranteed bandwidth service rate, which is a percentage of the reserved capacity of the intermediate or producer NF. For each rule, when the intermediate or producer NF is overloaded, even if a message matching a given rule has a lower priority than other service messages rejected by the intermediate broker node, the message matching the given rule will exclusively use a percentage of the reserved capacity of the intermediate or producer NF. For example, if a message with a priority of 10 for Rule-X is received at the intermediate broker node, then the message for Rule-X can be processed under the guaranteed bandwidth of Rule-X, while another higher-priority, unguaranteed message (according to 3GPP, higher priority means a lower numerical priority value) can be rejected by the intermediate or producer NF. In Table 3, 5% of the reserved capacity of the intermediate or producer NF is guaranteed for messages matching Rule X, 10% for messages matching Rule Y, and 3% for messages matching Rule Z.

[0125] In this model, network operators configure the following:

[0126] 1. The total capacity of intermediate or producer NF.

[0127] For example, the total capacity of the intermediate or producer NF is 100K.

[0128] 2. Guaranteed bandwidth for each rule

[0129] For example, if the total capacity of the intermediate or producer NF is 100K, then the guaranteed bandwidth or GTB (based on Table 3) will be as follows:

[0130] Rule-X: 5K

[0131] Rule-Y: 10K

[0132] Rule-Z: 3K

[0133] Therefore, regardless of the message priority among multiple service message types (through intermediate broker nodes or by the producer NF), the message that matches each rule (with the configured guaranteed bandwidth service) will ensure / guarantee the capacity allocated on the intermediate or producer NF.

[0134] Message processing details:

[0135] The following are the functional details that can be achieved by intermediate proxy nodes (such as SCP, SEPP, service mesh, or producer NF), which provide guaranteed communication bandwidth for messages that match specific overload message handling rules.

[0136] 1. Check the overload status of the intermediate or producer NF. If the intermediate or producer NF is not overloaded, no further checks are needed. As part of the unguaranteed bandwidth, messages should be allowed to pass through or be processed by the intermediate or producer NF. This is the normal functioning of the intermediate or producer NF (in non-overload scenarios). 2. If the intermediate or producer NF is overloaded, check if the received messages match one of the overload message handling rules.

[0137] a. If a message matches one of the overload message handling rules and there is still available bandwidth, then the message is forwarded to a service instance for processing (regardless of message priority).

[0138] Only messages that do not match one of the overload message handling rules will be throttled based on priority.

[0139] b. If an overload message handling rule and corresponding bucket are configured, and no bandwidth is available for a given message that matches one of the rules, then do the following:

[0140] i. If a lower-priority message (i.e., lower than the current message's priority) exists in the matching bucket, then that message is allowed to come from the guaranteed bandwidth used for the bucket. The matching bucket provides fine-grained logic to allow higher-priority messages among other messages to match the rules.

[0141] For example, for a message matching a given rule, P5 might be the highest priority message among all messages used for that rule. Therefore, during overload, P5 messages used for a rule must be allowed (up to the configured bandwidth for messages matching the rule, even if the overload policy might reject P3 messages that match other rules).

[0142] ii. If there are no messages of lower or equal priority in the bucket, then the message processing procedure is the same as for services without configured rules. (See step c for details)

[0143] c. If no overload message handling rules are configured, messages will be processed through an unguaranteed bandwidth bucket. Therefore, messages will be allowed / rejected based on the system's overload policy (the overload policy accepts / rejects messages based on message priority and system overload level).

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

[0145] ii. Otherwise, the message will be rejected.

[0146] In this way, messages whose parameters match the overload control rules will guarantee that the message processing bandwidth reaches the configured amount. This also applies even in the event of a data storm or other network anomalies.

[0147] Some message processing rules can be categorized and identified using the PATH / URI specified by 3GPP in the corresponding network function specification. As indicated above, other rules can require proper configuration of network slice and DNN identification parameters to determine priority. 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. Therefore, network operators should be able to configure guaranteed traffic bandwidth for any rule-matching type of traffic passing through the appropriate node. This approach can also be applied to providing guaranteed traffic bandwidth (based on FQDN, network slice identifier, DNN, etc.) for a given producer. This helps manage emergency services and other premium customer use cases. For messages without assigned priorities, operators can specify a default message priority. (According to 3GPP TS 29.500, all 5G core (5GC) messages that do not have a priority defined by the client should have a default priority of 24). Alternatively, network operators can determine relative message priorities based on network slice and / or DNN identification parameters.

[0148] Using overload message handling rules to implement guaranteed bandwidth in intermediate or producer NFs can also enable the following types of tracing / monitoring to enforce guaranteed bandwidth:

[0149] For messages configured with overload message handling rules, track the message rate processed for a given priority under each matching rule;

[0150] Track the overall message rate and compare it with the overall traffic capacity of the intermediate or producer NF; and

[0151] Track the unguaranteed bandwidth message rate used for individual priority messages.

[0152] Table 4 below illustrates examples of message rates that can be tracked at the intermediate or producer NF, which provides guaranteed bandwidth for messages that match overload message handling rules.

[0153]

[0154] Table 4: Message Rate Tracked by Intermediate or Producer NF

[0155] Table 4 shows that traffic is tracked for each of Rules-X, Rule-Y, and Rule-Z. Additionally, the rate for each allowed message priority within a given rule is also tracked. For example, for Rule-X, the message rates for priorities P0 and P5 are tracked. This represents 1K of traffic allowed through the Rule-X bucket for priority messages P0 and P5. It should be noted that rules not defined as having guaranteed bandwidth will not have the configured guaranteed bandwidth rate.

[0156] As mentioned above, in addition to tracking the message rate of messages with guaranteed bandwidth service, intermediate proxy nodes can also track message rates based on the priority given to unguaranteed bandwidth traffic. Table 5 below illustrates the unguaranteed bandwidth traffic that can be tracked by the intermediate or producer NF.

[0157]

[0158] Table 5: Tracked message rates based on priority for unguaranteed bandwidth traffic. Table 5 shows the message rates for unguaranteed bandwidth traffic tracked for each allowed message priority.

[0159] Another metric that intermediate or producer NF nodes that provide guaranteed bandwidth service can track is the total message rate of both unguaranteed and guaranteed bandwidth traffic. Table 6 below illustrates the total message rate that can be tracked by such intermediate or producer NF nodes.

[0160]

[0161] Table 6: Total Traffic Rates for Unguaranteed and Guaranteed Bandwidth

[0162] Table 6 illustrates the sum of all traffic rates in Tables 4 and 5, representing the total rate of traffic currently processed by intermediate or producer NF nodes. This rate can be compared to the node's overall message capacity to determine if the node is overloaded. For example, a network operator might configure a node's overload trigger state to 80% of its total capacity. If a node is capable of handling 100k messages per second and the engineered overload threshold is defined as 80k, then a rate of 83k in Table 6 would indicate that the node is overloaded and trigger guaranteed bandwidth service as described herein.

[0163] For a simplified explanation of guaranteed bandwidth service, the examples in Table 7 assume that the overload policy rejects messages at 100% node capacity. However, an overload policy with multiple limit levels and message priority mappings can be used to apply the rejection of messages from unguaranteed bandwidth buckets (where messages at a certain system overload level that are up to a certain priority level will be rejected).

[0164]

[0165]

[0166]

[0167]

[0168] Table 7: Scenarios and Message Handling under Overload Conditions

[0169] In Scenario 1 in Table 7, a message is received from Service A, for which no guaranteed bandwidth service is configured. Therefore, the message will be processed according to the policy defined for the unguaranteed bandwidth bucket. The message has a priority of 4. In this example, it is assumed that there are messages with a priority lower than 4 in the unguaranteed bandwidth bucket, and there is available bandwidth. Therefore, the message will be delivered or processed, and the count of unguaranteed bandwidth traffic with priority P4 will be updated.

[0170] In Scenario 2 of Table 7, another message is received for Rule-A. Similar to Example 1, no guaranteed bandwidth service is configured for the message; therefore, the message will be delivered or processed according to the policy defined for the unguaranteed bandwidth bucket. In Scenario 2, the message has a priority of 18. It is assumed that there are no messages with a priority lower than 18 in the unguaranteed bandwidth bucket. Therefore, if bandwidth is available for an unguaranteed bandwidth message with a priority of 18, the message will be delivered or processed. If no such bandwidth is available, the message will be rejected.

[0171] In scenario 3, a message with priority 18 for Rule-A is received. However, assuming the system is operating at 100% capacity, since no guaranteed bandwidth service is configured for Rule-A, no lower-priority messages are being processed in the unguaranteed bandwidth bucket, and there is no available system capacity, the message will be rejected.

[0172] In Scenario 4 of Table 7, for Rule-X, messages with priority 20 are received. 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, messages will be delivered or processed, and the rate for priority 20 traffic for Rule-X will be updated.

[0173] In Scenario 5 of Table 7, for Rule-X, messages with a priority of 20 are received. In this example, it is assumed that the system is operating at 100% capacity, but there is available quota within the guaranteed rate for messages used for Rule-X. Accordingly, the message will be delivered or processed, and the quota for priority 20 and Rule-X will be updated. It should be noted that when the system is operating at 100% capacity, the system will reject messages in the unguaranteed traffic bandwidth bucket, even if the message's priority is higher than the messages allowed within the reserved quota for a given service.

[0174] In Scenario 6 of Table 7, for Rule-Y, messages with priority 4 are received. It is also assumed that the guaranteed capacity of Rule-Y is exhausted. However, there are messages with priority lower than 4 in the guaranteed bandwidth bucket of Rule-Y. Therefore, messages from the guaranteed bandwidth bucket will be allowed for Rule-Y, and the guaranteed bandwidth rate for priority P4 will be updated for Rule-Y. Any lower priority messages matching Rule-Y will be processed under unguaranteed bandwidth. These messages will be rejected if necessary.

[0175] In Scenario 7 of Table 7, for Rule-Y, messages with a priority of 6 are received. It is also assumed that the guaranteed capacity for Rule-Y is exhausted and there are no lower-priority messages in the guaranteed bandwidth bucket used for Rule-Y. Therefore, messages will be processed from the unguaranteed bandwidth bucket. Based on the policy defined for the unguaranteed bandwidth bucket, the message is either processed or rejected.

[0176] In Scenario 8, assume the system is operating at 100% capacity and receiving messages with priority 6 for Rule-Y. It is also assumed that the guaranteed capacity for Rule-Y is exhausted, and there are no lower-priority messages in the guaranteed bandwidth bucket for Rule-Y. Therefore, messages will be processed from the unguaranteed bandwidth bucket. Messages are either allowed or denied based on their priority and the policy configured for the unguaranteed bandwidth bucket.

[0177] In Scenario 9, assume the message processing is at 100% capacity. For Rule-Y, a message with priority 18 is received. It is also assumed that the guaranteed capacity for Rule-Y is exhausted, and there are no lower-priority messages in the guaranteed bandwidth bucket for Rule-Y. Therefore, the message will be processed from the unguaranteed bandwidth bucket. In this example, assuming there are no lower-priority messages in the unguaranteed bandwidth bucket, the message will be rejected because the system is running at 100% capacity and there is no more buffer space to process messages.

[0178] Figure 6 This is a flowchart illustrating an exemplary process for providing rule-based overload control at the intermediate or producer NF level. (Reference) Figure 6 In step 600, the process includes configuring overload message handling rules at the intermediate or producer NF, wherein at least some of the rules include DNN or network slice, subscription or location, or any other attribute or identification parameter defined by 3GPP or the vendor, as rule selection criteria. For example, the network operator or NF vendor can configure overload control rules for the intermediate or producer NF, which specify DNN, S-NSSAI, SUPI, or other parameters as selection criteria.

[0179] In step 602, the process includes associating guaranteed bandwidth service at the intermediate or producer NF with at least some of the overload message handling rules. For example, a network operator or NF vendor can configure a reserved portion of the NF bandwidth for some or all of the overload control rules. When an NF is overloaded, messages matching one of the rules will be processed using the guaranteed bandwidth reserved for that node.

[0180] In step 604, a message is received at the intermediate or producer NF. For example, the intermediate or producer NF may receive messages related to 5G transactions, such as service requests from network functions (such as CF).

[0181] In step 606, an overload condition is determined to exist. An overload condition can be an overload condition affecting the entire intermediate or proxy NF, or it can be an overload condition affecting one of many services provided by the intermediate or producer NF. For example, messages can be received at the SCP, SEPP, service mesh node, or producer NF (such as PCF or UDM). An “overload state” means that the utilization of the intermediate or producer NF has exceeded a threshold defined by the operator, such as 80% of the available capacity for processing messages.

[0182] In step 608, the process includes the intermediate or producer NF identifying whether the message includes parameters that match the rule selection criteria used for one of the overload message handling rules. For example, the intermediate or producer NF may determine that the message includes DNN, S-NSSAI, or other parameters or combinations of parameters that match the selection criteria provided for one of the overload message handling rules.

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

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

[0185] The topics described in this article allow operators to provide guaranteed bandwidth to messages associated with different DNNs or network slices without relying on consumer NFs to correctly set 5G message priority parameters. Guaranteed bandwidth processing can be selectively applied to DNNs or network slices, allowing for different processing of the same type of message.

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

[0187] References:

[0188] 3GPP TS 29.500, Technical Specification Group Core Network and Terminals; 5G System; Technical Realization of Service Based Architecture; Stage3 (Release 16) V16.0.0, (2019-06).

[0189] 3GPP TS 29.510, Technical Specification Group Core Network and Terminals; 5G System; NetworkFunction Repository Services; Stage 3 (Release 16) V16.0.0 (2019-06).

[0190] 3GPP TS 29.512, Technical Specification Group Core Network and Terminals; 5G System, Session Management Policy Control Service, Stage 3 (Release16) V16.4.0 (2020-03)

[0191] It will be understood that various details of the subject matter disclosed herein may be changed without departing from the scope of this disclosure. Furthermore, the above description is for illustrative purposes only and not for limiting purposes.

Claims

1. A rule-based overload control method for 5G services, the method comprising: Configure overload message handling rules at the intermediate or producer network function (NF), at least some of which include destination network name (DNN) or network slice, subscription or location identification parameters as rule selection criteria; Associate the guaranteed processing bandwidth of the intermediate or producer NF with at least some of the overload message handling rules at the intermediate or producer NF. Receive the first message at the intermediate or producer NF; The existence of overload conditions is determined by the intermediate or producer NF. The intermediate or producer NF identifies whether the first message includes parameters that match one of the rule selection criteria used for overload message handling. A portion of the guaranteed processing bandwidth of the intermediate or producer NF, which is used to match the overload message handling rules, is determined by the intermediate or producer NF and can be used to process the first message. as well as The first message is processed by the intermediate or producer NF using a portion of the guaranteed processing bandwidth of the intermediate or producer NF used to match the overload message handling rule, and the message count used for that overload message handling rule is updated.

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

3. The method of claim 1, wherein configuring overload message handling rules includes configuring rules for different processing of messages of the same service type based on defined parameters or combinations of parameters.

4. The method as described in any of the preceding claims, wherein associating the guaranteed processing bandwidth of the intermediate or producer NF with at least some of the overload message handling rules includes associating at least some of the overload message handling rules with a bucket and configuring a message count corresponding to the guaranteed bandwidth for each rule and its corresponding bucket.

5. The method of claim 4, further comprising tracking the bandwidth utilization guaranteed for each rule by maintaining a count of the number of messages matching the rule for each bucket.

6. The method as described in any of the preceding claims, comprising creating dynamic overload message handling rules using information obtained from response messages and using the dynamic overload message handling rules to ensure that messages related to a shared session are processed by the shared processor of the intermediate or producer NF.

7. The method as described in any of the preceding claims, wherein the intermediate or producer NF includes a Security Edge Protection Proxy (SEPP), a Service Communication Proxy (SCP), or a Service Mesh Node.

8. The method as described in any of the preceding claims, wherein the intermediate or producer NF includes the producer NF.

9. The method as claimed in any of the preceding claims, comprising configuring an unguaranteed bandwidth bucket at an intermediate or producer NF that is useful for tracking the bandwidth of the intermediate or producer NF, the bandwidth bucket being usable for messages that do not match one of the overload message handling rules for which the guaranteed bandwidth of the intermediate or producer NF is configured.

10. The method of claim 9, comprising: Receive the second message at the intermediate or producer NF; The second message is determined to be inconsistent with one of the overload message handling rules configured for the intermediate or producer NF with guaranteed bandwidth. Use an unguaranteed bandwidth bucket to determine if the unguaranteed bandwidth is available for the second message; and The message is processed using unguaranteed bandwidth.

11. A rule-based overload control system for 5G services, the system comprising: Intermediate or producer network function (NF), which includes at least one processor; An overload control configuration interface, associated with an intermediate or producer NF, is used to provide overload message handling rules for configuring the intermediate or producer NF to dominate message processing during overload conditions, wherein at least some of the rules include a destination network name (DNN) or network slice, subscription or location identification parameters as rule selection criteria, and are used to associate guaranteed bandwidth service with at least some of the overload message handling rules. as well as An overload controller, implemented by an intermediate or producer NF, is used to receive a first message, determine that an overload condition exists, identify that the first message includes parameters that match one of the rule selection criteria used for overload message handling rules, determine that a portion of the guaranteed bandwidth used to match the overload message handling rules can be used to process the first message, forward the first message for further processing by the intermediate or producer NF, and update the message count used to match the overload message handling rules.

12. The system of claim 11, wherein the overload control configuration interface provides configuration of rules for different processing of messages of the same service type based on DNN or network slice identification parameters.

13. The system of claim 11, wherein the overload control configuration interface provides configuration of rules for different processing of messages of the same service type based on defined parameters or combinations of parameters.

14. The system of any one of claims 11 to 13, wherein the overload control configuration interface provides for associating at least some of the overload message handling rules with buckets and configuring message counts and their respective buckets corresponding to the bandwidth guaranteed for each rule.

15. The system of claim 14, wherein the overload controller tracks the bandwidth utilization guaranteed for each rule by maintaining a count of the number of messages matching the rule for each bucket.

16. The system of any one of claims 11 to 15, wherein the overload controller uses information obtained from the response message and creates dynamic overload message handling rules using dynamic overload message handling rules to ensure that messages related to the shared session are processed by the shared processor of the intermediate or producer NF.

17. The system of any one of claims 11 to 16, wherein the intermediate or producer NF includes a Service Communication Agent (SCP), a Security Edge Protection Agent (SEPP), or a producer NF.

18. The system of any one of claims 11 to 17, wherein the overload control configuration interface provides a configuration for an unguaranteed bandwidth bucket capable of tracking the bandwidth of an intermediate or producer NF, the unguaranteed bandwidth bucket being capable of handling messages that do not match one of the overload message handling rules configured for the guaranteed bandwidth of the intermediate or producer NF.

19. The system of claim 18, wherein the overload controller is configured to receive a second message, determine that the second message does not match one of the overload message handling rules for which a guaranteed bandwidth is configured for an intermediate or producer NF, determine, using an unguaranteed bandwidth bucket, that the unguaranteed bandwidth can be used to process the second message, and forward the second message to further process the message using the unguaranteed bandwidth.

20. A non-transitory computer-readable medium storing executable instructions thereon, the instructions controlling the computer to perform steps when executed by a computer's processor, including: Configure overload message handling rules at the intermediate or producer network function (NF), wherein at least some of the rules include destination network name (DNN) or network slice, subscription or location identification parameters as rule selection criteria; Associate the guaranteed processing bandwidth of the intermediate or producer NF with at least some of the overload message handling rules at the intermediate or producer NF. Receive the first message at the intermediate or producer NF; The existence of overload conditions is determined by the intermediate or producer NF. The first message identified by the intermediate or producer NF includes parameters that match the rule selection criteria used for overload message handling. A portion of the guaranteed processing bandwidth of the intermediate or provider NF, which is determined by the intermediate or producer NF to be used to process the first message, is available for processing. as well as The first message is processed by the intermediate or producer NF using a portion of the guaranteed processing bandwidth of the intermediate or producer NF used to match the overload message handling rules, and the message count used for the overload message handling rules is updated.

Images