(57)【特許請求の範囲】
【請求項１】
トラブルシューティング方法であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信し、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む、
方法。
【請求項２】
障害のあるオブジェクトを決定するステップは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される、請求項１に記載の方法。
【請求項３】
障害のあるオブジェクトを決定するステップは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１又は２に記載の方法。
【請求項４】
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
前記サービス成功率を第1の基準値と比較するステップと、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項２又は３に記載の方法。
【請求項５】
前記サービス成功率を第1の基準値と比較するステップは、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項４に記載の方法。
【請求項６】
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップの前に、
均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定するステップと、をさらに含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項４に記載の方法。
【請求項７】
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップは、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
前記サービス成功率を第3の基準値と比較するステップと、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項２に記載の方法。
【請求項８】
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップは、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集するステップと、
前記サービス成功率を第2の基準値と比較するステップと、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定するステップと、
サービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの前記決定された数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定するステップと、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定するステップと、を含む、請求項３に記載の方法。
【請求項９】
前記サービス成功率を第2の基準値と比較するステップは、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である、請求項８に記載の方法。
【請求項１０】
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、
前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するステップを含む、請求項２に記載の方法。
【請求項１１】
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、
前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション(MANO)ユニットに前記トラブルシューティングポリシーを送信するステップを含む、請求項３に記載の方法。
【請求項１２】
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後に、
障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定するステップと、
ネットワークレベルのトラブルシューティングポリシーを決定するステップと、をさらに含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項２に記載の方法。
【請求項１３】
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用される、ステップと、を含むか、又は、
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、
前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、ステップと、を含む、請求項３に記載の方法。
【請求項１４】
トラブルシューティング装置であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニットと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニットと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するように構成され、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニットと、を含む、
装置。
【請求項１５】
前記決定ユニットは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される、請求項１４に記載の装置。
【請求項１６】
前記決定ユニットは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するか、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１４又は１５に記載の装置。
【請求項１７】
前記決定ユニットは、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
前記サービス成功率を第1の基準値と比較し、そして、
サービス成功率が前記第1の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１５又は１６に記載の装置。
【請求項１８】
前記決定ユニットは、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項１７に記載の装置。
【請求項１９】
前記決定ユニットは、さらに、
サービス成功率が前記第1の基準値よりも低い前記サービス処理ユニットが前記障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも大きい第1のユニットセットを決定し、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第1の基準値よりも小さい第2のユニットセットを決定し、そして、
前記均質化されたサービス処理ユニットのすべてのうちで前記第1のユニットセットに含まれるユニットの割合が第1のあらかじめ設定された割合よりも大きいということを決定する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである、請求項１７に記載の装置。
【請求項２０】
前記決定ユニットは、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービスの失敗の数にしたがって、通信パスのサービス成功率を算出し、
前記サービス成功率を第3の基準値と比較し、そして、
サービス成功率が前記第3の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１５に記載の装置。
【請求項２１】
前記決定ユニットは、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
前記サービス成功率を第2の基準値と比較し、
サービス成功率が前記第2の基準値よりも小さいサービス処理ユニットの数を決定し、
サービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの前記決定された数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第2の基準値よりも小さい前記サービス処理ユニットの割合を決定し、そして、
前記割合が第2のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定する、ように構成される、請求項１６に記載の装置。
【請求項２２】
前記決定ユニットは、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である、請求項２１に記載の装置。
【請求項２３】
前記送信ユニットは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるということを決定した後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するように構成される、請求項１５に記載の装置。
【請求項２４】
前記送信ユニットは、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定した後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション(MANO)ユニットに前記トラブルシューティングポリシーを送信するように構成される、請求項１６に記載の装置。
【請求項２５】
前記決定ユニットは、さらに、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の1つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される、請求項１５に記載の装置。
【請求項２６】
前記取得ユニットは、さらに、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用されるか、又は、
前記取得ユニットは、さらに、前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、請求項１６に記載の装置。
【請求項２７】
コンピュータ実行可能な命令を含むコンピュータプログラムであって、前記コンピュータ実行可能な命令は、トラブルシューティング装置のプロセッサによって実行されると、前記トラブルシューティング装置に、請求項１乃至１３のうちのいずれか１項に記載の方法を実行させる、コンピュータプログラム。
【請求項２８】
請求項２７に記載のコンピュータプログラムを記録しているコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、２０１５年９月２２日付で中国特許庁に出願された“トラブルシューティング方法及び装置”と題する中国特許出願番号第２０１５１０６０８７８２．１号に基づく優先権を主張し、その内容は、参照により全体が本明細書に取り込まれる。
【０００２】
この出願は、ネットワークデータ処理の分野に関し、特に、トラブルシューティング方法及び装置に関する。
【背景技術】
【０００３】
通信システムにおいては、あるデバイスにおいて障害が発生する場合であって、長時間にわたってその障害をトラブルシューティングすることができないときに引き起こされるその通信システムのパフォーマンスに対する深刻な影響を回避するために、その障害をトラブルシューティングするための方法が必要となる。
【０００４】
トラブルシューティング方法は、手動で実行されてもよい。しかしながら、ある障害の手動による検出及びその後のその障害のトラブルシューティングは、通常、比較的高い時間的なコスト及び人件費につながる。したがって、産業界は、次第に、通信システムの中のデバイスが、その通信システムにおける障害を自動的にトラブルシューティングして、トラブルシューティングの効率を改善するとともに人件費を削減することを期待している。
【０００５】
従来技術のトラブルシューティング方法においては、あるデバイスが障害のある状態となっているか否かは、主として、そのデバイスのハートビートメッセージにしたがって決定される。具体的には、モニタリングしているデバイスは、モニタリングされているデバイスにハートビートメッセージを周期的に送信してもよく、そのハートビートメッセージを受信した後に、そのモニタリングされているデバイスは、モニタリングしているデバイスに応答メッセージを返送してもよい。モニタリングしているデバイスが、そのハートビートメッセージを送信した後のある指定された時間以内に、モニタリングされているデバイスが返送した応答メッセージを受信していない場合には、そのモニタリングされているデバイスが障害のある状態となっているということを決定し、さらに、そのモニタリングされているデバイスの全体がリセットされるか、又は、そのモニタリングされているデバイスが持っている機能が、トラブルシューティングのために、他のデバイスに切り替えられる。
【０００６】
一方で、モニタリングしているデバイスが、指定された時間以内に応答メッセージを受信していない原因が複数存在する場合がある。例えば、その原因は、モニタリングされているデバイスが応答メッセージを送信するのに使用するインターフェイスユニットが障害のある状態となっているということである場合がある。この場合には、そのモニタリングされているデバイスの全体のリセット又は機能の切り替えを伴うことなく、そのモニタリングされているデバイスの他のインターフェイスユニットを起動して、インターフェイスユニットを置き換えてもよい。モニタリングされているデバイスの全体のリセット又は機能の切り替えは、比較的高いリスクを引き起こし、比較的大きな数のサービスに影響を与える。
【０００７】
結論として、従来技術のトラブルシューティング方法においては、デバイスのハートビートメッセージにしたがって、ある障害を分析し、そして、その障害をトラブルシューティングするが、このことは、障害の特定の精度が比較的低くなることにつながる。
【発明の概要】
【０００８】
この出願の目的は、重要なパフォーマンスインジケータ情報を使用することによって障害を突き止めて、デバイスのハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決するトラブルシューティング方法及び装置を提供することである。
【０００９】
上記の目的を実現するために、この出願は、以下の解決方法を提示する。
【００１０】
この出願の第１の態様の第１の可能な実装によれば、この出願は、トラブルシューティング方法であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するステップと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップと、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信し、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、ステップと、を含む、トラブルシューティング方法を提供する。
【００１１】
第１の態様の第２の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。
【００１２】
第１の態様の第３の可能な実装に関して、障害のあるオブジェクトを決定するステップは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップ、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、を含み、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。
【００１３】
第１の態様の第２の可能な実装の第１の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
前記サービス成功率を第１の基準値と比較するステップと、
サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップと、を含む。
【００１４】
第１の態様の第２の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記サービス成功率を第１の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。
【００１５】
第１の態様の第２の可能な実装の第１の具体的な実装の第２のより具体的な実装に関して、サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定するステップの前に、当該方法は、
均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも大きい第１のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも小さい第２のユニットセットを決定するステップと、
前記均質化されたサービス処理ユニットのすべてのうちで前記第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定するステップと、をさらに含み、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。
【００１６】
第１の態様の第２の可能な実装の第２の具体的な実装に関して、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
前記サービス成功率を第３の基準値と比較するステップと、
サービス成功率が前記第３の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定するステップと、を含む。
【００１７】
第１の態様の第３の可能な実装の第１の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集するステップと、
前記サービス成功率を第２の基準値と比較するステップと、
サービス成功率が前記第２の基準値よりも小さいサービス処理ユニットの数を決定するステップと、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第２の基準値よりも小さい前記サービス処理ユニットの割合を決定するステップと、
前記割合が第２のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定するステップと、を含む。
【００１８】
第１の態様の第３の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記サービス成功率を第２の基準値と比較するステップは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
前記サービス成功率を前記均質化された基準値と比較するステップと、を含み、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。
【００１９】
第１の態様の第２の可能な実装の第３の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するステップを含む。
【００２０】
第１の態様の第３の可能な実装の第２の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するステップの後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップの後に、ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するステップは、特に、
前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットに前記トラブルシューティングポリシーを送信するステップを含む。
【００２１】
第１の態様の第２の可能な実装の第４の具体的な実装に関して、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップの後に、当該方法は、
障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定するステップと、
ネットワークレベルのトラブルシューティングポリシーを決定するステップと、をさらに含み、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。
【００２２】
第１の態様の第３の可能な実装の第３の具体的な実装に関して、ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用される、ステップと、を含むか、又は、
ネットワークレベルのトラブルシューティングポリシーを決定するステップは、特に、
前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される、ステップと、を含む。
【００２３】
この出願の第２の態様の第１の可能な実装によれば、この出願は、トラブルシューティング装置であって、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニットと、
前記重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
前記障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニットと、
ネットワーク機能仮想化システムの中の管理ユニットに前記トラブルシューティングポリシーを送信するように構成され、それによって、前記管理ユニットが、前記トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニットと、を含む、トラブルシューティング装置を提供する。
【００２４】
第２の態様の第２の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
前記障害のあるオブジェクトが前記サービス処理ユニットの間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるか、又は、前記サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワーク要素レベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。
【００２５】
第２の態様の第３の可能な実装に関して、前記決定ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定するか、又は、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
前記障害のあるオブジェクトが、前記モニタリングされているネットワーク要素であるか、又は、前記モニタリングされているネットワーク要素と前記他のネットワーク要素との間の前記通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。
【００２６】
第２の態様の第２の可能な実装の第１の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
前記サービス成功率を第１の基準値と比較し、そして、
サービス成功率が前記第１の基準値よりも低いサービス処理ユニットが前記障害のあるオブジェクトであるということを決定する、ように構成される。
【００２７】
第２の態様の第２の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較するように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。
【００２８】
第２の態様の第２の可能な実装の第１の具体的な実装の第２のより具体的な実装に関して、前記決定ユニットは、さらに、
サービス成功率が前記第１の基準値よりも低い前記サービス処理ユニットが前記障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも大きい第１のユニットセットを決定し、
前記均質化されたサービス処理ユニットのうちでサービス成功率が前記第１の基準値よりも小さい第２のユニットセットを決定し、そして、
前記均質化されたサービス処理ユニットのすべてのうちで前記第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定する、ように構成され、
前記均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともに前記サービスが離散的に割り当てられる前記サービス処理ユニットである。
【００２９】
第２の態様の第２の可能な実装の第２の具体的な実装に関して、前記決定ユニットは、特に、
前記重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
前記サービス成功率を第３の基準値と比較し、そして、
サービス成功率が前記第３の基準値よりも小さい通信パスが前記障害のあるオブジェクトであるということを決定する、ように構成される。
【００３０】
第２の態様の第３の可能な実装の第１の具体的な実装に関して、前記決定ユニットは、特に、
各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの前記重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の前記数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
前記サービス成功率を第２の基準値と比較し、
サービス成功率が前記第２の基準値よりも小さいサービス処理ユニットの数を決定し、
前記数にしたがって、前記モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が前記第２の基準値よりも小さい前記サービス処理ユニットの割合を決定し、そして、
前記割合が第２のあらかじめ設定された割合よりも大きい場合に、前記モニタリングされているネットワーク要素が前記障害のあるオブジェクトであるということを決定する、ように構成される。
【００３１】
第２の態様の第３の可能な実装の第１の具体的な実装の第１のより具体的な実装に関して、前記決定ユニットは、特に、
前記サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
前記平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
前記サービス成功率を前記均質化された基準値と比較する、ように構成され、
前記均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともに前記サービスが離散的に割り当てられる前記モニタリングされているネットワーク要素である。
【００３２】
第２の態様の第２の可能な実装の第３の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中の前記サービス処理ユニットであるということを決定した後、又は、前記障害のあるオブジェクトが前記サービス処理ユニットの間の前記通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の前記モニタリングされているネットワーク要素のシステム管理モジュールに前記トラブルシューティングポリシーを送信するように構成される。
【００３３】
第２の態様の第３の可能な実装の第２の具体的な実装に関して、前記送信ユニットは、特に、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素であるということを決定した後、又は、前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、前記ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットに前記トラブルシューティングポリシーを送信するように構成される。
【００３４】
第２の態様の第２の可能な実装の第４の具体的な実装に関して、前記決定ユニットは、さらに、
前記障害のあるオブジェクトが前記モニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成され、前記ネットワークレベルのトラブルシューティングポリシーは、前記モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素にトラブルシューティング動作を実行するのに使用される。
【００３５】
第２の態様の第３の可能な実装の第３の具体的な実装に関して、前記取得ユニットは、さらに、
前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記障害のあるオブジェクトであると決定されている前記モニタリングされているネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素で置き換えるように前記管理ユニットに指示するのに使用されるか、又は、
前記取得ユニットは、さらに、前記障害のあるオブジェクトであると決定されている前記通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成され、
前記決定ユニットは、さらに、
前記状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成され、前記トラブルシューティング指示情報は、前記通信パスにあるフロントエンドネットワーク要素に対応する前記バックエンドネットワーク要素を、前記正常な動作状態にある前記冗長ネットワーク要素に切り替えるように前記管理ユニットに指示するのに使用される。
【００３６】
この出願によって提供される複数の特定の実施形態によれば、この出願は、以下の技術的効果を開示する。
【００３７】
この出願によって開示されるトラブルシューティング方法及び装置によれば、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。
【００３８】
さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。
【図面の簡単な説明】
【００３９】
本出願の複数の実施形態にしたがった複数の技術的解決方法をより明確に説明するために、以下の記載は、それらの複数の実施形態を説明するのに必要となる複数の添付の図面を簡潔に説明する。明らかなことではあるが、以下の説明の中の複数の添付の図面は、本発明の複数の実施形態のうちのいくつかを示しているにすぎず、当業者は、さらに、創造的な努力なくして、これらの複数の添付の図面から他の図面を導き出すことが可能である。
【００４０】
【図１】この出願にしたがったネットワーク機能仮想化（ＮＦＶ）システムのアーキテクチャ図である。
【図２】この出願にしたがったトラブルシューティング方法の実施形態１のフローチャートである。
【図３】この出願にしたがったトラブルシューティング方法の実施形態２のフローチャートである。
【図４】この出願にしたがったトラブルシューティング方法の実施形態３のフローチャートである。
【図５】この出願にしたがったトラブルシューティング装置の１つの実施形態の構成図である。
【図６】この出願にしたがった計算ノードの構成図である。
【発明を実施するための形態】
【００４１】
以下の記載は、本出願の複数の実施形態にしたがった複数の添付の図面を参照して、本出願のそれらの複数の実施形態にしたがった複数の技術的解決方法を明確に説明する。明らかなことではあるが、それらの説明される実施形態は、本出願の複数の実施形態のうちのいくつかに過ぎず、すべてではない。創造的な努力なくして当業者が本出願のそれらの複数の実施形態に基づいて取得することが可能であるすべての他の実施形態は、本出願の保護の範囲に属するものとする。
【００４２】
この出願の目的、特徴、及び利点をよりわかりやすくするために、この出願は、さらに、複数の添付の図面及び複数の特定の実施形態を参照して以下で詳細に解説される。
【００４３】
図１は、この出願にしたがったネットワーク機能仮想化（ＮＦＶ）システムのアーキテクチャ図である。この出願にしたがったトラブルシューティング方法は、主として、ＮＦＶシステムに適用される。図１に示されているように、ＮＦＶシステムは、主に、
ネットワーク機能仮想化オーケストレータ（ＮＦＶ  Ｏｒｃｈｅｓｔｒａｔｏｒ）へのサービス要求を開始し、そして、あるサービスに必要なリソースを提供する、ように構成され、障害処理の役割を担う、オペレーションサポートシステム（Ｏｐｅｒａｔｉｏｎｓ  Ｓｕｐｐｏｒｔ  Ｓｙｓｔｅｍ，  ＯＳＳ）／ビジネスサポートシステム（Ｂｕｓｉｎｅｓｓ  Ｓｕｐｐｏｒｔ  Ｓｙｓｔｅｍ，  ＢＳＳ）と、
ＯＳＳ／ＢＳＳのサービス要求にしたがってＮＦＶサービスを実装する役割を担うとともに、ネットワークサービス（Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ，  ＮＳ）のライフサイクル管理の役割を担い、そして、管理リソースを組織化する役割を担い、及び、仮想化されたネットワーク機能（Ｖｉｒｔｕａｌｉｚｅｄ  Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎ，  ＶＮＦ）及びネットワーク機能仮想化インフラストラクチャ（Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎｓ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ，  ＮＦＶＩ）のリソース及び実行状態情報をリアルタイムでモニタリングする役割を担うオーケストレータ（Ｏｒｃｈｅｓｔｒａｔｏｒ）と、
例えば、起動、有効期間、及びＶＮＦ実行状態情報の管理等のＶＮＦ生成周期の管理の役割を担う仮想化されたネットワーク機能マネージャ（ＶＮＦ  Ｍａｎａｇｅｒ，  ＶＮＦＭ）と、
ＮＦＶＩリソースを管理しそして割り当てる役割を担うとともに、ＮＦＶＩ実行状態情報をモニタリングしそして収集する役割を担う仮想化されたインフラストラクチャマネージャ（Ｖｉｒｔｕａｌｉｚｅｄ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｍａｎａｇｅｒ，  ＶＩＭ）と、
ネットワーク要素の障害管理、構成管理、課金管理、パフォーマンス管理、セキュリティ管理（Ｆａｕｌｔ  Ｍａｎａｇｅｍｅｎｔ，  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ，  Ａｃｃｏｕｎｔｉｎｇ  Ｍａｎａｇｅｍｅｎｔ，  Ｐｅｒｆｏｒｍａｎｃｅ  Ｍａｎａｇｅｍｅｎｔ，  Ｓｅｃｕｒｉｔｙ  Ｍａｎａｇｅｍｅｎｔ，  ＦＣＡＰＳ）の役割を担う要素管理システム（Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ，  ＥＭＳ）と、を含む。
【００４４】
ＮＦＶＩリソースは、利用可能な／予約された／割り当てられたＮＦＶＩリソース等のすべてのＮＦＶＩリソースを含む。
【００４５】
この出願にしたがったトラブルシューティング方法は、ネットワーク要素の重要なパフォーマンスインジケータ（Ｋｅｙ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｉｎｄｉｃａｔｏｒ，  ＫＰＩ）モニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールは、ＮＦＶシステムの中のＶＮＦ、ＥＭＳ、又は管理及びオーケストレータ（Ｍａｎａｇｅｍｅｎｔ  ａｎｄ  Ｏｒｃｈｅｓｔｒａｔｏｒ，  ＭＡＮＯ）ユニットの中に配置されてもよく、又は、独立したネットワークノードに配置されてもよい。ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール及びネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールは、統合された方法で配置されてもよく、又は、個別に配置されてもよい。
【００４６】
図２は、この出願にしたがったトラブルシューティング方法の実施形態１のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素のＫＰＩモニタリング及びトラブルシューティング決定モジュール又はネットワークのＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図２に示されているように、上記の方法は、以下のステップを含む。
【００４７】
ステップ１０１：  モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ（Ｋｅｙ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｉｎｄｉｃａｔｏｒ，  ＫＰＩ）情報を取得する。
【００４８】
モニタリングされているネットワーク要素は、例えば、ＶＮＦ等のネットワーク機能仮想化（Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ，  ＮＦＶ）システムの中のネットワーク要素である。
【００４９】
モニタリングされているネットワーク要素の中に１つ又は複数のサービス処理ユニットが存在してもよい。
【００５０】
重要なパフォーマンスインジケータ情報は、サービス処理ユニットが受信するサービス要求の数、サービス要求の数に対応しているサービス失敗の数、及び／又は各々のサービス失敗の原因等の情報を含んでもよい。実際の適用では、重要なパフォーマンスインジケータ情報に含まれる情報のタイプは、要求に応じて設定されてもよい。例えば、重要なパフォーマンスインジケータ情報は、サービス遅延情報等の情報をさらに含んでもよい。
【００５１】
モニタリングされているネットワーク要素は、重要なパフォーマンスインジケータ情報を周期的に報告してもよい。
【００５２】
ステップ１０１が実行される前に、さらに、ＥＭＳ及び／又はＭＡＮＯに関する情報にしたがって、モニタリングされることが必要であるネットワーク要素を決定してもよいということに留意すべきである。ＥＭＳ及び／又はＭＡＮＯによって記録されているネットワーク要素の内部に配置されているサービス処理ユニットに関する情報及びネットワークの中に配置されているネットワーク要素に関する情報を取得してもよい。ネットワークの中に配置されているネットワーク要素に関する記録された情報に対応するネットワーク要素は、モニタリングされているネットワーク要素として決定される。ネットワーク要素の内部に配置されているサービス処理ユニットに関する記録された情報に対応するサービス処理ユニットは、モニタリングされることが必要であるサービス処理ユニットとして決定される。
【００５３】
ステップ１０２：  重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定する。
【００５４】
例えば、重要なパフォーマンスインジケータ情報にしたがって、あるサービス処理ユニットによって実行されるサービスの成功率を算出してもよい。その成功率がある特定の比率よりも低い場合には、障害のあるオブジェクトがそのサービス処理ユニットであるということを決定してもよい。相対的に低い成功率を有するサービス処理ユニットの数が、（例えば、そのモニタリングされているネットワーク要素の中のサービス処理ユニットの合計数のうちの８０％を超えるといったように）相対的に大きい場合には、障害のあるオブジェクトが、そのモニタリングされているネットワーク要素以外のネットワーク要素であるということを決定してもよい。他の例では、あるモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信のタイムアウトによって引き起こされるサービス失敗の重要なパフォーマンスインジケータ情報の中に記録されている数が、相対的に高い場合には、そのモニタリングされているネットワーク要素から次のホップのネットワーク要素への通信パスが障害を持っているということ、又はその次のホップのネットワーク要素が障害を持っているということを決定してもよい。
【００５５】
ステップ１０３：  障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する。
【００５６】
障害のあるオブジェクトが、モニタリングされているネットワーク要素の内部に存在するあるサービス処理ユニットである場合には、ネットワーク要素レベルのトラブルシューティングポリシーを決定してもよい。そのネットワーク要素レベルのトラブルシューティングポリシーは、そのモニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。
【００５７】
障害のあるオブジェクトがそのモニタリングされているネットワーク要素以外のネットワーク要素である場合には、ネットワークレベルのトラブルシューティングポリシーを決定してもよい。そのネットワークレベルのトラブルシューティングポリシーは、そのモニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。
【００５８】
ステップ１０４：  ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信し、それによって、その管理ユニットは、そのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する。
【００５９】
管理ユニットは、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールであってもよく、又は、ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットであってもよい。
【００６０】
ネットワーク要素レベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する手法は、以下の手法、すなわち、
障害のあるサービス処理ユニットの予備のユニットを決定し、そして、その障害のあるサービス処理ユニットが持っているサービスをその予備のユニットに切り替える手法、又は、
その障害にあるサービス処理ユニットをリセットする手法、を含んでもよく、
その予備のユニットが障害のある状態になった場合には、その障害のあるサービス処理ユニット及びその予備のユニットは、分離されてもよい。
【００６１】
ネットワークレベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行する手法は、以下の手法、すなわち、
障害のあるネットワーク要素の予備のネットワーク要素を決定するステップと、
その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるステップと、を含む手法、又は、
障害のあるパスの予備のパスを決定するステップと、
その障害のあるパスが持っているサービスをその予備のパスに切り替えるステップと、を含む手法、を含んでもよく、
その予備のパスが障害のある状態になったということを決定する場合には、その予備のパスの側にあるネットワーク要素の予備のネットワーク要素をさらに決定してもよく、
その予備のパスの側にあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替える。
【００６２】
結論として、この実施形態においては、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。
【００６３】
実際の適用においては、障害のあるオブジェクトを決定するステップは、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップ、又は、
障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定するステップ、を含んでもよい。
【００６４】
障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
障害のあるオブジェクトが、モニタリングされているネットワーク要素の中のサービス処理ユニットであるか、又は、サービス処理ユニットの間の前記通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定するステップを含んでもよく、そのネットワーク要素レベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。
【００６５】
実際の適用においては、障害のあるオブジェクトを決定するステップは、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定するステップ、又は、
障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定するステップ、をさらに含んでもよい。
【００６６】
障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定するステップは、特に、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と前記他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを含み、そのネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。
【００６７】
本発明のこの実施形態にしたがった方法に基づいて、実際の適用においては、ネットワーク要素レベルの障害については、最初に、ネットワーク要素レベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行してもよく、そのトラブルシューティングが失敗した場合に、ネットワークレベルのトラブルシューティングポリシーを使用して、トラブルシューティングを実行してもよいということに留意すべきである。
【００６８】
実際の適用においては、障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。
【００６９】
上記のステップにおいて、サービス失敗の数は、サービス処理ユニット自体によって引き起こされるサービス失敗の数であってもよい。特に、重要なパフォーマンスインジケータ情報の中にサービス失敗の原因を記録してもよく、そのサービス失敗の原因にしたがって、そのサービス処理ユニット自体によって引き起こされるサービス失敗の数に関する統計量を収集してもよい。
【００７０】
上記のステップにおいて、基準値は、あらかじめ設定された値であってもよく、又は、均質化されたサービス処理ユニットの平均サービス成功率に関する統計量にしたがって取得される均質化された基準値であってもよいということにさらに留意すべきである。したがって、サービス成功率を基準値と比較するステップは、特に、
サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定するステップと、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
サービス成功率を均質化された基準値と比較するステップと、を含んでもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。
【００７１】
均質化されたサービス処理ユニットは、複数の均質化されたサービス処理ユニットのサービス成功率のすべてが、ある理由に起因して、あらかじめ設定された基準値よりも低いという現象に直面する場合があるということに留意すべきである。この場合には、そのあらかじめ設定された基準値よりも低いサービス成功率を有するそれらの均質化されたサービス処理ユニットは、障害のある状態ではない場合がある。ほとんどの均質化されたサービス処理ユニットのサービス成功率は、他のデバイスの障害に起因して、減少している場合がある。上記の場合には、均質化されたサービス処理ユニットが障害のある状態であるということを誤って決定するのを防止するために、サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定するステップの前に、さらに、
均質化されたサービス処理ユニットのうちでサービス成功率があらかじめ設定された基準値よりも大きい第１のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのうちでサービス成功率がその基準値よりも小さい第２のユニットセットを決定するステップと、
均質化されたサービス処理ユニットのすべてのうちで第１のユニットセットに含まれるユニットの割合があらかじめ設定された割合よりも大きいということを決定するステップと、を使用してもよい。
【００７２】
上記のステップにおいて、実際の要求に応じて、あらかじめ設定された割合を設定してもよく、例えば、９０％に設定してもよい。すなわち、それらの均質化されたサービス処理ユニットのうちの９０％又はより多くの数のサービス成功率が、上記のあらかじめ設定された基準値よりも高く、そして、それらの均質化されたサービス処理ユニットのうちの１０％又はより少ない数のサービス成功率が、上記のあらかじめ設定された基準値よりも小さい場合には、その基準値よりも小さいサービス成功率を有する均質化されたサービス処理ユニットを、障害のあるオブジェクトとして決定してもよい。
【００７３】
実際の適用においては、障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも小さい通信パスが障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。
【００７４】
実際の適用においては、障害のあるオブジェクトが、モニタリングされているネットワーク要素が属するネットワークの中のネットワーク要素であるということを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、モニタリングされているネットワーク要素のサービス成功率に関する統計量を収集するステップと、
サービス成功率を基準値と比較するステップと、
サービス成功率がその基準値よりも小さいモニタリングされているネットワーク要素が障害のあるオブジェクトであるということを決定するステップと、を含んでもよい。
【００７５】
１つのネットワーク要素は、複数のサービス処理ユニットを含んでいてもよいということに留意すべきである。したがって、１つのネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得することが可能であり、各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報に含まれているとともにサービス要求の数に対応しているサービス失敗の数にしたがって、そのネットワーク要素が受信したサービス要求の数及びサービス要求のその数に対応しているサービス失敗の数に関する統計量を収集する。さらに、モニタリングされているネットワーク要素のサービス成功率を算出する。
【００７６】
実際の適用においては、サービス成功率を基準値と比較するステップは、特に、
サービス成功率をあらかじめ設定された基準値と比較するステップを含むか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定するステップと、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得するステップと、
サービス成功率を均質化された基準値と比較するステップと、を含んでもよく、
均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともにサービスが離散的に割り当てられるモニタリングされているネットワーク要素である。
【００７７】
図３は、この出願にしたがったトラブルシューティング方法の実施形態２のフローチャートである。この実施形態にしたがった方法は、ネットワーク要素ＫＰＩモニタリング及びトラブルシューティング決定モジュールによって実行されてもよい。図３に示されているように、上記の方法は、以下のステップを含んでもよい。
【００７８】
ステップ２０１：  モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。
【００７９】
この実施形態においては、サービス処理ユニットは、スレッド、プロセス、及び仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ，  ＶＭ）等であってもよい。重要なパフォーマンスインジケータ情報は、少なくとも、サービス処理ユニットが受信したサービス要求の数及びサービス要求の数に対応しているサービス失敗の数を含んでいてもよい。
【００８０】
ステップ２０２：  重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出する。
【００８１】
サービス要求の数からサービス失敗の数を減算し、得られた差をサービス要求の数で除算し、そして、得られた商に１００％を乗算することによって、サービス成功率を取得してもよい。
【００８２】
ステップ２０３：  サービス成功率を基準値と比較する。
【００８３】
実際の要求に応じて基準値を設定してもよい。例えば、通常のサービス処理ユニットのサービス成功率が、９５％又はより高い場合に、基準値を９５％に設定してもよい。
【００８４】
代替的に、均質化されたサービス処理ユニットの平均サービス成功率にしたがって、上記の基準値を算出してもよい。均質化されたサービス処理ユニットは、そのサービス成功率に対応しているサービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにそのサービス成功率に対応しているサービス処理ユニットの外部サービスネットワーキングと同じ外部サービスネットワーキングを有するサービス処理ユニットである。複数の均質化されたサービス処理ユニットが受信する（へと配信される）サービス要求メッセージは、無作為に分かれている。したがって、それらの複数の均質化されたサービス処理ユニットのサービス成功率は、基本的に同様であるはずである。したがって、均質化されたサービス処理ユニットの平均サービス成功率にしたがって均質化された基準値を算出してもよい。
【００８５】
特に、平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得してもよい。実際の要求に応じて、そのあらかじめ設定された値を設定してもよく、例えば、２０％又は１０％に設定してもよい。
【００８６】
ステップ２０４：  サービス成功率が基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する。
【００８７】
ステップ２０５：  障害のあるオブジェクトが、サービス処理ユニットである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する。
【００８８】
ステップ２０６：  ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信する。
【００８９】
ステップ２０５におけるネットワーク要素レベルのトラブルシューティングポリシーは、障害のあるサービス処理ユニットをリセットするようにシステム管理モジュールに指示してもよい。ネットワーク要素レベルのトラブルシューティングポリシーを受信した後に、システム管理モジュールは、障害のあるサービス処理ユニットをリセットしてもよい。
【００９０】
リセットされたサービス処理ユニットが依然として障害のある状態にある場合には、さらに、その障害のあるサービス処理ユニットを分離してもよいということに留意すべきである。さらに、分離されたサービス処理ユニットの数が第２のあらかじめ設定された閾値に達しているということを決定する場合には、ネットワークレベルのトラブルシューティングポリシーを遂行してもよい。ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。例えば、モニタリングされているネットワーク要素の次のホップの障害のあるネットワーク要素又は障害のある通信パスに対して切り替えを実行してもよい。冗長グループの中のネットワーク要素又は通信パスの健全性状態にしたがって、その切り替えに関する目標ネットワーク要素又は目標通信パスを選択してもよい。
【００９１】
障害のあるサービス処理ユニットが動作中の／予備のサービス処理ユニットである場合には、トラブルシューティングポリシーは、障害のあるサービス処理ユニットの予備のユニットを決定するステップ、及び、その障害のあるサービス処理ユニットが持っているサービスをその予備のユニットに切り替えるステップ、であってもよいということにさらに留意すべきである。さらに、予備のユニットが障害のある状態になった場合には、その障害のあるサービス処理ユニット及びその予備のユニットを分離してもよい。
【００９２】
図４は、この出願にしたがったトラブルシューティング方法の実施形態３のフローチャートである。ネットワークＫＰＩモニタリング及びトラブルシューティング決定モジュールによって、この実施形態にしたがった方法を実行してもよい。図４に示されているように、その方法は、以下のステップを含んでもよい。
【００９３】
ステップ３０１：  モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得する。
【００９４】
ステップ３０２：  重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出する。
【００９５】
ステップ３０３：  サービス成功率を基準値と比較する。
【００９６】
ステップ３０４：  サービス成功率が基準値よりも小さいサービス処理ユニットの数を決定する。
【００９７】
ステップ３０５：  数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が基準値よりも小さいサービス処理ユニットの割合を決定する。
【００９８】
サービス成功率が基準値よりも低いサービス処理ユニットの数が８であり、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべての数が１０であると仮定すると、上記の割合は８０％である。
【００９９】
ステップ３０６：  割合があらかじめ設定された割合よりも大きい場合に、障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定する。
【０１００】
実際の要求に応じて、あらかじめ設定された割合を設定してもよい。例えば、あらかじめ設定された割合を５０％又は８０％に設定してもよい。
【０１０１】
ステップ３０７：  障害のあるオブジェクトが、モニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素である場合に、ネットワークレベルのトラブルシューティングポリシーを決定する。
【０１０２】
障害のある位置が、モニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素である場合に、その障害のあるネットワーク要素を回復させるために、ネットワークレベルのトラブルシューティングポリシーを使用する必要がある。
【０１０３】
実際に適用においては、特に、ネットワークレベルのトラブルシューティングポリシーを決定するステップを複数の手法にしたがって実装してもよい。例えば、
障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するステップと、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、トラブルシューティング指示情報は、障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素を、正常な動作状態にある冗長ネットワーク要素で置き換えるように管理ユニットに指示するのに使用される、ステップと、を使用してもよい。
【０１０４】
上記のステップにおいて、障害のあるモニタリングされているネットワーク要素を置き換えるのに使用される冗長ネットワーク要素は、正常に動作することが可能であるということを保証することが可能である。モニタリングされているネットワーク要素の冗長ネットワーク要素のすべてが正常ではない場合には、その障害のあるモニタリングされているネットワーク要素を置き換えるのにあらかじめ設定された冗長ネットワーク要素を使用することは不可能であり、その障害のあるモニタリングされているネットワーク要素を置き換えるのに、正常に動作することが可能である他のネットワーク要素を見つけてもよい。
【０１０５】
他の例では、
障害のあるオブジェクトであると決定されている通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するステップと、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定するステップと、
ネットワークレベルのトラブルシューティング指示情報を生成するステップであって、トラブルシューティング指示情報は、通信パスにあるフロントエンドネットワーク要素に対応するバックエンドネットワーク要素を、正常な動作状態にある冗長ネットワーク要素に切り替えるように管理ユニットに指示するのに使用される、ステップと、を使用してもよい。
【０１０６】
上記のステップにおいて、切り替えられる冗長ネットワーク要素は、正常に動作することが可能であるということを保証することが可能である。通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素のすべてが正常ではない場合に、その切り替えのために、あらかじめ設定された冗長ネットワーク要素を使用することは不可能であり、その切り替えのために、正常に動作することが可能である他のネットワーク要素を見つけてもよい。
【０１０７】
ステップ３０８：  ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットにトラブルシューティングポリシーを送信する。
【０１０８】
ネットワークレベルのトラブルシューティングポリシーは、障害のあるネットワーク要素の予備のネットワーク要素を決定し、そして、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにＭＡＮＯユニットに指示してもよい。
【０１０９】
ネットワークレベルのトラブルシューティングポリシーを受信する場合に、ＭＡＮＯユニットは、障害のあるネットワーク要素の予備のネットワーク要素を決定してもよい。障害のあるネットワーク要素の予備のネットワーク要素を決定した後に、ＭＡＮＯユニットは、ＶＮＦＭに指示シグナリングを送信して、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えるようにＶＮＦＭに指示してもよい。その指示シグナリングを受信した後に、ＶＮＦＭは、その障害のあるネットワーク要素が持っているサービスをその予備のネットワーク要素に切り替えてもよい。
【０１１０】
この出願のこの実施形態において、重要なパフォーマンスインジケータ情報は、サービス失敗の原因に関する情報及びそのサービス失敗の原因によって引き起こされるサービス失敗の数に関する情報をさらに含んでもよい。サービス失敗の原因は、ダウンストリームネットワーク要素への通信のタイムアウト、リソースの不足、モニタリングされているネットワーク要素の複数の内部モジュールの間の通信のタイムアウト、及び（ソフトウェアの内部データの無効性及び正常ではないブランチに入るコード処理等の）ソフトウェアの内部エラー等を含んでもよい。したがって、この出願にしたがった重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定するステップは、特に、
重要なパフォーマンスインジケータ情報の中に含まれるサービス失敗の原因に関する情報にしたがって、障害のあるオブジェクトを決定するステップをさらに含んでもよい。
【０１１１】
サービス処理のタイムアウトによって引き起こされるサービス失敗の数及びモニタリングされているネットワーク要素がダウンストリームネットワーク要素に送信するとともに重要なパフォーマンスインジケータ情報の中に記録されているサービス要求の数にしたがって、サービス処理のタイムアウトによって引き起こされる失敗したサービスの割合を決定してもよい。
【０１１２】
失敗したサービスの割合があらかじめ設定された閾値と等しいか又はより大きい場合に、障害のある位置がそのモニタリングされているネットワーク要素であるということを決定してもよい。そのモニタリングされているネットワーク要素が属しているネットワークの中のネットワーク要素は、そのネットワーク要素の外部ネットワーク要素及びそのネットワーク要素自体を含んでもよい。したがって、この場合には、ネットワークレベルのトラブルシューティングポリシーを使用することが可能である。
【０１１３】
さらに、前にモニタリングされていた均質化されたサービス処理ユニットについては、リソースの不足によって引き起こされるサービス失敗の数を除外してもよく、サービス失敗の数に関する統計量を収集する間に、サービス失敗の合計の統計的な数に、リソースの不足によって引き起こされるサービス失敗の数を計数しなくてもよい。この場合の主たる原因は、サービスの数が過度に大きいということであり、サービス処理ユニットそれ自体は、通常、障害のある状態ではない。
【０１１４】
この出願は、さらに、トラブルシューティング装置を提供する。
【０１１５】
図５は、この出願にしたがったトラブルシューティング装置の１つの実施形態の構成図である。図５に示されているように、その装置は、
モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得するように構成される取得ユニット５０１と、
重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、そして、
障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定する、
ように構成される決定ユニット５０２と、
ネットワーク機能仮想化システムの中の管理ユニットにトラブルシューティングポリシーを送信するように構成され、それによって、管理ユニットが、トラブルシューティングポリシーを使用して、トラブルシューティングを実行する、送信ユニット５０３と、を含んでもよい。
【０１１６】
この実施形態においては、モニタリングされているネットワーク要素の中の各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報を取得し、その重要なパフォーマンスインジケータ情報にしたがって、障害のあるオブジェクトを決定し、その障害のあるオブジェクトにしたがって、トラブルシューティングポリシーを決定し、そして、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。重要なパフォーマンスインジケータ情報を使用することによって、障害を突き止めることが可能であり、それによって、ネットワーク要素のハートビートメッセージにしたがった障害の特定の精度が比較的低くなるという課題を解決することが可能である。さらに、障害のあるオブジェクトにしたがってトラブルシューティングポリシーを決定し、ネットワーク機能仮想化システムの中の管理ユニットにそのトラブルシューティングポリシーを送信する。したがって、適切なトラブルシューティングポリシーを使用することが可能であり、このことは、トラブルシューティングプロセスの間に生じるリスクを減少させ、トラブルシューティングプロセスの間のサービスに対する影響を軽減する。
【０１１７】
実際の適用においては、決定ユニット５０２は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定するか、又は、
障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素の中のサービス処理ユニットであるか、又は、サービス処理ユニットの間の通信パスである場合に、ネットワーク要素レベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワーク要素レベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素の内部でトラブルシューティング動作を実行するのに使用される。
【０１１８】
実際の適用においては、決定ユニット５０２は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定するか、又は、
障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定し、そして、
障害のあるオブジェクトが、モニタリングされているネットワーク要素であるか、又は、モニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスである場合に、ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。
【０１１９】
実際の適用においては、決定ユニット５０２は、特に、
重要なパフォーマンスインジケータ情報の中のサービス処理ユニットが受信したサービス要求の数及び重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、サービス処理ユニットが実行したサービスのサービス成功率を算出し、
サービス成功率を第１の基準値と比較し、そして、
サービス成功率が第１の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。
【０１２０】
実際の適用においては、決定ユニット５０２は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたサービス処理ユニットの平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較するように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。
【０１２１】
実際の適用においては、決定ユニット５０２は、さらに、
サービス成功率が第１の基準値よりも低いサービス処理ユニットが障害のあるオブジェクトであるという決定の前に、均質化されたサービス処理ユニットのうちでサービス成功率が第１の基準値よりも大きい第１のユニットセットを決定し、
均質化されたサービス処理ユニットのうちでサービス成功率が第１の基準値よりも小さい第２のユニットセットを決定し、そして、
均質化されたサービス処理ユニットのすべてのうちで第１のユニットセットに含まれるユニットの割合が第１のあらかじめ設定された割合よりも大きいということを決定する、ように構成されてもよく、
均質化されたサービス処理ユニットは、サービス処理ユニットが持っているサービスのサービスロジックと同じサービスロジックを有するとともにサービスが離散的に割り当てられるサービス処理ユニットである。
【０１２２】
実際の適用においては、決定ユニット５０２は、特に、
重要なパフォーマンスインジケータ情報の中に存在するとともに通信パスの障害によって引き起こされるサービス失敗の数にしたがって、通信パスのサービス成功率を算出し、
サービス成功率を第３の基準値と比較し、そして、
サービス成功率が第３の基準値よりも小さい通信パスが障害のあるオブジェクトであるということを決定する、ように構成されてもよい。
【０１２３】
実際の適用においては、決定ユニット５０２は、特に、
各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中の各々のサービス処理ユニットが受信したサービス要求の数及び各々のサービス処理ユニットの重要なパフォーマンスインジケータ情報の中に存在するとともにサービス要求の数に対応しているサービス失敗の数にしたがって、各々のサービス処理ユニットのサービス成功率に関する統計量を収集し、
サービス成功率を第２の基準値と比較し、
サービス成功率が第２の基準値よりも小さいサービス処理ユニットの数を決定し、
数にしたがって、モニタリングされているネットワーク要素の中のサービス処理ユニットのすべてのうちでサービス成功率が第２の基準値よりも小さいサービス処理ユニットの割合を決定し、そして、
割合が第２のあらかじめ設定された割合よりも大きい場合に、モニタリングされているネットワーク要素が障害のあるオブジェクトであるということを決定する、ように構成されてもよい。
【０１２４】
決定ユニット５０２は、特に、
サービス成功率をあらかじめ設定された基準値と比較するように構成されるか、又は、
均質化されたネットワーク要素の平均サービス成功率を決定し、
平均サービス成功率からあらかじめ設定された値を減算して、均質化された基準値を取得し、そして、
サービス成功率を均質化された基準値と比較する、ように構成されてもよく、
均質化されたネットワーク要素は、モニタリングされているネットワーク要素のサービスロジックと同じサービスロジックを有するサービスを持っているとともにサービスが離散的に割り当てられるモニタリングされているネットワーク要素である。
【０１２５】
実際の適用においては、送信ユニット５０３は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるということを決定した後、又は、障害のあるオブジェクトがサービス処理ユニットの間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中のモニタリングされているネットワーク要素のシステム管理モジュールにトラブルシューティングポリシーを送信するように構成されてもよい。
【０１２６】
実際の適用においては、送信ユニット５０３は、特に、
障害のあるオブジェクトがモニタリングされているネットワーク要素であるということを決定した後、又は、障害のあるオブジェクトがモニタリングされているネットワーク要素と他のネットワーク要素との間の通信パスであるということを決定した後に、ネットワーク機能仮想化システムの中の管理及びオーケストレーション（ＭＡＮＯ）ユニットにトラブルシューティングポリシーを送信するように構成されてもよい。
【０１２７】
実際の適用においては、決定ユニット５０２は、さらに、
障害のあるオブジェクトがモニタリングされているネットワーク要素の中のサービス処理ユニットであるという決定の後に、障害のあるサービス処理ユニットの数が、あらかじめ設定された閾値に達したということを決定し、そして、
ネットワークレベルのトラブルシューティングポリシーを決定する、ように構成されてもよく、ネットワークレベルのトラブルシューティングポリシーは、モニタリングされているネットワーク要素が位置しているネットワークの中の１つ又は複数のネットワーク要素に対してトラブルシューティング動作を実行するのに使用される。
【０１２８】
実際の適用においては、取得ユニット５０１は、さらに、
障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素に関連付けられている冗長ネットワーク要素の状態情報を取得するように構成されてもよい。
【０１２９】
決定ユニット５０２は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、障害のあるオブジェクトであると決定されているモニタリングされているネットワーク要素を、正常な動作状態にある冗長ネットワーク要素で置き換えるように管理ユニットに指示するのに使用される。
【０１３０】
代替的に、取得ユニット５０１は、さらに、障害のあるオブジェクトであると決定されている通信パスにあるバックエンドネットワーク要素の冗長ネットワーク要素の状態情報を取得するように構成される。
【０１３１】
決定ユニット５０２は、さらに、
状態情報にしたがって、正常な動作状態にある冗長ネットワーク要素を決定し、そして、
ネットワークレベルのトラブルシューティング指示情報を生成する、ように構成されてもよく、トラブルシューティング指示情報は、通信パスにあるフロントエンドネットワーク要素に対応するバックエンドネットワーク要素を、正常な動作状態にある冗長ネットワーク要素に切り替えるように管理ユニットに指示するのに使用される。
【０１３２】
さらに、この出願の１つの実施形態は、さらに、計算ノードを提供する。その計算ノードは、計算能力を有するホストサーバ、パーソナルコンピュータＰＣ、携帯用コンピュータ、又は端末等であってもよい。この出願の複数の特定の実施形態は、その計算ノードの特定の実装にいかなる制約も課するものではない。
【０１３３】
図６は、この出願にしたがった計算ノードの構成図である。図６に示されているように、計算ノード６００は、
プロセッサ（ｐｒｏｃｅｓｓｏｒ）６１０、通信インターフェイス（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｉｎｔｅｒｆａｃｅ）６２０、メモリ（ｍｅｍｏｒｙ）６３０、及び通信バス６４０を含む。
【０１３４】
プロセッサ６１０、通信インターフェイス６２０、及びメモリ６３０は、通信バス６４０を使用することによって互いに通信する。
【０１３５】
プロセッサ６１０は、プログラム６３２を実行するように構成される。
【０１３６】
特に、プログラム６３２は、プログラムコードを含んでもよく、プログラムコードは、コンピュータ動作命令を含む。
【０１３７】
プロセッサ６１０は、中央処理ユニットＣＰＵ、又は特定用途向け集積回路ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、又は、この出願の複数の実施形態を実装するように構成される１つ又は複数の集積回路であってもよい。
【０１３８】
メモリ６３０は、プログラム６３２を格納するように構成される。メモリ６３０は、高速ＲＡＭメモリを含んでもよく、少なくとも１つのディスクメモリ等の不揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ  ｍｅｍｏｒｙ）をさらに含んでもよい。プログラム６３２は、特に、図５に示されている実施形態にしたがった対応するモジュール又はユニットを含んでもよく、本明細書においては、細部は説明されない。
【０１３９】
最後に、この出願においては、第１の及び第２の等の関係を示す語は、他方のエンティティ又は動作から一方のエンティティ又は動作を区別するのに使用されるにすぎず、これらのエンティティ又は動作の間にいずれかの実際的な関係又は順序が存在するということを必然的に要求する又は示唆するものではないということに留意すべきである。さらに、“包含する”又は“含む”との記載或いはいずれかの他の変形語は、非制限的な包含を対象とすることを意図しており、結果として、構成要素のリストを含むプロセス、方法、製品、又は装置は、それらの構成要素を包含するのみならず、明白には列記されていない他の構成要素も含み、或いは、そのようなプロセス、方法、製品、又は装置に固有の複数の構成要素をさらに含む。“…を包含する”との記載の後に続くある構成要素は、それ以上制限されることなく、その構成要素を包含するそのプロセス、方法、製品、又は装置の中の複数の追加的な同等の構成要素の存在を除外するものではない。
【０１４０】
複数の実施形態の上記の説明に基づいて、当業者は、必要なハードウェアプラットフォームのほかにソフトウェアによって本出願を実装してもよく、或いは、ハードウェアのみによって本出願を実装してもよいということを明確に理解することが可能である。ほとんどの環境においては、必要なハードウェアプラットフォームに加えてソフトウェアによる実装が、好ましい実装である。そのような理解に基づいて、背景技術の部分にしたがった技術に対する貢献を示す本出願の複数の技術的解決方法のうちのすべて又は一部を、ソフトウェア製品の形態で実装してもよい。コンピュータソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク、又は光ディスク等の記憶媒体の中に格納されてもよく、複数の命令を含んでもよく、それらの複数の命令は、本出願の複数の実施形態又はそれらの複数の実施形態のうちの複数の部分において説明された複数の方法を実行するように、パーソナルコンピュータ、サーバ、又はネットワークデバイスであってもよいコンピュータデバイスに指示する。
【０１４１】
本明細書における複数の実施形態は、すべてが、革新的な手法で説明されており、これらの実施形態の中の同じ部分又は同様な部分については、これらの実施形態を参照することが可能であり、各々の実施形態は、他の実施形態とは異なる点に焦点を当てている。それらの複数の実施形態にしたがって開示された装置は、それらの複数の実施形態にしたがって開示された方法に対応しているため、比較的簡潔に説明されており、その方法の実施形態に関連する部分については、その方法の説明を参照することが可能である。
【０１４２】
本出願の原理及び複数の実施形態を説明するために、複数の特定の例が、本明細書の中で使用されている。上記の複数の実施形態は、本出願の方法及び概念の理解を助けることを意図しているにすぎない。さらに、複数の実装及び出願の範囲に関しては、当業者は、本出願の概念にしたがって、複数の修正を行うことが可能である。したがって、本出願を限定するものとしてこの明細書の記載内容を解釈するべきではない。
【図１】
0006556346.tif 000002
【図２】
0006556346.tif 000003
【図３】
0006556346.tif 000004
【図４】
0006556346.tif 000005
【図５】
0006556346.tif 000006
【図６】
0006556346.tif 000007