WO2024004102A1 - キューに格納されている性能指標値データに基づく通信システムの状態判定 - Google Patents

Abstract

通信システムの状態を妥当に判定できるようにする。データバス部（６８）は、通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成する。ＡＩ部（７０）及びポリシーマネージャ部（９０）は、性能指標値データがキューにエンキューされたことに応じて、キューが格納可能な性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定する。データバス部（６８）は、ＡＩ部（７０）が性能指標値データを取得する頻度よりも少ない頻度で、キューに格納されている性能指標値データのうちの少なくとも一部を含むファイルを生成する。

Description

キューに格納されている性能指標値データに基づく通信システムの状態判定

　本発明は、キューに格納されている性能指標値データに基づく通信システムの状態判定に関する。

　特許文献１には、通信システムに構築されるネットワークファンクション（ＮＦ）を監視する技術が記載されている。

　また、このような監視に用いられる、通信システムに含まれるＮＦなどの要素の性能指標値（例えば、メトリックやＫＰＩ（Key Performance Indicator）など）を示す性能指標値データが記録されたファイルを蓄積するファイル蓄積システムが存在する。このファイル蓄積システムでは、ファイル数が膨大になることを防ぐために、ある程度の長さの期間ごとに、その期間の性能指標値が示されたファイルが生成される。

国際公開第２０２１／１７１２１１号

　しかし、このようなファイルを用いて通信システムの状態を判定した場合、最新のファイルに通信システムの現況の性能が示されているとは限らないため、妥当な判定結果が得られないことがある。

　本発明は上記実情に鑑みてなされたものであって、その目的の一つは、通信システムの状態を妥当に判定できるようにすることにある。

　上記課題を解決するために、本開示に係るファイル生成システムは、通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成するキュー生成手段と、前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定する判定手段と、前記判定手段が前記性能指標値データを取得する頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成するファイル生成手段と、を含む。

　また、本開示に係るファイル生成方法は、通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成することと、前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定することと、前記性能指標値データが取得される頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成することと、を含む。

本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係るネットワークサービスの一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに構築される要素間の関連付けの一例を示す図である。 本発明の一実施形態に係るプラットフォームシステムで実装される機能の一例を示す機能ブロック図である。 物理インベントリデータのデータ構造の一例を示す図である。 本発明の一実施形態に係るデータバス部の一例を模式的に示す図である。 推定プロセスによる性能指標値データの取得の一例を模式的に示す図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。

　以下、本発明の一実施形態について図面に基づき詳細に説明する。

　図１及び図２は、本発明の一実施形態に係る通信システム１の一例を示す図である。図１は、通信システム１に含まれるデータセンタ群のロケーションに着目した図となっている。図２は、通信システム１に含まれるデータセンタ群で実装されている各種のコンピュータシステムに着目した図となっている。

　図１に示すように、通信システム１に含まれるデータセンタ群は、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４に分類される。

　セントラルデータセンタ１０は、例えば、通信システム１がカバーするエリア内（例えば、日本国内）に分散して数個配置されている。

　リージョナルデータセンタ１２は、例えば、通信システム１がカバーするエリア内に分散して数十個配置されている。例えば、通信システム１がカバーするエリアが日本国内全域である場合に、リージョナルデータセンタ１２が、各都道府県に１から２個ずつ配置されてもよい。

　エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。ここで図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（User Equipment）２０との間で無線通信を行う。アンテナ１６を備えた通信設備１８には、例えば、後述のＲＵ（Radio Unit）が設けられている。

　本実施形態に係るセントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４には、それぞれ、複数のサーバが配置されている。

　本実施形態では例えば、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４は、互いに通信可能となっている。また、セントラルデータセンタ１０同士、リージョナルデータセンタ１２同士、エッジデータセンタ１４同士も互いに通信可能になっている。

　図２に示すように、本実施形態に係る通信システム１には、プラットフォームシステム３０、複数の無線アクセスネットワーク（ＲＡＮ）３２、複数のコアネットワークシステム３４、複数のＵＥ２０が含まれている。コアネットワークシステム３４、ＲＡＮ３２、ＵＥ２０は、互いに連携して、移動通信ネットワークを実現する。

　ＲＡＮ３２は、第４世代移動通信システム（以下、４Ｇと呼ぶ。）におけるｅＮＢ（ｅＮｏｄｅＢ）や、第５世代移動通信システム（以下、５Ｇと呼ぶ。）におけるｇＮＢ（ＮＲ基地局）に相当する、アンテナ１６を備えたコンピュータシステムである。本実施形態に係るＲＡＮ３２は、主に、エッジデータセンタ１４に配置されているサーバ群及び通信設備１８によって実装される。なお、ＲＡＮ３２の一部（例えば、ＤＵ（Distributed Unit）、ＣＵ（Central Unit）、ｖＤＵ（virtual Distributed Unit）、ｖＣＵ（virtual Central Unit））は、エッジデータセンタ１４ではなく、セントラルデータセンタ１０やリージョナルデータセンタ１２で実装されてもよい。

　コアネットワークシステム３４は、４ＧにおけるＥＰＣ（Evolved Packet Core）や、５Ｇにおける５Ｇコア（５ＧＣ）に相当するシステムである。本実施形態に係るコアネットワークシステム３４は、主に、セントラルデータセンタ１０やリージョナルデータセンタ１２に配置されているサーバ群によって実装される。

　本実施形態に係るプラットフォームシステム３０は、例えば、クラウド基盤上に構成されており、図２に示すように、プロセッサ３０ａ、記憶部３０ｂ、通信部３０ｃ、が含まれる。プロセッサ３０ａは、プラットフォームシステム３０にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。記憶部３０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）、ハードディスクドライブ（ＨＤＤ）などである。記憶部３０ｂには、プロセッサ３０ａによって実行されるプログラムなどが記憶される。通信部３０ｃは、例えば、ＮＩＣ（Network Interface Controller）や無線ＬＡＮ（Local Area Network）モジュールなどといった通信インタフェースである。なお、通信部３０ｃにおいて、ＳＤＮ（Software-Defined Networking）が実装されていてもよい。通信部３０ｃは、ＲＡＮ３２、コアネットワークシステム３４、との間でデータを授受する。

　本実施形態では、プラットフォームシステム３０は、セントラルデータセンタ１０に配置されているサーバ群によって実装されている。なお、プラットフォームシステム３０が、リージョナルデータセンタ１２に配置されているサーバ群によって実装されていてもよい。

　本実施形態では例えば、購入者によるネットワークサービス（ＮＳ）の購入要求に応じて、購入要求がされたネットワークサービスがＲＡＮ３２やコアネットワークシステム３４に構築される。そして、構築されたネットワークサービスが購入者に提供される。

　例えば、ＭＶＮＯ（Mobile Virtual Network Operator）である購入者に、音声通信サービスやデータ通信サービス等のネットワークサービスが提供される。本実施形態によって提供される音声通信サービスやデータ通信サービスは、図１及び図２に示すＵＥ２０を利用する、購入者（上述の例ではＭＶＮＯ）にとっての顧客（エンドユーザ）に対して最終的に提供されることとなる。当該エンドユーザは、ＲＡＮ３２やコアネットワークシステム３４を介して他のユーザとの間で音声通信やデータ通信を行うことが可能である。また、当該エンドユーザのＵＥ２０は、ＲＡＮ３２やコアネットワークシステム３４を介してインターネット等のデータネットワークにアクセスできるようになっている。

　また、本実施形態において、ロボットアームやコネクテッドカーなどを利用するエンドユーザに対して、ＩｏＴ（Internet of Things）サービスが提供されても構わない。そして、この場合において、例えば、ロボットアームやコネクテッドカーなどを利用するエンドユーザが本実施形態に係るネットワークサービスの購入者となっても構わない。

　本実施形態では、セントラルデータセンタ１０、リージョナルデータセンタ１２、及び、エッジデータセンタ１４に配置されているサーバには、ドッカー（Ｄｏｃｋｅｒ（登録商標））などのコンテナ型の仮想化アプリケーション実行環境がインストールされており、これらのサーバにコンテナをデプロイして稼働させることができるようになっている。これらのサーバにおいて、このような仮想化技術によって生成される１以上のコンテナから構成されるクラスタが構築されてもよい。例えば、クバネテス（Ｋｕｂｅｒｎｅｔｅｓ（登録商標））等のコンテナ管理ツールによって管理されるクバネテスクラスタが構築されていてもよい。そして、構築されたクラスタ上のプロセッサがコンテナ型のアプリケーションを実行してもよい。

　そして本実施形態において購入者に提供されるネットワークサービスは、１又は複数の機能ユニット（例えば、ネットワークファンクション（ＮＦ））から構成される。本実施形態では、当該機能ユニットは、仮想化技術によって実現されたＮＦで実装される。仮想化技術によって実現されたＮＦは、ＶＮＦ（Virtualized Network Function）と称される。なお、どのような仮想化技術によって仮想化されたかは問わない。例えば、コンテナ型の仮想化技術によって実現されたＣＮＦ（Containerized Network Function）も、本説明においてＶＮＦに含まれる。本実施形態では、ネットワークサービスが１又は複数のＣＮＦによって実装されるものとして説明する。また、本実施形態に係る機能ユニットは、ネットワークノードに相当するものであってもよい。

　図３は、稼働中のネットワークサービスの一例を模式的に示す図である。図３に示すネットワークサービスには、複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ４４（ＣＵ－ＣＰ（Central Unit - Control Plane）４４ａ、及び、ＣＵ－ＵＰ（Central Unit - User Plane）４４ｂ）、複数のＡＭＦ（Access and Mobility Management Function）４６、複数のＳＭＦ（Session Management Function）４８、及び、複数のＵＰＦ（User Plane Function）５０などのＮＦがソフトウェア要素として含まれている。

　図３の例では、ＲＵ４０、ＤＵ４２、ＣＵ－ＣＰ４４ａ、ＡＭＦ４６、及び、ＳＭＦ４８が、コントロールプレーン（Ｃ－Ｐｌａｎｅ）の要素に相当し、ＲＵ４０、ＤＵ４２、ＣＵ－ＵＰ４４ｂ、及び、ＵＰＦ５０が、ユーザプレーン（Ｕ－Ｐｌａｎｅ）の要素に相当する。

　なお、当該ネットワークサービスに、他の種類のＮＦがソフトウェア要素として含まれていても構わない。また、ネットワークサービスは、複数のサーバ等のコンピュータリソース（ハードウェア要素）上に実装されている。

　そして、本実施形態では例えば、図３に示すネットワークサービスによって、あるエリアにおける通信サービスが提供される。

　そして、本実施形態では、図３に示す複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ－ＵＰ４４ｂ、及び、複数のＵＰＦ５０が、１つのエンド・ツー・エンドのネットワークスライスに所属していることとする。

　図４は、本実施形態において通信システム１に構築される要素間の関連付けの一例を模式的に示す図である。なお、図４に示された記号Ｍ及びＮは１以上の任意の整数を表し、リンクで接続された要素同士の個数の関係を示す。リンクの両端がＭとＮの組み合わせの場合は、当該リンクで接続された要素同士は多対多の関係であり、リンクの両端が１とＮの組み合わせ又は１とＭの組み合わせの場合は、当該リンクで接続された要素同士は１対多の関係である。

　図４に示すように、ネットワークサービス（ＮＳ）、ネットワークファンクション（ＮＦ）、ＣＮＦＣ（Containerized Network Function Component）、ｐｏｄ、及び、コンテナは、階層構成となっている。

　ＮＳは、例えば、複数のＮＦから構成されるネットワークサービスに相当する。ここで、ＮＳが、例えば、５ＧＣ、ＥＰＣ、５ＧのＲＡＮ（ｇＮＢ）、４ＧのＲＡＮ（ｅＮＢ）、などの粒度の要素に相当するものであってもよい。

　ＮＦは、５Ｇでは、例えば、ＲＵ、ＤＵ、ＣＵ－ＣＰ、ＣＵ－ＵＰ、ＡＭＦ、ＳＭＦ、ＵＰＦなどの粒度の要素に相当する。また、ＮＦは、４Ｇでは、例えば、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、Ｓ－ＧＷ（Serving Gateway）、ｖＤＵ、ｖＣＵなどの粒度の要素に相当する。本実施形態では例えば、１つのＮＳには、１又は複数のＮＦが含まれる。すなわち、１又は複数のＮＦが、１つのＮＳの配下にあることとなる。

　ＣＮＦＣは、例えば、ＤＵ　ｍｇｍｔやＤＵ　Ｐｒｏｃｅｓｓｉｎｇなどの粒度の要素に相当する。ＣＮＦＣは、１つ以上のコンテナとしてサーバにデプロイされるマイクロサービスであってもよい。例えば、あるＣＮＦＣは、ＤＵ、ＣＵ－ＣＰ、ＣＵ－ＵＰ等の機能のうち一部の機能を提供するマイクロサービスであってもよい。また、あるＣＮＦＣは、ＵＰＦ、ＡＭＦ、ＳＭＦ等の機能のうちの一部の機能を提供するマイクロサービスであってもよい。本実施形態では例えば、１つのＮＦには、１又は複数のＣＮＦＣが含まれる。すなわち、１又は複数のＣＮＦＣが、１つのＮＦの配下にあることとなる。

　ｐｏｄは、例えば、クバネテスでドッカーコンテナを管理するための最小単位を指す。本実施形態では例えば、１つのＣＮＦＣには、１又は複数のｐｏｄが含まれる。すなわち、１又は複数のｐｏｄが、１つのＣＮＦＣの配下にあることとなる。

　そして、本実施形態では例えば、１つのｐｏｄには、１又は複数のコンテナが含まれる。すなわち、１又は複数のコンテナが、１つのｐｏｄの配下にあることとなる。

　また、図４に示すように、ネットワークスライス（ＮＳＩ）とネットワークスライスサブネットインスタンス（ＮＳＳＩ）とは階層構成となっている。

　ＮＳＩは、複数ドメイン（例えばＲＡＮ３２からコアネットワークシステム３４）に跨るエンド・ツー・エンドの仮想回線とも言える。ＮＳＩは、高速大容量通信用のスライス（例えば、ｅＭＢＢ：enhanced Mobile Broadband用）、高信頼度かつ低遅延通信用のスライス（例えば、ＵＲＬＬＣ:Ultra-Reliable and Low Latency Communications用）、又は、大量端末の接続用のスライス（例えば、ｍＭＴＣ：massive Machine Type Communication用）であってもよい。ＮＳＳＩは、ＮＳＩを分割した単一ドメインの仮想回線とも言える。ＮＳＳＩは、ＲＡＮドメインのスライス、ＭＢＨ（Mobile Back Haul）ドメイン等のトランスポートドメインのスライス、又は、コアネットワークドメインのスライスであってもよい。

　本実施形態では例えば、１つのＮＳＩには、１又は複数のＮＳＳＩが含まれる。すなわち、１又は複数のＮＳＳＩが、１つのＮＳＩの配下にあることとなる。なお、本実施形態において、複数のＮＳＩが同じＮＳＳＩを共有してもよい。

　また、図４に示すように、ＮＳＳＩとＮＳとは、一般的には、多対多の関係となる。

　また、本実施形態では例えば、１つのＮＦは、１又は複数のネットワークスライスに所属できるようになっている。具体的には例えば、１つのＮＦには、１又は複数のＳ－ＮＳＳＡＩ（Sub Network Slice Selection Assist Information）を含むＮＳＳＡＩ（Network Slice Selection Assistance Information）を設定できるようになっている。ここで、Ｓ－ＮＳＳＡＩは、ネットワークスライスに対応付けられる情報である。なお、ＮＦが、ネットワークスライスに所属していなくてもよい。

　図５は、本実施形態に係るプラットフォームシステム３０で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係るプラットフォームシステム３０で、図５に示す機能のすべてが実装される必要はなく、また、図５に示す機能以外の機能が実装されていても構わない。

　図５に示すように、本実施形態に係るプラットフォームシステム３０には、機能的には例えば、オペレーションサポートシステム（ＯＳＳ）部６０、オーケストレーション（Ｅ２ＥＯ：End-to-End-Orchestration）部６２、サービスカタログ記憶部６４、ビッグデータプラットフォーム部６６、データバス部６８、ＡＩ（Artificial Intelligence）部７０、監視機能部７２、ＳＤＮコントローラ７４、構成管理部７６、コンテナ管理部７８、リポジトリ部８０、が含まれている。そして、ＯＳＳ部６０には、インベントリデータベース８２、チケット管理部８４、障害管理部８６、性能管理部８８、が含まれている。そして、Ｅ２ＥＯ部６２には、ポリシーマネージャ部９０、スライスマネージャ部９２、ライフサイクル管理部９４、が含まれている。これらの要素は、プロセッサ３０ａ、記憶部３０ｂ、及び、通信部３０ｃを主として実装される。

　図５に示す機能は、１又は複数のコンピュータであるプラットフォームシステム３０にインストールされ、当該機能に対応する指令を含むプログラムをプロセッサ３０ａが実行することにより、実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してプラットフォームシステム３０に供給されてもよい。また、図５に示す機能が、回路ブロック、メモリ、その他のＬＳＩで実装されてもよい。また、図５に示す機能が、ハードウェアのみ、ソフトウェアのみ、又はそれらの組合せといった様々な形態で実現できることは、当業者には理解されるところである。

　コンテナ管理部７８は、コンテナのライフサイクル管理を実行する。例えば、コンテナのデプロイや設定などといったコンテナの構築に関する処理が当該ライフサイクル管理に含まれる。

　ここで、本実施形態に係るプラットフォームシステム３０に、複数のコンテナ管理部７８が含まれていてもよい。そして、複数のコンテナ管理部７８のそれぞれには、クバネテス等のコンテナ管理ツール、及び、ヘルム（Ｈｅｌｍ）等のパッケージマネージャがインストールされていてもよい。そして、複数のコンテナ管理部７８は、それぞれ、当該コンテナ管理部７８に対応付けられるサーバ群（例えばクバネテスクラスタ）に対して、コンテナのデプロイ等のコンテナの構築を実行してもよい。

　なお、コンテナ管理部７８は、プラットフォームシステム３０に含まれている必要はない。コンテナ管理部７８は、例えば、当該コンテナ管理部７８によって管理されるサーバ（すなわち、ＲＡＮ３２やコアネットワークシステム３４）に設けられていてもよいし、あるいは、当該コンテナ管理部７８によって管理されるサーバに併設されている他のサーバに設けられていてもよい。

　リポジトリ部８０は、本実施形態では例えば、ネットワークサービスを実現する機能ユニット群（例えば、ＮＦ群）に含まれるコンテナのコンテナイメージを記憶する。

　インベントリデータベース８２は、インベントリ情報が格納されたデータベースである。当該インベントリ情報には、例えば、ＲＡＮ３２やコアネットワークシステム３４に配置され、プラットフォームシステム３０で管理されているサーバについての情報が含まれる。

　また本実施形態では、インベントリデータベース８２には、インベントリデータが記憶されている。インベントリデータには、通信システム１に含まれる要素群の構成や要素間の関連付けの現況が示されている。また、インベントリデータには、プラットフォームシステム３０で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。当該インベントリデータは、物理インベントリデータでもよいし、論理インベントリデータでもよい。物理インベントリデータ及び論理インベントリデータについては後述する。

　図６は、物理インベントリデータのデータ構造の一例を示す図である。図６に示す物理インベントリデータは、１つのサーバに対応付けられる。図６に示す物理インベントリデータには、例えば、サーバＩＤ、ロケーションデータ、建物データ、階数データ、ラックデータ、スペックデータ、ネットワークデータ、稼働コンテナＩＤリスト、クラスタＩＤ、などが含まれる。

　物理インベントリデータに含まれるサーバＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバの識別子である。

　物理インベントリデータに含まれるロケーションデータは、例えば、当該物理インベントリデータに対応付けられるサーバのロケーション（例えばロケーションの住所）を示すデータである。

　物理インベントリデータに含まれる建物データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている建物（例えば建物名）を示すデータである。

　物理インベントリデータに含まれる階数データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている階数を示すデータである。

　物理インベントリデータに含まれるラックデータは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されているラックの識別子である。

　物理インベントリデータに含まれるスペックデータは、例えば、当該物理インベントリデータに対応付けられるサーバのスペックを示すデータであり、スペックデータには、例えば、コア数、メモリ容量、ハードディスク容量などといったものが示される。

　物理インベントリデータに含まれるネットワークデータは、例えば、当該物理インベントリデータに対応付けられるサーバのネットワークに関する情報を示すデータであり、ネットワークデータには、例えば、当該サーバが備えるＮＩＣ、当該ＮＩＣが備えるポートの数、当該ポートのポートＩＤなどが示される。

　物理インベントリデータに含まれる稼働コンテナＩＤリストは、例えば、当該物理インベントリデータに対応付けられるサーバで稼働する１又は複数のコンテナに関する情報を示すデータであり、稼働コンテナＩＤリストには、例えば、当該コンテナのインスタンスの識別子（コンテナＩＤ）のリストが示される。

　物理インベントリデータに含まれるクラスタＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバが所属するクラスタ（例えば、クバネテスクラスタ）の識別子である。

　論理インベントリデータには、通信システム１に含まれる複数の要素についての、図４に示されているような要素間の関連付けの現況を示すトポロジーデータが含まれている。例えば、論理インベントリデータには、あるＮＳの識別子と当該ＮＳの配下にある１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。また、例えば、論理インベントリデータには、あるネットワークスライスの識別子と当該ネットワークスライスに所属する１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。

　また、インベントリデータに、通信システム１に含まれる要素間の地理的な関係やトポロジー的な関係などの現況が示すデータが含まれていてもよい。上述の通り、インベントリデータには、通信システム１に含まれる要素が稼働しているロケーション、すなわち、通信システム１に含まれる要素の現在のロケーションを示すロケーションデータが含まれている。このことから、インベントリデータには、要素間の地理的な関係（例えば、要素間の地理的な近さ）の現況が示されていると言える。

　また、論理インベントリデータに、ネットワークスライスに関する情報を示すＮＳＩデータが含まれていてもよい。ＮＳＩデータは、例えば、ネットワークスライスのインスタンスの識別子や、ネットワークスライスの種類等の属性を示す。また、論理インベントリデータに、ネットワークスライスサブネットに関する情報を示すＮＳＳＩデータが含まれていてもよい。ＮＳＳＩデータは、例えば、ネットワークスライスサブネットのインスタンスの識別子や、ネットワークスライスサブネットの種類等の属性を示す。

　また、論理インベントリデータに、ＮＳに関する情報を示すＮＳデータが含まれていてもよい。ＮＳデータは、例えば、ＮＳのインスタンスの識別子や、ＮＳの種類等の属性を示す。また、論理インベントリデータに、ＮＦに関する情報を示すＮＦデータが含まれていてもよい。ＮＦデータは、例えば、ＮＦのインスタンスの識別子や、ＮＦの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに関する情報を示すＣＮＦＣデータが含まれていてもよい。ＣＮＦＣデータは、例えば、インスタンスの識別子や、ＣＮＦＣの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに含まれるｐｏｄに関する情報を示すｐｏｄデータが含まれていてもよい。ｐｏｄデータは、例えば、ｐｏｄのインスタンスの識別子や、ｐｏｄの種類等の属性を示す。また、論理インベントリデータに、ｐｏｄに含まれるコンテナに関する情報を示すコンテナデータが含まれていてもよい。コンテナデータは、例えば、コンテナのインスタンスのコンテナＩＤや、コンテナの種類等の属性を示す。

　論理インベントリデータに含まれるコンテナデータのコンテナＩＤと、物理インベントリデータに含まれる稼働コンテナＩＤリストに含まれるコンテナＩＤと、によって、コンテナのインスタンスと、当該コンテナのインスタンスが稼働しているサーバとが関連付けられることとなる。

　また、ホスト名やＩＰアドレスなどの各種の属性を示すデータが論理インベントリデータに含まれる上述のデータに含まれていても構わない。例えば、コンテナデータに、当該コンテナデータに対応するコンテナのＩＰアドレスを示すデータが含まれていてもよい。また、例えば、ＮＦデータに、当該ＮＦデータが示すＮＦのＩＰアドレス及びホスト名を示すデータが含まれていてもよい。

　また、論理インベントリデータに、各ＮＦに設定されている、１又は複数のＳ－ＮＳＳＡＩを含むＮＳＳＡＩを示すデータが含まれていてもよい。

　また、インベントリデータベース８２は、コンテナ管理部７８と連携して、リソースの状況を適宜把握できるようになっている。そして、インベントリデータベース８２は、リソースの最新の状況に基づいて、インベントリデータベース８２に記憶されているインベントリデータを適宜更新する。

　また、例えば、通信システム１に含まれる新規要素の構築、通信システム１に含まれる要素の構成変更、通信システム１に含まれる要素のスケーリング、通信システム１に含まれる要素のリプレース、などのアクションが実行されることに応じて、インベントリデータベース８２は、インベントリデータベース８２に記憶されているインベントリデータを更新する。

　また、インベントリデータベース８２に、それぞれのＮＦについて、当該ＮＦが設けられているロケーションの重要度を示すデータが含まれていてもよい。例えば、官公庁、消防署、病院などが含まれるエリアをカバーするｇＮＢのインベントリデータに重要エリアフラグが関連付けられていてもよい。

　また、インベントリデータベース８２に、ＮＳ、ＮＦ、ネットワークスライスなどの要素についての、サービスの重要度を示すデータが含まれていてもよい。例えば、購入者によって、購入対象のＮＳが満たすべきＳＬＡが指定されており、当該ＳＬＡに対応する性能を保証する必要がある要素のインベントリデータには、重要サービスフラグが関連付けられていてもよい。

　サービスカタログ記憶部６４は、サービスカタログデータを記憶する。サービスカタログデータには、例えば、ライフサイクル管理部９４によって利用されるロジックなどを示すサービステンプレートデータが含まれていてもよい。このサービステンプレートデータには、ネットワークサービスを構築するために必要な情報が含まれる。例えば、サービステンプレートデータは、ＮＳ、ＮＦ及びＣＮＦＣを定義する情報と、ＮＳ－ＮＦ－ＣＮＦＣの対応関係を示す情報を含む。また、例えば、サービステンプレートデータは、ネットワークサービスを構築するためのワークフローのスクリプトを含む。

　サービステンプレートデータの一例として、ＮＳＤ（NS Descriptor）が挙げられる。ＮＳＤは、ネットワークサービスに対応付けられるものであり、当該ネットワークサービスに含まれる複数の機能ユニット（例えば複数のＣＮＦ）の種類などが示されている。なお、ＮＳＤに、ＣＮＦ等の機能ユニットの種類ごとについての、当該ネットワークサービスに含まれる数が示されていてもよい。また、ＮＳＤに、当該ネットワークサービスに含まれるＣＮＦに係る、後述するＣＮＦＤのファイル名が示されていてもよい。

　また、サービステンプレートデータの一例として、ＣＮＦＤ（CNF Descriptor）が挙げられる。ＣＮＦＤに、当該ＣＮＦが必要とするコンピュータリソース（例えば、ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。例えば、ＣＮＦＤに、当該ＣＮＦに含まれる複数のコンテナのそれぞれについての、当該コンテナが必要とするコンピュータリソース（ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。

　また、サービスカタログデータに、ポリシーマネージャ部９０によって利用される、算出された性能指標値と比較する閾値（例えば異常検出用閾値）に関する情報が含まれていてもよい。性能指標値については後述する。

　また、サービスカタログデータに、例えば、スライステンプレートデータが含まれていてもよい。スライステンプレートデータには、ネットワークスライスのインスタンス化を実行するために必要な情報が含まれ、例えば、スライスマネージャ部９２によって利用されるロジックが含まれる。

　スライステンプレートデータは、ＧＳＭＡ（GSM Association）（「GSM」は登録商標）が定める「Generic Network Slice Template」の情報を含む。具体的には、スライステンプレートデータは、ネットワークスライスのテンプレートデータ（ＮＳＴ）、ネットワークスライスサブネットのテンプレートデータ（ＮＳＳＴ）、ネットワークサービスのテンプレートデータを含む。また、スライステンプレートデータは、図４に示したような、これらの要素の階層構成を示す情報を含む。

　ライフサイクル管理部９４は、本実施形態では例えば、購入者によるＮＳの購入要求に応じて、購入要求がされた新たなネットワークサービスを構築する。

　ライフサイクル管理部９４は、例えば、購入要求に応じて、購入されるネットワークサービスに対応付けられるワークフローのスクリプトを実行してもよい。そして、このワークフローのスクリプトを実行することで、ライフサイクル管理部９４は、コンテナ管理部７８に、購入される新たなネットワークサービスに含まれるコンテナのデプロイを指示してもよい。そして、コンテナ管理部７８は、当該コンテナのコンテナイメージをリポジトリ部８０から取得して、当該コンテナイメージに対応するコンテナを、サーバにデプロイしてもよい。

　また、ライフサイクル管理部９４は、本実施形態では例えば、通信システム１に含まれる要素のスケーリングやリプレースを実行する。ここで、ライフサイクル管理部９４は、コンテナのデプロイ指示や削除指示をコンテナ管理部７８に出力してもよい。そして、コンテナ管理部７８が、当該指示に従い、コンテナのデプロイやコンテナの削除等の処理を実行してもよい。本実施形態ではライフサイクル管理部９４によって、コンテナ管理部７８のクバネテスのようなツールでは対応できないようなスケーリングやリプレースを実行できるようになっている。

　また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、通信経路の作成指示を出力してもよい。例えば、ライフサイクル管理部９４は、作成させる通信経路の両端の２つのＩＰアドレスをＳＤＮコントローラ７４に提示し、ＳＤＮコントローラ７４は、これら２つのＩＰアドレスを結ぶ通信経路を作成する。作成された通信経路は、これら２つのＩＰアドレスに関連付けられて管理されてもよい。

　また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、２つのＩＰアドレスに関連付けられた、これら２つのＩＰアドレス間の通信経路の作成指示を出力してもよい。

　スライスマネージャ部９２は、本実施形態では例えば、ネットワークスライスのインスタンス化を実行する。スライスマネージャ部９２は、本実施形態では例えば、サービスカタログ記憶部６４に記憶されているスライステンプレートが示すロジックを実行することで、ネットワークスライスのインスタンス化を実行する。

　スライスマネージャ部９２は、例えば、３ＧＰＰ（登録商標）（Third Generation Partnership Project）の仕様書「TS28 533」に記載される、ＮＳＭＦ（Network Slice Management Function）と、ＮＳＳＭＦ（Network Slice Sub-network Management Function）の機能を含んで構成される。ＮＳＭＦは、ネットワークスライスを生成して管理する機能であり、ＮＳＩのマネジメントサービスを提供する。ＮＳＳＭＦは、ネットワークスライスの一部を構成するネットワークスライスサブネットを生成し管理する機能であり、ＮＳＳＩのマネジメントサービスを提供する。

　ここで、スライスマネージャ部９２が、ネットワークスライスのインスタンス化に関係する構成管理指示を構成管理部７６に出力してもよい。そして、構成管理部７６が、当該構成管理指示に従った設定等の構成管理を実行してもよい。

　また、スライスマネージャ部９２は、ＳＤＮコントローラ７４に、２つのＩＰアドレスを提示し、これら２つのＩＰアドレス間の通信経路の作成指示を出力してもよい。

　構成管理部７６は、本実施形態では例えば、ライフサイクル管理部９４やスライスマネージャ部９２から受け付ける構成管理指示に従って、ＮＦ等の要素群の設定等の構成管理を実行する。

　ＳＤＮコントローラ７４は、本実施形態では例えば、ライフサイクル管理部９４又はスライスマネージャ部９２から受け付ける通信経路の作成指示に従って、当該作成指示に関連付けられている２つのＩＰアドレス間の通信経路を作成する。ＳＤＮコントローラ７４は、例えば、フレックスアルゴ（Ｆｌｅｘ　Ａｌｇｏ）などの公知のパス計算手法を用いて、２つのＩＰアドレス間の通信経路を作成してもよい。

　ここで例えば、ＳＤＮコントローラ７４は、セグメントルーティング技術（例えばＳＲｖ６（セグメントルーティングＩＰｖ６））を用いて、通信経路間に存在するアグリゲーションルータや、サーバなどに対して、ＮＳＩやＮＳＳＩを構築してもよい。また、ＳＤＮコントローラ７４は、複数の設定対象のＮＦに対して、共通のＶＬＡＮ（Virtual Local Area Network）を設定するコマンド、及び、当該ＶＬＡＮに設定情報が示す帯域幅や優先度を割り当てるコマンドを発行することにより、それら複数の設定対象のＮＦにわたるＮＳＩ及びＮＳＳＩを生成してもよい。

　なお、ＳＤＮコントローラ７４は、ネットワークスライスを構築することなく、２つのＩＰアドレス間の通信で利用可能な帯域幅の最大値の変更などを実行してもよい。

　本実施形態に係るプラットフォームシステム３０に、複数のＳＤＮコントローラ７４が含まれていてもよい。そして、複数のＳＤＮコントローラ７４は、それぞれ、当該ＳＤＮコントローラ７４に対応付けられるＡＧ等のネットワーク機器群に対して通信経路の作成等の処理を実行してもよい。

　監視機能部７２は、本実施形態では例えば、通信システム１に含まれる要素群を、所与の管理ポリシーに従って監視する。ここで、監視機能部７２は、例えば、ネットワークサービスの購入の際に購入者によって指定される監視ポリシーに従って、要素群を監視してもよい。

　監視機能部７２は、本実施形態では例えば、スライスのレベル、ＮＳのレベル、ＮＦのレベル、ＣＮＦＣのレベル、サーバ等のハードウェアのレベル、などといった、様々なレベルでの監視を実行する。

　監視機能部７２は、例えば、上述の様々なレベルでの監視が行えるよう、メトリックデータを出力するモジュールをサーバ等のハードウェアや通信システム１に含まれるソフトウェア要素に設定してもよい。ここで例えば、ＮＦが、当該ＮＦにおいて測定可能（特定可能）なメトリックを示すメトリックデータを監視機能部７２に出力するようにしてもよい。また、サーバが、当該サーバにおいて測定可能（特定可能）なハードウェアに関するメトリックを示すメトリックデータを監視機能部７２に出力するようにしてもよい。

　また、例えば、監視機能部７２は、サーバに、複数のコンテナから出力されたメトリックを示すメトリックデータをＣＮＦＣ（マイクロサービス）単位に集計するサイドカーコンテナをデプロイしてもよい。このサイドカーコンテナは、エクスポーターと呼ばれるエージェントを含んでもよい。監視機能部７２は、クバネテス等のコンテナ管理ツールを監視可能なプロメテウス（Prometheus）などのモニタリングツールの仕組みを利用して、マイクロサービス単位に集計されたメトリックデータをサイドカーコンテナから取得する処理を、所与の監視間隔で繰り返し実行してもよい。

　監視機能部７２は、例えば、「TS 28.552, Management and orchestration; 5G performance measurements」又は「TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)」に記載された性能指標についての性能指標値を監視してもよい。そして、監視機能部７２は、監視される性能指標値を示すメトリックデータを取得してもよい。

　そして、監視機能部７２は、本実施形態では、例えば、所定の集計単位で、メトリックデータを集計する処理（エンリッチメント）を実行することで、当該集計単位における、通信システム１に含まれる要素の性能指標値を示す性能指標値データを生成する。

　例えば、１つのｇＮＢについて、当該ｇＮＢの配下にある要素（例えば、ＤＵ４２やＣＵ４４などのネットワークノード）のメトリックを示すメトリックデータを集計することで、当該ｇＮＢの性能指標値データを生成する。このようにして、当該ｇＮＢがカバーするエリアにおける通信性能を示す性能指標値データが生成される。ここで、例えば、各ｇＮＢにおいて、トラフィック量（スループット）やレイテンシなどといった複数種類の通信性能を示す性能指標値データが生成されてもよい。なお、性能指標値データが示す通信性能は、トラフィック量やレイテンシには限定されない。

　そして、監視機能部７２は、上述のエンリッチメントによって生成される性能指標値データを、データバス部６８に出力する。

　データバス部６８は、本実施形態では例えば、監視機能部７２から出力される性能指標値データを受け付ける。そして、データバス部６８は、受け付ける１又は複数の性能指標値データに基づいて、当該１又は複数の性能指標値データを含む性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。

　また、通信システム１に含まれるネットワークスライス、ＮＳ、ＮＦ、ＣＮＦＣ等の要素や、サーバ等のハードウェアは、監視機能部７２に、各種のアラートの通知（例えば、障害の発生をトリガとしたアラートの通知）を行う。

　そして、監視機能部７２は、例えば、上述のアラートの通知を受け付けると、当該通知を示すアラートメッセージデータをデータバス部６８に出力する。そして、データバス部６８は、１又は複数の通知を示すアラートメッセージデータを１つのファイルにまとめたアラートファイルを生成して、当該アラートファイルをビッグデータプラットフォーム部６６に出力する。

　ビッグデータプラットフォーム部６６は、本実施形態では例えば、データバス部６８から出力される性能指標値ファイルやアラートファイルを蓄積する。

　ＡＩ部７０には、本実施形態では例えば、学習済の機械学習モデルが予め複数記憶されている。ＡＩ部７０は、ＡＩ部７０に記憶されている各種の機械学習モデルを用いて、通信システム１の利用状況やサービス品質の将来予測処理などの推定処理を実行する。ＡＩ部７０は、推定処理の結果を示す推定結果データを生成してもよい。

　ＡＩ部７０は、ビッグデータプラットフォーム部６６に蓄積されるファイルと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、長期的なトレンドの予測を低頻度で行う場合に好適である。

　また、ＡＩ部７０は、データバス部６８に格納されている性能指標値データを取得可能になっている。ＡＩ部７０は、データバス部６８に格納されている性能指標値データと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、短期的な予測を高頻度で行う場合に好適である。

　性能管理部８８は、本実施形態では例えば、複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、ＫＰＩ）を算出する。性能管理部８８は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してもよい。性能管理部８８は、総合評価である性能指標値を示す総合性能指標値データを生成してもよい。

　なお、性能管理部８８は、ビッグデータプラットフォーム部６６から上述の性能指標値ファイルを取得してもよい。また、性能管理部８８は、ＡＩ部７０から推定結果データを取得してもよい。そして、性能指標値ファイル又は推定結果データのうちの少なくとも一方に基づいて、ＫＰＩ等の性能指標値を算出してもよい。なお、性能管理部８８が、監視機能部７２からメトリックデータを直接取得してもよい。そして、当該メトリックデータに基づいて、ＫＰＩ等の性能指標値を算出してもよい。

　障害管理部８６は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の推定結果データ、上述の総合性能指標値データのうちの少なくともいずれかに基づいて、通信システム１における障害の発生を検出する。障害管理部８６は、例えば、所定のロジックに基づいて、単一のメトリックデータや単一のアラートの通知からでは検出できないような障害の発生を検出してもよい。障害管理部８６は、検出された障害を示す検出障害データを生成してもよい。

　なお、障害管理部８６は、メトリックデータやアラートの通知を、監視機能部７２から直接取得してもよい。また、障害管理部８６は、ビッグデータプラットフォーム部６６から性能指標値ファイルやアラートファイルを取得してもよい。また、障害管理部８６は、データバス部６８から、アラートメッセージデータを取得してもよい。

　ポリシーマネージャ部９０は、本実施形態では例えば、上述のメトリックデータ、上述の性能指標値データ、上述のアラートメッセージデータ、上述の性能指標値ファイル、上述のアラートファイル、上述の推定結果データ、上述の総合性能指標値データ、上述の検出障害データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。

　そして、ポリシーマネージャ部９０は、判定処理の結果に応じたアクションを実行してもよい。例えば、ポリシーマネージャ部９０は、スライスマネージャ部９２にネットワークスライスの構築指示を出力してもよい。また、ポリシーマネージャ部９０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示をライフサイクル管理部９４に出力してもよい。

　本実施形態に係るポリシーマネージャ部９０は、データバス部６８に格納されている性能指標値データを取得可能になっている。そして、ポリシーマネージャ部９０は、データバス部６８から取得される性能指標値データに基づいて、所定の判定処理を実行してもよい。また、ポリシーマネージャ部９０は、データバス部６８に格納されているアラートメッセージデータに基づいて、所定の判定処理を実行してもよい。

　チケット管理部８４は、本実施形態では例えば、通信システム１の管理者に通知すべき内容が示されたチケットを生成する。チケット管理部８４は、発生障害データの内容を示すチケットを生成してもよい。また、チケット管理部８４は、性能指標値データやメトリックデータの値を示すチケットを生成してもよい。また、チケット管理部８４は、ポリシーマネージャ部９０による判定結果を示すチケットを生成してもよい。

　そして、チケット管理部８４は、生成されたチケットを、通信システム１の管理者に通知する。チケット管理部８４は、例えば、生成されたチケットが添付された電子メールを、通信システム１の管理者の電子メールアドレスに宛てて送信してもよい。

　以下、データバス部６８における性能指標値ファイルの生成、及び、ＡＩ部７０によるデータバス部６８に格納されている性能指標値データに基づく推定処理について、さらに説明する。

　図７は、本実施形態に係るデータバス部６８の一例を模式的に示す図である。図７に示すように、本実施形態に係るデータバス部６８には、例えば、性能指標値データを先入れ先出しのリスト構造で保持するキュー１００が複数含まれている。

　そして、それぞれのキュー１００は、第１キュー群１０２ａ、又は、第２キュー群１０２ｂのいずれかに属している。

　また、本実施形態では例えば、監視機能部７２において、複数の集計プロセス１０４が動作している。それぞれの集計プロセス１０４には、当該集計プロセス１０４での集計対象である要素が予め設定されている。例えば、それぞれの集計プロセス１０４には、当該集計プロセス１０４での集計対象であるｇＮＢが予め設定されている。そして、それぞれの集計プロセス１０４は、当該集計プロセス１０４での集計対象でのｇＮＢの配下にあるＮＦ（例えば、ＲＵ４０、ＤＵ４２、及び、ＣＵ－ＵＰ４４ｂ）からメトリックデータを取得する。そして、当該集計プロセス１０４は、取得するメトリックデータに基づいて、当該ｇＮＢの通信性能を示す性能指標値データを生成するエンリッチメント処理を実行する。

　また、本実施形態では例えば、集計プロセス１０４とキュー１００とが予め関連付けられている。なお、便宜上、図７では、集計プロセス１０４とキュー１００とが１対１の関係で関連付けられていることが示されているが、集計プロセス１０４とキュー１００とが多対多の関係で関連付けられていてもよい。

　以下、第１キュー群１０２ａに含まれるキュー１００に関連付けられている集計プロセス１０４を、第１群集計プロセス１０４ａと呼ぶこととする。また、第２キュー群１０２ｂに含まれるキュー１００に関連付けられている集計プロセス１０４を、第２群集計プロセス１０４ｂと呼ぶこととする。

　そして、それぞれの第１群集計プロセス１０４ａが、所定の時間間隔で（例えば、１分おきに）、当該第１群集計プロセス１０４ａに対応付けられる、前回の集計から現時点までのメトリックデータを集計することで、性能指標値データを生成する。

　第１群集計プロセス１０４ａは、例えば、１分間隔で、当該第１群集計プロセス１０４ａに対応付けられる１又は複数のＮＦからメトリックデータを取得する。そして、当該第１群集計プロセス１０４ａは、同じ集計期間のメトリックデータを集計することで、当該集計期間における性能指標値データを生成する。

　そして、当該第１群集計プロセス１０４ａは、性能指標値データを生成する度に、当該第１群集計プロセス１０４ａに関連付けられている１又は複数のキュー１００に、当該性能指標値データをエンキューする。

　そして、それぞれの第２群集計プロセス１０４ｂが、所定の時間間隔で（例えば、１５分おきに）、当該第２群集計プロセス１０４ｂに対応付けられる、前回の集計から現時点までのメトリックデータを集計することで、性能指標値データを生成する。

　第２群集計プロセス１０４ｂは、例えば、１５分間隔で、当該第２群集計プロセス１０４ｂに対応付けられる１又は複数のＮＦからメトリックデータを取得する。そして、当該第２群集計プロセス１０４ｂは、同じ集計期間のメトリックデータを集計することで、当該集計期間における性能指標値データを生成する。

　そして、当該第２群集計プロセス１０４ｂは、性能指標値データを生成する度に、当該第２群集計プロセス１０４ｂに関連付けられている１又は複数のキュー１００に、当該性能指標値データをエンキューする。

　本実施形態では、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数は予め定められている。ここでは例えば、最大で６０個の性能指標値データがキュー１００に格納可能であることとする。つまり、最大数は「６０」とする。

　また、本実施形態では、第２キュー群１０２ｂに含まれるキュー１００に格納可能な性能指標値データの最大数は予め定められている。ここでは例えば、最大で４個の性能指標値データがキュー１００に格納可能であることとする。つまり、最大数は「４」とする。

　本実施形態において、例えば、ある１つのＮＦが、第１群集計プロセス１０４ａにも第２群集計プロセス１０４ｂにも関連付けられていてもよい。そして、当該ＮＦが、当該第１群集計プロセス１０４ａには、当該第１群集計プロセス１０４ａにおいて集計される種類のメトリックデータを１分間隔で出力してもよい。そして、当該ＮＦが、当該第２群集計プロセス１０４ｂには、当該第２群集計プロセス１０４ｂにおいて集計される種類のメトリックデータを１５分間隔で出力してもよい。

　当該第１群集計プロセス１０４ａに出力されるメトリックデータの種類と、当該第２群集計プロセス１０４ｂに出力されるメトリックデータの種類とは、同じであってもよいし異なっていてもよい。

　ここで例えば、当該ＮＦにおいて監視されるべきメトリックのうち、リアルタイムでの監視がされることが望ましい一部のメトリックについてのメトリックデータが、第１群集計プロセス１０４ａに出力されるようにしてもよい。

　そして、本実施形態では例えば、ＡＩ部７０において、複数の推定プロセス１０６（図８参照）が動作している。これらの推定プロセス１０６のうちの一部は、データバス部６８に格納されている性能指標値データに基づく推定処理を実行し、残りは、ビッグデータプラットフォーム部６６に格納されているファイルに基づく推定処理を実行する。

　また、本実施形態では例えば、推定プロセス１０６とキュー１００とが予め関連付けられている。なお、便宜上、図８では、推定プロセス１０６とキュー１００とが１対１の関係で関連付けられていることが示されているが、推定プロセス１０６とキュー１００とが多対多の関係で関連付けられていてもよい。

　そして本実施形態では例えば、それぞれの推定プロセス１０６が、当該推定プロセス１０６に対応する、第１キュー群１０２ａに含まれるキュー１００に格納されている性能指標値データを取得する。そして、当該推定プロセスは、当該性能指標値データに基づいて、当該推定プロセス１０６において予め定められている推定処理を実行する。

　ここで、推定プロセス１０６は、例えば、性能指標値データが、第１キュー群１０２ａに含まれるキュー１００にエンキューされたことに応じて、当該キュー１００が格納可能な性能指標値データの最大数よりも少ない数の、キュー１００に格納されている性能指標値データのうちの最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得する。

　なお、本実施形態では、第１キュー群１０２ａに含まれるキュー１００については、当該キュー１００に含まれるいずれの性能指標値データにも、デキューすることなくアクセスできるように（取得できるように）になっている。

　ここで例えば、データバス部６８は、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、当該キュー１００に関連付けられている１又は複数の推定プロセス１０６に、性能指標値データがエンキューされたことを示す通知を出力してもよい。

　そして、当該通知を受け付けた推定プロセス１０６が、当該通知の受付に応じて、当該キュー１００が格納可能な性能指標値データの最大数よりも少ない数の、キュー１００に格納されている性能指標値データのうちの当該最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得してもよい。

　ここでは例えば、図８に示されている推定プロセス１０６は、最新の性能指標値データを含む、１５個の推定指標値データを取得する。これらの性能指標値データは、最新の性能指標値データを含む直近１５分の性能指標値データに相当する。そして、当該推定プロセス１０６は、当該性能指標値データに基づいて、推定処理を実行する。

　なお、推定プロセス１０６は、上述のようにキュー１００に格納されている性能指標値データのうちの一部だけを取得する必要はなく、キュー１００に格納されているすべての性能指標値データを取得してもよい。

　そして、ポリシーマネージャ部９０が、推定プロセス１０６が取得する性能指標値データに基づいて、通信システム１の状態を判定する。ここで、ポリシーマネージャ部９０が、推定プロセス１０６による推定結果に基づいて、通信システム１の状態を判定してもよい。ここで、例えば、通信システム１に含まれる、推定プロセス１０６に対応付けられる要素の状態が判定されてもよい。

　また、データバス部６８は、本実施形態では例えば、ＡＩ部７０が性能指標値データを取得する頻度よりも少ない頻度で、キュー１００に格納されている性能指標値データのうちの少なくとも一部を含む性能指標値ファイルを生成する。

　例えば、データバス部６８が、所定の時間間隔で、性能指標値ファイルが前回生成されたタイミングより後に当該キュー１００に格納された性能指標値データを含む性能指標値ファイルを生成してもよい。

　ここで、当該時間間隔は、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数に相当する時間（上述の例では６０分）と一致していてもよいし、一致していなくてもよい。

　また、例えば、データバス部６８が、生成された性能指標値ファイルに含まれる性能指標値データがすべてデキューされたことに応じて、当該キュー１００に格納されているすべての性能指標値データを含むファイルを生成してもよい。すなわち、キュー１００に格納されている性能指標値データがすべて入れ替わったことに応じて、当該キュー１００に格納されているすべての性能指標値データを含むファイルが生成されてもよい。

　また、本実施形態では、第１キュー群１０２ａに含まれるキュー１００に６０個の性能指標値データが格納されている際に、新たな性能指標値データがエンキューされると、当該キュー１００に格納されている最も古い性能指標値データがデキューされる。すなわち、当該キュー１００に格納されている最も古い性能指標値データは、当該キュー１００から消去される。

　なお、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数は、６０個には限定されない。例えば、第１キュー群１０２ａに含まれるキュー１００に格納可能な性能指標値データの最大数が１８０個であっても構わない。そしてこの場合に、３時間間隔で、性能指標値ファイルが生成されるようにしてもよい。

　そして、本実施形態では、第２キュー群１０２ｂに含まれるキュー１００に４個の性能指標値データが格納されると、データバス部６８は、これら４個の性能指標値データを１つのファイルにまとめた性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。

　そして、データバス部６８は、当該キュー１００に格納されているすべての性能指標値データをデキューする。すなわち、当該キュー１００に格納されているすべての性能指標値データは、当該キュー１００から消去される。

　このように、第１キュー群１０２ａに含まれるキュー１００と、第２キュー群１０２ｂに含まれるキュー１００とでは、性能指標値ファイルが生成されたことに応じて実行される処理が異なる。第２キュー群１０２ｂに含まれるキュー１００では、性能指標値ファイルの生成に応じて、当該キュー１００に格納されているすべての性能指標値データが当該キュー１００から消去される。一方で、第１キュー群１０２ａに含まれるキュー１００では、性能指標値ファイルの生成に応じたデキューは実行されない。

　また、本実施形態において、ポリシーマネージャ部９０が、性能指標値データが、第１キュー群１０２ａに含まれるキュー１００にエンキューされたことに応じて、当該キュー１００が格納可能な性能指標値データの最大数よりも少ない数の、キュー１００に格納されている性能指標値データのうちの最新の性能指標値データを少なくとも含む直近所定数又は直近所定期間の性能指標値データを取得してもよい。そして、ポリシーマネージャ部９０が、取得される性能指標値データに基づいて、通信システム１の状態を判定してもよい。

　例えば、推定結果データが示す、あるｇＮＢにおけるトラフィック量の予測値が、所定値よりも小さい場合に、ポリシーマネージャ部９０は、ライフサイクル管理部９４に、リソースブロックの割当てを増やすように指示してもよい。そして、当該ｇＮＢについてのリソースブロックの割当てが増えるようにしてもよい。また、推定結果データが示す、あるｇＮＢにおけるトラフィック量の予測値が、所定値よりも小さい場合に、ポリシーマネージャ部９０は、ライフサイクル管理部９４に、当該ｇＮＢのスケールアウトを指示してもよい。そして、当該ｇＮＢの配下にある要素がスケールアウトされるようにしてもよい。

　本実施形態において、データバス部６８が、適宜、性能指標値データが格納されるキュー１００を生成してもよい。また、監視機能部７２が、適宜、性能指標値データが格納されるキュー１００を生成してもよい。また、ＡＩ部７０が、適宜、性能指標値データが格納されるキュー１００を生成してもよい。

　以上で説明したように、本実施形態に係るプラットフォームシステム３０には、性能指標値データがキュー１００にエンキューされたことに応じて、当該キュー１００が格納可能な性能指標値データの最大数よりも少ない数の、少なくともキュー１００に格納されている性能指標値データのうちの最新の性能指標値データを含む直近所定数又は直近所定期間の性能指標値データを取得して、当該性能指標値データに基づいて通信システム１の状態を判定する判定部が含まれる。ここで例えば、上述の推定プロセス１０６とポリシーマネージャ部９０とが全体として当該判定部に相当してもよい。また、ポリシーマネージャ部９０が当該判定部に相当してもよい。

　また、本実施形態に係るプラットフォームシステム３０には、上述の判定部が性能指標値データを取得する頻度よりも少ない頻度で、キュー１００に格納されている性能指標値データのうちの少なくとも一部を含むファイルを生成するファイル生成部が含まれる。上述の例では、データバス部６８が当該ファイル生成部に相当する。

　ビッグデータプラットフォーム部６６に格納されるファイルに基づいて、通信システム１の状態を判定した場合、最新のファイルには最新の性能指標値データが含まれているとは限らない。そのため、当該ファイルに基づいて、通信システム１の状態を判定すると、妥当な判定結果が得られないことがある。

　本実施形態では以上で説明したように、キューに格納されている性能指標値データのうちの最新の性能指標値データを少なくとも含む、直近所定数又は直近所定期間の性能指標値データに基づいて、通信システム１の状態が判定される。このようにして本実施形態によれば、通信システム１の状態を妥当に判定できることとなる。

　ここで、本実施形態に係るプラットフォームシステム３０で行われる、通信システム１の状態判定に関する処理の流れの一例を、図９に例示するフロー図を参照しながら説明する。

　本処理例では、データバス部６８が、第１キュー群１０２ａに含まれるキュー１００のそれぞれについて、性能指標値データがエンキューされることを監視する（Ｓ１０１）。

　キュー１００に対する性能指標値データのエンキューが検出されると、データバス部６８は、当該キュー１００に関連付けられている推定プロセス１０６に、性能指標値データがエンキューされたことを示す通知を出力する（Ｓ１０２）。

　当該通知を受け付けた推定プロセス１０６は、当該キュー１００に格納されている、最新の性能指標値データを含む直近所定数又は直近所定期間の性能指標値データを取得する（Ｓ１０３）。

　そして、当該推定プロセス１０６は、Ｓ１０３に示す処理で取得された性能指標値データに基づいて、所定の推定処理を実行して、推定結果データを生成する（Ｓ１０４）。

　そして、当該推定プロセス１０６は、Ｓ１０４に示す処理で生成された推定結果データをポリシーマネージャ部９０に出力する（Ｓ１０５）。

　当該推定結果データを受け付けたポリシーマネージャ部９０は、当該推定結果に基づく判定処理を実行する（Ｓ１０６）。

　本処理例では例えば、第１キュー群１０２ａに含まれるキュー１００に性能指標値データがエンキューされたことに応じて、Ｓ１０２～Ｓ１０５に示す処理が実行されることとなる。

　次に、本実施形態に係るプラットフォームシステム３０で行われる、第１キュー群１０２ａに係る性能指標値ファイルの生成に関する処理の流れの一例を、図１０に例示するフロー図を参照しながら説明する。

　データバス部６８は、第１キュー群１０２ａに含まれるキュー１００のいずれかが所定の条件を満たすまで待機する（Ｓ２０１）。

　あるキュー１００が所定の条件を満たしたら、データバス部６８は、当該キュー１００に格納されている性能指標値データのうちの少なくとも一部を含む性能指標値ファイルを生成して（Ｓ２０２）、Ｓ２０１に戻る。

　次に、本実施形態に係るプラットフォームシステム３０で行われる、第２キュー群１０２ｂに係る性能指標値ファイルの生成に関する処理の流れの一例を、図１１に例示するフロー図を参照しながら説明する。

　データバス部６８は、第２キュー群１０２ｂに含まれるキュー１００のいずれかが所定の条件を満たすまで待機する（Ｓ３０１）。

　あるキュー１００が所定の条件を満たしたら、データバス部６８は、当該キュー１００に格納されている性能指標値データのうちの少なくとも一部を含む性能指標値ファイルを生成する（Ｓ３０２）。

　そして、データバス部６８は、当該キュー１００に格納されているすべての性能指標値データを当該キュー１００から消去して（Ｓ３０３）、Ｓ３０１に示す処理に戻る。

　なお、Ｓ３０３に示す処理において、データバス部６８は、当該キュー１００に格納されているすべての性能指標値データをデキューすることで、当該キュー１００に格納されているすべての性能指標値データを当該キュー１００から消去してもよい。

　また、本処理例において、データバス部６８が、当該キュー１００に格納されているすべての性能指標値データをデキューによって消去してから、デキューされた性能指標値データに基づいて、性能指標値ファイルを生成してもよい。

　なお、本発明は上述の実施形態に限定されるものではない。

　本発明の適用範囲は、ｇＮＢのようなＲＡＮ３２の要素には限定されない。本発明は、コアネットワークシステム３４の要素にも適用可能である。

　また、本実施形態に係る機能ユニットは図３に示したものには限定されない。

　また、本実施形態に係る機能ユニットは、５ＧにおけるＮＦである必要はない。例えば、本実施形態に係る機能ユニットが、ｅＮｏｄｅＢ、ｖＤＵ、ｖＣＵ、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）などといった、４Ｇにおけるネットワークノードであっても構わない。

　また、本実施形態に係る機能ユニットが、コンテナ型の仮想化技術でなく、ハイパーバイザ型やホスト型の仮想化技術を用いて実現されてもよい。また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。

　本開示に記載の技術は以下のように表現することもできる。
［１］
　通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成するキュー生成手段と、
　前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定する判定手段と、
　前記判定手段が前記性能指標値データを取得する頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成するファイル生成手段と、
　を含むことを特徴とするファイル生成システム。
［２］
　前記ファイル生成手段は、所定の時間間隔で、前記ファイルが前回生成されたタイミングより後に前記キューに格納された前記性能指標値データを含む前記ファイルを生成する、
　ことを特徴とする［１］に記載のファイル生成システム。
［３］
　前記ファイル生成手段は、生成された前記ファイルに含まれる前記性能指標値データがすべてデキューされたことに応じて、前記キューに格納されているすべての前記性能指標値データを含む前記ファイルを生成する、
　ことを特徴とする［１］に記載のファイル生成システム。
［４］
　通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成することと、
　前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された当該性能指標値データに基づいて前記通信システムの状態を判定することと、
　前記性能指標値データが取得される頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成することと、
　を含むことを特徴とするファイル生成方法。

 

Claims (4)

1. 　１以上のプロセッサを備え、
   　前記１以上のプロセッサのうちの少なくとも１つによって、
   　通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成するキュー生成処理と、
   　前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定する判定処理と、
   　前記判定処理で前記性能指標値データを取得する頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成するファイル生成処理と、
   　が実行されるファイル生成システム。
2. 　前記ファイル生成処理では、所定の時間間隔で、前記ファイルが前回生成されたタイミングより後に前記キューに格納された前記性能指標値データを含む前記ファイルを生成する、
   　請求項１に記載のファイル生成システム。
3. 　前記ファイル生成処理では、生成された前記ファイルに含まれる前記性能指標値データがすべてデキューされたことに応じて、前記キューに格納されているすべての前記性能指標値データを含む前記ファイルを生成する、
   　請求項１に記載のファイル生成システム。
4. 　通信システムに含まれる要素の性能指標値を示す性能指標値データが格納されるキューを生成することと、
   　前記性能指標値データが前記キューにエンキューされたことに応じて、前記キューが格納可能な前記性能指標値データの最大数よりも少ない数の、前記キューに格納されている性能指標値データのうちの最新の前記性能指標値データを少なくとも含む直近所定数又は直近所定期間の前記性能指標値データを取得して、取得された性能指標値データに基づいて前記通信システムの状態を判定することと、
   　前記性能指標値データが取得される頻度よりも少ない頻度で、前記キューに格納されている前記性能指標値データのうちの少なくとも一部を含むファイルを生成することと、
   　を含むファイル生成方法。
   
    

Images