[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2023233470A1 - ネットワークの異常の原因推定 - Google Patents

ネットワークの異常の原因推定 Download PDF

Info

Publication number
WO2023233470A1
WO2023233470A1 PCT/JP2022/021958 JP2022021958W WO2023233470A1 WO 2023233470 A1 WO2023233470 A1 WO 2023233470A1 JP 2022021958 W JP2022021958 W JP 2022021958W WO 2023233470 A1 WO2023233470 A1 WO 2023233470A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
cause estimation
cause
estimation model
unit
Prior art date
Application number
PCT/JP2022/021958
Other languages
English (en)
French (fr)
Inventor
真也 北
Original Assignee
楽天モバイル株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天モバイル株式会社 filed Critical 楽天モバイル株式会社
Priority to US18/043,041 priority Critical patent/US20240283707A1/en
Priority to JP2024524531A priority patent/JPWO2023233470A1/ja
Priority to PCT/JP2022/021958 priority patent/WO2023233470A1/ja
Publication of WO2023233470A1 publication Critical patent/WO2023233470A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/064—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data

Definitions

  • the present disclosure relates to a network system and a method for dealing with network abnormalities.
  • communication networks have been provided by being divided into multiple networks (for example, multiple network slices) based on the type of target terminal or region. These multiple networks have different configurations and usage conditions depending on individual conditions.
  • the present disclosure has been made in view of the above circumstances, and one of its objectives is to provide a technology that makes it possible to appropriately determine abnormalities occurring in a network using a small number of machine learning models.
  • a network system includes one or more processors, and at least one of the one or more processors executes cause estimation processing and response processing.
  • a plurality of cause estimation models each corresponding to a plurality of groups into which a plurality of networks are classified are input data including indicators obtained for each corresponding group and correct data indicating the cause of the abnormality.
  • Get the output when In the response processing processing for responding to an abnormality occurring in the target network is executed based on the output of the cause estimation model for the target network.
  • the network abnormality response method includes one or more processors, and at least one of the one or more processors performs cause estimation processing and response processing.
  • a plurality of cause estimation models each corresponding to a plurality of groups into which a plurality of networks are classified are input data including indicators obtained for each corresponding group and correct data indicating the cause of the abnormality.
  • Get the output when In the response processing processing for responding to an abnormality occurring in the target network is executed based on the output of the cause estimation model for the target network.
  • FIG. 1 is a diagram illustrating an example of a communication system according to an embodiment of the present disclosure.
  • 1 is a diagram showing an example of a communication system according to the present embodiment.
  • FIG. 1 is a diagram schematically showing an example of a network service according to the present embodiment.
  • FIG. 2 is a diagram illustrating an example of association between elements constructed in the communication system according to the present embodiment.
  • FIG. 3 is a diagram illustrating an example of attributes of a network slice.
  • FIG. 2 is a functional block diagram showing an example of functions implemented in the platform system.
  • FIG. 2 is a flow diagram showing an overview of processing by a policy manager.
  • FIG. 2 is a flow diagram showing an example of processing by an AI/big data processing unit.
  • FIG. 3 is a diagram showing an example of correspondence between a cause estimation model, an API, and a group.
  • FIG. 3 is a flow diagram illustrating an example of processing performed by the policy manager using a cause estimation model. It is a flowchart which shows another example of processing of an AI/big data processing part.
  • FIG. 12 is a flow diagram showing another example of processing performed by the policy manager using a cause estimation model.
  • FIG. 7 is a flow diagram illustrating an example of processing performed by the policy manager without using a cause estimation model.
  • FIG. 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 data center group included in a communication system 1.
  • FIG. 2 is a diagram focusing on various computer systems implemented in a data center group included in the communication system 1.
  • the data center group included in the communication system 1 is classified into a central data center 10, a regional data center 12, and an edge data center 14.
  • central data centers 10 are distributed within the area covered by the communication system 1 (for example, within Japan).
  • regional data centers 12 are distributed within the area covered by the communication system 1. For example, if the area covered by the communication system 1 is the entire country of Japan, one to two regional data centers 12 may be placed in each prefecture.
  • each of the edge data centers 14 is capable of communicating with a communication facility 18 equipped with an antenna 16. As shown in FIG. 1, one edge data center 14 may be able to communicate with several communication facilities 18.
  • Communication equipment 18 may include a computer such as a server computer.
  • the communication equipment 18 according to the present embodiment performs wireless communication with a UE (User Equipment) 20 via the antenna 16.
  • the communication equipment 18 equipped with the antenna 16 is provided with, for example, an RU (Radio Unit), which will be described later.
  • a plurality of servers are arranged in each of the central data center 10, regional data center 12, and edge data center 14 according to this embodiment.
  • the central data center 10, the regional data center 12, and the edge data center 14 can communicate with each other.
  • the central data centers 10, the regional data centers 12, and the edge data centers 14 can also communicate with each other.
  • the communication system 1 includes a platform system 30, multiple radio access networks (RAN) 32, multiple core network systems 34, and multiple UEs 20.
  • the core network system 34, RAN 32, and UE 20 cooperate with each other to realize a mobile communication network.
  • the RAN 32 is an antenna that 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). It is a computer system equipped with 16.
  • the RAN 32 according to this embodiment is mainly implemented by a server group and communication equipment 18 located in the edge data center 14. Note that a part of the RAN 32 (for example, DU (Distributed Unit), CU (Central Unit), vDU (virtual Distributed Unit), vCU (virtual Central Unit)) is located not in the edge data center 14 but in the central data center 10 or regional It may also be implemented at data center 12.
  • DU Distributed Unit
  • CU Central Unit
  • vDU virtual Distributed Unit
  • vCU virtual Central Unit
  • the core network system 34 is a system equivalent to EPC (Evolved Packet Core) in 4G and 5G core (5GC) in 5G.
  • the core network system 34 according to this embodiment is mainly implemented by a group of servers located in the central data center 10 and the regional data center 12.
  • the platform system 30 is configured on a cloud infrastructure, for example, and includes one or more processors 30a, a storage section 30b, and a communication section 30c, as shown in FIG.
  • 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 ROM or RAM, a solid state drive (SSD), a hard disk drive (HDD), or the like.
  • the storage unit 30b stores programs and the like executed by the processor 30a.
  • the communication unit 30c is, for example, a communication interface such as a NIC (Network Interface Controller) or a wireless LAN (Local Area Network) module.
  • the communication unit 30c exchanges data with the RAN 32 and the core network system 34.
  • the communication unit 30c may constitute a part of SDN (Software-Defined Networking).
  • the platform system 30 is implemented by a group of servers located in the central data center 10. Note that the platform system 30 may be implemented by a group of servers located in the regional data center 12.
  • the processor 30a, the storage section 30b, and the communication section 30c may actually be included in the server.
  • the RAN 32 and the core network system 34 may include a processor 30a, a storage section 30b, and a communication section 30c.
  • the requested network service is constructed in the RAN 32 or the core network system 34.
  • the constructed network service is then provided to the purchaser.
  • network services such as voice communication services and data communication services are provided to purchasers who are MVNOs (Mobile Virtual Network Operators).
  • the voice communication service and data communication service provided by this embodiment are ultimately provided to the customer (end user) of the purchaser (MVNO in the above example) using the UE20 shown in FIGS. 1 and 2.
  • the end user can perform voice communication and data communication with other users via the RAN 32 and the core network system 34. Further, the end user's UE 20 can access a data network such as the Internet via the RAN 32 and the core network system 34.
  • IoT Internet of Things
  • end users who use robot arms, connected cars, and the like.
  • an end user who uses a robot arm, a connected car, or the like may become a purchaser of the network service according to this embodiment.
  • a container-type virtualization application execution environment such as Docker (registered trademark) is installed on the servers located in the central data center 10, regional data center 12, and edge data center 14. It is now possible to deploy and run containers on these servers.
  • a cluster composed of one or more containers generated by such virtualization technology may be constructed.
  • a Kubernetes cluster managed by a container management tool such as Kubernetes (registered trademark) may be constructed.
  • processors on the constructed cluster may execute container-type applications.
  • the network service in this embodiment is composed of one or more functional units (for example, a network function (NF)).
  • the functional unit is implemented as an NF realized by virtualization technology.
  • NF realized by virtualization technology is called VNF (Virtualized Network Function).
  • VNF Virtualized Network Function
  • CNF Containerized Network Function
  • container-type virtualization technology is also included in the VNF in this description.
  • the network service is implemented by one or more CNFs.
  • the functional unit according to this embodiment may correspond to a network node.
  • FIG. 3 is a diagram schematically showing an example of a network service in operation.
  • FIG. 3 shows an example of a configuration for an end-to-end network slice of one of the network services.
  • a network slice is a virtual division of a physical communication network.
  • the network services shown in FIG. 3 include multiple RUs 40, multiple DUs 42, multiple CUs 44, multiple UPFs (User Plane Functions) 46, one or more AMFs (Access and Mobility Management Functions), one or more SMFs ( NFs such as Session Management Function are included as software elements.
  • UPFs User Plane Functions
  • AMFs Access and Mobility Management Functions
  • SMFs SMFs
  • SDN 36 is implemented by equipment including dedicated network equipment and multiple servers.
  • a network route corresponds to a type of tunnel, and in the SDN 36, it is possible to set a new route or change the equipment that physically passes through an existing route through software settings.
  • a communication service in a certain area is provided by the network service shown in FIG.
  • the network service also includes other software elements, but the description of these elements will be omitted.
  • network services are implemented on computer resources (hardware elements) such as a plurality of servers.
  • FIG. 4 is a diagram schematically showing an example of the association between elements constructed in the communication system 1 in this embodiment.
  • the symbols M and N shown in FIG. 4 represent any integer greater than or equal to 1, and indicate the relationship between the numbers of elements connected by links. If both ends of a link are a combination of M and N, the elements connected by the link are in a many-to-many relationship, and if both ends of the link are a combination of 1 and N or a combination of 1 and M, the relevant Elements connected by links have a one-to-many relationship.
  • the network service (NS), network function (NF), CNFC (Containerized Network Function Component), pod, and container have a hierarchical structure.
  • An NS corresponds to, for example, a network service composed of multiple NFs.
  • the NS may correspond to a granular element such as 5GC, EPC, 5G RAN (gNB), 4G RAN (eNB), etc., for example.
  • NF corresponds to granular elements such as DU42, CU44, UPF46, etc. Further, NF corresponds to a granularity element such as AMF and SMF. Furthermore, in 4G, NF corresponds to granular elements such as MME (Mobility Management Entity), HSS (Home Subscriber Server), S-GW (Serving Gateway), vDU, and vCU.
  • MME Mobility Management Entity
  • HSS Home Subscriber Server
  • S-GW Serving Gateway
  • vDU Visitor Gateway
  • vCU vCU.
  • one NS includes one or more NFs. In other words, one or more NFs are under one NS.
  • CNFC corresponds to granular elements such as DU mgmt and DU Processing, for example.
  • a CNFC may be a microservice that is deployed on a server as one or more containers.
  • a certain CNFC may be a microservice that provides some of the functions of the DU 42, CU 44, etc.
  • a certain CNFC may be a microservice that provides some of the functions of the UPF 46, AMF, SMF, and the like.
  • one NF includes one or more CNFCs. That is, one or more CNFCs are under one NF.
  • a pod refers to the minimum unit for managing docker containers in Kubernetes.
  • one CNFC includes one or more pods.
  • one or more pods are under one CNFC.
  • one pod includes one or more containers.
  • one or more containers are under one pod.
  • the network slice (NSI) and network slice subnet instance (NSSI) have a hierarchical structure.
  • NSI can also be said to be an end-to-end virtual circuit that spans multiple domains (for example, from the RAN 32 to the core network system 34).
  • NSI is a slice for high-speed, large-capacity communication (for example, eMBB: enhanced Mobile Broadband), a slice for highly reliable and low-latency communication (for example, URLLC: for Ultra-Reliable and Low Latency Communications), or a high-volume terminal. (for example, for massive Machine Type Communication (mMTC)).
  • mMTC massive Machine Type Communication
  • NSSI can also be said to be a single domain virtual circuit that is divided from NSI.
  • the NSSI may be a slice of a RAN domain, a slice of a Mobile Back Haul (MBH) domain, or a slice of a core network domain.
  • MMH Mobile Back Haul
  • one NSI includes one or more NSSIs.
  • one or more NSSIs are under one NSI.
  • multiple NSIs may share the same NSSI.
  • NSSI and NS generally have a many-to-many relationship.
  • one NF can belong to one or more network slices.
  • one NF can be configured with NSSAI (Network Slice Selection Assistance Information) including one or more S-NSSAI (Sub Network Slice Selection Assist Information).
  • NSSAI Network Slice Selection Assistance Information
  • S-NSSAI Subscribe Network Slice Selection Assist Information
  • S-NSSAI is information associated with a network slice. Note that the NF does not need to belong to a network slice.
  • the plurality of network slices may differ from each other in target area, NF configuration, target UE 20 type, etc.
  • FIG. 5 is a diagram illustrating an example of attributes of a network slice.
  • slice ID, type, configuration, and group are shown as network slice attributes.
  • the slice ID is information that identifies a network slice.
  • the type indicates the type of network characteristics, and when it is blank, it indicates that the network has characteristics for communication with general UE 20, and in the case of IoT, it indicates that it has characteristics specialized for communication with IoT terminals.
  • the configuration indicates the number of NFs (AMF, SMF, UPF) that implement the network slice and the area covered.
  • Group indicates the group to which the network slice belongs.
  • a plurality of network slices are classified into a plurality of groups according to their types, configurations, and network usage characteristics (for example, usage characteristics centered on urban areas or usage characteristics centered on suburbs).
  • group classification the number of network routes determined from the numbers of AMFs, SMFs, and UPFs and the number of RANs, the type of the network routes, and the number of RANs (for example, gNBs) may also be used.
  • This classification may be performed using a so-called clustering technique.
  • One or more network slices belong to each of the plurality of groups.
  • the platform system 30 monitors each of a plurality of network slices, detects abnormalities that occur in them, and executes response processing according to the abnormalities. These processes will be explained in more detail below.
  • 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 the platform system 30 according to this embodiment does not need to implement all of the functions shown in FIG. 5, and functions other than those shown in FIG. 6 may be implemented.
  • the platform system 30 functionally includes an inventory database 50, an orchestration (E2EO: End-to-End-Orchestration) section 52, a ticket management section 54, an AI/BIG It includes a data processing section 56, a performance calculation section 57, a monitoring function section 58, an SDN controller 60, and a configuration management section 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 section 72 includes a plurality of normality determination models 73
  • the cause estimation section 74 includes a plurality of cause estimation models 75 . These elements are mainly implemented by the processor 30a, the storage section 30b, and the communication section 30c.
  • the functions and processes described in this embodiment are stored in one or more information processing devices (e.g., a server) equipped with a processor 30a, a storage unit 30b (e.g., memory), etc., in which software (program execution instructions) are recorded.
  • This storage medium may be a computer-readable, nonvolatile information storage medium such as, for example, an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory.
  • this software may be stored in an external storage device (for example, 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 circuit blocks, memories, or other integrated circuits. Further, those skilled in the art will easily understand that the functions shown in FIG. 6 can be realized in various forms such as only hardware, only software, or a combination thereof.
  • the inventory database 50 is a database that stores inventory information.
  • the inventory information includes, for example, information about servers placed in the RAN 32 or the core network system 34 and managed by the platform system 30.
  • the inventory database 50 stores inventory data.
  • the inventory data shows the configuration of the element groups included in the communication system 1 and the current status of the relationships between the elements (for example, topology data).
  • the elements include hardware elements and software elements.
  • Hardware elements include, for example, servers, racks, buildings, and network equipment.
  • Software elements include, for example, network slices, NFs, and running containers.
  • the inventory data also indicates the status of resources managed by the platform system 30 (for example, resource usage status).
  • the topology data indicating the current status of the association between elements includes, for example, the identifier of a certain NS and the identifiers of one or more NFs subordinate to the NS, and also includes, for example, the identifier of a certain network slice and the identifier of one or more NFs belonging to the network slice. and one or more NF identifiers.
  • the slice manager unit 82 instantiates a network slice by, for example, executing logic indicated by a slice template.
  • the slice manager unit 82 may output configuration management instructions related to instantiation of a network slice to the configuration management unit 62.
  • the configuration management unit 62 may then perform configuration management such as settings according to the configuration management instruction.
  • the slice manager unit 82 may output an instruction to the SDN controller 60 to create a communication path between NFs (between the CU 44, the UPF 46, and the AMF).
  • the SDN controller 60 may output a more specific communication path creation instruction to the SDN 36.
  • the specific communication path creation instruction includes the IP addresses of the two SRVs 6 as information specifying the CU 44 and the UPF 46 or AMF that communicate with each other.
  • the slice manager unit 82 executes a process of reinforcing at least one of the communication path in the network slice and the NF in the core network system 34 etc. in response to an instruction from the policy manager unit 80.
  • the slice manager unit 82 outputs a configuration management instruction to scale out any one of the UPF 46, AMF, and SMF associated with the network slice to the configuration management unit 62, and connects the scaled-out UPF 46 or AMF to the CU 44 of each RAN 32.
  • a creation instruction for creating a new communication path may be output to the SDN controller 60.
  • the slice manager unit 82 also changes 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 recreates the communication path (in other words, changes the communication path to be used).
  • the instructions may be output to the SDN controller 60.
  • the slice manager unit 82 includes, for example, NSMF (Network Slice Management Function) and NSSMF (Network Slice Sub-network Management Function) described in the 3GPP (Third Generation Partnership Project) (registered trademark) specification “TS28 533”. It consists of the following functions.
  • NSMF is a function that generates and manages network slices, and provides NSI management services.
  • NSSMF is a function that generates and manages a network slice subnet that forms part of a network slice, and provides NSSI management services.
  • the configuration management unit 62 executes configuration management such as setting of element groups such as NF in accordance with configuration management instructions received from the slice manager unit 82, for example.
  • the SDN controller 60 creates a communication path between NFs associated with the creation instruction, for example, in accordance with a communication path creation instruction received from the slice manager unit 82. Further, 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 the change instruction received from the slice manager unit 82.
  • the SDN controller 60 may use segment routing technology (for example, SRv6 (segment routing IPv6)) to construct NSI or NSSI for aggregation routers, servers, etc. that exist between communication paths.
  • segment routing technology for example, SRv6 (segment routing IPv6)
  • the SDN controller 60 issues a command to configure a common VLAN (Virtual Local Area Network) to multiple NFs to be configured, and a command to allocate the bandwidth and priority indicated by the configuration information to the VLAN. By doing so, it is possible to generate NSI and NSSI across the plurality of NFs to be configured.
  • 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 status of each network slice. Monitoring information is, for example, metric data and alert notifications. Note that the monitoring function unit 58 may acquire monitoring information at various levels, such as the NS level, NF level, CNFC level, and hardware level such as a server.
  • the monitoring function unit 58 may obtain monitoring information from a module that outputs metric data, for example.
  • a module that outputs metric data may be set in hardware such as a server or a software element included in the communication system 1.
  • the NF may be configured to output metric data indicating a measurable (identifiable) metric in the NF to the monitoring function unit 58.
  • the server may be configured to output metric data indicating metrics related to hardware that can be measured (specified) in the server to the monitoring function unit 58.
  • the monitoring function unit 58 may acquire metric data from a sidecar container deployed on the server.
  • the sidecar container aggregates metric data indicating metrics output from multiple containers in units of CNFC (microservices).
  • This sidecar container may contain agents called exporters.
  • the monitoring function unit 58 uses the mechanism of a monitoring tool such as Prometheus, which can monitor container management tools such as Kubanetes, to acquire metric data aggregated for each microservice from the sidecar container. It may be performed repeatedly at a given monitoring interval.
  • the monitoring function unit 58 may obtain, as metric data, a performance index value indicating the performance of the network and the time at which the performance index value was acquired. For example, the monitoring function unit 58 monitors performance indicators regarding the performance indicators listed 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)”. Metric data indicating the value may be acquired as monitoring information.
  • KPI Key Performance Indicators
  • 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.
  • elements such as a network slice, NS, NF, and CNFC included in the communication system 1 and hardware such as a server send notifications of various alerts to the monitoring function unit 58 (for example, any Alert notification triggered by the occurrence of an abnormality).
  • the monitoring function unit 58 acquires 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 section 80. The processing of the policy manager unit 80 will be described later.
  • the performance calculation unit 57 calculates a performance index value (for example, a type of KPI) based on the metrics indicated by these metric data.
  • the performance calculation unit 57 calculates a performance index value (for example, a performance index value related to an end-to-end network slice) that is a comprehensive evaluation of multiple types of metrics that cannot be calculated from a single metric data. good.
  • 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.
  • Performance index data is also a type of monitoring information that indicates the status of a network slice.
  • the performance calculation unit 57 may directly acquire metric data from the monitoring function unit 58 and calculate the performance index value based on the metric data.
  • the AI/big data processing unit 56 accumulates monitoring information such as metric data, alert notifications, and performance index values, and estimates the cause of abnormalities occurring in the network based on the accumulated monitoring information.
  • the big data storage unit 70 included in the AI/big data processing unit 56 stores monitoring information including metric data and alerts obtained from hardware such as servers and software elements such as NF into corresponding network slices and time. Stored in association with. Past monitoring information is accumulated in the big data storage unit 70.
  • the normality determination unit 72 included in the AI/big data processing unit 56 includes a plurality of normality determination models 73 each corresponding to a plurality of network slices.
  • the normality determination unit 72 determines the target network slice by acquiring the output when input data including the index acquired from the target network slice is input to the normality determination model 73 corresponding to the target network slice. Determine whether the state of is normal.
  • the plurality of normality determination models 73 may have one-to-one correspondence with the plurality of network slices.
  • the normality determination model 73 is normal training data that includes a metric index acquired at a certain time during normal operation or a certain period immediately before the corresponding network slice, and information indicating the time period in which the index was acquired. It has been learned by A normal period is a period in which no failure occurs.
  • the normal indicator is at least one of data indicating the amount of communication during the predetermined period, an index indicating the performance of the network during the predetermined period, a representative time of the predetermined period, a day of the week during the predetermined period, and a holiday flag indicating whether the predetermined period is a holiday. May include some.
  • 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 the k-nearest neighbor method, density-based clustering, or isolation forest.
  • the normality determination model 73 receives input data including an index of the current or most recent fixed time in a certain network slice and information indicating the 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 time.
  • the normality determination model 73 outputs information indicating the estimation result of whether the state of the network is normal or not. For example, the normality determination model 73 outputs information indicating normality for input data that has a small difference from any of the training data, and outputs information indicating abnormality for input data that has a large difference from any training data. You may do so.
  • the cause estimation unit 74 included in the AI/big data processing unit 56 includes a plurality of cause estimation models 75, each corresponding to a plurality of groups. Multiple network slices are classified into multiple groups. Further, the cause estimation unit 74 may include a plurality of cause estimation models 75 respectively corresponding to a plurality of cause types.
  • the cause estimation model 75 is a machine learning model.
  • the type of cause may be, for example, the type of event that triggers the discovery of an abnormality (hereinafter simply referred to as the trigger type).
  • the cause estimation model 75 is trained using input data including past monitoring information when an abnormality occurred in the network, and training data including correct data indicating the cause of the abnormality.
  • Each of the cause estimation models 75 is associated with a cause type, and the cause estimation model 75 determines which of the multiple causes included in the associated cause types is the cause of the abnormality. presume.
  • the cause estimation model 75 is provided for each combination of groups and cause types, and may be learned using different training data.
  • the cause estimation model 75 In order to estimate a cause from the plurality of cause estimation models 75 according to the cause type, there are a plurality of model determination conditions that correspond to the plurality of cause types and are different from each other. Based on this model determination condition, the cause estimation model 75 to be used is determined. Note that since it can also be said to be a condition for selecting one to be used from a plurality of cause estimation models 75, the model determination condition is also referred to as a model selection condition.
  • an instance of the cause estimation model 75 may be provided for each combination of a network instance and a cause type.
  • instances of the cause estimation model 75 for a certain cause type that include 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 common internal parameters for all network slices.
  • the cause estimation model 75 may be a model that estimates the cause of an abnormality occurring in the network from time-series information, such as a Transformer model, for example.
  • 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 typical 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 training data set may include representative index data in each snapshot of three consecutive blocks.
  • a plurality of indicators included in the input data for learning of the cause estimation model 75 may be obtained from a log of monitoring information stored in the big data storage unit 70 for network slices belonging to the corresponding group.
  • the normality determination model 73 and the cause estimation model 75 may be used in combination. Further, for a certain type of cause, information obtained by combining the outputs of a plurality of cause estimation models 75 may be used for estimating the cause.
  • the API unit 76 included in the AI/big data processing unit 56 provides an API called by the policy manager unit 80.
  • the API unit 76 acquires the result of estimating the cause of the abnormality occurring in the network by the cause estimating unit 74 (output of the cause estimating unit 74) in response to the API called by the policy manager unit 80, and further acquires the result of estimating the cause of the abnormality occurring in the network by the cause estimating unit 74,
  • the output of the cause estimation model 75 is returned to the caller.
  • the API unit 76 may provide different APIs depending on the type of cause (type of trigger), or may provide different APIs depending on the network slice.
  • the API unit 76 may simply obtain the cause type and network slice as parameters when calling the API, and return the output of the cause estimation model 75 according to the parameters.
  • the policy manager section 80 provides a predetermined information based on at least one of the above-mentioned metric data, the above-mentioned alert notification, the above-mentioned cause estimation model 75 output, and the above-mentioned performance index value data. Execute the determination process.
  • the policy manager section 80 executes an action according to the result of the determination process.
  • the policy manager unit 80 transmits an instruction to the slice manager unit 82 to strengthen at least one of the communication path in the network slice and the NF in the core network system 34 and the like.
  • the policy manager unit 80 transmits the details of the abnormality that has occurred (for example, the detected self-proclaimed name and its estimated cause) to the ticket management unit 54.
  • the policy manager section 80 outputs an instruction for scaling or replacing an element to a life cycle management section (not shown) according to the result of the determination process.
  • the ticket management unit 54 generates a ticket indicating the content to be notified to the administrator of the communication system 1, for example.
  • the ticket management unit 54 may generate a ticket indicating the details of the abnormality (failure) that has occurred. Further, the ticket management unit 54 may generate a ticket indicating the value of performance index value data or metric data. Further, the ticket management unit 54 may generate a ticket indicating the determination result by the policy manager unit 80.
  • 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 e-mail with the generated ticket attached to the e-mail address of the administrator of the communication system 1.
  • the cause estimation model 75 used for estimating the cause is determined according to the type of cause (type of trigger) and the group to which the target network slice belongs.
  • the plurality of model determination conditions are conditions for determining the cause estimation model 75, and correspond to the types of causes.
  • FIG. 7 is a flow diagram showing an overview of the processing of the policy manager unit 80.
  • the processing flow shown in FIG. 7 outlines the processing related to the functions of the policy manager unit 80 that acquire the cause of an abnormality occurring in the network and respond to the cause.
  • the policy manager unit 80 acquires monitoring information from the big data storage unit 70 (S101). Then, the policy manager unit 80 determines the method of calling the API unit 76 according to the model determination condition satisfied by the acquired monitoring information (S102). Then, the policy manager unit 80 uses the calling method to obtain the output of the cause estimation model 75 according to the model determination conditions via the API unit 76 (S103). Input data including 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 use part of the monitoring information to determine whether the model determination condition is satisfied. The monitoring information input to the cause estimation model 75 may include items different from the monitoring information used in S102.
  • the plurality of model determination conditions include first and second model determination conditions.
  • the first model determination condition is a condition indicating an abnormality in traffic (an abnormality in a performance index such as throughput) in a network slice.
  • the second model determination condition is a condition indicating an abnormality regarding terminal registration. Details of the processing regarding the first model determination condition and the second model determination condition will be described later using FIGS. 10 and 12.
  • FIG. 8 is a flow diagram showing an example of processing by the AI/big data processing unit 56.
  • FIG. 8 shows an example of processing when the API section 76 included in the AI/big data processing section 56 is called in S103.
  • 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 API type is an example of an API calling method. In the example shown in 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 cause type and network slice.
  • the API unit 76 may determine an instance of the cause estimation model 75 that corresponds to the combination of the called API type and the network slice. Since the type of the cause estimation model 75 according to the instance of the cause estimation model 75 is determined according to the group, the determination of the instance of the cause estimation model 75 according to the network slice is the same as the determination of the cause estimation model 75 according to the group. corresponds to Note that, in S201, the API unit 76 may determine a combination of two or more cause estimation models 75 whose output is to be obtained.
  • the API unit 76 determines the cause estimation model 75 (more specifically, its instance) when monitoring information indicating the network status for that network slice is input. Obtain the output (S202).
  • the API unit 76 sequentially acquires input data, inputs monitoring information as input data to the determined cause estimation model 75, and acquires the output of the cause estimation model 75. You can go.
  • the API unit 76 may obtain current or recent monitoring information to be input to the determined cause estimation model 75 from the big data storage unit 70 as input data.
  • monitoring information may be input as input data to any one of the plurality of cause estimation models 75, regardless of the determination of the cause estimation model 75 by the API section 76.
  • the current or most recent monitoring information may be periodically input to the cause estimation model 75 from the big data storage unit 70 as input data.
  • the monitoring information may be input to the cause estimation model 75 before the policy manager makes a determination regarding the model determination conditions or the API section 76 determines the cause estimation model 75.
  • the API unit 76 may obtain the results of the cause estimation model that have already been output, or if the results for the latest input data have not been output yet, wait until the results are output. You may. Since the estimation of the cause estimation model 75 is started early, it is possible to respond to the abnormality more quickly.
  • the API unit 76 transmits the output of the determined cause estimation model 75 to the caller (S203).
  • the policy manager unit 80 Upon receiving the output from the API unit 76, the policy manager unit 80 executes corresponding processing according to the output of the cause estimation model 75 (S104). This corresponding processing eliminates or suppresses the abnormality that occurs in the network. For example, if the output of the cause estimation model 75 indicates the 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 among the outputs exceeds the threshold), the policy manager unit 80 strengthens the communication path between the CU 44 and the UPF 46, more specifically, the policy manager unit 80 strengthens the communication path between the CU 44 and the UPF 46. Bandwidth may be increased.
  • the communication route may be recreated.
  • the number of UPFs 46 involved in data communication is increased (scaled out), and a communication path is added between the increased UPFs 46 and the existing CU 44. It's fine.
  • the number of SMFs is increased (scaled out)
  • the number of AMFs and SMFs is increased, If the label is indicated, restrictions may be placed on the UE's connection.
  • the policy manager unit 80 may send a notification of the occurrence of a failure to the ticket management unit 54.
  • the processing in FIG. 7 does not actually have to be performed in this order.
  • processes corresponding to S102 to S104 may be performed for each model determination condition.
  • a program is stored in the storage unit 30b for each model determination condition, and the processor 30a that executes each program determines whether or not the model determination condition included in the program is satisfied (corresponding to S102).
  • the API unit 76 may be called according to the result (corresponding to S103), and corresponding processing may be executed according to the output of the cause analysis model (corresponding to S104).
  • FIG. 10 is a flow diagram illustrating an example of the processing that the policy manager section 80 handles using the cause estimation model 75.
  • FIG. 10 shows in more detail the processing corresponding to S102 to S104 in FIG. 7 when performance-related conditions are used as model determination conditions. The process shown in FIG. 10 is repeatedly executed periodically.
  • the policy manager unit 80 first determines whether the latest acquired performance index value (for example, throughput) is less than a threshold value and the previously acquired performance index value is less than a threshold value (S301). .
  • the latest acquired performance index value for example, throughput
  • the policy manager unit 80 queries the cause estimation model 75 for the cause via the API-A of the API unit 76, and Obtain the output (S302).
  • the output of the cause estimation model 75 indicates one of a plurality of predetermined labels, or indicates that none of the labels apply.
  • the fact that the latest and previous performance index values are less than the threshold is a type of model determination condition. This is because the cause estimation model 75 that can be called via the API-A is limited, so the conditions for selecting the API-A are also the conditions for selecting the cause estimation model 75.
  • 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), causing the SDN controller 60 to increase its bandwidth. Further, when the process of S304 is performed, the process shown in FIG. 10 ends.
  • the policy manager unit 80 transmits an instruction to the SDN controller 60 to recreate the communication path between the UPF 46 and the RAN 32 (S306), and The communication path is recreated in the controller 60. Further, when the process of S306 is performed, the process shown in FIG. 10 ends.
  • the policy manager unit 80 transmits an instruction to the configuration management unit 62 to scale out the UPF 46, and instructs the SDN controller 60 to scale out the UPF 46 and RAN 32.
  • An instruction to scale out the communication path is transmitted (S308).
  • the instruction to scale out the UPF 46 is an instruction to execute processing for increasing the processing capacity of the UPF 46, and may be an instruction to add the UPF 46 to a target network slice, for example. Furthermore, the upper limit of CNF resources that can be used by the UPF 46 may be increased.
  • the instruction to scale out the communication path is an instruction to execute processing to enhance communication between the added UPF 46 and RAN 32.
  • the instruction to scale out the communication path is an instruction to execute processing to enhance communication between the added UPF 46 and RAN 32. It may also be an instruction to have someone create it. Furthermore, 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 received the instruction adds the UPF 46, and the SDN controller 60 that received the instruction creates a new communication path. Further, when the process of S308 is performed, the process shown in FIG. 10 ends.
  • the processing from S303 to S308 corresponds to the corresponding processing according to the output of the cause analysis model shown in S104 of FIG. Note that, for example, if information indicating that the state of the network is determined to be normal is returned in the process of FIG. 11, which will be described later, this corresponding process does not need to be performed.
  • the cause estimation model 75 is selected according to the type of the called API and the network slice through the process shown in FIG. 8, and the selected cause estimation model 75 is output. is returned to the policy manager section 80.
  • 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.
  • FIG. 11 is a flow diagram showing another example of the processing of the AI/big data processing unit 56.
  • the example in FIG. 11 shows a process in which some of the plurality of types of cause estimation models 75 are combined with a normality determination model 73 corresponding to a network slice. It is assumed that normality determination information indicating whether or not to combine with the normality determination model 73 is stored in advance in the storage unit 30b for each of the cause estimation models 75.
  • the API unit 76 determines the cause estimation model 75 according to the type of the called API and the group to which the network slice belongs (S401).
  • the API unit 76 determines whether the determined cause estimation model 75 is to be combined with the normality determination model 73 (S402). This determination may be made by the API unit 76 based on normality determination information stored in association with the determined cause estimation model 75. For example, the API unit 76 combines the normality determination model 73 and the cause estimation model 75 in the case of a trigger related to traffic volume, such as the performance index value in FIG. 10, and in the case of a trigger unrelated to traffic volume. It is not necessary to use the normality determination model 73 in this case.
  • the API unit 76 acquires the output of the normality determination model 73 corresponding to the corresponding network slice (S403). Further, if the obtained output of the API section 76 indicates that the state of the network slice is not abnormal (N in S404), the API section 76 transmits information indicating that no abnormality has occurred to the caller. Finish the process.
  • the output of the normality determination 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 that the network slice is abnormal. In the latter case, it may be determined whether the state of the network slice is normal or abnormal based on whether the output of the normality determination model 73 exceeds a threshold value.
  • the API unit 76 acquires the output of the determined cause estimation model 75 (S405). Then, the output of the acquired cause estimation model 75 is sent to the caller via the API (S406).
  • the details of the processing in S405 and S406 are the same as the processing in S202 and S203 in FIG.
  • the policy manager unit 80 determines that the network slice is abnormal. Only when it is determined by the model 73 that there is an abnormality in the network, processing corresponding to the abnormality is executed.
  • the API unit 76 may determine the type (and instance) of the cause estimation model 75 based on the network slice. If an API is provided for each combination of cause type (or trigger type) and network slice, the API unit 76 uses the cause specified by the called API without going through the processes of S201 and S401. The output of the estimation model 75 may be obtained.
  • FIG. 12 is a flow diagram showing another example of the processing that the policy manager section 80 handles using the cause estimation model 75.
  • FIG. 12 shows in more detail the processing corresponding to S102 to S104 in FIG. 7 when an alert is raised from a specific NF (specifically, AMF, SMF) as a model determination condition.
  • NF specifically, AMF, SMF
  • the process shown in FIG. 12 is also periodically and repeatedly executed.
  • the policy manager unit 80 first determines whether the latest monitoring information indicates that an alert from AMF or SMF has been raised, and whether the previous monitoring information also indicates that the same alert has been raised. (S501).
  • the policy manager unit 80 transmits an instruction to scale out the SMF to the configuration management unit 62 (S504). Further, when the process of S504 is performed, the process shown in FIG. 12 ends.
  • the policy manager unit 80 transmits an instruction to scale out AMF and SMF to the configuration management unit 62 (S506). Further, when the process of S506 is performed, the process shown in FIG. 12 ends.
  • the policy manager unit 80 transmits an instruction to limit the connection of the UE 20 to the RAN 32 (S508). Restriction of UE connections may be performed using a known method. For example, the RAN 32 that has received the instruction may reject connection requests from the UE 20 at a predetermined rate. Thereby, the number of connected UEs 20 can be reduced over time. Note that the predetermined ratio may be determined as appropriate. Further, when the process of S508 is performed, the process shown in FIG. 12 ends.
  • FIG. 13 is a flow diagram illustrating an example of processing that the policy manager unit 80 handles without using the cause estimation model 75. The process shown in FIG. 13 is used to deal with abnormalities whose causes are relatively easy to estimate.
  • the policy manager unit 80 first determines whether both the latest and previously acquired CPU usage rates of any of the servers exceed a threshold (S601).
  • the CPU usage rate of each of the plurality of servers is included in the monitoring information.
  • the policy manager unit 80 issues a warning ticket to the ticket management unit 54 ( S602), 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 scale out the corresponding server to the configuration management unit 62 (S603). More specifically, the policy manager section 80 transmits an instruction to the configuration management section 62 to divide the functions deployed in the corresponding server from other new servers and arrange them. In this way, when a predetermined response condition such as the CPU usage rate is satisfied, a predetermined response such as issuing a warning ticket or scaling out the server may be executed.
  • the processes in S602 and S603 are also a type of process that corresponds to network abnormalities.
  • a cause estimation model 75 which is a machine learning model, is used to estimate the cause of an abnormality that occurs in a network slice.
  • a cause estimation model 75 which is a machine learning model, is used to estimate the cause of an abnormality that occurs in a network slice.
  • the cause estimation model 75 is trained for each group of network slices. Corresponding processing is also executed according to the output of the cause estimation model 75 according to the group to which the network slice belongs. These allow appropriate determination of abnormalities occurring in the network.
  • the cause estimation model 75 is made common to all network slices, it is difficult to estimate the cause in cases where the abnormality that occurs differs depending on the network configuration. By using groups classified according to the network configuration, it is possible to estimate the cause according to the network configuration, and the estimation accuracy can be improved.
  • a plurality of cause estimation models 75 are provided, each corresponding to a trigger for detecting an abnormality, and the cause estimation model 75 used for estimating the cause is based on model determination conditions corresponding to the trigger for detecting an abnormality. are specified accordingly.
  • This trigger corresponds to the type of cause of the abnormality.
  • the execution platform according to this embodiment may be a Kubernetes cluster.
  • the execution platform according to this embodiment may be a server.
  • the functional unit according to this embodiment does not need to be an NF in 5G.
  • the functional units according to this embodiment include eNodeB, vDU, vCU, P-GW (Packet Data Network Gateway), S-GW (Serving Gateway), MME (Mobility Management Entity), HSS (Home Subscriber Server), etc. , it may be a network node in 4G.
  • the functional unit according to this embodiment may be realized using hypervisor-type or host-type virtualization technology instead of container-type virtualization technology. Further, the functional unit according to this embodiment does not need to be implemented by software, and may be implemented by hardware such as an electronic circuit. Further, the functional unit according to this embodiment may be implemented by a combination of an electronic circuit and software.
  • the current network status is determined using a model learned based on past monitoring information and current or recent monitoring information.
  • the determined network state does not necessarily have to be the current state. That is, by using the monitoring information obtained during the first time period and the model learned based on the monitoring information obtained during the second time period different from the first time period, The state of the network in the zone may also be determined.
  • a plurality of cause estimation models comprising one or more processors, each corresponding to a plurality of groups into which a plurality of networks have been classified by at least one of the one or more processors, the models each corresponding to a plurality of groups;
  • a cause estimation process that obtains an output when input data including indicators obtained from the target network is input; and an abnormality that has occurred in the target network based on the output of the cause estimation model for the target network.
  • the input data included in the training data used for learning the cause estimation model corresponding to the group including the target network is obtained from multiple networks belonging to the group including the target network.
  • the output of the cause estimation model includes information indicating whether or not the capacity of the virtualized processing unit configuring the target network is insufficient; In the corresponding 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 determined. Increase, network system.
  • the index obtained from the target network is input into the normality determination model corresponding to the target network among the plurality of normality determination models respectively corresponding to the plurality of networks.
  • a normality determination process is further executed to determine whether or not the state of the target network is normal by obtaining the output during the process, and when it is determined that the state of the target network is not normal, the cause estimation process is performed. is executed, and the plurality of normality determination models are learned based on a normality indicator in a corresponding network and information indicating a time period in which the indicator was acquired.
  • the normal indicators include 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.
  • a network system that includes at least a portion of.
  • the input data included in the training data includes at least a portion of a change rate of an index indicating network performance, a representative time, a day of the week, and a holiday flag. network system.
  • a plurality of cause estimation models comprising one or more processors, each of which corresponds to a plurality of groups into which a plurality of networks are classified by at least one of the one or more processors;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ネットワークに生じる異常を適切に判定する。ネットワークシステムは、複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得し（Ｓ１０３）、前記対象ネットワークについての前記異常原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する（Ｓ１０４）。

Description

ネットワークの異常の原因推定
　本開示は、ネットワークシステムおよびネットワーク異常の対応方法に関する。
　近年では、通信ネットワークは、対象となる端末の種類または地域などに基づいて、複数のネットワーク（例えば複数のネットワークスライス）に分割されて提供されている。この複数のネットワークでは、互いに、個別的な条件によりその構成や利用状況が異なっている。
特開２０２０－５３６４３４号公報
　これらのネットワークを効率的に監視するために、機械学習モデルを用いてそれらのネットワークに生じた異常を分析することが考えられる。
　一方、ネットワークの構成や利用状況といった背景は、個別的に異なっている。ネットワークに生じる異常はその個別的な背景に依存して異常が発生する一方で、ネットワークごとに機械学習モデルを学習させることは容易でなかった。
　本開示は上記実情に鑑みてなされたものであって、その目的の一つは、少数の機械学習モデルでネットワークに生じる異常を適切に判定することを可能にする技術を提供することにある。
　上記課題を解決するために、本開示にかかるネットワークシステムは、１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、原因推定処理、対応処理が実行される。前記原因推定処理では、複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得する。前記対応処理では、前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する。
　また、本開示にかかるネットワークの異常の対応方法は、１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、原因推定処理および対応処理が行われる。前記原因推定処理では、複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得する。前記対応処理では、前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する。
本開示の実施形態にかかる通信システムの一例を示す図である。 本実施形態にかかる通信システムの一例を示す図である。 本実施形態にかかるネットワークサービスの一例を模式的に示す図である。 本実施形態にかかる通信システムに構築される要素間の関連付けの一例を示す図である。 ネットワークスライスの属性の一例を示す図である。 プラットフォームシステムに実装される機能の一例を示す機能ブロック図である。 ポリシーマネージャの処理の概要を示すフロー図である。 ＡＩ・ビッグデータ処理部の処理の一例を示すフロー図である。 原因推定モデルとＡＰＩおよびグループとの対応の一例を示す図である。 ポリシーマネージャ部が原因推定モデルを用いて対応する処理の一例を示すフロー図である。 ＡＩ・ビッグデータ処理部の処理の他の一例を示すフロー図である。 ポリシーマネージャ部が原因推定モデルを用いて対応する処理の他の一例を示すフロー図である。 ポリシーマネージャ部が原因推定モデルを用いずに対応する処理の一例を示すフロー図である。
　以下、本開示における実施形態について図面に基づき詳細に説明する。
　図１および図２は、本開示の実施形態に係る通信システム１の一例を示す図である。図１は、通信システム１に含まれるデータセンタ群のロケーションに着目した図となっている。図２は、通信システム１に含まれるデータセンタ群で実装されている各種のコンピュータシステムに着目した図となっている。
　図１に示すように、通信システム１に含まれるデータセンタ群は、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４に分類される。
　セントラルデータセンタ１０は、例えば、通信システム１がカバーするエリア内（例えば、日本国内）に分散して数個配置されている。
　リージョナルデータセンタ１２は、例えば、通信システム１がカバーするエリア内に分散して数十個配置されている。例えば、通信システム１がカバーするエリアが日本国内全域である場合に、リージョナルデータセンタ１２が、各都道府県に１から２個ずつ配置されてもよい。
　エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（User Equipment）２０との間で無線通信を行う。アンテナ１６を備えた通信設備１８には、例えば、後述のＲＵ（Radio Unit）が設けられている。
　本実施形態に係るセントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４には、それぞれ、複数のサーバが配置されている。
　本実施形態では例えば、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４は、互いに通信可能となっている。また、セントラルデータセンタ１０同士、リージョナルデータセンタ１２同士、エッジデータセンタ１４同士も互いに通信可能になっている。
　図２に示すように、本実施形態に係る通信システム１には、プラットフォームシステム３０、複数の無線アクセスネットワーク（ＲＡＮ）３２、複数のコアネットワークシステム３４、複数のＵＥ２０が含まれている。コアネットワークシステム３４、ＲＡＮ３２、ＵＥ２０は、互いに連携して、移動通信ネットワークを実現する。
　ＲＡＮ３２は、第４世代移動通信システム（以下、４Ｇと呼ぶ。）におけるｅＮＢ（ｅＮｏｄｅＢ）や、第５世代移動通信システム（以下、５Ｇと呼ぶ。）におけるｇＮＢ（ＮＲ基地局）に相当する、アンテナ１６を備えたコンピュータシステムである。本実施形態に係るＲＡＮ３２は、主に、エッジデータセンタ１４に配置されているサーバ群および通信設備１８によって実装される。なお、ＲＡＮ３２の一部（例えば、ＤＵ（Distributed Unit）、ＣＵ（Central Unit）、ｖＤＵ（virtual Distributed Unit）、ｖＣＵ（virtual Central Unit））は、エッジデータセンタ１４ではなく、セントラルデータセンタ１０やリージョナルデータセンタ１２で実装されてもよい。
　コアネットワークシステム３４は、４ＧにおけるＥＰＣ（Evolved Packet Core）や、５Ｇにおける５Ｇコア（５ＧＣ）に相当するシステムである。本実施形態に係るコアネットワークシステム３４は、主に、セントラルデータセンタ１０やリージョナルデータセンタ１２に配置されているサーバ群によって実装される。
　本実施形態に係るプラットフォームシステム３０は、例えば、クラウド基盤上に構成されており、図２に示すように、１または複数のプロセッサ３０ａ、記憶部３０ｂ、通信部３０ｃ、が含まれる。プロセッサ３０ａは、プラットフォームシステム３０にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。記憶部３０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）、ハードディスクドライブ（ＨＤＤ）などである。記憶部３０ｂには、プロセッサ３０ａによって実行されるプログラムなどが記憶される。通信部３０ｃは、例えば、ＮＩＣ（Network Interface Controller）や無線ＬＡＮ（Local Area Network）モジュールなどといった通信インタフェースである。通信部３０ｃは、ＲＡＮ３２、コアネットワークシステム３４、との間でデータを授受する。通信部３０ｃは、ＳＤＮ（Software-Defined Networking）の一部を構成してもよい。
　本実施形態では、プラットフォームシステム３０は、セントラルデータセンタ１０に配置されているサーバ群によって実装されている。なお、プラットフォームシステム３０が、リージョナルデータセンタ１２に配置されているサーバ群によって実装されていてもよい。プロセッサ３０ａ、記憶部３０ｂ、通信部３０ｃは、実際にはサーバに含まれるものであってもよい。ＲＡＮ３２およびコアネットワークシステム３４は、プラットフォームシステム３０と同様にプロセッサ３０ａ、記憶部３０ｂ、通信部３０ｃを含んでよい。
　本実施形態では例えば、購入者によるネットワークサービス（ＮＳ）の購入要求に応じて、購入要求がされたネットワークサービスがＲＡＮ３２やコアネットワークシステム３４に構築される。そして、構築されたネットワークサービスが購入者に提供される。
　例えば、ＭＶＮＯ（Mobile Virtual Network Operator）である購入者に、音声通信サービスやデータ通信サービス等のネットワークサービスが提供される。本実施形態によって提供される音声通信サービスやデータ通信サービスは、図１および図２に示すＵＥ２０を利用する、購入者（上述の例ではＭＶＮＯ）にとっての顧客（エンドユーザ）に対して最終的に提供されることとなる。当該エンドユーザは、ＲＡＮ３２やコアネットワークシステム３４を介して他のユーザとの間で音声通信やデータ通信を行うことが可能である。また、当該エンドユーザのＵＥ２０は、ＲＡＮ３２やコアネットワークシステム３４を介してインターネット等のデータネットワークにアクセスできるようになっている。
　また、本実施形態において、ロボットアームやコネクテッドカーなどを利用するエンドユーザに対して、ＩｏＴ（Internet of Things）サービスが提供されてよい。そして、この場合において、例えば、ロボットアームやコネクテッドカーなどを利用するエンドユーザが本実施形態に係るネットワークサービスの購入者となってもよい。
　本実施形態では、セントラルデータセンタ１０、リージョナルデータセンタ１２、および、エッジデータセンタ１４に配置されているサーバには、ドッカー（Ｄｏｃｋｅｒ（登録商標））などのコンテナ型の仮想化アプリケーション実行環境がインストールされており、これらのサーバにコンテナをデプロイして稼働させることができるようになっている。これらのサーバにおいて、このような仮想化技術によって生成される１以上のコンテナから構成されるクラスタが構築されてもよい。例えば、クバネテス（Ｋｕｂｅｒｎｅｔｅｓ（登録商標））等のコンテナ管理ツールによって管理されるクバネテスクラスタが構築されていてもよい。そして、構築されたクラスタ上のプロセッサがコンテナ型のアプリケーションを実行してもよい。
　そして本実施形態におけるネットワークサービスは、１または複数の機能ユニット（例えば、ネットワークファンクション（ＮＦ））から構成される。本実施形態では、当該機能ユニットは、仮想化技術によって実現されたＮＦで実装される。仮想化技術によって実現されたＮＦは、ＶＮＦ（Virtualized Network Function）と称される。なお、どのような仮想化技術によって仮想化されたかは問わない。例えば、コンテナ型の仮想化技術によって実現されたＣＮＦ（Containerized Network Function）も、本説明においてＶＮＦに含まれる。本実施形態では、ネットワークサービスが１または複数のＣＮＦによって実装されるものとして説明する。また、本実施形態に係る機能ユニットは、ネットワークノードに相当するものであってもよい。
　図３は、稼働中のネットワークサービスの一例を模式的に示す図である。図３は、ネットワークサービスのうちの１つの、エンド・ツー・エンドのネットワークスライスに関する構成の一例を示している。ネットワークスライスは、物理的な通信ネットワークが仮想的に分割されたものである。
　図３に示すネットワークサービスには、複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ４４、複数のＵＰＦ（User Plane Function）４６、１または複数のＡＭＦ（Access and Mobility Management Function）、１または複数のＳＭＦ（Session Management Function）といったなどのＮＦがソフトウェア要素として含まれている。
　また、ＣＵ４４とＡＭＦおよびＵＰＦとの間は、それぞれＳＤＮ３６によりネットワークの経路が設けられる。ＳＤＮ３６は、専用のネットワーク機器および複数のサーバを含む機器により実装されている。ネットワークの経路は一種のトンネルに相当し、ＳＤＮ３６ではソフトウェア的な設定により、新たな経路を設定することや既存の経路において物理的に経由する機器を変更することが可能である。
　そして、本実施形態では例えば、図３に示すネットワークサービスによって、あるエリアにおける通信サービスが提供される。なお、当該ネットワークサービスには、他のソフトウェア要素も含まれるが、これらの要素については記載を省略する。また、ネットワークサービスは、複数のサーバ等のコンピュータリソース（ハードウェア要素）上に実装されている。
　図４は、本実施形態において通信システム１に構築される要素間の関連付けの一例を模式的に示す図である。なお、図４に示された記号ＭおよびＮは１以上の任意の整数を表し、リンクで接続された要素同士の個数の関係を示す。リンクの両端がＭとＮの組み合わせの場合は、当該リンクで接続された要素同士は多対多の関係であり、リンクの両端が１とＮの組み合わせまたは１とＭの組み合わせの場合は、当該リンクで接続された要素同士は１対多の関係である。
　図４に示すように、ネットワークサービス（ＮＳ）、ネットワークファンクション（ＮＦ）、ＣＮＦＣ（Containerized Network Function Component）、ｐｏｄ、および、コンテナは、階層構成となっている。
　ＮＳは、例えば、複数のＮＦから構成されるネットワークサービスに相当する。ここで、ＮＳが、例えば、５ＧＣ、ＥＰＣ、５ＧのＲＡＮ（ｇＮＢ）、４ＧのＲＡＮ（ｅＮＢ）、などの粒度の要素に相当するものであってもよい。
　ＮＦは、５Ｇでは、例えば、ＤＵ４２、ＣＵ４４、ＵＰＦ４６、などの粒度の要素に相当する。また、ＮＦは、ＡＭＦ、ＳＭＦなどの粒度の要素に相当する。また、ＮＦは、４Ｇでは、例えば、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、Ｓ－ＧＷ（Serving Gateway）、ｖＤＵ、ｖＣＵなどの粒度の要素に相当する。本実施形態では例えば、１つのＮＳには、１または複数のＮＦが含まれる。すなわち、１または複数のＮＦが、１つのＮＳの配下にあることとなる。
　ＣＮＦＣは、例えば、ＤＵ　ｍｇｍｔやＤＵ　Ｐｒｏｃｅｓｓｉｎｇなどの粒度の要素に相当する。ＣＮＦＣは、１つ以上のコンテナとしてサーバにデプロイされるマイクロサービスであってもよい。例えば、あるＣＮＦＣは、ＤＵ４２、ＣＵ４４等の機能のうち一部の機能を提供するマイクロサービスであってもよい。また、あるＣＮＦＣは、ＵＰＦ４６、ＡＭＦ、ＳＭＦ等の機能のうちの一部の機能を提供するマイクロサービスであってもよい。本実施形態では例えば、１つのＮＦには、１または複数のＣＮＦＣが含まれる。すなわち、１または複数のＣＮＦＣが、１つのＮＦの配下にあることとなる。
　ｐｏｄは、例えば、クバネテスでドッカーコンテナを管理するための最小単位を指す。本実施形態では例えば、１つのＣＮＦＣには、１または複数のｐｏｄが含まれる。すなわち、１または複数のｐｏｄが、１つのＣＮＦＣの配下にあることとなる。
　そして、本実施形態では例えば、１つのｐｏｄには、１または複数のコンテナが含まれる。すなわち、１または複数のコンテナが、１つのｐｏｄの配下にあることとなる。
　また、図４に示すように、ネットワークスライス（ＮＳＩ）とネットワークスライスサブネットインスタンス（ＮＳＳＩ）とは階層構成となっている。
　ＮＳＩは、複数ドメイン（例えばＲＡＮ３２からコアネットワークシステム３４）に跨るエンド・ツー・エンドの仮想回線とも言える。ＮＳＩは、高速大容量通信用のスライス（例えば、ｅＭＢＢ：enhanced Mobile Broadband用）、高信頼度かつ低遅延通信用のスライス（例えば、ＵＲＬＬＣ:Ultra-Reliable and Low Latency Communications用）、または、大量端末の接続用のスライス（例えば、ｍＭＴＣ：massive Machine Type Communication用）であってもよい。ＮＳＳＩは、ＮＳＩを分割した単一ドメインの仮想回線とも言える。ＮＳＳＩは、ＲＡＮドメインのスライス、ＭＢＨ（Mobile Back Haul）ドメインのスライス、または、コアネットワークドメインのスライスであってもよい。
　本実施形態では例えば、１つのＮＳＩには、１または複数のＮＳＳＩが含まれる。すなわち、１または複数のＮＳＳＩが、１つのＮＳＩの配下にあることとなる。なお、本実施形態において、複数のＮＳＩが同じＮＳＳＩを共有してもよい。
　また、図４に示すように、ＮＳＳＩとＮＳとは、一般的には、多対多の関係となる。
　また、本実施形態では例えば、１つのＮＦは、１または複数のネットワークスライスに所属できるようになっている。具体的には例えば、１つのＮＦには、１または複数のＳ－ＮＳＳＡＩ（Sub Network Slice Selection Assist Information）を含むＮＳＳＡＩ（Network Slice Selection Assistance Information）を設定できるようになっている。ここで、Ｓ－ＮＳＳＡＩは、ネットワークスライスに対応付けられる情報である。なお、ＮＦが、ネットワークスライスに所属していなくてもよい。
　複数のネットワークスライスは、互いに、対象とするエリアやＮＦの構成、対象とするＵＥ２０の種類、などが異なっていてよい。図５は、ネットワークスライスの属性の一例を示す図である。図５では、ネットワークスライスの属性として、スライスＩＤ、タイプ、構成、グループが示されている。スライスＩＤはネットワークスライスを識別する情報である。タイプはネットワークの特性の種類を示し、空白の場合は一般的なＵＥ２０との通信向けの特性、ＩｏＴの場合はＩｏＴ端末との通信に特化した特性を有することを示す。構成はネットワークスライスを実現するＮＦ（ＡＭＦ、ＳＭＦ、ＵＰＦ）の数、およびカバーするエリアを示す。グループは、ネットワークスライスが属するグループを示す。
　本実施形態では、複数のネットワークスライスは、そのタイプや構成、ネットワークの利用特性（例えば都市部中心の利用特性か郊外中心の利用特性か）に応じて複数のグループに分類される。グループの分類においては、ＡＭＦ、ＳＭＦ、ＵＰＦの数とＲＡＮの数とから求められるネットワーク経路の数、またそのネットワーク経路の種類、ＲＡＮ（例えばｇＮＢ）の数も用いられてよい。この分類は、いわゆるクラスタリング技術により行われてよい。複数のグループのそれぞれには、１または複数のネットワークスライスが属する。
　本実施形態にかかるプラットフォームシステム３０は、複数のネットワークスライスのそれぞれを監視し、それらに生じた異常を検出し、その異常に応じた対応処理を実行する。以下ではそれらの処理にについてより詳細に説明する。
　図６は、本実施形態にかかるプラットフォームシステム３０に実装される機能の一例を示す機能ブロック図である。なお、本実施形態にかかるプラットフォームシステム３０に対して、図５に示す機能のすべてが実装される必要はなく、また、図６に示す機能以外の機能が実装されていても構わない。
　図６に示すように、本実施形態に係るプラットフォームシステム３０は、機能的には、インベントリデータベース５０、オーケストレーション（Ｅ２ＥＯ：End-to-End-Orchestration）部５２、チケット管理部５４、ＡＩ・ビッグデータ処理部５６、性能算出部５７、監視機能部５８、ＳＤＮコントローラ６０、構成管理部６２、を含む。Ｅ２ＥＯ部５２は、機能的に、ポリシーマネージャ部８０、スライスマネージャ部８２を含む。ＡＩ・ビッグデータ処理部５６は、機能的に、ビッグデータ格納部７０、正常判定部７２、原因推定部７４、ＡＰＩ部７６を含む。正常判定部７２は複数の正常判定モデル７３を含み、原因推定部７４は、複数の原因推定モデル７５を含む。これらの要素は、主に、プロセッサ３０ａ、記憶部３０ｂ、および、通信部３０ｃにより実装される。
　本実施形態に記載される機能および処理は、プロセッサ３０ａ、記憶部３０ｂ（例えばメモリ）などを備えた１または複数の情報処理装置（例えばサーバ）にソフトウェア（プログラムの実行命令）が記録された記憶媒体を読み込ませ、プロセッサ３０ａがそのソフトウェアにかかる処理を実行することによって実現される。この記憶媒体は、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な、非揮発性の情報記憶媒体であってよい。また、プラットフォームシステム３０の記憶部３０ｂに含まれる外部記憶装置（例えばハードディスクドライブやソリッドステートドライブ）に、このソフトウェアが格納されてよい。また、図６に示す機能が、回路ブロック、メモリ、その他の集積回路により実装されてもよい。また、図６に示す機能が、ハードウェアのみ、ソフトウェアのみ、またはそれらの組合せといった様々な形態で実現できることは、当業者には容易に理解される。
　インベントリデータベース５０は、インベントリ情報が格納されたデータベースである。当該インベントリ情報には、例えば、ＲＡＮ３２やコアネットワークシステム３４に配置され、プラットフォームシステム３０で管理されているサーバについての情報が含まれる。
　また本実施形態では、インベントリデータベース５０には、インベントリデータが記憶されている。インベントリデータには、通信システム１に含まれる要素群の構成や要素間の関連付け（例えばトポロジーデータ）の現況が示されている。要素は、ハードウェア的な要素と、ソフトウェア的な要素とを含む。ハードウェア的な要素は、例えば、サーバ、ラック、建物、ネットワーク機器を含む。ソフトウェア的な要素は、例えば、ネットワークスライスやＮＦ、稼働するコンテナを含む。また、インベントリデータには、プラットフォームシステム３０で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。
　要素間の関連付けの現況を示すトポロジーデータは、例えば、あるＮＳの識別子と当該ＮＳの配下にある１または複数のＮＦの識別子とを含み、また例えば、あるネットワークスライスの識別子と当該ネットワークスライスに所属する１または複数のＮＦの識別子とを含む。
　図６に示されるＥ２ＥＯ部５２、チケット管理部５４、ＡＩ・ビッグデータ処理部５６、性能算出部５７、監視機能部５８、ＳＤＮコントローラ６０、構成管理部６２の各機能は、その処理においてインベントリデータベース５０に格納されるインベントリデータを参照し、必要に応じてインベントリデータを追加または更新する。例えば、通信システム１に含まれる新規要素の構築、通信システム１に含まれる要素の構成変更、通信システム１に含まれる要素のスケーリング、通信システム１に含まれる要素のリプレース、などのアクションが実行されることに応じて、インベントリデータベース５０に記憶されているインベントリデータが更新される。
　スライスマネージャ部８２は、本実施形態では例えば、スライステンプレートが示すロジックを実行することで、ネットワークスライスのインスタンス化を実行する。ここで、スライスマネージャ部８２は、ネットワークスライスのインスタンス化に関係する構成管理指示を構成管理部６２に出力してよい。そして、構成管理部６２が、当該構成管理指示に従った設定等の構成管理を実行してよい。
　スライスマネージャ部８２は、ＳＤＮコントローラ６０に、ＮＦ間（ＣＵ４４とＵＰＦ４６およびＡＭＦとの間）の通信経路の作成指示を出力してよい。ＳＤＮコントローラ６０は、ＳＤＮ３６に対して、より具体的な通信経路の作成指示を出力してよい。具体的な通信経路の作成指示は、互いに通信するＣＵ４４と、ＵＰＦ４６またはＡＭＦとを特定する情報として、２つのＳＲＶ６のＩＰアドレスを含む。
　ここで、スライスマネージャ部８２は、ポリシーマネージャ部８０からの指示に応じて、ネットワークスライスにおける通信経路と、コアネットワークシステム３４等におけるＮＦとのうち少なくとも一方を増強する処理を実行する。例えばスライスマネージャ部８２は、ネットワークスライスに関連付けられるＵＰＦ４６、ＡＭＦ、ＳＭＦのうちいずれかをスケールアウトする構成管理指示を構成管理部６２に出力し、スケールアウトされたＵＰＦ４６またはＡＭＦと各ＲＡＮ３２のＣＵ４４との新たな通信経路を作成する作成指示をＳＤＮコントローラ６０に出力してよい。またスライスマネージャ部８２は、既存のＵＰＦ４６またはＡＭＦと各ＲＡＮ３２のＣＵ４４との通信経路の帯域幅の上限を変更する、または通信経路を再作成する（言い換えれば、使用する通信経路を変更する）変更指示をＳＤＮコントローラ６０に出力してよい。
　スライスマネージャ部８２は、例えば、３ＧＰＰ（Third Generation Partnership Project）（登録商標）の仕様書「TS28 533」に記載される、ＮＳＭＦ（Network Slice Management Function）と、ＮＳＳＭＦ（Network Slice Sub-network Management Function）の機能を含んで構成される。ＮＳＭＦは、ネットワークスライスを生成して管理する機能であり、ＮＳＩのマネジメントサービスを提供する。ＮＳＳＭＦは、ネットワークスライスの一部を構成するネットワークスライスサブネットを生成し管理する機能であり、ＮＳＳＩのマネジメントサービスを提供する。
　構成管理部６２は、本実施形態では例えば、スライスマネージャ部８２から受け付ける構成管理指示に従って、ＮＦ等の要素群の設定等の構成管理を実行する。
　ＳＤＮコントローラ６０は、本実施形態では例えば、スライスマネージャ部８２から受け付けた通信経路の作成指示に従って、当該作成指示に関連付けられているＮＦ間の通信経路を作成する。またＳＤＮコントローラ６０は、スライスマネージャ部８２から受け付けた変更指示に従って、ＮＦ間の通信経路の帯域幅の上限を変更する、またはＮＦ間の通信経路を再作成する。
　ここで、ＳＤＮコントローラ６０は、セグメントルーティング技術（例えばＳＲｖ６（セグメントルーティングＩＰｖ６））を用いて、通信経路間に存在するアグリゲーションルータや、サーバなどに対して、ＮＳＩやＮＳＳＩを構築してもよい。また、ＳＤＮコントローラ６０は、複数の設定対象のＮＦに対して、共通のＶＬＡＮ（Virtual Local Area Network）を設定するコマンド、および、当該ＶＬＡＮに設定情報が示す帯域幅や優先度を割り当てるコマンドを発行することにより、それら複数の設定対象のＮＦにわたるＮＳＩおよびＮＳＳＩを生成してもよい。
　監視機能部５８は、ネットワークの状態を示す監視情報を取得する。監視機能部５８は、ネットワークスライスごとに、その状態を示す監視情報を取得してよい。監視情報は例えばメトリックデータおよびアラートの通知である。なお、監視機能部５８は、ＮＳのレベル、ＮＦのレベル、ＣＮＦＣのレベル、サーバ等のハードウェアのレベル、などといった、様々なレベルについて監視情報を取得してよい。
　監視機能部５８は、例えば、メトリックデータを出力するモジュールから監視情報を取得してよい。メトリックデータを出力するモジュールは、サーバ等のハードウェアや、通信システム１に含まれるソフトウェア要素に設定されてよい。また、ＮＦが、当該ＮＦにおいて測定可能（特定可能）なメトリックを示すメトリックデータを監視機能部５８に出力するように構成されてもよい。また、サーバが、当該サーバにおいて測定可能（特定可能）なハードウェアに関するメトリックを示すメトリックデータを監視機能部５８に出力するように構成されてもよい。
　また、例えば、監視機能部５８は、サーバにデプロイされるサイドカーコンテナからメトリックデータを取得してもよい。サイドカーコンテナは、複数のコンテナから出力されたメトリックを示すメトリックデータをＣＮＦＣ（マイクロサービス）単位に集計する。このサイドカーコンテナは、エクスポーターと呼ばれるエージェントを含んでもよい。監視機能部５８は、クバネテス等のコンテナ管理ツールを監視可能なプロメテウス（Prometheus）などのモニタリングツールの仕組みを利用して、マイクロサービス単位に集計されたメトリックデータをサイドカーコンテナから取得する処理を、所与の監視間隔で繰り返し実行してもよい。
　監視機能部５８は、メトリックデータとして、ネットワークの性能を示す性能指標値およびその性能指標値が取得された時刻を取得してよい。監視機能部５８は、例えば、「TS 28.552, Management and orchestration; 5G performance measurements」または「TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)」に記載された性能指標についての性能指標値を示すメトリックデータを監視情報として取得してよい。
　そして、監視機能部５８は、例えば、上述の監視情報を取得すると、当該監視情報をＡＩ・ビッグデータ処理部５６に向けて出力してよい。ＡＩ・ビッグデータ処理部５６は出力された監視情報をビッグデータ格納部７０に格納する。
　また、通信システム１に含まれるネットワークスライス、ＮＳ、ＮＦ、ＣＮＦＣ等の要素や、サーバ等のハードウェアは、監視機能部５８に、各種のアラートの通知（例えば、ハードウェアまたはソフトウェアに生じた何らかの異常の発生をトリガとしたアラートの通知）を行う。
　そして、監視機能部５８は、例えば、上述のアラートの通知を監視情報として取得すると、当該通知をＡＩ・ビッグデータ処理部５６に出力する。ＡＩ・ビッグデータ処理部５６は、その監視情報をビッグデータ格納部７０に格納する。格納されたアラートの通知は、ポリシーマネージャ部８０により利用される。ポリシーマネージャ部８０の処理については後述する。
　性能算出部５７は、ビッグデータ格納部７０に格納された複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、一種のＫＰＩ）を算出する。性能算出部５７は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してよい。性能算出部５７は、算出された性能指標値を示す性能指標データをＡＩ・ビッグデータ処理部５６に出力し、その性能指標値データをビッグデータ格納部７０に格納させてよい。性能指標データも、ネットワークスライスの状態を示す監視情報の一種である。
　なお、性能算出部５７は、メトリックデータを監視機能部５８から直接的に取得してそのメトリックデータに基づいて性能指標値を算出してもよい。
　ＡＩ・ビッグデータ処理部５６は、メトリックデータ、アラートの通知、性能指標値などの監視情報を蓄積し、またその蓄積された監視情報に基づいてネットワークに生じる異常の原因を推定する。
　ＡＩ・ビッグデータ処理部５６に含まれるビッグデータ格納部７０は、サーバ等のハードウェアやＮＦのようなソフトウェア要素から取得された、メトリックデータおよびアラートを含む監視情報を、対応するネットワークスライスおよび時刻と関連付けて格納する。ビッグデータ格納部７０には過去の監視情報が蓄積される。
　ＡＩ・ビッグデータ処理部５６に含まれる正常判定部７２は、複数のネットワークスライスにそれぞれ対応する複数の正常判定モデル７３を含む。正常判定部７２は、対象となるネットワークスライスに対応する正常判定モデル７３に対象となるネットワークスライスから取得される指標を含む入力データを入力した際の出力を取得することにより、対象となるネットワークスライスの状態が正常であるか否かを判定する。複数の正常判定モデル７３は、複数のネットワークスライスと１対１で対応してよい。
　正常判定モデル７３は、対応するネットワークスライスにおける、正常時のある時刻またはその直近の一定の期間に取得されたメトリックの指標と、その指標が取得された時間帯を示す情報とを含む正常訓練データにより学習されている。正常時とは、障害が発生していない期間である。正常時の指標は、所定期間の通信量を示すデータ、所定期間のネットワークの性能を示す指標、所定期間の代表時刻、所定期間の曜日、所定期間が休日か否かを示す休日フラグのうち少なくとも一部を含んでよい。正常判定モデル７３は、例えばｋ－近傍法、密度準拠クラスタリング、アイソレーションフォレストのような、データから外れ値を検出可能な公知の教師なし機械学習モデルに基づく異常検知モデルであってよい。
　正常判定モデル７３には、あるネットワークスライスにおける、現在または直近の一定の時間の指標と、現在の時間帯を示す情報を含む入力データが入力される。入力データは、ビッグデータ格納部７０に格納されたデータからネットワークスライスおよび時刻に応じて選択されたデータであってよい。正常判定モデル７３は、ネットワークの状態が正常であるか否かの推定結果を示す情報を出力する。正常判定モデル７３は、例えば、訓練データのいずれかとの差異が小さい入力データに対しては正常を示す情報を出力し、どの訓練データとも差異が大きい入力データに対しては異常を示す情報を出力してよい。
　ＡＩ・ビッグデータ処理部５６に含まれる原因推定部７４は、複数のグループにそれぞれ対応する複数の原因推定モデル７５を含む。複数のグループに、複数のネットワークスライスが分類されている。また原因推定部７４は、複数の原因の種類にそれぞれ対応する複数の原因推定モデル７５を含んでよい。原因推定モデル７５は、機械学習モデルである。原因の種類は、例えば、異常が発見されるトリガとなる事象の種類（以下では単にトリガの種類と記載する）であってよい。原因推定モデル７５は、ネットワークに異常が生じた際の過去の監視情報を含む入力データと、前記異常の原因を示す正解データとを含む訓練データによって学習されている。
　また原因推定モデル７５のそれぞれは、原因の種類と対応づけられており、原因推定モデル７５は、異常の原因が、対応づけられた原因の種類に含まれる複数の原因のうちいずれであるかを推定する。原因推定モデル７５はグループおよび原因の種類の組み合わせごとに設けられ、互いに異なる訓練データにより学習されてよい。複数の原因推定モデル７５から原因の種類に応じたものに原因を推定させるために、複数の原因の種類にそれぞれ対応し互いに異なる複数のモデル決定条件が存在する。このモデル決定条件により、用いられる原因推定モデル７５が決定される。なお、複数の原因推定モデル７５から用いられるものを選択するための条件とも言えるので、モデル決定条件はモデル選択条件とも称される。
　なお、原因推定モデル７５のインスタンスは、ネットワークインスタンスと原因の種類の組み合わせごとに設けられてよい。この場合、同じグループに属する複数のネットワークスライスを含むある原因の種類についての原因推定モデル７５のインスタンスは、同じ訓練データにより学習された同じ種類のものである。なお、原因推定モデル７５は原因の種類に応じて分かれていなくてもよく、全てのネットワークスライスで共通の内部パラメータを有してもよい。
　原因推定モデル７５は、例えばTransformerモデルのように時系列の情報からネットワークに生じた異常の原因を推定するモデルであってよい。原因推定モデル７５に入力される入力データは、直近の３ブロック（例えば１ｈ間隔であれば３ｈ）のそれぞれのスナップショットにおける代表的な指標であってよい。その代表的な指標は、監視情報に含まれる、トラフィック、ＫＰＩの推移、代表時刻、曜日、休日フラグのうち少なくとも一部の項目を含んでよい。学習用のデータセットは、連続する３ブロックのそれぞれのスナップショットにおける代表的な指標のデータを含んでよい。原因推定モデル７５の学習用の入力データに含まれる複数の指標は、対応するグループに属するネットワークスライスについてビッグデータ格納部７０に格納される監視情報のログから取得されてよい。
　ある原因の種類について、正常判定モデル７３および原因推定モデル７５が組み合わせて用いられてよい。またある原因の種類について、複数の原因推定モデル７５の出力を組み合わせた情報が原因の推定に用いられてもよい。
　ＡＩ・ビッグデータ処理部５６に含まれるＡＰＩ部７６は、ポリシーマネージャ部８０から呼び出されるＡＰＩを提供する。ＡＰＩ部７６は、ポリシーマネージャ部８０から呼び出されるＡＰＩに応じて、原因推定部７４によるネットワークに生じた異常の原因の推定結果（原因推定部７４の出力）を取得し、さらに、原因推定部７４の原因推定モデル７５の出力を呼び出し元へ返す。
　ＡＰＩ部７６は、原因の種類（トリガの種類）に応じて異なるＡＰＩを提供してよいし、ネットワークスライスに応じて異なるＡＰＩを提供してもよい。ＡＰＩ部７６は、単にＡＰＩを呼び出す際のパラメータとして原因の種類およびネットワークスライスを取得し、そのパラメータに応じた原因推定モデル７５の出力を返してもよい。
　ポリシーマネージャ部８０は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の原因推定モデル７５の出力、上述の性能指標値データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。
　そして、ポリシーマネージャ部８０は、判定処理の結果に応じたアクションを実行する。例えば、ポリシーマネージャ部８０は、スライスマネージャ部８２に、ネットワークスライスにおける通信経路と、コアネットワークシステム３４等におけるＮＦとのうち少なくとも一方を増強させる指示を送信する。また例えば、ポリシーマネージャ部８０は、チケット管理部５４へ、発生した異常の内容（例えば検知された自称およびその推定された原因）を送信する。また例えば、ポリシーマネージャ部８０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示を図示しないライフサイクル管理部に出力する。
　チケット管理部５４は、本実施形態では例えば、通信システム１の管理者に通知すべき内容が示されたチケットを生成する。チケット管理部５４は、発生した異常（障害）の内容を示すチケットを生成してもよい。また、チケット管理部５４は、性能指標値データやメトリックデータの値を示すチケットを生成してもよい。また、チケット管理部５４は、ポリシーマネージャ部８０による判定結果を示すチケットを生成してもよい。
　そして、チケット管理部５４は、生成されたチケットを、通信システム１の管理者に通知する。チケット管理部５４は、例えば、生成されたチケットが添付された電子メールを、通信システム１の管理者の電子メールアドレスに宛てて送信してもよい。
　以下では、通信システム１における、ネットワークに異常が生じた際のその異常の原因の推定およびその原因に応じた対応の処理についてより詳細に説明する。これらの推定および対応の処理は、ポリシーマネージャ部８０およびＡＩ・ビッグデータ処理部５６により実装される。
　本実施形態では、原因の推定に用いる原因推定モデル７５は、原因の種類（トリガの種類）および対象のネットワークスライスが属するグループに応じて定まる。複数のモデル決定条件は、原因推定モデル７５を決定するための条件であり、原因の種類に対応している。
　図７は、ポリシーマネージャ部８０の処理の概要を示すフロー図である。図７に示される処理フローは、ポリシーマネージャ部８０の機能のうち、ネットワークに生じた異常の原因を取得し、その原因に対応する機能に関する処理の概要を示している。
　はじめにポリシーマネージャ部８０は、ビッグデータ格納部７０から監視情報を取得する（Ｓ１０１）。そして、ポリシーマネージャ部８０は、取得された監視情報が満たすモデル決定条件に応じて、ＡＰＩ部７６の呼び出し手法を決定する（Ｓ１０２）。そしてポリシーマネージャ部８０はその呼び出し手法によりＡＰＩ部７６を介してモデル決定条件に応じた原因推定モデル７５の出力を取得する（Ｓ１０３）。原因推定モデル７５にはビッグデータ格納部７０から取得された監視情報を含む入力データが入力されてよい。Ｓ１０２においてポリシーマネージャ部８０は監視情報のうち一部を用いてモデル決定条件を満たすか判定してよい。原因推定モデル７５に入力される監視情報は、Ｓ１０２において用いられる監視情報と異なる項目を含んでもよい。
　複数のモデル決定条件は第１および第２のモデル決定条件を含む。第１のモデル決定条件はネットワークスライスにおけるトラフィックの異常（スループット等の性能指標の異常）を示す条件である。第２のモデル決定条件は端末の登録に関する異常を示す条件である。第１のモデル決定条件および第２のモデル決定条件に関する処理の詳細については、図１０、図１２を用いて後述する。
　呼び出されたＡＰＩ部７６の処理について説明する。図８は、ＡＩ・ビッグデータ処理部５６の処理の一例を示すフロー図である。図８は、Ｓ１０３によりＡＩ・ビッグデータ処理部５６に含まれるＡＰＩ部７６が呼び出された際の処理の一例を示す。
　ＡＰＩ部７６は、ＡＰＩの種類および対象となるネットワークスライスが属するグループに基づいて原因推定モデル７５を決定する（Ｓ２０１）。厳密には、ＡＰＩ部７６は、グループに基づいて原因推定モデル７５の種類を決定する。ＡＰＩの種類は、ＡＰＩの呼び出し手法の一例である。本図の例では、ＡＰＩの種類は、原因の種類や、異常が発見されるトリガとなる事象の種類に対応している。ＡＰＩは、原因の種類とネットワークスライスの組み合わせごとに設けられてもよい。
　ＡＰＩ部７６は、原因推定モデル７５の決定において、呼び出されたＡＰＩの種類とネットワークスライスとの組み合わせに対応する原因推定モデル７５のインスタンスを決定してよい。原因推定モデル７５のインスタンスに応じた原因推定モデル７５の種類はグループに応じて決まっているため、ネットワークスライスに応じた原因推定モデル７５のインスタンスの決定は、グループに応じた原因推定モデル７５の決定に相当する。なお、ＡＰＩ部７６は、Ｓ２０１において、出力の取得の対象となる２以上の原因推定モデル７５の組み合わせを決定してもよい。
　用いられる原因推定モデル７５が決定されると、ＡＰＩ部７６は、決定された原因推定モデル７５（厳密にはそのインスタンス）にそのネットワークスライスについてのネットワークの状態を示す監視情報が入力された際の出力を取得する（Ｓ２０２）。ここで、ＡＰＩ部７６は、Ｓ２０１の処理の後に、入力データの取得と、決定された原因推定モデル７５への入力データとして監視情報の入力と、その原因推定モデル７５の出力の取得とを順に行ってよい。ＡＰＩ部７６は、入力データとしてビッグデータ格納部７０から決定された原因推定モデル７５に入力する現在または直近の監視情報を取得してよい。
　一方、複数の原因推定モデル７５のいずれかには、ＡＰＩ部７６による原因推定モデル７５の決定と関係なく、入力データとして監視情報が入力されてもよい。この場合、原因推定モデル７５には定期的に、ビッグデータ格納部７０から現在または直近の監視情報が入力データとして入力されてよい。この場合、ポリシーマネージャによるモデル決定条件に関する判定や、ＡＰＩ部７６による原因推定モデル７５の決定より前に、原因推定モデル７５に監視情報が入力されてよい。この場合、ＡＰＩ部７６は、Ｓ２０２において、既に出力された原因推定モデルの結果を取得してもよいし、最新の入力データに対する結果がまだ出力されていない場合には、その結果の出力まで待機してもよい。原因推定モデル７５の推定が早く開始されるため、より早く異常に対応することができる。
　そして、ＡＰＩ部７６は、その決定された原因推定モデル７５の出力を呼び出し元へ送信する（Ｓ２０３）。
　なお、決定された原因推定モデルによっては、原因推定モデルと正常判定モデルの判定とが組み合わされてもよい。この詳細については後述する。
　ポリシーマネージャ部８０は、ＡＰＩ部７６から出力を受け付けると、原因推定モデル７５の出力に応じた対応の処理を実行する（Ｓ１０４）。この対応の処理によりネットワークに生じた異常が解消または抑制される。例えば、原因推定モデル７５の出力が第１のラベルを示す場合（言い換えれば、当該出力の値が、第１のラベルに相当する値と一致する、第１のラベルに相当する範囲内にある、または、出力のうち第１のラベルに対応する項目の値が閾値を超える）には、ポリシーマネージャ部８０はＣＵ４４とＵＰＦ４６との間の通信経路を増強する、より具体的にはその通信経路の帯域幅を増加させてよい。原因推定モデル７５の出力が第２のラベルを示す場合には、その通信経路を再作成させてよい。原因推定モデル７５の出力が第３のラベルを示す場合には、データ通信にかかるＵＰＦ４６の数を増加させ（スケールアウト）、その増加されたＵＰＦ４６と既存のＣＵ４４との間の通信経路を追加させてよい。また例えば原因推定モデルの出力が第４のラベルを示す場合には、ＳＭＦの数を増加させ（スケールアウト）、第５のラベルを示す場合には、ＡＭＦおよびＳＭＦの数を増加させ、第６のラベルを示す場合にはＵＥの接続に制限をかけてよい。また、前述の対応の処理として、ポリシーマネージャ部８０は、チケット管理部５４へ障害の発生の通知を送ってもよい。
　図７の処理は実際にはこの順番通りにされなくてもよい。例えば、モデル決定条件ごとにＳ１０２からＳ１０４に相当する処理が行われてよい。例えば、モデル決定条件ごとに記憶部３０ｂにプログラムが格納され、それぞれのプログラムを実行するプロセッサ３０ａが、そのプログラムに含まれるモデル決定条件を満たすか否かを判定し（Ｓ１０２に相当）、その判定結果に応じてＡＰＩ部７６を呼び出し（Ｓ１０３に相当）、原因分析モデルの出力に応じた対応の処理を実行してよい（Ｓ１０４に相当）。
　以下では、モデル決定条件ごとにより詳細に処理を説明していく。図１０は、ポリシーマネージャ部８０が原因推定モデル７５を用いて対応する処理の一例を示すフロー図である。図１０には、モデル決定条件として性能に関する条件が用いられる場合における、図７のＳ１０２からＳ１０４に相当する処理をより詳細に記載している。図１０に示される処理は定期的に繰り返し実行される。
　図１０の処理において、はじめにポリシーマネージャ部８０は、最新の取得された性能指標値（例えばスループット）が閾値未満であり、かつ前回取得された性能指標値が閾値未満であるか判定する（Ｓ３０１）。
　Ｓ３０１において最新および前回の性能指標値が閾値以上である場合には（Ｓ３０１のＮ）、図１０の処理を終了する。一方、性能指標値が閾値未満である場合には（Ｓ３０１のＹ）、ポリシーマネージャ部８０は、ＡＰＩ部７６のＡＰＩ－Ａを介して原因推定モデル７５に原因を問合せ、その原因推定モデル７５の出力を取得する（Ｓ３０２）。ここで、原因推定モデル７５の出力は、予め定められた複数のラベルのうちいずれかを指す、または、どのラベルも該当しないことを示すものとする。
　最新および前回の性能指標値が閾値未満であることは、モデル決定条件の一種である。ＡＰＩ－Ａを介して呼び出される原因推定モデル７５は限定されているため、ＡＰＩ－Ａを選択する条件は、原因推定モデル７５を選択する条件でもあるからである。
　取得された出力がラベルＡ１を指し示す場合には（Ｓ３０３のＹ）、ポリシーマネージャ部８０はＳＤＮコントローラ６０に対して、ＵＰＦ４６とＲＡＮ３２との既存の通信経路における帯域幅を増加させる指示を送信し（Ｓ３０４）、ＳＤＮコントローラ６０にその帯域幅を増加させる。またＳ３０４の処理がされると図１０に示される処理は終了する。
　取得された出力がラベルＡ２を指し示す場合には（Ｓ３０５のＹ）、ポリシーマネージャ部８０はＳＤＮコントローラ６０に対して、ＵＰＦ４６とＲＡＮ３２との通信経路を再作成させる指示を送信し（Ｓ３０６）、ＳＤＮコントローラ６０にその通信経路を再作成する。またＳ３０６の処理がされると図１０に示される処理は終了する。
　取得された出力がラベルＢを指し示す場合には（Ｓ３０７のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＵＰＦ４６をスケールアウトさせる指示を送信し、ＳＤＮコントローラ６０に、ＵＰＦ４６とＲＡＮ３２との通信経路をスケールアウトさせる指示を送信する（Ｓ３０８）。ＵＰＦ４６をスケールアウトさせる指示は、ＵＰＦ４６の処理能力を増強するための処理を実行させる指示であり、例えば対象のネットワークスライスにＵＰＦ４６を追加する指示でもよい。また、ＵＰＦ４６が使用可能なＣＮＦのリソースの上限を増やしてもよい。通信経路をスケールアウトさせる指示は、追加されたＵＰＦ４６とＲＡＮ３２との間の通信を増強するための処理を実行させる指示であり、例えば、ＵＰＦ４６とＲＡＮ３２との通信に使用する仮想の通信経路を新規に作成させる指示でもよい。また、ＵＰＦ４６とＲＡＮ３２との通信に使用されている通信経路の帯域幅を増加させてもよい。指示を受け付けた構成管理部６２はＵＰＦ４６を追加し、指示を受け付けたＳＤＮコントローラ６０はその通信経路を新規作成する。またＳ３０８の処理がされると図１０に示される処理は終了する。
　Ｓ３０３からＳ３０８の処理は、図７のＳ１０４に示される、原因分析モデルの出力に応じた対応の処理に相当する。なお、例えば後述の図１１の処理においてネットワークの状態が正常であると判定されたことを示す情報が返ってきた場合には、この対応の処理が行われなくてよい。
　ここで、Ｓ３０２においてＡＰＩ部７６が呼び出されると、図８に示される処理により、呼び出されたＡＰＩの種類およびネットワークスライスに応じて原因推定モデル７５が選択され、選択された原因推定モデル７５の出力がポリシーマネージャ部８０に返される。ここで、ＡＰＩ部７６を含むＡＩ・ビッグデータ処理部５６は、正常判定モデル７３の判定結果も用いて原因を推定してもよい。
　図１１は、ＡＩ・ビッグデータ処理部５６の処理の他の一例を示すフロー図である。図１１の例では、複数の種類がある原因推定モデル７５のうち一部の種類についてネットワークスライスに対応する正常判定モデル７３と組み合わせて処理をする場合の処理を示している。予め、原因推定モデル７５のそれぞれについて、正常判定モデル７３と組み合わせるか否かを示す正常判定情報が記憶部３０ｂに格納されているものとする。
　はじめにＡＰＩ部７６は、呼び出されたＡＰＩの種類とネットワークスライスが属するグループとに応じて原因推定モデル７５を決定する（Ｓ４０１）。
　そしてＡＰＩ部７６は、決定された原因推定モデル７５が、正常判定モデル７３と組み合わせるか否か判定する（Ｓ４０２）。この判定は、ＡＰＩ部７６が決定された原因推定モデル７５と関連付けて記憶される正常判定情報により行われてよい。例えば、ＡＰＩ部７６は、例えば図１０の性能指標値のような、トラフィック量と関係するトリガの場合には正常判定モデル７３と原因推定モデル７５とを組み合わせ、トラフィック量と関係のないトリガの場合には正常判定モデル７３を用いなくてよい。
　そして正常判定モデルと組み合わせると判定された場合には（Ｓ４０２のＹ）、ＡＰＩ部７６は該当するネットワークスライスに対応する正常判定モデル７３の出力を取得する（Ｓ４０３）。またＡＰＩ部７６はその取得された出力が、ネットワークスライスの状態が異常でないことを示す場合には（Ｓ４０４のＮ）、ＡＰＩ部７６は異常が生じていないことを示す情報を呼び出し元へ送信し処理を終了する。正常判定モデル７３の出力はネットワークスライスの状態が正常であるか異常であるかの２値の情報であってもよいし、異常である蓋然性を示す値であってもよい。後者の場合には、正常判定モデル７３の出力が閾値を超えるか否かに基づいてネットワークスライスの状態が正常であるか異常であるか判定されてよい。
　一方、ネットワークスライスの状態が異常であることを示す場合には（Ｓ４０４のＹ）、ＡＰＩ部７６は決定された原因推定モデル７５の出力を取得する（Ｓ４０５）。そして取得された原因推定モデル７５の出力を、ＡＰＩを介して呼び出し元へ送る（Ｓ４０６）。Ｓ４０５、Ｓ４０６の処理の詳細は、図８におけるＳ２０２、Ｓ２０３の処理と同様である。
　Ｓ４０２の判定において、正常判定モデルと組み合わせないと判定された場合には（Ｓ４０２のＮ）、Ｓ４０５以降の処理を実行する。この場合に実質的に行われる処理は、図８と同様となる。
　図１１に示されるように、正常判定モデル７３によってネットワークスライスの状態に異常があると判定された場合に原因推定モデル７５の出力が呼び出し元に送信されると、ポリシーマネージャ部８０は、正常判定モデル７３によってネットワークに異常があると判定された場合にのみその異常に対応する処理が実行される。
　なお、図８、図１１の例と異なり、ＡＰＩに応じて異なるプログラムが実行されてよい。この場合、ＡＰＩが原因の種類（またはトリガの種類）ごとに設けられている場合には、ＡＰＩ部７６はネットワークスライスに基づいて原因推定モデル７５の種類（およびインスタンス）を決定してよい。ＡＰＩが原因の種類（またはトリガの種類）とネットワークスライスとの組み合わせごとに設けられている場合には、ＡＰＩ部７６はＳ２０１およびＳ４０１の処理を経ずに、呼び出されたＡＰＩにより特定される原因推定モデル７５の出力を取得してよい。
　次に、図１０と異なるモデル決定条件についてのポリシーマネージャ部８０の処理の例について説明する。図１２は、ポリシーマネージャ部８０が原因推定モデル７５を用いて対応する処理の他の一例を示すフロー図である。図１２には、モデル決定条件として特定のＮＦ（具体的にはＡＭＦ、ＳＭＦ）からアラートが上がった場合における、図７のＳ１０２からＳ１０４に相当する処理をより詳細に記載している。図１２に示される処理も定期的に繰り返し実行される。
　図１２の処理において、はじめにポリシーマネージャ部８０は、最新の監視情報がＡＭＦまたはＳＭＦからのアラートが上がっていることを示し、また前回の監視情報も同じアラートが上がっていることを示すか判定する（Ｓ５０１）。
　最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示さない場合には（Ｓ５０１のＮ）、図１２の処理を終了する。一方、最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示す場合には（Ｓ５０１のＹ）、ポリシーマネージャ部８０は、ＡＰＩ部７６のＡＰＩ－Ｂを介して原因推定モデル７５に原因を問合せ、その原因推定モデル７５の出力を取得する（Ｓ５０２）。
　最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示すことは、モデル決定条件の一種である。ＡＰＩ－Ｂと原因推定モデル７５とは対応関係を有するため、ＡＰＩ－Ｂを選択する条件は、原因推定モデル７５を選択する条件でもあるからである。
　取得された出力がラベルＣ１を指し示す場合には（Ｓ５０３のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＳＭＦをスケールアウトさせる指示を送信する（Ｓ５０４）。またＳ５０４の処理がされると図１２に示される処理は終了する。
　取得された出力がラベルＣ２を指し示す場合には（Ｓ５０５のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＡＭＦおよびＳＭＦをスケールアウトさせる指示を送信する（Ｓ５０６）。またＳ５０６の処理がされると図１２に示される処理は終了する。
　取得された出力がラベルＤを指し示す場合には（Ｓ５０７のＹ）、ポリシーマネージャ部８０はＲＡＮ３２に対してＵＥ２０の接続に制限をかける指示を送信する（Ｓ５０８）。ＵＥの接続の制限は、公知の手法で行われてよい。例えば、指示を受信したＲＡＮ３２が、ＵＥ２０からの接続要求を所定の割合で拒否してもよい。これにより、時間とともにＵＥ２０の接続数を減らすことができる。なお、所定の割合は、適宜に定めてよい。またＳ５０８の処理がされると図１２に示される処理は終了する。
　Ｓ５０３からＳ５０８の処理は、図７のＳ１０４に示される、原因推定モデル７５の出力に応じた対応の処理に相当する。
　なお、取得された監視情報が所定の対応条件を満たす場合には、原因推定モデル７５の出力を用いずに、所定の対応の処理が行われてもよい。図１３はポリシーマネージャ部８０が原因推定モデル７５を用いずに対応する処理の一例を示すフロー図である。図１３に示される処理は、原因の推定が比較的容易な異常に対応するために用いられる。
　図１３の処理において、はじめにポリシーマネージャ部８０は、最新および前回に取得された、いずれかのサーバのＣＰＵ使用率の両方が閾値を超えているか否か判定する（Ｓ６０１）。複数のサーバのそれぞれのＣＰＵ使用率は監視情報に含まれる。
　いずれのサーバについても、最新および前回に取得された２つのＣＰＵ使用率の両方が閾値を超えていない場合には（Ｓ６０１のＮ）、図１３の処理を終了する。一方、いずれかのサーバについて最新および前回に取得されたＣＰＵ使用率の両方が閾値を超えている場合には（Ｓ６０１のＹ）、ポリシーマネージャ部８０はチケット管理部５４へ警告チケットを発行し（Ｓ６０２）、チケット管理部５４は管理者へ警告チケットに基づくメッセージを出力する。またポリシーマネージャ部８０は、構成管理部６２に対して該当するサーバをスケールアウトする指示を送信する（Ｓ６０３）。より具体的にはポリシーマネージャ部８０は、構成管理部６２に、該当するサーバにデプロイされている機能を他の新たなサーバと分割して配置する指示を送信する。このように、ＣＰＵ使用率などの所定の対応条件を満たした場合に、警告チケットの発行、サーバのスケールアウトといった所定の対応が実行されてもよい。
　Ｓ６０２、Ｓ６０３の処理もネットワークの異常に対応する処理に対応する処理の一種である。
　本実施形態では、機械学習モデルである原因推定モデル７５を用いてネットワークスライスに生じた異常の原因を推定している。ここで、一般的にネットワークに実際に異常が生じるケースは少なく、異常の原因に関する訓練データを大量に取得することは容易でない。
　本実施形態では、ネットワークスライスのグループごとに原因推定モデル７５が学習されている。またネットワークスライスが属するグループに応じた原因推定モデル７５の出力に応じて対応処理が実行される。これらにより、ネットワークに生じる異常を適切に判定することができる。
　より具体的には、ネットワークスライスごとに学習する場合に比べ、より多くの異常に関する訓練データを確保することができ推定の精度が向上する。また仮に原因推定モデル７５をすべてのネットワークスライスで共通にした場合、ネットワークの構成に応じて生じる異常が異なるようなケースにおいて原因を推定することが難しい。ネットワーク構成に応じて分類されたグループを用いることで、ネットワークの構成に応じた原因の推定が可能になり、推定精度を向上させることができる。
　また、図１０、図１１に示されるように、正常判定モデル７３によってネットワークに異常があると判定された場合に原因推定モデル７５の原因推定の結果に応じた対応処理が行われている。
　前述のように異常の原因に関する訓練データを大量に取得することは容易でない一方で、ネットワークスライスの状態が正常である場合の訓練データを確保することは容易である。そのため、予めネットワークスライスの状態が正常であるか否かを正常判定モデル７３により精緻に推定し、その後原因推定モデル７５で異常の原因を推定することにより、異常の原因の推定の精度を向上させることが可能になる。また正常判定モデル７３をネットワークスライスごとに学習させることにより、さらに精度を向上させることが可能になる。
　また本実施形態では、異常が検出されるトリガにそれぞれ対応する複数の原因推定モデル７５が設けられ、原因の推定に用いる原因推定モデル７５は、異常が検出されるトリガに対応するモデル決定条件に応じて特定されている。このトリガは異常の原因の種類に対応している。これにより、個々の原因推定モデル７５が推定すべき異常の原因の範囲を効率的に限定することができ、原因推定の精度を向上させることが可能になる。
　なお、本開示は上述の実施形態に限定されるものではない。実施形態において開示された構成を様々に組み合わせることが可能である。また本開示の技術的思想の範囲内において、本実施形態に記載される構成の一部が変更されてもよい。
　例えば、本実施形態に係る実行基盤は、クバネテスクラスタであってもよい。また、本実施形態に係る実行基盤は、サーバであってもよい。
　また、本実施形態に係る機能ユニットは、５ＧにおけるＮＦである必要はない。例えば、本実施形態に係る機能ユニットが、ｅＮｏｄｅＢ、ｖＤＵ、ｖＣＵ、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）などといった、４Ｇにおけるネットワークノードであっても構わない。
　また、本実施形態に係る機能ユニットが、コンテナ型の仮想化技術でなく、ハイパーバイザ型やホスト型の仮想化技術を用いて実現されてもよい。また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。
　なお、上記の実施形態では実際の運用を想定して説明したため、過去の監視情報に基づいて学習されたモデルと、現在または直近の監視情報と、を用いて、現在のネットワークの状態を判定すると述べた。しかし、判定されるネットワークの状態は、必ずしも現在の状態でなくてもよい。すなわち、第１の時間帯に得られた監視情報と、第１の時間帯とは異なる第２の時間帯に得られた監視情報に基づいて学習されたモデルとを用いて、第１の時間帯におけるネットワークの状態を判定してもよい。
　以上に説明した実施形態についての記載から把握されるように、本明細書では以下の開示を含む多様な技術的思想が開示されている。
　（１）１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得する原因推定処理と、前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する対応処理と、が実行されるネットワークシステム。
　（２）（１）において、前記複数のネットワークは、ネットワークの構成を示す情報、通信量に関する特性、ネットワークの用途のうち少なくとも一部により、前記複数のグループに分類される、ネットワークシステム。
　（３）（１）または（２）において、前記対象ネットワークを含むグループに対応する原因推定モデルの学習に用いられる訓練データに含まれる入力データは、前記対象ネットワークを含むグループに属する複数のネットワークから取得される指標を含む、ネットワークシステム。
　（４）（１）から（３）のいずれかにおいて、前記原因推定モデルの出力は、前記対象ネットワークを構成する仮想化された処理部の能力が不足しているか否かを示す情報を含み、前記対応処理では、前記原因推定モデルの出力が、予め定められた種類の仮想化された処理部の能力が不足していることを示す場合に、前記種類の仮想化された処理部の数を増加させる、ネットワークシステム。
　（５）（１）から（４）のいずれかにおいて、複数のネットワークにそれぞれ対応する複数の正常判定モデルのうち前記対象ネットワークに対応する正常判定モデルに前記対象ネットワークから取得される指標を入力した際の出力を取得することにより、前記対象ネットワークの状態が正常であるか否かを判定する正常判定処理がさらに実行され、前記対象ネットワークの状態が正常でないと判定された場合に前記原因推定処理が実行され、前記複数の正常判定モデルは、対応するネットワークにおける正常時の指標と前記指標が取得された時間帯を示す情報とに基づいて学習される、ネットワークシステム。
　（６）（５）において、前記正常時の指標は、所定期間の通信量を示すデータ、所定期間のネットワークの性能を示す指標、所定期間の代表時刻、所定期間の曜日、所定期間の休日フラグのうち少なくとも一部を含む、ネットワークシステム。
　（７）（１）から（６）のいずれかにおいて、前記訓練データに含まれる入力データは、ネットワークの性能を示す指標の変化割合、代表時刻、曜日、休日フラグのうち少なくとも一部を含む、ネットワークシステム。
　（８）１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得し、前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する、ネットワークの異常の対応方法。

Claims (8)

  1. 　１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、
    　複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得する原因推定処理と、
    　前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する対応処理と、
    　が実行されるネットワークシステム。
  2. 　前記複数のネットワークは、ネットワークの構成を示す情報、通信量に関する特性、ネットワークの用途のうち少なくとも一部により、前記複数のグループに分類される、
    　請求項１に記載のネットワークシステム。
  3. 　前記対象ネットワークを含むグループに対応する原因推定モデルの学習に用いられる訓練データに含まれる入力データは、前記対象ネットワークを含むグループに属する複数のネットワークから取得される指標を含む、
    　請求項１に記載のネットワークシステム。
  4. 　前記原因推定モデルの出力は、前記対象ネットワークを構成する仮想化された処理部の能力が不足しているか否かを示す情報を含み、
    　前記対応処理では、前記原因推定モデルの出力が、予め定められた種類の仮想化された処理部の能力が不足していることを示す場合に、前記種類の仮想化された処理部の数を増加させる、
    　請求項１に記載のネットワークシステム。
  5. 　前記１以上のプロセッサのうち少なくとも一つによって、
    　複数のネットワークにそれぞれ対応する複数の正常判定モデルのうち前記対象ネットワークに対応する正常判定モデルに前記対象ネットワークから取得される指標を入力した際の出力を取得することにより、前記対象ネットワークの状態が正常であるか否かを判定する正常判定処理がさらに実行され、
    　前記対象ネットワークの状態が正常でないと判定された場合に前記原因推定処理が実行され、
    　前記複数の正常判定モデルは、対応するネットワークにおける正常時の指標と前記指標が取得された時間帯を示す情報とに基づいて学習される、
    　請求項１に記載のネットワークシステム。
  6. 　前記正常時の指標は、所定期間の通信量を示すデータ、所定期間のネットワークの性能を示す指標、所定期間の代表時刻、所定期間の曜日、所定期間の休日フラグのうち少なくとも一部を含む、
    　請求項５に記載のネットワークシステム。
  7. 　前記訓練データに含まれる入力データは、ネットワークの性能を示す指標の変化割合、代表時刻、曜日、休日フラグのうち少なくとも一部を含む、
    　請求項１に記載のネットワークシステム。
  8. 　１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、
    　複数のネットワークが分類された複数のグループにそれぞれ対応する複数の原因推定モデルであって、それぞれ対応するグループについて取得される指標を含む入力データおよび異常の原因を示す正解データを含む訓練データにより学習された複数の原因推定モデルのうち、前記複数のネットワークのうちの対象ネットワークが属するグループに対応する原因推定モデルに、前記対象ネットワークから取得された指標を含む入力データを入力した際の出力を取得し、
    　前記対象ネットワークについての前記原因推定モデルの出力に基づいて、前記対象ネットワークに生じた異常に対応するための処理を実行する、
    　ネットワークの異常の対応方法。
PCT/JP2022/021958 2022-05-30 2022-05-30 ネットワークの異常の原因推定 WO2023233470A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/043,041 US20240283707A1 (en) 2022-05-30 2022-05-30 Cause inference regarding network trouble
JP2024524531A JPWO2023233470A1 (ja) 2022-05-30 2022-05-30
PCT/JP2022/021958 WO2023233470A1 (ja) 2022-05-30 2022-05-30 ネットワークの異常の原因推定

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/021958 WO2023233470A1 (ja) 2022-05-30 2022-05-30 ネットワークの異常の原因推定

Publications (1)

Publication Number Publication Date
WO2023233470A1 true WO2023233470A1 (ja) 2023-12-07

Family

ID=89025950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/021958 WO2023233470A1 (ja) 2022-05-30 2022-05-30 ネットワークの異常の原因推定

Country Status (3)

Country Link
US (1) US20240283707A1 (ja)
JP (1) JPWO2023233470A1 (ja)
WO (1) WO2023233470A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019145107A (ja) * 2018-02-20 2019-08-29 ダークトレース リミテッドＤａｒｋｔｒａｃｅ Ｌｉｍｉｔｅｄ 機械学習モデルを用いてｅメールネットワークを保護するサイバー脅威防御システム
JP2021083058A (ja) * 2019-11-22 2021-05-27 株式会社Ｋｄｄｉ総合研究所 制御装置、制御方法、及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019145107A (ja) * 2018-02-20 2019-08-29 ダークトレース リミテッドＤａｒｋｔｒａｃｅ Ｌｉｍｉｔｅｄ 機械学習モデルを用いてｅメールネットワークを保護するサイバー脅威防御システム
JP2021083058A (ja) * 2019-11-22 2021-05-27 株式会社Ｋｄｄｉ総合研究所 制御装置、制御方法、及びプログラム

Also Published As

Publication number Publication date
US20240283707A1 (en) 2024-08-22
JPWO2023233470A1 (ja) 2023-12-07

Similar Documents

Publication Publication Date Title
WO2023233470A1 (ja) ネットワークの異常の原因推定
WO2023233471A1 (ja) ネットワークの異常の原因推定
US20240281754A1 (en) Performance index value calculation system and performance index value calculation method
WO2023188187A1 (ja) 通信経路決定システム及び通信経路決定方法
WO2024202004A1 (ja) サイレント障害の原因であるルータの推定
WO2024047775A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2024047774A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2023188186A1 (ja) 通信経路決定システム及び通信経路決定方法
WO2024202003A1 (ja) サイレント障害の原因であるルータの推定
WO2024189910A1 (ja) サイレント障害の原因であるルータの推定
US20240281301A1 (en) Execution platform determination system and execution platform determination method
US20240248763A1 (en) Arrangement system and arrangement method
WO2024189911A1 (ja) サイレント障害の原因であるルータの推定
US20240275694A1 (en) Validation system and validation method
WO2024111027A1 (ja) 通信システムに含まれる要素の性能指標値が示された監視画面の表示制御
US20240272895A1 (en) Replace system and replace method
WO2024142179A1 (ja) アプリケーションが不安定である原因の推定
WO2024142181A1 (ja) 通信システムに含まれるプロセスが不安定であるか否かの判定
WO2024111026A1 (ja) 通信システムに含まれる要素に対するアクションを実行するか否かを判定する判定処理の実行開始制御
WO2024069948A1 (ja) 通信システムに含まれるハードウェアリソースの管理
WO2024161499A1 (ja) 通信経路の切替制御
WO2024111025A1 (ja) 通信システムに含まれる要素に対するアクションの実行条件の制御
WO2024004102A1 (ja) キューに格納されている性能指標値データに基づく通信システムの状態判定
WO2024142180A1 (ja) 不安定なアプリケーションのリプレース
WO2023157200A1 (ja) スケーリング制御システム及びスケーリング制御方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 18043041

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22944759

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2024524531

Country of ref document: JP

Kind code of ref document: A