WO2024024106A1 - ネットワーク負荷の予測開始タイミングの制御 - Google Patents

ネットワーク負荷の予測開始タイミングの制御 Download PDF

Info

Publication number
WO2024024106A1
WO2024024106A1 PCT/JP2022/029356 JP2022029356W WO2024024106A1 WO 2024024106 A1 WO2024024106 A1 WO 2024024106A1 JP 2022029356 W JP2022029356 W JP 2022029356W WO 2024024106 A1 WO2024024106 A1 WO 2024024106A1
Authority
WO
WIPO (PCT)
Prior art keywords
performance index
index value
data
network load
scale
Prior art date
Application number
PCT/JP2022/029356
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 PCT/JP2022/029356 priority Critical patent/WO2024024106A1/ja
Publication of WO2024024106A1 publication Critical patent/WO2024024106A1/ja

Links

Images

Classifications

    • 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level

Definitions

  • the present invention relates to control of network load prediction start timing.
  • Patent Document 1 describes that the usage bandwidth for each network processing function of a communication device is obtained, and if the bandwidth is larger than a scale-out threshold, the number of network software execution units used for network processing is increased. .
  • the present invention has been made in view of the above-mentioned circumstances, and one of its objects is to enable network load prediction to be started at an appropriate timing for scaling out elements included in a communication system. It's about doing.
  • a scale-out execution system includes a performance index value data acquisition means for acquiring performance index value data indicating an actual value of a performance index value related to a communication system, and a a first determining means for determining whether network load prediction is necessary based on the network load; a prediction start means for starting network load prediction in response to determining that network load prediction is necessary; after the prediction of the network load is started, a second determination means for determining whether or not scale-out is necessary based on the prediction result of the network load; A scale-out execution means for executing scale-out of included elements.
  • the scale-out execution method includes acquiring performance index value data indicating actual values of performance index values related to a communication system, and determining whether or not network load is predicted based on the performance index value data. and in response to determining that network load prediction is necessary, starting network load prediction, and after network load prediction has been started, based on the network load prediction result. , determining whether scale-out is necessary, and executing scale-out of elements included in the communication system in response to determining that scale-out is necessary.
  • FIG. 1 is a diagram showing an example of a communication system according to an embodiment of the present invention.
  • 1 is a diagram showing an example of a communication system according to an embodiment of the present invention.
  • FIG. 1 is a diagram schematically showing an example of a network service according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of association between elements constructed in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a functional block diagram illustrating an example of functions implemented in a platform system according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an example of a data structure of physical inventory data.
  • 1 is a diagram schematically showing an example of a data bus section according to an embodiment of the present invention.
  • FIG. 3 is a diagram schematically showing an example of acquisition of performance index value data through a performance determination process.
  • FIG. 3 is a diagram schematically showing an example of acquisition of performance index value data by a performance determination process and an estimation process. It is a flow diagram showing an example of the flow of processing performed in the platform system according to one embodiment of the present invention. It is a flow diagram showing an example of the flow of processing performed in the platform system according to one embodiment of the present invention.
  • FIG. 3 is a diagram schematically showing an example of the relationship between the resource usage rate of a determination process and the processing execution probability. It is a flow diagram showing an example of the flow of processing performed in the platform system according to one embodiment of the present invention.
  • FIG. 1 and 2 are diagrams showing 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 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.
  • 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 a processor 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. Note that SDN (Software-Defined Networking) may be implemented in the communication unit 30c.
  • the communication unit 30c exchanges data with the RAN 32 and the core network system 34.
  • 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 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, etc. 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 provided to the purchaser 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.
  • the network service shown in FIG. NFs such as an AMF (Access and Mobility Management Function) 46, a plurality of SMFs (Session Management Functions) 48, and a plurality of UPFs (User Plane Functions) 50 are included as software elements.
  • AMF Access and Mobility Management Function
  • SMFs Session Management Functions
  • UPFs User Plane Functions
  • the RU40, DU42, CU-CP44a, AMF46, and SMF48 correspond to elements of the control plane (C-Plane)
  • the RU40, DU42, CU-UP44b, and UPF50 correspond to the elements of the user plane (C-Plane). This corresponds to the element of U-Plane).
  • network service may include other types of NFs as software elements.
  • network services are implemented on computer resources (hardware elements) such as a plurality of servers.
  • a communication service in a certain area is provided by the network service shown in FIG.
  • 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 RU, DU, CU-CP, CU-UP, AMF, SMF, and UPF. 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 DU, CU-CP, CU-UP, etc.
  • a certain CNFC may be a microservice that provides some of the functions of UPF, AMF, SMF, and the like.
  • one NF includes one or more CNFCs.
  • 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 transport domain such as 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.
  • FIG. 5 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. 5 may be implemented.
  • the platform system 30 functionally includes, for example, an operation support system (OSS) section 60, an orchestration (E2EO: End-to-End-Orchestration) section 62, and a service Includes a 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 container management unit 78, and a repository unit 80.
  • the OSS section 60 includes an inventory database 82, a ticket management section 84, a fault management section 86, and a performance management section 88.
  • the E2EO section 62 includes a policy manager section 90, a slice manager section 92, and a life cycle management section 94. These elements are mainly implemented as a processor 30a, a storage section 30b, and a communication section 30c.
  • the functions shown in FIG. 5 may be installed in the platform system 30, which is one or more computers, and implemented by the processor 30a executing a program containing instructions corresponding to the functions.
  • 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 FIG. 5 may be implemented using circuit blocks, memories, and other LSIs. Further, those skilled in the art will understand that the functionality shown in FIG. 5 can be implemented in various forms, such as only hardware, only software, or a combination thereof.
  • the container management unit 78 executes container life cycle management.
  • the lifecycle management includes processes related to container construction, such as container deployment and configuration.
  • the platform system 30 may include a plurality of container management units 78.
  • a container management tool such as Kubernetes, and a package manager such as Helm may be installed in each of the plurality of container management units 78.
  • Each of the plurality of container management units 78 may perform container construction such as container deployment on a server group (for example, a Kubernetes cluster) associated with the container management unit 78.
  • the container management unit 78 does not need to be included in the platform system 30.
  • the container management unit 78 may be provided, for example, in a server managed by the container management unit 78 (that is, the RAN 32 or the core network system 34), or may be installed in a server managed by the container management unit 78. It may be provided in another server installed in parallel.
  • the repository unit 80 stores, for example, a container image of a container included in a functional unit group (for example, NF group) that realizes a network service.
  • a functional unit group for example, NF group
  • the inventory database 82 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 82 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. Furthermore, the inventory data indicates the status of resources managed by the platform system 30 (for example, resource usage status).
  • the inventory data may be physical inventory data or logical inventory data. The physical inventory data and logical inventory data will be described later.
  • FIG. 6 is a diagram showing an example of the data structure of physical inventory data.
  • the physical inventory data shown in FIG. 6 is associated with one server.
  • the physical inventory data shown in FIG. 6 includes, for example, server ID, location data, building data, floor number data, rack data, specification data, network data, operating container ID list, cluster ID, and the like.
  • the server ID included in the physical inventory data is, for example, the identifier of the server associated with the physical inventory data.
  • 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.
  • the building data included in the physical inventory data is, for example, data indicating a building (eg, building name) in which a server associated with the physical inventory data is located.
  • the floor number data included in the physical inventory data is, for example, data indicating the floor number where the server associated with the physical inventory data is located.
  • the rack data included in the physical inventory data is, for example, the identifier of the rack in which the server associated with the physical inventory data is located.
  • the spec data included in the physical inventory data is, for example, data indicating the specs of the server associated with the physical inventory data, and the spec data includes, for example, the number of cores, memory capacity, hard disk capacity, etc. .
  • the network data included in the physical inventory data is, for example, data indicating information regarding the network of the server associated with the physical inventory data. number, the port ID of the port, etc.
  • the operating container ID list included in the physical inventory data is, for example, data indicating information regarding one or more containers operating on the server associated with the physical inventory data, and the operating container ID list includes, for example, the container A list of instance identifiers (container IDs) is shown.
  • the cluster ID included in the physical inventory data is, for example, the identifier of the cluster (for example, the Kubernetes cluster) to which the server associated with the physical inventory data belongs.
  • the logical inventory data includes topology data indicating the current state of the association between elements as shown in FIG. 4 for a plurality of elements included in the communication system 1.
  • the logical inventory data includes topology data that includes an identifier of a certain NS and identifiers of one or more NFs under the NS.
  • 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.
  • the inventory data may include data indicating the current situation, such as geographical relationships and topological relationships between elements included in the communication system 1.
  • the inventory data includes location data indicating the locations where elements included in the communication system 1 are operating, that is, the current locations of the elements included in the communication system 1. From this, it can be said that the inventory data shows the current state of geographical relationships between elements (for example, geographical proximity between elements).
  • the logical inventory data may include NSI data indicating information regarding network slices.
  • the NSI data indicates, for example, attributes such as an identifier of a network slice instance and a type of network slice.
  • the logical inventory data may include NSSI data indicating information regarding network slice subnets.
  • the NSSI data indicates attributes such as, for example, the identifier of the network slice subnet instance and the type of the network slice subnet.
  • the logical inventory data may include NS data indicating information regarding the NS.
  • the NS data indicates, for example, attributes such as an identifier of an NS instance and a type of NS.
  • the logical inventory data may include NF data indicating information regarding NF.
  • the NF data indicates, for example, attributes such as an identifier of an NF instance and a type of NF.
  • the logical inventory data may include CNFC data indicating information regarding CNFC.
  • the CNFC data indicates, for example, attributes such as an instance identifier and a CNFC type.
  • the logical inventory data may include pod data indicating information regarding pods included in the CNFC.
  • the pod data indicates, for example, attributes such as a pod instance identifier and a pod type.
  • the logical inventory data may include container data indicating information regarding containers included in the pod.
  • the container data indicates, for example, attributes such as a container ID of a container instance and a container type.
  • the container instance and the server on which the container instance is running are associated by the container ID of the container data included in the logical inventory data and the container ID included in the active container ID list included in the physical inventory data. It will be.
  • 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.
  • the container data may include data indicating the IP address of the container corresponding to the container data.
  • the NF data may include data indicating the IP address and host name of the NF indicated by the NF data.
  • the logical inventory data may include data indicating NSSAIs set in each NF, including one or more S-NSSAIs.
  • the inventory database 82 cooperates with the container management unit 78 so that the status of resources can be grasped as appropriate. Then, the inventory database 82 appropriately updates the inventory data stored in the inventory database 82 based on the latest status of the resource.
  • inventory database 82 updates inventory data stored therein.
  • the inventory database 82 may include, for each NF, data indicating the importance of the location where the NF is located. For example, an important area flag may be associated with inventory data of a gNB that covers an area including government offices, fire stations, hospitals, etc.
  • the inventory database 82 may include data indicating the importance of services regarding elements such as NS, NF, and network slices.
  • the purchaser may specify an SLA that the NS to be purchased should meet, and an important service flag may be associated with inventory data of elements that need to guarantee performance corresponding to the SLA.
  • 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 to construct a network service.
  • the service template data includes information defining NS, NF, and CNFC, and information indicating a correspondence relationship between NS-NF-CNFC.
  • the service template data includes a workflow script for constructing a network service.
  • NSD Network Descriptor
  • the NSD is associated with a network service, and indicates the types of a plurality of functional units (for example, a plurality of CNFs) included in the network service.
  • the NSD may indicate the number of functional units included in the network service for each type of functional unit such as CNF.
  • the NSD may indicate a file name of a CNFD, which will be described later, related to a CNF included in the network service.
  • CNFD CNF Descriptor
  • the CNFD may indicate computer resources (eg, CPU, memory, hard disk, etc.) required by the CNF.
  • the CNFD may indicate computer resources (CPU, memory, hard disk, etc.) required by each of a plurality of containers included in the CNF.
  • the service catalog data may include information regarding a threshold value (for example, an abnormality detection threshold value) used by the policy manager unit 90 to be compared with the calculated performance index value.
  • a threshold value for example, an abnormality detection threshold value
  • the performance index values will be described later.
  • the service catalog data may include slice template data, for example.
  • the slice template data includes information necessary to perform network slice instantiation, including, for example, logic utilized by the slice manager unit 92.
  • the slice template data includes information on "Generic Network Slice Template” defined by GSMA (GSM Association) ("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. Further, the slice template data includes information indicating the hierarchical structure of these elements as shown in FIG.
  • the life cycle management unit 94 constructs a new network service for which a purchase request has been made in response to a purchase request for an NS by a purchaser.
  • the life cycle management unit 94 may execute a workflow script associated with the network service to be purchased in response to a purchase request. By executing this workflow script, the lifecycle management unit 94 may instruct the container management unit 78 to deploy a container included in a new network service to be purchased. Then, the container management unit 78 may acquire a container image of the container from the repository unit 80 and deploy a container corresponding to the container image on the server.
  • the life cycle management unit 94 executes scaling and replacement of elements included in the communication system 1, for example.
  • the life cycle management unit 94 may output a container deployment instruction or deletion instruction to the container management unit 78.
  • the container management unit 78 may execute processing such as deploying a container or deleting a container in accordance with the instruction.
  • the life cycle management unit 94 can perform scaling and replacement that cannot be handled by a tool such as Kubernetes of the container management unit 78.
  • the life cycle management unit 94 may output an instruction to create a communication path to the SDN controller 74.
  • 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.
  • life cycle management unit 94 may output to the SDN controller 74 an instruction to create a communication path between the two IP addresses, which is associated with the two IP addresses.
  • the slice manager unit 92 executes, for example, instantiation of a network slice.
  • the slice manager unit 92 instantiates a network slice by executing logic indicated by a slice template stored in the service catalog storage unit 64, for example.
  • the slice manager unit 92 includes, for example, NSMF (Network Slice Management Function) and NSSMF (Network Slice Sub-network Management Function) described in the 3GPP (registered trademark) (Third Generation Partnership Project) 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 slice manager unit 92 may output configuration management instructions related to instantiation of the network slice to the configuration management unit 76. Then, the configuration management unit 76 may perform configuration management such as setting according to the configuration management instruction.
  • the slice manager unit 92 may present two IP addresses to the SDN controller 74 and output an instruction to create a communication path between these two IP addresses.
  • the configuration management unit 76 executes configuration management such as setting of element groups such as NF in accordance with configuration management instructions received from the life cycle management unit 94 and the slice manager unit 92, for example.
  • the SDN controller 74 creates a communication path between two IP addresses associated with the creation instruction, for example, in accordance with a communication path creation instruction received from the life cycle management section 94 or the slice manager section 92.
  • the SDN controller 74 may create a communication path between two IP addresses using, for example, a known path calculation method such as Flex Algo.
  • the SDN controller 74 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 74 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.
  • VLAN Virtual Local Area Network
  • the SDN controller 74 may change the maximum value of the bandwidth that can be used for communication between two IP addresses without constructing a network slice.
  • the platform system 30 may include a plurality of SDN controllers 74. Then, each of the plurality of 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.
  • the monitoring function unit 72 monitors, for example, a group of elements included in the communication system 1 according to a given management policy.
  • the monitoring function unit 72 may monitor the element group, for example, according to a monitoring policy specified by the purchaser when purchasing the network service.
  • the monitoring function unit 72 executes monitoring at various levels, such as the slice level, NS level, NF level, CNFC level, and hardware level such as a server.
  • the monitoring function unit 72 may set a module that outputs metric data in hardware such as a server or a software element included in the communication system 1 so as to perform monitoring at the various levels described above.
  • the NF may output metric data indicating a measurable (identifiable) metric in the NF to the monitoring function unit 72.
  • the server may output metric data indicating metrics related to hardware that can be measured (specified) in the server to the monitoring function unit 72.
  • the monitoring function unit 72 may deploy a sidecar container on the server that aggregates metric data indicating metrics output from a plurality of containers in units of CNFC (microservices).
  • This sidecar container may contain agents called exporters.
  • the monitoring function unit 72 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 72 monitors the performance indicators regarding the performance indicators described in “TS 28.552, Management and orchestration; 5G performance measurements” or “TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)”. Values may be monitored. Then, the monitoring function unit 72 may acquire metric data indicating the performance index value to be monitored.
  • KPI Key Performance Indicators
  • the monitoring function unit 72 executes processing (enrichment) for aggregating metric data in a predetermined aggregation unit, thereby increasing the number of elements included in the communication system 1 in the aggregation unit. Generate performance index value data indicating performance index values.
  • performance index value data for the gNB is generated by aggregating metric data indicating metrics of elements under the gNB (for example, network nodes such as DU 42 and CU 44). In this way, performance index value data indicating communication performance in the area covered by the gNB is generated.
  • performance index value data indicating multiple types of communication performance such as traffic volume (throughput) and latency may be generated in each gNB. Note that the communication performance indicated by the performance index value data is not limited to traffic volume or latency.
  • the monitoring function unit 72 outputs the performance index value data generated by the enrichment described above to the data bus unit 68.
  • the data bus unit 68 receives performance index value data output from the monitoring function unit 72, for example. 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. The data bus unit 68 then outputs the generated performance index value file to the big data platform unit 66.
  • 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 72 (for example, an alert triggered by the occurrence of a failure). notification).
  • the monitoring function unit 72 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 is compiled into one file, and outputs the alert file to the big data platform unit 66.
  • the big data platform section 66 accumulates, for example, performance index value files and alert files output from the data bus section 68.
  • a plurality of trained machine learning models are stored in advance in the AI section 70.
  • the AI unit 70 uses 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 result of the estimation process.
  • the AI unit 70 may perform estimation processing based on the files accumulated in the big data platform unit 66 and the above-mentioned machine learning model. This estimation process is suitable for predicting long-term trends infrequently.
  • the AI section 70 is capable of acquiring performance index value data stored in the data bus section 68.
  • the AI section 70 may perform estimation processing based on the performance index value data stored in the data bus section 68 and the above-mentioned machine learning model. This estimation process is suitable for performing short-term predictions frequently.
  • the performance management unit 88 calculates, for example, a performance index value (for example, KPI) based on a metric indicated by a plurality of metric data.
  • the performance management unit 88 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 too.
  • the performance management unit 88 may generate comprehensive performance index value data indicating a performance index value that is a comprehensive evaluation.
  • the performance management unit 88 may obtain the above-mentioned performance index value file from the big data platform unit 66. Additionally, the performance management unit 88 may acquire estimation result data from the AI unit 70. Then, performance index values such as KPI may be calculated based on at least one of the performance index value file or the estimation result data. Note that the performance management unit 88 may directly acquire the metric data from the monitoring function unit 72. Then, a performance index value such as a KPI may be calculated based on the metric data.
  • the failure management unit 86 is configured to determine whether the communication system 1 is operating based on at least one of the above-mentioned metric data, the above-mentioned alert notification, the above-mentioned estimation result data, and the above-mentioned comprehensive performance index value data. Detect occurrence of failure. For example, the failure management unit 86 may detect the occurrence of a failure that cannot be detected from a single metric data or a single alert notification based on a predetermined logic. The fault management unit 86 may generate detected fault data indicating the detected fault.
  • failure management unit 86 may directly acquire metric data and alert notifications from the monitoring function unit 72. Further, the failure management unit 86 may obtain a performance index value file and an alert file from the big data platform unit 66. Further, the fault management section 86 may obtain alert message data from the data bus section 68.
  • the policy manager unit 90 includes, for example, the above-mentioned metric data, the above-mentioned performance index 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, and the above-mentioned A predetermined determination process is executed based on at least one of the comprehensive performance index value data and the above-mentioned detected failure data.
  • the policy manager section 90 may execute an action according to the result of the determination process. For example, the policy manager section 90 may output a network slice construction instruction to the slice manager section 92. Further, the policy manager section 90 may output an instruction for scaling or replacing the element to the life cycle management section 94 according to the result of the determination process.
  • the policy manager unit 90 is capable of acquiring performance index value data stored in the data bus unit 68. Then, the policy manager section 90 may execute a predetermined determination process based on the performance index value data obtained from the data bus section 68. Further, the policy manager section 90 may execute a predetermined determination process based on the alert message data stored in the data bus section 68.
  • the ticket management unit 84 generates a ticket indicating the content to be notified to the administrator of the communication system 1, for example.
  • the ticket management unit 84 may generate a ticket indicating the content of the occurred failure data. Further, the ticket management unit 84 may generate a ticket indicating the value of performance index value data or metric data. Further, the ticket management unit 84 may generate a ticket indicating the determination result by the policy manager unit 90.
  • the ticket management unit 84 notifies the administrator of the communication system 1 of the generated ticket.
  • the ticket management unit 84 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 generation of the performance index value file, the determination process based on the performance index value data stored in the data bus unit 68, and the estimation process based on the performance index value data stored in the data bus unit 68 will be further explained below. do.
  • FIG. 7 is a diagram schematically showing an example of the data bus section 68 according to the present embodiment.
  • the data bus section 68 according to this embodiment includes, for example, a plurality of queues 100 that hold performance index value data in a first-in, first-out list structure.
  • Each queue 100 belongs to either the first queue group 102a or the second queue group 102b.
  • a plurality of aggregation processes 104 are operating in the monitoring function unit 72.
  • Each of the aggregation processes 104 has preset elements to be aggregated by the aggregation process 104 .
  • gNBs to be aggregated by the aggregation process 104 are set in advance.
  • each aggregation process 104 acquires metric data from the NFs (eg, RU 40, DU 42, and CU-UP 44b) under the gNB that is the aggregation target of the aggregation process 104.
  • the aggregation process 104 executes enrichment processing to generate performance index value data indicating the communication performance of the gNB based on the acquired metric data.
  • the aggregation process 104 and the queue 100 are associated in advance.
  • FIG. 7 shows that the aggregation process 104 and the queue 100 are associated in a one-to-one relationship; however, the aggregation process 104 and the queue 100 are shown in a many-to-many relationship. You can leave it there.
  • the aggregation process 104 associated with the queues 100 included in the first queue group 102a will be referred to as a first group aggregation process 104a. Further, the aggregation process 104 associated with the queue 100 included in the second queue group 102b will be referred to as a second group aggregation process 104b.
  • each first group aggregation process 104a aggregates the metric data from the previous aggregation to the current time, which is associated with the first group aggregation process 104a, at predetermined time intervals (for example, every minute). By doing so, performance index value data is generated.
  • the first group aggregation process 104a acquires metric data from one or more NFs associated with the first group aggregation process 104a, for example, at one-minute intervals. Then, the first group aggregation process 104a generates performance index value data for the aggregation period by aggregating the metric data for the same aggregation period.
  • each second group aggregation process 104b aggregates the metric data from the previous aggregation to the current time, which is associated with the second group aggregation process 104b, at predetermined time intervals (for example, every 15 minutes). By doing so, performance index value data is generated.
  • the second group aggregation process 104b acquires metric data from one or more NFs associated with the second group aggregation process 104b, for example, at 15 minute intervals. Then, the second group aggregation process 104b generates performance index value data for the aggregation period by aggregating the metric data for the same aggregation period.
  • the maximum number of performance index value data that can be stored in the queues 100 included in the first queue group 102a is determined in advance.
  • a maximum of 240 pieces of performance index value data can be stored in the queue 100.
  • the maximum number is "240".
  • the maximum number of performance index value data that can be stored in the queues 100 included in the second queue group 102b is determined in advance.
  • the maximum number is "4".
  • one NF may be associated with both the first group aggregation process 104a and the second group aggregation process 104b. Then, the NF may output the type of metric data to be aggregated in the first group aggregation process 104a to the first group aggregation process 104a at one-minute intervals. Then, the NF may output the type of metric data to be aggregated in the second group aggregation process 104b to the second group aggregation process 104b at 15 minute intervals.
  • the type of metric data output to the first group aggregation process 104a and the type of metric data output to the second group aggregation process 104b may be the same or different.
  • metric data regarding some metrics that are desirable to be monitored in real time may be output to the first group aggregation process 104a.
  • a plurality of determination processes 106 are operating in the policy manager unit 90. Some of these determination processes 106 execute determination processing based on performance index value data stored in the data bus section 68, and the rest execute determination processing based on files stored in the big data platform section 66. Execute processing.
  • Some of the determination processes 106 acquire performance index value data indicating actual performance index values regarding the communication system 1. For example, there is a determination process 106 that acquires performance index value data in response to enqueuing of performance index value data in the queue 100 included in the first queue group 102a.
  • the configuration is such that any performance index value data included in the queue 100 can be accessed (obtained) without dequeueing. It has become.
  • the determination process 106 determines the state of the communication system 1 based on the acquired performance index value data.
  • the state of an element included in the communication system 1 and associated with the determination process 106 may be determined.
  • the state of the element that is the target of aggregation in the first group aggregation process 104a that generated the performance index value data acquired by the determination process 106 may be determined.
  • a determination process 106a will be referred to as a performance determination process 106a.
  • the performance determination process 106a and the queue 100 are associated in advance.
  • FIGS. 8 and 9 show that the performance determination process 106a and the queue 100 are associated in a one-to-one relationship; however, the performance determination process 106a and the queue 100 may They may be associated in a to-many relationship.
  • the data bus unit 68 in response to performance index value data being enqueued to a queue 100 included in the first queue group 102a, the data bus unit 68 sends information to one or more performance determination processes 106a associated with the queue 100. A notification indicating that the performance index value data has been enqueued may be output.
  • the performance determination process 106a that has received the notification may acquire the latest performance index value data stored in the queue 100 in response to the reception of the notification.
  • some of the determination processes 106 acquire estimation result data indicating the estimation results by the estimation process 108 (see FIG. 9) associated with the determination process 106. Then, the determination process 106 determines the state of the communication system 1 based on the acquired estimation result data.
  • the state of an element included in the communication system 1 and associated with the determination process 106 may be determined.
  • the state of the element that is the target of aggregation in the first group aggregation process 104a that generated the performance index value data acquired by the estimation process 108 may be determined.
  • a determination process 106 will be referred to as a predictive determination process 106b.
  • a plurality of estimation processes 108 are operating in the AI section 70. Some of these estimation processes 108 execute estimation processing based on performance index value data stored in the data bus unit 68, and the rest execute estimation processing based on files stored in the big data platform unit 66. Execute processing.
  • the estimation process 108 and the queue 100 are associated in advance.
  • FIG. 8 shows that the estimation process 108 and the queue 100 are associated in a one-to-one relationship; however, the estimation process 108 and the queue 100 are shown in a many-to-many relationship. You can leave it there.
  • each estimation process 108 acquires performance index value data stored in the queue 100 included in the first queue group 102a, which corresponds to the estimation process 108. Then, the estimation process executes a predetermined estimation process in the estimation process 108 based on the performance index value data.
  • the estimation process 108 calculates the latest performance index value data among the performance index value data stored in the queue 100.
  • the performance index value data of the nearest neighbor constant or the nearest neighbor period including at least the performance index value data of is obtained.
  • the data bus unit 68 enqueues one or more estimation processes 108 associated with the queue 100.
  • a notification indicating that the performance index value data has been enqueued may be output.
  • the estimation process 108 calculates the nearest neighbor constant or the nearest neighbor constant that includes at least the latest performance index value data among the performance index value data stored in the queue 100 Performance index value data for a predetermined period may be acquired.
  • the estimation process 108 shown in FIG. 9 acquires 60 pieces of estimated index value data, including the latest performance index value data. These performance index value data correspond to the latest 60 minutes of performance index value data including the latest performance index value data. Then, the estimation process 108 executes estimation processing based on the performance index value data.
  • the first group aggregation process 104a associated with a certain gNB aggregates metric data related to elements included in the gNB (for example, elements under the gNB), thereby improving the performance of the gNB.
  • the estimation process 108 that acquires the performance index value data generated by the first group aggregation process 104a stores the performance index value data in the queue 100. It is assumed that 60 pieces of performance index value data including the latest performance index value data are acquired.
  • the estimation process 108 uses the learned machine learning model stored in advance in the AI unit 70 to estimate the relevant estimation from the current time to 20 minutes ahead of the current time based on these 60 performance index value data. Predict the height of the network load of gNB.
  • prediction of traffic volume (throughput), latency, etc. may be performed as the height of the network load of the gNB.
  • This machine learning model may be, for example, an existing predictive model. Further, for example, this machine learning model may be a trained machine learning model in which supervised learning using a plurality of training data has been executed in advance.
  • Each of the plurality of training data includes, for example, learning input data indicating the traffic volume in the gNB for 60 minutes up to the given time point, which is different from each other, and learning input data indicating the traffic amount in the gNB from the given time point to the time point in the gNB.
  • estimation process 108 does not need to acquire part of the performance index value data stored in the queue 100 as described above, and even if all the performance index value data stored in the queue 100 is acquired. good.
  • the estimation process 108 outputs estimation result data indicating the execution result (estimation result) of the estimation process to the prediction determination process 106b associated with the estimation process 108. Then, the prediction determination process 106b acquires the estimation result data. Then, the prediction determination process 106b determines the state of the communication system 1 based on the acquired estimation result data.
  • the queue 100 is associated with the aggregation process 104, the performance determination process 106a, the prediction determination process 106b, and the estimation process 108.
  • the data bus unit 68 transmits at least part of the performance index value data stored in the queue 100 at a frequency less than the frequency at which the AI unit 70 acquires the performance index value data.
  • the data bus unit 68 may generate a performance index value file containing performance index value data stored in the queue 100 after the timing at which the performance index value file was previously generated at a predetermined time interval.
  • the time interval may coincide with a time corresponding to the maximum number of performance index value data that can be stored in the queues 100 included in the first queue group 102a (60 minutes in the above example), They don't have to match.
  • the data bus section 68 may include all the performance index value data stored in the queue 100. You can also generate files. That is, in response to all the performance index value data stored in the queue 100 being replaced, a file containing all the performance index value data stored in the queue 100 may be generated.
  • new performance index value data when new performance index value data is enqueued when 60 pieces of performance index value data are stored in the queue 100 included in the first queue group 102a, it is stored in the queue 100.
  • the oldest performance index value data that has been stored is dequeued. That is, the oldest performance index value data stored in the queue 100 is deleted from the queue 100.
  • the data bus unit 68 when four pieces of performance index value data are stored in the queue 100 included in the second queue group 102b, the data bus unit 68 stores these four pieces of performance index value data in one file. Generate a summarized performance index value file. The data bus unit 68 then outputs the generated performance index value file to the big data platform unit 66.
  • the data bus unit 68 dequeues all the performance index value data stored in the queue 100. That is, all performance index value data stored in the queue 100 is deleted from the queue 100.
  • the processing executed in response to the generation of the performance index value file is different between the queues 100 included in the first queue group 102a and the queues 100 included in the second queue group 102b.
  • the queue 100 included in the second queue group 102b all performance index value data stored in the queue 100 is deleted from the queue 100 in response to generation of the performance index value file.
  • dequeuing in accordance with the generation of the performance index value file is not performed.
  • the policy manager unit 90 may refer to the inventory data to check the attributes of the elements associated with the generated performance determination process 106a. Then, the policy manager unit 90 may generate a performance determination process 106a in which a workflow is set according to the confirmed attributes. The track record determination process 106a may perform the determination process by executing a workflow set in the track record determination process 106a.
  • the performance determination process 106a determines whether scale-out is necessary based on the acquired performance index value data.
  • the platform system 30 scales out the elements included in the communication system 1, for example, in response to the determination that scale-out is necessary.
  • the policy manager section 90, the life cycle management section 94, the container management section 78, and the configuration management section 76 may cooperate with each other to execute scale-out.
  • scaling out of the DU 42 and CU-UP 44b included in the gNB may be executed. .
  • the performance determination process 106a may determine whether the acquired performance index value data satisfies a predetermined first scale-out condition.
  • a predetermined first scale-out condition it may be determined whether the performance index value indicated by the performance index value data exceeds the threshold value th1.
  • This performance index value may be a value indicating the level of network load, such as traffic volume (throughput) or latency.
  • scaling out of the elements included in the communication system 1 is performed. good.
  • the performance determination process 106a determines whether network load prediction is necessary, for example, based on the acquired performance index value data.
  • the platform system 30 starts predicting the network load, for example, in response to determining that network load prediction is necessary.
  • the performance determination process 106a may determine whether the acquired performance index value data satisfies a predetermined prediction start condition. For example, it may be determined whether the performance index value indicated by the performance index value data exceeds the threshold value t2.
  • this threshold value th2 may be a smaller value than the above-mentioned threshold value th1. That is, the above-mentioned threshold th1 may be a larger value than the threshold th2.
  • network load prediction may be started in response to a determination that the prediction start condition is satisfied (for example, a determination that the performance index value exceeds the threshold th2).
  • the performance determination process 106a determines the network load level when the value indicating the height of the network load indicated by the performance index value data exceeds the first threshold value (for example, the above-mentioned threshold value th2). It may be determined that prediction is necessary. Then, in the performance determination process 106a, scaling out is necessary when the value indicating the height of the network load indicated by the performance index value data exceeds a second threshold (for example, the above-mentioned threshold th1) that is larger than the first threshold. It may be determined that
  • the performance determination process 106a determines that network load prediction is necessary. For example, assume that a predetermined prediction start condition is met.
  • the AI unit 70 generates the estimation process 108 that is associated with the performance determination process 106a
  • the policy manager unit 90 generates the prediction determination process 106b that is associated with the performance determination process 106a.
  • the estimation process 108 and the prediction determination process 106b may be activated.
  • instantiation of the trained machine learning model may also be executed.
  • the estimation process 108 may then perform estimation using the machine learning model instantiated in this manner.
  • the prediction determination process 106b may perform a predetermined determination process based on the estimation result data output by the estimation process 108 associated with the prediction determination process 106b. For example, the prediction determination process 106b may determine whether scale-out is necessary based on the network load prediction result.
  • the performance determination process 106a determines whether the enqueued performance index value data and the estimation process 108 obtains the performance index value data of the nearest neighbor constant or the nearest neighbor period that includes at least the enqueued performance index value data from among the performance index value data stored in the queue 100. You may. In this manner, in response to performance index value data being enqueued in the queue 100, the enqueued performance index value data may be acquired by both the performance determination process 106a and the estimation process 108.
  • the performance determination process 106a may determine whether scale-out is necessary based on the acquired performance index value data.
  • the estimation process 108 may generate estimation result data indicating the predicted result of the network load based on the acquired performance index value data. Then, the estimation process 108 may output the generated estimation result data to the prediction determination process 106b. Then, the prediction determination process 106b may acquire the estimation result data.
  • the prediction determination process 106b may determine whether scale-out is necessary based on the acquired estimation result data.
  • the performance determination process 106a may generate the estimation process 108 and the policy manager unit 90.
  • the platform system 30 scales out the elements included in the communication system 1, for example, in response to the determination that scale-out is necessary.
  • the prediction determination process 106b may determine whether the predicted value of the network load indicated by the estimation result data satisfies a predetermined second scale-out condition. For example, it may be determined whether the predicted value exceeds the threshold th3. Here, for example, it may be determined whether or not there is a predicted value exceeding the threshold th3 among a plurality of predicted values from the present time to 20 minutes ahead of the present time. This predicted value may be a value indicating the height of the network load, such as traffic volume (throughput) or latency. Then, in response to determining that the second scale-out condition is satisfied, scaling out of the elements included in the communication system 1 may be performed. Note that the second scale-out condition may be the same as or different from the first scale-out condition described above.
  • the prediction determination process 106b determines whether scale-out is necessary based on the network load prediction result after network load prediction is started.
  • the performance determination process 106a determines whether scale-out is necessary based on the performance index value data without depending on the network load prediction result.
  • the policy manager unit 90, life cycle management unit 94, container management unit 78, and configuration management unit 76 executes scaling out of the elements included in the communication system 1.
  • the estimation process 108 ends the prediction of the network load in response to satisfying a predetermined condition. That is, the estimation process 108 and the predictive determination process 106b disappear or stop.
  • the estimation process 108 and the predictive determination process 106b disappear or stop.
  • the conditions for terminating the network load prediction may be determined as appropriate depending on the specifications of the communication system 1, the requests of users using the communication system 1, and the like.
  • the estimation process 108 and the prediction determination process 106b associated with the element may be terminated (process killed).
  • the prediction determination process 106b may determine whether the predicted value of the network load indicated by the estimation result data is less than the threshold th4. Then, in response to it being determined that the predicted value of the network load indicated by the estimation result data is less than the threshold th4, the prediction determination process 106b and the estimation process 108 associated with the prediction determination process 106b end ( process kill).
  • the data bus unit 68 monitors that performance index value data is enqueued for each of the queues 100 included in the first queue group 102a (S101).
  • the performance determination process 106a associated with the queue 100 acquires the performance index value data (S102).
  • the performance determination process 106a determines whether the performance index value indicated by the performance index value data acquired in the process shown in S102 exceeds the threshold value th1 (S103).
  • the policy manager section 90, life cycle management section 94, container management section 78, and configuration management section 76 execute the relevant performance determination process.
  • the element associated with 106a is scaled out (S104), and the process returns to S101.
  • the performance determination process 106a performs the estimation process 108 associated with the performance determination process 106a and the prediction determination process 106b. It is determined whether it has been generated and whether the performance index value exceeds the threshold th2 (S105). As mentioned above, the threshold value th2 may be a smaller value than the above-mentioned threshold value th1.
  • the AI unit 70 instructs the performance determination process 106a.
  • the associated estimation process 108 is generated, and the policy manager unit 90 generates the prediction determination process 106b associated with the performance determination process 106a (S106). Then, the process returns to S101. In this way, the estimation process by the estimation process 108 and the judgment process by the predictive judgment process 106b are started.
  • step S105 if it is determined that the estimation process 108 and the prediction determination process 106b have been generated, or if it is determined that the performance index value does not exceed the threshold th2 (S105: N). , the process returns to step S101.
  • Constantly predicting network loads for all elements included in the communication system 1 is undesirable as it wastes computer resource capacity and power consumption.
  • network load prediction is started in response to a determination that network load prediction is necessary based on performance index value data. Then, after the network load prediction has started, scaling out of the elements included in the communication system 1 is executed in response to it being determined that scaling out is necessary based on the network load prediction result. . By doing so, according to the present embodiment, prediction of the network load for scaling out the elements included in the communication system 1 is started at an appropriate timing.
  • the performance determination process 106a determines whether there are sufficient computer resources for the determination process 106 (S206).
  • the AI unit 70 If it is determined that there are sufficient computer resources for the determination process 106 (S206: Y), the AI unit 70 generates the estimation process 108 associated with the performance determination process 106a, and the policy manager unit 90 generates a prediction determination process 106b associated with the performance determination process 106a (S207). Then, the process returns to step S201. In this way, the estimation process by the estimation process 108 and the judgment process by the predictive judgment process 106b are started.
  • the performance determination process 106a may determine whether network load prediction is necessary based on performance index value data and computer resource usage. Then, network load prediction may be started in response to determination that network load prediction is necessary. By doing so, it is possible to control whether to start predicting the network load depending on the amount of computer resources used. For example, it is possible to prevent network load prediction from starting when computer resources are tight.
  • the index indicating the usage amount of computer resources is not limited to the ratio of the number of currently executing determination processes 106 to the maximum number of determination processes 106 as described above.
  • the necessity of predicting the network load may be determined based on the number of determination processes 106 that are being executed. Further, the necessity of predicting the network load may be determined based on the ratio of the number of currently executing prediction determination processes 106b to the predetermined maximum number of prediction determination processes 106b. Furthermore, the necessity of predicting the network load may be determined based on the number of prediction determination processes 106b that are being executed. Further, the necessity of predicting the network load may be determined based on the ratio of the number of estimation processes 108 in execution to the predetermined maximum number of estimation processes 108. Furthermore, the necessity of predicting the network load may be determined based on the number of estimation processes 108 that are being executed. Further, the necessity of predicting the network load may be determined based on the CPU usage rate, memory usage rate, storage usage rate, and the like.
  • the policy manager unit 90 determines whether or not to perform a judgment on whether or not to predict the network load based on the amount of computer resources used, depending on the importance of the element to be scaled out. You may decide.
  • the process shown in FIG. 10 may be a process that corresponds to the first type workflow
  • the process shown in FIG. 11 may be a process that corresponds to the second type workflow.
  • the policy manager unit 90 may check the importance of the element associated with the generated track record determination process 106a based on the inventory data. Then, a track record determination process 106a may be generated in which a workflow is set according to the confirmed importance level. For example, for an element whose inventory data is associated with an important area flag or an important service flag, the performance determination process 106a in which the first type workflow is set may be generated. Then, for elements that are not associated with either the important area flag or the important service flag in the inventory data, the performance determination process 106a in which the second type workflow is set may be generated.
  • the performance determination process 106a predicts the network load with a probability according to the amount of computer resources used when the performance index value indicated by the performance index value data satisfies a predetermined condition. It may be determined that it is necessary.
  • the process shown in S207 may be executed with the probability shown in FIG. 12.
  • the execution probability of the process shown in S207 may be 1. That is, the process shown in S207 may be executed.
  • the execution probability of the process shown in S207 is 0.5. There may be. Here, for example, it may be determined whether or not to execute the process shown in S207 using pseudo-random numbers.
  • the execution probability of the process shown in S207 may be 0. That is, the process shown in S207 may not be executed.
  • the prediction determination process 106b monitors the output of estimation result data from the estimation process 108 associated with the prediction determination process 106b (S301).
  • the prediction determination process 106b acquires the estimation result data (S302).
  • the prediction determination process 106b determines whether the predicted value indicating the height of the network load indicated by the prediction result data obtained in the process shown in S302 exceeds the threshold th3 (S303).
  • the policy manager section 90, life cycle management section 94, container management section 78, and configuration management section 76 execute the relevant performance determination process 106a.
  • the scale-out of the element associated with is executed (S304).
  • the prediction determination process 106b terminates (kills) the estimation process 108 associated with the prediction determination process 106b and its own process (S305), and the processing shown in this processing example is terminated. .
  • the performance determination process 106a determines that the performance index value indicated by the acquired performance index value data is It may be determined whether or not it is below the threshold value th4. Then, when it is determined that the actual performance determination process 106a is below the threshold th4, the performance determination process 106a terminates (kills) the estimation process 108 and the prediction determination process 106b associated with the performance determination process 106a. ) is also good.
  • scaling out of elements of the core network system 34 may be performed instead of elements of the RAN 32 such as gNB.
  • elements of the RAN 32 such as gNB.
  • scaling out of the AMF 46, SMF 48, and UPF 50 may be performed.
  • performance index value data related to the elements of the core network system 34 may be used to determine whether to perform scale-out.
  • performance index value data regarding the elements of the RAN 32 and the elements of the core network system 34 may be used for the determination.
  • transport scale-out may be performed in a similar manner.
  • 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.
  • performance index value data acquisition means for acquiring performance index value data indicating actual values of performance index values related to the communication system; a first determination means for determining whether network load prediction is necessary based on the performance index value data; Prediction starting means for starting network load prediction in response to determining that network load prediction is necessary; a second determination unit that determines whether or not scale-out is necessary based on the network load prediction result after the network load prediction has started; Scale-out execution means for scaling out elements included in the communication system in response to determining that scale-out is necessary;
  • a scale-out execution system comprising: [2] further comprising third determining means for determining whether or not scale-out is necessary based on the performance index value data without depending on the network load prediction result, The scale-out execution means executes scale-out of the elements included in the communication system in response to the second determination means or the third determination means determining that scale-out is necessary.
  • the scale-out execution system characterized in that: [3] The first determining means determines that network load prediction is necessary when a value indicating the height of the network load indicated by the performance index value data exceeds a first threshold; The third determining means determines that scale-out is necessary when a value indicating the height of the network load indicated by the performance index value data exceeds a second threshold that is larger than the first threshold.
  • the scale-out execution system according to [2], characterized in that: [4] In response to the performance index value data being enqueued in the queue in which the performance index value data is stored, the third determining means determines whether or not scale-out is necessary based on the enqueued performance index value data.
  • the second determining means determines whether the performance index value data of the nearest neighbor constant or the nearest neighbor period includes at least the enqueued performance index value data, of the performance index value data stored in the queue. Determine whether scale-out is necessary based on network load prediction results.
  • the scale-out execution system according to [2] or [3], characterized in that: [5]
  • the first determining means determines whether network load prediction is necessary based on the performance index value data and the amount of computer resources used.
  • the scale-out execution system according to any one of [1] to [4], characterized in that: [6]
  • the method further includes execution determining means for determining whether or not to perform a determination as to whether network load prediction is necessary based on the amount of computer resources used, depending on the importance of the element to be scaled out.
  • the scale-out execution system characterized in that: [7]
  • the first determining means determines that network load prediction is necessary with a probability depending on the usage amount of computer resources when the actual value of the performance index value indicated by the performance index value data satisfies a predetermined condition.
  • the scale-out execution system according to [5] or [6], characterized in that: [8] Further comprising: prediction termination means for terminating network load prediction in response to satisfying a predetermined condition;
  • the scale-out execution system according to any one of [1] to [7], characterized in that: [9] Obtaining performance index value data indicating actual performance index values related to the communication system; Determining whether network load prediction is necessary based on the performance index value data; Initiating network load prediction in response to determining that network load prediction is necessary; After network load prediction has started, determining whether scale-out is necessary based on the network load prediction result; performing scaling out of elements included in the communication system in response to determining that scaling out is necessary;
  • a scale-out execution method characterized by comprising:

Landscapes

  • Engineering & Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (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）も、本説明においてＶＮＦに含まれる。本実施形態では、ネットワークサービスが１又は複数のＣＮＦによって実装されるものとして説明する。また、本実施形態に係る機能ユニットは、ネットワークノードに相当するものであってもよい。
　図３は、稼働中のネットワークサービスの一例を模式的に示す図である。図３に示すネットワークサービスには、複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ４４（ＣＵ－ＣＰ（Central Unit - Control Plane）４４ａ、及び、ＣＵ－ＵＰ（Central Unit - User Plane）４４ｂ）、複数のＡＭＦ（Access and Mobility Management Function）４６、複数のＳＭＦ（Session Management Function）４８、及び、複数のＵＰＦ（User Plane 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）部６２、サービスカタログ記憶部６４、ビッグデータプラットフォーム部６６、データバス部６８、ＡＩ（Artificial Intelligence）部７０、監視機能部７２、ＳＤＮコントローラ７４、構成管理部７６、コンテナ管理部７８、リポジトリ部８０、が含まれている。そして、ＯＳＳ部６０には、インベントリデータベース８２、チケット管理部８４、障害管理部８６、性能管理部８８、が含まれている。そして、Ｅ２ＥＯ部６２には、ポリシーマネージャ部９０、スライスマネージャ部９２、ライフサイクル管理部９４、が含まれている。これらの要素は、プロセッサ３０ａ、記憶部３０ｂ、及び、通信部３０ｃを主として実装される。
　図５に示す機能は、１又は複数のコンピュータであるプラットフォームシステム３０にインストールされ、当該機能に対応する指令を含むプログラムをプロセッサ３０ａが実行することにより、実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してプラットフォームシステム３０に供給されてもよい。また、図５に示す機能が、回路ブロック、メモリ、その他のＬＳＩで実装されてもよい。また、図５に示す機能が、ハードウェアのみ、ソフトウェアのみ、又はそれらの組合せといった様々な形態で実現できることは、当業者には理解されるところである。
　コンテナ管理部７８は、コンテナのライフサイクル管理を実行する。例えば、コンテナのデプロイや設定などといったコンテナの構築に関する処理が当該ライフサイクル管理に含まれる。
　ここで、本実施形態に係るプラットフォームシステム３０に、複数のコンテナ管理部７８が含まれていてもよい。そして、複数のコンテナ管理部７８のそれぞれには、クバネテス等のコンテナ管理ツール、及び、ヘルム（Ｈｅｌｍ）等のパッケージマネージャがインストールされていてもよい。そして、複数のコンテナ管理部７８は、それぞれ、当該コンテナ管理部７８に対応付けられるサーバ群（例えばクバネテスクラスタ）に対して、コンテナのデプロイ等のコンテナの構築を実行してもよい。
　なお、コンテナ管理部７８は、プラットフォームシステム３０に含まれている必要はない。コンテナ管理部７８は、例えば、当該コンテナ管理部７８によって管理されるサーバ（すなわち、ＲＡＮ３２やコアネットワークシステム３４）に設けられていてもよいし、あるいは、当該コンテナ管理部７８によって管理されるサーバに併設されている他のサーバに設けられていてもよい。
　リポジトリ部８０は、本実施形態では例えば、ネットワークサービスを実現する機能ユニット群（例えば、ＮＦ群）に含まれるコンテナのコンテナイメージを記憶する。
　インベントリデータベース８２は、インベントリ情報が格納されたデータベースである。当該インベントリ情報には、例えば、ＲＡＮ３２やコアネットワークシステム３４に配置され、プラットフォームシステム３０で管理されているサーバについての情報が含まれる。
　また本実施形態では、インベントリデータベース８２には、インベントリデータが記憶されている。インベントリデータには、通信システム１に含まれる要素群の構成や要素間の関連付けの現況が示されている。また、インベントリデータには、プラットフォームシステム３０で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。当該インベントリデータは、物理インベントリデータでもよいし、論理インベントリデータでもよい。物理インベントリデータ及び論理インベントリデータについては後述する。
　図６は、物理インベントリデータのデータ構造の一例を示す図である。図６に示す物理インベントリデータは、１つのサーバに対応付けられる。図６に示す物理インベントリデータには、例えば、サーバＩＤ、ロケーションデータ、建物データ、階数データ、ラックデータ、スペックデータ、ネットワークデータ、稼働コンテナＩＤリスト、クラスタＩＤ、などが含まれる。
　物理インベントリデータに含まれるサーバＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバの識別子である。
　物理インベントリデータに含まれるロケーションデータは、例えば、当該物理インベントリデータに対応付けられるサーバのロケーション（例えばロケーションの住所）を示すデータである。
　物理インベントリデータに含まれる建物データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている建物（例えば建物名）を示すデータである。
　物理インベントリデータに含まれる階数データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている階数を示すデータである。
　物理インベントリデータに含まれるラックデータは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されているラックの識別子である。
　物理インベントリデータに含まれるスペックデータは、例えば、当該物理インベントリデータに対応付けられるサーバのスペックを示すデータであり、スペックデータには、例えば、コア数、メモリ容量、ハードディスク容量などといったものが示される。
　物理インベントリデータに含まれるネットワークデータは、例えば、当該物理インベントリデータに対応付けられるサーバのネットワークに関する情報を示すデータであり、ネットワークデータには、例えば、当該サーバが備えるＮＩＣ、当該ＮＩＣが備えるポートの数、当該ポートのポートＩＤなどが示される。
　物理インベントリデータに含まれる稼働コンテナＩＤリストは、例えば、当該物理インベントリデータに対応付けられるサーバで稼働する１又は複数のコンテナに関する情報を示すデータであり、稼働コンテナＩＤリストには、例えば、当該コンテナのインスタンスの識別子（コンテナＩＤ）のリストが示される。
　物理インベントリデータに含まれるクラスタＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバが所属するクラスタ（例えば、クバネテスクラスタ）の識別子である。
　論理インベントリデータには、通信システム１に含まれる複数の要素についての、図４に示されているような要素間の関連付けの現況を示すトポロジーデータが含まれている。例えば、論理インベントリデータには、あるＮＳの識別子と当該ＮＳの配下にある１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。また、例えば、論理インベントリデータには、あるネットワークスライスの識別子と当該ネットワークスライスに所属する１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。
　また、インベントリデータに、通信システム１に含まれる要素間の地理的な関係やトポロジー的な関係などの現況が示すデータが含まれていてもよい。上述の通り、インベントリデータには、通信システム１に含まれる要素が稼働しているロケーション、すなわち、通信システム１に含まれる要素の現在のロケーションを示すロケーションデータが含まれている。このことから、インベントリデータには、要素間の地理的な関係（例えば、要素間の地理的な近さ）の現況が示されていると言える。
　また、論理インベントリデータに、ネットワークスライスに関する情報を示すＮＳＩデータが含まれていてもよい。ＮＳＩデータは、例えば、ネットワークスライスのインスタンスの識別子や、ネットワークスライスの種類等の属性を示す。また、論理インベントリデータに、ネットワークスライスサブネットに関する情報を示すＮＳＳＩデータが含まれていてもよい。ＮＳＳＩデータは、例えば、ネットワークスライスサブネットのインスタンスの識別子や、ネットワークスライスサブネットの種類等の属性を示す。
　また、論理インベントリデータに、ＮＳに関する情報を示すＮＳデータが含まれていてもよい。ＮＳデータは、例えば、ＮＳのインスタンスの識別子や、ＮＳの種類等の属性を示す。また、論理インベントリデータに、ＮＦに関する情報を示すＮＦデータが含まれていてもよい。ＮＦデータは、例えば、ＮＦのインスタンスの識別子や、ＮＦの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに関する情報を示すＣＮＦＣデータが含まれていてもよい。ＣＮＦＣデータは、例えば、インスタンスの識別子や、ＣＮＦＣの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに含まれるｐｏｄに関する情報を示すｐｏｄデータが含まれていてもよい。ｐｏｄデータは、例えば、ｐｏｄのインスタンスの識別子や、ｐｏｄの種類等の属性を示す。また、論理インベントリデータに、ｐｏｄに含まれるコンテナに関する情報を示すコンテナデータが含まれていてもよい。コンテナデータは、例えば、コンテナのインスタンスのコンテナＩＤや、コンテナの種類等の属性を示す。
　論理インベントリデータに含まれるコンテナデータのコンテナＩＤと、物理インベントリデータに含まれる稼働コンテナＩＤリストに含まれるコンテナＩＤと、によって、コンテナのインスタンスと、当該コンテナのインスタンスが稼働しているサーバとが関連付けられることとなる。
　また、ホスト名やＩＰアドレスなどの各種の属性を示すデータが論理インベントリデータに含まれる上述のデータに含まれていても構わない。例えば、コンテナデータに、当該コンテナデータに対応するコンテナのＩＰアドレスを示すデータが含まれていてもよい。また、例えば、ＮＦデータに、当該ＮＦデータが示すＮＦのＩＰアドレス及びホスト名を示すデータが含まれていてもよい。
　また、論理インベントリデータに、各ＮＦに設定されている、１又は複数のＳ－ＮＳＳＡＩを含むＮＳＳＡＩを示すデータが含まれていてもよい。
　また、インベントリデータベース８２は、コンテナ管理部７８と連携して、リソースの状況を適宜把握できるようになっている。そして、インベントリデータベース８２は、リソースの最新の状況に基づいて、インベントリデータベース８２に記憶されているインベントリデータを適宜更新する。
　また、例えば、通信システム１に含まれる新規要素の構築、通信システム１に含まれる要素の構成変更、通信システム１に含まれる要素のスケーリング、通信システム１に含まれる要素のリプレース、などのアクションが実行されることに応じて、インベントリデータベース８２は、インベントリデータベース８２に記憶されているインベントリデータを更新する。
　また、インベントリデータベース８２に、それぞれのＮＦについて、当該ＮＦが設けられているロケーションの重要度を示すデータが含まれていてもよい。例えば、官公庁、消防署、病院などが含まれるエリアをカバーするｇＮＢのインベントリデータに重要エリアフラグが関連付けられていてもよい。
　また、インベントリデータベース８２に、ＮＳ、ＮＦ、ネットワークスライスなどの要素についての、サービスの重要度を示すデータが含まれていてもよい。例えば、購入者によって、購入対象のＮＳが満たすべきＳＬＡが指定されており、当該ＳＬＡに対応する性能を保証する必要がある要素のインベントリデータには、重要サービスフラグが関連付けられていてもよい。
　サービスカタログ記憶部６４は、サービスカタログデータを記憶する。サービスカタログデータには、例えば、ライフサイクル管理部９４によって利用されるロジックなどを示すサービステンプレートデータが含まれていてもよい。このサービステンプレートデータには、ネットワークサービスを構築するために必要な情報が含まれる。例えば、サービステンプレートデータは、ＮＳ、ＮＦ及びＣＮＦＣを定義する情報と、ＮＳ－ＮＦ－ＣＮＦＣの対応関係を示す情報を含む。また、例えば、サービステンプレートデータは、ネットワークサービスを構築するためのワークフローのスクリプトを含む。
　サービステンプレートデータの一例として、ＮＳＤ（NS Descriptor）が挙げられる。ＮＳＤは、ネットワークサービスに対応付けられるものであり、当該ネットワークサービスに含まれる複数の機能ユニット（例えば複数のＣＮＦ）の種類などが示されている。なお、ＮＳＤに、ＣＮＦ等の機能ユニットの種類ごとについての、当該ネットワークサービスに含まれる数が示されていてもよい。また、ＮＳＤに、当該ネットワークサービスに含まれるＣＮＦに係る、後述するＣＮＦＤのファイル名が示されていてもよい。
　また、サービステンプレートデータの一例として、ＣＮＦＤ（CNF Descriptor）が挙げられる。ＣＮＦＤに、当該ＣＮＦが必要とするコンピュータリソース（例えば、ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。例えば、ＣＮＦＤに、当該ＣＮＦに含まれる複数のコンテナのそれぞれについての、当該コンテナが必要とするコンピュータリソース（ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。
　また、サービスカタログデータに、ポリシーマネージャ部９０によって利用される、算出された性能指標値と比較する閾値（例えば異常検出用閾値）に関する情報が含まれていてもよい。性能指標値については後述する。
　また、サービスカタログデータに、例えば、スライステンプレートデータが含まれていてもよい。スライステンプレートデータには、ネットワークスライスのインスタンス化を実行するために必要な情報が含まれ、例えば、スライスマネージャ部９２によって利用されるロジックが含まれる。
　スライステンプレートデータは、ＧＳＭＡ（GSM Association）（「GSM」は登録商標）が定める「Generic Network Slice Template」の情報を含む。具体的には、スライステンプレートデータは、ネットワークスライスのテンプレートデータ（ＮＳＴ）、ネットワークスライスサブネットのテンプレートデータ（ＮＳＳＴ）、ネットワークサービスのテンプレートデータを含む。また、スライステンプレートデータは、図４に示したような、これらの要素の階層構成を示す情報を含む。
　ライフサイクル管理部９４は、本実施形態では例えば、購入者によるＮＳの購入要求に応じて、購入要求がされた新たなネットワークサービスを構築する。
　ライフサイクル管理部９４は、例えば、購入要求に応じて、購入されるネットワークサービスに対応付けられるワークフローのスクリプトを実行してもよい。そして、このワークフローのスクリプトを実行することで、ライフサイクル管理部９４は、コンテナ管理部７８に、購入される新たなネットワークサービスに含まれるコンテナのデプロイを指示してもよい。そして、コンテナ管理部７８は、当該コンテナのコンテナイメージをリポジトリ部８０から取得して、当該コンテナイメージに対応するコンテナを、サーバにデプロイしてもよい。
　また、ライフサイクル管理部９４は、本実施形態では例えば、通信システム１に含まれる要素のスケーリングやリプレースを実行する。ここで、ライフサイクル管理部９４は、コンテナのデプロイ指示や削除指示をコンテナ管理部７８に出力してもよい。そして、コンテナ管理部７８が、当該指示に従い、コンテナのデプロイやコンテナの削除等の処理を実行してもよい。本実施形態ではライフサイクル管理部９４によって、コンテナ管理部７８のクバネテスのようなツールでは対応できないようなスケーリングやリプレースを実行できるようになっている。
　また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、通信経路の作成指示を出力してもよい。例えば、ライフサイクル管理部９４は、作成させる通信経路の両端の２つのＩＰアドレスをＳＤＮコントローラ７４に提示し、ＳＤＮコントローラ７４は、これら２つのＩＰアドレスを結ぶ通信経路を作成する。作成された通信経路は、これら２つのＩＰアドレスに関連付けられて管理されてもよい。
　また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、２つのＩＰアドレスに関連付けられた、これら２つのＩＰアドレス間の通信経路の作成指示を出力してもよい。
　スライスマネージャ部９２は、本実施形態では例えば、ネットワークスライスのインスタンス化を実行する。スライスマネージャ部９２は、本実施形態では例えば、サービスカタログ記憶部６４に記憶されているスライステンプレートが示すロジックを実行することで、ネットワークスライスのインスタンス化を実行する。
　スライスマネージャ部９２は、例えば、３ＧＰＰ（登録商標）（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)」に記載された性能指標についての性能指標値を監視してもよい。そして、監視機能部７２は、監視される性能指標値を示すメトリックデータを取得してもよい。
　そして、監視機能部７２は、本実施形態では、例えば、所定の集計単位で、メトリックデータを集計する処理（エンリッチメント）を実行することで、当該集計単位における、通信システム１に含まれる要素の性能指標値を示す性能指標値データを生成する。
　例えば、１つのｇＮＢについて、当該ｇＮＢの配下にある要素（例えば、ＤＵ４２やＣＵ４４などのネットワークノード）のメトリックを示すメトリックデータを集計することで、当該ｇＮＢの性能指標値データを生成する。このようにして、当該ｇＮＢがカバーするエリアにおける通信性能を示す性能指標値データが生成される。ここで、例えば、各ｇＮＢにおいて、トラフィック量（スループット）やレイテンシなどといった複数種類の通信性能を示す性能指標値データが生成されてもよい。なお、性能指標値データが示す通信性能は、トラフィック量やレイテンシには限定されない。
　そして、監視機能部７２は、上述のエンリッチメントによって生成される性能指標値データを、データバス部６８に出力する。
　データバス部６８は、本実施形態では例えば、監視機能部７２から出力される性能指標値データを受け付ける。そして、データバス部６８は、受け付ける１又は複数の性能指標値データに基づいて、当該１又は複数の性能指標値データを含む性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。
　また、通信システム１に含まれるネットワークスライス、ＮＳ、ＮＦ、ＣＮＦＣ等の要素や、サーバ等のハードウェアは、監視機能部７２に、各種のアラートの通知（例えば、障害の発生をトリガとしたアラートの通知）を行う。
　そして、監視機能部７２は、例えば、上述のアラートの通知を受け付けると、当該通知を示すアラートメッセージデータをデータバス部６８に出力する。そして、データバス部６８は、１又は複数の通知を示すアラートメッセージデータを１つのファイルにまとめたアラートファイルを生成して、当該アラートファイルをビッグデータプラットフォーム部６６に出力する。
　ビッグデータプラットフォーム部６６は、本実施形態では例えば、データバス部６８から出力される性能指標値ファイルやアラートファイルを蓄積する。
　ＡＩ部７０には、本実施形態では例えば、学習済の機械学習モデルが予め複数記憶されている。ＡＩ部７０は、ＡＩ部７０に記憶されている各種の機械学習モデルを用いて、通信システム１の利用状況やサービス品質の将来予測処理などの推定処理を実行する。ＡＩ部７０は、推定処理の結果を示す推定結果データを生成してもよい。
　ＡＩ部７０は、ビッグデータプラットフォーム部６６に蓄積されるファイルと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、長期的なトレンドの予測を低頻度で行う場合に好適である。
　また、ＡＩ部７０は、データバス部６８に格納されている性能指標値データを取得可能になっている。ＡＩ部７０は、データバス部６８に格納されている性能指標値データと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、短期的な予測を高頻度で行う場合に好適である。
　性能管理部８８は、本実施形態では例えば、複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、ＫＰＩ）を算出する。性能管理部８８は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してもよい。性能管理部８８は、総合評価である性能指標値を示す総合性能指標値データを生成してもよい。
　なお、性能管理部８８は、ビッグデータプラットフォーム部６６から上述の性能指標値ファイルを取得してもよい。また、性能管理部８８は、ＡＩ部７０から推定結果データを取得してもよい。そして、性能指標値ファイル又は推定結果データのうちの少なくとも一方に基づいて、ＫＰＩ等の性能指標値を算出してもよい。なお、性能管理部８８が、監視機能部７２からメトリックデータを直接取得してもよい。そして、当該メトリックデータに基づいて、ＫＰＩ等の性能指標値を算出してもよい。
　障害管理部８６は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の推定結果データ、上述の総合性能指標値データのうちの少なくともいずれかに基づいて、通信システム１における障害の発生を検出する。障害管理部８６は、例えば、所定のロジックに基づいて、単一のメトリックデータや単一のアラートの通知からでは検出できないような障害の発生を検出してもよい。障害管理部８６は、検出された障害を示す検出障害データを生成してもよい。
　なお、障害管理部８６は、メトリックデータやアラートの通知を、監視機能部７２から直接取得してもよい。また、障害管理部８６は、ビッグデータプラットフォーム部６６から性能指標値ファイルやアラートファイルを取得してもよい。また、障害管理部８６は、データバス部６８から、アラートメッセージデータを取得してもよい。
　ポリシーマネージャ部９０は、本実施形態では例えば、上述のメトリックデータ、上述の性能指標値データ、上述のアラートメッセージデータ、上述の性能指標値ファイル、上述のアラートファイル、上述の推定結果データ、上述の総合性能指標値データ、上述の検出障害データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。
　そして、ポリシーマネージャ部９０は、判定処理の結果に応じたアクションを実行してもよい。例えば、ポリシーマネージャ部９０は、スライスマネージャ部９２にネットワークスライスの構築指示を出力してもよい。また、ポリシーマネージャ部９０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示をライフサイクル管理部９４に出力してもよい。
　本実施形態に係るポリシーマネージャ部９０は、データバス部６８に格納されている性能指標値データを取得可能になっている。そして、ポリシーマネージャ部９０は、データバス部６８から取得される性能指標値データに基づいて、所定の判定処理を実行してもよい。また、ポリシーマネージャ部９０は、データバス部６８に格納されているアラートメッセージデータに基づいて、所定の判定処理を実行してもよい。
　チケット管理部８４は、本実施形態では例えば、通信システム１の管理者に通知すべき内容が示されたチケットを生成する。チケット管理部８４は、発生障害データの内容を示すチケットを生成してもよい。また、チケット管理部８４は、性能指標値データやメトリックデータの値を示すチケットを生成してもよい。また、チケット管理部８４は、ポリシーマネージャ部９０による判定結果を示すチケットを生成してもよい。
　そして、チケット管理部８４は、生成されたチケットを、通信システム１の管理者に通知する。チケット管理部８４は、例えば、生成されたチケットが添付された電子メールを、通信システム１の管理者の電子メールアドレスに宛てて送信してもよい。
　以下、性能指標値ファイルの生成、データバス部６８に格納されている性能指標値データに基づく判定処理、及び、データバス部６８に格納されている性能指標値データに基づく推定処理について、さらに説明する。
　図７は、本実施形態に係るデータバス部６８の一例を模式的に示す図である。図７に示すように、本実施形態に係るデータバス部６８には、例えば、性能指標値データを先入れ先出しのリスト構造で保持するキュー１００が複数含まれている。
　そして、それぞれのキュー１００は、第１キュー群１０２ａ、又は、第２キュー群１０２ｂのいずれかに属している。
　また、本実施形態では例えば、監視機能部７２において、複数の集計プロセス１０４が動作している。それぞれの集計プロセス１０４には、当該集計プロセス１０４での集計対象である要素が予め設定されている。例えば、それぞれの集計プロセス１０４には、当該集計プロセス１０４での集計対象であるｇＮＢが予め設定されている。そして、それぞれの集計プロセス１０４は、当該集計プロセス１０４での集計対象でのｇＮＢの配下にあるＮＦ（例えば、ＲＵ４０、ＤＵ４２、及び、ＣＵ－ＵＰ４４ｂ）からメトリックデータを取得する。そして、当該集計プロセス１０４は、取得するメトリックデータに基づいて、当該ｇＮＢの通信性能を示す性能指標値データを生成するエンリッチメント処理を実行する。
　また、本実施形態では例えば、集計プロセス１０４とキュー１００とが予め関連付けられている。なお、便宜上、図７では、集計プロセス１０４とキュー１００とが１対１の関係で関連付けられていることが示されているが、集計プロセス１０４とキュー１００とが多対多の関係で関連付けられていてもよい。
　以下、第１キュー群１０２ａに含まれるキュー１００に関連付けられている集計プロセス１０４を、第１群集計プロセス１０４ａと呼ぶこととする。また、第２キュー群１０２ｂに含まれるキュー１００に関連付けられている集計プロセス１０４を、第２群集計プロセス１０４ｂと呼ぶこととする。
　そして、それぞれの第１群集計プロセス１０４ａが、所定の時間間隔で（例えば、１分おきに）、当該第１群集計プロセス１０４ａに対応付けられる、前回の集計から現時点までのメトリックデータを集計することで、性能指標値データを生成する。
　第１群集計プロセス１０４ａは、例えば、１分間隔で、当該第１群集計プロセス１０４ａに対応付けられる１又は複数のＮＦからメトリックデータを取得する。そして、当該第１群集計プロセス１０４ａは、同じ集計期間のメトリックデータを集計することで、当該集計期間における性能指標値データを生成する。
　そして、当該第１群集計プロセス１０４ａは、性能指標値データを生成する度に、当該第１群集計プロセス１０４ａに関連付けられている１又は複数のキュー１００に、当該性能指標値データをエンキューする。
　そして、それぞれの第２群集計プロセス１０４ｂが、所定の時間間隔で（例えば、１５分おきに）、当該第２群集計プロセス１０４ｂに対応付けられる、前回の集計から現時点までのメトリックデータを集計することで、性能指標値データを生成する。
　第２群集計プロセス１０４ｂは、例えば、１５分間隔で、当該第２群集計プロセス１０４ｂに対応付けられる１又は複数のＮＦからメトリックデータを取得する。そして、当該第２群集計プロセス１０４ｂは、同じ集計期間のメトリックデータを集計することで、当該集計期間における性能指標値データを生成する。
　そして、当該第２群集計プロセス１０４ｂは、性能指標値データを生成する度に、当該第２群集計プロセス１０４ｂに関連付けられている１又は複数のキュー１００に、当該性能指標値データをエンキューする。
　本実施形態では、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数は予め定められている。ここでは例えば、最大で２４０個の性能指標値データがキュー１００に格納可能であることとする。つまり、最大数は「２４０」とする。
　また、本実施形態では、第２キュー群１０２ｂに含まれるキュー１００に格納可能な性能指標値データの最大数は予め定められている。ここでは例えば、最大で４個の性能指標値データがキュー１００に格納可能であることとする。つまり、最大数は「４」とする。
　本実施形態において、例えば、ある１つのＮＦが、第１群集計プロセス１０４ａにも第２群集計プロセス１０４ｂにも関連付けられていてもよい。そして、当該ＮＦが、当該第１群集計プロセス１０４ａには、当該第１群集計プロセス１０４ａにおいて集計される種類のメトリックデータを１分間隔で出力してもよい。そして、当該ＮＦが、当該第２群集計プロセス１０４ｂには、当該第２群集計プロセス１０４ｂにおいて集計される種類のメトリックデータを１５分間隔で出力してもよい。
　当該第１群集計プロセス１０４ａに出力されるメトリックデータの種類と、当該第２群集計プロセス１０４ｂに出力されるメトリックデータの種類とは、同じであってもよいし異なっていてもよい。
　ここで例えば、当該ＮＦにおいて監視されるべきメトリックのうち、リアルタイムでの監視がされることが望ましい一部のメトリックについてのメトリックデータが、第１群集計プロセス１０４ａに出力されるようにしてもよい。
　そして、本実施形態では例えば、ポリシーマネージャ部９０において、複数の判定プロセス１０６（図８、及び、図９参照）が動作している。これらの判定プロセス１０６のうちの一部は、データバス部６８に格納されている性能指標値データに基づく判定処理を実行し、残りは、ビッグデータプラットフォーム部６６に格納されているファイルに基づく判定処理を実行する。
　本実施形態に係る判定プロセス１０６のなかには、通信システム１に係る性能指標値の実績値を示す性能指標値データを取得するものがある。例えば、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、当該性能指標値データを取得する判定プロセス１０６がある。
　なお、本実施形態では、第１キュー群１０２ａに含まれるキュー１００については、当該キュー１００に含まれるいずれの性能指標値データにも、デキューすることなくアクセスできるように（取得できるように）になっている。
　そして、当該判定プロセス１０６は、取得する性能指標値データに基づいて、通信システム１の状態を判定する。ここで例えば、通信システム１に含まれる、当該判定プロセス１０６に対応付けられる要素の状態が判定されてもよい。例えば、当該判定プロセス１０６が取得する性能指標値データを生成した第１群集計プロセス１０４ａでの集計対象である要素の状態が判定されてもよい。以下、このような判定プロセス１０６を実績判定プロセス１０６ａと呼ぶこととする。
　本実施形態では例えば、実績判定プロセス１０６ａとキュー１００とが予め関連付けられている。なお、便宜上、図８、及び、図９では、実績判定プロセス１０６ａとキュー１００とが１対１の関係で関連付けられていることが示されているが、実績判定プロセス１０６ａとキュー１００とが多対多の関係で関連付けられていてもよい。
　ここで例えば、データバス部６８は、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、当該キュー１００に関連付けられている１又は複数の実績判定プロセス１０６ａに、性能指標値データがエンキューされたことを示す通知を出力してもよい。
　そして、当該通知を受け付けた実績判定プロセス１０６ａが、当該通知の受付に応じて、当該キュー１００に格納された最新の性能指標値データを取得してもよい。
　また、本実施形態に係る判定プロセス１０６のなかには、当該判定プロセス１０６に関連付けられている推定プロセス１０８（図９参照）による推定結果を示す推定結果データを取得するものがある。そして、当該判定プロセス１０６は、取得する推定結果データに基づいて、通信システム１の状態を判定する。ここで例えば、通信システム１に含まれる、当該判定プロセス１０６に対応付けられる要素の状態が判定されてもよい。例えば、当該推定プロセス１０８が取得する性能指標値データを生成した第１群集計プロセス１０４ａでの集計対象である要素の状態が判定されてもよい。以下、このような判定プロセス１０６を予測判定プロセス１０６ｂと呼ぶこととする。
　また、本実施形態では例えば、ＡＩ部７０において、複数の推定プロセス１０８（図９参照）が動作している。これらの推定プロセス１０８のうちの一部は、データバス部６８に格納されている性能指標値データに基づく推定処理を実行し、残りは、ビッグデータプラットフォーム部６６に格納されているファイルに基づく推定処理を実行する。
　また、本実施形態では例えば、推定プロセス１０８とキュー１００とが予め関連付けられている。なお、便宜上、図８では、推定プロセス１０８とキュー１００とが１対１の関係で関連付けられていることが示されているが、推定プロセス１０８とキュー１００とが多対多の関係で関連付けられていてもよい。
　そして本実施形態では例えば、それぞれの推定プロセス１０８が、当該推定プロセス１０８に対応する、第１キュー群１０２ａに含まれるキュー１００に格納されている性能指標値データを取得する。そして、当該推定プロセスは、当該性能指標値データに基づいて、当該推定プロセス１０８において予め定められている推定処理を実行する。
　ここで、推定プロセス１０８は、例えば、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、当該キュー１００に格納されている性能指標値データのうちの最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得する。
　ここで例えば、データバス部６８は、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、当該キュー１００に関連付けられている１又は複数の推定プロセス１０８に、性能指標値データがエンキューされたことを示す通知を出力してもよい。
　そして、当該通知を受け付けた推定プロセス１０８が、当該通知の受付に応じて、当該キュー１００に格納されている性能指標値データのうちの当該最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得してもよい。
　ここでは例えば、図９に示されている推定プロセス１０８は、最新の性能指標値データを含む、６０個の推定指標値データを取得する。これらの性能指標値データは、最新の性能指標値データを含む直近６０分の性能指標値データに相当する。そして、当該推定プロセス１０８は、当該性能指標値データに基づいて、推定処理を実行する。
　例えば、ある特定のｇＮＢに対応付けられる第１群集計プロセス１０４ａが、当該ｇＮＢに含まれる要素（例えば、当該ｇＮＢの配下にある要素）に係るメトリックデータを集計することによって、当該ｇＮＢに係る性能指標値データを生成するとする。そして、当該第１群集計プロセス１０４ａにより生成される性能指標値データを取得する推定プロセス１０８が、キュー１００に当該性能指標値データがエンキューされたことに応じて、当該キュー１００に格納されている最新の性能指標値データを含む６０個の性能指標値データを取得するとする。
　この場合、当該推定プロセス１０８が、ＡＩ部７０に予め記憶されている学習済の機械学習モデルを用いて、これら６０個の性能指標値データに基づいて、現時点から現時点の２０分先までの当該ｇＮＢのネットワーク負荷の高さを予測する。ここで例えば、ｇＮＢのネットワーク負荷の高さとして、トラフィック量（スループット）やレイテンシなどの予測が実行されてもよい。
　この機械学習モデルは、例えば、既存の予測モデルであっても構わない。また、例えば、この機械学習モデルは、複数の訓練データを用いた教師あり学習が予め実行された学習済の機械学習モデルであってもよい。そして、これら複数の訓練データのそれぞれには、例えば、互いに異なる所与の時点についての、当該ｇＮＢにおける当該時点までの６０分のトラフィック量を示す学習入力データと、当該ｇＮＢにおける当該時点から当該時点の２０分先までのネットワーク負荷の高さ（例えば、トラフィック量やレイテンシ）を示す教師データとが含まれていてもよい。
　なお、推定プロセス１０８は、上述のようにキュー１００に格納されている性能指標値データの一部を取得する必要はなく、キュー１００に格納されているすべての性能指標値データを取得してもよい。
　そして、当該推定プロセス１０８は、推定処理の実行結果（推定結果）を示す推定結果データを、当該推定プロセス１０８に関連付けられている予測判定プロセス１０６ｂに出力する。すると、当該予測判定プロセス１０６ｂが、当該推定結果データを取得する。そして、当該予測判定プロセス１０６ｂが、取得する推定結果データに基づいて、通信システム１の状態を判定する。
　以上のように、本実施形態に係るキュー１００には、集計プロセス１０４、実績判定プロセス１０６ａ、予測判定プロセス１０６ｂ、及び、推定プロセス１０８が関連付けられている。
　また、データバス部６８は、本実施形態では例えば、ＡＩ部７０が性能指標値データを取得する頻度よりも少ない頻度で、キュー１００に格納されている性能指標値データのうちの少なくとも一部を含む性能指標値ファイルを生成する。
　例えば、データバス部６８が、所定の時間間隔で、性能指標値ファイルが前回生成されたタイミングより後に当該キュー１００に格納された性能指標値データを含む性能指標値ファイルを生成してもよい。
　ここで、当該時間間隔は、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数に相当する時間（上述の例では６０分）と一致していてもよいし、一致していなくてもよい。
　また、例えば、データバス部６８が、生成された性能指標値ファイルに含まれる性能指標値データがすべてデキューされたことに応じて、当該キュー１００に格納されているすべての性能指標値データを含むファイルを生成してもよい。すなわち、キュー１００に格納されている性能指標値データがすべて入れ替わったことに応じて、当該キュー１００に格納されているすべての性能指標値データを含むファイルが生成されてもよい。
　また、本実施形態では、第１キュー群１０２ａに含まれるキュー１００に６０個の性能指標値データが格納されている際に、新たな性能指標値データがエンキューされると、当該キュー１００に格納されている最も古い性能指標値データがデキューされる。すなわち、当該キュー１００に格納されている最も古い性能指標値データは、当該キュー１００から消去される。
　そして、本実施形態では、第２キュー群１０２ｂに含まれるキュー１００に４個の性能指標値データが格納されると、データバス部６８は、これら４個の性能指標値データを１つのファイルにまとめた性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。
　そして、データバス部６８は、当該キュー１００に格納されているすべての性能指標値データをデキューする。すなわち、当該キュー１００に格納されているすべての性能指標値データは、当該キュー１００から消去される。
　このように、第１キュー群１０２ａに含まれるキュー１００と、第２キュー群１０２ｂに含まれるキュー１００とでは、性能指標値ファイルが生成されたことに応じて実行される処理が異なる。第２キュー群１０２ｂに含まれるキュー１００では、性能指標値ファイルの生成に応じて、当該キュー１００に格納されているすべての性能指標値データが当該キュー１００から消去される。一方で、第１キュー群１０２ａに含まれるキュー１００では、性能指標値ファイルの生成に応じたデキューは実行されない。
　本実施形態では例えば、ネットワークサービスが構築される際に、当該ネットワークサービスに含まれる要素だけでなく、図８に示すように、当該要素に関連付けられているキュー１００、集計プロセス１０４、及び、実績判定プロセス１０６ａが生成される。
　このとき、ポリシーマネージャ部９０は、インベントリデータを参照して、生成される実績判定プロセス１０６ａに対応付けられる要素の属性を確認してもよい。そして、ポリシーマネージャ部９０は、確認された属性に応じたワークフローが設定された実績判定プロセス１０６ａを生成してもよい。そして、実績判定プロセス１０６ａは、当該実績判定プロセス１０６ａに設定されたワークフローを実行することで判定処理を実行してもよい。
　そして、本実施形態では例えば、実績判定プロセス１０６ａは、取得した性能指標値データに基づいて、スケールアウトの要否を判定する。
　そして、プラットフォームシステム３０は、本実施形態では例えば、スケールアウトが必要であると判定されることに応じて、通信システム１に含まれる要素のスケールアウトを実行する。例えば、ポリシーマネージャ部９０、ライフサイクル管理部９４、コンテナ管理部７８、及び、構成管理部７６が、互いに連携してスケールアウトを実行してもよい。例えば、ある特定のｇＮＢに係る性能指標値データに基づいて、スケールアウトが必要であると判定されることに応じて、当該ｇＮＢに含まれるＤＵ４２やＣＵ－ＵＰ４４ｂのスケールアウトが実行されてもよい。
　例えば、実績判定プロセス１０６ａは、取得した性能指標値データが所定の第１スケールアウト条件を満たすか否かを判定してもよい。ここで、性能指標値データが示す性能指標値が閾値ｔｈ１を超えるか否かが判定されてもよい。この性能指標値は、トラフィック量（スループット）、レイテンシ、などといった、ネットワーク負荷の高さを示す値であってもよい。そして、第１スケールアウト条件を満たすと判定されること（例えば、性能指標値が閾値ｔｈ１を超えると判定されること）に応じて、通信システム１に含まれる要素のスケールアウトが実行されてもよい。
　また、当該実績判定プロセス１０６ａは、本実施形態では例えば、取得した性能指標値データに基づいて、ネットワーク負荷の予測要否を判定する。そして、プラットフォームシステム３０は、本実施形態では例えば、ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測を開始する。
　また、例えば、実績判定プロセス１０６ａは、取得した性能指標値データが所定の予測開始条件を満たすか否かを判定してもよい。例えば、性能指標値データが示す性能指標値が閾値ｔ２を超えるか否かが判定されてもよい。ここで、この閾値ｔｈ２は、上述の閾値ｔｈ１よりも小さい値であってもよい。すなわち、上述の閾値ｔｈ１は、閾値ｔｈ２よりも大きな値であってもよい。そして、予測開始条件を満たすと判定されること（例えば、性能指標値が閾値ｔｈ２を超えると判定されること）に応じて、ネットワーク負荷の予測が開始されてもよい。
　上述のように、本実施形態において、実績判定プロセス１０６ａは、性能指標値データが示すネットワーク負荷の高さを示す値が第１の閾値（例えば上述の閾値ｔｈ２）を超える場合に、ネットワーク負荷の予測が必要であると判定してもよい。そして、実績判定プロセス１０６ａは、性能指標値データが示すネットワーク負荷の高さを示す値が第１の閾値よりも大きな第２の閾値（例えば上述の閾値ｔｈ１）を超える場合に、スケールアウトが必要であると判定してもよい。
　例えば、図８に示すように、実績判定プロセス１０６ａが動作している状況において、実績判定プロセス１０６ａによって、ネットワーク負荷の予測が必要であると判定されたとする。例えば、所定の予測開始条件を満たしたとする。
　すると、ＡＩ部７０が、当該実績判定プロセス１０６ａに関連付けられている推定プロセス１０８を生成し、ポリシーマネージャ部９０が、当該実績判定プロセス１０６ａに関連付けられている予測判定プロセス１０６ｂを生成する。ここで例えば、推定プロセス１０８、及び、予測判定プロセス１０６ｂが起動するようにしてもよい。また、このときに、学習済の機械学習モデルのインスタンス化が併せて実行されてもよい。そして、当該推定プロセス１０８が、このようにしてインスタンス化された機械学習モデルを用いた推定を実行してもよい。
　そして、予測判定プロセス１０６ｂは、当該予測判定プロセス１０６ｂに関連付けられている推定プロセス１０８が出力する推定結果データに基づいて、所定の判定処理を実行してもよい。例えば、予測判定プロセス１０６ｂは、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定してもよい。
　本実施形態において例えば、図９に示すように、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、実績判定プロセス１０６ａが、エンキューされた性能指標値データを取得し、推定プロセス１０８が、当該キュー１００に格納されている性能指標値データのうちの、当該エンキューされた性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得してもよい。このように、キュー１００に性能指標値データがエンキューされたことに応じて、エンキューされた性能指標値データが、実績判定プロセス１０６ａにも推定プロセス１０８にも取得されるようにしてもよい。
　そして、実績判定プロセス１０６ａが、取得する性能指標値データに基づいて、スケールアウトの要否を判定してもよい。
　また、推定プロセス１０８が、取得する性能指標値データに基づいて、ネットワーク負荷の予測結果を示す推定結果データを生成してもよい。そして、推定プロセス１０８が、生成される推定結果データを予測判定プロセス１０６ｂに出力してもよい。そして、予測判定プロセス１０６ｂが、当該推定結果データを取得してもよい。
　そして、予測判定プロセス１０６ｂが、取得する推定結果データに基づいて、スケールアウトの要否を判定してもよい。
　なお、ＡＩ部７０が推定プロセス１０８を生成し、ポリシーマネージャ部９０が予測判定プロセス１０６ｂを生成する必要はない。例えば、実績判定プロセス１０６ａが、推定プロセス１０８、及び、ポリシーマネージャ部９０を生成してもよい。
　そして、プラットフォームシステム３０は、本実施形態では例えば、スケールアウトが必要であると判定されることに応じて、通信システム１に含まれる要素のスケールアウトを実行する。
　例えば、予測判定プロセス１０６ｂは、推定結果データが示すネットワーク負荷の予測値が所定の第２スケールアウト条件を満たすか否かを判定してもよい。例えば、当該予測値が閾値ｔｈ３を超えるか否かが判定されてもよい。ここで例えば、現時点から現時点の２０分先までの複数の予測値のうちに、閾値ｔｈ３を超えるものがあるか否かが判定されてもよい。この予測値は、トラフィック量（スループット）、レイテンシ、などといった、ネットワーク負荷の高さを示す値であってもよい。そして、第２スケールアウト条件を満たすと判定されることに応じて、通信システム１に含まれる要素のスケールアウトが実行されてもよい。なお、第２スケールアウト条件は、上述の第１スケールアウト条件と同じであってもよいし異なっていてもよい。
　上述のように、本実施形態では、予測判定プロセス１０６ｂは、ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定する。一方、実績判定プロセス１０６ａは、ネットワーク負荷の予測結果に依存することなく、性能指標値データに基づいて、スケールアウトの要否を判定する。
　そして、実績判定プロセス１０６ａ、又は、予測判定プロセス１０６ｂによってスケールアウトが必要であると判定されることに応じて、ポリシーマネージャ部９０、ライフサイクル管理部９４、コンテナ管理部７８、及び、構成管理部７６は、通信システム１に含まれる要素のスケールアウトを実行する。
　また、本実施形態において、所定の条件を満たすことに応じて、推定プロセス１０８が、ネットワーク負荷の予測を終了する。すなわち、推定プロセス１０８、及び、予測判定プロセス１０６ｂが、消失、又は、停止する。このようにして、本実施形態によれば、ネットワーク負荷の常時予測を行わないようにすることで（言い換えれば、定期的な、あるいは、一時的な予測を終了することで）、コンピュータリソースのキャパシティや消費電力の無駄が抑えられる。ネットワーク負荷の予測の終了条件は、通信システム１の仕様、通信システム１を利用するユーザの要求などに応じて、適宜に定められるようにして構わない。
　例えば、上述のようにして要素のスケールアウトが実行されたことに応じて、当該要素に対応付けられる推定プロセス１０８、及び、予測判定プロセス１０６ｂが終了（プロセスキル）するようにしてもよい。
　また、予測判定プロセス１０６ｂによって、推定結果データが示すネットワーク負荷の予測値が閾値ｔｈ４を下回るか否かが判定されてもよい。そして、推定結果データが示すネットワーク負荷の予測値が閾値ｔｈ４を下回ったと判定されたことに応じて、当該予測判定プロセス１０６ｂ、及び、当該予測判定プロセス１０６ｂに関連付けられている推定プロセス１０８が終了（プロセスキル）するようにしてもよい。
　ここで、本実施形態に係るプラットフォームシステム３０で行われる、実績判定プロセス１０６ａによる通信システム１の状態判定に関する処理の流れの一例を、図１０に例示するフロー図を参照しながら説明する。
　本処理例では、データバス部６８が、第１キュー群１０２ａに含まれるキュー１００のそれぞれについて、性能指標値データがエンキューされることを監視している（Ｓ１０１）。
　そして、キュー１００に対する性能指標値データのエンキューが検出されると、当該キュー１００に関連付けられている実績判定プロセス１０６ａが、当該性能指標値データを取得する（Ｓ１０２）。
　そして、当該実績判定プロセス１０６ａは、Ｓ１０２に示す処理で取得された性能指標値データが示す性能指標値が閾値ｔｈ１を超えているか否かを判定する（Ｓ１０３）。
　性能指標値が閾値ｔｈ１を超えていると判定された場合は（Ｓ１０３：Ｙ）、ポリシーマネージャ部９０、ライフサイクル管理部９４、コンテナ管理部７８、及び、構成管理部７６が、当該実績判定プロセス１０６ａに対応付けられる要素のスケールアウトを実行して（Ｓ１０４）、Ｓ１０１に示す処理に戻る。
　性能指標値が閾値ｔｈ１を超えていないと判定された場合は（Ｓ１０３：Ｎ）、当該実績判定プロセス１０６ａは、当該実績判定プロセス１０６ａに関連付けられている推定プロセス１０８、及び、予測判定プロセス１０６ｂが生成されているか否か、及び、性能指標値が閾値ｔｈ２を超えているか否かを判定する（Ｓ１０５）。上述のように、閾値ｔｈ２は、上述の閾値ｔｈ１よりも小さい値であってもよい。
　推定プロセス１０８、及び、予測判定プロセス１０６ｂが未生成であり、かつ、性能指標値が閾値ｔｈ２を超えていると判定された場合は（Ｓ１０５：Ｙ）、ＡＩ部７０が当該実績判定プロセス１０６ａに関連付けられている推定プロセス１０８を生成し、ポリシーマネージャ部９０が当該実績判定プロセス１０６ａに関連付けられている予測判定プロセス１０６ｂを生成する（Ｓ１０６）。そして、Ｓ１０１に示す処理に戻る。このようにして、推定プロセス１０８による推定処理、及び、予測判定プロセス１０６ｂによる判定処理が開始される。
　Ｓ１０５に示す処理で、推定プロセス１０８、及び、予測判定プロセス１０６ｂが生成済であると判定された場合、又は、性能指標値が閾値ｔｈ２を超えていないと判定された場合は（Ｓ１０５：Ｎ）、Ｓ１０１に示す処理に戻る。
　通信システム１に含まれるすべての要素についてネットワーク負荷を常時予測することは、コンピュータリソースのキャパシティや消費電力の無駄となり望ましくない。
　以上で説明したように、本実施形態では、性能指標値データに基づいて、ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測が開始される。そして、ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトが必要であると判定されることに応じて、通信システム１に含まれる要素のスケールアウトが実行される。このようにすることで本実施形態によれば、通信システム１に含まれる要素のスケールアウトを実行するためのネットワーク負荷の予測が適切なタイミングに開始されることとなる。
　また、本実施形態では、ネットワーク負荷の予測が行われていない状態でも、ネットワーク負荷の予測結果に依存することなく、性能指標値データに基づいて、スケールアウトの要否は判定される。そして、スケールアウトが必要であると判定されることに応じて、通信システム１に含まれる要素のスケールアウトが実行される。
　例えば、ネットワーク負荷の予測が行われていない状態でも、性能指標値が閾値ｔｈ１を超えている場合は、通信システム１に含まれる要素のスケールアウトが実行される。
　このようにして、本実施形態ではネットワーク負荷の予測が実行されているか否かに関わらず、通信システム１に含まれる要素をスケールアウトすべき事態が発生した際には、当該要素が的確にスケールアウトされることとなる。
　次に、本実施形態に係るプラットフォームシステム３０で行われる、実績判定プロセス１０６ａによる通信システム１の状態判定に関する処理の流れの別の一例を、図１１に例示するフロー図を参照しながら説明する。
　Ｓ２０１からＳ２０５に示す処理は、Ｓ１０１からＳ１０５に示す処理と同様の処理であるので、その説明を省略する。
　Ｓ２０５に示す処理で推定プロセス１０８、及び、予測判定プロセス１０６ｂが未生成であり、かつ、性能指標値が閾値ｔｈ２を超えていると判定されたとする（Ｓ２０５：Ｙ）。この場合は、当該実績判定プロセス１０６ａは、判定プロセス１０６のためのコンピュータリソースが充分にあるか否かを判定する（Ｓ２０６）。
　ここで例えば、予め定められている判定プロセス１０６の最大数に対する、実行中の判定プロセス１０６の数の割合が所定の割合以上であるか否かが判定されてもよい。
　そして、判定プロセス１０６のためのコンピュータリソースが充分にあると判定された場合は（Ｓ２０６：Ｙ）、ＡＩ部７０が当該実績判定プロセス１０６ａに関連付けられている推定プロセス１０８を生成し、ポリシーマネージャ部９０が当該実績判定プロセス１０６ａに関連付けられている予測判定プロセス１０６ｂを生成する（Ｓ２０７）。そして、Ｓ２０１に示す処理に戻る。このようにして、推定プロセス１０８による推定処理、及び、予測判定プロセス１０６ｂによる判定処理が開始される。
　判定プロセス１０６のためのコンピュータリソースが充分にないと判定された場合は（Ｓ２０６：Ｎ）、Ｓ２０１に示す処理に戻る。
　図１１に示すように、本実施形態において、実績判定プロセス１０６ａが、性能指標値データと、コンピュータリソースの使用量と、に基づいて、ネットワーク負荷の予測要否を判定してもよい。そして、ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測が開始されるようにしてもよい。このようにすることで、コンピュータリソースの使用量に応じてネットワーク負荷の予測を開始させるか否かを制御できることとなる。例えば、コンピュータリソースが逼迫している場合にネットワーク負荷の予測を開始させないようにすることなどが可能となる。
　ここで、コンピュータリソースの使用量を示す指標は、上述のような、判定プロセス１０６の最大数に対する実行中の判定プロセス１０６の数の割合には限定されない。例えば、実行中の判定プロセス１０６の数に基づいて、ネットワーク負荷の予測要否が判定されてもよい。また、予め定められている予測判定プロセス１０６ｂの最大数に対する実行中の予測判定プロセス１０６ｂの数の割合に基づいて、ネットワーク負荷の予測要否が判定されてもよい。また、実行中の予測判定プロセス１０６ｂの数に基づいて、ネットワーク負荷の予測要否が判定されてもよい。また、予め定められている推定プロセス１０８の最大数に対する実行中の推定プロセス１０８の数の割合に基づいて、ネットワーク負荷の予測要否が判定されてもよい。また、実行中の推定プロセス１０８の数に基づいて、ネットワーク負荷の予測要否が判定されてもよい。また、ＣＰＵ使用率、メモリ使用率、ストレージ使用率、などに基づいて、ネットワーク負荷の予測要否が判定されてもよい。
　また、本実施形態において、ポリシーマネージャ部９０が、スケールアウトの実行対象である要素の重要度に応じて、コンピュータリソースの使用量に基づくネットワーク負荷の予測要否の判定を実行するか否かを決定してもよい。
　例えば、図１０に示す処理が、第１種ワークフローに相当する処理で、図１１に示す処理が、第２種ワークフローに相当する処理であってもよい。
　そして、例えば、実績判定プロセス１０６ａを生成する場面において、ポリシーマネージャ部９０が、インベントリデータに基づいて、生成される実績判定プロセス１０６ａに対応付けられる要素の重要度を確認してもよい。そして、確認された重要度に応じたワークフローが設定された実績判定プロセス１０６ａが生成されてもよい。例えば、インベントリデータに重要エリアフラグ、又は、重要サービスフラグが関連付けられている要素については、第１種ワークフローが設定された実績判定プロセス１０６ａが生成されてもよい。そして、インベントリデータに重要エリアフラグも、重要サービスフラグも関連付けられていない要素については、第２種ワークフローが設定された実績判定プロセス１０６ａが生成されてもよい。
　この場合、第１種ワークフローが設定された実績判定プロセス１０６ａでは、コンピュータリソースの使用量に基づかないネットワーク負荷の予測要否の判定が実行される。また、第２種ワークフローが設定された実績判定プロセス１０６ａでは、コンピュータリソースの使用量に基づくネットワーク負荷の予測要否の判定が実行される。
　このようにすれば、スケールアウトの実行対象である要素の重要度に応じて、ネットワーク負荷の予測を開始させるか否かの判定にコンピュータリソースの使用量を加味するか否かを切り替えることができる。そのため、例えば、重要な要素については、コンピュータリソースが逼迫している状況でもネットワーク負荷の予測を開始させるようにすることなどが可能となる。
　また、本処理例において、実績判定プロセス１０６ａが、性能指標値データが示す性能指標値の実績値が所定の条件を満たす場合に、コンピュータリソースの使用量に応じた確率で、ネットワーク負荷の予測が必要であると判定してもよい。
　例えば、Ｓ２０６に示す処理で、判定プロセス１０６のためのコンピュータリソースが充分にあると判定された場合に、図１２に示す確率でＳ２０７に示す処理が実行されてもよい。
　例えば、予め定められている判定プロセス１０６の最大数に対する、実行中の判定プロセス１０６の数の割合が、５０％未満である場合は、Ｓ２０７に示す処理の実行確率が１であってもよい。すなわち、Ｓ２０７に示す処理が実行されるようにしてもよい。
　また、予め定められている判定プロセス１０６の最大数に対する、実行中の判定プロセス１０６の数の割合が、５０％以上８０％未満である場合は、Ｓ２０７に示す処理の実行確率が０．５であってもよい。ここで例えば、疑似乱数を用いてＳ２０７に示す処理を実行するか否かが決定されるようにしてもよい。
　また、予め定められている判定プロセス１０６の最大数に対する、実行中の判定プロセス１０６の数の割合が、８０％以上である場合は、Ｓ２０７に示す処理の実行確率が０であってもよい。すなわち、Ｓ２０７に示す処理が実行されないようにしてもよい。
　以上のようにすれば、コンピュータリソースの使用量に応じて生成されるプロセスの数を適切に制御することができることとなる。
　次に、本実施形態に係るプラットフォームシステム３０で行われる、予測判定プロセス１０６ｂによる通信システム１の状態判定に関する処理の流れの一例を、図１３に例示するフロー図を参照しながら説明する。
　本処理例では、予測判定プロセス１０６ｂが、当該予測判定プロセス１０６ｂに関連付けられている推定プロセス１０８からの推定結果データの出力を監視している（Ｓ３０１）。
　そして、当該推定プロセス１０８からの推定結果データの出力が検出されると、当該予測判定プロセス１０６ｂが、当該予測結果データを取得する（Ｓ３０２）。
　そして、当該予測判定プロセス１０６ｂは、Ｓ３０２に示す処理で取得された予測結果データが示すネットワーク負荷の高さを示す予測値が閾値ｔｈ３を超えているか否かを判定する（Ｓ３０３）。
　予測値が閾値ｔｈ３を超えていないと判定された場合は（Ｓ３０３：Ｎ）、Ｓ３０１に示す処理に戻る。
　予測値が閾値ｔｈ３を超えていると判定された場合は（Ｓ３０３：Ｙ）、ポリシーマネージャ部９０、ライフサイクル管理部９４、コンテナ管理部７８、及び、構成管理部７６が、当該実績判定プロセス１０６ａに対応付けられる要素のスケールアウトを実行する（Ｓ３０４）。そして、当該予測判定プロセス１０６ｂは、当該予測判定プロセス１０６ｂに関連付けられている推定プロセス１０８、及び、自プロセスを終了させて（キルさせて）（Ｓ３０５）、本処理例に示す処理は終了される。
　なお、図１０及び図１１に示す処理例において、推定プロセス１０８、及び、予測判定プロセス１０６ｂが生成済である場合に、実績判定プロセス１０６ａが、取得された性能指標値データが示す性能指標値が閾値ｔｈ４を下回っているか否かを判定してもよい。そして、閾値ｔｈ４を下回っていると判定された場合に、当該実績判定プロセス１０６ａが、当該実績判定プロセス１０６ａに関連付けられている推定プロセス１０８、及び、予測判定プロセス１０６ｂを終了させて（キルさせて）もよい。
　なお、本発明は上述の実施形態に限定されるものではない。
　例えば、本実施形態において、ｇＮＢのようなＲＡＮ３２の要素ではなく、コアネットワークシステム３４の要素のスケールアウトが実行されてもよい。例えば、ＡＭＦ４６やＳＭＦ４８やＵＰＦ５０のスケールアウトが実行されてもよい。またこの場合、スケールアウトを実行するか否かの判定に、コアネットワークシステム３４の要素に係る性能指標値データが用いられてもよい。あるいは、当該判定に、ＲＡＮ３２の要素、及び、コアネットワークシステム３４の要素に係る性能指標値データが用いられてもよい。
　また、同様にして、トランスポートのスケールアウトが実行されるようにしてもよい。
　また、本実施形態に係る機能ユニットは図３に示したものには限定されない。
　また、本実施形態に係る機能ユニットは、５ＧにおけるＮＦである必要はない。例えば、本実施形態に係る機能ユニットが、ｅＮｏｄｅＢ、ｖＤＵ、ｖＣＵ、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）などといった、４Ｇにおけるネットワークノードであっても構わない。
　また、本実施形態に係る機能ユニットが、コンテナ型の仮想化技術でなく、ハイパーバイザ型やホスト型の仮想化技術を用いて実現されてもよい。また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。
　本開示に記載の技術は以下のように表現することもできる。
［１］
　通信システムに係る性能指標値の実績値を示す性能指標値データを取得する性能指標値データ取得手段と、
　前記性能指標値データに基づいて、ネットワーク負荷の予測要否を判定する第１判定手段と、
　ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測を開始する予測開始手段と、
　ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定する第２判定手段と、
　スケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行するスケールアウト実行手段と、
　を含むことを特徴とするスケールアウト実行システム。
［２］
　ネットワーク負荷の予測結果に依存することなく、前記性能指標値データに基づいて、スケールアウトの要否を判定する第３判定手段、をさらに含み、
　前記スケールアウト実行手段は、前記第２判定手段又は前記第３判定手段によってスケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行する、
　ことを特徴とする［１］に記載のスケールアウト実行システム。
［３］
　前記第１判定手段は、前記性能指標値データが示すネットワーク負荷の高さを示す値が第１の閾値を超える場合に、ネットワーク負荷の予測が必要であると判定し、
　前記第３判定手段は、前記性能指標値データが示すネットワーク負荷の高さを示す値が前記第１の閾値よりも大きな第２の閾値を超える場合に、スケールアウトが必要であると判定する、
　ことを特徴とする［２］に記載のスケールアウト実行システム。
［４］
　前記性能指標値データが格納されるキューに前記性能指標値データがエンキューされたことに応じて、前記第３判定手段が、エンキューされた性能指標値データに基づいて、スケールアウトの要否を判定し、前記第２判定手段が、前記キューに格納されている前記性能指標値データのうちの、当該エンキューされた性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データに基づく、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定する、
　ことを特徴とする［２］又は［３］に記載のスケールアウト実行システム。
［５］
　前記第１判定手段は、前記性能指標値データと、コンピュータリソースの使用量と、に基づいて、ネットワーク負荷の予測要否を判定する、
　ことを特徴とする［１］から［４］のいずれか一項に記載のスケールアウト実行システム。
［６］
　スケールアウトの実行対象である要素の重要度に応じて、コンピュータリソースの使用量に基づくネットワーク負荷の予測要否の判定を実行するか否かを決定する実行決定手段、をさらに含む、
　ことを特徴とする［５］に記載のスケールアウト実行システム。
［７］
　前記第１判定手段は、前記性能指標値データが示す性能指標値の実績値が所定の条件を満たす場合に、コンピュータリソースの使用量に応じた確率で、ネットワーク負荷の予測が必要であると判定する、
　ことを特徴とする［５］又は［６］に記載のスケールアウト実行システム。
［８］
　所定の条件を満たすことに応じて、ネットワーク負荷の予測を終了する予測終了手段、をさらに含む、
　ことを特徴とする［１］から［７］のいずれか一項に記載のスケールアウト実行システム。
［９］
　通信システムに係る性能指標値の実績値を示す性能指標値データを取得することと、
　前記性能指標値データに基づいて、ネットワーク負荷の予測要否を判定することと、
　ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測を開始することと、
　ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定することと、
　スケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行することと、
　を含むことを特徴とするスケールアウト実行方法。

 

Claims (9)

  1. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサのうちの少なくとも１つによって、
    　通信システムに係る性能指標値の実績値を示す性能指標値データを取得する性能指標値データ取得処理と、
    　前記性能指標値データに基づいて、ネットワーク負荷の予測要否を判定する第１判定処理と、
    　ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測を開始する予測開始処理と、
    　ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定する第２判定処理と、
    　スケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行するスケールアウト実行処理と、
    　が実行されるスケールアウト実行システム。
  2. 　前記１以上のプロセッサのうちの少なくとも１つによって、ネットワーク負荷の予測結果に依存することなく、前記性能指標値データに基づいて、スケールアウトの要否を判定する第３判定処理、が実行され、
    　前記スケールアウト実行処理では、前記第２判定処理又は前記第３判定処理によってスケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行する、
    　請求項１に記載のスケールアウト実行システム。
  3. 　前記第１判定処理では、前記性能指標値データが示すネットワーク負荷の高さを示す値が第１の閾値を超える場合に、ネットワーク負荷の予測が必要であると判定され、
    　前記第３判定処理では、前記性能指標値データが示すネットワーク負荷の高さを示す値が前記第１の閾値よりも大きな第２の閾値を超える場合に、スケールアウトが必要であると判定される、
    　請求項２に記載のスケールアウト実行システム。
  4. 　前記性能指標値データが格納されるキューに前記性能指標値データがエンキューされたことに応じて、前記第３判定処理で、エンキューされた性能指標値データに基づいて、スケールアウトの要否が判定され、前記第２判定処理で、前記キューに格納されている前記性能指標値データのうちの、当該エンキューされた性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データに基づく、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否が判定される、
    　請求項２に記載のスケールアウト実行システム。
  5. 　前記第１判定処理では、前記性能指標値データと、コンピュータリソースの使用量と、に基づいて、ネットワーク負荷の予測要否が判定される、
    　請求項１に記載のスケールアウト実行システム。
  6. 　前記１以上のプロセッサのうちの少なくとも１つによって、スケールアウトの実行対象である要素の重要度に応じて、コンピュータリソースの使用量に基づくネットワーク負荷の予測要否の判定を実行するか否かを決定する実行決定処理、が実行される、
    　請求項５に記載のスケールアウト実行システム。
  7. 　前記第１判定処理では、前記性能指標値データが示す性能指標値の実績値が所定の条件を満たす場合に、コンピュータリソースの使用量に応じた確率で、ネットワーク負荷の予測が必要であると判定される、
    　請求項５に記載のスケールアウト実行システム。
  8. 　前記１以上のプロセッサのうちの少なくとも１つによって、所定の条件を満たすことに応じて、ネットワーク負荷の予測を終了する予測終了処理、が実行される、
    　請求項１に記載のスケールアウト実行システム。
  9. 　通信システムに係る性能指標値の実績値を示す性能指標値データを取得することと、
    　前記性能指標値データに基づいて、ネットワーク負荷の予測要否を判定することと、
    　ネットワーク負荷の予測が必要であると判定されることに応じて、ネットワーク負荷の予測を開始することと、
    　ネットワーク負荷の予測が開始された後に、ネットワーク負荷の予測結果に基づいて、スケールアウトの要否を判定することと、
    　スケールアウトが必要であると判定されることに応じて、前記通信システムに含まれる要素のスケールアウトを実行することと、
    　を含むことを特徴とするスケールアウト実行方法。

     
PCT/JP2022/029356 2022-07-29 2022-07-29 ネットワーク負荷の予測開始タイミングの制御 WO2024024106A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/029356 WO2024024106A1 (ja) 2022-07-29 2022-07-29 ネットワーク負荷の予測開始タイミングの制御

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/029356 WO2024024106A1 (ja) 2022-07-29 2022-07-29 ネットワーク負荷の予測開始タイミングの制御

Publications (1)

Publication Number Publication Date
WO2024024106A1 true WO2024024106A1 (ja) 2024-02-01

Family

ID=89705877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/029356 WO2024024106A1 (ja) 2022-07-29 2022-07-29 ネットワーク負荷の予測開始タイミングの制御

Country Status (1)

Country Link
WO (1) WO2024024106A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012142672A (ja) * 2010-12-28 2012-07-26 Nec Corp 無線通信システム、管理サーバ装置、無線通信リソース割当処理方法およびプログラム
JP2014183495A (ja) * 2013-03-19 2014-09-29 Fujitsu Ltd 伝送装置、制御カード、伝送方法及び伝送プログラム
JP2015149578A (ja) * 2014-02-06 2015-08-20 株式会社日立製作所 運用管理装置
WO2015194182A1 (ja) * 2014-06-19 2015-12-23 日本電気株式会社 サービスチェーン管理装置、サービスチェーン管理システム、サービスチェーン管理方法、及び、プログラム記録媒体
JP2018191217A (ja) * 2017-05-10 2018-11-29 ソフトバンク株式会社 データ監視装置、データ監視方法及びデータ監視プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012142672A (ja) * 2010-12-28 2012-07-26 Nec Corp 無線通信システム、管理サーバ装置、無線通信リソース割当処理方法およびプログラム
JP2014183495A (ja) * 2013-03-19 2014-09-29 Fujitsu Ltd 伝送装置、制御カード、伝送方法及び伝送プログラム
JP2015149578A (ja) * 2014-02-06 2015-08-20 株式会社日立製作所 運用管理装置
WO2015194182A1 (ja) * 2014-06-19 2015-12-23 日本電気株式会社 サービスチェーン管理装置、サービスチェーン管理システム、サービスチェーン管理方法、及び、プログラム記録媒体
JP2018191217A (ja) * 2017-05-10 2018-11-29 ソフトバンク株式会社 データ監視装置、データ監視方法及びデータ監視プログラム

Similar Documents

Publication Publication Date Title
CN109391505B (zh) 网络实例管理方法及相关设备
EP3053041B1 (en) Method, system, computer program and computer program product for monitoring data packet flows between virtual machines, vms, within a data centre
US10735279B2 (en) Networking service level agreements for computer datacenters
JP6538869B2 (ja) ネットワーク管理
CN110463141B (zh) 通信方法、装置和系统
CN112789832B (zh) 动态切片优先级处理
US11444840B2 (en) Virtualized networking application and infrastructure
CN112753250B (zh) 管理用户设备到网络切片的分配的方法和电信网络
CN108965147B (zh) 网络控制方法、装置及网络设备
CN116418876A (zh) 一种算力网络服务的迁移方法、系统及云管理平台
CN112771931B (zh) 管理电信网络中的网络业务的方法和管理网络业务的电信网络
WO2024024106A1 (ja) ネットワーク負荷の予測開始タイミングの制御
WO2024024107A1 (ja) ネットワーク負荷の予測開始タイミングの制御
WO2024004102A1 (ja) キューに格納されている性能指標値データに基づく通信システムの状態判定
WO2024004103A1 (ja) 通信システムに含まれる要素の適切なスケールアウトの実行
WO2024004104A1 (ja) 通信システムに含まれる要素の適切なスケールアウトの実行
WO2024047774A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2024047775A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2023218664A1 (ja) リプレースシステム及びリプレース方法
WO2023218663A1 (ja) 実行基盤決定システム及び実行基盤決定方法
WO2024142180A1 (ja) 不安定なアプリケーションのリプレース
WO2024142179A1 (ja) アプリケーションが不安定である原因の推定
WO2024069948A1 (ja) 通信システムに含まれるハードウェアリソースの管理
WO2023188185A1 (ja) 配置システム及び配置方法
Abderrahim et al. Dependability integration in cloud-hosted telecommunication services

Legal Events

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

Ref document number: 22953194

Country of ref document: EP

Kind code of ref document: A1