複数のインターフェースを介するビデオストリーム
【課題】好適実施形態は高品質ビデオストリーミング（又はリアルタイムストリーミング）を提供するため複数のインターフェースの存在を利用するシステム及び／又は方法を提供する。
【解決手段】提案解決法は３つの特定戦略１）受信機バッファ管理、２）パケットの選択的再送信及び３）複数のインターフェースを介して高品質ビデオストリーミングを達成するためインターフェース介するダイナミック負荷バランシングを含む。
【解決手段】提案解決法は３つの特定戦略１）受信機バッファ管理、２）パケットの選択的再送信及び３）複数のインターフェースを介して高品質ビデオストリーミングを達成するためインターフェース介するダイナミック負荷バランシングを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特に、複数のインターフェースを介してビデオストリームを提供すること、とりわけ高品質ビデオストリーム又はリアルタイムストリームを提供する複数のインターフェースに関する。
【背景技術】
【０００２】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００４】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれるエンティティに分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次のエンティティの一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべきエンティティを含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（General Packet Radio Service）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（登録商標）（Global System for Mobile Communications）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（Time Division Multiple Access）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１３】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１４】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１５】
ビデオストリーム
無線メディア（媒体）を介するビデオストリームは困難な課題である。特に、これは次の顕著な理由により難問となりうる。
【００１６】
第一に、クライアントに提供されるアクセス帯域幅は、特に、無線ネットワークを用いると、大きく変化する可能性がある。干渉のようなメディア特性及びメディアアクセスの頻繁な非決定論的特性（802.11はが典型的例である）は高可変処理能力及び遅延となる。更に、今日の世界で使用されているパケットネットワークはほとんど実質的に最善努力式であり、帯域幅、遅延又はパケット欠損に保証がない。
【００１７】
第二に、ビデオストリームアプリケーションが設定する帯域幅及びジッタに関する要求は厳しくなる可能性がある（代表的なＤＶＤストリーム帯域幅は９．２Ｍｂｐｓまでとなり、ジッタは２００ｍｓｅｃ以下になる必要がある）。更に、情報源は実質的に非固定となり、しばしば使用される符号化システムはパケット間の復号化依存性を招く。これはパケット遅延（又は欠損）における小さな可変性が視聴経験の品質に重大な劣化を導くことになる。
【００１８】
特に、無線ネットワークを介するビデオストリームに関する改良について技術的に要求があった。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
本発明の好適実施形態は上記及び／又は背景技術の他の問題を克服する。
【課題を解決するための手段】
【００２０】
好適実施形態では、我々が予測する複数のインターフェースを使用するのは未来の装置に当てはまる。本発明は、アプリケーションのための帯域幅及びＱＯＳを伝達するために、このアクセスダイバーシティを開発するための知的接続性ネットワーク（intelligent connectivity framework）（本発明のシステム）に関する。複数のインターフェースがどのように使用されるかは一般のネットワーク条件だけでなくアプリケーションの特性に依存する。本発明のシステムは最も該当する接続性方策を発見し、選択し、実行し、評価するための一般的な柔軟なプラットフォームを提供する。
【００２１】
本発明は装置間で高品質のビデオストリームを送るために、総括的な本発明のフレームワーク内で使用される特定のセットの接続性戦略に焦点を置いている。しかしながら、これら戦略は本発明のフレームワークによって制限され、任意の同様な代替フレームワークを用いて又はそれ自体によって使用し得る。
【００２２】
セットの方策は次のカテゴリの下にある。
【００２３】
１．受信機バッファ管理；
２．選択的再送信；及び
３．ダイナミック負荷バランス
この明細書では、ビデオパケットを供給する局（コンピュータ）は送信機（クライアント−サーバアーチテクチャのサーバ）と呼ばれ、ビデオを受信し、その後再生する局（コンピュータ）は受信機（クライアント）と呼ばれる。
【００２４】
受信局でのバッファ管理は複数のインターフェースを通過するパケットの再整理(re-ordering)を行い、パケットをタイムリーな方法でアップリケーション（この場合にはビデオプレイヤ）に解放する。
【００２５】
本方法では、ビデオストリームはインターフェースを介して分割される（異なるインターフェースを介して送信されるパケット）。ダイナミック負荷バランスは、現ネットワーク状態及びアプリケーション特性に応じるダイナミック形式で、利用可能インターフェースを介してビデオストリームを分割するため知的選択率（intelligent selection of ratios）を参照する。
【００２６】
本方法は更に少なくとも１つのパケットを複製すること及び異なるインターフェースを介してパケットの複製を送信することを含む。故に、パケット分割は少なくとも１つのパケットを複製し、異なるインターフェースを介してパケットの複製を送信するだけでなくシーケンスパケットを分割し、異なるインターフェースを介してパケットを送信することを含む、更に、本方法はパケットの分割及び複数のインターフェースを介して送信用パケットの複製の両方のステップの組合せを含む。本発明の一実施形態では、パケット分割によるパケットは複数のインターフェースを介して同時に送信され、他の実施形態では、それは若干異なる時間で送信される。
【００２７】
３つの方策はそれらの任意の１つが他の使用を要求しないで使用し得るように十分独立している。しかしながら、それらの全てが共に使用され、互いに支援する方法で使用されるとき、ビデオ品質を更にもっと高められることになる。
【００２８】
幾つかの好適実施形態によると、本発明は高品質ビデオストリーム（又はリアルタイムストリーム）を提供するために複数のインターフェースの存在を活用する。幾つかの実施形態では、提案解決策は複数のインターフェースを介して高品質ビデオストリームを達成するため１）受信機バッファ管理、２）パケットの選択的再送信及びインターフェースを介するダイナミック負荷バランスを含む３つの戦略を含む。
【図面の簡単な説明】
【００２９】
【図１Ａ】３つの提案戦略の全てを使用する具体的システムアーチテクチャを示す。
【図１Ｂ】３つの提案戦略の全てを使用する具体的システムアーチテクチャを示す。
【図２】バッファ管理システムの概略図である。
【図３】現在の技術（１つのインターフェース）に対する遅延値のグラフ図である。
【図４】本発明のビデオ（３つのインターフェース）に対する遅延値のグラフ図である。
【発明を実施するための形態】
【００３０】
本発明の好適実施形態は、限定されないが、添付図に一例として示されている。
【００３１】
本発明は多くの異なる形態で実施できるが、複数の具体的実施形態は本開示が本発明の原理の例を提供するように考えられ、そのような例が本発明をここに記載された及び／又はここに図示された好適実施形態に限定される意図がないことを考慮してここに説明されている。
【００３２】
受信機バッファ管理
本発明のフレームの好適実施形態のシステムの下では、単一のビデオストリームに属するパケットは複数のインターフェースを介して送信される。アーチテクチャはインターフェースのタイプに制限していなく、故にしばしばインターフェースは異種である。即ち、それらは処理能力及び遅延性能を含むキャパビリティについて広範囲に変化する。重要な副次的悪影響は受信機で異常となるパケットのそれである。ビデオストリームはしばしばＵＤＰをトランスポートプロトコルとして使用されるので、エンドアプリケーションへのパケットの順序付け配送を保障するエンティティは存在しない。これらの環境下では、パケットを再順序付けし、それらをタイムリーな方法でアプリケーションに与えるため受信機端でバッファを有することが重要である。
【００３３】
リアルタイムアップリケーションパケット（及び故にビデオストリーム）が、それ以上パケットが利用できない支払期限を有する。故に、アプリケーションへのパケットの注文配送が重要なだけでなく、パケットがアップリケーションへ配送された時間が重要である。従って、異種インターフェースによって生じる故障パケット配送を処理し、それらを順序及びタイムリー方法でアプリケーションに配送する知的バッファ管理システムが必要となる。
【００３４】
プレイアウト期限基準バッファ管理
各リアルタイムパケットはプレイアウト期限と関連している。パケットがプレイアウト期限を見過ごせば、その利用は喪失する。故に、我々が受信機で使用するバッファシステムはタイムリーな方法でパケットを目標アプリケーションに供給するためにこのプレイアウト期限を知っているべきである。しばしば、記録ビデオパケット(ex: MPEG)又はＲＴＰのようなストリームを搬送するために使用されるトランスポートプロトコルヘッダは対応するパケットのプレイアウト期限を有することになる。そのような符号化／プロトコルヘッダのフォーマットを知ること及び受信機でそのような情報を処理することによって、パケット毎にプレイアウト期限を決定することが可能になる。しかしながら、本発明のフレームワークは優先的にプロトコル／符号化を独立とするので、我々はプレイアウト期限を決定する代替方法を使用する。これは限定されなく、フレームワーク／アルゴリズムが存在する本発明は何かそのような方法と連携する。提案方法の好適実施形態のために次の仮定がなされている。
【００３５】
ａ）各パケットのプレイアウト期限はパケットが送信機器で生成される時間からの固定値（許容値）である。更に、許容時間は第１パケットがターゲットアプリケーションに配送される前に受信機でバッファされている時間として計算される。
【００３６】
ｂ）送信機と受信機機器との間に局部時刻同期Tplayout = T generation + Ttoleranceが存在する。
【００３７】
プレイアウト期限に基づいてパケットをバッファし、開放するための総体的方法は下記のサブコンポーネントを有する。
【００３８】
ａ）送信機器機でのパケット処理（マーキング、タイムスタンピング）（下記１．１参照）
ｂ）受信機機器でのパケット処理（バッファリング、再注文）（下記１．２参照）
ｃ）パケットプレイアウト期限に基づいてバッファからアプリケーションへパケットを配送するバッファ管理アルゴリズム（下記１．３参照）
送信機でのパケット処理（１．１）
我々はこの部分を達成するため本発明のフレームワークの好適実施形態のパケット処理モジュールを使用する。送信機器機でのパケット処理モジュールは各パケットを受信し、カスタムヘッダを各パケットに加え、パケットが通過することになっているインターフェースに基づいて、ＩＰヘッダを適切に変更する。カスタムヘッダは適用可能な種々の分野に適応させるためにアップリケーションタイプに特定されるように設計し得る。リアルタイムアプリケーションに対して、カスタムヘッダは局所的に生成される（順次増加される）パケットｉｄ、（送信機器機で）パケット処理モジュールがパケットを受信する現地時間を示す時間フィールド、及びパケットが送られるインターフェースを示すフィールドから成る。カスタムヘッダホーマットは下記のようにできる。
【表１】
【００３９】
受信機(1.2)でのパケット処理
受信機器機には、全ての着信パケットが最初に設定されるパケットバッファが存在する。カスタムヘッダ情報を用いて、プレイアウト期限が次式によりパケット毎に計算される。
【００４０】
Tplayout = Tgeneration + Ttolerance
許容時間は第1パケットがバッファされた時間に基づいて計算される。プレイアウト時間は第1パケットがアプリケーションに配送されるまで計算されない。プレイアウト期限が満了したパケットはバッファから除外される。同様に、同じパケットの複数のコピーが受信されれば、１つのコピーだけがバッファに保持され、残りは破棄される。パケットはパケットｉｄフィールドに基づいて（必要なら）再順序付けされ、最後にカスタムヘッダが取り去られる。パケットは（下記に与えられる）アルゴリズムがそれらをアプリケーションに放出することを決定するまでバッファに待機する。
【００４１】
バッファ管理アルゴリズム(1．3)
発見的アルゴリズムはパケットをアプリケーションに放出することを起こさせる一組の規則／閾値に基づいている。一度パケット放出が決定されると、パケットのグループはアプリケーションに配送される。むろん、本発明のシステム及びその実施はこのアルゴリズムによって限定されなく、その他のそのようなロジックと連携する。バッファ管理アルゴリズムはパケットのグループがアプリケーションに放出される時間及び開放されるパケットの数を決定する。
【００４２】
パケットの放出
下記のセットの規則／閾値が最新バージョンのアルゴリズムでパケットの放出を引き起こすために使用される。
【００４３】
１）最後に配送されたパケットのプレイアウト期限が満了しようとしている。
【００４４】
２）パケットバッファの列の長さが閾値を超えている。
【００４５】
３）最後のパケットの放出以降の時間が閾値を超えている。
【００４６】
第２条件は実施時固有の理由のために必要であり、使用されるオペレーティングシステム／ハードウエアプラットホームのタイプに基づいて変えることができる。（パケットがアプリケーションに配送されなかったとき）初めて、プレイアウト期限が決定し得ないので、条件２及び３だけが使用される。アルゴリズムに使用される他のパラメータは（パケットｉｄに基づいて）配送されるべき次のパケットがバッファに存在するかどうかである。これは変数：nextPktAvailableを用いて示される。規則のセットが以下に与えられるようにより正確に特定される。ここでは、CurrentTime変数は現在時間を示しており、QueueLengthはパケットバッファの現在の長さである。Treleaseは最終セットのパケットが配送されたときの時間を示している。
CurrentTime > Tplayout - Tthreshold2 ---- 条件 I
又は
QueueLength > QL threshold2 ---- 条件 II
又は
CurrentTime > Trelease - Tthreshold4 ---- 条件 III
又は
((CurrentTime > Tplayout - Tthreshold1) OR (QueueLength > QL threshold1) 又は
(CurrentTime > Trelease - Tthreshold3)) AND (nextPktAvailable ==1) ---- 条件 IV
条件I, II, IIIは個々の規則1), 2), 3)にそれぞれ対応する。条件IV配送されるべき次のパケットがバッファにおいて利用可能である条件(nextPktAvailable==1)と同様に条件の各々の集合規則である。キーは閾値変数：
Tthreshold1, Tthreshold2, Tthreshold3, Tthreshold4, QLthreshold1, QL threshold2
に対して適切な値を設定することである。
【００４７】
閾値選択において次のセットの関連性を維持することがアルゴリズムの効率を確実にするのに重要である。
【００４８】
Tthreshold1 > = Tthreshold2
Tthreshold3 > = Tthreshold4
QL threshold1 < = QL threshold2
我々が現実施形態において使用する特定セットの値は：
Tthreshold1 = 100 msec, Tthreshold2 = 50 msec,
Tthreshold3 = 10 sec, Tthreshold4 = 5 sec,
QL threshold1 = 800, QL threshold2 = 800
である。
【００４９】
放出されるパケットの数
利用可能な他の重要なシステムはどれだけ放出されるかのパケットを放出する決定を与えられる。現在の設計では、我々はこれを次の喪失パケットまで又は所定の閾値数のパケットのいずれかとして設定する。いずれも放出パケットの数に関しては少なくなる。使用された閾値はQL threshold3 < QL threshold1の場合にはQL threshold3であり、我々は現実施形態では、値QL threshold3 = 400を使用している。
【００５０】
アルゴリズムの重要な特徴はそれが動的に設定される閾値値を予想することである。閾値値は最終的にエンドユーザを規定して、どのくらいの開始バッファリングが生じるか及び頻繁にどれくらいパケットが放出されるかを制御する。閾値変数がどこに設定されるかに基づく可能候補である若干のパラメータは：
１）アプリケーションタイプ／パラメータ（例えば、ボイス、ビデオ、ゲームなど）
２）トランスポートプロトコル／パラメータ
３）オペレーティングシステム／ハードウエアプラットホーム、及び
４）ネットワーク状態
パケットの選択的再送信
多くの場合、ネットワークを介して送信されるパケットはネットワークのいろいろな障害により（プレイアウト時間を超えて）遅延し又は喪失する。両事例では、そのようなパケットは受信機側アプリケーションで展開するために使用できない。幾つかのリアルタイムアプリケーション、特に、ビデオに対しては、符号化は単一のパケット損失さえも複数のパケットを介して伝播させる（復号化依存性）。結果はエンドユーザ経験の品質の重大な低下となることが多い。無線アクセス又はベストエフォートサービスだけを提供するコアＩＰネットワークに依存することは確かに、再生されているビデオの頻繁な中断及びピクセル化のための方策である。故に、高品質エンドユーザ経験を持たせるために、そのようなネットワークを用いている間は、できるだけ多く欠損又は遅延パケットの数を減らす新たな戦略を持つことは重要である。
【００５１】
パケットを複製すること又は誤り訂正符号化の他の形態を使用することはこの問題を扱う１つの方法である。しかし、無線ネットワークでは、性能（遅延、欠損）は殆どの期間で妥当であり、パケットは短い集中期間だけ遅延／欠損することは非常に一般的である。そのような場合、種々形態の誤り訂正符号化はそれが消費する時間とメモリのような資源は言うまでもなく少ない無線帯域の非効率な使用となる。選択的再送信は遅延／欠損パケットの数を最小にするための帯域幅効率的及び効果的方法である。そのようなシステムの下で、受信機は選択された数のパケット（紛失したもの）を送ることを送信機に要求し、送信機はそれらのパケットを再送信することになる。紛失パケットの再送信を要求するときを決定するのはシステムの効率と効果を特徴付けるときに重要となる。本発明はビデオパケットの選択的再送信の戦略及び特定パケットの再送信を知的に要求するアルゴリズムを提供する。
【００５２】
戦略は次のサブシステムから成る。
【００５３】
ａ）すでに送信されたパケットのコピーを必要ならそれらを再送信し得るようにバッファし、バッファサイズが無限となるように適切な時間にバッファされたパケットを破壊するメカニズム（２．１）。
【００５４】
ｂ）送信機から特定パケットを要求する受信機のためのメカニズム（２．２）
ｃ）紛失／欠損パケットを最小にすることに関して効果的であり、帯域幅利用に関して効率的である、紛失パケットを再送信することを要求するときを決定するアルゴリズム（２．３）
ｄ）１以上のインターフェースを介して、パケットを再送信するための最も効果的な戦略を送信機が決定するためのシステム及びアルゴリズム（２．４）。
【００５５】
送信機側再送信バッファ（２．１）
パケットが初めて送信されるとき、パケットのコピーが作られ、送信機機器でパケットバッファに記憶される。後に受信機が特定のパケットの再送信を要求すると、それはパケットバッファ(送信機側)に記憶されたコピーを使用して行え得る。
【００５６】
しかしながら、全てのパケットのバッファリング（一時保存）は大きな必要メモリを招くことになる。必要メモリを最適化するために提案方法は送信機側バッファに記憶されたあるパケットの解放を決定するため受信機機器からのフィードバックを使用する。現在の実施では、受信機は全ての先のパケットが受信されてしまうときまでパケットのパケットｉｄを周期的にフィードバックする。その後、送信機はこのパケットまで全てのパケットに対してバッファを解放する。この方法、パケットの送信機側バッファリングによって使われるメモリは最小値に保たれる。
【００５７】
再送信パケットに対する受信機の要求（２．２）
受信機機器は選択パケットの再送信のためのその要求を送信機に知らせる必要がある。再送信要求（保存帯域幅）の数を最小にするために、再送信要求は可能なときはいつでもグループ化されることが提案されている。
【００５８】
本発明のフレームワークの好適実施形態に存在する制御チャネルは再送信を要求されるパケットｉｄｓのリストを送るために使用される。更に、各再送信の緊急性を示す方法が存在すべきであることが提案されている。これは各再送信パケットｉｄに付帯された追加のフィールドの形態であるか、或いはレベル当たりのパケットｉｄｓの順序付リストが続いている各レベルに属する緊急要求の数の計数値である。各再送信要求の緊急レベルを知ることは送信機が要求の種類毎に個別の再送信方策を持つことに役立つ。そのようなメカニズムが選択的再送信方法の効果及び効率を確実にするよう設計される。
【００５９】
一例として緊急性の２つのレベル、URGENT及びNORMALが存在すると仮定する。緊急レベルは所定時間閾値内でプレイアウトされる予定であるパケットを表すことができ、正常の物はその期限を超えるプレイアウト期限を有する。再送信メッセージフォーマットはリスト又はURGENTパケット及び最後にNORMALパケットのリストが続く、各レベルに属する要求の数を示す２つのフィールドを有することができる。
【００６０】
再送信要求アルゴリズム（２．３）
このアルゴリズムの機能は紛失パケットの再送信を問い合わせるときを決定することである。再送信要求はパケットのプレイアウト期限が過ぎる前に再送信パケットが受信機に到達することを確実にするため十分速くなされる必要がある。同時に、無線ネットワークで遅延／欠損の予測不可能な本質だけでなく複数の異種インターフェースを介して送信されているパケットにより、我々はパケットが送信中である可能性がある事実を説明する必要がある。既に送信中であるパケットに対して早急な再送信を要求することは無線帯域の能率的でない使用に導くことになる虞がある。故に、一方では、期限前の成功するパケット受信の確率が早急な再送信要求によって改善でき、他方で、より多くの無線帯域が早期に（及び不必要な）再送信によって消費される。（欠損を最小化する及び帯域幅を最大化する）２つの態様の間のトレードオフはしばしばネットワーク特性だけでなくアプリケーションの性質に依存する。特に提案の選択的再送信システム及びアルゴリズムはシステム要求及び動作条件に基づいてこのトレードオフを制御するパラメータを有する。
【００６１】
アルゴリズムによって実行される特定機能は
ａ）適切な時間に潜在的に‘紛失’としてパケットを認識する。
ｂ）適切な時間に再送信要求を送信する。
ｃ）紛失パケット毎に緊急性のレベルを認識する。
【００６２】
以上のように、帯域幅を節約するために再送要求は可能なときはいつでもグループ化される。故に、我々はパケットが‘紛失’として認識されるときと実際の再送信要求がなされるときの２つの異なる時刻を潜在的に有する。
【００６３】
（所定のパケットｉｄを持つ）パケットは下記のときに紛失と見なされる。
ａ）（パケットｉｄｓによって与えられるように）紛失パケットの直前に（順序付けられた）バッファに存在するパケットのプレイアウト期限が所定の閾値時間内にある。
ｂ）紛失パケットｉｄと最新パケットｉｄ（パケットｉｄｓが常に増加していれば最大パケットｉｄ）との差が閾値を超える。
【００６４】
再送信要求は‘紛失’パケット及び
ａ）最後に順序付けられたパケットのプレイアウト期限が満了しようとしている、
ｂ）タイムアウト値が最後の再送信要求（周期的再送信要求）がなされたときから生じる、
ｃ）紛失パケットの合計数が所定の閾値を超える、
ときに成される。
【００６５】
特定パケットの再送信要求の緊急性レベルの決定は下記に基づくことができる。
ａ）（パケットｉｄｓによって与えられているように）紛失パケット直前に（順序付けられた）バッファに存在するパケットのプレイアウト期限、
ｂ）紛失パケットの合計数は所定の閾値を超える。
【００６６】
現在の実施では、パケットは紛失パケットｉｄと最新パケットｉｄ（パケットｉｄｓが常に増加していれば最大パケットｉｄ）との差が１００を超えるとき紛失と見なされる。再送信要求は０．１秒毎に周期的に行われ、全てのパケットの緊急性レベルがURGENTに設定される。
【００６７】
プレイアウト期限と関連して使用される閾値はバッファされたパケットをアプリケーションに放出するためのトリガを決定するため先のアルゴリズムに存在するそのような閾値に依存すべきであることを留意することが重要である。
【００６８】
再送信方策アルゴリズム（２．４）
送信機は特定パケットに対する最新要求を一度受けると、それは緊急レベルに基づいて再送信方策を決定する。複数のインターフェースの存在はインターフェースの任意の組合せを介して再送信するオプションを送信機に与える。そのような戦略の１つに全ての利用可能インターフェースを介してＵＲＧＥＮＴレベルを持つパケットの複数のコピーを再送信し、ＮＯＲＭＡＬレベルパケットを再送信するために１つのインターフェースだけを使用することがある。
【００６９】
我々の最近の実施では、使用される戦略は良好な品質となると決定される全てのインターフェースを介してパケットの複数のコピーを再送信することである。インターフェース品質は経験したエンドツーエンド遅延又は他のチャネル品質判定を用いて判定される。
【００７０】
インターネットを介したダイナミック負荷バランス
パケットは複数の利用可能インターフェースを介して送ることができるのであれば、エンドツーエンドパケットは遅延し、故にストリーミング性能はストリームが複数のインターフェースを介してどのように分割されるか（インターフェース当たりのパケット数）に依存する。バッファリングメカニズムと選択的再送信を関連して使用される第３及び最終手法は利用可能インターフェースによって搬送されるパケットの量を適正に変えることである。無線インターフェース／ネットワークは有効処理能力、時間関数としての遅延及び欠損のような幅広く変化する特性を有することが知られている。フェーディング又は干渉によって生じるチャネル状態での変化、ネットワークを用いて他の局によって生じる媒体に関するトラフィックの突然のバースト、及び無線カード／装置ドライバの性能問題が不確実要素の幾つかの引き金となっている。そのような期間において、ネットワークを介して送信されるパケットは大きく欠損又は遅延されることになる可能性がある。故に、固定された数／率のパケットを種々インターフェースに割当てる送信戦略は無線ネットワークを介するストリームに余り適さない。ネットワーク状態及びアプリケーション特性に基づいて配分戦略を適正に変更することがキーとなる。しかしながら、ネットワーク状態をモニタし、種々の障害を予測できることが挑戦となる。ネットワーク状態の幾つかの特徴、特に、RF特性はその無線装置の装置ドライバについて質問することによって取得し得る。しかし、異種無線装置タイプを問い合わせるための共通ＡＰＩは存在しないことに留意し、故に、使用されたベンダー特定装置ドライバの詳細知識はこれを達成することを必要とされる。媒体を用いて他の局によって生じるネットワークにおけるエンドツーエンド遅延又は輻輳をモニタすることは非常に挑戦的であり、帯域外信号伝達を使用してしばしば行われる。この動作は関連するネットワークオーバヘッドだけでなく特定のプロトコルを必要とする。最後に、状態は非常に頻繁に変わり、重要な無線帯域のコストで繰返しモニタすることを必要とさせる。
【００７１】
本発明は出来るだけ外部プロトコル／オーバヘッドを少なく使用するだけでなくスペクトルを効率的に使用する有効な技術を提供する。更に、装置及びプロトコル不可知識論である本発明の考え方と歩調を合せると、我々の解決法は装置又はプロトコルについて特定の知識又は仮定を用いない。
【００７２】
ロードバランシングシステムに含まれるサブシステムは
ａ）ネットワーク状態について現行情報を提供する測定／モニタシステム、
ｂ）現在のネットワーク状態及びアプリケーション特性を考慮して、各インターフェースへの負荷率を決定するアルゴリズム
である。
【００７３】
測定／モニタシステム（３．１）
提案測定／モニタ戦略の重要な態様は
ａ）ネットワーク状態を特徴付けるデータストリーム性能パラメータを使用する、
ｂ）帯域外信号伝達を最小に保って、帯域内信号伝達及び帯域外信号伝達の組み合わせを使用する、
ことである。
【００７４】
装置ドライバ又は８０２．２１のような他のプロトコルを問い合わせることを介して利用できるネットワーク状態についてのこれ以上の測定／情報が容易に使用できる。しかしながら先に述べたように、重要な特徴はシステムがそのような情報に依存しないが、その代わりに一次ソースとしてデータストリーム性能パラメータを使用することである。
【００７５】
我々はインターフェース当たりのエンドツーエンド遅延測定及びインターフェース当たりの紛失／欠損パケットの使用を提案する。両者は送信戦略を評価するため現在のデータストリームを用いて測定される。これらの両パラメータは既に存在し、更に現在のネットワーク状態の効果の良好なインジケータである。目的はデータストリーム性能パラメータを改善する（遅延を最小にする、紛失を最小にする）ことであるので、最適化を行うため１ネットワーク当たりに同じパラメータを測定し、使用することは非常に適正な方法である。これは帯域外信号伝達を用いて信号長又はエンドツーエンド遅延のような他のネットワーク性能メトリックスをモニタし、測定する必要がない明確な利点を超えている。
【００７６】
各送信パケットはそれが送信されたインターフェースを示すカスタムヘッダにフィールドを有するので、受信側でインタフェースメトリック当たりのトラックを維持することが出来る。受信パケット毎に、受信機はタイムスタンプ値に基づいてエンドツーエンド遅延を計算する。定期的に受信機は（個定数のパケットが受信された後にも可能である）インターフェース毎に平均パケット遅延を決定し、本発明の制御チャネルを用いてこの情報を送信機機器にフィードバックする。選択的再送について先のセクションで説明したように、再送信要求を受けるときの送信機はインターフェース毎に紛失／欠損パケットを決定することもできる。
【００７７】
ダイナミッ負荷分散のためのアルゴリズム（３．２）
送信機器は定期的にインターフェース毎にパケット遅延及び欠損率をフィードバックする。これら２つのメトリックス（及びなお幾つかの他のもの）を用いて、各インターフェース品質がコスト関数（０と１の範囲）としてとらえられる。インターフェース毎のコスト関数はインターフェースを用いるときに性能劣化の観点からコストを表している。０のコスト関数はインターフェースを使用する際の優れたインターフェース状態及び品質の低下なしを表し、これに対して１はインターフェースを介して送信されるパケットの受入れられない品質を表している。
【００７８】
我々が行ったパケット遅延及び欠損の関数としてコスト関数の１つのそうような実現は以下の表のように与えられる。
【表２】
【００７９】
平均遅延がゼロのとき、それは幾つかの理由による可能性がある。送信機は期間中にそのインターフェースを介してどのパケットも受信機に送信しなったかもしれない、或いはインターフェース品質が送信パケットのどれも受信されなかったような悪いものであった可能性がある。他の理由はフィードバック情報を知らせるパケットの紛失である。故に、遅延値が０であると、コスト関数値はいくつのパケットが先の期間中にそのインターフェースに送信されたか、そうであればコスト関数が１に設定されているか、そうでなければ値は０．２５であるかに基づいて決定される。
【００８０】
インターフェース当たりのコスト関数が計算されると、次式で与えられるように、同じに先のコスト関数値の全体について平均化することによって時間平均コスト関数が計算される。
【数１】
【００８１】
最後に、適切な平均化コスト関数値がインターフェース毎に計算されると、各インターフェース利用率によって重み付けられたコスト関数の線形組合せが求められる。それは目的関数として寄与する重み付け全コストである。インターフェース利用率（所定インターフェースを介して送信されるべきパケットの％）を計算するアルゴリズムが次の線形プログラミング式によって集約し得る。
【数２】
【００８２】
を前提とする。
【００８３】
平均遅延を最小にすることを含む広範囲のアルゴリズム及び他の非線形アルゴリズムが利用できることに留意する。記事に記載された特定アルゴリズムはたたき台で現在実施されている代表的なものである。
【００８４】
目標化システム／ネットワークアクチュエータ
提案戦略（及び図１に与えられるような結果のアクチュエータ）は複数のインターフェースと共に装置によって使用されることを目標とされる。最適ネットワークアクチュエータは単一送信機単一受信機アクチュエータであり、これは今日のインターネットに最も一般的である。戦略は戦略及びアーチテクチャに適正な変更を行って、マルチキャストシナリオ（単一送信機、複数受信機）及び複数送信機単一受信機シナリオにも適用できる。
【００８５】
好適実施形態において最も望ましく作用するシステムに必要な最も重要な要素は：
ａ）エンドホスト間に複数のインターフェース（ネットワーク経路）の存在；
ｂ）（送信機及び受信機機器で必然的でない）複数の経路のエンドポイントで戦略を実施するソフトウエア
である。
【００８６】
同様に、記事がビデオアプリケーションだけを記載しているけれども、アーチテクチャはどんなリアルタイムストリームアプリケーションにも適用し得る。
【００８７】
性能結果
２つのメトリックスは今のところ（本発明のフレームワークの下で）提案機構によって達成される性能利得を立証及び確立するために選択される。所定のメトリックスに対して、３つのインターフェースを備えた提案本発明のビデオシステムの性能は単一送信インターフェース（現在の技術）を用いるものと比較される。本発明システムに使用されている３つのインターフェースの各々は54 Mbps 802.11インターフェースである。３つの54 Mbpsインターフェースの単一インターフェース送信に対して
ａ）パケット送信遅延
が使用される。
【００８８】
送信遅延は送信機マングラー（mangler）でパケットを取得するときと受信マングラーでパケットを受信するときの間にかかる時間として定義される。
【００８９】
従来技術：156.5 msec
本発明のビデオ：1.8 msec
ｂ）遅延パケットのパーセンテージ
パケットはそのエンドツーエンド遅延（送信＋バッファリング）が固定閾値を超過すれば遅延と考えられる。閾値が目標アプリケーションに配布される前に、第１パケットが受信機でバッファされている時間を与えられる。
【００９０】
従来技術：８％
本発明ビデオ：．０８％
考慮された両メトリックスに対して、提案の本発明ビデオアーチテクチャは現在の技術が行うことができるものより二桁（１００倍）多く実行する。そのような大きな性能利得は我々が本発明ビデオシステムにより多くのインターフェースを追加するに従って、提案技術が最適化されるに従って改善するだけである。
【００９１】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【技術分野】
【０００１】
本発明は、特に、複数のインターフェースを介してビデオストリームを提供すること、とりわけ高品質ビデオストリーム又はリアルタイムストリームを提供する複数のインターフェースに関する。
【背景技術】
【０００２】
ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００３】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。
【０００４】
ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれるエンティティに分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次のエンティティの一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。
【０００８】
モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべきエンティティを含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（General Packet Radio Service）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（登録商標）（Global System for Mobile Communications）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（Time Division Multiple Access）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１３】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１４】
（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１５】
ビデオストリーム
無線メディア（媒体）を介するビデオストリームは困難な課題である。特に、これは次の顕著な理由により難問となりうる。
【００１６】
第一に、クライアントに提供されるアクセス帯域幅は、特に、無線ネットワークを用いると、大きく変化する可能性がある。干渉のようなメディア特性及びメディアアクセスの頻繁な非決定論的特性（802.11はが典型的例である）は高可変処理能力及び遅延となる。更に、今日の世界で使用されているパケットネットワークはほとんど実質的に最善努力式であり、帯域幅、遅延又はパケット欠損に保証がない。
【００１７】
第二に、ビデオストリームアプリケーションが設定する帯域幅及びジッタに関する要求は厳しくなる可能性がある（代表的なＤＶＤストリーム帯域幅は９．２Ｍｂｐｓまでとなり、ジッタは２００ｍｓｅｃ以下になる必要がある）。更に、情報源は実質的に非固定となり、しばしば使用される符号化システムはパケット間の復号化依存性を招く。これはパケット遅延（又は欠損）における小さな可変性が視聴経験の品質に重大な劣化を導くことになる。
【００１８】
特に、無線ネットワークを介するビデオストリームに関する改良について技術的に要求があった。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
本発明の好適実施形態は上記及び／又は背景技術の他の問題を克服する。
【課題を解決するための手段】
【００２０】
好適実施形態では、我々が予測する複数のインターフェースを使用するのは未来の装置に当てはまる。本発明は、アプリケーションのための帯域幅及びＱＯＳを伝達するために、このアクセスダイバーシティを開発するための知的接続性ネットワーク（intelligent connectivity framework）（本発明のシステム）に関する。複数のインターフェースがどのように使用されるかは一般のネットワーク条件だけでなくアプリケーションの特性に依存する。本発明のシステムは最も該当する接続性方策を発見し、選択し、実行し、評価するための一般的な柔軟なプラットフォームを提供する。
【００２１】
本発明は装置間で高品質のビデオストリームを送るために、総括的な本発明のフレームワーク内で使用される特定のセットの接続性戦略に焦点を置いている。しかしながら、これら戦略は本発明のフレームワークによって制限され、任意の同様な代替フレームワークを用いて又はそれ自体によって使用し得る。
【００２２】
セットの方策は次のカテゴリの下にある。
【００２３】
１．受信機バッファ管理；
２．選択的再送信；及び
３．ダイナミック負荷バランス
この明細書では、ビデオパケットを供給する局（コンピュータ）は送信機（クライアント−サーバアーチテクチャのサーバ）と呼ばれ、ビデオを受信し、その後再生する局（コンピュータ）は受信機（クライアント）と呼ばれる。
【００２４】
受信局でのバッファ管理は複数のインターフェースを通過するパケットの再整理(re-ordering)を行い、パケットをタイムリーな方法でアップリケーション（この場合にはビデオプレイヤ）に解放する。
【００２５】
本方法では、ビデオストリームはインターフェースを介して分割される（異なるインターフェースを介して送信されるパケット）。ダイナミック負荷バランスは、現ネットワーク状態及びアプリケーション特性に応じるダイナミック形式で、利用可能インターフェースを介してビデオストリームを分割するため知的選択率（intelligent selection of ratios）を参照する。
【００２６】
本方法は更に少なくとも１つのパケットを複製すること及び異なるインターフェースを介してパケットの複製を送信することを含む。故に、パケット分割は少なくとも１つのパケットを複製し、異なるインターフェースを介してパケットの複製を送信するだけでなくシーケンスパケットを分割し、異なるインターフェースを介してパケットを送信することを含む、更に、本方法はパケットの分割及び複数のインターフェースを介して送信用パケットの複製の両方のステップの組合せを含む。本発明の一実施形態では、パケット分割によるパケットは複数のインターフェースを介して同時に送信され、他の実施形態では、それは若干異なる時間で送信される。
【００２７】
３つの方策はそれらの任意の１つが他の使用を要求しないで使用し得るように十分独立している。しかしながら、それらの全てが共に使用され、互いに支援する方法で使用されるとき、ビデオ品質を更にもっと高められることになる。
【００２８】
幾つかの好適実施形態によると、本発明は高品質ビデオストリーム（又はリアルタイムストリーム）を提供するために複数のインターフェースの存在を活用する。幾つかの実施形態では、提案解決策は複数のインターフェースを介して高品質ビデオストリームを達成するため１）受信機バッファ管理、２）パケットの選択的再送信及びインターフェースを介するダイナミック負荷バランスを含む３つの戦略を含む。
【図面の簡単な説明】
【００２９】
【図１Ａ】３つの提案戦略の全てを使用する具体的システムアーチテクチャを示す。
【図１Ｂ】３つの提案戦略の全てを使用する具体的システムアーチテクチャを示す。
【図２】バッファ管理システムの概略図である。
【図３】現在の技術（１つのインターフェース）に対する遅延値のグラフ図である。
【図４】本発明のビデオ（３つのインターフェース）に対する遅延値のグラフ図である。
【発明を実施するための形態】
【００３０】
本発明の好適実施形態は、限定されないが、添付図に一例として示されている。
【００３１】
本発明は多くの異なる形態で実施できるが、複数の具体的実施形態は本開示が本発明の原理の例を提供するように考えられ、そのような例が本発明をここに記載された及び／又はここに図示された好適実施形態に限定される意図がないことを考慮してここに説明されている。
【００３２】
受信機バッファ管理
本発明のフレームの好適実施形態のシステムの下では、単一のビデオストリームに属するパケットは複数のインターフェースを介して送信される。アーチテクチャはインターフェースのタイプに制限していなく、故にしばしばインターフェースは異種である。即ち、それらは処理能力及び遅延性能を含むキャパビリティについて広範囲に変化する。重要な副次的悪影響は受信機で異常となるパケットのそれである。ビデオストリームはしばしばＵＤＰをトランスポートプロトコルとして使用されるので、エンドアプリケーションへのパケットの順序付け配送を保障するエンティティは存在しない。これらの環境下では、パケットを再順序付けし、それらをタイムリーな方法でアプリケーションに与えるため受信機端でバッファを有することが重要である。
【００３３】
リアルタイムアップリケーションパケット（及び故にビデオストリーム）が、それ以上パケットが利用できない支払期限を有する。故に、アプリケーションへのパケットの注文配送が重要なだけでなく、パケットがアップリケーションへ配送された時間が重要である。従って、異種インターフェースによって生じる故障パケット配送を処理し、それらを順序及びタイムリー方法でアプリケーションに配送する知的バッファ管理システムが必要となる。
【００３４】
プレイアウト期限基準バッファ管理
各リアルタイムパケットはプレイアウト期限と関連している。パケットがプレイアウト期限を見過ごせば、その利用は喪失する。故に、我々が受信機で使用するバッファシステムはタイムリーな方法でパケットを目標アプリケーションに供給するためにこのプレイアウト期限を知っているべきである。しばしば、記録ビデオパケット(ex: MPEG)又はＲＴＰのようなストリームを搬送するために使用されるトランスポートプロトコルヘッダは対応するパケットのプレイアウト期限を有することになる。そのような符号化／プロトコルヘッダのフォーマットを知ること及び受信機でそのような情報を処理することによって、パケット毎にプレイアウト期限を決定することが可能になる。しかしながら、本発明のフレームワークは優先的にプロトコル／符号化を独立とするので、我々はプレイアウト期限を決定する代替方法を使用する。これは限定されなく、フレームワーク／アルゴリズムが存在する本発明は何かそのような方法と連携する。提案方法の好適実施形態のために次の仮定がなされている。
【００３５】
ａ）各パケットのプレイアウト期限はパケットが送信機器で生成される時間からの固定値（許容値）である。更に、許容時間は第１パケットがターゲットアプリケーションに配送される前に受信機でバッファされている時間として計算される。
【００３６】
ｂ）送信機と受信機機器との間に局部時刻同期Tplayout = T generation + Ttoleranceが存在する。
【００３７】
プレイアウト期限に基づいてパケットをバッファし、開放するための総体的方法は下記のサブコンポーネントを有する。
【００３８】
ａ）送信機器機でのパケット処理（マーキング、タイムスタンピング）（下記１．１参照）
ｂ）受信機機器でのパケット処理（バッファリング、再注文）（下記１．２参照）
ｃ）パケットプレイアウト期限に基づいてバッファからアプリケーションへパケットを配送するバッファ管理アルゴリズム（下記１．３参照）
送信機でのパケット処理（１．１）
我々はこの部分を達成するため本発明のフレームワークの好適実施形態のパケット処理モジュールを使用する。送信機器機でのパケット処理モジュールは各パケットを受信し、カスタムヘッダを各パケットに加え、パケットが通過することになっているインターフェースに基づいて、ＩＰヘッダを適切に変更する。カスタムヘッダは適用可能な種々の分野に適応させるためにアップリケーションタイプに特定されるように設計し得る。リアルタイムアプリケーションに対して、カスタムヘッダは局所的に生成される（順次増加される）パケットｉｄ、（送信機器機で）パケット処理モジュールがパケットを受信する現地時間を示す時間フィールド、及びパケットが送られるインターフェースを示すフィールドから成る。カスタムヘッダホーマットは下記のようにできる。
【表１】
【００３９】
受信機(1.2)でのパケット処理
受信機器機には、全ての着信パケットが最初に設定されるパケットバッファが存在する。カスタムヘッダ情報を用いて、プレイアウト期限が次式によりパケット毎に計算される。
【００４０】
Tplayout = Tgeneration + Ttolerance
許容時間は第1パケットがバッファされた時間に基づいて計算される。プレイアウト時間は第1パケットがアプリケーションに配送されるまで計算されない。プレイアウト期限が満了したパケットはバッファから除外される。同様に、同じパケットの複数のコピーが受信されれば、１つのコピーだけがバッファに保持され、残りは破棄される。パケットはパケットｉｄフィールドに基づいて（必要なら）再順序付けされ、最後にカスタムヘッダが取り去られる。パケットは（下記に与えられる）アルゴリズムがそれらをアプリケーションに放出することを決定するまでバッファに待機する。
【００４１】
バッファ管理アルゴリズム(1．3)
発見的アルゴリズムはパケットをアプリケーションに放出することを起こさせる一組の規則／閾値に基づいている。一度パケット放出が決定されると、パケットのグループはアプリケーションに配送される。むろん、本発明のシステム及びその実施はこのアルゴリズムによって限定されなく、その他のそのようなロジックと連携する。バッファ管理アルゴリズムはパケットのグループがアプリケーションに放出される時間及び開放されるパケットの数を決定する。
【００４２】
パケットの放出
下記のセットの規則／閾値が最新バージョンのアルゴリズムでパケットの放出を引き起こすために使用される。
【００４３】
１）最後に配送されたパケットのプレイアウト期限が満了しようとしている。
【００４４】
２）パケットバッファの列の長さが閾値を超えている。
【００４５】
３）最後のパケットの放出以降の時間が閾値を超えている。
【００４６】
第２条件は実施時固有の理由のために必要であり、使用されるオペレーティングシステム／ハードウエアプラットホームのタイプに基づいて変えることができる。（パケットがアプリケーションに配送されなかったとき）初めて、プレイアウト期限が決定し得ないので、条件２及び３だけが使用される。アルゴリズムに使用される他のパラメータは（パケットｉｄに基づいて）配送されるべき次のパケットがバッファに存在するかどうかである。これは変数：nextPktAvailableを用いて示される。規則のセットが以下に与えられるようにより正確に特定される。ここでは、CurrentTime変数は現在時間を示しており、QueueLengthはパケットバッファの現在の長さである。Treleaseは最終セットのパケットが配送されたときの時間を示している。
CurrentTime > Tplayout - Tthreshold2 ---- 条件 I
又は
QueueLength > QL threshold2 ---- 条件 II
又は
CurrentTime > Trelease - Tthreshold4 ---- 条件 III
又は
((CurrentTime > Tplayout - Tthreshold1) OR (QueueLength > QL threshold1) 又は
(CurrentTime > Trelease - Tthreshold3)) AND (nextPktAvailable ==1) ---- 条件 IV
条件I, II, IIIは個々の規則1), 2), 3)にそれぞれ対応する。条件IV配送されるべき次のパケットがバッファにおいて利用可能である条件(nextPktAvailable==1)と同様に条件の各々の集合規則である。キーは閾値変数：
Tthreshold1, Tthreshold2, Tthreshold3, Tthreshold4, QLthreshold1, QL threshold2
に対して適切な値を設定することである。
【００４７】
閾値選択において次のセットの関連性を維持することがアルゴリズムの効率を確実にするのに重要である。
【００４８】
Tthreshold1 > = Tthreshold2
Tthreshold3 > = Tthreshold4
QL threshold1 < = QL threshold2
我々が現実施形態において使用する特定セットの値は：
Tthreshold1 = 100 msec, Tthreshold2 = 50 msec,
Tthreshold3 = 10 sec, Tthreshold4 = 5 sec,
QL threshold1 = 800, QL threshold2 = 800
である。
【００４９】
放出されるパケットの数
利用可能な他の重要なシステムはどれだけ放出されるかのパケットを放出する決定を与えられる。現在の設計では、我々はこれを次の喪失パケットまで又は所定の閾値数のパケットのいずれかとして設定する。いずれも放出パケットの数に関しては少なくなる。使用された閾値はQL threshold3 < QL threshold1の場合にはQL threshold3であり、我々は現実施形態では、値QL threshold3 = 400を使用している。
【００５０】
アルゴリズムの重要な特徴はそれが動的に設定される閾値値を予想することである。閾値値は最終的にエンドユーザを規定して、どのくらいの開始バッファリングが生じるか及び頻繁にどれくらいパケットが放出されるかを制御する。閾値変数がどこに設定されるかに基づく可能候補である若干のパラメータは：
１）アプリケーションタイプ／パラメータ（例えば、ボイス、ビデオ、ゲームなど）
２）トランスポートプロトコル／パラメータ
３）オペレーティングシステム／ハードウエアプラットホーム、及び
４）ネットワーク状態
パケットの選択的再送信
多くの場合、ネットワークを介して送信されるパケットはネットワークのいろいろな障害により（プレイアウト時間を超えて）遅延し又は喪失する。両事例では、そのようなパケットは受信機側アプリケーションで展開するために使用できない。幾つかのリアルタイムアプリケーション、特に、ビデオに対しては、符号化は単一のパケット損失さえも複数のパケットを介して伝播させる（復号化依存性）。結果はエンドユーザ経験の品質の重大な低下となることが多い。無線アクセス又はベストエフォートサービスだけを提供するコアＩＰネットワークに依存することは確かに、再生されているビデオの頻繁な中断及びピクセル化のための方策である。故に、高品質エンドユーザ経験を持たせるために、そのようなネットワークを用いている間は、できるだけ多く欠損又は遅延パケットの数を減らす新たな戦略を持つことは重要である。
【００５１】
パケットを複製すること又は誤り訂正符号化の他の形態を使用することはこの問題を扱う１つの方法である。しかし、無線ネットワークでは、性能（遅延、欠損）は殆どの期間で妥当であり、パケットは短い集中期間だけ遅延／欠損することは非常に一般的である。そのような場合、種々形態の誤り訂正符号化はそれが消費する時間とメモリのような資源は言うまでもなく少ない無線帯域の非効率な使用となる。選択的再送信は遅延／欠損パケットの数を最小にするための帯域幅効率的及び効果的方法である。そのようなシステムの下で、受信機は選択された数のパケット（紛失したもの）を送ることを送信機に要求し、送信機はそれらのパケットを再送信することになる。紛失パケットの再送信を要求するときを決定するのはシステムの効率と効果を特徴付けるときに重要となる。本発明はビデオパケットの選択的再送信の戦略及び特定パケットの再送信を知的に要求するアルゴリズムを提供する。
【００５２】
戦略は次のサブシステムから成る。
【００５３】
ａ）すでに送信されたパケットのコピーを必要ならそれらを再送信し得るようにバッファし、バッファサイズが無限となるように適切な時間にバッファされたパケットを破壊するメカニズム（２．１）。
【００５４】
ｂ）送信機から特定パケットを要求する受信機のためのメカニズム（２．２）
ｃ）紛失／欠損パケットを最小にすることに関して効果的であり、帯域幅利用に関して効率的である、紛失パケットを再送信することを要求するときを決定するアルゴリズム（２．３）
ｄ）１以上のインターフェースを介して、パケットを再送信するための最も効果的な戦略を送信機が決定するためのシステム及びアルゴリズム（２．４）。
【００５５】
送信機側再送信バッファ（２．１）
パケットが初めて送信されるとき、パケットのコピーが作られ、送信機機器でパケットバッファに記憶される。後に受信機が特定のパケットの再送信を要求すると、それはパケットバッファ(送信機側)に記憶されたコピーを使用して行え得る。
【００５６】
しかしながら、全てのパケットのバッファリング（一時保存）は大きな必要メモリを招くことになる。必要メモリを最適化するために提案方法は送信機側バッファに記憶されたあるパケットの解放を決定するため受信機機器からのフィードバックを使用する。現在の実施では、受信機は全ての先のパケットが受信されてしまうときまでパケットのパケットｉｄを周期的にフィードバックする。その後、送信機はこのパケットまで全てのパケットに対してバッファを解放する。この方法、パケットの送信機側バッファリングによって使われるメモリは最小値に保たれる。
【００５７】
再送信パケットに対する受信機の要求（２．２）
受信機機器は選択パケットの再送信のためのその要求を送信機に知らせる必要がある。再送信要求（保存帯域幅）の数を最小にするために、再送信要求は可能なときはいつでもグループ化されることが提案されている。
【００５８】
本発明のフレームワークの好適実施形態に存在する制御チャネルは再送信を要求されるパケットｉｄｓのリストを送るために使用される。更に、各再送信の緊急性を示す方法が存在すべきであることが提案されている。これは各再送信パケットｉｄに付帯された追加のフィールドの形態であるか、或いはレベル当たりのパケットｉｄｓの順序付リストが続いている各レベルに属する緊急要求の数の計数値である。各再送信要求の緊急レベルを知ることは送信機が要求の種類毎に個別の再送信方策を持つことに役立つ。そのようなメカニズムが選択的再送信方法の効果及び効率を確実にするよう設計される。
【００５９】
一例として緊急性の２つのレベル、URGENT及びNORMALが存在すると仮定する。緊急レベルは所定時間閾値内でプレイアウトされる予定であるパケットを表すことができ、正常の物はその期限を超えるプレイアウト期限を有する。再送信メッセージフォーマットはリスト又はURGENTパケット及び最後にNORMALパケットのリストが続く、各レベルに属する要求の数を示す２つのフィールドを有することができる。
【００６０】
再送信要求アルゴリズム（２．３）
このアルゴリズムの機能は紛失パケットの再送信を問い合わせるときを決定することである。再送信要求はパケットのプレイアウト期限が過ぎる前に再送信パケットが受信機に到達することを確実にするため十分速くなされる必要がある。同時に、無線ネットワークで遅延／欠損の予測不可能な本質だけでなく複数の異種インターフェースを介して送信されているパケットにより、我々はパケットが送信中である可能性がある事実を説明する必要がある。既に送信中であるパケットに対して早急な再送信を要求することは無線帯域の能率的でない使用に導くことになる虞がある。故に、一方では、期限前の成功するパケット受信の確率が早急な再送信要求によって改善でき、他方で、より多くの無線帯域が早期に（及び不必要な）再送信によって消費される。（欠損を最小化する及び帯域幅を最大化する）２つの態様の間のトレードオフはしばしばネットワーク特性だけでなくアプリケーションの性質に依存する。特に提案の選択的再送信システム及びアルゴリズムはシステム要求及び動作条件に基づいてこのトレードオフを制御するパラメータを有する。
【００６１】
アルゴリズムによって実行される特定機能は
ａ）適切な時間に潜在的に‘紛失’としてパケットを認識する。
ｂ）適切な時間に再送信要求を送信する。
ｃ）紛失パケット毎に緊急性のレベルを認識する。
【００６２】
以上のように、帯域幅を節約するために再送要求は可能なときはいつでもグループ化される。故に、我々はパケットが‘紛失’として認識されるときと実際の再送信要求がなされるときの２つの異なる時刻を潜在的に有する。
【００６３】
（所定のパケットｉｄを持つ）パケットは下記のときに紛失と見なされる。
ａ）（パケットｉｄｓによって与えられるように）紛失パケットの直前に（順序付けられた）バッファに存在するパケットのプレイアウト期限が所定の閾値時間内にある。
ｂ）紛失パケットｉｄと最新パケットｉｄ（パケットｉｄｓが常に増加していれば最大パケットｉｄ）との差が閾値を超える。
【００６４】
再送信要求は‘紛失’パケット及び
ａ）最後に順序付けられたパケットのプレイアウト期限が満了しようとしている、
ｂ）タイムアウト値が最後の再送信要求（周期的再送信要求）がなされたときから生じる、
ｃ）紛失パケットの合計数が所定の閾値を超える、
ときに成される。
【００６５】
特定パケットの再送信要求の緊急性レベルの決定は下記に基づくことができる。
ａ）（パケットｉｄｓによって与えられているように）紛失パケット直前に（順序付けられた）バッファに存在するパケットのプレイアウト期限、
ｂ）紛失パケットの合計数は所定の閾値を超える。
【００６６】
現在の実施では、パケットは紛失パケットｉｄと最新パケットｉｄ（パケットｉｄｓが常に増加していれば最大パケットｉｄ）との差が１００を超えるとき紛失と見なされる。再送信要求は０．１秒毎に周期的に行われ、全てのパケットの緊急性レベルがURGENTに設定される。
【００６７】
プレイアウト期限と関連して使用される閾値はバッファされたパケットをアプリケーションに放出するためのトリガを決定するため先のアルゴリズムに存在するそのような閾値に依存すべきであることを留意することが重要である。
【００６８】
再送信方策アルゴリズム（２．４）
送信機は特定パケットに対する最新要求を一度受けると、それは緊急レベルに基づいて再送信方策を決定する。複数のインターフェースの存在はインターフェースの任意の組合せを介して再送信するオプションを送信機に与える。そのような戦略の１つに全ての利用可能インターフェースを介してＵＲＧＥＮＴレベルを持つパケットの複数のコピーを再送信し、ＮＯＲＭＡＬレベルパケットを再送信するために１つのインターフェースだけを使用することがある。
【００６９】
我々の最近の実施では、使用される戦略は良好な品質となると決定される全てのインターフェースを介してパケットの複数のコピーを再送信することである。インターフェース品質は経験したエンドツーエンド遅延又は他のチャネル品質判定を用いて判定される。
【００７０】
インターネットを介したダイナミック負荷バランス
パケットは複数の利用可能インターフェースを介して送ることができるのであれば、エンドツーエンドパケットは遅延し、故にストリーミング性能はストリームが複数のインターフェースを介してどのように分割されるか（インターフェース当たりのパケット数）に依存する。バッファリングメカニズムと選択的再送信を関連して使用される第３及び最終手法は利用可能インターフェースによって搬送されるパケットの量を適正に変えることである。無線インターフェース／ネットワークは有効処理能力、時間関数としての遅延及び欠損のような幅広く変化する特性を有することが知られている。フェーディング又は干渉によって生じるチャネル状態での変化、ネットワークを用いて他の局によって生じる媒体に関するトラフィックの突然のバースト、及び無線カード／装置ドライバの性能問題が不確実要素の幾つかの引き金となっている。そのような期間において、ネットワークを介して送信されるパケットは大きく欠損又は遅延されることになる可能性がある。故に、固定された数／率のパケットを種々インターフェースに割当てる送信戦略は無線ネットワークを介するストリームに余り適さない。ネットワーク状態及びアプリケーション特性に基づいて配分戦略を適正に変更することがキーとなる。しかしながら、ネットワーク状態をモニタし、種々の障害を予測できることが挑戦となる。ネットワーク状態の幾つかの特徴、特に、RF特性はその無線装置の装置ドライバについて質問することによって取得し得る。しかし、異種無線装置タイプを問い合わせるための共通ＡＰＩは存在しないことに留意し、故に、使用されたベンダー特定装置ドライバの詳細知識はこれを達成することを必要とされる。媒体を用いて他の局によって生じるネットワークにおけるエンドツーエンド遅延又は輻輳をモニタすることは非常に挑戦的であり、帯域外信号伝達を使用してしばしば行われる。この動作は関連するネットワークオーバヘッドだけでなく特定のプロトコルを必要とする。最後に、状態は非常に頻繁に変わり、重要な無線帯域のコストで繰返しモニタすることを必要とさせる。
【００７１】
本発明は出来るだけ外部プロトコル／オーバヘッドを少なく使用するだけでなくスペクトルを効率的に使用する有効な技術を提供する。更に、装置及びプロトコル不可知識論である本発明の考え方と歩調を合せると、我々の解決法は装置又はプロトコルについて特定の知識又は仮定を用いない。
【００７２】
ロードバランシングシステムに含まれるサブシステムは
ａ）ネットワーク状態について現行情報を提供する測定／モニタシステム、
ｂ）現在のネットワーク状態及びアプリケーション特性を考慮して、各インターフェースへの負荷率を決定するアルゴリズム
である。
【００７３】
測定／モニタシステム（３．１）
提案測定／モニタ戦略の重要な態様は
ａ）ネットワーク状態を特徴付けるデータストリーム性能パラメータを使用する、
ｂ）帯域外信号伝達を最小に保って、帯域内信号伝達及び帯域外信号伝達の組み合わせを使用する、
ことである。
【００７４】
装置ドライバ又は８０２．２１のような他のプロトコルを問い合わせることを介して利用できるネットワーク状態についてのこれ以上の測定／情報が容易に使用できる。しかしながら先に述べたように、重要な特徴はシステムがそのような情報に依存しないが、その代わりに一次ソースとしてデータストリーム性能パラメータを使用することである。
【００７５】
我々はインターフェース当たりのエンドツーエンド遅延測定及びインターフェース当たりの紛失／欠損パケットの使用を提案する。両者は送信戦略を評価するため現在のデータストリームを用いて測定される。これらの両パラメータは既に存在し、更に現在のネットワーク状態の効果の良好なインジケータである。目的はデータストリーム性能パラメータを改善する（遅延を最小にする、紛失を最小にする）ことであるので、最適化を行うため１ネットワーク当たりに同じパラメータを測定し、使用することは非常に適正な方法である。これは帯域外信号伝達を用いて信号長又はエンドツーエンド遅延のような他のネットワーク性能メトリックスをモニタし、測定する必要がない明確な利点を超えている。
【００７６】
各送信パケットはそれが送信されたインターフェースを示すカスタムヘッダにフィールドを有するので、受信側でインタフェースメトリック当たりのトラックを維持することが出来る。受信パケット毎に、受信機はタイムスタンプ値に基づいてエンドツーエンド遅延を計算する。定期的に受信機は（個定数のパケットが受信された後にも可能である）インターフェース毎に平均パケット遅延を決定し、本発明の制御チャネルを用いてこの情報を送信機機器にフィードバックする。選択的再送について先のセクションで説明したように、再送信要求を受けるときの送信機はインターフェース毎に紛失／欠損パケットを決定することもできる。
【００７７】
ダイナミッ負荷分散のためのアルゴリズム（３．２）
送信機器は定期的にインターフェース毎にパケット遅延及び欠損率をフィードバックする。これら２つのメトリックス（及びなお幾つかの他のもの）を用いて、各インターフェース品質がコスト関数（０と１の範囲）としてとらえられる。インターフェース毎のコスト関数はインターフェースを用いるときに性能劣化の観点からコストを表している。０のコスト関数はインターフェースを使用する際の優れたインターフェース状態及び品質の低下なしを表し、これに対して１はインターフェースを介して送信されるパケットの受入れられない品質を表している。
【００７８】
我々が行ったパケット遅延及び欠損の関数としてコスト関数の１つのそうような実現は以下の表のように与えられる。
【表２】
【００７９】
平均遅延がゼロのとき、それは幾つかの理由による可能性がある。送信機は期間中にそのインターフェースを介してどのパケットも受信機に送信しなったかもしれない、或いはインターフェース品質が送信パケットのどれも受信されなかったような悪いものであった可能性がある。他の理由はフィードバック情報を知らせるパケットの紛失である。故に、遅延値が０であると、コスト関数値はいくつのパケットが先の期間中にそのインターフェースに送信されたか、そうであればコスト関数が１に設定されているか、そうでなければ値は０．２５であるかに基づいて決定される。
【００８０】
インターフェース当たりのコスト関数が計算されると、次式で与えられるように、同じに先のコスト関数値の全体について平均化することによって時間平均コスト関数が計算される。
【数１】
【００８１】
最後に、適切な平均化コスト関数値がインターフェース毎に計算されると、各インターフェース利用率によって重み付けられたコスト関数の線形組合せが求められる。それは目的関数として寄与する重み付け全コストである。インターフェース利用率（所定インターフェースを介して送信されるべきパケットの％）を計算するアルゴリズムが次の線形プログラミング式によって集約し得る。
【数２】
【００８２】
を前提とする。
【００８３】
平均遅延を最小にすることを含む広範囲のアルゴリズム及び他の非線形アルゴリズムが利用できることに留意する。記事に記載された特定アルゴリズムはたたき台で現在実施されている代表的なものである。
【００８４】
目標化システム／ネットワークアクチュエータ
提案戦略（及び図１に与えられるような結果のアクチュエータ）は複数のインターフェースと共に装置によって使用されることを目標とされる。最適ネットワークアクチュエータは単一送信機単一受信機アクチュエータであり、これは今日のインターネットに最も一般的である。戦略は戦略及びアーチテクチャに適正な変更を行って、マルチキャストシナリオ（単一送信機、複数受信機）及び複数送信機単一受信機シナリオにも適用できる。
【００８５】
好適実施形態において最も望ましく作用するシステムに必要な最も重要な要素は：
ａ）エンドホスト間に複数のインターフェース（ネットワーク経路）の存在；
ｂ）（送信機及び受信機機器で必然的でない）複数の経路のエンドポイントで戦略を実施するソフトウエア
である。
【００８６】
同様に、記事がビデオアプリケーションだけを記載しているけれども、アーチテクチャはどんなリアルタイムストリームアプリケーションにも適用し得る。
【００８７】
性能結果
２つのメトリックスは今のところ（本発明のフレームワークの下で）提案機構によって達成される性能利得を立証及び確立するために選択される。所定のメトリックスに対して、３つのインターフェースを備えた提案本発明のビデオシステムの性能は単一送信インターフェース（現在の技術）を用いるものと比較される。本発明システムに使用されている３つのインターフェースの各々は54 Mbps 802.11インターフェースである。３つの54 Mbpsインターフェースの単一インターフェース送信に対して
ａ）パケット送信遅延
が使用される。
【００８８】
送信遅延は送信機マングラー（mangler）でパケットを取得するときと受信マングラーでパケットを受信するときの間にかかる時間として定義される。
【００８９】
従来技術：156.5 msec
本発明のビデオ：1.8 msec
ｂ）遅延パケットのパーセンテージ
パケットはそのエンドツーエンド遅延（送信＋バッファリング）が固定閾値を超過すれば遅延と考えられる。閾値が目標アプリケーションに配布される前に、第１パケットが受信機でバッファされている時間を与えられる。
【００９０】
従来技術：８％
本発明ビデオ：．０８％
考慮された両メトリックスに対して、提案の本発明ビデオアーチテクチャは現在の技術が行うことができるものより二桁（１００倍）多く実行する。そのような大きな性能利得は我々が本発明ビデオシステムにより多くのインターフェースを追加するに従って、提案技術が最適化されるに従って改善するだけである。
【００９１】
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【特許請求の範囲】
【請求項１】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記ダイナミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用の少なくとも１つのパケットを複製することである、方法。
【請求項２】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記ダインミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用単一ビデオストリームに属する少なくとも１つのパケットを分割する知的選択率である、方法。
【請求項３】
前記デジタルデータはパケット状であり、前記受信機に順序がバラバラに到達するパケットは前記受信機でバッファされ、再整理され、それによってそれらはタイムリーな方法でアプリケーションに到達する、請求項２の方法。
【請求項４】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、タイムリーな方法で目標アプリケーションにパケットを提供し、各リアルタイムパケットはプレイアウト期限と関連している、方法。
【請求項５】
前記パケットはフォーマット情報符号化／プロトコルヘッダを含み、前記受信機での前記フォーマット情報はパケット毎にプレイアウト期限を決定するために処理される、請求項４の方法。
【請求項６】
各パケットの前記プレイアウト期限はパケットが前記送信機で生成されるときの固定値である、請求項５の方法。
【請求項７】
前記送信機と前記受信機との間の局所クロック同期かを更に含み、
Tplayout = Tgeneration + Ttolerance.であり、
但し、Tplayout = 前記第1パケットがアプリケーションに配送されるときに計算されるプレイアウト時間、
Tgeneration = パケットが送信機で発生される時間、そして
Ttolerance = 前記第1パケットがバッファされていた時間に基づいて計算される許容時間
である、請求項６の方法。
【請求項８】
前記送信機でパケットをマーキング及びタイムスタンプすることを更に含む、請求項４の方法。
【請求項９】
前記送信機でのパケット処理を更に含み、前記パケット処理はカスタムヘッダを各パケットに追加することを含み、前記カスタムヘッダはパケットが送信されることになるインターフェースを示す、請求項４の方法。
【請求項１０】
前記方法はリアルタイムアプリケーションであり、前記カスタムヘッダは連続して増加する局所的に発生するパケット、送信機でのパケット処理モジュールがパケットを受信する局所時間を示すタイムフィールドを更に含む、請求項９の方法。
【請求項１１】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、次式：
Tplayout = Tgeneration + Ttolerance
但し、Tplayout = 前記第1パケットが前記アプリケーションに配送される計算されるプレイアウト時間、
Tgeneration =パケットが送信機で発生される時間、そして
Ttolerance =前記第1パケットがバッファされていた時間に基づいて計算される許容時間を用いてパケット毎にプレイアウト期限を計算するためにカスタムヘッダ情報を用いる、方法。
【請求項１２】
プレイアウト期限が経過したバッファ済みパケットを減少するステップを更に含む、請求項１１の方法。
【請求項１３】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、更に、前記受信機バッファで同じパケットの複数のコピーを受信し、同じパケットの前記複数のコピーの１つの他を破棄することを更に含む、方法。
【請求項１４】
前記パケットはパケットｉｄフィールドを含むカスタムヘッダを有し、前記パケットｉｄフィールドに基づいてパケットを整理し直し、パケットがアプリケーションに解放される前に前記パケットｉｄフィールドを取り去ることを含む、請求項１３の方法。
【請求項１５】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記送信機バッファから前記受信機バッファにパケットを下記アルゴリズム、
ａ）最後に配送されたパケットのプレイアウト期限が経過しようとしている、
ｂ）パケットバッファのパケットの数が閾値を超える、及び／又は
ｃ）最後のパケット開放からの時間が閾値を超える、
に従って再送信するステップを更に含む、方法。
【請求項１６】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
CurrentTime > Tplayout - Tthreshold2),
(QueueLength > QL threshold2),
(CurrentTime > Trelease - Tthreshold4), 及び
(((CurrentTime > Tplayout - Tthreshold1)OR (QueueLength > QLthreshold1) OR (CurrentTime > Trelease - Tthreshold3))AND(nextPktAvailable ==1)).
但し、a) QueueLengthはパケットの数,
b) CurrentTimeは現在時間,
c) Treleaseは最後のセットのパケットが配送された時間,
d) Tplayoutはプレイアウト期限,
e) Tthresholdはパケットが受信機又はアプリケーションでタイムリーに受信されるように解放されなければならない時間,及び
f) QL thresholdはバッファされることになるパケットの最大数（閾値が動的に設定され、初期バッファリングの限度及び解放されるパケットの周期を制御する）、.
を含むグループから選択される少なくとも１つのアルゴリズムに従って前記受信機バッファを管理することを更に含む、方法。
【請求項１７】
最も妥当な接続性戦略を発見し、選択し、実行し及び評価するための柔軟性プラットフォームを用いる、デジタルデータのリアルタイムストリーミングの方法であって、
ａ）送信機でデジタルデータのバッファ、
ｂ）バッファされたストリームデジタルデータを前記送信機から受信機への送信、
ｃ）前記送信機から前記ストリームデジタルデータの受信、
ｄ）前記送信機から前記受信機へのデジタルデータの選択的再送信、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランス
を含み、
前記送信機バッファの管理ステップを更に含み、前記バッファでの管理ステップは遅延又は欠損パケットがタイムリーな方法により受信機で更にプレイアウトし得るためにそれらを再送信するパケットの選択的再送信をみ、
前記ダイナミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用の単一ビデオストリームに属するパケットを分割するための率の知的選択である、方法。
【請求項１８】
前記受信機で順序がばらばらで到達しているパケットは前記受信機でバッファされ、再整理される、それによりそれらがタイムリーな方法でアプリケーションに到達する、請求項１７の方法。
【請求項１９】
前記デジタルデータがパケット状であり、前記受信機でバッファされたパケットはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、各リアルタイムプレイアウト期限と関連している、請求項１８の方法。
【請求項２０】
前記パケットはフォーマット情報符号化／プロトコルヘッダを含み、前記受信機での前記フォーマット情報はパケット毎にプレイアウト期限を決定するために処理される、請求項１９の方法。
【請求項２１】
各パケットの前記プレイアウト期限はパケットが前記送信機で生成される時点の固定値である、請求項２０の方法。
【請求項２２】
前記送信機と受信機の間の局所クロック同期を更に含み、
Tplayout = T generation + Ttoleranceであり、
但し、
Tplayout =前記第１パケットが前記アプリケーションに搬送されるとき計算されるプレイアウト時間,
Tgeneration = パケットが前記送信機で発生される時間、そして
Ttolerance = 前記第１パケットがバッファされた時間に基づいて計算された許容時間
である、請求項２１の方法。.
【請求項２３】
前記送信機でパケットをマーキングし、タイムスタンピングすることを更に含む、請求項１９の方法。
【請求項２４】
前記送信機でパケット処理を更に含み、前記パケット処理はカスタムヘッダを各パケットに追加し、前記カスタムヘッダは前記パケットが送信されることになるインターフェースを表す、請求項１９の方法。
【請求項２５】
前記方法はリアルタイムアプリケーションであり、前記カスタムヘッダは連続して増加する局所的に発生するパケット、送信機でのパケット処理モジュールがパケットを受信する局所時間を示すタイムフィールドを更に含む、請求項９の方法。
【請求項２６】
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、次式：
Tplayout = Tgeneration + Ttolerance
但し、Tplayout = 前記第1パケットが前記アプリケーションに配送される計算されるプレイアウト時間、
Tgeneration =パケットが送信機で発生される時間、そして
Ttolerance =前記第1パケットがバッファされていた時間に基づいて計算される許容時間を用いてパケット毎にプレイアウト期限を計算するためにカスタムヘッダ情報を用いる、請求項１８の方法。
【請求項２７】
プレイアウト期限が経過したバッファ済みパケットを減少するステップを更に含む、請求項２５の方法。
【請求項２８】
前記デジタルデータはパケット状であり、更に、前記受信機バッファで同じパケットの複数のコピーを受信し、同じパケットの前記複数のコピーの１つの他を破棄することを更に含む、請求項１８の方法。
【請求項２９】
前記パケットはパケットｉｄフィールドを含むカスタムヘッダを有し、前記パケットｉｄフィールドに基づいてパケットを整理し直し、パケットがアプリケーションに解放される前に前記パケットｉｄフィールドを取り去ることを含む、請求項２８の方法。
【請求項３０】
前記送信機バッファから前記受信機バッファにパケットを下記アルゴリズム、
ａ）最後に配送されたパケットのプレイアウト期限が経過しようとしている、
ｂ）パケットバッファのパケットの数が閾値を超える、及び／又は
ｃ）最後のパケット開放からの時間が閾値を超える、
に従って再送信するステップを更に含む、請求項１８の方法。
【請求項３１】
CurrentTime > Tplayout - Tthreshold2),
(QueueLength > QL threshold2),
(CurrentTime > Trelease - Tthreshold4), 及び
(((CurrentTime > Tplayout - Tthreshold1)OR (QueueLength > QLthreshold1) OR (CurrentTime > Trelease - Tthreshold3))AND(nextPktAvailable ==1)).
但し、a) QueueLengthはパケットの数,
b) CurrentTimeは現在時間,
c) Treleaseは最後のセットのパケットが配送された時間,
d) Tplayoutはプレイアウト期限,
e) Tthresholdはパケットが受信機又はアプリケーションでタイムリーに受信されるように解放されなければならない時間,及び
f) QL thresholdはバッファされることになるパケットの最大数（閾値が動的に設定され、初期バッファリングの限度及び解放されるパケットの周期を制御する）、.
を含むグループから選択される少なくとも１つのアルゴリズムに従って前記受信機バッファを管理することを更に含む、請求項１８の方法。
【請求項３２】
デジタルデータパケットを再送信するシステムであって、
パケットバッファを有する送信装置と、
前記送信機装置はパケットが必要に応じて再送信し得るようにパケットが作られるように、前記バッファにそれらをコピーし、記憶し、そのプレイアウト期限が経過したバッファされたパケットを破棄するように構成され、
前記受信装置は前記送信装置から特定パケットを要求するように構成された受信装置と、
デジタル記憶媒体に記憶され、紛失パケットの再送信を要求するためのアルゴリズムを含み、紛失／欠損パケットの最小化に関して効果的であり、帯域幅利用に関して効率的であるソフトウエアと、
デジタル記憶媒体に記憶され、少なくとも１つのインターフェースを介してパケットを送信するための最も効率的な戦略を計算するようプログラムされている送信機アルゴリズムソフトウエアと、
を具備する、システム。
【請求項３３】
前記受信装置によって再送信のために要求されているパケットｉｄｓのリストを送信する手段を有する制御チャネルを更に含む、請求項３２のシステム。
【請求項３４】
前記パケットは各再送信パケットｉｄに付帯されたフィールドを有し、前記フィールドは送信緊急性を指示する手段と、パケットグループに属する緊急性要求の数を計数する手段と、グループ当たりのパケットｉｄｓの順序付リストを送信する手段とを有する、請求項３２のシステム。
【請求項３５】
前記アルゴリズムは
ａ）相当の時間で潜在的に紛失としてパケットを認識する、
ｂ）相当な時間で再送信要求を送信する、
ｃ）紛失パケット毎に緊急性のレベルを認識する、
ことを含む、請求項３２のシステム。
【請求項３６】
送信機から受信機にデジタルデータをストリーミングする方法であって、
ａ）送信機から受信機にデジタルデータのパケットを記憶し、順序付けする、
ｂ）前記送信機バッファから受信機にストリームデジタルデータを送信する、
ｃ）前記送信機から前記ストリームデジタルデータを受信する、
ｄ）受信ストリームデータを受信機バッファに記憶する、
ｅ）パケットを選択的に再送信する、
ｆ）プレイアウト期限データ及びフォーマット情報符号化／プロトコルヘッダを有する前記受信機バッファに記憶されたストリームデジタルデータパケットの送信をダイナミック負荷バランシングする、
ｇ）前記受信機で前記フォーマット情報を処理し、パケット毎にパケットが前記送信機で発生される時点で設定された固定値である前記プレイアウト期限を決定する、
ｈ）前記送信機及び前記受信機をクロック同期化する、
ｉ）以下のとき前記送信機バッファから前記受信機へ所定パケットｉｄで紛失パケットを再送信する、
１）最後に順序付けられたパケットのプレイアウト期限が経過しようとしている、
２）タイムアウト値が最後の送信要求がなされたときから生じる、及び／又は
３）紛失パケットの合計数が所定の閾値を超える、
紛失パケットｉｄと最近のパケットｉｄとの差が閾値及び／又は前記紛失パケットが所定閾値時間に入る直前のパケットのプレイアウト期限を超えるときパケットが紛失となる、方法。
【請求項３７】
デジタルパケット送信を負荷バランシングするシステムであって、
ａ）ネットワーク状態についての現在情報を提供する測定及び／又はモニタリング手段と、
ｂ）デジタル記憶媒体に記憶されるソフトウエアと、
を含み、前記ソフトウエアは現在ネットワーク状態及びアプリケーション特性を考慮して、各インターフェースの負荷のパーセンテージを決定するアルゴリズムを含み、前記測定及び／又はモニタリング手段はネットワーク状態を特徴付け、帯域内信号伝達及び帯域外信号伝達の組合せを使用するデータストリーム性能パラメータを使用し、帯域外信号伝達を最小に保つ、システム。
【請求項１】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記ダイナミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用の少なくとも１つのパケットを複製することである、方法。
【請求項２】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記ダインミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用単一ビデオストリームに属する少なくとも１つのパケットを分割する知的選択率である、方法。
【請求項３】
前記デジタルデータはパケット状であり、前記受信機に順序がバラバラに到達するパケットは前記受信機でバッファされ、再整理され、それによってそれらはタイムリーな方法でアプリケーションに到達する、請求項２の方法。
【請求項４】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、タイムリーな方法で目標アプリケーションにパケットを提供し、各リアルタイムパケットはプレイアウト期限と関連している、方法。
【請求項５】
前記パケットはフォーマット情報符号化／プロトコルヘッダを含み、前記受信機での前記フォーマット情報はパケット毎にプレイアウト期限を決定するために処理される、請求項４の方法。
【請求項６】
各パケットの前記プレイアウト期限はパケットが前記送信機で生成されるときの固定値である、請求項５の方法。
【請求項７】
前記送信機と前記受信機との間の局所クロック同期かを更に含み、
Tplayout = Tgeneration + Ttolerance.であり、
但し、Tplayout = 前記第1パケットがアプリケーションに配送されるときに計算されるプレイアウト時間、
Tgeneration = パケットが送信機で発生される時間、そして
Ttolerance = 前記第1パケットがバッファされていた時間に基づいて計算される許容時間
である、請求項６の方法。
【請求項８】
前記送信機でパケットをマーキング及びタイムスタンプすることを更に含む、請求項４の方法。
【請求項９】
前記送信機でのパケット処理を更に含み、前記パケット処理はカスタムヘッダを各パケットに追加することを含み、前記カスタムヘッダはパケットが送信されることになるインターフェースを示す、請求項４の方法。
【請求項１０】
前記方法はリアルタイムアプリケーションであり、前記カスタムヘッダは連続して増加する局所的に発生するパケット、送信機でのパケット処理モジュールがパケットを受信する局所時間を示すタイムフィールドを更に含む、請求項９の方法。
【請求項１１】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、次式：
Tplayout = Tgeneration + Ttolerance
但し、Tplayout = 前記第1パケットが前記アプリケーションに配送される計算されるプレイアウト時間、
Tgeneration =パケットが送信機で発生される時間、そして
Ttolerance =前記第1パケットがバッファされていた時間に基づいて計算される許容時間を用いてパケット毎にプレイアウト期限を計算するためにカスタムヘッダ情報を用いる、方法。
【請求項１２】
プレイアウト期限が経過したバッファ済みパケットを減少するステップを更に含む、請求項１１の方法。
【請求項１３】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、更に、前記受信機バッファで同じパケットの複数のコピーを受信し、同じパケットの前記複数のコピーの１つの他を破棄することを更に含む、方法。
【請求項１４】
前記パケットはパケットｉｄフィールドを含むカスタムヘッダを有し、前記パケットｉｄフィールドに基づいてパケットを整理し直し、パケットがアプリケーションに解放される前に前記パケットｉｄフィールドを取り去ることを含む、請求項１３の方法。
【請求項１５】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
前記デジタルデータはパケット状であり、前記送信機バッファから前記受信機バッファにパケットを下記アルゴリズム、
ａ）最後に配送されたパケットのプレイアウト期限が経過しようとしている、
ｂ）パケットバッファのパケットの数が閾値を超える、及び／又は
ｃ）最後のパケット開放からの時間が閾値を超える、
に従って再送信するステップを更に含む、方法。
【請求項１６】
最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
ａ）送信機から受信機へストリームデジタルデータを送信する、
ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
ｄ）紛失データを選択的に再送信する、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランスを行う、
ことを含み、
CurrentTime > Tplayout - Tthreshold2),
(QueueLength > QL threshold2),
(CurrentTime > Trelease - Tthreshold4), 及び
(((CurrentTime > Tplayout - Tthreshold1)OR (QueueLength > QLthreshold1) OR (CurrentTime > Trelease - Tthreshold3))AND(nextPktAvailable ==1)).
但し、a) QueueLengthはパケットの数,
b) CurrentTimeは現在時間,
c) Treleaseは最後のセットのパケットが配送された時間,
d) Tplayoutはプレイアウト期限,
e) Tthresholdはパケットが受信機又はアプリケーションでタイムリーに受信されるように解放されなければならない時間,及び
f) QL thresholdはバッファされることになるパケットの最大数（閾値が動的に設定され、初期バッファリングの限度及び解放されるパケットの周期を制御する）、.
を含むグループから選択される少なくとも１つのアルゴリズムに従って前記受信機バッファを管理することを更に含む、方法。
【請求項１７】
最も妥当な接続性戦略を発見し、選択し、実行し及び評価するための柔軟性プラットフォームを用いる、デジタルデータのリアルタイムストリーミングの方法であって、
ａ）送信機でデジタルデータのバッファ、
ｂ）バッファされたストリームデジタルデータを前記送信機から受信機への送信、
ｃ）前記送信機から前記ストリームデジタルデータの受信、
ｄ）前記送信機から前記受信機へのデジタルデータの選択的再送信、
ｅ）ストリームデジタルデータの送信のダイナミック負荷バランス
を含み、
前記送信機バッファの管理ステップを更に含み、前記バッファでの管理ステップは遅延又は欠損パケットがタイムリーな方法により受信機で更にプレイアウトし得るためにそれらを再送信するパケットの選択的再送信をみ、
前記ダイナミック負荷バランスは現在のネットワーク状態及びアプリケーション特性に応じたダイナミック形式で、複数の利用可能インターフェースを介して送信用の単一ビデオストリームに属するパケットを分割するための率の知的選択である、方法。
【請求項１８】
前記受信機で順序がばらばらで到達しているパケットは前記受信機でバッファされ、再整理される、それによりそれらがタイムリーな方法でアプリケーションに到達する、請求項１７の方法。
【請求項１９】
前記デジタルデータがパケット状であり、前記受信機でバッファされたパケットはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、各リアルタイムプレイアウト期限と関連している、請求項１８の方法。
【請求項２０】
前記パケットはフォーマット情報符号化／プロトコルヘッダを含み、前記受信機での前記フォーマット情報はパケット毎にプレイアウト期限を決定するために処理される、請求項１９の方法。
【請求項２１】
各パケットの前記プレイアウト期限はパケットが前記送信機で生成される時点の固定値である、請求項２０の方法。
【請求項２２】
前記送信機と受信機の間の局所クロック同期を更に含み、
Tplayout = T generation + Ttoleranceであり、
但し、
Tplayout =前記第１パケットが前記アプリケーションに搬送されるとき計算されるプレイアウト時間,
Tgeneration = パケットが前記送信機で発生される時間、そして
Ttolerance = 前記第１パケットがバッファされた時間に基づいて計算された許容時間
である、請求項２１の方法。.
【請求項２３】
前記送信機でパケットをマーキングし、タイムスタンピングすることを更に含む、請求項１９の方法。
【請求項２４】
前記送信機でパケット処理を更に含み、前記パケット処理はカスタムヘッダを各パケットに追加し、前記カスタムヘッダは前記パケットが送信されることになるインターフェースを表す、請求項１９の方法。
【請求項２５】
前記方法はリアルタイムアプリケーションであり、前記カスタムヘッダは連続して増加する局所的に発生するパケット、送信機でのパケット処理モジュールがパケットを受信する局所時間を示すタイムフィールドを更に含む、請求項９の方法。
【請求項２６】
前記デジタルデータはパケット状であり、前記受信機バッファはプレイアウト期限データを含み、パケットをタイムリーな方法で目標アプリケーションに供給し、次式：
Tplayout = Tgeneration + Ttolerance
但し、Tplayout = 前記第1パケットが前記アプリケーションに配送される計算されるプレイアウト時間、
Tgeneration =パケットが送信機で発生される時間、そして
Ttolerance =前記第1パケットがバッファされていた時間に基づいて計算される許容時間を用いてパケット毎にプレイアウト期限を計算するためにカスタムヘッダ情報を用いる、請求項１８の方法。
【請求項２７】
プレイアウト期限が経過したバッファ済みパケットを減少するステップを更に含む、請求項２５の方法。
【請求項２８】
前記デジタルデータはパケット状であり、更に、前記受信機バッファで同じパケットの複数のコピーを受信し、同じパケットの前記複数のコピーの１つの他を破棄することを更に含む、請求項１８の方法。
【請求項２９】
前記パケットはパケットｉｄフィールドを含むカスタムヘッダを有し、前記パケットｉｄフィールドに基づいてパケットを整理し直し、パケットがアプリケーションに解放される前に前記パケットｉｄフィールドを取り去ることを含む、請求項２８の方法。
【請求項３０】
前記送信機バッファから前記受信機バッファにパケットを下記アルゴリズム、
ａ）最後に配送されたパケットのプレイアウト期限が経過しようとしている、
ｂ）パケットバッファのパケットの数が閾値を超える、及び／又は
ｃ）最後のパケット開放からの時間が閾値を超える、
に従って再送信するステップを更に含む、請求項１８の方法。
【請求項３１】
CurrentTime > Tplayout - Tthreshold2),
(QueueLength > QL threshold2),
(CurrentTime > Trelease - Tthreshold4), 及び
(((CurrentTime > Tplayout - Tthreshold1)OR (QueueLength > QLthreshold1) OR (CurrentTime > Trelease - Tthreshold3))AND(nextPktAvailable ==1)).
但し、a) QueueLengthはパケットの数,
b) CurrentTimeは現在時間,
c) Treleaseは最後のセットのパケットが配送された時間,
d) Tplayoutはプレイアウト期限,
e) Tthresholdはパケットが受信機又はアプリケーションでタイムリーに受信されるように解放されなければならない時間,及び
f) QL thresholdはバッファされることになるパケットの最大数（閾値が動的に設定され、初期バッファリングの限度及び解放されるパケットの周期を制御する）、.
を含むグループから選択される少なくとも１つのアルゴリズムに従って前記受信機バッファを管理することを更に含む、請求項１８の方法。
【請求項３２】
デジタルデータパケットを再送信するシステムであって、
パケットバッファを有する送信装置と、
前記送信機装置はパケットが必要に応じて再送信し得るようにパケットが作られるように、前記バッファにそれらをコピーし、記憶し、そのプレイアウト期限が経過したバッファされたパケットを破棄するように構成され、
前記受信装置は前記送信装置から特定パケットを要求するように構成された受信装置と、
デジタル記憶媒体に記憶され、紛失パケットの再送信を要求するためのアルゴリズムを含み、紛失／欠損パケットの最小化に関して効果的であり、帯域幅利用に関して効率的であるソフトウエアと、
デジタル記憶媒体に記憶され、少なくとも１つのインターフェースを介してパケットを送信するための最も効率的な戦略を計算するようプログラムされている送信機アルゴリズムソフトウエアと、
を具備する、システム。
【請求項３３】
前記受信装置によって再送信のために要求されているパケットｉｄｓのリストを送信する手段を有する制御チャネルを更に含む、請求項３２のシステム。
【請求項３４】
前記パケットは各再送信パケットｉｄに付帯されたフィールドを有し、前記フィールドは送信緊急性を指示する手段と、パケットグループに属する緊急性要求の数を計数する手段と、グループ当たりのパケットｉｄｓの順序付リストを送信する手段とを有する、請求項３２のシステム。
【請求項３５】
前記アルゴリズムは
ａ）相当の時間で潜在的に紛失としてパケットを認識する、
ｂ）相当な時間で再送信要求を送信する、
ｃ）紛失パケット毎に緊急性のレベルを認識する、
ことを含む、請求項３２のシステム。
【請求項３６】
送信機から受信機にデジタルデータをストリーミングする方法であって、
ａ）送信機から受信機にデジタルデータのパケットを記憶し、順序付けする、
ｂ）前記送信機バッファから受信機にストリームデジタルデータを送信する、
ｃ）前記送信機から前記ストリームデジタルデータを受信する、
ｄ）受信ストリームデータを受信機バッファに記憶する、
ｅ）パケットを選択的に再送信する、
ｆ）プレイアウト期限データ及びフォーマット情報符号化／プロトコルヘッダを有する前記受信機バッファに記憶されたストリームデジタルデータパケットの送信をダイナミック負荷バランシングする、
ｇ）前記受信機で前記フォーマット情報を処理し、パケット毎にパケットが前記送信機で発生される時点で設定された固定値である前記プレイアウト期限を決定する、
ｈ）前記送信機及び前記受信機をクロック同期化する、
ｉ）以下のとき前記送信機バッファから前記受信機へ所定パケットｉｄで紛失パケットを再送信する、
１）最後に順序付けられたパケットのプレイアウト期限が経過しようとしている、
２）タイムアウト値が最後の送信要求がなされたときから生じる、及び／又は
３）紛失パケットの合計数が所定の閾値を超える、
紛失パケットｉｄと最近のパケットｉｄとの差が閾値及び／又は前記紛失パケットが所定閾値時間に入る直前のパケットのプレイアウト期限を超えるときパケットが紛失となる、方法。
【請求項３７】
デジタルパケット送信を負荷バランシングするシステムであって、
ａ）ネットワーク状態についての現在情報を提供する測定及び／又はモニタリング手段と、
ｂ）デジタル記憶媒体に記憶されるソフトウエアと、
を含み、前記ソフトウエアは現在ネットワーク状態及びアプリケーション特性を考慮して、各インターフェースの負荷のパーセンテージを決定するアルゴリズムを含み、前記測定及び／又はモニタリング手段はネットワーク状態を特徴付け、帯域内信号伝達及び帯域外信号伝達の組合せを使用するデータストリーム性能パラメータを使用し、帯域外信号伝達を最小に保つ、システム。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図１Ｂ】
【図２】
【図３】
【図４】
【公開番号】特開２０１３−７８１２６（Ｐ２０１３−７８１２６Ａ）
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願番号】特願２０１２−２５５７３９（Ｐ２０１２−２５５７３９）
【出願日】平成２４年１１月２１日（２０１２．１１．２１）
【分割の表示】特願２００９−５５４８０４（Ｐ２００９−５５４８０４）の分割
【原出願日】平成２０年６月３０日（２００８．６．３０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願日】平成２４年１１月２１日（２０１２．１１．２１）
【分割の表示】特願２００９−５５４８０４（Ｐ２００９−５５４８０４）の分割
【原出願日】平成２０年６月３０日（２００８．６．３０）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（５０４４７３６７０）テルコーディア・テクノロジーズ・インコーポレーテッド (72)
【Ｆターム（参考）】
[ Back to top ]