JP2018533280A

JP2018533280A - トラブルシューティング方法及び装置

Info

Publication number: JP2018533280A
Application number: JP2018514977A
Authority: JP
Inventors: 文革 ▲張▼; 日 ▲東▼ 徐; 勇 ▲陣▼; 清明劉; 太洲 ▲陣▼; 福祥熊
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-09-22
Filing date: 2016-09-07
Publication date: 2018-11-08
Anticipated expiration: 2036-09-07
Also published as: US20180212819A1; WO2017050130A1; EP3340535A4; JP6556346B2; EP3340535B1; EP3340535A1; CN105187249B; CN105187249A; US10601643B2

Abstract

この出願は、トラブルシューティング方法及び装置を提供する。そのトラブルシューティング方法は、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信し、それによって、管理ユニットが、トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む。この出願にしたがった方法及び装置を使用することによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。

Description

この出願は、2015年9月22日付で中国特許庁に出願された"トラブルシューティング方法及び装置"と題する中国特許出願番号第201510608782.1号に基づく優先権を主張し、その内容は、参照により全体が本明細書に取り込まれる。

この出願は、ネットワークデータ処理の分野に関し、特に、トラブルシューティング方法及び装置に関する。

通信システムにおいては、あるデバイスにおいて障害が発生する場合であって、長時間にわたってその障害をトラブルシューティングすることができないときに引き起こされるその通信システムのパフォーマンスに対する深刻な影響を回避するために、その障害をトラブルシューティングするための方法が必要となる。

トラブルシューティング方法は、手動で実行されてもよい。しかしながら、ある障害の手動による検出及びその後のその障害のトラブルシューティングは、通常、比較的高い時間的なコスト及び人件費につながる。したがって、産業界は、次第に、通信システムの中のデバイスが、その通信システムにおける障害を自動的にトラブルシューティングして、トラブルシューティングの効率を改善するとともに人件費を削減することを期待している。

従来技術のトラブルシューティング方法においては、あるデバイスが障害のある状態となっているか否かは、主として、そのデバイスのハートビートメッセージにしたがって決定される。具体的には、モニタリングしているデバイスは、モニタリングされているデバイスにハートビートメッセージを周期的に送信してもよく、そのハートビートメッセージを受信した後に、そのモニタリングされているデバイスは、モニタリングしているデバイスに応答メッセージを返送してもよい。モニタリングしているデバイスが、そのハートビートメッセージを送信した後のある指定された時間以内に、モニタリングされているデバイスが返送した応答メッセージを受信していない場合には、そのモニタリングされているデバイスが障害のある状態となっているということを決定し、さらに、そのモニタリングされているデバイスの全体がリセットされるか、又は、そのモニタリングされているデバイスが持っている機能が、トラブルシューティングのために、他のデバイスに切り替えられる。

一方で、モニタリングしているデバイスが、指定された時間以内に応答メッセージを受信していない原因が複数存在する場合がある。例えば、その原因は、モニタリングされているデバイスが応答メッセージを送信するのに使用するインターフェイスユニットが障害のある状態となっているということである場合がある。この場合には、そのモニタリングされているデバイスの全体のリセット又は機能の切り替えを伴うことなく、そのモニタリングされているデバイスの他のインターフェイスユニットを起動して、インターフェイスユニットを置き換えてもよい。モニタリングされているデバイスの全体のリセット又は機能の切り替えは、比較的高いリスクを引き起こし、比較的大きな数のサービスに影響を与える。

結論として、従来技術のトラブルシューティング方法においては、デバイスのハートビートメッセージにしたがって、ある障害を分析し、そして、その障害をトラブルシューティングするが、このことは、障害の特定の精度が比較的低くなることにつながる。

この出願の目的は、重要なパフォーマンスインジケータ情報を使用することによって障害を突き止めて、デバイスのハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決するトラブルシューティング方法及び装置を提供することである。

上記の目的を実現するために、この出願は、以下の解決方法を提示する。

この出願の第1の態様の第1の可能な実装によれば、この出願は、トラブルシューティング方法であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信し、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む、トラブルシューティング方法を提供する。

第1の態様の第2の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

第1の態様の第3の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

第1の態様の第2の可能な実装の第1の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
前記サービス成功率を第1の基準値と比較するステップと、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第1の態様の第2の可能な実装の第1の具体的な実装の第1のより具体的な実装に関して、前記サービス成功率を第1の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第1の態様の第2の可能な実装の第1の具体的な実装の第2のより具体的な実装に関して、サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップの前に、当該方法は、
均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定するステップと、をさらに含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第1の態様の第2の可能な実装の第2の具体的な実装に関して、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
前記サービス成功率を第3の基準値と比較するステップと、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第1の態様の第3の可能な実装の第1の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集するステップと、
前記サービス成功率を第2の基準値と比較するステップと、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定するステップと、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定するステップと、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第1の態様の第3の可能な実装の第1の具体的な実装の第1のより具体的な実装に関して、前記サービス成功率を第2の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。

第1の態様の第2の可能な実装の第3の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するステップを含む。

第1の態様の第3の可能な実装の第2の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットに前記トラブルシューティングポリシーを送信するステップを含む。

第1の態様の第2の可能な実装の第4の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後に、当該方法は、
障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定するステップと、
ネットワークレベルのトラブルシューティングポリシーを決定するステップと、をさらに含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第1の態様の第3の可能な実装の第3の具体的な実装に関して、ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用される、ステップと、を含むか、又は、
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、ステップと、を含む。

この出願の第2の態様の第1の可能な実装によれば、この出願は、トラブルシューティング装置であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニットと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニットと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するように構成され、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニットと、を含む、トラブルシューティング装置を提供する。

第2の態様の第2の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

第2の態様の第3の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するか、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第2の態様の第2の可能な実装の第1の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
前記サービス成功率を第1の基準値と比較し、そして、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定する、ように構成される。

第2の態様の第2の可能な実装の第1の具体的な実装の第1のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較するように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第2の態様の第2の可能な実装の第1の具体的な実装の第2のより具体的な実装に関して、前記決定ユニットは、さらに、
サービス成功率が前記第1の基準値よりも低い前記サービス処理ユニットが前記障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定し、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定し、そして、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第2の態様の第2の可能な実装の第2の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
前記サービス成功率を第3の基準値と比較し、そして、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定する、ように構成される。

第2の態様の第3の可能な実装の第1の具体的な実装に関して、前記決定ユニットは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
前記サービス成功率を第2の基準値と比較し、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定し、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定し、そして、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定する、ように構成される。

第2の態様の第3の可能な実装の第1の具体的な実装の第1のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。

第2の態様の第2の可能な実装の第3の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるということを決定した後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するように構成される。

第2の態様の第3の可能な実装の第2の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定した後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットに前記トラブルシューティングポリシーを送信するように構成される。

第2の態様の第2の可能な実装の第4の具体的な実装に関して、前記決定ユニットは、さらに、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第2の態様の第3の可能な実装の第3の具体的な実装に関して、前記取得ユニットは、さらに、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用されるか、又は、
前記取得ユニットは、さらに、前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される。

この出願によって提供される複数の特定の実施形態によれば、この出願は、以下の技術的効果を開示する。

この出願によって開示されるトラブルシューティング方法及び装置によれば、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。

さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。

本出願の複数の実施形態にしたがった複数の技術的解決方法をより明確に説明するために、以下の記載は、それらの複数の実施形態を説明するのに必要となる複数の添付の図面を簡潔に説明する。明らかなことではあるが、以下の説明の中の複数の添付の図面は、本発明の複数の実施形態のうちのいくつかを示しているにすぎず、当業者は、さらに、創造的な努力なくして、これらの複数の添付の図面から他の図面を導き出すことが可能である。

この出願にしたがったネットワーク機能仮想化(NFV)システムのアーキテクチャ図である。この出願にしたがったトラブルシューティング方法の実施形態1のフローチャートである。この出願にしたがったトラブルシューティング方法の実施形態2のフローチャートである。この出願にしたがったトラブルシューティング方法の実施形態3のフローチャートである。この出願にしたがったトラブルシューティング装置の1つの実施形態の構成図である。この出願にしたがった計算ノードの構成図である。

以下の記載は、本出願の複数の実施形態にしたがった複数の添付の図面を参照して、本出願のそれらの複数の実施形態にしたがった複数の技術的解決方法を明確に説明する。明らかなことではあるが、それらの説明される実施形態は、本出願の複数の実施形態のうちのいくつかに過ぎず、すべてではない。創造的な努力なくして当業者が本出願のそれらの複数の実施形態に基づいて取得することが可能であるすべての他の実施形態は、本出願の保護の範囲に属するものとする。

この出願の目的、特徴、及び利点をよりわかりやすくするために、この出願は、さらに、複数の添付の図面及び複数の特定の実施形態を参照して以下で詳細に解説される。

図1は、この出願にしたがったネットワーク機能仮想化(NFV)システムのアーキテクチャ図である。この出願にしたがったトラブルシューティング方法は、主として、NFVシステムに適用される。図1に示されているように、NFVシステムは、主に、
ネットワーク機能仮想化オーケストレータ(NFV Orchestrator)へのサービス要求を開始し、そして、あるサービスに必要なリソースを提供する、ように構成され、障害処理の役割を担う、オペレーションサポートシステム(Operations Support System, OSS)/ビジネスサポートシステム(Business Support System, BSS)と、
OSS/BSSのサービス要求にしたがってNFVサービスを実装する役割を担うとともに、ネットワークサービス(Network Service, NS)のライフサイクル管理の役割を担い、そして、管理リソースを組織化する役割を担い、及び、仮想化されたネットワーク機能(Virtualized Network Function, VNF)及びネットワーク機能仮想化インフラストラクチャ(Network Functions Virtualization Infrastructure, NFVI)のリソース及び実行状態情報をリアルタイムでモニタリングする役割を担うオーケストレータ(Orchestrator)と、
例えば、起動、有効期間、及びVNF実行状態情報の管理等のVNF生成周期の管理の役割を担う仮想化されたネットワーク機能マネージャ(VNF Manager, VNFM)と、
NFVIリソースを管理しそして割り当てる役割を担うとともに、NFVI実行状態情報をモニタリングしそして収集する役割を担う仮想化されたインフラストラクチャマネージャ(Virtualized Infrastructure Manager, VIM)と、
ネットワーク要素の障害管理、構成管理、課金管理、パフォーマンス管理、セキュリティ管理(Fault Management, Configuration Management, Accounting Management, Performance Management, Security Management, FCAPS)の役割を担う要素管理システム(Element Management System, EMS)と、を含む。

NFVIリソースは、利用可能な/予約された/割り当てられたNFVIリソース等のすべてのNFVIリソースを含む。

この出願にしたがったトラブルシューティング方法は、ネットワーク要素の重要なパフォーマンスインジケータ(Key Performance Indicator, KPI)モニタリング及びトラブルシューティング決定モジュール又はネットワークのKPIモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。ネットワーク要素のKPIモニタリング及びトラブルシューティング決定モジュール又はネットワークのKPIモニタリング及びトラブルシューティング決定モジュールは、NFVシステムの中のVNF、EMS、又は管理及びオーケストレータ(Management and Orchestrator, MANO)ユニットの中に配置されてもよく、又は、独立したネットワークノードに配置されてもよい。ネットワーク要素のKPIモニタリング及びトラブルシューティング決定モジュール及びネットワークのKPIモニタリング及びトラブルシューティング決定モジュールは、統合された方法で配置されてもよく、又は、個別に配置されてもよい。

図2は、この出願にしたがったトラブルシューティング方法の実施形態1のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素のKPIモニタリング及びトラブルシューティング決定モジュール又はネットワークのKPIモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図2に示されているように、上記の方法は、以下のステップを含む。

ステップ101: モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ(Key Performance Indicator, KPI)情報を取得する。

モニタリングされているネットワーク要素は、例えば、VNF等のネットワーク機能仮想化(Network Function Virtualization, NFV)システムの中のネットワーク要素である。

モニタリングされているネットワーク要素の中に1つ又は複数のサービス処理ユニットが存在してもよい。

重要なパフォーマンスインジケータ情報は、サービス処理ユニットが受信するサービス要求の数、サービス要求の数に対応しているサービス失敗の数、及び/又は各々のサービス失敗の原因等の情報を含んでもよい。実際の適用では、重要なパフォーマンスインジケータ情報に含まれる情報のタイプは、要求に応じて設定されてもよい。例えば、重要なパフォーマンスインジケータ情報は、サービス遅延情報等の情報をさらに含んでもよい。

モニタリングされているネットワーク要素は、重要なパフォーマンスインジケータ情報を周期的に報告してもよい。

ステップ101が実行される前に、さらに、EMS及び/又はMANOに関する情報にしたがって、モニタリングされることが必要であるネットワーク要素を決定してもよいということに留意すべきである。EMS及び/又はMANOによって記録されているネットワーク要素の内部に配置されているサービス処理ユニットに関する情報及びネットワークの中に配置されているネットワーク要素に関する情報を取得してもよい。ネットワークの中に配置されているネットワーク要素に関する記録された情報に対応するネットワーク要素は、モニタリングされているネットワーク要素として決定される。ネットワーク要素の内部に配置されているサービス処理ユニットに関する記録された情報に対応するサービス処理ユニットは、モニタリングされることが必要であるサービス処理ユニットとして決定される。

ステップ102: 重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定する。

例えば、重要なパフォーマンスインジケータ情報にしたがって、あるサービス処理ユニットによって実行されるサービスの成功率を算出してもよい。その成功率がある特定の比率よりも低い場合には、障害のあるオブジェクトがそのサービス処理ユニットであるということを決定してもよい。相対的に低い成功率を有するサービス処理ユニットの数が、(例えば、そのモニタリングされているネットワーク要素の中のサービス処理ユニットの合計数のうちの80％を超えるといったように)相対的に大きい場合には、障害のあるオブジェクトが、そのモニタリングされているネットワーク要素以外のネットワーク要素であるということを決定してもよい。他の例では、あるモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信のタイムアウトによって引き起こされるサービス失敗の重要なパフォーマンスインジケータ情報の中に記録されている数が、相対的に高い場合には、そのモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信パスが障害を持っているということ、又はその次のホップのネットワーク要素が障害を持っているということを決定してもよい。

ステップ103: 障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する。

障害のあるオブジェクトが、モニタリングされているネットワーク要素の内部に存在するあるサービス処理ユニットである場合には、ネットワーク要素レベルのトラブルシューティングポリシーを決定してもよい。そのネットワーク要素レベルのトラブルシューティングポリシーは、そのモニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

障害のあるオブジェクトがそのモニタリングされているネットワーク要素以外のネットワーク要素である場合には、ネットワークレベルのトラブルシューティングポリシーを決定してもよい。そのネットワークレベルのトラブルシューティングポリシーは、そのモニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

ステップ104: ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信し、それによって、その管理ユニットは、そのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する。

管理ユニットは、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールであってもよく、又は、ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットであってもよい。

ネットワーク要素レベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する手法は、以下の手法、すなわち、
障害のあるサービス処理ユニットの予備のユニットを決定し、そして、その障害のあるサービス処理ユニットが持っているサービスをその予備のユニットに切り替える手法、又は、
その障害にあるサービス処理ユニットをリセットする手法、を含んでもよく、
その予備のユニットが障害のある状態になった場合には、その障害のあるサービス処理ユニット及びその予備のユニットは、分離されてもよい。

ネットワークレベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する手法は、以下の手法、すなわち、
障害のあるネットワーク要素の予備のネットワーク要素を決定するステップと、
その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるステップと、を含む手法、又は、
障害のあるパスの予備のパスを決定するステップと、
その障害のあるパスが持っているサービスをその予備のパスに切り替えるステップと、を含む手法、を含んでもよく、
その予備のパスが障害のある状態になったということを決定する場合には、その予備のパスの側にあるネットワーク要素の予備のネットワーク要素をさらに決定してもよく、
その予備のパスの側にあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替える。

結論として、この実施形態においては、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。

実際の適用においては、障害のあるオブジェクトを決定するステップは、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定するステップ、を含んでもよい。

障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
障害のあるオブジェクトが、モニタリングされているネットワーク要素の中のサービス処理ユニットであるか、又は、サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含んでもよく、そのネットワーク要素レベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

実際の適用においては、障害のあるオブジェクトを決定するステップは、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定するステップ、又は、
障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、をさらに含んでもよい。

障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と前記他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、そのネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

本発明のこの実施形態にしたがった方法に基づいて、実際の適用においては、ネットワーク要素レベルの障害については、最初に、ネットワーク要素レベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行してもよく、そのトラブルシューティングが失敗した場合に、ネットワークレベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行してもよいということに留意すべきである。

実際の適用においては、障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。

上記のステップにおいて、サービス失敗の数は、サービス処理ユニット自体によって引き起こされるサービス失敗の数であってもよい。特に、重要なパフォーマンスインジケータ情報の中にサービス失敗の原因を記録してもよく、そのサービス失敗の原因にしたがって、そのサービス処理ユニット自体によって引き起こされるサービス失敗の数に関する統計量を収集してもよい。

上記のステップにおいて、基準値は、あらかじめ設定された値であってもよく、又は、均質化されたサービス処理ユニットの平均サービス成功率に関する統計量にしたがって取得される均質化された基準値であってもよいということにさらに留意すべきである。したがって、サービス成功率を基準値と比較するステップは、特に、
サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
サービス成功率を均質化された基準値と比較するステップと、を含んでもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。

均質化されたサービス処理ユニットは、複数の均質化されたサービス処理ユニットのサービス成功率のすべてが、ある理由に起因して、あらかじめ設定された基準値よりも低いという現象に直面する場合があるということに留意すべきである。この場合には、そのあらかじめ設定された基準値よりも低いサービス成功率を有するそれらの均質化されたサービス処理ユニットは、障害のある状態ではない場合がある。ほとんどの均質化されたサービス処理ユニットのサービス成功率は、他のデバイスの障害に起因して、減少している場合がある。上記の場合には、均質化されたサービス処理ユニットが障害のある状態であるということを誤って決定するのを防止するために、サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定するステップの前に、さらに、
均質化されたサービス処理ユニットのうちでサービス成功率があらかじめ設定された基準値よりも大きい第1のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのうちでサービス成功率がその基準値よりも小さい第2のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのすべてのうちで第1のユニットセットに含まれるユニットの割合があらかじめ設定された割合よりも大きいということを決定するステップと、を使用してもよい。

上記のステップにおいて、実際の要求に応じて、あらかじめ設定された割合を設定してもよく、例えば、90％に設定してもよい。すなわち、それらの均質化されたサービス処理ユニットのうちの90％又はより多くの数のサービス成功率が、上記のあらかじめ設定された基準値よりも高く、そして、それらの均質化されたサービス処理ユニットのうちの10％又はより少ない数のサービス成功率が、上記のあらかじめ設定された基準値よりも小さい場合には、その基準値よりも小さいサービス成功率を有する均質化されたサービス処理ユニットを、障害のあるオブジェクトとして決定してもよい。

実際の適用においては、障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも小さい通信パスが障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。

実際の適用においては、障害のあるオブジェクトが、モニタリングされているネットワーク要素が属するネットワークの中のネットワーク要素であるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、モニタリングされているネットワーク要素のサービス成功率に関する統計量を収集するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも小さいモニタリングされているネットワーク要素が障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。

1つのネットワーク要素は、複数のサービス処理ユニットを含んでいてもよいということに留意すべきである。したがって、1つのネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得することが可能であり、各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているとともにサービス要求の数に対応しているサービス失敗の数にしたがって、そのネットワーク要素が受信したサービス要求の数及びサービス要求のその数に対応しているサービス失敗の数に関する統計量を収集する。さらに、モニタリングされているネットワーク要素のサービス成功率を算出する。

実際の適用においては、サービス成功率を基準値と比較するステップは、特に、
サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
サービス成功率を均質化された基準値と比較するステップと、を含んでもよく、
均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともにサービスが離散的に割り当てられるモニタリングされているネットワーク要素である。

図3は、この出願にしたがったトラブルシューティング方法の実施形態2のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素KPIモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図3に示されているように、上記の方法は、以下のステップを含んでもよい。

ステップ201: モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。

この実施形態においては、サービス処理ユニットは、スレッド、プロセス、及び仮想マシン(Virtual Machine, VM)等であってもよい。重要なパフォーマンスインジケータ情報は、少なくとも、サービス処理ユニットが受信したサービス要求の数及びサービス要求の数に対応しているサービス失敗の数を含んでいてもよい。

ステップ202: 重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出する。

サービス要求の数からサービス失敗の数を減算し、得られた差をサービス要求の数で除算し、そして、得られた商に100％を乗算することによって、サービス成功率を取得してもよい。

ステップ203: サービス成功率を基準値と比較する。

実際の要求に応じて基準値を設定してもよい。例えば、通常のサービス処理ユニットのサービス成功率が、95％又はより高い場合に、基準値を95％に設定してもよい。

代替的に、均質化されたサービス処理ユニットの平均サービス成功率にしたがって、上記の基準値を算出してもよい。均質化されたサービス処理ユニットは、そのサービス成功率に対応しているサービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにそのサービス成功率に対応しているサービス処理ユニットの外部サービスネットワーキングと同じ外部サービスネットワーキングを有するサービス処理ユニットである。複数の均質化されたサービス処理ユニットが受信する(へと配信される)サービス要求メッセージは、無作為に分かれている。したがって、それらの複数の均質化されたサービス処理ユニットのサービス成功率は、基本的に同様であるはずである。したがって、均質化されたサービス処理ユニットの平均サービス成功率にしたがって均質化された基準値を算出してもよい。

特に、平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得してもよい。実際の要求に応じて、そのあらかじめ設定された値を設定してもよく、例えば、20％又は10％に設定してもよい。

ステップ204: サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する。

ステップ205: 障害のあるオブジェクトが、サービス処理ユニットである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する。

ステップ206: ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信する。

ステップ205におけるネットワーク要素レベルのトラブルシューティングポリシーは、障害のあるサービス処理ユニットをリセットするようにシステム管理モジュールに指示してもよい。ネットワーク要素レベルのトラブルシューティングポリシーを受信した後に、システム管理モジュールは、障害のあるサービス処理ユニットをリセットしてもよい。

リセットされたサービス処理ユニットが依然として障害のある状態にある場合には、さらに、その障害のあるサービス処理ユニットを分離してもよいということに留意すべきである。さらに、分離されたサービス処理ユニットの数が第2のあらかじめ設定された閾値に達しているということを決定する場合には、ネットワークレベルのトラブルシューティングポリシーを遂行してもよい。ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。例えば、モニタリングされているネットワーク要素の次のホップの障害のあるネットワーク要素又は障害のある通信パスに対して切り替えを実行してもよい。冗長グループの中のネットワーク要素又は通信パスの健全性状態にしたがって、その切り替えに関する目標ネットワーク要素又は目標通信パスを選択してもよい。

障害のあるサービス処理ユニットが動作中の/予備のサービス処理ユニットである場合には、トラブルシューティングポリシーは、障害のあるサービス処理ユニットの予備のユニットを決定するステップ、及び、その障害のあるサービス処理ユニットが持っているサービスをその予備のユニットに切り替えるステップ、であってもよいということにさらに留意すべきである。さらに、予備のユニットが障害のある状態になった場合には、その障害のあるサービス処理ユニット及びその予備のユニットを分離してもよい。

図4は、この出願にしたがったトラブルシューティング方法の実施形態3のフローチャートである。ネットワークKPIモニタリング及びトラブルシューティング決定モジュールによって、この実施形態にしたがった方法を実行してもよい。図4に示されているように、その方法は、以下のステップを含んでもよい。

ステップ301: モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。

ステップ302: 重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットが実行したサービスのサービス成功率を算出する。

ステップ303: サービス成功率を基準値と比較する。

ステップ304: サービス成功率が基準値よりも小さいサービス処理ユニットの数を決定する。

ステップ305: 数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が基準値よりも小さいサービス処理ユニットの割合を決定する。

サービス成功率が基準値よりも低いサービス処理ユニットの数が8であり、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべての数が10であると仮定すると、上記の割合は80％である。

ステップ306: 割合があらかじめ設定された割合よりも大きい場合に、障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定する。

実際の要求に応じて、あらかじめ設定された割合を設定してもよい。例えば、あらかじめ設定された割合を50％又は80％に設定してもよい。

ステップ307: 障害のあるオブジェクトが、モニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素である場合に、ネットワークレベルのトラブルシューティングポリシーを決定する。

障害のある位置が、モニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素である場合に、その障害のあるネットワーク要素を回復させるために、ネットワークレベルのトラブルシューティングポリシーを使用する必要がある。

実際に適用においては、特に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを複数の手法にしたがって実装してもよい。例えば、
障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、トラブルシューティング指示情報は、障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素を、正常な動作状態にある冗長ネットワーク要素で置き換えるように管理ユニットに指示するのに使用される、ステップと、を使用してもよい。

上記のステップにおいて、障害のあるモニタリングされているネットワーク要素を置き換えるのに使用される冗長ネットワーク要素は、正常に動作することが可能であるということを保証することが可能である。モニタリングされているネットワーク要素の冗長ネットワーク要素のすべてが正常ではない場合には、その障害のあるモニタリングされているネットワーク要素を置き換えるのにあらかじめ設定された冗長ネットワーク要素を使用することは不可能であり、その障害のあるモニタリングされているネットワーク要素を置き換えるのに、正常に動作することが可能である他のネットワーク要素を見つけてもよい。

他の例では、
障害のあるオブジェクトであると決定されている通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、トラブルシューティング指示情報は、通信パスにあるフロントエンドネットワーク要素に対応するバックエンドネットワーク要素を、正常な動作状態にある冗長ネットワーク要素に切り替えるように管理ユニットに指示するのに使用される、ステップと、を使用してもよい。

上記のステップにおいて、切り替えられる冗長ネットワーク要素は、正常に動作することが可能であるということを保証することが可能である。通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素のすべてが正常ではない場合に、その切り替えのために、あらかじめ設定された冗長ネットワーク要素を使用することは不可能であり、その切り替えのために、正常に動作することが可能である他のネットワーク要素を見つけてもよい。

ステップ308: ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットにトラブルシューティングポリシーを送信する。

ネットワークレベルのトラブルシューティングポリシーは、障害のあるネットワーク要素の予備のネットワーク要素を決定し、そして、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにMANOユニットに指示してもよい。

ネットワークレベルのトラブルシューティングポリシーを受信する場合に、MANOユニットは、障害のあるネットワーク要素の予備のネットワーク要素を決定してもよい。障害のあるネットワーク要素の予備のネットワーク要素を決定した後に、MANOユニットは、VNFMに指示シグナリングを送信して、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにVNFMに指示してもよい。その指示シグナリングを受信した後に、VNFMは、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えてもよい。

この出願のこの実施形態において、重要なパフォーマンスインジケータ情報は、サービス失敗の原因に関する情報及びそのサービス失敗の原因によって引き起こされるサービス失敗の数に関する情報をさらに含んでもよい。サービス失敗の原因は、ダウンストリームネットワーク要素への通信のタイムアウト、リソースの不足、モニタリングされているネットワーク要素の複数の内部モジュールの間の通信のタイムアウト、及び(ソフトウェアの内部データの無効性及び正常ではないブランチに入るコード処理等の)ソフトウェアの内部エラー等を含んでもよい。したがって、この出願にしたがった重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中に含まれるサービス失敗の原因に関する情報にしたがって、障害のあるオブジェクトを決定するステップをさらに含んでもよい。

サービス処理のタイムアウトによって引き起こされるサービス失敗の数及びモニタリングされているネットワーク要素がダウンストリームネットワーク要素に送信するとともに重要なパフォーマンスインジケータ情報の中に記録されているサービス要求の数にしたがって、サービス処理のタイムアウトによって引き起こされる失敗したサービスの割合を決定してもよい。

失敗したサービスの割合があらかじめ設定された閾値と等しいか又はより大きい場合に、障害のある位置がそのモニタリングされているネットワーク要素であるということを決定してもよい。そのモニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素は、そのネットワーク要素の外部ネットワーク要素及びそのネットワーク要素自体を含んでもよい。したがって、この場合には、ネットワークレベルのトラブルシューティングポリシーを使用することが可能である。

さらに、前にモニタリングされていた均質化されたサービス処理ユニットについては、リソースの不足によって引き起こされるサービス失敗の数を除外してもよく、サービス失敗の数に関する統計量を収集する間に、サービス失敗の合計の統計的な数に、リソースの不足によって引き起こされるサービス失敗の数を計数しなくてもよい。この場合の主たる原因は、サービスの数が過度に大きいということであり、サービス処理ユニットそれ自体は、通常、障害のある状態ではない。

この出願は、さらに、トラブルシューティング装置を提供する。

図5は、この出願にしたがったトラブルシューティング装置の1つの実施形態の構成図である。図5に示されているように、その装置は、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニット501と、
重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニット502と、
ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信するように構成され、それによって、管理ユニットが、トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニット503と、を含んでもよい。

この実施形態においては、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。

実際の適用においては、決定ユニット502は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素の中のサービス処理ユニットであるか、又は、サービス処理ユニットの間の通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワーク要素レベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

実際の適用においては、決定ユニット502は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定するか、又は、
障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

実際の適用においては、決定ユニット502は、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
サービス成功率を第1の基準値と比較し、そして、
サービス成功率が第1の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

実際の適用においては、決定ユニット502は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較するように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。

実際の適用においては、決定ユニット502は、さらに、
サービス成功率が第1の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が第1の基準値よりも大きい第1のユニットセットを決定し、
均質化されたサービス処理ユニットのうちでサービス成功率が第1の基準値よりも小さい第2のユニットセットを決定し、そして、
均質化されたサービス処理ユニットのすべてのうちで第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定する、ように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。

実際の適用においては、決定ユニット502は、特に、
重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
サービス成功率を第3の基準値と比較し、そして、
サービス成功率が第3の基準値よりも小さい通信パスが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

実際の適用においては、決定ユニット502は、特に、
各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
サービス成功率を第2の基準値と比較し、
サービス成功率が第2の基準値よりも小さいサービス処理ユニットの数を決定し、
数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が第2の基準値よりも小さいサービス処理ユニットの割合を決定し、そして、
割合が第2のあらかじめ設定された割合よりも大きい場合に、モニタリングされているネットワーク要素が障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

決定ユニット502は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較する、ように構成されてもよく、
均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともにサービスが離散的に割り当てられるモニタリングされているネットワーク要素である。

実際の適用においては、送信ユニット503は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定した後、又は、障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信するように構成されてもよい。

実際の適用においては、送信ユニット503は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定した後、又は、障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットにトラブルシューティングポリシーを送信するように構成されてもよい。

実際の適用においては、決定ユニット502は、さらに、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

実際の適用においては、取得ユニット501は、さらに、
障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成されてもよい。

決定ユニット502は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素を、正常な動作状態にある冗長ネットワーク要素で置き換えるように管理ユニットに指示するのに使用される。

代替的に、取得ユニット501は、さらに、障害のあるオブジェクトであると決定されている通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成される。

決定ユニット502は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、通信パスにあるフロントエンドネットワーク要素に対応するバックエンドネットワーク要素を、正常な動作状態にある冗長ネットワーク要素に切り替えるように管理ユニットに指示するのに使用される。

さらに、この出願の1つの実施形態は、さらに、計算ノードを提供する。その計算ノードは、計算能力を有するホストサーバ、パーソナルコンピュータPC、携帯用コンピュータ、又は端末等であってもよい。この出願の複数の特定の実施形態は、その計算ノードの特定の実装にいかなる制約も課するものではない。

図6は、この出願にしたがった計算ノードの構成図である。図6に示されているように、計算ノード600は、
プロセッサ(processor)610、通信インターフェイス(Communications Interface)620、メモリ(memory)630、及び通信バス640を含む。

プロセッサ610、通信インターフェイス620、及びメモリ630は、通信バス640を使用することによって互いに通信する。

プロセッサ610は、プログラム632を実行するように構成される。

特に、プログラム632は、プログラムコードを含んでもよく、プログラムコードは、コンピュータ動作命令を含む。

プロセッサ610は、中央処理ユニットCPU、又は特定用途向け集積回路ASIC(Application-Specific Integrated Circuit)、又は、この出願の複数の実施形態を実装するように構成される1つ又は複数の集積回路であってもよい。

メモリ630は、プログラム632を格納するように構成される。メモリ630は、高速RAMメモリを含んでもよく、少なくとも1つのディスクメモリ等の不揮発性メモリ(non-volatile memory)をさらに含んでもよい。プログラム632は、特に、図5に示されている実施形態にしたがった対応するモジュール又はユニットを含んでもよく、本明細書においては、細部は説明されない。

最後に、この出願においては、第1の及び第2の等の関係を示す語は、他方のエンティティ又は動作から一方のエンティティ又は動作を区別するのに使用されるにすぎず、これらのエンティティ又は動作の間にいずれかの実際的な関係又は順序が存在するということを必然的に要求する又は示唆するものではないということに留意すべきである。さらに、"包含する"又は"含む"との記載或いはいずれかの他の変形語は、非制限的な包含を対象とすることを意図しており、結果として、構成要素のリストを含むプロセス、方法、製品、又は装置は、それらの構成要素を包含するのみならず、明白には列記されていない他の構成要素も含み、或いは、そのようなプロセス、方法、製品、又は装置に固有の複数の構成要素をさらに含む。"…を包含する"との記載の後に続くある構成要素は、それ以上制限されることなく、その構成要素を包含するそのプロセス、方法、製品、又は装置の中の複数の追加的な同等の構成要素の存在を除外するものではない。

複数の実施形態の上記の説明に基づいて、当業者は、必要なハードウェアプラットフォームのほかにソフトウェアによって本出願を実装してもよく、或いは、ハードウェアのみによって本出願を実装してもよいということを明確に理解することが可能である。ほとんどの環境においては、必要なハードウェアプラットフォームに加えてソフトウェアによる実装が、好ましい実装である。そのような理解に基づいて、背景技術の部分にしたがった技術に対する貢献を示す本出願の複数の技術的解決方法のうちのすべて又は一部を、ソフトウェア製品の形態で実装してもよい。コンピュータソフトウェア製品は、ROM/RAM、磁気ディスク、又は光ディスク等の記憶媒体の中に格納されてもよく、複数の命令を含んでもよく、それらの複数の命令は、本出願の複数の実施形態又はそれらの複数の実施形態のうちの複数の部分において説明された複数の方法を実行するように、パーソナルコンピュータ、サーバ、又はネットワークデバイスであってもよいコンピュータデバイスに指示する。

本明細書における複数の実施形態は、すべてが、革新的な手法で説明されており、これらの実施形態の中の同じ部分又は同様な部分については、これらの実施形態を参照することが可能であり、各々の実施形態は、他の実施形態とは異なる点に焦点を当てている。それらの複数の実施形態にしたがって開示された装置は、それらの複数の実施形態にしたがって開示された方法に対応しているため、比較的簡潔に説明されており、その方法の実施形態に関連する部分については、その方法の説明を参照することが可能である。

本出願の原理及び複数の実施形態を説明するために、複数の特定の例が、本明細書の中で使用されている。上記の複数の実施形態は、本出願の方法及び概念の理解を助けることを意図しているにすぎない。さらに、複数の実装及び出願の範囲に関しては、当業者は、本出願の概念にしたがって、複数の修正を行うことが可能である。したがって、本出願を限定するものとしてこの明細書の記載内容を解釈するべきではない。

この出願は、２０１５年９月２２日付で中国特許庁に出願された“トラブルシューティング方法及び装置”と題する中国特許出願番号第２０１５１０６０８７８２．１号に基づく優先権を主張し、その内容は、参照により全体が本明細書に取り込まれる。

この出願の第１の態様の第１の可能な実装によれば、この出願は、トラブルシューティング方法であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信し、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む、トラブルシューティング方法を提供する。

第１の態様の第２の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

第１の態様の第３の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

第１の態様の第２の可能な実装の第１の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
前記サービス成功率を第１の基準値と比較するステップと、
サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第１の態様の第２の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記サービス成功率を第１の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第１の態様の第２の可能な実装の第１の具体的な実装の第２のより具体的な実装に関して、サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップの前に、当該方法は、
均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも大きい第１のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも小さい第２のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのすべてのうちで前記第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定するステップと、をさらに含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第１の態様の第２の可能な実装の第２の具体的な実装に関して、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
前記サービス成功率を第３の基準値と比較するステップと、
サービス成功率が前記第３の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第１の態様の第３の可能な実装の第１の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集するステップと、
前記サービス成功率を第２の基準値と比較するステップと、
サービス成功率が前記第２の基準値よりも小さいサービス処理ユニットの数を決定するステップと、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第２の基準値よりも小さい前記サービス処理ユニットの割合を決定するステップと、
前記割合が第２のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定するステップと、を含む。

第１の態様の第３の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記サービス成功率を第２の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。

第１の態様の第２の可能な実装の第３の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するステップを含む。

第１の態様の第３の可能な実装の第２の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットに前記トラブルシューティングポリシーを送信するステップを含む。

第１の態様の第２の可能な実装の第４の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後に、当該方法は、
障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定するステップと、
ネットワークレベルのトラブルシューティングポリシーを決定するステップと、をさらに含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第１の態様の第３の可能な実装の第３の具体的な実装に関して、ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用される、ステップと、を含むか、又は、
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、ステップと、を含む。

この出願の第２の態様の第１の可能な実装によれば、この出願は、トラブルシューティング装置であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニットと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニットと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するように構成され、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニットと、を含む、トラブルシューティング装置を提供する。

第２の態様の第２の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

第２の態様の第３の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するか、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第２の態様の第２の可能な実装の第１の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
前記サービス成功率を第１の基準値と比較し、そして、
サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定する、ように構成される。

第２の態様の第２の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較するように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第２の態様の第２の可能な実装の第１の具体的な実装の第２のより具体的な実装に関して、前記決定ユニットは、さらに、
サービス成功率が前記第１の基準値よりも低い前記サービス処理ユニットが前記障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも大きい第１のユニットセットを決定し、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも小さい第２のユニットセットを決定し、そして、
前記均質化されたサービス処理ユニットのすべてのうちで前記第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。

第２の態様の第２の可能な実装の第２の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
前記サービス成功率を第３の基準値と比較し、そして、
サービス成功率が前記第３の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定する、ように構成される。

第２の態様の第３の可能な実装の第１の具体的な実装に関して、前記決定ユニットは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
前記サービス成功率を第２の基準値と比較し、
サービス成功率が前記第２の基準値よりも小さいサービス処理ユニットの数を決定し、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第２の基準値よりも小さい前記サービス処理ユニットの割合を決定し、そして、
前記割合が第２のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定する、ように構成される。

第２の態様の第３の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。

第２の態様の第２の可能な実装の第３の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるということを決定した後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するように構成される。

第２の態様の第３の可能な実装の第２の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定した後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットに前記トラブルシューティングポリシーを送信するように構成される。

第２の態様の第２の可能な実装の第４の具体的な実装に関して、前記決定ユニットは、さらに、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。

第２の態様の第３の可能な実装の第３の具体的な実装に関して、前記取得ユニットは、さらに、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用されるか、又は、
前記取得ユニットは、さらに、前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される。

この出願にしたがったネットワーク機能仮想化（ＮＦＶ）システムのアーキテクチャ図である。この出願にしたがったトラブルシューティング方法の実施形態１のフローチャートである。この出願にしたがったトラブルシューティング方法の実施形態２のフローチャートである。この出願にしたがったトラブルシューティング方法の実施形態３のフローチャートである。この出願にしたがったトラブルシューティング装置の１つの実施形態の構成図である。この出願にしたがった計算ノードの構成図である。

図１は、この出願にしたがったネットワーク機能仮想化（ＮＦＶ）システムのアーキテクチャ図である。この出願にしたがったトラブルシューティング方法は、主として、ＮＦＶシステムに適用される。図１に示されているように、ＮＦＶシステムは、主に、
ネットワーク機能仮想化オーケストレータ（ＮＦＶＯｒｃｈｅｓｔｒａｔｏｒ）へのサービス要求を開始し、そして、あるサービスに必要なリソースを提供する、ように構成され、障害処理の役割を担う、オペレーションサポートシステム（ＯｐｅｒａｔｉｏｎｓＳｕｐｐｏｒｔＳｙｓｔｅｍ，ＯＳＳ）／ビジネスサポートシステム（ＢｕｓｉｎｅｓｓＳｕｐｐｏｒｔＳｙｓｔｅｍ，ＢＳＳ）と、
ＯＳＳ／ＢＳＳのサービス要求にしたがってＮＦＶサービスを実装する役割を担うとともに、ネットワークサービス（ＮｅｔｗｏｒｋＳｅｒｖｉｃｅ，ＮＳ）のライフサイクル管理の役割を担い、そして、管理リソースを組織化する役割を担い、及び、仮想化されたネットワーク機能（ＶｉｒｔｕａｌｉｚｅｄＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎ，ＶＮＦ）及びネットワーク機能仮想化インフラストラクチャ（ＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎｓＶｉｒｔｕａｌｉｚａｔｉｏｎＩｎｆｒａｓｔｒｕｃｔｕｒｅ，ＮＦＶＩ）のリソース及び実行状態情報をリアルタイムでモニタリングする役割を担うオーケストレータ（Ｏｒｃｈｅｓｔｒａｔｏｒ）と、
例えば、起動、有効期間、及びＶＮＦ実行状態情報の管理等のＶＮＦ生成周期の管理の役割を担う仮想化されたネットワーク機能マネージャ（ＶＮＦＭａｎａｇｅｒ，ＶＮＦＭ）と、
ＮＦＶＩリソースを管理しそして割り当てる役割を担うとともに、ＮＦＶＩ実行状態情報をモニタリングしそして収集する役割を担う仮想化されたインフラストラクチャマネージャ（ＶｉｒｔｕａｌｉｚｅｄＩｎｆｒａｓｔｒｕｃｔｕｒｅＭａｎａｇｅｒ，ＶＩＭ）と、
ネットワーク要素の障害管理、構成管理、課金管理、パフォーマンス管理、セキュリティ管理（ＦａｕｌｔＭａｎａｇｅｍｅｎｔ，ＣｏｎｆｉｇｕｒａｔｉｏｎＭａｎａｇｅｍｅｎｔ，ＡｃｃｏｕｎｔｉｎｇＭａｎａｇｅｍｅｎｔ，ＰｅｒｆｏｒｍａｎｃｅＭａｎａｇｅｍｅｎｔ，ＳｅｃｕｒｉｔｙＭａｎａｇｅｍｅｎｔ，ＦＣＡＰＳ）の役割を担う要素管理システム（ＥｌｅｍｅｎｔＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ，ＥＭＳ）と、を含む。

ＮＦＶＩリソースは、利用可能な／予約された／割り当てられたＮＦＶＩリソース等のすべてのＮＦＶＩリソースを含む。

この出願にしたがったトラブルシューティング方法は、ネットワーク要素の重要なパフォーマンスインジケータ（ＫｅｙＰｅｒｆｏｒｍａｎｃｅＩｎｄｉｃａｔｏｒ，ＫＰＩ）モニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールは、ＮＦＶシステムの中のＶＮＦ、ＥＭＳ、又は管理及びオーケストレータ（ＭａｎａｇｅｍｅｎｔａｎｄＯｒｃｈｅｓｔｒａｔｏｒ，ＭＡＮＯ）ユニットの中に配置されてもよく、又は、独立したネットワークノードに配置されてもよい。ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール及びネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールは、統合された方法で配置されてもよく、又は、個別に配置されてもよい。

図２は、この出願にしたがったトラブルシューティング方法の実施形態１のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図２に示されているように、上記の方法は、以下のステップを含む。

ステップ１０１：モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ（ＫｅｙＰｅｒｆｏｒｍａｎｃｅＩｎｄｉｃａｔｏｒ，ＫＰＩ）情報を取得する。

モニタリングされているネットワーク要素は、例えば、ＶＮＦ等のネットワーク機能仮想化（ＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎＶｉｒｔｕａｌｉｚａｔｉｏｎ，ＮＦＶ）システムの中のネットワーク要素である。

モニタリングされているネットワーク要素の中に１つ又は複数のサービス処理ユニットが存在してもよい。

重要なパフォーマンスインジケータ情報は、サービス処理ユニットが受信するサービス要求の数、サービス要求の数に対応しているサービス失敗の数、及び／又は各々のサービス失敗の原因等の情報を含んでもよい。実際の適用では、重要なパフォーマンスインジケータ情報に含まれる情報のタイプは、要求に応じて設定されてもよい。例えば、重要なパフォーマンスインジケータ情報は、サービス遅延情報等の情報をさらに含んでもよい。

ステップ１０１が実行される前に、さらに、ＥＭＳ及び／又はＭＡＮＯに関する情報にしたがって、モニタリングされることが必要であるネットワーク要素を決定してもよいということに留意すべきである。ＥＭＳ及び／又はＭＡＮＯによって記録されているネットワーク要素の内部に配置されているサービス処理ユニットに関する情報及びネットワークの中に配置されているネットワーク要素に関する情報を取得してもよい。ネットワークの中に配置されているネットワーク要素に関する記録された情報に対応するネットワーク要素は、モニタリングされているネットワーク要素として決定される。ネットワーク要素の内部に配置されているサービス処理ユニットに関する記録された情報に対応するサービス処理ユニットは、モニタリングされることが必要であるサービス処理ユニットとして決定される。

ステップ１０２：重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定する。

例えば、重要なパフォーマンスインジケータ情報にしたがって、あるサービス処理ユニットによって実行されるサービスの成功率を算出してもよい。その成功率がある特定の比率よりも低い場合には、障害のあるオブジェクトがそのサービス処理ユニットであるということを決定してもよい。相対的に低い成功率を有するサービス処理ユニットの数が、（例えば、そのモニタリングされているネットワーク要素の中のサービス処理ユニットの合計数のうちの８０％を超えるといったように）相対的に大きい場合には、障害のあるオブジェクトが、そのモニタリングされているネットワーク要素以外のネットワーク要素であるということを決定してもよい。他の例では、あるモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信のタイムアウトによって引き起こされるサービス失敗の重要なパフォーマンスインジケータ情報の中に記録されている数が、相対的に高い場合には、そのモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信パスが障害を持っているということ、又はその次のホップのネットワーク要素が障害を持っているということを決定してもよい。

ステップ１０３：障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する。

障害のあるオブジェクトがそのモニタリングされているネットワーク要素以外のネットワーク要素である場合には、ネットワークレベルのトラブルシューティングポリシーを決定してもよい。そのネットワークレベルのトラブルシューティングポリシーは、そのモニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

ステップ１０４：ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信し、それによって、その管理ユニットは、そのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する。

管理ユニットは、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールであってもよく、又は、ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットであってもよい。

障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と前記他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、そのネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

均質化されたサービス処理ユニットは、複数の均質化されたサービス処理ユニットのサービス成功率のすべてが、ある理由に起因して、あらかじめ設定された基準値よりも低いという現象に直面する場合があるということに留意すべきである。この場合には、そのあらかじめ設定された基準値よりも低いサービス成功率を有するそれらの均質化されたサービス処理ユニットは、障害のある状態ではない場合がある。ほとんどの均質化されたサービス処理ユニットのサービス成功率は、他のデバイスの障害に起因して、減少している場合がある。上記の場合には、均質化されたサービス処理ユニットが障害のある状態であるということを誤って決定するのを防止するために、サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定するステップの前に、さらに、
均質化されたサービス処理ユニットのうちでサービス成功率があらかじめ設定された基準値よりも大きい第１のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのうちでサービス成功率がその基準値よりも小さい第２のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのすべてのうちで第１のユニットセットに含まれるユニットの割合があらかじめ設定された割合よりも大きいということを決定するステップと、を使用してもよい。

上記のステップにおいて、実際の要求に応じて、あらかじめ設定された割合を設定してもよく、例えば、９０％に設定してもよい。すなわち、それらの均質化されたサービス処理ユニットのうちの９０％又はより多くの数のサービス成功率が、上記のあらかじめ設定された基準値よりも高く、そして、それらの均質化されたサービス処理ユニットのうちの１０％又はより少ない数のサービス成功率が、上記のあらかじめ設定された基準値よりも小さい場合には、その基準値よりも小さいサービス成功率を有する均質化されたサービス処理ユニットを、障害のあるオブジェクトとして決定してもよい。

１つのネットワーク要素は、複数のサービス処理ユニットを含んでいてもよいということに留意すべきである。したがって、１つのネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得することが可能であり、各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているとともにサービス要求の数に対応しているサービス失敗の数にしたがって、そのネットワーク要素が受信したサービス要求の数及びサービス要求のその数に対応しているサービス失敗の数に関する統計量を収集する。さらに、モニタリングされているネットワーク要素のサービス成功率を算出する。

図３は、この出願にしたがったトラブルシューティング方法の実施形態２のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素ＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図３に示されているように、上記の方法は、以下のステップを含んでもよい。

ステップ２０１：モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。

この実施形態においては、サービス処理ユニットは、スレッド、プロセス、及び仮想マシン（ＶｉｒｔｕａｌＭａｃｈｉｎｅ，ＶＭ）等であってもよい。重要なパフォーマンスインジケータ情報は、少なくとも、サービス処理ユニットが受信したサービス要求の数及びサービス要求の数に対応しているサービス失敗の数を含んでいてもよい。

ステップ２０２：重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出する。

サービス要求の数からサービス失敗の数を減算し、得られた差をサービス要求の数で除算し、そして、得られた商に１００％を乗算することによって、サービス成功率を取得してもよい。

ステップ２０３：サービス成功率を基準値と比較する。

実際の要求に応じて基準値を設定してもよい。例えば、通常のサービス処理ユニットのサービス成功率が、９５％又はより高い場合に、基準値を９５％に設定してもよい。

代替的に、均質化されたサービス処理ユニットの平均サービス成功率にしたがって、上記の基準値を算出してもよい。均質化されたサービス処理ユニットは、そのサービス成功率に対応しているサービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにそのサービス成功率に対応しているサービス処理ユニットの外部サービスネットワーキングと同じ外部サービスネットワーキングを有するサービス処理ユニットである。複数の均質化されたサービス処理ユニットが受信する（へと配信される）サービス要求メッセージは、無作為に分かれている。したがって、それらの複数の均質化されたサービス処理ユニットのサービス成功率は、基本的に同様であるはずである。したがって、均質化されたサービス処理ユニットの平均サービス成功率にしたがって均質化された基準値を算出してもよい。

特に、平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得してもよい。実際の要求に応じて、そのあらかじめ設定された値を設定してもよく、例えば、２０％又は１０％に設定してもよい。

ステップ２０４：サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する。

ステップ２０５：障害のあるオブジェクトが、サービス処理ユニットである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する。

ステップ２０６：ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信する。

ステップ２０５におけるネットワーク要素レベルのトラブルシューティングポリシーは、障害のあるサービス処理ユニットをリセットするようにシステム管理モジュールに指示してもよい。ネットワーク要素レベルのトラブルシューティングポリシーを受信した後に、システム管理モジュールは、障害のあるサービス処理ユニットをリセットしてもよい。

リセットされたサービス処理ユニットが依然として障害のある状態にある場合には、さらに、その障害のあるサービス処理ユニットを分離してもよいということに留意すべきである。さらに、分離されたサービス処理ユニットの数が第２のあらかじめ設定された閾値に達しているということを決定する場合には、ネットワークレベルのトラブルシューティングポリシーを遂行してもよい。ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。例えば、モニタリングされているネットワーク要素の次のホップの障害のあるネットワーク要素又は障害のある通信パスに対して切り替えを実行してもよい。冗長グループの中のネットワーク要素又は通信パスの健全性状態にしたがって、その切り替えに関する目標ネットワーク要素又は目標通信パスを選択してもよい。

障害のあるサービス処理ユニットが動作中の／予備のサービス処理ユニットである場合には、トラブルシューティングポリシーは、障害のあるサービス処理ユニットの予備のユニットを決定するステップ、及び、その障害のあるサービス処理ユニットが持っているサービスをその予備のユニットに切り替えるステップ、であってもよいということにさらに留意すべきである。さらに、予備のユニットが障害のある状態になった場合には、その障害のあるサービス処理ユニット及びその予備のユニットを分離してもよい。

図４は、この出願にしたがったトラブルシューティング方法の実施形態３のフローチャートである。ネットワークＫＰＩモニタリング及びトラブルシューティング決定モジュールによって、この実施形態にしたがった方法を実行してもよい。図４に示されているように、その方法は、以下のステップを含んでもよい。

ステップ３０１：モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。

ステップ３０２：重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出する。

ステップ３０３：サービス成功率を基準値と比較する。

ステップ３０４：サービス成功率が基準値よりも小さいサービス処理ユニットの数を決定する。

ステップ３０５：数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が基準値よりも小さいサービス処理ユニットの割合を決定する。

サービス成功率が基準値よりも低いサービス処理ユニットの数が８であり、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべての数が１０であると仮定すると、上記の割合は８０％である。

ステップ３０６：割合があらかじめ設定された割合よりも大きい場合に、障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定する。

実際の要求に応じて、あらかじめ設定された割合を設定してもよい。例えば、あらかじめ設定された割合を５０％又は８０％に設定してもよい。

ステップ３０７：障害のあるオブジェクトが、モニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素である場合に、ネットワークレベルのトラブルシューティングポリシーを決定する。

ステップ３０８：ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットにトラブルシューティングポリシーを送信する。

ネットワークレベルのトラブルシューティングポリシーは、障害のあるネットワーク要素の予備のネットワーク要素を決定し、そして、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにＭＡＮＯユニットに指示してもよい。

ネットワークレベルのトラブルシューティングポリシーを受信する場合に、ＭＡＮＯユニットは、障害のあるネットワーク要素の予備のネットワーク要素を決定してもよい。障害のあるネットワーク要素の予備のネットワーク要素を決定した後に、ＭＡＮＯユニットは、ＶＮＦＭに指示シグナリングを送信して、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにＶＮＦＭに指示してもよい。その指示シグナリングを受信した後に、ＶＮＦＭは、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えてもよい。

この出願のこの実施形態において、重要なパフォーマンスインジケータ情報は、サービス失敗の原因に関する情報及びそのサービス失敗の原因によって引き起こされるサービス失敗の数に関する情報をさらに含んでもよい。サービス失敗の原因は、ダウンストリームネットワーク要素への通信のタイムアウト、リソースの不足、モニタリングされているネットワーク要素の複数の内部モジュールの間の通信のタイムアウト、及び（ソフトウェアの内部データの無効性及び正常ではないブランチに入るコード処理等の）ソフトウェアの内部エラー等を含んでもよい。したがって、この出願にしたがった重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中に含まれるサービス失敗の原因に関する情報にしたがって、障害のあるオブジェクトを決定するステップをさらに含んでもよい。

図５は、この出願にしたがったトラブルシューティング装置の１つの実施形態の構成図である。図５に示されているように、その装置は、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニット５０１と、
重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニット５０２と、
ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信するように構成され、それによって、管理ユニットが、トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニット５０３と、を含んでもよい。

実際の適用においては、決定ユニット５０２は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素の中のサービス処理ユニットであるか、又は、サービス処理ユニットの間の通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワーク要素レベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。

実際の適用においては、決定ユニット５０２は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定するか、又は、
障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

実際の適用においては、決定ユニット５０２は、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
サービス成功率を第１の基準値と比較し、そして、
サービス成功率が第１の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

実際の適用においては、決定ユニット５０２は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較するように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。

実際の適用においては、決定ユニット５０２は、さらに、
サービス成功率が第１の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が第１の基準値よりも大きい第１のユニットセットを決定し、
均質化されたサービス処理ユニットのうちでサービス成功率が第１の基準値よりも小さい第２のユニットセットを決定し、そして、
均質化されたサービス処理ユニットのすべてのうちで第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定する、ように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。

実際の適用においては、決定ユニット５０２は、特に、
重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
サービス成功率を第３の基準値と比較し、そして、
サービス成功率が第３の基準値よりも小さい通信パスが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

実際の適用においては、決定ユニット５０２は、特に、
各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
サービス成功率を第２の基準値と比較し、
サービス成功率が第２の基準値よりも小さいサービス処理ユニットの数を決定し、
数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が第２の基準値よりも小さいサービス処理ユニットの割合を決定し、そして、
割合が第２のあらかじめ設定された割合よりも大きい場合に、モニタリングされているネットワーク要素が障害のあるオブジェクトであるということを決定する、ように構成されてもよい。

決定ユニット５０２は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較する、ように構成されてもよく、
均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともにサービスが離散的に割り当てられるモニタリングされているネットワーク要素である。

実際の適用においては、送信ユニット５０３は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定した後、又は、障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信するように構成されてもよい。

実際の適用においては、送信ユニット５０３は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定した後、又は、障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットにトラブルシューティングポリシーを送信するように構成されてもよい。

実際の適用においては、決定ユニット５０２は、さらに、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。

実際の適用においては、取得ユニット５０１は、さらに、
障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成されてもよい。

決定ユニット５０２は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素を、正常な動作状態にある冗長ネットワーク要素で置き換えるように管理ユニットに指示するのに使用される。

代替的に、取得ユニット５０１は、さらに、障害のあるオブジェクトであると決定されている通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成される。

決定ユニット５０２は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、通信パスにあるフロントエンドネットワーク要素に対応するバックエンドネットワーク要素を、正常な動作状態にある冗長ネットワーク要素に切り替えるように管理ユニットに指示するのに使用される。

さらに、この出願の１つの実施形態は、さらに、計算ノードを提供する。その計算ノードは、計算能力を有するホストサーバ、パーソナルコンピュータＰＣ、携帯用コンピュータ、又は端末等であってもよい。この出願の複数の特定の実施形態は、その計算ノードの特定の実装にいかなる制約も課するものではない。

図６は、この出願にしたがった計算ノードの構成図である。図６に示されているように、計算ノード６００は、
プロセッサ（ｐｒｏｃｅｓｓｏｒ）６１０、通信インターフェイス（ＣｏｍｍｕｎｉｃａｔｉｏｎｓＩｎｔｅｒｆａｃｅ）６２０、メモリ（ｍｅｍｏｒｙ）６３０、及び通信バス６４０を含む。

プロセッサ６１０、通信インターフェイス６２０、及びメモリ６３０は、通信バス６４０を使用することによって互いに通信する。

プロセッサ６１０は、プログラム６３２を実行するように構成される。

特に、プログラム６３２は、プログラムコードを含んでもよく、プログラムコードは、コンピュータ動作命令を含む。

プロセッサ６１０は、中央処理ユニットＣＰＵ、又は特定用途向け集積回路ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ−ＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、又は、この出願の複数の実施形態を実装するように構成される１つ又は複数の集積回路であってもよい。

メモリ６３０は、プログラム６３２を格納するように構成される。メモリ６３０は、高速ＲＡＭメモリを含んでもよく、少なくとも１つのディスクメモリ等の不揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅｍｅｍｏｒｙ）をさらに含んでもよい。プログラム６３２は、特に、図５に示されている実施形態にしたがった対応するモジュール又はユニットを含んでもよく、本明細書においては、細部は説明されない。

最後に、この出願においては、第１の及び第２の等の関係を示す語は、他方のエンティティ又は動作から一方のエンティティ又は動作を区別するのに使用されるにすぎず、これらのエンティティ又は動作の間にいずれかの実際的な関係又は順序が存在するということを必然的に要求する又は示唆するものではないということに留意すべきである。さらに、“包含する”又は“含む”との記載或いはいずれかの他の変形語は、非制限的な包含を対象とすることを意図しており、結果として、構成要素のリストを含むプロセス、方法、製品、又は装置は、それらの構成要素を包含するのみならず、明白には列記されていない他の構成要素も含み、或いは、そのようなプロセス、方法、製品、又は装置に固有の複数の構成要素をさらに含む。“…を包含する”との記載の後に続くある構成要素は、それ以上制限されることなく、その構成要素を包含するそのプロセス、方法、製品、又は装置の中の複数の追加的な同等の構成要素の存在を除外するものではない。

複数の実施形態の上記の説明に基づいて、当業者は、必要なハードウェアプラットフォームのほかにソフトウェアによって本出願を実装してもよく、或いは、ハードウェアのみによって本出願を実装してもよいということを明確に理解することが可能である。ほとんどの環境においては、必要なハードウェアプラットフォームに加えてソフトウェアによる実装が、好ましい実装である。そのような理解に基づいて、背景技術の部分にしたがった技術に対する貢献を示す本出願の複数の技術的解決方法のうちのすべて又は一部を、ソフトウェア製品の形態で実装してもよい。コンピュータソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク、又は光ディスク等の記憶媒体の中に格納されてもよく、複数の命令を含んでもよく、それらの複数の命令は、本出願の複数の実施形態又はそれらの複数の実施形態のうちの複数の部分において説明された複数の方法を実行するように、パーソナルコンピュータ、サーバ、又はネットワークデバイスであってもよいコンピュータデバイスに指示する。

Claims

トラブルシューティング方法であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信し、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む、
方法。
障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される、請求項１に記載の方法。
障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１に記載の方法。
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
前記サービス成功率を第1の基準値と比較するステップと、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項２に記載の方法。
前記サービス成功率を第1の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項４に記載の方法。
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップの前に、
均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定するステップと、をさらに含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項４に記載の方法。
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
前記サービス成功率を第3の基準値と比較するステップと、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項２に記載の方法。
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集するステップと、
前記サービス成功率を第2の基準値と比較するステップと、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定するステップと、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定するステップと、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項３に記載の方法。
前記サービス成功率を第2の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である、請求項８に記載の方法。
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するステップを含む、請求項２に記載の方法。
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットに前記トラブルシューティングポリシーを送信するステップを含む、請求項３に記載の方法。
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後に、
障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定するステップと、
ネットワークレベルのトラブルシューティングポリシーを決定するステップと、をさらに含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項２に記載の方法。
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用される、ステップと、を含むか、又は、
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、ステップと、を含む、請求項３に記載の方法。
トラブルシューティング装置であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニットと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニットと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するように構成され、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニットと、を含む、
装置。
前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される、請求項１４に記載の装置。
前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するか、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１４に記載の装置。
前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
前記サービス成功率を第1の基準値と比較し、そして、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１５に記載の装置。
前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項１７に記載の装置。
前記決定ユニットは、さらに、
サービス成功率が前記第1の基準値よりも低い前記サービス処理ユニットが前記障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定し、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定し、そして、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項１７に記載の装置。
前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービスの失敗の数にしたがって、通信パスのサービス成功率を算出し、
前記サービス成功率を第3の基準値と比較し、そして、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１５に記載の装置。
前記決定ユニットは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
前記サービス成功率を第2の基準値と比較し、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定し、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定し、そして、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１６に記載の装置。
前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である、請求項２１に記載の装置。
前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるということを決定した後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するように構成される、請求項１５に記載の装置。
前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定した後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の管理及びオーケストレーションMANOユニットに前記トラブルシューティングポリシーを送信するように構成される、請求項１６に記載の装置。
前記決定ユニットは、さらに、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１５に記載の装置。
前記取得ユニットは、さらに、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用されるか、又は、
前記取得ユニットは、さらに、前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、請求項１６に記載の装置。