JP4390498B2 - セッション承認制御を与えるためのシステム及び方法 - Google Patents

Description

今日使用される殆どのネットワークは、パケットと称される小単位のデータの経路指定（ルーティング）を、パケットによって特定される宛先アドレスに基づいて可能にする。実際に、非同期転送モード（ＡＴＭ）、フレームリレー、インターネットプロトコル等といったパケット送信技術を使用するパケットデータネットワークによる通信は、好ましいデータ送信方法となってきている。データ通信を複数のパケットに分割することにより、１つのデータ経路を同じネットワーク内の複数のユーザ間で共有することができる。

企業ネットワークや公衆データネットワーク等の異なるネットワーク間のインタフェースは、一般に、後述する制約されたリソースを有している。インタフェースの例としては、Ｔ１／Ｔ３接続、デジタル加入者線（ＤＳＬ）、または、ケーブルモデムタイプ接続が挙げられるが、これらに限定されない。前述したインタフェースの容量は、ネットワーク内の容量よりも十分に小さい。一例として、企業ネットワーク内では高速イーサネットを使用することが一般的である。この場合、高速イーサネットは、最大で毎秒約１００メガビット（１００Ｍｂｐｓ）のデータ転送速度をサポートする。しかしながら、企業ネットワークと公衆データネットワークとの間のインタフェースは、最大で約１．５Ｍｂｐｓのデータ転送速度をサポートするＴ１接続かもしれない。残念ながら、Ｔ１接続の最大データ転送速度は、企業ネットワークの最大データ転送速度の１．５％である。したがって、企業ネットワークから送信されるパケットは、キュー（待ち行列）に入れられ、制約されたインタフェースへの入力を待っている間にパケットとしてのタイムアウト時間が経過すると、最終的に処分される。

パケット処理の制約に起因して、パケットフローのサービスの質（ＱｏＳ）の問題が発生する。当業者であれば分かるように、ＱｏＳは、保証されたパケットスループットレベルを特定するネットワーキング用語である。一般に、パケットは、待ち行列に入れられると短時間で失われるため、特定のパケットフローまたは宛先において特定のスループットレベルを保証することは難しい。

また、公衆データネットワーク間のピアリングポイントは、一般に、ギガビットイーサネット接続、光キャリアスリー（ＯＣ３）接続、または、ＯＣ１２接続である制約されたインタフェースを有している。幸いにも、殆どのネットワーク使用は、パケットロス及び／またはパケット遅れに対して寛容である。

多くの新規なタイプのピアツーピア通信は、リアルタイム通信を必要としている。一例として、これらに限定されないがＹａｈｏｏ（登録商標）、ＭＳＮ（登録商標）、ＡＯＬ（登録商標）等の会社からのインスタント・メッセージは、ユーザ同士がほぼリアルタイムで話せ且つ見られるオプションを含んでいる。インターネット上での音声通信（ＶｏＩＰ）は、リアルタイム通信要求を提供するが、これは、ＶｏＩＰがパケットのリアルタイムフローを必要とするためである。具体的には、ＶｏＩＰは、公衆交換電話網（ＰＳＴＮ）の従来の回線によるプロトコルではなく、離散的なパケットでデジタル音声情報を送信する。米国のマサチューセッツ州のウエストフォードにあるソナス（Ｓｏｎｕｓ）ネットワークスのＧＳＸ−９０００等の媒体ゲートウェイは、リアルタイム媒体フローのソースである。多くの他のタイプの帯域幅サービスは、プロセス制御のためのエンドユーザ要求及び他の個人的な使用に基づくビットレートに関与してきた。

したがって、リアルタイム通信が必要であるため、異なるネットワーク間の一般的なインタフェースによって導入される制約されたリソースを軽減することが望ましい。リアルタイム通信を必要とするネットワークの一例が図１に示されている。図１は、公衆データネットワーク（ＰＤＮ）集約点内に設けられたポイント・オブ・プレゼンス（ＰＯＰ）（以下、ＰＤＮ ＰＯＰと称する。）と、第１の集約領域１１２と、第２の集約領域１５２との間の従来の通信レイアウトのブロック図である。なお、他のネットワーク１０３をＰＤＮ ＰＯＰ １０２に接続しても良い。当業者であれば分かるように、領域は、ネットワーク装置を含むネットワークの一部である。領域の例は、プライベートネットワーク、企業等を含んでいても良い。

図１に示されるように、ＰＤＮ ＰＯＰ １０２はエッジルータ１０４を有している。このエッジルータ１０４は、エッジルータ１０４の下流側に設けられ且つＰＤＮ ＰＯＰ １０２とは別個の第１の集約領域１１２と第２の集約領域１５２との間でデータを経路指定する。エッジルータの例としては、米国のカリフォルニア州のサンノゼにあるシスコシステムズ社（Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ）によって製造されるＣｉｓｃｏ ７５ｘｘ、Ｃｉｓｃｏ １０ｘｘｘ、Ｃｉｓｃｏ １２ｘｘｘが挙げられるが、これらに限定されない。

また、ＰＤＮ ＰＯＰ １０２は、好ましくは２層集約装置である第１の集約装置１４８を有している。この集約装置の一例は、米国のニュージャージー州のマリーヒルにあるルーセントテクノロジー社（Ｌｕｃｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ）によって製造されたＬｕｃｅｎｔ ＣＢＸ５００等の集約スイッチであっても良い。第１の集約装置１４８は、第１の集約領域１１２内に設けられた第１の企業１２１と、第２の企業１３１と、第３の企業１４１との間での通信を可能にする。また、エッジルータ１０４を使用することにより、第１の集約装置１４８は、第１の集約領域１１２と第２の集約領域１５２との間での通信を可能にする。

また、好ましくは２層集約装置である第２の集約装置１８２も、ＰＤＮ ＰＯＰ １０２内に設けられている。第２の集約装置１８２は、第２の集約領域１５２内に設けられた第１の企業１６１と第２の企業１７１との間での通信を可能にする。また、エッジルータ１０４を使用することにより、第２の集約装置１８２は、第１の集約装置１５２と第２の集約装置１１２との間での通信を可能にする。

第１の集約領域１１２は、第１の企業１２１と、第２の企業１３１と、第３の企業１４１とを含んでいる。第１の企業１２１は、第１のアクセスルータ１２２と、第１のプライベートデータネットワーク１２４と、ユーザが使用する第１のコンピュータ１２６とを有している。第２の企業１３１は、第２のアクセスルータ１３２と、第２のプライベートデータネットワーク１３４と、ユーザが使用する第２のコンピュータ１３６とを有している。第３の企業１４１は、第３のアクセスルータ１４２と、第３のプライベートデータネットワーク１４４と、ユーザが使用する第２のコンピュータ１４６とを有している。企業１２１，１３１，１４１内に設けられた各アクセスルータ１２２，１３２，１４２は、コンピュータ１２６，１３６，１４６をＰＤＮ ＰＯＰ １０２に接続する。ＰＤＮ ＰＯＰ １０２によって利用可能にされたネットワークサービスのユーザは、ＰＤＮ ＰＯＰ １０２内から、あるいは、ＰＤＮ ＰＯＰ １０２の外部から、ＰＤＮ ＰＯＰ １０２に接続できる。図１には、第４のコンピュータ１７２が示されている。この第４のコンピュータによっても、ユーザは、ＰＤＮ ＰＯＰ １０２の外部からＰＤＮ ＰＯＰ １０２に対して直接にアクセスできる。

各アクセスルータ１２２，１３２，１４２は、プライベートデータネットワーク１２４，１３４，１４４のうちの１つに接続する。一例として、第１のアクセスルータ１２２は、第１のプライベートデータネットワーク１２４に接続する。また、各アクセスルータ１２２，１３２，１４２は、コンピュータ１２６，１３６，１４６を介したユーザと第１の集約領域１１２の他の部分との間の通信を可能にする。

第２の集約領域１５２は、第１の企業１６１と第２の企業１７１とを含んでいる。第２の集約領域１５２内に設けられた第１の企業１６１は、第１のモデム１６２と、ユーザが使用する第１のコンピュータ１６４とを有している。第２の集約領域１５２内に設けられた第２の企業１７１は、第２のモデム１７２と、ユーザが使用する第２のコンピュータ１７４とを有している。第１のモデム１６２及び第２のモデム１７２は、デジタル加入者線（ＤＳＬ）または他の種類のモデムであっても良い。

ＰＤＮ ＰＯＰ １０２の様々な部分を接続するリンクは、パケットを待ち行列に入れさせる制約を形成しても良い。以下は、ＰＤＮ ＰＯＰ １０２内の考えられるリンク特性の一例を与えている。例えばインターネットバックボーンルータ（図示せず）等のＰＤＮ ＰＯＰ １０２内の装置に対してエッジルータ１０４を接続するコアネットワークアクセスリンクは、毎秒約２．５ギガビット（Ｇｐｓ）で動作するＯＣ４８で動作しても良く、あるいは、約１０Ｇｐｓで動作するＯＣ１９２で動作しても良い。エッジルータ１０４は、第１の集約領域１１２内に設けられた第１の集約装置１４８と第２の集約領域１５２内に設けられた第２の集約装置１８２との間で通信を分ける。エッジルータ１０４と集約装置１４８，１８２との間の通信ラインは、一般に、同期光ネットワーク７（ＳＯＮＥＴ 7）またはソネット２０（ＳＯＮＥＴ ２０）上でパケットにより動作する。

集約装置１４８，１８２は、例えばＴ１またはＴ３上でのフレームリレー、Ｔ３上での非同期転送モード（ＡＴＭ）、高速シリアルインタフェース（ＨＳＳＩ）及び／またはＤＳＬ上でのポイント・ツー・ポイントプロトコル（ＰＰＰ）を含む低速接続までデータ送信速度を下げる。アクセスルータ１２２，１３２，１４２及びモデム１６２，１７２は、集約装置１４８，１８２からのリンクを終了させ、帯域幅フローを１０／１００イーサネットに変換する。したがって、最も遅いリンクは、集約装置１４８，１８２とアクセスルータ１２２，１３２，１４２またはモデム１６２，１７２との間である。

エッジルータ１０４は、下流の帯域幅の混雑状態を知ることがない。エッジルータは、ＰＤＮ ＰＯＰ １０２内で各論理的終点毎にキュー（待ち行列）を形成するようにプログラムされ、これによって、実際の下流側の送信容量に基づいて重み付けられた公正なパケットの分配を可能にしても良い。エッジルータの重み付け公正分配キューイングは、多数の理由により、帯域幅の混雑状態に対応するために現在使用されていない。前記多数の理由としては、エッジルータの性能の劣化や、計画するためには潜在的に複雑である提供機構を含むが、これらに限定されない。

公正なパケットの分配が重み付けられた後に帯域幅の混雑状態に対応するためには、一般に、どのパケットがリアルタイム要求に関連付けられているかを認識することにより、エッジルータ及びアクセスルータによってパケットを順序付けて、パケットのキューイング（待ち行列入れ）及び処分を防止できると考えられている。残念ながら、どのパケットがリアルタイムパケトであるかを識別するための技術は、高価なパケット分類集積回路及び構成を必要とする。したがって、殆どの既存のエッジルータ及びアクセスルータを更新し或は交換する必要がある。

また、リアルタイムパケットが識別されると、リアルタイムパケットを予期される量のパケットに関連付けて帯域幅確保すなわち帯域幅割り当てを行なうことが難しい。リアルタイムパケットの関連付けの困難性に取り組むためには、一般に、リソース指定セットアッププロトコル（ＲＳＶＰ）装置を使用して、帯域幅を要求するとともに、エッジルータでＲＳＶＰ要求の送信を要求する。当業者であれば分かるように、ＲＳＶＰは、１または複数のパケットルータから成るルート指定された経路に沿ってソースから宛先までリソースをソフトウェアアプリケーションによって確保できるプロトコルである。その後、ＲＳＶＰ使用可能ルータは、ＱｏＳ要求を満たすように形成され且つパケットに優先順位を付けても良い。ＲＳＶＰは、帯域幅要求を、その多くが企業・ファイアウォールによって再利用される宛先ＩＰアドレスに関連付ける。したがって、リアルタイムフローを標準的なフローに取って代えることができる。しかしながら、リアルタイムフローにおける帯域幅の割り当ては、ＲＳＶＰタイムアウトまで有効である。

ＲＳＶＰ及びパケット分類を共に使用すると、企業から送信されるフローの容量が向上する。しかしながら、現在、エッジルータの外側に由来するリアルタイムフローにおいて、ＲＳＶＰ要求をエッジルータで挿入するメカニズムはない。なお、これに限らないがセッション開始プロトコル（ＳＩＰ）等の幾つかの信号システムにおいて、実際の宛先アドレスは、帯域幅確保を行なうことが必要な時点で分かっていなくても良い。

残念ながら、個々のパケットを単に観察することによってフローの開始を識別することは難しいため、エッジルータによってパケットのフローを識別して特徴付けることは難しい。また、フローの終端を特徴付けることも同様に難しい。困難を高めることに、多くのリアルタイムフローは、サイレンスの持続時間中に停止し且つデータパケットを送信するエネルギがある時に再び開始するパケットフローによって規定される、サイレンス圧縮を利用する。パケットフローの進行におけるこの一貫性のなさにより、フローの開始を識別することが困難になる。

ネットワークのエッジでの帯域幅管理は、セッション確立のための工業規格信号メカニズムであるＳＩＰを使用することにより研究されてきた。２００１年１０月に発行され且つｄｒａｆｔ−ｖｅｌｔｒｉ−ｓｉｐ−ｑｓｉｐ−００.ｔｘｔというファイル名を有するベルトリ・ルカ（Ｖｅｌｔｒｉ Ｌｕｃａ）による「ディフサーブ（Ｄｉｆｆｓｅｒｖ）ネットワークにおけるＱｏＳサポートのためのＳＩＰ拡張子」と題されたインターネット文書は、ＳＩＰ拡張子を使用して、エッジルータを管理して提供することを教示している。エッジルータを管理して提供するために、ＳＩＰプロキシは、どのエッジルータが入ってきて、どのエッジルータが管理ドメインから出ていったかを判断して、パケットフローのための共通オープン・ポリシー・サービス（ＣＯＰＳ）を基本とするポリシーを管理できるようにする。当業者であれば分かるように、ＣＯＰＳは、ポリシー・デシジョン・ポイント（ＰＤＰ）からポリシー・エンフォースメント・ポイント（ＰＥＰ）へ送信するために使用されるプロトコルである。残念ながら、どのエッジルータが入ってきて、どのエッジルータが出ていったかを決定することを含む質の測定は無く、また、フロー割り込み検出も無い。

同様に、２００２年２月に発行され且つｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｃａｌｌ−ａｕｔｈ−０４．ｔｘｔというファイル名を有するディー・エバンズ（Ｄ．Ｅｖａｎｓ）等による媒体「認証のためのＳＩＰ拡張子」と題されたインターネット文書は、ＰＤＰから分配されたトークンを使用して、エッジルータにおけるネットワークに対してＱｏＳに基づく認証を行なうことができるようにすることを記載している。残念ながら、トークンは、ネットワーク内に設けられた集約装置の下流側にあっても良い発生領域に基づく質の測定を含んでいない。また、ポリシーを基本とする承認は、下流側の制限を反映しなくても良いエッジルータ内で与えられたリソースに基づいて行なわれる。

２００１年１１月に発行され且つｄｒａｆｔ−ｂｉａｎｃｈｉ−ｂｌｅｆａｒｉ−ｅｎｄ−ｔｏ−ｅｎｄ−ｑｏｓ−０２．ｔｘｔというファイル名を有するジー・ビアンキ（Ｇ．Ｂｉａｎｃｈｉ）による「厳密に駆動される認証制御の手段によって無国籍ネットワーク上でのエンドツーエンドＱｏＳを与える移動経路」と題されたインターネット文書は、ネットワーク内でパケットフローを認証する前にパケットフローの質を判断するための技術を記述している。質の判断は、パケットフローの実際の宛先の近傍に設けられた宛先試験点に対してパケットのバーストをプローブとして送信するソースにより与えられる。このパケットのバーストは、別個のマルチメディアフローが形成するものと同様である。宛先試験点から戻されたパケットの性能を解析することにより、別個のマルチメディアフローについて予想することができる。ソースは、パケットのバーストを宛先試験点に送り、その後、試験点は、パケットのバーストをソースに戻す。その後、プローブのソースは、バーストからのジター、パケットロス、待ち時間を測定する。当業者であれば分かるように、ジターは、フローにおけるパケット間のギャップの変化の測定値である。他の定義付けとして、ジターは、マルチメディアフローにおける待ち時間の変化である。

パケットのバーストは、宛先に対して承認を要求するパケットフローに類似するように意図される。したがって、パケットフローが例えばＧ．７１１フローである場合、パケットのバーストは、パケットフローがＧ．７１１フローであることを反映する。発信側がパケットフローの質を測定すると、宛先に対するパケットの承認が再開しても良い。この技術に伴う１つの問題点は、送信前にパケットフローを知るために宛先アドレスが必要になるという点である。多くの信号プロトコルは、経路指定可能であり、あるいは、複数のプロキシ及びゲートウェイにわたって移動する。それは、しばしば、信号発信によってパケットフローのセットアップがうまくいくまでアドレスが分からないといった場合である。残念ながら、パケットフローのセットアップがうまくいくまで待つことがあまりにも遅いため、パケットフローが宛先を呼び起こしたり知らせたりすることを防止できない。したがって、信号システムは、帯域幅経路が割り当てられる前に、通信セッションの到達を告げる。

ジー・ビアンキによって教示された技術に伴う更に他の欠点は、割り当てられた経路上で帯域幅の質を知る際の望ましくない遅れを含んでいる。この遅れは、数百ミリ秒の長さであるかもしれない。この遅れは、１つの宛先が試験されている場合に許容できる場合があるが、複数の宛先が存在する場合、すなわち、マルチネットワーク構成にわたって試験が複数回（各ネットワークに１回）行なわれる場合には、この遅れはリアルタイム通信にはあまりにも大き過ぎる。

２００２年２月に発行され且つｄｒａｆｔ−ｉｅｔｆ−ｒａｐ−ｒｓｖｐ−ａｕｔｈｅｓｓｉｏｎ−０２．ｔｘｔというファイル名を有するハマー（Ｈａｍｅｒ）らによる「ＲＳＶＰのためのセッション認証」と題された他のインターネット文書は、セッション承認制御のためのＲＳＶＰ認証要素を開示している。この要素を使用して、ＲＳＶＰをサポートするエッジルータから帯域幅を要求することができる。現在、エッジルータは、１フローずつを基本とする質の測定を行なうことができないため、ＲＳＶＰ認証要素において、最低限必要な質を基本とする承認制御は存在しない。また、勧告であっても良いような下流側の集約制限のためのサポートは存在しない。また、ＲＳＶＰ認証要素はＩＰアドレスに基づいている。プロトコル及びポート領域は強制的なＲＳＶＰ領域ではないため、ソース及び宛先ＩＰアドレスがたとえ供給された場合であっても、ＲＳＶＰ認証要素は、同じネットワークポイントから到達するリアルタイム転送プロトコル（ＲＴＰ）フローとファイル転送プロトコル（ＦＴＰ）フローとを区別することができない。したがって、ＲＳＶＰ要素がプロトコル及びセッションに気付くまで、マルチメディアセッションがＲＳＶＰ承認要素によってサポートされない場合がある。

２０００年１月に発行されたヤバトカー（Ｙａｖａｔｋａｒ）等による「ポリシーに基づく承認制御のためのフレームワーク」と題されたインターネット文書は、ＲＳＶＰ認証要素を開示している。このインターネット文書は、承認制御決定にわたってポリシーに基づく制御を与えるためにフレームワークを特定することに関するものである。残念ながら、ヤバトカーらによるインターネット文書は、１フローずつの送信承認及び質に基づく承認を開示していない。

２００２年２月に発行され且つｄｒａｆｔ−ｒａｗｌｉｎｓ−ａｄｍｃｔｌ−ｄｓ−ｍｇｔ−０２．ｔｘｔというファイル名を有するラウリンズ（Ｒａｗｌｉｎｓ）等による「クラスに基づくリソース管理を用いたエッジを基本とする承認制御」と題されたＲＳＶＰインターネット文書は、インターネット（Ｉｎｔｓｅｒｖ）クラスモデルにわたる一体的なサービスによって割り当てられる帯域幅の上流側のプールを記述している。残念ながら、リアルタイム承認制御において、質の測定が使用されていない。また、帯域幅の確保は、下流側の制限ではなく、上流側の制限に基づいている。

２０００年５月に発行されたヤバトカー等らによる「ＩＥＥＥ８０２型ネットワーク上でのＲＳＶＰに基づく承認制御のためのプロトコル」と題されたインターネット文書は、サブネット帯域幅管理プロトコルを記述している。このプロトコルは、ＬＡＮとＲＳＶＰに基づく３層ルーティングネットワークとの間にマネージャを挿入するための信号メカニズムである。しかしながら、このインターネット文書は、実際に観察された質に基づいて、または、集約リンクのネスト化された層に基づいて承認制御を行なうためのメカニズムを含んでいない。

米国のマサチューセッツ州のウォルサムにあるシタラ（Ｓｉｔａｒａ）ネットワークは、ディープパケット解析を行なって企業ネットワークにおけるＶｏＩＰのサポートを支援する製品を製造している。その製品の一例は、ＱｏＳアレイ（ＱｏＳＡｒｒａｙ）（登録商標）である。ＱｏＳアレイ製品は、ハイタッチパケット処理及び分類を、８０２．１ｐ等の２層質スキーム及び８０２．１ｑ等の仮想ＬＡＮ（ＶＬＡＮ）と一体化させ、ネットワーク間の広域ネットワーク（ＷＡＮ）接続等の制約されたリンクへのアクセスポイントでＶｏＩＰに優先順位をつける。シタラ製品は、信号を知ることがないため、通信の試みを拒絶することができない。これにより、パケットフローは拒絶されるが、パケットフローの宛先及びソースのいずれもフロー拒絶を知ることがない。予告無しのパケットの拒絶は、殆どの場合、予期しない結果を生む。

米国のミネソタ州にあるエデン・プレーリー（Ｅｄｅｎ Ｐｒａｉｒｉｅ）のアロット（Ａｌｏｔｔｏ）通信は、フローキューイング毎に行なうためにＶｏＩＰパケットに基づいて特定の処理を行なうネットエンフォーサー（ＮｅｔＥｎｆｏｒｃｅｒ）（登録商標）と称される製品を開発した。また、ネットエンフォーサー（登録商標）は、パケットを分割して（例えば、２０ｍｓのスピーチを伴うパケットは、それぞれが１０ｍｓのスピーチを伴う２つのパケットに分割される）、ＷＡＮ内でのゆっくりとした速度の送信に基づいて導入される待ち時間を殆ど生じさせないことを保証する。ネットエンフォーサーは、ＣＯＰＳまたはＲＳＶＰを基本とするルータネットワーク内で動作し、パケット承認制御を行なう。残念ながら、ネットエンフォーサー（登録商標）は、信号プラン（すなわち、ＳＩＰ、メディアゲートウェイ制御プロトコル（ＭＧＣＰ）、Ｈ．３２３）に関与せず、パケットの質をリアルタイムで測定しないとともに、パケットの質を承認決定に取り入れない。

また、エブズリン（Ｅｖｓｌｉｎ）等に対して付与された米国特許第６，４０４，８６４号（以下、‘８６４特許と称する）は、質の測定に基づいて通話のルーティングを制御するためのネットワークルーティングスキームを開示している。質の測定は、各通話の最後に集められて表にされ、その後にルーティング決定を行なうために使用される。したがって、質は、リアルタイムで測定されない。また、‘８６４特許は、領域毎の勧告的な帯域幅制限を開示せず、下流側または上流側のネットワークという概念を開示していないとともに、通話がネットワークに対して承認されることを防止しない。これに代わって、‘８６４特許は、通話がネットワークに対して承認される際にルーティングが制御されることについて記載している。

まとめると、図１のＰＤＮ ＰＯＰ １０２等のネットワークにパケットを入力する前だけでなく、エッジルータから下流側では、パケットフローがネットワークから出て他のネットワークに承認される時にも、パケットフロー制御及びＱｏＳパケットフロー承認制御を行なうことが望ましい。

概要
以上を鑑みて、本発明の第１の典型的な実施形態は、概して、セッション承認制御を与えるシステムに関する。

一般に、システム構造において、システムは、通信要求のソース及びセッションディレクタを利用する。セッションディレクタは、ソースからの帯域幅割り当て要求に応じるように帯域幅を割り当て、割り当てられた帯域幅の質が、ソースからセッションディレクタへのマルチメディアパケットの送信に適することを確保するとともに、割り当てられた帯域幅のサービスの質が、割り当てられた帯域幅によるマルチメディアパケットのフローを与えるのに適することを確保する。

また、本発明は、セッション承認制御を与える方法を提供するものとして見なすことができる。この点において、方法は、おおまかには、以下のステップにまとめられる。すなわち、帯域幅割り当て要求に応じるように帯域幅を割り当てるステップと、割り当てられた帯域幅の質がマルチメディアパケットの送信に適することを確保するステップと、割り当てられた帯域幅のサービスの質が、割り当てられた帯域幅によってマルチメディアパケットのフローを与えるのに適することを確保するステップとを備えている。

本発明の他のシステム及び方法は、以下の図面及び詳細な説明を検討することにより当業者に明らかとなる。そのような別個のシステム、方法、利点の全てが、この明細書中に含まれ、本発明の範囲内にあり、添付の請求の範囲によって保護されることを意図している。

詳細な説明
図２は、本発明の第１の典型的な実施形態に係る通信レイアウトを示すブロック図である。具体的に、図２は、ＰＤＮ ＰＯＰ ２０２と、ＰＤＮ ＰＯＰ ２０２に接続されるネットワークピアリングポイントに配置された第２のセッションディレクタ２０５と、第１の集約領域２１２と、第２の集約領域２５２との間の通信レイアウトを示している。

以下に詳細に説明するように、セッションディレクタ２０３，２０５は、パケットをＰＤＮ ＰＯＰ ２０２に入力する前だけでなく、エッジルータから下流側では、パケットフローがＰＤＮ ＰＯＰ ２０２から出て他のネットワークに承認される時にも、パケットフロー制御及びＱｏＳパケットフロー承認制御を行なう。なお、セッションディレクタ２０３，２０５は、図２のＰＤＮ ＰＯＰ ２０２内に設置する代わりに、任意の種類のネットワーク内に設置されていても良い。代わりのネットワーク設置位置としては、例えば、企業ネットワーク、サブマリン転送リンクへのアクセスといったコアネットワーク内の制約されたポイント等を挙げることができる。実際には、セッションディレクタ２０３，２０５は、遅い帯域幅転送リンクへのアクセスのための競合が存在し得る任意の場所で使用されても良い。

ＰＤＮ ＰＯＰ ２０２はエッジルータ２０４を有している。このエッジルータ２０４は、エッジルータの下流側に設けられた第１の集約領域２１２と第２の集約領域２５２との間でデータを経路指定する。また、ＰＤＮ ＰＯＰ ２０２は、好ましくは２層集約装置である第１の集約装置２４８を有している。第１の集約装置２４８は、第１の集約領域２１２内に設けられた第１の企業２２１と、第２の企業２３１と、第３の企業２４１との間での通信を可能にする。また、エッジルータ２０４を使用することにより、第１の集約装置２４８は、第１の集約領域２１２と第２の集約領域２５２との間での通信を可能にする。当業者であれば、集約装置がどのようにして通信を可能にするかについての知識を有しているため、本発明では、集約装置による通信可能手段についてこれ以上説明しない。

また、好ましくは２層集約装置である第２の集約装置２８２も、ＰＤＮ ＰＯＰ ２０２内に設けられている。第２の集約装置２８２は、第２の集約領域２５２内に設けられた第１の企業２６１と第２の企業２７１との間での通信を可能にする。また、エッジルータ２０４を使用することにより、第２の集約装置２８２は、第１の集約領域２１２と第２の集約領域２５２との間での通信を可能にする。

第１の集約領域２１２は、第１の企業２２１と、第２の企業２３１と、第３の企業２４１とを含んでいる。第１の企業２２１は、第１のアクセスルータ２２２と、第１のプライベートデータネットワーク２２４と、ユーザが使用する第１のコンピュータ２２６とを有している。第２の企業２３１は、第２のアクセスルータ２３２と、第２のプライベートデータネットワーク２３４と、ユーザが使用する第２のコンピュータ２３６とを有している。第３の企業２４１は、第３のアクセスルータ２４２と、第３のプライベートデータネットワーク２４４と、ユーザが使用する第３のコンピュータ２４６とを有している。なお、ユーザがコンピュータを使用して通信を行なう必要はない。その代わり、ユーザは、任意の通信装置を使用して通信を行なうことができる。このような通信装置の例としては、ピングテル（Ｐｉｎｇｔｅｌ）ＶｏＩＰ電話、ＩＰ電話、ＶｏＩＰゲートウェイ等のＶｏＩＰ電話を挙げることができるが、これらに限定されない。

企業２２１，２３１，２４１内に設けられた各アクセスルータ２２２，２３２，２４２は、コンピュータ２２６，２３６，２４６をＰＤＮ ＰＯＰ ２０２に接続する。ＰＤＮ ＰＯＰ ２０２によって利用可能なネットワークサービスのユーザは、ＰＤＮ ＰＯＰ ２０２内から、あるいは、例えば第１のコンピュータ２２６、第２のコンピュータ２３６、第３のコンピュータ２４６といったＰＤＮ ＰＯＰ ２０２の外部の場所から、ＰＤＮ ＰＯＰ ２０２に接続できる。図２には、第４のコンピュータ２７２が示されている。この第４のコンピュータ２７２によっても、ユーザは、ＰＤＮ ＰＯＰ ２０２の外部からＰＤＮ ＰＯＰ ２０２に対して直接にアクセスできる。

各アクセスルータ２２２，２３２，２４２は、プライベートデータネットワーク２２４，２３４，２４４のうちの１つに接続する。一例として、第１のアクセスルータ２２２は、第１のプライベートデータネットワーク２２４に接続する。また、各アクセスルータ２２２，２３２，２４２は、コンピュータ２２６，２３６，２４６を介したユーザと第１の集約領域２１２の他の部分との間の通信を可能にする。

第２の集約領域２５２は、第１の企業２６１と第２の企業２７１とを含んでいる。第２の集約領域２１２内に設けられた第１の企業２６１は、第１のモデム２６２と、ユーザが使用する第１のコンピュータ２６４とを有している。第２の集約領域２１２内に設けられた第２の企業２７１は、第２のモデム２７２と、ユーザが使用する第２のコンピュータ２７４とを有している。第１のモデム２６２及び第２のモデム２７２は、ＤＳＬモデム、あるいは、任意の他の種類のモデムであっても良い。

第１のセッションディレクタ２０３は、ＰＤＮ ＰＯＰ ２０２のサービスエッジに設けられている。この場合、第１のセッションディレクタ２０３は、ＰＤＮ ＰＯＰ ２０２の内部または外部に設けられた通信要求源のための帯域幅を割り当てて管理するとともに、割り当てられた帯域幅の質及び大きさが通信に適するようにする。一例として、通信要求源が第１の集約領域２１２内の第１のコンピュータ２２６、第２のコンピュータ２３６、第３のコンピュータ２４６のいずれである場合、帯域幅は、第１のアクセスルータ２２２、第２のアクセスルータ２３２、第３のアクセスルータ２４２のうちのいずれかとエッジルータ２０４との間で割り当てられて管理される。また、通信要求源が第２の集約領域２５２内の第１のコンピュータ２６４または第２のコンピュータ２７４のいずれかであった場合、帯域幅は、第１のモデム２６２または第２のモデム２７２のいずれかとエッジルータ２０４との間で割り当てられて管理される。

また、前述したように、第２のセッションディレクタ２０５は、ＰＤＮ ＰＯＰ ２０２に接続されるネットワークピアリングポイントに設けられている。第２のセッションディレクタ２０５は、ＰＤＮ ＰＯＰ ２０２の内部または外部に設けられた通信要求源のための帯域幅を割り当てて管理するとともに、割り当てられた帯域幅の質及び大きさが通信に適するようにする。一例として、図２に「他のネットワーク」という表示で表わされる遠隔ネットワーク２０６内に通信要求源が設けられていた場合、帯域幅は、アクセスルータや遠隔ネットワーク内のモデム等（これらに限られない）の装置とエッジルータ２０４との間で割り当てられて管理される。以下、第１のセッションディレクタ２０３及び第２のセッションディレクタ２０５によって行なわれる機能について詳細に説明する。

図３は、図２の第１のセッションディレクタ２０３を示すブロック図である。なお、第２のセッションディレクタ２０５(図２)は、第１のセッションディレクタ２０３と同じ構成要素を有して同じ機能を達成する。したがって、第１のセッションディレクタ２０３に関する以下の説明は、第２のセッションディレクタ２０５(図２)にも適用できる。また、図３内の構成要素の配置は、パケット処理に対する一連の順序を示そうとするものではない。

本発明の第１の実施形態において、第１のセッションディレクタ２０３は、第１のインタフェース３０２と第２のインタフェース３０４とを有している。なお、第１のセッションディレクタ２０３内に設けられるインタフェースは、これより多くても良く、あるいは、これより少なくても良い。第１のインタフェース３０２は、マルチメディアパケットのための通信経路を形成する信号メッセージ及びマルチメディアパケットを受信するため、第１のセッションディレクタ２０３によって使用される。第２のインタフェース３０４は、マルチメディアパケット及び信号メッセージを送信するため、第１のセッションディレクタ２０３によって使用される。

各インタフェース３０２，３０４には、ＰＤＮ ＰＯＰ ２０２（図２）内でインタフェース３０２，３０４を識別するため、ＩＰアドレスやメディアアクセス制御（ＭＡＣ）アドレスといった少なくとも１つのアドレスが割り当てられる。少なくとも１つのＩＰアドレス及びＭＡＣアドレスが各インタフェース３０２，３０４に割り当てられるため、第１のセッションディレクタ２０３は、ＳＩＰ ＩＮＶＩＴＥメッセージ等の信号メッセージを送受信することができ、これにより、マルチメディアパケットフローのための通信経路を形成することができる。一例として、信号メッセージは、ソースデバイスまたはネットワークから第１のセッションディレクタ２０３への通信経路を形成しても良い。また、第１のセッションディレクタ２０３は、通信経路が形成された後に、マルチメディアパケットフローを送受信することができる。ＩＰアドレスは、マルチメディアパケット及び信号メッセージの送受信において、各インタフェース３０２，３０４の識別子を与える。一方、ＭＡＣアドレスは、マルチメディアパケット及び信号メッセージの送受信において第１のセッションディレクタ２０３に割り当てられる固有のハードウエア番号である。

第１のセッションディレクタ２０３内には、第１のセッションディレクタ２０３によって受信されるパケットの種類を判断するパケット分類器３０６が設けられている。パケットの種類の一例としては、ＲＴＰパケットや、リアルタイム転送制御プロトコル（ＲＴＣＰ）パケットを挙げることができるが、これらに限定されない。したがって、パケット分類器３０６は、受信したパケットがＲＴＣＰパケット等の信号パケットであるか或いはＲＴＰパケット等のマルチメディアパケットであるかどうかを判断することができる。

第１のセッションディレクタ２０３内には、フローデータベース３０８も設けられている。なお、フローデータベース３０８は、任意の電子記憶媒体、磁気記憶媒体、光記憶媒体、あるいは、他の種類の記憶媒体であっても良い。フローデータベース３０８は、ＰＤＮ ＰＯＰ ２０２（図２）の管理者によって与えられるＩＰアドレス及びポートアドレスのプルーフを記憶する。本発明の第１の実施形態において、アドレスのプルーフは、セッションディレクタに接続される各領域または各ネットワーク毎に、管理者によって形成される。したがって、フローデータベース３０８内に記憶されたＩＰアドレス及びポートアドレスのプルーフは、第１の集約領域２１２（図２）内の第１の企業２２１（図２）と、第１の集約領域２１２（図２）内の第２の企業２３１（図２）と、第１の集約領域２１２（図２）内の第３の企業２４１（図２）と、第２の集約領域２５２（図２）内の第１の企業２６１（図２）と、第２の集約領域２５２（図２）内の第２の企業２７１（図２）と、ＰＤＮ ＰＯＰ ２０２（図２）とによって形成されるネットワークまたは領域のためのＩＰアドレス及びポートアドレスを備えている。

所定のキーがセッションディレクタメモリ３１０内に記憶される。この場合、所定の各キーは、フローデータベース３０８内に記憶された情報が第１のセッションディレクタ２０３に役立つか否かを判断できる一連の論理機能を実施するための実行可能な命令の順序付けリストを規定する。なお、セッションディレクタメモリ３１０は、揮発性メモリ素子（例えば、ランダムアクセスメモリ（ダイナミックＲＡＭ（ＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）等のＲＡＭ））及び不揮発性メモリ（例えば、読み出し専用メモリ（ＲＯＭ）等）のうちの任意の１つまたは組み合わせを有していても良い。また、セッションディレクタメモリ３０８は、電子記憶媒体、磁気記憶媒体、光記憶媒体、あるいは、他の種類の記憶媒体を組み込んでいても良い。また、セッションディレクタメモリ３１０は、コンテント・アドレッサブル・メモリであっても良い。

役に立つと考えられる情報の例としては、ソース／宛先ＩＰアドレス、ソース／宛先プロトコル、ソース／宛先ポートアドレス、非同期転送モード（ＡＴＭ）恒久仮想回路（ＰＶＣ）番号、マルチメディアパケットを特定の種類のメッセージとして分類する（例えば、ＳＩＰの場合、ユーザデータグラムプロトコル（ＵＤＰ）及びポート５０１６によって、マルチメディアパケットがＳＩＰメッセージとして分類される）プロトコル及びポートの組み合わせを挙げることができる。

パケット分類器３０６により信号パケットとして識別されたパケットは、その後、パケット分類器３０６によって検査され、所定のキーにより有用であると認められた情報を信号パケットが含んでいないかどうかが判断される。有用であると認められた情報を含んでいないと判断された信号パケットは、第１のセッションディレクタ２０３内に設けられたドロップパケットプロセッサ３１２に送信される。ドロップパケットプロセッサ３１２は、所定のキーによって有用であると認められた情報に準拠していないことに起因して落とされた信号パケットを一時的に記憶する。ドロップパケットプロセッサ３１２は、その後、落とされた信号パケットのソース（源）を識別して、ＰＤＮ ＰＯＰ ２０２（図２）を使用したサービスの試みの拒絶を扱うために使用されても良い。その結果、落とされた信号パケットのソースを検査して、マルチメディアパケットの送信のためにソースに適切に信号が送られなかった理由を判断しても良い。

第１のセッションディレクタ２０３内には、トラヒックマネージャ３１６も設けられている。第１のセッションディレクタ２０３の起動時、トラヒックマネージャ３１６は、落とされなかった信号パケットを信号プロキシ３１４に転送する。前述したように、信号パケットは、パケット分類器３０６により、信号パケットであると判断された。また、パケット分類器３０６は、管理者によって与えられる所定のキーによって確認された有用な情報を各信号パケットが含んでいたか否かを個々に判断するために使用された。一例として、プロトコルＵＤＰ上でポート５０１６に送られるパケットは、ＳＩＰ信号パケットであると見なされる。後述するように、信号プロキシ３１４は、第１のセッションディレクタ２０３によって受信した信号メッセージを処理するために使用される。

また、トラヒックマネージャ３１６を使用して、トラヒックと称されるＩＰセッションマルチメディアパケットフローレートを測定して実行（強化）し、これによって、第１のセッションディレクタ２０３にトラヒック測定能力を与えても良い。市販されているトラヒックマネージャ３１６の一例は、米国のカリフォルニアにあるＭＭＣネットワークによって販売されているＮＰＸ５７００トラヒックマネージャである。トラヒックマネージャ３１６は信号プロキシ３１４と共に機能し、これにより、信号プロキシ３１４によって転送決定が成されると、トラヒックマネージャ３１６は、信号パケットによって与えられたマルチメメディアパケットを、信号プロキシ３１４によって定められた対応する優先順位で、その各マルチメディアパケットフロー中に並ばせる。

信号パケットが信号プロキシ３１４によって受信されると、後述するように、信号プロキシ３１４は、第１のセッションディレクタ２０３によって使用される信号システムのカアテゴリーにしたがって信号パケットを解析する。一例として、信号システムは、Ｈ．３２３標準システム、ＳＩＰシステム、ＭＧＣＰシステムであっても良い。

大抵の場合、最初の信号パケットがソースから送信されると、最初の信号パケットのソースから出ているマルチメディアパケットフローの送信先（宛先）は分からない。一例として、ＳＩＰにおいて、ＩＮＶＩＴＥ信号パケットがネットワークに送信されると、ＩＮＶＩＴＥ信号パケットに関連付けられたマルチメディアパケットフローの最終的な送信先（宛先）は分からない。具体的には、ＩＮＶＩＴＥ信号パケットが送信されると、マルチメディアポケットフローの最終的な送信先に関しては、ＩＰアドレスも、ポート番号やＭＡＣアドレスも分からない。

マルチメディアパケットフローの送信先が分からなくても、第１のセッションディレクタ２０３は、信号パケットからの情報を使用して、ソースからの帯域幅を割り当てて管理できるとともに、信号パケットのソースがマルチメディアパケットを送信できる前に、割り当てられた帯域幅の質及び大きさがソースからの通信に適するようにすることができる。具体的には、信号プロキシ３１４は、領域データベーステーブル３２４を使用して、ソースの帯域幅利用可能性を決定するとともに、ソースからのマルチメディアパケットの送信のために帯域幅を割り当て、帯域幅の質がソースからのマルチメディアパケットの送信に適するようにする。図４の内容は、領域データベース３２２で説明する。また、第１のセッションディレクタ２０３は、フロー品質測定エンジン３４８を有している。

第１のインタフェース３０２、第２のインタフェース３０４、パケット分類器３０６、フローデータベース３０８、ドロップパケットプロセッサ３１２、信号プロキシ３１４、トラヒックマネージャ３１６、領域データベース３２２、フロー品質測定エンジン３４８は、ローカルインタフェース３０１によって通信可能に接続されている。技術的に知られているように、ローカルインタフェース３０１は、例えば、１または複数のバス、他の有線接続または無線接続であっても良いが、これらに限定されない。ローカルインタフェース３０１は、簡単のため省かれる別個の要素、例えば、通信できるように、コントローラ、バッファ（キャッシュ）、ドライバ、リピータ、レシーバを有していても良い。更に、ローカルインタフェース３０１は、前述した構成要素間で適切な通信を行なうことができるように、アドレス、制御、データ接続を含んでいても良い。

図４は、領域データベース３２２（図３）内に設けられた領域データベーステーブル３２４の概略図である。前述したように、領域データベーステーブル３２４は、信号プロキシ３１４（図３）によって要求される情報を記憶して、帯域幅利用可能性を決定するとともに、マルチメディアパケットの通信のための帯域幅を割り当てて、割り当てられた帯域幅を管理し、帯域幅の質及び大きさがマルチメディアパケットの送信に適するようにする。領域データベーステーブル３２４は、発生領域カラム３２６と、領域部分カラム３２８と、２層カラム３３２と、インタフェースカラム３３４と、サブインタフェースカラム３３６と、アドレスカラム３３８と、最大帯域幅カラム３４２と、割り当て帯域幅カラム３４４と、ＱｏＳスコアカラム３４６とを有している。後述するように、各カラム内では、情報を記憶するために、一連のセルが使用される。

発生領域カラム３２６内のセルは、信号メッセージ及びマルチメディアパケットフローのソースのテキスト名を記憶する。テキスト名は、領域データベーステーブル３２４に対してキーとして機能する。テキスト名は、様々な種類の文字を含んでいても良く、テキスト名のために領域データベース３２２内に割り当てられた空間の大きさにより文字数が制限されても良い。発生領域の例としては、図２の第１のプライベートネットワーク２２４、第２のプライベートネットワーク２３４、第３のプライベートネットワーク２４４を挙げることができる。

領域部分カラム３２８内のセルは、発生領域が配置される場所を表わすテキスト名を記憶する。一例として、発生領域がモデムである場合、領域部分はローカルエリアネットワーク（ＬＡＮ）であっても良い。他の例として、発生領域がＬＡＮである場合、領域部分は公衆データネットワークであっても良い。図２に特定すると、発生領域が第１のプライベートネットワーク２２４である場合、領域部分は第１の集約領域２１２であっても良い。

２層カラム３３２内のセルは、第１のセッションディレクタ２０３によって使用される２層ネットワーキングのタイプの識別子を記憶する。２層ネットワーキングのタイプの識別子は、サブインタフェースカラム３３６内に記憶される情報を規定するために使用される。インタフェースカラム３３４は、インタフェース３０２，３０４（図３）が配置される領域を示している。

サブインタフェースカラム３３６内のセルは、２層分離を行なうために使用される数値の指標を記憶する。したがって、アドレスカラム３３８内の複数のセルが同じ値を内部に記憶している場合、サブインタフェースカラム３３６は、セル間を区別するために使用されても良い。例えば、イーサネットインタフェースの場合、数値の指標は、８０２．１ｑ ＶＬＡＮタグを表わしても良い。他の例として、ＡＴＭインタフェースの場合、数値の指標は、ＰＶＣ数であっても良い。

アドレスカラム３３８内のセルは、ＩＰアドレス等のアドレスを記憶する。本発明の第１の実施形態において、各ＩＰアドレスの後には、スラッシュと、ＩＰアドレスに関連付けられた発生領域を識別するために使用されても良いビットの最大数の数値表示とが続く。したがって、後述するように、マルチメディアパケットフローに関してＩＰアドレスが信号プロキシ３１４（図３）によって与えられると、ＩＰアドレスは、発生領域カラム３２６のセル内に記憶されたエントリと一致し、これにより、マルチメディアパケットフローのソースを決定する。なお、発生領域カラム３２６、領域部分カラム３２８、２層カラム３３２、インタフェースカラム３３４、サブインタフェースカラム３３６、アドレスカラム３３８、最大帯域幅カラム３４２、割り当て帯域幅カラム３４４、ＱｏＳスコアカラム３４６のそれぞれのセル内に記憶された情報間の関連性は、領域データベーステーブル３２４の同じ列（横列）内に設けられたセル内に記憶される情報によって示される。

最大帯域幅カラム３４２内のセルは、発生領域から生じるマルチメディアパケットフローのために使用できる帯域幅の大きさの数値表示を記憶する。発生領域から生じるマルチメディアパケットフローのために使用できる帯域幅の大きさの１つの数値表示があることが好ましい。本発明の第１の実施形態において、最大帯域幅カラム３４２のセル内に示される帯域幅の大きさは、第１のセッションディレクタ２０３の管理者によって指定される勧告的な制限であり、発生領域によって利用できる物理的な帯域幅よりも小さい。図４の領域データベース３２４によって示される例において、Ａｃｍｅパケット発生領域は、Ａｃｍｅパケット発生領域に対するマルチメディアパケットの送信のため、最大８００キロバイト（ＫＢ）の帯域幅が許容される。前述したように、マルチメディアパケット送信のために利用できる実際の物理的な帯域幅は、特定の最大帯域幅よりも十分に大きくても良い。

後述するように、割り当て帯域幅カラム３４４及びＱｏＳスコアカラム３４６内のセルの値は、第１のセッションディレクタ２０３が使用される際に動的に決定される。割り当て帯域幅カラム３４４内のセルは、第１のセッションディレクタ２０３によってマルチメディアパケットフローのために割り当てられた全帯域幅の数値表示を記憶する。この場合、各発生領域毎に１つの数値表示が記憶される。なお、新たなマルチメディアパケットフローが第１のセッションディレクタ２０３によって与えられる際、または、マルチメディアパケットフローが第１のセッションディレクタ２０３によって終了する際、数値表示は、リアルタイムで維持される。

ＱｏＳスコアカラム３４６内のセルは、信号プロキシ３１４（図３）によって決定されるＱｏＳスコアを記憶する。ＱｏＳスコアは、発生領域から生じるマルチメディアパケットフローの測定されたジター、パケットロス、待ち時間に基づく帯域幅の質の数値表示である。以下、前述した各カラムについて詳細に説明する。

第１のセッションディレクタ２０３（図３）の使用前、割り当てられた帯域幅及びＱｏＳスコアを除き、領域データベーステーブル３２４内に記憶される情報は、第１のセッションディレクタ２０３（図３）内に設けられたフロー品質測定エンジン３４８（図３）によって与えられる。また、割り当てられる帯域幅及びＱｏＳスコアは、第１のセッションディレクタ２０３（図３）が使用されている間、信号プロキシ３１４（図３）によって計算される。ＱｏＳスコア計算については、以下に詳細に説明する。

第１のセッションディレクタの概要
図５は、図３の第１のセッションディレクタ２０３を使用することによって果たされる機能の概要を与えるフローチャート３５０である。フローチャート中の任意のプロセス内容すなわちブロックは、特定の論理機能すなわちプロセス中のステップを実施するための１または複数の実行可能な命令を含むコードの一部、モジュール、セグメントを表わしていることは言うまでもない。本発明における当業者であれば分かるように、関連する機能性に応じて、図示され又はここで説明する順序と異なる順序（ほぼ同時に或は逆の順序を含む）で機能を実行できる他の実施も、本発明の第１の典型的な実施形態の範囲内に含まれる。

ブロック３６０によって示されるように、帯域幅は、１つの発生領域のために割り当てられる。発生領域のための帯域幅の割り当てにより、発生領域内に設けられたソースから第１のセッションディレクタ２０３（図３）へのマルチメディアパケットフローの横断が可能になる。帯域幅割り当ての内容については、以下に与えられる図６で説明する。

現在の帯域幅の質がマルチメディアパケットの送信のために十分であることを確かめるため、発生領域のために割り当てられる帯域幅の質が判断される（ブロック３６２）。帯域幅の質がマルチメディアパケットの送信のために十分である場合、帯域幅は、領域部分のために割り当てられる（ブロック３６４）。領域部分のために割り当てられる帯域幅の質は、マルチメディアパケットの送信のために判断される（ブロック３６６）。ブロック３６４及びブロック３６６によって示される機能は、発生領域に関与する領域の残存部分が無くなるまで繰り返される（ブロック３６８）。

ブロック３７２によって示されるように、マルチメディアパケットフローが発生領域及び対応する領域部分（領域の一部）によって許容されると判断されると、決定された利用可能な帯域幅を反映するために、マルチメディアパケットフローに関与する信号パケットが必要に応じて更新される。ソースアドレス及び宛先アドレス等の信号パケット内に設けられたマルチメディア記述子のアドレスが更新されることにより、発生領域または領域部分（領域の一部）から送信されるマルチメディアパケット及び信号パケットは、宛先アドレスへの送信前に、第１のセッションディレクタ２０３（図２）に送られる。本発明の第１の典型的な実施形態においては、信号プロキシ３１４（図３）がマルチメディア記述子の更新を行なう。

更新された信号パケットは、信号プロキシ３１４（図３）からトラヒックマネージャ３１６（図３）に送信される。その後、トラヒックマネージャ３１６（図３）は、更新された信号パケットを第２のインタフェース３０４（図３）に転送し（ブロック３７４）、その後、更新された信号パケット（更新信号パケット）は、更新信号パケットの宛先に送信される（ブロック３７６）。

所定時間後、送信された更新信号パケットへの応答は、第１のセッションディレクタ２０３によって受信される（ブロック３７８）。この応答は、第１のインタフェース３０２（図３）に到達し、解析のために信号プロキシ３１４（図３）に送られる。応答は、マルチメディアパケットフローを始めることができることを示す肯定的な応答（例えば、ＳＩＰ ＯＫ， Ｈ．３２３ Ｃｏｎｎｅｃｔ， ＭＧＣＰ ＭＯＤＩＦＹ ＣＯＮＮＥＣＴＩＯＮ）であっても良く、あるいは、否定的な応答（例えば、ＳＩＰ ＮＡＣＫ，Ｈ．３２３ Ｒｅｌｅａｓｅ Ｃｏｍｐｌｅｔｅ）であっても良い。第１のセッションディレクタによって受信された応答が否定的な応答である場合、予め割り当てられていた帯域幅は、確保されていた帯域幅を領域データベース３２４（図４）に戻し加え且つこれにより割り当て帯域幅カラム３４４のセル内に記憶された値を減少させることにより、その割り当てが取り消される。なお、タイムアウト時間（例えば、ＭＧＣＰタイムアウト）は、否定的な応答であると見なされても良い。この場合、信号プロキシ３１４は、所定時間後に応答が第１のセッションディレクタ２０３によって受信されない場合、予め割り当てられていた帯域幅の割り当てを取り消す。

帯域幅再割当の例は以下の通りである。Ｇ．７１１またはＧ．７２９のための要求が宛先に送信されると仮定すると、８０ＫＢの割り当てが行なわれ、ＳＩＰ ＮＡＣＫが宛先により第１のセッションディレクタに戻される。割り当てられた８０ＫＢは、その後、マルチメディアパケットフローのために割り当てられた帯域幅値から差し引かれる。

しかしながら、肯定的な表示が宛先によって戻されると、戻された媒体記述子に記載される、マルチメディアパケットによって使用される実際の帯域幅を反映するように、帯域幅割り当てが再計算される（ブロック３８４）。一例として、前述したＧ．７１１またはＧ．７２９のための要求が８０ＫＢを確保し、最終的な結果として生じる媒体記述子がＧ．７２９を要求した場合、割り当て帯域幅カラム３４４内に記憶された割り当てられた帯域幅は、実際の帯域幅フローを反映するように減少される。

帯域幅割り当て
図６は、ソースから図３の第１のセッションディレクタ２０３へマルチメディアパケットを送信するために帯域幅を割り当てるステップを示すフローチャート３９０である。ブロック３９２によって示されるように、信号パケットがソースから受信されると、信号メッセージのソースアドレスが信号パケットから抽出される。一例として、ＳＩＰプロトコル及びＭＧＣＰプロトコルにおいて、ソースアドレスは、ＩＮＶＩＴＥメッセージ及びＣＲＥＡＴＥ ＣＯＮＮＥＣＴＩＯＮメッセージのそれぞれのセッション記述プロトコル（ＳＤＰ）部分で見出される。

マルチメディアパケット送信のための帯域幅の尺度がソースのために割り当てられる。この場合、帯域幅の尺度は、ソースによって許容される最大サポートタイプの帯域幅に対応する帯域幅の最大尺度と等しい。詳しく述べると、ソースは、多数のサポートタイプの帯域幅であっても良い。この場合、最大サポートタイプの帯域幅は、最も大きい帯域幅割り当てを要求するタイプである。一例として、信号メッセージのソースがＧ．７２９音声通信を要求している場合、音声通信のために８０ＫＢの帯域幅が確保されても良い。ソースのために割り当てられるマルチメディアパケット送信のための帯域幅の尺度は、領域データベーステーブル３２４（図４）の割り当て帯域幅カラム３４４（図４）内に記憶される。具体的には、本発明の典型的な第１の実施形態において、帯域幅の尺度は、ソースのアドレスを内部に記憶するアドレスカラム３３８（図４）内に設けられたセルと同じ列（横列）内にある割り当て大域幅カラム３４４（図４）のセル内に記憶される。

信号パケットの発生領域は、領域データベーステーブル３２４（図４）のアドレスカラム３３８（図４）内のソースアドレスを検索するとともに、ソースアドレスに関連付けられた発生領域を決定することによって決定される（ブロック３９６）。具体的には、本発明の第１の実施形態において、ソースアドレスに関連付けられた発生領域は、ソースアドレスが内部に記憶されたアドレスカラム３３８（図４）内のセルと同じ領域データベーステーブル（図４）の列内にある発生領域カラム３２６（図４）のセル内に記憶される。

帯域幅の質が適切となるように、割り当てられた帯域幅は、決定された発生領域によって許容された最大帯域幅と比較される（ブロック３９８）。決定された発生領域によって許容された最大帯域幅は、領域データベーステーブル３２４（図４）の最大帯域幅カラム３４２（図４）内に設けられたセル内に記憶される。このセルは、決定された発生領域を記憶するセルと同じ列内にある。割り当てられた帯域幅が許容された最大帯域幅よりも小さい場合、帯域幅は、要求された通信を許容するために利用でき、通信が許容されても良い（ブロック４００）。しかしながら、割り当てられた帯域幅が許容された最大帯域幅よりも大きい場合、要求された通信を許容するために必要な帯域幅を利用することができず、要求された通信は不可能である（ブロック４０２）。

本発明の第２の実施形態において、割り当てられた帯域幅が許容された最大帯域幅よりも大きい場合、信号メッセージのソースにより他のタイプの通信が許容され、これにより、帯域幅が小さい（下位の）タイプの通信が受け入れ可能か否かを判断しても良い。具体的には、通信要求のソースによって許容される帯域幅の下位サポートカテゴリーにおいて帯域幅を割り当てるように、図６のブロック３９４を差し替える。一例として、Ｇ．７１１コール要求がＧ．７２９コール要求に格下げされても良い。なお、帯域幅の下位サポートカテゴリーにおいて変更が生じた場合、媒体記述子もまた、通信要求に応じる当事者によって高い帯域幅が選択されないように修正が必要である。一例として、ＳＤＰ（ＳＩＰ及びＭＧＣＰにおいて）内及び／またはＨ．２４５（Ｈ．３２３において）内に設けられた媒体記述子を修正する必要がある。

ソースの帯域幅の質の決定
第１のセッションディレクタ２０３（図３）を使用することによってどのように帯域幅を割り当てるかについて説明するにあたっては、割り当てられた帯域幅の質を決定するとともに、マルチメディアパケットを第１のセッションディレクタ２０３（図３）に送信するために帯域幅の質が十分であるかどうかを決定することについて述べる（図５のブロック３６２）。ソースの帯域幅の質は、決定された発生領域に関連付けられたＱｏＳスコアを検索することによって決定されても良い。具体的には、本発明の第１の典型的な実施形態において、領域データベース３２２（図４）のＱｏＳスコアカラム３４６（図４）は、発生領域が内部に記憶された発生領域カラム３２６（図４）内のセルと同じ列内に設けられたセル内に記憶されるＱｏＳスコアに関して検索される。

前述したように、ＱｏＳスコアは、対応する発生領域から生じるマルチメディアパケットフローの測定されたジター、パケットロス、待ち時間に基づく帯域幅の質の数値表示である。ジター、パケットロス、待ち時間に関する新たな値をフロー品質測定エンジン３４８（図３）から受信した後、ＱｏＳスコアカラム３４６内に記憶されたＱｏＳスコアは、信号プロキシ３１４（図３）によって定期的に更新される。実際に、フロー品質測定エンジン３４８（図３）は、更新スケジュールにしたがって定期的な更新を行なうようにプログラムされていても良い。新たなジター、パケットロス、待ち時間の値を決定した後、フロー品質測定エンジン３４８（図３）は、前記値を信号プロキシ３１４（図３）に送信する。その後、信号プロキシがＱｏＳスコアを更新しても良い。

前述したように、マルチメディアパケットフローにおいてジター及びパケットロスが分かると、３つの統計値を１つの値にまとめるＱｏＳスコアが計算される。ＱｏＳスコアを計算するために使用できる多くの市販されたアルゴリズムがある。市販されたアルゴリズムの一例は、米国のジョージア州のアトランタにあるテルケミー社（Ｔｅｌｃｈｅｍｙ）から市販されているＶＱｍｏｎ（登録商標）である。ＶＱｍｏｎ（登録商標）によって与えられるアルゴリズムは、ジター、待ち時間、パケットロスの値の入力を許容し、その後、ＱｏＳスコアとして使用できる１つのＶＱｍｏｎ（登録商標）スコアが計算される。

本発明の典型的な第１の実施形態において、ＱｏＳスコアは、０の値から１の値の範囲をとる。１の値を持つＱｏＳスコアは、発生領域に関連付けられた現在の帯域幅の質が十分であることを表わしており、マルチメディアパケットの送信にその帯域幅を利用することができ、ジター、待ち時間、パケットロスが測定されないことを意味している。ＱｏＳスコアが１である場合の例は、フロー品質測定エンジン３４８（図３）の更新中に、発生領域内にマルチメディアパケットフローが存在しない場合である。

割り当てられた帯域幅の質がマルチメディアパケットフローの送信に十分であるかどうかを判断するために、信号プロキシ３１４（図３）は、決定されたＱｏＳスコアを、ソースからのマルチメディアパケットの送信に必要なデフォルト質レベルと比較する。一例として、ＬＡＮにおいて決定されたＱｏＳスコアの値が０．７である場合、決定されたＱｏＳスコアの値０．７は、典型的な目的のため０．８であると仮定するデフォルト質レベル要件と比較される。決定されたＱｏＳはデフォルトレベル要件よりも小さいため、ソースからのマルチメディアパケットフローは、割り当てられた帯域幅によって送信されない。

また、ＬＡＮにおいて決定されたＱｏＳスコアの値が０．９である場合、決定されたＱｏＳスコアの値０．７は、典型的な目的のため０．８であると仮定するデフォルト質レベル要件と比較される。決定されたＱｏＳはデフォルトレベル要件よりも大きいため、ソースからのマルチメディアパケットフローは、割り当てられた帯域幅によって送信される。

領域部分（領域の一部）に関する帯域幅の割り当て
ソースに関連付けられた帯域幅の質を決定する方法及びマルチメディアパケットフローを承認するために帯域幅の質が十分であるかどうかを決定する方法を説明するにあたって、図７のフローチャート４１０について述べる。このフローチャートは、領域部分に関して帯域幅を割り当てるステップを示している（図５のブロック３６４）。

ブロック４１２に示されるように、領域部分によって許容される最大サポートタイプの帯域幅が割り当てられる。一例として、領域部分がＧ．７２９音声通信またはＧ．７１１音声通信を要求した場合、音声通信のために８０ＫＢの帯域幅が確保されても良い。本発明の典型的な第１の実施形態において、信号パケットに関連付けられた領域部分は、領域データベース３２４（図４）の領域部分カラム３２８（図４）内のセルを読み出すことによって決定されても良い。このセルは、予め決定された発生領域を記憶するセルと同じ列内に設けられている。なお、図４には示されていないが、最大サポート帯域幅及び割り当てられた帯域幅をそれぞれ記憶して比較するために領域データベーステーブル３２４（図４）内に設けられた領域部分割り当て帯域幅カラム及び領域部分最大帯域幅カラムがあっても良い。

領域部分のために割り当てられた帯域幅は、決定された領域部分によって許容された最大帯域幅と比較される（ブロック４１４）。割り当てられた帯域幅が許容された最大帯域幅よりも小さい場合、要求される通信を許容するために前記帯域幅を利用することができ、通信が許容されても良い（ブロック４１６）。しかしながら、割り当てられた帯域幅が許容された最大帯域幅よりも大きい場合、要求される通信を許容するために必要な帯域幅を利用することができず、要求される通信が許容されない（ブロック４１８）。

本発明の第３の実施形態において、領域部分に関して割り当てられた帯域幅が許容された最大帯域幅よりも大きい場合、領域部分によって他のタイプの通信が要求され、これにより、帯域幅が小さい（下位の）タイプの通信が受け入れ可能か否かを判断しても良い。具体的には、領域部分によって許容される帯域幅の下位サポートカテゴリーにおいて帯域幅を割り当てるように、図７のブロック４１２を差し替える。一例として、Ｇ．７１１コール要求がＧ．７２９コール要求に格下げされても良い。なお、帯域幅の下位サポートカテゴリーにおいて変更が生じた場合、ＳＤＰ（ＳＩＰ及びＭＧＣＰにおいて）内及び／またはＨ．２４５（Ｈ．３２３において）内に設けられた媒体記述子もまた、通信要求に応じる当事者によって高い帯域幅が選択されないように修正が必要である。

領域部分の帯域幅の質の決定
領域部分に関して帯域幅が割り当てられた後（図５のブロック３６４）、領域部分に関して割り当てられた帯域幅の質が決定される（図５のブロック３６６）。ソースの帯域幅の質は、決定された領域部分に関連付けられたＱｏＳスコアを検索することによって決定されても良い。具体的には、本発明の第１の典型的な実施形態において、領域データベース３２２（図４）のＱｏＳスコアカラム３４６（図４）は、領域部分に関連付けられたＱｏＳスコアに関して検索される。

領域部分の帯域幅の質がメルチメディアパケットフローの送信のために十分であるかどうかを判断するために、信号プロキシ３１４（図３）は、決定されたＱｏＳスコアを、領域部分からのマルチメディアパケットの送信に必要なデフォルト質レベルと比較する。前述したように、領域部分における帯域幅の割り当て及び領域部分に関して割り当てられた帯域幅の質の決定（判断）は、発生領域に関連付けられた領域部分が無くなるまで繰り返される。

本発明の前述した実施形態は、考えられる単なる実施形態であり、本発明の原理を十分に理解できるように説明したものである点を強調しておく。本発明の要旨及び原理から実質的に逸脱することなく、本発明の前述した実施形態を変形し且つ修正することができる。また、そのような修正及び変形の全ては、この開示内容及び本発明の範囲内に含まれ、以下の請求項によって保護される。

以下の図面を参照すれば、本発明を良く理解することができる。図面の構成要素は、必ずしも一定の尺度で示されておらず、むしろ、本発明の原理を明確に示すことに重点が置かれている。また、図中、同じ参照符号は、幾つかの図面にわたって、同じ部分を示している。
図１は従来の通信レイアウトを示すブロック図である。 図２は本発明の第１の典型的な実施形態に係る通信レイアウトを示すブロック図である。 図３は図２の第１のセッションディレクタを示すブロック図である。 図４は図３の第１のセッションディレクタ内に設けられた領域データベーステーブルの概略図である。 図５は図３の第１のセッションディレクタを使用することにより果たされる機能の概要を与えるフローチャートである。 図６は図３の第１のセッションディレクタを使用してマルチメディアパケットフローを許容するために帯域幅を割り当てるステップを示すフローチャートである。 図７は図３の第１のセッションディレクタを使用することにより領域部分において帯域幅を割り当てるステップを示すフローチャートである。

Claims (9)

1. セッションディレクタ（２０３）であって、
   前記セッションディレクタ（２０３）によって受信されたパケットが信号パケットであるかマルチメディアパケットであるかを判断するパケット分類器（３０６）と、
   ソース（２６１，２７１）からの通信セッション要求に応じるように帯域幅を割り当て、前記割り当て帯域幅が、前記ソース（２６１，２７１）から前記セッションディレクタ（２０３）へのマルチメディアパケットフローの送信に適することを確保し、前記割り当て帯域幅のサービスの質がフローを与えるのに適することを確保するように構成された信号プロキシ（３１４）と、
   前記信号プロキシ（３１４）によって使用されるデータベーステーブル（３２４）であって、発生領域カラム（３２６）、領域部分カラム（３２８）、アドレスカラム（３３８）、最大帯域幅カラム（３４２）、割り当て帯域幅カラム（３４４）、およびサービスの質スコアカラム（３４６）を有するデータベーステーブルと、
   を有するセッションディレクタ（２０３）。
2. 前記パケット分類器（３０６）は、前記信号パケットを検査し、前記信号パケットから情報を抽出し、有用な情報を含まない前記信号パケットを、前記セッションディレクタ（２０３）内に設けられたドロップパケットプロセッサ（３１２）に転送するように構成された請求項１に記載のセッションディレクタ（２０３）。
3. 前記ドロップパケットプロセッサ（３１２）は、前記セッションディレクタ（２０３）に送信された信号パケットのソースを識別する請求項２に記載のセッションディレクタ（２０３）。
4. 前記通信セッション要求は、セッション開始プロトコル要求を有する請求項１に記載のセッションディレクタ（２０３）。
5. 前記信号プロキシ（３１４）は、前記ソース（２６１，２７１）の最大サポート帯域幅（３４２）を決定し且つ前記最大サポート帯域幅（３４２）によって適応された割り当て帯域幅（３４４）を割り当てることにより帯域幅を割り当て、前記割り当て帯域幅（３４４）を前記ソース（２６１，２７１）を包含する発生領域（１５２）によって許容される最大帯域幅と比較することにより、前記割り当て帯域幅（３４４）が、前記ソース（２６１，２７１）から前記セッションディレクタ（２０３）へのマルチメディアパケットの送信に適することを確保し、前記発生領域（１５２）に関連付けられたサービスの質スコア（３４６）を検索し、前記サービスの質スコア（１５２）を、前記ソース（２６１，２７１）からのマルチメディアパケットの送信に必要な所定の帯域幅質レベルと比較し、前記サービスの質スコア（３４６）が前記所定の帯域幅質レベルを超えた時に前記マルチメディアパケットの送信を許容し、超えない時に前記マルチメディアパケットの送信を防止することにより、前記割り当て帯域幅（３４４）のサービスの質が前記フローを与えるのに適することを確保する請求項１に記載のセッションディレクタ（２０３）。
6. 前記サービスの質スコア（３４６）は、前記発生領域（１５２）から生じるマルチメディアパケットフローの測定されたジター、パケットロス、待ち時間に基づく帯域幅質の数値表示である請求項５に記載のセッションディレクタ（２０３）。
7. 意図する通信セッションにとって望ましい帯域幅の徴候（indicia）を含む通信セッション要求をソースから受信するステップと、
   前記通信セッション要求に応じるために、割り当て帯域幅を形成するステップ（３６０）と、
   前記割り当て帯域幅がマルチメディアパケットの送信に適することを確保するステップ（３６４）と、
   前記割り当て帯域幅のサービスの質が、前記割り当て帯域幅によって前記マルチメディアパケットのフローを与えるのに適することを確保するステップ（３６６）と、
   を備えているセッション承認制御を行なう方法であって、
   前記割り当て帯域幅のサービスの質がフローを与えるのに適することを確保する前記ステップは、
   発生領域に関連付けられたサービスの質スコアを検索するステップと、
   前記サービスの質スコアを、前記ソースからのマルチメディアパケットの送信に必要な所定の帯域幅質レベル要件と比較するステップ（３６２）と、
   前記サービスの質スコアが前記所定の帯域幅質レベルを超える時に前記マルチメディアパケットの送信を許容する（３７４）とともに、超えない時に前記マルチメディアパケットの送信を防止する（３８２）ステップと、
   を更に備える方法。
8. 通信セッション要求を受信する前記ステップは、前記要求がセッション開始プロトコル要求に従っていることを確認することを含む請求項７に記載の方法。
9. 前記割り当て帯域幅がマルチメディアパケットの送信に適することを確保するステップは、
   前記割り当て帯域幅を、前記発生領域によって許容される最大帯域幅と比較するステップ（３９８）と、
   前記割り当て帯域幅が前記発生領域によって許容された最大帯域幅よりも小さい場合に前記マルチメディアパケットを送信し（４００）、そうでない場合に前記マルチメディアパケットの送信を防止する（４０２）ステップと、
   を更に備えている請求項７に記載の方法。

Images