(57)【要約】      （修正有）【課題】サービスレイヤの要望に適したリソースの組合せおよびリソースのパラメータを決定するリソース決定装置を提供する。【解決手段】リソース決定装置１０は、通信サービスについて、自然言語で表現されたサービスレイヤの要望を解析する解析手段１１と、前記解析手段により解析されたサービスレイヤの要望に適したリソースの組合せを決定する組合せ決定手段１２と、前記組合せ決定手段により決定されたリソースの組合せに含まれるリソースのパラメータを決定するパラメータ決定手段１３と、を有する。【選択図】図２
2019087105.tif 000002
【特許請求の範囲】
【請求項１】
通信サービスについて、自然言語で表現されたサービスレイヤの要望を解析する解析手段と、
前記解析手段により解析されたサービスレイヤの要望に適したリソースの組合せを決定する組合せ決定手段と、
前記組合せ決定手段により決定されたリソースの組合せに含まれるリソースのパラメータを決定するパラメータ決定手段と
を備えたリソース決定装置。
【請求項２】
前記解析手段は、
前記サービスレイヤの要望で示される文を単語に分解し、
前記分解された単語に対しその属性に応じたタグを付与し、
前記タグが付与された単語の属性に基づいて、複数種類のサービスレイヤの要望を解析する、
請求項１に記載のリソース決定装置。
【請求項３】
前記組合せ決定手段は、
リソースの組合せの基本構成に対し、前記解析手段により解析されたサービスレイヤの要望に応じたカスタマイズ・ルールを適用して、前記基本構成をカスタマイズすることで、前記リソースの組合せを決定する、
請求項１に記載のリソース決定装置。
【請求項４】
前記パラメータ決定手段は、
前記組合せ決定手段により決定されたリソースの組み合わせに含まれるリソースのパラメータに影響を与える複数種類の要素の関係を学習してモデルを生成し、
前記生成されたモデルを用いて、前記組合せ決定手段により決定されたリソースのパラメータを決定する、
請求項１に記載のリソース決定装置。
【請求項５】
リソース決定装置が行うリソース決定方法であって、
通信サービスについて、自然言語で表現されたサービスレイヤの要望を解析し、
前記解析されたサービスレイヤの要望に適したリソースの組合せを決定し、
前記決定されたリソースの組合せに含まれるリソースのパラメータを決定する
リソース決定方法。
【請求項６】
請求項１乃至４のいずれか１項に記載のリソース決定装置の前記各手段としてプロセッサを機能させるリソース決定処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、リソース決定装置、リソース決定方法およびリソース決定処理プログラムに関する。
【背景技術】
【０００２】
一般に、通信事業者が顧客に通信サービス（以下、サービスと称することがある）を提供する際には、顧客からサービスレイヤの要望を受領し、この要望に応じて、トラフィックを転送する通信経路（以下、リンクリソース）と、トラフィックを処理するネットワーク機能を配置するノード（以下、機能リソース）とをそれぞれ割り当てることで、ネットワークを利用可能な状態にする。したがって、ネットワークサービスの管理では、サービスレイヤの要望に応じたリソースの組合せ方、及びパラメータの決定が重要な要素である。一般的に、これらの決定は通信事業者のオペレータのスキルに依存している。
【０００３】
レガシーネットワークにおける通信サービスを提供する場合、リソースの組合せとパラメータの決定の自由度が低いため、オペレータは通信サービスを提供するためのスキルを短時間で習得できる。
【０００４】
仮想化ネットワーク技術NFV（Network Functions Virtualization）は、汎用サーバ上で多様なネットワーク機能、例えば、Firewall(FW)機能、 Web Server(WS)機能等を生成でき、さらに、各機能に割り当てるリソースの量、例えば、CPU数やメモリ量等を自由に変えることによって、リソースの処理能力を自由に変更できるようにしている。B2B2X(Business to Business to Consumer)時代では、通信事業者(ファーストB)が提供するNFV技術により構築された柔軟かつ安価な通信サービスを利用して、サービス事業者(ミドルB、ユーザ)がエンドユーザ(X)にサービスを提供する形態が増えると想定されている。この状況に対して通信事業者に求められる要件として、サービス事業者からのサービスレイヤの要望に対応した通信サービス提供と、当該通信サービスを実現するための効率的なリソース管理がある。
【０００５】
サービス事業者からのサービスレイヤの要望の具体例を説明する。オンラインバンキングを提供するサービス事業者が通信サービスを申込む際に関心を持っている事項は、サービスの機能であるオンラインバンキング・サービス、通信サービスの安全性及び通信サービスが収容できるユーザ数等である。動画サービスを提供するサービス事業者は、サービスの機能である動画サービス、サービスの処理能力、帯域等に注目している。これらのサービスレイヤの要望に応じてサービスを提供することが通信事業者に求められている。
【０００６】
当該通信サービスを実現するための効率的なリソース管理は、サービス事業者からのサービスレイヤの要望に応じて、サービスを構成する適切なリソースの種類とリソースのパラメータをそれぞれ決定することである。具体例として、オンラインバンキングというサービスレイヤでの要望(Service layer requirement)に応じて、仮想ネットワークリソース、例えばdeep packet inspection(DPI)、 firewall、 web server、 application server(AS)等の組合せを決定し、各リソースの処理能力等を表すパラメータの値を決定することは、サービスレイヤの要望に応じたリソース管理である。
【０００７】
サービスレイヤの要望の多様性、及び仮想化リソースの設定の高い自由度によって、サービスレイヤの要望に応じた効率的なリソース管理を行なうために、通信事業者のオペレータにはリソース管理の高度なスキルが要求される。これにより、仮想化されたネットワークにおけるサービス提供の複雑性、および管理コストが顕著に増加するという問題が発生する。
【０００８】
例えば、通信サービスのユーザ(サービス事業者)がサービスレイヤでの要望を用いて仮想化ネットワークサービスを申し込む場合で、ユーザが、リソースの管理を通信事業者に期待している。この状況で、通信事業者がユーザに仮想化ネットワークサービスを提供する際に、ユーザのサービスレイヤでの要望に応じて、リソースを決定するために、通信事業者のオペレータに高度なスキルが要求される。
【０００９】
サービスレイヤの要望は、サービスの機能とサービスの負荷についての要求とが挙げられる。サービスの機能は、例えばweb service, CDN(Content Delivery Network) service, high securityが挙げられ、サービスの負荷についての要求は、例えばWork load 10万ユーザ、1000 request/secondが挙げられる。
【００１０】
また、決定すべきリソースレイヤの内容としては、サービスを実現するためのリソースの組合せと該当リソースパラメータの値が挙げられる。サービスを実現するためのリソースの組合せは、例えば、web serviceを実現するためには、firewall, web server, data baseでなる３種類のリソースを使用する。  
また、リソースパラメータの値は、例えば、リソースのインスタンスの配置先、該当リソースのインスタンスのCPU数とMemory量が挙げられる。
【００１１】
次に、従来技術のETSI ENIについて説明する。  
ETSI ENI ISGは、ETSI(European Telecommunications Standards Institute)配下の、AI技術をオペレーション分野への応用を検討するワーキンググループとして2017年2月に設立された。ETSI ENI ISGの狙いとしては、AI技術とコンテキストアウェア・ポリシーを活用することで、ユーザの個々なニーズ、サービス提供の条件とビジネス目標に応じて、提供する通信サービスを調整し、オペレータを支援することである。
【００１２】
ENI(Experiential Network Intelligence)が起案した、Network Intelligenceを用いてオペレータ体験を向上させるアーキテクチャは、ENI Engineが挙げられる（例えば非特許文献１を参照）。ENI Engineは、主に以下の5つの機能ブロックで構成されている。各機能ブロックは、非特許文献１の執筆時点でコンセプトレベルのものである。
【００１３】
（１）Intelligent Service Deployment
（２）Intelligent Policy Control
（３）Intelligent Resource Management
（４）Intelligent Monitoring
（５）Intelligent Analyzing and Prediction
これらのうち、本発明との関わりが最も強い機能ブロックである、（１）Intelligent Service Deploymentについて、ENIの取り組みについて説明する。
【００１４】
このアーキテクチャでは、顧客（ユーザ）のサービス要求(Customer Service Requester)が、システムに入力され、Service Intent APIを通じて、サービス・テンプレート機能（Service Template）、言語変換機能(Language Transformation)、サービス組合せ機能(Service Composition and Management)をそれぞれ呼び出す。  
これらの機能が生成した情報を用いて、Service Delivery APIを通じてNetwork Controllerに指示を出し、Network Controllerは、Resource Management APIを通してリソース（Network Element）を制御し、サービスが提供される。
【００１５】
しかし、このアーキテクチャでは、Customer Service Requesterの具体的な表現方法、解析方法、リソース組合せの決定方法、システム処理について、明確に説明されていない。
【００１６】
Open Day Light（例えば、Open Day Light NIC
<https://wiki.opendaylight.org/view/Network_Intent_Composition:Main>参照）や、ONOS(Open Network Operating System)（例えばONOS Intent Framework
<https://wiki.onosproject.org/display/ONOS/Intent+Framework>参照）等のSoftware Defined Network(SDN)検討団体では、仮想化ネットワーク管理の複雑性を隠蔽することを目指し、Intentを使ってネットワークを制御するIBNMを検討している。この団体が目指していることは、「Do it like this」の代わりに「What I want」をオペレータに求めることでネットワークを制御することである。
【００１７】
図３０は、IBNM(Intent-based Network Management)の一例を説明する図である。  
Open Day LightのNetwork Intent Composition (NIC) の例を用いてIBNMを説明する。ここでは、Branch 1とBranch 2の間にHeadquarterを設け、Branch 1からHeadquarterの間に帯域が10Gbpsであるリンクc1を決定し、フローf1をHeadquarterのFirewall(FW)に通過させ、リンクc1の帯域を昼間に10Gbps、夜間に1Gbpsにそれぞれ制御する例である。
【００１８】
従来では、経路内の各スイッチにおいてリンクリソースのIPなどのパラメータ及び転送ルールの決定などの複雑なリソース決定が必要である。IBNMでは、実現したい要件を記述するだけで上記の制御を実現でき、実現したい制御以外のリンクパラメータの決定の複雑性を隠蔽することができる。要件の記述としては、例えば「Connection c1 Endnodes (branch1, HQ) Properties 10G」（図３０の「（Ａ）c1:10G」に対応）、「Policy ID1 Apply to f1 action go through (firewall, WoC)」（図３０の「（Ｂ）f1:FWを追加」に対応）である。
【００１９】
一方で、既存のIBNMを仮想化ネットワークにおけるサービス管理に適用するには以下の２つの課題がある。  
１つ目の課題は、IBNMの管理対象はリンクリソース管理に限られており、機能リソースの管理に対応できないことである。  
２つ目の課題は、サービスレイヤの要望に応じて適切なリソースを組合せる機能と、サービスレイヤの要望に応じて機能リソースのパラメータを決定する機能が検討されていないことである。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】Raymond Forbes, "Experimental Networked Intelligence", <https://portal.etsi.org/Portals/0/TBpages/ENI/Docs/ISG_ENI_presenatation.pdf>
【非特許文献２】Customizing the tokenizer spaCy Usage Documentation, <https://spacy.io/docs/usage/customizing-tokenizer>
【非特許文献３】Part-of-speech tagging spaCy Usage Documentation, <https://spacy.io/docs/usage/pos-tagging>
【非特許文献４】Rule-based matching spaCy Usage Documentation, <https://spacy.io/docs/usage/rule-based-matching>
【発明の概要】
【発明が解決しようとする課題】
【００２１】
現況における、サービスレイヤの要望からリソースを決定する方式について説明する。
ここでは、第１の方式（Cloud Consultant）と第２の方式(Self-management)について説明する。
【００２２】
第１の方式(Cloud Consultant方式)では、通信事業者の営業担当がサービスレイヤの要望のヒアリングを通じて、サービス事業者の要望をサービスレイヤの要望として把握し、通信事業者のオペレータが、この要望に応じてリソースを決定する。この方式によりサービスレイヤの要望を表現できるが、通信事業者の営業担当とオペレータとの稼働が必要になり、実現のためのコストが高い。
【００２３】
また、第２の方式(Self-management)は、リソースの管理をサービス事業者に任せる方式である。この方式では、例えば、サービス事業者自らが、サービスレイヤの要望をリソースへの要求に変換し、必要となるリソースを、通信事業者が提供するリソース管理インタフェースDashboardを通じて表現する。しかし、この方式はサービス事業者に仮想化ネットワークの知識が要求され、また、サービス事業者がサービスレイヤの要望を直接に表現できない。
【００２４】
本発明の目的は、サービスレイヤの要望に適したリソースの組合せおよびリソースのパラメータを決定できるリソース決定装置、リソース決定方法およびリソース決定処理プログラムを提供することである。
【課題を解決するための手段】
【００２５】
上記目的を達成するために、この発明の一実施形態におけるリソース決定装置の第１の態様は、リソース決定装置が、通信サービスについて、自然言語で表現されたサービスレイヤの要望を解析する解析手段と、前記解析手段により解析されたサービスレイヤの要望に適したリソースの組合せを決定する組合せ決定手段と、前記組合せ決定手段により決定されたリソースの組合せに含まれるリソースのパラメータを決定するパラメータ決定手段とを備えるようにしたものである。
【００２６】
上記構成のリソース決定装置の第２の態様は、第１の態様において、前記解析手段が、前記サービスレイヤの要望で示される文を単語に分解し、前記分解された単語に対しその属性に応じたタグを付与し、前記タグが付与された単語の属性に基づいて、複数種類のサービスレイヤの要望を解析するようにしたものである。
【００２７】
上記構成のリソース決定装置の第３の態様は、第１の態様において、前記組合せ決定手段が、リソースの組合せの基本構成に対し、前記解析手段により解析されたサービスレイヤの要望に応じたカスタマイズ・ルールを適用して、前記基本構成をカスタマイズすることで、前記リソースの組合せを決定するようにしたものである。
【００２８】
上記構成のリソース決定装置の第４の態様は、第１の態様において、前記パラメータ決定手段が、前記組合せ決定手段により決定されたリソースの組み合わせに含まれるリソースのパラメータに影響を与える複数種類の要素の関係を学習してモデルを生成し、前記生成されたモデルを用いて、前記組合せ決定手段により決定されたリソースのパラメータを決定するようにしたものである。
【００２９】
本発明の一実施形態における、リソース決定装置が行うリソース決定方法の一つの態様はであって、通信サービスについて、自然言語で表現されたサービスレイヤの要望を解析し、前記解析されたサービスレイヤの要望に適したリソースの組合せを決定し、前記決定されたリソースの組合せに含まれるリソースのパラメータを決定するようにしたものである。
【００３０】
本発明の一実施形態におけるリソース決定処理プログラムの一つの態様は、第１乃至第４の態様のいずれか１つにおけるリソース決定装置の前記各手段としてプロセッサを機能させるものである。
【発明の効果】
【００３１】
この発明の一実施形態におけるリソース決定装置の第１の態様によれば、オペレータに依存せずに、リソースの組合せとリソースパラメータを決定できるので、人的コストを削減できる。
【００３２】
この発明の一実施形態におけるリソース決定装置の第２の態様によれば、自然言語で表現されたサービスレイヤの要望を適切に解析することができる。
【００３３】
この発明の一実施形態におけるリソース決定装置の第３の態様によれば、サービスレイヤの要望に相応しいリソースの構成を決定することができる。
【００３４】
この発明の一実施形態におけるリソース決定装置の第４の態様によれば、オペレータに依存せずに、複数種類の要素が影響を与えるリソースパラメータを決定することができる。
【００３５】
すなわち本発明によれば、サービスレイヤの要望に適したリソースの組合せおよびリソースのパラメータを決定することが可能になる。
【図面の簡単な説明】
【００３６】
【図１】本発明の一実施形態におけるリソース決定の組合せ及びリソースパラメータの決定の概要の一例を示す図。
【図２】本発明の一実施形態におけるリソース決定装置の、サービスレイヤの要望の解析にかかる適用例を示す図。
【図３】本発明の一実施形態におけるリソース決定装置に適用されるサービスレイヤの要望の表現ルールの一例を説明する図。
【図４】本発明の一実施形態におけるリソース決定装置に適用されるサービスレイヤの要望の表現ルールの一例を説明する図。
【図５】本発明の一実施形態におけるリソース決定装置による、表現ルールに従ったサービスレイヤの要望の表現の一例を示す図。
【図６】本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、サービスレイヤの要望の解析の概要の一例を示す図。
【図７】本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、サービスレイヤの要望の解析の手順の一例を示すフローチャート。
【図８】本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、Tokenize（トークナイズ）の一例について説明する図。
【図９】本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、POS(Part of Speech Tagging)の一例について説明する図。
【図１０】本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、Rule based Matchingの一例について説明する図。
【図１１】本発明の一実施形態におけるリソース決定装置の、リソース組合せの決定にかかる適用例を示す図。
【図１２】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部による、リソース組合せの決定の手順の一例を示すフローチャート。
【図１３】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部による、リソースの組合せの決定について説明する図。
【図１４】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いる、サービスの基本組合せリポジトリの一例について説明する図。
【図１５】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールの一例を示す図。
【図１６】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールのフォーマットの一例を示す図。
【図１７】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールのフォーマットの一例を示す図。
【図１８】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールのフォーマットの一例を示す図。
【図１９】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部によるカスタマイズ・エンジンにかかる処理手順の一例を示すフローチャート。
【図２０】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第１の例を説明する図。
【図２１】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第２の例を説明する図。
【図２２】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第３の例を説明する図。
【図２３】本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第４の例を説明する図。
【図２４】本発明の一実施形態におけるリソース決定装置の、リソースパラメータの決定にかかる適用例を示す図。
【図２５】本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理の概要の一例を示す図。
【図２６】本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における学習フェーズと運用フェーズについて説明する図。
【図２７】本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における学習フェーズの具体例について説明する図。
【図２８】本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における運用フェーズの具体例について説明する図。
【図２９】本発明の一実施形態におけるリソース決定装置を用いることにより生ずる効果の一例を説明する図。
【図３０】IBNM(Intent-based Network Management)の一例を説明する図。
【発明を実施するための形態】
【００３７】
以下、図面を参照しながら、この発明に係わる一実施形態を説明する。  
図１は、本発明の一実施形態におけるリソースの組合せ及びリソースパラメータの決定の概要の一例を示す図である。この実施形態では、サービス事業者がサービスレイヤの要望をService Requesterとして表現する。  
また、受領したService Requesterに応じて、本発明の一実施形態を実現するリソース決定装置が適切なリソースの組合せ及びリソースパラメータをResource Descriptorとして決定する。
【００３８】
次に、サービスレイヤの要望の表現と解析について説明する。図２は、本発明の一実施形態におけるリソース決定装置の、サービスレイヤの要望の解析にかかる適用例を示す図である。  
図２に示すように、リソース決定装置１０は、サービスレイヤ要望解析部１１、リソース組合せ決定部１２、リソースパラメータ決定部１３を有する。このリソース決定装置１０のサービスレイヤ要望解析部１１、リソース組合せ決定部１２、リソースパラメータ決定部１３は、パーソナルコンピュータ（ＰＣ）などのコンピュータデバイスとした装置により実現することができる。例えば、コンピュータデバイスは、ＣＰＵ（Central Processing Unit）などのプロセッサと、プロセッサに接続される揮発性メモリと、不揮発性メモリと、通信インタフェースと、を備える。
【００３９】
サービスレイヤ要望解析部１１は、Service Requesterを入力し、このService Requesterの解析結果をリソース組合せ決定部１２、リソースパラメータ決定部１３に出力する。
リソース組合せ決定部１２は、解析結果に応じてリソースの組合せを決定して、これを出力する。  
リソースパラメータ決定部１３は、解析結果に応じてリソースのパラメータを決定して、これを出力する。  
リソース組合せ決定部１２による出力と、リソースパラメータ決定部１３による出力はResource Descriptorとして、仮想化リソース管理システムにそれぞれ出力される。
【００４０】
次に、図２に示したＷ１の枠内の「Input: Service Requester」とサービスレイヤ要望解析部１１とにかかる、サービスレイヤの要望の解析について説明する。  
通信事業者の営業担当の人的コストを抑えながら、リソースへの要求の変換稼働を要せずに、サービス事業者がサービスレイヤの要望を表現するために、本実施形態では、Controlled Natural Language(CNL：制限された自然言語)でサービスレイヤの要望を表現する方式について説明する。
【００４１】
CNLは、事前に規定した表現ルールに従って作成した自然言語である。このCNLは、完全の自然言語と比較して、曖昧性が抑えられ、精確に要件を表現でき、また、要件の解析が容易で、システムに読み込みやすいという利点がある。故に、通信事業者の営業担当の稼働の削減とサービスレイヤの要望の精確的な表現とを両立できる。
【００４２】
ここで、サービスレイヤの要望を表現するために、以下に示すCNL形式にて、サービスレイヤの要望の表現ルールを規定する。  
図３および図４は、本発明の一実施形態におけるリソース決定装置に適用されるサービスレイヤの要望の表現ルールの一例を示す図である。  
図３に示すようにサービスレイヤの要望の表現ルールは
「<ACTION><SERVICE><CONJ><DESCRIPTOR>」で表す。
【００４３】
<ACTION>は、サービスに対する操作を表す。  
<SERVICE>は、開通しようとしているサービスのタイプ、または既存サービスを表す識別子を表す。  
<CONJ>は、<SERVICE>と<DESCRIPTOR>を接続する。
【００４４】
図３に示すように<ACTION>、<SERVICE>、<CONJ>に使える単語としては複数種類の単語がある。  
<DESCRIPTOR>は、<SERVICE>が必要とするサービスの属性（要件）を表す。図４に示した例では、サービスの属性の種類は、WORKLOAD, LINK PROPERTY, REDUNDANCY, SECURITY, REGIONの５種類であり、それぞれの種類について表現ルールの文法が対応付けられる。図４では、表現ルールに含まれたタグに使える単語が示される。
【００４５】
図５は、本発明の一実施形態におけるリソース決定装置による、表現ルールに従ったサービスレイヤの要望の表現の一例を示す図である。  
サービスレイヤの要望の表現ルールに従って、サービスレイヤの要望は、図５に示した例Ａ、例Ｂ、例Ｃなどで表現できる。
【００４６】
次に、上記の例Ａのように表現されたサービスレイヤの要望の解析の例について説明する。図６は、本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、サービスレイヤの要望の解析の概要の一例を示す図である。  
例Ａで示したサービスレイヤの要望について解析された要件を.json(JavaScript（登録商標） Object Notation) fileで表現すると、図６に示すように"SECURITY"は"high security"であって、"WORKLOAD"が"1000 request/second"であって、"SERVICE TYPE"が"web service"であることが解析結果となる。
【００４７】
次に、サービスレイヤの要望の解析の各手順について説明する。この手順とは、Tokenize、Part of Speech Tagging (POS)、およびRule based Matchingである。  
図７は、本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、サービスレイヤの要望の解析の手順の一例を示す図である。図８は、本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、Tokenizeの一例について説明する図である。  
まず、サービスレイヤ要望解析部１１は、サービスレイヤの要望に対するTokenizeを行なう（Ｓ１１）Tokenizeは、文を単語に分解する、既存の機能である。  
ここでは、非特許文献２に開示されたtokenizeを用いる。
【００４８】
上記の例Ａに示したサービスレイヤの要望に対するTokenizeを行なうと、Tokenizeの結果として、
{Start, web, service, that, handles, 1000, request/second, with, high, security}が得られる。
【００４９】
図９は、本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、POSの一例について説明する図である。  
サービスレイヤ要望解析部１１は、Tokenizeの結果に対するPOSを行なう（Ｓ１２）。
【００５０】
POSは、単語の内容によって、単語にタグを付与する既存技術である。ここでは、非特許文献３に開示されたPOS taggingを用いる。
【００５１】
図８に示したTokenizeの結果に対するPOS taggingを行なうと、POS taggingの結果として
{Start: VERB, web: NOUN, service: NOUN, that: CONJ, handles: VERB,
1000:NUM, request/second: NOUN, with: CONJ, high: ADJ, security: NOUN}が得られる。  
ここで付与されたタグは、VERB（動詞）、NOUN（名詞）、CONJ（接続詞）、NUM（数字）、ADJ（形容詞）、ADV（副詞）である。
【００５２】
図１０は、本発明の一実施形態におけるリソース決定装置のサービスレイヤ要望解析部による、Rule based Matchingについて説明する図である。  
サービスレイヤ要望解析部１１は、POSの結果に対するRule based Matchingを行なう（Ｓ１３）。
【００５３】
rule-based matchingは、事前に定義した解析ルールに従って、一つまたは複数の単語の属性を識別し、分類する既存技術である。ここでは、非特許文献４に開示されたrule-based matchingを用いた。rule-based matching の結果として、各種類のサービス属性に対する要求が分類され、出力される。ここでは、各種類のサービス属性に対する要求をatom_requirementsと呼ぶ。atom_requirementsは次のリソース組み合わせ決定機能の入力、及びリソースパラメータ決定機能の入力である。
【００５４】
図９に示したPOS taggingの結果に対するRule based Matchingを行なうと、Rule based Matchingの結果として、
{"SECURITY": "high security", "WORKLOAD": "1000 request/second", "SERVICE TYPE": "web service"}が得られる。この結果が、サービスレイヤの要望の最終的な解析結果となる。
【００５５】
ここで、Rule based Matchingで用いる解析ルールについて説明する。  
この解析ルールは、図４に示したような基本表現ルールに対応して設計される。図４に示したような基本表現ルールに対応して設計された解析ルールは、WORKLOADの解析ルール、LINK PROPERTYの解析ルール、SECURITYの解析ルールを含む。以下に各種の解析ルールのロジックの例を示す。
【００５６】
・WORKLOADの解析ルール： 
If input = <NUM> + users per second/transactions per second/request per second:
mark as WORKLOAD requirement;
・LINK PROPERTYの解析ルール: 
If input = <ADJ or NUM> + GB/bandwidth/packet loss rate/priority:
mark as LINK PROPERTY requirement;
・SECURITYの解析ルール： 
If input = <ADJ>/<ADV> + security/protection:
mark as SECURITY requirement;
【００５７】
次に、リソース組合せの決定について説明する。図１１は、本発明の一実施形態におけるリソース決定装置の、リソース組合せの決定にかかる適用例を示す図である。次に、図１１に示したＷ２の枠内の「Output:リソースの組合せ」とリソース組合せ決定部１２とにかかる、リソースの組合せの決定について説明する。  
Ｓ１１の後、リソース組合せ決定部１２は、サービスレイヤ要望解析部１１により解析されたサービスレイヤの要望に応じて、リソースの組合せを決定する（Ｓ１２）。
【００５８】
現状、サービスレイヤの要望に応じて、リソースの組合せを決定することは、一般的にオペレータのスキルに依存する。また、サービス毎にリソースの組合せテンプレートが作られ、このテンプレートを参照して組合せが確定される。しかし、サービスのバリエーションの増加に伴い、数多くのテンプレートを作る必要があり、データ量が膨大になり、労力が掛かり、サービス提供時間が長くなってしまう。
【００５９】
本実施形態では、解析されたサービスレイヤの要望に応じて、基本サービス組合せおよびカスタマイズ・ルールを用いて、サービスレイヤの要望毎に、適したリソースの組合せを決定することについて説明する。
【００６０】
図１２は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部による、リソース組合せの決定の手順の一例を示すフローチャートである。  
リソース組合せ決定部１２は、サービス構成（リソースの構成）を決定する際に、まず、サービス種類に応じて、リソースの基本構成(基本組み合わせ)を基本構成リポジトリから読み出す（Ｓ２１）。基本構成リポジトリを含むリポジトリは、基本構成の情報をリソース決定装置１０の不揮発性メモリに記憶することにより実現される。次に、リソース組合せ決定部１２は、この基本構成に基づいて、サービスレイヤの要望（特に、冗長化要件、セキュリティ要件、地域要件（CDNの場合））を読み出し（Ｓ２２）、このサービスレイヤの要望に基づいて、基本サービス組合せに対する機能追加および変更を行なうことで、リソース構成をカスタマイズする（Ｓ２３）。
【００６１】
リソースの組合せの決定を自動化することより、従来のようにオペレータが労力をかける必要がなくなるので、人的コストの削減、およびサービス提供時間の短縮の効果が期待できる。
【００６２】
また、サービス毎にリソースの組合せテンプレートを作成する代わりに、少数のリソースの組合せテンプレートを用意し、カスタマイズ・エンジンを通じて、様々なサービスのリソースの組合せが生成できる。
【００６３】
リソース組合せ決定部１２は、基本サービス組合せをベースにし、Ｓ１１で解析されたサービスレイヤの要望に応じてカスタマイズ・ルールを適用し、基本サービス組合せに機能を追加・機能を変更することで、要望ごとに、適したリソースの組合せ（.yamlファイル）を自動的に生成する。
【００６４】
図１３は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部による、リソースの組合せの決定の一例について説明する図である。  
図１３に示した例では、機能リソースの種類は、FW(Firewall)、WS(Web Server)、AS(Application Server)、CS(Content Server)、LB(Load Balancer)であり、Web Service系の基本構成と、CDN(Content Delivery Network)系の基本構成に区分される。
【００６５】
図１３に示した例では、基本サービス組合せにおけるWeb Service系の基本構成はFW(Firewall),WS(Web Server),AS(Application Server)とこれらの機能リソースを連結させるリンクリソースLinkを含む構成である。また、基本サービス組合せにおけるCDN系の基本構成はCS(Content Server),LB(Load Balancer)とこれらの機能リソースを連結させるリンクリソースLinkを含む構成である。
【００６６】
図１４は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いる、サービスの基本組合せリポジトリの一例について説明する図である。  
基本サービス組合せはリポジトリに保存されている。
【００６７】
図１４（ａ）に示したように、Web Service系の基本構成が機能リソースFW,WS,ASと、とこれらの機能リソースを連結させるリンクリソースLinkを含む構成、であってCDN系の基本構成がLB,CSである基本サービス組合せは、図１４（ｂ）に示したフォーマットのように定義することができる。このフォーマットにおけるimage_URLは、該当リソースのイメージのダウンロード先のアドレスを示す。  
また、図１４（ｂ）に示したTierは、通信フローの流れにおけるリソースの前後順位を示す。
【００６８】
リソース組合せ決定部１２は、サービスの基本組合せをベースにし、サービスレイヤの要望に応じてカスタマイズ・ルールを適用する。  
図１５は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールの一例を示す図である。図１５に示すように、カスタマイズ・ルールの形式はECA(Event Condition Action)である。
【００６９】
図１５に示したカスタマイズ・ルールにおけるConditionは、カスタマイズ・ルールの対象サービスタイプを示す。図１５に示したカスタマイズ・ルールにおけるEventは、図１５に示したカスタマイズ・ルールが対応するサービスレイヤの要望を表す。このEventの種類は、サービスレイヤの要望の分類に対応する。図１５に示したカスタマイズ・ルールにおけるActionは、サービス組合せに対する操作、例えば、リソースの追加、変更、削除を表す。
【００７０】
図１６、図１７、図１８は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部が用いるカスタマイズ・ルールのフォーマットの一例を示す図である。  
図１５に示した「No.1」の列のカスタマイズ・ルールは、図１６に示すように定義できる。このカスタマイズ・ルールでは、Eventが「high security（高い安全性）」で、Conditionが「any service」で、Actionが「基本構成にセキュリティDPI機能の追加」であることが定義される。
【００７１】
図１５に示した「No.2」の列のカスタマイズ・ルールは、図１７に示すように定義できる。このカスタマイズ・ルールでは、Eventが「full redundancy（完全冗長化）」で、Conditionが「any service」で、Actionが「基本構成に同じ構成の追加かつ物理分離」であることが定義される。
【００７２】
図１５に示した「No.3」の列のカスタマイズ・ルールは、図１７に示すように定義できる。このカスタマイズ・ルールでは、Eventが「number of regions = n（提供地域数＝ｎ）」で、Conditionが「any service」で、Actionが「コンテント・サーバ(CS)ｎ個に追加」であることが定義される。
【００７３】
図１９は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部によるカスタマイズ・エンジンにかかる処理手順の一例を示すフローチャートである。  
まず、カスタマイズ・エンジンは、入力された要件(atom_requirements)の中にSERVICE TYPEが含まれているかを検査する。（Ｓ３１）。この入力された要件(atom_requirements)は、サービスレイヤの要望の解析結果である。入力された要件(atom_requirements)にSERVICE TYPEが含まれていれば、対応した基本サービス組合せ（リソース組合せ）(resource composition)をリポジトリ(repository)から抽出(fetch)し（Ｓ３２）、SERVICE TYPEが含まれていなければ、エラーを返す
Ｓ３２の後、カスタマイズ・エンジンは、入力された要件に含まれたSERVICE TYPE以外の要件に応じて（Ｓ３３、Ｓ３４）、この要件に対応したカスタマイズ・ルールがあれば、これを抽出する（Ｓ３５）。
【００７４】
続いて、カスタマイズ・エンジンは、抽出したカスタマイズ・ルールの優先度(priority)と矛盾(conflict)をそれぞれ分析し（Ｓ３６）、矛盾があればエラーを返す。矛盾がなければ、カスタマイズ・エンジンは、優先順位でカスタマイズ・ルールを実行し（Ｓ３７、３８）、このカスタマイズ・ルールに従って、基本リソース組合せにリソースを追加、変更、削除する。  
最後に、カスタマイズ・エンジンは、決定したリソース組合せをベースにして.yamlファイルを生成する（Ｓ３９）。
【００７５】
図２０は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第１の例を説明する図である。  
図２０に示した例では、まず、リソース組合せ決定部１２は、サービス種類に相応しいサービス基本構成をリポジトリから取り出す。この取り出したサービス種類はweb service系であり、このweb service系の基本構成は、機能リソースFW，WS，DBと、機能リソースを連結させるリンクリソースLinkを含む。基本リソース構成は以下のようになる。
【００７６】
基本リソース構成：[FW][Link][WS][Link][DB]
次に、リソース組合せ決定部１２は、サービスレイヤの要望に基づいて、カスタマイズ・ルールに従って、サービスレイヤの要望に応じて、基本リソース構成をカスタマイズする。ここでは、カスタマイズ・ルールにおけるセキュリティ要件(SECURITY)がhigh securityであることから、Deep Packet Inspection (DPI)というセキュリティ機能を基本リソース構成に追加することで、リソースの組合せを決定する。この結果、リソース構成は以下のように変更される。
【００７７】
カスタマイズした後のリソース構成：[DPI][Link][FW][Link][WS][Link][DB]
これにより、サービスレイヤの要望に相応しいリソース構成が決定される。
【００７８】
図２１は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第２の例を説明する図である。  
図２１に示した例では、まず、リソース組合せ決定部１２は、サービス種類に相応しいサービス基本構成をリポジトリから取り出す。この取り出したサービス種類はweb service系であり、このweb service系の基本構成は、機能リソースFW，WS，DBと、機能リソースを連結させるリンクリソースLinkを含む。基本リソース構成は以下のようになる。
【００７９】
基本リソース構成：[FW][Link][WS][Link][DB]
次に、リソース組合せ決定部１２は、サービスレイヤの要望に基づいて、カスタマイズ・ルールに従って、サービスレイヤの要望に応じて、基本リソース構成をカスタマイズする。ここでは、カスタマイズ・ルールにおける冗長化要件(REDUNDANCY)がfull redundancyであることから、上記の基本リソース構成と完全に同じ構成を追加し、この追加した構成と上記の基本リソース構成とを物理的に分離することで、リソースの組合せを決定する。この結果、リソース構成は以下のように変更される。
【００８０】
カスタマイズした後のリソース構成：
[FW][Link][WS][Link][DB]
[FW][Link][WS][Link][DB]
これにより、サービスレイヤの要望に相応しいリソース構成が決定される。
【００８１】
図２２は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第３の例を説明する図である。  
図２２に示した例では、まず、リソース組合せ決定部１２は、サービス種類に相応しいサービス基本構成をリポジトリから取り出す。この取り出した構成におけるサービス種類はCDN Service系であり、このCDN Service系の基本構成は、機能リソースLB, CSと、機能リソースを連結させるリンクリソースLinkを含む。基本リソース構成は以下のようになる。
【００８２】
基本リソース構成：[LB][Link][CS]
次に、リソース組合せ決定部１２は、サービスレイヤの要望に基づいて、カスタマイズ・ルールに従って、サービスレイヤの要望に応じて、基本リソース構成をカスタマイズする。ここでは、カスタマイズ・ルールにおける地域（REGION)要件が「A city, B city, C city」であることから、カスタマイズ・ルールに従って、リソース組合せ決定部１２は、基本リソース構成におけるCSの数を３つにする。この結果、リソース構成は、[LB]に対し、３つの[Link][CS]が並列に連なる構成に変更される。  
これにより、サービスレイヤの要望に相応しいサービス構成が決定される。
【００８３】
図２３は、本発明の一実施形態におけるリソース決定装置のリソース組合せ決定部により決定するリソース組合せの第３の例を説明する図である。  
図２３に示した例では、まず、リソース組合せ決定部１２は、サービス種類に相応しいサービス基本構成をリポジトリから取り出す。この取り出した構成におけるサービス種類はweb service系であり、このweb service系の基本構成は機能リソースFW、WS、DBと、機能リソースを連結させるリンクリソースLinkとを含む。基本リソース構成は以下のようになる。
【００８４】
基本リソース構成：[FW][Link][WS][Link][DB]
次に、リソース組合せ決定部１２は、サービスレイヤの要望に基づいて、カスタマイズ・ルールをリポジトリから取り出す。ここでは、取り出したカスタマイズ・ルールは要件に対応した２つのカスタマイズ・ルール（SECURITY: high securityとREDUNDANCY: full redundancy）である。これらのカスタマイズ・ルールを実行する順序によって、カスタマイズ後に決定されるリソース構成が変わる。
【００８５】
リソース組合せ決定部１２は、取り出されたカスタマイズ・ルールの優先順位を比較する。図１５に示した例では、SECURITY要件にかかるカスタマイズ・ルールの優先度は、REDUNDANCY要件にかかるカスタマイズ・優先度より高い。リソース組合せ決定部１２は、この優先度に従い、SECURITY要件にかかるカスタマイズ・ルールにしたがうカスタマイズを第１のカスタマイズとして先に実行し、つまり、基本リソース構成にセキュリティ機能DPIを追加する。  
このカスタマイズを実行した後のリソース構成は以下のようになる。
【００８６】
[DPI][Link][FW][Link][WS][Link][DB]
続いて、リソース組合せ決定部１２は、REDUNDANCY要件にかかるカスタマイズ・ルールにしたがうカスタマイズを第２のカスタマイズを実行し、つまり上記第１のカスタマイズを実行した後の構成に、当該構成と同じ構成を追加する。
【００８７】
第２のカスタマイズを実行した後のリソース構成は以下のようになる。  
[DPI][Link][FW][Link][WS][Link][DB]
[DPI][Link][FW][Link][WS][Link][DB]
【００８８】
次に、リソースパラメータの決定について説明する。図２４は、本発明の一実施形態におけるリソース決定装置の、リソースパラメータの決定にかかる適用例を示す図である。ここで、図２４に示したＷ３の枠内の「Output:リソースのパラメータ」とリソースパラメータ決定部１３とにかかる、リソースパラメータの決定について説明する。
【００８９】
一般的に、サービスレイヤの要望に応じての各リソースへの計算リソースの配分、即ちリソースのパラメータの決定はオペレータに依存する。しかし、リソースパラメータを決定するためは、サービスレイヤの要望を含む多くの要素を考慮する必要がある。例えば、処理の種類、リソース実装方式、クラウド提供者が定めたリソース利用率目標、求めているワークロード等の要素をすべて考慮してリソースパラメータを決定する必要がある。
【００９０】
故に、リソースパラメータを決定するには、オペレータに高いスキルが要求されることから人的コストが発生し、また、オペレータのスキルのレベルによって、リソース配分の非効率化が発生してしまう。
【００９１】
図２５は、本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理の概要の一例を示す図である。  
本実施形態では、図２５に示すように、リソースパラメータ決定部１３は、リソース組合せ決定部１２によりで決定した、各リソース（例えば、DPI、FW、WS、DB)のパラメータである、CPU数、メモリーサイズ、ディスクサイズを決定する。
【００９２】
これらのパラメータの決定は、サービスのワークロード要件（例えば、1000 request/second，1 million user）と直接関わる。また、処理の種類（例えばFW , AS, WS, CS, Encoder, DPI）、通信事業者の利用率目標（例えば、仮想リソース利用率<80%）、ホスト・サーバの状態（例えば、ホスト・サーバのCPU利用率）、ハードウェアの設定（例えば、仮想CPUと物理CPUを紐付け）は、リソースのパラメータの決定に影響を与える。
【００９３】
リソースパラメータ決定部１３は、サービスのワークロード要件とリソースのパラメータ及びその他の影響を与える各要素の関係を学習(Linear Regression, DDN Regression)によりモデル化し、このモデルを用いてリソースのパラメータを決定する。
【００９４】
次に、リソースパラメータ決定部１３による処理における、学習フェーズと運用フェーズについて説明する。図２６は、本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における学習フェーズと運用フェーズについて説明する図である。  
学習フェーズは、オペレータにより過去に決定したパラメータ及びこの決定によって生成した、既知の設計・運用データ(仮想化リソースのインスタンスのリソース利用率)に対する機械学習を行なって、リソースパラメータ決定のモデルを生成するフェーズである。
【００９５】
運用フェーズは、学習フェーズで生成したモデルにリソースの要件、リソースの処理種別、リソースの目標利用率などを入力して、リソースのパラメータを決定するフェーズである。
【００９６】
次に、学習フェーズの具体例について説明する。図２７は、本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における学習フェーズの具体例について説明する図である。  
学習フェーズでは、リソースパラメータ決定部１３は、機械学習の線形回帰分析(Linear Regression)と、DDN回帰分析(Deep Neural Network Regression)モデル（例えば、Tensorflow Estimators.（https://www.tensorflow.org/extend/estimators）参照）とを用いて、オペレータにより過去に決定されたリソースパラメータと上記の影響要素（処理の種類、ホストサーバの利用率等）及び運用データを学習する。学習させる訓練データの例は以下となる。
【００９７】
・リソースの処理種類(VNF type)
・ワークロード要件(workload requirements)
・オペレータが決定したリソースパラメータ(parameters decided by operators)
・ホスト・サーバの利用率(host utilization ratios)
・ハードウェアの情報(hardware conditions)
・上記の環境でリソースを実行した際の、各リソースインスタンスの利用率(VNF utilization ratios)
次に、運用フェーズの具体例について説明する。図２８は、本発明の一実施形態におけるリソース決定装置のリソースパラメータ決定部による処理における運用フェーズの具体例について説明する図である。  
運用フェーズでは、リソースパラメータ決定部１３は、学習フェーズで生成したモデルを用いて、求められるワークロード要件、クラウド提供者自身が定めた各インスタンスの目標リソース利用率等に応じて、パラメータを決定する。モデルへ入力するデータの例は以下となる。
【００９８】
リソースの処理種類(VNF type)
求められたワークロード要件(workload requirements)
ホスト・サーバの利用率(host utilization ratios)
ハードウェアの情報(hardware conditions)
インスタンスのリソース利用率の目標(objective VNF use ratios)
モデルから出力されるデータの例は以下となる。
【００９９】
リソースのパラメータ（CPU数、メモリーサイズ、ディスクサイズ）(calculated parameters)
最後に、リソースパラメータ決定部１３は、決定したパラメータをベースにし、リソース組合せ決定部１２により生成された.yamlファイルにflavor属性（例えば、Openstack flavor
（https://docs.openstack.org/horizon/latest/admin/manage-flavors.html）参照）を追加する。flavor属性は、リソースのCPU数、メモリーサイズ、ディスクサイズを表す属性である。
【０１００】
次に、本発明の一実施形態によって生じる効果について説明する。図２９は、本発明の一実施形態におけるリソース決定装置を用いることにより生ずる効果の一例を説明する図である。
【０１０１】
図２９に示した例では、リソースの組合せの決定およびリソースパラメータの決定がオペレータに依存し、本発明の一実施形態におけるリソース決定装置を用いない場合、クラウドの販売数に対するCloud Specialistの必要人数は、現在のCloud Specialist人数より多く、人材不足が生ずる。  
また、クラウドを行なう中小企業と大企業における、収入に対する設計コストが多い。また、クラウドの販売数が一定以上となると、このクラウドの販売数に対する平均サービス提供時間が、大幅に増加する。
【０１０２】
これに対し、リソースの組合せの決定およびリソースパラメータの決定がオペレータに依存せず、本発明の一実施形態におけるリソース決定装置を用いた場合、クラウドの販売数に対するCloud Specialistの必要人数は、現在のCloud Specialist人数より少なくなり、上記の人材不足は生じない。すなわち、仮想化ネットワークを設計する人的リソースの必要人数を減少し、人材育成コストを削減できる。
【０１０３】
また、クラウドを行なう中小企業と大企業における、収入に対する設計コストは、上記のオペレータに依存する場合と比較して低減される。  
すなわち、本発明の一実施形態におけるリソース決定装置がサービス設計を支援することより、人件と時間のコストを削減し、収益の確保と利益の増加を実現できる。  
また、クラウドの販売数が一定以上となっても、このクラウドの販売数に対する平均サービス提供時間は、上記のオペレータに依存する場合と比較して短い。  
すなわち、本発明の一実施形態におけるリソース決定装置によりサービス設計を自動化できるので、サービス提供時間を短縮し、販売の拡大に寄与することができる。
【０１０４】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組合せて実施してもよく、その場合組合せた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０１０５】
また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。
【符号の説明】
【０１０６】
１０…リソース決定装置、１１…サービスレイヤ要望解析部、１２…リソース組合せ決定部、１３…リソースパラメータ決定部。
【図１】
2019087105.tif 000003
【図２】
2019087105.tif 000004
【図３】
2019087105.tif 000005
【図４】
2019087105.tif 000006
【図５】
2019087105.tif 000007
【図６】
2019087105.tif 000008
【図７】
2019087105.tif 000009
【図８】
2019087105.tif 000010
【図９】
2019087105.tif 000011
【図１０】
2019087105.tif 000012
【図１１】
2019087105.tif 000013
【図１２】
2019087105.tif 000014
【図１３】
2019087105.tif 000015
【図１４】
2019087105.tif 000016
【図１５】
2019087105.tif 000017
【図１６】
2019087105.tif 000018
【図１７】
2019087105.tif 000019
【図１８】
2019087105.tif 000020
【図１９】
2019087105.tif 000021
【図２０】
2019087105.tif 000022
【図２１】
2019087105.tif 000023
【図２２】
2019087105.tif 000024
【図２３】
2019087105.tif 000025
【図２４】
2019087105.tif 000026
【図２５】
2019087105.tif 000027
【図２６】
2019087105.tif 000028
【図２７】
2019087105.tif 000029
【図２８】
2019087105.tif 000030
【図２９】
2019087105.tif 000031
【図３０】
2019087105.tif 000032