(57)【要約】【課題】サービススライスごとの最新の接続容量を把握する。【解決手段】ネットワーク管理装置は、コア網５を構成する複数のサービススライス９−１〜９−ｎのいずれかに端末８を接続させると共に、各サービススライス９への単位時間当たり要求量を測定し、このサービススライス９を本来の振り分け先とする各端末８からこのサービススライス９への振り分け量および、これら端末８から代替のサービススライス９への振り分け量を分別して測定するスライス制御部７−１，７−２と、スライス制御部７−１，７−２が測定したデータに基づき、各サービススライス９の接続容量を分析するパフォーマンスマネージャ６とを備える。【選択図】図３
2019009499.tif 000002
【特許請求の範囲】
【請求項１】
コア網を構成する複数のサービススライスのいずれかに端末を接続させると共に、各前記サービススライスへの単位時間当たり要求量を測定し、当該サービススライスを本来の振り分け先とする各端末から代替のサービススライスへの振り分け量を測定するスライス制御部と、
前記スライス制御部が測定したデータに基づき、各サービススライスの接続容量を分析するパフォーマンスマネージャと、
を備えることを特徴とするサービススライス性能監視システム。
【請求項２】
前記パフォーマンスマネージャは、前記スライス制御部が測定したデータを受信するデータ受信部と、
前記データ受信部が受信したデータを時系列で蓄積する時系列データ蓄積部と、
を備えることを特徴とする請求項１に記載のサービススライス性能監視システム。
【請求項３】
前記パフォーマンスマネージャは、前記時系列データ蓄積部に格納された時系列データを参照し、各前記サービススライスについて、当該サービススライスから代替のサービススライスへの振り分けが始まった時点を特定して当該時点のトラフィックを上限として捉え、当該上限に対して所定の余裕を持たせたトラフィックを当該サービススライスの接続容量として捉える接続容量分析部、
を備えることを特徴とする請求項２に記載のサービススライス性能監視システム。
【請求項４】
前記接続容量分析部が分析した各サービススライスの接続容量に関する情報を格納するインベントリデータベース、
を備えることを特徴とする請求項３に記載のサービススライス性能監視システム。
【請求項５】
前記パフォーマンスマネージャは、前記接続容量分析部が分析した各サービススライスの接続容量に関する情報を前記スライス制御部に送信する接続容量データ送信部、
を備えることを特徴とする請求項３に記載のサービススライス性能監視システム。
【請求項６】
前記スライス制御部は更に、前記端末を各サービススライスへ接続可能か否かを示す接続条件判定集合を判定して、当該スライス制御部が測定したデータと前記接続条件判定集合とを前記パフォーマンスマネージャに送信する、
ことを特徴とする請求項３に記載のサービススライス性能監視システム。
【請求項７】
スライス制御部は、コア網を構成する複数のサービススライスのいずれかに端末を接続させ、
各前記サービススライスへの単位時間当たり要求量を測定し、
当該サービススライスを本来の振り分け先とする各端末から代替のサービススライスへの振り分け量を測定し、
パフォーマンスマネージャは、前記スライス制御部が測定したデータに基づき、各サービススライスの接続容量を分析する、
ことを特徴とするサービススライス性能監視方法。
【請求項８】
前記パフォーマンスマネージャは、前記スライス制御部が測定したデータを受信し、
受信した前記データを時系列で時系列データ蓄積部に蓄積する、
ことを特徴とする請求項７に記載のサービススライス性能監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービススライスの振り分けにおける、性能の監視技術に関する。特に、端末アクセスポイントからのサービスセッション開始要求と再開要求の度にサービススライスの振り分けが行われる場合の監視に関する。
【背景技術】
【０００２】
従来のネットワークは、1つの物理ネットワークに全てのサービスを同じ基準で収容していた。現在、スマートフォンやフィーチャーフォンのトラフィックが、ネットワークの大半を占めている。
【０００３】
これからは、ＩｏＴ（Internet of Things）サービスの展開に伴い、大量の低スペック端末で構成されるスマートメータや環境センサをネットワークに接続することが求められる。更に工場機器の制御や遠隔手術や拡張現実のように、少量の端末を高い品質でネットワークに接続することも求められている。このようにサービス要求条件が異なる端末を同一の物理ネットワークに収容すると、価格が高すぎたり、サービス要求条件が低すぎたりするなどの問題が発生する。
【０００４】
サービススライスは、物理ネットワークを仮想的に分割（スライス）したものであり、ネットワークスライスとも呼ばれる。サービススライスにより、お客さまが利用するサービスの要求条件に合わせて効率的にネットワークを提供することができる。サービススライス技術によれば、共通のネットワーク基盤上にサービス面の要求条件に応じた複数のサービススライスが仮想的に構築される。これにより、顧客の要求条件に応じたサービスを効率的に提供可能である。
【０００５】
非特許文献１には、携帯電話網においてサービス要求条件を満たすネットワークスライスを割り当てる制御技術が記載されている。また、非特許文献２には、仮想化ネットワークにおける統合制御によるネットワークスライスの割り当て制御技術が記載されている。
【０００６】
しかし、非特許文献１，２に記載の技術では、サービスの要求量が増加した場合に、本来割り当てたサービススライスと条件の近い順に別の一つまたは複数のネットワークスライス（サービススライス）に順次振り分けていく技術は扱われていない。更に、リアルタイムで時系列データをモニタして別のネットワークスライスに振り分けが始まった時点でのトラヒック量および振り分けたサービススライスごとの振り分け量を測定する技術も扱われていない。
【０００７】
非特許文献１および非特許文献２で示される技術では、各サービススライスの最新の接続容量の上限を知ることができない。よって、これらの技術では、スライス割り当てを管理する統合制御において、端末の種々のサービス要求に対してネットワークの設備リソースを効率的に利用できず、かつサービス品質を満足するようにサービススライスを振り分けることができない。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】下城拓也、ウメシュ＝アニール、藤島大輔、巳之口淳、「5G時代に向けた将来コアネットワーク」、NTT DOCOMOテクニカル・ジャーナル、2016年1月、Vol.23、４号、49-58頁
【非特許文献２】有満秀浩、松本公秀、松林泰則、相原正夫、槇林康雄、「ネットワーク仮想化に向けた技術開発の現状」、NTT技術ジャーナル、2014年5月、26巻、５号、6-9頁
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特定サービス（特定ユースケース）の要求量が増加した場合、配置初期に本来所属として定められたサービススライスとは別のサービススライスに振り分けられるセッションが増加する。そのため、どのユースケースにおいて、本来所属として定められたサービススライスとは別のサービススライスへの振り分けが、どの程度発生しているのかを示す時系列データをリアルタイムで監視する必要がある。
【００１０】
しかし、サービススライスごとの振り分け量のデータを取得する手段は提供されておらず、よって、最新のサービススライスごとの接続容量（受付可能な単位時間当たりの要求量）の把握手段も提供されていない。
そこで、本発明は、サービススライスごとの最新の接続容量を把握することを課題とする。
【課題を解決するための手段】
【００１１】
前記した課題を解決するため、請求項１に記載の発明では、コア網を構成する複数のサービススライスのいずれかに端末を接続させると共に、各前記サービススライスへの単位時間当たり要求量を測定し、当該サービススライスを本来の振り分け先とする各端末から代替のサービススライスへの振り分け量を測定するスライス制御部と、前記スライス制御部が測定したデータに基づき、各サービススライスの接続容量を分析するパフォーマンスマネージャと、を備えることを特徴とするサービススライス性能監視システムとした。
【００１２】
このようにすることで、サービススライス性能監視システムは、サービススライスごとの最新の接続容量を把握することができる。
【００１３】
請求項２に記載の発明では、前記パフォーマンスマネージャは、前記スライス制御部が測定したデータを受信するデータ受信部と、前記データ受信部が受信したデータを時系列で蓄積する時系列データ蓄積部と、を備えることを特徴とする請求項１に記載のサービススライス性能監視システムとした。
【００１４】
このようにすることで、サービススライス性能監視システムは、サービススライスごとの振り分け量のデータを取得することができ、よって最新のサービススライスごとの接続容量を把握することができる。
【００１５】
請求項３に記載の発明では、前記パフォーマンスマネージャは、前記時系列データ蓄積部に格納された時系列データを参照し、各前記サービススライスについて、当該サービススライスから代替のサービススライスへの振り分けが始まった時点を特定して当該時点のトラフィックを上限として捉え、当該上限に対して所定の余裕を持たせたトラフィックを当該サービススライスの接続容量として捉える接続容量分析部、を備えることを特徴とする請求項２に記載のサービススライス性能監視システムとした。
【００１６】
このようにすることで、サービススライス性能監視システムは、容易に最新のサービススライスごとの接続容量を捉えることができる。
【００１７】
請求項４に記載の発明では、前記接続容量分析部が分析した各サービススライスの接続容量に関する情報を格納するインベントリデータベース、を備えることを特徴とする請求項３に記載のサービススライス性能監視システムとした。
【００１８】
このようにすることで、サービススライス性能監視システムは、接続容量情報のログを記録することができ、事後的にネットワークの状態を確認できる。
【００１９】
請求項５に記載の発明では、前記パフォーマンスマネージャは、前記接続容量分析部が分析した各サービススライスの接続容量に関する情報を前記スライス制御部に送信する接続容量データ送信部、を備えることを特徴とする請求項３に記載のサービススライス性能監視システムとした。
【００２０】
このようにすることで、サービススライス性能監視システムは、サービススライスごとの振り分け量のデータを取得することができ、よって最新のサービススライスごとの接続容量を把握することができる。
【００２１】
請求項６に記載の発明では、前記スライス制御部は更に、前記端末を各サービススライスへ接続可能か否かを示す接続条件判定集合を判定して、当該スライス制御部が測定したデータと前記接続条件判定集合とを前記パフォーマンスマネージャに送信する、ことを特徴とする請求項３に記載のサービススライス性能監視システムとした。
【００２２】
このようにすることで、時系列データに基づき、代替のサービススライスに接続された各単位時間について、ボトルネックとなった接続可能条件の把握が可能となる。
【００２３】
請求項７に記載の発明では、スライス制御部は、コア網を構成する複数のサービススライスのいずれかに端末を接続させ、各前記サービススライスへの単位時間当たり要求量を測定し、当該サービススライスを本来の振り分け先とする各端末から代替のサービススライスへの振り分け量を測定し、パフォーマンスマネージャは、前記スライス制御部が測定したデータに基づき、各サービススライスの接続容量を分析する、ことを特徴とするサービススライス性能監視方法とした。
【００２４】
このようにすることで、サービススライスごとの最新の接続容量を把握することができる。
【００２５】
請求項８に記載の発明では、前記パフォーマンスマネージャは、前記スライス制御部が測定したデータを受信し、受信した前記データを時系列で時系列データ蓄積部に蓄積する、ことを特徴とする請求項７に記載のサービススライス性能監視方法とした。
【００２６】
このようにすることで、サービススライス性能監視システムは、サービススライスごとの振り分け量の時系列データを取得することができ、よって最新のサービススライスごとの接続容量を把握することができる。
【発明の効果】
【００２７】
本発明によれば、サービススライスごとの最新の接続容量を把握することが可能となる。
【図面の簡単な説明】
【００２８】
【図１】第１の実施形態におけるネットワーク管理装置の機能構成図である。
【図２】変形例におけるネットワーク管理装置の機能構成図である。
【図３】ネットワーク管理装置の要部を示した機能構成図である。
【図４】サービススライス接続容量分析部の処理を示したフローチャートである。
【図５】端末からサービススライスへの接続動作と、振り分け量データの取得動作と、接続容量の判定動作とを示したシーケンス図である。
【図６】第２の実施形態における、振り分け量データの取得動作と、接続容量の判定動作とを示したシーケンス図である。
【発明を実施するための形態】
【００２９】
以降、本発明を実施するための形態を、各図を参照して詳細に説明する。
《第１の実施形態》
第１の実施形態のネットワーク管理装置は、各サービススライスへの単位時間当たり要求量を測定し、当該サービススライスを本来の振り分け先とする各端末から当該サービススライスへの振り分け量と、これら端末から代替のサービススライスへの振り分け量とを分別して測定する。ここでサービススライスへの単位時間当たり要求量とは、単位時間当たりの接続数とデータ量のことをいう。ネットワーク管理装置は、これら測定データを時系列データとして蓄積する。
【００３０】
ネットワーク管理装置は更に、時系列の測定データにより、各サービススライスについて、当該サービススライスから他のサービススライスへの振り分けが始まった時点を特定する。ネットワーク管理装置は、特定した時点における当該サービススライスのトラフィックを上限として捉え、この上限に対して所定の余裕を持たせたトラフィックを、当該サービススライスの接続容量として捉える。これによりネットワーク管理装置は、サービススライス性能監視システムとして動作する。
【００３１】
図１は、第１の実施形態におけるネットワーク管理装置Ｍの機能構成図である。
第１の実施形態のネットワーク管理装置Ｍは、仮想化領域となるコア網５および非仮想化領域となるアクセス網４を管理する。具体的には、ネットワーク管理装置Ｍは、コア網５に配置されている機器およびアクセス網４に配置されている機器からさまざまな情報を収集することで、これらの機器を監視する。通信システムは、コア網５に配置されている機器およびアクセス網４に配置されている機器によって構成される。コア網５は、複数のサービススライスを具現化している。ネットワーク管理装置Ｍは、オーケストレータ部１およびインフラマネージャ部２を備える。
【００３２】
《インフラマネージャ部２の詳細》
インフラマネージャ部２は更に、ＷＩＭ３３と、ＳＤＮマネージャ２６と、テレメトリデータベース２８と、インベントリデータベース２９とを備える。なお、図面ではデータベースのことを、“ＤＢ”と記載している場合がある。
ＷＩＭ３３（WAN（Wide Area Network） Infrastructure Manager）は、コア網５を管理し、制御する。ＷＩＭ３３は、コア網５に含まれるネットワークエレメントからテレメトリデータを取得し、ＳＤＮマネージャ２６に送信する。これにより、ＷＩＭ３３は、各ネットワークエレメントの障害を検知することができる。
【００３３】
ＳＤＮ（Software Defined Networking）マネージャ２６は、ソフトウェアによって具現化された仮想的なネットワークを管理する。ＳＤＮマネージャ２６は、パフォーマンスマネージャ６を備えている。
パフォーマンスマネージャ６は、各サービススライスの性能を監視する。パフォーマンスマネージャ６は、スライス制御部７ａが測定したデータを時系列に蓄積する。パフォーマンスマネージャ６は更に、時系列の測定データにおいて、各サービススライスについて、当該サービススライスから他のサービススライスへの振り分けが始まった時点を特定する。更にパフォーマンスマネージャ６は、特定した時点における当該サービススライスのトラフィックを上限として捉え、この上限に対して所定の余裕を持たせたトラフィックを、当該サービススライスの接続容量として捉える。
【００３４】
テレメトリデータベース２８は、テレメトリデータを格納するデータベースである。
インベントリデータベース２９は、例えばアクセス網４やコア網５の状態情報を格納するデータベースである。第１の実施形態において、インベントリデータベース２９は、コア網５を構成する各サービススライスの接続容量情報を格納する。
【００３５】
更にインフラマネージャ部２は、通信システムを構成しているＩＡサーバ、コアルータ５４、ＳＤＮ−Ｌ２スイッチ５１、ＰＯＮ４１、Ｌ２スイッチ４２、Ｌ３スイッチ４３などの機器を管理する。インフラマネージャ部２は、コア網５を制御するためＶＮＦＭ２１、ＶＩＭ２２などを備え、ＯＳＳ２５により上位装置Ｕと接続される。インフラマネージャ部２は、アクセス網４を制御するため、不図示のＮＭＳ（Network Management System）やＥＭＳ（Element Management System）などを備える。
【００３６】
ＶＮＦＭ（Virtual Network Function Manager：仮想ネットワーク機能管理）２１は、ＩＡサーバに生成された仮想マシンに実装されているアプリケーションを管理し、制御する。
ＶＩＭ（Virtual Infrastructure Manager：仮想インフラ管理）２２は、ＩＡサーバに生成された仮想マシンを管理し、制御する。
ＯＳＳ（Open Source Software）２５は、上位装置Ｕからの要求に応じて、インフラマネージャ部２を動作させるミドルウェアである。ＯＳＳ２５は、いわゆるオープンソース・ソフトウェアである。
【００３７】
《オーケストレータ部１の詳細》
オーケストレータ部１は、コア網５およびアクセス網４に亘って構築される通信システムに対して、ハードウェア、ミドルウェア、アプリケーション、サービスの配備、設定、管理を自律的に行う。オーケストレータ部１は、オペレータが操作する上位装置Ｕからネットワークサービス生成要求などの要求を取得する。オーケストレータ部１は、Ｅ２Ｅオーケストレータ１１と、サーバリソース・オーケストレータ１２と、ネットワークリソース・オーケストレータ１３とを備える。
【００３８】
Ｅ２Ｅオーケストレータ１１は、ユーザに提供されるネットワークサービスを自律的に管理する。
サーバリソース・オーケストレータ１２は、コア網５に配置されているＩＡサーバのリソース、および、ＩＡサーバ上に生成されている仮想マシンのリソースを自律的に管理する。
ネットワークリソース・オーケストレータ１３は、コア網５のリソースおよびアクセス網４のリソースを自律的に管理する。ネットワークリソース・オーケストレータ１３は、他律的な措置を実行する装置である。
【００３９】
《コア網５の構成》
コア網５には、コアルータ５４ａ，５４ｂ、パケット交換システム５３ａ，５３ｂ、ＳＤＮ−Ｌ２スイッチ５１ａ，５１ｂ、ＩＡサーバ、スライス制御部７ａが配置されているが、これらに限定されない。なお、図面ではスイッチのことを“ＳＷ”と記載している場合がある。また、コア網５に配置されているコアルータ５４ａ，５４ｂ、パケット交換システム５３ａ，５３ｂ、ＳＤＮ−Ｌ２スイッチ５１ａ，５１ｂ、ＩＡサーバなどを、ネットワークエレメントと記載している場合がある。
【００４０】
スライス制御部７ａは、コア網５に具現化された複数のサービススライスを制御する。具体的にいうと、スライス制御部７ａは、各サービススライスへの単位時間当たり要求量、このサービススライスを本来の振り分け先とする各端末からこのサービススライスへの振り分け量および、これらの端末から代替のサービススライスへの振り分け量を分別して測定する。更にスライス制御部７ａは、端末からの接続要求を受信した際に、いずれかのサービススライスに端末を接続させる。なお、スライス制御部７ａは、１台に限定されず、複数台が分散されて配置されていてもよい。
【００４１】
コアルータ５４ａ，５４ｂは、コア網５を経由するパケットの転送装置である。以下、コアルータ５４ａ，５４ｂを特に区別しないときには、単にコアルータ５４と記載する。
パケット交換システム（ＰＴＳ：Packet Transport System）５３ａ，５３ｂは、コア網５を経由するパケットを交換するためのシステムである。図面においてパケット交換システム５３ａ，５３ｂは、“ＰＴＳ”と記載している。パケット交換システム５３ａ，５３ｂを特に区別しないときには、単にパケット交換システム５３と記載する。
【００４２】
ＳＤＮ−Ｌ２スイッチ（Software Defined Networking Layer2 Switch）５１ａ，５１ｂは、コア網５を経由するパケットを転送するＳＤＮ対応型の転送装置である。ＳＤＮ−Ｌ２スイッチ５１ａ，５１ｂは、コア網５にてパケットが転送されるパスのＥＰ（End Point：エンドポイント、端点）となる。以下、ＳＤＮ−Ｌ２スイッチ５１ａ，５１ｂを特に区別しないときには、単にＳＤＮ−Ｌ２スイッチ５１と記載する。
【００４３】
ＩＡ（Intel（登録商標） Architecture）サーバは、汎用のサーバである。このＩＡサーバは、周知の仮想化技術によって１または複数の仮想マシン（ＶＭ：Virtual Machine）を生成することができる。仮想マシンは更に、１つのアプリケーション（ＡＰＬ：Application）を配置することができる。仮想マシン上のアプリケーションを動作させることで、仮想マシンは、所定のネットワークサービスをユーザに提供することができる。アプリケーションは、ＶＮＦ（Virtual Network Function：仮想ネットワーク機能）や、ＶＮＦＣ（ＶＮＦ component）と呼ばれる場合がある。
ＩＡサーバ上に生成された仮想マシンや、仮想マシン上に配置されたアプリケーションにより、物理ネットワークを仮想的に分割した複数のサービススライスを具現化することができる。これらサービススライスについては、後記する図３で詳細に説明する。
【００４４】
ＩＡサーバは、データセンタ５２ａ，５２ｂ（ＤＣ：Data Center）に設置されている。以下、データセンタ５２ａ，５２ｂを特に区別しないときには、単にデータセンタ５２と記載する。
各データセンタ５２は、１または複数のＩＡサーバを保有している。データセンタ５２は、ＩＡサーバ群とみなすことができる。データセンタ５２は、他のデータセンタ５２と接続するためのゲートウェイスイッチを備えるが、ここではゲートウェイスイッチに関する説明を省略する。
【００４５】
《データセンタ５２の詳細》
データセンタ５２は、他の仮想環境の影響を受けることのない独立した１または複数のサービススライスを生成することができる。サービススライスは、既存のネットワークの一部を仮想化したネットワークであり、データセンタ５２に対して生成したサービススライスを「ＤＣスライス（汎用サーバ用スライス）」と呼ぶ。データセンタ５２は、複数のＤＣスライスを生成することができる。ＤＣスライスは、自身のＤＣスライス内の仮想マシン間の通信を行うことができるとともに、同じデータセンタ５２内での他のＤＣスライスとの通信や、他のデータセンタ５２内のＤＣスライスとの通信を行うこともできる。
【００４６】
《アクセス網４の詳細》
アクセス網４には、ＰＯＮ４１、Ｌ２スイッチ４２、Ｌ３スイッチ４３が配置されている。なお、アクセス網４に配置される機器は、これらに限定されない。
ＰＯＮ（Passive Optical Network）４１は、複数のユーザ宅へ光ファイバなどの通信用インフラを導入する機器である。なお、ＰＯＮ４１の例として、ＯＬＴ（Optical Line Terminal：光回線終端装置）がある。
Ｌ２スイッチ（Layer2 Switch）４２は、アクセス網４を経由するパケットを、ＯＳＩ（Open Systems Interconnection）参照モデルの第２階層上で制御する転送装置である。
Ｌ３スイッチ（Layer3 Switch）４３は、アクセス網４を経由するパケットを、ＯＳＩ参照モデルの第３階層上で制御する転送装置である。
【００４７】
図２は、変形例におけるネットワーク管理装置Ｍの機能構成図である。
変形例においてスライス制御部７ｂは、アクセス網４に配置されている。スライス制御部７ｂは、コア網５に具現化された複数のサービススライスを制御する。具体的にいうと、スライス制御部７ｂは、各サービススライスへの単位時間当たり要求量、このサービススライスを本来の振り分け先とする各端末からこのサービススライスへの振り分け量および、これらの端末から代替のサービススライスへの振り分け量を分別して測定する。更にスライス制御部７ｂは、端末からの接続要求を受信した際に、いずれかのサービススライスに端末を接続する。
なお、スライス制御部７ｂは、１台に限定されず、複数台が分散されて配置されていてもよい。それ以外の構成は、図１に示した第１の実施形態と同様である。
【００４８】
図３は、ネットワーク管理装置Ｍの要部を示した機能構成図である。
端末８は、ユースケースＡＰ（アクセスポイント）８１を含んでいる。ここでユースケースとは、例えばブロードバンドアクセス、ＩｏＴ、超低遅延リアルタイム通信、高信頼性通信、ライフラインとしての通信などである。これらユースケースに応じて、効率や遅延量や信頼性やセキュリティの要求基準は全て異なる。よって、コア網５は、仮想的に分割されている。
【００４９】
サービススライス９−１〜９−ｎは、コア網５を仮想的に分割したものであり、ｎは自然数である。サービススライス９−１〜９−ｎは、端末８のユースケースＡＰ８１に合致したものであることが望ましい。これにより、コア網５は、顧客の要求条件に応じたサービスを効率的に提供可能である。以下、サービススライス９−１〜９−ｎを特に区別しないときには、単にサービススライス９と記載する。
【００５０】
スライス制御部７−１，７−２，…は、複数のサービススライス９−１〜９−ｎを制御する。以下、スライス制御部７−１，７−２，…を特に区別しないときには、単にスライス制御部７と記載する。
具体的にいうと、スライス制御部７は、端末８からの接続要求を、いずれかのサービススライス９に振り分ける。スライス制御部７は、先ずは本来のサービススライス９への振り分けを検討し、振り分けが困難な場合に接続要求したユースケースＡＰ８１の要求基準に最も近い性能を有するサービススライス９に振り分けるとよい。
【００５１】
スライス制御部７は、第１スライス振分接続量測定部７１−１〜第ｎスライス振分接続量測定部７１−ｎと、データ送信部７３と、接続容量データ受信部７４とを備える。この第１スライス振分接続量測定部７１−１は、サービススライス９−１への単位時間当たり要求量を測定する。更に第１スライス振分接続量測定部７１−１に含まれる第１スライス代替接続量測定部７２−１は、サービススライス９−１を本来の接続先とする端末８をサービススライス９−１に振り分けたときの単位時間当たり要求量、および、これら端末８を代替のサービススライス９に振り分けたときの単位時間当たり要求量を分別して測定する。
以下、サービススライス９−１を本来の接続先とする端末８による単位時間当たり要求量を、この端末８から本来のサービススライス９−１への振り分け量と記載する場合がある。これら端末８を代替のサービススライス９に振り分けたときの単位時間当たり要求量を、この端末８から代替のサービススライス９への振り分け量と記載する場合がある。
【００５２】
以降、第ｎスライス振分接続量測定部７１−ｎも同様に、サービススライス９−ｎへの単位時間当たり要求量を測定する。更に第ｎスライス振分接続量測定部７１−ｎに含まれる第ｎスライス代替接続量測定部７２−ｎも、サービススライス９−ｎを本来の接続先とする端末８をサービススライス９−ｎに振り分けたときの単位時間当たり要求量、および、これら端末８を代替のサービススライス９に振り分けたときの単位時間当たり要求量を分別して測定する。
【００５３】
第１スライス振分接続量測定部７１−１〜第ｎスライス振分接続量測定部７１−ｎによって測定されたデータは、データ送信部７３によってパフォーマンスマネージャ６に送信される。更に接続容量データ受信部７４は、パフォーマンスマネージャ６によって分析されたサービススライス９−１〜９−ｎの接続容量データを受信する。
【００５４】
パフォーマンスマネージャ６は、サービススライス９−１〜９−ｎのパフォーマンスを管理するものである。このパフォーマンスマネージャ６は、データ受信部６１、時系列データ蓄積部６２、サービススライス接続容量分析部６３、接続容量データ送信部６４を備える。
データ受信部６１は、スライス制御部７が測定したデータを受信する。なお、スライス制御部７−１，７−２のように分割されて配備されている場合には、全てのスライス制御部７−１，７−２から測定データを受信してサービススライス９ごとに合算し、新たな測定データとする。これにより、スライス制御部７が分割配備されていた場合でも、サービススライス９−１〜９−ｎへの単位時間当たり要求量を正しく測定することができる。
時系列データ蓄積部６２は、データ受信部６１が受信し、必要に応じて合算した測定データを時系列に蓄積する。
【００５５】
サービススライス接続容量分析部６３は、時系列データ蓄積部６２に蓄積された時系列データを分析して、各サービススライス９−１〜９−ｎについて、当該サービススライス９から他のサービススライス９への振り分けが始まった時点を特定する。更にサービススライス接続容量分析部６３は、特定した時点における当該サービススライス９のトラフィックを上限として捉え、この上限に対して一定程度の余裕を持たせたトラフィックを、当該サービススライス９の接続容量として捉える。このサービススライス接続容量分析部６３の処理は、後記する図４で更に説明する。
【００５６】
接続容量データ送信部６４は、サービススライス９−１〜９−ｎの接続容量データをインベントリデータベース２９に格納すると共に、スライス制御部７に送信する。この接続容量データ送信部６４の処理は、後記する図４で更に説明する。
インベントリデータベース２９は、接続容量データ送信部６４が送信したサービススライス９−１〜９−ｎの最新の接続容量データを格納する。
【００５７】
図４は、サービススライス接続容量分析部６３と接続容量データ送信部６４の処理を示したフローチャートである。
サービススライス接続容量分析部６３は、例えば所定時間ごとに図４の処理を開始する。
ステップＳ１０〜Ｓ１５において、サービススライス接続容量分析部６３は、全てのサービススライス９−１〜９−ｎについて処理を繰り返す。
処理の繰り返しの最初に、サービススライス接続容量分析部６３は、時系列データ蓄積部６２を参照して、このサービススライス９に係る時系列データを参照する（ステップＳ１１）。
サービススライス接続容量分析部６３は、時系列データ蓄積部６２に蓄積された時系列データを分析して、当該サービススライス９から他のサービススライス９への振り分けが始まった時点を特定する（ステップＳ１２）。更にサービススライス接続容量分析部６３は、特定した時点における当該サービススライス９のトラフィックを上限として捉え（ステップＳ１３）、この上限に対して所定の余裕を持たせたトラフィックを、当該サービススライス９の接続容量として捉える（ステップＳ１４）。
【００５８】
次いでサービススライス接続容量分析部６３は、全てのサービススライス９−１〜９−ｎについて処理を繰り返したか否かを判定する（ステップＳ１５）。サービススライス接続容量分析部６３は、処理を繰り返していないサービススライス９があれば、ステップＳ１０の処理に戻る。サービススライス接続容量分析部６３は、全てのサービススライス９−１〜９−ｎについて処理を繰り返したならば、ステップＳ１６，Ｓ１７の並行処理を行う。
接続容量データ送信部６４は、サービススライス９−１〜９−ｎの接続容量データをスライス制御部７に送信する（ステップＳ１６）。これと並行して、接続容量データ送信部６４は、サービススライス９−１〜９−ｎの接続容量データをインベントリデータベース２９に格納する（ステップＳ１７）。その後、接続容量データ送信部６４は、図４の処理を終了する。
【００５９】
図５は、端末８からサービススライス９への接続動作と、振り分け量データの取得動作と、接続容量の判定動作とを示したシーケンス図である。
ステップＳ２０〜Ｓ２４は、端末８からサービススライス９への接続動作を示している。
ステップＳ２０において、端末８は、スライス制御部７に接続要求を送信する。スライス制御部７は、接続要求が本来のサービススライス９に接続可能か否かを判定する。この接続要求は本来のサービススライス９に接続可能なので、スライス制御部７は、端末８を本来のサービススライス９に接続させる（ステップＳ２１）。
【００６０】
ステップＳ２２において、端末８は、スライス制御部７に接続要求を送信する。スライス制御部７は、端末８を本来のサービススライス９に接続可能か否かを判定する。この接続要求は本来のサービススライス９に接続できないので、スライス制御部７は、代替のサービススライス９を選択（ステップＳ２３）したのち、端末８を代替のサービススライス９に接続させる（ステップＳ２４）。
【００６１】
以下、ステップＳ３０〜Ｓ３３は、測定データの蓄積動作を示している。
スライス制御部７は、サービススライス９への単位時間当たり要求量を測定する（ステップＳ３０）。スライス制御部７は更に、このサービススライス９を本来の振り分け先とする各端末８からこのサービススライス９への振り分け量および、これらの端末８から代替のサービススライス９への振り分け量を分別して測定する（ステップＳ３１）。なお、図面では、ステップＳ３１について“代替接続量測定”と省略して記載している。スライス制御部７は、測定したデータをパフォーマンスマネージャ６に送信する（ステップＳ３２）。
パフォーマンスマネージャ６は、スライス制御部７が測定したデータを受信し（ステップＳ３３）、この測定データを時系列データ蓄積部６２に蓄積する（ステップＳ３４）。
【００６２】
以下、ステップＳ３４〜Ｓ３８の動作により、サービススライス９ごとの最新の接続容量を判定する。この判定処理は、ステップＳ３０〜Ｓ３３の処理とは非同期に行われる。
パフォーマンスマネージャ６は、時系列データ蓄積部６２に対して過去のデータを要求し（ステップＳ３４）、過去の時系列データを受信する（ステップＳ３５）。パフォーマンスマネージャ６は、この時系列データを分析して、サービススライス９ごとの最新の接続容量を判定する（ステップＳ３６）。パフォーマンスマネージャ６は、この接続容量データをスライス制御部７に送信（ステップＳ３７）すると共に、インベントリデータベース２９に格納する（ステップＳ３８）。
【００６３】
本技術がない場合、ネットワーク管理装置Ｍやその管理者は、端末８などのＡＰ（アクセスポイント）から本来の接続先でない代替のサービススライス９への接続を知ることができず、求められるサービス品質基準を満たさないサービスが提供され続ける。
端末８の多くが第１の代替サービススライス９へ振り分けられ、この第１の代替サービススライス９への接続が困難となると、それ以降に接続を要求した端末８は、第２、第３の代替サービススライス９へと振り分けられる。これにより、これら端末８に対して、サービス品質基準から更に大きく乖離したサービスが提供されてしまうおそれがある。
第１の実施形態では、インベントリデータベース２９にサービススライス９ごとの最新の接続容量が格納されている。よって、ネットワーク管理装置Ｍやその管理者は、このような事象に至らないよう、速やかに措置することができる。
【００６４】
《第２の実施形態》
第２の実施形態のネットワーク管理装置Ｍは、本来の接続先のサービススライスについての接続可能条件についても、時系列データとあわせて蓄積する。これにより、本来のネットワークスライス代替サービススライスへの振り分けが行われた各単位時間について、ボトルネックとなった接続可能条件を把握することができる。
【００６５】
図６は、第２の実施形態における、振り分け量データの取得動作と、接続容量の判定動作とを示したシーケンス図である。
ステップＳ５０〜Ｓ５４は、測定データ等の蓄積動作を示している。
スライス制御部７は、サービススライス９への単位時間当たり要求量を測定する（ステップＳ５０）。スライス制御部７は更に、このサービススライス９を本来の振り分け先とする各端末８からこのサービススライス９への振り分け量および、これらの端末８から代替のサービススライス９への振り分け量を分別して測定する（ステップＳ５１）。スライス制御部７は更に、各サービススライス９への接続可能条件を満たすか否かを判定する（ステップＳ５２）。
例えば、第ｉ番目のサービススライス９−ｉ（ｉはｎ以下の自然数）の接続可能条件の集合Ｃiは、以下の式（１）で示される。
【数１】
2019009499.tif 000003
【００６６】
第ｉ番目のサービススライス９−ｉが接続可能条件を満足したか否かの情報Ｖiは、以下の式（２）で示される。以下、サービススライス９が接続可能条件を満足したか否かを判定して得られた情報のことを、単に接続条件判定集合と記載する場合がある。
【数２】
2019009499.tif 000004
【００６７】
スライス制御部７は、測定したデータと接続条件判定集合とをパフォーマンスマネージャ６に送信する（ステップＳ５３）。
パフォーマンスマネージャ６は、スライス制御部７が測定したデータと接続条件判定集合とを受信すると、この測定データと接続条件判定集合とを時系列データ蓄積部６２に蓄積する（ステップＳ５４）。
【００６８】
以下、ステップＳ５５〜Ｓ５９の動作により、サービススライス９ごとの最新の接続容量を判定する。この判定処理は、図５に示したステップＳ３４〜Ｓ３８の処理と同様である。
第２の実施形態のネットワーク管理装置Ｍによれば、時系列データ蓄積部６２にて代替サービススライス９へ接続となった各単位時間について、ボトルネックとなった接続可能条件ｃjの把握が可能となる。
【００６９】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｅ）のようなものがある。
【００７０】
（ａ）  スライス制御部７は、端末８から本来の接続先でない代替サービススライス９への接続が発生したとき、その旨をパフォーマンスマネージャ６に送信してもよい。これにより、時系列データを事後的に分析するよりも早く、代替サービススライス９への接続を検知することができる。
（ｂ）  スライス制御部７は、端末８を本来のサービススライス９に接続できなかった場合、代替サービススライス９を判定して、この代替サービススライス９に接続させる。この代替サービススライス９の判定条件は特に限定されない。例えば、ユースケースごとに本来のサービススライス９と、第１〜第ｎの代替サービススライス９を予め表に定義しておき、定義した表に基づいて代替サービススライス９を判定してもよい。
（ｃ）  スライス制御部７は、パフォーマンスマネージャ６から受信したサービススライス９ごとの接続容量を参照して、端末８を本来のサービススライス９に接続可能か否かを判定してもよい。また、端末８を、どの代替サービススライス９に接続するかを判定してもよい。
（ｄ）  パフォーマンスマネージャ６は、サービススライス９ごとの接続容量データと共に、時系列データ蓄積部６２に格納された接続条件判定集合のデータをインベントリデータベース２９に格納してもよい。
（ｅ）  スライス制御部７は、このサービススライス９を本来の振り分け先とする各端末８からこのサービススライス９への振り分け量を測定しなくてもよい。スライス制御部７は、これら端末８から代替のサービススライス９への振り分け量を測定すればよい。
【符号の説明】
【００７１】
Ｍ  ネットワーク管理装置  （サービススライス性能監視システム）
１  オーケストレータ部
１１  Ｅ２Ｅオーケストレータ
１３  ネットワークリソース・オーケストレータ
１２  サーバリソース・オーケストレータ
２  インフラマネージャ部
２１  ＶＮＦＭ
２２  ＶＩＭ
２５  ＯＳＳ
２６  ＳＤＮマネージャ
２８  テレメトリデータベース
２９  インベントリデータベース
３１  ＮＭＳ
３２  ＥＭＳ
３２ａ  ＰＯＮ−ＥＭＳ
３２ｂ  Ｌ２−ＥＭＳ
３２ｃ  Ｌ３−ＥＭＳ
３３  ＷＩＭ
４  アクセス網
４１  ＰＯＮ
４２  Ｌ２スイッチ
４３  Ｌ３スイッチ
５  コア網
５１，５１ａ，５１ｂ  ＳＤＮ−Ｌ２スイッチ
５２，５２ａ，５２ｂ  データセンタ
５３，５３ａ，５３ｂ  パケット交換システム
５４，５４ａ，５４ｂ  コアルータ
６  パフォーマンスマネージャ
６１  データ受信部
６２  時系列データ蓄積部
６３  サービススライス接続容量分析部
６４  接続容量データ送信部
７，７ａ，７ｂ  スライス制御部
７１−１〜７１−ｎ  スライス振分接続量測定部
７２−１〜７２−ｎ  スライス代替接続量測定部
７３  データ送信部
７４  接続容量データ受信部
８  端末
８１  ユースケースＡＰ
９，９−１〜９−ｎ  サービススライス
【図１】
2019009499.tif 000005
【図２】
2019009499.tif 000006
【図３】
2019009499.tif 000007
【図４】
2019009499.tif 000008
【図５】
2019009499.tif 000009
【図６】
2019009499.tif 000010