WO2024069948A1 - 通信システムに含まれるハードウェアリソースの管理 - Google Patents

通信システムに含まれるハードウェアリソースの管理 Download PDF

Info

Publication number
WO2024069948A1
WO2024069948A1 PCT/JP2022/036742 JP2022036742W WO2024069948A1 WO 2024069948 A1 WO2024069948 A1 WO 2024069948A1 JP 2022036742 W JP2022036742 W JP 2022036742W WO 2024069948 A1 WO2024069948 A1 WO 2024069948A1
Authority
WO
WIPO (PCT)
Prior art keywords
hardware resource
resource group
hardware
group
resource
Prior art date
Application number
PCT/JP2022/036742
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/036742 priority Critical patent/WO2024069948A1/ja
Publication of WO2024069948A1 publication Critical patent/WO2024069948A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • the present invention relates to the management of hardware resources included in a communication system.
  • Patent Document 1 describes adding unused hardware resources that have been set up with system software corresponding to a specific type of functional unit to a resource pool associated with that specific type of functional unit.
  • Patent Documents 2 and 3 describe technologies for implementing scale-out of applications running on communication systems, such as VNF (Virtualized Network Function).
  • VNF Virtualized Network Function
  • the present invention was made in consideration of the above situation, and one of its objectives is to enable efficient use of hardware resources included in a communication system.
  • the resource management system includes a usage monitoring means for monitoring the usage of each of a plurality of hardware resource groups included in a communication system, and a resource adding means for changing the affiliation of a hardware resource included in a common spare resource group different from any of the hardware resource groups from the common spare resource group to the hardware resource group when the usage of any of the hardware resource groups satisfies a condition for being associated with that hardware resource group.
  • the resource management method also includes monitoring the usage status of each of a plurality of hardware resource groups included in a communication system, and, when the usage status of any of the hardware resource groups satisfies a condition for being associated with that hardware resource group, changing the affiliation of a hardware resource included in a common spare resource group different from any of the hardware resource groups from the common spare resource group to that hardware resource group.
  • FIG. 1 is a diagram illustrating an example of a communication system according to an embodiment of the present invention.
  • 1 is a diagram illustrating an example of a communication system according to an embodiment of the present invention.
  • FIG. 1 is a diagram illustrating an example of a network service according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of associations between elements established in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a functional block diagram showing an example of functions implemented in a platform system according to an embodiment of the present invention.
  • FIG. 2 illustrates an example of a data structure of physical inventory data.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of allocation of hardware resources included in a communication system according to an embodiment of the present invention.
  • FIG. 2 is a flow diagram showing an example of a flow of processing performed in a platform system according to an embodiment of the present invention.
  • FIG. 2 is a flow diagram showing an example of a flow of processing performed in a platform system according to an embodiment of the present invention.
  • FIGS. 1 and 2 are diagrams showing an example of a communication system 1 according to one embodiment of the present invention.
  • FIG. 1 is a diagram focusing on the locations of a group of data centers included in the communication system 1.
  • FIG. 2 is a diagram focusing on various computer systems implemented in the group of data centers included in the communication system 1.
  • the data centers included in the communication system 1 are classified into a central data center 10, a regional data center 12, and an edge data center 14.
  • central data centers 10 are distributed throughout the area covered by the communication system 1 (for example, within Japan).
  • regional data centers 12 are distributed throughout the area covered by the communication system 1. For example, if the area covered by the communication system 1 is the entirety of Japan, one or two regional data centers 12 may be located in each prefecture.
  • Each edge data center 14 is capable of communicating with communication equipment 18 equipped with an antenna 16. As shown in FIG. 1, one edge data center 14 may be capable of communicating with several pieces of communication equipment 18.
  • the communication equipment 18 may include a computer such as a server computer.
  • the communication equipment 18 in this embodiment performs wireless communication with a UE (User Equipment) 20 via the antenna 16.
  • the communication equipment 18 equipped with the antenna 16 is provided with, for example, an RU (Radio Unit) as described below.
  • the central data center 10, the regional data center 12, and the edge data center 14 each have multiple servers.
  • the central data center 10 the regional data centers 12, and the edge data centers 14 are capable of communicating with each other.
  • the central data centers 10 are also capable of communicating with each other
  • the regional data centers 12 are also capable of communicating with each other
  • the edge data centers 14 are also capable of communicating with each other.
  • the communication system 1 includes a platform system 30, multiple radio access networks (RANs) 32, multiple core network systems 34, and multiple UEs 20.
  • the core network systems 34, the RANs 32, and the UEs 20 work together to realize a mobile communication network.
  • the RAN 32 is a computer system equipped with an antenna 16, which corresponds to an eNB (eNodeB) in a fourth generation mobile communication system (hereinafter referred to as 4G) or a gNB (NR base station) in a fifth generation mobile communication system (hereinafter referred to as 5G).
  • the RAN 32 in this embodiment is mainly implemented by a group of servers and communication equipment 18 arranged in an edge data center 14.
  • a part of the RAN 32 e.g., a distributed unit (DU), a central unit (CU), a virtual distributed unit (vDU), and a virtual central unit (vCU)
  • DU distributed unit
  • CU central unit
  • vDU virtual distributed unit
  • vCU virtual central unit
  • vCU virtual central unit
  • the core network system 34 is a system equivalent to the EPC (Evolved Packet Core) in 4G and the 5G Core (5GC) in 5G.
  • the core network system 34 in this embodiment is implemented mainly by a group of servers located in the central data center 10 and the regional data centers 12.
  • the platform system 30 is configured, for example, on a cloud platform, and includes a processor 30a, a storage unit 30b, and a communication unit 30c, as shown in FIG. 2.
  • the processor 30a is a program-controlled device such as a microprocessor that operates according to a program installed in the platform system 30.
  • the storage unit 30b is, for example, a storage element such as a ROM or RAM, a solid-state drive (SSD), or a hard disk drive (HDD).
  • the storage unit 30b stores programs executed by the processor 30a.
  • the communication unit 30c is, for example, a communication interface such as a NIC (Network Interface Controller) or a wireless LAN (Local Area Network) module. Note that the communication unit 30c may be implemented with SDN (Software-Defined Networking).
  • the communication unit 30c transmits and receives data between 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 also be implemented by a group of servers located in the regional data centers 12.
  • the requested network service is constructed in the RAN 32 or the core network system 34. Then, the constructed network service is provided to the purchaser.
  • NS network service
  • network services such as voice communication services and data communication services are provided to a purchaser who is an MVNO (Mobile Virtual Network Operator).
  • the voice communication services and data communication services provided by this embodiment are ultimately provided to a customer (end user) of the purchaser (MVNO in the above example) who uses the UE 20 shown in Figures 1 and 2.
  • the end user is able to perform voice communication and data communication with other users via the RAN 32 and the core network system 34.
  • the UE 20 of the end user is also able to access a data network such as the Internet via the RAN 32 and the core network system 34.
  • an IoT (Internet of Things) service may be provided to an end user who uses a robot arm, a connected car, or the like.
  • an end user who uses a robot arm, a connected car, or the like may become a purchaser of the network service related to this embodiment.
  • a container-type virtualized application execution environment such as Docker (registered trademark) is installed on the servers located in the central data center 10, the regional data center 12, and the edge data center 14, so that containers can be deployed and run on these servers.
  • a cluster consisting 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.
  • a processor on the constructed cluster may execute a container-type application.
  • the network service provided to the purchaser is composed of one or more functional units (e.g., network functions (NFs)).
  • the functional units are implemented as NFs realized by virtualization technology.
  • NFs realized by virtualization technology are called VNFs (Virtualized Network Functions). It does not matter what virtualization technology is used for virtualization.
  • CNFs Containerized Network Functions
  • the network service is described as being implemented by one or more CNFs.
  • the functional units in this embodiment may correspond to network nodes.
  • FIG. 3 is a schematic diagram of an example of a network service in operation.
  • the network service shown in Figure 3 includes NFs as software elements, such as multiple RUs 40, multiple DUs 42, multiple CUs 44 (CU-CP (Central Unit - Control Plane) 44a and CU-UP (Central Unit - User Plane) 44b), multiple AMFs (Access and Mobility Management Functions) 46, multiple SMFs (Session Management Functions) 48, and multiple UPFs (User Plane Functions) 50.
  • NFs as software elements, such as multiple RUs 40, multiple DUs 42, multiple CUs 44 (CU-CP (Central Unit - Control Plane) 44a and CU-UP (Central Unit - User Plane) 44b), multiple AMFs (Access and Mobility Management Functions) 46, multiple SMFs (Session Management Functions) 48, and multiple UPFs (User Plane Functions) 50.
  • CU-CP Central Unit - Control Plane
  • RU 40, DU 42, CU-CP 44a, AMF 46, and SMF 48 correspond to elements of the control plane (C-Plane)
  • RU 40, DU 42, CU-UP 44b, and UPF 50 correspond to elements of the user plane (U-Plane).
  • the network service may also include other types of NF as software elements.
  • the network service is implemented on computer resources (hardware elements) such as multiple servers.
  • communication services in a certain area are provided by the network service shown in FIG. 3.
  • the multiple RUs 40, multiple DUs 42, multiple CU-UPs 44b, and multiple UPFs 50 shown in FIG. 3 belong to one end-to-end network slice.
  • FIG. 4 is a diagram showing a schematic example of an association between elements established in 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 in numbers between elements connected by a link.
  • the elements connected by the link When both ends of a link are a combination of M and N, the elements connected by the link have a many-to-many relationship, and when both ends of a link are a combination of 1 and N or a combination of 1 and M, the elements connected by the link have a one-to-many relationship.
  • NS network services
  • NF network functions
  • CNFC Containerized Network Function Component
  • NS corresponds to, for example, a network service composed of multiple NFs.
  • NS may correspond to elements of granularity such as 5GC, EPC, 5G RAN (gNB), 4G RAN (eNB), etc.
  • NFs correspond to elements with granularity such as RU, DU, CU-CP, CU-UP, AMF, SMF, and UPF.
  • NFs correspond to elements with granularity 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.
  • one NS has one or more NFs under it.
  • CNFC corresponds to an element of granularity such as DU mgmt and DU Processing.
  • CNFC may be a microservice 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, etc.
  • one NF includes one or more CNFCs.
  • one or more CNFCs are under the control of one NF.
  • a pod is the smallest unit for managing a Docker container in Kubernetes, for example.
  • one CNFC includes one or more pods.
  • one or more pods are under the control of one CNFC.
  • one pod includes one or more containers.
  • one or more containers are subordinate to one pod.
  • network slices (NSIs) and network slice subnet instances (NSSIs) are structured hierarchically.
  • the NSI can also be considered as an end-to-end virtual line spanning multiple domains (e.g., from the RAN 32 to the core network system 34).
  • the NSI may be a slice for high-speed, large-capacity communications (e.g., for enhanced Mobile Broadband (eMBB)), a slice for high-reliability, low-latency communications (e.g., for Ultra-Reliable and Low Latency Communications (URLLC)), or a slice for connecting a large number of terminals (e.g., for massive Machine Type Communication (mMTC)).
  • the NSSI can also be a virtual line of a single domain obtained by dividing the NSI.
  • the NSSI may be a slice of the RAN domain, a slice of a transport domain such as the Mobile Back Haul (MBH) domain, or a slice of the core network domain.
  • MMH Mobile Back Haul
  • one NSI includes one or more NSSIs.
  • one NSI has one or more NSSIs under it.
  • multiple NSIs may share the same NSSI.
  • NSSIs and NSs generally have a many-to-many relationship.
  • one NF can belong to one or more network slices.
  • one NF can be configured with an NSSAI (Network Slice Selection Assistance Information) that includes one or more S-NSSAIs (Sub Network Slice Selection Assist Information).
  • NSSAI Network Slice Selection Assistance Information
  • S-NSSAIs Sub Network Slice Selection Assist Information
  • the S-NSSAI is information associated with a network slice. Note that an NF does not have 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 this embodiment. Note that it is not necessary for all of the functions shown in FIG. 5 to be implemented in the platform system 30 according to this embodiment, and functions other than the functions shown in FIG. 5 may also be implemented.
  • the platform system 30 functionally includes, for example, an operation support system (OSS) unit 60, an orchestration (E2EO: End-to-End-Orchestration) unit 62, a service catalog storage unit 64, a big data platform unit 66, a data bus unit 68, an AI (Artificial Intelligence) unit 70, a monitoring function unit 72, an SDN controller 74, a configuration management unit 76, a container management unit 78, a repository unit 80, and a bare metal management unit 96.
  • the OSS unit 60 includes an inventory database 82, a ticket management unit 84, a fault management unit 86, and a performance management unit 88.
  • the E2EO unit 62 includes a policy manager unit 90, a slice manager unit 92, and a life cycle management unit 94. These elements are implemented primarily using the processor 30a, the storage unit 30b, and the communication unit 30c.
  • the functions shown in FIG. 5 may be implemented by having processor 30a execute a program that is installed in platform system 30, which is one or more computers, and that includes instructions corresponding to the functions.
  • This program may be supplied to platform system 30 via a computer-readable information storage medium, such as an optical disk, magnetic disk, magnetic tape, magneto-optical disk, or flash memory, or via the Internet, for example.
  • the functions shown in FIG. 5 may also be implemented in a circuit block, memory, or other LSI. Those skilled in the art will understand that the functions shown in FIG. 5 can be realized in various forms, such as hardware only, software only, or a combination thereof.
  • the container management unit 78 manages the life cycle of containers. For example, this life cycle management includes processes related to container construction, such as container deployment and configuration.
  • the platform system 30 may include multiple 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 multiple container management units 78.
  • Each of the multiple container management units 78 may execute container construction, such as container deployment, for a server group (e.g., 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 (i.e., the RAN 32 or the core network system 34), or may be provided in another server that is attached to the server managed by the container management unit 78.
  • the repository unit 80 stores, for example, container images of containers included in a functional unit group (e.g., a NF group) that realizes a network service.
  • a functional unit group e.g., a NF group
  • the inventory database 82 is a database in which inventory information is stored.
  • the inventory information includes, for example, information about servers that are placed in the RAN 32 and the core network system 34 and that are managed by the platform system 30.
  • inventory data is stored in the inventory database 82.
  • the inventory data indicates the configuration of the element group included in the communication system 1 and the current state of the association between the elements.
  • the inventory data also indicates the status of the resources managed by the platform system 30 (e.g., the resource usage status).
  • the inventory data may be physical inventory data or logical inventory data. Physical inventory data and logical inventory data will be described later.
  • 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, a server ID, location data, building data, floor data, rack data, spec data, network data, an operating container ID list, a cluster ID, and the like.
  • the server ID included in the physical inventory data is, for example, an 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 (e.g., 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 the building (e.g., the building name) in which the server associated with the physical inventory data is located.
  • the floor data included in the physical inventory data is, for example, data indicating the floor on which the server associated with the physical inventory data is located.
  • the rack data included in the physical inventory data is, for example, an identifier for 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 indicates, 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 that indicates information about the network of the server that corresponds to the physical inventory data, and the network data indicates, for example, the NIC that the server has, the number of ports that the NIC has, the port IDs of the ports, etc.
  • the operating container ID list included in the physical inventory data is, for example, data indicating information about one or more containers operating on a server associated with the physical inventory data, and the operating container ID list indicates, for example, a list of identifiers (container IDs) of instances of the containers.
  • the cluster ID included in the physical inventory data is, for example, an identifier of the cluster (e.g., a 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 associations between multiple elements included in the communication system 1, as shown in FIG. 4.
  • the logical inventory data includes topology data including an identifier of a certain NS and an identifier of one or more NFs under the NS.
  • the logical inventory data includes topology data including an identifier of a certain network slice and an identifier of one or more NFs belonging to the network slice.
  • the inventory data may also include data indicating the current status of geographical relationships and topological relationships between the elements included in the communication system 1.
  • the inventory data includes location data indicating the locations where the elements included in the communication system 1 are operating, i.e., the current locations of the elements included in the communication system 1. From this, it can be said that the inventory data indicates the current status of the geographical relationships between the elements (e.g., the geographical proximity between the elements).
  • the logical inventory data may also include NSI data indicating information about the network slice.
  • the NSI data indicates attributes such as an identifier of an instance of the network slice and a type of the network slice.
  • the logical inventory data may also include NSSI data indicating information about the network slice subnet.
  • the NSSI data indicates attributes such as an identifier of an instance of the network slice subnet and a type of the network slice subnet.
  • the logical inventory data may also include NS data indicating information about NS.
  • the NS data indicates attributes such as an NS instance identifier and an NS type.
  • the logical inventory data may also include NF data indicating information about NF.
  • the NF data indicates attributes such as an NF instance identifier and an NF type.
  • the logical inventory data may also include CNFC data indicating information about CNFC.
  • the CNFC data indicates attributes such as an instance identifier and a CNFC type.
  • the logical inventory data may also include pod data indicating information about a pod included in CNFC.
  • the pod data indicates attributes such as a pod instance identifier and a pod type.
  • the logical inventory data may also include container data indicating information about a container included in a pod.
  • the container data indicates attributes such as a container ID of a container instance and a container type.
  • the container ID of the container data included in the logical inventory data and the container ID included in the operating container ID list included in the physical inventory data associate a container instance with the server on which the container instance is running.
  • container data may include data indicating an IP address of a container corresponding to the container data.
  • NF data may include data indicating an IP address and a host name of an NF indicated by the NF data.
  • the logical inventory data may also include data indicating an NSSAI, including one or more S-NSSAIs, that is set in each NF.
  • the inventory database 82 also works in conjunction with the container management unit 78 to appropriately grasp the status of resources.
  • the inventory database 82 then appropriately updates the inventory data stored in the inventory database 82 based on the latest status of the resources.
  • the inventory database 82 updates the inventory data stored in the inventory database 82.
  • the service catalog storage unit 64 stores service catalog data.
  • the service catalog data may include, for example, service template data indicating the logic used by the life cycle management unit 94.
  • This service template data includes information necessary for building a network service.
  • the service template data includes information defining NS, NF, and CNFC, and information indicating the correspondence between NS, NF, and CNFC.
  • the service template data includes a workflow script for building a network service.
  • An example of service template data is an NSD (NS Descriptor).
  • An NSD is associated with a network service and indicates the types of multiple functional units (e.g. multiple CNFs) included in the network service.
  • the NSD may also indicate the number of each type of functional unit, such as CNFs, included in the network service.
  • the NSD may also indicate the file name of a CNFD (described later) related to the CNFs included in the network service.
  • the CNFD may indicate the computer resources (e.g., CPU, memory, hard disk, etc.) required by the CNF.
  • the CNFD may indicate the computer resources (CPU, memory, hard disk, etc.) required by each of multiple containers included in the CNF.
  • the service catalog data may also include information regarding thresholds (e.g., anomaly detection thresholds) that are used by the policy manager unit 90 to compare the calculated performance index values.
  • thresholds e.g., anomaly detection thresholds
  • the performance index values are described below.
  • the service catalog data may also include, for example, slice template data.
  • the slice template data includes information required to perform instantiation of a network slice, for example including logic utilized by the slice manager unit 92.
  • the slice template data includes information on the "Generic Network Slice Template” defined by the 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. The slice template data also includes information indicating the hierarchical structure of these elements, as shown in Figure 4.
  • the life cycle management unit 94 creates a new network service in response to a purchase request for an NS by a purchaser.
  • the life cycle management unit 94 may, for example, execute a workflow script associated with the network service to be purchased in response to a purchase request. Then, by executing this workflow script, the life cycle management unit 94 may instruct the container management unit 78 to deploy a container included in the new network service to be purchased. Then, the container management unit 78 may obtain a container image of the container from the repository unit 80, and deploy a container corresponding to the container image to a server.
  • the life cycle management unit 94 performs, for example, scaling and replacement of elements included in the communication system 1.
  • the life cycle management unit 94 may output container deployment and deletion instructions to the container management unit 78.
  • the container management unit 78 may then perform processes such as container deployment and container deletion in accordance with the instructions.
  • the life cycle management unit 94 is capable of performing scaling and replacement that cannot be handled by the container management unit 78's tools such as Kubernetes.
  • the life cycle management unit 94 may also output an instruction to the SDN controller 74 to create a communication path.
  • the life cycle management unit 94 presents the 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.
  • the life cycle management unit 94 may also output an instruction to the SDN controller 74 to create a communication path between the two IP addresses that is associated with the two IP addresses.
  • the slice manager unit 92 performs instantiation of a network slice.
  • the slice manager unit 92 performs instantiation of a network slice by executing logic indicated by a slice template stored in the service catalog storage unit 64.
  • the slice manager unit 92 is configured to include the functions of the Network Slice Management Function (NSMF) and the Network Slice Sub-network Management Function (NSSMF), for example, as described in the 3GPP (registered trademark) (Third Generation Partnership Project) specification "TS28 533.”
  • the NSMF is a function that generates and manages network slices, and provides NSI management services.
  • the NSSMF is a function that generates and manages network slice subnets that constitute part of the network slice, and provides NSSI management services.
  • the slice manager unit 92 may output configuration management instructions related to instantiation of the network slice to the configuration management unit 76.
  • the configuration management unit 76 may then execute configuration management such as settings in accordance with the configuration management instructions.
  • the slice manager unit 92 may also present two IP addresses to the SDN controller 74 and output an instruction to create a communication path between these two IP addresses.
  • the configuration management unit 76 performs configuration management such as setting up element groups such as NFs, in accordance with configuration management instructions received from the life cycle management unit 94 and slice manager unit 92, for example.
  • the SDN controller 74 creates a communication path between two IP addresses associated with a communication path creation instruction received from, for example, the life cycle management unit 94 or the slice manager unit 92.
  • the SDN controller 74 may create a communication path between two IP addresses using a known path calculation method such as Flex Algo.
  • the SDN controller 74 may use segment routing technology (e.g., SRv6 (Segment Routing IPv6)) to construct NSIs and NSSIs for aggregation routers and servers that exist between communication paths.
  • segment routing technology e.g., SRv6 (Segment Routing IPv6)
  • the SDN controller 74 may generate NSIs and NSSIs that span multiple NFs to be configured by issuing commands to multiple NFs to be configured to configure a common VLAN (Virtual Local Area Network), and commands to assign the bandwidth and priority indicated in the configuration information to the VLAN.
  • VLAN Virtual Local Area Network
  • the SDN controller 74 may also perform operations such as changing the maximum bandwidth available for communication between two IP addresses without constructing a network slice.
  • the platform system 30 may include multiple SDN controllers 74.
  • Each of the multiple SDN controllers 74 may perform 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 the group of elements included in the communication system 1 according to a given management policy.
  • the monitoring function unit 72 may monitor the group of elements according to a monitoring policy specified by a purchaser when purchasing a network service, for example.
  • the monitoring function unit 72 performs monitoring at various levels, such as the slice level, the NS level, the NF level, the CNFC level, and the hardware level of the server, etc.
  • the monitoring function unit 72 may set a module that outputs metric data in hardware such as a server or in software elements included in the communication system 1 so that monitoring can be performed at the various levels described above.
  • an NF may output metric data indicating metrics that are measurable (identifiable) in the NF to the monitoring function unit 72.
  • a server may output metric data indicating metrics related to hardware that is measurable (identifiable) 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 multiple containers on a CNFC (microservice) basis.
  • This sidecar container may include an agent called an exporter.
  • the monitoring function unit 72 may repeatedly execute a process of obtaining metric data aggregated on a microservice basis from the sidecar container at a given monitoring interval, using the mechanism of a monitoring tool such as Prometheus that can monitor container management tools such as Kubernetes.
  • the monitoring function unit 72 may, for example, monitor performance indicator values for 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 (KPIs)." The monitoring function unit 72 may then obtain metric data indicating the performance indicator values being monitored.
  • KPIs Key Performance Indicators
  • the monitoring function unit 72 executes a process (enrichment) of aggregating metric data in a predetermined aggregation unit, for example, to generate performance index value data indicating the performance index values of the elements included in the communication system 1 in that aggregation unit.
  • performance index value data for the gNB is generated by aggregating metric data indicating the metrics of elements (e.g., network nodes such as DU42 and CU44) under the control of the gNB.
  • 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 for each gNB. Note that the communication performance indicated by the performance index value data is not limited to traffic volume and latency.
  • the monitoring function unit 72 outputs the performance index value data generated by the above-mentioned enrichment to the data bus unit 68.
  • the data bus unit 68 receives performance index value data output from the monitoring function unit 72. Then, based on the received one or more performance index value data, the data bus unit 68 generates a performance index value file including the one or more performance index value data. Then, the data bus unit 68 outputs the generated performance index value file to the big data platform unit 66.
  • elements such as network slices, NS, NF, and CNFC included in the communication system 1, and hardware such as servers, notify the monitoring function unit 72 of various alerts (for example, alerts triggered by the occurrence of a failure).
  • the monitoring function unit 72 receives, for example, a notification of the above-mentioned alert, it outputs alert message data indicating the notification to the data bus unit 68.
  • the data bus unit 68 then generates an alert file in which the alert message data indicating one or more notifications are compiled into a single file, and outputs the alert file to the big data platform unit 66.
  • the big data platform unit 66 accumulates, for example, performance index value files and alert files output from the data bus unit 68.
  • the AI unit 70 has multiple trained machine learning models stored in advance.
  • the AI unit 70 uses the various machine learning models stored in the AI unit 70 to perform estimation processing such as future prediction processing of the usage status and service quality of the communication system 1.
  • the AI unit 70 may generate estimation result data that indicates the results of the estimation processing.
  • the AI unit 70 may perform estimation processing based on the files stored in the big data platform unit 66 and the above-mentioned machine learning model. This estimation processing is suitable for predicting long-term trends at low frequency.
  • the AI unit 70 can also acquire the performance index value data stored in the data bus unit 68.
  • the AI unit 70 may execute an estimation process based on the performance index value data stored in the data bus unit 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 a performance index value (e.g., KPI) based on multiple metric data and on the metrics indicated by these metric data.
  • the performance management unit 88 may also calculate a performance index value that is an overall evaluation of multiple types of metrics (e.g., a performance index value related to an end-to-end network slice) that cannot be calculated from a single metric data.
  • the performance management unit 88 may generate overall performance index value data that indicates the performance index value that is the overall evaluation.
  • the performance management unit 88 may obtain the above-mentioned performance index value file from the big data platform unit 66.
  • the performance management unit 88 may also obtain the estimation result data from the AI unit 70. Then, the performance index value such as KPI may be calculated based on at least one of the performance index value file or the estimation result data.
  • the performance management unit 88 may also obtain metric data directly from the monitoring function unit 72. Then, the performance index value such as KPI may be calculated based on the metric data.
  • the fault management unit 86 detects the occurrence of a fault in the communication system 1 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 overall performance index value data.
  • the fault management unit 86 may detect the occurrence of a fault that cannot be detected from a single metric data or a single alert notification, for example, based on a predetermined logic.
  • the fault management unit 86 may generate detected fault data indicating the detected fault.
  • the fault management unit 86 may obtain metric data and alert notifications directly from the monitoring function unit 72.
  • the fault management unit 86 may also obtain performance index value files and alert files from the big data platform unit 66.
  • the fault management unit 86 may also obtain alert message data from the data bus unit 68.
  • the policy manager unit 90 executes a predetermined determination process based on at least one of 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, the above-mentioned overall performance index value data, and the above-mentioned detected fault data.
  • the policy manager unit 90 may execute an action according to the result of the determination process. For example, the policy manager unit 90 may output an instruction to construct a network slice to the slice manager unit 92. The policy manager unit 90 may also output an instruction to scale or replace an element to the life cycle management unit 94 according to the result of the determination process.
  • the policy manager unit 90 is capable of acquiring performance index value data stored in the data bus unit 68. The policy manager unit 90 may then execute a predetermined judgment process based on the performance index value data acquired from the data bus unit 68. The policy manager unit 90 may also execute a predetermined judgment process based on the alert message data stored in the data bus unit 68.
  • the ticket management unit 84 generates a ticket indicating the content to be notified to the administrator of the communication system 1.
  • the ticket management unit 84 may generate a ticket indicating the content of the occurred fault data.
  • the ticket management unit 84 may also generate a ticket indicating the value of the performance index value data or metric data.
  • the ticket management unit 84 may also generate a ticket indicating the result of the determination made 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 email with the generated ticket attached to the email address of the administrator of the communication system 1.
  • the bare metal management unit 96 performs setup such as setting up the BIOS (Basic Input Output System), setting up single root I/O virtualization (SR-IOV), and installing or replacing system software.
  • BIOS Basic Input Output System
  • SR-IOV single root I/O virtualization
  • the configuration management unit 76 may perform hardware or software configuration for hardware resources, such as setting a cluster ID, IP address, host name, or label.
  • the bare metal management unit 96 may also perform setup on hardware resources according to a specific type of application.
  • the configuration management unit 76 or the bare metal management unit 96 may store a script (e.g., an assemble script) for setting up a specific type of application.
  • the script may describe, for example, an installation procedure for a host OS of a specific type or version that is the basis of the container execution environment.
  • the script may also describe, for example, a procedure for setting up the host OS kernel, a procedure for setting up the BIOS, a procedure for setting up SR-IOV, etc.
  • the bare metal management unit 96 may execute the script to perform setup on the hardware resource according to the type of application running on the hardware resource. For example, the bare metal management unit 96 may perform setup of the host OS and BIOS of the container execution environment on the hardware resource.
  • the bare metal management unit 96 may also replace system software, such as an OS, that is installed on a hardware resource.
  • system software such as an OS
  • the bare metal management unit 96 may uninstall system software that is installed on a hardware resource, and install different system software on that hardware resource.
  • FIG. 7 is a diagram showing an example of the allocation of hardware resources included in the communication system 1 according to this embodiment.
  • FIG. 7 shows a first hardware resource group 100a and a second hardware resource group 100b in which a UPF 50 included in the network service purchased by purchaser A operates.
  • the hardware resource group 100 may include a server group.
  • FIG. 7 also shows a third hardware resource group 100c in which AMF46, included in the network service purchased by purchaser A, operates.
  • FIG. 7 also shows a fourth hardware resource group 100d in which the UPF 50 included in the network service purchased by purchaser B operates, and a fifth hardware resource group 100e in which the AMF 46 included in the network service purchased by purchaser B operates.
  • the network service purchased by Purchaser A or Purchaser B also includes NFs (e.g., DU42, CU44, SMF48, etc.) that are not shown in Figure 7, but these NFs are omitted.
  • NFs e.g., DU42, CU44, SMF48, etc.
  • the hardware resources included in the communication system 1 are managed by dividing them into a plurality of hardware resource groups 100.
  • the plurality of servers included in the communication system 1 are managed by dividing them into a plurality of server groups.
  • the type of application that runs on each of the multiple hardware resource groups 100 may be predetermined.
  • the UPF 50 runs on the first hardware resource group 100a, the second hardware resource group 100b, and the fourth hardware resource group 100d.
  • the AMF 46 runs on the third hardware resource group 100c and the fifth hardware resource group 100e.
  • an application purchased by a purchaser other than the purchaser of an application running in one of the multiple hardware resource groups 100 may be running in another hardware resource group 100.
  • an application purchased by purchaser A runs in the first hardware resource group 100a, the second hardware resource group 100b, and the third hardware resource group 100c.
  • An application purchased by purchaser B runs in the fourth hardware resource group 100d and the fifth hardware resource group 100e.
  • hardware resources are not limited to servers. Furthermore, the location of the hardware resources shown in FIG. 7 is not particularly important. In the following description, the hardware resources shown in FIG. 7 are assumed to be located in the central data center 10, but the hardware resources may also be located in the regional data center 12 or the edge data center 14.
  • one hardware resource group 100 corresponds to one cluster (e.g., one Kubernetes cluster) managed by a container management tool.
  • one hardware resource group 100 does not necessarily correspond to one cluster managed by a container management tool.
  • one cluster managed by a container management tool may include multiple hardware resource groups 100.
  • one hardware resource group 100 may correspond to one name space.
  • the monitoring function unit 72 monitors the usage status of each of the multiple hardware resource groups 100 included in the communication system 1.
  • the monitoring function unit 72 may also monitor the usage status of each of the multiple server groups included in the communication system 1.
  • the usage status of the hardware resource group 100 refers to, for example, CPU usage, memory usage, storage usage, network usage, etc.
  • a comprehensive evaluation value calculated based on some or all of these indicators monitored for the hardware resource group may be monitored as a value indicating the usage status of the hardware resource group 100.
  • the configuration management unit 76 may identify the maximum amount of hardware resources expected to be used for the operation of applications for each of multiple hardware resource groups 100 (e.g., multiple server groups). In this way, the maximum amount of hardware resources expected to be used for the operation of applications may be proportional to the number of applications running in the hardware resource group 100.
  • the amount of hardware resources allocated to each hardware resource group 100 is shown diagrammatically.
  • the actual resource usage amount 102, the expected maximum resource usage amount 104, and the standby resource amount 106 which are each a part of the amount of hardware resources allocated to the hardware resource group 100, are shown.
  • the actual resource usage amount 102 corresponds to the amount of hardware resources actually used by the applications running on the hardware resource group 100.
  • the expected maximum resource usage amount 104 corresponds to the maximum hardware resource amount expected to be used for the operation of the applications described above.
  • the actual usage amount of the hardware resources fluctuates appropriately. Therefore, as shown in FIG. 7, the actual resource usage amount 102 is less than the expected maximum resource usage amount 104.
  • the standby resource amount 106 corresponds to the amount of hardware resources allocated to the hardware resource group 100 minus the expected maximum resource usage amount 104.
  • the expected maximum resource usage amount 104 increases, and the standby resource amount 106 decreases by the amount of increase in the expected maximum resource usage amount 104.
  • the amount of hardware resources allocated to the hardware resource group 100 may be specified by the purchaser when purchasing the network service, for example. For example, the more the purchase price of the network service by the purchaser, the more hardware resources may be allocated to the hardware resource group 100. Also, in this embodiment, the purchaser may be able to add or delete hardware resources allocated to the hardware resource group 100 as appropriate.
  • a common spare resource group 108 (e.g., a common server group) that is different from any of the above-mentioned hardware resource groups 100 is managed. That is, in this embodiment, a hardware resource group that is different from the above-mentioned multiple hardware resource groups 100 (e.g., the first hardware resource group 100a to the fifth hardware resource group 100e) is managed as the common spare resource group 108.
  • the common spare resource group 108 includes multiple spare resources 110 (110a, 110b, 110c, ).
  • One spare resource 110 corresponds to, for example, one or multiple servers.
  • the configuration management unit 76 changes the affiliation of the hardware resources included in the common spare resource group 108 from the common spare resource group 108 to that hardware resource group 100. In this way, hardware resources are added to that hardware resource group 100, and the amount of hardware resources allocated to that hardware resource group 100 increases.
  • the configuration management unit 76 may change the affiliation of a server included in a common spare server group that is different from any of the server groups from the common spare server group to the server group in question, in response to the fact that the usage status of any of the server groups satisfies the conditions for associating that server group with that server group.
  • the configuration management unit 76 changes the affiliation of a hardware resource that is part of the hardware resource group 100 from the hardware resource group 100 to the common spare resource group 108. In this way, the hardware resource is deleted from the hardware resource group 100, and the amount of hardware resources allocated to the hardware resource group 100 is reduced.
  • the hardware resources assigned to the hardware resource group 100 may not be deleted from the hardware resource group 100 even if the usage status of the hardware resource group 100 satisfies the resource deletion condition associated with the hardware resource group 100.
  • the configuration management unit 76 changes the affiliation of the hardware resource by setting the cluster ID, IP address, host name, or label.
  • the affiliation of one backup resource 110 (hereinafter referred to as the selected hardware resource) selected from the common backup resource group 108 is changed from the common backup resource group 108 to the first hardware resource group 100a.
  • the backup resource 110a corresponds to the selected hardware resource.
  • the ratio of the amount of actually used resources 102 to the amount of hardware resources allocated to the first hardware resource group 100a falls below a predetermined ratio p2.
  • the value of p2 may be smaller than p1.
  • the affiliation of the selected hardware resource described above is changed from the first hardware resource group 100a to the common spare resource group 108.
  • the ratio of the amount of actually used resources 102 to the amount of hardware resources allocated to the fourth hardware resource group 100d exceeds a predetermined ratio p3.
  • the value of p3 may be the same as or different from the value of p1.
  • the affiliation of the selected hardware resource is changed from the common spare resource group 108 to the fourth hardware resource group 100d.
  • the configuration management unit 76 may change the affiliation of a hardware resource whose affiliation has been changed from the first hardware resource group 100a to the common spare resource group 108 from the common spare resource group 108 to the fourth hardware resource group 100d in response to the usage status of the fourth hardware resource group 100d satisfying the resource addition condition associated with the fourth hardware resource group 100d.
  • the spare resource 110 used by one hardware resource group 100 can be used by another hardware resource group 100.
  • the configuration management unit 76 may change the affiliation of a selected hardware resource selected from the common spare resource group 108 from the common spare resource group 108 to the first hardware resource group 100a in response to the usage status of the first hardware resource group 100a satisfying a resource addition condition associated with the first hardware resource group 100a.
  • the configuration management unit 76 may change the affiliation of the selected hardware resource from the first hardware resource group 100a to the common spare resource group 108 in response to the usage status of the first hardware resource group 100a satisfying the resource deletion condition associated with the first hardware resource group 100a.
  • a specific spare resource 110 (selected hardware resource) can be rotated among multiple hardware resource groups 100.
  • the resource addition condition or the resource deletion condition may be a condition related to the actual usage amount of the hardware resource or the actual usage rate of the hardware resource.
  • the resource addition condition or the resource deletion condition may be a threshold related to the actual usage amount of the resource 102.
  • the resource addition condition or resource deletion condition may be a condition related to the maximum hardware resource amount expected to be used for the operation of an application in the hardware resource group 100, or a condition related to the maximum hardware resource rate expected to be used for the operation of an application in the hardware resource group 100.
  • the resource addition condition or resource deletion condition may be a condition related to the expected maximum resource usage amount 104. For example, when the expected maximum resource usage amount 104 exceeds a predetermined threshold, the affiliation of a hardware resource included in the common spare resource group 108 may be changed from the common spare resource group 108 to the hardware resource group 100.
  • the resource addition condition and resource deletion condition may be conditions associated with the number of applications running in the hardware resource group 100. For example, when the number of applications running in the hardware resource group 100 becomes three as a result of scale-out, the affiliation of the hardware resources included in the common spare resource group 108 may be changed from the common spare resource group 108 to the hardware resource group 100. When the number of applications running in the hardware resource group 100 becomes one as a result of scale-in, the affiliation of the hardware resources included in the hardware resource group 100 may be changed from the hardware resource group 100 to the common spare resource group 108.
  • the affiliation of a hardware resource included in the common spare resource group 108 is changed from the common spare resource group 108 to that hardware resource group 100.
  • the hardware resources included in the communication system 1 can be used efficiently.
  • the time required to deploy an application to a hardware resource already assigned to the hardware resource group 100 as a result of the scale-out is longer than the time required to deploy an application to the hardware resource 110 after changing the affiliation of the backup resource 110 from the common backup resource group 108 to the hardware resource group 100 as a result of the scale-out. Therefore, in order to ensure that the scale-out is performed smoothly, it is desirable to always have as many hardware resources as possible reserved in the hardware resource group 100.
  • the hardware resources secured in the hardware resource group 100 may not be enough to provide sufficient services.
  • the hardware resources reserved in the hardware resource group 100 can be flexibly adjusted, so that sufficient services can be provided even in the above-mentioned cases.
  • this embodiment makes it possible to change the affiliation of the spare resource 110 across clusters, which is not possible with a container management tool.
  • the present invention can also be applied to the hardware resource group 100 on which other applications (such as SMF48) included in the core network system 34 run.
  • the present invention can also be applied to the hardware resource group 100 on which applications (DU42, CU-CP44a, CU-UP44b, etc.) included in RAN32 run.
  • applications DU42, CU-CP44a, CU-UP44b, etc.
  • the resource addition condition and the resource deletion condition may be conditions that correspond to the type of application running on the hardware resource group 100.
  • the resource addition condition is a threshold related to the ratio of the actual resource usage amount 102 to the amount of hardware resources allocated to the hardware resource group 100
  • the resource addition condition may be set so that the threshold becomes smaller for an application that has a larger expected maximum resource usage amount 104 that increases due to scale-out.
  • the configuration management unit 76 may change the affiliation of a hardware resource included in the common spare resource group 108 from the common spare resource group 108 to the hardware resource group 100 in response to the usage status of the hardware resource group 100 satisfying a resource addition condition associated with the type of application running in the hardware resource group 100.
  • the configuration management unit 76 may change the affiliation of a hardware resource included in a hardware resource group 100 from the hardware resource group 100 to the common spare resource group 108 in response to the fact that the usage status of the hardware resource group 100 satisfies a resource deletion condition associated with the type of application running in the hardware resource group 100.
  • At least one of the resource addition conditions or the resource deletion conditions may be the same.
  • at least one of the resource addition conditions or the resource deletion conditions may be the same.
  • the resource addition conditions and resource deletion conditions may be conditions selected by the purchaser of the application from within a range associated with the type of application running on the hardware resource group 100, or conditions selected by the purchaser of the application from among a number of options associated with the type of application running on the hardware resource group 100. In this way, it is possible to allow the purchaser of the application to set resource addition conditions and resource deletion conditions, while also placing restrictions on the settings that are associated with the type of application.
  • the amount of hardware resources of the backup resources 110 that are changed from the common backup resource group 108 to the hardware resource group 100 may correspond to the amount of hardware resources allocated to the hardware resource group 100.
  • the more the amount of hardware resources allocated to the hardware resource group 100, the more the backup resources 110 that are changed in affiliation may be changed.
  • the addition of a spare resource 110 to the hardware resource group 100 may be performed multiple times. That is, after one spare resource 110 is added to the hardware resource group 100, one more spare resource 110 may be added to the hardware resource group 100 in response to the usage status of the hardware resource group 100 satisfying the resource addition condition.
  • the resource addition condition may be a condition according to the number of spare resources 110 added to the hardware resource group 100.
  • the bare metal management unit 96 may execute a setup for a hardware resource whose affiliation is changed from the common spare resource group 108 to one of the hardware resource groups 100, according to the type of application running in that hardware resource group 100. Then, the configuration management unit 76 may change the affiliation of the hardware resource for which the setup has been executed from the common spare resource group 108 to that hardware resource group 100.
  • the network service purchased by purchaser C also includes NFs (e.g., CU44, SMF48, etc.) that are not shown in FIG. 11, but these NFs are omitted.
  • NFs e.g., CU44, SMF48, etc.
  • the spare resources 110 (110a, 110b, 110c, ...) included in the common spare resource group 108 are hardware resources that do not require additional setup to be performed according to the type of application in order to run an application type other than a predetermined type.
  • the spare resource 110 is a hardware resource that does not require additional setup to be performed according to the type of application in order to run an application other than UPF 50 and DU 42.
  • UPF50 or DU42 In order to run a specific type of application (e.g., UPF50 or DU42) on the spare resource 110, it is necessary to execute a setup corresponding to that type for the spare resource 110.
  • the application cannot be run on a general-purpose hardware resource (e.g., a general-purpose server), and it is necessary to execute a setup corresponding to that type.
  • UPF50 and DU42 correspond to such types of applications.
  • the configuration management unit 76 may change the affiliation of the selected hardware resource, which is the backup resource 110 selected from the common backup resource group 108, from the common backup resource group 108 to the seventh hardware resource group 100g without performing any special setup.
  • the backup resource 110a corresponds to the selected hardware resource.
  • the bare metal management unit 96 may execute setup according to the UPF 50 for the selected hardware resource whose affiliation is to be changed from the common spare resource group 108 to the hardware resource group 100.
  • the spare resource 110a corresponds to the selected hardware resource.
  • the configuration management unit 76 may change the affiliation of the selected hardware resource for which the setup has been executed from the common spare resource group 108 to the sixth hardware resource group 100f.
  • the bare metal management unit 96 may execute setup for a hardware resource included in the common spare resource group 108 (e.g., the selected hardware resource described above) in response to the usage status of any one of the hardware resource groups 100 satisfying the resource addition condition associated with that hardware resource group 100, according to the type of application running on that hardware resource group 100.
  • a hardware resource included in the common spare resource group 108 e.g., the selected hardware resource described above
  • the bare metal management unit 96 may return the hardware resource for which the above-mentioned setup has been executed, which is changed from belonging to one of the hardware resource groups 100 to the common spare resource group 108, to the state before the execution of the setup.
  • the process of returning the hardware resource for which the above-mentioned setup has been executed to the state before the execution of the setup will be referred to as un-setup.
  • the bare metal management unit 96 may execute unsetup for the selected hardware resource for which setup according to the UPF 50 has been executed, and whose affiliation is changed from the sixth hardware resource group 100f to the common spare resource group 108. Then, the configuration management unit 76 may change the affiliation of the selected hardware resource for which unsetup has been executed from the sixth hardware resource group 100f to the common spare resource group 108.
  • the bare metal management unit 96 may return the hardware resource for which the above-mentioned setup was performed (e.g., the above-mentioned selected hardware resource) to the state before the setup was performed in response to the usage status of any one of the hardware resource groups 100 satisfying the resource deletion condition associated with that hardware resource group 100.
  • the hardware resource for which the above-mentioned setup was performed e.g., the above-mentioned selected hardware resource
  • the bare metal management unit 96 may execute setup for the selected hardware resource described above according to DU42. Then, the configuration management unit 76 may change the affiliation of the selected hardware resource for which the setup has been executed from the common spare resource group 108 to the eighth hardware resource group 100h.
  • the spare resources 110 included in the common spare resource group 108 are in a versatile state that allows many types of applications to run without having to perform additional setups according to the type of application.
  • the hardware resources included in the communication system 1 can be used more efficiently.
  • the affiliation of the backup resource 110 may be changed from the common backup resource group 108 to the hardware resource group 100 on which the application purchased by the purchaser runs.
  • the purchaser of the network service may be able to set whether or not the affiliation of the backup resource 110 is to be changed when the pre-set resource addition conditions as described above are met.
  • the purchaser of the network service may be notified of an inquiry as to whether or not a hardware resource needs to be added. Then, when the purchaser approves the resource addition, the affiliation of the spare resource 110 may be changed from the common spare resource group 108 to the hardware resource group 100 on which the application purchased by the purchaser runs.
  • the purchaser of the network service may be notified of an inquiry as to whether or not the hardware resource needs to be deleted. Then, when the resource deletion is approved by the purchaser, the affiliation of the spare resource 110 may be changed from the hardware resource group 100 on which the application purchased by the purchaser runs to the common spare resource group 108.
  • the resource addition condition or resource deletion condition may be a condition related to the number of servers on which an application is running or the number of free servers. For example, when the number of free servers included in the hardware resource group 100 falls below a predetermined number, the affiliation of a hardware resource included in the common spare resource group 108 may be changed from the common spare resource group 108 to the hardware resource group 100.
  • the resource addition condition or resource deletion condition may be a condition related to the number of virtual machines (VMs) on which an application is running, or the number of free VMs. For example, when the number of free VMs included in the hardware resource group 100 falls below a predetermined number, the affiliation of a hardware resource included in the common spare resource group 108 may be changed from the common spare resource group 108 to the hardware resource group 100.
  • VMs virtual machines
  • the process illustrated in FIG. 16 is executed in all hardware resource groups 100 included in the communication system 1 and in which the above-mentioned specific type of application (e.g., UPF 50 or DU 42) is running.
  • the above-mentioned specific type of application e.g., UPF 50 or DU 42
  • the policy manager unit 90 monitors whether the usage status of the hardware resource group 100 satisfies the resource addition conditions (S101).
  • the policy manager unit 90 determines that the usage of the hardware resource group 100 satisfies the resource addition condition (S101: Y), the bare metal management unit 96 executes setup for the selected hardware resource included in the common spare resource group 108 according to the type of application running on the hardware resource group 100 (S102).
  • the configuration management unit 76 changes the affiliation of the selected hardware resource for which setup was performed in the process shown in S102 from the common spare resource group 108 to the hardware resource group 100 (S103), and returns to the process shown in S101.
  • the process shown in S102 is not executed in any hardware resource group 100 in which an application other than the above-mentioned predetermined type of application (e.g., UPF 50 or DU 42) is running. Then, when it is determined that the usage status of the hardware resource group 100 satisfies the resource addition condition, the configuration management unit 76 changes the affiliation of the selected hardware resource from the common spare resource group 108 to the hardware resource group 100, and returns to the process shown in S101.
  • an application other than the above-mentioned predetermined type of application e.g., UPF 50 or DU 42
  • the process illustrated in FIG. 17 is executed in all hardware resource groups 100 included in the communication system 1 and in which the above-mentioned specific type of application (e.g., UPF 50 or DU 42) is running.
  • the above-mentioned specific type of application e.g., UPF 50 or DU 42
  • the policy manager unit 90 monitors whether the usage status of the hardware resource group 100 satisfies the resource deletion conditions (S201).
  • the policy manager unit 90 determines that the usage status of the hardware resource group 100 satisfies the resource deletion condition (S201: Y), the bare metal management unit 96 executes unsetup for the selected hardware resource (S202).
  • the configuration management unit 76 changes the affiliation of the selected hardware resource for which the setup was performed in the process shown in S202 from the hardware resource group 100 to the common spare resource group 108 (S203), and the process returns to the process shown in S201.
  • the process shown in S202 is not executed in any hardware resource group 100 in which an application other than the above-mentioned predetermined type of application (e.g., UPF 50 or DU 42) is running. Then, when it is determined that the usage status of the hardware resource group 100 satisfies the resource deletion condition, the configuration management unit 76 changes the affiliation of the selected hardware resource from the hardware resource group 100 to the common spare resource group 108, and returns to the process shown in S201.
  • an application other than the above-mentioned predetermined type of application e.g., UPF 50 or DU 42
  • the processing performed by the bare metal management unit 96 in the above description may be performed by, for example, the configuration management unit 76.
  • the processing performed by the configuration management unit 76 in the above description may be performed by, for example, the bare metal management unit 96.
  • the functional units according to this embodiment do not have to be NFs in 5G.
  • the functional units according to this embodiment may be network nodes in 4G, such as eNodeB, vDU, vCU, P-GW (Packet Data Network Gateway), S-GW (Serving Gateway), MME (Mobility Management Entity), and HSS (Home Subscriber Server).
  • 4G such as eNodeB, vDU, vCU, P-GW (Packet Data Network Gateway), S-GW (Serving Gateway), MME (Mobility Management Entity), and HSS (Home Subscriber Server).
  • the functional units according to this embodiment may be realized using hypervisor-type or host-type virtualization technology instead of container-type virtualization technology. Furthermore, the functional units according to this embodiment do not need to be implemented by software, and may be implemented by hardware such as electronic circuits. Furthermore, the functional units according to this embodiment may be implemented by a combination of electronic circuits and software.
  • a usage status monitoring means for monitoring the usage status of each of a plurality of hardware resource groups included in the communication system; a resource adding means for changing the affiliation of a hardware resource included in a common spare resource group different from any of the hardware resource groups from the common spare resource group to the hardware resource group in response to a usage status of any of the hardware resource groups satisfying a condition for being associated with the hardware resource group;
  • a resource management system comprising: [2] A type of application that runs on each of the plurality of hardware resource groups is determined in advance, the resource adding means changes the affiliation of the hardware resources included in the common spare resource group from the common spare resource group to the hardware resource group in response to a usage status of the hardware resource group satisfying a condition associated with a type of an application running on the hardware resource group.
  • the resource management system according to claim 1.
  • a setup execution unit that executes setup for a hardware resource that is to be changed from the common spare resource group to any one of the hardware resource groups in accordance with a type of application running on the hardware resource group; the resource addition means changes the affiliation of the hardware resource for which the setup has been executed from the common spare resource group to the hardware resource group.
  • the resource management system according to claim 2.
  • the setup execution means executes a setup for the hardware resources included in the common spare resource group in response to a usage status of any one of the hardware resource groups satisfying a condition associated with the hardware resource group, in accordance with a type of application running on the hardware resource group.
  • the resource management system according to claim 3.
  • the resource adding means changes the affiliation of a hardware resource included in the common spare resource group from the common spare resource group to the hardware resource group in response to a usage status of any one of the hardware resource groups satisfying a first condition associated with the hardware resource group; a resource deleting means for changing the affiliation of a hardware resource that is a part of any one of the hardware resource groups from the hardware resource group to the common spare resource group in response to a usage status of the any one of the hardware resource groups satisfying a second condition associated with the hardware resource group,
  • the resource management system according to claim 1 or 2.
  • a setup execution unit that executes setup for a hardware resource that is to be changed from the common spare resource group to any one of the hardware resource groups in accordance with a type of application running on the hardware resource group;
  • the resource addition means changes the affiliation of the hardware resource for which the setup has been executed from the common spare resource group to the hardware resource group, and an unsetup execution unit for returning the hardware resource for which the setup has been executed, the hardware resource being changed from the hardware resource group to the common spare resource group, to a state before the setup was executed.
  • the setup execution means in response to a usage status of any one of the hardware resource groups satisfying the first condition associated with the hardware resource group, executes a setup for a hardware resource included in the common spare resource group according to a type of an application running on the hardware resource group; the unsetup execution means, in response to a fact that a usage status of any one of the hardware resource groups satisfies the second condition associated with the hardware resource group, returns the hardware resource for which the setup has been executed to a state before the setup was executed.
  • the resource management system according to claim 6.
  • the plurality of hardware resource groups include a first hardware resource group and a second hardware resource group different from the first hardware resource group; the resource adding means changes the affiliation of the hardware resource, whose affiliation has been changed from the first hardware resource group to the common spare resource group, from the common spare resource group to the second hardware resource group in response to a usage state of the second hardware resource group satisfying a condition for being associated with the second hardware resource group.
  • the plurality of hardware resource groups include a first hardware resource group and a second hardware resource group different from the first hardware resource group; the resource adding means changes the affiliation of a selected hardware resource selected from the common spare resource group from the common spare resource group to the first hardware resource group in response to a usage status of the first hardware resource group satisfying a first condition associated with the first hardware resource group; a resource deleting means for changing the affiliation of the selected hardware resource from the first hardware resource group to the common reserve resource group in response to a usage status of the first hardware resource group satisfying a second condition associated with the first hardware resource group, the resource adding means changes the affiliation of the selected hardware resource, whose affiliation has been changed from the first hardware resource group to the common spare resource group, from the common spare resource group to the second hardware resource group in response to a usage status of the second hardware resource group satisfying a condition for being associated with the second hardware resource group.
  • a setup execution means for executing a setup according to a type of an application running on the first hardware resource group for a hardware resource that is to be changed from the common spare resource group to the first hardware resource group;
  • the resource adding means changes the affiliation of the hardware resource for which the setup has been executed from the common spare resource group to the first hardware resource group, and an unsetup execution means for returning the hardware resource for which the setup has been executed, the hardware resource being changed from the first hardware resource group to the common spare resource group, to a state before the setup was executed, the setup execution means executes a setup corresponding to a type of an application running on the second hardware resource group for a hardware resource that is to be changed from the common spare resource group to the second hardware resource group;
  • the resource management system according to claim 8 or 9.
  • the setup execution means in response to a usage status of the first hardware resource group satisfying a first condition associated with the first hardware resource group, executes a setup for hardware resources included in the common spare resource group according to a type of application running on the first hardware resource group;
  • the unsetup execution means in response to a usage status of the first hardware resource group satisfying a second condition associated with the first hardware resource group, returns the hardware resource for which the setup has been executed to a state before the setup was executed,
  • the setup execution means in response to a usage status of the second hardware resource group satisfying a condition associated with the second hardware resource group, executes a setup corresponding to a type of an application running on the second hardware resource group for the hardware resources that have returned to a state before the execution of the setup.
  • the condition is a condition related to an actual usage amount of a hardware resource, an actual usage rate of a hardware resource, an actual spare amount of a hardware resource, or an actual spare rate of a hardware resource.
  • the resource management system according to any one of claims [1] to [11].
  • the condition is a condition related to a maximum amount of hardware resources expected to be used for the operation of an application in the group of hardware resources, or a maximum hardware resource rate expected to be used for the operation of an application in the group of hardware resources; The resource management system according to any one of claims [1] to [11].
  • the condition is associated with the number of applications running on the group of hardware resources;
  • the resource management system according to any one of [1] to [13], [15] the condition is a condition selected by a purchaser of the application from within a range associated with the type of the application running on the group of hardware resources, or a condition selected by a purchaser of the application from among a plurality of options associated with the type of the application running on the group of hardware resources;
  • the resource management system according to any one of [1] to [15], [17]
  • the usage status monitoring means monitors the usage status of each of a plurality of server groups included in the communication system, said resource adding means, when a usage status of any one of said server groups satisfies a condition for being associated with said server group, changes the affiliation of a
  • the resource management system according to any one of [1] to [17]. [19] Monitoring the usage status of each of a plurality of hardware resources included in a communication system; When a usage status of any one of the hardware resource groups satisfies a condition for being associated with the hardware resource group, a hardware resource included in a common spare resource group different from any one of the hardware resource groups is changed to belong to the common spare resource group from the common spare resource group to the hardware resource group; 23.
  • a resource management method comprising:

Abstract

通信システムに含まれるハードウェアリソースを効率的に使用できるようにする。監視機能部（７２）は、通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する。構成管理部（７６）は、いずれかのハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれのハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更する。

Description

通信システムに含まれるハードウェアリソースの管理
　本発明は、通信システムに含まれるハードウェアリソースの管理に関する。
　通信システムに含まれるハードウェアリソースを複数のハードウェアリソース群に分けて管理する技術が存在する。このような技術の一例として、特許文献１には、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップが施された未使用ハードウェアリソースを、当該特定種類の機能ユニットに関連付けられているリソースプールに追加することが記載されている。
　また、特許文献２、及び、特許文献３には、ＶＮＦ（Virtualized Network Function）などといった、通信システムで稼働するアプリケーションのスケールアウトを実行する技術が記載されている。
国際公開第２０２１／１７１２１１号 特開２０１７－１７３８９４号公報 国際公開第２０１７／１７０４７０号
　通信システムに含まれるハードウェアリソースを複数のハードウェアリソース群に分けて管理する場合に、アプリケーションのスケールアウトが実行されることを見越して、複数のハードウェアリソース群のそれぞれで多くのハードウェアリソースを予め確保してしまうと、ハードウェアリソースの無駄が発生してしまう。
　本発明は上記実情に鑑みてなされたものであって、その目的の一つは、通信システムに含まれるハードウェアリソースを効率的に使用できるようにすることにある。
　上記課題を解決するために、本開示に係るリソース管理システムは、通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視手段と、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加手段と、を含む。
　また、本開示に係るリソース管理方法は、通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更することと、を含む。
本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係るネットワークサービスの一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに構築される要素間の関連付けの一例を示す図である。 本発明の一実施形態に係るプラットフォームシステムで実装される機能の一例を示す機能ブロック図である。 物理インベントリデータのデータ構造の一例を示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。
　以下、本発明の一実施形態について図面に基づき詳細に説明する。
　図１及び図２は、本発明の一実施形態に係る通信システム１の一例を示す図である。図１は、通信システム１に含まれるデータセンタ群のロケーションに着目した図となっている。図２は、通信システム１に含まれるデータセンタ群で実装されている各種のコンピュータシステムに着目した図となっている。
　図１に示すように、通信システム１に含まれるデータセンタ群は、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４に分類される。
　セントラルデータセンタ１０は、例えば、通信システム１がカバーするエリア内（例えば、日本国内）に分散して数個配置されている。
　リージョナルデータセンタ１２は、例えば、通信システム１がカバーするエリア内に分散して数十個配置されている。例えば、通信システム１がカバーするエリアが日本国内全域である場合に、リージョナルデータセンタ１２が、各都道府県に１から２個ずつ配置されてもよい。
　エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。ここで図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（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)」に記載された性能指標についての性能指標値を監視してもよい。そして、監視機能部７２は、監視される性能指標値を示すメトリックデータを取得してもよい。
　そして、監視機能部７２は、本実施形態では、例えば、所定の集計単位で、メトリックデータを集計する処理（エンリッチメント）を実行することで、当該集計単位における、通信システム１に含まれる要素の性能指標値を示す性能指標値データを生成する。
　例えば、１つのｇＮＢについて、当該ｇＮＢの配下にある要素（例えば、ＤＵ４２やＣＵ４４などのネットワークノード）のメトリックを示すメトリックデータを集計することで、当該ｇＮＢの性能指標値データを生成する。このようにして、当該ｇＮＢがカバーするエリアにおける通信性能を示す性能指標値データが生成される。ここで、例えば、各ｇＮＢにおいて、トラフィック量（スループット）やレイテンシなどといった複数種類の通信性能を示す性能指標値データが生成されてもよい。なお、性能指標値データが示す通信性能は、トラフィック量やレイテンシには限定されない。
　そして、監視機能部７２は、上述のエンリッチメントによって生成される性能指標値データを、データバス部６８に出力する。
　データバス部６８は、本実施形態では例えば、監視機能部７２から出力される性能指標値データを受け付ける。そして、データバス部６８は、受け付ける１又は複数の性能指標値データに基づいて、当該１又は複数の性能指標値データを含む性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。
　また、通信システム１に含まれるネットワークスライス、ＮＳ、ＮＦ、ＣＮＦＣ等の要素や、サーバ等のハードウェアは、監視機能部７２に、各種のアラートの通知（例えば、障害の発生をトリガとしたアラートの通知）を行う。
　そして、監視機能部７２は、例えば、上述のアラートの通知を受け付けると、当該通知を示すアラートメッセージデータをデータバス部６８に出力する。そして、データバス部６８は、１又は複数の通知を示すアラートメッセージデータを１つのファイルにまとめたアラートファイルを生成して、当該アラートファイルをビッグデータプラットフォーム部６６に出力する。
　ビッグデータプラットフォーム部６６は、本実施形態では例えば、データバス部６８から出力される性能指標値ファイルやアラートファイルを蓄積する。
　ＡＩ部７０には、本実施形態では例えば、学習済の機械学習モデルが予め複数記憶されている。ＡＩ部７０は、ＡＩ部７０に記憶されている各種の機械学習モデルを用いて、通信システム１の利用状況やサービス品質の将来予測処理などの推定処理を実行する。ＡＩ部７０は、推定処理の結果を示す推定結果データを生成してもよい。
　ＡＩ部７０は、ビッグデータプラットフォーム部６６に蓄積されるファイルと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、長期的なトレンドの予測を低頻度で行う場合に好適である。
　また、ＡＩ部７０は、データバス部６８に格納されている性能指標値データを取得可能になっている。ＡＩ部７０は、データバス部６８に格納されている性能指標値データと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、短期的な予測を高頻度で行う場合に好適である。
　性能管理部８８は、本実施形態では例えば、複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、ＫＰＩ）を算出する。性能管理部８８は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してもよい。性能管理部８８は、総合評価である性能指標値を示す総合性能指標値データを生成してもよい。
　なお、性能管理部８８は、ビッグデータプラットフォーム部６６から上述の性能指標値ファイルを取得してもよい。また、性能管理部８８は、ＡＩ部７０から推定結果データを取得してもよい。そして、性能指標値ファイル又は推定結果データのうちの少なくとも一方に基づいて、ＫＰＩ等の性能指標値を算出してもよい。なお、性能管理部８８が、監視機能部７２からメトリックデータを直接取得してもよい。そして、当該メトリックデータに基づいて、ＫＰＩ等の性能指標値を算出してもよい。
　障害管理部８６は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の推定結果データ、上述の総合性能指標値データのうちの少なくともいずれかに基づいて、通信システム１における障害の発生を検出する。障害管理部８６は、例えば、所定のロジックに基づいて、単一のメトリックデータや単一のアラートの通知からでは検出できないような障害の発生を検出してもよい。障害管理部８６は、検出された障害を示す検出障害データを生成してもよい。
　なお、障害管理部８６は、メトリックデータやアラートの通知を、監視機能部７２から直接取得してもよい。また、障害管理部８６は、ビッグデータプラットフォーム部６６から性能指標値ファイルやアラートファイルを取得してもよい。また、障害管理部８６は、データバス部６８から、アラートメッセージデータを取得してもよい。
　ポリシーマネージャ部９０は、本実施形態では例えば、上述のメトリックデータ、上述の性能指標値データ、上述のアラートメッセージデータ、上述の性能指標値ファイル、上述のアラートファイル、上述の推定結果データ、上述の総合性能指標値データ、上述の検出障害データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。
　そして、ポリシーマネージャ部９０は、判定処理の結果に応じたアクションを実行してもよい。例えば、ポリシーマネージャ部９０は、スライスマネージャ部９２にネットワークスライスの構築指示を出力してもよい。また、ポリシーマネージャ部９０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示をライフサイクル管理部９４に出力してもよい。
　本実施形態に係るポリシーマネージャ部９０は、データバス部６８に格納されている性能指標値データを取得可能になっている。そして、ポリシーマネージャ部９０は、データバス部６８から取得される性能指標値データに基づいて、所定の判定処理を実行してもよい。また、ポリシーマネージャ部９０は、データバス部６８に格納されているアラートメッセージデータに基づいて、所定の判定処理を実行してもよい。
　チケット管理部８４は、本実施形態では例えば、通信システム１の管理者に通知すべき内容が示されたチケットを生成する。チケット管理部８４は、発生障害データの内容を示すチケットを生成してもよい。また、チケット管理部８４は、性能指標値データやメトリックデータの値を示すチケットを生成してもよい。また、チケット管理部８４は、ポリシーマネージャ部９０による判定結果を示すチケットを生成してもよい。
　そして、チケット管理部８４は、生成されたチケットを、通信システム１の管理者に通知する。チケット管理部８４は、例えば、生成されたチケットが添付された電子メールを、通信システム１の管理者の電子メールアドレスに宛てて送信してもよい。
　ベアメタル管理部９６は、本実施形態では例えば、ＢＩＯＳ（Basic Input Output System）の設定、シングルルートＩ／Ｏ仮想化（ＳＲ－ＩＯＶ）の設定、システムソフトウェアのインストールや入替、などのセットアップを実行する。
　また、本実施形態において、構成管理部７６が、ハードウェアリソースに対して、クラスタＩＤ、ＩＰアドレス、ホスト名、又は、ラベルの設定などといった、ハードウェア若しくはソフトウェアの設定（コンフィギュレーション）を実行してもよい。
　また、ベアメタル管理部９６が、所定の種類のアプリケーションに応じたセットアップを、ハードウェアリソースに対して実行してもよい。
　例えば、構成管理部７６又はベアメタル管理部９６に所定の種類のアプリケーションについてのセットアップを行うためのスクリプト（例えば、Ａｎｓｉｂｌｅスクリプト）が記憶されていてもよい。当該スクリプトには、例えば、特定種類あるいは特定バージョンである、コンテナ実行環境の基盤であるホストＯＳのインストール手順が記述されていてもよい。また、当該スクリプトには、例えば、ホストＯＳのカーネルの設定手順、ＢＩＯＳの設定手順、ＳＲ－ＩＯＶの設定手順などが記述されていてもよい。
　そして、ベアメタル管理部９６が、当該スクリプトを実行することにより、ハードウェアリソースで稼働するアプリケーションの種類に応じたセットアップを、当該ハードウェアリソースに対して実行してもよい。例えば、ベアメタル管理部９６が、コンテナ実行環境のホストＯＳやＢＩＯＳのセットアップを、ハードウェアリソースに対して実行してもよい。
　また、ベアメタル管理部９６は、ハードウェアリソースにインストールされているＯＳ等のシステムソフトウェアの入替を実行してもよい。すなわち、ベアメタル管理部９６は、ハードウェアリソースにインストールされているシステムソフトウェアのアンインストール、及び、当該ハードウェアリソースに対する別のシステムソフトウェアのインストールを実行してもよい。
　以下、本実施形態に係る通信システム１に含まれるハードウェアリソースの管理について、さらに説明する。
　図７は、本実施形態に係る通信システム１に含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。
　ここでは例えば、２人の購入者（購入者Ａ、及び、購入者Ｂ）がネットワークサービスを購入したとする。そして、図７には、購入者Ａが購入したネットワークサービスに含まれるＵＰＦ５０が稼働する第１ハードウェアリソース群１００ａ、及び、第２ハードウェアリソース群１００ｂが示されている。このように、本実施形態において、１人の購入者によって購入されたネットワークサービスに含まれる１種類のＮＦが複数のハードウェアリソース群１００に配置されても構わない。ここで、ハードウェアリソース群１００には、サーバ群が含まれていてもよい。
　また、図７には、購入者Ａが購入したネットワークサービスに含まれるＡＭＦ４６が稼働する第３ハードウェアリソース群１００ｃが示されている。
　また、図７には、購入者Ｂが購入したネットワークサービスに含まれるＵＰＦ５０が稼働する第４ハードウェアリソース群１００ｄ、及び、購入者Ｂが購入したネットワークサービスに含まれるＡＭＦ４６が稼働する第５ハードウェアリソース群１００ｅが示されている。
　なお、購入者Ａ、又は、購入者Ｂが購入したネットワークサービスには、図７に示されていないＮＦ（例えば、ＤＵ４２、ＣＵ４４、ＳＭＦ４８等）も含まれているが、これらのＮＦについては省略されている。
　図７に示すように、本実施形態に係る通信システム１に含まれるハードウェアリソースは、複数のハードウェアリソース群１００に分けて管理されている。例えば、通信システム１に含まれる複数のサーバが、複数のサーバ群に分けて管理されている。
　また、図７に示すように、複数のハードウェアリソース群１００のそれぞれは、当該ハードウェアリソース群１００で稼働するアプリケーションの種類が予め定められていてもよい。図７の例では、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第４ハードウェアリソース群１００ｄでは、ＵＰＦ５０が稼働することが予め定められている。また、第３ハードウェアリソース群１００ｃ、及び、第５ハードウェアリソース群１００ｅでは、ＡＭＦ４６が稼働することが予め定められている。
　また、図７に示すように、複数のハードウェアリソース群１００のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別のハードウェアリソース群１００で稼働していてもよい。図７の例では、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第３ハードウェアリソース群１００ｃで、購入者Ａによって購入されたアプリケーションが稼働する。そして、第４ハードウェアリソース群１００ｄ、及び、第５ハードウェアリソース群１００ｅで、購入者Ｂによって購入されたアプリケーションが稼働する。
　なお、上述のハードウェアリソースは、サーバには限定されない。また、図７に示されているハードウェアリソースの所在は特に問わない。以下の説明では、図７に示されているハードウェアリソースは、セントラルデータセンタ１０に配置されているものであることとするが、当該ハードウェアリソースが、リージョナルデータセンタ１２やエッジデータセンタ１４に配置されていてもよい。
　そして、以下の説明では、１つのハードウェアリソース群１００（例えばサーバ群）は、コンテナ管理ツールによって管理される１つのクラスタ（例えば、１つのクバネテスクラスタ）に相当することとする。なお、１つのハードウェアリソース群１００が、コンテナ管理ツールによって管理される１つのクラスタに相当する必要はない。例えば、コンテナ管理ツールによって管理される１つのクラスタに複数のハードウェアリソース群１００が含まれていてもよい。この場合に、例えば、１つのハードウェアリソース群１００が、１つの名前空間（ネームスペース）に相当するものであってもよい。
　本実施形態では例えば、監視機能部７２が、通信システム１に含まれる複数のハードウェアリソース群１００のそれぞれの使用状況を監視する。ここで例えば、監視機能部７２が、通信システム１に含まれる複数のサーバ群のそれぞれの使用状況を監視してもよい。
　ここでハードウェアリソース群１００の使用状況とは、例えば、ＣＰＵ使用率、メモリ使用量、ストレージ使用量、ネットワーク使用量等を指す。また、ハードウェアリソース群について監視されるこれらの指標のうちの一部又は全部に基づいて算出される総合評価値が、当該ハードウェアリソース群１００の使用状況を示す値として監視されてもよい。
　そして、本実施形態では例えば、上述のように、トラフィック量やレイテンシ等の性能指標値に基づいて、ＮＦ等のアプリケーションのスケーリング（スケールアウトやスケールイン）が実行される。そのためスケーリングに伴い、１つのハードウェアリソース群１００で稼働しているアプリケーションの数は適宜変動する。
　また、本実施形態では例えば、１つのハードウェアリソース群１００で稼働しているアプリケーションの数に基づいて、当該ハードウェアリソース群１００における、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量が特定可能になっている。例えば、アプリケーションの種類ごとの、当該アプリケーション１つあたりの最大ハードウェアリソース量を示すデータが構成管理部７６に記憶されていてもよい。そして、構成管理部７６が、当該データに基づいて、複数のハードウェアリソース群１００（例えば、複数のサーバ群）のそれぞれについて、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量を特定してもよい。このように、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量が、ハードウェアリソース群１００で稼働しているアプリケーションの数に比例してもよい。
　図７では、それぞれのハードウェアリソース群１００に割り当てられているハードウェアリソース量が模式的に示されている。また、図７には、ハードウェアリソース群１００に割り当てられているハードウェアリソース量のそれぞれ一部である、実際使用リソース量１０２、想定最大使用リソース量１０４、及び、スタンバイリソース量１０６が示されている。
　ここで、実際使用リソース量１０２は、ハードウェアリソース群１００で稼働しているアプリケーションによって実際に使用されているハードウェアリソース量に相当する。
　また、想定最大使用リソース量１０４は、上述した、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量に相当する。本実施形態では、ハードウェアリソース群１００で稼働しているアプリケーションの数が変化していない状況でも、ハードウェアリソースの実際の使用量は適宜変動する。そのため、図７に示すように、実際使用リソース量１０２は、想定最大使用リソース量１０４よりも少ない。
　また、スタンバイリソース量１０６は、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から想定最大使用リソース量１０４を引いたハードウェアリソース量に相当する。
　本実施形態では、ハードウェアリソース群１００で稼働しているアプリケーションのスケールアウトが実行されると、想定最大使用リソース量１０４が増加し、想定最大使用リソース量１０４の増加量だけスタンバイリソース量１０６が減少することとなる。
　ハードウェアリソース群１００に割り当てられているハードウェアリソース量（すなわち、想定最大使用リソース量１０４とスタンバイリソース量１０６の合計）は、例えば、購入者がネットワークサービスの購入時に指定することができてもよい。例えば、購入者によるネットワークサービスの購入額が高額になるほど、より多くのハードウェアリソースがハードウェアリソース群１００に割り当てられるようにしてもよい。また、本実施形態において、購入者が、ハードウェアリソース群１００に割り当てられているハードウェアリソースを適宜追加したり削除したりできてもよい。
　また、本実施形態に係る通信システム１では、いずれの上述のハードウェアリソース群１００とも異なる共通予備リソース群１０８（例えば、共通サーバ群）が管理されている。すなわち、本実施形態では、上述の複数のハードウェアリソース群１００（例えば、第１ハードウェアリソース群１００ａから第５ハードウェアリソース群１００ｅ）とは別のハードウェアリソース群が、共通予備リソース群１０８として管理されている。
　図７に示すように、共通予備リソース群１０８には、複数の予備リソース１１０（１１０ａ，１１０ｂ，１１０ｃ，・・・）が含まれている。１つの予備リソース１１０は、例えば、１又は複数のサーバに相当する。
　そして、構成管理部７６が、本実施形態では例えば、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる第１の条件（以下、リソース追加条件と呼ぶ。）を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更する。このようにして、当該ハードウェアリソース群１００にハードウェアリソースが追加され、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量は増加する。
　ここで、構成管理部７６が、いずれかのサーバ群の使用状況が当該サーバ群に対応付けられる条件を満たしたことに応じて、いずれのサーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を共通予備サーバ群から当該サーバ群に変更してもよい。
　また、構成管理部７６が、本実施形態では例えば、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる第２の条件（以下、リソース削除条件と呼ぶ。）を満たしたことに応じて、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００から共通予備リソース群１０８に変更する。このようにして、当該ハードウェアリソース群１００からハードウェアリソースが削除され、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量は減少する。
　なお、本実施形態において、ハードウェアリソース群１００に割り当てられているハードウェアリソースに予備リソース１１０が含まれていない場合は、当該ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース削除条件を満たしても、当該ハードウェアリソース群１００からハードウェアリソースが削除されないようにしてもよい。
　本実施形態では例えば、構成管理部７６が、クラスタＩＤ、ＩＰアドレス、ホスト名、又は、ラベルの設定を実行することで、ハードウェアリソースの所属を変更する。
　例えば、図８に示すように、第１ハードウェアリソース群１００ａに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ１を超えたとする。
　すると、例えば、共通予備リソース群１０８のうちから選択される１つの予備リソース１１０（以下、選択ハードウェアリソースと呼ぶ。）の所属が、共通予備リソース群１０８から第１ハードウェアリソース群１００ａに変更される。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。
　そして、図９に示すように、第１ハードウェアリソース群１００ａに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ２を下回ったとする。ここで、ｐ２の値は、ｐ１よりも小さな値であってもよい。
　すると、例えば、上述の選択ハードウェアリソースの所属が、第１ハードウェアリソース群１００ａから共通予備リソース群１０８に変更される。
　そして、その後、図１０に示すように、第４ハードウェアリソース群１００ｄに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ３を超えたとする。ここで、ｐ３の値は、ｐ１の値と、同じであってもよいし、異なっていてもよい。
　すると、上述の選択ハードウェアリソースの所属が、共通予備リソース群１０８から第４ハードウェアリソース群１００ｄに変更される。
　このように、構成管理部７６は、第１ハードウェアリソース群１００ａから共通予備リソース群１０８に所属が変更されたハードウェアリソースの所属を、第４ハードウェアリソース群１００ｄの使用状況が第４ハードウェアリソース群１００ｄに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８から第４ハードウェアリソース群１００ｄに変更してもよい。
　このようにすれば、あるハードウェアリソース群１００で使用された予備リソース１１０が、他のハードウェアリソース群１００で使用されることとなる。
　また、上述のように、構成管理部７６は、第１ハードウェアリソース群１００ａの使用状況が第１ハードウェアリソース群１００ａに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８のうちから選択される選択ハードウェアリソースの所属を共通予備リソース群１０８から第１ハードウェアリソース群１００ａに変更してもよい。
　そして、構成管理部７６は、第１ハードウェアリソース群１００ａの使用状況が第１ハードウェアリソース群１００ａに対応付けられるリソース削除条件を満たしたことに応じて、当該選択ハードウェアリソースの所属を第１ハードウェアリソース群１００ａから共通予備リソース群１０８に変更してもよい。
　そして、構成管理部７６は、第１ハードウェアリソース群１００ａから共通予備リソース群１０８に所属が変更された当該選択ハードウェアリソースの所属を、第４ハードウェアリソース群１００ｄの使用状況が第４ハードウェアリソース群１００ｄに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８から第４ハードウェアリソース群１００ｄに変更してもよい。
　このようにすれば、特定の予備リソース１１０（選択ハードウェアリソース）が、複数のハードウェアリソース群１００において転々と使用されることとなる。
　また、リソース追加条件やリソース削除条件は、ハードウェアリソースの実際の使用量、又は、ハードウェアリソースの実際の使用率に係る条件であってもよい。例えば、リソース追加条件やリソース削除条件が、実際使用リソース量１０２に係る閾値であってもよい。
　また、リソース追加条件やリソース削除条件は、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件であってもよい。ここで、ハードウェアリソースの実際の余裕量とは、例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いたハードウェアリソース量に相当する。また、ハードウェアリソースの実際の余裕率は、例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量に対する、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いたハードウェアリソース量の割合に相当する。なお、余裕量及び余裕率の算出にあたり、重みづけを行ってもよいし、算出された値にさらに重みをかけるなどの追加の計算を行ってもよい。また、例えば、リソース追加条件やリソース削除条件が、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いた値に係る条件であってもよい。
　また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、ハードウェアリソース群１００でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件であってもよい。すなわち、リソース追加条件やリソース削除条件が、想定最大使用リソース量１０４に係る条件であってもよい。例えば、想定最大使用リソース量１０４が所定の閾値を超えたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。
　また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００で稼働しているアプリケーションの数に対応付けられる条件であってもよい。例えば、スケールアウトによって、ハードウェアリソース群１００で稼働しているアプリケーションの数が３になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。また、スケールインによって、ハードウェアリソース群１００で稼働しているアプリケーションの数が１になったことに応じて、当該ハードウェアリソース群１００に含まれるハードウェアリソースの所属が当該ハードウェアリソース群１００から共通予備リソース群１０８に変更されてもよい。
　通信システム１に含まれるハードウェアリソースを複数のハードウェアリソース群１００に分けて管理する場合に、アプリケーションのスケールアウトが実行されることを見越して、複数のハードウェアリソース群１００のそれぞれで多くのハードウェアリソースを予め確保してしまうと、ハードウェアリソースの無駄が発生してしまう。
　本実施形態では、以上で説明したように、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更される。
　このようにして、本実施形態によれば、通信システム１に含まれるハードウェアリソースを効率的に使用できることとなる。
　また、スケールアウトに伴いハードウェアリソース群１００に既に割り当てられているハードウェアリソースにアプリケーションをデプロイするのに要する時間よりも、スケールアウトに伴い予備リソース１１０の所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更した上で、当該予備リソース１１０にアプリケーションをデプロイするのに要する時間の方が長い。そのため、スケールアウトがスムーズに行われるようにするためには、ハードウェアリソース群１００にできるだけ多くのハードウェアリソースが常時確保されていることが望ましい。
　しかし、ハードウェアリソース群１００に割り当てられているハードウェアリソース量が多いほど購入者が支払う費用が多くなるような状況においては、ハードウェアリソース群１００に常時確保されるハードウェアリソース量はできるだけ少ない方が望ましい。
　一方で、不測の事態により負荷が突発的に高くなった場合や、多くの人が集まるイベントが開催されることが予定されている場合に、ハードウェアリソース群１００に確保されているハードウェアリソースだけでは充分なサービスが提供できないことがある。
　本実施形態では、以上で説明したように、ハードウェアリソース群１００への予備リソース１１０の一時的な追加により、当該ハードウェアリソース群１００に確保されるハードウェアリソースを柔軟に調整することができるので、上述の場合などにおいても充分なサービスを提供できることとなる。
　なお、ハードウェアリソース群１００がコンテナ管理ツールによって管理されるクラスタに相当する場合、本実施形態によれば、コンテナ管理ツールでは行えないような、クラスタをまたぐような予備リソース１１０の所属の変更が可能となる。
　また、本発明は、コアネットワークシステム３４に含まれる他のアプリケーション（ＳＭＦ４８等）が稼働するハードウェアリソース群１００についても適用可能である。
　また、本発明は、ＲＡＮ３２に含まれるアプリケーション（ＤＵ４２、ＣＵ－ＣＰ４４ａ、ＣＵ－ＵＰ４４ｂ等）が稼働するハードウェアリソース群１００にも適用可能である。
　また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる条件であってもよい。例えば、リソース追加条件が、ハードウェアリソース群１００に割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合に係る閾値である場合に、スケールアウトにより増加する想定最大使用リソース量１０４が多いアプリケーションであるほど、当該閾値が小さくなるようにリソース追加条件が設定されてもよい。
　そして、構成管理部７６は、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更してもよい。
　また、構成管理部７６は、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられるリソース削除条件を満たしたことに応じて、当該ハードウェアリソース群１００に含まれるハードウェアリソースの所属を当該ハードウェアリソース群１００から共通予備リソース群１０８に変更してもよい。
　例えば、ＵＰＦ５０が稼働している、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第４ハードウェアリソース群１００ｄについては、リソース追加条件、又は、リソース削除条件のうちの少なくとも一方が同じであってもよい。そして、ＡＭＦ４６が稼働している、第３ハードウェアリソース群１００ｃ、及び、第５ハードウェアリソース群１００ｅについては、リソース追加条件、又は、リソース削除条件のうちの少なくとも一方が同じであってもよい。
　このようにリソース追加条件やリソース削除条件をアプリケーションの種類に対応付けられるものとすることで、複数のアプリケーションの種類のそれぞれについて、当該種類に適したタイミングでのハードウェアリソースの追加や削除を行うことが可能となる。
　また、アプリケーションの購入者が、リソース追加条件やリソース削除条件を、設定できるようにしてもよい。
　また例えば、リソース追加条件やリソース削除条件が、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件であってもよい。このようにすれば、アプリケーションの購入者が、リソース追加条件やリソース削除条件を設定できるようにしつつ、その設定について、アプリケーションの種類に対応付けられる制限を設けることが可能となる。
　また、本実施形態において、共通予備リソース群１０８からハードウェアリソース群１００に所属が変更される予備リソース１１０のハードウェアリソース量が、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量に応じたものになっていてもよい。例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量が多いほど、多くの予備リソース１１０の所属が変更されるようにしてもよい。
　また、ハードウェアリソース群１００に対して、予備リソース１１０の追加（共通予備リソース群１０８から当該ハードウェアリソース群１００への所属の変更）が複数回実行されてもよい。すなわち、ハードウェアリソース群１００に１つの予備リソース１１０が追加された後で、さらに、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたことに応じて、当該ハードウェアリソース群１００にさらに１つの予備リソース１１０が追加されるようにしてもよい。この場合、リソース追加条件は、ハードウェアリソース群１００に追加された予備リソース１１０の数に応じた条件であってもよい。
　また、本実施形態において、ベアメタル管理部９６が、共通予備リソース群１０８からいずれかのハードウェアリソース群１００に所属が変更されるハードウェアリソースに対して、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に応じたセットアップを実行してもよい。そして、構成管理部７６が、当該セットアップが実行されたハードウェアリソースの所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更してもよい。
　以下、アプリケーションの種類に応じたセットアップが実行される状況について、図１１から図１５を参照しながら説明する。
　以下の説明では、図１１に示すように、第６ハードウェアリソース群１００ｆで、購入者Ｃが購入したＵＰＦ５０が稼働していることとする。そして、第７ハードウェアリソース群１００ｇで、購入者Ｃが購入したＡＭＦ４６が稼働していることとする。そして、第８ハードウェアリソース群１００ｈで、購入者Ｃが購入したＤＵ４２が稼働していることとする。
　なお、購入者Ｃが購入したネットワークサービスには、図１１に示されていないＮＦ（例えば、ＣＵ４４、ＳＭＦ４８等）も含まれているが、これらのＮＦについては省略されている。
　そして、共通予備リソース群１０８に含まれている予備リソース１１０（１１０ａ，１１０ｂ，１１０ｃ，・・・）は、所定の種類以外の種類のアプリケーションを稼働させるためには、当該アプリケーションの種類に応じたセットアップを追加で実行する必要がないハードウェアリソースであることとする。例えば、予備リソース１１０は、ＵＰＦ５０ともＤＵ４２とも異なるアプリケーションを稼働させるためには、当該アプリケーションの種類に応じたセットアップを追加で実行する必要がないハードウェアリソースであるとする。
　そして、予備リソース１１０で所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）を稼働させるためには、当該予備リソース１１０に対して、当該種類に応じたセットアップを実行する必要があることとする。アプリケーションの種類によっては、汎用的なハードウェアリソース（例えば、汎用サーバ）では当該アプリケーションを稼働させることができず、当該種類に応じたセットアップを実行する必要があるものがある。本実施形態では例えば、ＵＰＦ５０やＤＵ４２がそのような種類のアプリケーションに相当する。
　図１１に示す状況において、例えば、図１２に示すように、ＡＭＦ４６が稼働している、第７ハードウェアリソース群１００ｇの使用状況が、リソース追加条件を満たしたとする。
　この場合は、共通予備リソース群１０８のうちから選択される予備リソース１１０である選択ハードウェアリソースに対して特段のセットアップが実行されることなく、構成管理部７６は、当該選択ハードウェアリソースの所属を共通予備リソース群１０８から第７ハードウェアリソース群１００ｇに変更してもよい。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。
　また、図１１に示す状況において、例えば、図１３に示すように、ＵＰＦ５０が稼働している、第６ハードウェアリソース群１００ｆの使用状況が、リソース追加条件を満たしたとする。
　この場合、ベアメタル管理部９６が、共通予備リソース群１０８から当該ハードウェアリソース群１００に所属が変更される選択ハードウェアリソースに対して、ＵＰＦ５０に応じたセットアップを実行してもよい。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。そして、構成管理部７６が、当該セットアップが実行された選択ハードウェアリソースの所属を共通予備リソース群１０８から第６ハードウェアリソース群１００ｆに変更してもよい。
　また、上記の場合において、ベアメタル管理部９６は、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソース（例えば、上述の選択ハードウェアリソース）に対して、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に応じたセットアップを実行してもよい。
　また、本実施形態において、ベアメタル管理部９６が、いずれかのハードウェアリソース群１００から共通予備リソース群１０８に所属が変更される、上述のセットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻してもよい。以下、上述のセットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻す処理を、アンセットアップと呼ぶこととする。
　例えば、図１３に示す状況において、例えば、図１４に示すように、ＵＰＦ５０が稼働している第６ハードウェアリソース群１００ｆの使用状況が、リソース削除条件を満たしたとする。
　この場合、ベアメタル管理部９６が、第６ハードウェアリソース群１００ｆから共通予備リソース群１０８に所属が変更される、ＵＰＦ５０に応じたセットアップが実行された選択ハードウェアリソースに対して、アンセットアップを実行してもよい。そして、構成管理部７６が、アンセットアップが実行された選択ハードウェアリソースの所属を第６ハードウェアリソース群１００ｆから共通予備リソース群１０８に変更してもよい。
　また、上記の場合において、ベアメタル管理部９６は、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース削除条件を満たしたことに応じて、上述のセットアップが実行されたハードウェアリソース（例えば、上述の選択ハードウェアリソース）を当該セットアップの実行前の状態に戻してもよい。
　そして、図１４に示す状況において、その後、例えば、図１５に示すように、ＤＵ４２が稼働している第８ハードウェアリソース群１００ｈの使用状況が、リソース追加条件を満たしたとする。
　この場合、ベアメタル管理部９６が、上述の選択ハードウェアリソースに対して、ＤＵ４２に応じたセットアップを実行してもよい。そして、構成管理部７６が、当該セットアップが実行された選択ハードウェアリソースの所属を共通予備リソース群１０８から第８ハードウェアリソース群１００ｈに変更してもよい。
　このように、本実施形態では、共通予備リソース群１０８に含まれる予備リソース１１０は、アプリケーションの種類に応じたセットアップを追加で実行することなく、多くの種類のアプリケーションを稼働させることが可能な汎用的な状態となっている。
　そして、特殊な種類のアプリケーションが稼働するハードウェアリソース群１００に予備リソース１１０の所属を変更する場合には、当該予備リソース１１０に対して当該種類に応じたセットアップが実行されることとなる。また、上述の多くの種類のアプリケーションが稼働するハードウェアリソース群１００に予備リソース１１０の所属を変更する場合には、セットアップを追加で実行する必要がない。
　このようにすることで、通信システム１に含まれるハードウェアリソースをより効率的に使用することができることとなる。
　また、本実施形態において、ネットワークサービスの購入者の要求に応じて、予備リソース１１０の所属が、共通予備リソース群１０８から、当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００に変更されるようにしてもよい。
　また、ネットワークサービスの購入者が、上述のように予め設定されたリソース追加条件を満たした場合に予備リソース１１０の所属が変更されるようにするか否かを設定できてもよい。
　また、ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたことに応じて、ネットワークサービスの購入者にハードウェアリソースの追加要否の問い合わせが通知されるようにしてもよい。そして、当該購入者によってリソースの追加が承認されたことに応じて、予備リソース１１０の所属が共通予備リソース群１０８から当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００に変更されるようにしてもよい。
　同様に、ハードウェアリソース群１００の使用状況がリソース削除条件を満たしたことに応じて、ネットワークサービスの購入者にハードウェアリソースの削除要否の問い合わせが通知されるようにしてもよい。そして、当該購入者によってリソースの削除が承認されたことに応じて、予備リソース１１０の所属が、当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００から共通予備リソース群１０８に変更されるようにしてもよい。
　また、リソース追加条件やリソース削除条件が、アプリケーションが稼働しているサーバ数、又は、空きサーバ数に係る条件であってもよい。例えば、ハードウェアリソース群１００に含まれる空きサーバ数が所定数以下になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。
　また、リソース追加条件やリソース削除条件が、アプリケーションが稼働している仮想マシン（ＶＭ）数、又は、空きＶＭ数に係る条件であってもよい。例えば、ハードウェアリソース群１００に含まれる空きＶＭ数が所定数以下になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。
　ここで、本実施形態に係るプラットフォームシステム３０で行われる、ハードウェアリソース群１００へのハードウェアリソースの追加に関する処理の流れの一例を、図１６に例示するフロー図を参照しながら説明する。
　図１６に例示する処理は、通信システム１に含まれる、上述の所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）が稼働している、すべてのハードウェアリソース群１００において実行される。
　本処理例では、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしているか否かを監視している（Ｓ１０１）。
　ここで、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたと判定すると（Ｓ１０１：Ｙ）、ベアメタル管理部９６が、共通予備リソース群１０８に含まれる選択ハードウェアリソースに対して、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に応じたセットアップを実行する（Ｓ１０２）。
　そして、構成管理部７６が、Ｓ１０２に示す処理でセットアップが実行された選択ハードウェアリソースの所属を、共通予備リソース群１０８から当該ハードウェアリソース群１００に変更して（Ｓ１０３）、Ｓ１０１に示す処理に戻る。
　上述の所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）以外のアプリケーションが稼働している、すべてのハードウェアリソース群１００においては、Ｓ１０２に示す処理が実行されない。そして、ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたと判定されると、構成管理部７６が、選択ハードウェアリソースの所属を、共通予備リソース群１０８から当該ハードウェアリソース群１００に変更して、Ｓ１０１に示す処理に戻る。
　次に、本実施形態に係るプラットフォームシステム３０で行われる、ハードウェアリソース群１００からのハードウェアリソースの削除に関する処理の流れの一例を、図１７に例示するフロー図を参照しながら説明する。
　図１７に例示する処理は、通信システム１に含まれる、上述の所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）が稼働している、すべてのハードウェアリソース群１００において実行される。
　本処理例では、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース削除条件を満たしているか否かを監視している（Ｓ２０１）。
　ここで、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース削除条件を満たしたと判定すると（Ｓ２０１：Ｙ）、ベアメタル管理部９６が、選択ハードウェアリソースに対して、アンセットアップを実行する（Ｓ２０２）。
　そして、構成管理部７６が、Ｓ２０２に示す処理でアンセットアップが実行された選択ハードウェアリソースの所属を、当該ハードウェアリソース群１００から共通予備リソース群１０８に変更して（Ｓ２０３）、Ｓ２０１に示す処理に戻る。
　上述の所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）以外のアプリケーションが稼働している、すべてのハードウェアリソース群１００においては、Ｓ２０２に示す処理が実行されない。そして、ハードウェアリソース群１００の使用状況がリソース削除条件を満たしたと判定されると、構成管理部７６が、選択ハードウェアリソースの所属を、当該ハードウェアリソース群１００から共通予備リソース群１０８に変更して、Ｓ２０１に示す処理に戻る。
　なお、本発明は上述の実施形態に限定されるものではない。
　例えば、以上の説明においてベアメタル管理部９６によって実行される処理が、例えば、構成管理部７６によって実行されてもよい。逆に、以上の説明において構成管理部７６によって実行される処理が、例えば、ベアメタル管理部９６によって実行されてもよい。
　また、本実施形態に係る機能ユニットは図３に示したものには限定されない。
　また、本実施形態に係る機能ユニットは、５ＧにおけるＮＦである必要はない。例えば、本実施形態に係る機能ユニットが、ｅＮｏｄｅＢ、ｖＤＵ、ｖＣＵ、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）などといった、４Ｇにおけるネットワークノードであっても構わない。
　また、本実施形態に係る機能ユニットが、コンテナ型の仮想化技術でなく、ハイパーバイザ型やホスト型の仮想化技術を用いて実現されてもよい。また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。
　本開示に記載の技術は以下のように表現することもできる。
［１］
　通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視手段と、
　いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加手段と、
　を含むことを特徴とするリソース管理システム。
［２］
　前記複数のハードウェアリソース群のそれぞれは、当該ハードウェアリソース群で稼働するアプリケーションの種類が予め定められており、
　前記リソース追加手段は、前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更する、
　ことを特徴とする［１］に記載のリソース管理システム。
［３］
　前記共通予備リソース群からいずれかの前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段、をさらに含み、
　前記リソース追加手段は、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更する、
　ことを特徴とする［２］に記載のリソース管理システム。
［４］
　前記セットアップ実行手段は、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
　ことを特徴とする［３］に記載のリソース管理システム。
［５］
　前記リソース追加手段は、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更し、
　前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、当該ハードウェアリソース群の一部であるハードウェアリソースの所属を当該ハードウェアリソース群から前記共通予備リソース群に変更するリソース削除手段、をさらに含む、
　ことを特徴とする［１］又は［２］に記載のリソース管理システム。
［６］
　前記共通予備リソース群からいずれかの前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段、をさらに含み、
　前記リソース追加手段は、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更し、
　当該ハードウェアリソース群から前記共通予備リソース群に所属が変更される、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行手段、をさらに含む、
　ことを特徴とする［５］に記載のリソース管理システム。
［７］
　前記セットアップ実行手段は、前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行し、
　前記アンセットアップ実行手段は、前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記第２の条件を満たしたことに応じて、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻す、
　ことを特徴とする［６］に記載のリソース管理システム。
［８］
　前記複数の前記ハードウェアリソース群は、第１のハードウェアリソース群と、当該第１のハードウェアリソース群とは異なる第２のハードウェアリソース群と、を含み、
　前記リソース追加手段は、前記第１のハードウェアリソース群から前記共通予備リソース群に所属が変更されたハードウェアリソースの所属を、前記第２のハードウェアリソース群の使用状況が当該第２のハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群から当該第２のハードウェアリソース群に変更する、
　ことを特徴とする［５］に記載のリソース管理システム。
［９］
　前記複数の前記ハードウェアリソース群は、第１のハードウェアリソース群と、当該第１のハードウェアリソース群とは異なる第２のハードウェアリソース群と、を含み、
　前記リソース追加手段は、前記第１のハードウェアリソース群の使用状況が当該第１のハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群のうちから選択される選択ハードウェアリソースの所属を前記共通予備リソース群から当該第１のハードウェアリソース群に変更し、
　前記第１のハードウェアリソース群の使用状況が当該第１のハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、前記選択ハードウェアリソースの所属を当該第１のハードウェアリソース群から前記共通予備リソース群に変更するリソース削除手段、をさらに含み、
　前記リソース追加手段は、前記第１のハードウェアリソース群から前記共通予備リソース群に所属が変更された前記選択ハードウェアリソースの所属を、前記第２のハードウェアリソース群の使用状況が当該第２のハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群から当該第２のハードウェアリソース群に変更する、
　ことを特徴とする［１］又は［２］に記載のリソース管理システム。
［１０］
　前記共通予備リソース群から前記第１の前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該第１の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段、をさらに含み、
　前記リソース追加手段は、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該第１の前記ハードウェアリソース群に変更し、
　当該第１の前記ハードウェアリソース群から前記共通予備リソース群に所属が変更される、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行手段、をさらに含み、
　前記セットアップ実行手段は、前記共通予備リソース群から前記第２の前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該第２の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
　ことを特徴とする［８］又は［９］に記載のリソース管理システム。
［１１］
　前記セットアップ実行手段は、前記第１の前記ハードウェアリソース群の使用状況が当該第１の前記ハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該第１の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行し、
　前記アンセットアップ実行手段は、前記第１の前記ハードウェアリソース群の使用状況が当該第１の前記ハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻し、
　前記セットアップ実行手段は、前記第２の前記ハードウェアリソース群の使用状況が当該第２の前記ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記セットアップの実行前の状態に戻ったハードウェアリソースに対して、当該第２の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
　ことを特徴とする［１０］に記載のリソース管理システム。
［１２］
　前記条件は、ハードウェアリソースの実際の使用量、ハードウェアリソースの実際の使用率、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件である、
　ことを特徴とする［１］から［１１］のいずれか一項に記載のリソース管理システム。
［１３］
　前記条件は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件である、
　ことを特徴とする［１］から［１１］のいずれか一項に記載のリソース管理システム。
［１４］
　前記条件は、前記ハードウェアリソース群で稼働しているアプリケーションの数に対応付けられる条件である、
　ことを特徴とする［１］から［１３］のいずれか一項に記載のリソース管理システム。
［１５］
　前記条件は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件である、
　ことを特徴とする［１］から［１４］のいずれか一項に記載のリソース管理システム。
［１６］
　前記複数のハードウェアリソース群のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別の前記ハードウェアリソース群で稼働している、
　ことを特徴とする［１］から［１５］のいずれか一項に記載のリソース管理システム。
［１７］
　前記使用状況監視手段は、前記通信システムに含まれる複数のサーバ群のそれぞれの使用状況を監視し、
　前記リソース追加手段は、いずれかの前記サーバ群の使用状況が当該サーバ群に対応付けられる条件を満たしたことに応じて、いずれの前記サーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を前記共通予備サーバ群から当該サーバ群に変更する、
　ことを特徴とする［１］から［１６］のいずれか一項に記載のリソース管理システム。
［１８］
　前記ハードウェアリソース群は、コンテナ管理ツールによって管理されるクラスタに相当する、
　ことを特徴とする［１］から［１７］のいずれか一項に記載のリソース管理システム。
［１９］
　通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、
　いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更することと、
　を含むことを特徴とするリソース管理方法。

 

Claims (19)

  1. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサのうちの少なくとも１つによって、
    　通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視処理と、
    　いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加処理と、
    　が実行されるリソース管理システム。
  2. 　前記複数のハードウェアリソース群のそれぞれは、当該ハードウェアリソース群で稼働するアプリケーションの種類が予め定められており、
    　前記リソース追加処理では、前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更する、
    　請求項１に記載のリソース管理システム。
  3. 　前記１以上のプロセッサのうちの少なくとも１つによって、前記共通予備リソース群からいずれかの前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行処理、が実行され、
    　前記リソース追加処理では、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更する、
    　請求項２に記載のリソース管理システム。
  4. 　前記セットアップ実行処理では、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
    　請求項３に記載のリソース管理システム。
  5. 　前記リソース追加処理では、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更し、
    　前記１以上のプロセッサのうちの少なくとも１つによって、前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、当該ハードウェアリソース群の一部であるハードウェアリソースの所属を当該ハードウェアリソース群から前記共通予備リソース群に変更するリソース削除処理、が実行される、
    　請求項１に記載のリソース管理システム。
  6. 　前記１以上のプロセッサのうちの少なくとも１つによって、前記共通予備リソース群からいずれかの前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行処理、が実行され、
    　前記リソース追加処理では、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更し、
    　前記１以上のプロセッサのうちの少なくとも１つによって、当該ハードウェアリソース群から前記共通予備リソース群に所属が変更される、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行処理、が実行される、
    　請求項５に記載のリソース管理システム。
  7. 　前記セットアップ実行処理では、前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行し、
    　前記アンセットアップ実行処理では、前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記第２の条件を満たしたことに応じて、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻す、
    　請求項６に記載のリソース管理システム。
  8. 　前記複数の前記ハードウェアリソース群は、第１のハードウェアリソース群と、当該第１のハードウェアリソース群とは異なる第２のハードウェアリソース群と、を含み、
    　前記リソース追加処理では、前記第１のハードウェアリソース群から前記共通予備リソース群に所属が変更されたハードウェアリソースの所属を、前記第２のハードウェアリソース群の使用状況が当該第２のハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群から当該第２のハードウェアリソース群に変更する、
    　請求項５に記載のリソース管理システム。
  9. 　前記複数の前記ハードウェアリソース群は、第１のハードウェアリソース群と、当該第１のハードウェアリソース群とは異なる第２のハードウェアリソース群と、を含み、
    　前記リソース追加処理では、前記第１のハードウェアリソース群の使用状況が当該第１のハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群のうちから選択される選択ハードウェアリソースの所属を前記共通予備リソース群から当該第１のハードウェアリソース群に変更し、
    　前記１以上のプロセッサのうちの少なくとも１つによって、前記第１のハードウェアリソース群の使用状況が当該第１のハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、前記選択ハードウェアリソースの所属を当該第１のハードウェアリソース群から前記共通予備リソース群に変更するリソース削除処理、が実行され、
    　前記リソース追加処理では、前記第１のハードウェアリソース群から前記共通予備リソース群に所属が変更された前記選択ハードウェアリソースの所属を、前記第２のハードウェアリソース群の使用状況が当該第２のハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記共通予備リソース群から当該第２のハードウェアリソース群に変更する、
    　請求項１に記載のリソース管理システム。
  10. 　前記１以上のプロセッサのうちの少なくとも１つによって、前記共通予備リソース群から前記第１の前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該第１の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行するセットアップ実行処理、が実行され、
    　前記リソース追加処理では、前記セットアップが実行された前記ハードウェアリソースの所属を前記共通予備リソース群から当該第１の前記ハードウェアリソース群に変更し、
    　前記１以上のプロセッサのうちの少なくとも１つによって、当該第１の前記ハードウェアリソース群から前記共通予備リソース群に所属が変更される、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行処理、が実行され、
    　前記セットアップ実行処理では、前記共通予備リソース群から前記第２の前記ハードウェアリソース群に所属が変更されるハードウェアリソースに対して、当該第２の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
    　請求項８に記載のリソース管理システム。
  11. 　前記セットアップ実行処理では、前記第１の前記ハードウェアリソース群の使用状況が当該第１の前記ハードウェアリソース群に対応付けられる第１の条件を満たしたことに応じて、前記共通予備リソース群に含まれるハードウェアリソースに対して、当該第１の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行し、
    　前記アンセットアップ実行処理では、前記第１の前記ハードウェアリソース群の使用状況が当該第１の前記ハードウェアリソース群に対応付けられる第２の条件を満たしたことに応じて、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻し、
    　前記セットアップ実行処理では、前記第２の前記ハードウェアリソース群の使用状況が当該第２の前記ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、前記セットアップの実行前の状態に戻ったハードウェアリソースに対して、当該第２の前記ハードウェアリソース群で稼働しているアプリケーションの種類に応じたセットアップを実行する、
    　請求項１０に記載のリソース管理システム。
  12. 　前記条件は、ハードウェアリソースの実際の使用量、ハードウェアリソースの実際の使用率、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件である、
    　請求項１に記載のリソース管理システム。
  13. 　前記条件は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件である、
    　請求項１に記載のリソース管理システム。
  14. 　前記条件は、前記ハードウェアリソース群で稼働しているアプリケーションの数に対応付けられる条件である、
    　請求項１に記載のリソース管理システム。
  15. 　前記条件は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件である、
    　請求項１に記載のリソース管理システム。
  16. 　前記複数のハードウェアリソース群のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別の前記ハードウェアリソース群で稼働している、
    　請求項１に記載のリソース管理システム。
  17. 　前記使用状況監視処理では、前記通信システムに含まれる複数のサーバ群のそれぞれの使用状況を監視し、
    　前記リソース追加処理では、いずれかの前記サーバ群の使用状況が当該サーバ群に対応付けられる条件を満たしたことに応じて、いずれの前記サーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を前記共通予備サーバ群から当該サーバ群に変更する、
    　請求項１に記載のリソース管理システム。
  18. 　前記ハードウェアリソース群は、コンテナ管理ツールによって管理されるクラスタに相当する、
    　請求項１に記載のリソース管理システム。
  19. 　通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、
    　いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を前記共通予備リソース群から当該ハードウェアリソース群に変更することと、
    　を含むことを特徴とするリソース管理方法。

     
PCT/JP2022/036742 2022-09-30 2022-09-30 通信システムに含まれるハードウェアリソースの管理 WO2024069948A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/036742 WO2024069948A1 (ja) 2022-09-30 2022-09-30 通信システムに含まれるハードウェアリソースの管理

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/036742 WO2024069948A1 (ja) 2022-09-30 2022-09-30 通信システムに含まれるハードウェアリソースの管理

Publications (1)

Publication Number Publication Date
WO2024069948A1 true WO2024069948A1 (ja) 2024-04-04

Family

ID=90476981

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/036742 WO2024069948A1 (ja) 2022-09-30 2022-09-30 通信システムに含まれるハードウェアリソースの管理

Country Status (1)

Country Link
WO (1) WO2024069948A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005128866A (ja) * 2003-10-24 2005-05-19 Hitachi Ltd 計算機装置及び計算機装置の制御方法
JP2007310749A (ja) * 2006-05-19 2007-11-29 Hitachi Information Systems Ltd サーバリソース提供システム及びサーバリソース提供方法
WO2021171211A1 (ja) * 2020-02-26 2021-09-02 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド リソースプール管理システム、リソースプール管理方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005128866A (ja) * 2003-10-24 2005-05-19 Hitachi Ltd 計算機装置及び計算機装置の制御方法
JP2007310749A (ja) * 2006-05-19 2007-11-29 Hitachi Information Systems Ltd サーバリソース提供システム及びサーバリソース提供方法
WO2021171211A1 (ja) * 2020-02-26 2021-09-02 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド リソースプール管理システム、リソースプール管理方法及びプログラム

Similar Documents

Publication Publication Date Title
EP2957071B1 (en) Method, system, and computer readable medium for providing a thinking diameter network architecture
US10481935B2 (en) Management system, overall management node, and management method for managing virtualization resources in a mobile communication network
US10481953B2 (en) Management system, virtual communication-function management node, and management method for managing virtualization resources in a mobile communication network
EP3800926B1 (en) Alarm method and device
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
US20150215228A1 (en) Methods, systems, and computer readable media for a cloud-based virtualization orchestrator
US20140317261A1 (en) Defining interdependent virtualized network functions for service level orchestration
US20230043362A1 (en) Computer system and network slice management method
WO2019109039A1 (en) Priority based resource management in a network functions virtualization (nfv) environment
EP4165505A1 (en) Container orchestration system
KR102452758B1 (ko) 가상화된 네트워크 기능들
WO2024069948A1 (ja) 通信システムに含まれるハードウェアリソースの管理
WO2024069949A1 (ja) 通信システムに含まれるハードウェアリソースの管理
WO2023218663A1 (ja) 実行基盤決定システム及び実行基盤決定方法
WO2023218664A1 (ja) リプレースシステム及びリプレース方法
WO2023188185A1 (ja) 配置システム及び配置方法
WO2024047774A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2023188186A1 (ja) 通信経路決定システム及び通信経路決定方法
WO2024047775A1 (ja) 通信システムに係る所与の予測目的で用いられる機械学習モデルの決定
WO2023157200A1 (ja) スケーリング制御システム及びスケーリング制御方法
WO2024004102A1 (ja) キューに格納されている性能指標値データに基づく通信システムの状態判定
WO2023188187A1 (ja) 通信経路決定システム及び通信経路決定方法
WO2023157199A1 (ja) 妥当性検証システム及び妥当性検証方法
WO2024024106A1 (ja) ネットワーク負荷の予測開始タイミングの制御