JP7620164B2

JP7620164B2 - ネットワークの異常の原因推定

Info

Publication number: JP7620164B2
Application number: JP2024524532A
Authority: JP
Inventors: 真也北
Original assignee: Rakuten Mobile Inc
Current assignee: Rakuten Mobile Inc
Priority date: 2022-05-30
Filing date: 2022-05-30
Publication date: 2025-01-22
Anticipated expiration: 2042-05-30
Also published as: EP4535749A4; EP4535749A1; US20240291740A1; WO2023233471A1; US12289222B2; JPWO2023233471A1

Description

本開示は、ネットワークシステムおよびネットワーク異常の対応方法に関する。

機器やソフトウェアから取得される監視情報に基づいてルールベースでネットワークの状態を監視することが行われている。

特開２０２０－５３６４３４号公報

ネットワークに生じる異常には様々なタイプがある。障害のメカニズムが複雑な場合には、監視情報から異常の原因を判定するルールを作成することが難しい。

発明者らは、機械学習モデルを用いて異常の原因を判定することを検討している。しかしながら、ネットワークに生じる異常は非常に複雑であるため、単に機械学習モデルを用いてその異常の原因を判定しようとした場合、その判定の精度が確保できなかった。

本開示は上記実情に鑑みてなされたものであって、その目的の一つは、ネットワークに生じた異常の原因を精度よく推定することを可能にする技術を提供することにある。

上記課題を解決するために、本開示にかかるネットワークシステムは、１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、取得処理、選択処理、出力取得処理、対応処理が実行される。取得処理では、ネットワークの状態を示す第１の情報を取得する。選択処理では、前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択する。出力取得処理では、前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得する。対応処理では、前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を開始させる。

また、本開示にかかるネットワークの異常の対応方法は、１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、取得処理、選択処理、出力取得処理、対応処理が実行される。選択処理では、前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択する。出力取得処理では、前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得する。対応処理では、前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を開始させる。

本開示の実施形態にかかる通信システムの一例を示す図である。本実施形態にかかる通信システムの一例を示す図である。本実施形態にかかるネットワークサービスの一例を模式的に示す図である。本実施形態にかかる通信システムに構築される要素間の関連付けの一例を示す図である。ネットワークスライスの属性の一例を示す図である。プラットフォームシステムに実装される機能の一例を示す機能ブロック図である。ポリシーマネージャの処理の概要を示すフロー図である。ＡＩ・ビッグデータ処理部の処理の一例を示すフロー図である。原因推定モデルとＡＰＩおよびグループとの対応の一例を示す図である。ポリシーマネージャ部が原因推定モデルを用いて対応する処理の一例を示すフロー図である。ＡＩ・ビッグデータ処理部の処理の他の一例を示すフロー図である。ポリシーマネージャ部が原因推定モデルを用いて対応する処理の他の一例を示すフロー図である。ポリシーマネージャ部が原因推定モデルを用いずに対応する処理の一例を示すフロー図である。

以下、本開示における実施形態について図面に基づき詳細に説明する。

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

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

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

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

エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（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）も、本説明においてＶＮＦに含まれる。本実施形態では、ネットワークサービスが１または複数のＣＮＦによって実装されるものとして説明する。また、本実施形態に係る機能ユニットは、ネットワークノードに相当するものであってもよい。

図３は、稼働中のネットワークサービスの一例を模式的に示す図である。図３は、ネットワークサービスのうちの１つの、エンド・ツー・エンドのネットワークスライスに関する構成の一例を示している。ネットワークスライスは、物理的な通信ネットワークが仮想的に分割されたものである。

図３に示すネットワークサービスには、複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ４４、複数のＵＰＦ（User Plane Function）４６、１または複数のＡＭＦ（Access and Mobility Management Function）、１または複数のＳＭＦ（Session Management 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）部５２、チケット管理部５４、ＡＩ・ビッグデータ処理部５６、性能算出部５７、監視機能部５８、ＳＤＮコントローラ６０、構成管理部６２、を含む。Ｅ２ＥＯ部５２は、機能的に、ポリシーマネージャ部８０、スライスマネージャ部８２を含む。ＡＩ・ビッグデータ処理部５６は、機能的に、ビッグデータ格納部７０、正常判定部７２、原因推定部７４、ＡＰＩ部７６を含む。正常判定部７２は複数の正常判定モデル７３を含み、原因推定部７４は、複数の原因推定モデル７５を含む。これらの要素は、主に、プロセッサ３０ａ、記憶部３０ｂ、および、通信部３０ｃにより実装される。

本実施形態に記載される機能および処理は、プロセッサ３０ａ、記憶部３０ｂ（例えばメモリ）などを備えた１または複数の情報処理装置（例えばサーバ）にソフトウェア（プログラムの実行命令）が記録された記憶媒体を読み込ませ、プロセッサ３０ａがそのソフトウェアにかかる処理を実行することによって実現される。この記憶媒体は、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な、非揮発性の情報記憶媒体であってよい。また、プラットフォームシステム３０の記憶部３０ｂに含まれる外部記憶装置（例えばハードディスクドライブやソリッドステートドライブ）に、このソフトウェアが格納されてよい。また、図６に示す機能が、回路ブロック、メモリ、その他の集積回路により実装されてもよい。また、図６に示す機能が、ハードウェアのみ、ソフトウェアのみ、またはそれらの組合せといった様々な形態で実現できることは、当業者には容易に理解される。

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

また本実施形態では、インベントリデータベース５０には、インベントリデータが記憶されている。インベントリデータには、通信システム１に含まれる要素群の構成や要素間の関連付け（例えばトポロジーデータ）の現況が示されている。要素は、ハードウェア的な要素と、ソフトウェア的な要素とを含む。ハードウェア的な要素は、例えば、サーバ、ラック、建物、ネットワーク機器を含む。ソフトウェア的な要素は、例えば、ネットワークスライスやＮＦ、稼働するコンテナを含む。また、インベントリデータには、プラットフォームシステム３０で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。

要素間の関連付けの現況を示すトポロジーデータは、例えば、あるＮＳの識別子と当該ＮＳの配下にある１または複数のＮＦの識別子とを含み、また例えば、あるネットワークスライスの識別子と当該ネットワークスライスに所属する１または複数のＮＦの識別子とを含む。

図６に示されるＥ２ＥＯ部５２、チケット管理部５４、ＡＩ・ビッグデータ処理部５６、性能算出部５７、監視機能部５８、ＳＤＮコントローラ６０、構成管理部６２の各機能は、その処理においてインベントリデータベース５０に格納されるインベントリデータを参照し、必要に応じてインベントリデータを追加または更新する。例えば、通信システム１に含まれる新規要素の構築、通信システム１に含まれる要素の構成変更、通信システム１に含まれる要素のスケーリング、通信システム１に含まれる要素のリプレース、などのアクションが実行されることに応じて、インベントリデータベース５０に記憶されているインベントリデータが更新される。

スライスマネージャ部８２は、本実施形態では例えば、スライステンプレートが示すロジックを実行することで、ネットワークスライスのインスタンス化を実行する。ここで、スライスマネージャ部８２は、ネットワークスライスのインスタンス化に関係する構成管理指示を構成管理部６２に出力してよい。そして、構成管理部６２が、当該構成管理指示に従った設定等の構成管理を実行してよい。

スライスマネージャ部８２は、ＳＤＮコントローラ６０に、ＮＦ間（ＣＵ４４とＵＰＦ４６およびＡＭＦとの間）の通信経路の作成指示を出力してよい。ＳＤＮコントローラ６０は、ＳＤＮ３６に対して、より具体的な通信経路の作成指示を出力してよい。具体的な通信経路の作成指示は、互いに通信するＣＵ４４と、ＵＰＦ４６またはＡＭＦとを特定する情報として、２つのＳＲＶ６のＩＰアドレスを含む。

ここで、スライスマネージャ部８２は、ポリシーマネージャ部８０からの指示に応じて、ネットワークスライスにおける通信経路と、コアネットワークシステム３４等におけるＮＦとのうち少なくとも一方を増強する処理を実行する。例えばスライスマネージャ部８２は、ネットワークスライスに関連付けられるＵＰＦ４６、ＡＭＦ、ＳＭＦのうちいずれかをスケールアウトする構成管理指示を構成管理部６２に出力し、スケールアウトされたＵＰＦ４６またはＡＭＦと各ＲＡＮ３２のＣＵ４４との新たな通信経路を作成する作成指示をＳＤＮコントローラ６０に出力してよい。またスライスマネージャ部８２は、既存のＵＰＦ４６またはＡＭＦと各ＲＡＮ３２のＣＵ４４との通信経路の帯域幅の上限を変更する、または通信経路を再作成する（言い換えれば、使用する通信経路を変更する）変更指示をＳＤＮコントローラ６０に出力してよい。

スライスマネージャ部８２は、例えば、３ＧＰＰ（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)」に記載された性能指標についての性能指標値を示すメトリックデータを監視情報として取得してよい。

そして、監視機能部５８は、例えば、上述の監視情報を取得すると、当該監視情報をＡＩ・ビッグデータ処理部５６に向けて出力してよい。ＡＩ・ビッグデータ処理部５６は出力された監視情報をビッグデータ格納部７０に格納する。

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

そして、監視機能部５８は、例えば、上述のアラートの通知を監視情報として取得すると、当該通知をＡＩ・ビッグデータ処理部５６に出力する。ＡＩ・ビッグデータ処理部５６は、その監視情報をビッグデータ格納部７０に格納する。格納されたアラートの通知は、ポリシーマネージャ部８０により利用される。ポリシーマネージャ部８０の処理については後述する。

性能算出部５７は、ビッグデータ格納部７０に格納された複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、一種のＫＰＩ）を算出する。性能算出部５７は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してよい。性能算出部５７は、算出された性能指標値を示す性能指標データをＡＩ・ビッグデータ処理部５６に出力し、その性能指標値データをビッグデータ格納部７０に格納させてよい。性能指標データも、ネットワークスライスの状態を示す監視情報の一種である。

なお、性能算出部５７は、メトリックデータを監視機能部５８から直接的に取得してそのメトリックデータに基づいて性能指標値を算出してもよい。

ＡＩ・ビッグデータ処理部５６は、メトリックデータ、アラートの通知、性能指標値などの監視情報を蓄積し、またその蓄積された監視情報に基づいてネットワークに生じる異常の原因を推定する。

ＡＩ・ビッグデータ処理部５６に含まれるビッグデータ格納部７０は、サーバ等のハードウェアやＮＦのようなソフトウェア要素から取得された、メトリックデータおよびアラートを含む監視情報を、対応するネットワークスライスおよび時刻と関連付けて格納する。ビッグデータ格納部７０には過去の監視情報が蓄積される。

ＡＩ・ビッグデータ処理部５６に含まれる正常判定部７２は、複数のネットワークスライスにそれぞれ対応する複数の正常判定モデル７３を含む。正常判定部７２は、対象となるネットワークスライスに対応する正常判定モデル７３に対象となるネットワークスライスから取得される指標を含む入力データを入力した際の出力を取得することにより、対象となるネットワークスライスの状態が正常であるか否かを判定する。複数の正常判定モデル７３は、複数のネットワークスライスと１対１で対応してよい。

正常判定モデル７３は、対応するネットワークスライスにおける、正常時のある時刻またはその直近の一定の期間に取得されたメトリックの指標と、その指標が取得された時間帯を示す情報とを含む正常訓練データにより学習されている。正常時とは、障害が発生していない期間である。正常時の指標は、所定期間の通信量を示すデータ、所定期間のネットワークの性能を示す指標、所定期間の代表時刻、所定期間の曜日、所定期間が休日か否かを示す休日フラグのうち少なくとも一部を含んでよい。正常判定モデル７３は、例えばｋ－近傍法、密度準拠クラスタリング、アイソレーションフォレストのような、データから外れ値を検出可能な公知の教師なし機械学習モデルに基づく異常検知モデルであってよい。

正常判定モデル７３には、あるネットワークスライスにおける、現在または直近の一定の時間の指標と、現在の時間帯を示す情報を含む入力データが入力される。入力データは、ビッグデータ格納部７０に格納されたデータからネットワークスライスおよび時刻に応じて選択されたデータであってよい。正常判定モデル７３は、ネットワークの状態が正常であるか否かの推定結果を示す情報を出力する。正常判定モデル７３は、例えば、訓練データのいずれかとの差異が小さい入力データに対しては正常を示す情報を出力し、どの訓練データとも差異が大きい入力データに対しては異常を示す情報を出力してよい。

ＡＩ・ビッグデータ処理部５６に含まれる原因推定部７４は、複数のグループにそれぞれ対応する複数の原因推定モデル７５を含む。複数のグループに、複数のネットワークスライスが分類されている。また原因推定部７４は、複数の原因の種類にそれぞれ対応する複数の原因推定モデル７５を含んでよい。原因推定モデル７５は、機械学習モデルである。原因の種類は、例えば、異常が発見されるトリガとなる事象の種類（以下では単にトリガの種類と記載する）であってよい。原因推定モデル７５は、ネットワークに異常が生じた際の過去の監視情報を含む入力データと、前記異常の原因を示す正解データとを含む訓練データによって学習されている。

また原因推定モデル７５のそれぞれは、原因の種類と対応づけられており、原因推定モデル７５は、異常の原因が、対応づけられた原因の種類に含まれる複数の原因のうちいずれであるかを推定する。原因推定モデル７５はグループおよび原因の種類の組み合わせごとに設けられ、互いに異なる訓練データにより学習されてよい。複数の原因推定モデル７５から原因の種類に応じたものに原因を推定させるために、複数の原因の種類にそれぞれ対応し互いに異なる複数のモデル決定条件が存在する。このモデル決定条件により、用いられる原因推定モデル７５が決定される。なお、複数の原因推定モデル７５から用いられるものを選択するための条件とも言えるので、モデル決定条件はモデル選択条件とも称される。

なお、原因推定モデル７５のインスタンスは、ネットワークインスタンスと原因の種類の組み合わせごとに設けられてよい。この場合、同じグループに属する複数のネットワークスライスを含むある原因の種類についての原因推定モデル７５のインスタンスは、同じ訓練データにより学習された同じ種類のものである。なお、原因推定モデル７５は原因の種類に応じて分かれていなくてもよく、全てのネットワークスライスで共通の内部パラメータを有してもよい。

原因推定モデル７５は、例えばTransformerモデルのように時系列の情報からネットワークに生じた異常の原因を推定するモデルであってよい。原因推定モデル７５に入力される入力データは、直近の３ブロック（例えば１ｈ間隔であれば３ｈ）のそれぞれのスナップショットにおける代表的な指標であってよい。その代表的な指標は、監視情報に含まれる、トラフィック、ＫＰＩの推移、代表時刻、曜日、休日フラグのうち少なくとも一部の項目を含んでよい。学習用のデータセットは、連続する３ブロックのそれぞれのスナップショットにおける代表的な指標のデータを含んでよい。原因推定モデル７５の学習用の入力データに含まれる複数の指標は、対応するグループに属するネットワークスライスについてビッグデータ格納部７０に格納される監視情報のログから取得されてよい。

ある原因の種類について、正常判定モデル７３および原因推定モデル７５が組み合わせて用いられてよい。またある原因の種類について、複数の原因推定モデル７５の出力を組み合わせた情報が原因の推定に用いられてもよい。

ＡＩ・ビッグデータ処理部５６に含まれるＡＰＩ部７６は、ポリシーマネージャ部８０から呼び出されるＡＰＩを提供する。ＡＰＩ部７６は、ポリシーマネージャ部８０から呼び出されるＡＰＩに応じて、原因推定部７４によるネットワークに生じた異常の原因の推定結果（原因推定部７４の出力）を取得し、さらに、原因推定部７４の原因推定モデル７５の出力を呼び出し元へ返す。

ＡＰＩ部７６は、原因の種類（トリガの種類）に応じて異なるＡＰＩを提供してよいし、ネットワークスライスに応じて異なるＡＰＩを提供してもよい。ＡＰＩ部７６は、単にＡＰＩを呼び出す際のパラメータとして原因の種類およびネットワークスライスを取得し、そのパラメータに応じた原因推定モデル７５の出力を返してもよい。

ポリシーマネージャ部８０は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の原因推定モデル７５の出力、上述の性能指標値データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。

そして、ポリシーマネージャ部８０は、判定処理の結果に応じたアクションを実行する。例えば、ポリシーマネージャ部８０は、スライスマネージャ部８２に、ネットワークスライスにおける通信経路と、コアネットワークシステム３４等におけるＮＦとのうち少なくとも一方を増強させる指示を送信する。また例えば、ポリシーマネージャ部８０は、チケット管理部５４へ、発生した異常の内容（例えば検知された自称およびその推定された原因）を送信する。また例えば、ポリシーマネージャ部８０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示を図示しないライフサイクル管理部に出力する。

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

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

以下では、通信システム１における、ネットワークに異常が生じた際のその異常の原因の推定およびその原因に応じた対応の処理についてより詳細に説明する。これらの推定および対応の処理は、ポリシーマネージャ部８０およびＡＩ・ビッグデータ処理部５６により実装される。

本実施形態では、原因の推定に用いる原因推定モデル７５は、原因の種類（トリガの種類）および対象のネットワークスライスが属するグループに応じて定まる。複数のモデル決定条件は、原因推定モデル７５を決定するための条件であり、原因の種類に対応している。

図７は、ポリシーマネージャ部８０の処理の概要を示すフロー図である。図７に示される処理フローは、ポリシーマネージャ部８０の機能のうち、ネットワークに生じた異常の原因を取得し、その原因に対応する機能に関する処理の概要を示している。

はじめにポリシーマネージャ部８０は、ビッグデータ格納部７０から監視情報を取得する（Ｓ１０１）。そして、ポリシーマネージャ部８０は、取得された監視情報が満たすモデル決定条件に応じて、ＡＰＩ部７６の呼び出し手法を決定する（Ｓ１０２）。そしてポリシーマネージャ部８０はその呼び出し手法によりＡＰＩ部７６を介してモデル決定条件に応じた原因推定モデル７５の出力を取得する（Ｓ１０３）。原因推定モデル７５にはビッグデータ格納部７０から取得された監視情報を含む入力データが入力されてよい。Ｓ１０２においてポリシーマネージャ部８０は監視情報のうち一部を用いてモデル決定条件を満たすか判定してよい。原因推定モデル７５に入力される監視情報は、Ｓ１０２において用いられる監視情報と異なる項目を含んでもよい。

複数のモデル決定条件は第１および第２のモデル決定条件を含む。第１のモデル決定条件はネットワークスライスにおけるトラフィックの異常（スループット等の性能指標の異常）を示す条件である。第２のモデル決定条件は端末の登録に関する異常を示す条件である。第１のモデル決定条件および第２のモデル決定条件に関する処理の詳細については、図１０、図１２を用いて後述する。

呼び出されたＡＰＩ部７６の処理について説明する。図８は、ＡＩ・ビッグデータ処理部５６の処理の一例を示すフロー図である。図８は、Ｓ１０３によりＡＩ・ビッグデータ処理部５６に含まれるＡＰＩ部７６が呼び出された際の処理の一例を示す。

ＡＰＩ部７６は、ＡＰＩの種類および対象となるネットワークスライスが属するグループに基づいて原因推定モデル７５を決定する（Ｓ２０１）。厳密には、ＡＰＩ部７６は、グループに基づいて原因推定モデル７５の種類を決定する。ＡＰＩの種類は、ＡＰＩの呼び出し手法の一例である。本図の例では、ＡＰＩの種類は、原因の種類や、異常が発見されるトリガとなる事象の種類に対応している。ＡＰＩは、原因の種類とネットワークスライスの組み合わせごとに設けられてもよい。

ＡＰＩ部７６は、原因推定モデル７５の決定において、呼び出されたＡＰＩの種類とネットワークスライスとの組み合わせに対応する原因推定モデル７５のインスタンスを決定してよい。原因推定モデル７５のインスタンスに応じた原因推定モデル７５の種類はグループに応じて決まっているため、ネットワークスライスに応じた原因推定モデル７５のインスタンスの決定は、グループに応じた原因推定モデル７５の決定に相当する。なお、ＡＰＩ部７６は、Ｓ２０１において、出力の取得の対象となる２以上の原因推定モデル７５の組み合わせを決定してもよい。

用いられる原因推定モデル７５が決定されると、ＡＰＩ部７６は、決定された原因推定モデル７５（厳密にはそのインスタンス）にそのネットワークスライスについてのネットワークの状態を示す監視情報が入力された際の出力を取得する（Ｓ２０２）。ここで、ＡＰＩ部７６は、Ｓ２０１の処理の後に、入力データの取得と、決定された原因推定モデル７５への入力データとして監視情報の入力と、その原因推定モデル７５の出力の取得とを順に行ってよい。ＡＰＩ部７６は、入力データとしてビッグデータ格納部７０から決定された原因推定モデル７５に入力する現在または直近の監視情報を取得してよい。

一方、複数の原因推定モデル７５のいずれかには、ＡＰＩ部７６による原因推定モデル７５の決定と関係なく、入力データとして監視情報が入力されてもよい。この場合、原因推定モデル７５には定期的に、ビッグデータ格納部７０から現在または直近の監視情報が入力データとして入力されてよい。この場合、ポリシーマネージャによるモデル決定条件に関する判定や、ＡＰＩ部７６による原因推定モデル７５の決定より前に、原因推定モデル７５に監視情報が入力されてよい。この場合、ＡＰＩ部７６は、Ｓ２０２において、既に出力された原因推定モデルの結果を取得してもよいし、最新の入力データに対する結果がまだ出力されていない場合には、その結果の出力まで待機してもよい。原因推定モデル７５の推定が早く開始されるため、より早く異常に対応することができる。

そして、ＡＰＩ部７６は、その決定された原因推定モデル７５の出力を呼び出し元へ送信する（Ｓ２０３）。

なお、決定された原因推定モデルによっては、原因推定モデルと正常判定モデルの判定とが組み合わされてもよい。この詳細については後述する。

ポリシーマネージャ部８０は、ＡＰＩ部７６から出力を受け付けると、原因推定モデル７５の出力に応じた対応の処理を実行する（Ｓ１０４）。この対応の処理によりネットワークに生じた異常が解消または抑制される。例えば、原因推定モデル７５の出力が第１のラベルを示す場合（言い換えれば、当該出力の値が、第１のラベルに相当する値と一致する、第１のラベルに相当する範囲内にある、または、出力のうち第１のラベルに対応する項目の値が閾値を超える）には、ポリシーマネージャ部８０はＣＵ４４とＵＰＦ４６との間の通信経路を増強する、より具体的にはその通信経路の帯域幅を増加させてよい。原因推定モデル７５の出力が第２のラベルを示す場合には、その通信経路を再作成させてよい。原因推定モデル７５の出力が第３のラベルを示す場合には、データ通信にかかるＵＰＦ４６の数を増加させ（スケールアウト）、その増加されたＵＰＦ４６と既存のＣＵ４４との間の通信経路を追加させてよい。また例えば原因推定モデルの出力が第４のラベルを示す場合には、ＳＭＦの数を増加させ（スケールアウト）、第５のラベルを示す場合には、ＡＭＦおよびＳＭＦの数を増加させ、第６のラベルを示す場合にはＵＥの接続に制限をかけてよい。また、前述の対応の処理として、ポリシーマネージャ部８０は、チケット管理部５４へ障害の発生の通知を送ってもよい。

図７の処理は実際にはこの順番通りにされなくてもよい。例えば、モデル決定条件ごとにＳ１０２からＳ１０４に相当する処理が行われてよい。例えば、モデル決定条件ごとに記憶部３０ｂにプログラムが格納され、それぞれのプログラムを実行するプロセッサ３０ａが、そのプログラムに含まれるモデル決定条件を満たすか否かを判定し（Ｓ１０２に相当）、その判定結果に応じてＡＰＩ部７６を呼び出し（Ｓ１０３に相当）、原因分析モデルの出力に応じた対応の処理を実行してよい（Ｓ１０４に相当）。

以下では、モデル決定条件ごとにより詳細に処理を説明していく。図１０は、ポリシーマネージャ部８０が原因推定モデル７５を用いて対応する処理の一例を示すフロー図である。図１０には、モデル決定条件として性能に関する条件が用いられる場合における、図７のＳ１０２からＳ１０４に相当する処理をより詳細に記載している。図１０に示される処理は定期的に繰り返し実行される。

図１０の処理において、はじめにポリシーマネージャ部８０は、最新の取得された性能指標値（例えばスループット）が閾値未満であり、かつ前回取得された性能指標値が閾値未満であるか判定する（Ｓ３０１）。

Ｓ３０１において最新および前回の性能指標値が閾値以上である場合には（Ｓ３０１のＮ）、図１０の処理を終了する。一方、性能指標値が閾値未満である場合には（Ｓ３０１のＹ）、ポリシーマネージャ部８０は、ＡＰＩ部７６のＡＰＩ－Ａを介して原因推定モデル７５に原因を問合せ、その原因推定モデル７５の出力を取得する（Ｓ３０２）。ここで、原因推定モデル７５の出力は、予め定められた複数のラベルのうちいずれかを指す、または、どのラベルも該当しないことを示すものとする。

最新および前回の性能指標値が閾値未満であることは、モデル決定条件の一種である。ＡＰＩ－Ａを介して呼び出される原因推定モデル７５は限定されているため、ＡＰＩ－Ａを選択する条件は、原因推定モデル７５を選択する条件でもあるからである。

取得された出力がラベルＡ１を指し示す場合には（Ｓ３０３のＹ）、ポリシーマネージャ部８０はＳＤＮコントローラ６０に対して、ＵＰＦ４６とＲＡＮ３２との既存の通信経路における帯域幅を増加させる指示を送信し（Ｓ３０４）、ＳＤＮコントローラ６０にその帯域幅を増加させる。またＳ３０４の処理がされると図１０に示される処理は終了する。

取得された出力がラベルＡ２を指し示す場合には（Ｓ３０５のＹ）、ポリシーマネージャ部８０はＳＤＮコントローラ６０に対して、ＵＰＦ４６とＲＡＮ３２との通信経路を再作成させる指示を送信し（Ｓ３０６）、ＳＤＮコントローラ６０にその通信経路を再作成する。またＳ３０６の処理がされると図１０に示される処理は終了する。

取得された出力がラベルＢを指し示す場合には（Ｓ３０７のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＵＰＦ４６をスケールアウトさせる指示を送信し、ＳＤＮコントローラ６０に、ＵＰＦ４６とＲＡＮ３２との通信経路をスケールアウトさせる指示を送信する（Ｓ３０８）。ＵＰＦ４６をスケールアウトさせる指示は、ＵＰＦ４６の処理能力を増強するための処理を実行させる指示であり、例えば対象のネットワークスライスにＵＰＦ４６を追加する指示でもよい。また、ＵＰＦ４６が使用可能なＣＮＦのリソースの上限を増やしてもよい。通信経路をスケールアウトさせる指示は、追加されたＵＰＦ４６とＲＡＮ３２との間の通信を増強するための処理を実行させる指示であり、例えば、ＵＰＦ４６とＲＡＮ３２との通信に使用する仮想の通信経路を新規に作成させる指示でもよい。また、ＵＰＦ４６とＲＡＮ３２との通信に使用されている通信経路の帯域幅を増加させてもよい。指示を受け付けた構成管理部６２はＵＰＦ４６を追加し、指示を受け付けたＳＤＮコントローラ６０はその通信経路を新規作成する。またＳ３０８の処理がされると図１０に示される処理は終了する。

Ｓ３０３からＳ３０８の処理は、図７のＳ１０４に示される、原因分析モデルの出力に応じた対応の処理に相当する。なお、例えば後述の図１１の処理においてネットワークの状態が正常であると判定されたことを示す情報が返ってきた場合には、この対応の処理が行われなくてよい。

ここで、Ｓ３０２においてＡＰＩ部７６が呼び出されると、図８に示される処理により、呼び出されたＡＰＩの種類およびネットワークスライスに応じて原因推定モデル７５が選択され、選択された原因推定モデル７５の出力がポリシーマネージャ部８０に返される。ここで、ＡＰＩ部７６を含むＡＩ・ビッグデータ処理部５６は、正常判定モデル７３の判定結果も用いて原因を推定してもよい。

図１１は、ＡＩ・ビッグデータ処理部５６の処理の他の一例を示すフロー図である。図１１の例では、複数の種類がある原因推定モデル７５のうち一部の種類についてネットワークスライスに対応する正常判定モデル７３と組み合わせて処理をする場合の処理を示している。予め、原因推定モデル７５のそれぞれについて、正常判定モデル７３と組み合わせるか否かを示す正常判定情報が記憶部３０ｂに格納されているものとする。

はじめにＡＰＩ部７６は、呼び出されたＡＰＩの種類とネットワークスライスが属するグループとに応じて原因推定モデル７５を決定する（Ｓ４０１）。

そしてＡＰＩ部７６は、決定された原因推定モデル７５が、正常判定モデル７３と組み合わせるか否か判定する（Ｓ４０２）。この判定は、ＡＰＩ部７６が決定された原因推定モデル７５と関連付けて記憶される正常判定情報により行われてよい。例えば、ＡＰＩ部７６は、例えば図１０の性能指標値のような、トラフィック量と関係するトリガの場合には正常判定モデル７３と原因推定モデル７５とを組み合わせ、トラフィック量と関係のないトリガの場合には正常判定モデル７３を用いなくてよい。

そして正常判定モデルと組み合わせると判定された場合には（Ｓ４０２のＹ）、ＡＰＩ部７６は該当するネットワークスライスに対応する正常判定モデル７３の出力を取得する（Ｓ４０３）。またＡＰＩ部７６はその取得された出力が、ネットワークスライスの状態が異常でないことを示す場合には（Ｓ４０４のＮ）、ＡＰＩ部７６は異常が生じていないことを示す情報を呼び出し元へ送信し処理を終了する。正常判定モデル７３の出力はネットワークスライスの状態が正常であるか異常であるかの２値の情報であってもよいし、異常である蓋然性を示す値であってもよい。後者の場合には、正常判定モデル７３の出力が閾値を超えるか否かに基づいてネットワークスライスの状態が正常であるか異常であるか判定されてよい。

一方、ネットワークスライスの状態が異常であることを示す場合には（Ｓ４０４のＹ）、ＡＰＩ部７６は決定された原因推定モデル７５の出力を取得する（Ｓ４０５）。そして取得された原因推定モデル７５の出力を、ＡＰＩを介して呼び出し元へ送る（Ｓ４０６）。Ｓ４０５、Ｓ４０６の処理の詳細は、図８におけるＳ２０２、Ｓ２０３の処理と同様である。

Ｓ４０２の判定において、正常判定モデルと組み合わせないと判定された場合には（Ｓ４０２のＮ）、Ｓ４０５以降の処理を実行する。この場合に実質的に行われる処理は、図８と同様となる。

図１１に示されるように、正常判定モデル７３によってネットワークスライスの状態に異常があると判定された場合に原因推定モデル７５の出力が呼び出し元に送信されると、ポリシーマネージャ部８０は、正常判定モデル７３によってネットワークに異常があると判定された場合にのみその異常に対応する処理が実行される。

なお、図８、図１１の例と異なり、ＡＰＩに応じて異なるプログラムが実行されてよい。この場合、ＡＰＩが原因の種類（またはトリガの種類）ごとに設けられている場合には、ＡＰＩ部７６はネットワークスライスに基づいて原因推定モデル７５の種類（およびインスタンス）を決定してよい。ＡＰＩが原因の種類（またはトリガの種類）とネットワークスライスとの組み合わせごとに設けられている場合には、ＡＰＩ部７６はＳ２０１およびＳ４０１の処理を経ずに、呼び出されたＡＰＩにより特定される原因推定モデル７５の出力を取得してよい。

次に、図１０と異なるモデル決定条件についてのポリシーマネージャ部８０の処理の例について説明する。図１２は、ポリシーマネージャ部８０が原因推定モデル７５を用いて対応する処理の他の一例を示すフロー図である。図１２には、モデル決定条件として特定のＮＦ（具体的にはＡＭＦ、ＳＭＦ）からアラートが上がった場合における、図７のＳ１０２からＳ１０４に相当する処理をより詳細に記載している。図１２に示される処理も定期的に繰り返し実行される。

図１２の処理において、はじめにポリシーマネージャ部８０は、最新の監視情報がＡＭＦまたはＳＭＦからのアラートが上がっていることを示し、また前回の監視情報も同じアラートが上がっていることを示すか判定する（Ｓ５０１）。

最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示さない場合には（Ｓ５０１のＮ）、図１２の処理を終了する。一方、最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示す場合には（Ｓ５０１のＹ）、ポリシーマネージャ部８０は、ＡＰＩ部７６のＡＰＩ－Ｂを介して原因推定モデル７５に原因を問合せ、その原因推定モデル７５の出力を取得する（Ｓ５０２）。

最新および前回の監視情報が、ともにＡＭＦまたはＳＭＦからの同一のアラートが上がっていることを示すことは、モデル決定条件の一種である。ＡＰＩ－Ｂと原因推定モデル７５とは対応関係を有するため、ＡＰＩ－Ｂを選択する条件は、原因推定モデル７５を選択する条件でもあるからである。

取得された出力がラベルＣ１を指し示す場合には（Ｓ５０３のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＳＭＦをスケールアウトさせる指示を送信する（Ｓ５０４）。またＳ５０４の処理がされると図１２に示される処理は終了する。

取得された出力がラベルＣ２を指し示す場合には（Ｓ５０５のＹ）、ポリシーマネージャ部８０は構成管理部６２に対して、ＡＭＦおよびＳＭＦをスケールアウトさせる指示を送信する（Ｓ５０６）。またＳ５０６の処理がされると図１２に示される処理は終了する。

取得された出力がラベルＤを指し示す場合には（Ｓ５０７のＹ）、ポリシーマネージャ部８０はＲＡＮ３２に対してＵＥ２０の接続に制限をかける指示を送信する（Ｓ５０８）。ＵＥの接続の制限は、公知の手法で行われてよい。例えば、指示を受信したＲＡＮ３２が、ＵＥ２０からの接続要求を所定の割合で拒否してもよい。これにより、時間とともにＵＥ２０の接続数を減らすことができる。なお、所定の割合は、適宜に定めてよい。またＳ５０８の処理がされると図１２に示される処理は終了する。

Ｓ５０３からＳ５０８の処理は、図７のＳ１０４に示される、原因推定モデル７５の出力に応じた対応の処理に相当する。

なお、取得された監視情報が所定の対応条件を満たす場合には、原因推定モデル７５の出力を用いずに、所定の対応の処理が行われてもよい。図１３はポリシーマネージャ部８０が原因推定モデル７５を用いずに対応する処理の一例を示すフロー図である。図１３に示される処理は、原因の推定が比較的容易な異常に対応するために用いられる。

図１３の処理において、はじめにポリシーマネージャ部８０は、最新および前回に取得された、いずれかのサーバのＣＰＵ使用率の両方が閾値を超えているか否か判定する（Ｓ６０１）。複数のサーバのそれぞれのＣＰＵ使用率は監視情報に含まれる。

いずれのサーバについても、最新および前回に取得された２つのＣＰＵ使用率の両方が閾値を超えていない場合には（Ｓ６０１のＮ）、図１３の処理を終了する。一方、いずれかのサーバについて最新および前回に取得されたＣＰＵ使用率の両方が閾値を超えている場合には（Ｓ６０１のＹ）、ポリシーマネージャ部８０はチケット管理部５４へ警告チケットを発行し（Ｓ６０２）、チケット管理部５４は管理者へ警告チケットに基づくメッセージを出力する。またポリシーマネージャ部８０は、構成管理部６２に対して該当するサーバをスケールアウトする指示を送信する（Ｓ６０３）。より具体的にはポリシーマネージャ部８０は、構成管理部６２に、該当するサーバにデプロイされている機能を他の新たなサーバと分割して配置する指示を送信する。このように、ＣＰＵ使用率などの所定の対応条件を満たした場合に、警告チケットの発行、サーバのスケールアウトといった所定の対応が実行されてもよい。

Ｓ６０２、Ｓ６０３の処理もネットワークの異常に対応する処理に対応する処理の一種である。

本実施形態では、機械学習モデルである原因推定モデル７５を用いてネットワークスライスに生じた異常の原因を推定している。ここで、一般的にネットワークに実際に異常が生じるケースは少なく、異常の原因に関する訓練データを大量に取得することは容易でない。

本実施形態では、ネットワークスライスのグループごとに原因推定モデル７５が学習されている。またネットワークスライスが属するグループに応じた原因推定モデル７５の出力に応じて対応処理が実行される。これらにより、ネットワークに生じる異常を適切に判定することができる。

より具体的には、ネットワークスライスごとに学習する場合に比べ、より多くの異常に関する訓練データを確保することができ推定の精度が向上する。また仮に原因推定モデル７５をすべてのネットワークスライスで共通にした場合、ネットワークの構成に応じて生じる異常が異なるようなケースにおいて原因を推定することが難しい。ネットワーク構成に応じて分類されたグループを用いることで、ネットワークの構成に応じた原因の推定が可能になり、推定精度を向上させることができる。

また、図１０、図１１に示されるように、正常判定モデル７３によってネットワークに異常があると判定された場合に原因推定モデル７５の原因推定の結果に応じた対応処理が行われている。

前述のように異常の原因に関する訓練データを大量に取得することは容易でない一方で、ネットワークスライスの状態が正常である場合の訓練データを確保することは容易である。そのため、予めネットワークスライスの状態が正常であるか否かを正常判定モデル７３により精緻に推定し、その後原因推定モデル７５で異常の原因を推定することにより、異常の原因の推定の精度を向上させることが可能になる。また正常判定モデル７３をネットワークスライスごとに学習させることにより、さらに精度を向上させることが可能になる。

また本実施形態では、異常が検出されるトリガにそれぞれ対応する複数の原因推定モデル７５が設けられ、原因の推定に用いる原因推定モデル７５は、異常が検出されるトリガに対応するモデル決定条件に応じて特定されている。このトリガは異常の原因の種類に対応している。これにより、個々の原因推定モデル７５が推定すべき異常の原因の範囲を効率的に限定することができ、原因推定の精度を向上させることが可能になる。

なお、本開示は上述の実施形態に限定されるものではない。実施形態において開示された構成を様々に組み合わせることが可能である。また本開示の技術的思想の範囲内において、本実施形態に記載される構成の一部が変更されてもよい。

例えば、本実施形態に係る実行基盤は、クバネテスクラスタであってもよい。また、本実施形態に係る実行基盤は、サーバであってもよい。

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

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

なお、上記の実施形態では実際の運用を想定して説明したため、過去の監視情報に基づいて学習されたモデルと、現在または直近の監視情報と、を用いて、現在のネットワークの状態を判定すると述べた。しかし、判定されるネットワークの状態は、必ずしも現在の状態でなくてもよい。すなわち、第１の時間帯に得られた監視情報と、第１の時間帯とは異なる第２の時間帯に得られた監視情報に基づいて学習されたモデルとを用いて、第１の時間帯におけるネットワークの状態を判定してもよい。

以上に説明した実施形態についての記載から把握されるように、本明細書では以下の開示を含む多様な技術的思想が開示されている。

（１）１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、ネットワークの状態を示す第１の情報を取得する取得処理と、前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択する選択処理と、前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得する出力取得処理と、前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を実行する対応処理と、が実行されるネットワークシステム。

（２）（１）に記載のネットワークシステムにおいて、前記対応処理では、前記取得された第１の情報が所定の対応条件を満たす場合には、前記複数の原因推定モデルのいずれからの出力も用いずに前記ネットワークに生じた異常に対処する処理を開始させる、ネットワークシステム。

（３）（１）または（２）に記載のネットワークシステムにおいて、前記複数の原因推定モデルのいずれかには、前記選択処理において前記原因推定モデルが選択される前に、当該原因推定モデルに前記第１の情報が入力される、ネットワークシステム。

（４）１以上のプロセッサのうち少なくとも一つによって、ネットワークの状態を示す第１の情報を取得し、前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択し、前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得し、前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を実行する、ネットワーク異常に対する対応方法。

Claims

１以上のプロセッサを備え、前記１以上のプロセッサのうち少なくとも一つによって、
ネットワークの状態を示す第１の情報を取得する取得処理と、
前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択する選択処理と、
前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得する出力取得処理と、
前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を実行する対応処理と、
が実行されるネットワークシステム。
請求項１に記載のネットワークシステムにおいて、
前記対応処理では、前記取得された第１の情報が所定の対応条件を満たす場合には、前記複数の原因推定モデルのいずれからの出力も用いずに前記ネットワークに生じた異常に対処する処理を開始させる、
ネットワークシステム。
請求項１に記載のネットワークシステムにおいて、
前記複数の原因推定モデルのいずれかには、前記選択処理において前記原因推定モデルが選択される前に、当該原因推定モデルに前記第１の情報が入力される、
ネットワークシステム。
１以上のプロセッサのうち少なくとも一つによって、
ネットワークの状態を示す第１の情報を取得し、
前記ネットワークに生じる障害の原因の種類ごとに設けられ、それぞれモデル選択条件に対応付けられる複数の原因推定モデルであって、前記第１の情報とは異なる時間帯における前記ネットワークの状態を示す第２の情報を含む入力データと、対応する原因の種類に属する前記ネットワークに生じた異常の原因を示す正解データとを含む訓練データにより学習される複数の原因推定モデルから、前記取得された第１の情報が満たすモデル選択条件に対応する原因推定モデルを選択し、
前記選択された原因推定モデルに前記ネットワークの状態を示す第１の情報が入力された際の出力を取得し、
前記選択された前記原因推定モデルの前記取得された出力に基づいて前記ネットワークに生じた異常に対処する処理を実行する、
ネットワーク異常に対する対応方法。