Identifying the cause of network anomalies

Abstract

The present invention appropriately assesses abnormality that occurs to a network. In the present invention, a network system: acquires output when input data including an index acquired from a network of interest is inputted to a cause estimation model among a plurality of cause estimation models corresponding respectively to a plurality of groups into which a plurality of networks are classified, and having been trained on training data that includes input data including an index acquired with regard to a respective corresponding group and correct-answer data indicating the cause of abnormality, said cause estimation model corresponding to the group to which the network of interest among the plurality of networks belongs (S103); and executes a process for responding to the abnormality that has arisen on the network of interest, on the basis of the output of the cause of abnormality estimation model pertaining to the network of interest (S104).

Description

[Technical field]

[0001] The present disclosure relates to a network system and a method for dealing with a network anomaly. [Background technology]

[0002] In recent years, communication networks are provided by dividing them into multiple networks (e.g., multiple network slices) based on the type of target terminal or region, etc. The configurations and usage situations of these multiple networks differ from one another due to individual conditions. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-536434 A Summary of the Invention [Problem to be solved by the invention]

[0004] In order to effectively monitor these networks, it is conceivable to use machine learning models to analyze anomalies that occur in those networks.

[0005] However, the background of each network, such as its configuration and usage status, is different for each network. While anomalies that occur in a network depend on the individual background, it was not easy to train a machine learning model for each network.

[0006] The present disclosure has been made in consideration of the above-mentioned situation, and one of its objectives is to provide a technology that enables appropriate determination of anomalies occurring in a network using a small number of machine learning models. [Means for solving the problem]

[0007] In order to solve the above problems, a network system according to the present disclosure includes one or more processors, and a cause estimation process and a response process are executed by at least one of the one or more processors. In the cause estimation process, an output is obtained when input data including an index acquired from a target network is input to a cause estimation model corresponding to a group to which a target network belongs among the multiple networks, the cause estimation models being multiple cause estimation models respectively corresponding to multiple groups into which multiple networks are classified, the multiple cause estimation models being trained using input data including an index acquired for the corresponding group and training data including ground truth data indicating the cause of the anomaly. In the response process, a process for responding to an anomaly occurring in the target network is executed based on the output of the cause estimation model for the target network.

[0008] The method for dealing with an anomaly in a network according to the present disclosure includes one or more processors, and a cause estimation process and a handling process are performed by at least one of the one or more processors. In the cause estimation process, an output is obtained when input data including an index acquired from a target network is input to a cause estimation model corresponding to a group to which a target network belongs among a plurality of cause estimation models that correspond to a plurality of groups into which a plurality of networks are classified and that are trained using input data including an index acquired for each corresponding group and training data including ground truth data indicating the cause of the anomaly. In the handling process, a process for handling an anomaly occurring in the target network is executed based on the output of the cause estimation model for the target network. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a communication system according to an embodiment of the present disclosure. [Diagram 2] FIG. 1 is a diagram illustrating an example of a communication system according to an embodiment of the present invention. [Diagram 3]FIG. 2 is a diagram illustrating an example of a network service according to the present embodiment. [Figure 4] FIG. 2 is a diagram showing an example of an association between elements established in the communication system according to the present embodiment. [Diagram 5] A diagram showing an example of network slice attributes. [Figure 6] FIG. 2 is a functional block diagram showing an example of functions implemented in the platform system. [Figure 7] FIG. 11 is a flow diagram showing an overview of the process of a policy manager. [Figure 8] FIG. 11 is a flow diagram showing an example of processing of an AI big data processing unit. [Figure 9] FIG. 13 is a diagram illustrating an example of the correspondence between a cause inference model and an API and a group. [Figure 10] FIG. 11 is a flow diagram showing an example of a process in which a policy manager unit responds by using a cause estimation model. [Figure 11] FIG. 11 is a flowchart showing another example of the processing of the AI ​​big data processing unit. [Figure 12] FIG. 11 is a flowchart showing another example of the process in which the policy manager unit responds by using the cause estimation model. [Figure 13] FIG. 11 is a flow diagram showing an example of a process performed by a policy manager unit without using a cause estimation model. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

[0011] 1 and 2 are diagrams illustrating an example of a communication system 1 according to an embodiment of the present disclosure. Fig. 1 is a diagram focusing on the locations of a group of data centers included in the communication system 1. Fig. 2 is a diagram focusing on various computer systems implemented in the group of data centers included in the communication system 1.

[0012] As shown in FIG. 1, the data centers included in the communication system 1 are classified into a central data center 10, a regional data center 12, and an edge data center 14.

[0013] For example, several central data centers 10 are distributed and disposed within an area covered by the communication system 1 (for example, within Japan).

[0014] For example, several tens of regional data centers 12 are distributed in the area covered by the communication system 1. For example, when the area covered by the communication system 1 is the entirety of Japan, one or two regional data centers 12 may be disposed in each prefecture.

[0015] For example, several thousand edge data centers 14 are distributed and arranged within an area covered by the communication system 1. Each edge data center 14 is capable of communicating with a communication facility 18 having an antenna 16. As shown in FIG. 1, one edge data center 14 may be capable of communicating with several communication facilities 18. The communication facility 18 may include a computer such as a server computer. The communication facility 18 according to this embodiment performs wireless communication with a UE (User Equipment) 20 via the antenna 16. The communication facility 18 having the antenna 16 is provided with, for example, a radio unit (RU) described later.

[0016] In this embodiment, the central data center 10, the regional data center 12, and the edge data center 14 each have a plurality of servers arranged therein.

[0017] In this embodiment, for example, the central data center 10, the regional data centers 12, and the edge data centers 14 are capable of communicating with each other. In addition, the central data centers 10, the regional data centers 12, and the edge data centers 14 are also capable of communicating with each other.

[0018] 2, the communication system 1 according to the present embodiment includes a platform system 30, a plurality of radio access networks (RANs) 32, a plurality of core network systems 34, and a plurality of UEs 20. The core network systems 34, the RANs 32, and the UEs 20 cooperate with each other to realize a mobile communication network.

[0019] The RAN 32 is a computer system equipped with an antenna 16, which corresponds to an eNB (eNodeB) in a fourth generation mobile communication system (hereinafter referred to as 4G) or a gNB (NR base station) in a fifth generation mobile communication system (hereinafter referred to as 5G). The RAN 32 according to this embodiment is mainly implemented by a group of servers and communication equipment 18 arranged in an edge data center 14. Note that a part of the RAN 32 (e.g., a distributed unit (DU), a central unit (CU), a virtual distributed unit (vDU), and a virtual central unit (vCU)) may be implemented in the central data center 10 or the regional data center 12, instead of the edge data center 14.

[0020] The core network system 34 is a system equivalent to an EPC (Evolved Packet Core) in 4G and a 5G core (5GC) in 5G. The core network system 34 according to this embodiment is implemented mainly by a group of servers arranged in the central data center 10 and the regional data centers 12.

[0021] The platform system 30 according to the present embodiment is configured on a cloud platform, for example, and includes one or more processors 30a, a storage unit 30b, and a communication unit 30c, as shown in FIG. 2. The processor 30a is a program-controlled device such as a microprocessor that operates according to a program installed in the platform system 30. The storage unit 30b is, for example, a storage element such as a ROM or RAM, a solid-state drive (SSD), or a hard disk drive (HDD). The storage unit 30b stores programs executed by the processor 30a, etc. The communication unit 30c is, for example, a communication interface such as a network interface controller (NIC) or a wireless local area network (LAN) module. The communication unit 30c transmits and receives data between the RAN 32 and the core network system 34. The communication unit 30c may constitute a part of a software-defined networking (SDN).

[0022] In this embodiment, the platform system 30 is implemented by a group of servers arranged in the central data center 10. The platform system 30 may be implemented by a group of servers arranged in the regional data center 12. The processor 30a, the storage unit 30b, and the communication unit 30c may actually be included in the servers. The RAN 32 and the core network system 34 may include the processor 30a, the storage unit 30b, and the communication unit 30c, similar to the platform system 30.

[0023] In this embodiment, for example, in response to a purchase request for a network service (NS) by a purchaser, the network service for which the purchase request has been made is constructed in the RAN 32 and the core network system 34. Then, the constructed network service is provided to the purchaser.

[0024] For example, a purchaser, which is an MVNO (Mobile Virtual Network Operator), is provided with network services such as voice communication services and data communication services. The voice communication services and data communication services provided by this embodiment are ultimately provided to a customer (end user) of the purchaser (MVNO in the above example) who uses the UE 20 shown in Figs. 1 and 2. The end user is capable of performing voice communication and data communication with other users via the RAN 32 and the core network system 34. The UE 20 of the end user is also capable of accessing a data network such as the Internet via the RAN 32 and the core network system 34.

[0025] In addition, in this embodiment, an IoT (Internet of Things) service may be provided to an end user who uses a robot arm, a connected car, etc. In this case, for example, the end user who uses the robot arm, the connected car, etc. may become a purchaser of the network service according to this embodiment.

[0026] In this embodiment, a container-type virtualized application execution environment such as Docker (registered trademark) is installed on the servers arranged in the central data center 10, the regional data center 12, and the edge data center 14, so that containers can be deployed and operated on these servers. In these servers, a cluster consisting of one or more containers generated by such virtualization technology may be constructed. For example, a Kubernetes cluster managed by a container management tool such as Kubernetes (registered trademark) may be constructed. Then, a processor on the constructed cluster may execute a container-type application.

[0027] In this embodiment, the network service is composed of one or more functional units (for example, network functions (NFs)). In this embodiment, the functional units are implemented in NFs realized by virtualization technology. NFs realized by virtualization technology are called VNFs (Virtualized Network Functions). It does not matter what virtualization technology is used for virtualization. For example, in this description, a CNF (Containerized Network Function) realized by a container-type virtualization technology is also included in VNFs. In this embodiment, the network service is described as being implemented by one or more CNFs. Also, the functional units in this embodiment may correspond to network nodes.

[0028] Figure 3 is a schematic diagram of an example of a network service in operation. Figure 3 shows an example of the configuration of an end-to-end network slice of one of the network services. A network slice is a virtual division of a physical communication network.

[0029] The network service shown in Figure 3 includes NFs such as multiple RUs 40, multiple DUs 42, multiple CUs 44, multiple UPFs (User Plane Functions) 46, one or more AMFs (Access and Mobility Management Functions), and one or more SMFs (Session Management Functions) as software elements.

[0030] In addition, network routes are provided between the CU 44 and the AMF and between the CU 44 and the UPF by the SDN 36. The SDN 36 is implemented by dedicated network equipment and equipment including multiple servers. A network route corresponds to a kind of tunnel, and the SDN 36 makes it possible to set a new route or change the physical device through which an existing route passes by using software settings.

[0031] In this embodiment, for example, a communication service in a certain area is provided by the network service shown in Fig. 3. The network service also includes other software elements, but the description of these elements is omitted. The network service is implemented on computer resources (hardware elements) such as multiple servers.

[0032] Fig. 4 is a diagram showing an example of associations between elements established in the communication system 1 in this embodiment. The symbols M and N shown in Fig. 4 represent any integers equal to or greater than 1, and indicate the relationship between the numbers of elements connected by a link. When both ends of a link are a combination of M and N, the elements connected by the link have a many-to-many relationship, and when both ends of a link are a combination of 1 and N or a combination of 1 and M, the elements connected by the link have a one-to-many relationship.

[0033] As shown in Figure 4, network services (NS), network functions (NF), CNFCs (Containerized Network Function Components), pods, and containers are arranged in a hierarchical structure.

[0034] For example, the NS corresponds to a network service composed of multiple NFs. Here, the NS may correspond to an element of granularity such as 5GC, EPC, 5G RAN (gNB), 4G RAN (eNB), etc.

[0035] In 5G, the NFs correspond to elements of granularity such as DU42, CU44, and UPF46. In addition, the NFs correspond to elements of granularity such as AMF and SMF. In 4G, the NFs correspond to elements of granularity such as MME (Mobility Management Entity), HSS (Home Subscriber Server), S-GW (Serving Gateway), vDU, and vCU. In this embodiment, for example, one NS includes one or more NFs. That is, one or more NFs are subordinate to one NS.

[0036] A CNFC corresponds to an element of granularity such as DU mgmt and DU Processing. A CNFC may be a microservice deployed on a server as one or more containers. For example, a certain CNFC may be a microservice that provides some of the functions of DU42, CU44, etc. Also, a certain CNFC may be a microservice that provides some of the functions of UPF46, AMF, SMF, etc. In this embodiment, for example, one NF includes one or more CNFCs. That is, one or more CNFCs are subordinate to one NF.

[0037] A pod is the smallest unit for managing a Docker container in Kubernetes, for example. In this embodiment, for example, one CNFC includes one or more pods. That is, one or more pods are under the control of one CNFC.

[0038] In this embodiment, for example, one pod includes one or more containers. That is, one or more containers are subordinate to one pod.

[0039] Also, as shown in Figure 4, network slices (NSIs) and network slice subnet instances (NSSIs) have a hierarchical structure.

[0040] The NSI can also be considered as an end-to-end virtual circuit spanning multiple domains (e.g., from the RAN 32 to the core network system 34). The NSI may be a slice for high-speed, large-capacity communication (e.g., for enhanced Mobile Broadband (eMBB)), a slice for high-reliability and low-latency communication (e.g., for Ultra-Reliable and Low Latency Communications (URLLC)), or a slice for connecting a large number of terminals (e.g., for massive Machine Type Communication (mMTC)). The NSSI can also be a virtual circuit of a single domain obtained by dividing the NSI. The NSSI may be a slice of the RAN domain, a slice of the Mobile Back Haul (MBH) domain, or a slice of the core network domain.

[0041] In this embodiment, for example, one NSI includes one or more NSSIs. That is, one or more NSSIs are subordinate to one NSI. In this embodiment, multiple NSIs may share the same NSSI.

[0042] Furthermore, as shown in FIG. 4, NSSI and NS generally have a many-to-many relationship.

[0043] Also, in this embodiment, for example, one NF can belong to one or more network slices. Specifically, for example, one NF can be configured with NSSAI (Network Slice Selection Assistance Information) including one or more S-NSSAI (Sub Network Slice Selection Assist Information). Here, S-NSSAI is information associated with a network slice. Note that an NF does not have to belong to a network slice.

[0044] Multiple network slices may differ from one another in terms of the target area, the configuration of NFs, the type of UE 20 they target, etc. FIG. 5 is a diagram showing an example of attributes of a network slice. In FIG. 5, slice ID, type, configuration, and group are shown as attributes of a network slice. The slice ID is information for identifying a network slice. The type indicates the type of network characteristics, and if blank, it indicates characteristics for communication with general UE 20, and in the case of IoT, it indicates characteristics specialized for communication with IoT terminals. The configuration indicates the number of NFs (AMF, SMF, UPF) that realize the network slice and the area to be covered. The group indicates the group to which the network slice belongs.

[0045] In this embodiment, the multiple network slices are classified into multiple groups according to their types, configurations, and network usage characteristics (e.g., urban-centered usage characteristics or suburban-centered usage characteristics). In classifying the groups, the number of network paths calculated from the number of AMFs, SMFs, and UPFs and the number of RANs, as well as the types of the network paths and the number of RANs (e.g., gNBs) may also be used. This classification may be performed by a so-called clustering technique. One or multiple network slices belong to each of the multiple groups.

[0046] The platform system 30 according to the present embodiment monitors each of the multiple network slices, detects anomalies that occur in the network slices, and executes a process to deal with the anomalies. The process will be described in more detail below.

[0047] Fig. 6 is a functional block diagram showing an example of functions implemented in the platform system 30 according to the present embodiment. Note that it is not necessary for all of the functions shown in Fig. 5 to be implemented in the platform system 30 according to the present embodiment, and functions other than the functions shown in Fig. 6 may be implemented.

[0048] As shown in FIG. 6, the platform system 30 according to this embodiment functionally includes an inventory database 50, an orchestration (E2EO: End-to-End-Orchestration) unit 52, a ticket management unit 54, an AI / big data processing unit 56, a performance calculation unit 57, a monitoring function unit 58, an SDN controller 60, and a configuration management unit 62. The E2EO unit 52 functionally includes a policy manager unit 80 and a slice manager unit 82. The AI / big data processing unit 56 functionally includes a big data storage unit 70, a normality determination unit 72, a cause estimation unit 74, and an API unit 76. The normality determination unit 72 includes a plurality of normality determination models 73, and the cause estimation unit 74 includes a plurality of cause estimation models 75. These elements are mainly implemented by the processor 30a, the storage unit 30b, and the communication unit 30c.

[0049] The functions and processes described in this embodiment are realized by reading a storage medium in which software (program execution instructions) is recorded into one or more information processing devices (e.g., a server) including a processor 30a, a storage unit 30b (e.g., a memory), and the like, and by the processor 30a executing the processes related to the software. The storage medium may be, for example, a computer-readable, non-volatile information storage medium such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory. The software may be stored in an external storage device (e.g., a hard disk drive or a solid-state drive) included in the storage unit 30b of the platform system 30. The functions shown in FIG. 6 may be implemented by a circuit block, a memory, or other integrated circuits. It is easily understood by those skilled in the art that the functions shown in FIG. 6 can be realized in various forms such as hardware only, software only, or a combination thereof.

[0050] The inventory database 50 is a database that stores inventory information. The inventory information includes, for example, information about servers that are installed in the RAN 32 and the core network system 34 and that are managed by the platform system 30.

[0051] Furthermore, in this embodiment, inventory data is stored in the inventory database 50. The inventory data indicates the configuration of the group of elements included in the communication system 1 and the current status of the association between the elements (e.g., topology data). The elements include hardware elements and software elements. The hardware elements include, for example, servers, racks, buildings, and network devices. The software elements include, for example, network slices, NFs, and operating containers. The inventory data also indicates the status of resources managed by the platform system 30 (e.g., resource usage status).

[0052] Topology data indicating the current state of associations between elements includes, for example, an identifier of a NS and the identifiers of one or more NFs under the NS, and also includes, for example, an identifier of a network slice and the identifiers of one or more NFs belonging to the network slice.

[0053] 6 refer to inventory data stored in the inventory database 50 in their processing, and add or update the inventory data as necessary. For example, the inventory data stored in the inventory database 50 is updated in response to the execution of actions such as construction of a new element included in the communication system 1, configuration change of an element included in the communication system 1, scaling of an element included in the communication system 1, replacement of an element included in the communication system 1, and the like.

[0054] In this embodiment, for example, the slice manager unit 82 executes logic indicated by a slice template to instantiate a network slice. Here, the slice manager unit 82 may output a configuration management instruction related to the instantiation of the network slice to the configuration management unit 62. Then, the configuration management unit 62 may execute configuration management such as settings in accordance with the configuration management instruction.

[0055] The slice manager unit 82 may output an instruction to create a communication path between NFs (between the CU 44 and the UPF 46 and between the CU 44 and the UPF 46 and between the NFs and the AMF) to the SDN controller 60. The SDN controller 60 may output a more specific instruction to create a communication path to the SDN 36. The specific instruction to create a communication path includes the IP addresses of two SRVs 6 as information for identifying the CU 44 and the UPF 46 or the AMF that communicate with each other.

[0056] Here, the slice manager unit 82 executes a process of enhancing at least one of the communication path in the network slice and the NF in the core network system 34 or the like in response to an instruction from the policy manager unit 80. For example, the slice manager unit 82 may output a configuration management instruction to the configuration management unit 62 to scale out one of the UPF 46, AMF, and SMF associated with the network slice, and output a creation instruction to the SDN controller 60 to create a new communication path between the scaled-out UPF 46 or AMF and the CU 44 of each RAN 32. The slice manager unit 82 may also output a change instruction to the SDN controller 60 to change the upper limit of the bandwidth of the communication path between the existing UPF 46 or AMF and the CU 44 of each RAN 32, or to recreate the communication path (in other words, to change the communication path to be used).

[0057] The slice manager unit 82 is configured to include the functions of the NSMF (Network Slice Management Function) and the NSSMF (Network Slice Sub-network Management Function) described in the specification "TS28 533" of the 3GPP (Third Generation Partnership Project) (registered trademark), for example. The NSMF is a function that generates and manages network slices, and provides management services for NSIs. The NSSMF is a function that generates and manages network slice subnets that constitute part of the network slice, and provides management services for NSSIs.

[0058] In this embodiment, the configuration management unit 62 executes configuration management such as setting of element groups such as NFs, in accordance with a configuration management instruction received from the slice manager unit 82, for example.

[0059] In this embodiment, for example, the SDN controller 60 creates a communication path between NFs associated with a creation instruction for a communication path received from the slice manager unit 82. In addition, the SDN controller 60 changes the upper limit of the bandwidth of the communication path between NFs or recreates the communication path between NFs according to a change instruction received from the slice manager unit 82.

[0060] Here, the SDN controller 60 may use a segment routing technology (for example, SRv6 (segment routing IPv6)) to construct NSI and NSSI for aggregation routers and servers present on the communication paths. The SDN controller 60 may also generate NSI and NSSI across multiple target NFs by issuing a command to configure a common VLAN (Virtual Local Area Network) for multiple target NFs and a command to assign a bandwidth and priority indicated by configuration information to the VLAN.

[0061] The monitoring function unit 58 acquires monitoring information indicating the state of the network. The monitoring function unit 58 may acquire monitoring information indicating the state of each network slice. The monitoring information is, for example, metric data and alert notifications. The monitoring function unit 58 may acquire monitoring information for various levels, such as the NS level, the NF level, the CNFC level, and the hardware level of a server or the like.

[0062] The monitoring function unit 58 may acquire monitoring information from, for example, a module that outputs metric data. The module that outputs metric data may be set in hardware such as a server, or in a software element included in the communication system 1. The NF may be configured to output metric data indicating metrics measurable (identifiable) in the NF to the monitoring function unit 58. The server may be configured to output metric data indicating metrics related to hardware measurable (identifiable) in the server to the monitoring function unit 58.

[0063] Also, for example, the monitoring function unit 58 may acquire metric data from a sidecar container deployed on a server. The sidecar container aggregates metric data indicating metrics output from a plurality of containers for each CNFC (microservice). This sidecar container may include an agent called an exporter. The monitoring function unit 58 may repeatedly execute a process of acquiring metric data aggregated for each microservice from the sidecar container at a given monitoring interval by using a mechanism of a monitoring tool such as Prometheus that can monitor a container management tool such as Kubernetes.

[0064] The monitoring function unit 58 may acquire, as the metric data, a performance index value indicating the performance of the network and the time when the performance index value was acquired. For example, the monitoring function unit 58 may acquire, as the monitoring information, metric data indicating a performance index value for a performance index described in "TS 28.552, Management and orchestration; 5G performance measurements" or "TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)".

[0065] Then, for example, when the monitoring function unit 58 acquires the above-mentioned monitoring information, the monitoring function unit 58 may output the monitoring information to the AI / big data processing unit 56. The AI / big data processing unit 56 stores the output monitoring information in the big data storage unit 70.

[0066] In addition, elements such as network slices, NSs, NFs, CNFCs, and hardware such as servers included in the communication system 1 notify the monitoring function unit 58 of various alerts (for example, alerts triggered by the occurrence of some kind of abnormality in the hardware or software).

[0067] Then, when the monitoring function unit 58 obtains, for example, the above-mentioned alert notification as monitoring information, it outputs the notification to the AI / big data processing unit 56. The AI / big data processing unit 56 stores the monitoring information in the big data storage unit 70. The stored alert notification is used by the policy manager unit 80. The processing of the policy manager unit 80 will be described later.

[0068] The performance calculation unit 57 calculates a performance index value (e.g., a kind of KPI) based on the multiple metric data stored in the big data storage unit 70 and on the metrics indicated by these metric data. The performance calculation unit 57 may calculate a performance index value that is an overall evaluation of multiple types of metrics (e.g., a performance index value related to an end-to-end network slice) that cannot be calculated from a single metric data. The performance calculation unit 57 may output performance index data indicating the calculated performance index value to the AI / big data processing unit 56 and store the performance index value data in the big data storage unit 70. The performance index data is also a kind of monitoring information indicating the state of the network slice.

[0069] The performance calculation unit 57 may directly obtain the metric data from the monitoring function unit 58 and calculate the performance index value based on the metric data.

[0070] The AI / big data processing unit 56 accumulates monitoring information such as metric data, alert notifications, and performance index values, and also estimates the cause of abnormalities occurring in the network based on the accumulated monitoring information.

[0071] The big data storage unit 70 included in the AI ​​big data processing unit 56 stores monitoring information, including metric data and alerts acquired from hardware elements such as servers and software elements such as NFs, in association with the corresponding network slices and time. Past monitoring information is accumulated in the big data storage unit 70.

[0072] The normality determination unit 72 included in the AI ​​big data processing unit 56 includes a plurality of normality determination models 73 corresponding to the plurality of network slices, respectively. The normality determination unit 72 determines whether or not the state of a target network slice is normal by acquiring an output when input data including an index acquired from a target network slice is input to the normality determination model 73 corresponding to the target network slice. The plurality of normality determination models 73 may correspond one-to-one to the plurality of network slices.

[0073] The normality determination model 73 is trained by normality training data including a metric index acquired at a certain time during normality or during a certain period immediately preceding the time in the corresponding network slice, and information indicating a time period during which the index was acquired. The normality is a period during which no failure occurs. The normality index may include at least a part of data indicating the communication volume during a predetermined period, an index indicating the network performance during a predetermined period, a representative time during the predetermined period, a day of the week during the predetermined period, and a holiday flag indicating whether the predetermined period is a holiday or not. The normality determination model 73 may be an anomaly detection model based on a known unsupervised machine learning model capable of detecting outliers from data, such as k-nearest neighbors, density-based clustering, or isolation forest.

[0074] The normality determination model 73 receives input data including an index of a current or recent certain time in a certain network slice and information indicating a current time zone. The input data may be data selected from data stored in the big data storage unit 70 according to the network slice and the time. The normality determination model 73 outputs information indicating an estimation result of whether or not the state of the network is normal. For example, the normality determination model 73 may output information indicating normality for input data that is slightly different from any of the training data, and output information indicating an abnormality for input data that is significantly different from any of the training data.

[0075] The cause estimation unit 74 included in the AI ​​big data processing unit 56 includes a plurality of cause estimation models 75 corresponding to a plurality of groups, respectively. A plurality of network slices are classified into a plurality of groups. The cause estimation unit 74 may also include a plurality of cause estimation models 75 corresponding to a plurality of types of causes, respectively. The cause estimation model 75 is a machine learning model. The type of cause may be, for example, a type of event that triggers the discovery of an anomaly (hereinafter simply referred to as a trigger type). The cause estimation model 75 is trained by training data including input data including past monitoring information when an anomaly occurs in the network and ground truth data indicating the cause of the anomaly.

[0076] Each of the cause estimation models 75 is associated with a type of cause, and the cause estimation model 75 estimates which of the multiple causes included in the associated type of cause is the cause of the abnormality. The cause estimation model 75 is provided for each combination of group and type of cause, and may be learned using training data different from each other. In order to estimate a cause from the multiple cause estimation models 75 according to the type of cause, there are multiple model determination conditions that correspond to the multiple types of causes, respectively. The cause estimation model 75 to be used is determined by the model determination conditions. The model determination conditions can also be considered as conditions for selecting the one to be used from the multiple cause estimation models 75, and are therefore also called model selection conditions.

[0077] An instance of the cause estimation model 75 may be provided for each combination of a network instance and a type of cause. In this case, the instances of the cause estimation model 75 for a certain type of cause including multiple network slices belonging to the same group are of the same type learned using the same training data. The cause estimation model 75 does not need to be divided according to the type of cause, and may have internal parameters common to all network slices.

[0078] The cause estimation model 75 may be a model that estimates the cause of an anomaly that has occurred in a network from time-series information, such as a Transformer model. The input data input to the cause estimation model 75 may be representative indicators in each snapshot of the most recent three blocks (for example, 3 hours if the interval is 1 hour). The representative indicators may include at least some of the items included in the monitoring information, such as traffic, KPI trends, representative time, day of the week, and holiday flag. The learning dataset may include data of representative indicators in each snapshot of three consecutive blocks. The multiple indicators included in the learning input data for the cause estimation model 75 may be acquired from a log of monitoring information stored in the big data storage unit 70 for network slices belonging to a corresponding group.

[0079] For a certain type of cause, a combination of the normality determination model 73 and the cause estimation model 75 may be used. Also, for a certain type of cause, information combining the outputs of a plurality of cause estimation models 75 may be used to estimate the cause.

[0080] The API unit 76 included in the AI ​​& big data processing unit 56 provides an API called by the policy manager unit 80. In response to the API called by the policy manager unit 80, the API unit 76 acquires the inference result (output of the cause inference unit 74) of the cause of an abnormality occurring in the network by the cause inference unit 74, and further returns the output of a cause inference model 75 of the cause inference unit 74 to the caller.

[0081] The API unit 76 may provide different APIs depending on the type of cause (type of trigger) or different APIs depending on the network slice. The API unit 76 may simply obtain the type of cause and the network slice as parameters when calling the API, and return the output of the cause estimation model 75 according to the parameters.

[0082] In this embodiment, the policy manager unit 80 executes a predetermined determination process based on at least one of the above-mentioned metric data, the above-mentioned alert notification, the output of the above-mentioned cause estimation model 75, and the above-mentioned performance index value data, for example.

[0083] Then, the policy manager unit 80 executes an action according to the result of the judgment process. For example, the policy manager unit 80 transmits an instruction to the slice manager unit 82 to reinforce at least one of the communication path in the network slice and the NF in the core network system 34 or the like. Also, for example, the policy manager unit 80 transmits the contents of the abnormality that has occurred (for example, the detected anomaly and its estimated cause) to the ticket management unit 54. Also, for example, the policy manager unit 80 outputs an instruction to scale or replace an element to a life cycle management unit (not shown) according to the result of the judgment process.

[0084] In this embodiment, for example, the ticket management unit 54 generates a ticket indicating the contents to be notified to the administrator of the communication system 1. The ticket management unit 54 may generate a ticket indicating the contents of the abnormality (failure) that has occurred. The ticket management unit 54 may also generate a ticket indicating the values ​​of performance index data or metric data. The ticket management unit 54 may also generate a ticket indicating the result of the determination made by the policy manager unit 80.

[0085] Then, the ticket management unit 54 notifies the administrator of the communication system 1 of the generated ticket. The ticket management unit 54 may, for example, send an email with the generated ticket attached to the email address of the administrator of the communication system 1.

[0086] The following describes in more detail how to estimate the cause of an anomaly that occurs in the network and how to respond according to the cause in the communication system 1. The estimation and response processes are implemented by the policy manager unit 80 and the AI ​​& big data processing unit 56.

[0087] In this embodiment, the cause estimation model 75 used to estimate the cause is determined according to the type of cause (trigger type) and the group to which the target network slice belongs. The multiple model determination conditions are conditions for determining the cause estimation model 75 and correspond to the type of cause.

[0088] Fig. 7 is a flow diagram showing an overview of the processing of policy manager unit 80. The processing flow shown in Fig. 7 shows an overview of processing related to the function of policy manager unit 80, which is to obtain the cause of an abnormality that has occurred in the network and respond to that cause.

[0089] First, the policy manager unit 80 acquires monitoring information from the big data storage unit 70 (S101). Then, the policy manager unit 80 determines a calling method of the API unit 76 according to the model determination condition satisfied by the acquired monitoring information (S102). Then, the policy manager unit 80 acquires the output of the cause estimation model 75 according to the model determination condition via the API unit 76 by the calling method (S103). Input data including the monitoring information acquired from the big data storage unit 70 may be input to the cause estimation model 75. In S102, the policy manager unit 80 may determine whether the model determination condition is satisfied by using a part of the monitoring information. The monitoring information input to the cause estimation model 75 may include items different from the monitoring information used in S102.

[0090] The multiple model determination conditions include a first and a second model determination condition. The first model determination condition is a condition indicating an abnormality in traffic in the network slice (an abnormality in a performance index such as throughput). The second model determination condition is a condition indicating an abnormality related to the registration of a terminal. Details of the processing related to the first model determination condition and the second model determination condition will be described later with reference to FIG. 10 and FIG. 12.

[0091] The following describes the processing of the called API unit 76. Fig. 8 is a flow chart showing an example of the processing of the AI ​​and big data processing unit 56. Fig. 8 shows an example of the processing when the API unit 76 included in the AI ​​and big data processing unit 56 is called in S103.

[0092] The API unit 76 determines the cause estimation model 75 based on the type of API and the group to which the target network slice belongs (S201). Strictly speaking, the API unit 76 determines the type of cause estimation model 75 based on the group. The type of API is an example of an API calling method. In the example of this figure, the type of API corresponds to the type of cause and the type of event that triggers the discovery of an abnormality. An API may be provided for each combination of the type of cause and the network slice.

[0093] In determining the cause estimation model 75, the API unit 76 may determine an instance of the cause estimation model 75 corresponding to a combination of the type of the called API and the network slice. Since the type of the cause estimation model 75 corresponding to the instance of the cause estimation model 75 is determined according to the group, determining the instance of the cause estimation model 75 according to the network slice corresponds to determining the cause estimation model 75 according to the group. Note that the API unit 76 may determine a combination of two or more cause estimation models 75 from which output is to be obtained in S201.

[0094] When the cause estimation model 75 to be used is determined, the API unit 76 acquires the output when monitoring information indicating the network state for the network slice is input to the determined cause estimation model 75 (strictly speaking, its instance) (S202). Here, after the process of S201, the API unit 76 may sequentially acquire input data, input monitoring information as input data to the determined cause estimation model 75, and acquire the output of the cause estimation model 75. The API unit 76 may acquire current or most recent monitoring information to be input to the determined cause estimation model 75 from the big data storage unit 70 as input data.

[0095] On the other hand, monitoring information may be input as input data to any of the plurality of cause estimation models 75, regardless of the determination of the cause estimation model 75 by the API unit 76. In this case, current or most recent monitoring information may be periodically input as input data to the cause estimation model 75 from the big data storage unit 70. In this case, before the policy manager determines the model determination condition or the API unit 76 determines the cause estimation model 75, the monitoring information may be input to the cause estimation model 75. In this case, the API unit 76 may obtain the result of the cause estimation model that has already been output in S202, or may wait until the result for the latest input data is output if the result has not yet been output. Since the estimation of the cause estimation model 75 starts early, an abnormality can be dealt with earlier.

[0096] Then, the API unit 76 transmits the output of the determined cause estimation model 75 to the caller (S203).

[0097] Depending on the determined cause estimation model, the cause estimation model and the normality determination model may be combined. This will be described in detail later.

[0098] When the policy manager unit 80 receives an output from the API unit 76, it executes a corresponding process according to the output of the cause estimation model 75 (S104). This corresponding process resolves or suppresses an abnormality occurring in the network. For example, when the output of the cause estimation model 75 indicates a first label (in other words, the value of the output matches the value corresponding to the first label, is within the range corresponding to the first label, or the value of the item corresponding to the first label in the output exceeds a threshold), the policy manager unit 80 may reinforce the communication path between the CU 44 and the UPF 46, more specifically, increase the bandwidth of the communication path. When the output of the cause estimation model 75 indicates a second label, the communication path may be recreated. When the output of the cause estimation model 75 indicates a third label, the number of UPFs 46 involved in data communication may be increased (scaled out), and a communication path between the increased UPF 46 and the existing CU 44 may be added. Also, for example, when the output of the cause estimation model indicates a fourth label, the number of SMFs may be increased (scale out), when the output indicates a fifth label, the number of AMFs and SMFs may be increased, and when the output indicates a sixth label, restrictions may be placed on the connection of the UE. As the above-mentioned response process, the policy manager unit 80 may send a notification of the occurrence of a failure to the ticket management unit 54.

[0099] The processing in Fig. 7 does not have to be performed in this order in practice. For example, processing corresponding to S102 to S104 may be performed for each model determination condition. For example, a program may be stored in the storage unit 30b for each model determination condition, and the processor 30a that executes each program may determine whether or not the model determination condition included in the program is satisfied (corresponding to S102), call the API unit 76 according to the determination result (corresponding to S103), and execute a corresponding process according to the output of the cause analysis model (corresponding to S104).

[0100] The process will be described in more detail below for each model determination condition. Fig. 10 is a flow diagram showing an example of the process that the policy manager unit 80 handles using the cause estimation model 75. Fig. 10 describes in more detail the process corresponding to S102 to S104 in Fig. 7 when a performance-related condition is used as the model determination condition. The process shown in Fig. 10 is periodically and repeatedly executed.

[0101] In the process of FIG. 10, the policy manager unit 80 first determines whether the most recently acquired performance index value (for example, throughput) is less than a threshold value and whether the previously acquired performance index value is less than a threshold value (S301).

[0102] If the latest and previous performance index values ​​are equal to or greater than the threshold value in S301 (N in S301), the process in Fig. 10 ends. On the other hand, if the performance index values ​​are less than the threshold value (Y in S301), the policy manager unit 80 queries the cause estimation model 75 via API-A of the API unit 76 about the cause, and obtains the output of the cause estimation model 75 (S302). Here, the output of the cause estimation model 75 indicates one of a plurality of predetermined labels, or indicates that none of the labels apply.

[0103] The fact that the latest and previous performance index values ​​are less than the threshold is one type of model determination condition, because the cause inference models 75 called via API-A are limited, and therefore the condition for selecting API-A is also the condition for selecting the cause inference models 75.

[0104] When the acquired output indicates the label A1 (Y in S303), the policy manager unit 80 transmits an instruction to the SDN controller 60 to increase the bandwidth in the existing communication path between the UPF 46 and the RAN 32 (S304), and increases the bandwidth to the SDN controller 60. When the process of S304 is performed, the process shown in Fig. 10 ends.

[0105] If the acquired output indicates label A2 (Y in S305), the policy manager unit 80 transmits an instruction to the SDN controller 60 to re-create the communication path between the UPF 46 and the RAN 32 (S306), and the SDN controller 60 re-creates the communication path. When the process of S306 is completed, the process shown in Fig. 10 ends.

[0106] When the acquired output indicates label B (Y in S307), the policy manager unit 80 transmits an instruction to the configuration management unit 62 to scale out the UPF 46, and transmits an instruction to the SDN controller 60 to scale out the communication path between the UPF 46 and the RAN 32 (S308). The instruction to scale out the UPF 46 is an instruction to execute a process for enhancing the processing capacity of the UPF 46, and may be, for example, an instruction to add a UPF 46 to the target network slice. In addition, the upper limit of the CNF resources that the UPF 46 can use may be increased. The instruction to scale out the communication path is an instruction to execute a process for enhancing the communication between the added UPF 46 and the RAN 32, and may be, for example, an instruction to newly create a virtual communication path used for communication between the UPF 46 and the RAN 32. In addition, the bandwidth of the communication path used for communication between the UPF 46 and the RAN 32 may be increased. The configuration management unit 62 that has received the instruction adds the UPF 46, and the SDN controller 60 that has received the instruction creates a new communication path for the UPF 46. When the process of S308 is performed, the process shown in FIG.

[0107] The processes from S303 to S308 correspond to the process of responding in response to the output of the cause analysis model shown in S104 of Fig. 7. Note that, for example, if information indicating that the network status is determined to be normal is returned in the process of Fig. 11 described later, this process of responding may not be performed.

[0108] 8, a cause estimation model 75 is selected according to the type of the called API and the network slice, and the output of the selected cause estimation model 75 is returned to the policy manager unit 80. Here, the AI ​​& big data processing unit 56 including the API unit 76 may also use the determination result of the normality determination model 73 to estimate the cause.

[0109] Fig. 11 is a flow diagram showing another example of the processing of the AI ​​& big data processing unit 56. The example of Fig. 11 shows processing in the case where some of the multiple types of cause estimation models 75 are combined with a normality determination model 73 corresponding to a network slice for processing. It is assumed that normality determination information indicating whether or not each of the cause estimation models 75 is to be combined with the normality determination model 73 is stored in advance in the storage unit 30b.

[0110] First, the API unit 76 determines a cause estimation model 75 according to the type of the called API and the group to which the network slice belongs (S401).

[0111] Then, the API unit 76 determines whether or not to combine the determined cause estimation model 75 with the normal judgment model 73 (S402). This determination may be made based on normal judgment information stored by the API unit 76 in association with the determined cause estimation model 75. For example, the API unit 76 may combine the normal judgment model 73 with the cause estimation model 75 in the case of a trigger related to the traffic volume, such as the performance index value in Fig. 10, and may not use the normal judgment model 73 in the case of a trigger unrelated to the traffic volume.

[0112] If it is determined that the network slice is to be combined with the normal judgment model (Y in S402), the API unit 76 acquires the output of the normal judgment model 73 corresponding to the network slice (S403). If the acquired output indicates that the state of the network slice is not abnormal (N in S404), the API unit 76 transmits information indicating that no abnormality has occurred to the caller and ends the process. The output of the normal judgment model 73 may be binary information indicating whether the state of the network slice is normal or abnormal, or may be a value indicating the probability of abnormality. In the latter case, the state of the network slice may be determined to be normal or abnormal based on whether the output of the normal judgment model 73 exceeds a threshold value.

[0113] On the other hand, if the state of the network slice indicates an abnormality (Y in S404), the API unit 76 acquires the output of the determined cause estimation model 75 (S405). Then, the acquired output of the cause estimation model 75 is sent to the caller via the API (S406). The details of the processes of S405 and S406 are the same as those of S202 and S203 in FIG. 8.

[0114] In the judgment of S402, when it is judged that the normal judgment model is not to be combined (N of S402), the processing of S405 and the following are executed. In this case, the processing substantially performed is the same as that of FIG.

[0115] As shown in Figure 11, when the normality judgment model 73 judges that there is an abnormality in the state of the network slice and the output of the cause estimation model 75 is sent to the caller, the policy manager unit 80 executes processing corresponding to the abnormality only if the normality judgment model 73 judges that there is an abnormality in the network.

[0116] 8 and 11, different programs may be executed depending on the API. In this case, when an API is provided for each type of cause (or type of trigger), the API unit 76 may determine the type (and instance) of the cause estimation model 75 based on the network slice. When an API is provided for each combination of the type of cause (or type of trigger) and the network slice, the API unit 76 may acquire the output of the cause estimation model 75 identified by the called API without going through the processes of S201 and S401.

[0117] Next, an example of the processing of the policy manager unit 80 for a model determination condition different from that in Fig. 10 will be described. Fig. 12 is a flow diagram showing another example of the processing that the policy manager unit 80 handles using the cause estimation model 75. Fig. 12 describes in more detail the processing corresponding to S102 to S104 in Fig. 7 when an alert is issued from a specific NF (specifically, AMF, SMF) as a model determination condition. The processing shown in Fig. 12 is also periodically and repeatedly executed.

[0118] In the processing of FIG. 12, the policy manager unit 80 first determines whether the latest monitoring information indicates that an alert has been issued from the AMF or SMF, and whether the previous monitoring information also indicates that the same alert has been issued (S501).

[0119] If the latest and previous monitoring information do not both indicate that the same alert has been issued from the AMF or SMF (N in S501), the process of Fig. 12 ends. On the other hand, if the latest and previous monitoring information both indicate that the same alert has been issued from the AMF or SMF (Y in S501), the policy manager unit 80 queries the cause estimation model 75 via API-B of the API unit 76 about the cause, and obtains the output of the cause estimation model 75 (S502).

[0120] The fact that both the latest and previous monitoring information indicate that the same alert has been raised from the AMF or SMF is one type of model determination condition. Because API-B and the cause inference model 75 have a correspondence relationship, the condition for selecting API-B is also the condition for selecting the cause inference model 75.

[0121] If the acquired output indicates label C1 (Y in S503), the policy manager unit 80 transmits an instruction to the configuration management unit 62 to scale out the SMF (S504). When the process of S504 is completed, the process shown in FIG. 12 ends.

[0122] If the acquired output points to label C2 (Y in S505), the policy manager unit 80 sends an instruction to the configuration management unit 62 to scale out the AMF and SMF (S506). When the processing of S506 is performed, the processing shown in FIG. 12 ends.

[0123] If the acquired output indicates label D (Y in S507), the policy manager unit 80 transmits an instruction to the RAN 32 to restrict the connection of the UE 20 (S508). The restriction of the UE connection may be performed by a known method. For example, the RAN 32 that receives the instruction may reject a predetermined rate of connection requests from the UE 20. This makes it possible to reduce the number of connections of the UE 20 over time. The predetermined rate may be appropriately determined. After the processing of S508 is performed, the processing shown in FIG. 12 ends.

[0124] The processing from S503 to S508 corresponds to the processing of response according to the output of the cause estimation model 75 shown in S104 of FIG.

[0125] If the acquired monitoring information satisfies a predetermined response condition, a predetermined response process may be performed without using the output of the cause estimation model 75. Fig. 13 is a flow diagram showing an example of a response process performed by the policy manager unit 80 without using the cause estimation model 75. The process shown in Fig. 13 is used to respond to an abnormality whose cause can be relatively easily estimated.

[0126] 13, the policy manager unit 80 first determines whether or not both the latest and previously acquired CPU utilization rates of any server exceed a threshold value (S601). The CPU utilization rates of each of the multiple servers are included in the monitoring information.

[0127] For any server, if both the latest and the previously acquired CPU utilization rates do not exceed the threshold (N in S601), the process of FIG. 13 is terminated. On the other hand, if both the latest and the previously acquired CPU utilization rates for any server exceed the threshold (Y in S601), the policy manager unit 80 issues a warning ticket to the ticket management unit 54 (S602), and the ticket management unit 54 outputs a message based on the warning ticket to the administrator. The policy manager unit 80 also transmits an instruction to the configuration management unit 62 to scale out the corresponding server (S603). More specifically, the policy manager unit 80 transmits an instruction to the configuration management unit 62 to divide and allocate the functions deployed to the corresponding server to other new servers. In this way, when a predetermined response condition such as CPU utilization rate is met, a predetermined response such as issuing a warning ticket or scaling out the server may be executed.

[0128] The processes in S602 and S603 are also a type of process corresponding to the process for dealing with a network abnormality.

[0129] In this embodiment, the cause of an anomaly occurring in a network slice is estimated using a cause estimation model 75, which is a machine learning model. Generally, there are few cases in which an anomaly actually occurs in a network, and it is not easy to obtain a large amount of training data regarding the cause of the anomaly.

[0130] In this embodiment, a cause estimation model 75 is trained for each group of network slices. In addition, a response process is executed according to the output of the cause estimation model 75 corresponding to the group to which the network slice belongs. This allows an abnormality occurring in the network to be appropriately determined.

[0131] More specifically, compared to the case where learning is performed for each network slice, more training data on anomalies can be secured, improving the accuracy of estimation. In addition, if the cause estimation model 75 is common to all network slices, it is difficult to estimate the cause in cases where the anomaly that occurs varies depending on the network configuration. By using groups classified according to the network configuration, it becomes possible to estimate the cause according to the network configuration, and the estimation accuracy can be improved.

[0132] Furthermore, as shown in FIGS. 10 and 11, when the normality determination model 73 determines that there is an abnormality in the network, a response process is carried out in accordance with the result of the cause estimation by the cause estimation model 75.

[0133] As described above, while it is not easy to obtain a large amount of training data regarding the cause of anomalies, it is easy to secure training data when the state of a network slice is normal. Therefore, it is possible to improve the accuracy of estimating the cause of anomalies by precisely estimating in advance whether the state of the network slice is normal or not using the normality determination model 73, and then estimating the cause of the anomaly using the cause estimation model 75. In addition, it is possible to further improve accuracy by training the normality determination model 73 for each network slice.

[0134] In this embodiment, a plurality of cause estimation models 75 corresponding to the triggers at which an anomaly is detected are provided, and the cause estimation model 75 used to estimate the cause is specified according to the model determination condition corresponding to the trigger at which an anomaly is detected. This trigger corresponds to the type of cause of the anomaly. This makes it possible to efficiently limit the range of causes of anomalies that each cause estimation model 75 should estimate, thereby improving the accuracy of cause estimation.

[0135] The present disclosure is not limited to the above-described embodiment. The configurations disclosed in the embodiments can be combined in various ways. Furthermore, within the scope of the technical idea of ​​the present disclosure, a part of the configuration described in the present embodiment may be changed.

[0136] For example, the execution platform according to the present embodiment may be a Kubernetes cluster. Also, the execution platform according to the present embodiment may be a server.

[0137] In addition, the functional unit according to the present embodiment does not need to be a NF in 5G. For example, the functional unit according to the present embodiment may be a network node in 4G, such as an eNodeB, a vDU, a vCU, a P-GW (Packet Data Network Gateway), an S-GW (Serving Gateway), an MME (Mobility Management Entity), or an HSS (Home Subscriber Server).

[0138] Furthermore, the functional units according to the present embodiment may be realized using a hypervisor-type or host-type virtualization technology instead of a container-type virtualization technology. Furthermore, the functional units according to the present embodiment do not need to be implemented by software, and may be implemented by hardware such as an electronic circuit. Furthermore, the functional units according to the present embodiment may be implemented by a combination of an electronic circuit and software.

[0139] In the above embodiment, since the description is based on actual operation, it has been stated that the current network state is determined using a model trained based on past monitoring information and current or most recent monitoring information. However, the determined network state does not necessarily have to be the current state. In other words, the network state in the first time period may be determined using monitoring information obtained in a first time period and a model trained based on monitoring information obtained in a second time period different from the first time period.

[0140] As can be understood from the description of the embodiments described above, this specification discloses various technical ideas, including the following disclosures.

[0141] (1) A network system comprising one or more processors, wherein at least one of the one or more processors executes a cause inference process for acquiring an output when input data including an indicator obtained from a target network is inputted into a cause inference model corresponding to a group to which a target network belongs among the plurality of networks, the cause inference models respectively corresponding to a plurality of groups into which a plurality of networks are classified, the cause inference models being trained using input data including an indicator obtained for the corresponding group and training data including ground truth data indicating the cause of the anomaly; and a response process for executing a process to respond to an anomaly that has occurred in the target network based on the output of the cause inference model for the target network.

[0142] (2) In the network system according to (1), the plurality of networks are classified into the plurality of groups based on at least some of the information indicating the network configuration, characteristics related to communication volume, and network usage.

[0143] (3) In the network system according to (1) or (2), the input data included in the training data used to learn a cause inference model corresponding to a group including the target network includes indicators obtained from a plurality of networks belonging to a group including the target network.

[0144] (4) In any one of (1) to (3), the output of the cause estimation model includes information indicating whether or not the capacity of a virtualized processing unit that constitutes the target network is insufficient, and in the response processing, when the output of the cause estimation model indicates that the capacity of a predetermined type of virtualized processing unit is insufficient, the number of virtualized processing units of the predetermined type is increased.

[0145] (5) In any of (1) to (4), a normality judgment process is further executed to judge whether or not the state of the target network is normal by obtaining an output when an indicator obtained from a target network is input into a normality judgment model corresponding to the target network among a plurality of normality judgment models corresponding to the plurality of networks, and when it is determined that the state of the target network is not normal, the cause estimation process is executed, and the plurality of normality judgment models are trained based on the indicators in the corresponding network when normal and information indicating the time period when the indicators were acquired.

[0146] (6) In the network system according to (5), the indicators during normal times include at least some of the following: data indicating communication volume for a specified period of time, an indicator indicating network performance for a specified period of time, a representative time for the specified period of time, a day of the week for the specified period of time, and a holiday flag for the specified period of time.

[0147] (7) In any one of (1) to (6), the input data included in the training data includes at least a part of the rate of change of an index indicating the performance of the network, a representative time, a day of the week, and a holiday flag.

[0148] (8) A method for responding to a network anomaly, comprising: one or more processors; and at least one of the one or more processors acquires an output when input data including an indicator obtained from a target network is input into a cause estimation model corresponding to a group to which a target network belongs among the multiple networks, the cause estimation models being trained using input data including an indicator obtained for the corresponding group and training data including ground truth data indicating the cause of the anomaly; and performs processing to respond to an anomaly that has occurred in the target network based on the output of the cause estimation model for the target network.

Claims

1. The method includes the steps of: a cause inference process for acquiring an output when input data including an index acquired from a target network is input to a cause inference model corresponding to a group to which a target network belongs among the plurality of networks, the cause inference models being trained using input data including an index acquired for each corresponding group and training data including ground truth data indicating the cause of the anomaly; A response process for executing a process for responding to an abnormality occurring in the target network based on an output of the cause estimation model for the target network; The network system on which the

2. The plurality of networks are classified into the plurality of groups based on at least a part of information indicating a network configuration, characteristics related to communication volume, and network usage. The network system according to claim 1 .

3. input data included in training data used to learn a cause inference model corresponding to a group including the target network includes indices obtained from a plurality of networks belonging to a group including the target network; The network system according to claim 1 .

4. the output of the cause estimation model includes information indicating whether or not the capability of a virtualized processing unit constituting the target network is insufficient; In the response process, when an output of the cause estimation model indicates that a capacity of a virtualized processing unit of a predetermined type is insufficient, the number of virtualized processing units of the predetermined type is increased. The network system according to claim 1 .

5. by at least one of the one or more processors, a normality determination process is further executed to determine whether or not the state of the target network is normal by acquiring an output when an index acquired from the target network is input to a normality determination model corresponding to the target network among a plurality of normality determination models respectively corresponding to a plurality of networks; When it is determined that the state of the target network is not normal, the cause estimation process is executed; The plurality of normality determination models are trained based on indicators of normal times in the corresponding networks and information indicating time periods during which the indicators were acquired. The network system according to claim 1 .

6. the indicators in the normal state include at least a part of data indicating communication volume for a predetermined period, an indicator indicating network performance for a predetermined period, a representative time for a predetermined period, a day of the week for a predetermined period, and a holiday flag for a predetermined period; The network system according to claim 5.

7. The input data included in the training data includes at least a part of a change rate of an index indicating the performance of the network, a representative time, a day of the week, and a holiday flag. The network system according to claim 1 .

8. The method includes the steps of: a plurality of cause estimation models each corresponding to a plurality of groups into which a plurality of networks are classified, the plurality of cause estimation models being trained using input data including indicators acquired for the respective corresponding groups and training data including ground truth data indicating the cause of the anomaly, and an output is obtained when input data including an indicator acquired from a target network is input to a cause estimation model corresponding to a group to which a target network of the plurality of networks belongs; Executing a process for dealing with an anomaly occurring in the target network based on an output of the cause estimation model for the target network. How to respond to network anomalies.

Images