特許 7329017 診断装置、診断方法、プログラム及び診断システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-08

(45)【発行日】2023-08-17

(54)【発明の名称】診断装置、診断方法、プログラム及び診断システム

(51)【国際特許分類】

   H04L 41/16 20220101AFI20230809BHJP

   H04L 43/10 20220101ALI20230809BHJP

   H04L 41/0631 20220101ALI20230809BHJP

【ＦＩ】

H04L41/16

H04L43/10

H04L41/0631

【請求項の数】 8

(21)【出願番号】P 2021105296

(22)【出願日】2021-06-25

(65)【公開番号】P2023003916

(43)【公開日】2023-01-17

【審査請求日】2022-03-28

(73)【特許権者】

【識別番号】501440684

【氏名又は名称】ソフトバンク株式会社

(73)【特許権者】

【識別番号】504176911

【氏名又は名称】国立大学法人大阪大学

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】山内 啓嗣

(72)【発明者】

【氏名】木村 達明

【審査官】羽岡 さやか

(56)【参考文献】

【文献】特開２０１５－１９２１６３（ＪＰ，Ａ）

【文献】特開２０２０－０６８５１０（ＪＰ，Ａ）

【文献】特開２００２－１１１６６５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４１／００

Ｈ０４Ｌ ４３／００

(57)【特許請求の範囲】

【請求項1】

通信ネットワークに含まれる複数の通信装置の中から、所定の通信サービスを収容する所定の通信装置群を特定する特定部と、
前記特定部で特定された所定の通信装置群に含まれる通信装置の各々でコマンドを実行することで、前記所定の通信装置群に含まれる各通信装置の動作状態を示す所定のコマンド応答を収集する収集部と、
前記通信ネットワークにおける通信サービスを収容する複数の通信装置から収集されたコマンド応答に基づいて生成された特徴ベクトルと、該特徴ベクトルに対応する故障種別を示すラベルと、を対応づけた教師データを用いて学習された学習済モデルと、
前記所定のコマンド応答に基づき、前記所定の通信サービスにおける故障種別を判別する判別部と、
前記判別部で判別された前記故障種別を出力する出力部と、
を有し、
前記判別部は、前記所定のコマンド応答に基づいて生成された所定の特徴ベクトルを前記学習済モデルに入力し、前記学習済モデルから出力される故障種別を示すラベルを取得することで、前記所定の通信サービスにおける故障種別を判別する、
診断装置。

【請求項2】

前記通信ネットワークにおける通信サービスを収容する複数の通信装置から収集された複数のコマンド応答に基づいて生成された特徴ベクトルを複数のクラスにクラスタリングし、各々のクラスに対し故障種別を示すラベルが対応づけられたデータベースを記憶する記憶部と、
前記データベースに格納された特徴ベクトルと、当該特徴ベクトルが属するクラスタに対応するラベルとを教師データとしてモデルを学習させることで、前記学習済モデルを生成する学習処理部と、を有する、
請求項１に記載の診断装置。

【請求項3】

前記判別部により判別された前記所定の通信サービスにおける故障種別が正解又は誤りであるかと、前記所定の通信サービスにおける故障種別が誤りであった場合における正しい故障種別とを受け付ける受付部と、
前記受付部で、前記所定の通信サービスにおける故障種別が正解であることを受け付けた場合に、前記所定のコマンド応答に基づいて生成された特徴ベクトルと前記判別部により判別された前記所定の通信サービスにおける故障種別を示すラベルとを対応づけた教師データを生成し、前記受付部で、前記所定の通信サービスにおける正しい故障種別を受け付けた場合に、前記所定のコマンド応答に基づいて生成された特徴ベクトルと前記受付部で受け付けた正しい故障種別を示すラベルとを対応づけた教師データを生成する、生成部と、を有する、
請求項２に記載の診断装置。

【請求項4】

決定木を用いて学習させた前記学習済モデルの分岐に用いられる特定コマンドを抽出する抽出部、を有する、
請求項１に記載の診断装置。

【請求項5】

前記収集部は、前記所定の通信装置群に含まれる通信装置の各々で、少なくとも前記特定コマンドに含まれるコマンドを実行することで、前記所定の通信装置群に含まれる通信装置の動作状態を示す前記所定のコマンド応答を収集する、
請求項４に記載の診断装置。

【請求項6】

通信ネットワークに含まれる複数の通信装置の中から、所定の通信サービスを収容する所定の通信装置群を特定するステップと、
前記特定するステップで特定された所定の通信装置群に含まれる通信装置の各々にコマンドを入力することで、前記所定の通信装置群に含まれる各通信装置の動作状態を示す所定のコマンド応答を収集するステップと、
前記所定のコマンド応答に基づき、前記所定の通信サービスにおける故障種別を判別するステップと、
前記判別するステップで判別された前記故障種別を出力するステップと、 を含み、
前記判別するステップは、前記所定のコマンド応答に基づいて生成された所定の特徴ベクトルを、前記通信ネットワークにおける通信サービスを収容する複数の通信装置から収集されたコマンド応答に基づいて生成された特徴ベクトルと、該特徴ベクトルに対応する故障種別を示すラベルと、を対応づけた教師データを用いて学習された学習済モデルに入力し、前記学習済モデルから出力される故障種別を示すラベルを取得することで、前記所定の通信サービスにおける故障種別を判別する、
診断装置が実行する診断方法。

【請求項7】

コンピュータに、
通信ネットワークに含まれる複数の通信装置の中から、所定の通信サービスを収容する所定の通信装置群を特定するステップと、
前記特定するステップで特定された所定の通信装置群に含まれる通信装置の各々でコマンドを実行することで、前記所定の通信装置群に含まれる各通信装置の動作状態を示す所定のコマンド応答を収集するステップと、
前記所定のコマンド応答に基づき、前記所定の通信サービスにおける故障種別を判別するステップと、
前記判別するステップで判別された前記故障種別を出力するステップと、
を実行させ、
前記判別するステップは、前記所定のコマンド応答に基づいて生成された所定の特徴ベクトルを、前記通信ネットワークにおける通信サービスを収容する複数の通信装置から収集されたコマンド応答に基づいて生成された特徴ベクトルと、該特徴ベクトルに対応する故障種別を示すラベルと、を対応づけた教師データを用いて学習された学習済モデルに入力し、前記学習済モデルから出力される故障種別を示すラベルを取得することで、前記所定の通信サービスにおける故障種別を判別する、
プログラム。

【請求項8】

通信ネットワークに含まれる複数の通信装置及び診断装置を有する診断システムであって、
前記通信装置は、
前記通信装置の動作状態を管理する管理部と、
前記通信装置の動作状態を示すコマンド応答を前記診断装置に送信する送信部と、を備え、
前記診断装置は、
前記複数の通信装置の中から、所定の通信サービスを収容する所定の通信装置群を特定する特定部と、
前記特定部で特定された所定の通信装置群に含まれる通信装置の各々でコマンドを実行することで、前記所定の通信装置群に含まれる各々の通信装置の動作状態を示す所定のコマンド応答を収集する収集部と、
前記通信ネットワークにおける通信サービスを収容する複数の通信装置から収集されたコマンド応答に基づいて生成された特徴ベクトルと、該特徴ベクトルに対応する故障種別を示すラベルと、を対応づけた教師データを用いて学習された学習済モデルと、
前記所定のコマンド応答に基づき、前記所定の通信サービスにおける故障種別を判別する判別部と、
前記判別部で判別された前記故障種別を出力する出力部と、
を有し、
前記判別部は、前記所定のコマンド応答に基づいて生成された所定の特徴ベクトルを前記学習済モデルに入力し、前記学習済モデルから出力される故障種別を示すラベルを取得することで、前記所定の通信サービスにおける故障種別を判別する、
診断システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、診断装置、診断方法、プログラム及び診断システムに関する。

【背景技術】

【0002】

例えば、特許文献１には、通信事業者（キャリア）が管理するＩＰ中継網で利用するネットワーク装置及びその通信経路の監視技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００５－１８４６３８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

通信事業者は、通信ができない等の申告をユーザから受けた場合、通信ネットワークを構成する各通信機器に対して様々なコマンドを投入し、その応答結果を確認することで、故障診断を行っている。しかしながら、近年における通信ネットワークの規模及びサービスの拡大に応じて、通信ネットワークを構成する通信機器の数及び種別が多様化している。更に、通信機器ごとに診断方法も異なっていることから、通信事業者が行う故障診断業務は、非常に煩雑化している。

【0005】

本開示は、このような状況を鑑みてなされたものであって、通信ネットワークにおける故障種別の特定を効率化することを目的とする。

【課題を解決するための手段】

【0006】

本発明の一態様に係る診断装置は、通信ネットワークに含まれる複数の通信装置の中から、所定の通信サービスを収容する所定の通信装置群を特定する特定部と、前記特定部で特定された所定の通信装置群に含まれる通信装置の各々にコマンドを入力することで、前記所定の通信装置群に含まれる各通信装置の動作状態を示す所定のコマンド応答を収集する収集部と、前記所定のコマンド応答に基づき、前記所定の通信サービスにおける故障種別を判別する判別部と、前記判別部で判別された前記故障種別を出力する出力部と、を有する。

【図面の簡単な説明】

【0007】

【図1】本実施形態に係る診断システムのシステム構成例を示す図である。

【図2】診断装置及び通信装置のハードウェア構成例を示す図である。

【図3】診断装置の機能ブロック構成例を示す図である。

【図4】通信装置の機能ブロック構成例を示す図である。

【図5】特徴ベクトルを説明するための図である。

【図6】特徴ベクトルに付与されたラベルの一例を示す図である。

【図7】故障種別の判別を行う処理手順の一例を示すフローチャートである。

【図8】ＮＷ構成ＤＢの一例を示している。

【図9】コマンド及び確認ルールの一例を示す図である。

【図10】特徴ベクトルのクラスタリングを行うことで教師データを生成する処理手順の一例を示すフローチャートである。

【図11】クラスタリングによりラベルが付与された特徴ベクトルの一例を示す図である。

【図12】特徴ベクトルを可視化した例を示す図である。

【図13】決定木を用いた学習済モデルの一例を示す図である。

【発明を実施するための形態】

【0008】

添付図面を参照して、本発明の実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

【0009】

＜システム構成＞
図１は、本実施形態に係る診断システム１のシステム構成例を示す図である。診断システム１は、診断装置１０と、複数の通信ネットワークＮ１～Ｎ４と、ユーザネットワークＵを含む。

【0010】

通信ネットワークＮ１～Ｎ４は、通信事業者が管理する通信ネットワークである。通信ネットワークＮ１～Ｎ４は、通信事業者が管理する施設に配置される複数の通信装置２０－１～２０－１７により構成されている。通信装置２０は、例えば、ルータ、スイッチ、ハブ、ファイアウォール、ＯＮＵ（Optical Network Unit）等のネットワーク機器である。以下の説明において、複数の通信装置２０－１～２０－１７を区別しない場合、通信装置２０と記載する。また、通信ネットワークＮ１～Ｎ４を構成する通信装置２０の数に制限はない。また、図１の例では、通信事業者が管理する通信ネットワークとして通信ネットワークＮ１～Ｎ４の４つが図示されているが、通信事業者が管理する通信ネットワークの数に制限はない。以下の説明において、通信ネットワークＮ１～Ｎ４を区別しない場合、通信ネットワークＮと記載する。図示しないが、通信ネットワークＮ（例えば通信ネットワークＮ４）は、インターネットに接続されていてもよい。

【0011】

ユーザネットワークＵは、ユーザが管理する通信ネットワークである。ユーザが管理する通信ネットワークには、例えば、個人ユーザ宅内の無線ＬＡＮ通信環境や、企業ユーザのネットワーク等が含まれる。図１の例では、ユーザネットワークＵのみが図示されているが、ユーザネットワークの数に制限はない。

【0012】

通信ネットワークＮ１は、ユーザネットワークＵと接続することから、アクセスネットワーク（アクセス網）と呼ばれてもよい。一方、通信ネットワークＮ２～Ｎ４は、コアネットワーク（コア網）と呼ばれてもよい。

【0013】

診断装置１０は、通信事業者が管理する通信ネットワークＮ１～Ｎ４を構成する複数の通信装置２０の動作状態を監視する装置である。より具体的には、診断装置１０は、各通信装置２０から受信したコマンド応答に基づいて、通信装置２０が有する各インタフェースの状態や、通信装置２０本体の処理負荷などを監視する。通信装置２０が備えるインタフェースとは、ケーブルを接続する物理的なインタフェース、及び／又は、物理的なインタフェース内に作成される論理的なインタフェースを意味する。論理的なインタフェースは、仮想的なインタフェースと呼ばれることもある。

【0014】

ここで、現在行われている、ネットワーク運用業務における通信サービス故障対応業務のフローを説明する。まず、通信サービス故障を検知したユーザは、各ユーザに割り振られたサービスＩＤをキーに窓口へ申告を行う。通信事業者のオペレータは、サービスＩＤをキーにユーザの通信サービスを収容する通信ネットワーク（例えばアクセスネットワークや中継ネットワーク等）および通信装置２０を確認し、各通信装置２０に対して遠隔ログインして、故障診断を行うためのコマンドを実行し、故障被疑箇所を特定する。

【0015】

さらに、故障復旧対応に関する作業者手配や現地における復旧作業指示、正常性確認結果等の情報連携を、故障対応システムを用いて作業者が利用する端末との間で行う。各コマンドには、応答結果をもとに故障診断を行うための確認ルールが存在する。確認ルールは、通信ネットワークごとで確認内容は異なり、それに応じて各通信ネットワークおよび各通信装置２０で実行すべきコマンドも異なる。このため、ある故障に対して、故障箇所・原因特定といった故障診断を行うためには、ユーザが収容される全ての通信装置２０に関するコマンド応答結果を確認し、その結果をもとに判断する必要がある。また、通信装置２０ごとに実行すべきコマンドは大量に存在し、またその応答結果も目視で判断することを前提とした複雑なテキストメッセージである。従って、現状の故障診断業務はオペレータの専門知識に依存した手作業を中心としたものとなっている。

【0016】

（診断システムの概要）
診断装置１０は、通信事業者が提供するサービスを利用するユーザから、例えば電話やメール等を介して通信ができない等の申告を受け付けると、申告されたサービスＩＤをキーに、通信ネットワークＮ１～Ｎ３に含まれる複数の通信装置２０の中から、当該ユーザの通信サービスを収容する複数の通信装置２０を特定する。例えば図１の例では、ユーザの通信サービスが通る経路は図１の太線に該当し、ユーザの通信サービスを収容する複数の通信装置２０は、通信装置２０－３、２０－４、２０－８、２０－９及び２０－１３に該当する。次に、診断装置１０は、特定された、当該ユーザの通信サービスを収容する複数の通信装置２０に遠隔ログインし、通信装置２０の動作状態を確認するコマンドを実行することで、各通信装置２０から、各通信装置２０の動作状態を示すコマンド応答を収集する。次に、診断装置１０は、収集したコマンド応答結果に基づいて、故障種別を判別する。

【0017】

なお、本実施形態において、「故障事象」は、学習に用いる特徴ベクトルを構成するものであり、「故障種別」は、ラベルとして各故障事象に付与され、推定されるものである。言い換えると、「故障事象」は、“実際に生じた”故障の内容を意味しており、「故障種別」は、“推定される”故障の内容を意味する。

【0018】

本実施形態では、診断装置１０は、以下の３つの機能のうち少なくとも１以上の機能を提供する。
１．教師あり学習を用いた故障種別の判別機能：コマンド応答データに基づいて生成された特徴ベクトルに故障種別をラベルとして付与することで生成されたラベル付き特徴ベクトルを教師データとして学習済モデルを事前に生成し、ユーザ申告をトリガに収集されたコマンド応答に基づく特徴ベクトルを、学習済モデルに入力することで、故障種別を判別する機能。ラベル付き特徴ベクトルは、過去の故障診断業務により予めで生成されたものである。
２．教師なし学習を用いた教師データ作成補助機能：過去に収集された各通信装置２０からの多数のコマンド応答に基づいて生成した特徴ベクトルを、教師なし学習を用いてクラスタリングすることで特徴ベクトルを複数のクラスに分類し、各クラスに対し故障種別を示すラベルを付与することで生成されたラベル付き特徴ベクトルを、教師データとする機能。
教師なし学習を用いた教師データ作成補助機能は、例えば、過去の故障診断業務により予め生成されたラベル付き特徴ベクトルの数が、モデルを学習させるのに十分な数ではない場合に利用することを想定している。なお、クラスタリングとは、複数のデータを、データ間の類似度に基づいて複数のグループにグループ分けすることである。また、各クラスと具体的な故障事象との対応づけは、通信事業者のオペレータ等により予め行われる前提である。
３．投入コマンド最適化機能：ラベル付き特徴ベクトルを用いて決定木を学習させ、学習させた決定木を用いて、通信装置２０が備える多数のコマンドの中から、故障種別の特定に有効なコマンドを抽出することで、通信装置２０からコマンド応答を効率的に収集可能とする機能。

【0019】

＜機能ブロック構成＞
図２は、診断装置１０及び通信装置２０のハードウェア構成例を示す図である。診断装置１０及び通信装置２０は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphical Processing Unit）等のプロセッサ１１、メモリ、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等の記憶装置１２、有線又は無線通信を行う通信ＩＦ（Interface）１３、入力操作を受け付ける入力デバイス１４、及び情報の出力を行う出力デバイス１５を有する。診断装置１０の入力デバイス１４は、例えば、キーボード、タッチパネル、操作パネル、入力端子、マウス及び／又はマイク等である。出力デバイス１５は、例えば、ディスプレイ、出力端子、タッチパネル及び／又はスピーカ等である。

【0020】

（診断装置）
図３は、診断装置１０の機能ブロック構成例を示す図である。診断装置１０は、記憶部１００と、コマンド生成部１０１と、収集部１０２と、前処理部１０３と、判別部１０４と、出力部１０５と、受付部１０６と、生成部１０７と、学習処理部１０８と、クラス分類部１０９とを含む。記憶部１００は、診断装置１０が備える記憶装置１２を用いて実現することができる。また、コマンド生成部１０１と、収集部１０２と、前処理部１０３と、判別部１０４と、出力部１０５と、受付部１０６と、生成部１０７と、学習処理部１０８と、クラス分類部１０９とは、診断装置１０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

【0021】

記憶部１００は、ＮＷ（Network）構成ＤＢ（Data Base）１００ａ、学習済モデル１００ｂ、コマンド応答ＤＢ１００ｃ及び教師データＤＢ１００ｄを記憶する。

【0022】

ＮＷ構成ＤＢ１００ａは、通信ネットワークＮを構成する各通信装置２０の接続関係、通信装置２０の機種、各ユーザの通信サービスを収容する通信装置２０、各通信装置２０において各ユーザの通信サービスを収容するインタフェース及びポートの識別子を示す情報等を格納する。

【0023】

学習済モデル１００ｂは、複数の通信装置２０から収集されたコマンド応答に基づいて生成された特徴ベクトルを入力すると、推定される故障種別を示すラベルを出力する能力を有するように学習されたモデルである。学習済モデル１００ｂは、通信ネットワークＮにおける通信サービスを収容する複数の通信装置２０から収集されたコマンド応答に基づいて生成された特徴ベクトルと、該特徴ベクトルに対応する故障種別を示すラベルと、を対応づけた教師データを用いて学習することで生成される。

【0024】

学習済モデル１００ｂには、例えば、決定木（例えばCART、XG Boost等）、ＳＶＭ（サポートベクターマシン）、ニューラルネットワーク、多層ニューラルネットワーク、ランダムフォレスト、ロジスティック回帰分析など、どのようなモデルが利用されてもよい。

【0025】

コマンド応答ＤＢ１００ｃは、通信事業者のオペレータ等が故障事象を特定した際に、ユーザの通信サービスを収容する複数の通信装置２０にコマンドを送信することで収集されたコマンド応答を格納する。コマンド応答ＤＢ１００ｃには、過去に故障切り分けを行った際に収集されたコマンド応答が大量に格納されている。コマンド応答ＤＢ１００ｃは、「教師なし学習を用いた教師データ作成補助機能」で使用することを想定している。

【0026】

教師データＤＢ１００ｄは、ユーザの通信サービスを収容する複数の通信装置２０から得られたコマンド応答に基づいて生成された特徴ベクトルと、故障種別の正解を示すラベルとを対応づけた、教師データを格納する。前述した学習済モデル１００ｂは、当該教師データＤＢ１００ｅを用いて学習されたものであってもよい。教師データＤＢ１００ｄは、過去の故障診断業務を通じて予め生成されたものであってもよいし、「教師なし学習を用いた教師データ作成補助機能」を利用して生成されたものであってもよい。

【0027】

コマンド生成部１０１は、通信ネットワークＮに含まれる複数の通信装置２０の中から、所定の通信サービスを収容する所定の通信装置群を特定し、特定した所定の通信装置群に実行させるコマンドを生成する。所定の通信サービスは、診断装置１０が故障種別を調査する対象の通信サービスであり、例えば、故障申告を受けたユーザの通信サービスであってもよい。

【0028】

なお、所定の通信サービスは、どのような通信サービスも含まれるが、例えば、ユーザネットワークＵから通信ネットワークＮを通ってインターネットに抜ける通信サービス（若しくはその逆）、又は、あるユーザネットワークＵ（例えばユーザ企業の拠点Ａ）から通信ネットワークＮを通って他のユーザネットワークＵ（例えば同一ユーザ企業の拠点Ｂ）に向ける通信サービス（若しくはその逆）などが挙げられる。また、所定の通信装置群は、通信ネットワークＮに存在する多数の通信装置２０の中から、調査対象の通信サービスを流れるデータが通過する１以上の通信装置２０を意味する。

【0029】

収集部１０２は、コマンド生成部１０１で特定された所定の通信装置群に含まれる通信装置２０の各々で、コマンド生成部１０１で生成されたコマンドを実行することで、所定の通信装置群に含まれる各通信装置２０の動作状態を示す所定のコマンド応答を収集する。

【0030】

前処理部１０３は、収集部１０２で収集された所定のコマンド応答に基づいて特徴ベクトルを生成する。

【0031】

判別部１０４は、収集部１０２で収集された所定のコマンド応答に基づき、所定の通信サービスにおける故障種別を判別する。より具体的には、判別部１０４は、収集部１０２で収集された所定のコマンド応答に基づいて前処理部１０３で生成された特徴ベクトルを学習済モデル１００ｂに入力し、学習済モデル１００ｂから出力される故障種別を示すラベルを取得することで、所定の通信サービスにおける故障種別を判別するようにしてもよい。

【0032】

出力部１０５は、判別部１０４で判別された故障種別を出力する。例えば、出力部１０５は、診断装置１０又は診断装置１０に接続される装置が備えるディスプレイに、故障種別を示す情報を表示させるようにしてもよい。

【0033】

受付部１０６は、判別部１０４により判別された、所定の通信サービスにおける故障種別が正解又は誤りであるかと、当該所定の通信サービスにおける故障種別が誤りであった場合における正しい故障種別とを、例えば通信事業者のオペレータ等から受け付ける。

【0034】

生成部１０７は、受付部１０６で、所定の通信サービスにおける故障種別が正解であることを受け付けた場合に、収集部１０２で収集された所定のコマンド応答に基づいて生成された特徴ベクトルと判別部１０４により判別された当該所定の通信サービスにおける故障種別を示すラベルとを対応づけた教師データを生成し、教師データＤＢ１００ｄに格納する。また、生成部１０７は、受付部１０６で、所定の通信サービスにおける正しい故障種別を受け付けた場合に、収集部１０２で収集された所定のコマンド応答に基づいて生成された特徴ベクトルと受付部１０６で受け付けた正しい故障種別を示すラベルとを対応づけた教師データを生成し、教師データＤＢ１００ｄに格納する。

【0035】

学習処理部１０８は、教師データＤＢ１００ｅを用いてモデルを学習させることで、学習済モデル１００ｂを生成する。

【0036】

クラス分類部１０９は、コマンド応答ＤＢ１００ｃに格納されている複数の通信装置２０から収集された複数のコマンド応答に基づいて生成された特徴ベクトルを、教師なし学習を用いて複数のクラスにクラスタリングする処理を行う。また、クラス分類部１０９は、各特徴ベクトルに、各特徴ベクトルが属するクラスに対応する故障種別を示すラベルを付与してデータベースに格納することで、教師データＤＢ１００ｄを生成する。学習処理部１０８は、当該教師データＤＢ１００ｄに格納された特徴ベクトルと、当該特徴ベクトルが属するクラスタに対応するラベルとを教師データとしてモデルを学習させることで、学習済モデル１００ｂを生成するようにしてもよい。

【0037】

更に、コマンド生成部１０１は、決定木を用いて学習させた学習済モデル１００ｂについて、当該学習済モデル１００ｂにおける決定木の分岐に用いられる特定コマンドを抽出する。例えば、コマンド生成部１０１は、学習済みの決定木における各分岐の判定に用いられている全てのコマンドを、当該特定コマンドとして抽出するようにしてもよい。

【0038】

更に、収集部１０２は、所定の通信装置群に含まれる通信装置の各々で、少なくともコマンド生成部１０１で抽出された特定コマンドに含まれるコマンドを実行することで、当該所定の通信装置群に含まれる通信装置の動作状態を示す所定のコマンド応答を収集するようにしてもよい。

【0039】

（通信装置）
図４は、通信装置２０の機能ブロック構成例を示す図である。通信装置２０は、記憶部２００と、通信処理部２０１と、管理部２０２と、入力部２０３と、出力部２０４とを含む。記憶部２００は、通信装置２０が備える記憶装置１２を用いて実現することができる。また、通信処理部２０１は、通信装置２０が備える通信ＩＦ１３を用いて実現することができる。また、管理部２０２と、入力部２０３と、出力部２０４とは、通信装置２０のプロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

【0040】

記憶部２００は、ルーティングテーブルや各種の設定情報等、通信装置２０の動作に必要な各種の情報を記憶する。通信処理部２０１は、ルーティングテーブル等に基づいて、受信したデータのルーティングを行う。管理部２０２は、通信装置２０の動作状態（ＣＰＵ使用率、メモリ使用率、各インタフェースの状態、データの送受信状態など）を管理する。入力部２０３は、通信装置２０が備えるコマンド等の入力を受け付ける。出力部２０４は、通信装置２０の動作状態を示すコマンド応答を診断装置１０に送信する。

【0041】

＜処理手順＞
（特徴ベクトルの構成）
診断装置１０は、申告された通信サービスを収容する各通信装置２０へログインし、故障診断に必要な一連のコマンド（以下、「コマンド系列」と言う）を実行する。さらに、全ての装置コマンドの応答結果を特徴ベクトルへと変換し、特徴ベクトルを学習済モデル１００ｂに入力することによって故障種別の推定を行う。

【0042】

診断装置１０は、申告された通信サービスを収容する各通信装置２０から得られるコマンド応答の確認結果を結合し、故障事象ごとに１つの特徴ベクトルを構築する。ここで、各ユーザの通信サービスを収容する通信装置２０に対して実行するコマンドの種別は、通信装置２０によって異なっており、更に、各ユーザの通信サービスを収容する通信装置２０は、ユーザごと異なる。そこで、本実施形態では、特徴ベクトルの次元が、全てのユーザにおいて同一次元となるようにするため、診断装置１０が管理する、各ユーザの通信サービスを収容する全ての通信装置２０の全ての装置コマンド数を、その次元数とする。例えば、各ユーザの通信サービスを収容する全ての通信装置２０の全ての装置コマンドが合計で３５０コマンドである場合、特徴ベクトルは、３５０次元のベクトルになる。

【0043】

次に、通信装置２０からのコマンド応答は、人間が目視で判断することを前提とした複雑なテキストメッセージで構成されている。しかしながら、診断装置１０は、学習済モデル１００ｂを利用して故障種別の判別を行うことから、通信装置２０から収集するコマンド応答を、学習済モデル１００ｂで扱えるようにする必要がある。そこで、診断装置１０は、各通信装置２０のコマンドの応答結果と、事前定義された確認ルールとを照合し、各コマンドの応答内容に対する確認結果を実数に変換することで、特徴ベクトルを生成する。実数は、例えば０（正常）／１（異常）であってもよいし、更に複数の数値に分類されてもよい。

【0044】

図５は、特徴ベクトルを説明するための図である。なお、図５の例では、通信ネットワークＮ１～Ｎ４が図示されているが、図示の便宜上であり、通信ネットワークＮの数に制限はない。図５において、「通信ネットワーク」は、各ユーザの通信サービスを収容する全ての通信ネットワークＮであり、「通信装置」は、各通信装置２０に設置されている、各ユーザの通信サービスを収容する全ての通信装置２０である。また、「コマンドＩＤ」は、各ユーザの通信サービスを収容する全ての通信装置２０の全ての装置コマンドを一意に識別する識別子である。例えば、各ユーザの通信サービスを収容する全ての通信装置２０の全ての装置コマンドが合計で３５０コマンドである場合、Ｃｎ＝Ｃ３４９になる。

【0045】

１つの特徴ベクトルは、Ｃ１～Ｃｎまでのコマンド応答を、事前定義された確認ルールに従って０又は１に変換することで生成される。例えば、Ｃ０＝０、Ｃ１＝０、Ｃ２＝１、・・・、Ｃ３４９＝０のように変換された場合、特徴ベクトルは、（Ｃ０、Ｃ１、Ｃ２、・・・・、Ｃ３４９）＝（０、０、１、・・・、０）の形になる。

【0046】

（学習済モデルの生成）
学習処理部１０８は、教師データＤＢ１００ｄから教師データ（すなわちラベル付き特徴ベクトル）を取得し、モデルを学習させることで学習済モデル１００ｂを生成する。図６は、特徴ベクトルに付与されたラベルの一例を示す図である。図６の表の各要素は、９種類のラベルＩＤ及び故障種別を示している。ラベル付き特徴ベクトルは、例えば、（ラベルＩＤ、Ｃ０、Ｃ１、Ｃ２、・・・・、Ｃ３５０）＝（５、０、０、１、・・・、０）といった形式の特徴ベクトルになる。

【0047】

学習処理部１０８は、事前に設定が必要な各種パラメータをモデルにセットし、教師データを用いて学習を行う。また、学習処理部１０８は、学習済モデル１００ｂを検証するための検証データを用いて、学習済モデル１００ｂが適切に学習されているか否かを検証する。学習済モデル１００ｂが十分に学習されていない場合、パラメータの変更、学習及び検証を繰り返す。学習済モデル１００ｂに格納されている学習用データの一部が、検証データとして利用されてもよい。

【0048】

（教師あり学習を用いた故障種別の判別）
図７は、診断装置１０が、故障種別の判別を行う処理手順の一例を示すフローチャートである。図７の例において、学習済モデル１００ｂは、図６に示す故障種別を示すラベルを出力する能力を有しているものとする。

【0049】

ステップＳ１０で、ユーザから故障申告を受けた場合、コマンド生成部１０１は、ＮＷ構成ＤＢ１００ａを参照し、申告を受けたユーザの通信サービスを収容する複数の通信装置２０を特定する。

【0050】

図８は、ＮＷ構成ＤＢ１００ａの一例を示す図である。図８の例は、各サービスＩＤで特定される通信サービスのトラフィックが、各通信ネットワークＮ１～Ｎ４において、どの通信装置２０をどの順に通るのかを示している。例えば、サービスＩＤ１の通信サービスのトラフィックは、通信ネットワークＮ１～Ｎ４において、Ａ１、Ａ２、Ｂ１、Ｂ２、Ｃ１、Ｃ２、Ｄ１及びＤ２の通信装置２０を通ることを示している。なお、図８は一例に過ぎず、各ユーザの通信サービスは、更に多くの通信ネットワークＮや通信装置２０を通過することもあり得る。また、各通信ネットワークＮを構築する通信装置２０には異なる機種の通信装置２０が含まれていてもよい。また、ＮＷ構成ＤＢ１００ａには、各通信装置２０において、サービスＩＤで特定される通信サービスを収容する物理ポート番号（又は仮想ポート番号）及びインタフェース番号等が、サービスＩＤと対応づけて格納されていてもよい。

【0051】

また、コマンド生成部１０１は、特定された、ユーザの通信サービスを収容する複数の通信装置２０に実行させる、故障診断に必要なコマンド系列を生成する。コマンド生成部１０１は、通信装置２０ごとに予め定められたルールに従ってコマンド系列を生成するようにしてもよい。通信装置２０で実行されるコマンド及び確認ルールの一例を図９に示す。

【0052】

ステップＳ１１で、収集部１０２は、ステップＳ１０で特定された各通信装置２０にログインし、生成されたコマンド系列を実行することで、コマンド応答を収集する。

【0053】

ステップＳ１２で、前処理部１０３は、ステップＳ１１で収集されたコマンド応答に対し前処理を行うことで、特徴ベクトルを生成する。具体的には、前処理部１０３は、受信したコマンド応答群を、事前定義された確認ルールにより０又は１に変換することで特徴ベクトルを生成する。ここで、前処理部１０３は、特徴ベクトル（Ｃ０～Ｃｎ）のうち、受信したコマンド応答には含まれていないコマンドＩＤに対応する次元については、「０（正常）」をセットする。例えば、特徴ベクトルが、Ｃ０～Ｃ３４９の３５０次元である場合で、コマンド応答には、コマンドＩＤが０～３９、６０～９９、２００～２１９である合計１００個のコマンド応答が含まれていたものとする。この場合、前処理部１０３は、特徴ベクトル（Ｃ０～Ｃ３４９）のうち、４０～５９、１００～１９９、２２０～３４９のコマンドＩＤに対応する次元については、「０（正常）」をセットする。

【0054】

ステップＳ１３で、判別部１０４は、ステップＳ１２で生成された特徴ベクトルを学習済モデル１００ｂに投入する。続いて、判別部１０４は、学習済モデル１００ｂから出力される、故障種別を示すラベルを取得する。続いて、出力部１０５は、学習済モデル１００ｂから出力されたラベルに対応する故障種別を示す情報（例えば図７の故障種別に示す文言）を、ディスプレイ等に出力する。

【0055】

なお、受付部１０６は、ディスプレイに表示された故障種別を参考に実際の故障解析を行った通信事業者のオペレータから、ステップＳ１３の処理手順で出力された故障種別が正しいか否かを示す情報、及び、故障種別が誤っている場合には、正しい故障種別を示すラベルの入力を受け付けるようにしてもよい。また、生成部１０７は、正しい故障種別を示すラベルの値と、ステップＳ１２の処理手順で生成した特徴ベクトルとを対応づけて新たなラベル付き教師データを生成し、教師データＤＢ１００ｄを更新するようにしてもよい。このように新たな教師データが追加された教師データＤＢ１００ｄを利用することで、学習済モデル１００ｂを追加学習させることも可能になる。

【0056】

（教師なし学習におけるクラスタリング処理）
図１０は、特徴ベクトルのクラスタリングを行うことで教師データを生成する処理手順の一例を示すフローチャートである。

【0057】

ステップＳ２１で、前処理部１０３は、コマンド応答ＤＢ１００ｃに格納されている各コマンド応答から特徴ベクトルを生成する。なお、前処理部１０３は、図７のステップＳ１２で説明した処理手順と同一の処理手順により特徴ベクトルを生成する。続いて、クラス分類部１０９は、生成された複数の特徴ベクトルについて、例えばｋ－ｍｅａｎｓ法を用いてクラスタリングを行う。ここでは、複数の特徴ベクトルが、例えば５つのクラスにクラスタリングされたものとする。クラス分類部１０９は、５つのクラスにクラスタリングされた各特徴ベクトルに対してラベル（例えば１～５）を付与する。

【0058】

ステップＳ２２で、受付部１０６は、通信事業者のオペレータから、ラベル付けされた５つのクラスについての具体的な故障種別を示す情報の入力を受け付ける。このとき、受付部１０６は、クラスタリング処理を行うオペレータ等から、クラス分類部１０９により各特徴ベクトルに付与されたラベルの修正を受け付けるようにしてもよい。

【0059】

図１１は、クラスタリングによりラベルが付与された特徴ベクトルを格納するデータベースの一例を示す図である。図１１のＡにおける１つの行は、特徴ベクトルと、当該特徴ベクトルに付与されたラベルとを示している。また、図１１のＢは、通信事業者のオペレータが、５つのクラスに対し具体的な故障種別を付与した例を示している。

【0060】

ステップＳ２３で、生成部１０７は、ステップＳ２１の処理手順及びステップＳ２２の処理手順で得られたラベル付き特徴ベクトルを格納した教師データＤＢ１００ｄを、記憶部１００に格納する。その後、学習処理部１０８は、記憶部１００に格納された教師データＤＢ１００ｄを用いて、学習済モデル１００ｂを生成する。

【0061】

（投入コマンド最適化）
本実施形態では、最小のコマンド数で故障種別の推定を行うために、故障種別推定に用いる決定木の情報を利用することで、通信装置２０に実行させる最適なコマンド系列を事前に生成するようにしてもよい。決定木は、特徴ベクトルの分類に関する規準を節点に、各特徴ベクトルが最終的に分類されるラベルを葉に持つ木構造により表現される。決定木における各節点は、特徴ベクトルのどの要素が何の値であるか、すわなち、対応するコマンドの確認結果を表しており、節点の情報を確認することで、どのコマンドを実行・確認すべきかが把握できる。したがって、根から順に節点を辿り、各節点で利用されているコマンドを抽出することで、故障種別推定の観点から最適なコマンド系列を獲得することができる。

【0062】

図１２は、故障申告を受け付けた際に各通信装置２０から収集された特徴ベクトルを可視化した例を示す図である。図１２の縦軸は、コマンド種別（つまり特徴ベクトルの次元数であり、ここでは３５０次元）に対応し、横軸は各故障事象に対応している。

【0063】

図１２において点が存在する場所は、コマンド応答が異常であることを示している。ここで、図１２に示すように、３５０個のコマンドのうち、異常を示すコマンドには偏りがある。つまり、３５０個のコマンドのうち、故障種別の特定に役立つコマンドは一部に限られることを示している。

【0064】

そこで、コマンド生成部１０１は、決定木である学習済モデル１００ｂに入力する複数の特徴ベクトルのうち、決定木の中で分岐に用いられている特定コマンドを抽出する。図１３は、決定木を用いた学習済モデル１００ｂの一例を示す図である。例えば、図１３に示す決定木は、Ｃ０～Ｃ３５０までのコマンドが投入されると、最も可能性が高い故障種別を示すラベル（ｉ）を出力するように学習されているものとする。図１５の例では、３５０次元を構成する３５０個のコマンドのうち、Ｃ４、Ｃ１６、Ｃ７０、Ｃ８０、Ｃ１００及びＣ２００が分岐に用いられている。従って、コマンド生成部１０１は、特定コマンドとして、コマンドＣ４、Ｃ１６、Ｃ７０、Ｃ８０、Ｃ１００及びＣ２００を抽出するようにしてもよい。

【0065】

なお、投入コマンド最適化機能を実現するにあたり、故障種別の判別機能に用いるための学習済モデル１００ｂと、投入コマンド最適化機能にて分析する決定木は、同一のモデルであってもよいし異なるモデルであってもよい。例えば、学習処理部１０８は、最適なコマンド系列を得るために、故障種別の判別機能に用いるための学習済モデル１００ｂとは別個に決定木のモデルを作成するようにしてもよい。

【0066】

前述した図７のステップＳ１１の処理手順において、コマンド生成部１０１は、特定された複数の通信装置２０に実行させる、故障診断に必要なコマンド系列を生成する際、投入コマンド最適化機能で抽出された特定コマンドの範囲でコマンド系列を生成するようにしてもよい。つまり、収集部１０２で自動実行されるコマンドは、決定木の情報に基づき、故障種別の判別が可能な最小のコマンド実行数に絞られることになる。これにより、故障種別の判別結果には影響しない不要なコマンドを各通信装置２０に送信する必要がなくなることから、故障種別の判定をより迅速に行うことが可能になる。

【0067】

＜まとめ＞
以上説明した実施形態によれば、診断装置１０は、教師あり学習により生成された学習済みモデルに特徴ベクトルを入力することで、故障種別を判別するようにした。これにより、通信ネットワークにおける故障種別の特定を効率化することが可能になる。また、診断装置１０は、故障申告を受けた際に収集したコマンド応答を、教師なし学習によりクラスタリングすることで、教師データの作成を補助するようにした。これにより、過去の故障診断業務で作成された教師データの数が十分ではない場合であっても、学習済みモデルを生成することが可能になる。

【0068】

また、診断装置１０は、学習済モデル１００ｂによる判定結果が、実際の故障種別とは異なっていたとオペレータにより判断された場合、正解の故障種別を受け付けるとともに、受け付けた正解の故障種別と、収集されたコマンド応答に基づき生成された特徴ベクトルとを対応づけて教師データとして保存するようにした。これにより、教師あり学習を進めるために必要な教師データを効率的に収集することが可能になる。

【0069】

また、診断装置１０は、決定木を用いた学習済モデル１００ｂを利用し、決定木の中で分岐に用いられている特定コマンドを抽出するようにした。これにより、故障種別の判別には使われない不要なコマンドを各通信装置２０に送信する必要がなくなることから、コマンド応答を効率的に収集することが可能になる。

【0070】

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。

【0071】

なお、本実施形態において、コマンド生成部１０１は、特定部及び抽出部の一例である。

【符号の説明】

【0072】

１…診断システム、１０…診断装置、１１…プロセッサ、１２…記憶装置、１３…通信ＩＦ、１４…入力デバイス、１５…出力デバイス、２０…通信装置、１００…記憶部、１００ａ…ＮＷ構成ＤＢ、１００ｂ…学習済モデル、１００ｃ…コマンド応答ＤＢ、１００ｄ…教師データＤＢ、１０１…コマンド生成部、１０２…収集部、１０３…前処理部、１０４…判別部、１０５…出力部、１０６…受付部、１０７…生成部、１０８…学習処理部、１０９…クラス分類部、２００…記憶部、２０１…通信処理部、２０２…管理部、２０３…入力部、２０４…出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】