JP2009526484A - マルチメディア通信セッションに使用するメディア・ゲートウェイのインテリジェントな選択 - Google Patents

Abstract

パケット・ネットワークを操作する方法は、パケット・ネットワークとＴＤＭネットワークの間でマルチメディア通信セッションを接続するための候補となる複数のゲートウェイの中から１つを選択するステップを備えている。パケット・ネットワークにはマルチメディア通信セッションのソース・ノードが含まれており、ＴＤＭネットワークはマルチメディア通信セッションの宛て先が含まれている。候補となるゲートウェイは、パケット・ネットワークとＴＤＭネットワークとを相互接続する。選択のステップには、ソース・ノードと複数の様々な候補となるゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を比較するステップが含まれる。

Description

本発明は、一般にパケット・ネットワークに関し、より具体的には時分割多重（ＴＤＭ）ネットワークを使用したマルチメディア通信セッションをサポートするパケット・ネットワークに関する。

ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などのマルチメディア・サービスを実装すると、データ・サービスによる収束が可能になるため、サービス・プロバイダ（ＳＰ：ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）は資本と業務の両方を節約できる。基本的なＶｏＩＰサービスを実装するのは簡単かもしれないが、従来の電話の品質、信頼性、セキュリティ、および拡張性を備えるＶｏＩＰサービスの実装は難題であろう。実際に、キャリア・グレードのＶｏＩＰには、パケット・ネットワークの様々なレイヤでの要件があると言える。望ましい要件には、サービス・レイヤでのユーザ認証、データ・レイヤでのバースト性トラフィックにおける音声の品質、およびコントロール・レイヤでのネットワーク障害への動的な対応が含まれる。さらに、こうした特性は複数のベンダーが異なるアクセス技術を使用している場合にも望ましい。

パケット・ネットワークと公衆交換電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）の間のインターフェースは、キャリア・グレードのＶｏＩＰを開発するときにおそらく技術上の重要な問題であろう。このインターフェースは、ハイブリッドＶｏＩＰと回路交換ネットワーク（例えばＰＳＴＮ）の間の効率的で信頼性と拡張性が高い相互運用を提供するのが望ましい。こうしたハイブリッド・ネットワークにおいて、ＩＴマルチメディア・サブシステム（ＩＭＳ：ＩＴ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）アーキテクチャは、接続許可制御、ルーティング、およびサービスの品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）の保証を提供できることになる。ＩＭＳアーキテクチャは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）および第３世代パートナーシップ・プロジェクト２（３ＧＰＰ２：３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）によって開発され、標準化されている。

ＩＭＳアーキテクチャにおいて、１つまたは複数のコア・パケット・ネットワークは標準化されたインターフェースを経由してネットワークにアクセスする。標準化されたインターフェースにより、コア・ネットワークは、Ｅｔｈｅｒｎｅｔ（登録商標）、ケーブル、ＤＳＬ、第３世代（３Ｇ）セルラー、およびＷｉＦｉなど、異なるアクセス技術間にシームレスな通信を提供できることになる。ＩＭＳアーキテクチャにおいて、コア・パケット・ネットワークはセッション開始プロトコル（ＳＩＰ：ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ）をサポートする。

ＩＭＳアーキテクチャには、ＴＤＭネットワーク（例えばＰＳＴＮネットワーク）とコア・パケット・ネットワークの間のマルチメディア通信セッションをサポートするメディア・ゲートウェイを割り当てる機能コンポーネントを含めることができる。こうした機能コンポーネントは、例えばボーダー・ゲートウェイ制御機能（ＢＧＣＦ：ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）でもよい。ＢＧＣＦは、コア・パケット・ネットワークと宛て先ＴＤＭネットワークの間のマルチメディア通信セッションにメディア・ゲートウェイ（ＭＧＷ：ｍｅｄｉａ ｇａｔｅｗａｙ）を割り当てることにより、マルチメディア通信セッション（例えばＶｏＩＰコール）のルーティングを決定する。ＢＧＣＦは、ルーティング・テーブルを使用してマルチメディア通信セッションを宛て先ＴＤＭネットワークに接続する適切なＭＧＷを決定することができる。

ＩＭＳをサポートするパケット・ネットワークと時分割多重ネットワークの間で、マルチメディア通信セッションを接続するゲートウェイを提供する。

一部のネットワーク・アーキテクチャでは、ボーダー・ゲートウェイ制御機能（ＢＧＣＦ）を使用して、メディア・ゲートウェイ（ＭＧＷ）からマルチメディア通信セッション（例えばＶｏＩＰコール）のルーティングを統計的に決定する。こうしたＢＧＣＦは、通常は静的なルーティング・テーブルに依存しているため、動的でバースト性のトラフィック状態に関しては最適化されない。これとは対照的に、インテリジェントＢＧＣＦはリンクの状態とトラフィックの負荷の変化をＭＧＷで補償することができる。インテリジェントＢＧＣＦのいくつかの実施形態では、要求されたマルチメディア通信セッションのソース・ノードとセッションの宛て先ＴＤＭネットワークにサービスを提供するＭＧＷの間のベアラ（ｂｅａｒｅｒ）・トラフィックに関するエンドツーエンドの輻輳に基づいて、セッションにメディア・ゲートウェイ（ＭＧＷ：ｍｅｄｉａ ｇａｔｅｗａｙ）を動的に割り当てる。こうした動的なルーティング方法により、宛て先ＴＤＭネットワークに接続できるマルチメディア通信セッションの数を増やすことができる。

１つの実施形態は、パケット・ネットワークの一部を操作する方法を特徴とする。本方法には、パケット・ネットワークとＴＤＭネットワークの間でマルチメディア通信セッションを接続するための候補となる複数のゲートウェイの中から１つを選択するステップが含まれる。パケット・ネットワークにはマルチメディア通信セッションのソース・ノードが含まれており、ＴＤＭネットワークはマルチメディア通信セッションの宛て先が含まれている。候補となるゲートウェイは、パケット・ネットワークとＴＤＭネットワークとを相互接続する。選択のステップには、ソース・ノードと複数の異なる候補となるゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を比較するステップが含まれる。

別の実施形態は、ＩＰメディア・サブシステム（ＩＭＳ）をサポートするパケット・ネットワークの一部を操作する方法を特徴とする。本方法には、パケット・ネットワークと時分割多重ネットワークの間のマルチメディア通信セッションとを接続するための候補となる複数のメディア・ゲートウェイの中から１つを選択するステップが含まれる。パケット・ネットワークは、マルチメディア通信セッション（例えばＶｏＩＰコール）のソース・ノードを備えており、ＩＰマルチメディア・サブシステムをサポートする。時分割多重ネットワークは、マルチメディア通信セッションの宛て先を備えている。候補となるメディア・ゲートウェイのそれぞれは、パケット・ネットワークと時分割多重ネットワークとを相互接続する。選択のステップには、ソース・ノードと候補となる第１のゲートウェイの間のベアラ・パケット・トラフィックに関するエンドツーエンドの輻輳と、ソース・ノードと候補となる第２のゲートウェイの間のベアラ・パケット・トラフィックに関するエンドツーエンドの輻輳とを比較するステップが含まれる。

様々な実施形態には、マシンで実行可能な形の命令プログラムでエンコードされたデータ記憶媒体が含まれる。こうした命令は、パケット・ネットワークを操作して本明細書で説明する１つの方法および／またはプロセスのステップを実行する方法を提供する。例えば、この命令はエンコードされ、前述の方法における選択のステップを実行することによってパケット・ネットワークの一部を操作することができる。

さらに別の実施形態は、方法のステップを実行するマシンで実行可能な命令プログラムを格納するデータ記憶媒体を備えるサーバまたはルータを特徴とする。こうしたステップには、パケット・ネットワークと時分割多重ネットワークの間で要求されたＶｏＩＰコールを接続するための候補となる複数のメディア・ゲートウェイの中から１つを選択するステップが含まれる。パケット・ネットワークには、ＶｏＩＰコールのソース・ノードが含まれている。時分割多重ネットワークには、ＶｏＩＰコールの宛て先が含まれている。候補となるメディア・ゲートウェイは、パケット・ネットワークと時分割多重ネットワークとを相互接続する。選択のステップには、ソース・ノードと候補となる複数のゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を、第１のゲートウェイと第２のゲートウェイについて比較するステップが含まれる。サーバまたはルータは、パケット・ネットワーク内に配置されており、ＳＩＰをサポートする。

説明を目的とした実施態様は、図面および以下の「発明を実施するための最良の形態」によってより詳細に説明される。ただし、本発明は様々な形で具体化でき、図面および以下の「発明を実施するための最良の形態」で説明されている実施形態に限定はされない。

図１は、ＩＭＳアーキテクチャを備える例示的なインターネット・プロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）および／またはマルチプロトコル・ラベル交換（ＭＰＬＳ：Ｍｕｌｔｉｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）コア・パケット・ネットワーク１２を簡略化して示している。ＩＭＳアーキテクチャには、コア・パケット・ネットワーク１２とＴＤＭネットワーク１４（例えばＰＳＴＮ）の間のマルチメディア通信セッション（ＭＣＳ）をセットアップするときに動作できる様々な機能コンポーネントが含まれる。ＩＭＳアーキテクチャの様々な機能コンポーネントは、図１の線で簡略化して示すように、セッション開始プロトコル（ＳＩＰ）メッセージを送信することによって対話する。ＩＭＳアーキテクチャの機能コンポーネントは、例えば、コア・データ・ネットワーク１２内のサーバおよび／またはルータに格納され、そこで実行されるマシンで実行可能な命令プログラムおよび／またはデータ構造でもよい。

コア・パケット・ネットワーク１２には、さらにメディア・ゲートウェイ（ＭＧＷ）の複数のＩＰアドレスまたはＭＰＬＳラベルも含まれる。ＭＧＷは、コア・パケット・ネットワーク１２内のソース・ノードとＴＤＭネットワーク１４の間のベアラ・トラフィックに使用する接続（すなわち太線で示される）を提供する。特に、各ＭＧＷは、例えば、コア・パケット・ネットワーク１２内のベアラ・トラフィックのＩＰおよび／またはＭＰＬＳプロトコルと、ＴＤＭネットワーク１４内のベアラ・トラフィックのリアルタイム・トランスポート・プロトコル（ＲＴＰ：ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）トラフィック（例えばＰＳＴＮのＩＳＤＮ／ＩＳＵＰプロトコル・トラフィック）の間の相互変換を提供する。ベアラ・トラフィックは、例えば、マルチメディア通信をサポートする。例示的なマルチメディア通信には、ＶｏＩＰコール、音声通信、ファクシミリ送信、イメージ通信、低解像度ビデオ通信などが含まれる。

本明細書では、コア・パケット・ネットワーク１２とＴＤＭネットワーク１４の間でベアラ・トラフィックを転送できるメディア・ゲートウェイ（ＭＧＷ）の各ＩＰポートのアドレスまたはＭＰＬＳポート・ラベルは、メディア・ゲートウェイ（ＭＧＷ）と表されている。各ポートには、対応するベアラ・トラフィックの負荷、およびコア・パケット・ネットワーク１２の様々なソース・ノードをソースおよび／または宛て先とするベアラ・トラフィックの操作に関連するエンドツーエンドの輻輳が存在する。こうしたＭＧＷの個別のポートには、それぞれに固有の負荷および輻輳のプロパティがある。

本明細書では、パケット・ネットワークの２つのアドレス間に提供されるエンドツーエンドのＱｏＳは、様々な測定可能プロパティから評価できる。このようなプロパティは、２つのアドレス間のパケット・ベアラ・トラフィックに関するエンドツーエンドの輻輳を表している。こうした測定可能プロパティの例には、２つのアドレス間の送信に関するエンドツーエンドのパケット遅延、２つのアドレス間の送信に関する往復パケット遅延、２つのアドレス間の送信に関するパケット損失率、２つのアドレス間の送信に関するパケット遅延ジッタ（ｊｉｔｔｅｒ）、および前述の任意の測定可能プロパティの平均が含まれる。こうしたプロパティのいずれかの増大は、２つのアドレス間のベアラ・トラフィックに関するエンドツーエンドの輻輳が増大したことを示している。本明細書において、エンドツーエンドの輻輳に基づく操作はこうした任意のプロパティの値に基づいてもよい。

ＩＭＳアーキテクチャにおいて、複数のＳＩＰ対応の機能コンポーネントはコア・パケット・ネットワーク１２を経由したＭＣＳの許可およびルーティングを行う場合に動作できる。こうしたコンポーネントには、問い合わせコール・セッション制御機能（Ｉ−ＣＳＣＦ：ｉｎｔｅｒｒｏｇａｔｉｎｇ ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）、１つまたは複数のサービス・コール・セッション制御機能（Ｓ−ＣＳＣＦ：ｓｅｒｖｉｃｅ ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）、ホーム加入者サーバ（ＨＳＳ：ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ ｓｅｒｖｅｒ）、ボーダー・ゲートウェイ制御機能（ＢＧＣＦ）、およびメディア・ゲートウェイ制御機能（ＭＧＣＦ：ｍｅｄｉａ ｇａｔｅｗａｙ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）を含めてもよい。

各Ｉ−ＣＳＣＦは、外部エンティティとＩＭＳアーキテクチャとのインターフェースを担当する論理インターフェースを構成する。例示的な外部エンティティには、ユーザ・エージェント、アクセス・ネットワーク、およびその他のコア・パケット・ネットワークが含まれる。Ｉ−ＣＳＣＦは、例えば、ＭＣＳセットアップ要求に応答した許可およびルーティングの決定を担当する。Ｉ−ＣＳＣＦは、こうした要求に関連するＳＩＰメッセージ（１つまたは複数）をＳ−ＣＳＣＦに送信できる。Ｉ−ＣＳＣＦおよび／またはＳ−ＣＳＣＦは、許可およびルーティングに関する決定を行う適切なＩＭＳ機能を決定し、こうした機能にＳＩＰメッセージ（１つまたは複数）を送信する。

Ｉ−ＣＳＣＦおよび／またはＳ−ＣＳＣＦは、ＩＭＳアーキテクチャを経由して１つまたは複数のネットワーク・データベースに問い合わせて、ＳＩＰルーティングの決定または対処に関する支援を受けることができる。データベースには、例えば、一般的にユーザ情報（様々な外部エンティティのＳ−ＣＳＣＦ ＩＤなど）を格納するホーム加入者サーバ（ＨＳＳ）を含めてもよい。

Ｉ−ＣＳＣＦおよび／またはＳ−ＣＳＣＦは、さらに１つまたは複数のアプリケーション・サーバ（ＡＳ：ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｅｒ）に問い合わせて、ＳＩＰルーティングの決定または対処に関する支援を受けることもできる。ＡＳは、特定のサービス（例えば、ＶｏＩＰコールのルーティングを変更するサービス）を提供できる。

要求されたＭＣＳの宛て先がＴＤＭネットワーク１４内にある場合は、対応するＩ−ＣＳＣＦまたはＳ−ＣＳＣＦは許可およびルーティングに関する決定を行うためのセッションレベルの任務をＢＧＣＦにハンドオフする。特に、ＢＧＣＦはＭＣＳを許可するかどうかを決定し、候補となるＭＧＷを選択してコア・パケット・ネットワーク１２とＴＤＭネットワーク１４の間のＭＣＳのベアラ・トラフィックに使用する接続を提供することができる。本明細書において、候補となるＭＧＷとは、要求されたＭＣＳのソースを含むパケット・ネットワークと要求されたＭＣＳの宛て先を含むＴＤＭネットワークとを相互接続するＭＧＷを意味する。実際に、ＢＧＣＦはコア・パケット・ネットワーク１２内で許可されるＭＣＳのベアラ・トラフィックに使用する１つのエンド・ポイント（すなわちＭＧＷ）を選択することによって、こうしたＭＣＳのルーティングを決定する。

ＭＧＷを選択した後で、ＢＧＣＦは選択されたＭＧＷを担当するメディア・ゲートウェイ制御機能（ＭＧＣＦ）に要求されたＭＣＳの制御を渡す。ＭＧＣＦは、ＩＭＳアーキテクチャのＳＩＰプロトコルとＴＤＭネットワーク１４のプロトコルの間にシグナリングの相互作用を提供するとともに、選択されたＭＧＷを制御する。ＭＧＷの宛て先ＩＰアドレスが選択されると、ＩＭＳネットワークを経由したパスはＢＧＣＦでは制御されなくなる。実際に、基盤となるコア・パケット・ネットワーク・トポロジはＢＧＣＦからは不可視であってもよい。こうした不可視性は、１つの組織の組がＩＰトランスポート・レイヤを備えており、別の組織の組がＩＭＳアーキテクチャを備えていることによって発生する可能性がある。

宛て先がＴＤＭネットワーク１４内にあるＭＣＳのセットアップ要求は、適切なＢＧＣＦをトリガーしてＭＧＷの選択と割り当てに関連する決定を行う一方で、ソースがＴＤＭネットワーク１４内にあるＭＣＳは通常はＭＣＳ用のＭＧＷの選択を実行する場合にＢＧＣＦを呼び出さない。

一部のＩＭＳアーキテクチャは、コア・パケット・ネットワーク内のソース・ノードに対してＭＧＷの静的な割り当てを行う。１つの静的割り当てのタイプには、与えられたソースおよび宛て先が与えられたＴＤＭネットワーク内にあるすべてのＭＣＳに対して、あらかじめ選択された同一のＭＧＷを割り当てるタイプが含まれる。このような例において、ＢＧＣＦは、あらかじめ選択されたＭＧＷが使用できない場合はいつでも、要求されたＭＣＳをブロックするＳＩＰメッセージを送信する。これに代わる静的割り当てのタイプには、あらかじめ選択されたリストからＭＧＷを選択するタイプが含まれる。ＢＧＣＦは、リストを検索し、要求されたＭＣＳに対してＭＧＷを逐次的に検出する。ＢＧＣＦは、リスト内で使用可能な最初のＭＧＷを要求されたＭＣＳに割り当て、リスト内に使用可能なＭＧＷがない場合は要求されたＭＣＳをブロックするように決定する。

負荷の大きいトラフィック状態では、こうしたソース・ノードへのＭＧＷの静的割り当てを行うと、いくつかの理由により、ＭＣＳの非効率的な処理が発生する可能性がある。第１に、静的割り当てによって、割り当てられた１つまたは複数のＭＧＷにかかる負荷が大きい場合はいつでもＭＣＳをブロックする要求が生成される。つまり、こうした条件の下では、パケット・ネットワークに含まれる他のＭＧＷが要求されたＭＣＳに使用する接続を提供できる場合でも、特定のソース・ノードから要求されたすべてのＭＣＳがブロックされることになる。第２に、こうしたＭＧＷの静的割り当てでは、あらかじめ選択されたリストを使用してＭＧＷを選択した場合に、いくつかのＭＧＷの使用が過大になり、他のいくつかのＭＧＷの使用が過小になる傾向がある。

ＭＣＳの静的なルーティング方法にはこうした１つまたは複数の非効率性があるため、動的なＭＣＳのルーティング方法が提案されている。以下では、様々な実施形態がパケット・ネットワーク内のソース・ノードとＴＤＭネットワーク内の宛て先の間で要求されたＭＣＳの許可とルーティングを行うための動的な方法を提供している。

図１に示すＩＭＳアーキテクチャでは、ＢＧＣＦはソース・ノードと個々の候補となるＭＧＷの間のベアラ・トラフィックに関するエンドツーエンドの輻輳に基づいて、要求されたＭＣＳを接続するＭＧＷを選択する。したがって、このようなＢＧＣＦをインテリジェントＢＧＣＦと呼ぶことができる。前述の説明から明らかなように、ソース・ノードと個々の候補となるＭＧＷの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を表す様々な測定可能プロパティが存在する。こうした測定値には、例えば、エンドツーエンドのパケット遅延、エンドツーエンドの往復パケット遅延、エンドツーエンドのパケット損失率、エンドツーエンドのパケット遅延ジッタについて最近測定された任意の値、および前述の任意の測定可能プロパティの平均が含まれる。本実施形態は、ベアラ・トラフィックに関するエンドツーエンドの輻輳を表すこうした任意の測定可能プロパティに基づく方法および装置を対象とする。例として、エンドツーエンドのパスの輻輳を表す測定値は、コア・パケット・ネットワーク１２内のパスをアクティブに調査することによって動的に作成してもよく、コア・パケット・ネットワーク１２内の管理システムによる累積データを使用して受動的に作成してもよい。前者の方法では、例えば、ＩＰのピン(ｐｉｎｇ)機能を使用して、ソース・ノードと候補となるＭＧＷの間のベアラ・トラフィックに関するエンドツーエンドのパスの遅延および／または別のエンドツーエンドの輻輳の基準を取得することができる。後者の例では、簡易ネットワーク管理プロトコル（ＳＮＭＰ：ｓｉｍｐｌｅ ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｐｒｏｔｏｃｏｌ）の測定値をコア・パケット・ネットワーク１２の個々の要素から収集し、それによってベアラ・トラフィックに関するエンドツーエンドの輻輳の低周波測定値を取得することができる。

図２は、図１に示すコア・データ・ネットワーク１２内のエンドツーエンドのパスの輻輳を表す測定値またはこうした測定値の平均を保持するために使用できる例示的なルーティング・テーブル１６を示している。ルーティング・テーブル１６には、ソース・ノード（すなわちルータまたはサーバ）、およびＭＧＷ（すなわちＭＧＷ−１〜ＭＧＷ−Ｎ）を含むペアでラベル付けされた個々のエントリ１８が含まれる。また、各エントリ１８には、ソース・ノードとＭＧＷのペア間のエンドツーエンドの輻輳を表す選択された測定値、または測定されたエンドツーエンドの輻輳の平均を格納することもできる。ルーティング・テーブル１６は、ＢＧＣＦと同じサーバまたはルータに格納することもできるが（例えば、図１０に示すように）、コア・データ・ネットワーク１２内の任意の場所にすることも格納できる。ルーティング・テーブル１６の個々のエントリ１８は、定期的に、不定期に、または指定されたイベント（例えば、新しいＭＣＳのセットアップ要求の受信または処理）に応答して更新することができる。

図３Ａは、パケット・ネットワークに含まれるソース・ノードとＴＤＭネットワークに含まれる宛て先・アドレスの間のＭＣＳセットアップ要求を処理する方法２０Ａを示している。様々な実施形態において、要求されたマルチメディア通信は、ＶｏＩＰコール、イメージ通信、ファクシミリ送信、低解像度ビデオ通信、および／またはその他のタイプのマルチメディア通信のいずれでもよい。

方法２０Ａには、パケット・ネットワーク内のソース・ノードで新しいＭＣＳセットアップ要求を受信するステップ（ステップ２１Ａ）が含まれる。こうした要求は、例えば、ソース・ノードに直接接続されたユーザ・エージェントから、または要求の実際の生成元を受信ソース・ノードに接続する別のパケット・ネットワークから受信される。

方法２０Ａには、要求されたＭＣＳに使用するパケット・ネットワークとＴＤＭネットワークの間の接続として機能する１つのメディア・ゲートウェイを選択して割り当てるステップ（ステップ２３Ａ）が含まれる。割り当てられたメディア・ゲートウェイは、２つのネットワーク間のＭＣＳのベアラ・トラフィック・データを変換し、転送する。このメディア・ゲートウェイは、ソース・パケット・ネットワークと宛て先ＴＤＭネットワークとを相互接続する候補となるメディア・ゲートウェイのセットの中から選択される。選択のステップには、ソース・ノードと候補となる様々な個別のゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を比較するステップが含まれる。これは、例えば、図２のルーティング・テーブル１６に格納されるエンドツーエンドの輻輳を表す測定値を比較することによる。選択のステップは、比較を使用してエンドツーエンドの輻輳が最も小さい候補となるゲートウェイの適切なサブセットを識別し、さらにこの適切なサブセットの中からメディア・ゲートウェイを選択して要求されたＭＣＳに割り当てるステップを含むことができる。選択されたメディア・ゲートウェイを割り当てることにより、前記ゲートウェイはＭＣＳのベアラ・トラフィックを処理できるようになる。

いくつかの実施形態において、メディア・ゲートウェイを選択するステップには、候補となる様々なメディア・ゲートウェイから得られるＱｏＳを考慮するステップも含まれる。例えば、選択のステップには、ソース・ノードとのベアラ・トラフィックに関するエンドツーエンドの輻輳が十分に低く、要求されたＭＣＳタイプについてあらかじめ必要とされたＱｏＳレベルを保証できるメディア・ゲートウェイを識別し、さらにこのようにして識別されたメディア・ゲートウェイの１つを選択することによって要求されたＭＣＳに使用するネットワーク間の接続を提供するステップが含まれる。

方法２０Ａには、オプションで、メディア・ゲートウェイの選択を実行することによって要求されたＭＣＳに使用するネットワーク相互接続を提供する前に、要求されたＭＣＳを許可するかブロックするかを決定するステップ（ステップ２２Ａ）が含まれる。許可するかブロックするかの決定は、候補となるメディア・ゲートウェイの利用可能性と、オプションでサービスの品質（ＱｏＳ）に関する考察に基づいている。いくつかの実施形態では、要求されたＭＣＳが許可されるためには、新しいＭＣＳに使用するメディア・ゲートウェイの回路の利用可能性で十分である。この実施形態では、要求されたＭＣＳに使用できる回路を備えるメディア・ゲートウェイが見つからない場合に、方法２０Ａには要求されたＭＣＳをブロックするステップ（ステップ２４Ａ）が含まれる。他の実施形態では、得られるＱｏＳは要求されたＭＣＳを許可するかブロックするかを決定する上で１つの役割を果たす。このような実施形態において、要求されたＭＣＳの許可を決定するには、少なくとも、１つのメディア・ゲートウェイが要求されるＭＣＳのタイプにふさわしいＱｏＳを提供できることを確認する必要がある。ＱｏＳの値は、エンドツーエンドの輻輳を表す前述の任意のプロパティ（例えば、ソース・ノードとメディア・ゲートウェイの間に発生する一方向のみまたは往復のエンドツーエンドのパケット遅延、ソース・ノードとメディア・ゲートウェイの間のパケット損失率、ソース・ノードとメディア・ゲートウェイの間の累積されたパケット遅延ジッタ、およびこれらの平均）を使用して測定できる。エンドツーエンドの輻輳を表すものとして選択された測定可能プロパティの値が要求されたＭＣＳに関してあらかじめ選択されたしきい値を下回る場合に、関連のメディア・ゲートウェイは適切なＱｏＳを提供する。この実施形態では、要求されたＭＣＳに使用できる回路を備えると同時に適切なＱｏＳを提供できるメディア・ゲートウェイが見つからない場合に、方法２０Ａには要求されたＭＣＳをブロックするステップ（ステップ２４Ａ）が含まれる。

図３Ｂは、図３Ａに示す方法２０Ａの特定の実施形態２０Ｂを示している。この実施形態において、パケット・ネットワークはＩＭＳアーキテクチャを備えており、ＩＰおよび／またはＭＰＬＳプロトコルをサポートする。ＴＤＭネットワークは、ＩＳＤＮ／ＩＳＵＰプロトコルをサポートでき、例えばＰＳＴＮでもよい。特に、要求されたＭＣＳのソース・ノードは図１に示すコア・パケット・ネットワーク１２内にあり、要求されたＭＣＳの宛て先アドレスは図１に示すＴＤＭネットワーク１４内にある。

方法２０Ｂには、新しいＭＣＳのセットアップ要求をＩ−ＣＳＣＦで受信するステップ（ステップ２２Ｂ）が含まれる。ただし、ＭＣＳのソース・ノード（すなわちルータまたはサーバ）はパケット・ネットワーク１２内にあることになる。方法２０Ｂには、受信した要求に関連するＳＩＰメッセージ（１つまたは複数）をＩ−ＣＳＣＦから前記Ｉ−ＣＳＣＦで指定されたＳ−ＣＳＣＦに転送するステップ（ステップ２３Ｂ）が含まれてよい。方法２０Ｂには、ＭＣＳの宛て先はＴＤＭネットワーク内にあるという判定に応答して要求されたＭＣＳに関するＳＩＰメッセージ（１つまたは複数）をＳ−ＣＳＣＦまたはＩ−ＣＳＣＦから適切なインテリジェントＢＧＣＦに送信するステップ（ステップ２４Ｂ）が含まれる。この適切なインテリジェントＢＧＣＦは、要求されたＭＣＳの宛て先ＴＤＭネットワークに関するエンド・ポイントのルーティングの決定（すなわちＭＧＷの選択）を行う。これに代わる実施形態では、インテリジェントＢＧＣＦをインテリジェントＭＧＣＦのセットで置き換えてもよい。ただし、セットに含まれるインテリジェントＭＧＣＦは宛て先ＴＤＭネットワークのための候補となるＭＧＷの唯一の適切なサブセットを制御し、選択できる。本明細書において、候補となるＭＧＷはＭＣＳのソース・ノードを備えるパケット・ネットワークをＭＣＳの宛て先を備えるＴＤＭネットワークに接続するＭＧＷである。ＢＧＣＦで、方法２０Ｂには要求されたＭＣＳを許可するかブロックするかを決定するステップ（ステップ２５Ｂ）がオプションで含まれる。いくつかの実施形態では、候補となるＭＧＷがいずれも要求されたＭＣＳのサポートに使用できない場合にのみ、ＢＧＣＦは要求されたＭＣＳをブロックするように決定することになる。他の実施形態では、候補となるＭＧＷがいずれも使用できない場合、または使用できる候補となるＭＧＷがいずれも要求されたタイプのＭＣＳに対して必要とされるＱｏＳを提供できない場合に、ＢＧＣＦは要求されたＭＣＳをブロックするように決定することになる。例えば、不適切なＱｏＳはソース・ノードと候補となる各ＭＧＷの間のベアラ・トラフィックに関するエンドツーエンドの輻輳が非常に高い場合に得られる。

要求されたＭＣＳを許可するのに応答して、方法２０Ｂには候補となるＭＧＷのセットの中から１つのＭＧＷをＢＧＣＦに選択させるステップ（ステップ２６Ｂ）が含まれる。選択されたＭＧＷは、新しいＭＣＳのサポートに割り当てられ、その結果、要求されたＭＣＳの第２のＩＰおよび／またはＭＰＬＳエンド・ポイントとして効果的に動作する。割り当てられたＭＧＷは、要求されたＭＣＳのベアラ・トラフィックに関するパケット・ネットワーク１２とＴＤＭネットワーク１４の間の相互接続を提供することになる。許可と選択に関する決定のステップ２５Ｂ、２６Ｂは、ソース・ノードと候補となるＭＧＷのそれぞれ１つの間のベアラ・トラフィックに関するエンドツーエンドの輻輳の動的に更新された測定値に基づいている。ステップ２５Ｂと２６Ｂには、ルーティング・テーブル（例えば図２のルーティング・テーブル１６）に問い合わせてこうしたエンドツーエンドの輻輳を表す測定値を取得するステップを含めてもよい。ＭＧＷの割り当てに応答して、方法２０Ｂにはソース・ノードに割り当てられるＭＧＷを識別するＳＩＰメッセージ（１つまたは複数）をＩ−ＣＳＣＦに送信するステップ（ステップ２７Ｂ）が含まれる。このメッセージ（１つまたは複数）は、例えば、割り当てられたＭＧＷを制御するＢＧＣＦまたはＭＧＣＦから発生でき、識別情報には、例えば割り当てられたＭＧＷのＩＰアドレスまたはＭＰＬＳラベルが含まれる。要求されたＭＣＳをブロックするという決定に応答して、方法２０ＢにはＭＣＳがブロックされることを要求するＳＩＰメッセージをＢＧＣＦからＩ−ＣＳＣＦに送信するステップ（ステップ２８Ｂ）が含まれる。続いて、要求されたＭＣＳが許可される場合に、ソース・ノードはＭＣＳのベアラ・トラフィックを割り当てられたＭＧＷに送信することになる（２９Ｂ）。

様々な実施形態において、方法２０Ｂには様々な動的プロセスに従って要求されたＭＣＳに割り当てられるＭＧＷを選択するステップが含まれる。このような動的プロセスの例は、図４〜８に示されている。このような動的プロセスにおいて、２つのアドレス間のベアラ・トラフィックに関するエンドツーエンドの輻輳は、２つのアドレス間の送信に関するエンドツーエンドのパケット遅延、往復のパケット遅延、パケット損失率、またはパケット遅延ジッタを意味してもよく、こうした任意の測定可能プロパティの平均を意味してもよい。

図４を参照すると、第１のプロセス３０では候補となるＭＧＷ間でエンドツーエンドの輻輳の極端な相違を縮小する傾向があるようにＭＧＷを選択している。特に、プロセス３０には、ルーティング・テーブル（例えば図２に示すルーティング・テーブル１６）を検索することによって、候補となるＭＧＷの中で要求されたＭＣＳのソース・ノードとのベアラ・トラフィックのエンドツーエンドの輻輳が最も小さいものを識別するステップ（ステップ３２）が含まれる。また、プロセス３０には、識別された候補となるＭＧＷを割り当てることによって、要求されたＭＣＳのベアラ・トラフィックに関するネットワーク間の接続を提供するステップ（ステップ３４）が含まれる。

要求されたＭＣＳを識別されたＭＧＷに割り当てることにより、ルーティング・テーブルのエントリがそれほど古くない場合に、候補となるＭＧＷ間でエンドツーエンドの輻輳の範囲を縮小する傾向がある。ルーティング・テーブルのエントリが古い場合は、プロセス３０によって候補となるＭＧＷ間でエンドツーエンドの輻輳の範囲が増大する可能性もある。実際に、ルーティング・テーブルが更新されない限り、指定されたソース・ノードから新しいＭＣＳが要求されるたびに、プロセス３０によって同じＭＧＷが選択されることになる。したがって、プロセス３０に基づく実施形態では、おそらくルーティング・テーブルを頻繁に更新し、ソース・ノードからの新しいすべてのＭＣＳセットアップ要求によって、選択されるＭＧＷの負荷が過大にならないようにする必要があるだろう。

図５を参照すると、要求されたＭＣＳに対してＭＧＷを選択するための第２のプロセス４０は、ＱｏＳの制約に基づいている。

プロセス４０には、エンドツーエンドの輻輳を表す１つまたは複数の測定されたプロパティを提供するルーティング・テーブルを検索し、要求されたタイプのＭＣＳで必要とされるＱｏＳを提供できるあらかじめ選択された数の候補となるＭＧＷを識別するステップ（ステップ４２）が含まれる。ステップ４２で、あらかじめ選択された数を２にすることによって２つのＭＧＷが識別されるようにしてもよい。また、あらかじめ選択された数は、２より大きい整数でもよい。ステップ４２では、必要とされるＱｏＳに対してエンドツーエンドの輻輳が大きすぎる候補となるＭＧＷを除去することによって、候補となるＭＧＷのセットを縮小する。特に、ステップ４２では、要求されたＭＣＳのタイプに関してあらかじめ選択されたしきい値を上回るエンドツーエンドの輻輳に関連した候補となるＭＧＷを識別しない。

また、プロセス４０には、識別された候補となるＭＧＷの中からランダム選択プロセスを介して１つのＭＧＷを選択するステップ（ステップ４４）も含まれる。選択されたＭＧＷは、要求されたＭＣＳのベアラ・トラフィックのためのパケット・ネットワーク１２とＴＤＭネットワーク１４の間の接続を提供するように割り当てられる。ランダムな選択を行うには、固定数のオブジェクトの集合から１つのオブジェクトを疑似乱数的に選択するための様々なアルゴリズムのいずれを使用してもよい。ルーティング・テーブルの関連するエントリが古くない場合は、選択されたＭＧＷは通常は要求されたＭＣＳに関して十分なＱｏＳを提供することになる。

図６を参照すると、要求されたＭＣＳに対してＭＧＷを選択するための第３のプロセス５０は、ソース・ノードと候補となるＭＧＷのセットに含まれるＭＧＷの間のエンドツーエンドの輻輳を等化する傾向がある。プロセス５０には、あらかじめ選択された数の候補となるＭＧＷをランダムに選択するステップ（ステップ５２）が含まれる。あらかじめ選択された数は、２でも２より大きい整数でもよい。選択のステップ５２では、固定数のオブジェクトの集合からあらかじめ指定された数のオブジェクトを疑似乱数的に選択するための様々な周知のアルゴリズムのいずれを使用してもよい。プロセス５０には、選択されたＭＧＷの中からＭＧＷ自体とソース・ノードの間のベアラ・トラフィックに関するエンドツーエンドの輻輳が最小となるＭＧＷ（１つ）を識別するステップ（ステップ５４）が含まれる。選択のステップ５４には、例えばルーティング・テーブル内の選択されたＭＧＷのエンドツーエンドの輻輳を表す測定されたプロパティをルックアップ（ｌｏｏｋｉｎｇ ｕｐ）するステップと、選択されたＭＧＷの中からエンドツーエンドの輻輳のエントリが最小となるＭＧＷ（１つ）を識別するステップとが含まれる。また、プロセス５０には、選択されたＭＧＷの中から識別された１つのＭＧＷを割り当てることによって、要求されたＭＣＳをパケット・ネットワーク１２と宛て先ＴＤＭネットワーク１４の間で接続するステップ（ステップ５６）も含まれる。プロセス５０は、ルーティング・テーブルのエントリがあまり頻繁に更新されない場合でも、依然としてソース・ノードと候補となるＭＧＷのセットに含まれるＭＧＷの間でエンドツーエンドの輻輳を等化する傾向を維持できる。

図７を参照すると、要求されたＭＣＳに割り当てるＭＧＷを選択するための第４のプロセス６０は、ソース・ノードと候補となるＭＧＷのセットに含まれるＭＧＷの間のベアラ・トラフィックのエンドツーエンドの輻輳を等化する傾向があると同時に、ソース・ノードと候補となる様々なＭＧＷの間のエンドツーエンドの輻輳の振動を縮小している。プロセス６０には、候補となるｋ番目のＭＧＷが選択される確率ｑ（ｋ）が割り当てられる統計的な選択プロセスによって、候補となるＭＧＷの中から１つのＭＧＷを選択するステップ（ステップ６２）が含まれる。割り当てられた選択の確率のセット｛ｑ（ｋ）｝は、Σ^Ｎ _ｋ＝１ｑ（ｋ）＝１（ただし、「Ｎ」は候補となるＭＧＷの数）を満たしている。また、プロセス６０には、候補となるＭＧＷの選択された１つを割り当てることによって、パケット・ネットワーク１２とＭＣＳのベアラ・トラフィックのためのＴＤＭネットワーク１４との間の接続を提供するステップ（ステップ６４）も含まれる。プロセス６０がルーティングに関する決定に使用された場合は、時間の経過に伴い、要求されたＭＣＳのベアラ・トラフィックは、ソース・ノードと候補となる様々なＭＧＷの間のエンドツーエンドの輻輳を徐々に等化する傾向があると期待される。

図８を参照すると、プロセス６０には、ルーティング・テーブルが更新されるたびに、ソース・ノードと候補となるＭＧＷのペアに関連付けられた選択の確率、すなわちｑ（ｊ）の割り当てを更新するプロセス７０を実行するステップが含まれる。

プロセス７０では、アクティブなペアは非アクティブなペアと区別されている。ソース・ノードと候補となるＭＧＷのペアｋは、これに割り当てられる選択の確率ｑ（ｋ）がゼロでない場合にアクティブである。それ以外の場合に、ソース・ノードと候補となるＭＧＷのペアは非アクティブである。プロセス７０において、すべてのペアが最初はアクティブである。

更新を行う間に、プロセス７０には、非アクティブなペアがベアラ・トラフィックに関するエンドツーエンドの平均の輻輳Ｄ（ｋ）を有する場合、すなわち_κＥ［Ｄ］より小さい場合に、そのペアをアクティブにするステップが含まれる。ここで、κは範囲（０，１］内であらかじめ選択された数値であり、Ｅ［Ｄ］はアクティブなパスに関するエンドツーエンドの輻輳の平均である。こうした平均は、例えば、エンドツーエンドの輻輳がＭＣＳのＱｏＳ要件をサポートするペアの平均でもよい。非アクティブなペアをアクティブにするステップの後で、プロセス７０には新しいアクティブなペアを考慮に入れるようにＥ［Ｄ］を更新するステップが含まれる。

プロセス７０では、さらに、ペアのソース・ノードとＭＧＷの間のベアラ・トラフィックに関するエンドツーエンドの輻輳に基づいて、アクティブな各ペアを負荷が過大と負荷が過小のいずれかに分類する（ステップ７２）。ステップ７２で、アクティブなペアを負荷が過小のペアのグループと負荷が過大のペアのグループに分割する。負荷が過小のペアとは、例えば、ベアラ・トラフィックがＥ（Ｄ）より低いエンドツーエンドの輻輳すなわちＤ（ｒ）を有するアクティブなソース・ノードと候補となるＭＧＷのペア「ｒ」である。負荷が過大のペアとは、例えば、ベアラ・トラフィックがＥ（Ｄ）以上のエンドツーエンドの輻輳すなわちＤ（ｓ）を有するアクティブなソース・ノードと候補となるＭＧＷのペア「ｓ」である。

更新のプロセス７０には、負荷が過大のペアに対応する候補となる各ＭＧＷに割り当てられた選択の確率、すなわちｑ（ｓ）を低下させるステップ（ステップ７４）が含まれる。こうした「ｑ（ｓ）」は、ｑ（ｓ）←ｑ（ｓ）−ω（ｓ）のように置き換えることによって低下される。ここで、ω（ｓ）はオリジナルのｑ（ｓ）の最小値であり、あらかじめ適切に選択され正の定数値をδとした場合は、［δ・（Ｄ（ｓ）−Ｅ（Ｄ））／Ｅ（Ｄ）］である。前述の置き換えにより、得られる確率ｑ（ｓ）があらかじめ選択された正の小さい数εを下回る場合は、プロセス７０には、対応するペアｓを非アクティブにするステップと、調整ω（ｓ）←ω（ｓ）＋ｑ（ｓ）およびｑ（ｓ）←０をするステップも含まれる。負荷が過大のペア「ｓ」のすべてが考慮されると、ΩはΣ_ｓω（ｓ）にセットされる。

また、更新のプロセス７０には、負荷が過小のペアに対応する候補となる各ＭＧＷに割り当てられた選択の確率、すなわちｑ（ｒ）を向上させるステップ（ステップ７６）も含まれる。こうした「ｑ（ｒ）」は、ｑ（ｒ）←ｑ（ｒ）＋η（ｒ）のように置き換えることによって増加する。ここで、η（ｒ）はΩ（Ｅ（Ｄ）−Ｄ（ｒ））／［Σ_{ｐ＝１．．．Ｎ}（Ｅ（Ｄ）−Ｄ（ｐ））］によって定義できる正の数である。ただし、合計はアクティブなソース・ノードと候補となるＭＧＷのペアｐのすべてについて合計する。

丸め誤差を補正するために、プロセス７０には、選択の確率を調整し、それぞれを更新した後に強制的にΣ_ｋｑ（ｋ）＝１にするステップも含めることもできる。ただし、合計はアクティブなソース・ノードと候補となるＭＧＷのペアｋのすべてについて合計する。

図９を参照すると、要求されたＭＣＳにＭＧＷを選択し、割り当てる第５のプロセス８０は、ＭＧＷを選択し、割り当てる前述のプロセス３０、４０、５０、および６０の中から複数を組み合わせる。プロセス８０には、確率的なアルゴリズムを使用してこうしたプロセスの固定のセット中から１つのＭＧＷを選択し、割り当てる１つのプロセスを選択するステップ（ステップ８２）が含まれる。例えば、固定のセットには、図６に示すプロセス５０と図７に示すプロセス６０を含めることができる。確率的なアルゴリズムにおいて、各プロセス、すなわち３０、４０、５０、または６０を選択する確率は、ルーティング・テーブルが最後に更新されてからの経過時間によって変わる。例えば、固定のセットが前述のプロセス５０と６０で構成される場合に、ステップ８２はプロセス５０の確率としてｅｘｐ（−ｔ／β）を選択し、プロセス６０の確率として［１−ｅｘｐ（−ｔ／β）］を選択することができる。ここで、「ｔ」はルーティング・テーブルが最後に更新されてからの経過時間であり、「β」はあらかじめ選択された適切な正の定数値である。さらに、プロセス８０には、選択された１つのＭＧＷの選択と割り当てのプロセスに従ってＭＧＷの選択と割り当てを実行するステップ（ステップ８４）が含まれる。プロセス８０では、ＭＧＷの選択および割り当てスキームの過度の選択、例えば、少ない数の候補となるＭＧＷのみが利用可能な場合にプロセス５０の過度の選択を軽減することができる。

図１０は、図１に示すインテリジェントＢＧＣＦ９０の例示的なアーキテクチャを概略的に示している。

例示的なインテリジェントＢＧＣＦには、ＢＧＣＦアプリケーション９０と関連のＳＩＰコアが含まれる。ＢＧＣＦアプリケーション９０は、Ｓ−ＣＳＣＦからのＳＩＰ ＩＮＶＩＴＥ要求（例えば、新しいＶｏＩＰコールのセットアップ要求）の処理を担当する。ＢＧＣＦアプリケーションは、ＳＩＰコアによってレイヤに分けられる。ＳＩＰコアは、ＳＩＰメッセージを受信し、ＳＩＰトランザクションを処理し、さらにプロキシ・サービスを提供する。ＢＧＣＦアプリケーション９０は、ＳＩＰ ＩＮＶＩＴＥ要求が到着するたびに応答してＳＩＰコアのプロキシ・レイヤによって通知される。ＢＧＣＦは、ルート・データベース９４に配置されたルーティング・テーブルに基づいて、例えば前述の図３Ａ〜３Ｂの方法２０Ａ〜２０Ｂで説明するように、要求されたＭＣＳに割り当てるＭＧＷを選択する。ＢＧＣＦは、ルーティング・テーブルで経路のルックアップを行い、ターゲット・セットを作成してＳＩＰコアに戻る。各ターゲット・セットは、対応するＭＧＷのためのＭＧＣＦのＳＩＰ ＵＲＬのリストである。ＢＧＣＦは、通常は選択されたＭＧＷまたはＭＧＣＦの実際のＩＰアドレスを認識していない。ＳＩＰコアは、ＭＧＣＦの１つがＳＩＰ ＩＮＶＩＴＥを受信するまで、ＳＩＰ ＩＮＶＩＴＥメッセージをターゲット・セットに含まれる各ＭＧＣＦに連続的に送信する。

例示的なインテリジェントＢＧＣＦには、ルーティング・テーブル（例えば、図２に示すルーティング・テーブル１６）を備えるルート・データベース９２も含まれている。ルート・データベース９２により、新しいルート・エントリをルーティング・テーブルに外部的に追加することができる。

インテリジェントＢＧＣＦには、測定サーバ９４も含まれている。測定サーバ９４は、前述のインテリジェント・ルーティング・プロセスに使用するプラットフォームでもよい。測定サーバ９４は、ＩＰおよび／またはＭＰＬＳパケット・ネットワークのベアラ・トラフィックに関する測定値を使用してルーティング・テーブルのエントリを更新する。ベアラ・トラフィック・レベルの測定値は、ＩＰおよび／またはＭＰＬＳコア・データ・アーキテクチャのプローブ・コレクタまたはローカル・アグリゲータから取得できる。測定サーバ９４は、タイマー、ソケットおよびイベント・ループ管理、および組み込みＷｅｂサーバを提供するアプリケーション・フレームワークの最も上のレイヤでもよい。Ｗｅｂサーバは、データをアップロードまたはダウンロードでき、認証スキームに基づいて測定サーバ９４を監視または設定できる。測定サーバ９４は、通常はＩＰおよび／またはＭＰＬＳ測定インフラストラクチャと通信するための測定アプリケーション・インターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｉｎｔｅｒｆａｃｅ）を備えている。測定ＡＰＩは、例えば、ＩＰ／ＭＰＬＳアーキテクチャの入力ノードと出力ノードの間で現在測定されているＱｏＳを提供するパスのＱｏＳ行列を取得できる。一般的な測定ＡＰＩにより、測定サーバは様々なタイプのＩＰおよび／またはＭＰＬＳ測定システムと対話することができる。

前述の開示、図面、および特許請求の範囲による、他の実施形態は当業者には明らかになることになる。

インターネット・プロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）またはマルチプロトコル・ラベル交換（ＭＰＬＳ：Ｍｕｌｔｉｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）コア・パケット・ネットワークで使用するＩＭＳアーキテクチャを簡略化して示すブロック図である。 例えば図１に示すネットワーク内で、いくつかのマルチメディア通信セッション（ＭＣＳ：ｍｕｌｔｉｍｅｄｉａ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｅｓｓｉｏｎｓ）をセットアップする要求に応答して、許可およびルーティングに関する決定を行うために使用できるルーティング・テーブルの一部を示す図である。 パケット・ネットワークとＴＤＭネットワークの間でＭＣＳをセットアップする要求に応答して、許可およびルーティングに関する決定を行う方法を示す流れ図である。 図３Ａに示す方法であって、例えば図１に示すコア・パケット・ネットワークのように、パケット・ネットワークはＩＭＳアーキテクチャをサポートする方法の特定の実施形態を示す流れ図である。 ソース・ノードと候補となるＭＧＷのセットの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を等化する傾向のある動的なＭＣＳルーティング・プロセスを示す流れ図である。 ソース・ノードと適切なサービスの品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）を保持できる候補となるＭＧＷのサブセットの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を等化する傾向のある動的なＭＣＳルーティング・プロセスを示す流れ図である。 ルーティング・テーブルの更新頻度が低下した場合でも、ソース・ノードと候補となるＭＧＷのセットの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を等化する傾向を維持できる動的なＭＣＳルーティング・プロセスを示す流れ図である。 ソース・ノードと候補となるＭＧＷのセットの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を、長期間にわたって等化する傾向のある動的なＭＣＳルーティング・プロセスを示す流れ図である。 図７に示すプロセスで使用するルーティングの確率を、ベアラ・トラフィックに関するエンドツーエンドの輻輳が通常は長期間にわたって等化される傾向があるように更新するプロセスを示す流れ図である。 図６のルーティング・プロセスを適用するか図７のルーティング・プロセスを適用するかを動的に選択するＭＣＳルーティング・プロセスを示す流れ図である。 図１および３Ｂに示すインテリジェントＢＧＣＦの例示的な構成を示すブロック図である。

Claims (10)

1. パケット・ネットワークと時分割多重ネットワークの間でマルチメディア通信セッションを接続する複数の候補となるゲートウェイの中から１つを選択するステップであって、前記パケット・ネットワークは前記マルチメディア通信セッションのソース・ノードまたは入力ノードを備えており、前記時分割多重ネットワークは前記マルチメディア通信セッションの宛て先を備えており、前記候補となるゲートウェイは前記パケット・ネットワークと前記時分割多重ネットワークを相互接続する、選択するステップを備えており、
   前記選択するステップは、前記ソース・ノードと前記複数の様々な候補となるゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を比較するステップを含む方法。
2. 前記時分割多重ネットワークは公衆交換電話網であり、前記パケット・ネットワークはＭＰＬＳネットワークである請求項１に記載の方法。
3. 前記パケット・ネットワークはＩＰマルチメディア・サブシステムをサポートする請求項１に記載の方法。
4. 前記マルチメディア通信セッションはボイス・オーバー・アイピー（ＶｏＩＰ）コールである請求項１に記載の方法。
5. 前記選択するステップは、前記ソース・ノードと前記候補となるゲートウェイの１つまたは複数との間のエンドツーエンドの輻輳が前記マルチメディア通信セッションによって要求されるサービスの品質に関するあらかじめ選択されたしきい値を下回ることの確認に応答して、前記マルチメディア通信セッションを許可するステップを含む請求項１に記載の方法。
6. 前記選択するステップは、ルーティング・テーブルのエントリを検索するステップをさらに備えており、各エントリは前記ソース・ノードと前記各エントリに対応する候補となるゲートウェイの間のエンドツーエンドの輻輳を提供する請求項１に記載の方法。
7. 方法のステップを実行するマシンで実行可能な命令プログラムを格納するサーバまたはルータであって、前記ステップは、
   パケット・ネットワークと時分割多重ネットワークの間で要求されたＶｏＩＰコールを接続する複数の候補となるメディア・ゲートウェイの中から１つを選択するステップであって、前記パケット・ネットワークは前記ＶｏＩＰコールのソース・ノードを備えており、前記時分割多重ネットワークはＶｏＩＰコールの宛て先を備えており、前記候補となるメディア・ゲートウェイは前記パケット・ネットワークと前記時分割多重ネットワークを相互接続するステップを備えており、
   前記選択するステップは前記ソース・ノードと前記複数の候補となるゲートウェイの中の第１と第２のゲートウェイの間のベアラ・トラフィックに関するエンドツーエンドの輻輳を比較するステップを備えており、
   前記サーバまたはルータは、前記パケット・ネットワーク内に配置され、ＳＩＰをサポートするサーバまたはルータ。
8. 前記選択するステップを実行する命令は、前記ソース・ノードと前記候補となるゲートウェイの１つまたは複数との間のエンドツーエンドの輻輳が前記ＶｏＩＰコールによって要求されるサービスの品質に関してあらかじめ選択されたしきい値を下回ることの確認に応答して、前記要求されたＶｏＩＰを許可する命令を含む請求項７に記載のサーバまたはルータ。
9. 前記選択するステップは、
   ルーティング・テーブルのエントリを検索するステップであって、各エントリは前記ソース・ノードと前記各エントリに対応する候補となるゲートウェイの間の前記エンドツーエンドの輻輳を提示する、検索するステップをさらに備えており、
   前記選択するステップは、前記検索されたエントリに対応する前記候補となるゲートウェイの中で前記候補となるゲートウェイの１つのエンドツーエンドの輻輳が最低となるのに応答して、前記候補となるゲートウェイの１つを選択する請求項７に記載のサーバまたはルータ。
10. 前記選択するステップは、
    前記候補となるゲートウェイの中から適切なサブセットをランダムに選択するステップと、
    次に、前記適切なサブセットの中から前記ソース・ノードとのベアラ・トラフィックに関するエンドツーエンドの輻輳が最低となる前記候補となるゲートウェイの１つを選択するステップとをさらに備える請求項７に記載のサーバまたはルータ。

Images