Intelligent signaling message guiding method in 5G core

Abstract

A method, a non-transitory computer-readable medium, a network traffic management apparatus, and a network traffic management system for providing intelligent signaling message steering in a 5G core are shown. By this technique, a network request is received and a feature set is identified. Based on the identified feature set and the fault probability table, a faulty producer network function of the plurality of producer network functions may be identified. A subset of the plurality of network functions that do not include the failed network function may be defined, and the network request may be routed to one of the subset of the plurality of network functions. Thus, based on the characteristics of the network requests, the network requests may be routed away from network functions having a relatively high probability of causing a failure to handle the network requests.

Description

Technical Field

[0001] The technology relates to methods and systems for intelligently routing network requests within a 5G core network. Background Art

[0002] The fifth generation of mobile communication technology (5G) is a global wireless standard representing the fifth generation of cellular network technology. Compared with the fourth generation of mobile communication technology (4G), 5G introduces the use of high-band (i.e., millimeter wave) frequencies. Although the range of high-band frequencies is more limited than that of low-band and mid-band frequencies, they can provide faster data transmission speeds, thereby enabling new service levels and new technology applications. Another advantage of 5G is that it provides network function virtualization (NFV), which decouples network functions from proprietary hardware, allowing network functions to run as software on standardized hardware, thereby making the network more flexible by minimizing the dependence on specific hardware.

[0003] Like previous generations of mobile networks, the 5G core network provides service access to devices while providing service providers with the functionality required to authenticate, authorize and manage their customers. However, the architecture of the 5G core network provides an advantage in scalability over previous generations. Software is defined and built using a service-based architecture (SBA), which allows for a decentralized, cloud-native and distributed 5G core. One of the many advantages of the 5G core is that the location of the network function (NF) can be optimally placed to ensure the highest efficiency, highest performance and lowest latency.

[0004] Traditionally, mobile networks deploy multiple NFs and support load balancing for high availability. Such configurations support dynamic parameters (such as load and service availability), as well as static parameters (such as location). Ideally, all these NFs are similar and operate identically (e.g., each Mobility Management Function (AMF) operates all these NFs), but in practice, NFs are often different from each other due to various factors, such as configuration mismatches / errors, specific network connectivity issues, different images / versions (e.g., one AMF has received a software update, and another AMF has not yet received the update), and specific openness to software / hardware defects. Traditionally, incoming network requests are load balanced based on common parameters such as load, capacity, location, etc. However, due to the reality that all NFs are not exactly the same in practice, this traditional load balancing approach will not produce effective traffic routing or maximize the success rate of services provided by various NFs.

[0005] It is therefore desirable to create systems for more efficient selection of destination NFs in 5G core networks that can account for operational differences in similar NF types and even account for the fact that such differences may be dynamic and evolving. Summary of the invention

[0006] A method implemented by a network traffic management system includes receiving a network request. Identifying a feature set based on the network request. Identifying a faulty producer network function (NF) from a plurality of producer network functions based on the feature set and a fault probability table. A subset of the plurality of producer NFs is defined as not including a faulty producer NF in the producer NFs. The network request is routed to one of the subset of the plurality of producer NFs.

[0007] A network traffic management device includes a memory and one or more processors, the memory including programming instructions stored thereon, the processors being configured to be able to execute the stored programming instructions to receive a network request. A feature set is identified based on the network request. A faulty producer network function (NF) is identified from a plurality of producers based on the feature set and a failure probability table. A subset of the plurality of producer NFs is defined as not including a faulty producer NF in the producer NFs. The network request is routed to one of the subset of the plurality of producer NFs.

[0008] A non-transitory computer readable medium having instructions including executable code stored thereon, which when executed by one or more processors, causes the processor to receive a network request. A feature set is identified based on the network request. A faulty producer network function (NF) is identified from a plurality of producer network functions based on the feature set and a fault probability table. A subset of the plurality of producer NFs is defined as not including a faulty producer NF in the producer NFs. The network request is routed to one of the subset of the plurality of producer NFs.

[0009] A network traffic management system having a memory and one or more processors, the memory including programming instructions stored thereon, and the processors being configured to be capable of executing the stored programming instructions to receive a network request. A feature set is identified based on the network request. A faulty producer network function (NF) is identified from a plurality of producer network functions based on the feature set and a failure probability table. A subset of the plurality of producer NFs is defined as not including a faulty producer NF in the producer NFs. The network request is routed to one of the subset of the plurality of producer NFs.

[0010] The technology provides many advantages including providing methods, non-transitory computer-readable media, network traffic management devices, and network traffic management systems, which can provide intelligent routing of network requests to producer NFs based on characteristics of the network requests, and the producer NFs have a lower probability of being unable to process the network requests.

[0011] CROSS-REFERENCE TO RELATED APPLICATIONS

[0012] This application claims priority to U.S. Provisional Application Serial No. 63 / 531,663, filed on August 9, 2023, the entire contents of which are incorporated herein by reference. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a block diagram of a reference point representation of an exemplary 5G system architecture;

[0014] Figure 1B is a block diagram of a service-based representation of an exemplary 5G system architecture;

[0015] Figure 2A is a block diagram of a reference point representation of an exemplary 5G system architecture having a network traffic management device (NTMD) for providing intelligent signal message steering;

[0016] Figure 2B is a service-based representation block diagram of an exemplary 5G system architecture with an NTMD for providing intelligent signal message steering;

[0017] Figure 3is a block diagram of an exemplary network traffic management device;

[0018] Figure 4 is an exemplary network request feature table according to an embodiment of the present disclosure;

[0019] Figure 5 is an exemplary sample training data set according to examples of the present disclosure;

[0020] Fig. 6A and Figure 6B is a partial exemplary failure probability table according to an example of the present disclosure;

[0021] Figure 6C is an exemplary anti-affinity rule created based on data from a failure probability table;

[0022] Figure 7 is a flow chart of an exemplary method for intelligently routing network requests within a 5G core network; and

[0023] Figure 8 is a flow chart of an exemplary method for identifying a faulty user equipment (UE) interacting with a 5G core network. DETAILED DESCRIPTION

[0024] In the following description, for the purpose of explanation, many specific details are set forth to provide a thorough understanding of the present invention. However, it is apparent that the present invention can be implemented without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessary obscurity of the present invention.

[0025] It should be further understood that: unless otherwise expressly stated, the term "or" can be inclusive or exclusive; the term "set" can include zero, one, or two or more elements; the terms "first", "second", "a" and "particular" are used as naming conventions to distinguish elements from each other, and unless otherwise stated, do not imply the order, time or any characteristics of the referenced items; the terms "such as", "eg,", "for example" and the like describe one or more examples, but are not limited to the described examples; the terms "comprises" and / or "comprising" specify the presence of the stated features, but do not exclude the presence or addition of one or more other features.

[0026] A "computer system" refers to one or more computers, such as one or more physical computers, virtual computers, and / or computing devices. For example, a computer system may be or may include one or more server computers, cloud-based computers, cloud-based computer clusters, virtual machine instances, or virtual machine computer elements, such as virtual processors, storage and memory, data centers, storage devices, desktop computers, laptop computers, mobile devices, or any other special-purpose computing devices. Unless otherwise expressly stated, any "computer system" referred to herein may refer to one or more computers. When a computer system performs a measure, the measure is performed by one or more computers of the computer system.

[0027] "Client", "client device", "user equipment (UE)" and / or "user equipment device" refers to a combination of integrated software components and an allocation of computing resources, such as memory, computing devices, and processes on the computing devices for executing the integrated software components. The combination of software and computing resources is configured to interact with one or more servers over a network, such as the Internet. A client may refer to a combination of components on one or more computers, or may refer to one or more computers. User equipment may be any device used directly by an end user to communicate with a network, and may include devices such as handsets, smartphones, laptops equipped with mobile broadband adapters, or any other such device capable of connecting to a radio access network (RAN), a Wi-Fi network, or any other such network.

[0028] "Server" (also referred to as "server system" or "server computer system") refers to a combination of integrated software components and an allocation of computing resources, such as memory, computing devices, and processes on the computing devices for executing the integrated software components. The combination of software and computing resources provides a particular type of functionality to the server's clients. A server may refer to a combination of components on one or more computers, or may refer to one or more computers. A server may include multiple servers; that is, a server may include a first server computing device and a second server computing device, which may provide the same or different functionality to the same or different sets of clients.

[0029] As used herein, the term "network function" (NF) may refer to a component of a network infrastructure that provides well-defined functional behaviors (e.g., routing, switching, etc.). An NF may be a functional building block within a network infrastructure that has a well-defined external interface and well-defined functional behaviors. An NF may be a network node, a physical facility, or a software implementation of a previously physically implemented network function. As used herein, an NF may refer to a physical network function (PNF), a virtualized network function (VNF), and / or a cloud-native network function (CNF).

[0030] This document generally describes systems, methods, devices, and other technologies for intelligently routing network requests within a 5G core network. Conventional methods of routing network requests route traffic based on common parameters such as load, capacity, location, data network name (DNN), network slice, International mobile subscriber identity (IMSI) range, etc. However, these methods are not as efficient as possible because they do not take into account the unique conditions of each NF, which may affect the processing of messages with different feature sets. For example, a particular NF may have received a software update that has inadvertently introduced a software error that causes the NF to have more difficulties in processing network traffic with one or more specific characteristics. Conventional routing methods will not be able to address these issues, which may result in greater packet loss and lower overall data processing efficiency for the system. However, embodiments of the present disclosure provide techniques for not only identifying that a particular NF has such a problem for a particular type of network traffic, but also for directing such network requests away from the NF so as to avoid sending a particular type of network traffic to a NF that has a much lower probability of successfully processing the network traffic. Therefore, embodiments of the present disclosure may provide intelligent routing / steering that may improve the overall efficiency and success processing speed of a network (such as a 5G core architecture) by maximizing the message processing success rate of services provided by NFs.

[0031] The techniques disclosed herein may involve utilizing a machine learning model (such as a naive Bayes classifier) ​​to calculate the probability of failure for each feature in a time series of each of a plurality of consumer NFs of incoming network requests. Thus, for example, if a particular NF is having problems successfully processing voice traffic, the system may determine that a particular NF for processing network requests having features associated with voice traffic has a significantly higher failure rate than other NFs, thereby allowing the system to direct future voice traffic away from the particular NF to minimize the number of failures. In another implementation, the techniques disclosed herein may involve utilizing a machine learning model (such as an anomaly detection model / algorithm) that can be used to identify anomalies based on failure rates exceeding a configured threshold / limit. In this case, the system may direct network requests / traffic having failure features away from destination NF instances that are identified as anomalies because the failure rate of requests having these features is significantly higher than the typical failure rate. When the system identifies NFs having higher failure rates relative to particular network request features, the system may formulate anti-affinity rules that cause incoming network requests having these features to be directed away from the corresponding problematic NFs. According to an embodiment of the present disclosure, the system can maintain a probabilistic failure table that provides a time series of failure rates for each feature of each NF. The probabilistic failure table can be dynamically updated over time, so that when the problem with the NF is resolved (naturally or through human intervention) and the failure rate of the NF returns to normal, the corresponding anti-affinity rule can be removed, and traffic with the corresponding feature can be allowed to flow to the previously problematic NF again. Therefore, the disclosed technology can provide for dynamically creating, removing, or otherwise changing anti-affinity rules to divert traffic away from specified problematic NFs as processing conditions at the NF evolve over time.

[0032] In addition, in addition to providing intelligent routing, embodiments of the present disclosure may also be used to identify problematic user equipment (UE) devices and / or types of UE devices, and optionally take mitigation measures therefor. For example, if a particular model of UE device has recently received a software update, it may be that the software update has inadvertently introduced a software vulnerability to the UE, resulting in a higher than normal network request processing failure rate at a particular NF. For example, a software update for a particular brand of smartphone may cause voice messages to have a higher failure rate when processed at the Session Management Function (SMF) of the 5G core. In this case, an embodiment of the disclosed technology may be configured to identify such problems originating from one or more UEs, because such errors may appear on multiple NFs (e.g., all SMFs receiving traffic from these UEs will show a higher than normal failure rate). The system may be configured to provide a notification of the problem to a system administrator so that the problem can be corrected, or in some cases, the system may be configured to provide mitigation measures for the offending UE by, for example, limiting or blocking traffic from these devices. Under traditional systems, problems caused by specific devices (such as software updates for devices of a particular brand or model) may be completely ignored, and therefore only result in unnecessary high NF failure rates and unnecessary high overall loads on the system. However, since embodiments of the present disclosure can provide a mechanism for identifying problems originating from the UE, which can then be addressed and ultimately repaired, the disclosed technology provides the advantage of allowing the NF network request processing failure rate to be reduced and the overall network request load on the system to be reduced.

[0033] refer to Figure 1A and Figure 1B , shows an exemplary reference point representation and an exemplary service-based representation of the 5G core (5GC) network architecture defined by the 3rd Generation Partnership Project (3GPP) standard. As will be appreciated by those of ordinary skill in the art, the reference point representation focuses on the interaction between pairs of network functions defined by point-to-point reference points (e.g., N7) between any two network functions (e.g., SMF and Policy Control Function (PCF)), and is used when there is some interaction between any two system functions. In addition, while the service-based representation also includes point-to-point reference points between NFs when necessary (e.g., see Figure 1AThe lower part of the diagram, but the upper part of the diagram (i.e., the 5GC control plane) has a "bus" and service-based interfaces exposed by individual functions. This creates the so-called service-based architecture (SBA), where a CP network function (e.g., SMF) allows any other authorized NF to access its services. According to the 3GPP standard, NFs within the 5GC control plane can only use service-based interfaces to execute instructions.

[0034] The 5G core consists of the following network functions: Access and Mobility Management Function (AMF), Session Management Function (SMF), User plane function (UPF), Policy Control Function (PCF), Authentication Server Function (AUSF), Unified Data Management (UDM), Application Function (AF), Network Exposure function (NEF), NF Repository function (NRF) and Network Slice Selection Function (NSSF). As will be understood by those of ordinary skill in the art, all of these NFs are well known and defined by the standards organization 3GPP. However, this article briefly outlines some of the functions of each function for reference:

[0035] AMF can support termination of NAS signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management.

[0036] SMF can support session management (e.g., session establishment, modification, and release), UE Internet Protocol (IP) address allocation and management, Dynamic Host Configuration Protocol (DHCP) functions, termination of NAS signaling related to session management, DL data notification, and traffic steering configuration of UPF for appropriate traffic routing.

[0037] UPF can support packet routing and forwarding, packet inspection, Quality of Service (QoS) processing, act as an external Power Distribution Unit (PDU) session point interconnected with the Data Network (DN), and is the anchor point for mobility within and between Radio Access Technologies (RATs).

[0038] PCF can support a unified policy framework, provide policy rules for CP functions, and access subscription information of policy decisions in a unified data repository (UDR).

[0039] AUSF can act as an authentication server.

[0040] UDM can support the generation of authentication and key agreement (AKA) certificates, user identity processing, access authorization and subscription management.

[0041] AF can support applications to influence traffic routing, access NEF, and interact with the policy framework for policy control.

[0042] NEF can support the opening of capabilities and events, the provision of information from external applications to 3GPP network security, and the conversion of internal / external information.

[0043] NRF can support service discovery functions and maintain NF profiles and available NF instances.

[0044] NSSF can support the selection of network slice instances to serve UEs, determine the allowed network slice selection assistance information (NSSAI), and determine the AMF set used to serve UEs.

[0045] As will be appreciated by those skilled in the art, Figure 1A and Figure 1B As further depicted in , a user equipment (UE) device (e.g., a smartphone) can access the 5G core by connecting to a radio access network (R(AN)) (e.g., a cellular network), and can ultimately access an external data network (DN). For example, the 5G architecture may also include other network devices, such as routers or switches, which are known in the art and are therefore not described here.

[0046] and Figure 1A and Figure 1B similar, Figure 2A and Figure 2B Reference point representation and service-based representation of an exemplary 5G system architecture are also depicted separately. Figure 2A and Figure 2BAlso included is a network traffic management device (NTMD) according to the exemplary embodiments described herein. Although the NTMD is labeled as a device, it should be understood that in some embodiments, the NTMD may exist as a software module on another device (e.g., a device that stores and executes multiple different software-based NFs). According to some embodiments, the NTMD may be a service communication proxy (SCP) device (as described by the 3GPP standards organization). For example, in some embodiments, the functionality described herein may be implemented in a software update provided to the SCP that enhances the functionality provided by the SCP. In addition, although Figure 2A and Figure 2B The NTMD is depicted as being located between the AMF and SMF in this example, but it should be understood that in other embodiments, the NTMD can be placed between any two service based interface (SBI) NFs and perform similar functions as described herein. The NTMD can utilize different reference points or interfaces based on which NFs it is located between. For example, Figure 2A As shown, in this example, NTMD is positioned between AMF and SMF, so although Figure 2B Not depicted in , but the NTMD will make use of the Nsmf and Namf reference points as it is a proxy between the AMF and SMF.

[0047] As mentioned above, in some embodiments, the NTMD may be an SCP. Traditionally, the SCP may provide various functions, such as indirect communication, delegated discovery, message forwarding and routing to the destination NF / NF service, message forwarding and routing to the next-hop SCP, communication security (e.g., authorizing NF service consumers to access NF service producer application programming interfaces (Application Programming Interface, API)), load balancing, monitoring, overload control, and other such functions. The SCP may optionally interact with the UDR to resolve the UDM group ID / UDR group ID / AUF group ID / PSF group ID / adjustment function (CHF) group ID / home subscriber server (Home Subscriber Server, HSS) group ID based on the UE identity code (e.g., Subscription Permanent Identifier, SUPI) or IP Multimedia Private Identity (IP Multimedia Private Identity, IMPU) IMPI / IP Multimedia Public Identity (IP Multimedia Public Identity, IMPU)). The SCP may be deployed in a distributed manner. There may be more than one SCP in the communication path between NF services. The SCP may be deployed at the PLMN level, shared slice level, and slice-specific level. In order to enable SCP to route messages through multiple SCPs (i.e., next SCP hop discovery), SCP can register its configuration file in NRF. Alternatively, local configuration can be used. The load balancing, monitoring and overload control functions provided by SCP are yet to be implemented. Therefore, examples of the present disclosure may include novel enhancements to the functions provided by traditional SCPs.

[0048] refer to Figure 2A-2B , the NTMD can perform any number of functions, such as providing intelligent routing of network requests within the 5G core network as described herein. In this example, the NTMD includes a processor 202, a memory 204, and a communication interface 206, which are coupled together via a bus, although the NTMD may include other types or numbers of elements in other configurations. In addition, although the NTMD is described herein as a device, it should be understood that in some embodiments, the NTMD may be virtualized and some or all of the functions of the NTMD described herein may be implemented in software.

[0049] The processor 202 of the NTMD can execute programmed instructions stored in the memory 204 of the NTMD for any number of functions described and illustrated herein. The processor 202 of the NTMD can include one or more central processing units (CPUs) or general-purpose processors having one or more processing cores, for example, but other types of processors can also be used.

[0050] The memory 204 of the NTMD stores these programming instructions for one or more aspects of the present technology as described and illustrated herein, although some or all of the programming instructions may be stored elsewhere. Various different types of memory storage devices (such as random access memory (RAM), read-only memory (ROM), hard disk, solid state drive, flash memory, or other computer readable media that is read and written by a magnetic, optical, or other read-write system coupled to a processor) can be used for the memory.

[0051] Thus, the memory of the NTMD may store one or more modules that may include computer executable instructions that, when executed by the NTMD, cause the NTMD to perform actions such as sending, receiving, or otherwise processing network messages, for example, and performing the following reference Figure 4-Figure 8 Other actions described and illustrated. These modules can be implemented as components of other modules. In addition, these modules can be implemented as applications, software programs, operating system extensions, plug-ins, etc.

[0052] Further, these modules can operate in a cloud-based computing environment. These modules can be executed in a virtual machine or virtual server managed in a cloud-based computing environment, or can be executed as a virtual machine or server. In addition, these modules and even the NTMD itself may be located in a virtual server running in a cloud-based computing environment, rather than being bound to one or more specific physical network computing devices. In addition, these modules can be run in one or more VMs executed on a secure server device. In addition, in one or more examples of the technology, the virtual machines running on the NTMD can be managed or supervised by a hypervisor.

[0053] In this particular example, the memory of the NTMD includes a feature extraction module 210. According to some examples, the feature extraction module 210 can extract features from a network request. According to some embodiments, the NTMD can be positioned between a consumer NF (e.g., AMF) and a producer NF (e.g., SMF) such that a network flow device intercepts or otherwise receives a network request flowing from a consumer NF to a producer NF. After intercepting a network request originating from a consumer NF, the NTMD can extract features of the network request. Examples of extracted features can include one or more of: an IP address of the consumer NF (e.g., an IP address of the AMF), a DNN, a quality of service class identifier (QCI), an allocation and retention priority (ARP), a location, and a radio access technology type ("RAT type") (e.g., Wi-Fi, 4G, 5G). The NFMD can also be configured to receive or intercept a response (to a request) from a producer NF to a consumer NF, from which the NFMD can determine whether a given request was successfully processed. Figure 4 A table depicting exemplary network request features that may be extracted from a network request by NTMD. Figure 4 The features shown are merely examples, and it is contemplated that, according to other embodiments, any other features not described herein that can be extracted by NTMD may be extracted. Furthermore, it is contemplated that, in various embodiments, different combinations of features may be extracted from network requests, and the present disclosure is not intended to be limited to any one particular set of features.

[0054] According to some embodiments, the NTMD may encapsulate the feature footprint and insert it into the producer NF (e.g. SMF) uniform resource identifier (URI) sent to the consumer NF (e.g. AMF) so that the NTMD can extract the features for all subsequent messages (e.g. modification, handover, etc.). In other words, certain features forwarded from the consumer NF to the producer NF are present only during the session creation message. Subsequently, when the modification / deletion message is sent, these features are not available in the message. For example, a session creation request sent by a consumer NF (e.g. AMF) may include features such as device ID and DNN in a specific field of the message payload (e.g. GPRS Tunneling Protocol version 2 (GTPv2) payload), however, a create session response message from the producer NF (e.g. SMF) to the consumer NF (e.g. AMF) may include a URI that only includes the resource location but not the features such as device ID and DNN. However, the missing information may be retained in the modified URI to be processed in subsequent messages. For example, a session creation message (sent from a consumer NF to the NTMD and then to the producer NF) may include device ID, DNN and location features, which may be extracted by the NTMD and stored as a feature set. When the producer NF sends a response to the create session request, the NTMD may modify the location URI in the location header of the response message to embed the device ID and DNN. In other words, the producer NF may send a response to the create session request with a URI that provides the location of the resource but does not include features such as the device ID and DNN, but the NTMD may modify the URI to include data representing the device ID and DNN so that the consumer NF receives a modified URI that encodes the device ID and DNN. Thus, when the consumer NF (e.g., AMF) sends a subsequent message, such as a modify session request message, the consumer NF (e.g., AMF) sends the modified URI (embedded in the HTTP header portion of the request) to the NTMD (including the location of the resource and the data encoding the device ID and DNN). In other words, although the Modify Session Request message will include the location in the message content, the device ID and DNN features will not be available in the message content, however the device ID and DNN features will be encoded in the URI in the header of the message. Therefore, upon receiving the Modify Session Request message, the NTMD may extract the device ID and DNN from the URI in the header and replace the URI with the original location URI previously received (i.e., the NTMD may modify the URI of the received Modify Session Request message to remove the data encoding the device ID and DNN before forwarding the Modify Session Request message to the producer SMF).Although the previous example describes extracting and storing device ID and DNN features, it should be understood that this is merely an example and any number or type of features described herein may be extracted / stored in this manner. Thus, for each network request destined for a particular type of producer NF (e.g., SMF), the NTMD may extract a set of features from the request that may be compared to the features listed in the anti-affinity rules associated with the respective producer NFs to determine whether the network request should be routed away from the corresponding producer NF.

[0055] For purposes of illustration, an example of the feature extraction process described above will now be provided. According to one example, the AMF may initiate a session by sending a create session request that includes a location and one or more additional features (e.g., device ID1, DNN1, etc.) in a message payload (e.g., GTPv2 payload) of the create session request. The NTMD may receive the create session request from the AMF, and may extract and store the location and one or more features (as a stored "footprint") from the message, and may then forward the message to the SMF. Typically, upon receiving the create session request, the SMF creates the session (i.e., resource) and returns the location of the resource (i.e., URI), and the AMF will use the URI received from the SMF in future messages (e.g., update / delete / modify session messages) to enable the SMF to locate the session and take action on it. Thus, in response to receiving a Create Session Request, the AMF may initiate a session and send a Create Session Response message including a location URI, such as "xyz", (where "xyz" provides the location of the requested resource). The NTMD may receive the Create Session Response message and modify the URI to include data encoding the stored one or more additional features, thereby creating a modified URI, such as "xyzABC" (where "xyz" provides the location of the requested resource and "ABC" encodes the one or more additional features). The NTMD may forward the Create Session Response message with the modified URI to the AMF, such that the AMF receives the URI "xyzABC". Upon sending a subsequent request message, such as a Modify Session Request message, the AMF will utilize the modified URL. Thus, for example, the AMF may send a Create Session Response message including the URI "xyzABC" to the NTMD. The modify session request message may include an HTTP header and a GTPv2 payload. Although the GTPv2 payload of the create session request includes fields for one or more additional features (e.g., device ID1, DNN1, etc.), the GTPv2 payload of the subsequent message (e.g., modify / delete / update session message) does not include such fields and therefore will not indicate the one or more additional features. Therefore, conventionally, the modify / update / delete session message cannot be used to extract such additional features because these features are not included in the message originating from the AMF after the create session request message. However, according to an example of the present disclosure, the modified URI may be included in the HTTP header of such subsequent message originating from the AMF (e.g., the header of the modify session request message). Therefore, upon receiving the modify session request message, the NTMD may extract data encoding the one or more additional features (i.e., "ABC") and identify the one or more additional features (e.g., device ID1, DNN1, etc.) based on the previously stored footprint.The NTMD may remove the data encoding one or more additional features from the URI and then forward the modified session request information to the SMF so that the URI in the header of the message received by the SMF includes only the location (i.e., "xyz"). In this way, the NTMD may extract and identify the feature set from the network request.

[0056] The memory 204 of the NTMD may also include a machine learning model module 212. The machine learning model module 212 in this example may be trained to predict a response result (e.g., success or failure) of a specific network request by a specific producer NF based on features extracted from the network request. According to some embodiments, the machine learning model may be a naive Bayesian machine learning algorithm that may classify objects based on their features using Bayes' theorem and may assign probabilities to each possible outcome or classification for a given problem instance. In other embodiments, any other type of suitable machine learning model may be utilized, such as, for example, an anomaly detection algorithm that may be used to measure the deviation of a failure rate from a configured / automatic detection threshold.

[0057] According to some embodiments, the machine learning model can use features extracted from incoming network requests and responses to the requests as a training set. According to some embodiments, when an anomaly is detected (e.g., a failure rate exceeds a threshold), model learning can be stopped and mitigation measures can be implemented, and when the problem is corrected and normality is restored, the learning / training mode can be restarted. Figure 5 An exemplary sample training data set that can be used to train a machine learning model is illustrated. As shown in this example, the sample training set includes features of AMF IP, DNN, QCI, ARP location, RAT type, and whether the response to the request was successful or failed. Based on the training data, the machine learning model can determine the failure probability and / or failure rate of the feature at a specific consumer NF for each feature on a per consumer NF (e.g., per SMF) basis. According to some embodiments, the model can be retrained periodically (e.g., every hour). In some embodiments, model training can occur continuously, but anomaly detection using the learned data can be periodic. The trained model can generate the following: Fig. 6A and Figure 6BA time series table of failure probabilities and / or failure rates as shown in the example table depicted in . According to some embodiments, the machine learning model may be a Naive Bayes algorithm that calculates failure probabilities based on a data set. In some embodiments, the machine learning model may include an anomaly detection algorithm, in which case the values ​​may represent actual failure rates / percentages over a specific time period. In other words, in one implementation, the failure probability may represent a machine learning-based failure prediction, and in another case (utilizing anomaly detection), the failure probability may represent the actual failure rate observed over a period of time. For each feature (e.g., IP version) and its possible value (e.g., ipv4, ipv6, etc.), NTMD may generate a failure probability table (or any other suitable data structure, such as a database, etc.), which lists the failure rates of network requests including the feature values ​​for each consumer NF in each time interval (all failure rates are collectively referred to as a single "failure probability table"). In Fig. 6A and Figure 6B In the example shown, the failure probability table indicates that SMF1 has an abnormally high failure rate (relative to its own baseline and other SMFs) for network requests with the "internet" DNN characteristic and the "ipv6" session type starting at 12:00 noon on November 30, 2022. According to some embodiments, when the failure rate of a specific producer NF processing network requests with specific characteristics exceeds a predetermined threshold, the NTMD can generate an anti-affinity rule for the specific producer NF including the specific characteristics. Figure 6C Shown based on Fig. 6A and Figure 6B 1 shows an example of an anti-affinity rule generated from the example data of the failure probability table shown in . As shown, the anti-affinity rule stipulates that for network requests with the "internet" DNN capability and the "ipv6" session type, the network request should not be sent to SMF1.

[0058] According to some embodiments, when one or more failure probabilities exceed a predetermined threshold above a characteristic baseline amount, NTMD may form an anti-affinity rule. For example, for a characteristic session type=ipv6, the baseline failure rate may range between 0% and 2% per hour, and the predetermined threshold may be 0.5%. Thus, if Figure 6BAs shown, all failure rates in the columns corresponding to 10:00 AM and 11:00 AM are within the normal baseline range. At 12:00 noon, the failure rate of SMF1 exceeded a predetermined threshold (i.e., 0.5%) above the baseline amount (i.e., 2% of the maximum value of the baseline range). In other words, the failure rate of 4.5% exceeds the baseline of 2.5% plus the threshold amount, and an anti-affinity rule should be formed. Although the 2.3% failure rate of SMF3 is higher than the baseline amount, it is still within the predetermined threshold and therefore has not been used to create an anti-affinity rule. According to some embodiments, in the event that the failure rates of multiple different characteristics associated with the same producer NF exceed the baseline level plus a predetermined threshold, the NTMD may create an anti-affinity rule that includes all of these characteristics. For example, if Fig. 6A and Figure 6B As shown, for the feature DNN=internet and session type=ipv6, SMF1 may have a failure rate that exceeds the baseline level of each feature by a respective predetermined threshold amount, which may cause NTMD to create Figure 6C The anti-affinity rule shown indicates that if a new incoming network request has the characteristics of DNN=internet and session type=ipv6, the network request will be routed out of SMF1.

[0059] According to some embodiments, the NTMD may generate a separate rule for each feature, so that if a network request has any feature associated with a high failure rate, the anti-affinity rule will apply to it. In some embodiments, the NTMD may determine the specific features included in the anti-affinity rule based on which features the NTMD determines cause the failure. For example, if there are 10 features associated with a high failure rate for a particular producer NF, the NTMD may determine that only 5 of the 10 features appear to correspond to the cause of the failure, so the other 5 features may be excluded from the anti-affinity rule. According to some embodiments, the NTMD may determine which features correspond to the cause of the failure by trial and error or using, for example, an anomaly detection algorithm using a histogram. In other words, the NTMD may form a first rule that includes a first feature subset (of a set associated with an abnormally high failure rate) and observe whether the application of the rule causes the failure rate to decrease over a predetermined time period or a predetermined number of network requests, and if not, the NTMD may try a different rule with a different second feature subset and observe whether the application of the rule reduces the failure rate of network requests at the producer NF, and so on, until the NTMD isolates the features associated with the cause of the failure. In some embodiments, when a combination of features that causes a failure occurs, the NTMD can determine which features to use in the anti-affinity rule by individually checking whether the failure rate deviation of the features is in similar proportion to the overall failure when the features are combined. For example, if the failure rate of messages with features F1, F2, and F3 increases by 2%, and the increase in the individual failure rate of all messages with F1 is about 1.8%, the increase in the individual failure rate of all messages with F2 is about 2.1%, and the increase in the individual failure rate of all messages with F3 is about 2.05%, then the NTMD can determine that all 3 features together cause the failure. However, if the combined failure rate increase of F2 and F3 is only about 0.1%, the algorithm can conclude that F2 and F3 only cause significant failures when they appear in messages with F1, and not otherwise. According to some embodiments, after determining that the failure rate of one or more features already included in the anti-affinity rule has returned to a more normal level, the NTMD can remove, delete, or modify the anti-affinity rule to remove such one or more features.

[0060] The memory 204 of the NTMD may also include a routing module 214, which may determine how to route a network request from a consumer NF to a specific producer NF. According to some embodiments, the routing module may include or access the failure probability table and anti-affinity rules generated as described above. Upon receiving a new network request from a producer NF, the NTMD may extract features of the network request as described above, and then the routing module 214 may compare the extracted features with any anti-affinity rules created based on the failure probability table. If one or more anti-affinity rules are applied to the network request based on the extracted features and corresponding features found in the anti-affinity rules, the routing module 214 may prevent the network request from being routed to the NF corresponding to the applicable anti-affinity rule. For example, based on Figure 6C According to the anti-affinity rule shown, if a network request with a feature value corresponding to DNN=internet and session type=ipv6 is received, the routing module 214 will cause the network request to be blocked from being routed to SMF1 and instead route it to one of SMF2 or SMF3. According to some embodiments, after applying the anti-affinity rule, the routing module 214 may route the network request to one of the remaining NFs based on one or more of the load, capacity, and location of each of the remaining NFs.

[0061] although Figure 2A-2B Only a single NTMD and a single NF (e.g., AMF, SMF, etc.) are depicted, but it should be understood that it is contemplated that the system architecture may include multiple of each. For example, there may be multiple NTMDs that communicate with various producer NFs and consumer NFs. In some embodiments, in addition to the NTMDs that communicate with various producer NFs, a given producer NF may also communicate with multiple NTMDs. Therefore, a producer NF may have network messages routed to the producer NF from multiple NTMDs that communicate with multiple consumer NFs. According to some embodiments, each NTMD may operate independently of other NTMDs and may maintain its own failure probability table related to the failure probabilities of connected consumer NFs.

[0062] The communication interface 206 of the NTMD operably couples and communicates between the NTMD and various other NFs (such as AMF, SMF, UDM, AF, PCF, NRF, AUSF, and NEF), and also allows communication with UE, R (AN), UPF, and DN, for example Figure 2BAs shown. According to some embodiments, some or all NFs may be executed as software on a single device, which may be configured to allow communication between NFs. According to some embodiments, the communication interface 206 may be coupled to a communication network that allows communication with NFs on separate devices that may be located outside the NTMD and other external devices such as UE, R(AN), and DN devices. According to some embodiments, the NTMD may be a separate physical device. However, in some embodiments, the enhancements disclosed herein may alternatively be implemented in a software component that can be uploaded to a device such as an SCP. In some embodiments, similar software modules may work in conjunction with other devices similar to the SCP, which may act as a load balancer agent.

[0063] By way of example only, the communication network may include a local area network (LAN) or a wide area network (WAN), and may use the Transmission Control Protocol / Internet Protocol (TCP / IP) and industry standard protocols on Ethernet, although other types or numbers of protocols or communication networks may also be used. The communication network in this example may employ any suitable interface mechanism and network communication technology, including, for example, any suitable form of telecommunication service (e.g., voice, modem, etc.), a Public Switched Telephone Network (PSTN), an Ethernet-based Packet Data Network (PDN), combinations thereof, and the like.

[0064] Although the NTMD is illustrated in this example as including a single device, in other examples, the NTMD may include multiple devices or blades, each of which has one or more processors (each of which has one or more processing cores) that implement one or more steps of the technology. In these examples, one or more devices may have a dedicated communication interface or memory. Alternatively, one or more devices may utilize memory, communication interfaces, or other hardware or software components of one or more other devices included in the NTMD.

[0065] In addition, in other examples, one or more devices that together constitute NTMD can be independent devices or integrated with one or more other devices or apparatuses, such as one or more server devices. In addition, in these examples, one or more devices of NTMD can be located in the same or different communication networks, including, for example, one or more public networks, private networks, or cloud networks.

[0066] Although the NTMD is shown as a single device, one or more actions of each NTMD may be distributed across one or more different network computing devices, which together constitute one or more NTMDs. In addition, the NTMD is not limited to a particular configuration. Thus, the NTMD may include network computing devices that operate in a master / slave manner, where one of the NTMD's network computing devices is used to manage or otherwise coordinate the operations of other network computing devices. For example, the NTMD may operate as multiple network computing devices within a cluster architecture, a peer-to-peer architecture, a virtual machine, or a cloud architecture.

[0067] Therefore, the technology disclosed herein should not be interpreted as being limited to a single environment, and other configurations and architectures can also be envisioned. For example, in some embodiments, the machine learning module and / or the anomaly detection module can be an integrated software component such as an NTMD or SCP device. In some embodiments, the machine learning module and / or the anomaly detection module can be run as a separate container in a cloud-based deployment and can interact with the NTMD or SCP and any other agent that provides input about features to the module and receives feedback / actions from the module. In some embodiments, the machine learning module and / or the anomaly detection module can be implemented as a separate artificial intelligence or machine learning device located in front of the NTMD / SCP / other agent in the network. In this case, there may be non-standard communication between the device and the NTMD / SPC / other agent to provide features, response status, etc. as input to the device and receive anti-affinity rules / fault tables from the device as output. In some embodiments, the machine learning module that detects fault features and / or faulty NFs can be part of a non-standard NF load balancer / agent.

[0068] The user equipment (UE) devices of the 5G network architecture in this example include any type of computing device that can exchange network data, such as mobile, desktop, laptop or tablet computing devices, virtual machines (including cloud-based computers), etc. Each UE device includes a processor, a memory, and a communication interface, which are coupled together via a bus or other communication link (not shown), but other numbers or types of components may also be used.

[0069] The UE device may run an interface application, such as a standard web browser or a standalone client application. The interface application may provide an interface to make requests to and receive content stored on one or more server devices as part of a data network (DN). The UE device may also include a display device, such as a display screen or a touch screen, or an input device, such as a keyboard (not shown).

[0070] Although an exemplary 5G system architecture with NTMD, UE devices, R (AN), DN and various NFs is described and shown herein, other types or numbers of systems, devices, components or elements in other topologies may also be used. It should be understood that the example system described herein is for exemplary purposes, because many variations of specific hardware and software for implementing the example are possible, as will be understood by those skilled in the relevant art.

[0071] One or more components described in the 5G system architecture, such as NTMD and various NFs, can be configured to run as virtual instances on the same physical machine. In other words, NTMD and one or more of the various NFs can run on the same physical device instead of running as separate devices communicating through a communication network. In addition, there may be more than Figure 2A-2B More or fewer examples of NTMDs or various NFs are shown.

[0072] In addition, in any example, two or more computing systems or devices may replace any one system or device. Therefore, the principles and advantages of distributed processing such as redundancy and replication may also be implemented as needed to improve the robustness and performance of the devices and systems of the examples. The examples may also be implemented on a computer system extended across any suitable network using any suitable interface mechanism and traffic technology, including, by way of example only, wireless traffic networks, cellular traffic networks, packet data networks (PDNs), the Internet, intranets, and combinations thereof.

[0073] The examples may also be implemented as one or more non-transitory computer-readable media having instructions stored thereon (such as in a memory of the NTMD) for one or more aspects of the present technology, as described and shown in the examples herein. The instructions in some examples include executable code that, when executed by one or more processors (such as a processor of the NTMD), may cause the processor to perform the steps required to implement the method of the present technology examples described and shown herein.

[0074] Reference Figure 2A-Figure 7 An exemplary method for intelligently routing network requests within a 5G core network is described. More specifically, reference is made to Figure 7, a flowchart of an example method 700 for intelligently routing network requests within a 5G core network is shown. In step 702 of this example, the NTMD may receive a network request. According to some embodiments, the NTMD may be a service communication proxy (SCP) device that has been modified to perform the functions described herein. In some embodiments, the NTMD may be located between a consumer NF and a producer NF, such as between an AMF and an SMF. In this example, the NTMD will intercept / receive network requests from the AMF (consumer NF) that are intended for the SMF (producer NF). The NTMD may also be configured to receive / intercept responses from the producer NF to the consumer NF, from which it may be determined whether the request was successfully processed. According to some embodiments, the producer NF and the consumer NF may be configured to direct requests and responses directly to the NTMD, for example, the IP address of the NTMD may be locally configured at the consumer / producer NF, or the consumer / producer NF may discover the NTMD from the NRF using the provisions specified in the 3GPP specification 29.510.

[0075] In step 704, the NTMD may identify a feature set based on the network request. Figure 3 and Figure 4 As described above, the NTMD may include a feature extraction module, which may extract various features (and their corresponding values) from a network request. Therefore, for each network request received by the NTMD, the NTMD will extract a corresponding feature value set.

[0076] In step 706, the NTMD may identify a faulty producer network function (NF) from the plurality of NFs based on the feature set and the failure probability table. It is to be understood that more than one producer NF may experience a failure in response to a particular feature set, and it is contemplated that the techniques described herein may be used to identify all such faulty producer NFs in the same manner as a single faulty producer NF described herein. According to some embodiments, the failure probability table is configured to track, for each of the plurality of producer NFs, a time series of network request processing failure rates for each of the plurality of features. For example, as described above with respect to Figure 3 , Fig. 6A and Figure 6B As described, the NTMD may include a machine learning model module. Therefore, in some embodiments, a machine learning model (such as a naive Bayes algorithm) may be used to determine the network request processing failure rate, for example, by receiving the features of the request and whether the request was successfully processed as input, and outputting the probability that each feature is the cause of the failure. In other words, in some embodiments, the machine learning model is trained to predict the probability of a request processing failure using features extracted from multiple previous requests, each of which is known to have been successfully processed or is known to have had a processing failure.

[0077] According to some embodiments, the NTMD may identify a faulty producer NF among the producer NFs by determining that the producer NF has a failure rate associated with one or more feature values ​​that exceeds a predetermined threshold percentage above a baseline percentage. In some embodiments, the baseline percentage may be a maximum percentage of a range of percentages that are considered normal failure levels for network requests having features of an associated type (e.g., during a specified time of day and / or day of the week).

[0078] Alternatively, according to some embodiments, the NTMD may identify a faulty producer NF among the producer NFs by determining that the producer NF has the highest failure rate for a given feature value out of the set of all available producer NFs. Thus, in this case, the NTMD may be configured to direct network requests including the given feature value away from the NF having the highest failure rate associated with the feature value.

[0079] In step 708, the NTMD may define a subset of the plurality of producer NFs such that the subset of the plurality of producer NFs does not include a faulty producer NF among the producer NFs. In other words, the NTMD may define an anti-affinity rule that excludes the faulty producer NF from being one of the options to which the network request may be routed.

[0080] In step 710, the NTMD may route the network request to one of the subset of the plurality of producer NFs. According to some embodiments, routing the network request to one of the subset of the plurality of producer NFs is based on one or more of a load of each of the subset of the plurality of producer NFs, a capacity of each of the subset of the plurality of producer NFs, and a location of each of the subset of the plurality of producer NFs. In other words, after ruling out the faulty producer NF as a possible destination for the received network request, the NTMD may then route the received network request between the remaining set of producer NFs using a more conventional approach.

[0081] refer to Figure 8, an exemplary method 800 for identifying a faulty UE device interacting with a 5G core network is shown, which will now be described. In step 802 of the example, the NTMD may identify a plurality of faulty producer NFs. For example, the NTMD may maintain a failure probability table that provides a failure rate of network message processing for each feature value of each producer NF in time series. In other words, for each producer NF connected to the NTMD, the NTMD may maintain a table indicating the failure rate of each feature value of a plurality of features that may be extracted from a network request at different time intervals. The NTMD may identify a plurality of faulty producer NFs (i.e., traffic may be directed to them) by identifying two or more producer NFs connected to the NTMD that have a failure rate that is higher than a predetermined threshold amount above a baseline failure rate. Each type of feature may have its own baseline failure rate and a predetermined threshold.

[0082] In step 804, the NTMD may identify a set of fault signatures based on network messages sent to multiple faulty producer NFs. Fault signatures may be signatures that cause higher than normal failure rates at producer NFs. The NTMD may identify a set of fault signatures that are common among multiple faulty producer NFs. For example, if NF1 has fault signatures 1, 2, 3, and 4, NF2 has fault signatures 2, 3, 5, and NF3 has fault signatures 2, 3, and 4, the NTMD may determine that the set of fault signatures is 2 and 3 because these are common signatures that appear to cause all three faulty NFs to fail. This set of fault signatures may be considered a fault footprint.

[0083] In step 806, the NTMD may identify the UE type based on the set of fault features. In other words, according to some embodiments, the NTMD may identify the UE type based on the fault footprint. For example, referring to the example in the previous paragraph, the NTMD may determine that features 2 and 3 correspond to a smartphone of a specific brand running a specific version of an operating system. Therefore, the NTMD may determine that there is a UE-related problem associated with this specific type of smartphone running this specific operating system. According to some embodiments, the NTMD may utilize such fault fingerprints to identify various aspects of the UE, such as manufacturer, model, operating system version, browser, location, and other such features. For example, a person of ordinary skill in the art will understand that the International Mobile Station Equipment Identity Software Version (IMEISV) is a feature that identifies a device and consists of 16 digits, wherein the first 8 digits identify the manufacturer, the subsequent 6 digits identify the unique serial number of a specific device within the manufacturer, and the last 2 digits represent the software version of the device. Therefore, if IMEISV is one of the fault features identified by the NTMD, the IMEISV digits may be analyzed to identify the manufacturer, serial number, and software version of the device that caused the fault. Another example may include features of a Public Land Mobile Network (PLMN) code and location, which may not directly indicate a device, but may identify a specific RAN cellular base station by identifying that the device is used with a specific telecom operator's SIM card and connected to a specific location. It should be understood that these are merely examples, and it is contemplated that other features may also be similarly used to identify issues with a specific device (e.g., a specific cellular tower) or device (e.g., a specific brand / model and / or software version).

[0084] In step 808, the NTMD may perform mitigation actions for one or more sessions associated with the UE type. For example, the NTMD may limit or block network traffic from devices or sessions associated with or originating from devices of the UE type. In addition, in some embodiments, performing mitigation actions may include generating a notification to a system administrator detailing one or more NFs that are experiencing a fault, characteristic values / fault footprints associated with the fault, and the UE type that the NTMD has identified as the source of the faulty NF. In this way, the system can detect problems caused by the UE and notify the administrator so that the problem with the UE can be corrected (e.g., by updating the UE software to fix the error).

[0085] Through this technology, intelligent routing of network requests within the 5G core network can be achieved, so that faulty NFs can be identified, and traffic that is likely to not be successfully processed by the faulty NF can be diverted away from the faulty NF while still providing load balancing capabilities. Therefore, the system can advantageously perform load balancing while reducing the rate of message processing failures that occur across NFs. The system can dynamically route / direct traffic away from the faulty NF based on the changing conditions of the network, so that as new NFs begin to fail and previously faulty NFs resume normal operation, the system can automatically create and delete anti-affinity rules based on the changing NF conditions to minimize the failure rate. In addition, the system allows identification of problems that cause high NF processing failure rates that are not problems with the NF itself, but rather problems that originate from UEs. After identifying that a set of UEs appears to have problems that cause elevated NF processing failure rates, the system can generate a notification identifying the set of UEs that cause the problem so that an administrator can resolve the problem. In addition, in some embodiments, after identifying the set of UEs that cause NF processing failures, the system can optionally take one or more mitigation actions on these UEs by limiting or blocking network traffic originating from these UEs. Therefore, the system can advantageously identify problems caused by NFs and UEs and take actions to minimize NF processing failure rates to improve the reliability and speed of services provided by 5G networks.

[0086] Having thus described the basic concepts of the invention, it will be apparent to those skilled in the art that the above detailed disclosure is presented by way of example only and not by way of limitation. Although not expressly described herein, it will be appreciated by those skilled in the art that various changes, improvements and modifications occur. These changes, improvements and modifications are intended to be presented herein and are within the spirit and scope of the invention. In addition, the order of the processing elements or sequences, or the use of numbers, letters or other names therefor, is not meant to limit the claimed process to any order, unless otherwise provided in the claims. Therefore, the present invention is limited only by the following claims and their equivalents.

Claims

1. A method implemented by a network traffic management system, the network traffic management system comprising one or more network traffic management devices and a network function NF, the method comprising: Receive network requests; identifying a feature set based on the network request; identifying a faulty producer network function among the producer network functions from a plurality of producer network functions based on the feature set and the fault probability table; defining a subset of the plurality of producer network functions, wherein the subset of the plurality of producer network functions does not include the one faulty one of the producer network functions; as well as The network request is routed to one of a subset of the plurality of producer network functions.

2. The method according to claim 1, wherein: The failure probability table is configured to track, for each of the plurality of producer network functions, a time series of a network request processing failure rate for each of a plurality of characteristics.

3. The method according to claim 2, wherein: The network request processing failure rate is determined using a machine learning model.

4. The method according to claim 3, wherein: The machine learning model is trained to predict a probability of a request processing failure using features extracted from a plurality of previous requests, wherein each of the plurality of previous requests is known to have been successfully processed or is known to have had a processing failure.

5. The method according to claim 1, wherein: Routing the network request to one of the subset of the plurality of producer network functions is based on one or more of: a load for each of a subset of the plurality of producer network functions; the capacity of each of a subset of the plurality of producer network functions; or The location of each of the subset of the plurality of producer network functions.

6. A network traffic management device comprising a memory and one or more processors, the memory including programming instructions stored thereon, the processors being configured to execute the stored programming instructions to perform the following operations: Receive network requests; identifying a feature set based on the network request; Based on the feature set and the fault probability table, identifying a faulty producer network function among the plurality of producer network functions NF; defining a subset of the plurality of producer network functions, wherein the subset of the plurality of producer network functions does not include the one faulty one of the producer network functions; as well as The network request is routed to one of a subset of the plurality of producer network functions.

7. The device according to claim 6, wherein: The failure probability table is configured to track, for each of the plurality of producer network functions, a time series of a network request processing failure rate for each of a plurality of characteristics.

8. The device according to claim 7, wherein: The network request processing failure rate is determined using a machine learning model.

9. The device according to claim 8, wherein: The machine learning model is trained to predict a probability of a request processing failure using features extracted from a plurality of previous requests, wherein each of the plurality of previous requests is known to have been successfully processed or is known to have had a processing failure.

10. The device according to claim 6, wherein: Routing the network request to one of the subset of the plurality of producer network functions is based on one or more of: a load for each of a subset of the plurality of producer network functions; the capacity of each of a subset of the plurality of producer network functions; or The location of each of the subset of the plurality of producer network functions.

11. A non-transitory computer-readable medium having instructions stored thereon, the instructions comprising executable code, when the executable code is executed by one or more processors, causing the processor to perform the following operations: Receive network requests; identifying a feature set based on the network request; Based on the feature set and the fault probability table, identifying a faulty producer network function among the plurality of producer network functions NF; defining a subset of the plurality of producer network functions, wherein the subset of the plurality of producer network functions does not include the one faulty one of the producer network functions; as well as The network request is routed to one of a subset of the plurality of producer network functions.

12. The non-transitory computer readable medium of claim 11, wherein: The failure probability table is configured to track, for each of the plurality of producer network functions, a time series of a network request processing failure rate for each of a plurality of characteristics.

13. The non-transitory computer readable medium of claim 12, wherein: The network request processing failure rate is determined using a machine learning model.

14. The non-transitory computer readable medium of claim 13, wherein: The machine learning model is trained to predict a probability of a request processing failure using features extracted from a plurality of previous requests, wherein each of the plurality of previous requests is known to have been successfully processed or is known to have had a processing failure.

15. The non-transitory computer readable medium of claim 11, wherein: Routing the network request to one of the subset of the plurality of producer network functions is based on one or more of: a load for each of a subset of the plurality of producer network functions; the capacity of each of a subset of the plurality of producer network functions; or The location of each of the subset of the plurality of producer network functions.

16. A network traffic management system, comprising one or more network traffic management devices and a network function NF, the network traffic management system having a memory and one or more processors, the memory comprising programming instructions stored thereon, the one or more processors being configured to be able to execute the stored programming instructions to perform the following operations: Receive network requests; identifying a feature set based on the network request; identifying a faulty producer network function from among a plurality of producer network functions based on the feature set and the fault probability table; defining a subset of the plurality of producer network functions, wherein the subset of the plurality of producer network functions does not include the one faulty one of the producer network functions; as well as The network request is routed to one of a subset of the plurality of producer network functions.

17. The system of claim 16, wherein: The failure probability table is configured to track, for each of the plurality of producer network functions, a time series of a network request processing failure rate for each of a plurality of characteristics.

18. The system of claim 17, wherein: The network request processing failure rate is determined using a machine learning model.

19. The system of claim 18, wherein: The machine learning model is trained to predict a probability of a request processing failure using features extracted from a plurality of previous requests, wherein each of the plurality of previous requests is known to have been successfully processed or is known to have had a processing failure.

20. The system of claim 16, wherein: Routing the network request to one of the subset of the plurality of producer network functions is based on one or more of: a load for each of a subset of the plurality of producer network functions; the capacity of each of a subset of the plurality of producer network functions; or The location of each of the subset of the plurality of producer network functions.

Images