(57)【要約】      （修正有）【課題】ＡＶデータの品質をリアルタイムで連続的に最適にすること、および、ネットワークの予測不能で、かつダイナミックに変化する条件に適合することにより、ネットワークを通してオーディオ／ビジュアルデータを健全に流すことができるようにする。【解決手段】送信機により、あるデータ速度でビデオの複数のフレームをコード化するステップと、ネットワーク相互接続を通して受信機に前記コード化されたビデオを送信するステップとを備えている。前記コード化するステップが、前記複数のフレームに対する遅延時間制限および前記ビデオのフレームのタイプおよび速度歪みモデルのうちの少なくとも１つに基づき、前記ビデオの複数のフレームに対し、ビットを割り当てる。【選択図】なし【特許請求の範囲】
【請求項１】
（ａ）送信機により、あるデータ速度でビデオの複数のフレームをコード化するステップと、
（ｂ）ネットワーク相互接続を通して受信機に前記コード化されたビデオを送信するステップとを備え、
（ｃ）前記コード化するステップが、前記複数のフレームに対する遅延時間制限および（１）前記ビデオのフレームのタイプおよび（２）速度歪みモデルのうちの少なくとも１つに基づき、前記ビデオの複数のフレームに対し、ビットを割り当てることを含むことを特徴とするビデオコンテントを送信するための方法。
【請求項２】
前記割り当てが、前記ビデオのフレームの前記タイプに基づくものである、請求項１記載の方法。
【請求項３】
前記割り当てが、前記速度歪みモデルに基づくものである、請求項１記載の方法。
【請求項４】
前記モデルが、Ｉ、ＰおよびＢフレームに基づくものである、請求項３記載の方法。
【請求項５】
前記割り当てが、フレームのシーケンシャルな組に基づくものである、請求項３記載の方法。
【請求項６】
前記割り当てが、前記送信機でのデータのバックログに基づくものである、請求項３記載の方法。
【請求項７】
現在のフレームに対する前記割り当てが将来のフレームに基づくものである、請求項３記載の方法。
【請求項８】
前記割り当てが、フレームのグループ内のロケーションに基づくものである、請求項３記載の方法。
【請求項９】
前記タイプのフレームが、Ｉ、ＢおよびＰフレームを含む、請求項２記載の方法。
【請求項１０】
前記割り当てが、フレームのシーケンシャルな組に基づくものである、請求項２記載の方法。
【請求項１１】
前記割り当てが、前記送信機におけるデータのバックログに基づくものである、請求項２記載の方法。
【請求項１２】
現在のフレームに対する前記割り当てが、将来のフレームに基づくものである、請求項２記載の方法。
【請求項１３】
前記割り当てが、フレームのグループ内のロケーションに基づくものである、請求項２記載の方法。
【請求項１４】
前記速度歪みモデルが、前記複数のフレームのうちの１つのフレームのビットレート低減を、前記ビデオの前記複数のフレームの平均歪みの尺度に関連させるようになっている、請求項３記載の方法。
【請求項１５】
平均歪みの前記尺度が、平均二乗誤りに基づくものである、請求項１４記載の方法。
【請求項１６】
前記ビデオをトランスコーディングすることにより、前記ビットレート低減を達成する、請求項１４記載の方法。
【請求項１７】
前記関係が線型関係である、請求項１４記載の方法。
【請求項１８】
前記関係が、指数関係である、請求項１４記載の方法。
【請求項１９】
前記割り当てが、前記ビデオの前記複数のフレームの歪みを最小にすることに基づくものである、請求項１４記載の方法。
【請求項２０】
前記最小化が、前記ビデオの前記複数のフレームのうちの各フレームによって生じる歪みを等しくすることに基づくものである、請求項１９記載の方法。
【請求項２１】
前記割り当てが、エンドツーエンドの遅延時間に基づくものである、請求項１記載の方法。
【請求項２２】
前記割り当てが、前記受信機の初期プレイアウトバッファリング間隔に基づくものである、請求項２１記載の方法。
【請求項２３】
前記割り当てが、前記ネットワークの相互接続を通る前記ビデオの送信に対して利用できるバンド幅に基づくものである、請求項２１記載の方法。
【請求項２４】
前記複数のフレームが、画像のグループに対応する、請求項２１記載の方法。
【請求項２５】
前記複数のフレームが、画像のグループよりも少ないフレームを含む、請求項２１記載の方法。
【請求項２６】
前記複数のフレームが、画像のグループよりも多いフレームを含む、請求項２１記載の方法。
【請求項２７】
平均歪みの前記尺度が、信号対ノイズ比に基づくものである、請求項１４記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願とのクロスレファレンス）
本願は、２００５年１２月３０日に出願された米国仮特許第６０／７５５，３４４号に基づく優先権を主張するものである。
【０００２】
本発明は、一般的には無線送信システムに関し、より詳細には、無線ビデオ送信システムに関する。
【背景技術】
【０００３】
強化されたテレビシステムを開発することは、民生用電子機器メーカーにとって重要な事項である。従来のテレビシステムでは、番組発信源から受信した番組情報を見るのにディスプレイデバイスを使用できる。ディスプレイデバイスを入力デバイス、出力デバイスおよび作動電力に結合する種々の物理的接続によって課される制約により、従来のディスプレイデバイスは一般に固定されたロケーションに設定される。その他の事項、例えばディスプレイのサイズおよびディスプレイの重量も従来のテレビシステムにおける視聴者の移動可能性を大幅に制限し得る。
【０００４】
ポータブルテレビディスプレイは、好ましいことに適当な視聴ロケーションを選択する際に更なるフレキシビリティを視聴者に提供できる。例えば家庭環境では、家庭内の種々の遠隔ロケーションで番組を観るのにポータブルテレビを容易に移動することができる。従って、ユーザーは固定されたディスプレイデバイスから離れたロケーションで別の作業を行っている間でも、テレビ番組をフレキシブルに視聴できる。
【０００５】
更に、潜在的な番組発信源（アナログおよびデジタルの双方）の数が大幅に増大することにより、選択的な視聴をするための番組が豊富になり、システムのユーザーに利点を与えることができる。特に、フレキシブルな家庭用の安価な無線オーディオ／ビデオ送信システムにより、テレビ視聴者には多数の番組発信源の選択が提供されると同時に、ポータビリティ（携帯性）を備えることによって、テレビ視聴者がテレビ視聴を大幅に改善できる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
デジタルデータネットワーク技術および無線デジタル送信技術の革新により、家庭におけるテレビシステムのフレキシビリティが広がり、高品質が提供される。しかしながら、現在の無線データネットワークは、一般に、高品位のビデオ情報を送信するのには最適ではない。
【０００７】
高品位の連続したメディアストリーム、例えば、ビデオ画像ストリームをそのまま、効果的および／またはタイムリーに送信するには、高い送信速度、すなわち、広いバンド幅を必要とすることが多い。多くの場合、必要な送信速度を提供するコストおよび／または努力は、禁止的なものとなる。この送信速度の問題は、高度にパックされたデータを形成するのにコンテントの連続性を活用する圧縮方式によって解決されることが多い。例えば、オーディオおよびビデオのための動画エキスパートグループ（ＭＰＥＧ）規格およびその変形規格に基づく圧縮方法は周知である。解像度が高いビデオの場合、例えば、高品位テレビ（ＨＤＴＶ）で使用される１０８０ｉの解像度の場合、かかるビデオ画像ストリームのデータ送信速度は、圧縮後でも極めて高い。
【０００８】
かかる高データ送信速度によって生じる一つの問題は、データを記憶することにある。妥当な長さの時間、高速度のビデオストリームを記録すなわちセーブするには、かなりの記憶容量が必要であり、このような記憶容量は禁止的に高価となり得る。高解像度のビデオデータによる別の問題は、多くの出力デバイスがデータをレンダリングできないことである。例えば、より低い解像度のビデオ画像ストリームを観るのに使用できるディスプレイシステムは、かかる高解像度の画像をディスプレイできないことがある。更に別の問題は、限られたバンド幅または容量のネットワーク内で連続したメディアを送信することである。例えば多数の受信／出力デバイスを有するローカルエリアネットワークでは、かかるネットワークはバンド幅または容量が限られていることが多く、従って、多数の受信／出力デバイスを同時にサポートすることは物理的および／またはロジスティカリーにできない。さらに、無線相互接続およびネットワークの有効なバンド幅は、時間的に変化することが多く、いくつかの要素によって予測不可能である。
【０００９】
かかるネットワークを通して、圧縮されたメディアデータを送信することは困難である。その理由は広いバンド幅が連続的に必要とされ、連続したメディアストリームに関連する遅延の制約が厳格であることによる。チャンネル条件が劣化する結果、データパケットが失われたり遅れたりすることがあり、これによってメディアプレゼンテーションが歪んだり、または中断したりすることになる。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明の技術手段は、（ａ）送信機により、あるデータ速度でビデオの複数のフレームをコード化するステップと、（ｂ）ネットワーク相互接続を通して受信機に前記コード化されたビデオを送信するステップとを備え、（ｃ）前記コード化するステップが、前記複数のフレームに対する遅延時間制限および（１）前記ビデオのフレームのタイプおよび（２）速度歪みモデルのうちの少なくとも１つに基づき、前記ビデオの複数のフレームに対し、ビットを割り当てることを含むことを特徴としたものである。
【発明を実施するための最良の形態】
【００１１】
図１は、バンド幅が限られている場合があるネットワークにおいて、マルチデータストリームを送信するためのシステムを示す。このシステムは中央ゲートウェイメディアサーバ２１０と、複数のクライアント受信ユニット２３０、２４０、２５０とを含む。中央ゲートウェイメディアサーバはマルチデータストリームを送信できる任意のデバイスでよい。入力データストリームはメディアサーバに記憶してもよいし、外部ソース、例えば、衛星テレビ送信機２６０、デジタルビデオディスクプレイヤー、ビデオカセットレコーダまたはケーブルヘッドエンド２６５から到達してもよく、圧縮されたフォーマットでクライアント受信ユニット２３０、２４０、２５０に送信される。これらデータストリームはディスプレイデータ、グラフィックデータ、デジタルデータ、アナログデータ、マルチメディアデータ、オーディオデータなどを含むことができる。ゲートウェイメディアサーバ２１０上の適応型バンド幅システムは、ネットワークのバンド幅の特性を決定し、このバンド幅特性に従って出力データストリームのためのバンド幅を調節する。
【００１２】
現行のシステムでは、各ストリームのためのメディアの各ユニットのスタート時間は、そのユニットのための推定送信時間に合わせて決めている。実際の１つの送信時間が所定スレッショルドだけ、推定送信時間を超えると、ネットワークは飽和状態に近いかまたは既に飽和していると見なされ、システムは少なくとも１つのストリームを、全バンド幅利用率を下げるためのターゲットとして選択できる。クライアント受信ユニットに関連したターゲットストリームが一旦選択されると、より低いデータ送信速度を生じさせ得る少ないデータを送信するようにターゲットストリームが変更される。例えば、送信すべきデータを減少することは、ターゲットストリーム上で実行されるデータの圧縮度を徐々にエスカレートし、ターゲットストリームの解像度を下げることによって達成できる。データ圧縮度をエスカレートするだけではバンド幅の飽和を防止するのに送信すべきデータを適正に低減できない場合、ターゲットストリームの解像度も下げることができる。例えば、ターゲットストリームがビデオストリームである場合、フレームサイズをスケールダウンし、フレーム当たりのデータ量を低減し、よって、データ送信速度を減少させることができる。
【００１３】
背景として、異なるタイプのコンテントの許容できる品質のためのバンド幅条件は大幅に変化する。
ＣＤのオーディオ信号は、約１Ｍｂｐｓで送信される。
標準的な品位のビデオ（ＭＰＥＧ−２）は、一般に、約６Ｍｂｐｓで送信される。
高品位ビデオ（ＭＰＥＧ−２）は、一般に、約２０Ｍｂｐｓで送信される。
マルチオーディオ／ビデオストリームは、一般に、約５０〜１５０Ｍｂｐｓ以上で送信される。
全体の品質は多くの異なる方法、例えば、ピーク信号対ノイズ比、遅延時間（効果的なリアルタイムの２ウェイ通信を行うには、１００ｍｓ未満）、オーディオとビデオとの同期化（一般に１０ｍｓ未満）、および、ジッター（時間的に変化する遅延時間）で表現できる。多くのケースでは、オーディオ／ビデオストリームは単一方向であるが、通信のためにバックチャンネルを含むことがある。
【００１４】
本発明者たちが識別した特性は多数あり、これらの特性は上記技術よりも優れた結果をもたらすオーディオ／ビジュアル送信システムのためのものと見なすことができる。
（１）デバイスは、異なる物理的ロケーションに設置されることがあり、時間経過に対して、ユーザーはゲートウェイに対するこれらデバイスのロケーションを変えることがあり得る。例えば、ユーザーはデバイスをゲートウェイの近くに移動したり、またはゲートウェイから離間させたりするかもしれないし、あるいはまた物理的環境が時間の経過に対し大幅に変わるかもしれないが、これらはいずれも、このデバイスに対する無線ネットワークの性能に影響し、順に他のデバイスのための利用可能なバンド幅に影響を及ぼす。この結果、バンド幅が予測できないものとなったり、ダイナミックに変化したりする。
（２）ネットワークに相互接続された異なるデバイスは異なるリソースおよび異なる利用パラダイムを有する。例えば、異なるデバイスは、異なるマイクロプロセッサ、異なるメモリ条件、異なるディスプレイ特性、異なる接続バンド幅能力および異なるバッテリーリソースを有し得る。更に、異なる利用パラダイムは、例えば移動ハンドヘルドデバイスであったり、テレビジョンであったり、パーソナルビデオレコーダーであったりすることがあり得る。この結果、ネットワークの最大スループットが予測できないものとなったり、ダイナミックに変化したりする。
（３）多数のユーザーが異なるタイプのデバイスを使って、同時にシステムからデータにアクセスすることを望むことがあり得る。ユーザーがデータにアクセスし、データへのアクセスを停止するので、ネットワーク条件はダイナミックに変化する傾向がある。この結果、ネットワークの最大スループットが予測できないものとなったり、ダイナミックに変化したりする。
（４）クライアントデバイスに応じ、送信されたデータを異なるフォーマット、例えば、ＭＰＥＧ−２、ＭＰＥＧ−１、Ｈ.２６３、Ｈ.２６１、Ｈ.２６４、ＭＰＥＧ−４（アナログおよびデジタル）にする必要がある。これら異なるフォーマットは、バンド幅に異なる影響を与え得る。この結果、ネットワークの最大スループットが予測できないものとなったり、ダイナミックに変化したりする。
（５）ゲートウェイに提供されるデータは、一定ビットレート（ＣＢＲ）または可変ビットレート（ＶＢＲ）を含み得る圧縮されたビットストリームの形態となり得る。この結果、ネットワークの最大スループットが予測できないものとなったり、ダイナミックに変化したりする。
【００１５】
ゲートウェイで受信したり、送信するために、種々のネットワーク技術、例えば、ＩＥＥＥ８０２.１１、イーサネットおよびパワーラインネットワーク（すなわち、ホームプラグパワーラインアライアンス）を使用できる。かかるネットワークはデータ送信に適しているが、オーディオ／ビデオデータ送信の性質によって課される厳密な条件により、オーディオ／ビデオコンテントに特に適しているわけではない。更に、ネットワークの能力、特に、提供されるデータ最大スループットは、本来的に予測不能であり、上記変化する条件に起因してダイナミックに変化し得る。送信側から受信側に成功裏に送信される（１秒当たりの）実際の（アプリケーション）ペイロードビット（１秒当り）の量に換算して、データスループットを定義できる。システムは、オーディオ／ビデオを示すが、これら概念はビデオ単独および／またはオーディオ単独にも使用される。
【００１６】
特定タイプの無線ネットワーク、すなわちＩＥＥＥ８０２.１１、例えば、ＩＥＥＥ８０２.１１ａおよび８０２.１１ｂを参照すると、これらは次の数種の異なるデータリンクレートで作動できる。
すなわち、８０２.１１（ａ）に対しては６、９、１２、１８、２４、３６、４８または５４Ｍｂｐｓ、および、８０２.１１（ｂ）に対しては１、２、５.５または１１Ｍｂｐｓ。
しかしながら、アプリケーションレイヤーから見た実際の最大スループットはプロトコルオーバーヘッドに起因して、より低く、クライアントデバイスとアクセスポイント（ＡＰ）との間の距離およびクライアントデバイスの配置に応じて変わる。従って、セル（すなわち、ＡＰを中心とする、一般に、円形のエリア）内のデバイスに対する潜在的な最大スループットは、デバイスがＡＰの近くに設置されているときに最大となり、離れているときにはより小さくなる。距離以外に他の要因、例えば、壁またはその他のビル構造物が存在すること、および、コードレス電話および電子レンジの使用に起因する高周波妨害も実際のデータ最大スループットを低下させる原因となる。更に、同じＡＰ内で通信する同一セル内の多数のデバイスは、利用できるセルの最大スループットを共用しなければならない。
【００１７】
チェンおよびギルバート両氏によるケーススタディ、「５−ＧＨｚの８０２.１１ａの無線ＬＡＮシステムの測定性能」、Ａｔｈｅｒｏｓ通信、２００１年８月２７日は、オフィス環境におけるＩＥＥＥ８０２.１１ａのシステムの実際の最大スループットは、約７.３ｍ（２４フィート）で約２３Ｍｂｐｓでしかなく、約２１.４ｍ（７０フィート）を超える距離では２０Ｍｂｐｓ（ほぼ単一の高品位ビデオ信号のレート）より低くなることを示している。８０２.１１（ｂ）システムの最大スループットは、わずかに６Ｍｂｐｓであり、約７.６ｍ（２５フィート）の距離では６Ｍｂｐｓ（ほぼＤＶＤ品位における単一標準品位のビデオ信号のレート）より低下する。このレポートは、約２１.５ｍ（６５フィート）の半径（米国における大きなサイズの家の代表的な値）の円形のセル内に対して、８０２.１１ａに対しては２２.６Ｍｂｐｓ、および、８０２.１１ｂに対しては５.１Ｍｂｐｓの平均的スループットを引用している。従って、ビデオレートを大幅に低減しない限り、８０２.１１ａシステムを使って同じ時間に２つのクライアントデバイスに標準的な品位のビデオ信号および高品位のビデオ信号を流すことはできない。更に、他の状況も同じように、いくつかの異なるオーディオビジュアル信号からの競合トラヒックに関係する。更に、無線通信は、ネットワークが気が付かないデバイス、例えば、上記のようなコードレス電話および電子レンジからの高周波妨害の問題がある。かかる干渉は、ネットワーク性能の予想できないダイナミックな変化を生じさせる。すなわち、データ最大スループット／バンド幅を失わせる。
【００１８】
無線ローカルエリアネットワーク（ＷＬＡＮ）、例えば、８０２.１１システムは、物理的（ＰＨＹ）およびメディアアクセス制御（ＭＡＣ）層での効率的な誤り検出および訂正技術を含む。このシステムは受信確認フレーム（パケット）の送信と、失われたと考えられるフレームの再送信を含む。発信元からのフレームのかかる再送信は、有効最大スループットを低下させることを犠牲に、メディアの固有の誤り率を効果的に低減する。更に、高い誤り率は、ネットワーク内の送信局が未処理データリンクレートを下げるように切り換えさせ、アプリケーションに利用できるデータレートを減少しながら誤り率を低下し得る。
【００１９】
パワーライン通信に基づくネットワークは、基礎となるチャンネルメディアの予想不能で、かつ苛酷な性質に起因する同様な問題を提する。ホームプラグ規格に基づくシステムは、データリンクレートをチャンネル条件に適応させるための技術を含む。８０２.１１無線ネットワークと同じように、ホームプラグ技術は有効最大スループットを下げながら、チャンネル誤り率を低減するための技術、例えば、誤り検出、誤り訂正およびフレームの再送信を含む。これら条件のダイナミックな性質に起因し、ネットワークが提供する最大スループットはＡＶデータストリームを送信するのに必要なデータレートよりも（例えば一時的に）低下し得る。この結果、ＡＶデータが失われ、これによって認識されるＡＶの品質が許容できない程度まで低下する。
【００２０】
かかる制限を低減するために、（１）ネットワークをオーディオビジュアルデータにより適すように、ネットワーク技術を改善し、および／または（２）オーディオ／ビジュアルデータをかかる送信ネットワークにより適したものにするよう、オーディオ／ビジュアルデータを変更することができる。従って、システムは、
（１）ＡＶデータの品質をリアルタイムで連続的に最適にすること、および、
（２）ネットワークの予測不能で、かつダイナミックに変化する条件に適合することにより、（無線）ネットワークを通してオーディオ／ビジュアルデータを健全に流すことができる。
従って、ダイナミックな速度適応化を含むシステムは、性能の大きなダイナミックな変化に悩むネットワークを通して、高品位のオーディオ／ビデオストリームの配信に対処するのに適す。これら変動は受信機の送信機からの距離の変化、妨害波からの距離の変化またはその他の要因によって生じる。
【００２１】
次の説明では、単一ストリームのダイナミックな速度の適応化について説明し、次にマルチストリームのダイナミックな速度の適応化について説明し、次に種々の他の実施例について説明する。
【００２２】
単一ストリームのダイナミックな速度の適応化
ネットワークを通してビデオ信号を健全に流すために、ダイナミックな速度の適応化を使用するシステムをエキステンダーと称すことができる。図２および３には、単一ビデオストリームを処理する基本的な形態のエキステンダーが示されている。図２および３は、このシステムの送信部分、アナログビデオ入力を有する第１部分、デジタル（圧縮された）ビデオ入力を有する第２部分を示す。エキステンダーは入力ビデオストリームがアナログフォーマットであるか、またはデジタル（圧縮された）フォーマットであるかに応じ、ビデオコーディングまたはトランスコーディングモジュールを含む。入力がアナログである場合、処理ステップはＡ／Ｄ変換だけでなく、ＭＰＥＧ−２によるデジタル圧縮およびネットワークを通した最終的な送信を含むことができる。入力が既にデジタルフォーマット、例えば、ＭＰＥＧ−２のビットストリームとなっている場合、処理は通常のエンコーダと異なり、着信ビデオを異なるビットレートで出力ストリームに圧縮するための着信ビットストリームのトランスコーディングを含むことができる。トランスコーディングモジュールは、通常、デジタル圧縮された入力ビデオストリーム、例えばＭＰＥＧ−２のビットストリームまたは他の任意の適当なフォーマットのビットレートを下げる。
【００２３】
コーディング／トランスコーディングモジュールには、所望する出力ビットレート（または他の同様な情報）が提供され、このモジュールはこのビットレートを達成するために速度制御機構を使用する。所望する出力ビットレートの値は、ネットワークモニタモジュールによってエキステンダーに提供される送信チャンネルに関する情報の一部である。ネットワークモニタはネットワークをモニタし、ビデオストリームに利用できるバンド幅をリアルタイムで推定する。エキステンダーから受信機に送られるビットストリームが、利用できるバンド幅（例えばチャンネルレート）にある態様で適合するビットレートを有することを保証するのに、ネットワークモニタからの情報が使用される。ビデオビットレートが固定されている場合、通常画質はフレーム毎に変わる。最適な出力ビットレートを得るために、コーダ／トランスコーダはビデオデータに適用される圧縮レベルを高め、視覚的な品質をゆっくりと低下することができる。トランスコーダの場合、このことをトランス・レーティングと称すことができる。ビットストリームを変えることにより、この結果生じる視覚的な画質の低下はネットワークでサポートできないビットストリームでビデオストリームを送信した場合に生じる視覚的な画質の損失と比較して最小となる。ネットワークによってサポートできないビットレートによってビデオデータが失われると、例えば、フレームが欠落するようなビデオフレームの深刻な誤りを生じ、更に（ＭＰＥＧのようなビデオコーディングアルゴリズムの性質に起因する）誤り伝搬が続くことになる。ネットワークモニタから得られるフィードバックは、出力ビットレートが最適なレベルに向かい、よってトランス・レーティングによって生じる画質の損失が最小となることを保証できる。
【００２４】
システムのうちの受信機部分は、通常のビデオデコーダモジュール、例えば、ＭＰＥＧ−２デコーダを含むことができる。このデコーダは、ネットワークインターフェースと統合できる（すなわち、ネットワークのインターフェースカードのハードウェアに内蔵できる）。これとは異なり、受信デバイスはソフトウェアデコーダに依存できる（例えば、デコーダがパソコンである場合）。このシステムの受信機部分は送信機におけるネットワークモニタモジュールに対するカウンターパートを含むこともできる。この場合、送信機と受信機にあるネットワークモニタモジュールは、エキステンダーシステムにネットワークリソースの所望する推定値を提供するように協動する。一部のケースでは、ネットワークモニタは受信機だけに存在してもよい。
【００２５】
例えば、エキステンダーを含むシステムが、前に述べたように、ビデオ信号を消費するクライアントデバイスに利用できるリソースに関する情報を有する場合、エキステンダーはバンド幅利用率を調節することによりデバイスリソースに従って出力ビデオの画質を更に増減できる。例えば、３０ｆｐｓで６４０×４８０の空間解像度で４ＭｂｐｓにおけるＭＰＥＧ−１のソースストリームを検討する。このストリームが１５ｆｐｓで３２０×２４０の画像解像度の再生能力を有するハンドヘルドのようなリソースが限定されたデバイスに送信されている場合、トランスコーダは、量子化レベルを高めることなく、ビデオをサブサンプリングするだけで、レートを０.５Ｍｂｐｓまで下げることができる。そうしない場合、サブサンプリングを行わなければ、トランスコーダは量子化レベルを高めなければならない。更に、デバイスリソースに関する情報は、共用するネットワークリソースの無駄も防止する。トランスコーダは着信デジタルビデオストリームの圧縮フォーマットを、例えば、ＭＰＥＧ−２フォーマットからＭＰＥＧ−４フォーマットに変換することもできる。従って、トランスコーダは例えばビットレートを変更したり、フレーム速度を変更したり、空間解像度を変更したり、圧縮フォーマットを変更することができる。
【００２６】
エキステンダーは種々の誤り制御技術、例えば順方向誤り訂正およびインターリーブのような方法を使ってビデオを処理することもできる。
【００２７】
ダイナミックな速度適応化
利用可能なバンド幅を管理するのに使用できる別の技術として、ダイナミックな速度適応化技術があり、この技術は、一般に、ビットレートを制御するのにフィードバックを使用する。出力ビデオのレートは送信機から受信側へ現在利用できるネットワークのバンド幅よりも小さくなるよう、最も好ましくは、常時小さくなるように変更される。このように、特に無線ネットワークに適した一定ビットレートを有しないネットワークにシステムを適用できる。
【００２８】
ＭＰＥＧビデオストリームの速度制御をするための１つの技術として、いわゆるＭＰＥＧ−２テストモデル５（ＴＭ５）技術があり、この技術は、ＭＰＥＧグループによって公表されている基準ＭＰＥＧ−２コーデックアルゴリズムである（図１０参照）。図４を参照すると、ＴＭ５における速度制御は多数のＩタイプ、ＰタイプおよびＢタイプのビデオフレームから成るグループオブピクチャー（ＧＯＰ）のレベルでスタートする。画像の番号で表示されるＧＯＰの長さはＮGOPで表示される。一定ビットレート（ＣＢＲ）チャンネルのための速度制御は、固定されたある数のビットＧGOPを提供される（一定の）バンド幅に直接比例するＧＯＰに割り当てることによりスタートする。その後、ＧＯＰ内の特定フレームに目標ビット数が割り当てられる。ＧＯＰ内のその後の各フレームにはコーディングされる直前にビットが割り当てられる。ＧＯＰ内のすべてのフレームをコード化した後に、次のＧＯＰにビットが割り当てられる。このことは、図４に示されており、この図では図解のためにＮGOP＝９となっている。
【００２９】
利用できるバンド幅がＧＯＰの長さに対して低速でしか変化しないと仮定できる場合、時間変化するチャンネルの拡張を適用できる。これは、ある理由のために実際のチャンネル条件が低速でしかまたはあまり頻繁でなく変化するときのケースとなり得る。これとは異なり、粗い時間グラニュラリティを有する変化するチャンネル条件を測定できるにすぎないこともある。いずれのケースにおいても、バンド幅を断片状の一定信号としてモデル化することができるが、変化は（スーパー）ＧＯＰの境界でしか許されない。従って、ＧGOPはＧＯＰごとに変化することが許される。
【００３０】
しかしながら、ＧＯＰの期間に対してバンド幅が短時間で変化するときすなわちターゲットビットレートへの調節およびビット割り当てをフレームごとに行わなければならないとき、または、より頻繁に行わなければならない場合、このことは問題を解決できない。フレームごとにターゲットビットレートへの調節を可能にするために、図５に示されるようなバーチャルＧＯＰの概念を導入することができる（図１１参照）。
【００３１】
各バーチャルＧＯＰは実際のＭＰＥＧ  ＧＯＰと同じ長さでもよいし、他の任意の長さでもよいし、または、実際のＭＰＥＧ  ＧＯＰの長さの整数倍である長さとすることもできる。バーチャルＧＯＰは、一般に、単一の画像シーケンス内に同じ数のＩタイプ、ＰタイプおよびＢタイプの画像を含む。しかしながら、バーチャルＧＯＰは次のバーチャルＧＯＰが現在のバーチャルＧＯＰに対して１（またはそれ以上の）フレームだけシフトしている場合、互いにオーバーラップし合う。Ｉタイプ、ＰタイプおよびＢタイプの画像の順序は１つのバーチャルＧＯＰから次のＧＯＰに変化するが、このことは、各バーチャルＧＯＰへの全体のビットの割り当てには影響しない。従って、例えば、ＴＭ５で使用されたと同じ方法を使ってビットをバーチャルＧＯＰ（正式なＧＯＰの代わりに）に割り当てることができるが、ＧＯＰレベルのビット割り当てはある意味ではフレームごとに再スタートされる（または異なるインターバルで再スタートされる）。
【００３２】
Ｒtを、フレームｔにおいてＧＯＰのうちの残りのフレームをコード化するのに利用できるビットの残りの数を示すものとし、Ｓtを、時間ｔにおいてフレームをコード化するのに実際に使用されたビットの数であるとし、Ｎtを、フレームｔからスタートし、現在のＧＯＰ内でコード化するのに残されているフレームの数を示すものとする。
【００３３】
ＴＭ５ではシーケンスのスタート時にＲtを０にセットし、ＧＯＰのスタートごとにＧGOPだけ増加させる。更に、１つの画像をコード化した終了時にＲtからＳtを減算する。Ｒtを次のように閉じたフォームで記載できることを証明できる。
【００３４】
【数１】
2007184913.tif 000002
【００３５】
ここで、Ｇpは次の式で示される定数である。
【００３６】
【数２】
2007184913.tif 000003
【００３７】
この式は１つのフレームをコード化するのに利用できる平均ビット数を示す。
【００３８】
時間と共に変化するバンド幅を扱うために、定数ＧPをｔと共に変化し得るＧtに置換できる。更に、システムは、フレームｔごとにすなわち各バーチャルＧＯＰに対し、（１）式を再計算できる。バーチャルＧＯＰ内のフレームの残りの数は、ＮGOPであるので、システムはＮｔをＮGOPに置換することができ、この結果、次の式が得られる。
【００３９】
【数３】
2007184913.tif 000004
【００４０】
Ｒtが決定されると、次のステップは時間ｔにおいて現在のフレームにビットを割り当てることである。この場合、フレームはＩタイプ、ＰタイプまたはＢタイプとなり得る。このステップはＣｔで表示される特定のフレームをコード化する複雑さを考慮している。例えば、シーン内の複雑なオブジェクトの動きのために、コード化するのがより複雑なフレームは、コード化し、所定の画質を得るにはより多数のビットを必要とする。ＴＭ−５では、エンコーダが各フレームをコード化した後に更新される各タイプのフレーム（Ｉ、ＰまたはＢ）の複雑さの推定値を維持する。ＣI、ＣP およびＣB がＩ、ＰおよびＢフレームに対する複雑さの現在の推定値を表示するものとし、ＮI、ＮP およびＮB がバーチャルＧＯＰにおいてコード化するのに残されているＩタイプ、ＰタイプおよびＢタイプのフレーム数を表示するものとする（ここで、これらの値はバーチャルＧＯＰの場合、定数であることに留意されたい）。
【００４１】
Ｍ５は上記パラメータに基づき、コード化すべきＩ、ＢまたはＰ画像に対するビットのターゲット数であるＴI、ＴP、ＴBを計算するための方法を示す。ＴＭ５の式は次のようにバーチャルＧＯＰを取り扱うのに若干変更できる。
【００４２】
【数４】
2007184913.tif 000005
【００４３】
ここで、ＫI、ＫP およびＫB は定数であり、Ｉ、Ｂ、ＰはＩフレーム、ＢフレームおよびＰフレームをそれぞれ示し、Ｃは複雑さの尺度である。任意のタイプの圧縮速度歪みモデルも、一般的な意味において定義され、同じように使用できると理解すべきである。
【００４４】
これから判るように、この方式はフレームからフレームへのバーチャルＧＯＰ方式（またはバーチャルＧＯＰのスペーシングと合致する他の方式）に基づき、ビットの再割り当てを可能にする。１つのバーチャルＧＯＰに対する利用率およびビット割り当てをトラッキングすることができ、次のバーチャルＧＯＰに対し、バーチャルＧＯＰに対する使用されていないビットを割り当てることができる。
【００４５】
マルチストリームのダイナミックな速度適応化
上記単一ＡＶストリームのための基本エキステンダーは、アナログ入力ストリームをコード化するか、またはバンド幅制限の原因または他の競合するストリーム（存在する場合）に関係することなく、入力デジタルビットストリームのビットレートを利用可能なバンド幅に適応させる。次の記載では、システムは多数のビデオストリームを処理する異なるエキステンダーシステムを含むことができ、この場合、エキステンダーシステムは、競合トラヒックの場合に多数のストリームのビットストリームを制御または調節する責任を果たす。
【００４６】
図６に示されたマルチストリームエキステンダーは、多数のビデオエンコーダ／トランスコーダの上に“（トランス）コーダマネージャー”を設けている。図６に示されるように、システムはｎ個のビデオストリームに操作している。この場合、各ソースはアナログ（例えば、コンポジット）またはデジタル（例えば、ＭＰＥＧ−２で圧縮されたビットストリーム）のいずれかでよい。ここで、Ｖnは入力ストリームｎを示すが、Ｖ’nは出力ストリームｎを示し、Ｒnは入力ストリームｎのビットレート（この入力ストリームは入力ストリームｎが既に圧縮されたデジタルフォームとなっている場合にしか存在せず、入力がアナログである場合は使用されない）を示し、一方、Ｒ’nは出力ストリームｎのビットレートを示す。
【００４７】
それらのビットレートは（トランス）コーダマネージャーによって制御されるが、各入力ストリームは別々にコード化またはトランスコードされる。この（トランス）コーダマネージャーは、出力ビデオストリームの総ビットレートが所望する総チャンネルビットレートに一致するように、多数のビデオストリームにビットレートを割り当てる。多数のビデオストリームの総レートが利用できるバンド幅を超えないことを保証するように、ネットワークモニタモジュールから再び所望するビットレートを得る。各コーダ／トランスコーダは再びそのストリームのための割り当てられたビットレートを達成するために、ある種のレート制御を使用する。
【００４８】
この場合、システムは（図には示されていない）多数の受信機を含むことができる。このシステム内の各受信機は単一ストリームの場合のための受信機と同様な機能を有する。
【００４９】
単一ストリームケースの場合のように、多数のストリームのビットレートはかかる制約を満足するように、ある種のビット割り当ておよびゲート制御により制御しなければならない。しかしながら、マルチストリームシステムの場合、ダイナミックなビットレートの適応化をするには、より一般的で、かつフレキシブルなフレームワークが有効である。
以下のようないくつかの理由が存在する。
（１）システムは異なる特性を有し得る多数のＡＶストリームを取り扱わなければならず、従って、チャンネルによってサポートされる利用可能なビットを割り当てなければならない。
（２）システムは、一部予測不能なネットワーク特性を取り扱わなければならず、後述するように、多数の受信機の場合、特別な注意が必要である。
（３）システムは、受信デバイス自身の間の差、例えば、スクリーンサイズ、サポートされているフレームレートなどの差を処理しなければならない。
（４）異なるビデオソースはそれらのコンテントに起因して重要性が異なるものと見なすことができる。また、異なるビデオストリームが異なる人（ユーザー）によって異なるロケーション（例えば、家庭内の異なる部屋）で観られるので、システムは異なるユーザーの優先度を考慮したいことがある。
【００５０】
システムを最適化する間、この結果生じる環境の異質性を考慮することができる。
【００５１】
この目的のために、マルチストリームエキステンダーシステムは、図６に示されるように、トランスコーダマネージャーへの入力として（送信チャンネルに関する情報の他に）別の情報をオプションで受信できる。この情報は、例えば、
各受信デバイスに関する情報、
各ビデオソースに関する情報、および、
各ユーザーの優先度に関する情報を含む。
【００５２】
次のサブセクションでは、まず、このシステム内の多数のストリームのビットレートが受ける制限のタイプをリストアップし、次に、上記のようなネットワークの所定の異質な特性を取り込むのに使用されるストリームの優先権の決定の表記について説明し、次に、マルチストリーム（または、ジョイント）ダイナミックレートの適応化を達成するための種々の技術について説明する。
【００５３】
多数のストリームのためのビットレートの制限
ネットワーク上の個々のオーディオ／ビデオストリームのビットレートは種々の制約を受ける。
【００５４】
まず、個々のストリームの合計速度は送信側から受信側への全チャンネル容量またはネットワークのバンド幅以下となり得る。このバンド幅はストリームの数の増減、ネットワーク内の輻輳、妨害などに起因し、ダイナミックに変わり得る。
【００５５】
更に、個々の各ストリームの速度は最小値および最大値によって境界が定められる。次の理由から最大値の制限が課される。
（１）使用されるチャンネルまたはネットワークの制限に起因し、１つのストリームは最大速度を有し得る。例えば、無線ネットワークを使用する場合、単一デバイスへの最大スループットは、アクセスポイントとクライアントデバイスとの間の距離に応じて決まる。この最大レートは時間と共に変化し得ることに留意されたい。例えばワイヤレスネットワーク内のクライアントデバイスがポータブルであり、アクセスポイントへの距離が長くなっている（例えば、携帯中の）場合、最大スループットは低下すると予想される。
（２）ストリームはクライアントデバイスも制限することにより、最大速度を有し得る。クライアントデバイスは能力またはリソース制限、例えば、バッファサイズ制限または処理パワー制限があり得るので、着信オーディオ／ビデオストリームの速度上限が定められる。
（３）ストリームは最小の品質を保証するためにシステムまたはユーザーによって課される最小レートを有し得る。この最小速度がシステムによって提供されない場合、デバイスへの送信を行うことはできない。このことは、所定の最小の品質を達成するのに役立つ。ストリームはバッファのアンダーフローを防止するために課される最小速度を有し得る。
【００５６】
ストリームの優先度の決定または重み付け
上記（トランス）コーダマネージャーはいくつかの戦略的方針を使用できる。このマネージャーは各ストリームに対して同じ量の利用可能なビットを割り当てようと試みる。しかしながら、この場合、ストリームの質は、時間に対するのと同様ストリームごとに大きく変わり得る。更に、マネージャーは又各ストリームの質がほぼ等しくなるように利用可能なビットを割り当てる。この場合、極めてアクティブなコンテントを有するストリームには、あまりアクティブでないコンテントを有するストリームよりも多くのビットが割り当てられる。別の方法は、ユーザーの好みに基づき、異なるストリームの質を変えることができるように、ユーザーが異なるストリームに対して異なる優先度を割り当てできるようにすることである。この方法は、一般に（トランス）コーダマネージャーが全体の歪みを最小にするときに、各ストリームの個々の歪みを重み付けすることに一般に均等である。
【００５７】
オーディオ／ビデオストリームの優先度または重みは、種々の方法で得ることができるが、一般に、クライアントデバイスのユーザーの好みに関係する。本明細書で説明する重み（優先度）とは、（ビデオ内の動きまたはテキスチャー変化の量に関係する）マクロブロック、ビデオフレーム、フレームのグループまたはビデオシーケンスのコード化の複雑さに対応する、文献によく記載されているタイプの重みまたは係数とは異なるものであり、この重み（優先度）を使ってビデオのかかる部分の間の画質を均一にできることに留意されたい。ここで、１つ（または、それ以上の）オーディオ／ビデオストリームを他のストリームよりもより重要と見なす場合、重みは故意に、いくつかのオーディオ／ビデオストリームにわたり画質の分布を不均一になるようにされる。種々のケースは、例えば、次のケースおよび次のケースの組み合わせを含むことができる。
【００５８】
ケースＡ
ストリームの重みをクライアントデバイスに関係する好みの結果とすることができる（図１５参照）。競合するストリームがチャンネルからバンド幅をリクエストする場合、あるデバイスが受信するストリームの歪みを別のデバイスが受信するストリーム内の歪みと同じ量の歪みとして、より厳しく見なすように、１つのデバイスに１つの優先度を割り当てる。例えば、ユーザーはロケーションによって、別のＴＶ受信機よりも１つのＴＶ受信機に優先度を割り当てると決定できる。ユーザーはベッドルームまたは書斎内のＴＶと比較してリビングルーム内のＴＶ（多数の視聴者が観る可能性が高いので）により高い重みを割り当てることができる。この場合、リビングルーム内のＴＶで受信されるコンテントは他のＴＶで受信されるコンテントよりもトランスコーディングにより受ける歪みが少なくなる。別の例として、相対的なスクリーンサイズによって、異なるＴＶ受像機にいくつかの優先度を割り当ててもよい。すなわち、ＴＶ受像機のスクリーンサイズが十分小さければ、レートを大幅に低減すること（および歪みがより高いこと）は、許容可能である。他のデバイスリソースも又、重みあるいは優先度に変換することができる。
【００５９】
かかる重み付けはデフォルトにより固定された値にセットできる。すなわち、固定されたパターンを使用できる。所望する場合、かかる重み付けはユーザーからの入力を必要としないようにできる。
【００６０】
かかる重み付けを１回だけ（セットアップおよび設置中に）セットするようにできる。例えばユーザーがどのクライアントデバイスをネットワークの一部とし、デバイスをどこに設置するかを決定すれば、ユーザーによってこのようなセッティングを入力できる。ユーザーが新しいクライアントデバイスをネットワークに接続するときに、このようなセットアップの手順を周期的に繰り返すことができる。
【００６１】
かかる重み付けをゲートウェイとクライアントデバイスの間の相互作用の結果とすることもできる。例えば、クライアントデバイスはゲートウェイに対して自らを所定のタイプのデバイスとしてアナウンスし、記述できる。この結果、ゲートウェイにより所定の重み、すなわち優先度の値をこのデバイスに割り当てできる。
【００６２】
ケースＢ
ストリームの重みを時間内の特定のポイントで特定のストリームによって搬送されるコンテントアイテム（例えば、ＴＶ番組）に関連した好みの結果とすることができる（図１６参照）。すなわち、ストリームを通して所定タイプのコンテントが送信されている時間の間に、このストリームの歪みが同一または他のデバイスによって受信される異なるタイプのコンテントを有する他のストリーム内の同じ量の歪みとしてより深刻に見なされるように、このストリームに対し、ある優先度を割り当てる。例えば、ユーザーは、ジャンルまたはその他のコンテントに関する属性に基づき、ＴＶ番組に優先度を割り当てると決定できる。番組に関するこれら属性、ジャンル情報は電子番組ガイドから得ることができる。これらコンテント属性は、コンテントのチャンネルの知識（映画チャンネル、スポーツチャンネルなど）に基づくこともできる。例えば、ユーザーは他のＴＶ番組、例えば、ゲームショーと比較してより重い重みを映画に割り当てることができる。この場合、多数のストリームが限られたチャンネル幅に関して競合し、１つのストリームが１つのＴＶ受像機に映画を搬送しており、一方、別のストリームが同時に別のＴＶにゲームショーを搬送しているとき、第２ストリームよりも第１ストリームのほうが、トランスコーディングによって、より少ない歪みしか受けないような優先度を第１ストリームに割り当てる。
【００６３】
かかる重み付けはデフォルトにより固定された値にセットできる。すなわち、固定されたパターンを使用できる。所望する場合、かかる重み付けはユーザーが入力しなくてよいようにできる。
【００６４】
かかる重み付けは（セットアップおよび設置中に）１回設定できる。例えば、ユーザーがどのタイプのコンテントが自分にとって重要であるかを判断すれば、ユーザーがこの設定を入力できる。次に、作動中にゲートウェイはユーザーの好み（１つ以上のユーザーの好み）の記述と送信される番組の記述とを一致させることができる。実際の重みはこの一致手順の結果として設定できる。ユーザーの好みをセットアップする手順は周期的に繰り返すことができる。ユーザーの好みは任意のタイプの好み、例えば、ＭＰＥＧ−７またはＴＶのＡｎｙｔｉｍｅとすることができる。システムは少なくとも一部として、ターゲットビットレートを選択するためのユーザーのプレゼンス（任意のユーザーまたは特定のユーザー）を同じように含むことができる。ユーザーはリモコンのような直接入力を含むことができ、更に、システムはターゲットビットレートを選択するためのユーザーの好みの間の優先度を含むことができる。
【００６５】
かかる重み付けはユーザーの動作をゲートウェイがトラッキングする結果とすることもできる。例えば、ゲートウェイはユーザーが頻繁に使用するコンテントのタイプをトラッキングするようにできる。ゲートはユーザーの動作からユーザーの好みを推定することができ、この結果、ゲートウェイにより所定の重みまたは優先度の値を所定のタイプのコンテントに割り当てできる。
【００６６】
ケースＣ
任意の時間、またはユーザーの要求でストリームの相対的重みを設定したり変えたりすることができる（図１７参照）。
【００６７】
かかる重み付けは、家の中の特定の人物に対して定めることができる。例えば、家庭内のある人物がどんなデバイスを使用するにせよ、可能な最高画質のコンテントを受信したいことがある。この場合、特定の時間においてその人が使用中のデバイスに従って重みを変更できる。
【００６８】
かかる重み付けは、例えば、リモコンを使って任意の時間に設定または変更できる。
【００６９】
かかる重み付けはユーザーが視聴中ではなく、コンテントを録画中であるかどうかに基づくこともできる。ストリームが（視聴ではなく）録画中である場合に、より高い優先度と見なされるような（従って、より少ない歪みしか受けないような）重み付けとすることができる。
【００７０】
ケースＤ
ストリームの相対的重みはストリームのモードに基づいて設定してもよい。特に、オーディオビジュアルストリームのオーディオストリームとビデオストリームとを送信中に分離し、異なるように扱ってもよい。例えば、オーディオビジュアルストリームのうちのビデオ部分よりも、より高い優先度をオーディオ部分に割り当ててもよい。このことは、ＴＶ番組を観ているときに多くのケースではユーザーにとってオーディオ信号が損われることはＴＶ信号からのビデオ情報が損われることよりもより深刻な事態であると見なされることによって動機付けされる。このことは、例えば、視聴者がスポーツ番組を観ているときに、コメンテーターが決定的な情報を提供する場合のようなケースである。別の例として、ユーザーが高品位の音楽を含むオーディオストリームの品質を劣化させたくない場合を挙げることができる。更に、オーディオの品質はスピーカーの間で異なることがあったり、異なるスピーカーに送られることがある。
【００７１】
ネットワークの特性
上記ネットワークの物理層およびデータリンク層は、チャンネル媒体の悪条件を緩和するようになっている。これらネットワークの特性の１つは、特に、本明細書で説明するマルチストリームイクステンダーシステム内のような多数のストリーム間のビット割り当てに影響する。特に、ＩＥＥＥ８０２.１１に基づくネットワークでは、ゲートウェイシステムは異なるクライアントデバイスと異なるデータリンク速度で通信することができる。ＩＥＥＥ８０２.１１に基づくＷＬＡＮはいくつかのデータリンク速度で作動でき、アクセスポイントとクライアントデバイスとの間の妨害効果または距離の効果を適応的に小さくするように、データリンク速度を切り換えまたは選択できる。距離が長くなり、妨害が大きくなることにより、ネットワーク内の局は未処理のデータリンク速度を下げるように切り換わる。このことをマルチレートサポートと称すことができる。ゲートウェイが単一無線チャンネル内で異なるデータ速度で異なるクライアントデバイスと通信することは、多数のストリームのジョイントコーディングのためのビット割り当てで使用されるようなチャンネルのモデルに影響を与える。
【００７２】
速度制御およびビット割り当てにおけるこれまでの作業は、個々のＡＶストリームに対し、リクエストされた速度に直接比例してＡＶストリーム間で単に分割できる単一のバンド幅が存在するような従来のチャンネルモデルを使用している。本発明者たちは、このことは、マルチ速度能力によって、ＷＬＡＮ、例えば、８０２.１１のＷＬＡＮのケースには当てはまらないと判断した。かかる無線システムは、各リンクの速度の合計が異なるリンク間で割り当てられるために、システムから利用できる全バンド幅と必ずしも同じでないことを特徴とし得る。このように、３０Ｍｂｐｓの最大バンド幅を有するシステムでは、１０Ｍｂｐｓのビデオ信号および２０Ｍｂｐｓのビデオ信号を、送信できないことがある。８０２.１１無線システムにおいて、特定の無線リンクが使用するバンド幅は性質上、一時的なものであり、特定の無線リンクの最大バンド幅に関係している。例えば、リンク１が３６Ｍｂｐｓの能力を有し、１８Ｍｂｐｓの速度でデータが送信される場合、そのリンクの利用率は５０％であり、この結果、システムの全バンド幅の５０％が使用される。例えば、リンク２が２４Ｍｂｐｓの能力を有し、２４Ｍｂｐｓの速度でデータが送信される場合、リンク２の利用率は１００％である。リンク２を利用する結果、システム全体のバンド幅の１００％が使用され、他のリンクにはバンド幅は残されないので、１つのストリームしか送信できないことになる。
【００７３】
マルチストリームのジョイントコーディングにおけるビット割り当て
マルチストリームの速度適応に対するより最適なアプローチは、ジョイントビット割り当て／速度制御を適用することである。このアプローチはマルチストリームエキステンダーシステムへの入力ストリームがアナログであるケースだけでなく、入力ストリームが既に圧縮されたデジタルフォームとなっているケースにも当てはまる。
次のパラメータを下記のように定める。
ＮLはストリームの数を示す。
Ｐnは、ストリームｎに割り当てられる重みまたは優先度を示し、Ｐn≧０である。
ａnは、ストリームｎに対する最小出力レートを示し、ａn≧０である。
ｂnは、ストリームｎに対する最大出力レートを示し、ｂn≧ａnである。
Ｄn（ｒ）は出力レートｒの関数として出力ストリームｎの歪み（すなわちエンコーダまたはトランスコーダの入力に対する出力の歪み）を示す。
ＲCはチャンネルの利用可能なバンド幅または最大ネットワークの最大スループットを示す。
Ｒnは入力ストリームｎのビットレートを示す。
Ｒ’nは出力ストリームｎのビットレートを示す。
【００７４】
Ｒn、Ｒ’n、ＲCは一般に時間可変であり、従ってこれらは時間ｔの関数である。
【００７５】
マルチストリームエキステンダーの問題は次のように包括的に定式化できる。
【００７６】
この目標は、全てのストリームの合計速度をチャンネル容量の範囲内としながら、全ての出力ストリームの全体の品質を最高にするか、または等価的に全歪み基準Ｄを最小にする出力レートＲ’n，ｎ＝１，…，ＮLの組を探すことである。
【００７７】
全歪み基準Ｄの一つの形態は個々のストリームの歪みの重み付けされた平均値である。
【００７８】
【数５】
2007184913.tif 000006
【００７９】
別の形態は、個々のストリームの重み付けされた歪みの最大値である。
【００８０】
【数６】
2007184913.tif 000007
【００８１】
メディアストリームの品質を記述するその他の適当な基準として、例えば、ピーク信号対ノイズ比（ＰＳＮＲ）を使用できる。同様に、すべてのストリームの全体の品質を記述するのに他の適当な基準、例えば個々のストリームのＰＳＮＲ値の平均、または個々のストリームのＰＳＮＲ値の最小値または他の適当な形態を使用できる。
【００８２】
この章では、ストリームに提供されるビットレートの等量が、チャンネルの利用等量に対応する、ケーブルテレビと同様な従来のチャンネルモデルを使用するが、一方、このモデルは上記無線タイプの利用にも拡張できる。従って、目標は次の制限によって式（４）または（５）の基準を最小にすることである。
【００８３】
【数７】
2007184913.tif 000008
【００８４】
すべてのｎに対し、所定の時間ｔで次の式が成り立つ。
【００８５】
【数８】
2007184913.tif 000009
【００８６】
トランスコーディングの場合、各出力ストリームＶ’nの歪みは元の圧縮によって、元のデータに対して既に大きな歪みを有する入力ストリームＶｎに関して測定されることに注意を要する。しかしながら、元のデータに対するこの歪みは未知である。従って、元の（入力でない）ストリームに対する出力ストリームの最終歪みも未知であるが、対応する入力ストリームＶｎ内に既に存在する歪みによって下方の境界が定められる。トランスコーディングの場合、組み合わされた入力レートが利用可能なチャンネルバンド幅を超えないとき、すなわち次の式で示されるときに、この問題に対する些細な解決案が見つかっていることが注目される。
【００８７】
【数９】
2007184913.tif 000010
【００８８】
ここで、すべてのｎに対し、Ｒ’n ＝Ｒn であり、Ｄn （Ｒ’n ）＝Ｄn （Ｒn ）であり、トランスコーディングを実施する必要はない。
【００８９】
下記の式が成立する場合、問題に対する解は存在しないことに留意すべきである。
【００９０】
【数１０】
2007184913.tif 000011
【００９１】
輻輳、妨害または他の問題に起因して、利用できるチャンネルバンド幅／ネットワーク最大スループットが（劇的に）低下するときに、このことが起り得る。このような状況では、制限（７）のうちの１つを緩和しなければならないか、または、システムはバンド幅をリクエストするストリームへのアクセスを拒否しなければならないことになる。
【００９２】
式（５）の歪み基準を最小にする最適解は、個々のストリームの（重み付けされた）歪みの値がすべて等しい場合の解であることに注目すべきである。
式（６）は従来のチャンネルモデルによるチャンネルによって課される制限を具現化するものであることに注目すべきである。この制限は、特定のネットワークの特性によって決定される。マルチ速度サポートを有するＬＡＮに適用したときは、異なるタイプの制限が使用されることになる。
【００９３】
上記最小化問題に対する解を探すのに使用できるいくつかの現存の最適化アルゴリズム、例えば、ラグラジュアンの最適化アルゴリズムおよびダイナミックプログラムが存在する。上記問題にかかる最適化アルゴリズムを適用するには、広い解空間にわたってサーチしなければならないだけでなく、ビデオデータの圧縮を何回も繰り返さなければならないことがあり得る。このことは、計算上禁止的に高価となり得る。マルチビデオプログラムをジョイントコーディングするためのビット割り当ての問題に対する実際的なアプローチは、いわゆる、ＭＰＥＧ−２のテストモデル５（ＴＭ５）で使用されるアプローチを拡張するものである。
【００９４】
現存のアプローチはスーパーＧＯＰおよびスーパーフレームの概念に基づく。単一ストリームの通常のＭＰＥＧ−２のＧＯＰ（グループオブピクチャー）は、多数のＩタイプ、Ｐタイプ、Ｂタイプのフレームを含む。多数のＭＰＥＧ−２のストリームの上にはスーパーＧＯＰが形成され、このＧＯＰはＮGOPスーパーフレームから構成される。ここで、１つのスーパーフレームは各ストリームからの１つのフレームを含むフレームの組であり、スーパーフレーム内のすべてのフレームは同時に発生する。スーパーＧＯＰは個々のストリームのＧＯＰSが同一長さでなく、整合していなくても、整数のストリームレベルのＭＰＥＧ−２のＧＯＰSを常に含む。ビット割り当て方法はスーパーＧＯＰに割り当てられたターゲット数のビットを含む。このターゲット数ＴsはどのスーパーＧＯＰに対しても同じであり、固定と見なされるチャンネルビットレートから得られる。Ｔsを決定すると、ビット割り当てはスーパーＧＯＰ内の各スーパーフレームに対して実行される。この結果生じるスーパーフレームに対するビットのターゲット数Ｔtは、所定ストリーム内のＩ、ＰおよびＢフレームの数に応じて決まる。次に、Ｔtを決定すると、スーパーフレーム内の各フレームに対してビット割り当てが実行される。この結果生じる時間ｔにおけるスーパーフレーム内のフレームに対するビットのターゲット数はＴt，nによって表示される。
【００９５】
現存技術は、ビデオフレームをコーディングする“複雑さ”を示すビデオフレームに対する複雑度の尺度Ｃを使用することに基づいている。ストリームには各ストリーム内のフレームの推定複雑度に比例したビットが割り当てられる。すなわち、コーディングするのにより複雑なフレームを有するストリームは、コーディングするのにあまり複雑でないストリームと比較して、ビット割り当て中に多数のビットを受け、この結果、各ストリーム内の歪み量は等しくなる。コーディングまたはトランスコーディングの結果生じるストリームの速度と歪みとの関係は、当業者に公知の種々のタイプの速度−歪みモデルを使用し、種々の態様で表わされる。次の記載は、複雑度の尺度Ｃを用いた簡単なレート−歪みモデルを使用しているが、他のレート−歪みモデルも同じように利用できる。
【００９６】
ビデオフレームに対する複雑度の尺度Ｃは、そのビデオフレームのＤＣＴ係数を圧縮するのに使用される量子化値と、（その量子化値を使用する）そのビデオフレームをコード化するのに発生されるビット数との積で定められる。従って、そのフレームの複雑度の推定値Ｃt，nと、そのフレームに対して使用される量子化値Ｑt，nに基づき、スーパーフレーム内の特定フレームに対するビットのターゲット数Ｔt，nを計算できる。
【００９７】
【数１１】
2007184913.tif 000012
【００９８】
Ｃt，nの値は、コード化すべき同じタイプ（Ｉ、ＰまたはＢ）の将来の全てのフレームに対しストリーム内で一定であると仮定する。従って、Ｃt，nはフレームタイプに応じ、ＣI，nまたはＣP，nまたはＣB，nのいずれかに等しい。
【００９９】
スーパーフレーム内のすべてのフレームに割り当てられるビット数の合計は、そのスーパーフレームに割り当てられるビット数に等しくなければならない。すなわち次のとおりである。
【０１００】
【数１２】
2007184913.tif 000013
【０１０１】
この技術は、均一な画質を得るために全てのストリーム内の全てのフレームに対し、同じ量子化値Ｑを使用するものである。しかしながら、異なるピクチャータイプ（Ｉ、ＰおよびＢ）を考慮すると、各フレームに対する量子化値は一定の重み付けファクターによって固定されたＱに関連づけられる。すなわち、次のとおりである。
【０１０２】
【数１３】
2007184913.tif 000014
【０１０３】
ここで、Ｋt，nはフレームタイプだけに関係し、単純に、ＫI、ＫPまたはＫBのいずれかである。
【０１０４】
式（１０）と（１１）と（１２）とを組み合わせることにより、スーパーフレーム内のフレームに対し、次のようなビット割り当て式が得られる。
【０１０５】
【数１４】
2007184913.tif 000015
【０１０６】
ここで、この式は異なるストリームからのフレームに対し、それらに対する予想複雑度に比例するビットが割り当てられることを示す。
【０１０７】
上記のように、ストリームの優先度を定めることに適応するために、次のように既存の技術を拡張できる。
【０１０８】
ストリームの優先度ｐｎを含むことにより、式（１２）を次のように一般化できる。
【０１０９】
【数１５】
2007184913.tif 000016
【０１１０】
ここで、ｐｎは次の式が成立するように選択される。
【０１１１】
【数１６】
2007184913.tif 000017
【０１１２】
例えば、全ての式が同じ優先度を有する場合、上記式（１５）が成立するように、すべてのｎに対してｐｎ＝１となる。より高い優先度のストリームに対しては１より大きい値ｐｎが割り当てられるが、より低い優先度のストリームに対しては１より小さいｐｎの値が割り当てられる。
【０１１３】
式（１０）と（１１）と（１２）とを組み合わせると、次の式が得られる。
【０１１４】
【数１７】
2007184913.tif 000018
【０１１５】
上記式を使って式（１３）の代わりにビット割り当てをすることができる。優先度を使用し、高い優先度のストリームからのフレームに多数のビットを割り当て、低い優先度のストリームからのフレームに少ないビットを割り当てることができることが式（１６）から理解できる。このような方針は、暗黙に歪み基準式（５）を最小にしようとする試みである。このような拡張はコーディングおよびトランスコーディングの双方に実行できることを示している。
【０１１６】
上記アプローチでは、コード化に当って、過去のコード化されたフレームから、フレームのコード化の複雑度Ｃを推定する。これら推定値は、フレームごとに更新され、着信フレームにビットを割り当てるのに使用される。すなわち、現在のフレームｔおよび将来のフレームに対する複雑度の推定値は、前のフレームで使用された量子化値の測定値だけでなく、（同一ストリームｎ内の）前のフレームで使用されたビットの実際の量に基づく。従って、推定値は次のようになる。
【０１１７】
【数１８】
2007184913.tif 000019
【０１１８】
ここで、Ｓはビデオフレームで実際に使用されたビット数を示し、ｔは現在のフレームを示し、ｔ−τは同一タイプ（Ｉ、ＰまたはＢ）の最も近い前のフレームを示し、プライム符号（’）はエンコーダの出力から推定値が計算されたことを示す。また、実際には１つのストリームに対し、これら推定値の３つの値（各画像タイプに対して１つの値）しか維持されないことに留意すべきである。
【０１１９】
このアプローチはトランスコーディングでも使用できるが、本発明者はこれら推定値を改善できると判断した。その理由は、トランスコーディングの場合、現在のフレームの複雑度に関する情報が存在することにあり、トランスコーダの入力にはコード化されたフォームでこのフレームを利用できるからである。しかしながら、トランスコーダはビットストリームのレートを変えるので、出力フレームの複雑度はトランスコーダの入力フレームの複雑度と同一でないことが判った。入力の複雑度に対する出力の複雑度の比は、時間に対して比較的一定に留まることも判った。従って、前のフレームの入力の複雑度の推定値および出力の複雑度の推定値に基づくこの比の推定値を使って、現在のフレームの所定の入力の複雑度の値をスケーリングし、次のように、現在のフレームの出力の複雑度をより良好に推定することができる。
【０１２０】
【数１９】
2007184913.tif 000020
【０１２１】
ここで、プライム符号（’）のないＳおよびＱは、入力ビットストリームから計算されたものである。
【０１２２】
マルチストリームエンコーディングのための上記アプローチは、いずれも一定ターゲットビットレート、すなわち、一定ビットレートのチャンネルを仮定したものである。実際にはこのような仮定が成り立たないネットワークもある。前述したように、特に、無線チャンネルでは成り立たない。従って、チャンネルの時間変化する性質を考慮した変形アプローチが有効である。
【０１２３】
（スーパー）ＧＯＰの時間長さに対してターゲットビットレートが、低速でしか変化しないと仮定することができる場合には、１つの拡張を適用することができる。これは、ある理由から、実際のチャンネル条件が低速でしか、または比較的頻繁には変化しないときのケースとなり得る。代りに、粗い時間グラニュラリティで変化するチャンネル情報を測定することができるだけかもしれない。いずれのケースにおいても、ターゲットビットレートを物理的な制限によって決定される所定の値よりも、より迅速に変わるようにすることはできない。従って、（スーパー）ＧＯＰの境界でしか変化が許されない場合、ターゲットビットレートを断片的な一定の信号としてモデル化できる。
【０１２４】
このアプローチは、各（スーパー）ＧＯＰのスタート時にビット割り当てアルゴリズム（可能な場合には上記他の拡張と一緒に）にＴsの新しい値を提供することにより、前述のアプローチと組み合わせることができる。換言すれば、Ｔsは（スーパー）ＧＯＰごとに変化することが許される。
【０１２５】
別の拡張方法は、（スーパー）ＧＯＰの時間長さに対してターゲットビットレートが迅速に変化する場合のケース、すなわち、ビットレートに対する調節およびビット割り当てを（スーパー）フレームごとに行わなければならない場合のケースに対してバーチャルＧＯＰの概念を使用することである。これまで、バーチャルＧＯＰの使用はシングルストリームのダイナミックな速度適応化に対して説明した。マルチストリームのケースでは、バーチャルＧＯＰの概念はバーチャルスーパーＧＯＰの概念まで拡張される。
【０１２６】
マルチ速度のサポートを有するネットワークに対しては、ＩＥＥＥ８０２.１１に基づくようなＬＡＮ環境におけるマルチストリームのジョイントコーディングにおける別のビット割り当てアプローチが適当である。この場合、ゲートウェイ内のアクセスポイントは異なるデータリンク速度で異なるクライアントデバイスと通信できる。このために、また他の理由から、ゲートウェイから１つのデバイスへの最大データスループットは、ゲートウェイから別のデバイスへの最大スループットと異なることが有り得るが、各デバイスへの送信は単一の共用チャンネルの全体の利用に影響する。
【０１２７】
前と同じように、利用可能なチャンネル容量を共用するネットワークの上には、ＮL個のデバイスが存在する。これらＮL個のデバイスに対し、ＮL個のストリーム（デバイスごとに１つのストリーム）が送信されると仮定できる。このシステムは、これらデバイスに送信されるビデオの最良の可能な画質を保証する役割を果たすマルチストリームマネージャー（例えば、マルチストリームトランスコーダまたはエンコーダマネージャー）を使用する。
【０１２８】
各デバイスｎ＝１，２，…，ＮLに対するバンド幅または最大データスループットＨnを測定するのに１つの機構を利用できると見なすことができる。一般に、このスループットはデバイスごとに変化し、ネットワーク内の変動Ｈn（ｔ）に起因して時間と共に変化する。データ最大スループットは、時間の十分細かいグラニュラリティをもって測定できると推測される。最大データスループットＨnは、毎秒のビットで測定される。最大スループットＨnは、実際には所定の時間インターバルにわたる、すなわち、ビデオフレームまたは複数のフレームのグループの継続時間にわたる平均値であることに留意されたい。
【０１２９】
例えば、８０２.１１ネットワークのケースでは、デバイスｎに対するバンド幅または最大データスループットは、アクセスポイントとデバイスｎとの間で通信を行うために使用される生データ速度、パケット長さ（ビットを単位とする）およびパケット誤り率の測定値に関する情報から推定できる。最大スループットを測定するための他の方法も使用できる。
【０１３０】
（共用）チャンネルの１つの特定モデルは、ゲートウェイが時間のうちの部分ｆnの間に各クライアントデバイスｎと通信するようなモデルとなっている。例えば、時間部分ｆ1の間にホームゲートがデバイス１にビデオストリーム１を送信し、時間部分ｆ2の間にゲートウェイがビデオストリーム２をデバイス２に送信し、次々に同様なことが行われる。従って、ゲートウェイからクライアントｎまでの有効スループットはｆｎＨｎで得られる。
【０１３１】
任意の時間インターバルに対して次のチャンネル制約が成り立つ。
【０１３２】
【数２０】
2007184913.tif 000021
【０１３３】
すなわちチャンネルが利用する時間部分の合計は、１.０以下でなければならない。これら時間部分が１.０まで増加した場合、チャンネルはフル容量で利用される。
【０１３４】
トランスコーディングの場合、Ｒnは元の（ソース）ビデオストリームｎの速度を表示するものとする。ビデオストリームを同時にすべてのデバイスに送信できるようにするには、（１９）の制限のもとで全てのｎに対して次の式が成り立つような、ｆn，ｎ＝１、２、…、ＮLの組が存在し得ることである。
【０１３５】
【数２１】
2007184913.tif 000022
【０１３６】
かかるｆnの組が存在しない場合、１つ以上のビデオソースの速度は減少する。Ｒ’nがトランスレートされた（出力）ビデオストリームｎの速度を示すものとする。可能なビデオの最高画質を維持するには、ｆnの組が存在し、（１９）の制限のもとですべてｎに対して次の式が成立するように速度低減の最少量を適用しなければならない。
【０１３７】
【数２２】
2007184913.tif 000023
【０１３８】
ジョイントコーディング（ジョイントトランスコーディングの代わりの）の場合、目標は式（１９）の制限のもとで式（２１）に対する解を単に見つけることである。ここでＲ’nはエンコーダの出力ストリームｎの速度レートを示す。
【０１３９】
一般に、一組の時間部分ｆnの組を決定する問題はより制限の少ない問題である。上記関係はユニークな解を与えるものではない。当然ながら、目的は組み合わせたすべてのビデオストリームの全件の画質のある尺度を最大にするような、この問題に対する解を見つけることである。
【０１４０】
一実施例は、ジョイントコーディング原則に基づくものであり、この原則では全般的に均一な画質を得るように、異なるビットストリームのビットレートが相対的なコーディングの複雑度に基づいて変化することが許容される。このアプローチは、ジョイントコーディングされたビデオストリームの最低品質を最高にする、すなわち、このアプローチは、歪み基準（５）を最小にしようする。
【０１４１】
同じサイズＮGのＧＯＰで各ストリームがＭＰＥＧ−２コード化されたＮLビデオストリームを考えることができる。時間的に同時に発生する一組のＮL個のＧＯＰS（各ストリームから１つずつ）を考えることもできる。スーパーＧＯＰとも称されるこの組はＮLｘＮG個のビデオフレームに属している。一部のビット割り当て技術における第１ステップは、スーパーＧＯＰ内の各ＧＯＰにターゲット数のビットを割り当てることであり、この場合、各ＧＯＰは異なるストリームｎに基づく。スーパーＧＯＰ内の各ＧＯＰの相対的複雑度に比例して割り当てが実行される。ビット割り当て手順における第２ステップは、各ビデオストリームのＧＯＰの各フレームにターゲット数のビットを割り当てることである。
【０１４２】
ＴnはストリームｎのＧＯＰ（スーパーＧＯＰ内の）に割り当てられたビットのターゲット数を示すものとし、Ｓn，tはビデオストリームｎのフレームｔに対し、エンコーダ／トランスコーダによって発生されたビット数を示すものとする。一連のＧＯＰにわたってストリームｎに対して発生されたビットの総数は、次の式で示されるＴnに等しいか、それに近い値でなければならない。
【０１４３】
【数２３】
2007184913.tif 000024
【０１４４】
ＭＰＥＧ−２  ＴＭ５におけるように、フレームに対するコーディングの複雑度の尺度が使用される。それは次の式で示されるような、使用される量子化値とそのフレームに対して発生されるビット数との積である。
【０１４５】
【数２４】
2007184913.tif 000025
【０１４６】
したがって、式（２２）は次のように書き直すことができる。
【０１４７】
【数２５】
2007184913.tif 000026
【０１４８】
式（１４）のように、一般的に、一定画質アプローチが使用される。すべての量子化値は画像タイプ（Ｉ、ＰおよびＢ）の差およびストリームの優先度ｐｎを考慮した一定係数Ｋｎ，ｔの値に等しくできる。従って、式（２４）を次のように書き直すことができる。
【０１４９】
【数２６】
2007184913.tif 000027
【０１５０】
式（２１）を満たすために次の式が成り立つ。
【０１５１】
【数２７】
2007184913.tif 000028
【０１５２】
式（２５）と（２６）と（１９）とを組み合わせると、ｎ個の未知数の組に対する次の解ｆｎ（Ｑの構成要素）が得られる。
【０１５３】
【数２８】
2007184913.tif 000029
【０１５４】
チャンネルは最大容量まで利用されると仮定する。すなわち、チャンネル利用率の合計は、正確に１.０まで増加する。利用率を１.０よりも低い値まで増加しなければならない場合、このアプローチはまだ有効であることに留意されたい。式（２７）は、これを許容するように追加ファクタにより簡単に変更される。例えば、チャンネル容量の一部を消費するネットワーク内でアクティブなＡＶでないストリームが存在するかもしれない。ＡＶでないストリームの場合、かかるストリームに対し一部の容量を設定しなければならず、上記合計を１.０よりも下げることにより、ＡＶストリームの速度の最適化はこれを考慮しなければならない。
【０１５５】
ｆnを決定した場合、式（２６）により、各ＧＯＰに対する実際のターゲットレートを計算できる。
【０１５６】
上記のように、ビット割り当てにおける第２のステップは、各ビデオストリームのＧＯＰの各フレームに対し、ターゲット数のビットを割り当てることである。このことは、ＴＭ５で提供されているような現存のビット割り当て方法を使って達成できる。その後のコーディングまたはトランスコーディングは、標準的な方法、この場合、ＭＰＥＧ−２に準拠する任意のエンコーダ／トランスコーダを用いて実行できる（図１２参照）。
【０１５７】
上記方法は、特に無線ＬＡＮのケースに対して考えられたものであるが、上記モデルおよび式は中央ゲートウェイ、サーバまたはアクセスポイントが多数のクライアントデバイスと異なる最大レートで通信できるようになっている他の任意のタイプのＬＡＮまたはネットワークに対しても成立することに留意すべきである。上記記載では、コーディングの複雑度の尺度Ｃを使用する簡単な速度−歪みモデルを使用したが、チャンネル利用率ｆの最適な組を決定するのに同じように、他の速度−歪みモデルも利用できる。
【０１５８】
ダイナミックな速度の適応化のケースでは、最大スループットレートＨｎは時間と共に変化する。この場合、上記方法は多数のＡＶストリームのバーチャルＧＯＰからなり、時間的にオーバーラップするバーチャルＧＯＰまたはバーチャルスーパーＧＯＰの概念と組み合わせることができる（図１３参照）。特定のストリームｎのバーチャルＧＯＰにターゲット数のビットを割り当てるために、フレーム時間ごとに式（２７）が実行される。その後、例えば、式（３）を使って、各バーチャルＧＯＰ内の各フレームに対するターゲット数のビットを割り当てなければならない。
【０１５９】
更に、上記方法は、ＧＯＰを使用しないケースで使用できること、すなわち、例えばＧＯＰごとではなく、フレームごとの方式で上記方法を使用できることに留意されたい（図１４参照）。例えば、Ｐタイプの画像だけを検討し、速度制御をフレームごとに実行するケースがあり得る。この場合、異なるビデオストリームから同時に生じるＮL個のフレームの組からの個々のフレームにビットを割り当てる必要がある。上記方法は、全てのストリームからのフレームの組内の各フレームの相対的コーディング複雑度に従って、各フレームに対し、ターゲット数のビットを割り当てるのにも使用できる。
【０１６０】
一実施例は、図７に示されるような、単一ストリームのシステムを使用するものである。この単一ストリームのシステムは単一のアナログＡＶソースを有する。デジタル圧縮されたビットストリーム、例えば、ＭＰＥＧ−２またはＭＰＥＧ−４のビデオストリームを発生するＡＶエンコーダを含む処理モジュールにアナログＡＶソースが入力される。このビットストリームのビットレートは、チャンネルの条件にダイナミックに適合される。このＡＶビットストリームはチャンネルを通して送信される。送信機と受信機との間の接続は、厳密に、ポイントツーポイントの接続であり、受信機はデジタル圧縮されたビットストリームをデコードするＡＶデコーダを含む。
【０１６１】
別の実施例は、図８に示されるような、単一ストリームのシステムである。この単一ストリームのシステムは単一のデジタルＡＶソース、例えば、ＭＰＥＧ−２またはＭＰＥＧ−４ビットストリームを有する。このデジタルソースは第２デジタルビットストリームを出力するトランスコーダ／トランスレータを含む処理モジュールに入力される。このビットストリームのビットレートは、チャンネルの条件にダイナミックに適応される。このＡＶビットストリームは、チャンネルを通して送信され、送信機と受信機との間の接続は、厳密に、ポイントツーポイントであり、受信機はデジタル圧縮されたビットストリームをデコードするＡＶデコーダを含む。
【０１６２】
別の実施例は、図９に示されるような、マルチストリームシステムである。このマルチストリームシステムは、多数のＡＶソースを有し、ここではアナログのソースもあれば、デジタルフォーム（例えばＭＰＥＧ−２またはＭＰＥＧ−４のビットストリーム）のソースもある。これらＡＶソースは０以上のエンコーダ（アナログ入力）だけでなく０以上のトランスコーダ（デジタル入力）を含む処理モジュールに入力される。各エンコーダおよび／またはトランスコーダは、対応する出力ビットストリームを発生する。これらビットストリームのビットレートは、チャンネルの条件にダイナミックに適合され、すべてのストリームの全体の品質を最適にする。このシステムは、受信デバイスの能力に関する情報に基づき、これらストリームを適応させることもできる。システムは各ユーザーの好みに関する情報に基づき、ストリームを適応させることもできる。すべてのコード化され／トランスコードされたビットストリームは、ネットワークアクセスポイントへ送られ、アクセスポイントは各ビットストリームを対応する受信機へ送る。各受信機は、デジタル圧縮されたビットストリームをデコードするＡＶデコーダを含む。
【０１６３】
チャンネルバンド幅推定
システムの実現例は、ある態様でバンド幅を推定できる。現存のバンド幅推定モデルは、相互接続されたノードの分散ネットワーク、例えば、インターネットのネットワーク容量の推定値に主に基づいている。一般に、相互接続されたノードは多数存在し、各ノードは異なるバンド幅容量を有し得る。比較的高速のノードを通して送信されるデータパケットは、比較的低速ノードを通した送信をするために待ち状態となり得る。通信ネットワークのボトルネックとなるバンド幅を推定しようとするために、サーバからボトルネックリンクを通し、クライアントに一連のパケットを送信できる。受信したパケット間の時間間隔を計算することにより、クライアントはボトルネックノードのバンド幅を推定できる。従って、データパケットを送信する際に通過する多くのネットワーク接続内の比較的低速のネットワーク接続によって、パケットの時間間隔が生じる。この時間間隔は比較的短い時間フレームで、例えば、１秒未満でネットワークバンド幅の変化の割合を測定するものではなく、むしろ周期的に、例えば、数分ごとに測定したときのネットワークボトルがどのリンクであるかを測定するものである。更に、物理的ボトルネックノードは分散ネットワーク例えばインターネットを横断するトラヒックが変化する際に、時間に対して変化する傾向がある。
【０１６４】
分散型ネットワークのバンド幅を推定するための他の技術は、特に、ネットワークのバンド幅を推定するために多量のテストデータを発生することである。不幸なことに、かかるテストデータはテスト期間中に他のデータに対して利用できるバンド幅を大幅に低下させるという点で、オーバーヘッドを大きくしてしまう。多くのケースでは、テストデータはオフラインで分析されるが、この方法では、テストトラヒックすべてを送受信した後で推定値を計算する。かかるテストデータの使用は、時間に影響されないネットワークアプリケーションに対して有効となり得るが、ネットワークバンド幅の時間的中断が望ましくない環境およびリンクバンド幅に関する情報が実質的に連続して、かつ、リアルタイムで必要とされる環境では適当でない傾向がある。
【０１６５】
インターネットを通したオーディオおよびビデオのストリーミングは、比較的低いビットレート（６４〜５１２Ｋｂｐｓの範囲で）と、比較的高いパケット損失率（１０％までの損失率が一般に許容可能と見なされる）および比較的大きいパケットジッター（パケットの到達時間の変動）を特徴とすることに留意すべきである。かかるビットレートを用いた場合、バンド幅の一般的な測定は受信機側でパケットの損失量および／またはパケットジッターを測定し、その後、測定したデータを送信機へ送り戻すことから成る。この技術は、大きなパーセントのパケット損失が許容可能であることを前提とし、パケットの損失量を最小にするかまたは除去しようとするのではなく、パケットの損失量を管理しようとするものである。更に、かかる技術は、より高いビットレートのアプリケーション、標準品位のビデオに対するは６Ｍｂｐｓまたは高品位ビデオに対するは２０Ｍｂｐｓで高品位ビデオをストリーミングすることに必ずしも直接適用可能なものではない。
【０１６６】
システムが送信機から受信機へのトラヒックを追加プロービングをしないようにシステムを実現できる。このように、送信機によってネットワークバンド幅に追加的な負荷が加えられることはない。受信機から送信機への限られた量のネットワークトラヒックは、ネットワークトラヒックをモニタする機構として使用できるフィードバックを含むことができる。代表的な無線実現例では、プロトコルのＭＡＣ層でのデータの送信、フィードバックおよび再送信がある。ＭＡＣ層では、バンド幅利用のためのネットワークモニタリングを実行できるが、本明細書に記載のシステムの一の実現例は好ましいことにＡＰＰＬＩＣＡＴＩＯＮ層でネットワークのモニタリングを行っている。アプリケーション層を使用することにより、実現例は特定のネットワークの実現例にあまり依存しなくなり、より広い範囲のネットワークで使用できる。バックグラウンドとして、多くの無線プロトコルシステムは物理層、ＭＡＣ層、トランスポート／ネットワーク層およびアプリケーション層を含む。
【０１６７】
最適な解を検討するとき、（１）どのパラメータを測定するか、（２）送信機でパラメータを測定すべきか、受信機で測定すべきか、および、（３）モデルをベースとするアプローチ（システムがどのようにふるまうかのモデルを有する）かプローブをベースとするアプローチ（より多数のデータを送り、システムがいつブレークダウンするかを見て、次により少ないデータを送り、システムがブレークダウンするまでデータを増加するようにする）のどちらを使用すべきかをよく考えなければならない。モデルに基づくアプローチでは、送信されるストリームのより正確な調節を行うことができるので、利用できるバンド幅の最適な利用を実現しやすい。
【０１６８】
受信機でパラメータを測定し、チャンネルを通して送信機へ送ることができる。受信機でパラメータを測定することがシステムに過剰な影響を与えることなく実現できるが、チャネルの使用を増やし、受信機の測定と送信機に情報が到達するまでの間に遅延が生じる。
【０１６９】
ＭＡＣ層
上記とは異なり、送信機でパラメータを送信してもよい。送信機のＭＡＣ層は何をいつ送信したかの情報を有している。送信機のＭＡＣ層は何を受信したか、受信確認を通していつ受信したかの情報も有する。例えば、システムはＭＡＣ層からのデータリンク速度および／またはパケット誤り率（再試行の回数）を使用できる。データリンク速度および／またはパケット誤り率は、ＭＡＣ層、８０２.１１の管理情報ベースパラメータから直接得ることができるし、または、他の方法で得ることもできる。例えば、図１８は、無線送信（または通信）システムのための送信機と受信機との間のデータリンク速度を下げるための失われたパケットの再送信およびフォールバックを示す。
【０１７０】
無線送信システムでは、パケットはＰ個のペイロードビットを搬送する。Ｐ個のビットを有するパケットを送信するのにかかる時間Ｔは、データリンク速度、再試行の回数およびＭＡＣおよびＰＨＹのオーバーヘッドの前の情報（例えば、ヘッダーの競合ウィンドー長さの時間、受信確認を送るためにかかる時間など）を決定すれば、計算可能である。従って、最大スループットをＰ／Ｔ（ビット／秒）として計算できる。
【０１７１】
ＡＰＰＬＩＣＡＴＩＯＮ層
図１９に示されるように、送信機にはパケットが送付され、場合によっては、送信機は再送信しなければならない。受信機は送信機からのパケットを受信し、その後、あるポイントにおいてアプリケーション層にパケットが受信された旨を表示する。パケットの受信は、パケットを正しく受信したレートまたは増減する傾向を表示するのに使用する。この情報は、利用できるバンド幅すなわち最大スループットを決定するのに使用できる。図２０は、送信機でパケットのバーストを形成し、できるだけ迅速にこれらバーストを周期的にチャンネル内に読み込み、システムのスループットを測定することに基づくアプローチを示す。このプロセスを周期的に繰り返すことにより測定リンクの最大スループットを測定できるが、データの有効スループットは最大値よりも低くてよい。
【０１７２】
図２１を参照する。利用できるバンド幅を推定するための技術は、送信機から受信機へ送られる単一のトラヒックストリームに基づくことができる。この単一のトラヒックストリームは、例えば、オーディオデータおよびビデオデータを含むパケットから構成できる。図２１に示されるように、ここにはネットワークリンクの理想的条件における時間に対する成功したパケットの５回の送信の組が示されており、ここで、Ｔｘは送信機であり、Ｒｘは受信機である。図２１は、要約されたモデルを示し、ここでは実際の送信は受信機から送信機へ送られる受信確認およびデータのフレーム内間隔（８０２.１１規格に規定されているような）を含むことができる。一定のビットレートを有する実際のビデオデータストリームでは、パケットは時間的に均一に離間され、ここではデータパケット間の時間インターバルは一定であり、ビデオストリームのビットレートおよび選択されたパケットのサイズによって決定される。
【０１７３】
図２２を参照する。ここには、理想的でない条件下の５つのパケットのシーケンスが示されている。アプリケーションがパケットのうちの一部を送信した後に、送信機はパケットの一部を再送信する。その理由は、それら再送信されるパケットが受信機によって正しく受信されなかったか、不正確であったか、または、送信機によって受信確認が受信されなかったからである。パケットの再送信はアプリケーション層が事象について気づかないように無線送信システムのうちの他のプロトコル層で自動的に行われる。図２２に示されるように、受信機によって最初の２つのパケットが正しく受信される前に、最初の２つのパケットが１回再送信される。パケットを再送信する必要がある結果、システムは自動的により低速のデータ速度に戻り、より低いビットレートを使って各パケットが送信される。８０２.１１ａの仕様は、データリンク速度６、９、１２、１８、２４、３６、４８または５４Ｍｂｐｓで作動でき、８０２.１１ｂ仕様は１、２、５.５または１１Ｍｂｐｓで作動できる。このようにしてパケットを再送信する必要性が軽減または解消される。
【０１７４】
図２３を参照する。本発明者たちは矢印に示されるアプリケーションから送信すべきパケットの送信を検討した。観察されるように、アプリケーションには分からない１回の再送信が存在し、更に、同じように、アプリケーションには分からないビットレートの２回の変更がある。アプリケーションは送信すべきパケットの送信回数しか知らない。受信機のアプリケーション層へのパケットの到達は矢印で示されている。パケットは、離間したインターバルで到達するが、受信機上のアプリケーションは、行われた可能性のある再送信については知らない。しかしながら、判断できるように、最大有効バンド幅が図２３に示されるパケットの送受信に基づくものであることを識別することは困難である。
【０１７５】
困難なことを検討した後に、本発明者たちはビデオの平均ビットレートに対し、バンド幅を利用可能であると効果的に評価するには、送信機がパケットを受け入れるのと同じ速さで、さもなくはば、パケットが送信機に提供される通常の速度と比較して、パケット間に実質的な間隔無しで、送信機にパケットのグループを提供しなければならないと判断した。図２４を参照すると、パケットのバーストは、複数であることが好ましく、３つ以上であることがより好ましい。その後、送信機から無線ネットワークを通して受信機へパケットが送信される。受信機では、各バーストにおける個々のパケットの到達のタイミングが定められる。
【０１７６】
多くのケースでは、無線ネットワークを通したパケットの送信は最大データレートよりも低い平均データ速度で行われる。従って、送信機は送信のために受信した複数のパケットを一時的に蓄積できる。データパケットは例えばパケットが一定ビットレートで作動中のビデオエンコーダまたはトランスコーダから着信した場合、システムの送信機部分に一定のインターバルで到達できる。送信機は蓄積したパケットをバーストとして、すなわち、最大送信速度で送信することを試みることができる。送信機は所望するように追加バーストを形成するために、パケットの追加グループを蓄積し続けることができる。
【０１７７】
かかるバーストでパケットを送る望ましい結果は、システムの全スループットがストリーミングビデオのターゲットビットレートにほぼ等しくなることである。次の３つのパラメータを制御することにより、有効スループットＥを変更できる。
（１）パケットサイズ（例えば、バイトの数を単位とする）または各パケットのデータペイロードのサイズ、および／または、
（２）パケットの各バースト内のパケット数および／または
（３）パケットのその後のバースト間の時間インターバル。
例えば、ペイロードサイズが１４７２バイトであり、バースト内のパケット数が１０であり、バースト間の時間インターバルが４０ミリ秒である場合、有効スループットは１０（バースト当たりのパケット数）×１４７２（パケット当たりのバイト数）×８（バイト当たりのビット数）／０.０４０（バースト当たりの秒）＝毎秒２，９４４，０００ビット、すなわち、約２.９Ｍｂｐｓとなる。従って、無線接続を使用するレートで２.９Ｍｂｐｓのビットレートを有するオーディオビジュアルストリームをストリーミングできる。これらパケットは実際のビデオ信号であり、ネットワークに課される単なる追加テストトラヒックではないことが判断できる。更に、システムは、平均データ速度が（１０％内で）ビデオビットレートに一致するように、逐次パケットバーストを送信できる。このように、システムは平均ビデオ速度を変えないまま、利用可能なビデオバンド幅の連続測定をすることができる。
【０１７８】
システムの有効スループットは、チャンネルがサポートできるバンド幅あるいは最大スループットよりも常時小さく（または、等しく）なる。バンド幅または最大スループットはＴと表示できる。例えば、理想条件では、ＤＣＦモードの８０２.１１ｂリンクは、ペイロードサイズがパケット当たり１４７２バイトであり、基礎となるリンク速度が１１Ｍｂｐｓの場合、約６.２Ｍｂｐｓの最大スループット（バンド幅）をサポートできる。理想的でない条件では、再送信またはリンク速度の低下に起因し、この最大スループットまたはバンド幅は低下する。当然ながら、有効スループットは決して最大スループットを上回ることはできない。図２４には、理想的状況が示されており、図２５には、非理想的状況が示されている。図２４のケースでは、チャンネルは実際にＴ＝ＴAＭｂｐｓの最大スループットまでのより大きいスループットを実際にサポートできる。すなわち、ＥS＜ＴAであり、追加トラヒックのためのスペースがある。図２５に示されるケースでは、基礎となるＭＡＣがデータストリーム内のパケットを送信するのにチャンネルの容量の多くを使用し、追加トラヒックにはあまり余裕がないので、最大スループットは低下する。この場合の最大スループット、すなわち、Ｔ＝ＴBは、図２４に示されたケースよりも低くなる。すなわち、ＴB＜ＴAである。まだ、有効スループットをサポートでき、同じようにＥS＜ＴBが成り立つ。
【０１７９】
必要な場合に、オーディオ／ビデオストリームのバンド幅に適応するための正しい情報を送信機に提供する（もし必要ならば）のに推定されるのは、最大スループットまたはバンド幅Ｔである。パケットのバーストの送信中に一時的ではあるが最大スループットが達成される。従って、１つのバースト中に送信されるビット数とそのバーストの継続時間との比を計算することにより、最大スループットが推定される。より正確には、受信機に到達するＮ個のパケット（Ｎ≧２）のバーストを検討する。ここで、そのバースト内のパケットｉ、１≦ｉ≦Ｎは時間ｔi（秒）に到達する。受信機では、送信のために送信機がネットワークに第１パケットを送った時間については知らない場合がある。図２４および２５に示されるように、バーストの第１パケットの到達から、最終パケットまでの間の時間間隔Δｔ＝ｔN−ｔ1の間に、ネットワークはパケット２からＮ（第１パケットを除くバースト内の全てのパケット）を送信するのにビジーである。バースト内の各パケットは同じペイロードのＰビットを搬送すると仮定した場合、間隔Δｔ中に送信されるビット数は、Ｐ*（Ｎ−１）ビットとなる。従って、このバースト時の最大スループットまたはバンド幅は次の式で示される。
【０１８０】
【数２９】
2007184913.tif 000030
【０１８１】
より一般的には、バーストｊに対する最大スループットまたはバンド幅をＴｊで表示することができる。バーストｊの間のパケットのペイロードは、Ｐj（バースト中の全てのパケットは同じペイロードを有する）である。バーストｊ内のパケット数はＮjであり、バーストｊ内のパケットｉの到達時間はｔj，iであり、バーストｊに対して測定される時間インターバルは、Δｔj＝ｔj，N −ｔj，1 となる。
【０１８２】
送信機でパケットペイロード内に時間スタンプを埋め込めば、送信機側で測定される時間スタンプを受信機が利用することができることに留意されたい。パケットペイロードは、パケットシーケンス番号も含むことができる。パケットペイロードは、バーストシーケンス番号も含むことができ、パケットの損失を検出するために受信機によってかかるシーケンス番号を使用できる。パケットペイロードはパケットがバースト内の最初のパケットであることを示すフィールドおよび／またはパケットがバースト内の最終パケットであることを表示するフィールド、および／またはパケットがバースト内の最初のパケットでもなければ最終パケットでもないことを表示するフィールドを含むこともできる。
【０１８３】
ハードウェア／ソフトウェアプラットフォームの内部のクロックにより、タイムスタンプまたは時間の測定値およびタイムインターバルを提供することができる。異なるハードウェア／ソフトウェアプラットフォームは異なるＡＰＩを提供でき、クロックの分解能（または細分性）によって、異なる性能のクロックをサポートできる。例えば、ライナックスプラットフォームではgettimeofdayのＡＰＩを利用できる。これはマイクロ秒の分解能で時間の値を提供する。別の例として、ウィンドウズ２０００／ウィンドウズＸＰプラットフォーム（Ｗｉｎ３２ＡＰＩ）では、GetTickCount および QueryPerformanceCounterのＡＰＩを利用できる。後者のＡＰＩは、サブミリ秒の分解能を有する時間値を検索するのに使用でき、QueryPerformanceCounterのＡＰＩで提供される時間値の実際の分解能は、ハードウェアによって決まる。例えば、この分解能は、２つの異なるウィンドウズ２０００のラップトップパソコンでマイクロ秒の分解能よりも良好であることが判っており、より新しいＸＰデスクトップパソコンでナノ秒よりも良好であることが判っている。
【０１８４】
進行しながら、すなわち、１回より多い回数、バンド幅測定を行うことができる。バーストの送信中に利用できるバンド幅を推定するのに、オーディオ／ビデオデータのストリーミング中のデータパケットのどのバーストも使用できる。受信機で実行されるかかる測定値は送信側に送り戻される。
【０１８５】
２台のウィンドウズ２０００のラップトップパソコン（双方にはＩＥＥＥ８０２.１１ｂのＷＬＡＮクライアントカードが装備されている）で作動するソフトウェアを使ってテストセットアップを実行した。これらラップトップパソコン上のこれらＷＬＡＮカードは８０２.１１のアドホックモードで通信するように構成されており、ＩＰプロトコルの設定は２台のラップトップによるプライベートネットワークを形成するように構成されていた。１つのパソコンで作動するソフトウェアは、サーバとして作動し、ネットワークを通し、ＵＤＰ、ＩＰおよび８０２.１１ｂプロトコルを使う受信機へパケットを送信した。ＵＤＰはリアルタイムのトラヒックにより適しているので、ＴＣＰの代わりに使用できることに留意されたい。システムは他のプロトコル、例えば、パワーライン通信ネットワークまたは他のＬＡＮも使用できることに留意すべきである。
【０１８６】
最初の例は、一般的な理想的なケースにおける８０２.１１ｂのスループット性能を示し、ここではラップトップパソコンは互いに接近しており、外部ソースからの妨害波も最小にされた。８０２.１１ｂカードは最大の１１Ｍｂｐｓリンク速度で通信するように構成されていた。パケットペイロードは１４７２バイト（８０２.１１のＭＡＣが１５００バイトのパケットを送るように、ＵＤＰおよびＩＰにより追加の２８バイトが使用される）で一定であった。各実験では、１００個のバーストを送信した。この例では、各バーストは１０パケットから成り、次のバーストとの時間間隔は４０ｍｓとなるようにスケジュールされた。従って、このケースにおける有効スループットは約２.９Ｍｂｐｓである。
【０１８７】
図２６には、理想的な条件に対する結果が示されている。他の測定から、このケースにおける最大スループット／バンド幅は平均６.２Ｍｂｐｓであることが判った。バンド幅は６.２Ｍｂｐｓの値の前後で変化し、１００バーストを越えたときの平均値は６.２４Ｍｂｐｓであり、標準偏差は０.２２Ｍｂｐｓであることに留意されたい。１００バーストを越えたときの平均値は期待値に極めて近く、標準偏差は相応に小さい。変動を取り扱う方法については次の章で説明する。
【０１８８】
第２の例は、一般的に非理想的な条件における８０２.１１ｂのスループット性能を示し、ここではラップトップコンピュータは、多くの小区画に仕切られた屋内環境で送信機と受信機との間には数個の壁があり、４３ｍ離して設置された。他のすべてのパラメータは第１の例と同じであった。
【０１８９】
図２７には、理想的でないケースに対する結果が示されている。このケースにおける最大スループットはかなり低く、１００個を越えるバーストに対する平均は３.３Ｍｂｐｓである。１００個を越えるバーストに対する標準偏差はかなり大きく、１.２０Ｍｂｐｓである。図は、低下したスループット性能および性能における変動の増加を示す（垂直軸は、図２６及び図２７とは異なるスケールとなっていることに留意されたい）。
【０１９０】
この第２例から、測定されたバンド幅の値における変動は、バンド幅を直接推定する別の方法として、オーディオ／ビデオストリーミングシステムにおいて、フィードバックとして使用するのにそれ自体有効なパラメータとなり得る。
【０１９１】
ロバストネス
バンド幅の測定値は、図２６および２７に示されるように、ほとんどの条件において時間的な変動を受ける。一般に、ノイズと称されるこれら変動のあるものは、無線放送に関しては意味がない。誤りの１つの原因は、パケットの到達時間を測定するのに使用されるクロックの（限られた）分解能によって生じるものと判断された。かかる誤りが存在する場合、送信機のオーディオ／ビデオエンコーダで速度適応化機構への入力として使用できる（瞬間的な）バンド幅のロバストな推定値を提供することが望ましい。
【０１９２】
バースト内のパケット数とバンド幅推定値のロバストネスとの間の兼ね合いが存在する。バースト当たり、より多数のパケットを使用することにより、バンド幅の推定値のロバストネスを高めることができる。例えば２つを越えるパケットを有するバーストを使用すると、測定クロックの限られた分解能の効果が少なくなる。しかしながら、バースト当たりのパケット数を増加することは、送信機におけるバッファサイズを増加させなければならず、その結果、実現のコストが高くなり、送信遅延時間が長くなる。
【０１９３】
図２６および図２７に示された例は、１０個のパケットのバーストサイズを想定したが、適当な数のパケットを使用してもよい。パケットの数が実現可能な最大値まで増加する際に、バンド幅の推定における時間的変動のあるものは、一般に、同じままである。変動を減少するのに、バンド幅の推定または測定された時間インターバルのいずれかの処理を使用できる。バンド幅の最終推定値を計算するのに、処理技術を適用できる。
【０１９４】
インターネットのボトルネックバンド幅を測定するのに適用できる従来の技術は、一組のバンド幅推定の周波数分布（ヒストグラム）を使用し、最終バンド幅推定値として、その分布の平均値、メディアン値またはモードのいずれかをとる。このアプローチは、データを先ず収集し、その後で処理すべき一組のデータであるとみなすことに基づいている。しかしながら、本発明者は、ＷＬＡＮにおけるリアルタイムのバンド幅推定に対してかかる技術は、適当でないと判断した。かかる技術が不適当であると本発明者が判断した主な理由の１つは、有意な周波数分布を形成するのに十分なバンド幅サンプルを収集するのに数秒かかることである。しかしながら、無線ネットワークによるビデオの場合、チャンネルはより小さい（サブ秒の）時間スケールでの変動を受けるから、システムはこれら変動により速く応答できなければならない。
【０１９５】
このような組をベースとする前提の制限を克服するために、本発明者は、収集し、その後、処理すべきデータの組としてデータを見るのとは異なり、測定サンプルのシーケンシャルな組としてデータを分析しなければならないと判断した。このように、データの時間的な性質が重要となる。データを時間シーケンスのような測定サンプルの組として、すなわち、離散的な時間信号として処理できる。従って、異なる順序でサンプルを受信した場合、その結果生じる出力は異なる。測定サンプルは時間的に等しい距離に離間していると仮定した場合、ノイズの多い変動を除去するのに、次の技術を含むが、これらだけに限定されない種々の信号処理技術も使用できる。
（１）ＦＩＲフィルタリング。有限数のフィルタタブを用いた非再帰フィルタリングである。１つの例として、移動平均フィルタを挙げることができる。図２６および図２７は、バンド幅測定サンプルのシーケンスへの１０タブ移動平均フィルタの効果を示す。
（２）ＩＩＲフィルタリング。有限数のフィルタタブを有する再帰フィルタリングである。１つの例として、一次再帰フィルタを挙げることができる。このフィルタは新しい推定値を計算するのに、前の推定値を現在の測定サンプルで重み付けする。図２６および図２７は、バンド幅測定サンプルのシーケンスに対する一次ＩＩＲフィルタの効果を示す。
（３）統計的処理。例えば、平均二乗誤差（ＭＳＥ）推定、最大事後（ＭＡＰ：maximum a posteriori）推定、ウィーナーフィルタリング、カルマンフィルタリングがある。統計的処理は、同時にサンプルをフィルタリングし、将来の値を予測できるので、特に便利なフレームワークを提供できる。予測を行うことは重要である。何故なら（近い）未来に送信されるオーディオ／ビデオデータの速度を制御するのに、測定の結果が使用されるからである。
（４）曲線はめ込み。直線、スプラインおよびその他の曲線をはめ込むことにより、ノイズの多いデータサンプルから補間、近似および外挿が可能となる。測定サンプルが時間的に等距離に離間していない場合、曲線はめ込み方法が特に有効である。
【０１９６】
これら方法の各々では、バーストｊでのバンド幅に対する最終推定値を計算するための追加処理は、過去からの限られた数のバンド幅サンプルＴm，ｊ−Ｍ1≦ｍ≦ｊを使用でき、過去からの限られた数の最終バンド幅推定値Ｔ*m，ｊ−Ｍ2≦ｍ≦ｊ−１も利用できる。一実施例は、例えば次のような一次のＩＩＲタイプのフィルタを利用できる。
【０１９７】
【数３０】
2007184913.tif 000031
【０１９８】
ここで、ｗは０から１の間のパラメータである。例えばｗ＝０.５である場合、バーストｊでのバンド幅の最終推定値はバーストｊ−１におけるバンド幅の最終推定値と、バーストｊに対する現在のバンド幅サンプルとを等しく重み付けすることによって計算される。パラメータｗはバンド幅サンプルに適用されるスムーズ化または平均化の量を制御し、このスムーズ化の量はｗが小さいときに大きくなり、ｗが大きいときにスムーズ化の量は小さくなる。次の式で示されるパラメータ
【０１９９】
【数３１】
2007184913.tif 000032
【０２００】
は一定に保持できるが、これとは異なり、このパラメータを適応的に変えることもできる。このような技術は、図２６および２７の例に使用された。ここでＷの値は０.１である。
【０２０１】
バンド幅サンプルＴｊをフィルタリングまたは処理する代わりに、
【０２０２】
【数３２】
2007184913.tif 000033
【０２０３】
を使用してバンド幅の値を計算する前に、測定された時間インターバルΔｔjをフィルタリングまたは処理することもできる。この場合、過去からの測定された時間インターバルのサンプルΔｔm，ｊ−Ｍ1≦ｍ≦ｊを利用できるだけでなく、過去からの限られた数の処理された時間インターバル推定値Δｔ*m，ｊ−Ｍ2≦ｍ≦ｊ−１を使って、バーストｊに対する代表的時間インターバルの最終推定値Δ*ｔjを計算できる。次に、時間インターバルのこの最終推定値を使用し、バーストｊでのバンド幅の最終推定値Ｔ*jを計算することもできる。１つの例は、次の式で示される測定された時間インターバルに対してＩＩＲフィルタリングを使用することである。
【０２０４】
【数３３】
2007184913.tif 000034
【０２０５】
かかるフィルタリング、推定および予測技術により、最終推定値を迅速に提供でき、のノイズのある変動の適当な量をフィルタリングで除去することが可能である。
【０２０６】
受信機での測定結果は送信機に送信し戻される。送信機はこのフィードバック情報を使って送信されるオーディオ／ビデオ、特にその速度を適応させる。受信機から送信機へ送信されるフィードバックは受信機が計算した（瞬間的な）バンド幅／最大スループットの推定値を含むことができる。更に、最終推定値を計算するのに送信機が使用できる生の測定結果または部分推定値を含むこともできる。更に、推定値を計算した時間を表示するタイムスタンプおよびパケット番号、または、パケットバースト番号を表示するシーケンス番号を含むこともできる。フィードバック情報は、受信機がパケットの損失を検出したかどうかの表示も含むことができる。
【０２０７】
オーディオ／ビデオデータを搬送する同じネットワークリンクを使用し、送信機にフィードバック情報を送り戻すことができる。特に、フィードバック情報を有するパケットを送信機から受信機へのオーディオ／ビデオデータを有するパケットバーストの送信の間で送信できる。かかるフィードバックパケットは、周期的に、例えば、オーディオ／ビデオパケットのバーストごとの後、または、各Ｋ個のバーストの後、または、好きなときにいつでも、例えば、バンド幅の性能が大きく変化した場合に限り送ることができる。フィードバックパケットは、送信に利用できるバンド幅の小さい部分しか使用しない。このオーバーヘッドは送信機がタイムリーに反応できるようにしながら、最小すなわち小さく維持しなければならない。かかるフィードバックパケットにおける情報量は、オーディオ／ビデオデータと比較して極めて小さいので、バンド幅のオーバーヘッドは極めて小さい。更に、送信機はこのオーバーヘッドが小さいことを考慮して、バンド幅割り当ておよび適応化方針を決めることができる。
【０２０８】
図２８Ａを参照すると、ここには受信機の一例のフローチャートが示されている。受信機はパケットバーストｊを受信し、パケットの損失を判断し、パケットの到達を測定する。次に、受信機はバーストｊに対するバンド幅サンプルを計算する。その後、受信機は前のパケットのバンド幅を取り込むことにより、バーストｊに対する最終バンド幅推定値を計算する。最終バンド幅を推定した後に、受信機はこのバンド幅情報を送信機に送信し戻す。送信機は受信機からの情報に基づき、バンド幅情報およびバンド幅推定値を計算すると理解すべきである。
【０２０９】
図２８Ｂを参照すると、ここには別の受信機の例のフローチャートが示されている。受信機はパケットバーストｊを受信し、パケットの損失を判断し、パケットの到達を測定する。次に、受信機はバーストｊに対する時間インターバルを計算する。その後、前のパケットの時間インターバルを取り込むことにより、バーストｊに対する最終バンド幅推定値を計算する。最終バンド幅を推定した後に、受信機はこのバンド幅情報を送信機に送信する。送信機は受信機からの情報に基づき、バンド幅情報およびバンド幅推定値を計算すると理解すべきである。
【０２１０】
図２９を参照すると、ここには送信機の一例のフローチャートが示されている。送信機は受信機にパケットバーストを送り、次に送信機は受信機からのフィードバックを受信するために予め決定した時間インターバルだけ待機する。フィードバック情報を受信すると、送信機は速度を適合させ、受信機へパケットを送るスケジュールを定める。送信機は受信機からの情報に基づき、バンド幅情報およびバンド幅推定値を計算する。
【０２１１】
図３０を参照すると、無線放送システムは、例えば、ＭＰＥＧフォーマットのように、入力ビデオ３００を含んでいる。ＭＰＥＧトランスコーダ３１０には入力ビデオ３００が与えられ、トランスコーダは１つ以上のビデオストリームに対する所望するデータ送信速度にビデオビットレートを適応させる。速度を減少させた（または増加させた）ＭＰＥＧビデオ３２０は、パケッタイザーおよびパケットスケジューラ３３０にが与えられる。このスケジュールはチャンネルを通した送信のためのパケットのスケジュールを定め、利用できるバンド幅よりも一般に低く留まるように、データ送信速度を適合させる。無線ネットワーク３５０には、多くの場合、“バースト”状になっているビデオパケット３４０が提供される。無線ネットワーク３５０からのデータは、デパケッタイザーおよびバンド幅推定器３６０によって受信される。推定器３６０は無線ネットワーク３５０へバンド幅推定値および損失フィードバック３７０を提供し、ネットワークは次にスケジューラ３３０へデータ３８０を提供する。データ３８０はＭＰＥＧトランスコーダ３１０に提供されるターゲットビデオビットレート３９０を決定するのに使用される。推定器３６０の出力はＭＰＥＧデコーダ３９５へ与えられる。
【０２１２】
図３０に示されたシステムに対して、バンド幅は、前に述べたように、または特定時間において“より低い”ネットワーク層により、オーディオ／ビデオアプリケーション層へ提供される最大スループットとして定義される。オーディオ／ビデオデータを送信するのに利用できる最大スループットまたはバンド幅は、時間的に変化するＨで表示でき、送信速度はＳで表示され、送信側がネットワークへデータを送る速度によって定義される。有効スループットはＥで表示でき、更に、送信機と受信機との間で特定時間に実現されるオーディオ／ビデオデータの一切のスループットによって定義できる。
【０２１３】
有効スループットは特定時間における最大スループットまたはバンド幅を越えることができないことが理解できよう。すなわち、Ｅ≦Ｈ。チャンネルの所定の最大スループットが例えばＨ＝ＨA  Ｍｂｐｓの場合、送信機は、パケットを損失することなくタイムリーに受信機にすべての送信データが到達することを保証するよう、ＨAよりも低いレート、例えばＳ＝ＳAで送信機はデータを送信する。かかるケースでは、有効スループット、例えばＥ＝ＥA  Ｍｂｐｓは、送信速度ＥA＝ＳA ≦ＨA に等しい。
【０２１４】
送信速度がバンド幅よりも高いと仮定した場合、送られるデータの一部が失われるか、または到達が遅れる。例えば、ＳA ≧ＨA＝ＥAとなる。従って、送信機の１つの特徴は、すべての時間または多くの時間でＥ＝Ｓ≦Ｈとなることを保証することである。送信機はオーディオ／ビデオデータパケットの送信のスケジュールを適切に定めることにより、送信速度を制御する。送信機の別の特徴は、発生されるビデオのビットレート、すなわちＲ’が送信速度に等しくなる（例えばＲ’＝Ｓ）ことを保証することにある。単一ストリームの実施例では、送信機はＲ’＝Ｓ≦Ｈを達成できなければならない。
【０２１５】
一例として、原ビデオストリームのビデオ速度が既にネットワークのバンド幅を下回っている場合、トランスレータは積極的にビットレートを小さくする必要はない。実際にトランスレータは、所望すればビットレートを積極的に大きくできる。性能を最適にするため、送信機はパケット送信速度とビデオビットレートを実質的に一致させ、画質を改善できる。しかしながら、無線ネットワークのバンド幅がビデオビットレートに近づくように充分減少すると、送信機は送信速度およびトランスレータの出力ビットレートの双方をダイナミックに適切に下げることにより、パケットの損失を防止するように反応する。
【０２１６】
前に述べたように、送信機から受信機へデータを送信する１つの技術は、時間ΔＴにわたってパケットサイズＰを有するＭ個のパケットのバーストを使用することである。送信速度を制御するのに変更できる適当なパラメータの組として、例えば次のものを挙げることができる。
（１）パケットサイズ（例えばバイトの数）または各パケットのデータペイロードのサイズ、Ｐ
（２）各パケットバーストにおけるパケット数、Ｍ
（３）次のパケットバーストとの間の時間インターバル、ΔＴ
説明のために、単一バースト内のすべてのパケットは同じペイロードサイズを有すると仮定する。パケットサイズはバーストごとに、更にパケットごとに変えられる。同じペイロードサイズの場合、送信速度Ｓを次のように定義できる。
【０２１７】
【数３４】
2007184913.tif 000035
【０２１８】
パケットのバーストの送信中に一時的ではあるが、最大スループットＨが得られる。
【０２１９】
送信速度を利用できるバンド幅に一致させるように、効果的に適応させることを更に検討した後に、本発明者たちはパケットサイズを効果的に変更するとこにより、大きな利点が得られると判断した。多くのケースでは、実現を簡略にするために、各バースト内のパケットの数Ｍを定数（またはいくつかのバーストの期間中、９０％またはそれ以上）として維持するだけでなく、バーストの間の時間インターバルも定数（いくつかのインターバルΔＴの期間中、９０％またはそれ以上）として維持する。システムはセッションのスタート時にＭおよびΔＴを計算でき、セッションの残りの間一定に維持できるので、速度適応時にこれら値は定数と見なされる。各バースト内のパケット数Ｍおよび／またはバースト間のインターバルΔＴは、所望すればセッション中でも変更できる。
【０２２０】
パケットサイズ（またはペイロードサイズＰ）を変えることにより、送信速度を適応化することは、バースト内のパケット数またはバースト間の時間インターバルを変えることよりもいくつか利点がある。バースト内のパケット数を変える結果、受信機がバースト内の最初のパケットおよび最終パケット（これらはバンド幅を推定するのに使用される）を検出することが、より困難となる。パケット数を変えるには、バースト内のパケット（最初のパケット、最終パケットまたはそのいずれでもないパケット）の位置の信号を送らなければならない可能性が生じ、このことは送信されるデータでのオーバーヘッドを増加させる。更に、バーストごとのパケット数を過剰に少なくてはならない、何故ならば、バンド幅の推定値の信頼性がより低くなるからである。バースト当たりのパケット数を過剰に少なくしたり多くすることは、制限しなければならない。更に、システムは、信頼性を保証するためにパケットの数のより低いスレッショルド値を含むことができる。所望すれば、バースト内のパケット数は２〜５００の範囲内、または、より好ましくは、１０〜５０の範囲内とすることができる。更に、パケットの数は過剰に大きくしてはならない。その理由は、過剰に増加すると、送信デバイスでバッファが大幅に大きくなるだけでなく、バッファリングの平均遅延時間も長くなるからである。従って、適応化対策単独として、バースト内のパケット数を単に変えるだけでは、多くのアプリケーションに対して充分にロバストとすることはできない。
【０２２１】
パケットサイズを変えることにより、バンド幅の利用率をより良好にできるという利点が得られる。システムが、劣化したチャンネル状態を検出したときにパケットサイズを小さくすると、サイズを変えなかった場合に生じるはずのバンド幅より大きなバンド幅が得られる。この理由は、所定のチャンネル条件ではパケットをより小さくすると、パケットを大きくした場合と比較し、正しく送信される確率が高くなるからである（すなわちパケットの誤り率が低くなる）。従って、パケットを小さくする結果、受信機に正しく到達する前の再送信回数がより少なくなる。このことは、自動的にアプリケーション層において利用可能なバンド幅に良い影響を与えることになる。
【０２２２】
利用可能なバンド幅Ｈが狭くなったときは、ペイロードサイズＰをすなわち、パケットサイズを小さくすることが望ましく、利用可能なバンド幅が広くなったときは、ペイロードサイズＰを、すなわち、パケットサイズを大きくすることが望ましいと判断された。送信速度を必要な値よりも低くすることなく、時間の全て（例えば、時間のうちの９０％、９９％またはそれ以上）、または、実質的に全ての間で、利用できるバンド幅Ｈよりも低く送信速度Ｓを維持することが望ましい。
【０２２３】
パケットサイズの適応化を次のように定めることができる。送信機は利用できるバンド幅の推定値／最大値Ｈを（例えば受信機または他の方法で）入手済みである。システムは最大スループットを推定する間使用されたパケットの現在のペイロードサイズＰcurrentについて知っている。送信機は、現在の送信速度Ｓcurrentについても知っている。送信機はパケットの次のバーストに対する異なる送信速度Ｓnextだけでなく、その送信速度の値を実現するための次のペイロードサイズＰnextも決定できる。
【０２２４】
無線ネットワークの場合に生じる別の問題は、バンド幅／最大スループットがパケットサイズに応じて決まることである。小さいパケットサイズで得られる最大スループットは、大きいパケットサイズで得られるスループットよりも小さい。従って、パケットサイズを変えることによっても得られる最大スループットを変えることができる。
【０２２５】
利用できるバンド幅の推定値が与えられた場合に、送信速度を選択するための１つの潜在的な技術は、次の式が維持されるようにペイロードサイズＰnextを計算することである。
【０２２６】
【数３５】
2007184913.tif 000036
【０２２７】
ここで、Ｆはバンド幅利用係数で０≦Ｆ≦１であり、Ｆは利用可能なバンド幅の推定値の誤差および短い時間インターバル内で利用可能なバンド幅が急に変化することに対するセーフガードのマージンを提供するものである。Ｈは利用可能なバンド幅の最新の推定値に基づくが、システムは測定時間と送信機が速度適応化のためのかかる推定値を利用できる時間との間に生じ得るバンド幅の変化も考慮できる。例えば、１秒以下、１秒の２分の１以下、１秒の１０分の１以下、または、１秒の１００分の１以下の時間を使ってチャンネルのバンド幅が増減する時間インターバルの尺度として使用できる。例えば、受信機で利用できるバンド幅の推定値が得られ、その後、この推定値が送信機に送信された場合、推定値を計算してからそれを利用するまでの時間インターバルは無視できないものとなる。推定値を計算することが、順方向時間のバンド幅を予測するための技術を含んでいても、かかる推定値はロバストでない。従って、システムは追加安全マージンを提供するのにＦを利用できる。図３１には、この技術の一実現例が示されている。
【０２２８】
例えば、バンド幅が一般に劣化している場合、利用可能なバンド幅の推定値はデータを送るときの実際の利用可能なバンド幅よりも大きくなり得る。これとは異なり、バンド幅が一般に良くなってきている場合、利用できるバンド幅のそのときの推定値はデータを送ったときの実際の利用可能なバンド幅よりも小さくなり得る。同じように、Ｆの他の関数も使用できる。
【０２２９】
一般に、送信速度を計算する際に、他の要素も考慮できる。例えば、オーディオ／ビデオストリーミング環境では、システムは１つのバーストから次のバーストで送信速度を大幅に増減してはならない。その理由は、送信速度をゆっくりと増加すること（例えば、１０％、２０％、３０％、４０％または５０％未満の変化）を可能にしながら、ビデオビットレートを急に増減（例えば１０％、２０％、３０％、４０％、６０％または８０％以上）すると、別のロバストネスまたはユーザーの好みが生じるからである。多くのケースでは、許容される減少量は許容される増加量よりも大きくなる。更に、多数のストリームを同時に送信した場合、他のストリームの送信速度に応じ、送信速度増減量も制限する。このように、他のストリームに基づく値よりも増減量は異なる。
【０２３０】
考慮し得る別の要素は、バンド幅推定値における（時間に対する）変化量である。このことは、ｎ個の劣化したチャンネル条件は、利用できるバンド幅を狭くするだけでなく、一般に推定値の変化量が増加するという事実によって理由付けされる。従って、変動の大きさを使って、利用できるバンド幅と選択される送信速度との間に維持しなければならない安全マージンを変えることができる。図３２にはこの技術の一実現例が示されている。
【０２３１】
前の式
【０２３２】
【数３６】
2007184913.tif 000037
【０２３３】
は前のパケットバーストにおいてパケットが失われなかった場合に一般に使用される。前のバーストにおいて、パケットが失われた場合、次の送信速度に対し別の値が計算される。例えば、この場合、最小送信速度を選択できる。
【０２３４】
上記のように、送信速度を得るために新しいペイロードサイズＰnextを選択できる。上記のように、新しく選択されたＰnextを使用する際に、上記選択の結果得られる送信速度Ｓnextが、利用できるバンド幅に比例するように、Ｐnextを選択することが望ましい。しかしながら、送信機は、現在のペイロードサイズＰcurrentを使用する際に、利用可能なバンド幅の推定値について知っているだけであるので、後者の新しく選択された値は送信機には判っていない。上記のように、利用できるバンド幅は使用されるパケットサイズに応じて決まる。
【０２３５】
前の式は次のように、より正確に記載できる。
【０２３６】
【数３７】
2007184913.tif 000038
【０２３７】
送信機はＨ（Ｐcurrent）について知っているが、Ｐcurrentは選択すべき最適なＰnextに等しかったり等しくなかったりする。最適なＰを選択するには、送信機は新しいペイロードサイズＰnextで期待される利用可能なバンド幅を推定するか、さもなければ持っていなければならない。
【０２３８】
パケットサイズ／ペイロードサイズを選択するための１つの技術は、理論および／または実験からペイロードサイズに対する利用可能な最大のバンド幅：Ｈmax（Ｐ）を決定することである。この利用可能な最大バンド幅は無線チャンネルの理想的な（または実質的に理想的な）条件下で得られる。すなわち、再送信が発生せず、最大データリンク速度が使用されることである。
【０２３９】
現在のペイロードサイズにおける測定されたバンド幅Ｈ（Ｐcurrent）と、このペイロードサイズでの最大可能なバンド幅Ｈmax（Ｐcurrent）との比を計算できる。この比は現在のチャンネル条件で測定されたバンド幅は常に（理想的なチャンネル条件下で得られる）最大バンド幅以下であるので、定義により、１.０以下となる。次に、この比を使って現在のチャンネル条件下の任意のペイロードサイズに対する利用可能なバンド幅を予測することができる。この関係の式は次のとおりとなる。
【０２４０】
【数３８】
2007184913.tif 000039
【０２４１】
Ｐnextによってこの式を書き直すと、次の式が得られる。
【０２４２】
【数３９】
2007184913.tif 000040
【０２４３】
従って、送信機は、この式が成立するようにＰnextを選択できる。Ｈ（Ｐcurrent）は既知であり（測定したので）、同じようにＨmax（Ｐcurrent）およびＨmax（Ｐnext）の値も既知である。後者の値はオンラインで計算するかまたは予め計算し、Ｐの選択された値に対するルックアップテーブル内に記憶できる。
【０２４４】
パケット選択のための別の技術は、利用できるバンド幅を無線チャンネル条件に従属させることである。特定の送信システムに対するチャンネル条件は、ビット誤り率（ＢＥＲ）、すなわち、送信後のビット誤りの確率によって特性を定めることができる。このチャンネルの条件は、他の特性、例えば、信号対ノイズ比を使って特徴を定めることもできる。ＢＥＲは信号対ノイズ比の関数となっていることに留意する。
【０２４５】
パケット誤り率ＰＥＲは、１つ以上のビット誤りを含む全パケットの確率（ある意味では８０２.１１のデータフレーム）として定義できる。多くのケースにおけるＰＥＲは、ＢＥＲおよびデータパケットサイズに応じて決まる。ＢＥＲの値を固定すると、パケットサイズが大きくなれば、ＰＥＲも大きくなる。上記のように、大きいパケットは小さいパケットよりも誤りをより生じやすい。ＰＥＲとＢＥＲとの関係は次のように近似できる。すなわち、
ＰＥＲ＝１−（１−ＢＥＲ）ｂ
ここで、ｂはビット数で表示したパケットサイズ（すなわち８×Ｐ＋ＭＡＣ／ＰＨＹのオーバーヘッド）である。
【０２４６】
達成可能なスループット（利用可能なバンド幅）は、他の要素の他にＰＥＲ、データパケットサイズ、プロトコルオーバーヘッドに応じて決まる。チャンネル条件は統計的にモデル化することができ、システムはＨ’で表示される、期待される最大達成可能なスループット（期待される利用可能なバンド幅）を計算できる。このモデルは、８０２.１１  ＭＡＣによる固定された数の再試行に基づく。ＰＥＲが小さいとき、少ない回数の再試行により受信機側にパケットが到達することに成功すると予想される。この場合、最大スループットは大きくなる。他方、ＰＥＲが大きいとき、より多い回数の再試行が予想され、パケットが失われる確率がより高くなる。かかるチャンネル条件では、最大スループットは小さくなる。
【０２４７】
従って、システムはＢＥＲからＰＥＲを計算し、図３３に示されるように、ＰＥＲから期待される最大スループットを計算できる。これらの関係は、正確に基礎となる統計的プロセスだけでなく、無線（例えば、８０２.１１）プロトコルをどのようにモデル化したかに応じて、多数の異なる方法で計算できる。
【０２４８】
図３４を参照すると、ペイロードサイズＰの異なる値および８０２.１１ｂ  ＭＡＣのためのＢＥＲの異なる値に対する期待バンド幅の表が示されている。ここで、図３４は８０２.１１ｂ  ＭＡＣのスループットの期待値を示すが、これら期待値は、中間プロトコル層の使用およびプロトコルヘッダーに起因する関連オーバーヘッドの使用により、オーディオ／ビデオアプリケーション層におけるスループットとは異なることがある。ＭＡＣサービスデータユニット（ＭＳＤＵ）は、オーディオ／ビデオペイロードだけでなく、中間プロトコルのためのヘッダー、例えば、ＵＤＰおよびＩＰの双方を含む。例えば、オーディオ／ビデオデータが８０２.１１ｂの頂部でＵＤＰおよびＩＰを使用して運ばれる場合、１５００バイトのＭＳＤＵは１４７２バイトのオーディオ／ビデオアプリケーションデータを含む。その理由は、ＵＤＰ（８バイト）およびＩＰ（２０バイト）のヘッダーによって２８バイトが必要であるからである。従って、オーディオ／ビデオデータに対して実際に達成できるスループットは、表内の値より若干小さくなる。我々の適応化アルゴリズムではこのことを考慮している。
【０２４９】
８０２.１１ａ、８０２.１１ｇまたは他の無線プロトコルに対して、図３４と同様な表を作成できる。図３４内のＭＳＤＵのサイズおよびＢＥＲの値は代表的な値の例であり、適宜、その他の値も使用できることに留意されたい。ＢＥＲ＝０の縦列は理想的なチャンネル条件のケースに対応し、更に右の縦列は劣化しているチャンネル条件に対応する。
【０２５０】
図３５に示されるような速度適応化を、この技術が提供できる。現在のペイロードサイズＨ（Ｐcurrent）における現在の利用できるバンド幅の推定値が決定されると、システムは図３４を使って現在のチャンネル条件を推定できる。特に、図４５の横列では、システムはバンド幅の値のレンジを定める。ここで、各レンジは横列内の２つの継続するバンド幅の入力欄の間の中間値によって定められる。例えば、現在のＭＳＤＵのサイズが（ＵＤＰ／ＩＰが使用されているケースでは、Ｐcurrent＝１４７２に対応する）１５００である場合、ＢＥＲ＝１０−７の欄内の値とＢＥＲ＝１０−６の欄内の値の間の中間値は（６.２３７＋６.１５９）／２＝６.１９８Ｍｂｐｓとなる。同様にＢＥＲ＝１０−６とＢＧＲ＝１０−５の縦列の値の間の中間値は（６.１５９＋５.４０８）／２＝５.７８４Ｍｂｓとなる。６.１９８Ｍｂｐｓの値と５.７８４Ｍｂｐｓの値は、速度の範囲を定める。現在のＭＳＤＵのサイズが１５００であり、現在の推定バンド幅の値がこのレンジ内にある場合、システムはＢＥＲが約１０−６であると推定するので、現在のチャンネル条件の特徴を定めることができる。
【０２５１】
その後、現在のチャンネル条件のもとでのより最適なペイロードサイズを探すために、システムはサーチの結果得られる送信速度（Ｐnextの場合）がＦでスケーリングされたＰnextおよびＢＥＲで期待される利用可能バンド幅に最も近くなるような横列に対して、前のステップで見つけたＢＥＲを有する縦列をサーチする。
【０２５２】
より詳細には、（図３４のような表から）Ｐのいくつかの値に対し、ＢＥＲおよび期待バンド幅Ｈ’の値が与えられると、システムは次の値を最小にするＰの値として、Ｐnextを選択する。
【０２５３】
【数４０】
2007184913.tif 000041
【０２５４】
２つの縦列の間の中間点によって定められたバンド幅のレンジを含むＢＥＲの値およびＰ（またはＭＳＤＵのサイズ）の値の組に対して、図３４全体を予め計算することができることに留意されたい。従って、Ｆ、ＭおよびΔＴの値が決定されると、直接上記式によって定められるような選択プロセス全体を予め計算し、ルックアップテーブルに記憶することができる。従って、速度適応化技術の実現は、下記に詳細を示すように、表を１回だけ、または数回ルックアップするだけで行うことができる。
【０２５５】
上記適応化アルゴリズムは、ルックアップテーブルの一組により効率的に実現できる。このテーブルセットは、所定のＭＳＤＵサイズと現在のバンド幅の推定値を（この所定のＭＳＤＵサイズを使って）新しいＭＳＤＵサイズにマッピングするだけであり、新しいＭＳＤＵサイズは推定されるチャンネル条件において最適なものである。
【０２５６】
テーブルルックアップ機構の作動を示すために、８０２.１１ｂのケースに対する、テーブルセットの一例として下記に例を示す。
【０２５７】
テーブルの設計は｛０、１０-7、１０-6、１０-5、１０-4.75、１０-4.5、１０-4.25、１０-4、１０-3.75、１０-3.5、１０-3.25｝のセット内でＭＳＤＵのサイズについてスタートする。
【０２５８】
バースト当たりのパケット数Ｍを１０とすることができる。
【０２５９】
バーストの間の時間インターバルΔＴを３０ミリ秒とすることができる。
【０２６０】
この場合、ＭＳＤＵサイズ１５００バイトに対する（ＭＡＣレベルでの）送信速度は４Ｍｂｐｓである。この値は１４７２バイトのオーディオ／ビデオペイロードおよび３.９２５Ｍｂｐｓのアプリケーション層の送信速度に対応する。理想的なチャンネル条件（ＢＥＲ＝０）では、最大パケットサイズが（ＭＳＤＵに基づき１５００バイトである）使用され、劣化したチャンネル条件（０より大きいＢＥＲ）では、より小さいパケットサイズ（上記セットにおいてより小さいＭＳＤＵサイズに対応する）が使用されることになる。
【０２６１】
一例では、Ｆ＝０.６４を使用する。この例は、理想的なケース（ＢＥＲ＝０であり、ＭＳＤＵサイズは１５００バイトである）に対して、この関係が正確に成り立つように設計した。ここで、送信速度（ＭＡＣレベルでの）は４Ｍｂｓ、期待バンド幅は約６.２５Ｍｂｓである。
【０２６２】
この技術は、図３６Ａ〜図３６Ｉにおいて上記チャンネル条件に利用可能なバンド幅が従属することを利用した方法に基づき設計されたルックアップテーブルを示している。この場合、最適なＭＳＤＵサイズの組は次のサブセットである。
｛１５００、１２００、１０００、９００、６００、３００、２００、１００｝
【０２６３】
特定のケースでは、一次元ルックアップテーブルの組の代わりに単一の二次元ルックアップテーブルを使用するほうがより好ましい。
【０２６４】
ルックアップテーブルを実現することにより、本明細書に記載した特定の技術（この技術だけに限定されない）を含む設計方法が可能になる。更にテーブルの設計および計算をオフラインで実行できる。従って、オンラインの適応化方法は、主にテーブルをルックアップする操作から成る。
【０２６５】
適応化ルックアップテーブルの設計は、使用するＭＳＤＵのセットだけでなく、バースト当たりのパケット数Ｍおよびバースト間インターバルにも依存する。ＭＳＤＵサイズのセットは異なるネットワークのタイプに対して、恐らくはネットワークの機器の異なる実現例に対して異なることがある。すべてのアプリケーションにおける製品開発中にこの組を固定できることが期待される。ＭおよびΔＴの選択は、オーディオ／ビデオデータをストリーミングするのに使用される最大速度によってほとんど決まる。一部のアプリケーションでは、これらの値は製品開発中に固定される。かかるすべてのケースでは、完全にオフラインでルックアップテーブルを構成できる。オーディオ／ビデオストリーミングのビットレートが事前に判っていない場合、アプリケーションはストリーミングセッションをスタートする前にＭおよびΔＴを選択しなければならないことがある。実際のルックアップテーブルはストリーミング前に、上記選択時に構成できる。他のケースでは、製品開発時に既知のビットレートの領域が存在し、この場合、上記のようなルックアップテーブルのセットを代表的なビットレートの値に適用できるように予め計算し、製品内に予め記憶することができる。
【０２６６】
別の組み合わせでは、図３４に示されるような期待バンド幅の値を有するテーブルだけがデバイス内に予め記憶される。この場合、適応化ルックアップテーブルはデバイス内に記憶されず、次の式で示されるように、図３４に基づき、オンラインでパケット選択プロセスを実行する。
【０２６７】
【数４１】
2007184913.tif 000042
【０２６８】
この技術は計算上の複雑度が低く、高速実現に適している。
【０２６９】
一実現例では、送信機から受信機へのデータは８０２.１１ＭＡＣを通してＵＤＰおよびＩＰを使って運ばれる。従って、８０２.１１ＭＡＣペイロード（ＭＳＤＵ）は２０バイトのＩＰヘッダーと８バイトのＵＤＰヘッダーとを含む。このシステムはＵＤＰペイロード内にパケットシーケンス番号およびバーストシーケンス番号を含むことができ、これら番号は受信機におけるパケットの損失を検出し、かつバースト内の最初のパケットおよび最後のパケットを検出すのに使用される。ある場合には、バーストシーケンス番号は受信機にてパケットシーケンス番号から導出できる。この場合、各パケット内にバーストシーケンス番号が含まれなくてもよい。現在の実現例では、オーディオ／ビデオストリームの間、バースト当たりのパケット数は一定である。
【０２７０】
別の設計は、ＵＤＰ／ＩＰの上にＲＴＰ（リアルタイムのトランスポートプロトコル）を使用することであり、ＲＴＰヘッダーは既にパケットシーケンス番号を含み、同じように他の機能を提供する。
【０２７１】
一実現例では、受信機から送信機へのフィードバックパケットは８０２.１１ＭＡＣを通してＵＤＰおよびＩＰを使って輸送される。ペイロードは受信機で計算された利用可能なバンド幅の推定値を含み、更に最新のパケットバースト内でパケットの損失が検出されたかどうかを示すインジケータも含む。
【０２７２】
別の設計例は、受信機から送信機へのフィードバックを提供するのに、ＲＴＣＰ（リアルタイム制御プロトコル）を使用できる。このＲＴＣＰはＲＴＰに対するコンパニオンプロトコルであり、ＲＴＣＰはいわゆる送信レポートおよび受信レポートの形態でＲＴＰセッションの参加者にクォリティオブサービスに関連したフィードバック情報を提供する。
【０２７３】
フィードバックパケットのペイロードは受信機でバンド幅を推定するのに使用されるパケットのサイズに対応するパケットサイズまたはペイロードサイズの値も含むことができると一般的に理解すべきである。これによって送信速度適応化プロセスはパケットサイズ適応化テーブルにインデックスを付けるための正しい（パックサイズ、バンド幅）タップル（ｔｕｐｌｅ）を有する。更に、パケットサイズ適応化技術は送信機ではなく受信機で実現できる。かかるケースでは、フィードバックパケットは速度適応化プロセスによって計算されるように次の送信のために計算された新しいパケットまたはペイロードサイズを含むことができる。
【０２７４】
一部の実施例では、受信機でバンド幅の値を計算することができ、この値はその後、送信機へ伝送され、送信機で速度適応化プロセスを実行する。別の実施例では、受信機は新しいパケットおよび／またはペイロードサイズ、および／またはその後のパケット送信をするために使用すべきパケット（またはバースト）の間のタイミングを計算するために、計算されたバンド幅の値を直接使用できる。かかるケースでは、推定されたバンド幅の値ではなく、新しいパケットおよび／またはペイロードサイズおよび／またはパケット（またはバースト）の間のタイミングを送信機に伝送する。測定値の検出、かかる測定値に基づくバンド幅の値の計算、無線チャンネルの状態を表示するその他の量、速度適応化の実行、パケットサイズの計算、バースト内のパケット数の計算、パケット間およびバースト間の時間の計算は、受信機または送信機のいずれかで、またはこれら２つを組み合わせて実行することができると一般に理解すべきである。どこで測定および処理を行うかを選択するのに使用できる１つの事項は、送信機および／または受信機に利用できる計算リソースだけではなく、無線チャンネルの期待条件および利用可能なバンド幅である。
【０２７５】
次に速度適応化方式の動作の一例について説明する。バンド幅推定、フィードバックおよび速度適応化モジュールは、ソフトウェアモジュールで実現できる。これらソフトウェアモジュールは２つのウィンドウズ２０００ラップトップコンピュータ（一方は送り側／サーバであり、他方は受信機／クライアントである）で機能できる。各ラップトップコンピュータには８０２.１１のアドホックネットワーキングモードに設定し、８０２.１１ｂ  ＤＣＦを使って通信する８０２.１１ｂのクライアントアダプタを装備する。データは８０２.１１ｂを通してＵＤＰおよびＩＰを使って運ばれる。
【０２７６】
この例では、パラメータは上記ルックアップテーブルの設計例に対するパラメータと同じであって、バースト当たりのパケット数Ｍは１０であり、バースト間の時間インターバルは３０ミリ秒である。最大ＭＳＤＵのサイズは１５００バイト（１４７２バイトのペイロード）であり、適応化中、ＭＳＤＵのサイズは｛１５００、１２００、１０００、９００、６００、４００、３００、２００、１００｝の中から選択される。従って、最大送信速度は４Ｍｂｐｓであり、一方、最小送信速度は０.２６７Ｍｂｐｓであった。上記のように記載されたルックアップテーブルの組みを送信側で使用した。受信機でバンド幅の推定値を計算し、送信機へ送った。
【０２７７】
この例ではラップトップパソコンは最初に近くに設置し、約５秒後、ラップトップパソコン間の距離を（ラップトップパソコンの一方を載せたローリングカートを押すことにより）約２５ｍまで離した。スピードは約１ｍ／秒であった。実験の開始から約５５秒後、最初の位置まで２つのラップトップパソコン間の距離を短くした。実験はデータストリームの時間と同じように約９０秒続いた。この例において、８０２.１１ｂのカードは自動速度フォールバックモードに設定され、これによってカードはチャンネル条件に応じてデータリンク速度を切り換えることができた。送信パワーは１ｍＷにセットした。これら条件により、送信／受信部は劣化したチャンネル条件の影響を受けた。
【０２７８】
図３７には、利用できるバンド幅の上記実験の結果生じる測定値（受信機がレポートするような）だけでなく、適応化された送信速度が示されている。図３７に示されるように、推定中、利用可能なバンド幅のサンプルをスムーズにしたのと同じように、送信速度のオリジナルのサンプル（バーストごとに１つのサンプル）をスムーズにした。速度が常時推定された利用可能なバンド幅よりも下になるように、適応化に成功したことをグラフは示している。
【０２７９】
無線チャンネルの特性を定め、他の基準、例えば信号対ノイズ比に基づき、無線チャネルを通って送信されるデータの特性を定めることができる。このように、速度適応化技術、パケットサイズ適応化、スペースの決定およびパケット数の決定は少なくとも一部はこれらの他の特性、例えば信号対ノイズ比に基づくことができる。
【０２８０】
遅延時間が制限された送信
最高の品質を維持するには、変化するネットワークの条件およびオーディオ／ビデオコンテントの特性に基づき、リアルタイムでオーディオ／ビデオストリームを適応化することが望ましい。特に、オーディオ／ビデオコンテントのコーディングまたはトランスコーディングからデコーディングまたはプレゼンテーションまでのエンドツーエンドの遅延時間が小さい場合、伝送システムをモデル化するだけでなく、オーディオ／ビデオコンテントの特性をより広くモデル化することが好ましい。
【０２８１】
オーディオ／ビデオデータユニットのシーケンスとして、圧縮されたオーディオ／ビデオストリームを見ることが望ましい。例えば、データユニットはビデオストリームを構成する一連のビデオフレームのうちの一つのビデオフレームに対応できる。連続したオーディオ／ビデオメディアストリームに対しては受信機でのコンテントのデコーディングおよびレンダリングの中断または歪みを避けるために、送信締切期限前に各オーディオ／ビデオデータユニットを受信機に送らなければならない。従って、各オーディオ／ビデオデータユニット送信締切期限を有し、その結果、実質的にエンコーディング（またはトランスコーディング）の時間からデコーディングの時間までの間に、このデータユニットによって生じる遅延時間に対する制限が生じる。更に、オーディオ／ビデオデータユニットの重要性、すなわち送信締切期限前にデータユニットが送られた場合、送信締切期限後にデータユニットが送られた場合、または完全にデータユニットが失われた場合における、コンテントのレンダリングの品質に対する効果を検討することが好ましい。遅延時間が制限されたオーディオ／ビデオ送信では、オーディオ／ビデオストリームはそれぞれの送信締切期限前に実質的にすべてのデータユニットが受信機に到達するように、オーディオ／ビデオストリームを適応化する。別のやり方としては、実質的に最も重要なデータユニットがそれぞれの送信締切期限の前に受信機に到達するようにオーディオ／ビデオストリームを適応化する。例えば、このことは、利用可能なバンド幅の変化に応じて、圧縮ビデオデータのビットレートを適応化することによって達成できる。
【０２８２】
エンコーディングの時間からデコーディングの時間までの間の異なった時間における圧縮されたオーディオ／ビデオデータのバッファリングを検討することが望ましい。種々の理由から、オーディオ／ビデオ伝送システムでは、オーディオ／ビデオデータをバッファリングすることが必要であり、一般的なことである。システムの送信機（エンコーディング）部分は一般にエンコーダの出力端にバッファを含む。システムの受信（デコーディング）部分は一般にデコーダの入力端にバッファを含む。バッファは、一般に送信機（エンコーダ）において、受信機（デコーダ）において、更に、オプションとしてはネットワーキンクの中間において、種々のネットワーキングプロトコル層を実現するシステムの部分において存在する。かかるバッファリングは全て、送信されるオーディオ／ビデオデータユニットに生じる遅延に対する効果がある。かかるバッファリングは、時間に対する利用できるバンド幅の変化およびオーディオ／ビデオビットレートの変化と共に検討しなければならない。
【０２８３】
受信機へ送られるデータの現在のビットレートは推定されたバンド幅に適すが、バンド幅は変動する傾向があり、この結果、データレートが実際に利用できるバンド幅よりも一時的に大きくなる。利用できるバンド幅を超えるビットレートでデータを送信しようとすると、この間、送信側（サーバまたはゲートウェイ）におけるバッファ内またはチャンネル内でデータのバックログ（積滞）が大きくなる。データ速度が利用できるバンド幅よりも低くなると、送信機（サーバまたはゲートウェイ）にあるバッファまたはチャンネル内でバックロブされたデータは、減少していく。このような送信機（サーバまたはゲートウェイ）におけるバッファ内またはチャンネル内のデータの一時的なバックログは、時間に影響を受けないデータに対してはクリティカルではない。しかしながら、オーディオおよび／またはビデオ送信をするためには、指定された時間までに送信されたデータがデコーダに存在し、よってデータを正しくデコードできるようにすることを求める時間的な制限がある。不幸なことに、送信機（サーバまたはゲートウェイ）におけるバッファ内でバックログされたまたはチャンネル内で遅延したデータは指定された時間の後に最終的にデコーダに到達するので、時間どおり正しくデコードできないこととなる。この結果、受信側でビデオの対応するフレームが失われたり、またはスキップされたり、もしくはビデオ表示の中断が生じ得る。システムはバッファ、特にデコーダにおけるバッファのアンダーフローを防止しなければならない。更に、バッファ、特にエンコーダにあるバッファのオーバーフローも防止しなければならない。
【０２８４】
図３８を参照する。エンコーディングの時間５００は受信機へ送信するために各フレームをコード化および／またはトランスコードする時間ｓiを示す。送信の時間長さｄi５０２は、コーディングおよび／またはトランスコーディングの時間５０１から受信機でのデータの受信時間５０３までを示す。異なるデータユニットに対する送信の時間長さｄi５０２は、特定のチャンネル条件および送信機（サーバまたはゲートウェイ）におけるバッファ内の他の送信すべきデータユニットによって変化する傾向がある。送信時間長さｄi５０２は、各データユニットに対して変化する傾向があるので、システムは各データユニットに対する送信締切期限ＳDTS，iよりも充分前の時間ΔＴＥ５０４（遅延許容度）において、各データユニット（例えばフレームの部分）をエンコードおよび／またはトランスコードすることが望ましい。システムに対する遅延制限は、ｓi＋ｄi≦ＳDTS，iとして表示できる。フレームに対するビット数を増減することにより、送信のための時間長さｄi５０２を変更できる。図３８において、６番目のフレームに対するデータユニットは、遅く５０８で到達しているので、時間どおりデコードされず、ビデオの画質が損なわれたことが判断できよう。従って、１フレームのビット数を適切に調節するように、バンド幅および／またはデータユニットの到達時間を監視することが望ましい。
【０２８５】
図３９を参照する。システムはデータのエンコーディングおよび／またはトランスコーディングと受信機においてデコーダがデータを受信する間で、システム内に１つ以上のバッファまたは他の機構を含むことができる。システムは、エンコーダおよび／またはトランスコーダ５１８からデータを受信するエンコーダの後にエンコーダバッファ５２０を含むことができる。このエンコーダバッファ５２０は、システムの送信側部分のアプリケーションレベルとすることができる。送信機は更にエンコーダおよび／またはエンコーダバッファ５２０からのデータを受信する送信機のＭＡＣ層にＭＡＣバッファ５２２を更に含むことができる。送信機におけるエンコーダバッファおよびＭＡＣバッファの双方はエンコーダ／トランスコーダ５１８により既にコード化され／トランスコードされたデータユニットのためのパケットを含むことができる。システムはビットレートを選択する際に送信機バッファ内のデータ量を考慮することができ、システムは無線送信５２４における遅延時間を含み得る。受信機は無線送信５２４からのデータを受信するＭＡＣバッファ５２６およびデコーダバッファ５２８を含むことができ、前に説明したように、システムはデコーダ５３０におけるビデオフレーム／データユニットの送信締切期限を考慮できる。デコーダバッファ５２８内には圧縮されたビデオフレームのようなデータユニットがそれらの送信締切時に存在していなければならない。システムの特徴を定めるのに使用できる別の基準は、各送信締切期限５６０に対する各データユニットの到着時間５３２である。この到達時間５３２が送信締切期限５０６よりも充分前にあるとき、所望すれば、データ速度を大きくすることができ、逆に到達時間５３２が送信締切期限５０６よりも充分前になければ、所望すれば、データ速度を小さくすることができる。
【０２８６】
適切なデータ速度を選択しようとする際に、システムの時間的な特徴も考慮できる。前のデータユニットの送信のための過去のチャンネル条件を考慮することができる。例えば、最新のチャンネルのバンド幅が狭かった場合、チャンネル条件が改善しても、データ速度を大幅に大きくしないことが好ましい。更に、システムはデータユニットの数推定値さもなければ、前の時間中に利用できるバンド幅を超えて、エンコーダから送られたデータの測定値を考慮に入れることができる。エンコーダおよび／またはトランスコーダからのこの追加データを追加データユニットを変更するための基礎として使用できる。利用できる別の特性は、現在および／または将来の送信のための適切なデータ速度を決定するための、前の時間におけるチャンネル条件の累積効果である。前のデータユニットに対する過去のチャンネル条件の変化を考慮に入れることができる。例えば、チャンネルが瞬間的に広いバンド幅を有する場合、システムは将来のバンド幅が広くなるものと予想し、それに応じたデータ速度を提供することができる。例えば、チャンネルが時間経過に対して狭いバンド幅に向かっている場合、データ速度を低減するか、さもなくばデータ速度を増加しないことが望ましい。過去のデータユニットの送信に基づき、送信すべき後のデータユニットのための予想将来チャンネル条件を考慮できる。送信すべき後のデータユニットのための将来のチャンネル条件を予測するための基礎として、過去のチャンネル条件の変化を使用できる。例えば、チャンネルのバンド幅が広がった場合、システムは将来、バンド幅が更に広くなることを予想し、データ速度を大きくすることができる。
【０２８７】
ＭＰＥＧ−２タイプのビデオデータの場合、異なるタイプのフレーム情報、例えば、Ｉフレーム、ＢフレームおよびＰフレームが存在する。ビデオデータを再構成するには、Ｉフレームがもっと重要であり、ＰフレームはＩフレームほど重要ではなく、ＢフレームはＰフレームほど重要ではない。このように、実現可能であれば、より重要なフレームに追加データを付与できる。更に、重要なフレーム、例えば、Ｉフレームの直前のデータを、より少ないビットでコード化し、追加バンド幅をＩフレームに利用できるようにすることができる。このようにすれば、Ｉフレームがタイムリーに到達する可能性が高くなる。あるケースでは、トランスコーダまたはエンコーダは、送信のバンド幅特性に関する情報を使用し、送信特性を改善するためにエンコーディングまたはトランスコーディングのために使用されるビット数を調節できる。一般に、データストリームのある部分は、データストリームの他の部分よりも重要であるので、異なる数のビットでコード化される。従って、メディアの特性、例えばそのフレームタイプを知ることにより、異なるデータユニットを、可能な異なるコード化特性および／または異なる送信特性、例えば可能な遅延時間とすることができる。
【０２８８】
無線通信の時間的特徴を制御する１つの態様として、次のものがある。システムは実際の送信締切期限よりも早い時間に目標送信時刻を決定できる。締切期限感度ファクタＦを使用して目標送信時刻を決定する。その後、システムはデータユニットの到達の期待時刻が目標送信時刻と一致するように、データユニットのビットレートを適応させる。このことは次のように表示できる。
【０２８９】
【数４２】
2007184913.tif 000043
【０２９０】
ここで、ｓiはデータユニットｉをコード化またはトランスコードした時間であり、
Ｅ（ｄi）はデータユニットｉの送信期待時間長さであり、
Ｆは期限感度ファクタ０≦Ｆ≦１であり、
ΔＴEはエンドツーエンドの遅延時間であり、
ｓstartは最初の画像を送信側でコード化またはトランスコードした時刻であり、
ΔＴはデータユニットのプレイアウト時間長さである。
【０２９１】
無線ネットワークによって送信されるデータは、データユニットのあるシーケンスによって記述でき、データユニットの各々はコード化されたか、または、圧縮されたメディアデータの一部を含む。データユニットは、例えば、一つのビデオフレームに対応する。これとは異なり、データユニットは、例えば、１フレーム以下のビデオフレーム、１つのビデオフレームのうちの一部、１つのビデオフレーム内のオブジェクトまたはマルチビデオフレームに対応できる。データユニットにはｉ、ｉ＝０，１，２，３，…でインデックスを付けることができ、各データユニットは１又は多数のパケットに対応し、ここで１つのパケットはネットワークを通して送信するのに適したデータの１つのユニットである。
【０２９２】
データユニットをコード化するのに使用されるビット数は、ｒi（ｑ）によって表示でき、ここでｑは１組のコーディング選択、特に量子化ステップサイズである。ｑでコード化する際のデータユニットｉに関連する歪みは、Ｄi（ｑ）で表示できる。各データユニットは関連する送信締切期限を有し、データユニットは許可された時間内に正しくデコードされるよう、この送信締切期限までに受信側に到達しなければならない。この送信締切期限はデコーダのタイムスタンプｔDTS，iで表示でき、このタイムスタンプはメディア時間ｔで表示される。１つのデータユニットが１つのビデオフレームに対応する一定フレーム速度のビデオの場合、一般に次の式が成り立つ。
【０２９３】
【数４３】
2007184913.tif 000044
【０２９４】
ここで、ΔＴはフレーム時間長さ、すなわち、フレームインターバル（１.０をフレームレートで割った値）に対応する。すなわち、任意のデータユニットｉのデコーダのタイムスタンプと第１データユニットのデコーダのタイムスタンプとの間の差はデータユニットの処理終了までの時間長さの倍数となる。所望すれば、同じように他の関係も使用できる。
【０２９５】
ほとんどのケースにおいては、受信側ではデータユニットをデコーダに送る前に無線ネットワークからの着信データユニットをバッファ化する。従って、データパケットのストリームの送信をスタートしたときに、受信側はデータパケットを受信し、最初のデータユニットのデコードをスタートする前に、固定された時間インターバルだけ待機する。その後、受信機は、一般に、一定速度でデータユニットをデコードする。例えば、ビデオの場合、この一定速度はフレーム速度に対応させることができる。
【０２９６】
メディア時間ｔ（メディアクロック）は次の変換式により、送信時間ｓ（送信側でのクロック）に関連する。
【０２９７】
【数４４】
2007184913.tif 000045
【０２９８】
ここで、ｓstartは最初のデータユニットがコード化／トランスコードされる送信側での時刻（送信側クロックでの）に対応し、ΔＴＥはコーディングからデコーディングまでの間のエンドツーエンドの遅延時間である。このエンドツーエンドの遅延時間は、実質的に３つの成分ΔＴE＝ｄE＋ｄF＋ｄBから成り、ここで、ｄEは最初のデータユニットがコード化された時刻から最初のデータユニットの最初のパケットが送信側から送信された時刻までの間の時間差であり、ｄFは送信機が最初のデータの最初のパケットをチャンネル内に送ったときから最初のパケットが受信機に到達した時刻までの間の時間差であり、ｄBはデータユニットのうちの最初のパケットが受信機に到達した時刻から受信機のバッファからこのデータユニットが除かれ、デコードされる時刻までの時間差である。このようなタイミングは受信機における通常の再生速度に基づく。しかしながら、このタイミングは、例えば、受信機での再生速度に基づく他のファクタに変えてもよい。ｄBの値はシステムによって制御でき、この値が大きくなることは、送信をスタートする際に、または、例えば、チャンネル変更によって入力ビデオを変えるときに、ユーザーが受ける遅延時間が長くなることを犠牲にしてロバストネスが大きくなることを意味する。
【０２９９】
一定フレームレートのビデオの場合、上記式を使用することにより、デコーディングタイムスタンプは、送信機の時間（送信機のクロックでの）によって次のように表示できる。
【０３００】
【数４５】
2007184913.tif 000046
【０３０１】
図３８を参照すると、デコーディングタイムスタンプｓDTS，iとデータユニットのインデックスｉとの関係を、送信締切期限の曲線５０６によって表示できる。この送信締切期限の曲線は、一定遅延時間の値だけ、コーディング時刻５００の曲線からオフセットされる。
【０３０２】
時刻ｓiに送信側がデータユニットｉをコード化またはトランスコードしようとしていると仮定し、データユニットｉをコード化する瞬間から、データユニットが到達する瞬間までの間の時間差をｄiとしよう。この時間長さｄiは、データユニットｉをコード化するのに使用されるビット数ｒiと、データユニットｉをどのようにパケット化（特に、データパケットの数およびペイロードサイズ）するかと、ネットワークまたはチャンネルの（時間的に変化する）スループット性能とに応じて決まり、このデータユニットが時間どおり送られれば次の式が成り立つ。
【０３０３】
【数４６】
2007184913.tif 000047
【０３０４】
図３８を参照する。データユニットの到達時刻５３２は送信締切期限５０６よりも前になければならない。このことは、エンドツーエンドの遅延時間の制限を示す。
【０３０５】
システムのモデルは更にエンコーダの出力端におけるエンコーダバッファだけでなく、送信機におけるネットワーク部分内の送信待ち合せまたはバッファを更に含むことができる。この送信待ち合せ（またはバッファ）はＷＬＡＮ  ＭＡＣのパケット待ち合せに対応し得る。多くのケースでは、アプリケーション層はこの待ち合せに容易にアクセスできない。アプリケーションがチャンネル内にデータパケットを送信すると、アプリケーションは送信待ち合せ内にパケットをドロップするだけである。特定の時間におけるエンコーダバッファおよび送信バッファの状態、例えば、満杯は、チャンネル条件（時間によって変化する）に応じて決まる。多くのケースにおいて、送信バッファはチャンネル条件が一般に良好であれば、ほとんどの時刻で空となり得る。これと対照的にチャンネル条件が良好でなければ、送信バッファは一杯であるか、完全に一杯になり始めている。
【０３０６】
図３９には、時刻ｓiにおけるシステムの状態が示されている。送信機はデータユニットｉをエンコーダ／トランスコードしようとしている。送信機びバッファ５２０および５２２は、０でない数のデータユニットｋ、ｋ＋１、ｙ、ｉ−２、ｉ−１を含むことができ、ここで、前にエンコーダバッファに送られた待ち合せ内のデータユニットはユニットｉ−１である。無線チャンネルを通してまさに送られようとしているデータユニットはユニットｋであり、このユニットは送信機のＭＡＣ待ち合せ５２２内にまだある最小インデックスを含むデータユニットである。受信機バッファ５２６および５２８に既に到達した最大のインデックスを有するデータユニットはユニットｋ−１である。受信機のＭＡＣバッファ５２６は小さく、ほとんどデータを滞留しないことに留意すべきである。データユニットがビデオフレームに対応し、エンコーダおよびデコーダが一定のフレーム速度で作動する場合、送信システム内のデータユニットの総数を一定にしなければならない。
【０３０７】
Δｔjを無線チャンネルを通してデータユニットｊを送信するのにかかる時間、すなわち、受信機のデータバッファに入るためのデータユニットｊの最初のビットから最終ビットまでの時間長さであるとする。この時間長さΔｔjは、データユニットｊをどのようにパケット化するか、例えば、データパケットの数およびサイズおよび無線チャンネルを通して実際にデータユニットｊを送信しているときのネットワークまたはチャンネルのスループット性能に応じて決まる。
【０３０８】
この場合、ｄiはつぎのように表示できる。
【０３０９】
【数４７】
2007184913.tif 000048
【０３１０】
すなわち、無線チャンネルを通してデータユニットｉを送信するのにかかる時間の他に、無線チャンネルを通して送信機バッファ内にまだある前の全てのデータユニットを送信しなければならない。
【０３１１】
この場合、遅延時間の制限値（式２８）を次のように表示できる。
【０３１２】
【数４８】
2007184913.tif 000049
【０３１３】
Δｔjはデータユニットｊの送信時のチャンネルのスループットまたはバンド幅に応じて決まることにも留意されたい。遅延制限値は、データユニットｉの時間どおりの配信はデータユニットｋ〜ｊの送信中のそれぞれの時刻におけるチャンネルのスループットまたはバンド幅に応じて決まるということを示している。かかるシステムではチャンネルのスループットまたはバンド幅は時間に対して変動する。従って、時間的な変動の特徴を定めるのに適切な技術、例えば、チャンネル動作の確率的モデルを使用できる。この場合、モデルが与えられ、過去のチャンネル性能の観測値が与えられれば、将来のチャンネルのスループットまたはバンド幅の性能の推定値または予測値を決定できる。むしろ、かかる観測値はアプリケーションに対するチャンネル性能の推定値のフィードバックから得ることができる。
【０３１４】
Δｔjはデータユニットｊをコード化するのに使用されるビット数ｒjに応じて決まることにも留意されたい。従って、レート適応化は一般に次式のように定めることができる。すなわち、ユニットｉの歪みＤiが遅延時間制限（式２９）を受けて最小となるように、データユニットｉに対する最適レートｒiを探すことである。
【０３１５】
速度適応化技術
チャンネル特性が与えられると、適切な速度適応化技術を定めることができる。１つのアプローチは、期待遅延時間制限値を表すように、式２９を変更することである。
【０３１６】
【数４９】
2007184913.tif 000050
【０３１７】
この式は、チャンネルの確率的モデルおよび過去のチャンネル性能の与えられた観測値に基づくものである。速度適応化は次に、ユニットｉの歪みＤiが期待遅延時間制限（式３０）を受けて最小となるように、データユニットｉに対する最適速度ｒiを探すことである。
【０３１８】
別のアプローチは、遅延時間制限値が満足されない確率（下記の式で示される）、換言すれば、データユニットｉからのデータが失われる確率を（データは受信機に遅れて到達するか、または完全に失われるので）算出することである。
【０３１９】
【数５０】
2007184913.tif 000051
【０３２０】
この式も又、再びチャンネルの確率的モデルおよび過去のチャンネル性能の与えられた観測値に基づく。この場合における速度適応化の問題は、データユニットｉに対する最適速度ｒiを探すことであり、よってユニットｉの歪みＤiを最小にし、よって（式３１）によって示される確率が低いスレッショルドを下回ったままとなるようにすることである。一部のケースでは、予想される歪みを算出するのに、式３１を利用することもできる。
【０３２１】
式３０を使用する一例について、より詳細に説明する。データユニットの送信の期待時間長さＥ［Δｔj］は、データユニットｊをコード化するのに使用されるビット数ｒjおよびθjで表示される送信時刻におけるチャンネル条件に応じて決まる。また、データユニットをどのようにパケット化するかによっても決まる。ｒjビットを含むデータユニットｊは、全てのパケットに対しペイロードサイズＰjを有するＭj個のパケットにパケット化される。従って、次の式が成り立つ。
【０３２２】
【数５１】
2007184913.tif 000052
【０３２３】
一例として、Ｅ［Δｔj］を計算するための２つの技術について説明する。Ｅ［Δｔj］を計算するための最初の技術は、データユニットｊの送信時の利用できる期待バンド幅の推定値の形態でのチャンネル条件の情報を含む。
ＷＬＡＮシステムにおける利用可能なバンド幅Ｈを推定する１つの技術は、バースト内のパケットを送信することに基づき、バンド幅を周期的に推定することであり、バンド幅の推定値は、１つ以上のバーストに対して１つ計算される。変更されたシステムでは、単一のデータユニットに対するパケットを単一のバーストで送信することができる。バンド幅の推定値は受信機により計算し、送信側へ送られるか、または受信した単一バーストに関する情報を得て、バンド幅を計算し、送信機へ提供される。この場合、この情報が速度適応化機構に有効である。フィードバック情報は、このバンド幅推定値の他に、バーストの数（インデックス）、すなわち、推定値を計算したデータユニットを含む。
【０３２４】
利用できるバンド幅のための推定値を得るための別の技術も使用できる。特に、ＷＬＡＮ  ＭＡＣおよびＰＨＹ層から直接情報を検索するための機構を送信機が使用でき、この情報からバンド幅または最大スループットを計算できる。
【０３２５】
ここで、メディアユニットｊ＝ｋ....，ｉに対するＥ［Δｔj］を計算するのに、最も新しい、利用できるバンド幅に対する推定値を利用する。従って、システムは将来の送信のために利用できるバンド幅を予測するのに、過去に観測された利用可能なバンド幅の値を利用できる。システムは次のようにＥ［Δｔj］を計算できる。
【０３２６】
【数５２】
2007184913.tif 000053
【０３２７】
ここで、Ｈ−は利用できるバンド幅の最も新しい推定値である。
【０３２８】
一実施例では、各メディアユニットに対するパケット数は一定値に保持される。従って、すべてのｉに対し、Ｍi＝Ｍとなる。従って、パケットサイズＰiを適応化することにより、速度適応化を達成する。
【０３２９】
目標は、期待される遅延時間制限（式３０）を受ける単一メディアユニットｉに対する速度を選択することであるので、式３０が成立するユニットｉに対する最大速度を選択するだけで充分である。データユニットｋ、ｋ＋１、…、ｉ−１は既にコード化され、エンコーダ内に記憶されているか、または、送信待ち合せ内にあることに留意されたい。従って、時刻ｓiにおいて、システムはユニットｉの速度を単に変更するだけでよい。換言すれば、時刻ｓiにおいて、システムは次の式が成立するように最大のＰiを選択することができる。
【０３３０】
【数５３】
2007184913.tif 000054
【０３３１】
特定の実現例では、ペイロードサイズの離散的な組、例えば｛７２、１７２、…、１３７２、１４７２｝の組を定めることができる。次に、システムは、下記の式を最も良く満足するこの組から、Ｐiに対する値を選択する。
【０３３２】
【数５４】
2007184913.tif 000055
【０３３３】
ここで、Ｆは締切期限感度ファクタであり、Ｆが小さい場合、システムは締切期限に対して極めて敏感であり、一般に、データユニットに対して、より小さいビットレートを選択する。Ｆが大きい場合、システムはあまり感度が高くなく、一般に、より大きいビットレートを選択する。このことは、目標配信時刻を決定することに等しい。すなわち、期待配信時刻が目標配信締切期限に一致するように、データユニットに対するビットレートを選択することに等しい。
【０３３４】
最も小さい許容可能な速度（最も小さいペイロードサイズＰi）を使用しても、（期待される）遅延時間制限値を満たすことができない場合、適応化技術においてデータユニットｉを廃棄すること、すなわち、データユニットを送信しないことが望ましいと判断できる。
【０３３５】
送信機の適応化技術では、最も旧いデータがまだ送信機バッファ５２０および５２２内にある間、このデータのインデックスＫについて知っていなければならない。すなわち、待ち合せにまさにデータユニットｉを加えようとしているときに、どれだけ多くのデータユニットがまだエンコーダ内およびネットワークの待ち合せ内に存在するかをわかっていなければならない。適応化アルゴリズムではエンコーダバッファ内に記憶されているデータユニットの数についてわかっているが、実現例によっては適応化アプリケーションが送信待ち合せにアクセスできないので、ネットワークバッファ内に記憶されているデータユニットの数に関する情報は役に立たない。この数を推定する１つの技術は次のとおりである。受信機がデータユニットを受信すると、受信機は、可能なら推定されたバンド幅だけでなく、データユニットのインデックスも含むフィードバックを送信側に提供する。次に送信機は、時刻ｓiにフィードバックを受信した最後のデータユニットが、その時刻に受信機に到達した最新のデータユニットに対応するものであると見なす。従って、送信機がフィードバックを受信した最新のデータユニットのインデックスがｕである場合、送信機はｋ＝ｕ＋１であると推定する。
【０３３６】
上記を仮定すると、送信機は次に式３２からＰiを選択できる。この値は図４０に示された技術によって示すことができる。
【０３３７】
この技術の別の実施例では、全てのメディアユニットに対するパケットのペイロードサイズは一定値に保持される。すなわち、すべてのｉに対し、Ｐi＝Ｐである。従って、異なるデータユニットｉに対し、パケットの数Ｍiを適応させることにより、速度適応が達成される。
【０３３８】
この場合、データユニットｉに対し、次の式が成立するように、システムは最大のＭiを選択できる。
【０３３９】
【数５５】
2007184913.tif 000056
【０３４０】
前と同じように、実際のアプローチはＭiに対する値の離散的セット、例えば｛２，３，…、ＭＭＡＸ｝の組を定めることである。次に、下記の式を最も良く満足する。この組からＭiに対する値を選択する。
【０３４１】
【数５６】
2007184913.tif 000057
【０３４２】
最小の許容可能なレート（パケットの最小の数Ｍi）を使用しているときでも、（期待される）遅延時間制限値を満たすことができなければ、適応化アルゴリズムではデータユニットを廃棄すること、すなわち、データユニットを送信しないと判断することができる。この結果、図４１に示されるような速度適応化技術が得られる。
【０３４３】
更に、別の実施例では、パケットの数だけでなく、パケットの各々に対するペイロードサイズを適応化することができる。
【０３４４】
これまで説明した技術は、データユニットの期待送信時間長さ（または期待される利用可能なバンド幅）と無線チャンネルの条件との関係を明らかにモデル化するものではない。この技術は、時間長さ（または利用可能案バンド幅）がパケットサイズによって決められることも無視する。これに適合させるために、システムはψ（Ｐ，θ）をペイロードサイズＰを有するパケットの、無線チャンネル（例えば、８０２.１１の無線チャンネル）を通したときの期待送信時間長さであるとする。ここで、θはチャンネル条件である。チャンネル条件θはＳＮＲ、ＢＥＲ、ＰＥＲまたはその他のパラメータによって定義でき、受信機から得られるフィードバックから、または、送信機に直接利用できる情報から推定できる。期待される時間長さは任意の適切な技術を使って計算できる。上で述べたように、ψ（Ｐ，θ）の値は、Ｐおよびθの値の離散的組に対して表にできる。
【０３４５】
８０２.１１ａ、８０２.１１ｇまたはその他のプロトコルに対し、同様の表を作成できる。表内のＭＳＤＵサイズおよびＢＥＲの値は、単なる例であり、適切であればその他の値も使用できる。
【０３４６】
【表１】
2007184913.tif 000058
【０３４７】
データユニットｊの期待時間長さは次の式によって計算される。
【０３４８】
【数５７】
2007184913.tif 000059
【０３４９】
送信機で得られる最新のフィードバックから推定されるチャンネル条件を使ってデータユニットｊ＝ｋ、ｋ＋１、…、ｉ−１、ｉの期待される時間長さを予測することによって、更に簡略化できる。速度適応化では次の式が成立するように、データユニットｉに対しする速度ｒi＝Ｍi・Ｐiを時刻Ｓiで選択する。
【０３５０】
【数５８】
2007184913.tif 000060
【０３５１】
次のように、３つの別個の技術を定義できる。最初の技術では、各データユニットに対するパケット数を一定値に保持する。すなわち、すべてのｉに対し、Ｍi＝Ｍとする。従って、パケットサイズＰiを適応化し、前述の技術によって速度適応化が達成される。パケットサイズＰiの選択は、式３４に基づいて行うことができる。
【０３５２】
第２の技術では、全てのデータユニットに対するパケットのペイロードサイズは一定値に保持される。従って、全てのｉに対し、Ｐi＝Ｐとなる。従って、上記第１の技術と同じように、異なるデータユニットｉに対するパケット数Ｍiを適応化することにより、速度適応化が達成される。Ｍiの選択は、式（３４）に基づいて行うことができる。
【０３５３】
第３の技術では、パケットの数Ｍiだけでなく、各パケットに対するペイロードサイズＰiを式（３４）に基づいて適応化できる。
【０３５４】
プロアクティブ速度適応化
現在および将来のフレームを含むビデオ画像フレームを送信するための遅延時間制限を満足するには、画像フレームに対して送信ビットバジェットを割り当てることが望ましい。このことにより、現在の画像フレームに対して最大可能な速度を選択する結果、異なるフレーム間で歪みが変化する。ＭＰＥＧ−２のような圧縮されたビデオは種々の異なるタイプのフレームを含む。Ｉフレームはイントラコード化され、Ｐフレームは前のＩフレームまたはＰフレームに基づいて予測され、ＢフレームはＩフレームおよび／またはＰフレームから双方向に予測される。異なるタイプのフレームを検討しなければ、ビデオ画質にとってより重要となるＩフレームおよびＰフレームは、エンドツーエンドのバンド幅が低下すると、重要性が低いＢフレームよりも大幅に減少する。従って、システムは遅延時間の制限を維持しながら、全件の期待歪量を下げなければならない。
【０３５５】
ビットバジェットの計算
チャンネルバンド幅が低下すると、送信できる状態にある圧縮されたＡＶパケットは、送信側／サーバ側で、ＭＡＣ層内の待ち合せ（バッファ）またはアプリケーション層内の送信バッファのいずれかでバックログ状態となる傾向がある。新しく送信されるパケットはバックログされたパケットが送信されるまで待機しなければならない。クライアントが初期のバッファリング終了時刻（遅延許容値）までにビデオフレームを受信しない場合、バッファのアンダーラン（アンダーフロー）が生じる。従って、ＡＶサーバは送信側のパケットバックログをスレッショルドより低く維持するか、または目標レベルに維持することにより、かかるアンダーランを低減しなければならない。
【０３５６】
図４２を参照する。第１ステージで、提案された技術により現在のフレームと、Ｈ個の将来のフレームから成る画像フレームのブロックまたはシーケンスに対する全送信ビットバジェットを計算する。このバジェットはこのブロック内の最後のフレームの最終パケットが受ける期待遅延時間が、より小さいかあるスレッショルド値に等しくなるように制限されている。このスレッショルド値は最大バッファ    に対する目標レベルに等しい。同じように、指定された配信時刻前にブロックの最終フレームがクライアントに送られるように、当該画像フレーム（現在フレームとｈ個の将来のフレームとを含む）のブロックに対する全送信ビットバジェット（配分計画値）を計算する。全送信ビットバジェット（配分計画値）がブロック内の画像フレームの元の全サイズよりも小さい場合、ビデオのレートは、これらｈ＋１個のフレームに対応する時間フレーム内に低減されなければならない。
【０３５７】
この技術の第２ステージは第１ステージで計算された全ビットバジェット（配分計画値）のうちのどれだけを現在のフレームに割り当てるべきかを判断することである。ブロックに対する全ビットバジェットにおける制限の個々のフレームに対する効果は、ブロック内のフレームの数（ｈ＋１）が増加するにつれ、より緩和されることが認められる。ブロックが１フレームしか含まない（すなわち、ｈ＝０）とき、ブロックに対する全ビットバジェットはその単一フレームに割り当てられるビット量を直接決定する。しかしながら、ブロックが多数のフレーム（ｈ≧１）を含むとき、この方式では、全ビットバジェット（配分計画値）の範囲内で、ブロック内の異なるフレームに異なる量のビットを割り当てることができる。このような能力は、全体のビデオ画質を高めることが判っている。その理由は、異なるフレームは異なるコーディング複雑度または速度歪み特性を有するからである。従って、提案される速度適応化方式はブロック内のフレーム数が増加するとき、ブロック内の異なる画像フレームをコード化するのに必要とされるビット量を可変にする能力を高める。更に、将来のフレームを速度適応化でプロアクティブに考慮することにより、バッファのバックログの増加を防止できる。
【０３５８】
第１ステージにおけるフレームのうちの１ブロックに対する全送信ビットバジェット（配分計画値）を決定する。遅延時間制限値は、次の式によって特徴づけられる。
【０３５９】
【数５９】
2007184913.tif 000061
【０３６０】
ここで、この上記式は次の項を含む。
ｒblockは、現在およびｈ個の将来のフレームのブロックに対する全送信ビットバジェット（配分計画値）を示す。
Ｈ∧は、チャンネルの推定バンド幅を示す。
ΔＴEは、初期のプレイアウトバッファ時間長さ（エンドツーエンドの遅延時間の許容値）を示す。
Ωは、ΔＴEによって表される送信機のバックログターゲットを決定する一定の乗数である。
ΔＴは、フレーム間間隔（フレーム速度によって決まる）である。
Ｂ∧は、送信機における現在の推定バックログサイズである。
【０３６１】
Ω・ΔＴE＋ｈ・ΔＴはフレームのブロックに対する遅延時間制限を示す。
【０３６２】
【数６０】
2007184913.tif 000062
【０３６３】
は、ブロックの最初のフレームに対する推定待ち合せ時間（待ち時間）と解釈できる。ブロック（ｈ＋１）の最適サイズおよび遅延時間パラメータΩの値は固定してもよいし、マニュアルで選択してもよい。これらパラメータの双方は、初期のプレイアウトバッファ時間長さが長くなるにつれ、より大きい値にセットすることが望ましい。バッファ時間長さに基づくパラメータのルックアップテーブルは、これらパラメータを自動的にセットするのに使用できる。
【０３６４】
歪みが最適にされる割り当て
次のステップは、現在のフレームに速度低減を実施するかどうか、またはどの位実施するのかを決めることである。この目標は、速度低減によって生じる全歪みを低減し、時間に対する画質の変化を制限することにある。従って、現在のフレームに対する速度選択を、近い将来に送信すべき多数のフレームと共に実行すべきである。更に、ブロックサイズに対する歪みの最適化を行うために共に検討する将来のフレームの数を制限することも望ましい。ブロック内のフレームの組はフレーム｛ｉ、ｉ＋１、ｉ＋２、Ｙ、ｉ＋ｈ｝によって与えられる。フレームｊ（ｉ≦ｊ≦ｉ＋ｈである）に対するビットの元の量をνjと表示する。送信のために、フレームｊに割り当てられるビット量（トランス・レーティング後の）をｒjと表示する。従って、ｘjで表示されるフレームｊに対する速度低減比は、νjに対するｒjの比によって決定される。すなわち次のとおりである。
【０３６５】
【数６１】
2007184913.tif 000063
【０３６６】
速度適応は、全歪みを最小にしながら、全ビットバジェット（配分計画値）を超えないように、フレームｊ、ｉ≦ｊ≦ｉ＋ｈに対するｒj、すなわち等価的にｘjの値を決定しなければならない。
【０３６７】
個々のフレームの速度低減比の関数として、ブロック内のフレームの全歪みを表す方法が望ましい。かかる関数を決定することは実現可能であるが、問題の次元の数がブロック内のフレームの数と共に大きくなるので、一般に、極めて困難な作業である。更に、速度低減比の許容可能な値によって与えられる高い次元の探索範囲にわたって歪みを最適にすることは計算上極めて複雑であり、時間のかかることとなる。全歪み値を近似する簡略的なアプローチは、ある時間の単一フレームを速度低減することによって生じる全歪みに対する効果を検討することである。このようなやり方で問題をブレークダウンすることにより、下記に示すように極めて簡単に歪み最適解を計算することができる。
【０３６８】
トランス・レーティングまたはスケーラビリティにより画像フレームのサイズを縮小すると、そのフレームおよびそのフレームを基準として使用するフレームの画質が劣化する。コーディングのタイプ（Ｉ、ＰまたはＢ）およびＧＯＰ（画像のグループ）内部の位置によって、これらのフレームの速度−歪み特性が大きく異なることが理解できよう。例えば、Ｉフレームのビットレートを低減することにより、ＧＯＰのすべてのフレーム内に歪みが生じる。その理由は、ＧＯＰ内のすべてのフレームは、Ｉフレームに依存しているからである。次のＰフレームをコード化するための基準としてＩフレームが使用され、次に、このＰフレームがその次のＰフレームをコード化するための基準として使用される。更に、Ｂフレームをコード化するための基準として、ＩフレームおよびＰフレームが使用される。他方、Ｂフレームのビットレートの低減は１つのフレームすなわちそのフレーム自身だけにしか影響しない。何故なら、Ｂフレームは他のフレームをコーディングするための基準として使用されないからである。更に、ＧＯＰのスタート近くのＰフレームはＧＯＰの終了点近くのＰフレームと比較して全画質により大きな影響を与え得る。異なる速度低減技術、例えば、トランス・レーティングおよびスケーラビリティに対し、種々のモデルを使用できる。更に、パラメータおよびモデルの種類はビデオコーデックすなわちビデオトランスコーダ、コンテント、速度、サイズおよび画像速度に応じて変わり得る。単純なモデルでも、実質的な品質改善をするために、ＩフレームとＰフレームとＢフレームとの間を区別することができる。
【０３６９】
次の記載は、トランス・レーティングに基づく速度低減のための簡単な速度−歪みモデルの使用を示すものである。速度−歪みモデルのパラメータは、ＧＯＰ内部のフレームの位置に応じて決まる。特定のフレームのビットレート低減によるブロック内の全歪みに対する効果のための線形モデルは次のとおりである。
【０３７０】
【数６２】
2007184913.tif 000064
【０３７１】
ΔＤｊの項は、単一ビデオフレームｊの速度低減に起因する当該フレームのブロック内のすべてのフレームの全歪みの変化をＰＳＮＲの低減またはＭＳＥの増加よって示す。そのフレームに対する速度低減比はｘｊである。送信のために割り当てられるビット量は元のサイズより小さいか等しくなければならない。すなわちｒj≦νjまたは等価的にｘj≦１.０以下とでなければならない。同じように、画像フレームに対し割り当てられたビット量は、最小値如何によって決まるので、速度低減比は下方に境界を定められる。このような速度低減比の下方の境界は、Ｘmin ≧０と表示される。このような下方の境界ｘminは、例えば実験に基づき、マニュアルで選択できる。ａjおよびｂjは、線形モデルパラメータを示し、これらパラメータはＧＯＰ内のそれらの位置および／またはフレームのコーディングタイプ（Ｉ、ＰまたはＢ）によって、フレームごとに変化する。これらパラメータは、サンプルビデオテストシーケンスを使って、または、前に処理されたビデオフレームからダイナミックに抽出することができる。
【０３７２】
全歪みに対する単一フレーム内の速度低減の効果の指数モデルは次のとおりである。
【０３７３】
【数６３】
2007184913.tif 000065
【０３７４】
再び、ａjおよびｂjはモデルパラメータを示し、これらパラメータはフレームごとに変化し、前に処理されたビデオフレームから推定できる。指数モデルは上記線形モデルよりも良好に、速度−歪み特性を把握することができる。しかしながら、対数をとることにより、この式をｘjで示された線形方程式に変えることができ、このモデルは下記に提案するように模範的な複雑度が低い解を与える。
【０３７５】
次のようにフレームのブロック内の歪みを最適にするのに、上記速度−歪みモデルを使用できる。提案された方式の目的は、歪み変化値ΔＤｊで示されるような個々のフレームのビットレート低減効果を最小にすることにある。このことは、フレームｉ≦ｊ≦ｉ＋ｈの間の歪み変化ΔＤｊの最大値を最小にすることによって達成できる。このような最適化の目標は歪み変化ΔＤｊの値が等しいときに得られる。従って、歪み最適化の１つの目的は、全ブロック歪みに対する個々の効果ΔＤｊ（ｘｊ）がほとんど等しくなり、全送信ビットバジェット（配分計画値）を超えないように、個々のフレームｘｊに対する速度低減比を決定することである。これらの制限は次のように記載できる。
【０３７６】
【数６４】
2007184913.tif 000066
【０３７７】
上記速度−歪みモデルが与えられると、速度に関する下方の境界および上方の境界を満足するように、上記線形式を繰り返し使用することにより、限られた計算パワーでこの問題を解くことができる。この繰り返し方法は次のように進行する。
【０３７８】
【数６５】
2007184913.tif 000067
【０３７９】
前に述べたように、この速度適応化アルゴリズムは各フレームを送信する前に作動する。現在のフレーム（フレームｉ）に対して計算された送信サイズが元のサイズ未満である場合、フレームのサイズを計算した値（ｒi）まで減少させる。他のフォームのスケーラビリティにより、フレームをトランスレートまたは縮小し、次に無線チャンネルを通して送信することができる。この方法は現在のフレームに続くブロック内のフレームに対して割り当てられるビットレート（または速度低減比ｘj）を計算することができるが、システムは実際には計算されたこれらのビットレートを使用しなくてもよいことに留意されたい。その代わりに、この方法は次のフレーム（フレームｉ＋１）をコーディングまたはトランスコーディングするときに再び使用され、システムは新しい情報（例えば更新されたバンド幅情報）などを考慮することができるようになる。
【０３８０】
サーバにビデオコンテントが記憶されていない場合、将来の画像フレーム（νj）の元のサイズについては正確に知ることができないことに留意されたい。かかるケースでは、各ＧＯＰ位置の値νjは、同じＧＯＰ位置または同じタイプの前のフレームにおける前のフレームの平均値に基づき推定できる。
【０３８１】
速度歪み情報がない場合、フレームｉに割り当てられるビット量は第１ステージで決定されたブロックに対する全送信ビットバジェット（配分計画）および入力ビデオシーケンス内のブロックに対するビットの元の量を使用するだけで決定できる。現在フレーム（ｉ）の速度低減比は次の式で示される。
【０３８２】
【数６６】
2007184913.tif 000068
【０３８３】
現在フレームの他のブロック内のフレーム数（ｈ）は、所望すれば、
【０３８４】
【数６７】
2007184913.tif 000069
【０３８５】
を推定するのがより容易となるように選択できる。
【０３８６】
一般的には、この方法は、効率的に、またはフレームごとにフレームブロックサイズ（ｈ＋１）および送信機のバックログターゲット乗数（Ω）パレメータを選択することを目標とする。ｈおよびΩパラメータの好ましい値は、ビデオシーケンス（ビットレート、コーディング構造）、チャンネルバンド幅統計値および初期ストリーミングバッファ時間長さ（遅延時間許容値）に応じて決まる。一般に、リアルタイムでの値の選択は、最適に選択したスタティックなパラメータの選択結果に近い画質が得られる結果となる。
【０３８７】
ｈパラメータは候補整数Φ｛ｈ1、ｈ2、…、ｈn｝の有限セットから繰り返し選択される。短い遅延制限時間の場合、小さいｈの値が有効であるが、他方、長い遅延時間制限の場合、大きいｈの値が有効である。計算時間は一般に、セットサイズが大きくなるにつれ長くなる。
【０３８８】
セットの要素は、最小値ｈminと最大値ｈmaxとの間で等しい間隔に離間した整数として選択できる。一部の実現例では、最小値は２が選択され、最大値はビデオのＧＯＰサイズ（２×ＧＯＰサイズ−１）に関連する。候補値の間の間隔はＰ個のフレームの周期にひとしくなるように選択される。従って、例として、組Φ＝｛２，５，８，１１，１４，１７，２０，２３，２６，２９｝が使用される。
【０３８９】
この方法は、フレームの各々または選択された１つを送信する前に使用される。下記のように、特別に計算されたΩhを使用して候補値ｈごとにフレームブロック送信ビットバジェット（配分計画値）を計算する。
【０３９０】
【数６８】
2007184913.tif 000070
【０３９１】
次に、送信ビットバジェット（配分計画値）を使って現在のフレーム（ｉ）に対する速度低減比ｘhiを計算する。速度割り当てのために、速度歪みモデルのような他の方法も使用できる。結果として、最小速度低減比を生じさせるようなｈを選択することが望ましい。このために、現在フレームに対する有効速度低減比は次の式で示される。
【０３９２】
【数６９】
2007184913.tif 000071
【０３９３】
かかる方法は短い遅延時間制限および長い遅延時間制限の双方を満足するように働く。この結果、システムは遅延時間制限を満足させながら、速度適応化をプロアクティブにすることができる。
【０３９４】
パラメータΩは、バンド幅および推定誤りに対する待ち合せ時間に対する安全ファクタとして使用される。その最適値はｈパラメータと結合しており、次の式を使ってパラメータΩを計算することが好ましい。
【０３９５】
【数７０】
2007184913.tif 000072
【０３９６】
従って、システムは、フレームブロックサイズおよび遅延時間許容値によって決定される将来の時間間隔における推定誤りに対する最大バンド幅を計算することが望ましい。ビデオフレームのブロックに対する遅延時間制限は、ΔＴE＋ｈ・ΔＴでよい。システムは、この遅延時間制限値に等しいタイムスケールに対する最小観測バンド幅を決定しようとする。過去のｚ秒の間のバンド幅測定値の履歴も記録する。次に、システムは、この履歴に対するΔＴE＋ｈ・ΔＴ間隔ごとのバンド幅を計算する。このバンド幅のサンプルＨhminの最小値は当該将来の時間間隔の間の最悪条件の推定値である。時間スケールが大きくなるにつれ、Ｈ＾ｈｍｉｎも更に安定化し、実際のバンド幅推定値Ｈ∧により近くなる。
【０３９７】
送信ビットバジェット（配分計画値）が下記の最悪ケースのシナリオで遅延時間制限を満足するように、システムはΩh の値を計算できる。
【０３９８】
【数７１】
2007184913.tif 000073
【０３９９】
となる。
その結果、Ωhの値は、最小境界および最大境界に強く影響される。
【０４００】
【数７２】
2007184913.tif 000074
【０４０１】
あるいは、ビデオ送信中、フレームブロックサイズ（ｈ＋１）およびバックログターゲット乗数（Ω）のパラメータをスタティック（一定）値に設定できる。フレームブロックサイズパラメータはエンドツーエンドの遅延時間許容値に応じて決めることができる一定値に設定できる。同様に、バックログターゲット乗数もエンドツーエンドの遅延時間および選択されたフレームブロックサイズパラメータの値に応じて決まる一定値にセットできる。
【０４０２】
本明細書で引用したすべての引用例を参考例として援用する。
【０４０３】
上記明細書で使用した用語および表現は、発明を説明する用語として用いたものであり、発明を限定するための用語として用いたものではなく、かかる用語および表現の使用に当たり、本明細書に示し、記載した特徴またはその一部の均等物を排除する意図はなく、本発明の範囲は特許請求の範囲のみによって定義されることが認識されよう。
【図面の簡単な説明】
【０４０４】
【図１】ゲートウェイ、メディアソース、受信ユニットおよびネットワークを示す図である。
【図２】アナログエキステンダーを示す図である。
【図３】デジタルエキステンダーを示す図である。
【図４】ＧＯＰを示す図である。
【図５】バーチャルＧＯＰを示す図である。
【図６】エキステンダーのより詳細な図である。
【図７】アナログソースの単一ストリームを示す図である。
【図８】デジタルソースの単一ストリームを示す図である。
【図９】マルチストリームを示す図である。
【図１０】ＭＰＥＧ−２のＴＭ５を示す図である。
【図１１】バーチャルＧＯＰによるダイナミックな速度適応化を示す図である。
【図１２】ＧＯＰビット割り当てによるスーパーＧＯＰの低速で変化するチャンネル条件を示す図である。
【図１３】バーチャルスーパーＧＯＰのビット割り当てによるバーチャルＧＯＰのダイナミックなチャンネル条件を示す図である。
【図１４】スーパーフレームのビット割り当てによるスーパーフレームのダイナミックなチャンネル条件を示す図である。
【図１５】ストリームに対するユーザーの好みおよび優先度決定を示す図である。
【図１６】時間内の特定のポイントにおけるユーザーの好みから生じるストリームの重みを示す図である。
【図１７】任意の時間またはユーザーの要求で設定される又は変化するストリームの相対的重みを示す図である。
【図１８】ＭＡＣ層のモデルを示す図である。
【図１９】ＡＰＰＬＩＣＡＴＩＯＮ層のモデルに基づくアプローチを示す図である。
【図２０】ＡＰＰＬＩＣＡＴＩＯＮ層のパケットバーストアプローチを示す図である。
【図２１】理想的な送信および受信を示す図である。
【図２２】再送信およびより低いデータ速度へのフォールバックを示す図である。
【図２３】パック送信およびパケットの到達を示す図である。
【図２４】パックバーストの送信および到達を示す図である。
【図２５】パケットバースとの送信および誤りを伴う到達を示す図である。
【図２６】理想的条件下のパケットバーストを使用して測定された最大バンド幅を示す図である。
【図２７】非理想的条件下のパケットバーストを使用して測定された最大バンド幅を示す図である。
【図２８Ａ】パケットの受信を示す図である。
【図２８Ｂ】パケットの受信を示す図である。
【図２９】パケットの送信を示す図である。
【図３０】無線システムを示す図である。
【図３１】利用できるバンド幅および送信速度の一実施例を示す図である。
【図３２】利用できるバンド幅および送信速度の別の実施例を示す図である。
【図３３】ＢＥＲ、ＰＥＲおよびＨ’を示す図である。
【図３４】ＢＥＲの異なる値およびＭＳＤＵサイズの異なる値に対する期待される８０２.１１Ｂ  ＭＡＣの最大スループットを示す図である。
【図３５】処理システムを示す図である。
【図３６Ａ】ルックアップテーブルを示す図である。
【図３６Ｂ】ルックアップテーブルを示す図である。
【図３６Ｃ】ルックアップテーブルを示す図である。
【図３６Ｄ】ルックアップテーブルを示す図である。
【図３６Ｅ】ルックアップテーブルを示す図である。
【図３６Ｆ】ルックアップテーブルを示す図である。
【図３６Ｇ】ルックアップテーブルを示す図である。
【図３６Ｈ】ルックアップテーブルを示す図である。
【図３６Ｉ】ルックアップテーブルを示す図である。
【図３７】送信速度適応化方式の作動を示す図である。
【図３８】データのタイミングを示す図である。
【図３９】バッファを示す図である。
【図４０】１つの技術を示す図である。
【図４１】別の技術を示す図である。
【図４２】ビット割り当てシステムを示す図である。
【符号の説明】
【０４０５】
２６０…衛星ＴＶ、２６５…ケーブル、２１０…中央ゲートウェイメディアサーバ、２３０…ラップトップパソコン、２４０…コンピュータ、２５０…ビューイングユニット。
【図１】
2007184913.tif 000075
【図２】
2007184913.tif 000076
【図３】
2007184913.tif 000077
【図４】
2007184913.tif 000078
【図５】
2007184913.tif 000079
【図６】
2007184913.tif 000080
【図７】
2007184913.tif 000081
【図８】
2007184913.tif 000082
【図９】
2007184913.tif 000083
【図１０】
2007184913.tif 000084
【図１１】
2007184913.tif 000085
【図１２】
2007184913.tif 000086
【図１３】
2007184913.tif 000087
【図１４】
2007184913.tif 000088
【図１５】
2007184913.tif 000089
【図１６】
2007184913.tif 000090
【図１７】
2007184913.tif 000091
【図１８】
2007184913.tif 000092
【図１９】
2007184913.tif 000093
【図２０】
2007184913.tif 000094
【図２１】
2007184913.tif 000095
【図２２】
2007184913.tif 000096
【図２３】
2007184913.tif 000097
【図２４】
2007184913.tif 000098
【図２５】
2007184913.tif 000099
【図２６】
2007184913.tif 000100
【図２７】
2007184913.tif 000101
【図２８Ａ】
2007184913.tif 000102
【図２８Ｂ】
2007184913.tif 000103
【図２９】
2007184913.tif 000104
【図３０】
2007184913.tif 000105
【図３１】
2007184913.tif 000106
【図３２】
2007184913.tif 000107
【図３３】
2007184913.tif 000108
【図３４】
2007184913.tif 000109
【図３５】
2007184913.tif 000110
【図３６Ａ】
2007184913.tif 000111
【図３６Ｂ】
2007184913.tif 000112
【図３６Ｃ】
2007184913.tif 000113
【図３６Ｄ】
2007184913.tif 000114
【図３６Ｅ】
2007184913.tif 000115
【図３６Ｆ】
2007184913.tif 000116
【図３６Ｇ】
2007184913.tif 000117
【図３６Ｈ】
2007184913.tif 000118
【図３６Ｉ】
2007184913.tif 000119
【図３７】
2007184913.tif 000120
【図３８】
2007184913.tif 000121
【図３９】
2007184913.tif 000122
【図４０】
2007184913.tif 000123
【図４１】
2007184913.tif 000124
【図４２】
2007184913.tif 000125