Determination of whether processes involved in communication system are unstable

JPWO2024142181A5Active Publication Date: 2025-06-25RAKUTEN MOBILE INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024566969
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-04-10
Publication Date
2025-06-25
Estimated Expiration
2042-12-26

AI Technical Summary

Technical Problem

Monitoring unstable processes in communication systems with distributed virtual machines incurs a significant processing load, as existing methods require individual monitoring of each process, leading to inefficiency.

Method used

A determination system that monitors application stability across multiple virtual machines, calculates stability evaluation values, and identifies unstable processes with a reduced processing load by focusing on cluster and application stability before specific process monitoring.

Benefits of technology

Enables the extraction of unstable processes with a smaller processing load by determining cluster and application stability first, thereby efficiently identifying and addressing unstable processes within the communication system.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader

Abstract

The present invention makes it possible to extract unstable processes from processes involved in a communication system under a low processing load. A policy manager unit (90) monitors whether an application that is involved in a communication system and involves a process that is distributed and run across a plurality of virtual machines has become unstable. In response to detection that the application has become unstable, the policy manager unit (90) determines whether at least one process that is involved in the application and is running across a plurality of virtual machines is unstable for each of the virtual machines at which the process is running.
Need to check novelty before this filing date? Find Prior Art

Description

Determining whether a process in a communication system is unstable

[0001] The present invention relates to determining whether a process involved in a communication system is unstable.

[0002] Patent Document 1 describes NFV (Network Functions Virtualization), which realizes the functions of network devices and the like in software using a virtual machine (VM) implemented on a virtualization layer such as a hypervisor.

[0003] International Publication No. 2020 / 145242

[0004] Some applications, such as network functions, that operate in a communication system include multiple processes, and these processes may be distributed and run on multiple virtual machines.

[0005] Here, when extracting unstable processes from among these processes, if each process is monitored to see if it has become unstable, the processing load for monitoring may become enormous.

[0006] The present invention has been made in view of the above circumstances, and one of its objects is to make it possible to extract unstable processes from among processes included in a communication system with a small processing load.

[0007] In order to solve the above problem, the determination system of the present disclosure includes an application monitoring means for monitoring whether an application included in a communication system, whose included processes are distributed and running on multiple virtual machines, has become unstable, and a process instability determination means for determining, in response to detection that the application has become unstable, for each of multiple virtual machines on which at least one process included in the application is running, whether the process running on that virtual machine is unstable.

[0008] In addition, the determination method according to the present disclosure includes monitoring whether an application included in a communication system, in which the included processes are distributed and running on multiple virtual machines, has become unstable, and, in response to detecting that the application has become unstable, determining, for each of multiple virtual machines in which at least one process included in the application is running, whether the process running on that virtual machine is unstable.

[0009] 1 is a diagram illustrating an example of a communication system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a communication system according to an embodiment of the present invention. FIG. 3 is a diagram illustrating an example of a network service according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an example of an association between elements established in a communication system according to an embodiment of the present invention. FIG. 5 is a functional block diagram illustrating an example of a function implemented in a platform system according to an embodiment of the present invention. FIG. 6 is a diagram illustrating an example of a data structure of physical inventory data. FIG. 7 is a diagram illustrating an example of a situation in which processes included in each of a plurality of applications are distributed and running on a plurality of virtual machines. FIG. 8 is a diagram illustrating an example of a situation in which processes included in each of a plurality of applications are distributed and running on a plurality of virtual machines. FIG. 9 is a flow diagram illustrating an example of the flow of processing performed in a platform system according to an embodiment of the present invention. FIG.

[0010] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

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

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

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

[0014] For example, several tens of regional data centers 12 are distributed and placed 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 or two regional data centers 12 may be placed in each prefecture.

[0015] For example, several thousand edge data centers 14 are distributed within the area covered by the communication system 1. Each edge data center 14 is capable of communicating with communication equipment 18 equipped with an antenna 16. As shown in FIG. 1 , one edge data center 14 may be capable of communicating with several pieces of communication equipment 18. The communication equipment 18 may include a computer such as a server computer. The communication equipment 18 according to this 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, a radio unit (RU) (described later).

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

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

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

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

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

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

[0022] In this embodiment, 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 also be implemented by a group of servers located in the regional data centers 12.

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

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

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

[0026] In this embodiment, a hypervisor (bare metal hypervisor) and host-based virtualization software running on a host operating system (host OS) are installed on servers located in the central data center 10, the regional data centers 12, and the edge data center 14. One or more virtual machines (VMs) run on each server. One or more processes can be deployed and run on each virtual machine. In this embodiment, a cluster of virtual machines may be built across multiple servers.

[0027] In this embodiment, the network service provided to the purchaser is composed of one or more functional units (for example, network functions (NFs)). In this embodiment, the functional units are implemented as NFs realized by virtualization technology. NFs realized by virtualization technology are called VNFs (Virtualized Network Functions). In the following description, the functional units are implemented as VNFs realized by hypervisor-type or host-type virtualization technology. In this embodiment, the network service is described as being implemented by one or more NFs. Furthermore, the functional units according to this embodiment may correspond to network nodes.

[0028] Fig. 3 is a diagram illustrating an example of a network service in operation. The network service illustrated in Fig. 3 includes, as software elements, NFs such as a plurality of RUs 40, a plurality of DUs 42, a plurality of CUs 44 (CU-CPs (Central Unit - Control Plane) 44a and CU-UPs (Central Unit - User Plane) 44b), a plurality of AMFs (Access and Mobility Management Functions) 46, a plurality of SMFs (Session Management Functions) 48, and a plurality of UPFs (User Plane Functions) 50.

[0029] In the example of Figure 3, RU 40, DU 42, CU-CP 44a, AMF 46, and SMF 48 correspond to elements of the control plane (C-Plane), and RU 40, DU 42, CU-UP 44b, and UPF 50 correspond to elements of the user plane (U-Plane).

[0030] The network service may include other types of NF as software elements. The network service is implemented on computer resources (hardware elements) such as multiple servers.

[0031] In this embodiment, for example, a communication service in a certain area is provided by the network service shown in FIG.

[0032] In this embodiment, it is assumed that the multiple RUs 40, multiple DUs 42, multiple CU-UPs 44b, and multiple UPFs 50 shown in Figure 3 belong to one end-to-end network slice.

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

[0034] As shown in FIG. 4, network services (NS), network functions (NF), and processes have a hierarchical structure.

[0035] The NS corresponds to, for example, a network service configured from a plurality of NFs. Here, the NS may correspond to, for example, a granular element such as 5GC, EPC, 5G RAN (gNB), or 4G RAN (eNB).

[0036] In 5G, NFs correspond to elements with granularity such as RU, DU, CU-CP, CU-UP, AMF, SMF, and UPF. In 4G, NFs correspond to elements with granularity such as MME (Mobility Management Entity), HSS (Home Subscriber Server), S-GW (Serving Gateway), vDU, and vCU. In this embodiment, for example, one NS includes one or more NFs. In other words, one or more NFs are under the control of one NS.

[0037] An NF includes one or more processes, that is, one or more processes are under the control of one NF.

[0038] A certain process may provide some of the functions of the DU, CU-CP, CU-UP, etc. Furthermore, a certain process may provide some of the functions of the UPF, AMF, SMF, etc. For example, the UPF may include multiple types of processes, such as a management process and a process for communication in the user plane. Furthermore, one NF (for example, one UPF) may include multiple processes of a specific type.

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

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

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

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

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

[0044] Fig. 5 is a functional block diagram showing an example of functions implemented in the platform system 30 according to this 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 the functions shown in Fig. 5 may also be implemented.

[0045] As shown in FIG. 5 , the platform system 30 according to this embodiment functionally includes, for example, an operations support system (OSS) unit 60, an orchestration (E2EO: End-to-End-Orchestration) unit 62, a service catalog storage unit 64, a big data platform unit 66, a data bus unit 68, an AI (Artificial Intelligence) unit 70, a monitoring function unit 72, an SDN controller 74, a configuration management unit 76, a process management unit 78, and a repository unit 80. The OSS unit 60 includes an inventory database 82, a ticket management unit 84, a fault management unit 86, and a performance management unit 88. The E2EO unit 62 includes a policy manager unit 90, a slice manager unit 92, and a lifecycle management unit 94. These elements are implemented primarily using a processor 30 a, a storage unit 30 b, and a communication unit 30 c.

[0046] The functions shown in Figure 5 may be implemented by installing a program including instructions corresponding to the functions in a platform system 30, which is one or more computers, on the platform system 30 and having the processor 30a execute the program. This program may be supplied to the platform system 30 via a computer-readable information storage medium, such as an optical disk, a magnetic disk, a magnetic tape, a magneto-optical disk, or a flash memory, or via the Internet. The functions shown in Figure 5 may also be implemented using circuit blocks, memory, or other LSIs. Those skilled in the art will understand that the functions shown in Figure 5 can be realized in various forms, such as hardware alone, software alone, or a combination thereof.

[0047] The process management unit 78 executes process lifecycle management, which includes, for example, processes related to process construction, such as process deployment and configuration.

[0048] Here, the platform system 30 according to this embodiment may include multiple process management units 78. A process management tool may be installed in each of the multiple process management units 78. Each of the multiple process management units 78 may execute process construction, such as process deployment, for a server group (e.g., a cluster) associated with the process management unit 78.

[0049] It should be noted that the process management unit 78 does not need to be included in the platform system 30. The process management unit 78 may be provided, for example, in a server managed by the process management unit 78 (i.e., the RAN 32 or the core network system 34), or may be provided in another server that is annexed to the server managed by the process management unit 78.

[0050] In this embodiment, the repository unit 80 stores, for example, images of processes included in a group of functional units (for example, a group of NFs) that realize a network service.

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

[0052] In this embodiment, inventory data is stored in the inventory database 82. The inventory data indicates the configuration of the elements included in the communication system 1 and the current status of the associations between the elements. The inventory data also indicates the status of resources managed by the platform system 30 (e.g., resource usage status). The inventory data may be physical inventory data or logical inventory data. Physical inventory data and logical inventory data will be described later.

[0053] Fig. 6 is a diagram illustrating an example of the data structure of physical inventory data. The physical inventory data illustrated in Fig. 6 is associated with one server. The physical inventory data illustrated in Fig. 6 includes, for example, a server ID, location data, building data, floor data, rack data, specification data, network data, a list of running process IDs, and a cluster ID.

[0054] The server ID included in the physical inventory data is, for example, an identifier of the server associated with the physical inventory data.

[0055] The location data included in the physical inventory data is, for example, data indicating the location (for example, the address of the location) of the server associated with the physical inventory data.

[0056] The building data included in the physical inventory data is, for example, data indicating the building (for example, the building name) in which the server associated with the physical inventory data is located.

[0057] The floor number data included in the physical inventory data is, for example, data indicating the floor number on which the server associated with the physical inventory data is located.

[0058] The rack data included in the physical inventory data is, for example, an identifier of the rack in which the server associated with the physical inventory data is located.

[0059] The specification data included in the physical inventory data is, for example, data indicating the specifications of the server associated with the physical inventory data, and the specification data indicates, for example, the number of cores, memory capacity, hard disk capacity, etc.

[0060] The network data included in the physical inventory data is, for example, data indicating information about the network of the server associated with the physical inventory data, and the network data indicates, for example, the NIC equipped in the server, the number of ports equipped in the NIC, the port ID of the port, etc.

[0061] The running process ID list included in the physical inventory data is, for example, data that indicates information about one or more processes running on a server associated with the physical inventory data, and the running process ID list indicates, for example, a list of identifiers (process IDs) of instances of the processes.

[0062] The cluster ID included in the physical inventory data is, for example, an identifier of the cluster (for example, a Kubernetes cluster) to which the server associated with the physical inventory data belongs.

[0063] The logical inventory data includes topology data indicating the current state of associations between multiple elements included in the communication system 1, such as those shown in Figure 4. For example, the logical inventory data includes topology data including an identifier of a certain NS and identifiers of one or more NFs under the NS. Also, for example, the logical inventory data includes topology data including an identifier of a certain network slice and identifiers of one or more NFs belonging to the network slice.

[0064] The inventory data may also include data indicating the current status of geographical relationships and topological relationships between elements included in the communication system 1. As described above, the inventory data includes location data indicating the locations where the elements included in the communication system 1 are operating, i.e., the current locations of the elements included in the communication system 1. From this, it can be said that the inventory data indicates the current status of the geographical relationships between elements (e.g., the geographical proximity between elements).

[0065] The logical inventory data may also include NSI data indicating information about the network slice. The NSI data indicates attributes such as an identifier of an instance of the network slice and a type of the network slice. The logical inventory data may also include NSSI data indicating information about the network slice subnet. The NSSI data indicates attributes such as an identifier of an instance of the network slice subnet and a type of the network slice subnet.

[0066] The logical inventory data may also include NS data indicating information about NSs. The NS data indicates attributes such as an identifier of an NS instance and the type of NS. The logical inventory data may also include NF data indicating information about NFs. The NF data indicates attributes such as an identifier of an NF instance and the type of NF. The logical inventory data may also include process data indicating information about processes included in the NFs. The process data indicates attributes such as a process ID of a process instance and the type of process.

[0067] The process ID of the process data included in the logical inventory data and the process ID included in the running process ID list included in the physical inventory data associate a process instance with the server on which the process instance is running.

[0068] In addition, data indicating various attributes such as a host name and an IP address may be included in the above-mentioned data included in the logical inventory data. For example, the process data may include data indicating an IP address of a process corresponding to the process data. Furthermore, for example, the NF data may include data indicating an IP address and a host name of the NF indicated by the NF data.

[0069] The logical inventory data may also include data indicating an NSSAI, including one or more S-NSSAIs, that is set in each NF.

[0070] The inventory database 82 is also able to grasp the status of resources as needed in cooperation with the process management unit 78. The inventory database 82 then updates the inventory data stored therein as needed based on the latest status of the resources.

[0071] In addition, in response to actions being performed, such as constructing a new element included in the communication system 1, changing the configuration of an element included in the communication system 1, scaling an element included in the communication system 1, or replacing an element included in the communication system 1, the inventory database 82 updates the inventory data stored in the inventory database 82.

[0072] The service catalog storage unit 64 stores service catalog data. The service catalog data may include, for example, service template data indicating logic used by the life cycle management unit 94. This service template data includes information necessary for building a network service. For example, the service template data includes information defining NSs, NFs, and processes, and information indicating the correspondence between NSs, NFs, and processes. Furthermore, for example, the service template data includes a workflow script for building a network service.

[0073] An example of service template data is an NSD (NS Descriptor). The NSD is associated with a network service and indicates the types of functional units included in the network service. The NSD may also indicate the number of functional units included in the network service for each type. The NSD may also indicate the file name of an NFD (described later) related to the NF included in the network service.

[0074] An example of service template data is an NFD (NF Descriptor). The NFD may indicate computer resources (e.g., a CPU, memory, hard disk, etc.) required by the NF. For example, the NFD may indicate, for each of a plurality of processes included in the NF, the computer resources (e.g., a CPU, memory, hard disk, etc.) required by the process.

[0075] The service catalog data may also include information regarding thresholds (e.g., anomaly detection thresholds) used by the policy manager 90 to compare with the calculated performance index values ​​and stability evaluation values. The performance index values ​​and stability evaluation values ​​will be described later.

[0076] The service catalog data may also include, for example, slice template data, which includes information necessary to perform instantiation of a network slice, including, for example, logic utilized by the slice manager unit 92.

[0077] The slice template data includes information on the "Generic Network Slice Template" defined by the GSM Association (GSMA) ("GSM" is a registered trademark). Specifically, the slice template data includes network slice template data (NST), network slice subnet template data (NSST), and network service template data. The slice template data also includes information indicating the hierarchical structure of these elements, as shown in FIG. 4.

[0078] In this embodiment, for example, the life cycle management unit 94 constructs a new network service in response to a purchase request for an NS from a purchaser.

[0079] For example, in response to a purchase request, the life cycle management unit 94 may execute a workflow script associated with the network service to be purchased. By executing this workflow script, the life cycle management unit 94 may instruct the process management unit 78 to deploy a process included in the new network service to be purchased. The process management unit 78 may then obtain an image of the process from the repository unit 80 and deploy the process corresponding to the image to a server.

[0080] In this embodiment, the life cycle management unit 94 also performs, for example, scaling and replacement of elements included in the communication system 1. Here, the life cycle management unit 94 may output a process deployment instruction or deletion instruction to the process management unit 78. Then, the process management unit 78 may perform processing such as process deployment or process deletion in accordance with the instruction. In this embodiment, the life cycle management unit 94 is capable of performing scaling and replacement that cannot be handled by the tools of the process management unit 78.

[0081] Furthermore, the life cycle management unit 94 may output an instruction to create a communication path to the SDN controller 74. For example, the life cycle management unit 94 presents two IP addresses at both ends of the communication path to be created to the SDN controller 74, and the SDN controller 74 creates a communication path connecting these two IP addresses. The created communication path may be managed in association with these two IP addresses.

[0082] Furthermore, the life cycle management unit 94 may output to the SDN controller 74 an instruction to create a communication path between the two IP addresses that is associated with the two IP addresses.

[0083] In this embodiment, for example, the slice manager unit 92 performs instantiation of a network slice. In this embodiment, for example, the slice manager unit 92 performs instantiation of a network slice by executing logic indicated by a slice template stored in the service catalog storage unit 64.

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

[0085] Here, the slice manager unit 92 may output a configuration management instruction related to the instantiation of the network slice to the configuration management unit 76. Then, the configuration management unit 76 may perform configuration management such as setting in accordance with the configuration management instruction.

[0086] The slice manager unit 92 may also present two IP addresses to the SDN controller 74 and output an instruction to create a communication path between these two IP addresses.

[0087] In this embodiment, the configuration management unit 76 performs configuration management such as setting of element groups such as NFs in accordance with configuration management instructions received from the life cycle management unit 94 and the slice manager unit 92, for example.

[0088] In this embodiment, the SDN controller 74 creates a communication path between two IP addresses associated with a communication path creation instruction received from, for example, the life cycle management unit 94 or the slice manager unit 92. The SDN controller 74 may create a communication path between two IP addresses using a known path calculation method such as Flex Algo.

[0089] Here, for example, the SDN controller 74 may use a segment routing technology (for example, SRv6 (Segment Routing IPv6)) to construct NSIs and NSSIs for aggregation routers, servers, and the like present along the communication paths. Furthermore, the SDN controller 74 may generate NSIs and NSSIs across multiple NFs to be configured by issuing commands to configure a common VLAN (Virtual Local Area Network) for multiple NFs to be configured, and commands to assign the bandwidth and priority indicated in the configuration information to the VLAN.

[0090] In addition, the SDN controller 74 may perform operations such as changing the maximum bandwidth available for communication between two IP addresses without constructing a network slice.

[0091] The platform system 30 according to this embodiment may include multiple SDN controllers 74. Each of the multiple SDN controllers 74 may execute processing such as creating a communication path for a group of network devices such as an AG associated with the SDN controller 74.

[0092] In this embodiment, for example, the monitoring function unit 72 monitors the group of elements included in the communication system 1 in accordance with a given management policy. Here, the monitoring function unit 72 may monitor the group of elements in accordance with a monitoring policy specified by a purchaser when purchasing a network service, for example.

[0093] In this embodiment, the monitoring function unit 72 performs monitoring at various levels, such as the slice level, the NS level, the NF level, the process level, and the hardware level of the server, etc.

[0094] For example, in order to perform monitoring at the various levels described above, the monitoring function unit 72 may set a module that outputs metric data in hardware such as a server or in a software element included in the communication system 1. Here, for example, an NF may output metric data indicating metrics that are measurable (identifiable) in the NF to the monitoring function unit 72. Also, a server may output metric data indicating metrics related to hardware that is measurable (identifiable) in the server to the monitoring function unit 72.

[0095] Furthermore, for example, the monitoring function unit 72 may deploy a sidecar process that acquires metric data on a process-by-process basis on the server. The monitoring function unit 72 may use the mechanism of a monitoring tool to repeatedly execute a process of acquiring the metric data acquired on a process-by-process basis from the sidecar process at a given monitoring interval.

[0096] The monitoring function unit 72 may monitor performance indicator values ​​for performance indicators described in, for example, “TS 28.552, Management and orchestration; 5G performance measurements” or “TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI).” Then, the monitoring function unit 72 may acquire metric data indicating the monitored performance indicator values.

[0097] In this embodiment, the monitoring function unit 72 performs a process (enrichment) of aggregating metric data, for example, in a predetermined aggregation unit, thereby generating performance index value data indicating the performance index values ​​of the elements included in the communication system 1 in that aggregation unit.

[0098] For example, for one gNB, performance index value data for the gNB is generated by aggregating metric data indicating the metrics of elements (e.g., network nodes such as DU42 and CU44) under the control of the gNB. In this way, performance index value data indicating communication performance in the area covered by the gNB is generated. Here, for example, performance index value data indicating multiple types of communication performance such as traffic volume (throughput) and latency may be generated for each gNB. Note that the communication performance indicated by the performance index value data is not limited to traffic volume and latency.

[0099] Then, the monitoring function unit 72 outputs the performance index value data generated by the above-mentioned enrichment to the data bus unit 68.

[0100] In this embodiment, for example, the data bus unit 68 receives performance index value data output from the monitoring function unit 72. Then, based on the received one or more pieces of performance index value data, the data bus unit 68 generates a performance index value file including the one or more pieces of performance index value data. Then, the data bus unit 68 outputs the generated performance index value file to the big data platform unit 66.

[0101] In this embodiment, the monitoring function unit 72 also identifies, for example, a stability evaluation value indicating the stability of the elements included in the communication system 1. Then, the monitoring function unit 72 generates stability evaluation value data indicating the identified stability evaluation value. Then, the monitoring function unit 72 outputs the generated stability evaluation value data to the data bus unit 68.

[0102] In this embodiment, the data bus unit 68 receives, for example, stability evaluation value data output from the monitoring function unit 72 .

[0103] In addition, elements such as network slices, NSs, NFs, processes, etc. included in the communication system 1, and hardware such as servers, notify the monitoring function unit 72 of various alerts (for example, notification of an alert triggered by the occurrence of a failure).

[0104] Then, for example, when the monitoring function unit 72 receives the above-mentioned alert notification, it outputs alert message data indicating the notification to the data bus unit 68. Then, the data bus unit 68 generates an alert file in which alert message data indicating one or more notifications are compiled into a single file, and outputs the alert file to the big data platform unit 66.

[0105] In this embodiment, the big data platform unit 66 accumulates, for example, performance index value files and alert files output from the data bus unit 68 .

[0106] In this embodiment, for example, a plurality of trained machine learning models are stored in advance in the AI ​​unit 70. The AI ​​unit 70 uses the various machine learning models stored in the AI ​​unit 70 to perform estimation processing such as future prediction processing of the usage status and service quality of the communication system 1. The AI ​​unit 70 may generate estimation result data indicating the results of the estimation processing.

[0107] The AI ​​unit 70 may perform estimation processing based on the files stored in the big data platform unit 66 and the above-mentioned machine learning model. This estimation processing is suitable for low-frequency prediction of long-term trends.

[0108] The AI ​​unit 70 is also capable of acquiring performance index value data stored in the data bus unit 68. The AI ​​unit 70 may perform estimation processing based on the performance index value data stored in the data bus unit 68 and the above-described machine learning model. This estimation processing is suitable for performing short-term predictions frequently.

[0109] In this embodiment, for example, the performance management unit 88 calculates a performance index value (e.g., KPI) based on metrics indicated by multiple metric data. The performance management unit 88 may calculate a performance index value that is an overall evaluation of multiple types of metrics (e.g., a performance index value related to an end-to-end network slice) that cannot be calculated from a single metric data. The performance management unit 88 may generate overall performance index value data that indicates the performance index value that is the overall evaluation.

[0110] The performance management unit 88 may acquire the above-mentioned performance index value file from the big data platform unit 66. The performance management unit 88 may also acquire estimation result data from the AI ​​unit 70. Then, performance index values ​​such as KPIs may be calculated based on at least one of the performance index value file and the estimation result data. The performance management unit 88 may also directly acquire metric data from the monitoring function unit 72. Then, performance index values ​​such as KPIs may be calculated based on the metric data.

[0111] In this embodiment, the fault management unit 86 detects the occurrence of a fault in the communication system 1 based on, for example, at least one of the above-mentioned metric data, the above-mentioned alert notification, the above-mentioned estimation result data, and the above-mentioned overall performance index value data. The fault management unit 86 may detect the occurrence of a fault that cannot be detected from a single piece of metric data or a single alert notification, for example, based on a predetermined logic. The fault management unit 86 may generate detected fault data that indicates the detected fault.

[0112] The fault management unit 86 may obtain metric data and alert notifications directly from the monitoring function unit 72. The fault management unit 86 may also obtain performance index value files and alert files from the big data platform unit 66. The fault management unit 86 may also obtain alert message data from the data bus unit 68.

[0113] In this embodiment, the policy manager unit 90 executes a predetermined judgment process based on, for example, at least one of the above-mentioned metric data, the above-mentioned performance index value data, the above-mentioned stability evaluation value data, the above-mentioned alert message data, the above-mentioned performance index value file, the above-mentioned alert file, the above-mentioned estimation result data, the above-mentioned overall performance index value data, and the above-mentioned detected fault data.

[0114] The policy manager unit 90 may then execute an action according to the result of the determination process. For example, the policy manager unit 90 may output an instruction to construct a network slice to the slice manager unit 92. The policy manager unit 90 may also output an instruction to scale or replace an element to the life cycle management unit 94 according to the result of the determination process.

[0115] The policy manager unit 90 according to this embodiment is capable of acquiring performance index value data stored in the data bus unit 68. The policy manager unit 90 may then execute a predetermined determination process based on the performance index value data acquired from the data bus unit 68. The policy manager unit 90 may also execute a predetermined determination process based on alert message data stored in the data bus unit 68.

[0116] Furthermore, the policy manager unit 90 according to this embodiment is capable of acquiring stability evaluation value data stored in the data bus unit 68. The policy manager unit 90 may then execute a predetermined determination process based on the stability evaluation value data acquired from the data bus unit 68. For example, the policy manager unit 90 may determine whether an application is unstable based on the stability evaluation value data indicating the stability of the application.

[0117] In this embodiment, for example, the ticket management unit 84 generates a ticket indicating the content to be notified to the administrator of the communication system 1. The ticket management unit 84 may generate a ticket indicating the content of the occurred fault data. The ticket management unit 84 may also generate a ticket indicating the values ​​of performance index value data, stability evaluation value data, or metric data. The ticket management unit 84 may also generate a ticket indicating the determination result by the policy manager unit 90.

[0118] Then, the ticket management unit 84 notifies the administrator of the communication system 1 of the generated ticket. For example, the ticket management unit 84 may send an email with the generated ticket attached to the email address of the administrator of the communication system 1.

[0119] The platform system 30 according to this embodiment determines whether a process included in the communication system 1 is unstable. Hereinafter, the determination of whether a process is unstable, which is executed by the platform system 30 according to this embodiment, will be further described.

[0120] FIG. 7 is a diagram illustrating an example of a situation in which processes included in a plurality of applications are distributed and run on a plurality of virtual machines.

[0121] The example of FIG. 7 shows a situation in which four applications with identifiers AP1, AP2, AP3, and AP4 are running.

[0122] These applications may be network functions (eg, DU 42, CU-CP 44a, CU-UP 44b, AMF 46, SMF 48, UPF 50, etc.).

[0123] In this embodiment, for each type of application, a hardware resource on which the application of that type can run is predetermined. In the following description, the hardware resource is assumed to be a server, but the hardware resource does not have to be a server and may be, for example, a node.

[0124] Hereinafter, a hardware resource on which a certain type of application can run will be referred to as a tenant corresponding to that application.

[0125] 7 shows four servers with identifiers S1, S2, S3, and S4, respectively, and these four servers belong to one cluster with identifier CL101.

[0126] 7 are each assumed to be of a different type. The tenant corresponding to the application with the identifier AP1 includes servers with identifiers S1, S2, and S3. The tenant corresponding to the application with the identifier AP2 includes servers with identifiers S2 and S3. The tenant corresponding to the application with the identifier AP3 includes servers with identifiers S1, S2, S3, and S4. The tenant corresponding to the application with the identifier AP4 includes servers with identifiers S1 and S4.

[0127] Furthermore, it is assumed that virtual machines with identifiers VM1, VM6, and VM10 are running on a server with identifier S1. It is assumed that virtual machines with identifiers VM2, VM4, and VM7 are running on a server with identifier S2. It is assumed that virtual machines with identifiers VM3, VM5, and VM8 are running on a server with identifier S3. It is assumed that virtual machines with identifiers VM9 and VM11 are running on a server with identifier S4.

[0128] 7 corresponds to one process, and the numbers shown in the rounded rectangles are identifiers associated with the types of processes.

[0129] 7, an application with an identifier AP1 includes three types of processes, one each of which has identifiers 1, 2, and 3. The types of processes with identifiers 1, 2, and 3 run on virtual machines with identifiers VM1, VM2, and VM3, respectively.

[0130] An application with an identifier AP2 includes two types of processes, one each of which has an identifier 4 and 5. The types of processes with identifiers 4 and 5 are running on virtual machines with identifiers VM4 and VM5, respectively.

[0131] An application with an identifier AP3 includes four types of processes, one each of which has identifiers 6, 7, 8, and 9. The types of processes with identifiers 6, 7, 8, and 9 are running on virtual machines with identifiers VM6, VM7, VM8, and VM9, respectively.

[0132] An application with an identifier AP4 includes two types of processes, one each of which has an identifier 10 and an identifier 11. The types of processes with identifiers 10 and 11 are running on virtual machines with identifiers VM10 and VM11, respectively.

[0133] In this way, the application shown in Fig. 7 includes multiple processes, and these processes run in a distributed manner on multiple virtual machines.

[0134] In the example of Fig. 7, one application includes one of each of multiple types of processes, but one application may include multiple processes of one type. Also, in the example of Fig. 7, one process is running in one virtual machine, but multiple processes may be running in one virtual machine.

[0135] In this embodiment, for example, the monitoring function unit 72 acquires a value (metric) indicating the stability of each process. Here, metrics such as a value indicating the state of the process (e.g., alive or dead), the start time of the process, the length of time the process performed input / output, the number of dropped packets sent by the process, and the number of dropped packets received by the process may be acquired.

[0136] The monitoring function unit 72 then calculates a weighted sum of the acquired metrics, using weights associated with the respective metrics, as a stability evaluation value indicating the stability of the process. For example, a weight for each metric type may be predetermined for each process type. The weighted sum of the acquired metrics, using the predetermined weights, may then be calculated as a stability evaluation value indicating the stability of the process of that type. Hereinafter, a stability evaluation value indicating the stability of a process will be referred to as a process stability evaluation value. For example, in the example of FIG. 7 , a process stability evaluation value is calculated for each of the processes with identifiers 1 to 11.

[0137] The monitoring function unit 72 then identifies a stability evaluation value indicating the stability of the application based on the process stability evaluation value of each process included in the application, which is obtained for that process. Hereinafter, the stability evaluation value indicating the stability of an application will be referred to as the application stability evaluation value. For example, the monitoring function unit 72 calculates the application stability evaluation value for each application based on the process stability evaluation values ​​calculated for the processes included in the application.

[0138] Here, the application stability evaluation value may be determined based on at least one of the following: the state of a process included in the application; the lifetime of a process included in the application; the length of time that a process included in the application has performed input / output; or the number of packet drops of a process included in the application. Here, for example, the lifetime of a process can be determined based on a value indicating the start time of the process.

[0139] Furthermore, the monitoring function unit 72 may calculate an application stability evaluation value indicating the stability of an application in accordance with a rule associated with the type of application. For example, a formula may be defined in advance for each type of application. Then, the application stability evaluation value of the application may be calculated by applying the process stability evaluation value of the process related to each type, which is obtained for each type of process included in the application, to the formula.

[0140] For example, an application stability evaluation value for an application with an identifier AP1 is calculated based on the process stability evaluation values ​​of processes with identifiers 1 to 3. Furthermore, an application stability evaluation value for an application with an identifier AP2 is calculated based on the process stability evaluation values ​​of processes with identifiers 4 to 5. Furthermore, an application stability evaluation value for an application with an identifier AP3 is calculated based on the process stability evaluation values ​​of processes with identifiers 6 to 9. Furthermore, an application stability evaluation value for an application with an identifier AP4 is calculated based on the process stability evaluation values ​​of processes with identifiers 10 to 11.

[0141] The monitoring function unit 72 then identifies a stability evaluation value indicating the stability of a cluster based on the application stability evaluation value calculated for each application. Hereinafter, the stability evaluation value indicating the stability of a cluster will be referred to as a cluster stability evaluation value. For example, the monitoring function unit 72 calculates the cluster stability evaluation value for each cluster based on the process stability evaluation value calculated for the application running in that cluster.

[0142] The monitoring function unit 72 may calculate the cluster stability evaluation value according to a predetermined rule. For example, a weight may be set in advance for each type of application. Then, the weighted sum of the application stability evaluation values ​​of the applications running in the cluster may be calculated as the cluster stability evaluation value of the cluster.

[0143] For example, the cluster stability evaluation value of the cluster with the identifier CL101 is calculated based on the application stability evaluation values ​​of the applications with the identifiers AP1 to AP4.

[0144] The monitoring function unit 72 then generates cluster stability evaluation value data for each of the multiple clusters, indicating the cluster stability evaluation value calculated for that cluster, and outputs the generated cluster stability evaluation value data to the data bus unit 68. In this embodiment, for example, the monitoring function unit 72 generates cluster stability evaluation value data representing the latest situation at predetermined time intervals. The monitoring function unit 72 then outputs the cluster stability evaluation value data to the data bus unit 68 every time cluster stability evaluation value data is generated.

[0145] Then, the policy manager unit 90 acquires the cluster stability evaluation value data in response to the cluster stability evaluation value data being output to the data bus unit 68. Then, the policy manager unit 90 identifies the cluster stability evaluation value indicated by the acquired cluster stability evaluation value data.

[0146] The policy manager unit 90 then determines whether each of the multiple clusters is unstable based on a cluster stability evaluation value that indicates the stability of the cluster. For example, the more unstable a cluster is, the smaller the cluster stability evaluation value. In this case, the policy manager unit 90 determines that the cluster is unstable when the cluster stability evaluation value is smaller than a predetermined threshold, for example.

[0147] As described above, in this embodiment, the process of determining whether a cluster is unstable is executed every time the cluster stability evaluation value data of the cluster is output to the data bus unit 68. In this way, in this embodiment, the policy manager unit 90 monitors whether a cluster included in the communication system 1 has become unstable.

[0148] In this embodiment, for example, upon detecting that a cluster has become unstable, the policy manager unit 90 starts monitoring whether each of the multiple applications running in the cluster has become unstable.

[0149] For example, suppose that the policy manager unit 90 determines that a cluster with an identifier CL101 is unstable. In this case, the policy manager unit 90 may output an instruction to start outputting stability evaluation value data indicating application stability evaluation values ​​for each of a plurality of applications running in the cluster to the monitoring function unit 72. Hereinafter, the stability evaluation value data indicating the application stability evaluation values ​​will be referred to as application stability evaluation value data.

[0150] In this embodiment, for example, in response to receiving the output start instruction, the monitoring function unit 72 starts generating application stability evaluation value data representing the latest status for each of the multiple applications running in the cluster (here, for example, four applications with identifiers AP1 to AP4) at predetermined time intervals. Then, every time application stability evaluation value data is generated, the monitoring function unit 72 outputs the application stability evaluation value data to the data bus unit 68.

[0151] In this embodiment, for example, the policy manager unit 90 acquires the application stability evaluation value data in response to the application stability evaluation value data being output to the data bus unit 68 .

[0152] In this embodiment, for example, the policy manager unit 90 determines whether the application is unstable based on the stability evaluation value indicated by the acquired application stability evaluation value data. For example, the more unstable the application, the smaller the application stability evaluation value. In this case, the policy manager unit 90 determines that the application is unstable when the application stability evaluation value is smaller than a predetermined threshold.

[0153] As described above, in this embodiment, the process of determining whether an application is unstable is executed each time the application stability evaluation value data of the application is output to the data bus unit 68. In this way, in this embodiment, the policy manager unit 90 monitors whether an application included in the communication system 1, whose processes are distributed and running on multiple virtual machines, has become unstable.

[0154] Furthermore, as described above, upon detecting that a cluster has become unstable, the policy manager unit 90 may begin monitoring whether each of the multiple applications running in the cluster has become unstable.

[0155] In this embodiment, the policy manager unit 90 may monitor a plurality of monitoring items related to an application. Then, in response to detecting that the monitoring result of a given monitoring item among the plurality of monitoring items satisfies a predetermined condition, the policy manager unit 90 may determine whether or not a process running on each of a plurality of virtual machines on which at least one process included in the application is running is unstable.

[0156] In this embodiment, for example, in response to detecting that an application has become unstable, the policy manager unit 90 determines whether the process running on each of multiple virtual machines on which at least one process included in the application is running is unstable.

[0157] For example, in response to detecting that an application has become unstable, the policy manager unit 90 may identify multiple virtual machines on which at least one process included in the application is running, and then start monitoring each of the identified virtual machines to determine whether the process running on that virtual machine is unstable.

[0158] For example, suppose that the policy manager unit 90 determines that an application with an identifier AP1 is unstable. In this case, the policy manager unit 90 may output an instruction to start outputting stability evaluation value data indicating process stability evaluation values ​​for each of a plurality of processes included in the application to the monitoring function unit 72. Hereinafter, the stability evaluation value data indicating the process stability evaluation values ​​will be referred to as process stability evaluation value data.

[0159] In this embodiment, for example, in response to receiving the output start instruction, the monitoring function unit 72 starts generating process stability evaluation value data representing the latest status for each of the multiple processes included in the application (here, for example, three processes with identifiers 1 to 3) at predetermined time intervals. Then, every time process stability evaluation value data is generated, the monitoring function unit 72 outputs the process stability evaluation value data to the data bus unit 68.

[0160] In this embodiment, for example, in response to the process stability evaluation value data being output to the data bus unit 68, the policy manager unit 90 acquires the process stability evaluation value data.

[0161] In this embodiment, for example, the policy manager unit 90 determines whether the process is unstable based on the stability evaluation value indicated by the acquired process stability evaluation value data. For example, the more unstable the process, the smaller the process stability evaluation value. In this case, the policy manager unit 90 determines that the process is unstable when the process stability evaluation value is smaller than a predetermined threshold value.

[0162] As described above, in this embodiment, the process of determining whether a process is unstable is executed each time the application stability evaluation value data of the process is output to the data bus unit 68. In this way, in this embodiment, the policy manager unit 90 monitors whether a process included in the communication system 1 has become unstable.

[0163] Furthermore, as described above, upon detecting that an application has become unstable, the policy manager unit 90 may begin monitoring whether each of the multiple processes included in the application has become unstable.

[0164] Note that, in response to a determination that a cluster is unstable, it is not necessary to start outputting the application stability evaluation value data to the data bus unit 68. For example, in response to a determination that a cluster is unstable, the policy manager unit 90 may request the monitoring function unit 72 to output application stability evaluation value data indicating the latest application stability evaluation value for the application running in the cluster.

[0165] Then, in response to receiving the request, the monitoring function unit 72 may generate application stability evaluation value data indicating the latest application stability evaluation value, and output the generated application stability evaluation value data to the policy manager unit 90. Then, the policy manager unit 90 may receive the application stability evaluation value data output from the monitoring function unit 72, and determine whether or not the application is unstable based on the application stability evaluation value indicated by the application stability evaluation value data.

[0166] Similarly, when an application is determined to be unstable, the output of the process stability evaluation value data to the data bus unit 68 does not have to be initiated. For example, when an application is determined to be unstable, the policy manager unit 90 may request the monitoring function unit 72 to output process stability evaluation value data indicating the latest process stability evaluation value for the process included in the application.

[0167] Then, in response to receiving the request, the monitoring function unit 72 may generate process stability evaluation value data indicating the latest process stability evaluation value, and output the generated process stability evaluation value data to the policy manager unit 90. Then, the policy manager unit 90 may receive the process stability evaluation value data output from the monitoring function unit 72, and determine whether or not the process is unstable based on the process stability evaluation value indicated by the process stability evaluation value data.

[0168] Furthermore, in this embodiment, in response to determining that a process is unstable, the policy manager unit 90 may execute an action related to the process. For example, the policy manager unit 90 may execute an action on the process, an action on a virtual machine on which the process is running, an action on a server on which the virtual machine is running, an action on a cluster on which the server is running, etc.

[0169] Here, for example, in response to determining that a process is unstable, the policy manager unit 90 may determine whether a process running on a virtual machine different from the virtual machine on which the process is running, which is running on the hardware resource on which the process is running, is unstable, and may then execute an action according to the determination result of whether the process running on the different virtual machine is unstable.

[0170] Here, for example, the policy manager unit 90 may replace a process. The policy manager unit 90 may also start or shut down a virtual machine. The policy manager unit 90 may also separate a hardware resource from a cluster. The policy manager unit 90 may also change the tenant settings of an application.

[0171] For example, in response to determining that the process with identifier 1 is unstable, it may be determined whether the processes with identifiers 6 and 10 are unstable.

[0172] Then, for example, if it is determined that at least one of the processes with identifiers 6 and 10 is stable, a new virtual machine with identifier VM12 may be started on the server with identifier S4, as shown in Fig. 8. Then, the process with identifier 1 may be replaced so that it runs on the new virtual machine with identifier VM12. Then, the virtual machine with identifier VM1 may be terminated.

[0173] On the other hand, if it is determined that both the processes with identifiers 6 and 10 are unstable, as shown in FIG. 9 , a server with identifier S5 may be added to a cluster with identifier CL101. Then, new virtual machines with identifiers VM12, VM13, and VM14 may be started on a server with identifier S4. Then, the processes with identifiers 1, 6, and 10 may be replaced so that the process with identifier 1 runs on the new virtual machine with identifier VM12, the process with identifier 6 runs on the new virtual machine with identifier VM13, and the process with identifier 10 runs on the new virtual machine with identifier VM14. Then, the server with identifier S1 may be separated from the cluster with identifier CL101.

[0174] In addition, in this embodiment, it is assumed that multiple processes are running on one virtual machine. In this case, if all of these multiple processes are determined to be unstable, all of these multiple processes may be replaced and the virtual machine may be terminated. On the other hand, if some of these multiple processes are determined to be unstable, the process determined to be unstable may be replaced. In this case, the remaining processes may continue to run on the virtual machine without being replaced.

[0175] In this embodiment, the conditions for determining that a cluster is unstable may be less stringent than the conditions for determining that an application is unstable.

[0176] For example, the more unstable a cluster is, the smaller the cluster stability evaluation value is, and the more unstable an application is, the smaller the application stability evaluation value is. The cluster stability evaluation value indicating the stability of a cluster is the sum of the application stability evaluation values ​​indicating the stability of the applications running in the cluster. If the cluster stability evaluation value is smaller than a predetermined threshold th1, the cluster is determined to be unstable, and if the application stability evaluation value is smaller than a predetermined threshold th2, the application is determined to be unstable.

[0177] Here, when the number of applications running in the cluster is n1, the threshold th1 may be greater than n1 times the threshold th2.

[0178] Conversely, the conditions for determining that an application is unstable may be less stringent than the conditions for determining that a cluster is unstable. For example, in the above case, threshold th1 may be smaller than n1 times threshold th2.

[0179] Furthermore, the conditions for determining that an application is unstable may be less stringent than the conditions for determining that a process is unstable.

[0180] For example, the more unstable an application is, the smaller the application stability evaluation value is, and the more unstable a process is, the smaller the process stability evaluation value is. Furthermore, the application stability evaluation value indicating the stability of an application is the sum of the process stability evaluation values ​​indicating the stability of the processes included in the application. If the application stability evaluation value is smaller than a predetermined threshold value th3, the application is determined to be unstable, and if the process stability evaluation value is smaller than a predetermined threshold value th4, the process is determined to be unstable.

[0181] Here, when the number of processes included in the application is n2, the threshold value th3 may be greater than n2 times the threshold value th4.

[0182] Conversely, the conditions for determining that a process is unstable may be less stringent than the conditions for determining that an application is unstable. For example, in the above case, threshold value th3 may be smaller than n2 times threshold value th4.

[0183] Here, an example of the flow of processing related to determining whether a process is unstable, which is performed in the platform system 30 according to this embodiment, will be described with reference to the flow charts shown in FIGS. 10A and 10B.

[0184] In this processing example, for example, the processing shown in S101 to S113 described below is executed for each of the multiple clusters included in the communication system 1. Below, focusing on one of the multiple clusters, an example of the flow of processing executed for that cluster will be described.

[0185] In this processing example, for example, the policy manager unit 90 monitors whether cluster stability evaluation value data indicating the stability of the cluster is output to the data bus unit 68 (S101).

[0186] When it is detected that the cluster stability evaluation value data has been output to the data bus unit 68, the policy manager unit 90 acquires the cluster stability evaluation value data (S102).

[0187] Then, the policy manager unit 90 determines whether the cluster is unstable based on the cluster stability evaluation value data acquired in the process shown in S102 (S103).

[0188] If it is not determined to be unstable (S103: N), the process returns to S101.

[0189] If it is determined that the applications are unstable (S103: Y), the policy manager unit 90 outputs an instruction to start outputting application stability evaluation value data for each of the multiple applications running on the cluster to the monitoring function unit 72 (S104).Then, the monitoring function unit 72 starts outputting the application stability evaluation value data to the data bus unit 68.

[0190] Then, the policy manager unit 90 monitors whether application stability evaluation value data indicating the stability of each of the applications running on the cluster is output to the data bus unit 68 (S105).

[0191] When it is detected that the application stability evaluation value data has been output to the data bus unit 68, the policy manager unit 90 acquires the application stability evaluation value data (S106).

[0192] Then, the policy manager unit 90 determines whether the application is unstable or not based on the application stability evaluation value data acquired in the process shown in S106 (S107).

[0193] If it is not determined to be unstable (S107: N), the process returns to S105.

[0194] If it is determined that the application is unstable (S107: Y), the policy manager unit 90 outputs an instruction to start outputting process stability evaluation value data for each of the multiple processes included in the application to the monitoring function unit 72 (S108).Then, the monitoring function unit 72 starts outputting the process stability evaluation value data to the data bus unit 68.

[0195] Then, the policy manager unit 90 monitors whether process stability evaluation value data indicating the stability of each of the processes included in the application is output to the data bus unit 68 (S109).

[0196] When it is detected that the process stability evaluation value data has been output to the data bus unit 68, the policy manager unit 90 acquires the process stability evaluation value data (S110).

[0197] Then, the policy manager unit 90 determines whether the process is unstable based on the process stability evaluation value data acquired in the processing shown in S110 (S111).

[0198] If it is not determined to be unstable (S111: N), the process returns to S109.

[0199] If it is determined that the process is unstable (S111: Y), the policy manager unit 90 executes an action related to the process (S112), such as replacing the process with another virtual machine.

[0200] The policy manager unit 90 then outputs an output end instruction to the monitoring function unit 72 (S113). The monitoring function unit 72 then ends the above-mentioned output of the application stability evaluation value data and the process stability evaluation value data to the data bus unit 68. Then, the process returns to S101.

[0201] In this processing example, even while the processing shown in S109 to S113 is being executed, the policy manager unit 90 may monitor whether the application stability evaluation value data is being output to the data bus unit 68. Then, in response to the policy manager unit 90 detecting that the application stability evaluation value data has been output to the data bus unit 68, the processing shown in S106 and thereafter may be executed for the application stability evaluation value data.

[0202] When extracting unstable processes from among the processes included in the communication system 1, if each process is monitored to see if it has become unstable, the processing load for monitoring may become enormous.

[0203] As described above, in this embodiment, the process of determining whether a process included in an application is unstable is not executed until it is detected that the application has become unstable.

[0204] Then, in response to detection that an application has become unstable, for each of a plurality of virtual machines on which at least one process included in the application is running, it is determined whether the process running on that virtual machine is unstable.

[0205] In this way, according to this embodiment, it is possible to extract unstable processes from among the processes included in the communication system 1 with a small processing load.

[0206] The present invention is not limited to the above-described embodiment.

[0207] For example, the functional units according to this embodiment are not limited to those shown in FIG.

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

[0209] Furthermore, the functional units according to the present embodiment do not necessarily have to be implemented by software, but may be implemented by hardware such as electronic circuits, etc. Furthermore, the functional units according to the present embodiment may be implemented by a combination of electronic circuits and software.

[0210] The technology described in the present disclosure can also be expressed as follows: [1] A determination system comprising: application monitoring means for monitoring whether an application included in a communication system, the included processes of which are distributed across multiple virtual machines and running, has become unstable; and process instability determination means for determining, in response to detection that the application has become unstable, for each of the multiple virtual machines on which at least one process included in the application is running, whether the process running on the virtual machine is unstable. [2] The determination system described in [1], wherein the application monitoring means monitors multiple monitoring items related to the application, and the process instability determination means, in response to detection that a monitoring result of a given monitoring item among the multiple monitoring items satisfies a predetermined condition, determines, for each of the multiple virtual machines on which at least one process included in the application is running, whether the process running on the virtual machine is unstable. [3] The determination system described in [1] or [2], further comprising cluster monitoring means for monitoring whether a cluster included in the communication system, on which multiple applications are running, has become unstable, and, in response to detection that the cluster has become unstable, the application monitoring means starts monitoring whether each of the multiple applications running on the cluster has become unstable. [4] The determination system according to any one of [1] to [3], further comprising: an action execution means for executing an action related to the process in response to the process being determined to be unstable.[5] The determination system according to [4], wherein the process instability determination means, in response to a determination that the process is unstable, determines whether a process running on a virtual machine different from the virtual machine on which the process is running and which is running on the hardware resource on which the process is running is unstable, and the action execution means executes an action in response to a determination result of whether the process running on the different virtual machine is unstable. [6] The determination system according to any one of [1] to [5], wherein the application is a network function. [7] A determination method comprising: monitoring whether an application included in a communication system, in which processes included in the application are distributed and running on a plurality of virtual machines, has become unstable; and, in response to detection that the application has become unstable, determining whether a process running on the virtual machine on which at least one process included in the application is running is unstable.

Claims

1. An application monitoring means for monitoring whether an application included in a communication system, the process of which is distributed and running on a plurality of virtual machines, has become unstable; a process instability determination means for determining, in response to detection that the application has become unstable, whether or not a process running on each of a plurality of virtual machines on which at least one process included in the application is running is unstable; A judgment system including:

2. The application monitoring means monitors a plurality of monitoring items related to the application, the process instability determination means, in response to detection that a monitoring result of a given monitoring item among the plurality of monitoring items satisfies a predetermined condition, determines whether or not a process running on each of a plurality of virtual machines on which at least one process included in the application is running is unstable; The determination system according to claim 1 .

3. The communication system further includes a cluster monitoring means for monitoring whether a cluster in which a plurality of applications are running becomes unstable, the application monitoring means, in response to detection that the cluster has become unstable, starts monitoring whether each of a plurality of applications running on the cluster has become unstable. The determination system according to claim 1 .

4. The method further includes: an action execution means for executing an action related to the process in response to determining that the process is unstable. The determination system according to claim 1 .

5. The process instability determination means, in response to the determination that the process is unstable, determines whether or not a process running on a virtual machine different from the virtual machine on which the process is running and which is running on the hardware resource on which the process is running is unstable; the action execution means executes an action according to a result of determining whether the process running on the different virtual machine is unstable. The determination system according to claim 4 .

6. The application is a network function. The determination system according to claim 1 .

7. Monitoring whether an application included in a communication system, the process of which is distributed and running on a plurality of virtual machines, has become unstable; In response to detection that the application has become unstable, determining whether or not a process running on each of a plurality of virtual machines on which at least one process included in the application is running is unstable; A determination method comprising: