JP6714541B2 - 管理装置、および、ネットワークサービス管理方法 - Google Patents

Description

本発明は、管理装置、および、ネットワークサービス管理方法に関する。

特許文献１には、「複数の計算機ノード、一つもしくは複数の通信機器、及び前記計算機ノードと前記通信機器間を接続する複数のリンクを含む物理インフラと、前記物理インフラの前記計算機ノード毎の計算機資源量と前記リンク毎のネットワーク資源量を把握しており、要求されたネットワーク機能仮想化サービスに必要な仮想マシーン及び仮想接続を算出し、前記計算機資源量と前記ネットワーク資源量に基づいて前記仮想マシーンと前記計算機ノードとの収容関係を探し、前記仮想マシーン及び前記仮想接続を前記物理インフラ上に構築する管理計算機と、を備えるネットワーク機能仮想化基盤管理システム」について開示されている。

特開２０１５−１６２１４７号公報（請求項１）

特許文献１によれば、サーバ系装置やＮＷ系装置のリソースを確保する技術について開示されているに留まり、構築したネットワークサービスを変更する技術について言及されていない。従来では、構築したネットワークサービスを変更する場合には、新規のネットワークサービスを構築し、サービス移行を実施することになると想定される。しかし、このようなサービス移行は、ユーザに対するサービス継続の中断等の影響が懸念され、ネットワークサービスの信頼性を損ねる可能性がある。

そこで、本発明は、上記事情に鑑みて、ネットワークサービスの変更時におけるネットワークサービスの信頼性を向上させることを課題とする。

前記課題を解決するために、請求項１に記載の発明は、仮想化領域となるコアＮＷ（Network）および非仮想化領域となるアクセスＮＷを含むＮＷに構築されるＮＳ（Network Service）を管理する管理装置であって、前記ＮＳの構成情報であるサービス構成情報を管理するサービス構成情報管理部と、前記ＮＳのサービス構成情報の履歴を管理するサービス構成履歴管理部と、前記サービス構成情報に基づいて生成されたインスタンスを管理するインスタンス管理部と、前記構築されたＮＳの変更を要求するＮＳ変更要求を外部から取得すると、前記ＮＳ変更要求に含まれるインプットパラメータに基づいて前記サービス構成情報を変更するとともに、前記変更する前のサービス構成情報に基づいて生成されたインスタンスを前記インスタンス管理部に保護させるワークフロー部と、を備える、ことを特徴とする。

また、請求項８に記載の発明は、仮想化領域となるコアＮＷ（Network）および非仮想化領域となるアクセスＮＷを含むＮＷに構築されるＮＳ（Network Service）を管理する管理装置におけるネットワークサービス管理方法であって、前記管理装置は、前記構築されたＮＳの変更を要求するＮＳ変更要求を外部から取得するステップと、前記ＮＳ変更要求に含まれるインプットパラメータに基づいて、前記ＮＳの構成情報であるサービス構成情報を変更するステップと、前記変更する前のサービス構成情報に基づいて生成されたインスタンスを保護するステップと、を実行する、ことを特徴とする。

請求項１，８に記載の発明によれば、変更前のサービス構成情報に基づいてインスタンス化されたインスタンスは保護されるため、当該インスタンスを用いたサービスの疎通は確保され、ユーザは、当該サービスを継続して利用することができる。
したがって、ネットワークサービスの変更時におけるネットワークサービスの信頼性を向上させることができる。

また、請求項２に記載の発明は、請求項１に記載の管理装置であって、前記ワークフロー部は、前記サービス構成情報の変更の度に、前記変更されたサービス構成情報に版数を付与することで、前記サービス構成情報の世代管理を行う、ことを特徴とする。

請求項２に記載の発明によれば、所望の版数が付与されたサービス構成情報に基づいてインスタンス化されたインスタンスを用いたサービスをユーザに提供することができる。

また、請求項３に記載の発明は、請求項２に記載の管理装置であって、前記ワークフロー部は、前記サービス構成情報管理部および前記サービス構成履歴管理部に、特定の前記版数が付与されたサービス構成情報を読み出させ、当該読み出したサービス構成情報に基づいて要求を処理する、ことを特徴とする。

請求項３に記載の発明によれば、特定の版数が付与されたサービス構成情報に対応する要求であっても確実に処理することができる。

また、請求項４に記載の発明は、請求項１から請求項３のいずれか１項に記載の管理装置であって、前記ワークフロー部は、前記変更する前のサービス構成情報に基づいて生成されたインスタンスを利用するユーザが存在する場合、前記変更する前のサービス構成情報の廃止を防止する、ことを特徴とする。

請求項４に記載の発明によれば、変更前のサービス構成情報に基づくインスタンス化によって作成されたインスタンスを利用するユーザによるサービス中断を未然に防ぐことができる。

また、請求項５に記載の発明は、請求項１から請求項３のいずれか１項に記載の管理装置であって、前記ワークフロー部は、前記変更する前のサービス構成情報に基づいて生成されたインスタンスを利用するユーザが存在する場合、予め許可が設定された業務について処理を実行可能とする業務制限を実行する、ことを特徴とする。

請求項５に記載の発明によれば、変更前のサービス構成情報に基づくサービスのゆるやかな巻き取り（旧版サービスの利用量の減少）を促進させることができる。

また、請求項６に記載の発明は、請求項５に記載の管理装置であって、前記ワークフロー部は、前記業務制限を変更するための制限レベルを設定する、ことを特徴とする。

請求項６に記載の発明によれば、変更前のサービス構成情報に基づくサービスのゆるやかな巻き取りをさらに促進させることができる。

また、請求項７に記載の発明は、請求項５または請求項６に記載の管理装置であって、前記ワークフロー部は、前記業務制限を実行したことを所定の関係者に通知する、ことを特徴とする。

請求項７に記載の発明によれば、変更後のサービス構成情報に基づくサービスを関係者に確実に知らせることができ、変更前のサービス構成情報に基づくサービスのゆるやかな巻き取りをさらに促進させることができる。

本発明によれば、ネットワークサービスの変更時におけるネットワークサービスの信頼性を向上させることができる。

本実施形態の管理装置の機能構成図である。 所定のＮＷ構成に対するＮＳの構築の説明図である。 参考システムにおける、リソース照会後のインスタンス化の失敗を示す比較例である。 ＮＳ生成処理を示すフローチャートである。 サービス構成情報の具体例を示すＵＭＬ（Unified Modeling Language）図である。 Product Orderのライフサイクルの状態遷移図である。 Product Inventoryのライフサイクルの状態遷移図である。 ＮＳ変更処理を示すフローチャートである。

本発明を実施するための形態（実施形態）について、図面を参照しながら詳細に説明する。

本実施形態の管理装置Ｍは、仮想化領域となるコアＮＷおよび非仮想化領域となるアクセスＮＷを管理する。具体的には、管理装置Ｍは、コアＮＷに配置されている機器およびアクセスＮＷに配置されている機器から情報を収集することでこれらの機器を監視する。コアＮＷに配置されている機器およびアクセスＮＷに配置されている機器によってＮＷ構成ができあがる。

また、管理装置Ｍは、コアＮＷおよびアクセスＮＷを含むＮＷに構築されるＮＳ（Network Service）を管理する。このＮＳは、ＮＳ利用側（ユーザ）の端末からＮＳ提供側（例：通信事業者）が保持するアクセスＮＷ、コアＮＷ上の機器からサービス事業者（例：ＩＳＰ（Internet Service Provider）事業者）との端点までのＥ２Ｅ（End to End：エントツーエンド）の管理が実現可能なＮＳとなる。

図１に示すように、管理装置Ｍは、Ｅ２ＥＯ（End to End Orchestrator：エンドツーエンドオーケストレータ、Ｅ２Ｅオーケストレータ）１と、サーバ系装置管理部２と、ＮＷ系装置管理部３（ネットワーク装置管理部）と、を備える。

Ｅ２ＥＯ１は、ユーザに提供されるＮＳの管理を自律的に行う機能部である。
サーバ系装置管理部２は、コアＮＷおよびアクセスＮＷを含むＮＷに配置されるサーバ系装置を管理する。
ＮＷ系装置管理部３は、コアＮＷおよびアクセスＮＷを含むＮＷに配置されるＮＷ系装置を管理する。
オペレータが操作する上位装置Ｕ、または、上位装置Ｕと同等の機能を有する他システムＵ１からの要求に応じて、Ｅ２ＥＯ１、サーバ系装置管理部２、および、ＮＷ系装置管理部３は動作する。なお、他システムＵ１はＯＳＳ（Operation Support System）やＢＳＳ（Business Support System）が相当するが、上位装置Ｕに関する説明は、他システムＵ１に対してもあてはまるため、特別な事情が無い限り、他システムＵ１に関する説明は省略する。

サーバ系装置は、ＮＳを実行する装置である。サーバ系装置には、例えば、ＤＣ（Data Center：データセンタ）、ＤＣ上に設置されている汎用サーバ、汎用サーバを仮想化した仮想サーバ（ＶＭ（Virtual Machine）。仮想マシン。）があるが、これらに限定されない。仮想サーバには１つのＡＰＬ（Application：アプリケーション）を配置することができる。仮想サーバ上のＡＰＬを動作させることで、所定のＮＳをユーザに提供することができる。本実施形態では、ＡＰＬを、ＶＮＦc（Virtual Network Function Component：仮想ネットワーク機能コンポーネント、ＮＷ機能コンポーネント）または、１つ以上のＶＮＦｃを組み合わせて構成されるＶＮＦ（Virtual Network Function：仮想ネットワーク機能、ＮＷ機能）と呼ぶ場合がある。また、ＤＣは、ＮＦＶＩ−ＰｏＰ（Network Function Virtualization Infrastructure- Point of Presence）と呼ぶ場合がある。

ＮＷ系装置は、ＮＳを実行するためのデータを他のＮＷ系装置またはサーバ系装置に転送する装置である。ＮＷ系装置には、例えば、ＯＬＴ（Optical Line Terminal：光加入者回線終端装置）、コアルータ、Ｌ２ＳＷ（Layer2 Switch）、Ｌ３ＳＷ（Layer3 Switch）、ＮＴＥ（Network Terminal Equipment：ネットワーク終端装置）があるが、これらに限定されない。

（Ｅ２ＥＯ１）
Ｅ２ＥＯ１は、ワークフロー部１１と、要求受付部１２と、カタログ管理部１３と、リソース調停部１４と、ＤＢ（DataBase）１５と、サービス構成情報管理部１６と、サービス構成履歴管理部１７と、インスタンス管理部１８とを備える。

要求受付部１２は、上位装置Ｕから出力されるＮＳ生成要求を取得する。ＮＳ生成要求は、管理装置ＭにＮＳを生成（構築）させる情報である。ＮＳ生成要求は、所定のＮＷ構成を対象にして設定する論理パスを表現するために、複数種類のサーバ系装置の記述子および複数種類のＮＷ系装置の記述子を適宜並べて組み合わせたＮＳ情報を含む。Ｅ２ＥＯ１は、これらの記述子を、ＮＷ上に配置されている対応のサーバ系装置およびＮＷ系装置にマッピングする。また、ＮＳ生成要求は、前記論理パスを利用したＮＳの提供に供する、サーバ系装置およびＮＷ系装置を指定するために必要なインプットパラメータを含む。
また、要求受付部１２は、上位装置Ｕから出力されるＮＳ変更要求を取得する。ＮＳ変更要求は、管理装置Ｍに構築済みのＮＳを変更させる情報である。

カタログ管理部１３は、ＮＳの雛型となるカタログを管理する。上位装置Ｕは、カタログ管理部１３から所望のカタログを取得することができる。オペレータは、上位装置Ｕを操作して、取得したカタログを用いて所定事項（後記のインプットパラメータを含む）を入力することで、所望のＮＳ生成要求を容易に作成することができる。カタログ管理部１１３が管理するカタログは、１または複数種類あり、必要に応じて追加、削除、更新、提供などされる。カタログの詳細は後記する。

リソース調停部１４は、サーバ系装置のリソースおよびＮＷ系装置のリソースを調停する。リソース調停部１４は、この調停の結果をサーバ系装置管理部２およびＮＷ系装置管理部３に出力し、リソースの調停を指示する。
なお、サーバ系装置のリソースには、サーバ系装置自身に割り当てられるリソースが含まれるし、サーバ装置に設定される接続点に接続されるリンクに割り当てられるリソースも含まれる。
また、ＮＷ系装置のリソースには、ＮＷ系装置自身に割り当てられるリソースが含まれるし、ＮＷ系装置に設定される接続点に接続されるリンクに割り当てられるリソースも含まれる。リンクには、仮想化されたリンク（ＶＬ：Virtual Link）も含まれる。サーバ装置に設定される接続点に接続されるリンクと、ＮＷ系装置に設定される接続点に接続されるリンクが同じである場合は、例えば、そのリンクをサーバ系装置のリソースとして扱うことができる。しかし、ＮＷ系装置のリソースとして扱ってもよい。
リソースの調停の詳細については後記する。

ＤＢ１５は、各種情報を体系的に記憶している。ＤＢ１５が記憶している情報には、例えば、カタログ管理部１３が管理するカタログＣが含まれる。
ワークフロー部１１は、管理装置Ｍの処理全体を制御する機能部である。また、ワークフロー部１１は、外部からの要求に応じたＮＳを構築するためのワークフローを管理する。

サービス構成情報管理部１６は、ＮＳの構成情報であるサービス構成情報を管理する。サービス構成情報は、例えば、ＤＢ１５に記憶されている。サービス構成情報の詳細については後記する。

サービス構成履歴管理部１７は、サービス構成情報の履歴を管理する。ＮＳの構成の履歴は、例えば、サービス構成情報の世代管理（後記）を実行したときの結果物としてＤＢ１５に記憶することができる。

インスタンス管理部１８は、構築されたＮＳのサービス構成情報に基づいてインスタンス化されたインスタンス（サービス構成情報に基づいて生成されたインスタンス）を管理する。ＮＳの変更があった場合には、インスタンス管理部１８は、変更後のＮＳのサービス構成情報に基づいてインスタンス化されたインスタンスを管理するとともに、変更前のＮＳのサービス構成情報に基づいてインスタンス化されたインスタンスも管理する。これらのインスタンスの管理情報は、例えば、ＤＢ１５に記憶されている。

（サーバ系装置管理部２）
サーバ系装置管理部２は、ＳＶＲＯ（Server Resource Orchestrator：サーバリソースオーケストレータ）２１と、ＶＩＭ（Virtual Infrastructure Manager：仮想インフラ管理）２２と、ＶＮＦＭ（Virtual Network Function Manager：仮想ネットワーク機能管理）２３と、Ｈ／Ｗ（Hardware）用ＥＭＳ（Element Management System：機器管理システム）２４と、ＡＰＬ用ＥＭＳ２５とを備える。

ＳＶＲＯ２１は、サーバ系装置のリソースの管理を自律的に行う機能部である。ＳＶＲＯ２１は、ＮＷ構成に配置されている１または複数のサーバ系装置を対象にして複数存在させることができる。
ＶＩＭ２２は、汎用サーバに生成されたＶＭを管理、制御する機能部である。ＶＩＭ２２は、生成された１または複数のＶＭを対象にして複数存在させることができる。
ＶＮＦＭ２３は、汎用サーバに生成されたＶＭに実装されているＡＰＬを管理、制御する機能部である。ＶＮＦＭ２３は、ＮＷ構成上で動作する１または複数のＡＰＬを対象にして複数存在させることができる。
Ｈ／Ｗ用ＥＭＳ２４は、サーバ系装置を管理、制御する機能部である。
ＡＰＬ用ＥＭＳ２５は、上位装置Ｕからの要求情報に応じて、ＡＰＬを管理、制御する機能部である。

（ＮＷ系装置管理部３）
ＮＷ系装置管理部３は、ＮＷＲＯ（Network Resource Orchestrator：ネットワークリソースオーケストレータ）３１と、ＮＩＭ（Network Infrastructure Manager）３２とを備える。

ＮＷＲＯ３１は、ＮＷ系装置のリソースの管理を自律的に行う機能部である。
ＮＩＭ３２は、ＮＷ系装置を管理、制御する機能部である。

（カタログ）
カタログ管理部１３が管理するカタログは、例えば、ＮＳＤ（ＮＳ Descriptor）と、ＶＮＦＤ（ＶＮＦ Descriptor）と、ＰＮＦＤ（Physical Network Function Descriptor）と、ＶＬＤ（ＶＬ Descriptor）と、ＶＮＦＦＧＤ（ＶＮＦ Forwarding Graph Descriptor）といった要素を含む。

ＮＳＤは、ＮＳの構成を記述する部分である。ＮＳＤは、当該ＮＳの識別や構築するために必要な情報や、当該ＮＳに関連するＶＮＦＤ、ＰＮＦＤ、ＶＮＦＦＧＤ、ＶＬＤを参照する情報などを保持する。
ＶＮＦＤは、ＮＳにて利用されるアプリケーション（ＶＮＦ）を記述する部分である。ＶＮＦＤは、当該ＶＮＦの識別や構築するために必要な情報を保持する。
ＰＮＦＤは、ＮＳにて利用される物理機能（サーバ系装置およびＮＷ系装置が提供するＮＷ機能。ＰＮＦ（Physical Network Function）。）を記述する部分である。ＰＮＦＤは、当該ＰＮＦの識別や構築するために必要な情報を保持する。
ＶＬＤは、ＮＳにて利用されるＶＬ（リンク）を記述する部分である。ＶＬＤは、ＶＬの識別や構築するために必要な情報を保持する。
ＶＮＦＦＧＤは、前記ＮＳにて利用される複数のアプリケーション（ＶＮＦ）による連携を記述する部分を含む。アプリケーションによる連携とは、複数の（ＶＮＦ）を接続して１つの機能を提供することを意味する。ＶＮＦＦＧＤは、当該ＶＮＦＦＧＤを識別する情報、連携するＶＮＦ同士のリンク情報、当該ＶＮＦＦＧＤに関連するＶＬＤ、ＶＮＦＤを識別する情報などを保持する。

（ＮＳＤの詳細）
前記ＮＳＤは、ＮＳＤを識別するための名前(nsdName)と、バージョン情報(nsdVersion)と、ＮＳを生成するためのキャパシティや性能といった要件を記述した情報（NS Deployment Flavour）と、ＮＳの端点を記述した情報（Service Access Point）と、Service Access Pointの最大数の情報（maxEndPoint）と、ＮＳ生成時に指定可能なインプットパラメータをＮＳＤに設定する情報(runtimePolicyInfo)と、アラーム通知先の情報(notifications)と、いった要素を含む。

前記NS Deplotyment Flavourは、識別するための情報(nsFlavourID)と、保全のための情報(flavourKey)と、構成するＶＮＦの情報（ConstituentVNF）と、構成するＶＬの情報（ConstituentVL）と、構成するＶＮＦＦＧの情報（ConstitutentVnffg）と、アフィニティーポリシー（AffinityType）と、アンチアフィニティポリシー（AntiAffinityType）と、制約情報（constraint）と、いった要素を含む。

前記Service Access Pointは、識別するための情報（cpId）と、端点タイプの情報（ConnectionPointType）と、生成最大数の情報(maxEndPoint)と、いった要素を含む。

前記Constituent VNFは、ＶＮＦＤを参照するための情報(vnfReference)と、ＶＮＦを生成するための要件を記述した情報（DeplotymentFlavour）を参照するための情報と、インスタンス化契機を判断するための情報(instantiateMode)と、冗長化モデルの情報(redundancyModel)と、アフィニティーポリシー（AffinityType）と、アンチアフィニティポリシー（AntiAffinityType）と、制約情報（constraint）と、能力(capability)と、インスタンス化数(numberOfInstances)と、いった要素を含む。

前記Constituent VLは、ＶＬＤを参照するための情報(vlReference)と、ＶＬを生成するための要件を記述した情報(VldFlavour)と、インスタンス化契機を判断するための情報(instantiateMode)と、制約情報（constraint）と、いった要素を含む。

前記Constituent VNFFGは、ＶＮＦＦＧＤを参照するための情報(vnffgReference)と、インスタンス化契機を判断するための情報(instantiateMode)と、制約情報（constraint）と、いった要素を含む。

前記Affinity Typeは、アフィニティーポリシールールのスコープ情報(affinityScope)と、アフィニティーポリシールールが適用されるリソースを識別する情報のリスト(policyRules)と、いった要素を含む。

前記Anti Affinity Typeは、アンチアフィニティーポリシールールのスコープ情報(antiAffinityScope)と、アンチアフィニティーポリシールールが適用されるリソースを識別する情報のリスト(policyRules)と、いった要素を含む。

前記Connection Point Typeは、サーバ系装置に関する端点情報(ConnectionPointValue)と、ＮＷ系装置に関する端点情報(ConnectionPointValue)と、いった要素を含む。

前記Connection Point Valueは、端点種別（NNI（Network Network Interface）や拠点終端点、ＤＣのGateway Router端点、UNI（User Network Interface）等）と、対応するService Access Pointを識別する情報と、ポート情報（アクセスポートやトランクポート等）と、VLAN-ID情報と、IPｖ4アドレス情報と、IPv6アドレス情報と、IPv4プレフィックス情報と、IPv6プレフィックス情報と、IPv4フィルター情報と、IPv6フィルター情報と、利用プロトコル情報（BGPやOSPF、スタティクス、Direct、VRRP等）と、近接A情報Sと、近接IPv4アドレス情報と、近接IPv6アドレス情報と、認証鍵情報と、エリア情報と、メトリック情報と、MD5鍵情報と、スタティクスルート情報(StaticRoute)と、グループID情報と、ロールID情報と、仮想IPv4アドレス情報と、仮想IPv6情報と、仮想IPv4プレフィックス情報と、仮想IPv6プレフィックス情報と、いった要素を含む。

前記Static Routeは、アドレス種別情報（IPｖ4、IPｖ6等）と、アドレス情報と、プレフィックス情報と、ネクストホップ情報と、いった要素を含む。

（ＶＮＦＤの詳細）
前記ＶＮＦＤは、ＶＮＦＤを識別するための名前(vnfdName)と、バージョン情報(vnfdVersion)と、ＶＮＦを構成するＶＮＦコンポーネントの情報（Virtulised Development Unit）と、ＶＮＦ内部(ＶＮＦｃの間含む)の接続性を記述した情報（IntervalVirtualLinkDescriptor）と、ＶＮＦ外部との端点を記述した情報（ExternalConnectionPointDescriptor）と、ＶＮＦを生成するためのキャパシティや性能といった要件を記述した情報（Deployment Flavour）と、いった要素を含む。

前記Virtulised Development Unitは、識別するための情報(vduId)と、ＶＮＦｃ間の接続性を記述した情報（InternalConnectionPointDescriptor）と、いった要素を含む。

前記Internal Connection Point Descriptorは、識別するための情報(icpId)と、Internal Virtual Link Descriptorを参照するための情報と、端点タイプの情報（ConnectionPointType）と、いった要素を含む。

前記Internal Virtual Link Descriptorは、識別するための名前(vldName)と、バージョン情報(vldVersion)と、概要情報(description)と、Internal Connection Point Descriptorを参照するための情報と、External Connection Point Descriptorを参照するための情報と、接続種別を記述した情報（Connectivity Type）と、ＶＬを生成するための要件を記述した情報(Vld Flavour)と、アフィニティーポリシー（AffinityType）と、アンチアフィニティポリシー（AntiAffinityType）と、いった要素を含む。

前記External Connection Point Descriptorは、識別するための情報(cpId)と、Internal Virtual Link Descriptorを参照するための情報と、Internal Connection Point Descriptorを参照するための情報と、端点タイプの情報（ConnectionPointType）と、いった要素を含む。

前記Deplotyment Flavourは、識別するための情報(dFlavourId)と、保全のための情報(flavourKey)と、構成するＶＤＵの情報（ConstituentVDU）と、構成するＶＬの情報（ConstituentVl）と、制約情報（constraint）と、いった要素を含む。

前記Constituent VDUは、Virtualisation Deployment Unitを参照するための情報と、要求されたインスタンス数の情報(numberOfInstances)と、構成するＶＮＦｃの情報（ConstituentVnfc）と、いった要素を含む。

前記Constituent Vnfcは、識別するための情報(vnfcId)と、Internal Connection Point Descriptorを参照するための情報と、いった要素を含む。

前記Connectivity Typeは、提供種別（L1、L2、L3等）と、接続性要件(E-LineやE-LAN、E-Tree、IPv6、IPv4等)と、いった要素を含む。

前記VLD Flavourは、識別するための情報(vldFlavourId)と、帯域要件を記述した情報(BandWidthRequirements)と、QoSを記述した情報（QoSDescription）と、可用性レベル情報と、いった要素を含む。

前記BandWidthRequirementsは、集約点での必要帯域情報と、端点での必要帯域情報と、いった要素を含む。

前記QoSDescriptionは、最大遅延情報と、最大ジッタ情報と、最大パケット廃棄率と、優先レベルと、いった要素を含む。

（ＶＬＤの詳細）
前記ＶＬＤは、ＶＬＤを識別するための名前(vldName)と、バージョン情報(vldVersion)と、ＣｏｎｎｅｃｔｉｏｎＰｏｉｎｔを参照するための情報と、接続種別を記述した情報（Connectivity Type）と、ＶＬを生成するための要件を記述した情報(Vld Flavour)と、アフィニティーポリシー（AffinityType）と、アンチアフィニティポリシー（AntiAffinityType）と、いった要素を含む。

(ＶＮＦＦＧＤの詳細)
前記ＶＮＦＦＧＤは、ＶＮＦＦＧＤを識別するための名前(vnffgdName)と、バージョン情報(vnffgdVersion)と、端点数情報(numberOfEndponts)と、ＶＬ数情報(numberOfVirtualLinks)と、ＶＬＤ を参照するための情報と、Ｎｅｔｗｏｒｋ Ｆｏｒｗａｒｄｉｎｇ Ｐａｔｈを記述した情報（NFP）と、Ｃｏｎｎｅｃｔｉｏｎ Ｐｏｉｎｔを参照するための情報と、構成するＶＮＦのＶＮＦＤを参照するための情報と、いった要素を含む。

前記NFPは、ＮＦＰを識別するための情報(nfpId)と、NFPに適用するポリシールール（MAC転送ルールやルーティングエントリー等）と、Ｃｏｎｎｅｃｔｉｏｎ Ｐｏｉｎｔを参照するための情報と、いった要素を含む。

(ＰＮＦＤの詳細)
前記ＰＮＦＤは、ＰＮＦＤを識別するための名前(pnfdName)と、バージョン情報(pnfdVersion)と、接続するＶＬの端点を記述した情報（ConnectionPoint）と、いった要素を含む。

前記Connection Pointは、識別するための情報(cpId)と、端点タイプの情報と、いった要素を含む。

ＮＳＤは、ＮＳごと、例えば、ＩＳＰ接続サービスや専用線サービスといったサービスごとに用意され、ＶＮＦＤ、ＰＮＦＤ、ＶＬＤ、および、ＶＮＦＦＧＤの組み合わせによって表現することができる。オペレータは、上位装置Ｕを操作して、インプットパラメータを入力し、所望のＮＳ生成要求を容易に作成することができる。オペレータは、ＮＳ生成要求の作成に関して、基本的には、ＮＳ構成に一致するカタログをＤＢ１５から選択することになる。

例えば、図２に示すＮＷ構成（符号Ｎ１）に対して、上位装置Ｕは、ＮＳＤ（ｃ１）、ＶＮＦＤ（ｃ２）、ＰＮＦＤ（ｃ３）、ＶＮＦＦＧＤ（ｃ５）、ＶＬＤ（ｃ４）が定められたカタログを管理装置Ｍから取得し、取得したカタログにインプットパラメータを入力することができる。なお、このＮＷ構成は、一例として、丸付き数字で示されるコネクションポイントによって、コアＮＷ（ｆ１）に対して、住宅（内の終端装置）に接続されているアクセスＮＷ（ｆ２，ｆ３）、ＩＳＰ事業者Ａ，Ｂ（ｆ４，ｆ５）、所定の地域（Ｚｏｎｅ）に設置されているＤＣ（ｆ６〜ｆ８）が接続されている。インプットパラメータが、アクセス側のコネクションポイントとして１２番を指定（アクセスＮＷ上に配置されており、丸付き数字１２で示されるコネクションポイントを指定）し、アクセス先のＩＳＰ事業者としてＡ（丸付き数字１で示されるコネクションポイントに接続している）を指定するものであった場合、図２中符号Ｎ２に示すように、１２番のコネクションポイントにＶＬが張られたＮＳ（太線の囲み線）が構築される。また、インプットパラメータが、アクセス側のコネクションポイントとして９番を指定（アクセスＮＷ上に配置されており、丸付き数字９で示されるコネクションポイントを指定）し、アクセス先のＩＳＰ事業者としてＢ（丸付き数字２で示されるコネクションポイントに接続している）を指定するものであった場合、図２中符号Ｎ３に示すように、２番のコネクションポイントと９番のコネクションポイントにＶＬが張られた別のＮＳ（太線の囲み線）が構築される。

なお、このＮＳでは、ＶＮＦＤに従って、６番のコネクションポイントに接続されているＤＣ（またはこのＤＣ上のＮＴＥ）に配置されたＶＭ上でｖＮＴＥＡＰＬ（virtual NTE APL）（ｆ９）を実装させている。また、このＮＳでは、７番のコネクションポイントに接続されているＤＣ（またはこのＤＣ上のＮＴＥ）に配置されたＶＭ上で別のｖＮＴＥＡＰＬ（ｆ１０）を実装させている。ｖＮＴＥＡＰＬは、仮想化されたＮＴＥ上で動作するＡＰＬである。

このようにして、管理装置Ｍは、ＮＳの雛型をカタログとして管理し、ＮＳ生成要求に含まれるインプットパラメータに応じてＮＳを構築することができ、同じカタログを再利用して要件の違うサービスを提供することができる。

ワークフロー部１１は、上位装置ＵからのＮＳ生成要求に対してカタログが選定された場合、インプットパラメータに応じて、指定されたサーバ系装置のリソース、および、指定されたＮＷ系装置のリソースを生成して、ＮＳを実現するスライスを生成する（スライス生成ステップ）。スライスは、既存のＮＷの一部を仮想化したＮＷである。ワークフロー部１１は、他の仮想環境の影響を受けることのない独立した１または複数のスライスを生成することができる。
なお、本実施形態では、「ＮＳを実現するスライスを生成する」ことを、単に、「ＮＳを生成する」、と表現する場合がある。

上記のように、仮想化領域となるコアＮＷおよび非仮想化領域となるアクセスＮＷを含むＮＷにＮＳを構築する際、選定されたカタログに対して、インプットパラメータでＮＳの提供に供するサーバ系装置およびＮＷ系装置を指定するために必要な情報を要求すればよい。前記必要な情報は、例えば、サーバ系装置およびＮＷ系装置を指定する情報でもよいし、所定の内部ロジックで選定した結果を示す情報でもよい。
したがって、ネットワークサービスの構築を迅速化・効率化し、ネットワークの利便性を向上させることができる。

（リソースの予約）
ＮＳを構築する場合、対象となるサーバ系装置およびＮＷ系装置に所定量のリソースを割り当て、その後必要なＶＮＦを実装するためのインスタンス化を実行することになる。しかし、本実施形態で扱うＮＷ構成は、例えば、複数のオペレータからのＮＳ生成要求をそれぞれ受けることになるので、インスタンス化の際に必要なリソースが確保できない場合がある。

例えば、図３に示すように、ＮＳを構築する機能を有する参考システムは、オペレータＡ，Ｂから空きリソース照会を受けたとする（ステップＳ１，Ｓ２）。ただし、オペレータＡからの空きリソース照会はオペレータＢからの空きリソース照会よりも少し早かったとする。このとき、参考システムは、オペレータＡに対してリソースの空きありと判定し（ステップＳ３）、その旨の回答を送信する（ステップＳ４）。しかし、オペレータＢからのリソース照会が早すぎたため、オペレータＡからのリソース照会によって本来的には空きが無いにもかかわらず、オペレータＢに対してリソースの空きありと誤って判定してしまい（ステップＳ５）、その旨の回答を送信する（ステップＳ６）。

その結果、オペレータＡからのインスタンス化要求（ステップＳ７）に対しては、通常通り、インスタンス化を実行し、完了通知をするが（ステップＳ８）、オペレータＢからのインスタンス化要求（ステップＳ９）に対しては、すでに空きリソースが無いため（ステップＳ１０）インスタンス化に失敗してしまう（ステップＳ１１）という不都合を招く。

このような不都合を回避するため、管理装置Ｍのリソース調停部１４は、サーバ系装置およびＮＷ系装置に割り当てることになるリソースを管理するリソース情報に、「利用可能リソース」、「予約済リソース」、「利用中リソース」のフラグを持たせる。

「利用可能リソース」のフラグは、対象のリソースが空いているときにオンとなり、そうでなければオフとなる。
「予約済リソース」のフラグは、対象のリソースが上位装置Ｕのオペレータから照会されたときはオンになり、そうでないときはオフとなる。
「利用中リソース」のフラグは、対象のリソースが既にＮＳ提供に利用されているときはオンになり、そうでないときはオフとなる。

上記のように、あるオペレータからリソース照会があったときは、そのリソースを予約済リソースとして確保することで、インスタンス化時には確実にリソースが存在することを保証することができる。図３の例でいえば、参考システムを本実施形態の管理装置Ｍに置き換えた場合、オペレータＡに対してリソースの空きありと判定した時点で（ステップＳ３）、そのリソースを予約済リソースにすることで、管理装置Ｍは、オペレータＢからの空きリソース照会を受けたとしても、すでに予約済みであり他の空きがないため空きリソースが無い旨をオペレータＢに回答することができる。よって、オペレータＢからのインスタンス化要求（図３のステップＳ９）を不要とすることができる。

≪ＮＳ生成処理≫
次に、ＮＳ構築時にて、管理装置ＭがＮＳを生成するときのＮＳ生成処理について説明する。コアＮＷおよびアクセスＮＷには、複数種類のサーバ系装置および複数種類のＮＷ系装置が設置されている。

図４に示すように、まず、管理装置Ｍは、リソース予約生成処理を実行する（ステップＳ２１）。リソース予約生成処理は、ＮＳ提供に利用されるリソースを予約して生成する処理である。具体的には、管理装置Ｍは、上位装置Ｕからリソース予約生成要求を取得する。リソース予約生成要求には、対象のＮＷ構成に配置されているサーバ系装置およびＮＷ系装置のうち、構築予定のＮＳに携わるサーバ系装置およびＮＷ系装置を識別する識別情報が含まれる。

また、管理装置ＭのＥ２ＥＯ１は、リソース予約時におけるインスタンス情報を保持する。インスタンス情報とは、インスタンス化されるＶＮＦを実装することになるサーバ系装置およびＮＷ系装置を特定する情報である。インスタンス情報は、ＤＢ１５に記憶される。

また、管理装置Ｍのサーバ系装置管理部２のＳＶＲＯ２１は、ＶＩＭ２２に対し、仮想リソース予約生成要求を送信する。仮想リソース予約生成要求とは、要求対象のＶＮＦに仮想リソースを確実に生成できるようにするための要求である。結果的に、この要求に応じて、上位装置Ｕからのリソース予約生成要求にて指定されたサーバ系装置上で動作するＶＮＦに、予約分の仮想リソースが生成される。

また、管理装置ＭのＮＷ系装置管理部３のＮＷＲＯ３１は、ＮＩＭ３２に対し、ＮＷリソース予約生成要求を送信する。ＮＷリソース予約生成要求とは、要求対象のＮＷ系装置にリソースを確実に生成できるようにするための要求である。結果的に、この要求に応じて、上位装置Ｕからのリソース予約生成要求にて指定されたＮＷ系装置に、予約されるリソースが生成される。
ステップＳ２１のリソース予約生成処理により、構築予定のＮＳの提供に利用されるリソースを確実に生成し、インスタンス化失敗（図３参照）を未然に防ぐことができる。

次に、管理装置Ｍは、ＮＳ生成処理を実行する（ステップＳ２２）。ＮＳ生成処理は、リソースが予約された状態でＮＷ構成に対してＮＳを生成（構築）する処理である。具体的には、管理装置Ｍは、上位装置ＵからＮＳ生成要求を取得する。ＮＳ生成要求には、構築予定のＮＳに携わり、リソースが予約済みである、サーバ系装置およびＮＷ系装置を識別する識別情報が含まれる。ＮＳ生成要求は、インプットパラメータと同一視することができる。

また、管理装置ＭのＥ２ＥＯ１は、受信したＮＳ生成要求を解析して、要求の対象となるＮＳが予約済であるか否かを検査する。具体的には、構築予定のＮＳに携わるサーバ系装置およびＮＷ系装置のリソースが予約生成されているか否かを検査する。ここでは、そのリソースが予約生成されているとする。

また、管理装置ＭのＮＷ系装置管理部３のＮＷＲＯ３１は、ＮＩＭ３２に対し、リソース生成要求を送信する。結果的に、この要求に応じて、ＮＩＭ３２自身の管理対象のＮＷ系装置に対してリソースが生成される。

また、管理装置Ｍのサーバ系装置管理部２のＳＶＲＯ２１は、ＶＩＭ２２に対し、リソース生成要求を送信する。この要求に応じて、ＶＩＭ２２自身の管理対象のサーバ系装置に対してリソースが生成される。

また、管理装置Ｍのサーバ系装置管理部２のＳＶＲＯ２１は、ＶＮＦＭ２３に対して、ＶＮＦインスタンス化要求を送信する。結果的に、この要求に応じて、構築予定のＮＳに携わるサーバ系装置上で動作するＶＮＦのインスタンス化が実現する。

ステップＳ２２のＮＳ生成処理により、要求のあったＮＳを構築することができる。
なお、ワークフロー部１１は、構築したＮＳを実現するスライスを生成する。

（リソースの予約の応用）
リソース調停部１４は、まず、ＳＶＲＯ２１によりサーバ系装置の（仮想）リソースの予約を行い、その後、ＮＷＲＯ３１によりＮＷ系装置の（仮想）リソースの予約を行う、という順番をとることができる。このような順番をとることで、ＮＳ生成時のサーバ系装置を構築する拠点（ＤＣなど）を柔軟に選択することができる。

ＮＷ構成の性質上、１つのサーバ系装置に対しては多数のＮＷ系装置が接続されているのに対し、１つのＮＷ系装置に対しては少数の限られたサーバ系装置だけ接続されていることが多い。このため、リソースを生成するＮＷ系装置を先に決定してしまうと、リソースを生成するサーバ系装置として、先に決定したＮＷ系装置に接続されている限られたサーバ系装置を選択するしかないという不便性がある。本実施形態のような順番にすれば、この不便性は回避できる。

また、リソース調停部１４は、リソースの予約が完了後、ＮＷ系装置のリソースの予約からＮＷ接続の生成・有効化を行い、その後、サーバ系装置のリソースの予約からアプリケーションの生成・有効化を行う、という順番をとることができる。
このような順番をとることで、ＮＷの疎通性の確保を行い、その後、アプリケーションの起動を行うことでＮＳ生成と同時にＮＳの疎通試験を行うことができる。

リソース調停部１４は、サーバ系装置のリソースの予約、および、ＮＷ系装置のリソースの予約に関して、リソースの予約の終了期限を設定可能とすることができる。例えば、「予約済リソース」のフラグがオンになっているリソースに関して、終了期限を迎えるまでにそのリソースの生成がなされることが無ければ、リソース調停部１４は、「予約済リソース」のフラグをオフにする。これにより、予約済のリソースによるリソース占有を回避することができる。

また、リソース調停部１４は、サーバ系装置のリソースの予約、および、ＮＷ系装置のリソースの予約に関して、リソースの予約の（受付）開始日時を設定可能とすることができる。これにより、ＮＳ生成要求日時前にオペレータによるオペレーションをすることができる。その結果、上位装置Ｕのオペレータは、将来を見据えた戦略的なリソース予約を実施することができ、上位装置Ｕの稼働を削減し、オペレータの作業効率を向上させることができる。

また、サーバ系装置のリソースの予約、および、ＮＷ系装置のリソースの予約に関して、インプットパラメータにて予約の優先度を設定することができる。具体的には、リソース情報に、リソースの予約に関する優先度フラグを設定し、優先度フラグに「最優先」（優先度大）、「優先」（優先度中）、「一般」（優先度小）といった段階的な値を持たせることができる。これにより、複数のオペレータからのリソース予約によって予約の競合が発生しても、優先度のより大きなリソースを確保できるようにし、ＮＳ構築を円滑に進めることができる。例えば、優先度の大きなリソースは、社会的・経済的に重要と認められるリソースとするとよい。

ＮＳの内容によっては、サーバ系装置とＮＷ系装置とを接続する場合において、サーバ系装置のリソース（サーバ系リソース）が必要とする端点数（接続点の数）と、ＮＷ系装置のリソース（ＮＷ系リソース）に設定する端点数（接続点の数）が異なる場合がある。このとき、リソース調停部１４は、サーバ系リソースが必要とする端点のＮＷ情報として、ＶＬＡＮ（Virtual Local Area Network）−ＩＤ、サブネットレンジ、デフォルトゲートウェイ）などからＮＷ系リソースの設定に必要な情報を抽出して、両端点数の差分の調停を行うことができる。これにより、端点数が異なる、サーバ系装置−ＮＷ系装置間の接続を一括設定することができる。例えば、１つの接続点を有するＧＷルータ（ＮＷ系装置の例）に対し、１つの接続点を有する４つのＶＮＦを一括で接続させることができる。

（カタログの応用）
ＮＳの構成部分として、このＮＳの初期構築時にインスタンスが生成される部分（加入者非依存部分）と、初期構築後に加入者単位で（例えば、ＩＳＰ事業者ごとに）インスタンスが随時追加生成される部分（加入者依存部分）とが存在する。加入者非依存部分は、例えば、Ｅ２Ｅ−ＮＳの基本部分となる、各加入者に共通なコアＮＷスライス（Ｌ３（Layer3）−ＶＰＮ（Virtual Private Network）スライスなど）とし、加入者依存部分は、例えば、加入者追加時に生成される、アクセスＮＷおよび加入者専用ＡＰＬに対応する個別スライス（Ｌ２（Layer2）−ＶＰＮスライスなど）とすることができる。

このようなＮＳを実現するために、カタログの要素として、ＮＳを実現するスライスが、ＮＳ構築時に生成されるスライスであるか、加入者追加時に追加生成されるスライスであるかを区別するインスタンス化契機フラグを記述する要素を具備する。インスタンス化契機フラグを具備することにより、ワークフロー部１１が、構築予定のＮＳの各部分について適切なインスタンス化契機を判断することができる。

（インスタンス管理）
本実施形態の管理装置Ｍに代表されるオーケストレータは、ＴＭＦ（TeleManegement Forum）６２２が規定するProduct Orderingで実行されるProduct Orderがあると、インスタンスを作成する。作成されたインスタンスは、すでに説明した、インスタンス化されたＶＮＦである。また、作成されたインスタンスは、仮想化されたＮＷ機能のインスタンスを登録するためのＮＦＶ（Network Function Virtualization）インスタンスファイルの種類の１つとなるＮＳＲ（Network Service Record）である。

また、作成されたインスタンスは、Product Inventryにて管理されている。Product Inventryは、例えば、ＴＭＦ６３７に規定されているものであり、本実施形態では、インスタンス管理部１８として実装されている。

Product Inventryにてインスタンスを管理するために用いられる各種情報、および、これらの情報の関連は、図５のＵＭＬ図で表現することができる（コンポジット構造図の形式で表現）。本実施形態では、図５に示すこれらの情報の集合をサービス構成情報と呼ぶ。サービス構成情報は、ＤＢ１５に記憶されており、サービス構成情報管理部１６が管理する。

図５に示すサービス構成情報は、例えば、Product分類子４０ａと、ProductSpecificationRef分類子４０ｂと、BillingAccountRef分類子４０ｃと、RealizingService分類子４０ｄと、ProductOfferingRef分類子４０ｅと、RealizingResource分類子４０ｆと、ProductPrice分類子４０ｇと、Price分類子４０ｈと、ProductRelationship分類子４０ｉと、ProductRef分類子４０ｊと、ProductCharacteristic分類子４０ｋと、AgreementRef分類子４０ｌと、RelatedPartyRef分類子４０ｍとを含む。

ProductSpecificationRef分類子４０ｂは、ProductSpecificationコネクタによってProduct分類子４０ａと関連付けられている。
BillingAccountRef分類子４０ｃは、billingAccountコネクタによってProduct分類子４０ａと関連付けられている。
RealizingService分類子４０ｄは、realizingServiceコネクタによってProduct分類子４０ａと関連付けられている。
ProductOfferingRef分類子４０ｅは、productOfferingコネクタによってProduct分類子４０ａと関連付けられている。
RealizingResource分類子４０ｆは、realizingResourceコネクタによってProduct分類子４０ａと関連付けられている。
ProductPrice分類子４０ｇは、productPriceコネクタによってProduct分類子４０ａと関連付けられている。
Price分類子４０ｈは、priceコネクタによってProductPrice分類子４０ｇと関連付けられている。
ProductRelationship分類子４０ｉは、productRelationshipコネクタによってProduct分類子４０ａと関連付けられている。
ProductRef分類子４０ｊは、productコネクタによってProductRelationship分類子４０ｉと関連付けられている。
ProductCharacteristic分類子４０ｋは、productCharacteristicコネクタによってProduct分類子４０ａと関連付けられている。
AgreementRef分類子４０ｌは、agreementコネクタによってProduct分類子４０ａと関連付けられている。
RelatedPartyRef分類子４０ｍは、relatedPartyコネクタによってProduct分類子４０ａと関連付けられている。

本実施形態の管理装置Ｍが、構築されたＮＳを変更する場合、サービス構成情報を変更することになり、図５中の各種情報（例えば、Price分類子４０ｈ）を変更する。サービス構成情報の変更は、例えば、Product Ordering用のＡＰＩ（Application Programming Interface）となるProduct Ordering APIに対し、ActionとしてModifyを設定することで、Product Inventryの管理用ＡＰＩとなるProduct Inventry Management APIを用いることができるようにし、Product Inventryに対するPUT操作（全部置換の更新メソッド）、PATCH操作（部分置換の更新メソッド）を適宜行うことで実行することができる。

要求受付部１２が上位装置Ｕから取得するＮＳ変更要求には、上記のPUT操作やPATCH操作が、サービス構成情報を変更するためのインプットパラメータとして含まれている。ＮＳ変更要求によるサービス構成情報の変更は、カタログそのものを変化させるものではなく、カタログ内の値を変化させるものであるため、カタログそのものを変化させる場合と比較して、ＮＳ変更に伴う負荷を低減化することができる。

（ＮＳのライフサイクル管理）
ユーザに対するサービスを継続する上で、ＮＳの更新、削除といったライフサイクルの管理を行うことになる。本実施形態では、ＮＳのライフサイクルの管理は、インスタンス管理部１８（またはインスタンス管理部１８を制御するワークフロー部１１）が担当する。ＮＳのライフサイクルの管理は、Product Orderのライフサイクルと、Product Inventryのライフサイクルに分類することができる。

［Product Orderのライフサイクルの管理］
Product Orderのライフサイクルは、図６に示す状態遷移図で表すことができる。図６の状態遷移図は、ＴＭＦ６３７「Product_Ordering_API_REST_Specification」に規定されている「PRODUCTORDER LIFECYCLE」である。図６に示すように、Product Orderのライフサイクルは、AcknowledgedフェーズＰ１１と、RejectedフェーズＰ１２と、InProgressフェーズＰ１３と、PendingフェーズＰ１４と、CancelledフェーズＰ１５と、HeldフェーズＰ１６と、CompletedフェーズＰ１７と、FailedフェーズＰ１８と、PartialフェーズＰ１９といった各状態間の遷移で表現することができる。

AcknowledgedフェーズＰ１１は、（ＮＳの変更に関する）オーダが受信され、（上位装置Ｕに）通知を返したことを示すフェーズである。AcknowledgedフェーズＰ１１は、オーダの受信が成功したとき（Accept Order分岐ＢでYes）に到達する。

RejectedフェーズＰ１２は、オーダの受信を拒否したことを示すフェーズである。RejectedフェーズＰ１２は、オーダの受信が失敗したとき（Accept Order分岐ＢでNo）に到達し、その後、Product Orderのライフサイクルが終了する。オーダの受信が失敗とは、例えば、チェックＮＧ（オーダの実現不可）、オーダ情報の誤り、ビジネスルール不適合がある。

InProgressフェーズＰ１３は、オーダが実現可能であることのチェックが完了しており、サービスのデリバリ（提供）が開始したことを示すフェーズである。RejectedフェーズＰ１２は、AcknowledgedフェーズＰ１１にてオーダ処理を開始したとき（Start Order treatment）、PendingフェーズＰ１４にて追加情報を受信したとき（Extra information received）、HeldフェーズＰ１６にて問題が解決したとき（Issue is solved）に到達する。

PendingフェーズＰ１４は、オーダを進めるために、完了しなければならない操作を待っていることを示すフェーズである。PendingフェーズＰ１４は、InProgressフェーズＰ１３にて追加情報を要求しているとき（Ordering process needs extra information to continue）に到達する。

CancelledフェーズＰ１５は、流通中のオーダが正常に取り消されたことを示すフェーズである。CancelledフェーズＰ１５は、PendingフェーズＰ１４にて追加情報が得られなかったとき（Extra information cannot be supplied）、HeldフェーズＰ１６にて問題が解決できなかったとき（Issue is solved）に到達し、その後、Product Orderのライフサイクルが終了する。

HeldフェーズＰ１６は、設備の不足などの問題（Issue）でオーダを進めることができないことを示すフェーズである。HeldフェーズＰ１６は、InProgressフェーズＰ１３にてオーダ処理が阻害されているとき（Ordering process is blocked due to an issue）に到達する。

CompletedフェーズＰ１７は、オーダが完了し、サービスが開始されたことを示すフェーズである。CompletedフェーズＰ１７は、オーダ処理が完了したとき（Order completely treated）に到達し、その後、Product Orderのライフサイクルが終了する。

FailedフェーズＰ１８は、すべてのオーダアイテムが失敗し、結果としてオーダ全体が失敗となったことを示すフェーズである。FailedフェーズＰ１８は、すべてのオーダ処理が失敗したとき（Order completely failed）に到達し、その後、Product Orderのライフサイクルが終了する。

PartialフェーズＰ１９は、いくつかのオーダアイテムが失敗しており、いくつかは成功していることを示すフェーズである。PartialフェーズＰ１９は、オーダ処理が部分的に成功または失敗したとき（Order partially completed/failed）に到達し、その後、Product Orderのライフサイクルが終了する。

［Product Inventryのライフサイクルの管理］
Product Inventryのライフサイクルは、図７に示す状態遷移図で表すことができる。図７の状態遷移図は、ＴＭＦ６３７「Product_Inventory_Management_API_REST_Specification」に規定されている「STATE MACHINE DIAGRAM FOR STATUS ATTRIBUTE ON PRODUCT」である。図７に示すように、Product Inventryのライフサイクルは、createdフェーズＰ２１と、pending activeフェーズＰ２２と、abortedフェーズＰ２３と、activeフェーズＰ２４と、cancelledフェーズＰ２５と、suspendedフェーズＰ２６と、terminatedフェーズＰ２７と、pending terminatedフェーズＰ２８といった各状態間の遷移で表現することができる。

createdフェーズＰ２１は、サービスが新たにシステム投入され、他のフェーズＰ２２〜Ｐ２８のいずれにも特定されていないときに属することを示すフェーズである。createdフェーズＰ２１は、初期状態を示すフェーズとなる。

pending activeフェーズＰ２２は、準備はされているが、まだ顧客（ユーザ）がサービスを利用できないことを示すフェーズである。pending activeフェーズＰ２２は、createdフェーズＰ２１にてアクティベーションがなされたとき（activate1）に到達する。

abortedフェーズＰ２３は、技術的または内部的要因でアクティベーションが中止されたことを示すフェーズである。abortedフェーズＰ２３は、pending activeフェーズＰ２２にてアクティベーションが中止したとき（abort）に到達する。

activeフェーズＰ２４は、顧客がプロダクトを使用可能であることを示すフェーズである。activeフェーズＰ２４は、createdフェーズＰ２１にてアクティベーションがなされたとき（activate1）、pending activeフェーズＰ２２にてアクティベーションがなされたとき（activate2）、suspendedフェーズＰ２６にて顧客がプロダクトを使用可能になったとき（re-enable）に到達する。

cancelledフェーズＰ２５は、顧客や法的な要求によってアクティベーションが中止されたことを示すフェーズである。cancelledフェーズＰ２５は、pending activeフェーズＰ２２にてアクティベーションが中止したとき（cancel）に到達する。

suspendedフェーズＰ２６は、料金未納や顧客要望によって一時的に休止されたことを示すフェーズである。suspendedフェーズＰ２６にあるとき顧客はサービスを利用できない。suspendedフェーズＰ２６は、activeフェーズＰ２４にてサービスが休止したとき（suspend）に到達する。

terminatedフェーズＰ２７は、顧客がサービスを利用することができないことを示すフェーズである。terminatedフェーズＰ２７は、activeフェーズＰ２４にてサービスが廃止される予定が決まったとき（terminate1）、pending terminatedフェーズＰ２８にてサービスが廃止されたとき（terminate2）に到達する。

pending terminatedフェーズＰ２８は、サービスが廃止される予定であるが、顧客がまだプロダクトを使用可能であることを示すフェーズである。pending terminatedフェーズＰ２８は、activeフェーズＰ２４にてサービスが廃止される予定が決まったとき（terminate1）に到達する。

Product Inventryのライフサイクルは、例えば、Product Orderを受信した後に開始することもできる。詳細には、Product Orderのライフサイクル（図６）のInProgressフェーズＰ１３への遷移を契機として、Product Inventryのライフサイクル（図７）にてProduct InventoryをcreatedフェーズＰ２１に遷移させることができる（図７の矢印Ａ１参照）。また、内部的にProduct Inventryの処理を実行しておき（図７の矢印Ａ２参照）、Product Inventryがactiveになり、activeフェーズＰ２４に遷移したことを契機として、Product OrderをCompletedフェーズＰ１７（図６）に遷移させることができる。
なお、上記とは異なり、Product Inventryのライフサイクルは、例えば、Product Orderの受信の有無にかかわらず事前に開始することもできる。

（サービス構成情報に対するProduct Orderの処理）
サービス構成情報を変更するとき、具体的には、Product Inventoryに対するＰＵＴ操作、ＰＡＴＣＨ操作を実行するとき、従来では、対象のサービスの加入者（ユーザ）、および、当該サービスに連携する連携サービスの加入者（ユーザ）に対して、変更後のサービス構成情報がデフォルトで適用される。しかし、例えば、（１）サービス提供不可状態への遷移（例：suspendedフェーズＰ２６（図７）への遷移）、（２）帯域減少を伴う変更（例：100M→32M）の場合には、サービス影響が発生し得る。

そこで、本実施形態の管理装置Ｍは、サービス構成情報の変更するとき、以下の手段１〜手段３を実行する。
手段１：変更前のサービス構成情報を保存。
手段２：変更前のサービス構成情報に自動的に版数を付与した世代管理を実行。
手段３：最後に変更した後のサービス構成情報は最新世代として扱う。

手段１は、サービス構成情報管理部１６が担当する。サービス構成情報管理部１６は、変更前のサービス構成情報について、Product Orderのライフサイクル（図６）のいずれの状態に遷移しているか、および、Product Inventryのライフサイクル（図６）のいずれの状態に遷移しているかも保存する。保存先はＤＢ１５である。

手段２，３は、サービス構成履歴管理部１７が担当する。サービス構成履歴管理部１７は、サービス構成情報の変更のたびに、新たな版数を付与し、版数が付与されたサービス構成情報は一通りＤＢ１５に保存する。

新たなProduct Orderがあった場合、どの世代（版数）のサービス構成情報を利用するかを設定可能とする。ワークフロー部１１は、サービス構成情報の世代を、上位装置Ｕのオペレータが設定可能とするためのパラメータを有している。

また、ワークフロー部１１は、所定の条件に応じて、どの世代のサービス構成情報を利用するかを自動判別する機能を有してもよい。例えば、外部から取得したProduct Orderが、旧版のサービス構成情報に紐づくインスタンス（インスタンス管理部１８が管理）に対するProduct Orderである場合、サービス構成情報管理部１６は、自動判別によって、旧版のサービス構成情報を選択してサービスを提供することができる。一般的に、外部から取得したProduct Orderが、特定世代（任意の世代）のサービス構成情報に紐づくインスタンスに対するProduct Orderである場合、サービス構成情報管理部１６は、自動判別によって、特定世代のサービス構成情報を選択してサービスを提供することができる。

また、例えば、（最新世代のサービス構成情報を仮に用いた場合には）帯域減少を伴うサービス構成情報の変更の場合は、ワークフロー部１１は、旧版のサービス構成情報をあえて用いて、帯域減少を回避する、といった自動判別を行ってもよい。また、価格変更を伴うサービス構成情報の変更の場合は、ワークフロー部１１は、常に最新世代のサービス構成情報を用いる、といった自動判別を行ってもよい。これらのように業務に応じて世代を使い分け、利便性を向上させることができる。
なお、自動判別に関する条件が無い場合には、ワークフロー部１１は、最新世代のサービス構成情報を用いるとしてもよい。

（ユーザに対するサービス継続の中断の回避）
ＮＳを変更する場合、変更後の新版のサービス構成情報を用いる場合には、従来技術では、変更前の旧版のサービス構成情報を廃止することになる。このとき、従来技術では、旧版のサービスでインスタンス化済の加入者（旧版のサービス構成情報に基づいて構築されたＮＳで用いられたインスタンス化済のＶＮＦを利用するユーザ）の加入者数に関わらず、オーケストレータは、廃止（delete）のProduct Orderを外部から受信した時点でオーダ処理を実行し、旧版のサービス構成情報（Product Inventory）をterminatedに遷移させていた（Product Inventory（図７）にてterminatedフェーズＰ２７に遷移させていた）。従来技術では、旧版のサービスでインスタンス化済の加入者に関する処理は、何ら定義されていないため、旧版のサービス構成情報がterminatedに遷移した場合、インスタンス化済の加入者も含めてサービスが削除される。結果として、サービス構成情報の変更時に、加入者のサービス断（ユーザに対するサービス継続の中断）が発生し、ＮＳの信頼性を損ねる可能性があった。

本実施形態の管理装置Ｍのワークフロー部１１は、加入者のサービス断を防ぐ機能として、旧版サービス加入者ガード機能と、旧版サービスに対する業務制限機能とを有する。

旧版サービス加入者ガード機能とは、旧版のサービスでインスタンス化済の加入者が存在する場合には、旧版のサービス構成情報（Product Inventory）をterminatedに遷移させることを防ぐ機能である。ＤＢ１５（図１）には、旧版のサービスでインスタンス化済の加入者の情報が登録されており、ワークフロー部１１は、ＤＢ１５を参照することで当該加入者の有無を確認することができる。また、ワークフロー部１１は、旧版のサービスでインスタンス化済の加入者が存在する場合には、図７のProduct Inventryのライフサイクルにて、activeフェーズＰ２４からterminatedフェーズＰ２７への遷移、および、pending terminatedフェーズＰ２８からterminatedフェーズＰ２７への遷移を禁止する。
旧版サービス加入者ガード機能によって、サービス構成情報の変更時に、旧版サービスの加入者をサービス断から保護することができる。

旧版サービスに対する業務制限機能とは、旧版のサービスでインスタンス化済の加入者が存在する場合、または、旧版サービスが他のサービスと連携している場合には、Product Order（業務）を制限する機能である。Product Orderの制限とは、管理装置Ｍに入力される業務を、処理を許可する業務および処理を禁止する業務に分類し、処理を許可する業務のみを実行することをいう。

管理装置Ｍのワークフロー部１１は、例えば、上位装置Ｕからの入力によって、処理を許可する業務を予め設定する。つまり、ワークフロー部１１は、処理を許可する業務をホワイトリストに含めるホワイトリスト方式を採用する。ワークフロー部１１は、処理を許可する業務をＤＢ１５に登録することができる。ホワイトリストに存在しない業務が上位装置Ｕから要求された場合には、処理を禁止する業務として扱い、エラー返却を行う。このエラー返却は、例えば、NgReasonを拡張して定義することで実現できる。
または、処理を許可しない業務をあらかじめ設定することもできる。つまり、ワークフロー部１１は、処理を許可しない業務をブラックリストに含めるブラックリスト方式も採用できる。ワークフロー部１１は、処理を許可しない業務をＤＢ１５に登録することができる。ブラックリストに存在する業務が上位装置Ｕから要求された場合には、処理を禁止する業務として扱い、エラー返却を行う。このエラー返却は、例えばNgReasonを拡張して定義することで実現できる。

また、旧版サービスに対する業務制限機能では、旧版サービスを利用しようとする新規加入者の追加は禁止する。また、旧版サービスに対する業務制限機能では、旧版サービスに対する新規サービスの連携、つまり、旧版サービスを利用することで利用可能となる新規サービスの導入は禁止する。ワークフロー部１１は、これらの禁止に関する処理を行う。

旧版サービスに対する業務制限機能によって、旧版サービスのゆるやかな巻き取り（旧版サービスの利用量の減少）を促進させることができる。その結果、サービス構成情報の変更時に、旧版サービスの加入者をサービス断を低減させることができる。

また、ワークフロー部１１は、旧版サービスに対する業務制限の制限レベルを設定することができ、制限レベルに応じて制限業務を適宜変更することができる。例えば、新版サービス導入直後は、加入者の旧版サービスの利用への変更を許可するが、新版サービス導入後ｎ（自然数）年経過した後は制限レベルを引き上げ、旧版サービスの利用への変更は許可せず、旧版サービスの加入者の解約や、旧版サービスとのサービス連携の解除のみを可能とする。
制限レベルの設定により、旧版サービスのゆるやかな巻き取りをさらに促進させることができる。

また、ワークフロー部１１は、旧版サービスに対する業務制限機能による業務制限を実行したことを、関係者に通知する通知機能を有してもよい。ここで、関係者とは、旧版サービスを利用する加入者、旧版サービスと連携する連携先サービスの提供者、旧版サービスに係る利用サービスプロバイダなどを挙げることができるが、これらに限定されない。また、通知機能に通知の手段は、例えば、メール通知などの周知の手段を用いることができる。また、通知機能による通知のタイミングは、業務制限開始時や制限レベルの変更時などといった所定のタイミングを挙げることができるが、これらに限定されない。
通知機能による通知により、関係者に新版サービスの存在を確実に知らせることができ、旧版サービスのゆるやかな巻き取りをさらに促進させることができる。

≪ＮＳ変更処理≫
次に、ＮＳ変更時にて、管理装置ＭがＮＳを変更するときのＮＳ変更処理について説明する。
図８に示すように、まず、管理装置Ｍは、要求受付部１２によって、上位装置ＵからＮＳ変更要求を取得する（ステップＳ３１）。

次に、管理装置Ｍは、ワークフロー部１１によって、要求受付部１２に含まれるインプットパラメータに基づいて、現行のＮＳに対応するサービス構成情報（図５参照）を変更する（ステップＳ３２）。

次に、管理装置Ｍは、ワークフロー部１１によって、変更後のサービス構成情報に基づいてインスタンス化されたインスタンスを用いてＮＳを変更する（ステップＳ３３）。変更後のサービス構成情報に基づいてインスタンス化されたインスタンスは、インスタンス管理部１８が管理する。また、ＮＳを変更する際、変更前の（現行の）サービス構成情報に基づいてインスタンス化されたインスタンスは、インスタンス管理部１８によって保護される。変更前のサービス構成情報に基づいてインスタンス化されたインスタンスの保護とは、変更前のサービス構成情報の廃止を防止することを意味し、具体的には、先述した、旧版サービス加入者ガード機能、旧版サービスに対する業務制限機能が該当する。

次に、管理装置Ｍは、サービス構成履歴管理部１７によって、変更後のサービス構成情報に版数を付与する（ステップＳ３４）。変更後のサービス構成情報に付与する版数は、最新世代を象徴する版数となる。サービス構成履歴管理部１７は、変更後のサービス構成情報に付与した版数を、変更後のサービス構成情報に紐付けるようにしてＤＢ１５に登録する。

次に、管理装置Ｍは、サービス構成情報管理部１６によって、変更後のサービス構成情報をＤＢ１５に保存する（ステップＳ３５）。このとき、変更後のサービス構成情報に付与した版数を変更後のサービス構成情報に紐付けるようにしてＤＢ１５に保存する。

次に、管理装置Ｍは、ワークフロー部１１によって、旧版サービス業務制限処理を実行する（ステップＳ３６）。具体的には、ワークフロー部１１が、すでに説明した、旧版サービス加入者ガード機能、旧版サービスに対する業務制限機能、旧版サービスに対する業務制限の制限レベルの設定、関係者に通知する通知機能を実行する。これにより、サービス構成情報を変更した後、旧版サービスのゆるやかな巻き取りを図る。

図８のＮＳ変更処理によれば、サービス構成情報が変更しても、変更前のサービス構成情報に基づくインスタンスを保護するため、当該インスタンスによるサービスでインスタンス化済の加入者のサービスを継続させることができる。

また、図８のＮＳ変更処理によれば、サービス構成情報の版数管理（世代管理）が行われることになるため、当該版数に基づきインスタンス化されている加入者のサービスを継続することができる。よって、特定世代のサービス構成情報に基づく業務が要求された場合には、サービス構成情報管理部１６およびサービス構成履歴管理部１７が、特定世代の（特定の版数が付与された）サービス構成情報をＤＢ１５から読み出し、当該読み出したサービス構成情報に基づいて要求（オーダ）を処理することができる。このとき、インスタンス管理部１８が管理している当該特定世代のサービス構成情報に基づくインスタンスが用いられる。

≪まとめ≫
本実施形態によれば、変更前のサービス構成情報に基づいてインスタンス化されたインスタンスは保護されるため、当該インスタンスを用いたサービスの疎通は確保され、ユーザは、当該サービスを継続して利用することができる。
したがって、ネットワークサービスの変更時におけるネットワークサービスの信頼性を向上させることができる。

また、所望の版数が付与されたサービス構成情報に基づいてインスタンス化されたインスタンスを用いたサービスをユーザに提供することができる。
また、特定の版数が付与されたサービス構成情報に対応する要求であっても確実に処理することができる。
また、変更前のサービス構成情報に基づくインスタンス化によって作成されたインスタンスを利用するユーザによるサービス中断を未然に防ぐことができる。
また、変更前のサービス構成情報に基づくサービスのゆるやかな巻き取りを促進させることができる。
また、変更後のサービス構成情報に基づくサービスを関係者に確実に知らせることができ、変更前のサービス構成情報に基づくサービスのゆるやかな巻き取りをさらに促進させることができる。

（その他）
本実施形態の管理装置Ｍは、入出力用のＩ／Ｆ（インターフェイス）などで構成される入出力部、ハードディスク、フラッシュメモリ、ＲＡＭ（Random Access Memory）などで構成される記憶部、ＣＰＵ（Central Processing Unit）などで構成される制御部といったハードウェアを備えるコンピュータである。制御部は、例えば、記憶部に記憶されているプログラム（ネットワーク管理プログラム）を記憶部の記憶領域に展開し実行することにより、上記の処理が実行される。本実施形態の管理装置Ｍは、このようなソフトウェアとハードウェアの協働を実現することができる。

また、本実施形態では、カタログ管理部１３が管理するカタログとして、ＮＳＤと、ＶＮＦＤと、ＰＮＦＤと、ＶＬＤと、ＶＮＦＦＧＤといった５つの要素を含むものを採り上げた。しかし、他の要素を追加してもよいし（例：すでに説明したインスタンス化契機フラグ）、前記５つの要素のうち少なくとも１つを除いてもよい。例えば、構築予定のＮＳに用いられるアプリケーションが他のアプリケーションとの連携を必要しないのであれば、カタログにＶＮＦＦＧＤを含めなくてもよい。

本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

Ｍ 管理装置
Ｕ 上位装置（外部）
１ Ｅ２ＥＯ
２ サーバ系装置管理部
３ ＮＷ系装置管理部
４ ＯＳＳ
１１ ワークフロー部
１２ 要求受付部
１３ カタログ管理部
１４ リソース調停部
１５ ＤＢ
１６ サービス構成情報管理部
１７ サービス構成履歴管理部
１８ インスタンス管理部
２１ ＳＶＲＯ
２２ ＶＩＭ
２３ ＶＮＦＭ
２４ Ｈ／Ｗ用ＥＭＳ
２５ ＡＰＬ用ＥＭＳ
３１ ＮＷＲＯ
３２ ＮＩＭ

Claims (8)

1. 仮想化領域となるコアＮＷ（Network）および非仮想化領域となるアクセスＮＷを含むＮＷに構築されるＮＳ（Network Service）を管理する管理装置であって、
   前記ＮＳの構成情報であるサービス構成情報を管理するサービス構成情報管理部と、
   前記ＮＳのサービス構成情報の履歴を管理するサービス構成履歴管理部と、
   前記サービス構成情報に基づいて生成されたインスタンスを管理するインスタンス管理部と、
   前記構築されたＮＳの変更を要求するＮＳ変更要求を外部から取得すると、前記ＮＳ変更要求に含まれるインプットパラメータに基づいて前記サービス構成情報を変更するとともに、前記変更する前のサービス構成情報に基づいて生成されたインスタンスを前記インスタンス管理部に保護させるワークフロー部と、を備える、
   ことを特徴とする管理装置。
2. 前記ワークフロー部は、
   前記サービス構成情報の変更の度に、前記変更されたサービス構成情報に版数を付与することで、前記サービス構成情報の世代管理を行う、
   ことを特徴とする請求項１に記載の管理装置。
3. 前記ワークフロー部は、
   前記サービス構成情報管理部および前記サービス構成履歴管理部に、特定の前記版数が付与されたサービス構成情報を読み出させ、当該読み出したサービス構成情報に基づいて要求を処理する、
   ことを特徴とする請求項２に記載の管理装置。
4. 前記ワークフロー部は、
   前記変更する前のサービス構成情報に基づいて生成されたインスタンスを利用するユーザが存在する場合、前記変更する前のサービス構成情報の廃止を防止する、
   ことを特徴とする請求項１から請求項３のいずれか１項に記載の管理装置。
5. 前記ワークフロー部は、
   前記変更する前のサービス構成情報に基づいて生成されたインスタンスを利用するユーザが存在する場合、予め許可が設定された業務について処理を実行可能とする業務制限を実行する、
   ことを特徴とする請求項１から請求項３のいずれか１項に記載の管理装置。
6. 前記ワークフロー部は、
   前記業務制限を変更するための制限レベルを設定する、
   ことを特徴とする請求項５に記載の管理装置。
7. 前記ワークフロー部は、
   前記業務制限を実行したことを所定の関係者に通知する、
   ことを特徴とする請求項５または請求項６に記載の管理装置。
8. 仮想化領域となるコアＮＷ（Network）および非仮想化領域となるアクセスＮＷを含むＮＷに構築されるＮＳ（Network Service）を管理する管理装置におけるネットワークサービス管理方法であって、
   前記管理装置は、
   前記構築されたＮＳの変更を要求するＮＳ変更要求を外部から取得するステップと、
   前記ＮＳ変更要求に含まれるインプットパラメータに基づいて、前記ＮＳの構成情報であるサービス構成情報を変更するステップと、
   前記変更する前のサービス構成情報に基づいて生成されたインスタンスを保護するステップと、を実行する、
   ことを特徴とするネットワークサービス管理方法。

Images