(57)【要約】ソース（１０５）と転送先（１０７）との間でストリーミング・デジタル情報信号の伝送および提示を行うためのシステムおよび方法であって、グッドプット、スループット、遅延、受信機バッファ要件、ならびに損失およびジッタに対する許容限度を含め、性能の様々な特質の競合を鑑みた性能の最適化に用いることができる。該システムは、情報のセグメントの各々に関連付けられた優先順位に基づいて情報のセグメントを順序付けること、情報のセグメントの優先順位に基づいてバッファ（１０１）に入出力するセグメントの流れを管理すること、情報が通信媒体（１０１）に供給される速度を調整すること、および情報を送信することを行う。
2005526422.tif 000002
【特許請求の範囲】
【請求項１】
情報のセグメントの各々に関連付けられた優先順位に基づいて情報のセグメントを順序付けること、
情報のセグメントの優先順位に基づいてバッファへ入出力するセグメントのフローを管理すること、
情報が通信媒体に供給される速度を調整すること、および
情報を送信すること
を含むデジタル通信提供方法。
【請求項２】
前記情報のセグメントの優先順位がセグメント間の依存性に基づいて計算および再計算される、請求項１記載の方法。
【請求項３】
前記計算および再計算は、さらに、特定のセグメントが指定時間ＴＤまでに転送先に到達できるかどうかに基づく、請求項２に記載の方法。
【請求項４】
指定時間ＴＤが現在時刻ｔｃに伝送時間ｔｔを加算した値より大きい場合、特定のセグメントが指定時間までに転送先に達することができないと判断する、請求項３に記載の方法。
【請求項５】
指定時間ＴＤが現在時刻ｔｃに伝送時間ｔｔを加算した値より大きい場合、前記特定のセグメントを落とす、請求項４に記載の方法。
【請求項６】
前記計算および再計算は、さらに、転送先の性能に基づく、請求項２に記載の方法。
【請求項７】
前記転送先の性能は、転送先が強い後処理能力を有するかどうかを含む、請求項６に記載の方法。
【請求項８】
前記転送先の性能は、転送先がエラーコンシールメントを提供できるかどうかを含む、請求項６に記載の方法。
【請求項９】
前記転送先の性能は、転送先での受信速度がソースから転送先への伝送速度より小さい場合、転送先が情報のセグメントを落とすことができるかどうかを含む、請求項６に記載の方法。
【請求項１０】
前記計算および再計算は、さらに、ソースと転送先の間の接続履歴に基づく、請求項２に記載の方法。
【請求項１１】
通信媒体に予め提供された帯域幅の量に基づいて通信媒体に予測される帯域幅を計算することを更に含む、請求項１０に記載の方法。
【請求項１２】
前記情報の送信を、平均帯域幅の範囲内の速度で実行する、請求項１０に記載の方法。
【請求項１３】
前記情報の送信を、前記通信媒体上に予め提供された最小帯域幅の範囲内の速度で実行する、請求項１０に記載の方法。
【請求項１４】
前記計算および再計算は、さらに、前記通信媒体と前記ソースの間の速度ずれに基づく、請求項２に記載の方法。
【請求項１５】
前記情報が該情報の個々のセグメントの属性に基づいて送信される速度を調整することを更に含む、請求項１４に記載の方法。
【請求項１６】
優先順位の計算では前記転送先で要求されたサービス品質が考慮される、請求項２に記載の方法。
【請求項１７】
優先順位の計算では前記情報のセグメントの属性が考慮される、請求項２に記載の方法。
【請求項１８】
優先順位の計算では前記通信媒体の性能が考慮される、請求項２に記載の方法。
【請求項１９】
前記通信媒体の性能は、帯域幅、通信速度、および前記情報のセグメントの再送信時間の少なくとも１つを含む、請求項１８に記載の方法。
【請求項２０】
優先順位の計算ではバッファに保持された情報の管理の特性を考慮する、請求項２に記載の方法。
【請求項２１】
バッファに保持された情報を管理することは、更に、
バッファに置かれることになる到来する情報のセグメントの優先順位を予測すること、および
到来する情報のセグメントの全てを受信するのに十分な容量をバッファが有するかどうか決定すること
を含む、請求項１に記載の方法。
【請求項２２】
バッファに保持された情報を管理することは、更に、
到来する情報のセグメントの全てを受信するのに十分な容量をバッファが有しないと決定した場合、情報のセグメントを落とすこと
を含む、請求項２１に記載の方法。
【請求項２３】
落とされた情報のセグメントは、到来する情報のセグメントより低い優先順位を有する、請求項２２に記載の方法。
【請求項２４】
バッファ内の情報のセグメントが、到来する情報のセグメントの少なくとも１つの優先順位と同じかそれより低い優先順を有するかどうかを決定すること、および
バッファ内の情報の少なくとも１つのセグメントが、到来する情報のセグメントの少なくとも１つの優先順位と同じかそれより低い優先順を有すると決定した場合、バッファが少なくとも１つの到来するセグメントを受信する前に、少なくとも１つの到来するセグメントより低い優先順位を有する少なくとも１つの情報のセグメントをバッファから落とすこと
を更に含む、請求項２１に記載の方法。
【請求項２５】
情報のセグメントを選択的に落とすことを更に含む、請求項１に記載の方法。
【請求項２６】
従属セグメントが落とされたセグメントに依存すると決定された場合、従属する情報のセグメントを落とす、請求項２５に記載の方法。
【請求項２７】
前記セグメントの１つが他の前記セグメントより低い優先順位を有する場合、該セグメントを落とする、請求項２６に記載の方法。
【請求項２８】
情報が通信媒体に供給される速度を、通信媒体上の往復時間および損失率を用いて計算する、請求項１に記載の方法。
【請求項２９】
前記速度を、通信媒体の通信速度の可用性に基づいて調整する、請求項１に記載の方法。
【請求項３０】
前記速度の調整は、
情報が通信媒体に供給される速度が、通信媒体がデータを伝送することができる速度より小さい場合、使用していない帯域幅容量の帯域幅クレジットを累積することを含む、請求項１に記載の方法。
【請求項３１】
前記帯域幅クレジットは、前記通信媒体上の実際の接続速度とＴＣＰフレンドリ速度との間の差分である、請求項３０に記載の方法。
【請求項３２】
情報が通信ネットワークに供給される速度が、前記通信媒体上のＴＣＰフレンドリ速度より大きい場合、累積した帯域幅クレジットを消費することを更に含む、請求項３０に記載の方法。
【請求項３３】
ｆｘｘ（Ｃｉｄｅａｌ／２）の渋滞ウインドウを提供すること（Ｃｉｄｅａｌ＝帯域幅と遅延の積、Ｒ＊ｒｔｔとして計算された理想的な渋滞ウインドウ、ｒｔｔ＝通信媒体上の往復時間、Ｒ＝フローのデータ速度）、
渋滞が増加した場合、定数ｘの増加関数により渋滞制御ウインドウを増加させること、
渋滞が減少した場合、ｆｙｙ（Ｍａｘ（０，Ｃｃｕｒｒｅｎｔ−Ｃｉｄｅａｌ））（Ｃｃｕｒｒｅｎｔ＝現在の渋滞制御ウインドウ）により渋滞制御ウインドウを減少させること
により渋滞制御を提供することを更に含む、請求項１に記載の方法。
【請求項３４】
前記渋滞制御を提供することは、
理想的なウインドウサイズである渋滞ウインドウから開始すること、
定数ｘの関数により渋滞ウインドウを増加させること、および
渋滞ウインドウが理想的なウインドウサイズよりどれだけ大きいかの関数により渋滞ウインドウを減少させること
を更に含む、請求項１に記載の方法。
【請求項３５】
セグメントを順序付けること、
バッファに入出力するセグメントのフローを管理すること、および
転送先でのサービス品質要求に基づいて速度を調整すること
を調整することを更に含む、請求項１に記載の方法。
【請求項３６】
前記サービス品質の要求が転送先のユーザによって提供される、請求項３５に記載の方法。
【請求項３７】
セグメントを順序付けること、
バッファに入出力するセグメントのフローを管理すること、および
転送先の機器の能力に基づいて速度を調整すること
を調整することを更に含む、請求項１に記載の方法。
【請求項３８】
セグメントを順序付けること、
バッファに入出力するセグメントのフローを管理すること、および
通信媒体の能力に基づいて速度を調整すること
を調整することを更に含む、請求項１に記載の方法。
【請求項３９】
セグメントに関する時間同期情報を転送先へ提供することを更に含む、請求項１に記載の方法。
【請求項４０】
セグメントに関する優先順位署名情報を転送先へ提供することを更に含む、請求項１に記載の方法。
【発明の詳細な説明】
【発明の開示】
【０００１】
本出願は、２００１年９月２７日に出願された米国仮特許出願第６０／３２５０１７号の利益を主張する。該米国仮特許出願は、本明細書に十分に開示するように、全ての目的のために参照することにより、本明細書に包含する。
【０００２】
発明の分野
本発明は、信号を送信するためのシステムおよび方法に関する。とりわけ、本発明は、ソースと受信機との間で、タイム・センシティブで、完全に信頼できるデジタル信号を送受信するためのシステムおよび方法に関する。
【０００３】
関連技術の説明
タイム・センシティブで、完全に信頼できないデジタル信号は、オーディオ、オーディオおよびグラフィックス、ビデオ、ならびに、同期オーディオおよびビデオデータを含む、単一メディアおよびマルチメディア・データ・ストリームを含む。本明細書において説明するように、本発明の概念は、データ送信はタイム・センシティブであるが、完全な信頼性により与えられる忠実度を必要としない、少なくとも１つの送信機から少なくとも１つの受信機へデジタル情報をストリーミングする任意のシステムに適用可能である。加えて、伝送されるデータまたは情報は、データまたは情報（例えば異質な優先順位）の優先順位スキーマ、例えば、パケットなどの異なる部分に割り当てられる多重優先順位を有することができる。
【０００４】
例えば、マルチメディア・データは、タイムクリティカルな方法でユーザに提示される。例えば、データがあまりに遅く、あるいは間違った順序で提示される場合、ユーザの聴覚体験は妨害される。あまりに遅く提示される場合、ユーザは、スピーカに適しているものより低い周波数の音声を聞く可能性があり、提示の忠実度を減少させる。減少した忠実度は、オーディオデータ、例えば音楽の有用性を減少させる。データがシーケンスから欠落するか、入れ替わる場合、ユーザは、スピーカから出力されている音声を確定することができない可能性があり、これは、通信の有用性を減少させる。他の例として、ビデオデータがシーケンスから外れて、またはオーディオデータの同期から外れて提示される場合、ユーザの視覚体験が妨害される。１つのフレームに対する送信時間より長い時間スケールでシーケンスから外れたビデオデータは、フレームがシーケンスから外れて示されると円滑な動きがジグザグになることを引き起こし、動きが重要なビデオ、例えば、ダンス、スポーツ競技、および科学研究のための有用性が破壊される。より短い時間スケールでシーケンスから外れたビデオデータは、単一のフレームの部分が表示画面上の誤った空間位置で提示されることを引き起こす。このため、映像は、良くてもゆがめられ、最悪の場合、認識できなくなる。
【０００５】
マルチメディア・データは、当該技術で知られている多くの形式をとる。例えば、オーディオデータは、様々なフォーマットを用いるバイナリ・データのファイルとして格納される。いくつかのフォーマットにおいて、データは、ファイルに格納されているときの二進数（ビット）の数が、人間の観察者に提示する間に用いられるビット数より少なくなるように、圧縮される。それらのデータを格納するのに用いられるファイル名に拡張子でしばしば示される画像フォーマットの例には、数ある中で、ＧＩＦ、ＪＰＥＧ、ＴＩＦＦ、ビットマップ（ＢＭＰ）、ＣＧＭ、ＤＸＦ、ＥＰＳ、ＰＣＸ、ＰＤＦ、ＰＩＣが含まれる。それらのデータを格納するのに用いられるファイル名に拡張子でしばしば示されるオーディオフォーマットの例には、数ある中で、ウェーブファイル（ＷＡＶ：wave form audio）、ＭＰ３、アイフ（ＡＩＦＦ：audio interchange file format）、ユニックス・オーディオ（ＡＵ）、ミディ（ＭＩＤＩ：musical instrument digital interface）、およびサウンドファイル（ＳＮＤ）が含まれる。それらのデータを格納するのに用いられるファイル名の拡張子でしばしば示されるビデオフォーマットの例には、数ある中で、クイックタイム、ＡＶＩおよびエムペグ（ＭＰＥＧ：Motion Picture Experts Group format）が含まれる。この主題は更に、「Video Communication, (1) Image and Video Compression Standards, V. Bhaskaran and K. Konstantinides, Kluwer Academic, 1995」なる書籍で扱われている。
【０００６】
複数の複雑なシステムが通信するのを可能にするため、規格の共通セットが確立され、システムおよびコンポーネント製造業は、それらシステムおよびコンポーネントに用いることに同意した。これら規格は、複数の機能の基本的なセットに関する。機能の中で、かつ最も基本的なレベルは、情報を交換するための、通信機能およびルール、またはプロトコルである。適用可能な規格は、データの文法構造、および、例えば、ＭＰＥＧ、ケーブル、インターネットなど、それを介してデータが送信されるネットワークまたはシステムに依存する。例えば、２つの周知のインターネットプロトコルは、伝送制御プロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）である。本発明の原理は、基本的なプロトコルに関係なく、そのようなシステムのいずれにも適用可能である。
【０００７】
ＴＣＰは、完全な信頼性を可能にするフィードバック・ループを含む。ＴＣＰは、データの配信を保証し、かつ、パケットが送られたときと同じ順序で配信されることを保証する。ＴＣＰは、フィードバック情報によって示されるように、パケットの多重再送信を可能にすることにより、パケット損失から回復しようとし、パケット損失が認められた場合、送信速度を動的に調整する。しかしながら、パケット損失を最小限に抑えることの見返りは、再送信処理によって生じる固有の遅延である。したがって、ＴＣＰは、マルチメディア伝送にとって特に遅く、例えば、ＴＣＰを用いた場合、ビデオ伝送が遅くなる。実際、損失状態の下でＴＣＰを用いるシステムは「フリーズ」し、それによりユーザがストリーミング情報を見ない、または聞かない場合があるので、サービス品質が低下する。サーバからのデータバケット送信とクライアントでのパケット受信との間の遅延はネットワーク待ち時間と呼ばれる。ＴＣＰは、十分な信頼性を必要とする、待ち時間に対する耐性が大きいデータトラヒックにとって良いプロトコルである。
【０００８】
ＵＤＰは、信頼性機構やフィードバック・ループを有しておらず、大荒れのビデオ伝送を提供する。ＵＤＰは非常に単純（または「鈍い」）ので、遅延がないが、再送信が許されない。ＵＤＰは、待ち時間に対する耐性の無い通信により適している。例えば、ＵＤＰは、しばしばブロードキャスト伝送のために用いられる。
【０００９】
アプリケーションは、インターネットやケーブルのようなネットワークを介して伝送されるストリーミング信号の表示品質を向上させるために適合させられた。しかしながら、そのようなアプリケーションは、帯域幅が制限される場合、伝送に問題が内在するため、依然として高解像度ディスプレイを提供するものではない。
【００１０】
発明の概要
したがって、本発明は、関連技術の限界および障害による、１つ以上の課題をほぼ取り除く、クライアントとサーバ機器の間のサービス品質をシグナリングするシステムおよび方法を目的とする。
【００１１】
本発明の利点は、グッドプット、スループット、遅延、受信機のバッファ要件、ならびに損失およびジッタに対する許容限度を含め、パフォーマンスの様々な特質の競合を鑑みてパフォーマンスを最適化する、ストリーミング・デジタル情報信号の伝送および提示を提供することである。
【００１２】
本発明の他の利点は、信頼性を最大化し、待ち時間を最小限に抑えることである。
【００１３】
本発明の他の利点は、ユーザの経験と要求という観点からパフォーマンスの特質を調整することである。
【００１４】
本発明の他の利点は、伝送された信号の損失を迅速に検出するための技術を提供することである。
【００１５】
本発明の他の利点は、送信機または中間ノードにおいて、主導的なバッファ管理を提供することである。
【００１６】
本発明の他の利点は、固定ビットレート環境における速度制御または渋滞制御のための技術を提供することである。
【００１７】
本発明の他の利点は、可変ビットレート環境における速度制御または渋滞制御のための技術を提供することである。
【００１８】
本発明の他の利点は、受信機のサービス品質の要求を示すために、送信機へインタラクティブ信号またはフィードバックを提供することである。
【００１９】
本発明の他の利点は、接続の進捗に従って、特定のデータに対する属性の動的な優先順位付けを提供することである。
【００２０】
本発明によるシステム適合と技術は、非レガシーシステムおよびレガシーシステムの双方に対して有益である。本発明によるシステム適合と技術は、アプリケーションまたはソースおよびクライアント・ノードのトランスポート層、および、場合によっては、ネットワークまたはルータあるいはその他ノードのデータリンクレベルで得ることができる。アプリケーション層以外のレベル（例えばトランスポート層）での適合は、如何なるレガシー・アプリケーションにも影響を及ぼさずに細粒度適合（fine grained adaptation）が可能であるため、レガシー・アプリケーションにとって有益である。そのような適合は、アプリケーション層でしか実行することができず、それゆえ粗粒度方法（coarse-grained fashion）にしか適合できず、またレガシー・アプリケーションのパフォーマンスを向上させるために用いることができない従来の適合とは異なる。
【００２１】
本発明の更なる特徴および利点は、以下の説明で述べられ、ある程度が説明から明白になり、あるいは本発明の実行により理解することができる。本発明の目的と他の利点は、特に、本明細書および特許請求の範囲、並びに添付図面に示す構造により実現され、達成される。
【００２２】
ここに実施例を示し概略を説明するように、これらの利点と他の利点を達成するための、本発明の目的に従うデジタル通信を提供するための方法は、情報のセグメントの各々に関連する優先順位に基づいて情報のセグメントを並べ、情報のセグメントの優先順位に基づいてバッファへ入出力するセグメントの流れを管理し、情報が通信媒体に供給される速度を調整し、情報を送信することを含む。
【００２３】
本発明の他の態様では、｛次の独立請求項を挿入する｝
【００２４】
上述の一般的な説明と以下の詳細な説明の双方は、例示的および説明的なものであり、特許請求の範囲に記載した本発明をさらに説明することを意図していると理解されたい。
【００２５】
添付図面は、本発明のより深い理解を促すものであり、本明細書に包含されて本明細書の一部を構成するものである。それらは、本発明の実施形態を詳細に説明し、明細書と共に本発明の理念を説明する。
【００２６】
ここで、本発明の実施形態を詳細に参照する。その幾つかの例を添付図面に示す。
【００２７】
図１は、本発明による、送信機１０５から受信機１０７への、および受信機１０７から送信機１０５への、本システムを用いるデータフロー１０１、制御経路１０２およびフィードバック１０３の一例を示す。経路の各々を、図１について検討する。
【００２８】
データフロー経路１０１は、送信機１０５から受信機１０７までである。データフローは、送信機１０５側または受信機１０７側での複数の動作のいずれかにより影響を受ける。また、データタイプは、データ上で実行される様々な動作に影響し得る。
【００２９】
図１を参照すると、データに割り当てられる優先順位は、送信機１０５側のエキスパート・システム１０９によって割り当てられる。また、送信機１０５側は、エキスパート・システム１０９によって割り当てられた優先順位に基づき、データ経路１０１に沿った伝送のために重要なデータまたはデータパケットを複製１１１してもよい。また、パケット・インターリービング１１３が送信機１０５側で実行される。これは、動的な優先順位付けエキスパート・システム１０９によって割り当てられた優先順位に従って実行されてもよい。誤り訂正コーディングの他の技術も適用できる。データはバッファリング１１５され、伝送媒体、例えば、インターネットのようなオープン・ネットワーク上、広域またはローカル・エリア・ネットワークのようなクローズド・ネットワーク上、ブロードキャスト・システム上、またはポイント・ツー・ポイントシステム上などに置かれる。一般的に、データは、伝送媒体上に置かれる前に、ネットワーク・インターフェースのようなインターフェース１１７を通過する。
【００３０】
受信機１０７側において、データは、一般的に、ネットワーク・インターフェースのようなインターフェース１１７を介して、伝送媒体から受信される。受信機１０７側では、損失検出１１９が実行される。また、そのような能力がある場合、エラーコンシールメント１２１がデータフロー１０１で実行される。データはバッファリング１２３され、ユーザによる使用のために受信機側のアプリケーション１２５に供給される。
【００３１】
データ経路１０１のデータ上で実行される動作の各々は、エラー・コーディングまたは同様の動作を含め、本明細書で述べないが当業者には周知である他の動作の中でも、優先順位付け１０９、複製１１１、インターリービング１１３およびバッファリング１１５のような、複数の動作のいずれかによって影響を受ける。本発明によれば、データ上で実行される動作は、受信機１０７および送信機１０５の間のフィードバックおよび制御に基づいて適合可能である。これらの動作は、単独で、または任意の組合せで、または任意の順序で実行することができる。
【００３２】
フィードバック経路１０３は、図１の点線で示される。受信機／転送先１０７からのフィードバックの少なくとも３つのタイプが、本発明によるデータ伝送の品質と信頼性を向上させるのに有用である。例えば、信号が実際に受信されたか否か等の信号／データ・フィードバック、利用可能な帯域幅のようなネットワーク・フィードバック、および受信機におけるバッファ・オーバフローのような受信機フィードバックがある。
【００３３】
図１に示すように、受信機フィードバック１０３ａは、受信機が、送信機１０５から送信されたデータの損失を補償することができるエラーコンシールメント機能を有するか否かについての情報を含む。データ損失検出フィードバックは、エラーコンシールメント１２１が失われた情報を補償することができない場合にのみ、送信機に供給される。エラーコンシールメント１２１は、受信されないデータを推定するために、実際に受信されたデータを補間することによって実行される。バッファは、受信機のバッファに適合しないデータを捨てなければならないので、バッファ管理フィードバック１０３ｂは、受信機でのバッファのオーバフローを防止するために情報が失われるように設けられている。バッファ管理部１２４は、転送先のバッファ動作を能動的に監視する。殆どの場合、受信機フィードバック１０３ｄは、受信機または転送先アプリケーション１２５によって受信されたデータにおける実際の損失に関する経験的データである。受信機フィードバックの使用については、送信機１０５側に関して説明する。
【００３４】
ネットワーク・フィードバック１０３ｃは、データまたはデータパケットをネットワークまたはネットワーク・インターフェースの伝送媒体に置く速度を調整する、すなわち速度制御する１２６ために、送信機が使用する帯域幅可用性情報を含む。データまたはデータパケットがネットワークまたは伝送媒体に置かれる速度は、バッファ１１５が情報で占められる場合、バッファが枯渇する速度である。バッファ管理アルゴリズム１２７は、アプリケーションがバッファ１１５に情報を供給する速度とネットワーク・フィードバック１０３ｃからの帯域幅可用性情報とに従って、バッファ１１５の枯渇速度を調整することができる。また、バッファ管理アルゴリズム１２７は、データ優先順位、バッファ特性またはネットワーク特性に関する演繹情報に従って、情報を落とすことができる。
【００３５】
信号フィードバック１０３ｄは能動的に供給できる。例えば、送信されたデータの各ブロックに対し、ブロックが受信されたか受信されなかったかを示すために信号を送信機に送り返する。しかしながら、送信機が失われたデータを補償する前にフィードバックを評価する間、そのようなフィードバックが、貴重な帯域幅を占有するか、時間遅延を誘導することがある。したがって、ポジティブなフィードバック信号が用いられてもよい一方で、ネガティブなフィードバック信号が好まれる。すなわち、受信機は、データブロック、またはパケット、またはデータブロックパケットの一部を受信しない場合にのみフィードバック信号を送出し、データが損失なしで受信された場合、如何なる信号も送出しない。加えて、システムがデータの一部を受信しなくても、受信機においてエラーが効果的に隠されるのであれば、ネガティブ確認応答フィードバック信号が送信機に供給される必要はない。
【００３６】
信号フィードバック１０３ｄは、サーバ側で実行される、様々な動作のいずれにも供給できる。例えば、情報が失われている速度に従って、動的な優先順位付けアルゴリズムによって割り当てられる優先順位を挙げることができる。パケット複製の度合いは、システムの損失率を補償するために、上昇させるか、または低下させることができる。また、受信機からのフィードバック信号が、データが失われたことを示す場合、送信機は、複製されたパケットまたはブロックを再送信することができる。
【００３７】
送信機１０５は、動的な優先順位スキーマに従ってデータをバッファリングするための独立した再送信バッファ１２９を有してもよい。また、再送信バッファ１２９は、送信されるデータフローをバッファリングするためのメインバッファの一部であってもよい。
【００３８】
図２に示すように、中間ルータ２３０は、ソース２０５と転送先２０７の間の経路上にあってもよい。図３ないし図８を参照して説明するように、中間ルータは、含まれるソースおよび転送先の機能に様々な段階を有してもよい。
【００３９】
図３に示すルータの構成において、ルータ３３０は、転送先３０７とソース３０５の間の如何なるフィードバックにも反応しない。図４に示すように、図３に示されたルータの構成は、本発明による速度制御４２６、バッファ管理４２７、バッファ４１５、および動的優先順位４０９を含んでもよい。
【００４０】
図５に示すルータの構成において、ルータ５３０は、本システムのソースコンポーネント５３２を含んでもよく、それにより、ルータ５３０は、転送先５０７から、または上流のルータ５３０からのフィードバックに基づいて適応され、ゆえに、上流のルータまたは転送先からのフィードバックに基づいて調整され得る。例えば、図６に示すように、図５に示されたルータは、本発明によるソースの場合のように、動的な優先順位付け６０９、パケット複製６１１、パケット・インターリービング６１３、バッファ６１５およびバッファ管理６２７、速度制御６２６、および損失再送信６１６を含むことができる。
【００４１】
図７に示すルータの構成において、ルータ７３０は、図５および図６において説明したように、ソースコンポーネント７３２を含んでよく、また、本システムの受信機コンポーネント７３４を含んでよい。それにより、ルータ７３０は、下流のルータＲ２または転送先７０７からのデータに基づいて適応することができる。例えば、図８に示されるように、上流側のルータＲ１は、本発明によるソース７０５と同様に、動的な優先順位付け８０９、パケット複製８１１、パケット・インターリービング８１３、バッファ８１５およびバッファ管理８２７、速度制御８２６、および損失再送信８１６等のソースコンポーネント７３２を含むことができる。加えて、例えば、下流側のルータＲ２は、高速損失検出８１９、エラーコンシールメント８２１、ならびにバッファ８２３およびバッファ管理８２４等の、本発明による受信機コンポーネント７３４を含むことができる。
【００４２】
統計的マルチプレクサ（統計Ｍｕｘ）も、中間ルータに対して上述したような特徴の一部あるいは全てを実装できる。
【００４３】
本発明による例示的アーキテクチャで実行される動作のいくつかについて図９を参照して説明する。図９は、受信機およびサーバ側で実行される動作を示すフローチャートである。図から分かるように、本システムのアーキテクチャにおける動作は、互いに相互関係を有し、システムは、動作間に流れる情報に従って適応する。
【００４４】
まず、優先順位付けが信号の初期エンコーディングに基づいて設定される。動的優先順位計算９０９は、クライアント機器のアプリケーション情報とユーザからのサービス要求情報も計算に入れることができる。動的優先順位計算９０９から得られる優先順位付けスキーマは、ネットワーク９０４を介した送信または再送信を要求する送信／再送信機構９０２に供給される。言い換えると、データは、複数のアプリケーション、ネットワークおよび信号属性に従って優先順位を付けられてもよい。データ損失が生じる場合、システムは、優先順位付けまたは属性に従い、適切にデータを再送信するか、または適切にデータを落とすことができる。
【００４５】
損失検出器９１９は、ネットワーク９０４を介して受信された信号が情報損失を含むかを判定する。上述したように、損失情報は、動的優先順位計算９０９に供給されてよい。初期優先順位付け後、送信が開始されると、動的優先順位計算９０９は、損失検出器９１９からの損失情報を含めるために修正される。本発明による動的優先順位計算９０９を、以下にさらに詳細に説明する。
【００４６】
サーバに損失検出情報を供給するための１つの方法は、エラーを隠すことができないデータに対するネガティブな損失情報だけを供給することである。したがって、サーバに損失として報告される唯一の信号は、受信機において隠すことができないものである。他のデータに対するポジティブな確認応答があったとみなされる。例えば、送信された第１および第３のデータパケットに対しするネガティブ確認応答を２つ受信し、しかし第２のデータバケットに対してはネガティブ確認応答を受信しない場合、第２のデータパケットは失われなかったと見なされる。本発明による損失検出は、以下でさらに詳細に説明する。粗粒度の何らかのポジティブ確認応答を使用することにより、ネガティブ確認応答の損失から回復することが可能となる。
【００４７】
場合によっては信号ヘッダとして、送信機から受信機へ送信された署名プロファイルは、送信されている信号の時間同期に関する情報を受信機に提供する。言い換えると、受信機は、パケットまたはデータの受領についての時間署名および／または優先順位署名と見なすことができる署名プロファイルに基づいて、信号ストリームのどの辺りにデータパケットがあるかを認知する。
【００４８】
上述したように、ネットワーク９０４は、また、帯域幅および通信速度に関する情報を提供する。速度または帯域幅情報は、優先順位の低いデータを落とすための仕組み９０２を含む、速度制御９２６およびバッファ管理９２７で考慮される。バッファ管理９２７は、通信速度がネットワークの通信速度を上回る場合に必要とされる。バッファ管理部は、署名プロファイル内の情報に基づき、将来データ・オーバフローが発生するかを前もって予測することができる。本発明によるバッファ管理について、以下に更に詳細に説明する。
【００４９】
本発明によれば、進歩的な複数の技術を使用して、ネットワーク環境のける情報の伝送を最適化することができる。これら技術の様々な態様について以下に詳細に説明する。
【００５０】
損失検出
できるだけ早く、ネットワーク内でのパケット欠落を認知することが望ましい。情報がタイム・センシティブであるビデオ・ストリーミング・アプリケーションの場合は特にそうである。損失検出のための機構の多くは、送信機でのタイムアウト（受信機から確認応答が戻ってくるまでに掛かる大雑把な推定時間）に依存する。しかしながら、そのようなタイムアウトは大雑把なものであるので、パケットストリームに遅延を導入し、その結果、バッファ要件が増大するか、またはその代わりに帯域幅の過剰供給が増大し得る。
【００５１】
サーバに損失検出情報を供給するための１つの方法は、エラーを隠すことができないデータに対するネガティブな損失情報だけを供給することである。したがって、サーバに損失として報告される唯一の信号は、受信機において隠すことができないものである。他のデータに対するポジティブな確認応答があったとみなされる。例えば、送信された第１および第３のデータパケットに対しするネガティブ確認応答を２つ受信し、しかし第２のデータバケットに対してはネガティブ確認応答を受信しない場合、第２のデータパケットは失われなかったと見なされる。
【００５２】
本発明のシステムは、従来のシステムよりもはるかに高速の損失検出を提供する。従来のシステムでは、送信機が所定の時間に送信機から信号のポジティブ確認応答を受信することを期待する。ソースが所定の時間までに期待される確認応答を受信しなかった場合、送信機は、確認応答を受信するかどうかを確認するために多少の付加的な時間の間、待機し続ける。該付加的な時間経過後に、従来のシステムの送信機は、初めて信号が失われることを受け入れ、必要に応じて、再送信を実行する等の、失われた信号を補償するための処置をとる。
【００５３】
本発明の損失検出では、待機期間は、期待されるデータの優先順位に基づいて動的にチューニングされる。情報信号に先立つ署名プロファイルは、信号がいつ頃受信されるかを含め、受信される信号の時間同期情報（コード）および優先順位情報（優先順位プロファイル）を提供できる。また、署名プロファイルは、トラヒックが可変ビットレートである場合、インターパケット分離時間（ＩＰＳ）に関する情報を受信機に提供する。任意の２つの連続したパケットの間のＩＰＳは異なってよい。そのようなＩＰＳ情報は、署名プロファイルによって提供される。署名プロファイルに基づき、受信機は、信号がいつ頃受信されるか、および後続の信号がいつ頃受信されるかを認知する。すなわち、第１の信号がｔｉにおいて期待される場合、次の信号は、ｔｉ＋１＝ｔｉ＋ＩＰＳｉにおいて期待される。本システムによる損失検出では、時間ｔｉ＋１に到達したが、期待された信号が受信されない場合、受信機は、失われた信号を補償するための動作を開始する。
【００５４】
概して、本発明の損失検出は、不均一な優先順位システムにおいて、パケットの優先順位に比例して、より積極的である。通常、損失の報告とパケットの優先順位との間の関係は、単調非増加関数である。
【００５５】
いくつかのシステムでは、パケットは、パケット間で特に固定されたか、または可変のＩＰＳを有する周期的なストリームに含まれて到着する。ファイル転送において、例えば、あるいはＩＰＳを全く、または殆ど伴わずに、パケットを連続して転送できる。しかしながら、パケット到着タイミングとパケット間の間隔は、パケット・ストリームを一定の期間に亘り実際にモニタリングすること、すなわち経験的なデータによって決定できる。経験的サンプリングの後、システムは、利用可能な通信速度が変化するために変更し得るパケット間の間隔に合わせて適応することができる。
【００５６】
例示的なクライアント側の損失検出アルゴリズムは、署名プロファイルによって提供された情報を利用する。
【００５７】
接続存続期間の開始時に、送信機は、受信機に対して署名プロファイルを送信する。署名プロファイルは、信号が固定ビットレートであるか可変ビットレートであるか、および信号が均一な優先順位を有するか、不均一な優先順位を有するかによって、タイムスタンプ情報および／または優先順位情報を含むことができる。信号が固定ビットレートである場合、ストリーミング速度Ｒとパケット長Ｌのみが、タイムスタンプ情報の代わりに、署名プロファイルに含まれる。
【００５８】
優先順位プロファイルは、ストリーミングされるパケットに対する優先順位のリストを示す。例えば、第１のパケットに対する優先順位をｐｉとする。
【００５９】
ｉ番目のパケットの受信後、クライアントは、例えば、
Ｔｗ＝ｃ１＊ｆｘ（Ｌ／Ｒ）＋ｃ２＊ｆｙ（Ｋ（ｐｉ＋１））＊ｆＺ（ｄｅｖ（Ｊ））
だけ待機してから送信機にネガティブ確認応答（ＮＡＣＫ）を送信する。上記式のパラメータは次の通りである。
Ｋ（ｐｉ＋１）は、期待されるパケットに対する優先順位レベルに特有の定数である。
ｘ＜ｙのとき、およびｘ＜ｙの場合のみ、Ｋ（ｘ）＞Ｋ（ｙ）である。
【００６０】
すなわち、優先順位の高いパケットに対し、Ｋ（ｐ）は低くなり、クライアントにＮＡＣＫを送信機へより速く送信させる。
【００６１】
ゆえに、送信機に高速なフィードバックが得られ、同時に、優先順位の低いパケットについて偽の再送信が防止される。
【００６２】
本システムの損失検出の他の態様では、スタートアップ遅延を設けることにより、ジッタ補償と損失が検出されて再送信が要求されたとき再送信時間が提供される。スタートアップ遅延はバッファのサイズによって決まる。上述したような可変損失検出は、より速く再送信を要求すること、および、優先順位の高い情報に再送信要求を制限することにより、スタートアップ遅延要件を最小限に抑える。このような利点は、固定されたバッファサイズを有するシステムにおいて、またはユーザがより小さなスタートアップ遅延を要求する場合に特に有用である。
【００６３】
この「高速」損失検出システムを、不均一な優先順位を有する情報を有するシステムにおける使用について説明しているが、同様の損失検出は、優先順位スキーマを有していないデータシステムにも適用可能である。
【００６４】
また、この「高速」損失検出システムは、伝統的なインターネット環境のような、受信した信号の選択的な確認応答を有するシステムに用いることができる。
【００６５】
（バッファ管理）
本システムは、ソースおよび受信機双方におけるアクティブバッファ管理を含む。受信機のバッファ管理をフロー制御に関して説明する。
【００６６】
ソース側では、バッファ管理は、ソースとネットワークの間のインターフェースの前でバッファの占有速度を監視する。バッファ管理部は、バッファがオーバフローしているか、あるいはオーバフローしそうかどうかを監視する。このシステムでは、データが出力される速度は、バッファの占有（入力）速度より十分に大きく、バッファは空のままであり、バッファ管理の必要性がない。出力速度がバッファの占有速度より大きい短期間の他は入力速度が出力速度より大きく、したがってバッファ管理が必要な場合がある。ネットワークへの出力速度がバッファの占有速度以下である場合、バッファ管理が必要であり、ネットワークに置かれる前に情報を落とさねばならない場合がある。通常のシステムでは、バッファが満杯であると、次のパケットは、パケットに含まれる情報の重要性にかかわらず落とされる。しかしながら、本システムは、バッファ内の情報およびバッファに置かれなければならない情報に関し、情報の優先順位または重要性情報を考慮に入れる。速度制御アルゴリズムは、出力速度を制御する。
【００６７】
優先順位ドロップは、優先順位の高いパケットがバッファリングされる必要性があと、キューから優先順位の低いパケットを取り除く。
【００６８】
積極的なドロップは、異なる優先順位の情報の受信に期待されるタイミング、および速度制御コンポーネントによって決定された出力速度の現在の推定値に基づき、前もって損失を予測する。損失が予測される場合、バッファが満杯でなくても優先順位の低い情報を落とす。いくつかのシステムでは、情報ストリームの優先順位の比率は変動しない。この情報を用いて、バッファ管理部は、次に到来する情報の優先順位が何であるかを予測することができ、バッファが優先順位の高い情報の全てを受信することができるかどうかを判定することができる。バッファがバッファ内のいくつかのパケットより高い優先順位を有する情報の損失を予測する場合、バッファ管理部は、到来する高い優先順位の情報を収容するために、バッファから優先順位の低いパケットのいくつかを落とすことをバッファに指示する。このドロップ指示は、高い優先順位の予測される到来情報がそのようなドロップを保証する場合、バッファが満杯でなくとも、バッファに与えることができる。
【００６９】
情報ストリームの優先順位プロファイルが変動する場合でさえ、署名プロファイルは、積極的なバッファ管理に十分な情報を提供することができ、パケット受信を予測することができる。加えて、バッファ管理部は、それ自身の情報から、または他のシステム、例えば速度コントローラからの通知によって、バッファがオーバフローすることを認知することができる。例えば、バッファ管理部は、優先順位の高いパケットＰが予想される場合、バッファ内の情報の優先順位を予測することができる。バッファ管理部が、優先順位の高いパケットＰが受信されたときのバッファ内の唯一の情報が、優先順位の高いパケットＰと同じ優先順位か、またはそれより高い優先順位を有するパケットｘであると予測した場合、バッファ管理部は、バッファ内において優先順位がより高いパケットＰｘを落とさず、指示がない場合より早くそれらが送信されることを可能にすべく、低い優先順位のパケットを落とすように前もってバッファに指示する。
【００７０】
そのような積極的なドロップは、不均一な優先順位を有する任意のデータ・スキーマに特に適用可能である。
【００７１】
（フロー制御）
受信機のバッファ管理は、フロー制御を可能にする。すなわち、転送先の受信速度が何らかの理由により変化した場合、バッファは、変更された速度で満杯になる。バッファ管理部は、受信機での異なる占有速度を検出し、送信速度の調整が必要なソースへフィードバックする。言い換えると、受信機のバッファは、オーバフローを防止するために能動的にモニターされる。
【００７２】
（速度制御）
速度制御は、環境によって異なる。例えば、パブリックドメイン・インターネットにおける速度制御は、プライベートドメイン・ネットワークにおける速度制御と異なる。パブリックドメイン・インターネットの速度制御の範囲内で、固定ビット（デジタル）レート環境の速度制御は、可変ビットレート環境の速度制御とは異なる。固定ビットレート環境において、情報は、システムによって提供可能な平均速度である固定レートで供給される。そのような速度制御は、ソースフレンドリ、且つＴＣＰフレンドリである。すなわち、ソースは、固定レートで送信することができる。
【００７３】
現在のインターネットのトラヒックのほとんどがＴＣＰトランスポート層のプロトコル上で実行される一方、マルチメディアのような他のトラヒックタイプの出現は、特に混雑制御の課題のために、非ＴＣＰに基づくトランスポート層アルゴリズムを必要とした。同時に、ＴＣＰフローの既存の大部分との整合性を保つため、それらの新しいアルゴリズムは、依然として「ＴＣＰフレンドネス」を示す必要がある。言い換えると、非ＴＣＰ混雑制御アルゴリズムが接続により用いられる場合、接続が享受する長期平均速度を、ＴＣＰフローが同じ設定の下で享受するものと確実に同じにしなければならない。ＴＣＰフレンドリネスを維持すると同時に、（短時間のスケールで）非変動レートを提供する固定ビットレート（ＣＢＲ）トラヒックのため、いくつかのそのようなアルゴリズムが提案された。そのようなアルゴリズムの例には、二項混雑制御（ＢＣＣ）、ＴＦＲＣ（ＴＣＰフレンドリ速度制御）などが含まれる。そのようなアルゴリズムは、ＴＣＰ接続速度に影響を与えるキーファクタである、損失率（ｐ）および往復時間（ｒｔｔ）を適切にモニターすることにより、「ＴＣＰフレンドリ」な速度を推定する。ここで説明される技術は、ＣＢＲトラヒックに対するＴＣＰフレンドリ速度制御の達成を目的とする。
【００７４】
本発明の態様による技術は、新規かつ唯一の、ＴＣＰ可変レート制御（ＴＶＲＣ）と呼ばれる可変ビットレート（ＶＢＲ）トラヒックに対するＴＣＰフレンドリ速度制御を含む。本質的に、ＣＢＲフレンドリ速度制御アルゴリズムと同様に、ＴＶＲＣは、損失率と往復時間の推定値からＴＣＰフレンドリ速度を計算する。しかしながら、接続のアプリケーション速度が、利用可能なＴＣＰフレンドリ速度より小さい場合、ＴＶＲＣは、接続がもたす帯域幅の量の原因である接続の「クレジット」を維持する。その後、アプリケーションの出力速度がＴＣＰフレンドリ速度より大きくなった場合、ＴＶＲＣは、利用可能なクレジットが余剰より大きい限り、接続出力速度がＴＣＰフレンドリ速度を超えるのを可能にする（ゆえにクレジットは減少する）。蓄えられたクレジットを使い切ってしまうと、ＴＶＲＣは、接続速度がＴＣＰフレンドリ速度のそれを超えるのを許可しない。利用可能なＴＣＢフレンドリ速度より下のＴＶＲＣ接続（遅延した接続）は、本当の損失率ｐを追跡するため、（この目的のために保持されたダミーパケットまたは本当のデータパケットを用いて）より大きな速度で定期的にパケットを送信する。そのようなプローブ期間の間に経験した損失を使用して、ＴＣＰフレンドリ速度より大きな速度を享受しているＴＶＲＣ接続（主要な接続）は、それらが受信している付加的なサービスの追跡を維持する。ＴＶＲＣ接続は、それが主要な接続である場合、ＴＣＰ副次混雑制御機構を用いる。
【００７５】
上述した機構は、ＴＣＰフレンドリ速度を提供することを可能にする一方、同時に、ＶＢＲトラヒックに最良の速度制御機構を提供する。
【００７６】
本発明の他の態様は、サービス品質（ＱｏＳ）を供給するネットワークを介した信頼できるポイント・ツー・ポイント情報配信に対する帯域幅認識渋滞制御である。ＴＣＰ／ＩＰプロトコル・スタックを用いるＩＰネットワークを介して映像がポイント・ツー・ポイント方法（ユニキャスト）で配信される場合、ＴＣＰの非効率な速度制御に対処するために大量のオーバープロビジョニングが必要となる。
【００７７】
１の増加ファクタおよび０．５の減少ファクタを有するＴＣＰのＬＩＭＤ（線形増加倍数詞減少）アルゴリズムは、ベスト・エフォート（およびそれより大きな）インターネット環境に適している。しかしながら、接続またはストリームが特定のサービス品質レベルで提供される如何なる環境も、ＬＩＭＤアルゴリズムをもはや許容しない。例えば、ケーブル・サービス・プロバイダが利用可能なパイプ容量の許容量一杯の大量のフロー（動画ストリーム）だけを流すケーブルＩＰ環境において、ＬＩＭＤアルゴリズムはもはや最適ではない。これらの限界のため、典型的なオーバープロビジョニングの割合は、フローのデータ速度を保持するために必要とされる最小帯域幅の１０〜５０％である。例えば、各々が３Ｍｂｐｓで流されている１０個のフローがある場合、フレーム表示デッドラインが破られないように損失無しで且つタイムリーなサービスを保証するためにＴＣＰを用いるとき、要求される最小帯域幅は３０Ｍｂｐｓのみであるにもかかわらず、生の帯域幅量は、４５Ｍｂｐｓに達し得る。
【００７８】
本システムは、上記環境で動作し、要求されるオーバープロビジョニングの量を減少させる渋滞制御アルゴリズムを提供し、以下のアルゴリズムを用いる。
【００７９】
ＴＣＰの場合のように、１の渋滞ウインドウから開始する代わりに、本発明によって提供される渋滞制御技術は、ｆｘｘ（Ｃｉｄｅａｌ／２）の渋滞ウインドウから開始する。Ｑｉｄｅａｌは、帯域幅遅延の積Ｒ＊ｒｔｔとして計算された理想的渋滞ウインドウであり、ｒｔｔは、パイプ上の往復時間であり、Ｒは配信のデータ転送速度である。これは、渋滞制御アルゴリズムが理想的な動作速度Ｒに達するまでの時間を減少させる。
【００８０】
渋滞の増加のため、本発明の渋滞制御アルゴリズムは、ＴＣＰ（１）の場合と同じように、増加定数ｘを用いる。
【００８１】
渋滞の減少のため、本発明の渋滞制御アルゴリズムは、ＴＣＰが使用するブラインド０．５減少に対して、帯域幅認識減少機構を用いる。具体的には、フローに損失が発生し、現在の渋滞ウインドウがＣｃｕｒｒｅｎｔであるとき、フローが、次式によりその渋滞ウインドウを減少させる。
ｆｙｙ（Ｍａｘ（０，Ｃｃｕｒｒｅｎｔ−Ｃｉｄｅａｌ））
【００８２】
本質的に、フローは、現在のウインドウサイズが理想のウインドウサイズより大きい場合にのみ、その渋滞ウインドウを減少させる。減少の決定がなされた場合、渋滞ウインドウを減少させる量は、渋滞ウインドウが理想的な渋滞ウインドウよりどれだけ大きいかの関数である。
【００８３】
上記アルゴリズムの背後の論法は次の通りである。固定値（例えば理想値）で渋滞ウインドウを固定することは、その結果（高い多重周波数−関連する損失率）のため、望ましくない。ゆえに、ＴＣＰの場合のような何らかの適応が望ましい。しかしながら、適応が実行される場合、利用可能な帯域幅を考慮すべきである。理想的な速度を上回る量の関数だけ瞬間的な速度（Ｃｃｕｒｒｅｎｔ）を減少させることは、理想的な速度Ｒに等しいフローの平均速度を発見的に達成しようとしていることになる。
【００８４】
（サービス品質）
信号伝送を最適化するために用いることができる他の技術は、受信機／転送先／クライアントで、必要とされるか、あるいは要求されるサービス品質（ＱｏＳ）に従って最適化を行うことである。そのような最適化は、実際のユーザ要件、人間知覚最小要件、またはアプリケーションに特化した要件を考慮に入れることができる。また、ネットワークのサイズ、またはネットワーク上のユーザ数に基づいてスケーリングを提供することができる。サービス品質の要件は、品質、複雑さ、遅延およびデータ転送速度のトレードオフ、またはバランスを求めることである。言い換えると、本発明のＱｏＳ技術は、遅延を最小にし、スループットを最大にすることを求める。すなわち、制約の範囲内で品質を最大化することにある。
【００８５】
サービス品質のために少なくとも４つの入力を調整するためエキスパート・システムが提供されることになる。例えば、サービス品質要件のための入力は、送信機と受信機の間の通信の４つの異なる「レベル」、即ち、ネットワーク、ソース、クライアント・アプリケーションまたはデバイス、およびユーザで行うことができる。そのような入力は、リアルタイム・フィードバックを通して、または、セッションごと、市場（顧客）ごと、または市場（ドメイン）ごとに提供される。
【００８６】
サービス品質プリミティブ（すなわち、送信機、受信機、クライアント・アプリケーション、およびユーザ性能と要求に従って調整可能な通信品質要因）は、例えば、ビデオ品質；空間的分解能；時間軸分解能；表示サイズ、品質と分解能；オーディオ品質；帯域幅；空間リアリズム；音声制御とフィードバック；スタートアップ遅延許容限度；中流待ち時間などを含むことができる。ＱｏＳプリミティブは、通信システムの様々な構成要素によって実際に実装することができる、ネットワークまたはシステム・パラメータに変換される。そのようなパラメータは、ビデオ・ビットレート、ビデオ・ビットエラーレートプロファイル、ビデオ・パケット損失プロファイル、オーディオ・ビットレート、オーディオ・ビットエラーレート・プロファイル、オーディオ・パケット損失プロファイル、可変／固定／適応可能なビットレート、グローバル遅延ジッタ・プロファイル、差分ジッタ・プロファイルなどを含む。
【００８７】
ＱｏＳプリミティブは、本発明の他の態様、技術またはコンポーネントに対し入力を提供することができるエキスパート・システムによって、評価され、変換される。ＱｏＳエキスパート・システムと、サービス品質要件とアクティブ・フィードバックに従ってソース、ネットワーク、クライアント・アプリケーションおよびユーザ要求を適応させる他の態様は、「System and Method of Quality of Service Feedback between Client and Server Devices」という表題で２００２年９月２６日出願の米国特許出願に開示されている。該米国特許出願は、本明細書において説明するすべての目的のために参照することにより、本明細書に包含する。
【００８８】
図１０に示されるように、ＱｏＳエキスパート・システムは、アプリケーション層、動的優先順位計算、パケット複製、パケット・インターリービング、損失回復、バッファ管理、および速度制御にＱｏＳシグナリングを供給することができる。例えば、アプリケーション層は、誤り訂正技術またはスタートアップ遅延を調整するＱｏＳ情報を受信できる。動的優先順位計算は、表示速度、スタートアップ遅延、またはＥ２Ｅ遅延を調整する情報を受信できる。パケット複製は、ネットワーク損失率についてのＱｏＳ情報を含むことができる。損失回復は、表示速度および品質のようなＱｏＳ情報によって影響を受ける場合がある。速度制御は、ユーザおよびラストマイル・アクセス媒体により要求される品質についてのＱｏＳ情報によって調整可能である。
【００８９】
（動的優先順位付け）
本発明による動的優先順位付け１１０９のための処理を、図１１を参照して説明する。まず、本システムが設定する優先順位付けを、信号が最初にエンコードされるとき、信号に割り当てられた優先順位付けに基づいて決定する。ステップ１１２０では、送信されるデータおよびデータタイプを送信するアプリケーションを決定する。ステップ１１３０では、アプリケーションとデータタイプを伴ういくつかのシナリオを決定する。例えば、人間が見て、且つ使用するデータ転送速度を規定するシナリオ、ならびにケーブル・オペレータが特定の帯域幅リンクを有するリンクの範囲内で提供することができるチャンネル数を決定するシナリオが規定される。
【００９０】
ステップ１１４０では、調整可能な信号およびネットワークの特性が、特定の範囲内で変更され、人間の知覚がシミュレートされ、知覚能力メジャーとして表現される。ステップ１１５０では、スループットに対する「グッドプット」の最良の比率に基づいて最適値を選択する。ステップ１１６０では、本システムは、グッドプット／スループット比率の観点から最適な値を取るように設定された調整可能な特性を有するように適用される。言い換えると、本システムは、アプリケーションとネットワークの間の仲介者として動作する。
【００９１】
動的優先順位付けは、データおよび信号の様々な属性を考慮して実行される。例えば、優先順位は、（１）情報セグメント間の依存性、（２）受信機到達のデッドライン、（３）クライアント・転送先／受信機の性能、（４）ソースと受信機の間の接続履歴、および（５）ソース、ネットワークおよび受信機間の速度ずれに基づいて計算および再計算される。
【００９２】
高い優先順位パケットが落とされて回復されない場合、依存する低い優先順位パケットを送信する必要がないように、不均一な優先順位システムに、低い優先順位パケットがしばしば高い優先順位パケットに依存する依存性が生じる。
【００９３】
デッドラインは、パケットが転送先で受信されなければならない時刻ｔＤである。情報パケットがデッドラインまでに受信されない場合、受信機に役に立たないことになる。パケットが時刻ｔｃに転送され、ソースと転送先の間の転送時間がｔｔである場合、転送先／受信機において期待される情報の到達時刻は、ｔｃ＋ｔｔである。デッドライン時刻ｔＤが現時刻ｔｃプラス転送時間ｔｔより大きい場合（ｔＤ＞ｔｃ＋ｔｔ）、パケットが転送先／受信機にとって有用であるためには転送先にあまりに遅く到達するので、パケットは落とされた方がよい。例外は、後で転送される依存パケットが時間内に受信機に達することができる場合で、この場合、現在のパケットは、デッドラインの後で受信されるとしても、後の依存パケットが正しくデコードされるように、送信されてよい。
【００９４】
クライアント／転送先の能力は、転送先／受信機が、エラーコンシールメントを実行する能力のような強い後処理能力を有するかどうかを含む。動的優先順位付けは、受信速度が伝送速度より小さい場合、転送先／受信機が自動的に情報を落とすかどうかを考慮に入れる。
【００９５】
接続履歴は、ネットワークにより提供される速度を説明し、期待されるネットワークの帯域幅に対して転送先要件をバランスさせる品質情報の送信を試みる。期待されるネットワークの帯域幅は、ネットワーク上に提供された過去の帯域幅を考慮して決定されてもよく、また、システムは、平均帯域幅または期待される最小帯域幅の範囲内に留まろうとしてもよい。接続履歴に基づくモニタリングおよび適応は、システムがユーザに対して一貫したサービス品質を提供することを可能にする。
【００９６】
速度ずれがある場合、動的優先順位付けは、速度を調整するために個々のパケットの属性を考慮に入れる。すなわち、動的優先順付けは、等しい優先順位を有するフレームに目を向け、それらフレームの各々が、転送先／受信機により必要とされる時刻までに転送先に到達しそうかどうかを評価する。動的優先順位付けは、転送先／受信機で受信されるかどうかに基づいて、パケットの送信オーダーのキューを調整する。
【００９７】
さらに、ユーザは、送信機および受信機システムの能力およびサービス品質のユーザ要求と、ネットワーク属性とのバランスが取れるように、再送信またはエラー抑制が適用されるように、本システムが考慮する情報を提供することができる。この情報は、送信機に対する受信機のフィードバックの一部として提供される。
【００９８】
例えば、ＭＰＥＧ映像データの場合、フレームは、３つのタイプ：内部フレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）、および双方向予測フレーム（Ｂフレーム）にエンコードされる。Ｉフレームは、過去または未来の如何なるフレームも参照しない単一のイメージであり、アンカー・フレームと呼ばれることもある。Ｐフレームは、過去のＩフレームまたは過去のＰフレームのような過去の参照フレームに関連してエンコードされる。Ｂフレームは、過去の参照フレーム、未来の参照フレーム、または双方のフレームに関連してエンコードされる。一般的に、Ｉフレームは多くの情報を含むという性質を持つので、ＰまたはＢフレームよりも、転送のために多くのユニット、例えばビットを必要とする。
【００９９】
フレームは、一般的に動作補償圧縮に用いられるユニットであり、マイクロブロックに分割される。それらには、輝度および色差ブロックのようなデータを含むブロックが含まれる。
【０１００】
ＭＰＥＧフォーマットのビデオ画像は、「グループ・オブ・ピクチャ」またはＧＯＰと表現される。典型的なＧＯＰは、Ｉフレーム、および関連するＢフレームとＰフレームを含む。ＧＯＰのフレームの順序は、フレームの表示順である。しかしながら、対応しているビットストレームは、一般的に、Ｉフレームを先頭とし、関連フレームに基づいて順序付けられる。例えば、一般的なＧＯＰは、以下の通りである。
【０１０１】
本システムは、細分性の異なるレベルに適応する。例えば、ＭＰＥＧの環境では、本システムは、フレームレベル、マイクロブロックレベルまたはブロックレベルで適用されることになる。
【０１０２】
例えば、フレームＩ１が失われた場合、ＧＯＰに残っているフレームを適切に提示するために必要な情報を含むアンカー・フレームがない。情報のアプリケーションおよび提示に応じて、生じる待ち時間がアプリケーションの観点から許容可能である場合は本システムはＩフレームの再送信を要求し、あるいは不規則に変化する結果となる提示が許容可能である場合は本システムは全ＧＯＰを削除する。
【０１０３】
例えば、Ｐフレームが失われた場合、関連Ｂフレームは送信されない。
【０１０４】
動的優先順位計算は、アプリケーション・クライアントを含め、複数のソースから情報を受信する。アプリケーションからの情報は、サービス品質要件および情報依存性を含む。アプリケーション・クライアント側の他の情報は、クライアントでの、サービス品質要求、後処理要求、アプリケーション送信速度およびエラーコンシールメント能力以外の他のユーザ・パラメータを含む。
【０１０５】
また、動的優先順位計算は、いつデータパケットが到来するかを含めた受信される信号についての時間同期情報（コード）を提供する署名プロファイルを含む、データ信号についての情報を受信する。したがって、署名プロファイルは、パケット損失、損失プロファイルおよび回復の検出においてクライアントを助ける。また、動的優先順位計算は、受信機システムによって、または受信機システムのユーザによって提供されるサービス品質要求を考慮することができる。
【０１０６】
また、動的優先順位計算は、情報の再送信のための、帯域幅、通信速度および通信時間を含む、ネットワークおよび伝送メディアに関する情報を考慮する。また、動的優先順位計算は、アプリケーション送信速度、オーバフローおよび渋滞管理間の差異を含め、バッファ管理および速度制御を考慮しなければならない。
【０１０７】
上述の例で説明したように、ＰフレームおよびＢフレーム情報は、Ｉフレームが受信されない場合落とされる。ゆえに、バッファ内の情報が削除され、バッファ空間が解放されて、実際のドロッッピング機構は、ドロップ情報をバッファ管理に供給できる。バッファ占有情報は、動的優先順位計算に有用で、動的優先順位計算において考慮される。
【０１０８】
本明細書の実施例はネットワークを介したビデオデータの転送に関するものであるが、本発明の原理は、ＭＰＥＧ、ケーブル、インターネットプロトコルなど、任意の構文のパケット切替環境において、ビデオ、オーディオおよび音声を含むあらゆるデジタル信号にも適用可能である。実際、本発明のシステムは、ＭＰＥＧ２およびＭＰＥＧ４を含む、あらゆる転送スキームへのアプリケーションであってよい。
【０１０９】
本発明のシステムおよび方法は、５層モデルのアプリケーション層およびトランスポート層で用いられてもよい。本発明のシステムおよび方法は、信号およびネットワーク要求への適応度が高く、それに従って適応可能である。本発明のシステムおよび方法の根底にあるのは、デジタル情報について、再送信が可能でなければならない環境がある一方、再送信を防止しなければならない環境もあるという考え方である。例えば、失われたパケットによってビデオフレームに生成された穴をエラーコンシールメントによって埋めることができる場合、再送信を避けることができる。また、ビデオまたはオーディオのように、人間のユーザに対して提示されるいくつかの信号については、そのようなフレームの欠如を人間ユーザが認めない場合、フレームを再送信する必要がない。同様に、特定のデータの損失がアプリケーションの実行に影響を及ぼさず、したがって再送信が不要な場合がある。しかしながら、特定のデータの損失が、タイム・センシティブで信頼性が不十分な他のアプリケーションに影響し、再送信が必要な場合もある。
【０１１０】
本発明の可能な用途は、オンライン・ビデオ・レンタル、ビデオ、テレキャスト、およびビデオ・オン・デマンド（ＶｏＤ）のような単一の転送先へマルチメディアデータを送信するポイントキャストから、双方向テレビ（ＩＴＶ）およびビデオ会議システム、または多重ユニキャストのように複数の機器へマルチメディアデータを送信するマルチキャストまでの範囲に亘る。
【０１１１】
ネットワークを介した、ソースと転送先の間での、不均一な優先順位を有するデータ通信に関して本システムを説明したが、本システムの技術は、他の環境または副環境にも適用可能である。
【０１１２】
加えて、本システムの原理は、クライアントとソースの間だけでなく、転送先と中間ルータの間、中間ルータ間、および中間ルータとソースの間にも適用可能である。例えば、限定するものではないが、「高速」損失検出、バッファ管理、フロー制御、速度制御および動的優先順位付けなどの、本明細書に開示した技術は、ルータ間に適用することができる。
【０１１３】
本発明による技術は、信号、ネットワークおよび提示の属性のうち、必要なものと、失われても特定のユーザによって要求されるサービス品質に有意な影響を与えないものを識別する。
【０１１４】
本発明の精神または範囲から逸脱することなく、本発明に様々な変更や変形が可能であることは当業者にとって明白である。したがって、本発明は、特許請求の範囲とそれらの均等物の範囲に含まれる限り、本発明は本発明の変更物および変形例を含むものである。
【図面の簡単な説明】
【０１１５】
【図１】本発明の一実施形態による信号の例示的なフローを示す図である。
【図２】本発明の他の実施形態による信号の例示的なフローを示す図である。
【図３】本発明の他の実施形態による例示的なルータの構成を示す図である。
【図４】本発明の他の態様による例示的なルータ部品の機能を示す図である。
【図５】本発明の他の実施形態による例示的なルータの構成を示す図である。
【図６】本発明の他の態様による例示的なルータ部品の機能を示す図である。
【図７】本発明の他の実施形態による例示的なルータの構成を示す図である。
【図８】本発明の他の態様による典型的なルータ部品の機能を示す図である。
【図９】本発明の一実施形態による、システムパフォーマンスの最適化のために実行される基本的な動作を示すブロック図である。
【図１０】サービス要件または要求の品質に基づいた、本発明によるシステムの機能の調整を示す図である。
【図１１】本発明の一態様による動的な優先順位付けの例示的処理を示すフロー図である。
【図１】
2005526422.tif 000003
【図２】
2005526422.tif 000004
【図３】
2005526422.tif 000005
【図４】
2005526422.tif 000006
【図５】
2005526422.tif 000007
【図６】
2005526422.tif 000008
【図７】
2005526422.tif 000009
【図８】
2005526422.tif 000010
【図９】
2005526422.tif 000011
【図１０】
2005526422.tif 000012
【図１１】
2005526422.tif 000013
【国際調査報告】
2005526422.tif 000014
2005526422.tif 000015
2005526422.tif 000016