(57)【要約】  ネットワークにおけるクォリティーオブサービスを保証する装置を提供する。第１のストリームセンダは、フローコントロールパラメータを有し、第１のストリームを送信する。ネットワークインターコネクションは、上記の第１のストリームおよび第２のストリームを受ける。上記の第１のストリームは非リアルタイムストリームであり、上記の第２のストリームはリアルタイムストリームである。バンド幅制コントロールは、上記のネットワークインターコネクションに関係する。上記のバンド幅コントロールは、上記のフローコントロールパラメータを調整し、上記の第２のストリームに係るクォリティーオブサービスパラメータを保つ。
2005536921.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおけるクォリティーオブサービスを保証する装置であって、
少なくとも１つのフローコントロールパラメータを有する、少なくとも１つの第１のストリームセンダと、
前記第１のストリームセンダから転送された、少なくとも１つの第１のストリームと、
前記第１のストリームセンダから転送された前記第１のストリーム、および第２のストリームセンダから転送された少なくとも１つの第２のストリームを受信するネットワークインターコネクションと、
前記ネットワークインターコネクションに係るバンド幅コントロールとを備え、
前記バンド幅コントロールは、前記第１のストリームセンダの前記フローコントロールパラメータを調整し、前記第２のストリームに係る少なくとも１つの性能パラメータを保つ
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２】
請求項１に記載のクォリティーオブサービス保証装置において、
前記第１のストリームセンダを有する第１のネットワークコネクションと、
前記ネットワークインターコネクションを有する第２のネットワークとを備えた
ことを特徴とするクォリティーオブサービス保証装置。
【請求項３】
請求項２に記載のクォリティーオブサービス保証装置において、
前記ネットワークインターコネクションはホームゲートウェイであり、
前記第２のネットワークはホームネットワークである
ことを特徴とするクォリティーオブサービス保証装置。
【請求項４】
請求項２に記載のクォリティーオブサービス保証装置において、
前記第１のストリームセンダおよび前記第２のストリームセンダを前記ネットワークインターコネクションに接続する少なくとも１つのチャネルを備え、
前記チャネルは、前記第１のストリームおよび第２のストリームによって共有されるバンド幅容量を有する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項５】
請求項２に記載のクォリティーオブサービス保証装置において、
前記第１のストリームは非リアルタイムストリームであり、
前記第２のストリームはリアルタイムストリームであり、
前記第２のストリームは、前記バンド幅容量の一部を一定して要求する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項６】
請求項５に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記第１のストリームが前記バンド幅容量と前記第２のストリームのバンド幅容量との差以下のバンド幅容量の割り当て分を使用するように、前記フローコントロールパラメータを調整する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項７】
請求項１に記載のクォリティーオブサービス保証装置において、
前記性能パラメータは、前記第２のストリームに係る所定のクォリティーオブサービスパラメータの集合から選択される
ことを特徴とするクォリティーオブサービス保証装置。
【請求項８】
請求項７に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、前記フローコントロールパラメータを調整し、かつ前記第１のストリームのバンド幅要求を制御することにより前記第２のストリームに係るクォリティーオブサービスパラメータを維持する。
ことを特徴とするクォリティーオブサービス保証装置。
【請求項９】
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、前記第１のストリームのフローを調節する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１０】
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、前記第１のストリームのフローを調節することで前記第１のストリームにおけるバンド幅利用を調節する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１１】
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、ＴＣＰ（Transmission Control Protocol）を実行する前記第２のストリームセンダに係るフローコントロールウインドウを有する
ことを特徴とするクォリティーオブサービス保証置。
【請求項１２】
請求項１に記載のクォリティーオブサービス保証装置において、
前記ネットワークインターコネクションは、ルータ、プロトコル変換器、およびゲートウェイからなる群のうちのいずれか１つの装置である
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１３】
ネットワークにおけるクォリティーオブサービスを保証する装置であって、
少なくとも２つのＴＣＰストリームを操作する少なくとも２つのＴＣＰコネクションと、
前記２つのＴＣＰコネクションに係る少なくとも２つのフローコントロールパラメータと、
バンド幅容量を有するチャネルを使用する前記ＴＣＰコネクションに接続されたネットワークインターコネクションと、
前記チャネルを使用する前記ネットワークインターコネクションに接続された少なくとも１つのリアルタイムストリームと、
前記ネットワークインターコネクションに係るバンド幅コントロールとを備え、
前記バンド幅コントロールは、前記ＴＣＰコネクションの前記フローコントロールパラメータを調整し、前記ＴＣＰストリームのバンド幅使用を制御する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１４】
請求項１３に記載のクォリティーオブサービス保証装置において、
前記ＴＣＰコネクションを有する少なくとも１つのサーバと、
前記ネットワークインターコネクションに接続された少なくとも１つのネットワーク要素とを備えた
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１５】
請求項１４に記載のクォリティーオブサービス保証装置において、
前記１つのネットワーク要素は、ホームネットワークに含まれるものであり、
前記ネットワークインターコネクションは、ホームゲートウェイである
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１６】
請求項１３に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、前記フローコントロールパラメータを調整することで、前記リアルタイムストリームに係る複数のクォリティーオブサービスパラメータを保護する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１７】
請求項１６に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記ＴＣＰストリームが前記バンド幅容量と前記リアルタイムストリームのバンド幅要求との差以下のバンド幅容量の割り当て分を要求するように、前記フローコントロールパラメータを調整する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１８】
ネットワークにおけるクォリティーオブサービスを保証する装置であって、
通信チャネルに接続されたエッジルータと、
前記通信チャネルに接続されたネットワークインターコネクションと、
前記エッジルータに接続された少なくとも１つのリアルタイムデータストリームと、
少なくとも１つのフローコントロールパラメータを有し、前記エッジルータにリンクされた少なくとも１つのＴＣＰコネクションと
前記ネットワークインターコネクションに係るバンド幅コントロールとを備え、
前記リアルタイムデータストリームは、前記エッジルータから前記ネットワークインターコネクションに前記通信チャネルを用いて転送されるものであり、
前記バンド幅コントロールは、前記フローコントロールパラメータを調整し、前記ＴＣＰコネクションのバンド幅要求を調節する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項１９】
請求項１８に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、第１のストリームセンダの前記フローコントロールパラメータを調整し、前記リアルタイムデータストリームに係る少なくとも１つのクォリティーオブサービスパラメータを保つものである
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２０】
請求項１８に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記ＴＣＰストリームが前記バンド幅容量と前記リアルタイムストリームのバンド幅要求との差以下のバンド幅容量の割り当て分を要求するように、前記フローコントロールパラメータを調整することで、前記ＴＣＰコネクションのバンド幅要求を調節する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２１】
動的なバンド幅割り当てを用いてネットワークにおけるクォリティーオブサービスを保証する装置であって、
それぞれが、少なくとも１つのフローコントロールパラメータを有する少なくとも２つの第１のストリームセンダと、
前記第１のストリームセンダから転送された少なくとも２つの第１のストリームと、
前記第１のストリームセンダから転送された前記第１のストリーム、および第２のストリームセンダから転送された少なくとも１つの第２のストリームを受信するネットワークインターコネクションと、
前記ネットワークインターコネクションに係るバンド幅コントロールとを備え、
前記バンド幅コントロールは、前記フローコントロールパラメータを動的に調整し、所定の前記第１のストリームに割り当てられた未使用のバンド幅を、他の前記第１のストリ
ームに割り当てる
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２２】
請求項２１に記載のクォリティーオブサービス保証装置において、
前記第１のストリームは非リアルタイムＴＣＰストリームであり、
前記第２のストリームはリアルタイムデータストリームである
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２３】
請求項２２に記載のクォリティーオブサービス保証装置において、
前記所定の第１のストリームは、ＴＣＰスロースタートの間、未使用のバンド幅を有する
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２４】
請求項２１に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記所定の第１のストリームが定常状態になったとき、前記所定の第１のストリームおよび前記他の第１のストリームに等しいバンド幅を割り当てる
ことを特徴とするクォリティーオブサービス保証装置。
【請求項２５】
ネットワークにおけるクォリティーオブサービスを保証する方法であって、
少なくとも１つの第１のストリームセンダに係る少なくとも１つのフローコントロールパラメータを調整することで少なくとも１つの第１のストリームのバンド幅要求を調節するステップを備え、
前記第１のストリームセンダは、バンド幅容量を有する少なくとも１つの通信チャネルを使用して前記第１のストリームを転送するものであり、
当該方法は、
前記通信チャネルを使用して少なくとも１つの第２のストリームセンダから転送された少なくとも１つの第２のストリームに対して、少なくとも１つのクォリティーオブサービスパラメータを保証するステップを備え、
前記クォリティーオブサービスパラメータは、前記第１のストリームのバンド幅要求に依存している
ことを特徴とするクォリティーオブサービス保証方法。
【請求項２６】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記調節するステップは、
前記通信チャネルに接続されたネットワークインターコネクションに係るバンド幅コントロールを用いて、前記第１のストリームのバンド幅要求を調整する
ことを特徴とするクォリティーオブサービス保証方法。
【請求項２７】
請求項２６に記載のクォリティーオブサービス保証方法において、
前記調整するステップは、
前記第１のストリームのバンド幅要求が前記通信チャネルのバンド幅容量と前記第２のストリームのバンド幅要求との差以下になるように、前記第１のストリームのバンド幅要求を調整する
ことを特徴とするクォリティーオブサービス保証方法。
【請求項２８】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記通信チャネルのバンド幅容量は、前記第１のストリームおよび第２のストリームによって共有される
ことを特徴とするクォリティーオブサービス保証方法。
【請求項２９】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記フローコントロールパラメータは、前記第１のストリームのバンド幅要求を調節する
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３０】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記ネットワークインターコネクションは、ルータ、プロトコル変換器、およびゲートウェイからなる群のうちのいずれか１つの装置である
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３１】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記第１のストリームは非リアルタイムストリームを有するものであり、
前記第２のストリームはリアルタイムストリームを有するものである
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３２】
請求項３１に記載のクォリティーオブサービス保証方法において、
前記非リアルタイムストリームはＴＣＰストリームを有するものであり、
前記第１のストリームセンダはＴＣＰコネクションである
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３３】
請求項２５に記載のクォリティーオブサービス保証方法において、
前記通信チャネルのバンド幅容量は、前記第１のストリームと前記第２のストリームとで共有される
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３４】
動的なバンド幅割り当てを用いてネットワークにおけるクォリティーオブサービスを保証する方法であって、
少なくとも１つの第１のストリームセンダに係る少なくとも１つのフローコントロールパラメータを動的に調整するステップを備え、
前記第１のストリームセンダは、バンド幅容量を有する少なくとも１つの通信チャネルを使用して前記第１のストリームを転送するものであり、
当該方法は、
前記フローコントロールパラメータを動的に調整することで、前記第１のストリームのバンド幅要求を調節するステップと、
前記通信チャネルを使用して少なくとも１つの第２のストリームセンダから転送された少なくとも１つの第２のストリームに対して、少なくとも１つのクォリティーオブサービスパラメータを保証するステップとを備え、
前記クォリティーオブサービスパラメータは、前記第１のストリームのバンド幅要求に依存している
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３５】
請求項３４に記載のクォリティーオブサービス保証方法において、
前記調整するステップは、
前記第１のストリームセンダおよび第２のストリームセンダに接続されたネットワークインターコネクションに係るバンド幅コントロールを用いて、所定の前記第１のストリームに割り当てられた未使用のバンド幅を他の前記第１のストリームに割り当てる
ことを特徴とするクォリティーオブサービス保証装置。
【請求項３６】
請求項３５に記載のクォリティーオブサービス保証方法において、
前記バンド幅コントロールは、
前記所定の第１のストリームが定常状態になったとき、前記所定の第１のストリームおよび他の第１のストリームに等しいバンド幅を割り当てる
ことを特徴とするクォリティーオブサービス保証方法。
【請求項３７】
請求項３４に記載のクォリティーオブサービス保証方法において、
前記第１のストリームは非リアルタイムＴＣＰストリームを有するものであり、
前記第２のストリームはリアルタイムストリームを有するものである
ことを特徴とするクォリティーオブサービス保証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおけるクォリティオブサービスを保証することに関し、特に、リアルタイムおよび非リアルタイムデータストリームを送受信するネットワークについてクォリティオブサービスを保証することに関する。
【背景技術】
【０００２】
ネットワークユーザは、インターネットや他の情報源からの様々な種類の情報とアクセスすることができる。ネットワークユーザがアクセスできる情報の種類は大きく、リアルタイムストリームと非リアルタイムストリームとの２種類に分けられる。たとえば、一般のユーザは、ビデオまたはオーディオのようなリアルタイムデータストリーム、そして、ｅメール、ウェブページ、またはＦＴＰ(File-Transfer Protocol)ダウンロードのような非リアルタイムデータストリームを受信する。一般に、リアルタイムデータストリームは、わずかな上限時間内に転送または処理されなければならない。一方、非リアルタイムデータストリームについては、リアルタイムデータストリームに求められるように決められた時間内にデータを転送または処理する必要がないことは広く解されている。リアルタイムおよび非リアルタイムデータストリームは、以下で示すように異なった特性を持っている。
【０００３】
ここでいうリアルタイムおよび非リアルタイムデータストリームの主たる特性は、おのおのがバンド幅要求を行い、異なったレベルのＱｏＳ(Quality-of-Service)を提供することである。ＱｏＳは、一般的に、スループット、トランジット、遅延、および優先度を含む、所定のネットワークサービスにおける性能特性の集合として広く解されている。ここでいうリアルタイムストリームにおける付加的なＱｏＳパラメータは、他のパラメータのうち、バンド幅の利用率、遅延、およびジッタを含んでいる。当業者であれば、所定のＱｏＳパラメータについての関連性および重要性は、特別なアプリケーションに用いられるリアルタイムデータストリームの特質に依存することを理解できるであろう。本発明は、所定のリアルタイムデータストリームにおけるＱｏＳパラメータ集合に適応可能である。リアルタイムストリームは、比較的速いかつ時間制限された情報転送のために、保証されたＱｏＳを必要とする。非リアルタイムストリームは、一般的に、ＴＣＰ／ＩＰ(Transmission Control Protocol／Internet Protocol)を用いて転送される。対照的に、非リアルタイムストリームは一般的に、リアルタイムストリームに必要であったＱｏＳに類似したＱｏＳを必要としない。リアルタイムおよび非リアルタイムデータストリームを扱うネットワークについて典型的な例を以下で示す。
【０００４】
ネットワークは、外部の情報源からリアルタイムおよび非リアルタイムデータストリーム双方を受信するように構成され得る。転送チャネルによって、一般的にユーザのネットワークはＩＳＰ(Internet Service Provider)にリンクされる。同一の転送チャネルによって、リアルタイムおよび非リアルタイムストリーム双方は同時に伝送される。一般にこのような転送チャネルのバンド幅容量（bandwidth capacity)は固定されている。したがって、リアルタイムおよび非リアルタイムストリームにおける相容れない要求の間で、利用可能なバンド幅の割り当てのバランスをとることが必要になってくる。以下に、バンド幅の割り当てについての問題を一般的なユーザを対象に説明する。
【０００５】
ネットワークユーザは、通常、インターネットアクセスおよび場合によってはビデオオンデマンド、ＩＰ電話、ストリーミングオーディオおよびビデオのような他のサービスを提供するサービスプロバイダを通してインターネットのようなネットワークに接続される。サービスプロバイダは、ダイアルアップ電話回線、ｘＤＳＬおよびＩＳＤＮなどの転送
チャネルによってネットワークユーザとリンクされている。サービスプロバイダの末端にある接続機器はエッジルータであり得、ネットワークユーザの末端にある接続器機は一般的にゲートウェイであろう。
【０００６】
リアルタイムデータストリームは、ほぼ固定されたバンド幅の割り当てを必要とする。リアルタイムデータストリームについては、ＱｏＳパラメータが変化してしまうため、バンド幅要求を自由に調整することは困難である。これとは対照的に、非リアルタイムのデータストリームについては、通常、それほど厳格なＱｏＳを必要としないため、バンド幅要求に対して比較的柔軟に対応することができる。バンド幅の利用率は、所定の期間ごとに変動する。したがって、サービスプロバイダからネットワークユーザまでの非リアルタイムストリームのトラフィックは、リアルタイムストリームが自身のＱｏＳパラメータ維持に要求されるバンド幅を確実に得られるように制御される必要がある。以下に、バンド幅の共有が制御可能な方法について考察する。
【０００７】
以下では、パケットぺーシング（packet pacing)方法を用いた一般的なアプローチを議論する。サービスプロバイダ側にあるルータからゲートウェイに転送される非リアルタイムトラフィックは、一般にＴＣＰプロトコルを利用して転送されるインターネット通信トラフィックである。インターネットサイトにおけるＴＣＰセンダ（sender)は、非リアルタイムのパケットをぺーシング（pacing)することで非リアルタイムトラフィックを制御し、リアルタイムトラフィックが、要求するバンド幅を得られるようになっている。以下に、パケットぺーシング方法およびこれに関連した問題について記載する。
【０００８】
パケットぺーシングは一般的に、パケット転送レートを制御することで実行される。このようなパケットぺーシング方法を実現するためには、ＴＣＰセンダの動作において重大な変化が要求される。典型的なユーザが接続されるＴＣＰセンダ、つまりＨＴＴＰ（Hypertext Transfer Protocol）サーバは、大学、病院または企業のような外部の機関の制御下にある。ＩＳＰがあらゆる特別なバンド幅管理技術を採用するとは考えられない。ＩＳＰは一般的に、同時に動作するいくつかのアクティブＴＣＰコネクションを各ユーザが使用する状態で多数のユーザにサービスを提供する。このようなパケットぺーシングのアプローチは、多数のユーザへのサービスの提供に関するスケーラビリティー問題のため、ＩＳＰサイトで実現しそうにない。したがって、ネットワークのゲートウェイ側で実現される改良型バンド幅管理技術が必要となる。
【０００９】
もう１つの試みは、非リアルタイムストリームに関するＴＣＰトラフィックを一般のユーザのゲートウェイから制御するものを有する。しかし、この試みには、ユーザのゲートウェイ側のＴＣＰレシーバ（receiver)が、ＨＴＴＰ（Hypertext Transfer Protocol)サーバまたはＦＴＰサーバといったＴＣＰセンダを有効に制御できないという難点がある。したがって、ゲートウェイ末端で非リアルタイムトラフィックを制御可能であり、さらにユーザ末端でいかなる特別な装置をも使用することなくＴＣＰの環境に適した装置および方法が必要とされる。
【００１０】
以上、チャネルの利用可能なバンド幅をリアルタイムおよび非リアルタイムトラフィックに対して共有させる、ネットワークにおけるバンド幅管理について記載した上述の広く知られた方法は、上述したようにいくつかの欠点がある。よって、リアルタイムストリームが所望のＱｏＳを設定できるように、非リアルタイムストリームのバンド幅要求を制御可能なバンド幅管理の実現が必要とされる。また、ネットワークにおいてユーザの末端に位置するゲートウェイ上に、このような解決策を実現することが必要とされる。
【００１１】
［発明の概要］
ネットワークにおけるクォリティーオブサービスを保証するシステムを開示する。ネットワークには、ゲートウェイに接続されたＴＣＰトラフィックなどのリアルタイムおよび
非リアルタイム転送を共有する１つの通信チャネルが使用される。非リアルタイムストリームは、フローコントロールパラメータ（flow control paramerter)やウインドウ(window)を有する非リアルタイムセンダを用いて転送される。ゲートウェイはさらに、様々なネットワーク要素を備えたネットワークに接続される。ゲートウェイは、非リアルタイムセンダのフローコントロールパラメータを調整することで非リアルタイム転送のバンド幅要求を制御する、バンド幅コントロールユニットを備えている。リアルタイムストリームは、適切なバンド幅を要求し、遅延やジッタのようなＱｏＳパラメータを保つ（support)。バンド幅コントロールは、非リアルタイムコネクションのバンド幅要求を調節することで、リアルタイムストリームによって要求されるバンド幅を保証するものである。バンド幅コントロールはまた、複数の非リアルタイムＴＣＰコネクション間でバンド幅を動的に割り当てることができる。このため、所定のＴＣＰコネクションのＴＣＰスロースタート（slow start)までの間利用可能な未使用バンド幅は、別の定常状態のＴＣＰコネクションに割り当てることができる。
【００１２】
本発明のさらなる応用範囲は、以後下記の詳細な記述から明らかになるであろう。なお、詳細な説明および具体例は、本発明の好ましい実施形態を表したものにすぎず、本発明の適応範囲を当該説明に限定する意図ではないことに留意すべきである。
【発明を実施するための最良の形態】
【００１３】
以下の好ましい実施形態の記載は本質を単に示したにすぎず、本発明、その応用、またはその利用を制限することを意図するものではない。
【００１４】
図１は、バンド幅管理を説明するためのネットワーク構成１０を示す。本発明に係るバンド幅管理の原理は、典型的なネットワーク構成１０を用いて説明される。このため、ネットワーク構成１０を以下で詳細に記載する。ネットワーク構成１０の構成要素を以下に記載する。ＶｏＤサーバ１２およびＩＰ（Internet Protocol)電話１４は、プライベートネットワーク１６に接続される。ＶｏＤサーバ１２はＶｏＤ（Video-on-Demand）転送を提供し、さらにＩＰ電話１４はＩＰプロトコルを利用したフォンライク（phone-like)コミュニケーションサービスをネットワークユーザに提供する。ＦＴＰサーバ１８およびＨＴＴＰサーバ２０は、インターネットサーバ２２に接続される。一般的に、ＶｏＤサーバ１２およびＩＰ電話１４は、厳格な時間制約があるリアルタイム形式で転送する。対照的に、ＦＴＰサーバ１８およびＨＴＴＰサーバ２０は、比較的厳格な時間制約がある非リアルタイム形式で情報を転送する。当業者であれば、ネットワークにおける以下の記載は、単に例を説明しただけにすぎず、本発明はあらゆる好適なネットワーク構成の形式をも含むことを理解できるであろう。
【００１５】
インターネットサーバ２２およびプライベートネットワーク１６双方は、ＩＳＰエッジルータ２４に接続される。アクセスセグメント２６は、エッジルータ２４をゲートウェイ２８に接続する。アクセスセグメント２６は、ＩＳＰエッジルータ２４およびゲートウェイ２８間のデータ送受信の通信チャネルである。アクセスセグメント２６は一般的に、ｘＤＳＬ、ＩＳＤＮまたは同軸ケーブルのようなブロードバンドコネクションであるが、ダイアルアップ電話回線でもよい。アクセスセグメント２６は、エッジルータ２４を経由して転送されたリアルタイムおよび非リアルタイムストリーム双方を同時に伝送する。ストリームは、データフローの論理チャネルである。リアルタイムストリームは、ＶｏＤのようなアプリケーションに対してリアルタイムのデータを伝送する。ここでいう非リアルタイムストリームとは一般的に、ＴＣＰ、または適当なプロトコルを利用した類似の論理通信エクスチェンジである。当業者であれば、ここで用いている用語“ストリーム”は、データまたは情報の連続した並びを示すものとして、一般的に広い定義で使用されていることを理解できるであろう。
【００１６】
リアルタイムストリームは、非リアルタイムＴＣＰトラフィックと同一のアクセスセグメント２６のバンド幅を共有する。したがって、バンド幅管理についての方法またはアルゴリズムは、利用可能なバンド幅をリアルタイムと非リアルタイムストリームとの間で割り当てることを要求される。総バンド幅のうちほとんどのバンド幅は、厳格なＱｏＳ要求をするリアルタイムストリームに割り当てる必要がある。このため、上記のような方法またはアルゴリズムでは、入力ＴＣＰトラフィックを制限しなければならない。以下に、エッジルータ２４の好ましい特性について記載する。
【００１７】
エッジルータ２４は、サービスプロバイダと通信するネットワークユーザのための中継点（connection point)である。エッジルータ２４は、インターネットホストからゲートウェイ２８にパケットを転送可能な機能を有していれば、どのような汎用目的の装置であってもよい。エッジルータ２４は、ゲートウェイ２８とインターネットサーバ２２との間で、ＩＰパケットを送受信するものである。このため、上記のサービスを提供するルータであれば、ここでいうエッジルータ２４として使用してもよい。エッジルータ２４は、インターネットおよび他のトラフィックを多重化するような他の機能も有している。しかし、このような付加的な機能は本発明では必要ない。本発明に関連する機能は、インターネットホストからゲートウェイ２８にＩＰパケットを送受信する機能のみである。以下に、アクセスセグメント２６を通して送信されるデータストリームの特徴について記載する。
【００１８】
リアルタイムメディアストリームは、ＩＰまたは非ＩＰトラフィックとして転送され得る。ここで関連すると考えられるリアルタイムストリームの特性の１つは、リアルタイムストリームがパケット化されていることである。これは、リアルタイムストリームが、パケットで送信されること、厳格な時間制約を有していること、およびあらゆるパケット遅延がリアルタイムストリームの性能特性にとって好ましいことではないことを意味する。アクセスセグメント２６を通して送信されたリアルタイムストリームは、十分なバンド幅、最小遅延および最小ジッタまたはジッタなしのような厳しいＱｏＳ要求をおこなう。ＶｏＤサーバ１２およびＩＰ電話１４からのメディアストリームは、あらゆるリアルタイムストリームのうちの一例にすぎず、本発明におけるリアルタイムストリーム情報の数または形式を制限するものではない。リアルタイムストリーム転送形式については構成に応じて変化するため特に考慮しない。本発明の原理は、一定のバンド幅要求をおこない、所定のＱｏＳパラメータ集合を保証するリアルタイム転送形式に適応される。バンド幅管理方法の実現にとって好ましいネットワーク位置はゲートウェイ２８である。以下に、ゲートウェイ２８の好ましい特性について記載する。
【００１９】
ゲートウェイ２８は、アクセスセグメント２６とネットワーク３０とを接続する。ネットワーク３０はたとえば、ＩＥＥＥ  １３９４、イーサネット、８０２．１１無線ＬＡＮ、およびパワーラインネットワークのような多重化されたネットワーク技術を用いることによって構成され得る。ゲートウェイ２８は、従来のゲートウェイであってもよいし、または分離して設置されたルータであってもよい。ゲートウェイ２８は、ネットワークにおいて、ホームネットワーク３０をエッジルータ２４に接続する中継点（interconnection point)である。ゲートウェイ２８はまた、デジタルテレビジョンまたはセットトップボックスのような装置に内蔵可能である。ゲートウェイ２８の機能は、あるインタフェースで連絡したインターネットコネクションと他のインタフェースで連絡した、構成装置が接続されたネットワーク３０との間の接続を提供することである。ゲートウェイ２８は、ネットワーク３０とエッジルータ２４との中継点として使用される。以下に、ホームネットワーク３０およびこれに関連したネットワーク要素について記載する。
【００２０】
ネットワーク要素群は、ホームネットワーク３０を通してゲートウェイ２８に接続される。テレビジョン３２、コンピュータ３４、およびＩＰ電話１４のような様々な装置が、ネットワーク３０に接続される。当業者であれば、ここで示されたネットワーク要素が、
ホームネットワーク３０に接続される装置の種類の説明にのみ用いられていることを理解できるであろう。上記で示した装置または機器は、単に説明のための一例として挙げたものであって、他の多くの装置もまた、ホームネットワーク３０に接続することができる。
【００２１】
図２は、１つのＴＣＰセンダを有し、バンド幅管理を実現したネットワークの構成例を示す。当業者であれば、バンド幅管理を備えたネットワークとこれを備えていないネットワークとを比較することで、本発明をより明確に理解できるであろう。１つのＴＣＰセンダを有したネットワークにおけるバンド幅管理は２つの工程で示される。第１の工程では、バンド幅管理が行われていないと想定して、ネットワークの性能がシミュレートおよび解析される。このようなシミュレーションによって、バンド幅管理を備えたネットワークと備えていないネットワークとの相違が分かる。第２の工程では、上記と同一のネットワークがシミュレートおよび解析されるが、この場合バンド幅コントロールを用いて、１つのＴＣＰセンダのネットワークに対して本発明の原理が実現される。したがって最初、図２で示されたネットワークは、以下に記載するようにバンド幅コントロールがされないと想定して、シミュレートおよび解析される。
【００２２】
以下の記載は、バンド幅コントロールについての必要性を確証するものである。後で示すものと比較するため、図２で示したバンド幅制コントロールは存在しないものと想定する。ここに記載されたネットワークは、バンド幅管理を用いない典型的なネットワークの性能特性のシミュレーションに利用される。ＶｏＤサーバ１２、ＨＴＴＰサーバ２０、インターネットサーバ２２、エッジルータ２４およびゲートウェイ２８は、図１で示したものと同様に接続される。
【００２３】
ここでいうネットワークにおけるアクセスセグメント２６はたとえば、ダウンストリームおよびアップストリームを、それぞれ２．０Ｍｂｐｓおよび０．７Ｍｂｐｓのバンド幅で転送できるＡＤＳＬリンクのような専用の非対称リンクである。一般に、エッジルータ２４およびゲートウェイ２８はお互いに近接しているため、アクセスセグメント２６を経由する時間はわずか１ミリ秒である。
【００２４】
ＶｏＤサーバ１２は、データ転送時間が２０ミリ秒である全２重（full-duplex)ＶｏＤリンク３６によってエッジルータ２４に接続される。ＶｏＤサーバ１２は、リアルタイム形式で１．０ＭｂｐｓのレートであるＣＢＲ（Constant Bit Rate）を有するビデオ信号を転送する。ＨＴＴＰサーバ２０は、（図２で示したような）インターネットサーバ２２の構成要素の一部として設定されるか、または（図１に示したような）インターネットサーバ２２と外的に接続され得る。ＨＴＴＰサーバ２０は、１．５Ｍｂｐｓのバンド幅を有し、２０ミリ秒でデータ転送可能な全２重ＨＴＴＰリンク３８を経由して、非リアルタイムデータパケットを転送する。
【００２５】
エッジルータ２４は、２０個のパケットを格納可能な容量（capacity)を有したＦＩＦＯ（First-In First-Out）キュー４０を有する。ＶｏＤサーバ１２から送信されたリアルタイムストリームは、アクセスセグメント２６の計２Ｍｂｐｓのダウンワード容量４２から１Ｍｂｐｓのバンド幅を要求する。この結果、ＨＴＴＰサーバ２０は、ゲートウェイ２８に転送する非リアルタイムトラフィックに対して、最大でも１．０Ｍｂｐｓの容量で、パケットトラフィックを転送することができる。
【００２６】
図３および図４は、非リアルタイムストリームの管理バンド幅要求において、バンド幅コントロールを使用しないネットワークに係るネットワークシミュレーションの結果を示した図である。最初に、シミュレーション技術についての基礎的な情報をいくつか記載する。
【００２７】
ネットワークシミュレータは、バンド幅管理を備えたネットワーク性能と備えていないネットワーク性能とを比較するシミュレーションを実行するのに用いられる。以下に記載するようなシミュレーションを実行可能であれば、どのような一般的なネットワークシミュレータを用いてもよい。たとえば、‘ｎｓ  ＵＣＢ／ＬＢＮＬ／ＶＩＮＴ’ネットワークシミュレータを用いてもよい。５７６バイトのパケットサイズのＵＤＰ（User Datagram Protocol）を使用してデータを送信するＣＢＲ情報源によって、ＶｏＤストリームはモデル化される。非リアルタイムデータに対するＴＣＰコネクションは、ＨＴＴＰサーバ２０でのＴＣＰ／Ｒｅｎｏ情報源、およびゲートウェイ２８でのＴＣＰシンク（sink)を使用することでモデル化される。最大セグメントサイズは５７６バイトに設定され、初期フローコントロールウインド４６のサイズは３２パケットに設定される。ＴＣＰのフローコントロールウインドウ４６のサイズは、大部分のオペレーティングシステムでは１６キロバイトまたは３２キロバイトである。したがって、ＨＴＴＰサーバ２０は、常にサイズ５７６バイトのＴＣＰパケットを送信し、転送では６４以上の応答確認されていないＴＣＰセグメントを有さない。以下に記載のＴＣＰセンダとは、ＨＴＴＰダウンロード５２をゲートウェイ２８に転送するＨＴＴＰサーバ２０を示している。ネットワークシミュレーションについて基礎的な情報を示すため、以下に、適当な図を用いて具体的なシミュレーションを記載する。
【００２８】
図３は、バンド幅管理をおこなわないリアルタイムおよび非リアルタイムストリームに係る平均バンド幅を示したグラフである。グラフのＸ軸の数値は秒を示し、グラフのＹ軸の数値は平均バンド幅（Ｍｂｐｓ）を示す。平均バンド幅は、ゲートウェイ２８で０．１秒ごとに算出される。グラフは、明らかにＶｏＤストリーム５０が遅延およびジッタのようなＱｏＳパラメータを満足するのに必要な１Ｍｂｐｓの一定したバンド幅を得られないことを示している。
【００２９】
さらに、ＨＴＴＰダウンロード５２もまた、エッジルータ２４（図２参照）でのパケットドロップ（drop)に起因して無秩序な振る舞いをみせている。ＨＴＴＰサーバ２０（図２参照）が１Ｍｂｐｓ以上のバンド幅を要求するＨＴＴＰダウンロード５２を注入（pumping)し始めるたびに、エッジルータ２４はリアルタイムおよび非リアルタイムストリーム双方からパケットをドロップし始める。この問題は、時間１．４秒、３．５秒に発生し、以後周期的に繰り返される。
【００３０】
ちょうど、時間１．４秒でＨＴＴＰダウンロード５２のパケットが減少し始めるのに応じて、ＴＣＰ輻輳（congestion)ウインドウ４８（図２参照）は小さくなり、輻輳を調整する。これにより、ＨＴＴＰサーバ２０はパケット転送のレートを削減する。ＨＴＴＰダウンロード５２におけるこのようなレートの削減は、ＶｏＤストリーム５０にとって、有益である。しかし、削減されたＨＴＴＰダウンロード５２はいくらかのバンド幅を未使用のままにしておくため、アクセスセグメント２６のバンド幅は使用状態となる。この削減されたＨＴＴＰダウンロード５２によるバンド幅の使用状態は、ＴＣＰセンダがこの削減されたパケットを取り戻し、送信レートを増加させるまで継続する。一旦、ＴＣＰセンダが削減されたパケットを完全に取り戻し、時間３．５秒付近で１Ｍｂｐｓの制限を超えて送信し始めたならば、エッジルータ２４は、上述の時間１．４秒で発生したものと同様な振る舞いの原因となるストリーム双方からパケットを再びドロップする。そしてこのサイクルは、シミュレーションの終わりまで継続する。
【００３１】
図４は、ＶｏＤストリーム５０に係る平均インターパケット（inter-packet)時間について示す。グラフのＸ軸の数値は秒を示し、グラフのＹ軸の数値は平均インターパケット時間（Ｍｂｐｓ）を示す。
【００３２】
ジッタは、リアルタイム転送にとって好ましくない特性である。ジッタは、平均インタ
ーパケット時間によってうまく表される。変動するインターパケット時間は、より多くのジッタの原因となる。ＨＴＴＰサーバ２０が１Ｍｂｐｓのレベルを超えてＨＴＴＰダウンロード５２（図３参照）を注入し始めるとすぐに、ＶｏＤストリーム５０（図３参照）のパケットは、ＦＩＦＯキュー４０（図２参照）において遅延が起こり、これがインターパケット時間を増加させる。この後、ＨＴＴＰサーバ２０がパケットのドロップを検出し、パケット送信におけるパケットのドロップのレートを削減すると、ＦＩＦＯキュー４０で待ち行列に入っているパケットはすぐに続けて送信され、インターパケット時間が減少する。インターパケット時間の増加または減少に関する上述した事例は双方、好ましいものではない。また、上述のどちらかは、ゲートウェイ２８上の別末端でアンダーフローまたはオーバーフローの原因となる。理想的に、インターパケット時間は、ジッタなしの線５４で示されたレベルで固定されるものがよい。転送の間でジッタが発生し、さらに問題の原因となる区間はジッタ領域５６で示される。以下に、上述した第２の工程において、本発明の原理を用いた１つのＴＣＰセンダのためのバンド幅管理を含めて、図２に示したような完全なネットワークについて説明する。
【００３３】
リアルタイムおよび非リアルタイム転送を１つの転送チャネルでおこなうネットワークの構成は、上述したようにバンド幅の割り当ての問題に直面する。以下に記載のものは、１つの転送チャネルに関するものである。しかし、当業者であれば、本発明は複数の転送チャネルであっても実現可能であることを理解できるであろう。
【００３４】
バンド幅管理は、リアルタイムストリームのＱｏＳ要求に忠実であることが求められる。バンド幅管理はまた、アクセスセグメント２６の総チャネル利用 および非リアルタイムネットワークトラフィックのスループットを向上させる。バンド幅管理は、リアルタイムストリームについてのＱｏＳ基準を保証する。バンド幅管理は、ネットワークにおいて制御をおこなう場所の選択を要求し、そこでバンド幅コントロール方法を実現する。バンド幅コントロールを実現するネットワークにおいて、ゲートウェイ２８は、本発明にとって好適な場所である。
【００３５】
再び図２を参照しながら、以下に、１つのＴＣＰセンダにおける本発明のバンド幅管理技術について記載する。一般的なネットワーク設定において、ＨＴＴＰサーバ２０のようなＴＣＰセンダは、ＴＣＰレシーバまでのチャネルにおいて利用可能なバンド幅を事前に知ることはないであろう。本実施形態におけるゲートウェイ２８のようなＴＣＰレシーバは、利用可能なチャネルのバンド幅について認識しているであろう。また、リアルタイムトラフィックが、２．０Ｍｂｐｓの総アクセスセグメント２６の下方の容量から、１Ｍｂｐｓの想定されたバンド幅を必要としているため、ゲートウェイ２８は、ＴＣＰトラフィックが１Ｍｂｐｓを超えるべきではないことを事前に認識するであろう。
【００３６】
ゲートウェイ２８は、リアルタイムおよび非リアルタイムストリームのバンド幅要求について認識し、非リアルタイムを制御する。ここで、非リアルタイムとは、非リアルタイムストリームに利用可能なバンド幅を超えないように、ＨＴＴＰサーバ２０から送信されたＴＣＰトラフィックのことを示す。これにより、リアルタイムストリームは、要求されるＱｏＳ基準を満たすことができる。
【００３７】
バンド幅コントロール６０は、ゲートウェイ２８末端からデータフローを制御することでリアルタイムストリームのＱｏＳ要求を保証することができる。バンド幅コントロール６０は、ハードウェアで実現することができるが、ソフトウェアモジュールとして、またはハードウェアとソフトウェアとの組み合わせとしてでも実現することができる。ゲートウェイ２８末端から非リアルタイムトラフィックのフローを制御することで、インターネットのサービスプロバイダ側においてエッジルータ２４からのトラフィックを制御する解決策と関連する起こり得るスケーラビリティー問題をなくすことができる。
【００３８】
もし、バンド幅管理の解決策がエッジルータ２４末端で行われるのであれば、リアルタイムおよび非リアルタイムトラフィックストリームごとにゲートウェイ２８とエッジルータ２４との間のバンド幅の調整プロセスをおこなうべく、別々のプロトコルが要求される。バンド幅コントロール６０をゲートウェイに実現することによって、上記の問題は解消される。以下に、バンド幅をゲートウェイ２８から管理する方法の詳細について記載する。
【００３９】
以下に、１つのＴＣＰコネクションについて考慮し、これより後に、複数のＴＣＰコネクションについて考慮する。ＴＣＰセンダ（ＨＴＴＰサーバ２０）は、“ｒｔｔ”（round trip time）セグメントごとに‘ｗｎｄ’個のパケットをＴＣＰレシーバ（ゲートウェイ２８）に送信する。ｒｔｔセグメントごとに送信された‘ｗｎｄ’個のパケットは、アクティブウインドウサイズであるｗｎｄ＝ｍｉｎ｛ｃｗｎｄ，ｆｗｎｄ｝として計算される。ＴＣＰセンダは、常に“ｃｗｎｄ”および“ｆｗｎｄ”と呼ばれる２つの変数つまりパラメータを保持する。ｃｗｎｄは、“congestion control window”（輻輳コントロールウインドウ）を意味しており、受信した応答確認およびパケットドロップを基に、ＴＣＰセンダで計算される。ｃｗｎｄパラメータは、完全にＴＣＰセンダにより制御される。ｆｗｎｄパラメータは、“flow control window”（フローコントロールウインドウ）を意味しており、ＴＣＰレシーバによって設定される。
【００４０】
ｒｔｔセグメントでのＴＣＰコネクションに関するデータレート“ｂ”は、ｂ＝ｗｎｄ／ｒｔｔで与えられる。所定のＴＣＰコネクションにおけるスロースタート（slow start)フェーズを考慮すると、もしコネクションがセンダのクロックで時刻ｔ0に開始されるならば、時刻ｔ（ｔ＞ｔ0）でパケットドロップがないと仮定すると、センダはパケットを以下の式で示されるように送信する。
【００４１】
【数１】
2005536921.tif 000003
【００４２】
もし、パケットのドロップを考慮するならば、さらに複雑なスループットの公式がよく知られた方法によって導出される。
【００４３】
“定常状態”（steady state)コネクションは、送信されたパケットの数がｆｗｎｄパラメータにより完全に決定されるコネクションのことである。定常状態である所定のコネクションにおいて、ｃｗｎｄの値は、ｆｗｎｄパラメータの値よりも高いものでなければならない。定常状態において、ＴＣＰセンダの出力は、ＴＣＰレシーバによって完全に制御可能であり、上記の数式１で与えられる。
【００４４】
ゲートウェイ２８は、ＴＣＰセンダのもう一方の末端で検出されるフローコントロールウインドウｆｗｎｄiのサイズを操作することで非リアルタイムトラフィックを制御する。ここに記載する説明では、非リアルタイムトラフィック、すなわちＴＣＰトラフィックは、１Ｍｂｐｓの制限を超えない。もし最大ＴＣＰセグメントのサイズが５７６バイトであり、ゲートウェイ２８とＨＴＴＰサーバ２０との間のｒｔｔがシミュレーションに基づいて導出された４７ミリ秒であるならば、ゲートウェイ２８は、フローコントロールウインドウのサイズ、すなわち、ｆｗｎｄiの値を（１Ｍｂｐｓ＊４７ｍｓ）／（５７６＊８ｂｉｔｓ）＝１０パケットに設定する。ｆｗｎｄiの値を１０パケットに設定することで、輻輳ウィンドウのサイズにかかわらず、ＴＣＰコネクションの最大データレートが１Ｍｂｐｓを決して超えることがないようにすることできる。
【００４５】
図５は、複数のＴＣＰコネクションを有し、バンド幅管理を実現するネットワークの構成を示す。示されたネットワークの構成は、図２で示したものと概念的および構造的に類似している。図５で示したネットワークは、１．５Ｍｂｐｓのバンド幅が要求される情報
を送信し、エッジルータまでの送信時間が２０ミリ秒であるＦＴＰサーバ１８形式の付加的なＴＣＰセンダを含んでいる。バンド幅コントロール６０は、ゲートウェイ２８からフローコントロールを操作することに利用される。
【００４６】
図６は、すべてのストリーム、すなわちリアルタイムおよび非リアルタイムストリーム双方の総バンド幅を通して、各ストリームの平均バンド幅について示す。時間０秒で、ＶｏＤサーバ１２が１ＭｂｐｓのレートでリアルタイムのＣＢＲビデオを注入し始める。時間１秒で、ネットワークユーザが、ＦＴＰサーバ１８からＦＴＰダウンロードを開始する。時間３秒付近で、ネットワークユーザが、ＨＴＴＰサーバ２０からウェブページダウンロードを開始する。ダウンロードされたウェブページは、ウェブページの一部としてダウンロードされた映像およびオーディオクリップのような多重化された項目を有していると想定する。ウェブブラウザ（図示なし）は、４つの同時ＴＣＰコネクション、すなわちＨＴＴＰダウンロード５２a、５２b、５２c および５２d を開始し、ウェブページおよびこれに関する多重化された項目をダウンロードする。４つのＨＴＴＰダウンロード５２a、５２b、５２c および５２d は、時間４．５秒付近で終了し、シミュレーションは、時間５秒で終了する。
【００４７】
ＶｏＤストリーム５０は明らかに、アクティブＴＣＰコネクションの数によらず連続して１Ｍｂｐｓを維持している。ＨＴＴＰダウンロード５２が時間２秒付近で開始されたとき、バンド幅コントロール６０はＦＴＰダウンロード５８についてデータレートを削減する。バンド幅コントロール６０が上記のデータレートを削減することにより、総非リアルタイムトラフィックは非リアルタイムトラフィックの使用可能範囲である１Ｍｂｐｓのバンド幅を決して超えることはない。バンド幅コントロール６０は、リアルタイムストリームが自身のＱｏＳ要求を保証するのに十分なバンド幅を受け取るように、それぞれ異なる非リアルタイムデータコネクションを調整する。したがって、バンド幅コントロール６０は、いくつかのＴＣＰセンダでそれぞれ異なるフローコントロールウインドウを扱うことで総非リアルタイムのバンド幅を調整する。
【００４８】
以下に、複数のＴＣＰコネクションに関して、本発明の原理を用いたバンド幅管理技術について記載する。まず、ｎ個の非リアルタイムコネクションの集合をＮとする。各々の非リアルタイムコネクションは一般的に、ＨＴＴＰまたはＦＴＰコネクションである。ｒｔｔiを所定のコネクションｉのｒｔｔの評価とする。ｒｔｔiは、以下に示すように計算される。
【００４９】
ゲートウェイ２８は、コネクションを設定時に応答確認を受け取るのに求められる時間について初期評価をおこなう。Ｒはリアルタイムストリームの集合とし、ＢiはＲに含まれる所定のリアルタイムストリームｉに要求されるバンド幅とする。ここで、Ｒのストリームは、ＣＢＲを要求する。上述したパラメータｎ、ｉ、ｒｔｔi、Ｂi、集合ＮおよびＲは時間についての関数とし、必要であれば分かるように記載する。
【００５０】
ＴＣＰセンダｉがｗｎｄi＝ｍｉｎ｛ｃｗｎｄi，ｆｗｎｄi｝を送信した後の目標は、コネクションについてスループットｂi＝ｗｎｄi／ｒｔｔiを最大にすることである。スループットの最大化は、以下で与えられる不等式を条件とする。
【００５１】
【数２】
2005536921.tif 000004
【００５２】
ここで、ＢCは、アクセスセグメント２６の全容量である。
【００５３】
もし、コネクションがすべて同じように重要であるならば、数式２を条件とする各ｉにおける定常状態のフローコントロールウインドウのサイズは、以下の式で示すように保存限界（conservative bound)で与えられる。
【００５４】
【数３】
2005536921.tif 000005
【００５５】
静的なスケジューリングポイントは、新しいコネクションが設定されるか、または既存のコネクションがなくなるかのいずれかの時刻として定義される。以下に、静的なバンド幅の割り当てにおける手続きまたはアルゴリズムについて示す。
【００５６】
【数４】
2005536921.tif 000006
【００５７】
図７は、動的なバンド幅管理の性能特性についてのグラフを示す。段落［００３８］に記述したアルゴリズム（以下、単に“アルゴリズム”と称する）は、以下で示すようにさらに改良することができる。アルゴリズムは、静的に動作し、総非リアルタイムＴＣＰトラフィックのバンド幅を制限し、リアルタイムトラフィックに要求されるＱｏＳを保証する。アルゴリズムは、非リアルタイムコネクションの数には依存しない。静的なバンド幅割り当てでなく動的なバンド幅割り当てを用いることで、非リアルタイムコネクションの実行および全体のチャネル利用についてのさらなる改善が可能となる。以下に、本発明に係るバンド幅の動的な割り当て技術について記載する。
【００５８】
改善を説明するため、例として以下の表を用いる。
【００５９】
【表１】
2005536921.tif 000007
【００６０】
まず、アルゴリズムの動作について考察する。初期状態として、ｒｔｔが１秒である１つのＴＣＰコネクションのみがあるものとする。もし、アクセスセグメント２６（図５参照）における利用可能な容量が１６パケット／秒であれば、最初のＴＣＰコネクションは１つだけのため、利用可能な容量をこのコネクションに十分利用することができる。次の期間の始めに、ｒｔｔが１秒の別のＴＣＰコネクションが起こる。アルゴリズムに従って、最初のＴＣＰコネクションおよび次のＴＣＰコネクションが各々ｂ＝８パケット／秒となるように、利用可能なバンド幅がこれらのＴＣＰコネクションの間で分割される。しかし、ＴＣＰのスロースタートのため、次のＴＣＰコネクションについてはすぐにはｂ＝８パケット／秒で開始できない。次のＴＣＰコネクションは、定常状態レートであるｂ＝８パケット／秒に達するまで、期間２、３、および４において、それぞれ１、２、および４個のパケットのみを送信する。静的なバンド幅割り当ては、ＴＣＰスロースタートメカニズムを補うものではない。実現された静的なバンド幅割り当てでアルゴリズムを用いると、期間２、３、および４においてそれぞれ７、６および４パケットの未使用バンド幅が残ってしまう。
【００６１】
前例を考慮すると、最初のＴＣＰコネクションは、次のＴＣＰコネクションが定常状態になるまで未使用バンド幅が割り当てられる。したがって、最初のＴＣＰコネクションは、期間２、３、および４で、それぞれ１５、１４、および１２のパケットを送信する。次のコネクションは、期間５で定常状態に達し、このときに、割り当てられた８パケットのバンド幅すべてを使用することができる。また第１のＴＣＰコネクションも８パケットとなる。
【００６２】
バンド幅コントロール６０を用いた動的なバンド幅の割り当てについてのシミュレーションを示す。システムのシミュレーションに用いられるネットワークは、図５で示したものと同様である。リアルタイムストリームは静的なバンド幅の割り当ての場合と同様な性能を示すため、非リアルタイムストリームであるＨＴＴＰダウンロード５２およびＦＴＰダウンロード５８についてのバンド幅のみを示す。静的および動的なバンド幅コントロール双方は、リアルタイムストリームのＱｏＳ要求を満足することを保証する。動的なバンド幅の割り当てはスループットを向上させるため、静的なバンド幅の割り当てよりも性能がよい。
【００６３】
動的割り当てを実行して時間３秒付近で１つの変化がある。ＨＴＴＰダウンロードにおける４つのコネクション、すなわちＨＴＴＰダウンロード５２a、５２b、５２c、および５２dが開始されるときには、動的なバンド幅割り当てがされたＦＴＰダウンロード５８aは、すでに定常状態となっている。アルゴリズムで示されたような静的なバンド幅の割り当ての場合では、バンド幅コントロールは利用可能なバンド幅をすべてのアクティブコネクション間で即座に分配していた。しかし、動的な割り当ての場合では、最近開始された４つのＨＴＴＰコネクションがスロースタートモードであろうという事実によって、すでに定常状態となっているＦＴＰダウンロードに、ＨＴＴＰダウンロードのスロースタートの間利用可能である未使用バンド幅が割り当てられる。動的な割り当てがされたＦＴＰダウンロード５８aのまさに３秒付近の変化で示されるように、ＦＴＰダウンロードの性能は改善されている。これは、動的な割り当てなしのＦＴＰダウンロード５８bを示したグラフにおけるプロットと比較することができる。したがって、動的な割り当ては、総利用可能バンド幅の利用を改善する。ＦＴＰコネクションについてのデータレートは、ＨＴＴＰダウンロード５２が定常状態に達するのと同様に、定常状態レートまで徐々に削減される。前述は、動的なバンド幅管理についての記載である。以下に、上記で参照したバンド幅コントロール６０についてさらに記載する。
【００６４】
バンド幅コントロール６０（図５参照）は、上述したアルゴリズムの代わりに動的なバンド幅の割り当てのアルゴリズムで動作するように設定することができる。すでに定常状態となっているＴＣＰコネクションに未使用のバンド幅を割り当てることで、動的なバンド幅の割り当て方法によって改善された性能が実現される。
【００６５】
本発明の特別な応用は、ホームネットワークユーザを対象に記載されている。上記すべての図は、ホームユーザを対象とした本発明の説明に用いられている。ホームネットワークユーザは一般的に、ゲートウェイ２８の具体的な型であるホームゲートウェイを通してインターネットに接続される。ユーザは、上記と同一のホームゲートウェイを通して、ビデオオンデマンドおよびＩＰ電話のような他のサービスにも接続される。ホームまたはレジデンシャルゲートウェイに接続されたホームネットワーク３０（図１参照）は、コンピュータ、テレビジョン、電話、ラジオなどの多様な機器に接続することができる。
【００６６】
上述のバンド幅管理の問題は、インターネットサービスプロバイダ末端でバンド幅管理技術を実現することが困難であるとの理由から、ホームユーザ側が直面するものである。ホームユーザは、ＴＣＰコネクションの実現におけるインターネットサービスプロバイダのメカニズムに対して制御を行なわない。このため、レジデンシャルまたはホームゲートウェイでバンド幅管理を実現することが求められる。
【００６７】
本発明の原理によると、ホームゲートウェイ内にバンド幅コントロール６０が実装される。バンド幅コントロールの動作については、上で詳細に記載した。上述の記載は、ホームネットワークユーザにも同様に適応される。特に、ホームユーザがリアルタイムデータストリームの専用チャネルの使用が高価であると気が付くと、リアルタイムおよび非リアルタイムＴＣＰトラフィック双方についてアクセスセグメント２６のチャネルを共有するようになるであろう。したがって、本発明は、ホームユーザがリアルタイムおよび非リアルタイムデータ双方とアクセスするために共有チャネルを利用することに有益である。
【００６８】
本発明の明細書は、本質を単に例示したものにすぎない。したがって、発明の本質から外れない程度の変形例は、本発明の範囲内であり、このような変形例は、本発明の本質および範囲から逸脱するものではない。
【図面の簡単な説明】
【００６９】
【図１】本発明の実施形態に係るバンド幅管理を説明するためのネットワークの構成図である。
【図２】１つのＴＣＰセンダを有し、本発明のバンド幅管理を実現するネットワークの構成例である。
【図３】バンド幅管理を行なわない場合のリアルタイムおよび非リアルタイムのストリームに係る平均バンド幅を示したグラフである。
【図４】ＶｏＤストリームに係る平均インターパケット時間を示した図である。
【図５】複数のＴＣＰコネクションを有し、バンド幅管理を実現するネットワークの構成図である。
【図６】各ストリームの平均バンド幅および総ストリームの全バンド幅を示したグラフである。
【図７】動的なバンド幅管理の性能特性を示したグラフである。
【図１】
2005536921.tif 000008
【図２】
2005536921.tif 000009
【図３】
2005536921.tif 000010
【図４】
2005536921.tif 000011
【図５】
2005536921.tif 000012
【図６】
2005536921.tif 000013
【図７】
2005536921.tif 000014
【国際調査報告】
2005536921.tif 000015
2005536921.tif 000016