JP2006005942A - インターネット・プロトコル電話の高速な障害検出および復旧 - Google Patents

Abstract

【課題】通信ネットワークの障害検出および復旧を高速に実施するための技術を開示する。
【解決手段】例えば、本発明の一態様において、通信ネットワークの１つまたは複数の状態を検出するための技術は、以下の工程／動作を含む。１つまたは複数のキープアライブ・パケットが、通信ネットワーク内のソース・ノードから通信ネットワーク内の宛先ノードに、ソース・ノードと宛先ノードの間の２つ以上の経路を介して送信される。この２つ以上の経路は、少なくとも一部が分離している。宛先ノードで、１つまたは複数のキープアライブ・パケットを２つ以上の経路を介して受信したとき、宛先ノードで、その２つ以上の各経路に対して少なくとも１つの品質尺度が計算される。この少なくとも１つの品質尺度は、通信ネットワークの１つまたは複数の状態を示す。本発明は、ＩＰ（インターネット・プロトコル）電話ネットワーク、具体的にはＶｏＩＰ（ボイス・オーバＩＰ）アプリケーションを提供するＩＰ電話ネットワークに特に適する。
【選択図】図１

Description

本発明は一般に、ＩＰ（インターネット・プロトコル）電話ベース・ネットワークなどの通信ネットワークに関し、より詳細には、そのようなネットワークにおける障害の検出および復旧を高速に実施するための技術に関する。

本出願は、２００４年６月１８日出願の米国特許仮出願第６０／５８１３２９号の優先権を主張するものであり、その開示を参照により本明細書に組み込む。

コストを抑え、新しいサービスを可能にするためにＩＰ電話への関心が高まっている。多くの企業やコール・センタが集中ＩＰインフラ上のＩＰ電話を採用し、多くのマルチサイト企業がイントラ通信またはサイト間通信にＶｏＩＰ（ボイス・オーバＩＰ）を使用している。

ミッションクリティカルなビジネス・アプリケーションにＶｏＩＰを使用するには、ＶｏＩＰ通話の信頼性および品質を評価し、高めることが重要である。理想的には、ＶｏＩＰ通話には、従来の回線交換方式の電話通話と同等の信頼性が必要である。しかし、ＶｏＩＰ通話（特に、広域リンク上のもの）の品質を監視し評価すると、従来の回線交換方式のネットワークでは生じない、ＩＰネットワークに関する固有のパケット損失、遅延、およびジッタを処理することが必要になる。ほとんどのＩＰネットワークは、ネットワーク障害に対しては自己復旧であり、多くの企業ネットワークは、サイト間に冗長リンクまたは経路を備えるように設計されている。しかし、今日のＩＰネットワークは、音声に必要とされる時間尺度での性能低下に対処するようには設計されていない。例えば、最近の研究によると、サービス・プロバイダー・ネットワークの中には許容できる性能のものも存在するが、多くのバックボーン経路では、相変わらずＶｏＩＰ性能が不十分であり、ネットワーク障害により問題が発生することが示されている。

ロバストなＶｏＩＰインフラストラクチャを提供するためには、性能低下や障害を高速に検出することが重要である。この検出は、いくつかの要因により複雑なものになっている。例えば、接続ベースでは、ＶｏＩＰ通話には、（例えば、通話の当事者が話さずに聞いているときなど、）パケットがソースから送信されない固有の無音期間が存在する。したがって、（例えば、受信側で）ＶｏＩＰ通話を監視するときには、自然な会話の沈黙、あるいは会話の圧縮などによって生ずるギャップと、ＩＰネットワークのパケット損失、遅延、およびジッタによって生ずるギャップとを区別する必要がある。また、問題を検出することによって、確かにネットワーク管理者に警告をだすことができるようにはなるが、ネットワークが、検出された問題に対処し、それを回避できればさらに有用であろう。
Ｍ．Ｋａｒｏｌ、Ｐ．Ｋｒｉｓｈｎａｎ、Ｊ．Ｊ．Ｌｉ、「ＶｏＩＰ Ｎｅｔｗｏｒｋ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｕｓｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ」、Ｐｒｏｃ．２００３ Ｉｎｔ．Ｃｏｎｆ．ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｓ、Ｏｃｔｏｂｅｒ ２００３

したがって、ＩＰ電話ネットワーク、詳細にはＶｏＩＰアプリケーションを提供するＩＰ電話ネットワークなどの通信ネットワークにおいて、障害の検出および復旧を高速に実施するための技術が必要とされている。

本発明は、通信ネットワークにおいて、障害の検出および復旧を高速に実施するための技術を提供する。これに限定されるものではないが、本発明は、ＩＰ電話ネットワーク、詳細にはＶｏＩＰアプリケーションを提供するＩＰ電話ネットワークに、特に適したものである。

例えば、本発明の一態様では、通信ネットワークの１つまたは複数の状態を検出する技術は、以下の工程／動作を含む。１つまたは複数のキープアライブ・パケットが、通信ネットワークのソース・ノードから通信ネットワークの宛先ノードに、ソース・ノードと宛先ノードの間の複数の経路を介して送信される。この場合、この複数の経路は、少なくとも一部が分離している。宛先ノードで、１つまたは複数のキープアライブ・パケットを２つ以上の経路を介して受信したとき、宛先ノードで、その２つ以上の各経路に対して少なくとも１つの品質尺度が計算される。この少なくとも１つの品質尺度は、通信ネットワークにおける１つまたは複数の状態を示すものである。

さらに、この品質尺度は、２つ以上の経路の各々について比較することができる。比較の結果は、宛先ノードからソース・ノードに送信することができる。受信した結果の少なくとも一部に基づいて、ソース・ノードから１つまたは複数の通信パケットを送信することができる。

したがって、一例として例示的実施形態に従えば、短い、低帯域幅のキープアライブ・パケットをＶｏＩＰパケット・ストリームに投入して、障害やネットワーク状態の低下（例えば、遅延、ジッタ、または損失の増加）を高速に検出することができる。キープアライブ・パケットは、複製することができ、それらを使用して主ネットワーク経路および代替ネットワーク経路の遅延および損失特性を継続的に監視し比較することができる。その結果、障害またはＱｏＳ状態の低下が検出されたときは、（進行中の、およびその後の）通話を代替ルーティング経路（または回線交換ＰＳＴＮ）に高速に切り換える制御を支援することができる。キープアライブ・パケットの複製を複数の経路を介して同時に送信して遅延差を測定し比較することによって、この技術は、多くの共通の同期およびタイミングの誤差を回避する。

本発明の、これらおよび他の目的、特徴、利点は、本発明の例示的実施形態についての以下の詳細な説明を、添付の図面と併せて読むことによって明らかになるはずである。

本発明は、ＶｏＩＰ機能を備えたＩＰ電話ベース・ネットワークの文脈のもとに説明するが、本発明がそれに限定されるものではないことを理解されたい。すなわち、本発明は、より一般的に、通信ネットワークの１つまたは複数の状態を検出することが望まれる、任意の通信ネットワークに適用可能である。

本発明の技術の実装についての例示的な詳細を、ＶｏＩＰ機能を備えたＩＰ電話ベース・ネットワークの文脈で説明する前に、より一般的な通信ネットワークの見地から本発明の原理を説明する。

通信ノードからなるネットワークを想定する。このネットワークは、ＶｏＩＰ機能を備えたＩＰ電話ベースのネットワークであってもよい。ただし、このネットワークには、特別な場合のシグナリング・ネットワークを含めることもできる。さらに、ソース通信ノードから宛先通信ノード（どの通信ノードも、様々な通信セッションにおいてソースおよび宛先のどちらにもなり得る）に通信パケットを経路制御するための、基礎となる経路制御アルゴリズムが存在するものと想定する。例えば、通信パケットは、ＶｏＩＰパケットであってもよい。また、通信パケットは、シグナリング・パケットであってもよい。シグナリング・パケットの例には、エラー・メッセージ、通話要求、割り込み要求などがある。

本発明の原理によれば、通信ノードのいくつかは、ペースメーカ／測定／経路制御（ＰＭＲ）ノードとしての機能を果たすように設置される。このことについては、以下で詳細に説明する。このＰＭＲ機能は、例えば、ゲートウェイ中に実装することができる。また、スタンドアローンのＰＭＲノードを備えることもできる。

さらに、本発明の原理によれば、ソースＰＭＲノードはキープアライブＰＭＲパケットを、少なくとも１つのノードまたはリンクが異なる２つ以上の経路（すなわち、少なくとも一部が分離した２つ以上の経路）に沿って宛先ＰＭＲノード宛てに投入（ｉｎｊｅｃｔ）または送信することができる。キープアライブ・パケットは、追加の短いパケットであり、ソース・ノードと宛先ノードの間の通信を「生かしておく（ｋｅｅｐ ａｌｉｖｅ）」（すなわち、長いアイドル・ギャップをなくす）ために定期的に送信される。キープアライブＰＭＲパケットは、ネットワーク内部で、ネットワークで配送される通信パケットと同じ種類のサービス品質（ＱｏＳ）を受ける。キープアライブＰＭＲパケットは、２つ以上の経路に沿って同時に投入することができる。キープアライブＰＭＲパケットは、例えば、常時（すなわち、ソースＰＭＲノードと宛先ＰＭＲノードの間の通話の有無に関係なく）、通話時に継続的に、通話中の無音期間の間だけ、または通話間のアイドル期間の間だけ、定期的に（一定時間間隔で）送信することができる。キープアライブＰＭＲパケットが送信される割合は、ソースＰＭＲノードと宛先ＰＭＲノードの様々なペアごとに異なっていてもよい。２つ以上の経路に沿った送信には、１つまたは複数の中間ＰＭＲノード（すなわち、ソースＰＭＲノードと宛先ＰＭＲノードの間にあるＰＭＲノード）を通過するトンネリングを用いることもできる。複数の経路に沿った送信は、（パケットの経路制御に作用する）ヘッダ・アドレス・ビットを適切に設定することによって実施することができる。複数の経路に沿った送信は、一連のオーバレイＰＭＲノードを経由することができる。

また、本発明の原理によると、２つ以上の経路のＱｏＳ尺度（例えば、遅延、ジッタ、損失など）を、宛先ＰＭＲノードで比較することができる。ＱｏＳ比較は、相対的な受信時間によって行うことができる。したがって、ソースＰＭＲノードと宛先ＰＭＲノードの時計を同期させる必要がなくなる。ＱｏＳ比較では、関連する通信パケットの種類に適した、様々な、遅延、ジッタ、および損失についての尺度が考慮される（例えば、ＶｏＩＰパケットについては遅延およびジッタを重視し、シグナリング・パケットについては損失を重視することができる）。

また、本発明の原理によれば、宛先ＰＭＲノードにおけるＱｏＳ比較の情報をソースＰＭＲノードに送り返し、それを使用して、その後のソース通信ノードから宛先通信ノードへの通信パケットの経路に影響を及ぼすことができる。通信パケットの経路は、その後の通話に対する設定で変更することができる。さらに、必要ならば、継続中の既存のセッションの通信パケットに対しても変更することができる。経路は、１つまたは複数の中間ＰＭＲノードを通過するトンネリングによって、あるいはオーバレイＰＭＲネットワークによって、あるいはルーティング・アルゴリズムの基になるルーティング・テーブルを変更することによって変更することができる。信頼性を上げるために、ＱｏＳ比較情報は、宛先ＰＭＲノードからソースＰＭＲノードまで複数の経路を介して送り返すこともできる。

次に、上記の本発明の原理についての例示的なＶｏＩＰ実装について考える。
Ｉ．はじめに
本発明の原理は、短い、低帯域幅のキープアライブ・パケットを使用するための技術を提供する。キープアライブ・パケットは、ＶｏＩＰパケット・ストリームに投入することによって、障害、あるいは悪化するネットワークの状態、例えば、遅延、ジッタ、損失の増大などを高速に検出することができる。「短い」という用語、および「低帯域幅」という用語は、個々のネットワーク・アプリケーションに依存するものであるが、本発明は、特定のパケット長、または帯域幅値に限定されるものではない。短い、低帯域幅のキープアライブ・パケットの一例には、３２ビットのＳＤＥＳ ＲＴＣＰ（Ｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）パケットがあり、このパケットのオーバヘッドは０．２パーセント未満である。

キープアライブ・パケットがどのように複製できるか、また、主および代替ネットワーク経路の遅延および損失特性を継続して監視し比較するために、そのパケットがどのように使用できるかについて説明する。また、その結果、障害またはＱｏＳ状態の悪化が検出されたとき、通話を代替ルーティング経路に高速に切り換える制御をどのように支援するかについて説明する。詳細には、通話をより良好な（より少ない遅延、損失、またはジッタ特性を有する）代替経路に高速に切り換え／送信することによって、本発明の技術は、（ｉ）進行中の通話のＱｏＳを改善すること、（ｉｉ）進行中の通話の経路を、検出された障害を避けて迂回すること、および（ｉｉｉ）その後の通話の経路を、障害を避けて迂回することを支援することができる。この技術を使用して、所望のときまたは必要なときに、ＩＰネットワークの検出された状態に基づいて通話を従来の回線交換方式ＰＳＴＮに切り換えることもできる。

ＶｏＩＰトラフィックをネットワークに追加する前に、先ず、所望のＱｏＳが（予想されるトラフィック・ミックスに対して）実際に達成可能かどうかを判断する必要がある。例えば、最初のネットワーク評価によって、ネットワークが適切に構成できるかどうかを判断することができる。この例示的実装においては、ネットワークの帯域幅、構成、および設定は、予想されるトラフィックに対する所望のＱｏＳを提供するために、実際に十分かつ適正なものであると想定する。次に、本発明の技術は、低帯域幅のキープアライブ・パケットを使用して、進行中の接続を監視し制御するために使用される。キープアライブ・パケットは、主ネットワーク経路、および比較のために代替ネットワーク経路を介して送信される。このパケットは、基本的に、障害および（たとえ一時的であるとしても）予期しないトラフィック状態によって引き起こされる、基準からの偏差を監視し検出する。本発明の技術は、ネットワークの諸問題を検出するだけでなく、（例えば、混雑や障害を迂回するなど）適切な制御応答の決定を支援する。

セクションＩＩでは、本発明の検出、監視、および制御の技術を例示として説明する。セクションＩＩＩでは、いくつかの一般概念、ならびに構造上および実装上の問題を例示として提示する。セクションＩＶでは、数学的により詳細に説明し、いくつかの解析結果を提示して、本発明の概念の正当性を立証する。セクションＶでは、例示的なハードウェア実装を提供する。セクションＶＩでは、例示の要約を提示し、いくつかの拡張について論ずる。

ＩＩ．制御のための検出および監視
このセクションでは、ネットワーク障害およびＱｏＳ問題を検出するための低帯域幅技術を導入する。本発明によって提供されるアーキテクチャ／技術上の１つの主要な概念は、制御のための検出および監視という概念である。これに対して、いくつかのネットワーク監視技術においては、ネットワークの状態および問題は検出するが、その障害に対する適切な制御応答については、ほとんど、あるいはまったく指針を与えない。低帯域幅高速検出方法を提示した後で、ネットワーク状態の悪化および障害に対する高速制御応答の方法について説明する。次に、本発明の制御方法は、ＶｏＩＰのための経路ＱｏＳ監視における多くの共通の問題を回避する監視方法を提供する。

Ａ．低帯域幅検出
受信装置でネットワーク障害およびＱｏＳの低下を高速に検出するために、本発明は、送信装置によって、ＶｏＩＰストリームとともに低帯域幅のキープアライブ信号を送信することを提案する。例えば、ＶｏＩＰ（例えば、ＲＴＰすなわちＲｅａｌ−ｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）パケットとともに、短いキープアライブ・パケットを定期的に、「一定の」時間間隔（例えば、５００ミリ秒）で送信することができる。ネットワークの障害だけを検出するためには、これらのパケットは、ＶｏＩＰ通話の無音期間中だけに送信する必要がある。他の時間には、ＲＴＰパケットそれ自体を障害検出の目的で使用することができる。送信装置は、ＲＴＰパケットの数が減少したとき（無音期間中）には、キープアライブ・パケットの数を増加させて、各Ｔ秒ごとに、ＲＴＰパッケットまたはキープアライブ・パケットの少なくとも一方が確実に送信されるようにする。具体的には、ＲＴＰストリームの無音期間中は、追加の（短い）キープアライブ・パケットが、Ｒ＝１／Ｔの割合で投入される。

受信装置では、ｋＴ秒（ｋ＝２，３，・・・）の時間枠内に、ＲＴＰパケットもキープアライブ・パケットも受信されなかった場合に障害が宣言される。次に、受信装置は、セッションに参加している各ユーザに通知する。さらに、恐らくは、新しい通話を開始しようと試みた場合に影響を受けることになる、他のユーザにも通知する。ＲＴＰパケットおよびキープアライブ・パケットは、ネットワークのジッタおよび損失の影響を受けるので、障害が誤って宣言される（すなわち、「誤報」の）可能性がある。ただし、受信装置は、ＲＴＰまたはキープアライブ・パケットが再度受信されると直ぐに、その「障害通知」を取り消す。この機能は、（ｉ）誤報を訂正する、あるいは（ｉｉ）実際の障害の後で復旧を通知するように働く。言い換えると、（ｉ）は、次の有効なＲＴＰまたはキープアライブ・パケットが受信されると、直ちに誤報が自動的に自己訂正されることを意味する。

多くの個別の実装についての問題が、Ｍ．Ｋａｒｏｌ、Ｐ．Ｋｒｉｓｈｎａｎ、Ｊ．Ｊ．Ｌｉ、「ＶｏＩＰ Ｎｅｔｗｏｒｋ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｕｓｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ」、Ｐｒｏｃ．２００３ Ｉｎｔ．Ｃｏｎｆ．ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｓ、Ｏｃｔｏｂｅｒ ２００３で取り扱われており、その開示を参照により本明細書に組み込む。詳細には、キープアライブ・パケットとしてＳＤＥＳ ＲＴＣＰパケットが使用された場合に、その実装によるオーバヘッドが０．２％未満になることが示されている。（例えば、ベンダー固有のゲートウェイ装置間では）専用のキープアライブ信号の使用など、他の選択肢も存在する。実際の実装では、キープアライブ・パケットは、端末（例えば、ＩＰソフト電話）によって、あるいは（ＶｏＩＰ通話収集のための）ＶｏＩＰゲートウェイによって投入できるはずである。しかし、これらの技術の実装においては、ＩＰネットワークが、キープアライブ・パケットをＶｏＩＰ（例えば、ＲＴＰ）パケットとまったく同一に処理すること、すなわち、同一のルーティング経路、優先度などを使用すること、また、その結果、キープアライブ・パケットによる損失や遅延が、ＶｏＩＰ通話による損失や遅延を正確に反映することを確認する必要がある。例えば、ＲＴＰまたはＲＴＣＰパケットをキープアライブ・パケットとして使用することができる。

Ｂ．ＱｏＳ監視への拡張
次に、低帯域幅ＱｏＳ監視技術を説明する。ＲＴＰ無音期間に、キープアライブ・パケットがＲ＝１／Ｔの固定割合で投入されることについては、先に述べた。ＲＴＰの有音期間にＱｏＳを監視する（また、それに高速で応答する）ためには、２つの選択肢がある。先ず、低帯域幅のキープアライブ・パケットは、少し余分の帯域幅を犠牲にすることにより、有音期間中にも挿入することができる。すなわち、キープアライブ・パケットは、常時Ｒ＝１／Ｔの割合で挿入することができる。次に、ＲＴＰパケットが非常に高い精度で（例えば、２０ｍｓごとに）挿入されることが分かっている場合には、ＲＴＰパケットそのものを監視用に使用することができる。どちらの場合でも、受信装置は、送信装置がＲＴＰ無音期間およびＲＴＰ有音期間の両方の期間に、名目上固定の時間間隔でいくつかのパケットを投入するという事実を利用するように設計される。

音声ＱｏＳ（例えば、ＭＯＳスコア／Ｒ値）は、パケット損失、ジッタ、および一方向遅延によって決まる。ＭＯＳは、「平均オピニオン・スコア（Ｍｅａｎ Ｏｐｉｎｉｏｎ Ｓｃｏｒｅ）」を意味する。これは、ＶｏＩＰの品質を評価するために使用される、従来からある尺度の１つである。これは、人間ユーザによって主観的に認識される、音声会話の相対的品質を評価する尺度である。Ｒ値は、一般に使用される第２の尺度である。

パケット損失確率は、失われたまたはドロップした、キープアライブ・パケットおよびＲＴＰパケットの数を、受信装置側で単純に数えることによって評価される。しかし、一方向遅延およびジッタについては、測定がより困難である。キープアライブ（およびＲＴＰ）パケットが、各経路において、一定の時間間隔で（しかも、高優先度で）送信される場合は、受信側での連続するパケットの間隔が各経路のジッタの近似的な尺度になる。遅延を監視するために、送信時にグローバルな「タイムスタンプ」をパケットに追加し、それを受信時にクロックと比較することができる。しかし、これには、送信ノードと受信ノードの正確な時間調節および同期を必要とする。別法として、送信ノードと受信ノード間に存在する複数の経路を使用する場合は、遅延の評価はずっと簡単になる。このことについては、以下のセクションＣ説明する。

Ｃ．制御のための監視
本発明の技術の焦点は、代替ネットワーク経路（またはＰＳＴＮ）への高速切り換え、およびそれに関連する性能の問題にあてる。本発明の制御方法および解析についての議論を始めるために、図１に示したように、例示的ネットワーク１００の一部に２つのサイト、すなわち送信サイト１０２および受信サイト１０４があると想定する。逆方向の通信では、「送信サイト」が「受信サイト」にもなり、別のトラフィックでは、「受信サイト」が「送信サイト」にもなり得ることを理解されたい。

企業サイトが、複数のサービス・プロバイダ（ＳＰ）に接続されるか、または複数のＷＡＮ（広域ネットワーク）リンク（すなわち、マルチホーム・アーキテクチャ）を有しており、かつその企業が、恐らくはサービス内容合意書（ＳＬＡ）による、いくつかの限定された情報を除けば、ＳＰ／ＷＡＮの経路／性能に関する、いかなる制御も情報も有していないと想定する。

また、送信側および受信側の各々に、受信されたＶｏＩＰストリームの品質を監視する特別な（ハードウェア／ソフトウェア）デバイス１０６が存在し、しかも、それらの間で情報を交換することができるものと想定する。これらの特別なデバイスをＰＭＲデバイスと呼ぶ。その理由は、これらのデバイスが以下の動作、すなわち、（ｉ）（ペースメーカ（Ｐａｃｅｍａｋｅｒ）と同様に）キープアライブ・メッセージを送信すること、（ｉｉ）そのメッセージに基づき、ＱｏＳを監視／評価（Ｍｏｎｉｔｏｒ／Ｍｅａｓｕｒｅ）すること、および（ｉｉｉ）相互にＶｏＩＰパケットを中継／経路制御（Ｒｅｌａｙ／Ｒｏｕｔｅ）すること、の３つの動作を実施するからである。ＰＭＲデバイス１０６は、ネットワークのメディア・ゲートウェイの中、ルータの中、またはそれらと並列に設置することができる。あるいは、シグナリング・サーバが、リモートのＰＭＲデバイスとの間のすべてのトラフィックを指示することもできる。

次に、キープアライブ・パケット（例えば、ＲＴＣＰ）が、送信側のＰＭＲデバイス１０６で複製され、複数のＳＰ／ＷＡＮ経路（例えば、デュアルホーム・アーキテクチャの２つの経路であるＳＰ／ＷＡＮ １ １０８−１、およびＳＰ／ＷＡＮ ２ １０８−２）を介して同時に送信されるものと想定する。各複製パケットには、それらが送信されてきたＳＰ／ＷＡＮ経路を示す識別子が付いている。ＳＰ／ＷＡＮリンクを横断した後で、複製キープアライブ・パケット１１０は、例えば、リモート終端のエッジ・ルータ／ＰＭＲデバイスに到達する。次に、受信した複数の複数の複製の、遅延、ジッタ、および損失の様々な比較が行われる。この情報を使用して、ＳＰ／ＷＡＮとの間の「最良の」入口／出口ポイントを識別し、ＶｏＩＰパケットを現在の「最良の」経路に切り換えることを支援することができる。

ここで重要な点は、高速切り換えを制御するためのＱｏＳ比較に主要な関心があるので、判断する必要があるのは、例えば、主経路と代替経路の間の遅延差およびジッタ差である。この方法によれば、同期やタイミングのエラーを回避することができる。その理由は、この方法では、キープアライブ・パケットの複製を、複数の経路を介して同時に送信して、遅延差を計測し比較するからである。

具体的には、キープアライブの複製が到着する順番は、相対的な遅延の大きさを示している。受信装置における、連続するパケット間の間隔は、各経路のジッタの近似的な大きさを示すものであり、その間隔を使用して、２つの経路間のジッタ差を決定することができる。これらの測定結果は、例えば、数秒間にわたって平均化され、様々な経路の現在のＱｏＳ特性の比較に使用することができる。受信デバイスは、（安全のために、複数の経路に沿うように複製された）フィードバック・メッセージを送信して、送信装置にどの経路を使用すべきかを知らせる。次に、ジッタ、遅延、および損失によって音声品質が許容レベル以下に低下した場合は、例えば、通話は、（より良い）ＩＰ経路（または、回線交換ＰＳＴＮ）に切り換えられる。結果として、自動的に絶えず最良の（最小遅延の）サービス・プロバイダを利用する、簡単な「高性能ルータ」のように動作できるシステムが得られる。

したがって、既存の方法とは異なり、本発明の方法は、ＱｏＳ比較のために複製される制御／測定用のパケットを提供して、ＶｏＩＰパケットがとる経路を決定し、高速に切り換える。

Ｄ．ＱｏＳ比較の改善
次に、ＱｏＳ比較の実施に関する問題をより詳細に述べる。例えば、ジッタに関しては、パケット相互の間隔は、経路ジッタを与える妥当なアイデアであるが、実際には、キープアライブ・パケットやＲＴＰパケットの投入時間には、僅かなばらつきが存在する。しかし、このソース・ジッタが、ここでの関心事であるネットワーク・ジッタの量よりも少ない場合は、上記のジッタ測定で十分なはずである。より重要なことは、本発明の技術が、（以下でさらに説明するように）ジッタおよび遅延の測定を処理するための他の方法を含んでいることである。

先ず、先に述べたように、本発明では主に複数の経路間のＱｏＳ比較を扱う。本発明の遅延差測定においては、キープアライブ・パケットの複数の複製が同時に送信されるので、ソース・ジッタ成分は自動的に除去される。次に、（例えば、通話を回線交換ＰＳＴＮに切り換えるべきかどうかを調べるために）経路上の絶対ジッタ量を測定する必要があるとする。このとき、本発明によれば、ソース・ジッタの多くの影響を打ち消すことができる。具体的には、送信装置は単に、（ある一定の時間にわたってパケットを投入するときに）ソース・ジッタ量を測定し、一定時間ごとに受信装置に知らせる必要があるだけである。次いで、受信装置は、測定された（全体の）ジッタからこの成分を減算して、ネットワーク・ジッタの推定値を算出する。

同様に、キープアライブ・パケットが名目上、複数の経路を介して一定の間隔で同時に投入されるという知識を使用して、（例えば、クロックのドリフトに起因する）タイミング・エラーを除去することもできる。

最後に、必要ならば本発明の技術は、（例えば、最初のネットワーク評価の間に実施された）一方向絶対遅延を不定期の測定で補完することができる。最初の許容できる状態の知識から始めて、本発明の技術を使用して、偏差を測定することができる。次にこの情報は、例えば、シグナリング・サーバに伝えられる。一定の遅延／ジッタ／損失の閾値を越え、しかも送信装置と受信装置の間にただ１つの経路しかない場合は、通話は、例えば、ＰＳＴＮに切り換えることができ、かつ／または影響を受ける一組の端末に問題が存在することを通知することができる。常に正確な性能測定を実施する必要があるわけではないことに留意されたい。単に、偏差を監視するだけで十分なのである。

ＩＩＩ．アーキテクチャおよび実装上の問題
このセクションでは、図１の基本モデルを拡張して、マルチサイト企業をどのようにモデル化できるか、またそれらの企業がどのように本発明の技術を使用できるかを示す。

典型的な企業ネットワークは、専用のＷＡＮラインまたはトンネルを介して接続された、地理的に分散した複数のサイトを有する。各サイトはグラフＧのノードと考えることができ、２つのノードを接続するＷＡＮリンクはＧのエッジになる。グラフＧは、２つのノード間に複数のエッジを有する多重グラフであってもよい。このグラフにおいて、例えば、図２のグラフ／ネットワーク２００に示されるように、ノード２０２間には、経路の冗長性のための、１つまたは複数のリンク２０４から構成された複数の経路があり、保護用に使用されている。上記のグラフは、ＶｏＩＰのオーバレイ・ネットワークを形成する。このグラフの各ノードには、本発明の原理に従って、１つまたは複数のＰＭＲデバイスが機能として組み込まれている。結果として得られた（組み込まれたＰＭＲを含む）グラフ／ネットワークを、オーバレイＶｏＩＰ ＰＭＲグラフ／ネットワークと呼ぶ。このようなグラフ／ネットワーク３００が、図３に示されている。この図では、ＰＭＲデバイスは参照番号３０２で示され、エッジは参照番号３０４で示されている。

ＶｏＩＰ品質の問題は、ノードの内部でも（サイト内部の問題に起因して）起こり得るが、より一般的にはＧのエッジに存在する問題に起因する（すなわち、ＷＡＮリンクの問題に起因する）。各ＰＭＲは、オーバレイＶｏＩＰ ＰＭＲネットワークを識別し、キープアライブ信号を複数の経路に沿って送信する。ＶｏＩＰによって設けられる自然の制約（例えば、制限された遅延、ジッタなど）により、調査のために考慮すべき可能な経路が指示され制限されることになる。このような経路は一般に、例えば、ＶｏＩＰ配備の評価段階で見つかるはずである。各ＰＭＲは、オーバレイ・ネットワークの技術、および／またはトンネリング／アドレス書き換えの技術を使用して、パケットを「最良の」ＶｏＩＰ経路に沿って迂回させることができる。

オーバレイＶｏＩＰ ＰＭＲグラフについては、興味深いルーティングの問題が存在するが、本明細書の焦点が、オーバレイ・ネットワークおよびオーバレイ・ネットワークの構築にはないことに留意されたい。ここで注目すべきことは、ＶｏＩＰ接続の健全性を評価するために低帯域幅技術を使用すること、経路の選択のために「制御のための検出」パケットを選択的に複製する方法を使用すること、および判断を実行するために限定されたバージョンのオーバレイ・ネットワーク技術を使用することである。

ＩＶ．誤報確率および遅延低減
このセクションでは、ある程度数学的な詳細に立ち入り、本発明のシステムのいくつかの態様を検討する。先ず、（誤報と呼ばれている）障害が誤って宣言される確率を計算する。この解析では、ＶｏＩＰ有音無音モデルのいくつかの態様を採用して、Ｍ．Ｋａｒｏｌ、Ｐ．Ｋｒｉｓｈｎａｎ、Ｊ．Ｊ．Ｌｉ、「ＶｏＩＰ Ｎｅｔｗｏｒｋ Ｆａｉｌｕｒｅ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｕｓｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎ」、Ｐｒｏｃ．２００３ Ｉｎｔ．Ｃｏｎｆ．ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｎｅｔｗｏｒｋｓ、Ｏｃｔｏｂｅｒ ２００３の場合より厳しい上限を生成する。この論文の開示を、参照により本明細書に組み込む。解析結果は、プロトタイプ実装における検出時間および誤報率の実測結果とよく一致する。ここでは、有音無音モデルのパラメータが、誤報確率にどのように影響を与えるかを示し、誤報確率、障害検出時間（ｋＴ）、およびキープアライブ・パケットが投入される割合（Ｒ＝１／Ｔ）の間のいくつかのトレードオフについて論ずる。最後に、複製されたキープアライブ・パケットを使用して達成できる低減された遅延を評価して、代替の低遅延経路への高速切り換えを制御する。

誤報は、エンドツーエンド接続がまだ動作中であるにもかかわらず、ＲＴＰパケットおよびキープアライブ・パケットが、（パケット損失またはジッタのために）時間ｋＴの間まったく受信されなかった場合に発生する。一般に、ＲＴＰパケットは、（有音中は）キープアライブ・パケット（例えば、Ｔ＝５００ｍｓごとに１回）よりはるかに速いレート（例えば、２０ｍｓごとに１回）で送信されるので、（典型的なパケット損失確率としては）ＲＴＰ有音中には誤報は発生しないと想定しても問題ない。例えば、長さ２秒（例えば、ｋ＝４、およびＴ＝５００ｍｓ）の有音期間中に、すべてのＲＴＰパケットが損失されたか、または遅延した場合は、障害は（ほとんど）確実に発生する（発生しない場合は、ネットワークのパケット損失レートが高すぎて、正常な状態であっても許容できるＶｏＩＰ ＱｏＳを提供できないことになる）。したがって、誤報確率の計算においては、キープアライブ・パケットの損失だけに注目する。また、キープアライブ・パケットへのジッタの影響も無視する。その理由は、各キープアライブ・パケット間の間隔Ｔは、（許容できるＶｏＩＰ ＱｏＳを提供できるほど十分に小さいことが必要な）ネットワーク・ジッタより十分に大きいからである。

ｆ_ｎは、ｎ個のキープアライブ・パケット送信の間に、ｋ個（または、それ以上の）連続するパケットがドロップする確率を示す（この場合、ＲＴＰストリーム中の単一の無音期間中にｋ個のパケットが送信された場合には、誤報が引き起こされる）。連続するキープアライブ・パケットの間隔が相対的に大きいので、各パケットは確率ｐで独立にドロップするものと想定する。したがって、ｆ_ｎは次の再帰的定義で与えられる。
ｆ_ｎ＝ｆ_ｎ−１＋（１−ｆ_{ｎ−ｋ−１}）（１−ｐ）ｐ^ｋ， ｎ＞ｋ （１）
また、初期条件としてｆ_ｋ＝ｐ^ｋであり、ｎ＜ｋの場合はｆ_ｎ＝０である。ｆ_{ｎ−ｋ−１}≧０なので、次式が得られる。
ｆ_ｎ＜ｆ_ｎ-１＋（１−ｐ）ｐ^ｋ， ｎ＞ｋ （２）
式（２）をｆ_ｎについて解くと、次式が得られる。
ｆ_ｎ＜ｐ^ｋ［（ｎ−ｋ＋１）−（ｎ−ｋ）ｐ］， ｎ＞ｋ （３）

したがって、ｆ_ｎについての上限が得られたことになる。このｆ_ｎを使用して継続時間Ｌの通話の間の誤報確率の上限が計算できる。各有音期間中に、少なくとも１つのＲＴＰパケットがうまく送信されると想定したので、異なるＲＴＰ無音期間の間に損失が発生した場合は、ｋ個の連続するキープアライブ・パケットの損失によって誤報が引き起こされることはないはずである。したがって、全体の誤報確率を計算するために、先ず、ｋＴより長い継続期間の各ＲＴＰ無音期間に対する誤報確率をそれぞれ独立に計算する（すなわち、特定の長さの無音期間の間に、ｋ個以上の連続するキープアライブ・パケットがドロップする確率を計算する）。次いで、全通話期間にわたり、様々な無音期間の長さに従って平均化することによって、全体の誤報確率を求める。

全体の誤報確率を計算する前に、先ず、誤報確率が、ＲＴＰの有音および無音期間の固有の確率分布に大きく依存することに留意されたい。例えば、すべてのＲＴＰ無音期間の継続期間がｋＴ未満である場合は、（このセクションの想定の下では）誤報は発生しない。その理由は、ｎがｋ未満の場合は常に、ｆ_ｎ ＝ ０であり、その上限は、（すべての無音期間ｎがｋ未満のときは）誤報確率が０であることを正しく示している。同様に、有音期間の長さも（具体的には、継続時間Ｌの通話内で発生する無音期間の数に影響を与えることにより）全体の誤報確率に影響を与える。

無音期間がｎＴと（ｎ＋１）Ｔの間の継続時間を有する（すなわち、その無音期間の間にｎ個のキープアライブ・パケットが送信される）確率を、ｄ_ｎによって示す。確率ｄ_ｎは、例えば、所与のオンオフＶｏＩＰ有音無音モデルから直接計算することができる。したがって、誤報が（ランダムな）無音期間の間に発生する確率ｈは次式で与えられる。

最後に、ｍ個の（統計的に独立な）無音期間を有する通話の、全体の誤報確率ｇ_ｍは次式で与えられる
ｇ_ｍ＝１−（１−ｈ）^ｍ， （５）
（３）式より、［（ｎ−ｋ＋１）−（ｎ−ｋ）ｐ］＜ｎとなるので、ｆ_ｎ＜ｎｐ^ｋであることが分かる。したがって、（４）式から次式が得られる。

上式で、ＹはＲＴＰ無音期間の期待長さ、「Ｙ｜Ｔ」はＹ／Ｔに等しいか、それ未満の最大整数である。「Ｙ｜Ｔ」が、長さＹの無音期間の間に送信されたキープアライブ・パケットの数であることに留意されたい。したがって、（５）式および（６）式から次式が得られる。
ｇ_ｍ＜１−｛１−ｐ^ｋ＊「Ｙ｜Ｔ」｝^ｍ， （７）

継続時間Ｌの通話の間にｍ個の無音期間がある確率は、個別のＶｏＩＰ有音無音モデルから求めることができる。しかし、ここでは、例示（および簡単化）のために、無音期間の数ｍがその期待値Ｌ／（Ｙ＋Ｘ）に等しいときの誤報確率ｇだけを計算する。ただし、ＸはＲＴＰ有音期間の期待長さを表す。（７）式で、ｍ＝Ｌ／（Ｙ＋Ｘ）と設定すると、次式が得られる。
ｇ＜１−｛１−ｐ^ｋ＊「Ｙ｜Ｔ」｝^{Ｌ／（Ｙ＋Ｘ）}， （８）
（８）式を使用すると、誤報確率ｇ、障害検出時間（ｋＴ）、およびキープアライブ・パケットのために必要な（割合Ｒ＝１／Ｔに比例する）余分の帯域幅の間の、多くのトレードオフを調べることができる。個々の比較は、通話の長さＬ、パケット損失率ｐ、およびＲＴＰ有音および無音期間の期待長さに依存する。例示のために、Ｙ＝Ｘ＝１０秒（すなわち、同じ有音および無音継続時間を有する対称的な通話）とする。表１および表２は、１０分の通話、５％のパケット損失率（ｐ＝０．０５）、ならびに障害検出時間（ｋＴ）をそれぞれ１秒および５００ミリ秒とした場合の、いくつかの代表的な結果を示す。誤報確率ｇがｋの増加とともに急速に低下することに留意されたい。一方、余分の「キープアライブ帯域幅」は、（検出時間が一定ならば、）ｋの増加とともにリニアに増加する。

表１−５％パケット損失率（ｐ＝０．０５）、障害検出時間（ｋＴ）１秒として１０分間通話した場合の誤報確率の上限

表２−５％パケット損失率（ｐ＝０．０５）、障害検出時間（ｋＴ）５００ミリ秒として１０分間通話した場合の誤報確率の上限

最後に、複製されたキープアライブ・パケットを使用して代替経路のＱｏＳを比較することに関する、いくつかの性能面について解析して、ＶｏＩＰ通話の最適経路への高速切り換えの制御を支援する。個別の性能向上については、代替のより良い経路が発見される割合と切り換え速度に依存する。どのような種類の性能向上が可能であるかを知るために、ここでは「即時」検出および切り換えという、極端な場合（すなわち、各パケットが、現状の最良かつ最小遅延の経路に沿って送信される場合）を考える。このようなシステムは、より広い帯域幅を犠牲にしてＶｏＩＰパケットそのものを複製することによって近似できる。その結果、各パケットの一方の複製が常に現在の最良の経路をとることになる。

あるパケットが経路ｉを横断したときの遅延をＸ_ｉで表す。したがって、理想は、あらゆるパケットが現在の最小遅延の経路に沿って経路制御され、結果として、パケット遅延Ｘが遅延Ｘ_ｉの最小値に等しくなることである。すなわち、デュアルホーム構成では、Ｘ＝ｍｉｎ｛Ｘ_１，Ｘ_２｝となることである。様々な遅延モデル（または、実際のネットワーク遅延測定）のために、（解析的に、または数値的に）Ｘの分布を決定することができる。実際のネットワーク・モデルおよびトラフィック・モデルは、解析的には非常に複雑なものであるが、簡単な遅延モデルによって、有益な見通しを提供し、いくつかの重要な性能特性およびトレードオフを明らかにする。

例示のために、デュアルホーム・アーキテクチャを考える。この場合、各経路の遅延は、単純なＭ／Ｍ／１待ち行列の待ち時間としてモデル化される。実ネットワーク（の待ち行列）は、単純なＭ／Ｍ／１モデルよりはるかに複雑である。しかし、結論は定性的には同一になる。経路ｉに対して、１／λ_ｉは平均到達間隔、１／μ_ｉは平均サービス時間とし、全経路負荷をρ_ｉ＝λ_ｉ／μ_ｉとする。このとき、Ｐｒｏｂ｛Ｘ_ｉ≦ｔ｝＝１−ρ_ｉ＊ｅ^−μ _ｉ ^（１−ρ _ｉ ^）ｔ，ただしｔ＞０であり、Ｐｒｏｂ｛Ｘ_ｉ＝０｝＝１−ρ_ｉである。

次に、ｑ_ｉが経路ｉ上のパケット損失確率を示すものとする。また、２つの遅延分布は、（恐らくは、２つの経路が異なるサービス・プロバイダのネットワークであるために）統計的に独立であると想定する。このとき、次式が得られる。
Ｐｒｏｂ｛Ｘ≦ｔ｝＝１−Ｐｒｏｂ｛Ｘ_１＞ｔ｝＊Ｐｒｏｂ｛Ｘ_２＞ｔ｝＝１−｛（１−ｑ_１）（１−ｑ_２）ρ_１ρ_２＊ｅ^−μ _１ ^（１−ρ _１ ^）ｔｅ^−μ _２ ^（１−ρ _２ ^）ｔ｝−｛（１−ｑ_１）ｑ_２ρ_１＊ｅ^−μ _１ ^（１−ρ _１ ^）ｔ｝−｛ｑ_１（１−ｑ_２）ρ_２＊ｅ^−μ _２ ^（１−ρ _２ ^）ｔ｝−ｑ_１ｑ_２，（ただし、ｔ＞０） （９）
また、
Ｐｒｏｂ｛Ｘ＝０｝＝１−（１−ｑ_１）（１−ｑ_２）ρ_１ρ_２−（１−ｑ_１）ｑ_２ρ_１−ｑ_１（１−ｑ_２）ρ_２−ｑ_１ｑ_２， （１０）

表３−パケットの９９％は、（平均パケット長に正規化された）表の値以下の遅延を有する。ただし、経路１は１０％パケット損失、経路２は０％パケット損失とする。

式（９）および（１０）を使用して、表３は、１０％のパケット損失率（すなわち、ｑ_１＝０．１）を有する経路１が、損失の無い経路２（すなわち、ｑ_２＝０）と組み合わされたときの、いくつかの代表的な遅延のトレードオフを示す。表３は、様々な負荷（ρ_１およびρ_２）に対する遅延Ｘの９９百分位数（すなわち、パケットの９９％が表３に示された値より小さい遅延になる数）を一覧表にしたものである。表３の最後の行は、比較のために、経路１への切り換えがまったくない場合の、経路２の遅延（Ｘ_２）の９９百分位数を一覧にしたものである。この比較により、高速のＱｏＳ検出および代替経路への切り換えによって可能になる、遅延の低減が示される。例えば、経路２の総負荷が４０％の場合、高速切り換えなしならば、遅延の９９百分位数は６．２（パケット長）であり、高速切り換えを用いると、９９百分位数は（表３で）２．５から５．４の範囲の値にまで低減される。遅延低減量が代替経路１の総負荷（および対応する遅延）に依存していることは明らかである。すなわち、経路１の負荷（遅延）が大きくなるにつれて、経路２から経路１へのパケットの高速切り換えによって可能な改善の量はより少なくなる。経路２の方が、経路１よりパケット損失が少ないにもかかわらず、（経路１の遅延の方が小さいときには）いくつかのパケットを経路１に切り換えることが有利である。

Ｖ．例示的なハードウェア実装
次に図４を参照すると、ブロック図には、本発明の一実施形態による、本明細書に記載の技術の実装に適したコンピュータ・システムの一般化されたハードウェア・アーキテクチャが示されている。すなわち、コンピュータ・システム４００は、サーバ、ルータ、エッジ・デバイス、および／または送信サイト（図１の１０２）または受信サイト（図１の１０４）のゲートウェイ、１つまたは複数のそれらのサイト・コンポーネントに組み込まれたＰＭＲ装置（図１の１０６、図３の３０２）もしくはリモート位置のスタンドアローンのＰＭＲ装置、本発明の原理の実装に適する任意のシステムまたは装置などを表す。当然のことながら、本発明が、特定のコンピュータ・システムへの実装に限定されるものではないことを理解されたい。

この例示的な実装において、本発明の方法の少なくとも一部を実装するプロセッサ４０２は、バス４１０または代替接続装置を介して、メモリ４０４、入出力（Ｉ／Ｏ）装置４０６、およびネットワーク・インタフェース４０８に動作可能に結合されている。本明細書で使用する「プロセッサ」という用語が、例えば、ＣＰＵ（中央演算処理装置）および／または他の処理回路（例えば、ＤＳＰ（デジタル・シグナル・プロセッサ）、マイクロプロセッサ）などの任意の処理デバイスを含むことを意図したものであることを理解されたい。さらに、「プロセッサ」という用語が複数の処理デバイスを意味する場合があること、また、ある処理デバイスに関連する様々な要素は他の処理デバイスと共用できることを理解されたい。

本明細書で使用する「メモリ」という用語は、プロセッサまたはＣＰＵに関連した、メモリおよび他のコンピュータ可読の媒体、例えば、ＲＡＭ（ランダム・アクセス・メモリ）、ＲＯＭ（リード・オンリー・メモリ）、固定記憶メディア（例えば、ハード・ドライブ）、リムーバブル記憶メディア（例えば、ディスケット）、フラッシュ・メモリなどを含むことを意図したものである。

また、本明細書で使用する「入出力装置」という用語は、処理ユニットにデータを入力するための１つまたは複数の入力装置（例えば、キーボード、マウスなど）、ならびに処理ユニットに関する結果を提供するための１つまたは複数の出力装置（例えば、ＣＲＴ表示器など）を含むことを意図したものである。

また、本明細書で使用する「ネットワーク・インタフェース」という用語は、例えば、コンピュータ・システム４００を他のコンピュータ・システムと通信できるようにする機能を有する、１つまたは複数の装置を含むことを意図したものである。したがって、ネットワーク・インタフェースは、適切な通信プロトコルを介して、他のコンピュータ・システムの送受信機と通信するように構成された送受信機を含むことができる。本発明が、特定の通信プロトコルに限定されるものではないことを理解されたい。

本明細書では、本発明を障害検出および復旧システムの文脈で説明してきたが、本発明の方法が、コンピュータ可読媒体の形で分配できること、また、分配のために実際に使用される信号搬送媒体の個々の種類とは無関係に、本発明を実装し、その利点を実現できることを理解されたい。本明細書で使用する「コンピュータ可読媒体」という用語は、記録可能型媒体、例えば、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ（コンパクト・ディスク）ＲＯＭ、ならびに伝送型媒体、例えば、デジタルまたはアナログ通信リンク、無線周波数伝送や光伝送などの伝送形式を使用した有線または無線通信リンクなどを含むことを意図したものである。コンピュータ可読媒体は、コード化されたフォーマットの形をとることができる。このコード化されたフォーマットは、特定のデータ処理システムでの使用時にデコードされる。

したがって、本明細書で説明した本発明の方法を実施するための命令またはコードを含む、１つまたは複数のコンピュータ・プログラムまたはそのソフトウェア・コンポーネントは、１つまたは複数の関連する記憶媒体（例えば、ＲＯＭ、固定またはリムーバブル記憶装置）に格納することができ、使用時に、全体または一部が（例えば、ＲＡＭに）ロードされ、プロセッサ４０２によって実行される。

いずれの場合でも、本明細書で説明し添付の図面に示された本発明の技術は、ハードウェア、ソフトウェア、またはそれらの組み合わせなど様々な形で実装することができる。例えば、付随するメモリ、特定実装用の集積回路、機能回路などを備えた、動作可能にプログラムされた１つまたは複数の汎用デジタルコンピュータなどに実装することができる。本明細書で提示した本発明の技術を前提とすれば、当業者なら、本発明の技術の他の実装を企図できるはずである。

ＶＩ．例示の要約および拡張
したがって、本明細書で例示として説明してきたように、本発明は、ネットワークに固有の冗長性を使用することによって、ＶｏＩＰネットワークの復旧力およびＱｏＳを改善するための技術を提供する。本発明は、ＶｏＩＰストリームに投入される、短い、低帯域幅のキープアライブ・パケットを使用して、障害およびネットワークＱｏＳ状態を高速に検出するための新しい監視技術を提供する。本発明は、制御のための監視および検出という考えを重視することによって、キープアライブ・パケットを効果的に複製して第１および第２のネットワーク経路を比較する方法を提示する。また、タイミングと同期の複雑さを避けながら、２つの経路間のＱｏＳ差をより容易に計算する方法も提示する。誤差も除去される。本明細書では、誤報確率を計算することによって、検出方法の良さを解析的に調査した。また、経路間を切り換えることの潜在的な性能利点を調査することによって、本発明の制御方式の利点も解析的に調査した。本発明の提案による解決策は、（ＰＭＲと呼ばれる）装置の中に埋め込むことができる。ＰＭＲは、メディア・ゲートウェイ、エンタープライズ・ルータ、またはエッジ・デバイスと同一場所に配置するか、またはその中に組み込むことができる。

本発明の原理が、他のトラフィック・タイプの性能を監視（および比較）するために使用できることを理解されたい。例えば、各ノードが、「高優先度」および「低優先度」（がヘッダに指定された）キープアライブ・パケットを投入した場合は、高優先度および低優先度サービスのジッタを測定することができる。

本明細書では、本発明の例示的実施形態を添付の図面を参照して説明してきたが、本発明が、これらの実施形態そのものに限定されるものではないことを理解されたい。また、当業者なら、本発明の範囲および趣旨を逸脱することなく、様々な他の変形形態および修正形態を実施し得ることを理解されたい。

本発明の例示的実施形態を使用できるＩＰ電話ベース・ネットワークにおいて、送信サイトと受信サイトの間の複数の経路を示すために使用される簡単なモデルを示すブロック図である。 本発明の例示的実施形態を使用できる、マルチサイトの企業に関連する例示的ＩＰ電話ベース・ネットワークを示すブロック図である。 本発明の例示的実施形態による、障害検出と復旧方法の説明に使用されるオーバレイＶｏＩＰ ＰＭＲグラフを示すブロック図である。 本発明の例示的実施形態による、障害検出と復旧方法の実装に使用されるコンピュータ・システム・アーキテクチャを示すブロック図である。

Claims (20)

1. 通信ネットワークの１つまたは複数の状態を検出する方法であって、
   １つまたは複数のキープアライブ・パケットを、前記通信ネットワーク内のソース・ノードから前記通信ネットワーク内の宛先ノードに、前記ソース・ノードと前記宛先ノードとの間の、少なくとも一部が分離した２つ以上の経路を介して送信する工程と、
   前記宛先ノードで、前記１つまたは複数のキープアライブ・パケットを前記２つ以上の経路を介して受信したとき、前記宛先ノードで、前記通信ネットワークの１つまたは複数の状態を示す少なくとも１つの品質尺度を、前記２つ以上の各経路に対して計算する工程とを含む方法。
2. 前記２つ以上の各経路対して計算された前記品質尺度を比較する工程をさらに含む、請求項１に記載の方法。
3. 前記比較結果を、前記宛先ノードから前記ソース・ノードに送信する工程をさらに含む、請求項２に記載の方法。
4. 前記受信した結果の少なくとも一部に基づいて、前記ソース・ノードから１つまたは複数の通信パケットを送信する工程をさらに含む、請求項３に記載の方法。
5. 前記１つまたは複数の通信パケットがＶｏＩＰパケットである、請求項４に記載の方法。
6. 前記１つまたは複数の通信パケットがシグナリング・パケットである、請求項４に記載の方法。
7. 前記比較の工程が、前記２つ以上の各経路に対して相対的な受信時間に基づいて計算された前記品質尺度を比較する工程をさらに含む、請求項２に記載の方法。
8. 前記送信の工程が、前記１つまたは複数のキープアライブ・パケットを、前記２つ以上の経路を介して同時に送信することをさらに含む、請求項１に記載の方法。
9. 前記送信の工程が、前記１つまたは複数のキープアライブ・パケットを、前記２つ以上の経路を介して一定の時間間隔で送信する工程をさらに含む、請求項１に記載の方法。
10. 前記送信の工程が、前記１つまたは複数のキープアライブ・パケットを、前記通信ネットワーク内の１つまたは複数の中間ノードを通過してトンネリングすることによって送信する工程をさらに含む、請求項１に記載の方法。
11. 前記少なくとも１つの品質尺度が、遅延、ジッタ、および損失のうちの１つに関連している、請求項１に記載の方法。
12. 通信ネットワークの１つまたは複数の状態の検出に使用される装置であって、
    メモリと、
    前記メモリに結合された少なくとも１つのプロセッサであって、１つまたは複数のキープアライブ・パケットを、前記通信ネットワーク内のソース・ノードから前記通信ネットワーク内の宛先ノードに、前記ソース・ノードと前記宛先ノードの間の、少なくとも一部が分離した２つ以上の経路を介して送信するように動作し、前記宛先ノードで、前記１つまたは複数のキープアライブ・パケットが前記２つ以上の経路を介して受信されたとき、前記宛先ノードで、前記通信ネットワークの１つまたは複数の状態を示す少なくとも１つの品質尺度が、前記２つ以上の各経路に対して計算可能になるプロセッサと
    を含むことを特徴とする装置。
13. 前記送信動作が、前記１つまたは複数のキープアライブ・パケットを前記２つ以上の経路を介して同時に送信することをさらに含む、請求項１２に記載の装置。
14. 前記送信動作が、前記１つまたは複数のキープアライブ・パケットを前記２つ以上の経路を介して一定の時間間隔で送信することを含む、請求項１２に記載の装置。
15. 前記送信動作が、前記１つまたは複数のキープアライブ・パケットを、前記通信ネットワーク内の１つまたは複数の中間ノードを通過してトンネリングすることにより送信することを含む、請求項１２に記載の装置。
16. 通信ネットワークの１つまたは複数の状態の検出に使用される装置であって、
    メモリと、
    前記メモリに結合された少なくとも１つのプロセッサであって、１つまたは複数のキープアライブ・パケットが、前記通信ネットワーク内のソース・ノードから前記通信ネットワーク内の宛先ノードに、前記ソース・ノードと前記宛先ノードの間の、少なくとも一部が分離した２つ以上の経路を介して送信されたことに応答して、前記宛先ノードで、前記１つまたは複数のキープアライブ・パケットを前記２つ以上の経路を介して受信したとき、前記宛先ノードで、前記通信ネットワークの１つまたは複数の状態を示す少なくとも１つの品質尺度を、前記２つ以上の各経路に対して計算するように動作するプロセッサと
    を含むことを特徴とする装置。
17. 前記少なくとも１つのプロセッサが、前記２つ以上の各経路に対して計算された前記品質尺度を比較するようにさらに動作する、請求項１６に記載の装置。
18. 前記少なくとも１つのプロセッサが、前期比較の結果を前記宛先ノードから前記ソース・ノードに送信するようにさらに動作する、請求項１７に記載の装置。
19. 前記比較の動作が、前記２つ以上の各経路に対して相対的な受信時間に基づいて計算された前記品質尺度を比較することをさらに含む、請求項１７に記載の装置。
20. 前記少なくとも１つの品質尺度が、遅延、ジッタ、および損失のうちの１つに関連している、請求項１６に記載の装置。
    

Images