JP5507266B2 - 複数のインターフェースを介するビデオストリーム - Google Patents

複数のインターフェースを介するビデオストリーム Download PDF

Info

Publication number
JP5507266B2
JP5507266B2 JP2009554804A JP2009554804A JP5507266B2 JP 5507266 B2 JP5507266 B2 JP 5507266B2 JP 2009554804 A JP2009554804 A JP 2009554804A JP 2009554804 A JP2009554804 A JP 2009554804A JP 5507266 B2 JP5507266 B2 JP 5507266B2
Authority
JP
Japan
Prior art keywords
packet
receiver
packets
digital data
transmitter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2009554804A
Other languages
English (en)
Other versions
JP2010532594A (ja
Inventor
ゴパラクリシュナン、プラビーン
マノーサキス、キリアコス
バーグ、エリック、バン、デン
ファモラリ、デビッド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Publication of JP2010532594A publication Critical patent/JP2010532594A/ja
Application granted granted Critical
Publication of JP5507266B2 publication Critical patent/JP5507266B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H04L1/1838—Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/02—Arrangements for detecting or preventing errors in the information received by diversity reception
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H04L1/1841—Resequencing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0096—Channel splitting in point-to-point links

Description

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

Claims (8)

  1. 最適切接続性戦略を発見、選択、実行及び評価を行うために柔軟性プラットフォームを用いて、デジタルデータをストリーミングする方法であって、
    ａ）送信機から受信機へストリームデジタルデータを配信する、
    ｂ）前記送信機からの前記ストリームデジタルデータを受信する、
    ｃ）受信したストリームデジタルデータを受信機バッファに記憶する、
    ｄ）紛失データを選択的に再送信する、
    ｅ）ストリームデジタルデータの送信のためインターフェースを介して前記ストリームデジタルデータを分割するダイナミック負荷バランスを行う、
    ことを含み、
    前記受信機で記憶した受信ストリームデータのバッファ管理ステップと、
    前記デジタルデータはパケットに存在し、前記受信機でのバッファ管理ステップは複数のインターフェースを通過するパケットの再整理を行うことを含み、
    前記ストリームデジタルデータは前記パケットが送信されるため通過する前記インターフェースを識別する前記送信機によって追加されたインターフェースフィールドを有するパケットを含み、前記受信機は前記インターフェースフィールドを考慮してインターフェース毎の平均パケット遅延及び欠損率を決定し、前記ダイナミック負荷バランスのために前記送信機に前記インターフェース毎の前記平均パケット遅延及び前記欠損率を送信する、方法。
  2. 前記デジタルデータはパケットに存在し、前記受信機でのバッファ管理ステップは遅延又は欠損パケットがタイムリーな方法によって受信機で展開し得るためにそれらを再送信するためのパケットの選択的再送信を含む、請求項１の方法。
  3. 前記デジタルデータはビデオデータであり、前記受信機はビデオパケットをビデオ再生器に放出し、更に前記ビデオ再生器でリアルタイムストリームビデオを表示するステップを含む、請求項２の方法。
  4. 前記受信機で受信されたビデオデータストリームはパケットに分割されており、複数のインターフェースを介して送信されるビデオデータである、請求項３の方法。
  5. 前記受信機で受信されたビデオデータストリームは複製された少なくとも１つのパケットを有しており、複数のインターフェースを介して送信されたビデオデータである、請求項３の方法。
  6. 最も妥当な接続性戦略を発見し、選択し、実行し及び評価するための柔軟性プラットフォームを用いる、デジタルデータのリアルタイムストリーミングの方法であって、
    ａ）送信機でデジタルデータのバッファ、
    ｂ）バッファされたストリームデジタルデータを前記送信機から受信機への送信、
    ｃ）前記送信機から前記ストリームデジタルデータの受信、
    ｄ）前記送信機から前記受信機へのデジタルデータの選択的再送信、
    ｅ）ストリームデジタルデータの送信のためインターフェースを介して前記ストリームデジタルデータを分割するダイナミック負荷バランスを含み、
    前記送信機バッファの管理ステップを更に含み、前記バッファでの管理ステップは遅延又は欠損パケットがタイムリーな方法により受信機で更に展開し得るために前記遅延又は欠損パケットを再送信するパケットの選択的再送信を含み、
    前記ストリームデジタルデータは前記パケットが送信されるため通過するインターフェースを識別する前記送信機によって追加されたインターフェースフィールドを有するパケットを含み、前記受信機は前記インターフェースフィールドを考慮してインターフェース毎の平均パケット遅延及び欠損率を決定し、前記ダイナミック負荷バランスのために前記送信機に前記インターフェース毎の前記平均パケット遅延及び前記欠損率を送信する、方法。
  7. 前記デジタルデータはビデオデータのパケットであり、前記受信機はビデオパケットをビデオ再生器に放出し、前記ビデオ再生器でリアルタイムストリームビデオを表示するステップを更に含む、請求項６の方法。
  8. 前記受信機で受信されたビデオデータストリームはパケットに分割された、複数のインターフェースを介して送信されるビデオデータである、請求項７の方法。
JP2009554804A 2007-06-29 2008-06-30 複数のインターフェースを介するビデオストリーム Expired - Fee Related JP5507266B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US94719007P 2007-06-29 2007-06-29
US60/947,190 2007-06-29
US12/164,058 2008-06-29
US12/164,058 US8589578B2 (en) 2007-06-29 2008-06-29 Streaming video over multiple network interfaces
PCT/JP2008/062250 WO2009005162A2 (en) 2007-06-29 2008-06-30 Video streaming over multiple interfaces

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2012255739A Division JP5675757B2 (ja) 2007-06-29 2012-11-21 複数のインターフェースを介するビデオストリーム

Publications (2)

Publication Number Publication Date
JP2010532594A JP2010532594A (ja) 2010-10-07
JP5507266B2 true JP5507266B2 (ja) 2014-05-28

Family

ID=40039989

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2009554804A Expired - Fee Related JP5507266B2 (ja) 2007-06-29 2008-06-30 複数のインターフェースを介するビデオストリーム
JP2012255739A Active JP5675757B2 (ja) 2007-06-29 2012-11-21 複数のインターフェースを介するビデオストリーム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2012255739A Active JP5675757B2 (ja) 2007-06-29 2012-11-21 複数のインターフェースを介するビデオストリーム

Country Status (6)

Country Link
US (1) US8589578B2 (ja)
EP (1) EP2174438B1 (ja)
JP (2) JP5507266B2 (ja)
KR (1) KR101293372B1 (ja)
CA (1) CA2692444C (ja)
WO (1) WO2009005162A2 (ja)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8364863B2 (en) * 2008-07-11 2013-01-29 Intel Corporation Method and apparatus for universal serial bus (USB) command queuing
GB2463329B (en) 2008-09-10 2013-02-20 Echostar Advanced Technologies L L C Set-top box emulation system
US8959556B2 (en) * 2008-09-29 2015-02-17 The Nielsen Company (Us), Llc Methods and apparatus for determining the operating state of audio-video devices
US8055749B1 (en) 2008-09-30 2011-11-08 Amazon Technologies, Inc. Optimizing media distribution using metrics
US8325601B2 (en) * 2009-05-08 2012-12-04 Canon Kabushiki Kaisha Reliable network streaming of a single data stream over multiple physical interfaces
US8068514B2 (en) * 2009-05-22 2011-11-29 Canon Kabushiki Kaisha Efficient bandwidth utilization when streaming data over multiple network interfaces
US20110282980A1 (en) * 2010-05-11 2011-11-17 Udaya Kumar Dynamic protection of a resource during sudden surges in traffic
KR101808732B1 (ko) * 2010-06-09 2018-01-18 프라발라 인코포레이티드 복수의 서로 다른 네트워크를 통한 데이터 송신
US8793391B2 (en) 2010-11-30 2014-07-29 Deutsche Telekom Ag Distortion-aware multihomed scalable video streaming to multiple clients
KR101672253B1 (ko) * 2010-12-14 2016-11-03 삼성전자주식회사 휴대용 단말기에서 스트리밍 서비스를 제공하기 위한 장치 및 방법
WO2012114728A1 (ja) * 2011-02-25 2012-08-30 パナソニック株式会社 送信データ処理方法、情報処理方法、送信装置、及び受信装置
US9332005B2 (en) 2011-07-11 2016-05-03 Oracle International Corporation System and method for providing switch based subnet management packet (SMP) traffic protection in a middleware machine environment
CN103621048B (zh) 2011-07-11 2016-08-17 甲骨文国际公司 在中间件机器环境中利用多播组和分组处理代理中的至少一种来支持泛洪机制的系统与方法
US9071418B2 (en) * 2011-07-29 2015-06-30 Blackfire Research Corporation Synchronous media rendering of demuxed media components across multiple devices
WO2013030811A1 (en) * 2011-09-02 2013-03-07 Universidade Do Porto Method and apparatus for feedback-based real-time network coding
CN102355679A (zh) * 2011-09-08 2012-02-15 中兴通讯股份有限公司 一种实现网络中移动用户信息采集的方法、基站及系统
US9461777B2 (en) * 2011-11-21 2016-10-04 Qualcomm Incorporated Hybrid networking system with seamless path switching of streams
US8908523B2 (en) * 2012-04-23 2014-12-09 Apple Inc. Apparatus and methods for improved packet flow mobility
US9112820B2 (en) 2012-07-31 2015-08-18 Hewlett-Packard Development Company, L.P. Delay queues based on delay remaining
US20150288610A1 (en) * 2012-11-12 2015-10-08 Nec Corporation Relay apparatus for communication, relay system for communication, relay method for communication, and relay program for communication
EP2739117A1 (en) * 2012-11-29 2014-06-04 Deutsche Telekom AG System and method for simultaneously routing traffic through multiple network interfaces
US9722943B2 (en) 2012-12-17 2017-08-01 Qualcomm Incorporated Seamless switching for multihop hybrid networks
US9363132B2 (en) 2013-04-24 2016-06-07 International Business Machines Corporation Maximizing throughput of streaming media by simultaneously connecting to streaming media server over multiple independent network connections
EP2961092A1 (en) * 2014-06-27 2015-12-30 Orange Method for communicating multimedia data between two devices incorporating effectiveness of error correction strategies, associated computer program, communication quality module and device
US9584420B2 (en) * 2015-05-08 2017-02-28 Cisco Technology, Inc. Switching between loss-based and delay-based mode for real-time media congestion controllers
US10856046B2 (en) * 2015-12-18 2020-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Video playback buffer control
CN108293241B (zh) * 2015-12-23 2023-08-04 苹果公司 多频带数据传送设备和方法
US10778435B1 (en) * 2015-12-30 2020-09-15 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US10841222B2 (en) * 2016-07-05 2020-11-17 Ologn Technologies Ag Systems, apparatuses and methods for network packet management
US11570098B2 (en) * 2016-07-05 2023-01-31 Six Impossible Things Before Breakfast Limited Systems, apparatuses and methods for cooperating routers
EP3482569A4 (en) 2016-07-05 2020-01-15 Vishare Technology Limited CONTINUOUS VIDEO BROADCASTING METHODS AND SYSTEMS
KR102656013B1 (ko) 2016-10-28 2024-04-11 삼성전자주식회사 컨텐츠 출력 장치 및 그 제어 방법
EP3923495A1 (en) 2016-11-11 2021-12-15 OLogN Technologies AG Systems, apparatuses and methods for cooperating routers
US10693928B2 (en) * 2017-01-30 2020-06-23 Wipro Limited Method and device for adaptive streaming of multimedia data
EP3404886A1 (en) * 2017-05-15 2018-11-21 IMEC vzw Network stack for a plurality of physical communication interfaces
EP3540993A1 (en) * 2018-03-15 2019-09-18 InterDigital CE Patent Holdings Method and device for sending data packets on a first and a second links
US10721174B2 (en) 2018-10-09 2020-07-21 Cisco Technology, Inc. Network-based coordination of loss/delay mode for congestion control of latency-sensitive flows
US10891179B2 (en) * 2018-10-22 2021-01-12 Western Digital Technologies, Inc. Data storage device with deadlock recovery capabilities
KR20210133229A (ko) * 2019-03-26 2021-11-05 에스케이플래닛 주식회사 클라우드 스트리밍 서비스에서의 사용자 인터페이스 세션 복구 방법 및 이를 위한 장치
WO2021061157A1 (en) * 2019-09-27 2021-04-01 Viasat, Inc. Method and apparatus for distributing network traffic over multiple communication networks
US11784839B2 (en) * 2019-12-31 2023-10-10 Dish Network Technologies India Private Limited Dynamic low latency mode for a digital video production system
US11956352B2 (en) * 2020-01-15 2024-04-09 Mark Taylor Time randomizing interface protocol language encryption

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2004680A (en) * 1933-04-13 1935-06-11 Open electric arc-lamp for the gen
US6826616B2 (en) * 1998-10-30 2004-11-30 Science Applications International Corp. Method for establishing secure communication link between computers of virtual private network
US6804244B1 (en) 1999-08-10 2004-10-12 Texas Instruments Incorporated Integrated circuits for packet communications
US7024609B2 (en) * 2001-04-20 2006-04-04 Kencast, Inc. System for protecting the transmission of live data streams, and upon reception, for reconstructing the live data streams and recording them into files
US7117521B2 (en) * 2001-08-31 2006-10-03 Intel Corporation Method to measure the perceived quality of streaming media
US7010598B2 (en) * 2002-02-11 2006-03-07 Akamai Technologies, Inc. Method and apparatus for measuring stream availability, quality and performance
WO2004080011A1 (en) * 2003-03-03 2004-09-16 Matsushita Electric Industrial Co., Ltd. Mobile terminal having functions of program reception through broadcasting and through network communication, and program reception controlling method
JP3838237B2 (ja) 2003-04-30 2006-10-25 ソニー株式会社 無線通信システム、送信装置および受信装置
JP2005051299A (ja) * 2003-07-29 2005-02-24 Toshiba Corp パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法
US7664109B2 (en) * 2004-09-03 2010-02-16 Microsoft Corporation System and method for distributed streaming of scalable media
JP4069428B2 (ja) * 2005-03-14 2008-04-02 船井電機株式会社 データ伝送システム
EP1866788B1 (en) * 2005-04-01 2018-06-13 Cisco Technology, Inc. Stream control failover
JP4657305B2 (ja) * 2005-12-08 2011-03-23 シャープ株式会社 通信システム及び通信端末
JP4541293B2 (ja) * 2005-12-14 2010-09-08 日本電信電話株式会社 無線パケット通信方法および無線パケット通信システム
FR2895181B1 (fr) 2005-12-16 2008-12-05 Mediatvcom Sarl Procede et systeme de transmission d'un flux de donnees multimedia
WO2010045109A1 (en) * 2008-10-17 2010-04-22 Azuki Systems, Inc. Method and apparatus for efficient http data streaming

Also Published As

Publication number Publication date
KR20090080933A (ko) 2009-07-27
JP2013078126A (ja) 2013-04-25
JP5675757B2 (ja) 2015-02-25
EP2174438B1 (en) 2018-09-05
CA2692444C (en) 2014-06-03
KR101293372B1 (ko) 2013-08-05
WO2009005162A3 (en) 2009-04-16
US8589578B2 (en) 2013-11-19
CA2692444A1 (en) 2009-01-08
EP2174438A2 (en) 2010-04-14
WO2009005162A2 (en) 2009-01-08
US20090019505A1 (en) 2009-01-15
JP2010532594A (ja) 2010-10-07

Similar Documents

Publication Publication Date Title
JP5507266B2 (ja) 複数のインターフェースを介するビデオストリーム
KR101594304B1 (ko) 무선 통신 네트워크에서 다중경로 전송 접속을 위한 동적 서브플로우 제어
JP4805081B2 (ja) 無線中継装置、無線中継方法および無線中継プログラム
US8982847B2 (en) Packet aggregation
Xu et al. CMT-NC: improving the concurrent multipath transfer performance using network coding in wireless networks
US20220060879A1 (en) Message ordering for network based mobility management systems
TWI323600B (en) Mobile handover utilizing multicast in a multi-protocol label switching (mpls)-based network
JP4840365B2 (ja) 通信装置、通信システム、通信方法、および、通信プログラム
US11159423B2 (en) Techniques for efficient multipath transmission
JP2004531971A (ja) モバイル・アドホック・ネットワークにおけるソフトウェア・アーキテクチャ・プロトコル・スタックのインターネット・プロトコル・ルーティング層の下に埋め込まれたルーティング・プロトコル
JP2010532952A (ja) 送信ノードにおける輻輳制御
Sharma et al. CL-ADSP: Cross-Layer adaptive data scheduling policy in mobile ad-hoc networks
EP1868334B1 (en) Quality of service securing method and apparatus
JP2006101428A (ja) 無線ネットワークの制御装置及び制御方法、制御プログラム並びに記録媒体
Cao et al. 2 M 2: A potentially underperforming‐aware path usage management mechanism for secure MPTCP‐based multipathing services
JP2012114584A (ja) 無線通信システム
JP2009033676A (ja) 通信システム、通信装置およびパケット伝送方法
Zhong et al. Adaptive load balancing algorithm for multi-homing mobile nodes in local domain
Kumar et al. Device‐centric data reordering and buffer management for mobile Internet using Multipath Transmission Control Protocol
JP4847543B2 (ja) メディアフレームの耐性のある表現形を使用してメディア伝送品質を改善する方法および装置
Bhat et al. MPTCP combining congestion window adaptation and packet scheduling for multi-homed device
Liu et al. A multi-layer approach to support multimedia communication in mesh networks with qos
Mahapatra et al. RCM-BR: An efficient rate control protocol for multimedia delivery in Wireless Internet
JP2009044601A (ja) 無線送信装置、無線通信システム、無線端末、通信装置、送信方法、およびプログラム
KR20070081810A (ko) 이동통신 시스템에서 패킷혼잡 제어 장치 및 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120522

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120822

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120829

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120921

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120928

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121022

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121029

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121121

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130319

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130618

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130625

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130719

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130726

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130819

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130826

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130826

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131029

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20131205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140124

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140218

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140319

R150 Certificate of patent or registration of utility model

Ref document number: 5507266

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

Free format text: JAPANESE INTERMEDIATE CODE: R313117

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R360 Written notification for declining of transfer of rights

Free format text: JAPANESE INTERMEDIATE CODE: R360

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees