JP4351159B2

JP4351159B2 - ネットワークゲートウェイにおけるクォリティオブサービスの管理

Info

Publication number: JP4351159B2
Application number: JP2004527661A
Authority: JP
Inventors: アキンラークネイト; エルバシオーニクハレド; カメルイブラヒム
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2002-08-12
Filing date: 2003-07-29
Publication date: 2009-10-28
Anticipated expiration: 2023-07-29
Also published as: EP1535130A4; AU2003259265A1; US20040030797A1; DE60323511D1; EP1535130B1; CN1672142B; WO2004015520A2; US7802008B2; JP2005536921A; EP1535130A2; CN1672142A; AU2003259265A8; EP1535130B9; JP4896177B2; WO2004015520A3; JP2009201123A

Description

本発明は、ネットワークにおけるクォリティオブサービスを保証することに関し、特に、リアルタイムおよび非リアルタイムデータストリームを送受信するネットワークについてクォリティオブサービスを保証することに関する。

ネットワークユーザは、インターネットや他の情報源からの様々な種類の情報とアクセスすることができる。ネットワークユーザがアクセスできる情報の種類は大きく、リアルタイムストリームと非リアルタイムストリームとの２種類に分けられる。たとえば、一般のユーザは、ビデオまたはオーディオのようなリアルタイムデータストリーム、そして、ｅメール、ウェブページ、またはＦＴＰ(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)フェーズを考慮すると、もしコネクションがセンダのクロックで時刻ｔ⁰に開始されるならば、時刻ｔ（ｔ＞ｔ⁰）でパケットドロップがないと仮定すると、センダはパケットを以下の式で示されるように送信する。

もし、パケットのドロップを考慮するならば、さらに複雑なスループットの公式がよく知られた方法によって導出される。

“定常状態”（steady state)コネクションは、送信されたパケットの数がｆｗｎｄパラメータにより完全に決定されるコネクションのことである。定常状態である所定のコネクションにおいて、ｃｗｎｄの値は、ｆｗｎｄパラメータの値よりも高いものでなければならない。定常状態において、ＴＣＰセンダの出力は、ＴＣＰレシーバによって完全に制御可能であり、上記の数式１で与えられる。

ゲートウェイ２８は、ＴＣＰセンダのもう一方の末端で検出されるフローコントロールウインドウｆｗｎｄ_iのサイズを操作することで非リアルタイムトラフィックを制御する。ここに記載する説明では、非リアルタイムトラフィック、すなわちＴＣＰトラフィックは、１Ｍｂｐｓの制限を超えない。もし最大ＴＣＰセグメントのサイズが５７６バイトであり、ゲートウェイ２８とＨＴＴＰサーバ２０との間のｒｔｔがシミュレーションに基づいて導出された４７ミリ秒であるならば、ゲートウェイ２８は、フローコントロールウインドウのサイズ、すなわち、ｆｗｎｄ_iの値を（１Ｍｂｐｓ＊４７ｍｓ）／（５７６＊８ｂｉｔｓ）＝１０パケットに設定する。ｆｗｎｄ_iの値を１０パケットに設定することで、輻輳ウィンドウのサイズにかかわらず、ＴＣＰコネクションの最大データレートが１Ｍｂｐｓを決して超えることがないようにすることできる。

図５は、複数のＴＣＰコネクションを有し、バンド幅管理を実現するネットワークの構成を示す。示されたネットワークの構成は、図２で示したものと概念的および構造的に類似している。図５で示したネットワークは、１．５Ｍｂｐｓのバンド幅が要求される情報
を送信し、エッジルータまでの送信時間が２０ミリ秒であるＦＴＰサーバ１８形式の付加的なＴＣＰセンダを含んでいる。バンド幅コントロール６０は、ゲートウェイ２８からフローコントロールを操作することに利用される。

図６は、すべてのストリーム、すなわちリアルタイムおよび非リアルタイムストリーム双方の総バンド幅を通して、各ストリームの平均バンド幅について示す。時間０秒で、ＶｏＤサーバ１２が１ＭｂｐｓのレートでリアルタイムのＣＢＲビデオを注入し始める。時間１秒で、ネットワークユーザが、ＦＴＰサーバ１８からＦＴＰダウンロードを開始する。時間３秒付近で、ネットワークユーザが、ＨＴＴＰサーバ２０からウェブページダウンロードを開始する。ダウンロードされたウェブページは、ウェブページの一部としてダウンロードされた映像およびオーディオクリップのような多重化された項目を有していると想定する。ウェブブラウザ（図示なし）は、４つの同時ＴＣＰコネクション、すなわちＨＴＴＰダウンロード５２_a、５２_b、５２_c および５２_d を開始し、ウェブページおよびこれに関する多重化された項目をダウンロードする。４つのＨＴＴＰダウンロード５２_a、５２_b、５２_c および５２_d は、時間４．５秒付近で終了し、シミュレーションは、時間５秒で終了する。

ＶｏＤストリーム５０は明らかに、アクティブＴＣＰコネクションの数によらず連続して１Ｍｂｐｓを維持している。ＨＴＴＰダウンロード５２が時間２秒付近で開始されたとき、バンド幅コントロール６０はＦＴＰダウンロード５８についてデータレートを削減する。バンド幅コントロール６０が上記のデータレートを削減することにより、総非リアルタイムトラフィックは非リアルタイムトラフィックの使用可能範囲である１Ｍｂｐｓのバンド幅を決して超えることはない。バンド幅コントロール６０は、リアルタイムストリームが自身のＱｏＳ要求を保証するのに十分なバンド幅を受け取るように、それぞれ異なる非リアルタイムデータコネクションを調整する。したがって、バンド幅コントロール６０は、いくつかのＴＣＰセンダでそれぞれ異なるフローコントロールウインドウを扱うことで総非リアルタイムのバンド幅を調整する。

以下に、複数のＴＣＰコネクションに関して、本発明の原理を用いたバンド幅管理技術について記載する。まず、ｎ個の非リアルタイムコネクションの集合をＮとする。各々の非リアルタイムコネクションは一般的に、ＨＴＴＰまたはＦＴＰコネクションである。ｒｔｔ_iを所定のコネクションｉのｒｔｔの評価とする。ｒｔｔ_iは、以下に示すように計算される。

ゲートウェイ２８は、コネクションを設定時に応答確認を受け取るのに求められる時間について初期評価をおこなう。Ｒはリアルタイムストリームの集合とし、Ｂ_iはＲに含まれる所定のリアルタイムストリームｉに要求されるバンド幅とする。ここで、Ｒのストリームは、ＣＢＲを要求する。上述したパラメータｎ、ｉ、ｒｔｔ_i、Ｂ_i、集合ＮおよびＲは時間についての関数とし、必要であれば分かるように記載する。

ＴＣＰセンダｉがｗｎｄ_i＝ｍｉｎ｛ｃｗｎｄ_i，ｆｗｎｄ_i｝を送信した後の目標は、コネクションについてスループットｂ_i＝ｗｎｄ_i／ｒｔｔ_iを最大にすることである。スループットの最大化は、以下で与えられる不等式を条件とする。

ここで、Ｂ_Cは、アクセスセグメント２６の全容量である。

もし、コネクションがすべて同じように重要であるならば、数式２を条件とする各ｉにおける定常状態のフローコントロールウインドウのサイズは、以下の式で示すように保存限界（conservative bound)で与えられる。

静的なスケジューリングポイントは、新しいコネクションが設定されるか、または既存のコネクションがなくなるかのいずれかの時刻として定義される。以下に、静的なバンド幅の割り当てにおける手続きまたはアルゴリズムについて示す。

図７は、動的なバンド幅管理の性能特性についてのグラフを示す。段落［００３８］に記述したアルゴリズム（以下、単に“アルゴリズム”と称する）は、以下で示すようにさらに改良することができる。アルゴリズムは、静的に動作し、総非リアルタイムＴＣＰトラフィックのバンド幅を制限し、リアルタイムトラフィックに要求されるＱｏＳを保証する。アルゴリズムは、非リアルタイムコネクションの数には依存しない。静的なバンド幅割り当てでなく動的なバンド幅割り当てを用いることで、非リアルタイムコネクションの実行および全体のチャネル利用についてのさらなる改善が可能となる。以下に、本発明に係るバンド幅の動的な割り当て技術について記載する。

改善を説明するため、例として以下の表を用いる。

まず、アルゴリズムの動作について考察する。初期状態として、ｒｔｔが１秒である１つのＴＣＰコネクションのみがあるものとする。もし、アクセスセグメント２６（図５参照）における利用可能な容量が１６パケット／秒であれば、最初のＴＣＰコネクションは１つだけのため、利用可能な容量をこのコネクションに十分利用することができる。次の期間の始めに、ｒｔｔが１秒の別のＴＣＰコネクションが起こる。アルゴリズムに従って、最初のＴＣＰコネクションおよび次のＴＣＰコネクションが各々ｂ＝８パケット／秒となるように、利用可能なバンド幅がこれらのＴＣＰコネクションの間で分割される。しかし、ＴＣＰのスロースタートのため、次のＴＣＰコネクションについてはすぐにはｂ＝８パケット／秒で開始できない。次のＴＣＰコネクションは、定常状態レートであるｂ＝８パケット／秒に達するまで、期間２、３、および４において、それぞれ１、２、および４個のパケットのみを送信する。静的なバンド幅割り当ては、ＴＣＰスロースタートメカニズムを補うものではない。実現された静的なバンド幅割り当てでアルゴリズムを用いると、期間２、３、および４においてそれぞれ７、６および４パケットの未使用バンド幅が残ってしまう。

前例を考慮すると、最初のＴＣＰコネクションは、次のＴＣＰコネクションが定常状態になるまで未使用バンド幅が割り当てられる。したがって、最初のＴＣＰコネクションは、期間２、３、および４で、それぞれ１５、１４、および１２のパケットを送信する。次のコネクションは、期間５で定常状態に達し、このときに、割り当てられた８パケットのバンド幅すべてを使用することができる。また第１のＴＣＰコネクションも８パケットとなる。

バンド幅コントロール６０を用いた動的なバンド幅の割り当てについてのシミュレーションを示す。システムのシミュレーションに用いられるネットワークは、図５で示したものと同様である。リアルタイムストリームは静的なバンド幅の割り当ての場合と同様な性能を示すため、非リアルタイムストリームであるＨＴＴＰダウンロード５２およびＦＴＰダウンロード５８についてのバンド幅のみを示す。静的および動的なバンド幅コントロール双方は、リアルタイムストリームのＱｏＳ要求を満足することを保証する。動的なバンド幅の割り当てはスループットを向上させるため、静的なバンド幅の割り当てよりも性能がよい。

動的割り当てを実行して時間３秒付近で１つの変化がある。ＨＴＴＰダウンロードにおける４つのコネクション、すなわちＨＴＴＰダウンロード５２_a、５２_b、５２_c、および５２_dが開始されるときには、動的なバンド幅割り当てがされたＦＴＰダウンロード５８_aは、すでに定常状態となっている。アルゴリズムで示されたような静的なバンド幅の割り当ての場合では、バンド幅コントロールは利用可能なバンド幅をすべてのアクティブコネクション間で即座に分配していた。しかし、動的な割り当ての場合では、最近開始された４つのＨＴＴＰコネクションがスロースタートモードであろうという事実によって、すでに定常状態となっているＦＴＰダウンロードに、ＨＴＴＰダウンロードのスロースタートの間利用可能である未使用バンド幅が割り当てられる。動的な割り当てがされたＦＴＰダウンロード５８_aのまさに３秒付近の変化で示されるように、ＦＴＰダウンロードの性能は改善されている。これは、動的な割り当てなしのＦＴＰダウンロード５８_bを示したグラフにおけるプロットと比較することができる。したがって、動的な割り当ては、総利用可能バンド幅の利用を改善する。ＦＴＰコネクションについてのデータレートは、ＨＴＴＰダウンロード５２が定常状態に達するのと同様に、定常状態レートまで徐々に削減される。前述は、動的なバンド幅管理についての記載である。以下に、上記で参照したバンド幅コントロール６０についてさらに記載する。

バンド幅コントロール６０（図５参照）は、上述したアルゴリズムの代わりに動的なバンド幅の割り当てのアルゴリズムで動作するように設定することができる。すでに定常状態となっているＴＣＰコネクションに未使用のバンド幅を割り当てることで、動的なバンド幅の割り当て方法によって改善された性能が実現される。

本発明の特別な応用は、ホームネットワークユーザを対象に記載されている。上記すべての図は、ホームユーザを対象とした本発明の説明に用いられている。ホームネットワークユーザは一般的に、ゲートウェイ２８の具体的な型であるホームゲートウェイを通してインターネットに接続される。ユーザは、上記と同一のホームゲートウェイを通して、ビデオオンデマンドおよびＩＰ電話のような他のサービスにも接続される。ホームまたはレジデンシャルゲートウェイに接続されたホームネットワーク３０（図１参照）は、コンピュータ、テレビジョン、電話、ラジオなどの多様な機器に接続することができる。

上述のバンド幅管理の問題は、インターネットサービスプロバイダ末端でバンド幅管理技術を実現することが困難であるとの理由から、ホームユーザ側が直面するものである。ホームユーザは、ＴＣＰコネクションの実現におけるインターネットサービスプロバイダのメカニズムに対して制御を行なわない。このため、レジデンシャルまたはホームゲートウェイでバンド幅管理を実現することが求められる。

本発明の原理によると、ホームゲートウェイ内にバンド幅コントロール６０が実装される。バンド幅コントロールの動作については、上で詳細に記載した。上述の記載は、ホームネットワークユーザにも同様に適応される。特に、ホームユーザがリアルタイムデータストリームの専用チャネルの使用が高価であると気が付くと、リアルタイムおよび非リアルタイムＴＣＰトラフィック双方についてアクセスセグメント２６のチャネルを共有するようになるであろう。したがって、本発明は、ホームユーザがリアルタイムおよび非リアルタイムデータ双方とアクセスするために共有チャネルを利用することに有益である。

本発明の明細書は、本質を単に例示したものにすぎない。したがって、発明の本質から外れない程度の変形例は、本発明の範囲内であり、このような変形例は、本発明の本質および範囲から逸脱するものではない。

本発明の実施形態に係るバンド幅管理を説明するためのネットワークの構成図である。１つのＴＣＰセンダを有し、本発明のバンド幅管理を実現するネットワークの構成例である。バンド幅管理を行なわない場合のリアルタイムおよび非リアルタイムのストリームに係る平均バンド幅を示したグラフである。ＶｏＤストリームに係る平均インターパケット時間を示した図である。複数のＴＣＰコネクションを有し、バンド幅管理を実現するネットワークの構成図である。各ストリームの平均バンド幅および総ストリームの全バンド幅を示したグラフである。動的なバンド幅管理の性能特性を示したグラフである。

Claims

ネットワークにおけるクォリティーサービスを保証する装置であって、
所定のイベントが発生する前に送信可能なデータ量を特定する、フローコントロールパラメータを有し、このフローコントロールパラメータに従って第１のストリームを転送する、少なくとも１つの第１のストリームセンダと、
前記第１のストリームセンダからネットワークを介して転送された前記第１のストリーム、および第２のストリームセンダからネットワークを介して転送された少なくとも１つの第２のストリームを受信するネットワークインターコネクションと、
前記ネットワークインターコネクションに係り、前記第２のストリームのスロースタート期間の間、定常状態にある前記第１のストリームセンダのフローコントロールパラメータを増加させるバンド幅コントロールとを備えている
ことを特徴とするクォリティーオブサービス保証装置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記第１のストリームセンダを有する第１のネットワークコネクションと、
前記ネットワークインターコネクションを有する第２のネットワークとを備えた
ことを特徴とするクォリティーオブサービス保証装置。
請求項２に記載のクォリティーオブサービス保証装置において、
前記ネットワークインターコネクションはホームゲートウェイであり、
前記第２のネットワークはホームネットワークである
ことを特徴とするクォリティーオブサービス保証装置。
請求項２に記載のクォリティーオブサービス保証装置において、
前記第１のストリームセンダおよび前記第２のストリームセンダを前記ネットワークインターコネクションに接続する少なくとも１つのチャネルを備え、
前記チャネルは、前記第１のストリームおよび第２のストリームによって共有されるバンド幅容量を有する
ことを特徴とするクォリティーオブサービス保証装置。
請求項４に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記第１のストリームが前記バンド幅容量と前記第２のストリームのバンド幅容量との差以下のバンド幅容量の割り当て分を使用するように、前記フローコントロールパラメータを調整する
ことを特徴とするクォリティーオブサービス保証装置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記性能パラメータは、前記第２のストリームに係る所定のクォリティーオブサービスパラメータの集合から選択される
ことを特徴とするクォリティーオブサービス保証装置。
請求項６に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、前記フローコントロールパラメータを調整し、かつ前記第１のストリームのバンド幅要求を制御することにより前記第２のストリームに係るクォリティーオブサービスパラメータを維持する。
ことを特徴とするクォリティーオブサービス保証装置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、前記第１のストリームのフローを調節する
ことを特徴とするクォリティーオブサービス保証装置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、前記第１のストリームのフローを調節することで前記第１のストリームにおけるバンド幅利用を調節する
ことを特徴とするクォリティーオブサービス保証装置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記フローコントロールパラメータは、ＴＣＰ（Transmission Control Protocol）を実行する前記第２のストリームセンダに係るフローコントロールウインドウを有する
ことを特徴とするクォリティーオブサービス保証置。
請求項１に記載のクォリティーオブサービス保証装置において、
前記ネットワークインターコネクションは、ルータ、プロトコル変換器、およびゲートウェイからなる群のうちのいずれか１つの装置である
ことを特徴とするクォリティーオブサービス保証装置。
ネットワークにおけるクォリティオブサービスを保証する装置であって、
それぞれが、ＴＣＰストリームをサポートし、ＴＣＰで定義されたようにフローコントロールパラメータに従って動作する、少なくとも２つのＴＣＰコネクションと、
バンド幅容量を有するチャネルを使用する前記ＴＣＰコネクションに接続されたネットワークインターコネクションと、
前記チャネルを使用する前記ネットワークコネクションに接続された少なくとも１つのリアルタイムストリームと、
前記ネットワークインターコネクションに係り、前記ＴＣＰコネクションのフローコントロールパラメータを調整して前記ＴＣＰストリームのバンド幅使用を制御するバンド幅コントロールとを備え、
前記バンド幅コントロールは、別の非リアルタイムストリームのスロースタート期間の間、定常状態にある非リアルタイムストリームのフローコントロールウィンドウを増加させることによって動的にバンド幅を割り当て、その非リアルタイムストリームのフローコントロールウィンドウを減少させることによって定常状態にする
ことを特徴とするクォリティーオブサービス保証装置。
請求項１２に記載のクォリティーオブサービス保証装置において、
前記ＴＣＰコネクションを有する少なくとも１つのサーバと、
前記ネットワークインターコネクションに接続された少なくとも１つのネットワーク要素とを備えた
ことを特徴とするクォリティーオブサービス保証装置。
請求項１３に記載のクォリティーオブサービス保証装置において、
前記１つのネットワーク要素は、ホームネットワークに含まれるものであり、
前記ネットワークインターコネクションは、ホームゲートウェイである
ことを特徴とするクォリティーオブサービス保証装置。
請求項１２に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、前記フローコントロールパラメータを調整することで、前記リアルタイムストリームに係る複数のクォリティーオブサービスパラメータを保護する
ことを特徴とするクォリティーオブサービス保証装置。
請求項１５に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記ＴＣＰストリームが前記バンド幅容量と前記リアルタイムストリームのバンド幅要求との差以下のバンド幅容量の割り当て分を要求するように、前記フローコントロールパラメータを調整する
ことを特徴とするクォリティーオブサービス保証装置。
ネットワークにおけるクォリティーオブサービスを保証する装置であって、
通信チャネルに接続されたエッジルータと、
前記通信チャネルに接続されたネットワークインターコネクションと、
前記エッジルータから前記ネットワークインターコネクションに前記通信チャネルを用いて転送される少なくとも１つのリアルタイムデータストリームと、
前記通信チャネルを介して転送されるデータストリームをＴＣＰで定義されたようにフローコントロールパラメータに従ってサポートする、少なくとも１つのＴＣＰコネクションと、
前記ネットワークインターコネクションに係り、別のストリームのスロースタート期間の間、定常状態にあるデータストリームのフローコントロールウィンドウを増加させることによって、前記フローコントロールパラメータを調整し、前記ＴＣＰコネクションのバンド幅要求を調節するバンド幅コントロールとを備えた
ことを特徴とするクォリティーオブサービス保証装置。
請求項１７に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、第１のストリームセンダの前記フローコントロールパラメータを調整し、前記リアルタイムデータストリームに係る少なくとも１つのクォリティーオブサービスパラメータを保つものである
ことを特徴とするクォリティーオブサービス保証装置。
請求項１７に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記ＴＣＰストリームが前記バンド幅容量と前記リアルタイムストリームのバンド幅要求との差以下のバンド幅容量の割り当て分を要求するように、前記フローコントロールパラメータを調整することで、前記ＴＣＰコネクションのバンド幅要求を調節する
ことを特徴とするクォリティーオブサービス保証装置。
動的なバンド幅割り当てを用いてネットワークにおけるクォリティーオブサービスを保証する装置であって、
それぞれが、少なくとも１つのフローコントロールパラメータを有し、応答確認を受信する前に送信可能なデータ量を特定する、フローコントロールパラメータに従って第１のストリームを転送する、少なくとも２つの第１のストリームセンダと、
前記第１のストリームセンダから転送された前記第１のストリーム、および第２のストリームセンダから転送された少なくとも１つの第２のストリームを受信するネットワークインターコネクションと、
前記ネットワークインターコネクションに係り、前記第２のストリームセンダからの前記第２のストリームのスロースタート期間の間、定常状態にある前記第１のストリームのフローコントロールウィンドウを増加させることによって、バンド幅を動的に調整するバンド幅コントロールとを備えている
ことを特徴とするクォリティーオブサービス保証装置。
請求項２０に記載のクォリティーオブサービス保証装置において、
前記バンド幅コントロールは、
前記所定の第１のストリームが定常状態になったとき、前記所定の第１のストリームおよび前記他の第１のストリームに等しいバンド幅を割り当てる
ことを特徴とするクォリティーオブサービス保証装置。