WO2024069846A1 - 仮想化ネットワーク機能のためのリソース割り当ての動的な変更 - Google Patents

仮想化ネットワーク機能のためのリソース割り当ての動的な変更 Download PDF

Info

Publication number
WO2024069846A1
WO2024069846A1 PCT/JP2022/036428 JP2022036428W WO2024069846A1 WO 2024069846 A1 WO2024069846 A1 WO 2024069846A1 JP 2022036428 W JP2022036428 W JP 2022036428W WO 2024069846 A1 WO2024069846 A1 WO 2024069846A1
Authority
WO
WIPO (PCT)
Prior art keywords
applications
cnf
resource allocation
controller
app
Prior art date
Application number
PCT/JP2022/036428
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/036428 priority Critical patent/WO2024069846A1/ja
Publication of WO2024069846A1 publication Critical patent/WO2024069846A1/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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements

Definitions

  • This disclosure relates to dynamically changing resource allocation within a host to create virtualized network functions.
  • VNFs virtual network functions
  • development also referred to as "development” or “deployment”
  • applications may be deployed as Virtual Machines (VMs) or Containerized Network Functions (CNFs) in the cloud close to the users who will receive the service.
  • VMs Virtual Machines
  • CNFs Containerized Network Functions
  • Whether a VM/CNF can be deployed is determined by a management device (e.g., an orchestrator) based on the resource allocation rate of the destination cloud (i.e., how much of the CPU, memory, storage, etc. has already been allocated). However, it may happen that the resources of the destination cloud are not used effectively.
  • a management device e.g., an orchestrator
  • the present disclosure is devised to address at least one of the problems of the prior art and provides for dynamic modification of resource allocations to create virtualized network functions.
  • the controller in the virtualization infrastructure includes one or more processors. At least one of the one or more processors discovers common processes for two or more applications within the same host, aggregates the common processes to create a new application, and shrinks resource allocations for each of the two or more applications by the resource allocation for the new application.
  • the method of managing resources within the same host includes discovering common processes for two or more applications within the same host using a virtualization platform, consolidating the common processes using the virtualization platform to create a new application, and shrinking the resource allocation for each of the two or more applications using the virtualization platform by the amount of resource allocation for the new application.
  • FIG. 1 is a diagram illustrating an example of a communication network system in which the method or controller according to the present disclosure may be applied.
  • FIG. 2 is a schematic diagram for explaining application virtualization by a virtual machine and hardware resources.
  • FIG. 3 is a schematic diagram for explaining application virtualization by containers and hardware resources.
  • FIG. 4 is a diagram showing the relationship between services and applications in the microservices architecture.
  • FIG. 5 is a schematic diagram showing an example of hardware resource management according to the present embodiment.
  • FIG. 6 is a functional block diagram showing the configuration of a virtualization platform according to this embodiment.
  • FIG. 7 shows an example of shrinking hardware resource allocation for two or more applications according to the present embodiment.
  • FIG. 8 is a flowchart showing an example of a method for managing resources within the same host according to the present embodiment.
  • FIG. 9 is a block diagram showing a configuration of the controller shown in FIG.
  • the communication network system 1 in Fig. 1 includes a radio access network (RAN) 200 and a core network (CN) 800.
  • Each of the RANs 200 includes one or more CUs (Central Units) 210, DUs (Distributed Units) 220, and RUs (Radio Units) 230, and realizes the functions of a base station.
  • the RUs 230 form a coverage area (not shown) and can communicate with an information processing device.
  • the information processing device may be, in particular, a user equipment (UE) 90.
  • the CUs 210 are connected to the CN 800.
  • the functions of the DU 220 and the CU 210 are virtualized in a virtualization infrastructure 300 on a cloud (not shown) and constructed as a virtualized DU (vDU) 220 and a virtualized CU (vCU) 210, respectively.
  • vDU virtualized DU
  • vCU virtualized CU
  • connections between devices (CU, DU, or RU elements) in the RAN 200 and with the CN 800 can be made to comply with specifications standardized by O-RAN (O-RAN Alliance) etc.
  • O-RAN O-RAN Alliance
  • the space between the RU 230 and the vDU 220 is called a fronthaul
  • the space between the vDU 220 and the vCU 210 is called a midhaul
  • the space between the vCU 210 and the CN 800 is called a backhaul.
  • Standardization of connections between devices allows multiple vendors to provide RU 230, vDU 220, and vCU 210 in RAN 200 in FIG. 1 (multi-vendor).
  • the management device 100 may be connected to the vCU 210, the vDU 220, and the RU 230, and may configure and manage them.
  • the management device 100 may be an orchestrator (particularly, an End-to-End (E2E) orchestrator).
  • the management device 100 is a device for configuring and managing the communication network system 1 .
  • the management device 100 can generate (deploy) applications for providing various services to UEs 90 within a coverage area formed by one or more RUs 230 on the virtualization infrastructure 300 .
  • a typical example of a deployed application is a vCU 210 or a vDU 220 for providing RAN 200 services to a UE 90 .
  • the "application" to be deployed is not limited to vCU210 or vDU220, but refers to applications in general for providing various services to UE90.
  • SNFs Service Network Functions
  • AMF Access and Mobility Management Function
  • UPF User Plane Function
  • examples of services other than RAN 200 and CN 800 include web distribution services, game provision services, video distribution services, music distribution services, monitoring services, navigation services, autonomous driving services, email provision services, and sensor services.
  • examples of applications that provide these services include web distribution applications, game provision applications, video distribution applications, music distribution applications, surveillance execution applications, navigation applications, autonomous driving applications, email provision applications, and sensor execution applications.
  • Application virtualization can be broadly divided into virtual machine-based and container-based virtualization. Next, we will explain virtualization using virtual machines or containers and hardware resources.
  • FIG. 2 is a schematic diagram for explaining application virtualization by a virtual machine (VM) and hardware resources.
  • a virtualization infrastructure 300 is built on a physical server 500.
  • the virtualization infrastructure 300 may be constructed directly on the physical server 500 (native type), or may be constructed on the host OS 400 of the physical server 500 (host type) as shown in Fig. 2.
  • the physical server 500 may be a single machine or a cluster consisting of two or more machines.
  • VM#1, VM#2, and VM#3 are each assigned the hardware resources of the physical server 500.
  • the hardware resources of the physical server 500 are computational resources, typically the number of assigned CPUs or the number of CPU cores.
  • the physical server 500 has six cores, two cores are assigned to each of VM#1 and VM#2, and one core is assigned to VM#3.
  • the hardware resources (computing resources) of the physical server 500 are divided and used by each virtual machine.
  • VM#1, VM#2, and VM#3 the physical server 500 has only one core remaining that can be assigned to another virtual machine (e.g., VM#4). Therefore, VM#4, which requires two cores to be assigned, cannot be deployed to the virtualization infrastructure 300. In other words, the freedom to deploy new virtual machines is limited.
  • FIG. 3 is a schematic diagram for explaining application virtualization and hardware resources using containers.
  • a virtualization infrastructure 300 is constructed on a host OS 400 of a physical server 500.
  • the physical server 500 may be a single machine or a cluster consisting of two or more machines.
  • a service is composed of one or more applications.
  • the number of applications that compose one service varies depending on the service.
  • Each application is constructed from one or more Containerized Network Functions (CNFs).
  • CNF runs on, for example, "Kubernetes" (registered trademark).
  • Kubernetes is open source software (OSS) that automatically configures and manages containerized services.
  • the number of CNFs that configure one application may vary depending on the application and design.
  • Fig. 2 shows that an application APP#1 is configured from n (n is an integer) CNF#11, CNF#12, ..., CNF#1n.
  • CNF that runs on Kubernetes is constructed from one or more Pods.
  • a Pod is the smallest unit of an application that can run on Kubernetes. Multiple Pods are operated and managed by Kubernetes. Pods that run on CNF have a self-repair function; for example, when a Pod stops operating, another Pod is started and the CNF function is self-repaired. Each Pod is constructed from one or more containers.
  • microservices architecture is also being considered for 5G (fifth generation mobile communication system).
  • 5G fifth generation mobile communication system
  • examples of the above-mentioned services in 5G include a radio access network (RAN) and a core network (CN).
  • RAN radio access network
  • CN core network
  • a CU Central Unit
  • DU Distributed Unit
  • the CNF indicated by CNF#11 can be a CU-CP (Control Plane), and the CNF indicated by CNF#12 can be a CU-UP (User Plane).
  • the CU-CP includes Radio Resource Control (RRC), and the CU-UP includes Service Data Adaption Protocol (SDAP) and Packet Data Convergence Protocol (PDCP) related to the user plane.
  • RRC Radio Resource Control
  • SDAP Service Data Adaption Protocol
  • PDCP Packet Data Convergence Protocol
  • the CU-CP and CU-UP can communicate with each other via an E1 interface. Both the CU-CP and CU-UP can be connected to the DU via an F1 interface.
  • CNF#1, CNF#2, and CNF#3 are deployed on a virtualization infrastructure 300.
  • CNF#1, CNF#2, and CNF#3 are each assigned the computational resources of the physical server 500.
  • the physical server 500 has six cores, with CNF#1 and CNF#2 each assigned two cores, and CNF#3 assigned one core.
  • the hardware resources (computational resources) of the physical server 500 are divided and used by each CNF, but which hardware resources are used varies over time, but the amount of resources (e.g., the number of cores) allocated to each of the three CNFs does not change.
  • CNF#1, CNF#2, and CNF#3 the physical server 500 has only one core remaining that can be assigned to another CNF (for example, CNF#4). Therefore, CNF#4, which requires two cores to be assigned, cannot be deployed to the virtualization infrastructure 300. In other words, the freedom to deploy new CNFs is limited.
  • FIG. Fig. 5 is a schematic diagram showing an example of hardware resource management according to the present embodiment.
  • the deployment of an application by a VM and the deployment of an application by a container are collectively described.
  • the same parts as those in Fig. 2 or Fig. 3 are denoted by the same reference numerals.
  • Fig. 5 when an application is deployed by a VM, two cores are assigned to VM#1.
  • Fig. 5 when an application is deployed by a container, two cores are assigned to CNF#1.
  • the cases of VM#1 and CNF#1 will be collectively referred to as "VM/CNF#1".
  • the ratio of resources used by VM/CNF#1 out of the resources allocated at the time of deployment (“resource usage rate”) is monitored by the virtualization infrastructure 300. This monitoring can be performed by the controller 310 (see FIG. 6) of the virtualization infrastructure 300. For example, even if two cores are assigned to VM/CNF#1 at the time of deployment, if the operation drops and only one core is used later, the resource utilization rate will be 50%. More generally, the resource utilization rate is assumed to be in the range of 0 to 100% by taking the average within a unit time.
  • the resources assigned to a VM or CNF whose operation has decreased can be shrunk.
  • Shrinking means, for example, reducing the number of cores.
  • the resources can be shrunk by the virtualization platform 300, particularly the controller 310 of the virtualization platform 300 (see FIG. 6). For example, assume that a VM or CNF to which N cores (N is an integer equal to or greater than 2) are assigned has a resource usage rate of less than (1-1/N) x 100%.
  • the VM or CNF can operate even if at least one of the N cores is released. Therefore, the resources allocated to the VM or CNF can be shrunk. More generally, if the resource usage rate is less than (1-m/N) x 100% (where m is an integer equal to or greater than 1 and less than N), the VM or CNF can operate even if m of the N cores are released. 5, two cores are assigned to VM/CNF#1 at the time of deployment, so the assigned resources may be shrunk when the resource usage rate falls below 50%.
  • a value equal to or less than 50% may be set as a threshold, and the assigned resources may be shrunk when the resource usage rate falls below the threshold. More generally, for a VM or CNF that is allocated one or more cores at deployment time, some of the cores may be deallocated when resource utilization falls below a threshold.
  • the resources allocated to the new VM or CNF are increased.
  • the resources of the deployment destination cloud are used more efficiently, and the degree of freedom of deployment is increased.
  • the resource usage rate may continue to be monitored by the virtualization infrastructure 300 to determine whether further shrinkage is possible.
  • Fig. 6 is a functional block diagram showing the configuration of a virtualization platform according to this embodiment.
  • the virtualization infrastructure 300 includes a controller 310 that manages a virtualization function.
  • the controller 310 includes a common process discovery unit 311, a new application creation unit 313, and a resource allocation reduction unit 315.
  • the virtualization infrastructure 300 and the controller 310 may include components not shown.
  • the virtualization infrastructure 300 may include a worker (not shown) on which a virtualized network function (VNF) is actually constructed, and the controller 310 in this disclosure may also function as a part that controls the worker.
  • VNF virtualized network function
  • APP#1 and APP#2 are deployed on the same host.
  • the host does not have any resources at all or has insufficient resources to newly deploy an application other than APP#1 and APP#2.
  • APP#1 and APP#2 can be applications in the microarchitecture described with reference to FIG.
  • the common process discovery unit 311 monitors two or more applications (APP#1 and APP#2 in FIG. 6) on the same host and discovers a common process (especially CNF). A specific example of the method will be described later.
  • the new application creation unit 313 collects the common processes discovered by the common process discovery unit 311 and creates a new application (referred to as APP# 3 in FIG. 6; see reference numeral 63 ) on the virtualization infrastructure 300 . Assume that two or more applications (APP#1 and APP#2) of the same host are applications in the microarchitecture described in Fig. 4. If the common process is one or more CNFs, a new application (APP#3) is an application in the microarchitecture that includes these one or more CNFs.
  • the resource allocation reduction unit 315 shrinks the resource allocation from each of the two or more applications (APP#1 and APP#2) to the new application (APP#3). That is, the resource allocation of the two or more applications (APP#1 and APP#2) is shrunk by canceling the resource allocation for the common process included in the new application (APP#3).
  • the operations of APP#1 and APP#2 after shrinking can be continued on the same host by using APP#3, also from the viewpoint of authentication for data sharing between different applications.
  • FIG. 7 is a diagram illustrating an example of reducing hardware resource allocation for two or more applications according to the present embodiment.
  • FIG. 7 shows processes (CNF) contained in two applications (APP#1 and APP#2) on the same host.
  • APP#1 includes CNF#1, CNF#2, CNF#3, and CNF#5.
  • APP#2 includes CNF#2, CNF#4, and CNF#5.
  • CNF processes contained in two applications
  • APP#1 includes CNF#1, CNF#2, CNF#3, and CNF#5.
  • APP#2 includes CNF#2, CNF#4, and CNF#5.
  • CNF CNF
  • FIG. 7 shows processes (CNF) contained in two applications (APP#1 and APP#2) on the same host.
  • APP#1 includes CNF#1, CNF#2, CNF#3, and CNF#5.
  • APP#2 includes CNF#2, CNF#4, and CNF#5.
  • APP#1 is assigned four cores
  • APP#2 is assigned three core
  • APP#1 and APP#2 include CNF#2 and CNF#5 as common processes. Therefore, a new application (APP#3) including CNF#2 and CNF#5 is created in the virtualization infrastructure 300. Then, for APP#1 and APP#2, resource allocations for CNF#2 and CNF#5 are canceled, and APP#3 is used. After shrinking, APP#1 is assigned two cores to CNF#1 and CNF#3, APP#2 is assigned one core to CNF#4, and APP#3 is assigned two cores to CNF#2 and CNF#5, for a total of five cores. Therefore, before and after shrinking, two more cores can be allocated for new deployment of APPs other than APP#1, APP#2, and APP#3, thereby increasing the degree of freedom in deployment.
  • the virtualization infrastructure 300 finds a common process (CNF) between two or more applications in the same host, and combines the common processes to create a new application. Therefore, the operation of a common process grouped together as a new application among two or more applications will decrease. Then, the resource allocation for each of the two or more applications is shrunk by the amount of the resource allocation for the new application by the virtualization platform. This allows more resources to be allocated to other applications. Overall, this allows for more efficient use of the resources of the cloud where the application is deployed, and increases the flexibility of deployment.
  • CNF common process
  • the common process discovery unit 311 may monitor two or more applications on the same host to discover a common process, for example, in the following two examples. These methods may be executed by the common process discovery unit 311 from the viewpoint of authentication for data sharing between different applications on the same host. (1) Monitoring the Operation of Applications The common process discovery unit 311 can employ a method of specifically discovering a common process by monitoring the operation of two or more applications, like a proxy server. (2) Monitoring Based on a Catalog at the Time of Deployment Applications may be deployed using a file called a catalog (also called a catalog file or a bundle catalog). The common process discovery unit 311 can employ a method of discovering common processes based on the catalog used in each application, for example, by creating the table shown in FIG. 7 .
  • a method 1000 for managing resources within a same host will be described with reference to Fig. 8.
  • This method can be particularly executed by a controller of a virtualization infrastructure.
  • the method 1000 includes discovering common processes (particularly CNF) for two or more applications within the same host via a virtualization infrastructure (reference number S1010).
  • the method 1000 includes orchestrating common processes through a virtualization infrastructure to create new applications (see reference numeral 1020).
  • the method 1000 includes shrinking resource allocations for each of the two or more applications by an amount corresponding to the resource allocation for the new application by the virtualization infrastructure (reference number S1030).
  • the present disclosure also includes a program for causing a system to execute the above-mentioned resource management method 1000.
  • the program may be provided by being recorded on a computer-readable, non-transitory storage medium.
  • the controller 310 can be realized by a device shown in the block diagram of FIG.
  • the controller 310 of FIG. 9 includes a transceiver unit 3110 and a processor unit 3120 .
  • the transmission/reception unit 3110 transmits and receives data to and from other components of the virtualization platform, the host OS, the physical server, or a management device (orchestrator), etc.
  • the processing unit 3120 includes a processor 3121 and a memory 3123. There may be one or more processors 3121 and memories 3123.
  • the processing unit 3120 may further include a storage 3125.
  • the processing unit 3120 operates the transmission/reception unit 3110, and can execute processing as the controller 310 by the processor 3121 and the memory 3123.
  • the controller 310 may further include components not shown in FIG.
  • connection means a logical connection for communication.
  • “B connected to A” means that A and B are logically connected so that they can communicate.
  • a and B do not need to be directly physically connected by a physical cable or the like, and there may be multiple devices or wireless communication between A and B.
  • the present disclosure includes the following aspects:
  • a controller in a virtualization infrastructure comprising one or more processors; by at least one of the one or more processors, Discovering common processes for two or more applications within the same host; bringing together said common processes to create a new application; and shrinking a resource allocation for each of the two or more applications by an amount corresponding to the resource allocation for the new application; Run the controller.
  • the controller described in [1] discovers the common process for two or more applications in the same host by monitoring the operation of each of the two or more applications in the controller.
  • a method for managing resources within a same host comprising: discovering common processes for two or more applications within the same host via a virtualization infrastructure; creating a new application by consolidating the common processes through the virtualization infrastructure; shrinking a resource allocation for each of the two or more applications by an amount corresponding to the resource allocation for the new application through the virtualization infrastructure;
  • the method includes:

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本開示に係る仮想化基盤内のコントローラは、１以上のプロセッサを含む。　前記１以上のプロセッサの少なくとも一つによって、同一のホスト内の２以上のアプリケーション（ｖＣＵ又はｖＤＵ等のＶＮＦ、又はその他のアプリケーション）について共通のプロセス（ＣＮＦ）を発見することと、前記共通のプロセスを纏めて新規アプリケーションを創出することと、前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクする（コア数を減らす）ことと、を実行する。

Description

仮想化ネットワーク機能のためのリソース割り当ての動的な変更
　本開示は、仮想化ネットワーク機能を生成するためのホスト内でのリソース割り当ての動的な変更に関する。
　通信ネットワークシステムにおいて、サービスの提供に必要なコンテナ又は仮想化ネットワーク機能（ＶＮＦ：Virtual Network Function）等のアプリケーションの生成（「展開」又は「デプロイ」とも言う。）がされることがある。
　アプリケーションは、サービスの種類に応じて、サービスの提供を受けるユーザの近くにあるクラウドに仮想マシン（ＶＭ）またはＣＮＦ（Containerized Network Function）としてデプロイされることがある。
　ＶＭ／ＣＮＦがデプロイ可能かどうかは、デプロイ先クラウドのリソース割り当て率（つまり、ＣＰＵ、メモリ又はストレージ等を既にどれぐらい割り当ててしまっているか）に基づいて、管理装置（例えばオーケストレータ）が判断している。しかし、デプロイ先クラウドのリソースの有効利用がされていないことが起こり得る。
　本開示は、従来技術の問題点の少なくとも１つを解決しようと案出されたものであり、仮想化ネットワーク機能を生成するためのリソース割り当ての動的な変更を提供する。
　本開示に係る仮想化基盤内のコントローラは、１以上のプロセッサを含む。
　前記１以上のプロセッサの少なくとも一つによって、同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、前記共通のプロセスを纏めて新規アプリケーションを創出することと、前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、を実行する。
　本開示に係る同一のホスト内のリソースを管理する方法は、仮想化基盤によって前記同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、前記仮想化基盤によって前記共通のプロセスを纏めて新規アプリケーションを創出することと、前記仮想化基盤によって前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、を含む。
図１は、本開示に係る方法又はコントローラが適用される通信ネットワークシステムの例を示す図である。 図２は、仮想マシンによるアプリケーションの仮想化とハードウェアリソースについて説明するための模式図である。 図３は、コンテナによるアプリケーションの仮想化とハードウェアリソースについて説明するための模式図である。 図４は、マイクロサービスアーキテクチャにおける、サービスと、アプリケーションとの関係を示す図である。 図５は、本実施形態に係るハードウェアリソースの管理の例を示す模式図である。 図６は、本実施形態に係る仮想化基盤の構成を示す機能ブロック図である。 図７は、本実施形態に係る２以上のアプリケーションのハードウェアリソース割り当てをシュリンクする例を示す。 図８は、本実施形態に係る同一のホスト内のリソースを管理する方法の例を示すフローチャートである。 図９は、図６に示すコントローラの構成を示すブロック図である。
　以下、本開示の一実施形態について、図面を参照して詳細に説明する。
　図１に、本開示に係る方法又はコントローラが適用される通信ネットワークシステムの例を示す。図１の通信ネットワークシステム１は、無線アクセスネットワーク（ＲＡＮ）２００と、コアネットワーク（ＣＮ）８００とを含む。
　ＲＡＮ２００はそれぞれ１以上のＣＵ（Central Unit）２１０と、ＤＵ（Distributed Unit）２２０と、ＲＵ（Radio Unit）２３０とを含み、基地局の機能を実現する。ＲＡＮ２００においてＲＵ２３０はカバレッジエリア（図示せず）を形成し、情報処理装置と通信することができる。情報処理装置は特にユーザ端末（ＵＥ）９０であってよい。また、ＣＵ２１０はＣＮ８００に接続している。
　ＤＵ２２０の機能及びＣＵ２１０の機能は、クラウド（図示せず）上の仮想化基盤３００で仮想化されて、仮想化ＤＵ（ｖＤＵ）２２０、及び仮想化ＣＵ（ｖＣＵ）２１０としてそれぞれ構築されている。
　以降の記載においては、特に必要がなければ、ＤＵとｖＤＵを区別せずに記載し、ＣＵとｖＣＵを区別せずに記載することがある。
　更に、ＲＡＮ２００における機器（ＣＵ、ＤＵ又はＲＵの要素）間及びＣＮ８００との接続については、Ｏ－ＲＡＮ（O-RAN Alliance）等によって標準化された仕様に従うようにすることができる。なお、ＲＵ２３０とｖＤＵ２２０との間をフロントホール、ｖＤＵ２２０とｖＣＵ２１０との間をミッドホール、及び、ｖＣＵ２１０とＣＮ８００との間をバックホールと呼ぶ。
　機器間の接続の標準化により、図１のＲＡＮ２００におけるＲＵ２３０、ｖＤＵ２２０及びｖＣＵ２１０について、複数のベンダーが提供すること（マルチベンダー化）が可能である。
　また、管理装置１００がｖＣＵ２１０、ｖＤＵ２２０及びＲＵ２３０に接続し、それらの設定や管理をし得る。管理装置１００はオーケストレータ（特にEnd-to-End（Ｅ２Ｅ）オーケストレータ）であってもよい。
　管理装置１００は、通信ネットワークシステム１の設定や管理を行うための装置である。
　管理装置１００は、１以上のＲＵ２３０により形成されるカバレッジエリア内のＵＥ９０に様々なサービスを提供するためのアプリケーションを、仮想化基盤３００に生成（デプロイ）することができる。
　デプロイされるアプリケーションの典型例は、ＵＥ９０にＲＡＮ２００のサービスを提供するためのｖＣＵ２１０又はｖＤＵ２２０である。
　しかし、本開示において、デプロイされる「アプリケーション」は、ｖＣＵ２１０又はｖＤＵ２２０に限定されず、ＵＥ９０に様々なサービスを提供するためのアプリケーション全般を指す。
　例えば、ＵＥ９０にＣＮ８００のサービスを提供するために、ＡＭＦ（Access and Mobility Management Function）、ＵＰＦ（User Plane Function）等のＣＮ８００を構築するＳＮＦ（Service Network Function）がデプロイされてもよい。
　また、ＲＡＮ２００及びＣＮ８００以外のサービスとして、Ｗｅｂ配信サービス、ゲーム提供サービス、映像配信サービス、音楽配信サービス、監視サービス、ナビゲーションサービス、自動運転サービス、メール提供サービス、センサーサービスが例示される。
　これらのサービスを提供するアプリケーションとしては、Ｗｅｂ配信アプリケーション、ゲーム提供アプリケーション、映像配信アプリケーション、音楽配信アプリケーション、監視実行アプリケーション、ナビゲーションアプリケーション、自動運転アプリケーション、メール提供アプリケーション、センサー実行アプリケーションが例示される。
　アプリケーションの仮想化は、仮想マシンによるものとコンテナによるものに大別される。次に、仮想マシン又はコンテナによる仮想化とハードウェアリソースについて説明する。
　まず、図２を参照して、仮想マシンによる仮想化とハードウェアリソースについて説明する。
　図２は仮想マシン（ＶＭ）によるアプリケーションの仮想化とハードウェアリソースについて説明するための模式図である。図２においては、物理サーバ５００に仮想化基盤３００が構築されている。
　なお、仮想化基盤３００は物理サーバ５００上に直接構築されてもよい（ネイティブ型）し、図２のように物理サーバ５００のホストＯＳ４００上に構築されてもよい（ホスト型）。また、物理サーバ５００は単一のマシンでもよいし、２以上のマシンからなるクラスタであってもよい。
　図２の例においては、３つのアプリケーションが３つの仮想マシン（ＶＭ＃１、ＶＭ＃２及びＶＭ＃３）として仮想化されている。
　ここで、ＶＭ＃１、ＶＭ＃２及びＶＭ＃３にはそれぞれ物理サーバ５００のハードウェアリソースが割り当てられている。ここで、物理サーバ５００のハードウェアリソースとは計算リソースであり、割り当てられるＣＰＵの数又はＣＰＵのコア数がその典型である。
　図２においては、物理サーバ５００は６コアを有しており、ＶＭ＃１及びＶＭ＃２にはそれぞれ２コアが割り当てられており、ＶＭ＃３には１コアが割り当てられている。
　つまり、図２の例は、物理サーバ５００のハードウェアリソース（計算リソース）が分割されて各仮想マシンに使用されている。
　よって、ＶＭ＃１、ＶＭ＃２及びＶＭ＃３があるために、物理サーバ５００には別の仮想マシン（例えばＶＭ＃４とする）に割り当てることが可能なコアが１つしか残っていない。そのため、２コアが割り当てられる必要のあるＶＭ＃４については、仮想化基盤３００にデプロイすることができない。つまり、新たな仮想マシンのデプロイの自由度が制限されている。
　次に、図３を参照して、コンテナによる仮想化とハードウェアリソースについて説明する。
　図３はコンテナによるアプリケーションの仮想化とハードウェアリソースについて説明するための模式図である。図３においては、物理サーバ５００のホストＯＳ４００上に仮想化基盤３００が構築されている。物理サーバ５００は単一のマシンでもよいし、２以上のマシンからなるクラスタであってもよい。
　図３におけるアプリケーションの仮想化の説明のために、図４を参照して、マイクロサービスアーキテクチャにおける、サービスと、アプリケーション（以下、「ＡＰＰ」とも記載する）との関係を説明する。
　図４に示すように、サービスは１以上のアプリケーションから構築されている。１つのサービスを構築するアプリケーション数は、サービスによって異なる。
　各アプリケーションは、１以上のＣＮＦ（Containerized Network Function）から構築されている。
　ＣＮＦは、例えば、「Kubernetes」（登録商標）上で動作する。Kubernetesは、コンテナ化されたサービスの設定及び管理を自動で行うオープンソースソフトウェア（ＯＳＳ）である。
　１つのアプリケーションを構築するＣＮＦ数は、アプリケーション及び設計によって異なり得る。図２には、アプリケーションＡＰＰ＃１が、ｎ個（ｎは整数）のＣＮＦ＃１１、ＣＮＦ＃１２、…、ＣＮＦ＃１ｎから構築されている様子が示されている。
　Kubernetes上で動作するＣＮＦは、１以上のＰｏｄから構築される。Ｐｏｄは、Kubernetesで実行できるアプリケーションの最小単位である。複数のＰｏｄは、Kubernetesにより運用管理される。ＣＮＦで動作するＰｏｄは、自己修復機能を有しており、例えば、あるＰｏｄが動作を停止したときに、別のＰｏｄが起動され、ＣＮＦの機能が自己修復される。
　各Ｐｏｄは、１以上のコンテナから構築される。
　５Ｇ（第５世代移動通信システム）においても、マイクロサービスアーキテクチャの利用が検討されている。
　５Ｇにおける上記サービスとしては、無線アクセスネットワーク（ＲＡＮ）、及び、コアネットワーク（ＣＮ）が例示される。前述のように、サービスがＲＡＮの場合、ＣＵ（Central Unit）及びＤＵ（Distributed Unit）がアプリケーションに相当する。
　特に、ＡＰＰ＃１で示されるアプリケーションがＣＵの場合、ＣＮＦ＃１１で示されるＣＮＦをＣＵ－ＣＰ（Control Plane）とし、ＣＮＦ＃１２で示されるＣＮＦをＣＵ－ＵＰ（User Plane）とすることができる。
　ＣＵ－ＣＰには無線リソース制御（ＲＲＣ）が含まれる。ＣＵ－ＵＰにはユーザプレーンに関連するＳＤＡＰ（Service Data Adaption Protocol）及びＰＤＣＰ（Packet Data Convergence Protocol）が含まれる。
　ＣＵ－ＣＰとＣＵ－ＵＰとは、Ｅ１インターフェースにより機能連携通信が可能である。ＣＵ－ＣＰ及びＣＵ－ＵＰの双方は、Ｆ１インターフェースでＤＵに接続可能である。
　図３の例に戻る。３つのＣＮＦ（ＣＮＦ＃１、ＣＮＦ＃２及びＣＮＦ＃３）が仮想化基盤３００にデプロイされている。
　ここで、ＣＮＦ＃１、ＣＮＦ＃２及びＣＮＦ＃３はそれぞれ物理サーバ５００の計算リソースを割り当てられている。
　図３においては、物理サーバ５００は６コアを有しており、ＣＮＦ＃１及びＣＮＦ＃２がそれぞれ２コアを割り当てられており、ＣＮＦ＃３は１コアを割り当てられている。
　なお、図３の例では、物理サーバ５００のハードウェアリソース（計算リソース）が分割されて各ＣＮＦに使用されるが、どのハードウェアリソースが使用されるかは時間で変動する。ただし、３つのＣＮＦのそれぞれに割り当てられたリソースの量（例えばコア数）は変動しない。
　よって、ＣＮＦ＃１、ＣＮＦ＃２及びＣＮＦ＃３があるために、物理サーバ５００には別のＣＮＦ（例えばＣＮＦ＃４とする）に割り当てることが可能なコアが１つしか残っていない。そのため、２コアが割り当てられる必要のあるＣＮＦ＃４については仮想化基盤３００にデプロイすることができない。つまり、新たなＣＮＦのデプロイの自由度が制限されている。
　次に、図５を参照して、特にリソースのシュリンクについて説明する。
　図５は、本実施形態に係るハードウェアリソースの管理の例を示す模式図である。図５においては、ＶＭによってアプリケーションがデプロイされることと、コンテナによってアプリケーションがデプロイされることとをまとめて説明する。図５では、図２又は図３と同じ部分には同じ符号を付す。
　図５において、ＶＭによるアプリケーションのデプロイ時には、ＶＭ＃１には２コアが割り当てられている。図５において、コンテナによるデプロイ時には、ＣＮＦ＃１には２コアが割り当てられている。以下、ＶＭ＃１の場合とＣＮＦ＃１の場合をまとめて「ＶＭ／ＣＮＦ＃１」として説明する。
　デプロイ時に割り当てられたリソースのうち、ＶＭ／ＣＮＦ＃１が使用しているリソースの割合（「リソース使用率」）は仮想化基盤３００によって監視される。仮想化基盤３００のコントローラ３１０（図６参照）によって、この監視をすることができる。
　例えばデプロイ時にＶＭ／ＣＮＦ＃１に２コアが割り当てられていたとしても、その後、稼動が下がり、１コアしか使用されていない場合にはリソース使用率は５０％となる。なお、より一般的には、リソース使用率は単位時間内での平均を取ることにして０から１００％の範囲にあるとする。
　図５のようにデプロイ時にＶＭ／ＣＮＦ＃１に２コアが割り当てられていたとしても、リソース使用率が５０％未満になると、２つのうち１コアのＶＭ／ＣＮＦ＃１への割り当てを解消してもＶＭ／ＣＮＦ＃１の動作が可能である。このように、稼動が下がったＶＭ又はＣＮＦへ割り当てられたリソースをシュリンク（縮小）することができる。シュリンクとは例えばコア数を減らすことを意味する。仮想化基盤３００、特に仮想化基盤３００のコントローラ３１０（図６参照）によってリソースをシュリンクすることができる。
　例えば、Ｎ個（Ｎは２以上の整数とする）のコアが割り当てられたＶＭ又はＣＮＦについて、リソース使用率が（１－１／Ｎ）×１００％未満になっているとする。その場合、当該ＶＭ又はＣＮＦについては、Ｎコアのうち少なくとも１コアの割り当てを解消しても動作が可能である。よって、当該ＶＭ又はＣＮＦへ割り当てられたリソースをシュリンクすることができる。さらに一般的に、リソース使用率が（１－ｍ／Ｎ）×１００％未満（ここでｍは１以上Ｎ未満の整数とする）であれば、Ｎコアのうちｍコアの割り当てを解消しても動作が可能である。
　図５の例ではデプロイ時にＶＭ／ＣＮＦ＃１に２コアが割り当てられているので、リソース使用率が５０％未満になったときに割り当てられたリソースをシュリンクするようにしてもよい。または、動作の安定性などを目的として５０％以下の値（例えば４０％）を閾値として、リソース使用率が閾値未満になったときに割り当てられたリソースをシュリンクするようにしてもよい。
　さらに一般的に、デプロイ時に１以上のコアが割り当てられたＶＭ又はＣＮＦに対して、リソース使用率が閾値未満になったときに、そのうちいくつかのコアについて割り当てを解消することができる。
　稼動が下がったＶＭ又はＣＮＦへ割り当てられたリソースをシュリンクすると、新たなＶＭ又はＣＮＦへ割り当てられるリソースが増える。総じて、デプロイ先クラウドのリソースの有効利用がされて、デプロイの自由度が増大する。
　なお、リソースをシュリンクした後であっても、更にシュリンクすることが可能か否かを判断するために、仮想化基盤３００によってリソース使用率は引き続き監視され得る。
　次に、図６を参照して、仮想化基盤によってリソースをシュリンクすることについて説明する。
　図６は、本実施形態に係る仮想化基盤の構成を示す機能ブロック図である。図６では、図２又は図３と同じ部分には同じ符号を付す。
　仮想化基盤３００は、仮想化機能を司るコントローラ３１０を含む。コントローラ３１０は共通プロセス発見部３１１と、新規アプリケーション創出部３１３と、リソース割り当て縮小部３１５とを含む。仮想化基盤３００及びコントローラ３１０は図示しない構成を含んでもよい。
　なお、仮想化基盤３００は、実際に仮想化ネットワーク機能（ＶＮＦ）が構築されるワーカ（図示せず）を含むことができるが、本開示におけるコントローラ３１０は、ワーカを制御する部位を兼ねてもよい。
　図６においては、同一のホストに、ＡＰＰ＃１とＡＰＰ＃２（符号６１と６２を参照）の２つのアプリケーションがデプロイされている。特に、ＡＰＰ＃１とＡＰＰ＃２とは別のアプリケーションを新たにデプロイするためのリソースがホスト内に全く無い場合、又は、不足している場合を想定する。
　なお、ＡＰＰ＃１及びＡＰＰ＃２は図４で説明したマイクロアーキテクチャにおけるアプリケーションとすることができる。
　共通プロセス発見部３１１は同一のホストの２以上のアプリケーション（図６ではＡＰＰ＃１とＡＰＰ＃２）を監視して、共通のプロセス（特にＣＮＦ）を発見する。その具体的方法の例については後述する。
　新規アプリケーション創出部３１３は、共通プロセス発見部３１１で発見された共通のプロセスを纏めて新規のアプリケーション（図６においてＡＰＰ＃３とする。符号６３参照。）を仮想化基盤３００上に創出する。
　同一のホストの２以上のアプリケーション（ＡＰＰ＃１及びＡＰＰ＃２）が図４で説明したマイクロアーキテクチャにおけるアプリケーションであるとする。共通のプロセスが１以上のＣＮＦである場合には、新規のアプリケーション（ＡＰＰ＃３）はこれら１以上のＣＮＦを含む、マイクロアーキテクチャにおけるアプリケーションである。
　リソース割り当て縮小部３１５は、２以上のアプリケーション（ＡＰＰ＃１とＡＰＰ＃２）の各々から新規アプリケーション（ＡＰＰ＃３）に対するリソース割り当てをシュリンクする。つまり、新規のアプリケーション（ＡＰＰ＃３）に含まれる共通のプロセスについてはリソースの割り当てを解消することにより、２以上のアプリケーション（ＡＰＰ＃１とＡＰＰ＃２）のリソース割り当てをシュリンクする。
　シュリンクした後のＡＰＰ＃１及びＡＰＰ＃２の動作については、同一のホストにおいては、異なるアプリケーション間のデータ共有についての認証の観点からも、ＡＰＰ＃３を援用することによって継続し得る。
　図７は、本実施形態に係る２以上のアプリケーションに対するハードウェアリソース割り当てを縮小する例を示す図である。
　図７では、同一のホストにおける２つのアプリケーション（ＡＰＰ＃１とＡＰＰ＃２）について、それらに含まれるプロセス（ＣＮＦ）を示している。
　ＡＰＰ＃１はＣＮＦ＃１、ＣＮＦ＃２、ＣＮＦ＃３及びＣＮＦ＃５を含んでいる。ＡＰＰ＃２はＣＮＦ＃２、ＣＮＦ＃４及びＣＮＦ＃５を含んでいる。説明を簡単にするために、図７の例では、デプロイ時に各ＣＮＦに１つのコアが割り当てられているとする。ＡＰＰ＃１には４コアが割り当てられ、ＡＰＰ＃２には３コアが割り当てられるから、合計７コアが割り当てられている。より一般的な場合についても容易に理解し得る。
　ここで、ＡＰＰ＃１とＡＰＰ＃２は共通のプロセスとして、ＣＮＦ＃２及びＣＮＦ＃５を含んでいる。そこで、ＣＮＦ＃２及びＣＮＦ＃５を含む新規のアプリケーション（ＡＰＰ＃３）を仮想化基盤３００に創出する。そして、ＡＰＰ＃１及びＡＰＰ＃２についてはＣＮＦ＃２及びＣＮＦ＃５に対するリソース割り当てが解消されて、ＡＰＰ＃３が援用される。
　シュリンクした後は、ＡＰＰ＃１についてはＣＮＦ＃１及びＣＮＦ＃３に２コア、ＡＰＰ＃２についてはＣＮＦ＃４に１コア、ＡＰＰ＃３についてはＣＮＦ＃２及びＣＮＦ＃５に２コアであるから、合計５コアが割り当てられる。
　よって、シュリンクの前後で２コアをＡＰＰ＃１、ＡＰＰ＃２及びＡＰＰ＃３以外のＡＰＰの新たなデプロイのために更に割り当てることができるので、デプロイの自由度が増大する。
　つまり、仮想化基盤３００、特にそのコントローラ３１０は、同一のホスト内の２以上のアプリケーションについて共通のプロセス（ＣＮＦ）を見出し、共通のプロセスを纏めて新規アプリケーションを創出するようにしている。
　よって、２以上のアプリケーションのうち、新規アプリケーションとして括り出した共通のプロセスについては稼動が下がることになる。
　そして、仮想化基盤によって２以上のアプリケーションの各々に対するリソース割り当てを、新規アプリケーションに対するリソース割り当て分だけシュリンクしている。
　これにより、別のアプリケーションへ割り当てられるリソースが増える。総じて、デプロイ先クラウドのリソースの有効利用がされて、デプロイの自由度が増大する。
　また、管理装置（オーケストレータ）１００ではなく、仮想化基盤３００においてリソース割り当ての変更をすることにより、管理装置１００だけの場合に比べて、より細かいリソース割り当ての調整が可能になる。
　なお、共通プロセス発見部３１１は同一のホストの２以上のアプリケーションを監視して、共通のプロセスを発見する方法については例えば次の２例がある。これらの方法は同一のホストにおいては、異なるアプリケーション間のデータ共有についての認証の観点からも共通プロセス発見部３１１により実行し得る。
（１）アプリケーションの動作の監視
　共通プロセス発見部３１１は代理サーバ（プロキシ）のように、２以上のアプリケーションの動作を監視して、具体的に共通プロセスを発見する方法を採用することができる。
（２）デプロイ時のカタログに基づく監視
　アプリケーションは、カタログと称されるファイル（カタログファイル、バンドルカタログとも言う。）が用いられてデプロイされることがある。共通プロセス発見部３１１は、各アプリケーションに用いられたカタログに基づいて、共通プロセスを発見し、例えば図７のテーブルを作成して、共通プロセスを発見する方法を採用することができる。
　図８を参照して、本実施形態に係る同一のホスト内のリソースを管理する方法１０００について説明する。この方法は、特に、仮想化基盤のコントローラによって実行することができる。
　方法１０００は、仮想化基盤によって同一のホスト内の２以上のアプリケーションについて共通のプロセス（特にＣＮＦ）を発見すること（符号Ｓ１０１０）を含む。
　方法１０００は、仮想化基盤によって共通のプロセスを纏めて新規アプリケーションを創出すること（符号Ｓ１０２０）を含む。
　方法１０００は、仮想化基盤によって２以上のアプリケーションの各々に対するリソース割り当てから新規アプリケーションに対するリソース割り当て分だけシュリンクすること（符号Ｓ１０３０）を含む。
　更に上述のリソースを管理する方法１０００をシステムに実行させるためのプログラムも本開示に含まれる。当該プログラムは、コンピュータ読み取り可能で非一時的な（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）記憶媒体に記録されて提供されてよい。
　また、本実施形態に係るコントローラ３１０は図９のブロック図に示す装置によって実現することができる。
　図９のコントローラ３１０は送受信部３１１０と処理部３１２０を含む。
　送受信部３１１０は仮想化基盤の他の部品、ホストＯＳ、物理サーバ又は管理装置（オーケストレータ）等との間でデータを送受信する。
　処理部３１２０は、プロセッサ３１２１及びメモリ３１２３を含む。なお、プロセッサ３１２１及びメモリ３１２３は１個でも複数でもよい。処理部３１２０は更にストレージ３１２５を含んでもよい。処理部３１２０は送受信部３１１０を動作させるとともに、プロセッサ３１２１及びメモリ３１２３によって、コントローラ３１０としての処理を実行することができる。
　コントローラ３１０は、図９に示していない構成を更に含んでいてもよい。
　本開示は、上述の実施形態に限定されるものではなく、上述の構成に対して、構成要素の付加、削除又は転換を行った様々な変形例も含むものとする。また、各実施例が様々に組み合わせることが可能である。
　なお、本説明において用いられた「接続」という用語は、通信のための論理的接続を意味する。例えば、「Ａに接続しているＢ」とは、ＡとＢとが通信可能なように論理的に接続されていることを意味する。Ａ及びＢが物理的なケーブル等で物理的に直接接続されている必要はないし、ＡとＢの間に複数の機器や無線通信が介在していてもよい。
　更に、本開示は次の態様を含む。
　[１]仮想化基盤内のコントローラであって、１以上のプロセッサを含み、
　前記１以上のプロセッサの少なくとも一つによって、
　　同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、
　　前記共通のプロセスを纏めて新規アプリケーションを創出することと、
　　前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、
を実行する、コントローラ。
　[２]前記コントローラにおいて、２以上のアプリケーションの各々の動作を監視することによって、同一のホスト内の前記２以上のアプリケーションについて前記共通のプロセスを発見する、[１]に記載のコントローラ。
　[３]２以上のアプリケーションの各々のデプロイ時の情報に基づいて、同一のホスト内の前記２以上のアプリケーションについて前記共通のプロセスを発見する、[１]に記載のコントローラ。
　[４]前記デプロイ時の情報はカタログに関する情報である、[３]に記載のコントローラ。
　[５]同一のホスト内のリソースを管理する方法であって、
　　仮想化基盤によって前記同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、
　　前記仮想化基盤によって前記共通のプロセスを纏めて新規アプリケーションを創出することと、
　　前記仮想化基盤によって前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、
を含む方法。
１　　　　　　　　通信ネットワークシステム
６１、６２、６３　アプリケーション
９０　　　　　　　ＵＥ
１００　　　　　　管理装置
２００　　　　　　ＲＡＮ
２１０　　　　　　ｖＣＵ
２２０　　　　　　ｖＤＵ
２３０　　　　　　ＲＵ
３００　　　　　　仮想化基盤
３１０　　　　　　コントローラ
３１１０　　　　　送受信部
３１２０　　　　　処理部
３１２１　　　　　プロセッサ
３１２３　　　　　メモリ
３１２５　　　　　ストレージ
３１１　　　　　　共通プロセス発見部
３１３　　　　　　新規アプリケーション創出部
３１５　　　　　　リソース割り当て縮小部
４００　　　　　　ホストＯＳ
５００　　　　　　物理サーバ
８００　　　　　　ＣＮ
１０００　　　　　リソースを管理する方法

Claims (5)

  1. 　仮想化基盤内のコントローラであって、１以上のプロセッサを含み、
    　前記１以上のプロセッサの少なくとも一つによって、
    　　同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、
    　　前記共通のプロセスを纏めて新規アプリケーションを創出することと、
    　　前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、
    を実行する、コントローラ。
  2. 　前記コントローラにおいて、２以上のアプリケーションの各々の動作を監視することによって、同一のホスト内の前記２以上のアプリケーションについて前記共通のプロセスを発見する、請求項１に記載のコントローラ。
  3. 　２以上のアプリケーションの各々のデプロイ時の情報に基づいて、同一のホスト内の前記２以上のアプリケーションについて前記共通のプロセスを発見する、請求項１に記載のコントローラ。
  4. 　前記デプロイ時の情報はカタログに関する情報である、請求項３に記載のコントローラ。
  5. 　同一のホスト内のリソースを管理する方法であって、
    　　仮想化基盤によって前記同一のホスト内の２以上のアプリケーションについて共通のプロセスを発見することと、
    　　前記仮想化基盤によって前記共通のプロセスを纏めて新規アプリケーションを創出することと、
    　　前記仮想化基盤によって前記２以上のアプリケーションの各々に対するリソース割り当てを、前記新規アプリケーションに対するリソース割り当て分だけシュリンクすることと、
    を含む方法。
PCT/JP2022/036428 2022-09-29 2022-09-29 仮想化ネットワーク機能のためのリソース割り当ての動的な変更 WO2024069846A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/036428 WO2024069846A1 (ja) 2022-09-29 2022-09-29 仮想化ネットワーク機能のためのリソース割り当ての動的な変更

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/036428 WO2024069846A1 (ja) 2022-09-29 2022-09-29 仮想化ネットワーク機能のためのリソース割り当ての動的な変更

Publications (1)

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

Family

ID=90476788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/036428 WO2024069846A1 (ja) 2022-09-29 2022-09-29 仮想化ネットワーク機能のためのリソース割り当ての動的な変更

Country Status (1)

Country Link
WO (1) WO2024069846A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007524889A (ja) * 2003-03-19 2007-08-30 ユニシス　コーポレイシヨン サーバ統合のデータモデル
JP2016527780A (ja) * 2013-06-26 2016-09-08 アマゾン テクノロジーズ インコーポレイテッド リースエージェントシステム間での制作者システムの分配
WO2020036106A1 (ja) * 2018-08-13 2020-02-20 日本電信電話株式会社 通信システムおよび通信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007524889A (ja) * 2003-03-19 2007-08-30 ユニシス　コーポレイシヨン サーバ統合のデータモデル
JP2016527780A (ja) * 2013-06-26 2016-09-08 アマゾン テクノロジーズ インコーポレイテッド リースエージェントシステム間での制作者システムの分配
WO2020036106A1 (ja) * 2018-08-13 2020-02-20 日本電信電話株式会社 通信システムおよび通信方法

Similar Documents

Publication Publication Date Title
CN107924383B (zh) 用于网络功能虚拟化资源管理的系统和方法
US20210004258A1 (en) Method and Apparatus for Creating Virtual Machine
EP3530037B1 (en) System and method for network slice management in a management plane
US11947697B2 (en) Method and system to place resources in a known state to be used in a composed information handling system
US9999030B2 (en) Resource provisioning method
CN111698112B (zh) 一种容器化虚拟网络功能vnf的资源管理方法及装置
US10397132B2 (en) System and method for granting virtualized network function life cycle management
US20200358666A1 (en) Releasing and retaining resources for use in a nfv environment
US20100293544A1 (en) Integrated virtual and physical resource provisioning system
EP3481007A1 (en) Method, device, and equipment for processing resource pool
CN117897691A (zh) 在Kubernetes中使用远程POD
KR102524540B1 (ko) 멀티 클라우드 서비스 플랫폼 장치 및 방법
CN116800616B (zh) 虚拟化网络设备的管理方法及相关装置
CN114615268B (zh) 基于Kubernetes集群的服务网络、监控节点、容器节点及设备
KR20220104241A (ko) 네트워크 작업 방법, 장치, 설비 및 저장매체
EP4202668A1 (en) Computer system and container management method and device
US20210240511A1 (en) Computer-implemented method for reducing service disruption times for a universal customer premise equipment, ucpe, device with resource constraint in a network functions virtualization, nfv, network infrastucture
CN113127144B (zh) 一种处理方法、装置及存储介质
JP2024501005A (ja) コンテナクラスタのための管理方法および装置
US20230138867A1 (en) Methods for application deployment across multiple computing domains and devices thereof
CN112015515B (zh) 一种虚拟网络功能的实例化方法及装置
WO2024069846A1 (ja) 仮想化ネットワーク機能のためのリソース割り当ての動的な変更
JP6591045B2 (ja) ネットワークサービスを移行するための方法及びネットワークサービス装置
US11928515B2 (en) System and method for managing resource allocations in composed systems
WO2019011180A1 (zh) 一种License的发送方法和装置

Legal Events

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

Ref document number: 22960906

Country of ref document: EP

Kind code of ref document: A1