(57)【特許請求の範囲】
【請求項１】
パケットスイッチングネットワーク上で送信ノードと受信ノードとの間のデータフローを制御する方法であって、
データは、前記受信ノードのプロトコル固有のバッファに現在のデータレート（ＳＲ）により送信され、
アプリケーションは、再生レートにより前記バッファに格納されているデータを読み、固定サイズ（ｃｈｕｎｋＳｉｚｅ）を有するチャンクと呼ばれる部分において前記バッファから前記データを取得し、
ラウンドトリップタイム（ＲＴＴ）は、前記送信ノードにより前記受信ノードへの第１パケットの発行と、前記第１パケットの受信直後に前記受信ノードにより発行される第２パケットの前記送信ノードによる受信との間の経過時間であり、
当該方法は、前記受信ノードにおいて、
前記再生レート（ＳＰＲ）の値から前記送信ノードの所望の送信レート（ＤＳＲ）の値を決定するステップであって、前記決定は前記バッファの占有量テストの結果によってトリガーされ、前記占有量テストは定期的に実行され、前記バッファの占有量が小さな閾値（ＬＴＨＲ）より小さいか、又は大きな閾値（ＨＴＨＲ）より大きいか決定することから構成される、前記決定するステップと、
前記所望の送信レート（ＤＳＲ）の値が前記現在のデータレートの値と有意に異なるとき、前記送信ノードに前記所望の送信レートの値を通知するステップと、
を有し、
前記小さな閾値と前記大きな閾値とは、前記受信ノードによって動的に割り当てられ、
前記小さな閾値は、前記チャンクのサイズの値（ｃｈｕｎｋＳｉｚｅ）、前記現在の送信レート及び前記ラウンドトリップタイムの値から計算される方法。
【請求項２】
前記バッファは、記憶容量（ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ）を有し、
前記小さな閾値は、
ＬＴＨＲ＝ｍｉｎ（ｍａｘ（２＊ｃｈｕｎｋＳｉｚｅ；ＳＲ＊ＲＴＴ）＋Ｋ；ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ−４＊ｃｈｕｎｋＳｉｚｅ）
により割り当てられ、Ｋは経験値である、請求項１記載の方法。
【請求項３】
Ｋは、ネットワークモデル化から決定される値である、請求項２記載の方法。
【請求項４】
前記大きな閾値は、前記チャンクのサイズ、前記現在の送信レート、前記バッファの記憶容量、及び前記ラウンドトリップタイムの値に依存する、請求項１又は３記載の方法。
【請求項５】
前記大きな閾値は、
ＨＴＨＲ＝ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ−ｍａｘ（２＊ｃｈｕｎｋＳｉｚｅ，ＳＲ＊ＲＴＴ）
に従って割り当てられる、請求項４記載の方法。
【請求項６】
前記バッファの占有量に関するテストが実行される期間は、前記ラウンドトリップタイムの一部に等しい、請求項１乃至５何れか一項記載の方法。
【請求項７】
当該方法はさらに、前記受信ノードにおいて、前記送信ノードからそれの最大送信レート（ＳＲＭａｘ）を受信するステップを有し、
前記所望の送信レートを決定するステップはさらに、前記再生レートが前記小さな閾値より小さいことを示す連続するバッファ占有量テストの回数ｉを決定するステップと、前記再生レートの値が前記小さな閾値より小さいことを示す連続するバッファ占有量テストの回数ｊを決定するステップとを有する、請求項１乃至６何れか一項記載の方法。
【請求項８】
増加パーセンテージ値（ＤＲＩ）は、０％〜１０％の固定的なパーセンテージ値であり、
前記バッファの占有量テストが、結果として前記バッファの占有量が前記小さな閾値より小さいと判断すると、前記所望の送信レートの値は、
ＤＳＲ＝ｍｉｎ（（ＳＰＲ＋ｉ＊ＤＲＩ＊ＳＲ），ＳＲＭａｘ）
に従って決定される、請求項７記載の方法。
【請求項９】
減少パーセンテージ値（ＤＲＲ）は、０％〜１０％の固定的なパーセンテージ値であり、
前記バッファの占有量テストが、結果として前記バッファの占有量が前記大きな閾値より大きいと判断すると、前記所望の送信レートの値は、
ＤＳＲ＝ｍｉｎ（（ＳＰＲ−ｊ＊ＤＲＩ＊ＳＲ），ＳＲＭａｘ）
に従って決定される、請求項７又は８記載の方法。
【請求項１０】
前記テスト及び前記所望の送信レートの値の決定に使用される前記再生レートの値は、再生レートの移動平均法により提供される、請求項１乃至９何れか一項記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットスイッチングネットワーク上の２つの計算ノード間のフロー制御の分野に関する。さらに、本発明はまた、フロー制御方法に関する。
【背景技術】
【０００２】
パブリックパケットスイッチングネットワークの帯域幅は、統計的な多重化ゲインを達成するため、あらゆるタイプのアプリケーションにより共有される。このリソースの共有は、ワークロード及びリソース要求において大きな不確実性を招く。このようなネットワークを介したパケットの送信中、ネットワークがある期間においてエラーがなかったとしても、予測不能な遅延ジッタが限られたクライアントバッファにおけるアンダーフロー又はオーバフローを生じさせる。しかしながら、従来のテキスト／イメージネットワークアプリケーションと異なって、マルチメディアアプリケーションは、オーディオ及びビデオのジッタのない再生によるエンド・ツー・エンドＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を求める。このため、マルチメディア通信などのタイムクリティカルなアプリケーションに対して妥当なレベルによるパケット毎の平均遅延と高いスループットを維持するのに良好なエンド・ツー・エンドフロー制御機構が必要とされる。
【０００３】
フロー制御は、輻輳制御の後、信頼できる接続指向データ伝送のエリアにおける接続管理の主要な目的の１つである。輻輳制御は、ネットワークが全体的に混雑するのを防ぐ。他方、フロー制御の主たる目的は、低速又はビジーな受信ノードがより高速なデータ送信機により混雑することを回避することである。“レートベース”及び“ウィンドウベース”機構は、フロー制御のための最も良く知られた２つのアプローチである。
【０００４】
［Ｐｏｓ８１］（Ｐｏｓｔｅｌ，Ｊｏｎ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ−ＤＡＲＰＡ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｇｒａｍ  Ｐｒｏｔｏｃｏｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，ＲＦＣ  ７９３，Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｓｐｕｔｈｅｒｎ  Ｃａｌｉｆｏｒｎｉａ−Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｃｉｅｎｃｅ  Ｉｎｓｔｉｔｕｔｅ（１９８１））に記載される一般的なＴＣＰフロー制御は、ウィンドウベースフロー制御機構を利用する。受信機は、直近に受信したセグメントを超える許容されるシーケンス番号の範囲を示す各アクノリッジメントによる“ウィンドウ”を返す。ウィンドウは、送信機がさらなるパーミッションを受信する前に送信する許可されたバイト数を示す。この方法の短所は、バーストな送信方法であり、当該方法は、高帯域幅遅延プロダクトリンク（“高ＢＤＰリンク”とも呼ばれる）上で増幅する。
【０００５】
他方、レートベースフロー制御は、パケットスイッチングネットワーク上でエンド・ツー・エンド決定的及び統計的パフォーマンス保証を提供することが可能である。レート調整は、保証されたＱｏＳを達成するため、クライアントからの集中的なフィードバック制御によって実行される。１つのレートベースアプローチが、［Ｗａｎ０１］（Ｗａｎｇ，Ｃｈｉａ−Ｈｕｉ；Ｊａｎ−Ｍｉｎｇ；Ｃｈａｎｇ，Ｒａｙ−Ｉ  ａｎｄ  Ｈｓｕ，Ｓｈｕｎ−Ｃｈｉｎ：Ａ  Ｃｏｎｔｒｏｌ−Ｔｈｅｏｒｅｔｉｃ  Ｍｅｃｈａｎｉｓｍ  ｆｏｒ  Ｒａｔｅ−ｂａｓｅｄ  Ｆｌｏｗ  Ｃｏｎｔｒｏｌ  ｏｆ  Ｒｅａｌｔｉｍｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ，Ｔｅｃｈｎ，Ｂｅｒ．，Ｄｅｐａｒｔｍｅｎｔ  ｏｆ  Ｃｏｍｐｕｔｅｒ  Ｓｃｉｅｎｃｅ  ａｎｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｎｇｉｎｅｅｒｉｎｇ，Ｎａｔｉｏｎａｌ  Ｔａｉｗａｎ  Ｕｎｉｖｅｒｓｉｔｙ，Ｔａｉｐｅｉ，Ｔａｉｗａｎ，Ｒ．Ｏ．Ｃ  ａｎｄ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｃｉｅｎｃｅ，Ａｃａｄｅｍｉａ  Ｓｉｎｉｃａ，Ｔａｉｐｅｉ，Ｔａｉｗａｎ，Ｒ．Ｏ．Ｃ（２００１），Ｍｕｌｔｉｍｅｄｉａ，Ｉｎｔｅｒｎｔ，Ｖｉｄｅｏ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  ２００１（ＭＩＶ２００１）ｏｆ  ＷＳＥＳ／ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｕｌｔｉ−ｃｏｎｆｅｒｅｎｃｅ）に記載される。この方法は、閉ループ制御機構を用いて送信機のデータレートを調整する。制御理論的な“制御するためのデバイス”は、受信バッファ占有量（ＢＯ）である。ＢＯ値が所与の閾値を超える場合、受信機は、それのＢＯに関するフィードバックを送信機に与える。送信機は、比例微分（ＰＤ）レート制御を用いて、受信したＢＯフィードバックから新たな送信レートを計算する。Ｗａｎｇにより提案される方法は、現在の送信レートと受信バッファ占有量の変動のみに依存する。受信機にあるアプリケーションの有効受信レートは、直接的には考慮されない。これは、当該レートの変動は不明であるためである。高ＢＤＰリンクに関して、これは、意図しないバッファオーバフロー又はアンダーフローをそれぞれもたらしうる。Ｗａｎｇにより提案される方法の欠点は、それがバッファから現在読み取り可能なデータ量を無視するものであり、不要な又は誤った速度調整を生じさせる可能性があるということである。
【０００６】
本発明の目的の１つは、従来技術によりフロー制御機構よりエラーのある高ＢＤＰリンクにおいてでさえ効果的で信頼性のあるデータフロー制御を提供し、既知のアプローチより効率的なネットワークリソース利用を可能にするレートベースフロー制御機構を提案することである。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明が解決しようとする技術的課題は、受信機の混雑を回避するため送信機の送信レートを制御し、受信機のアプリケーションレベルにおけるデータ受信レートに従ってデータ送信機が自らの送信データレートを最適に調整することを可能にすることである。
【課題を解決するための手段】
【０００８】
従って、本発明は、パケットスイッチングネットワーク上で送信ノードＳＮと受信ノードＲＮとの間のデータフローを制御する方法に関し、データは、前記受信ノードのプロトコル固有のバッファに現在のデータレートＳＲにより送信され、アプリケーションＡＰは、再生レートＳＰＲにより前記バッファＢＵに格納されているデータを読む。本発明によると、前記送信ノードＳＮが、前記受信ノードＲＮに自らの最大送信レートＳＲＭａｘを通知するステップと、前記受信ノードＲＮが、再生レート値ＳＰＲから前記送信ノードＳＮの所望の送信レート値ＤＳＲを決定するステップと、前記所望の送信レート値ＤＳＲが前記現在のデータレート値ＳＲと有意に異なるとき、前記受信ノードＲＮが、前記送信ノードＳＮに前記所望の送信レートＤＳＲを通知するステップに関する。
【図面の簡単な説明】
【０００９】
【図１】図１ａは、送信ノードＳＮと受信ノードＲＮとの間のデータ交換を示し、図１ｂは、本発明による連続する４つのメインステップを有するデータフロー制御方法の一例となるフローチャートである。
【図２】図２は、“Ｂｒｕｔ”再生レートとスムージングされた再生レートとの間の差分を示す。
【図３】図３ａは、所与の時点ｔ１における非エンプティバッファアンダーラン状況を示し、図３ｂは、バッファ占有量とバッファからの可読データ量との時間的な進展を示すグラフである。
【図４】図４は、本発明による方法の所望の送信レートＤＳＲの決定のステップ２０の詳細なフローチャートである。
【発明を実施するための形態】
【００１０】
図１ａは、プロトコルに固有のバッファＢＵを有する受信ノードＲＮと送信ノードＳＮとの間のデータ交換を示す。送信ノードＳＮは、１秒毎のメガビットなどにより表現される現在の送信レートＳＲによりデータを受信ノードＲＮに送信する。受信ノードＲＮにより受信されると、データはバッファＢＵに格納される。少なくとも１つのアプリケーションＡＰが、受信ノードＲＮ上で実行され、再生レートによりデータを取得する。
【００１１】
アプリケーションＡＰは、例えば、送信ノードＳＮからビデオデータを受信し、当該データをビデオスクリーンに再生するメディアプレーヤーである。他の例では、送信されるデータはメディアストリーミングであり、アプリケーションＡＰはまたファイル転送、データベース複製などに適用可能である。
【００１２】
バッファ占有量ＢＯは、受信ノードＲＮにより受信されたデータにより占有されるバッファスペースのサイズであり、バッファＢＵは、ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅとして示される記憶容量を有する。
【００１３】
本発明による方法を実現するためのフローチャートの一例が図１ｂに示される。本発明による方法により実現されるフロー制御機構は、レートベースアプローチを利用する。
【００１４】
第１ステップ１において、例えば、接続セットアップ中などに、送信ノードＳＮは、送信ノードＳＮが受信ノードＲＮにデータを送信可能な最も高いレートである最大送信レートＳＲＭａｘを受信ノードＲＮに通知する。受信ノードＲＮは、例えば、ステップ２０などにおいて、送信ノードＳＮに所望の送信レートＤＳＲを通知する。
【００１５】
所望の送信レートＤＳＲの値を決定するための計算は、中間ステップ１０において受信ノードＲＮにより実行される。これにより、所望の送信レートＤＳＲは、再生レート又は“ｂｒｕｔ”再生レートを観察することによって決定されるスムース再生レートＳＰＲから計算される。
【００１６】
従って、再生レートは、アプリケーションＡＰによるデータ抽出の一定でないビットレートにより生じる変動を受ける。レート計算中の丸め誤差などの小さな変動を解消するため、再生レートは、時間移動平均などを適用することによってスムージングされる。例えば、ＥＷＭＡ（Ｅｘｐｏｎｅｎｔｉａｌｌｙ  Ｗｅｉｇｈｔｅｄ  Ｍｏｖｉｎｇ  Ａｖｅｒａｇｅ）方法は、スムース再生レートＳＰＲを取得するのに利用される。ＥＷＭＡは、指数的に減少する加重ファクタを適用することから構成される。より以前の各データポイントに対する重み付けが指数的に減少し、より以前に観察されたものを全く無視するのでなく、最近に観察されたものをより重視する。
【００１７】
効果的には、所望の送信レートＤＳＲの値をテスト及び決定するのに利用される再生レートＳＰＲ値は、ＥＷＭＡ方法などの再生レートの移動平均方法により与えられる値である。
【００１８】
図２は、“ｂｒｕｔ”再生レート、すなわち、スムースフィルタなしに測定される再生レートの値の時間進展と、２５００ミリ秒においてＥＷＭＡによりスムージングされた再生レートＳＰＲの値とを比較する。図２において、Ｘ軸は時間を示し、Ｙ軸はＭｂｉｔｓ／ｓによりレート値を示す。“ｂｒｕｔ”再生レートは“高周波”変動を受けるのに対して、スムージングされた再生レートＳＰＲはほぼ一定である。データフローの開始から５５０ｍｓ後、スムージングされた再生レートＳＰＲは、一定であり、アプリケーションにおけるより大きな変動まで変化せず、２３００ｍｓ後に発生する。
【００１９】
送信ノードＳＮによる受信ノードＲＮへのパケット発行時間と、それの受信直後に受信ノードＲＮにより発行されたパケットの送信ノードＳＮによる受信時との間の経過時間を測定することが可能である。この測定された経過時間は、“ラウンドトリップタイム”又はＲＴＴである。
【００２０】
アプリケーションＡＰは、プロトコルエンジンに対する受信コールを発行することによってバッファＢＵに対してポーリングを実行する。この受信コールは、アプリケーションＡＰがバッファＢＵからフェッチすることを所望するデータ量を送信する。従って、このデータフェッチ処理は、アプリケーションＡＰにより完全に制御される。理想的には、ストリーミングアプリケーションでは、データフェッチ処理は一定サイズの部分により時間的に等距離に実行される。“チャンク”と呼ばれるこれらの部分のサイズは、“ｃｈｕｎｋＳｉｚｅ”により示される。しかしながら、実際には、何れの（非リアルタイム）アプリケーションも等距離フェッチ処理アプローチ（“コンスタントビットレートデータシンク”とも呼ばれる）に到達できない。アプリケーションＡＰの受信コールが遅延した場合、バッファＢＵに格納されるデータ量は増大し、データ量を増やすための受信コールの頻度を増やすか、１つの受信コール内でフェッチされる部分のサイズを増やすか、又はその両方を必要とする。例えば、アプリケーションＡＰは、毎秒２４フレームにより圧縮されていないビデオフィードをストリーミングする。１秒以内で、アプリケーションＡＰは、バッファＢＵから２４のピクチャフレームを取得する。各フレームがバッファＢＵから個別に受信される場合、各フレームが同一サイズを有するという事実に基づき、チャンクサイズは１フレームのサイズとなる。
【００２１】
アプリケーションの受信コールにより、例えば、２３００ｍｓ後の図２に示されるような高い振幅の再生レートの変動は、受信ノードＲＮから送信ノードＳＮへの周期的な送信レートの更新によって制御可能である。
【００２２】
大きな送信遅延の問題点を軽減するため、レート更新は低域的に送信され、これにより、更新期間は接続のＲＴＴの分数により表現される。しかしながら、最小期間値は、ある固定値に限定される必要がある。期間値は、例えば、経験的な検討などに基づくものとすることができる。ＲＴＴの使用される分数は、例えば、１／４ＲＴＴなどに対応する。ＲＴＴの部分の最小値は、４０ｍｓより大きなＲＴＴ値については１０ｍｓとなる。
【００２３】
効果的には、バッファ占有量に関するテストが実行される期間は、ラウンドトリップタイムＲＴＴの一部に等しい。
【００２４】
本発明の実施例によると、所望の送信レートＤＳＲ値を決定するステップは、バッファの占有量に対するテスト結果によりトリガーされ、このテストは定期的に実行される。
【００２５】
図４は、所望の送信レートＤＳＲを決定するステップ１０を実現するための実現形態の一例を示す。
【００２６】
現在のスムージングされた再生レートＳＰＲ値の上下への送信レートの増減に関する決定は、受信ノードＲＮのバッファの占有量ＢＯに基づく。バッファ占有量に関するテストは、２つのステップ１０．２及び１０．３である。
【００２７】
本発明の実施例によると、バッファ占有量に関するテストは、バッファ占有量は小さな閾値ＬＴＨＲより小さいか、又は大きな閾値ＨＴＨＲより大きいか決定することからなる。
【００２８】
バッファ占有量ＢＯが大きな閾値ＨＴＨＲを上回る又は小さな閾値ＬＴＨＲを下回る場合、所望の送信レートＤＳＲ値はそれぞれ、現在のスムース再生レートＳＰＲまで増減される（図４に示されるステップ１０．５及び１０．６）。
【００２９】
効果的には、小さな閾値ＬＴＨＲと大きな閾値ＨＴＨＲは、動的に割り当てられる。
【００３０】
大きな閾値ＨＴＨＲと小さな閾値ＬＴＨＲは、ステップ１０．１において動的に割り当てられる。大きな閾値及び／又は小さな閾値の割当ての動的な特徴は、レートベースフロー制御の従来の実現形態との大きな相違の１つである。これは、図４に示されるように、非エンプティバッファアンダーランを回避する。
【００３１】
効果的には、小さな閾値ＬＴＨＲは、チャンクのサイズ（ｃｈｕｎｋＳｉｚｅ）、現在の送信レートＳＲ及びラウンドトリップタイムＲＴＴから計算される。
【００３２】
これにより、大きな閾値ＨＴＨＲは、アプリケーションＡＰがバッファＢＵから受信する最大チャンクサイズ（２＊ｃｈｕｎｋＳｉｚｅなど）と、ＲＴＴと現在の送信レートとの積である既存のＢＤＰとに基づき計算できる。ＢＤＰは、データ送信の応答が実行可能になる前に送信可能なデータ量を表すため（ＳＲ＊ＲＴＴ）、トランスポートプロトコルのエリアにおける極めて重要なパラメータである。
【００３３】
効果的には、大きな閾値ＨＴＨＲは、チャンクのサイズｃｈｕｎｋＳｉｚｅ、現在の送信レートＳＲ、バッファ記憶容量ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ及びラウンドトリップタイム値ＲＴＴに依存する。
【００３４】
効果的には、大きな閾値ＨＴＨＲは、
ＨＴＨＲ＝ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ−ｍａｘ（２＊ｃｈｕｎｋＳｉｚｅ，ＳＲ＊ＲＴＴ）
に従って割り当てられる。
【００３５】
パフォーマンスの観点から、バッファＢＵアンダーランは、バッファＢＵオーバフローより重大である。従って、小さな閾値ＬＴＨＲの割当てのためにはＢＤＰとアプリケーションＡＰにおけるチャンクサイズのみの計算を考慮することは十分でない。
【００３６】
大きなエラーレートを有するリンク又は輻輳したリンクに対して、さらなるファクタが考慮される必要がある。欠落したパケットは、バッファＢＵに格納されるデータストリームにおいてギャップを生じさせ、アプリケーションＡＰがこのギャップを超えてデータを受信することを妨げる。この状況は、図４ａに示される。バッファＢＵは、矩形の受信部として示される。時点ｔ１において、受信データにより充填されるバッファＢＵの黒色で示された部分が示される。バッファのエンプティ部分は、白色で設定される。２つの黒部分の間の白部分は、消失したパケットに対応する。従って、受信の最も高い部分により示されるバッファに格納されるデータ量（図４ａにおいてＢＯとして示される）と、バッファＢＵから可読なデータ量ＢＲ１との間には相違がある。
【００３７】
これにより、パケット損失レートが高くなるほど、バッファに格納されるデータとバッファから読み取り可能なデータとの間の相違が大きくなる（格納／可読差）。
【００３８】
小さな閾値ＬＴＨＲの決定のため格納／可読差を考慮することが重要である。小さな閾値ＬＴＨＲが、Ｗａｎｇにより用いられる任意の固定値と共にチャンクサイズとＢＤＰとの最大値からのみ割り当てられる場合、バッファアンダーランが発生する可能性があり、このことは、バッファＢＵがエンプティでなくても、アプリケーションＡＰがバッファＢＵからデータを即座には受信できないことを意味する。この“非アンプティバッファアンダーラン”状況は、格納／可読差が小さな閾値ＬＴＨＲより大きくなると生じる。この状況は、ｔ２より大きな時間について図３ｂに示されるバッファ占有量の時間進展のグラフに示される。
【００３９】
これが、小さな閾値ＬＴＨＲが、チャンクサイズとＢＤＰ（ＳＲ＊ＲＴＴ）との最大値に、最大値Ｋとして示される上述された格納／可読差の最大値を加えた値に設定される理由である。
【００４０】
ＬＴＨＲ＝ｍａｘ（２＊ｃｈｕｎｋＳｉｚｅ；ＳＲ＊ＲＴＴ）＋Ｋ
Ｋの値を追加することによって、小さな閾値ＬＴＨＲは大きな閾値ＨＴＨＲを超える可能性があるため、小さな閾値ＬＴＨＲはまた、この場合には大きな閾値ＨＴＨＲより小さな値に限定される必要がある（例えば、ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ−４＊ｃｈｕｎｋＳｉｚｅなど）。
【００４１】
効果的には、小さな閾値ＬＴＨＲは、
ＬＴＨＲ＝ｍｉｎ（ｍａｘ（２＊ｃｈｕｎｋＳｉｚｅ；ＳＲ＊ＲＴＴ）＋Ｋ；ｔｏｔａｌＢｕｆｆｅｒＳｉｚｅ−４＊ｃｈｕｎｋＳｉｚｅ）
に従って割り当てられる。ここで、Ｋは経験値である。
【００４２】
効果的には、Ｋは、ネットワークモデルから決定された値である。
【００４３】
レート増減量は、現在の送信レートに依拠する必要がある（例えば、増加用のＤＲＩ＝２％と減少用のＤＲＲ＝１％などの送信レートの小さな部分など）。充填されたバッファはエンプティバッファより好ましいため、減少値（送信レートの減少値）は増加値（送信レートの増加値）より小さくなるべきであり、バッファを充填よりゆっくりとエンプティにさせる。
【００４４】
何れのケースでも、定期的なレート更新は送信ノードの最大送信レートを超える必要はない。
【００４５】
送信レート調整を送信機に送信した後、受信ノードＲＮは、定期的なレート更新と共に次のＢＯ評価を遅延しなければならない。この遅延は、１０．４として示されるボックスにより示される。送信ノードにより実現される送信レートの調整は、調整メッセージが受信機により送信された後の少なくとも１つのＲＴＴ前の受信機のＢＯに対して効果を有しない。従って、ＢＯの評価は、少なくとも１つのＲＴＴ（好ましくは、２＊ＲＴＴ）だけ遅延される。
【００４６】
２つの連続するＢＯの評価が閾値超過に関する同様の結論を導く場合、レートは、これらの評価の第２のものの後により積極的に増減される。
【００４７】
例えば、バッファ占有量ＢＯが、２つの連続するＢＯ評価の後に小さな閾値ＬＴＨＲを超える場合、所望の送信レートＤＳＲは、同じ結論を導いた連続するＢＯ評価の回数から決定される。
【００４８】
効果的には、所望の送信レートＤＳＲを決定するステップはさらに、再生レートＳＰＲが小さな閾値ＬＴＨＲより小さいことを示す連続するバッファ占有量テストの回数ｉを決定するステップと、再生レートＳＰＲ値が小さな閾値ＬＴＨＲより小さいことを示す連続するバッファ占有量テストの回数ｊを決定するステップとを有する。
【００４９】
効果的には、バッファ占有量に関するテストが結果としてバッファ占有量が小さな閾値ＬＴＨＲより小さいと判断すると、所望の送信レートＤＳＲ値は、
ＤＳＲ＝ｍｉｎ（（ＳＰＲ＋ｉ＊ＤＲＩ＊ＳＲ），ＳＲＭａｘ）
に従って決定される。
【００５０】
ｉをスムージングされた再生レートＳＰＲが小さな閾値ＬＴＨＲより小さいという連続する検出の回数とし、ＤＲＩを上述した増加値とすると、所望の送信レートＤＳＲは以下のように計算される。
【００５１】
ＤＳＲ＝ｍｉｎ（（ＳＰＲ＋ｉ＊ＤＲＩ＊ＳＲ），ＳＲＭａｘ）
効果的には、バッファ占有量に関するテストが結果としてバッファ占有量が大きな閾値ＨＴＨＲより大きいと判断したとき、所望の送信レートＤＳＲ値は、
ＤＳＲ＝ｍｉｎ（（ＳＰＲ−ｊ＊ＤＲＩ＊ＳＲ），ＳＲＭａｘ）
に従って決定される。
【００５２】
ｉをスムージングされた再生レートＳＰＲが大きな閾値ＨＴＨＲより大きくなるという連続する検出回数とし、ＤＲＲを上述した減少値とすると、所望の送信レートＤＳＲは以下のように計算される。
【００５３】
ＤＳＲ＝ｍｉｎ（（ＳＰＲ−ｉ＊ＤＲＲ＊ＳＲ），ＳＲＭａｘ）
現在計算されたＤＳＲが更新期間内に大きく変化しなかった場合、すなわち、更新処理が以前に送信されたＤＳＲ更新と同じ値を送信したか、又は有意な変化がない場合、送信レートの更新は帯域幅を節約するため省略可能である。ＤＳＲとＳＲの各値を比較するステップは、図４のステップ１．８により示される。εは、一定の経験値を有する閾値である。
【００５４】
効果的には、増加パーセンテージ値ＤＲＩは、減少パーセンテージ値ＤＲＲより大きい。
【図１】
0005512699.tif 000002
【図２】
0005512699.tif 000003
【図３】
0005512699.tif 000004
【図４】
0005512699.tif 000005