(57)【要約】  本発明は、インターネット・プロトコル・ネットワークなどのパケット交換ネットワークを介するデータ、音声、および映像の流れの送信伝送レートをエンドツーエンド方式で算出する方法からなる。送信伝送レートは、直近に送信されたデータの関数として、また、ネットワーク輻輳の信号および許容バンド幅が変化するネットワークに応じて動的に設定されるプロービング関数ｗ（ｔ）として算出される。
2007504694.tif 000002
【特許請求の範囲】
【請求項１】
クライアント／サーバ装置の使用者がクライアント／サーバ装置に接続するのに用いられるパケット交換ネットワークを介して行われるデータ、音声、または映像の送信伝送レートｒ（ｔ）を算出する方法であって、
送信伝送レートを算出し、
ルーチンが受信側で実現される場合には、クライアントによって受信されたパケットの流れに基づいて許容バンド幅のサンプルＢ（ｔ）を算出し、また、ルーチンが送信側で実現される場合には、送信側にて受信された確認応答パケットに基づいて許容バンド幅のサンプルＢ（ｔ）を算出し、
任意の時間に応じたローパスフィルタを用いることにより、許容バンド幅のサンプルＢ（ｔ）
2007504694.tif 000020
【請求項２】
前記送信伝送レートｒ（ｔ）が、以下の式により算出される請求項１に記載の方法；
2007504694.tif 000021
ここで、
ａ）［ｘ］＋は（０，ｘ）の最大値
ｂ）ｋは比例定数
ｃ）ＲＴＴはラウンドトリップ時間
ｄ）ｗ（ｔ）は、ネットワーク容量をプロービングするための増加フェーズおよびそのネットワーク容量を見出した後で、前記増加フェーズの終わりに開始される減少フェーズとにより構成される入力関数。減少フェーズの後、増加フェーズが再び開始される。
ｅ）ｓ（ｔ）は、ネットワークを介して送信側に明らかな輻輳のフィードバックが無いときには無限大をとり、ネットワークを介して輻輳のフィードバックがあるときには適切な値をとる関数である。
【請求項３】
前記関数ｗ（ｔ）の増加フェーズが、以下の２つのフェーズにより構成される請求項２に記載の方法；
ａ）関数ｗ（ｔ）が以下のように設定されるクイック・プロービング・フェーズ；
2007504694.tif 000022
ここで、ｔ０は、前回、クイック・プロービング・フェーズが開始された時刻である。ｗ（ｔ）が閾値ｓｓｔｈｒｅｓｈと等しい場合に、ジェントル・プロービング・フェーズが開始される。
ｂ）関数ｗ（ｔ）が以下のように設定されるジェントル・プロービング・フェーズ；
2007504694.tif 000023
ここで、ｔ０は、ジェントル・プロービング・フェーズが開始された時刻である。
【請求項４】
前記関数ｗ（ｔ）の減少フェーズが、以下のように設定される請求項２に記載の方法；
ａ）フィードバックされる通知によって、或いは、パケット受信のシーケンスにホールが生ずることに起因して受信側から送信側に対してｎ回（通常は、ｎ＝３）重複して確認応答が送られることにより、時刻ｔ１において輻輳の発生が通知された場合、または明示的輻輳通知により輻輳の発生が通知された場合、関数ｗ（ｔ）は、時刻ｔ１における関数ｗ（ｔ１）から時刻
2007504694.tif 000024
である。時刻ｔ１＋ＲＴＴｍにおいて、ｗ（ｔ）の設定は、再びジェントル・プロービング・フェーズに入る。
ｂ）送信側が受信側から長い時間にわたり一切のレポートを受信しなかったことによりタイムアウト時間を超過して、タイムアウトが生じ、輻輳の発生が時刻ｔ１において通知された場合、時刻ｔ１における関数ｗ（ｔ）、即ち、関数ｗ（ｔ１）は、２または数個のセグメントで表わさ
2007504694.tif 000025
プ時間の最小値である。関数ｗ（ｔ）の値が閾値ｓｓｔｈｒｅｓｈに達したときに、関数ｗ（ｔ）は、ジェントル・プロービング・フェーズに入る。
【請求項５】
前記関数ｗ（ｔ）の減少フェーズが、以下のように設定される請求項２に記載の方法；
ａ）フィードバックされる通知によって、或いは、パケット受信のシーケンスにホールが生ずることに起因して受信側から送信側に対してｎ回（通常は、ｎ＝３）重複して確認応答が送られることにより、時刻ｔ１において輻輳の発生が通知された場合、または明示的輻輳通知により輻輳の発生が通知された場合、関数ｗ（ｔ）は以下のように設定される。
2007504694.tif 000026
り、ｔｆ＝ｔ１＋ＲＴＴｍである。時刻ｔ１＋ＲＴＴｍにおいて、関数ｗ（ｔ）は、再びジェントル・プロービング・フェーズに入る。
ｂ）送信側が受信側から長い時間にわたり一切のレポートを受信しなかったことによりタイムアウト時間を超過して、タイムアウトが生じ、輻輳の発生が時刻ｔ１において通知された場合、時刻ｔ１における関数ｗ（ｔ）、即ち、ｗ（ｔ１）は、２または数個のセグメントで表わされる。
2007504694.tif 000027
の最小値である。関数ｗ（ｔ）の値が閾値ｓｓｔｈｒｅｓｈに達したときに、関数ｗ（ｔ）は、ジェントル・プロービング・フェーズに入る。
【請求項６】
時刻ｔｉにおける許容バンド幅のサンプルＢ（ｉ）は、ラウンドトリップ時間毎に、または、ＳＲＴＴ毎に、以下の式によって算出される請求項１に記載の方法；
2007504694.tif 000028
ここで、Ｄ（ｉ）は、前回のＲＴＴまたはＳＲＴの期間に受信されたデータ量である。
【請求項７】
2007504694.tif 000029
【請求項８】
時間に伴って乗数が変化する以下のフィルタを用いて、許容バンド幅のサ
2007504694.tif 000030
求項１に記載の方法；
2007504694.tif 000031
タの出力、Ｂ（ｉ）は時刻ｔｉにおいて算出された許容バンド幅のサンプル、τｆはこのフィルタの時定数である。Ｔ（ｉ）がτｆ／４より大きい場合、４・Ｔ（ｉ）／τｆの値をとる整数Ｎを用いて、内挿および再度のサンプリングを行う。仮想サンプルＢ（ｉ）は、Ｔｖ（ｉ）＝τｆ／４の時間間隔で届く。
【請求項９】
一定の乗数をもつフィルタを用いて許容バンド幅のサンプルＢ（ｔ）にローパ
2007504694.tif 000032
【請求項１０】
一定の乗数を持つ以下のフィルタを用いて許容バンド幅のサンプルＢ（ｔ）
2007504694.tif 000033
載の方法；
2007504694.tif 000034
タの出力、Ｂ（ｉ）は時刻ｔｉにおいて算出された許容バンド幅のサンプル、αは定数である。
【請求項１１】
請求項７から請求項１０のいずれかに記載の方法に用いられる前記フィルタをカスケード内に連続して設け、許容バンド幅のサンプルＢ（ｔ）を連続するフィルタの
2007504694.tif 000035
載の方法。
【請求項１２】
伝送制御プロトコルの輻輳制御で実行される請求項１から請求項１１のいずれかに記載の方法。
【請求項１３】
パケットネットワークを介してデータを送信するためのアプリケーションで実行される請求項１から請求項１１のいずれかに記載の方法。
【請求項１４】
音声／映像ストリーミングのためのアプリケーションで実行される請求項１から請求項１１のいずれかに記載の方法。
【請求項１５】
パケットネットワークを介して行われるリアルタイム会議のためのアプリケーションで実行される請求項１から請求項１１のいずれかに記載の方法。
【請求項１６】
パケットネットワークを介してファイルを共有するピアツーピアのアプリケーションで実行される請求項１から請求項１１のいずれかに記載の方法。
【請求項１７】
請求項１または請求項６から請求項１１のいずれかに記載の方法によっ
2007504694.tif 000036
は、音声／映像ソースの階層符号化において転送されるレイヤの数を適切に選択する方法。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、総じて、パケット交換網を介した効率的な通信に関する。詳しくは、本発明は、インターネットのようにパケット通信網を介してデータ、音声、あるいは映像を送信するための伝送レートに基づく輻輳制御機構を提案するものである。本発明は、有線、および、特に無線のインターネットプロトコルを用いて行われるデータ、音声、または映像の伝送における効率を向上させるものである。【０００２】  本出願は、伊国特許出願ＢＡ２００３Ａ００００３９号を基礎としている。本出願は、２００１年１０月１５日出願の米国特許出願公開第２００２／００８５５８７号明細書に基づいている。本出願は、著作権により保護される事項を含むものとする。
【背景技術】
【０００３】  潜在的に高品質なビデオデータを伝送するためのインターネットの活用は、増え続けている。高品質な符号化スキーム、前進型誤信号制御技術、および輻輳制御アルゴリズムを統合することは、効果的な映像配信装置の提供にあたり非常に重要である。符号化は、映像データを転送する際のビット数を大幅に低減し、誤り訂正技術は、冗長データを付加することにより復元性を確かにし、輻輳制御アルゴリズムは、ネットワークにおける許容バンド幅を推定する。高品質な輻輳制御は、インターネットのように、伝送容量が時間的に変化するネットワークを介して映像を効率的に配信するのに、重要な方策である。つまり、高品質な輻輳制御を利用することで、許容バンド幅が不足する場合には、品質の低い映像を配信し、その一方で、十分な空きバンド幅が確保できる場合には、品質の高い映像を配信することができる。図１に、上述した全ての機能を組み合わせた一般的な映像配信システムを示す。この映像配信システムは、以下のモジュールから構成される。【０００４】  すなわち、映像配信システムは、
伝送レートを抑制するとともに、許容バンド幅および損失伝送レートをバンド幅割付ルーチン（Ｔｈｅ  Ｂａｎｄｗｉｄｔｈ  Ａｌｌｏｃａｔｏｒ）に対して通知する伝送レート制御部と、
伝送レート制御部からの許容バンド幅および損失伝送レートを考慮することにより、レイヤ選択部（Ｌａｙｅｒ  Ｓｅｌｅｃｔｏｒ）および複数のロス・レジリエンス・ブロック（ｌｏｓｓ  ｒｅｓｉｌｉｅｎｃｅ  ｂｌｏｃｋｓ）に対して許容バンド幅を割り当てるバンド幅割付ルーチンと、
バンド幅割付ルーチンおよびクライアントのバッファの状態により、割り当てられた許容バンド幅の割合に基づいて、送信するレイヤを選択するレイヤ選択部と、
損失伝送レートおよびバンド幅割付ルーチンにより割り当てられたバンド幅の割合を考慮して、該レイヤ選択部によって選択されたレイヤに冗長データを付加するロス・レジリエンス・ブロックと、
伝送レート制御部に対してフィードバック情報を送ることにより閉ループ制御を構築する受信機と
を有している。【０００５】  従来の映像エンコーダは、ネットワークの伝送容量を一定であるとみなすとともに、損失伝送レートを低い値にみなしているので、バンド幅および損失伝送レートの双方が予測不可であり、且つ、時間とともに変化するインターネットを介して転送する場合には、低品質のビットストリームを生成することとなる。
損失伝送レートが高いと、あるいは、バンド幅が狭いと、時間とともに伝搬する映像的な欠陥が現れる。このような映像エンコーダは、パケットの損失伝送レートを補償し、また、許容バンド幅を一致させるために、ＦＥＣコードの数や伝送された映像の品質を適切に規制することを主要な課題とするような映像配信システムには適していない。【０００６】  長い年月をかけて、伝送レートが時間的に変化するネットワークを介して映像ストリームを符号化して、転送するためのいくつかの解決策が提案されている。単一階層の符号化を用いれば、エラーの伝搬を回避する目的で瞬時予測を行わずに（つまり、フレームの前後の内容を考慮せずに）イントラブロックを適切に選択することによって、エラーに対する圧縮率とレジリエンスとのバランスをとることができる。【０００７】  動的に品質を適合させるために、符号化特定パケット（ｅｎｃｏｄｉｎｇ−ｓｐｅｃｉｆｉｃ  ｐａｃｋｅｔ）を破棄するアルゴリズムを配置することが、一般的な解決策としてとられている。このアルゴリズムは、伝送レートとチャネルバンド幅とを一致させるために、優先度の低い情報を含むパケットを破棄するものである。この解決策により得られる結果は、特定のメディアコンテンツ及び採用されている符号化スキームに応じて、限定された範囲の伝送レートに対してのみ満足できるものである。【０００８】  マルティプル・ディスクリプション（ＭＤ：Ｍｕｌｔｉｐｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）・コーダは、マルチプル・ディスクリプション・映像エンコーダを用いる。ＭＤによる符号化は、ソースを二つのビットストリームに符号化することにより生ずる問題に取り組んでいるので、二つのビットストリームが得られる場合には高い再現性を得ることができ、また、その一方で、いずれか一つのビットストリームが失われた場合でも、依然として許容できる範囲で再現させることができる。ＭＤコーダは、概して、符号化時におけるチャネル損失レートが不確かな場合に、一層効果を発揮する。しかしながら、ＭＤコーダは、依然として、変化するチャネルバンド幅に適合するために、ネットワークの支援を必要とする。【０００９】  サイマル放送は、高品質な映像を達成するために提案される最も簡便な技術である。この技術は、符号化の目標ビットレートを変更することにより、符号化の形態の異なる同一映像を生成する。サイマル放送の欠点は、同一映像から生成した各符号化データが互いに独立している点、および、一の形態に属する符号化データが他の形態に使用できない点である。この結果、ソースが、許容バンド幅に適合するように配信する映像の品質を切り替えると、すでに受信側へ送信されているけれども未だに再生されていないデータと新たなデータとの関連付けができないこととなる。【００１０】  階層符号化技術に基づくマルチキャストと階層符号化（Ｌａｙｅｒｅｄ  Ｅｎｃｏｄｉｎｇ）は、映像を、１つの基本レイヤと複数の拡張レイヤとが配列されてなるいくつかのレイヤに符号化する技術である。より広い許容バンド幅が確保できたときには拡張レイヤを追加し、また、許容バンド幅が狭くなったときには、拡張レイヤを間引く（ｓｔｒｉｐｉｎｇ）ことにより、映像品質を徐々に適合させ��ことができる。階層符号化は、高度な符号化を必要とするが、映像を構成している各レイヤの整合性を互いに確保することができるという補償がある。これにより、送り側が新たなレイヤを追加した場合でも、既に受信側にて受信されたが未だに再生されていないデータと、これから送信する新たなデータとの整合性を取ることができる。許容バンド幅にあわせて、送信するレイヤの数を変えることで、符号化時における正確なチャネルバンド幅を把握する必要性を緩和できる。このことは、データ移送と符号化アルゴリズムとを分離するのに寄与する。データ移送と符号化アルゴリズムとを分離することで、改良された階層化エンコーダと高度なレート制御アルゴリズムとの段階的な統合が徐々に実現されることとなる。【００１１】  ここ１０年間、輻輳制御アルゴリズムの研究はかなり活発に行われている。基本的には、「ベストエフォート」型の信頼度の高い伝送量を確保するのに適した輻輳制御に焦点が当てられている。伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の輻輳制御の現行バージョンは、依然、主として、Ｖａｎ  Ｊａｃｏｂｓｏｎによる基本書（ｃｏｒｎｅｒｓｔｏｎｅ  ｐａｐｅｒ）、並びに、その修正（例えば、ＴＣＰ  Ｎｅｗ  Ｒｅｎｏなど）に基づいている。この輻輳制御は、主流であるＵｎｉｘ、Ｌｉｎｕｘ  ＴＣＰ  プロトコルのパッケージソフトウェア、或いは、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＴＣＰプロトコルのパッケージソフトウェアに用いられている。【００１２】  ここに、ＴＣＰ  Ｒｅｎｏ用の主な修正例を記載する。選択確認応答オプション付き伝送制御プロトコル（ＴＣＰ  ＳＡＣＫ：ＴＣＰ  ｗｉｔｈ  Ｓｅｌｅｃｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）は、確認応答（ＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）データについて一層の改良がなされた機構を取り入れている。ＴＣＰ  Ｎｅｗ  Ｒｅｎｏは、ウィンドウ・データに生ずる多くの損失を回復させるための機構を取り入れている。Ｗｅｓｔｗｏｏｄ＋ＴＣＰは、新たな論理的枠組みを開発している。このＴＣＰ  Ｗｅｓｔｗｏｏｄの主要な構想は、ＴＣＰ通信において許容されるバンド幅を推定するために、ＡＣＫパケットを返信するストリーム型通信を開発することである。このバンド幅の推定は、輻輳ウィンドウ、および、タイムアウト後、或いは、ＡＣＫを３回重複して受信した後のスロースタートの閾値（ｓｌｏｗ−ｓｔａｒｔ  ｔｈｒｅｓｈｏｌｄ）を、適応性を維持しながら低減させるのに用いられる。【００１３】  従来のＴＣＰは、ウィンドウ・データに基づいているが、このような特徴は、データ伝送の集中の原因となっていた。つまり、ソースデータのバーストは、円滑に再生を行うための大容量のバッファをクライアント側に必要とするだけでなく、パケット損失のバーストを経験から把握することを必要とし、これにより、前進型誤信号訂正によるデータ再現を難しくしていた。このことから、ＴＣＰ輻輳制御は、ジッタ遅延に対して感度の低いアプリケーションや、ファイル転送プロトコル（ＦＴＰ）のデータ伝送などのように、伝送レートが急に変化するようなアプリケーションに対して好適なものである一方で、ジ��タ遅延や送信伝送レートの急激な変化に起因して品質が変動し、また、それが知覚されるような映像データの配信には、不向きであった。このため、複数の伝送レートに基づく輻輳制御アルゴリズムを、本項のはじめに記載した一般的な映像伝送フレームワークと統合することが提案された。【００１４】  映像配信に好適な輻輳制御アルゴリズムは、到達パケットのジッタを低減するとともに、受信側における再生用バッファの容量を低減させるために伝送レートに円滑に対応する必要がある。また、Ｒｅｎｏソースにおいて使いやすくするために、マルチメディアや大容量データを伝送するためのｆａｉｒなバンド幅の割付ルーチンを備えることを必要とする。【００１５】  利便性を確保するために、Ｒｅｎｏアルゴリズムの長期挙動のエミュレートを試みた数多くの制御アルゴリズムが提案されてきたが、これらは応答性（レスポンス）がより遅いものであった。ＴＥＡＲ（ＴＣＰ  Ｅｍｕｌａｔｉｏｎ  ａｔ  Ｒｅｃｅｉｖｅｒｓ）伝送レート制御アルゴリズムは、受信側における入力伝送レートを算出し、それを送信側へフィードバックする。この伝送レートは、伝送レートに基づく接続回線の同一経路を経由することにより、仮想上のＲｅｎｏ接続回線の長期挙動スループットの平均値をエミュレートすることによって算出される。ＴＥＡＲは、典型的なセルフタイマ機構を備えておらず、また、高い損失伝送レートのＲｅｎｏ  ＴＣＰに対する適応性が低く、また、輻輳が生じている状況下において送信伝送レートを低減させることができないことが示されてきた。【００１６】  近年、ＴＦＲＣ（ＴＣＰ  Ｆｒｉｅｎｄｌｙ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ）が、主要なアルゴリズムとして用いられている。このＴＦＲＣは、Ｒｅｎｏのスループットの長期挙動をエミュレートしようとしたものである。ＲＦＲＣは、Ｒｅｎｏ  ＴＣＰに使用しやすいように、伝送レートを円滑に変動させることを狙ったものである。利便性を確保するために、ＴＦＲＣの送信側では、Ｒｅｎｏのスループットの長期挙動演算モデルを使用してＲｅｎｏ通信の長期挙動をエミュレートする。この手法によれば、ＴＦＲＣの送信側では、受信側から送信側へフィードバックされた平均損失伝送レートの静的な非線形関数を用いて伝送レートを算出する。ＴＦＲＣは、公平（ｆａｉｒ）ではなく、また、使用しにくいことが実験によりわかった。また、ＴＦＲＣは、遅延が大きく、不均一な損失が発生するという性質をもつＧＰＲＳ（ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｖｉｃｅ）、３Ｇ、４Ｇシステムおよび衛星リンクなどのワイヤレス・リンクに対して、非常に低い性能を示すことが実験によってわかった。【００１７】  提案されているリンク・レイヤは、ワイヤレス・リンクを介した局所的な再伝送および前進型誤信号訂正を使用するワイヤレス・リンクのために損失を隠すように機能する。リンク・レイヤ・プロトコルの一例としては、前進型誤信号訂正（ＦＥＣ）およびＡＲＱ（Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）が挙げられ、これらはＴＤＭＡやＣＤＭＡなどの無線デジタル通信網に用いられている。
【発明の開示】
【発明が解決しようとする課題】
【００１８】  本発明は、特に、無線を利用したインターネットを介したデータ、音声ストリーム、および映像ストリームの伝送効率を大幅に向上させるものである。また、本発明は、音声および映像のソースデータのリアルタイム・ストリーミングの向上を図るものである。
【課題を解決するための手段】
【００１９】  本発明は、パケット交換ネットワークを介してデータ、音声、および映像を送信する際の端末相互間における輻輳制御アルゴリズムを提供することを総括的な目的とする。本発明は、特に、図１に示される一般的な映像配信システムにおいて、符号化スキームと統合されるのに特に適した伝送レートに基づく輻輳制御アルゴリズムを提供する。特に、本発明は、図１に示される伝送レート制御モジュールを用いることにより、ＲＴＰ／ＵＤＰ／ＩＰスタックなどのインターネットプロトコルを介して行われる音声や映像の高品質な配信を実現させることができる。このような伝送レートに基づく輻輳制御アルゴリズムは、端末相互間におけるキューのバックログや占有バンド幅の両方を推定する機構に基づいている。【００２０】  本発明を用いることにより、ＧＳＭ（Ｇｒｏｕｐ  Ｓｐｅｃｉａｌ  Ｍｏｂｉｌｅ）、ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）、３Ｇ、４Ｇ、あるいは、ＵＭＲＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｐｈｏｎｅ  Ｓｙｓｔｅｍ）、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６などの無線リンクを利用したＩＰを介して伝送されるデータ、音声、および映像の伝送効率を向上させることができる。また、本発明を用いることにより、有線回線網（換言すると、ケーブルＴＶネットワーク）、直接放送衛星（換言すると、双方向帰路チャンネルをもつＤＶＢ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔ）を用いたＩＰサービス）、ＶＳＡＴ（Ｖｅｒｙ  Ｓｍａｌｌ  Ａｐｅｒｔｕｒｅ  Ｓａｔｅｌｌｉｔ  Ｔｅｒｍｉｎａｌｓ）、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）、及び、いくつかのパケット無線ネットワークのように、バンド幅が非対称な通信状態であっても、ネットワークにおけるバンド幅の利用率を向上させることができる。これらのネットワークが、高速インターネットアクセス用回線としてますます配備されることは、より一層の伝送性能の向上を図るのに非常に好ましいことである。また、本発明は、バンド幅の利用率における公平性（ｆａｉｒｎｅｓｓ）を増加させる。【００２１】  本発明は、適応符号化を用いて、音声／映像ストリームの伝送をＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）を介して行う場合に適用可能である。適応符号化とは、許容バンド幅の推定値を考慮して実行される符号化の品質を意味する。その一例として、ＭＰＥＧ−４  Ｆｉｎｅ−Ｇｒａｉｎｅｄ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇのような階層符号化が挙げられるが、その際には、転送されるレイヤ数が許容バンド幅の推定値に基づいて選択され得る。【００２２】  本発明は、ＵＤＰプロトコル上で実行され、リアルタイム配信を行うＲＴＰ（ｔｈｅ  Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）に利用されるものとして考案されたアプリケーションに適用可能である。バンド幅推定値は、ＲＴＰ制御プロトコルにより、受信側から送信側へ配信されるものである。【００２３】  以上、本発明に係る主な特徴について述べてきた。本発明の他の特徴および本発明を十分に理解するための説明は、以下に続く「発明を実施するための最良の形態���の項にて言及するものとする。
【発明を実施するための最良の形態】
【００２４】  本発明の理解ならびにその利点をより完全なものとするために、後述の詳細な説明において参照される図面は以下の通りである。
図１には、一般的な映像配信システムが示されている。
図２には、本発明が実行されるシステムが示されている。
図３には、回線の送信側にて実行される伝送レート制御が示されている。
図４には、サーバ側または回線のクライアント側で実行されるバンド幅の推定について示されている。【００２５】  公知のインターネットクライアントーサーバシステムは、図２に示されるような構成により実現される。クライアント／サーバ装置１０は、ネットワーク２を介してクライアント／サーバ装置１４に接続されている。詳述すると、ネットワーク１２は、インターネット、イントラネット、エクストラネット、衛星回線、あるいはその他の無線または有線のネットワークである。クライアント／サーバ装置は、クライアント、サーバ、あるいは、ピアツーピア（Ｐｅｅｒ−ｔｏ−ｐｅｅｒ）アプリケーションなどのクライアント−サーバになり得る装置である。基本的には、サーバは、処理装置、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  ＸＰ（登録商標）、ＩＢＭ  ＯＳ／２（登録商標）、Ｓｕｎ  Ｓｏｌａｒｉｓ（登録商標）、Ｕｎｉｘ、Ｌｉｎｕｘなどのオペレーティングシステム、Ｎｅｔｓｃａｐｅ  Ｅｎｔｅｒｐｒｉｓｅ  ｓｅｒｖｅｒ（登録商標）、Ａｐａｃｈｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ（登録商標）などのウェブサーバプログラムから構成されるコンピュータである。また、サーバは、アプリケーション開発者がソケットバッファのサイズなどの伝送レイヤのパラメータを拡張する或いはカスタマイズすることを許容するＭＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を有している。サーバは、携帯可能なサーバでも良い。【００２６】  クライアント装置は、基本的には、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  ＸＰ（登録商標）、ＩＢＭ  ＯＳ／２（登録商標）、Ｓｕｎ  Ｓｏｌａｒｉｓ（登録商標）、Ｕｎｉｘ、Ｌｉｎｕｘなどのオペレーティングシステなどを備えるＰｅｎｔｉｕｍ（登録商標）、Ｍｏｔｏｒｏｌａ（登録商標）、あるいはＲＩＳＣ（登録商標）などの処理装置、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｐｌｏｒｅｒ（登録商標）、或いはＮｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ（登録商標）などのウェブブラウザ、およびＲｅａｌ  Ｎｅｔｗｏｒｋ（登録商標）、あるいはＷｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｐｌａｙｅｒ（登録商標）などのアプリケーションプログラムに基づくパーソナルコンピュータである。また、クライアント装置は、ノート型パソコン、ＰＤＡ、携帯電話機などの携帯可能な装置、または、有線回線或いは無線ＬＡＮ（換言すると、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６）、ＨｙｐｅｒＬａｎ、Ｂｌｕｔｏｏｔｈ、ＧＰＲＳ、３Ｇ、４Ｇ、ＵＭＴＳなどの無線回線を介してコンピュータネットワークに接続可能な他の装置である。また、クライアントーサーバ通信は、携帯電話機やＰＤＡなどのモバイルホスト（ｍｏｂｉｌｅ  ｈｏｓｔｓ）間に構築される。クライアント装置は、Ｓｙｍｂｉａｎ（登録商標）Ｐａｌｍ  ＯＳ（登録商標）、Ｍｉｃｒｏｓｏｆｔ’ｓ  Ｗｉｎｄｏｗｓ  Ｍｏｂｉｌｅ  ｆｏｒ  Ｓｍａｒｔｐｈｏｎｅ（登録商標）（ＷＭＳ）およびＬｉｎｕｘなどのオペレーティングシステムを備えている。【００２７】  クライアント／サーバ装置は、基本的には、パ��ソナルコンピュータ、または、ファイル、音声、映像或いは、インターネットプロトコルを介して電話の映像や音声を伝送するためのアプリケーションソフトウェアなどを共有するためのピアツーピア・アプリケーションを実行する一般的な携帯ツール（ｍｏｂｉｌｅ  ｈａｎｄｓｅｔ）である。【００２８】  本発明は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＴＣＰ、Ｓｕｎ  Ｓｏｌａｒｉｓ  ＴＣＰ  Ｓｙｍｂｉａｎ  ＴＣＰ、Ｐａｌｍ  ＯＳ  ＴＣＰ、Ｍｉｃｒｏｓｏｆｔ’ｓ  Ｗｉｎｄｏｗｓ  Ｍｏｂｉｌｅ  ｆｏｒ  Ｓｍａｒｔｐｈｏｎｅ  ＴＣＰ、及びＬｉｎｕｘ  ＴＣＰなどのＴＣＰプロトコルに適したいくつかのオペレーティングシステムにより実現することができる。【００２９】  本発明は、また、ＲＴＰ／ＵＤＰプロトコル上で作動するアプリケーションにより実現することができる。例えば、これらのアプリケーションとしては、Ｒｅａｌ  Ｎｅｔｗｏｒｋｓ（登録商標）あるいはＷｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｐｌａｙｅｒ（登録商標）などのように音声／映像ストリームのために設計されたアプリケーションや、リアルタイム会議のために設計されたアプリケーションが一例として挙げられる。【００３０】  本発明は、図３に示される伝送レート制御部４１により実現される伝送レートに基づく輻輳制御機構を提供する。本発明は、パケットネットワーク１２を介してデータ伝送、音声／映像ストリーミング、およびリアルタイム会議を行うために設計されたものである。本発明は、図１に示されるような一般的なフレームネットワークにおいて用いられるＭＰＥＧ−４  Ｆｉｎｅ  Ｇｒａｉｎｅｄ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇのような適応符号化に用いることができる。【００３１】  図３に、本発明の概要を示す。送信側のアプリケーションソフトウェアは、クライアント側の受信機４４に届いた送信伝送レートｒ（ｔ）を算出する。時刻ｔにおける送信伝送レートｒ（ｔ）は、以下のように算出される。【００３２】
2007504694.tif 000003
【００３３】  ここで、ｋは比例定数、［ｘ］＋は、（０，ｘ）の最大値、ｗ（ｔ）は後述するような式で与えられる関数、ｓ（ｔ）は、ネットワークを介して送信側に明らかな輻輳のフィードバックが無いときには無限大をとり、ネットワークを介して輻輳のフィードバックがあるときには適切な値をとる関数である。例えば、ｓ（ｔ）は、ＴＣＰにおけるウィンドウの流量（ＴＣＰ  Ａｄｖｅｒｔｉｓｅｄ  Ｗｉｎｄｏｗ）または受信側の残りバッファサイズ（ｓｐａｃｅ  ａｖａｉｌａｂｌｅ）、あるいは接続経路上の残りバッファサイズの最小値と、同じ値をとる。ＲＴＴは、ラウンドトリップ時間、ｍｉｎ（ｗ（ｔ），ｓ（ｔ））は、ｗ（ｔ）およびｓ（ｔ）の最小値である。【００３４】  ｋは、基本的には０．１ｓ−１から０．５ｓ−１の間の値、或いは、１／ＲＴＴｍの値をとる。ここで、１／ＲＴＴｍはラウンドトリップ時間の最小値である。【００３５】  関数ｗ（ｔ）は、以下のような増加フェーズ（Ｉｎｃｒｅａｓｉｎｇ  Ｐｈａｓｅ）および減少フェーズ（Ｄｅｃｒｅａｓｉｎｇ  Ｐｈａｓｅ）の状態をとる正関数である。増加フェーズは、端末およびネットワーク容量のプロービングを行い、輻輳が発生した場合に終了する。輻輳が発生した場合、関数ｗ（ｔ）は、減少フェーズに入り、その後再び、増加フェーズに入る。【００３６】  特に効率的な増加フェーズは、以下の名前を持つ２つのフェーズから形成されている。
（Ｉ）クイック・プロービング（ｑｕｉｃｋ  ｐｒｏｂｉｎｇ）（ＩＩ）ジェントル・プロービング（ｇｅｎｔｌｅ  ｐｒｏｂｉｎｇ）【００３７】  クイック・プロービングの期間において、関数ｗ（ｔ）は、小さい値から急激に値が増加する増加関数として設定される。詳細には、クイック・プロービング・フェーズは、以下の式のように実施される。【００３８】
2007504694.tif 000004
【００３９】  ここで、ｔ０は、前回、クイック・プロービング・フェーズが開始された時間である。ｗ（ｔ０）は、基本的には値２をとり、αは基本的には、０．１から０．５の間の値、或いは、ＲＴＴｍと等しい値をとる。また、ｃは、基本的には２であるが、３，４或いはそれ以上の値、並びに、これらの整数間の実数値をとりうる。更に、ｃは、ｗ（ｔ）の関数、即ち、ｃ＝ｃ（ｗ）として求められる推定値である。ｗ（ｔ）が、初期状態において、クライアントコネクションリンク（例えば、６４Ｋバイト）のバンド幅容量に応じて決定される初期値に設定される閾値ｓｓｔｈｒｅｓｈと等しいときに、プロービング・フェーズがジェントル・プロービング・フェーズに入る。【００４０】  ジェントル・プロービングの期間において、関数ｗ（ｔ）は、以下のように設定される。【００４１】
2007504694.tif 000005
【００４２】  ここで、ｔ０は、前回、ジェントル・プロービング・フェーズに入った時間である。βは基本的には、０．１から０．３の間の値、或いは、ＲＴＴｍと等しい値をとる。また、βは、ｗ（ｔ）の関数、即ち、β＝β（ｗ）として求められる推定値である。【００４３】  輻輳が発生している期間において、入力伝送レートを低減させるために、縮退相（ｓｈｒｉｎｋｉｎｇ  ｐｈａｓｅ）を始動させることが必要となる。輻輳の発生は、明示的輻輳通知（ＥＣＮ：Ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を行うルータ、または、周知のルータによって確実に通知され、また、以下に示す２つのイベントによって推定することができる。（１）パケット受信のシーケンスにホールが生ずることに起因して受信側から送信側に対してフィードバック・レポート（ｆｅｅｄｂａｃｋ  ｒｅｐｏｒｔ）が送られたとき；（２）送信側が受信側から長い時間にわたり一切のレポートを受信しなかったことによりタイムアウト時間を超過して、タイムアウトが生じたとき。【００４４】  タイムアウトは、以下のような標準規格のＴＣＰにより算出される。また、フィードバック・レポート４６の流れが図３に示されている。
送信側では、ＥＣＮにより、または、ｎ（通常は、ｎ＝３）回にわたって重複してＡＣＫが送られることにより、若しくはフィードバック・レポートが送られることにより、時刻ｔ１において輻輳の発生が通知されると、関数ｗ（ｔ）の値は、時刻ｔ１における関数ｗ（ｔ１）の値から
2007504694.tif 000006
時刻ｔ１における許容バンド幅、ＲＴＴｍはラウンドトリップ時間の最小値である。時刻ｔ１＋ＲＴＴｍにおいて、ｗ（ｔ）は再びジェントル・プロービング・フェーズに入る。【００４５】  具体的には、減少関数は、以下に示すような線形的な減少関数として設定される。【００４６】
2007504694.tif 000007
【００４７】
2007504694.tif 000008
時刻ｔ１における許容バンド幅、ＲＴＴｍはラウンドトリップ時間の最小値である。時刻ｔ１＋ＲＴＴｍのとき、ｗ（ｔ）の設定は、再びジェントル・プロービング・フェーズに入る。【００４８】  送信側では、タイムアウトが生ずることによって、時刻ｔ１において輻輳イベントが通知されると、関数ｗ（ｔ）を以下に示すように設定することによって対応する。【００４９】
2007504694.tif 000009
【００５０】  ここで、ｔ０は、前回、クイック・プロービング・フェーズに入った時間である。ｗ（ｔ０）は、基本的には値２をとり、αは基本的には、０．１から０．５の間の値、或いは、ＲＴＴｍと等しい値をとる。また、ｃは、基本的には２であるが、３，４或いはそれ以上の値、並びに、これらの整数間の実数値をとりうる。更に、ｃは、関数ｗ（ｔ）、即ち、ｃ＝ｃ（ｗ）として求められる推定値である。閾値ｓｓｔｈｒｅｓｈは、以下のように設定される。【００５１】
2007504694.tif 000010
【００５２】
2007504694.tif 000011
値である。ｗ（ｔ）が閾値ｓｓｔｈｒｅｓｈと等しくなったとき、ジェントル・プロービング・フェーズに再び入る。【００５３】
2007504694.tif 000012
ともに、これらの受信パケットにフィルタを施す。具体的には、ラウンドトリップ時間毎、または、ＳＲＴＴ（Ｓｍｏｏｔｈｅｄ  Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）毎に、時刻ｔｉにおける使用バンド幅Ｂ（ｉ）のサンプルが、以下の式に基づき受信側において算出される。この際、ＳＲＴＴは、有名なＶａｎ  Ｊａｃｏｂｓｏｎアルゴリズムを用いて算出される。【００５４】
2007504694.tif 000013
【００５５】  ここで、Ｄ（ｉ）は、前回、ＳＲＴＴ＝Ｔ（ｉ）またはＲＴＴ＝Ｔ（ｉ）の期間に受信されたデータ量である。受信したパケット数をカウントすることにより、受信側にてルーチンを実現させることができ、また、ＡＣＫパケットをカウントすることにより、送信側にてルーチンを実現させることができる。ネットワークの輻輳は、許容バンド幅のローパス要素に依存するので、バンド幅のサンプルＢ（ｉ）を平均化することが必要となる。これは、以下に示すような時間に伴い変化するフィルタを用いることで実現可能である。【００５６】
2007504694.tif 000014
【００５７】
2007504694.tif 000015
におけるバンド幅サンプル、τｆはフィルタの時定数（基本的にはτｆ＝０．５ｓ）である。Ｔ（ｉ）がτｆ／４より大きい場合、４・Ｔ（ｉ）／τｆの値をとる整数Ｎを用いて内挿および再度のサンプリングを行う。仮想サンプルＢ（ｉ）は、エイリアシング効果を防ぐために、Ｔｖ（ｉ）＝τｆ／４の時間間隔で届くこととなる。【００５８】  バンド幅サンプルＢ（ｉ）を平均化するために、以下の（８）式に示す時不変フィルタを用いることができる。【００５９】
2007504694.tif 000016
【００６０】  ここで、αは、基本的には、７／８の値をとりうる。
2007504694.tif 000017
受信側から送信側に送られ、送信側にて用いられる。【００６１】
2007504694.tif 000018
ことによって算出することができる。ここで、連続して配置されているフィルタは、上述したフィルタであり、許容バンド幅のサンプルＢ（ｔ）が連続するフィルタのうちの最初のフィルタに入力されることとなる。【００６２】  また、許容バンド幅は、送信側において、ＡＣＫパケットを用いてＤ（ｉ）を算出することにより、推定することができる。図４は、許容バンド幅を計算するルーチンの２つの取りうる位置、即ち、３０または３２を示したものである。パケット２２は、送信側から受信側へ向かって流れる。【００６３】  ＡＣＫパケット（ＡＣＫｓ）２０は、受信側から送信側へ向かって流れる。このスキーム、或いは、他の似たようなスキームは、前方へデータを送信し、それとは逆行して制御データを送信するというスキームに基づいており、ＴＣＰ／ＩＰプロトコル或いはＲＴＰ制御プロトコルなどのプロトコル、或いは、非同期転送モード（ＡＴＭ）ネットワークなどのその他のパケットネットワークによって、輻輳制御に利用される。ＡＣＫパケット２０を返信する流れ（フロー：ｆｌｏｗ）は、送信側のルーチン３２において許容バンド幅を算出するのに利用され、一方、パケット２２の流れは、クライアント側のルーチン３０により、許容バンド幅を算出するのに利用される（米国特許出願公開第２００２／００８５５８７号明細書も参照。）。【００６４】
2007504694.tif 000019
するネットワークにおける許容バンド幅に適応させるために用いられる。その一例として、ＭＰＥＧ−４Ｆｉｎｅ−Ｇｒａｉｎｅｄ  Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇのような階層符号化が挙げられるが、その際には、転送されるレイヤ数が許容バンド幅の推定値に基づいて選択され得る。【００６５】  本発明によれば、主に、以下のような効果を奏する。（１）特に、ワイヤレス・リンクなどのネットワークにおける許容バンド幅をより一層効果的に利用することが可能となる。（２）パケットネットワークを介したデータ伝送における性能を向上させることができる。（３）パケットネットワークを介して伝送される音楽および映像のストリーミングの品質向上を図ることができる。（４）パケットネットワークを介したリアルタイム会議の品質向上を図ることができる。
【図面の簡単な説明】
【００６６】
【図１】  一般的な映像配信システムを示す図である。
【図２】  本発明が実行されるシステムを示す図である。
【図３】  回線の送信側にて実行される伝送レート制御について示した図である。
【図４】  サーバ側または回線のクライアント側で実行されるバンド幅の推定について示した図である。
【符号の説明】
【００６７】１０  クライアント／サーバ
１２  パケットネットワーク
１４  クライアント／サーバ
４１  伝送レート制御部
４４  受信機
３０，３２  ルーチン
２０  ＡＣＫパケット
２２  パケット
【図１】
2007504694.tif 000037
【図２】
2007504694.tif 000038
【図３】
2007504694.tif 000039
【図４】
2007504694.tif 000040
【国際調査報告】
2007504694.tif 000041
2007504694.tif 000042
2007504694.tif 000043
2007504694.tif 000044
2007504694.tif 000045