JP7173587B2 - パケット伝送システムおよび方法 - Google Patents

Description

（関連出願の相互参照）
本出願は、（１）２０１６年１２月２１日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第６２／４３７６３５号、および（２）２０１７年９月１４日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第６２／５５８６１０号の非仮出願であり、かつそれらの優先権を含む全ての利益を主張するものである。これらの出願の両方は全て参照により組み込まれている。

本開示は、一般に電子通信の分野に関し、より具体的にはレイテンシ、スループット、ジッターおよびパケットシーケンスなどの競合する要求を有するプロトコルのための向上したパケットの伝送と、個々のデータ接続が損失性であったり、信頼できなかったり、あるいは著しく異なり得るか可変的なレイテンシ、伝送速度またはパケットロスを有し得る状況において向上した伝送速度および信頼性を実現するための複数のデータ接続の結合とに関する。

有線および無線ネットワークを通した電子データの伝送は各種パケット化法を用いて行うことができる。例えばパケットは、ユーザデータグラムプロトコル（ＵＤＰ）および伝送制御プロトコル（ＴＣＰ）などの各種プロトコルの下で提供され得る。ＵＤＰパケットの場合、パケットは「ベスト・エフォート型」ベースで提供され、これはトランスポート層にパケットごとに送信されるパケットの受信に関する肯定応答が存在しないことを意味する。従って、トランスポート層における効率的な伝送は単純化されており、乱れた順番のパケットまたは失われたパケットを柔軟に取り扱うのをアプリケーションに任せる。ＴＣＰパケットの場合、トランスポートプロトコルの一部としてエラー検査が行われ、かつアプリケーションが全てのデータを確実かつ順番通りに受信するのを保証するために、ＴＣＰパケットシーケンス番号および肯定応答が利用される。失われたパケットは、例えば明示的に再送される。

ＴＣＰを用いる場合、輻輳制御アルゴリズムが誤った順番のパケットをネットワーク伝送エラーによって引き起こされたとみなして伝送速度を落としてこれらの認識されたエラーを補償するので、誤った順番のパケットの受信は、ＴＣＰに組み込まれた肯定応答および再要求プロセスにより伝送効率に影響を与える場合がある。この問題は、著しく異なるレイテンシを有するデータ接続を単純に結合させ、これにより著しい伝送速度の低下（「ヘッドオブラインブロッキング（ｈｅａｄ ｏｆ ｌｉｎｅ ｂｌｏｃｋｉｎｇ）」問題として知られている）が生じる場合に特に重要である。

異なるネットワークおよび／または接続を互いに結合することは技術的に難しい。単一のネットワークおよび／または接続は、特に伝送エラー、信号損失および冗長性の欠如を引き起こしやすい。結合されたネットワークおよび／または接続は、取材および報道などの様々なシナリオで特に有用であるが、その理由は、これらのシナリオは、個々に信頼できる接続を容易に利用可能でない場合があったり（例えば、農村地域、高地）、あるいは利用可能であったとしても混雑していたり（例えばスポーツイベント）、十分に機能しなかったりする（例えば自然災害後）様々な環境を通る信頼できる高帯域幅伝送を必要とするからである。

出願人らは、いくつかの実施形態では、ハイブリッドネットワーク接続を確立する際のネットワーク技術の技術的特徴の利用に対して非従来的な手法を適用する改良されたデータ伝送管理解決法を開発した。さらに詳細に記載されているように、さらなる技術的用法および手法は、実行可能な接続を確立するという措置が求められるため（例えば、上に記載したように「ヘッドオブライン」ブロッキング問題を回避するため）、ＴＣＰは特に結合するのが難しい。これらの改良されたハイブリッド接続は、例えば高帯域幅のビデオ、音声または他のデータを転送するために使用することができる。例えば災害状況では、特に緊急通信を確立し、地上報道を提供し、緊急遠隔医療を可能にするために改良されたハイブリッド接続を利用することができる。

ネットワーク接続を通してデータフローを制御するためのネットワークゲートウェイが、対応する方法、装置およびコンピュータ可読媒体と共に本明細書に記載されている。本ゲートウェイは、いくつかの実施形態では、プログラムコードまたはコンピュータ論理の形態のソフトウェアおよび組み込みファームウェアを代表とする命令セットに従ってデータパケットを受信してルーティングするように構成された、プロセッサ、インタフェース、バス、電源、メモリ（ＲＯＭ、ＲＡＭ、フラッシュ）などの構成要素を備えた物理的なハードウェア装置であってもよい。

本ネットワークゲートウェイは一例では、本明細書中のいくつかの例に記載されているように、ＴＣＰ接続を結合するために特に最適化された専門の計算装置であってもよい。本ネットワークゲートウェイは他の例では、より大きなシステムの一部としてプロセッサおよび／または他のコンピューティングハードウェアを用いて実装されていてもよい。本ネットワークゲートウェイは単一の装置であってもよく、あるいは場合によっては、一斉に動作する複数の装置であってもよい。受信の時点で信号を再構築するために対応する結合解除サーバが設けられていてもよい。

一実施形態では、本ネットワークゲートウェイは複数のネットワーク接続を通してデータフローをルーティングするように構成されており、本ネットワークゲートウェイは、複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースと、少なくとも１つのプロセッサであって、複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、パケットのデータフローの少なくとも１つのパケットを解析してデータフローのためのデータフロークラスを特定することであって、そのデータフロークラスは、データフローの少なくとも１つのネットワークインタフェース要件を定めることと、データフロークラスおよび時変ネットワーク伝送特性に基づいてデータフロー内のパケットを複数のネットワーク接続を通してルーティングすることとのために構成された少なくとも１つのプロセッサとを備える。

別の実施形態では、本ネットワークゲートウェイは、複数のネットワーク接続を通してデータを伝送するための第１のネットワークインタフェースを含む複数のネットワークインタフェースを備える。本ネットワークゲートウェイは、第１のネットワークインタフェースを通してパケットの順次バーストを送信することのために構成されたプロセッサを備える。プロセッサは、パケットの順次バースト内のパケットが受信ノードで受信された場合に記録されるタイムスタンプおよびパケットのサイズに基づいて、第１のネットワークインタフェースの帯域幅を生成し、第１のネットワークインタフェースの生成された帯域幅に基づいて複数のネットワーク接続を通して順次パケットのデータフローをルーティングする。

一態様では、第１のネットワークインタフェースの帯域幅を生成することは、バースト内の最初もしくは最後のパケットと合体されていないバースト内のパケットのタイムスタンプに基づいて帯域幅を生成することを含む。

別の態様では、第１のネットワークインタフェースの帯域幅を生成することは、バースト内の特定のパケットの受信タイムスタンプを特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含む。

別の態様では、受信ノードが定期的な間隔で受信されたパケットを処理する場合、第１のネットワークインタフェースの帯域幅を生成することは、（ｉ）帯域幅決定においてエンドパケットとして選択されたバースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、（ｉｉ）エンドパケットとして選択されたバースト内のパケットの受信タイムスタンプをエンドパケットに先行するバースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することとを含む。

別の態様では、プロセッサは、データフロー内の順次パケットの各パケットのために、データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、複数のネットワーク接続の監視されたレイテンシに基づく複数のネットワーク接続およびデータフロー内の他のパケットのネットワーク接続のうちの１つを通してルーティングするためのパケットを提供することのために構成されている。

別の態様では、所望のシーケンスは、データフロー内の順次パケットの元のシーケンスである。

別の態様では、所望のシーケンスは、そのシーケンス内でのパケットの再送をトリガーしないパケットの少なくとも１つの誤順序付けを含むシーケンスである。

別の態様では、プロセッサは、複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、パケットを宛先ノードにルーティングする前に肯定応答をソースインタフェースに送信することと、パケットが宛先ノードにルーティングされる前にパケットを少なくとも１つのバッファに格納することとのために構成されている。

別の態様では、少なくとも１つのプロセッサは、複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて少なくとも１つのバッファのサイズを動的に制御することのために構成されている。

別の態様では、少なくとも１つのプロセッサは、複数のネットワーク接続の伝送特性の監視および順次パケットのデータフローの受信における不均等分配に基づいて、パケットの肯定応答の送信および格納を制御することのために構成されている。

別の態様では、少なくとも１つのプロセッサは、第１のデータ接続の帯域幅およびそれを通してデータフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも１つに基づいてパケットを提供するように構成されている。

別の態様では、少なくとも１つのプロセッサは複数のデータフローのためにパケットをルーティングするように構成されており、ここでは少なくとも１つのプロセッサは、複数のデータフローの分類に基づいて複数のネットワーク接続のうちの１つを通してルーティングするための複数のデータフローのパケットを提供することのために構成されている。

別の態様では、複数のデータフローの１つの分類は、閾値体積のデータがルーティングされた後に変わる。

別の態様によれば、複数の同時データ接続を通した複数のフローに属するデータパケットのルーティングの制御に適したデータ伝送管理装置（「ゲートウェイ」）が提供され、各データ接続は複数のフローに属する複数のパケットを運び、ここでは、複数のフローの少なくとも１つは実質的に順次に伝送されるデータパケットを有し、データ伝送管理装置は、１つ以上の入力データ接続からフロー（入力データパケットのシーケンス）を受信するように構成されたバッファマネージャであって、バッファマネージャは入力データパケットをルーティングのために抽出された１つ以上のバッファに格納し、各入力データパケットはフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられているバッファマネージャと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続するように構成された接続制御装置と、複数のデータ接続を介して１つ以上のバッファからの入力データパケットのルーティングを制御するためにバッファマネージャによって実行される命令を生成することによってバッファマネージャの動作を制御するように構成されたスケジューラとを備え、そのルーティングは、各個々の入力データパケットのために、（ｉ）そこを通って個々の入力データパケットが伝送される対応するデータ接続、および（ｉｉ）個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスを決定する。

別の態様では、上記装置は、一緒または個々に監視される複数のデータ接続のそれぞれを通した伝送特性を監視するように構成されたネットワーク特性監視ユニットをさらに備える。

別の態様では、上記装置は、１つ以上のバッファに格納された入力データパケットのルーティングを制御するためのスケジューラによって実行される命令を生成することによってスケジューラの動作を制御するように構成された動作エンジンをさらに備え、ルーティングは複数のデータ接続を通して監視される伝送特性に基づいて制御され、入力データセットに基づいてルーティングを修正するように構成された動作エンジンは、スループット、パケットロス、レイテンシ、明示的輻輳通知（ＥＣＮ）コスト、信頼性、ジッター、ユーザ／管理嗜好および他のネットワーク接続制約のうちの少なくとも１つに関する情報を提供する。

別の態様では、上記装置は、入力データパケットのそれぞれのシーケンス番号に基づいてデータ伝送管理装置によって受信された入力データパケットを再構成するように構成されたシーケンサをさらに備える。

別の態様では、上記装置は、固有の特性に基づいてフローを識別し、かつ動作エンジンおよびシーケンサにフロー情報を提供するように設計されたフロー識別エンジンをさらに備える。

別の態様では、上記装置は、入力データフローおよびそれらの要求を分類し、かつフローの特性および要求に基づいて、この情報を入力データフローのルーティングの修正のために動作エンジンに提供し、かつデータパケットを再構成する方法の修正のためにシーケンサに提供するように構成されたフロー分類エンジンをさらに備える。

別の態様では、バッファマネージャは、複数のデータ接続の伝送特性の可変性を補償するための過剰バッファリングと、伝送の不均等分配（「バースト性の伝送」）とを提供するようにさらに構成されている。

別の態様では、動作エンジンは、複数のデータ接続の各データ接続に関して帯域幅遅延積を決定するようにさらに構成されており、帯域幅遅延積はスケジューラによって制御されるようなルーティングを修正するために使用される。

別の態様では、動作エンジンは、不完全な情報が利用可能な場合に帯域幅推定を行うようにさらに構成されている。

別の態様では、１つ以上の種類のデータトラフィック（フロー）は、ＦＴＰ、ＤＮＳ、ＨＴＴＰ、ＳＳＨおよびＳＳＬ／ＴＬＳのうちの少なくとも１つを含む。

別の態様では、動作エンジンは、１つ以上のデータフローのどれがレイテンシセンシティブであるかを決定するように構成されており、かつレイテンシセンシティブである１つ以上のデータフローのために、より低いおよび／または同様のレイテンシ特性を有する複数のデータ接続のデータ接続を介して、対応する入力データパケットのルーティングを優先的に維持する。このシナリオでは、動作エンジンは過剰バッファリング／バッファブロートを防止するために、この複数のデータ接続を介するレイテンシセンシティブでないフローのルーティングも防止してもよい。

別の態様では、動作エンジンは、複数のデータ接続を通してそれらの性能を最適化するために公知のプロトコルのヘッダー情報を修正するようにさらに構成されている。例えば、複数のデータ接続が１つ以上の高レイテンシ地上波衛星接続を含む場合、最適化エンジンは、フローが高帯域幅遅延積を利用できる（ＴＣＰ加速法として知られている）ようにするために、宣伝されているＴＣＰウィンドウサイズを調整してもよい。これらの変更は、フロー毎ベースでさらなるパケットをバッファするためのバッファマネージャをさらに必要としてもよい。別の例は、データパケットの断片化を防止するために複数のデータ接続によってサポートされる最も小さいＭＳＳ（最大のセグメントサイズ）に一致させるためのＴＣＰ ＭＳＳヘッダオプションの修正である。

別の態様では、複数のデータ接続を通してデータフロー（データパケットからなる）のルーティングを制御して複数のデータフローのうちの少なくとも１つが実質的に順次に伝送される改良された伝送性能を提供するためのデータ伝送管理方法が提供され、データ伝送管理方法は、１つ以上の入力データソースから、データフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられている入力データパケットのストリームまたはシーケンスを受信して、ルーティングのために抽出された１つ以上のバッファに格納することと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続することと、１つ以上のバッファを制御して入力データパケットを複数のデータ接続を通してルーティングするスケジューラによってルーティング命令を生成することであって、上記命令は各個々の入力データパケットのために、（ｉ）そこを通って個々の入力データパケットが伝送される対応するデータ接続と、（ｉｉ）個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスとを提供することと、入力データパケットをルーティング命令に従ってルーティングすることとを含む。

別の態様では、命令を格納する非一時的コンピュータ可読媒体が提供され、上記命令は実行されると、プロセスに複数のデータ接続を通したデータフロー（データパケットからなる）のルーティングを制御するためのデータ伝送管理方法の工程を行わせて、複数のデータフローのうちの少なくとも１つが実質的に順次に伝送される改良された伝送性能を提供し、本方法は、１つ以上の入力データソースから、データフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられている入力データパケットのストリームまたはシーケンスを受信して、ルーティングのために抽出された１つ以上のバッファに格納することと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続することと、スケジューラによってルーティング命令を生成し、１つ以上のバッファを制御して入力データパケットを複数のデータ接続を介してルーティングすることであって、上記命令は、各個々の入力データパケットのために、（ｉ）そこを通って個々の入力データパケットが伝送される対応するデータ接続と、（ｉｉ）個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスとを提供することと、入力データパケットをルーティング命令に従ってルーティングすることとを含む。

様々なさらなる態様では、本開示は、対応するシステムおよび装置と、そのようなシステム、装置および方法を実装するための機械実行可能コード化命令セットなどの論理構造を提供する。

この点に関して、少なくとも１つの実施形態を詳細に説明する前に、当該実施形態は適用において、以下の説明に記載されているか図面に図示されている構成の詳細または構成要素の配置に限定されないことを理解されたい。また当然のことながら、本明細書で用いられている表現法および用語は説明のためのものであり、限定するものとしてみなされるべきではない。

本明細書に記載されている実施形態に関する多くのさらなる特徴およびそれらの組み合わせは、本開示を読んだ後に当業者には明らかになるであろう。

図において実施形態は例として示されている。説明および図は単に例示のためのものであって、理解を助けるものであることをはっきりと理解すべきである。

次に実施形態を単なる一例として添付の図を参照しながら説明する。

いくつかの実施形態に係る、それぞれがバッファマネージャ、動作エンジン、接続制御装置、ネットワーク特性監視ユニット、フロー分類エンジン（フロー識別および分類を取り扱う）、スケジューラおよびシーケンサを備え、かつ各ゲートウェイが特定のエンドポイントに接続された状態でＮ個のデータ接続によって連結された２つのゲートウェイを有するシステムのブロック概略図である。 いくつかの実施形態に係る、インターネットユーザが様々なネットワーク特性を有するトランスポートリンクを利用するゲートウェイの組み合わせを介してウェブに接続するシナリオを示すブロック概略図である。 いくつかの実施形態に係る、図２のネットワークに基づく例に係る６つのパケットの順序付けを実証することによってシーケンサの動作を説明するブロック概略図である。 いくつかの実施形態に係る、スケジューラがデータ接続のレイテンシを検討するように構成されているシナリオを示すブロック概略図である。 いくつかの実施形態に係る、帯域幅遅延積（ＢＤＰ）を示すブロック概略図である。 いくつかの実施形態に係る、少なくともフロー要求の寸法（サイズおよびレイテンシに対する感度）に基づく動作に適しているシステムを示すブロック概略図である。 いくつかの実施形態に係る、ネットワーク特性監視ユニットの動作を示すブロック概略図である。 いくつかの実施形態に係る、送信機が８つのパケットのバーストを送信するシナリオの例を示す帯域幅推定方法の例の説明である。 いくつかの実施形態に係る、実際の実装における非理想性を示す帯域幅推定方法の例の説明である。 いくつかの実施形態に係る、少なくとも部分的に割り込みレイテンシによるエラーを訂正するための手法の例を示す帯域幅推定方法の例の説明である。 いくつかの実施形態に係る、異なる条件下で少なくとも部分的に割り込みレイテンシによるエラーを訂正するための図８Ｃに記載されている例の変形を示す。 いくつかの実施形態に係る、割り込み調停技術が検討される例を示す帯域幅推定方法の例の説明である。 いくつかの実施形態に係る、衛星へのオフロード（単一の入力）を利用するシステムを示すブロック概略図である。 いくつかの実施形態に係る、複数の入力との混合の例を示すブロック図である。 いくつかの実施形態に係る、結合されていないディザスタリカバリー／ロードバランシング用途のために構成されたシナリオ（バッファが他方側で必要とされない、すなわち第２のゲートウェイが存在しないため、各フローは全く結合がない状態で特定のデータチャネルにスティッキーである）を示すブロック図である。 いくつかの実施形態に係る、トラフィックが結合されて第２のゲートウェイを介してルーティングされる、結合されたディザスタリカバリー／ロードバランシング用途のために構成されたシステムを示すブロック図である。 いくつかの実施形態に係る、２つ以上のエンドポイントを接続する一連のマルチパスゲートウェイを示す。 いくつかの実施形態に係る、従来の境界ゲートウェイプロトコル（ＢＧＰ）トランジット／ピアリング構成でインターネットに接続された２つのマルチホームサイトを示す。 いくつかの実施形態に係る、２つのサイト間のアウトバウンドおよびインバウンドトラフィックの両方をルーティングする方法の細分性制御を可能にするマルチパスゲートウェイを用いて接続された同じ２つのマルチホームサイトを示す。 いくつかの実施形態に係る計算装置の例示である。

方法、システムおよび装置の実施形態について図面を参照しながら説明する。

伝送制御プロトコル（ＴＣＰ）は３ウェイハンドシェイクを利用して接続を確立するものであり、故に信頼できるプロトコルである（無接続プロトコルであるユーザデータグラムプロトコル（ＵＤＰ）とは対照的）。これらのプロトコルは、例えばＲＦＣ７９３およびＲＦＣ７３２３に記載されており、これらは参照により本明細書に組み込まれる。

ＴＣＰは、より複雑な実装を必要とし、かつパケットの保証された順番どおりの配信に適している。この接続は、データ転送の前に最初に送信機と受信者との間で確立されなければならず、かつこの接続はデータ伝送の終了時に終了される場合が多い（割り当てられたリソースを解放するため）。

接続を確立するための最初のハンドシェイクは、データ伝送中に提供されるデータの順番を特定するためにデータ伝送中に使用される最初のシーケンス番号（例えば、任意のシーケンス番号）を提供する。

データ伝送中に、アプリケーションによって生成されたデータはデータパケットにセグメント化され、これらのデータパケットまたはセグメントは、それらが伝送のためにカプセル化されている場合には、頭に追加される情報（例えば、「ヘッダー」）を有する。ヘッダーは、例えばデータの各セグメントに関連づけられたシーケンス番号を示す伝送中に利用される情報を含む。シーケンス番号は、データのセグメントが乱れた順番で受信されたり、失われていたり（例えば、再送が要求される場合がある）、遅延していたり、破損されていたりなどしていても、データのセグメントを再順序付けして再構築することができるように、受信装置によって利用される。

ＴＣＰ法は、さらなるプロセスを利用して伝送に関する問題を減らすのを助け、これらのプロセスとしては、フロー制御、エラー検出、再送プロトコル、輻輳制御、選択的肯定応答などが挙げられる。

いくつかのシナリオでは、改良されたデータ通信性能は一斉に動作する複数のデータ接続またはネットワークの使用により得てもよい。これらのデータ接続またはネットワークは、ネットワークが論理的に結合または連結されるように互いに「結合されている」ものとみなされてもよい。一斉に動作する２つ以上のネットワークは、特にデータの伝送、エラーの訂正の提供などの１つ以上の通信機能を行ってもよい。この文脈では、１つ以上のネットワークは必ずしも別個のネットワークである必要はないが、同じネットワークを通る異なるチャネル、異なるデータ接続などを含んでもよい。

有利には各ネットワークの組み合わせられた特性を利用するか多岐にわたる特性および能力を用いて得ることができる改良されたデータ伝送特性（向上した信頼性および上昇した速度など）が存在し得るので、結合されたネットワークが望ましい。ネットワークとしては例えば、様々な特性および品質を有する特にセルラーネットワーク、イーサネットネットワーク、ＷｉＦｉ、衛星ネットワークが挙げられる。

例えば特定のネットワーク接続（例えば、パス、チャネル）は、特定の種類の通信（例えば、エラー検出および制御信号のために低レイテンシだが低帯域幅）のために理想的なものになり得、別のネットワーク接続は、別の種類の通信（例えば、高スループットデータ転送のために高帯域幅）にとって理想的なものになり得る。いくつかの実施形態では、エンドポイント（例えば、送信機、受信機）は、データの通信のために利用されている通信パスまたは手法に気づくことを必要としないようなネットワークの結合を提供することができる。

ＴＣＰは、かなりの数のネットワークおよびトラフィックのために使用されているプロトコルであるため、改良された転送特性を有する結合されたＴＣＰ解決法を有することが特に望ましい。但し、結合されたＴＣＰ解決法は実装するのが難しい。

ＴＣＰに関する課題（特に各パケットの肯定応答を必要とするため）は、特にデータ接続が異なるレイテンシなどの有意に異なる特性を有するネットワークを通して提供される場合に、ＴＣＰ接続は互いに「結合する」ことが技術的に難しいという点にある。これらの難点は、ネットワーク化されたＴＣＰ通信のために結合を利用する通信システムの効率に影響を与える。

データはデータ接続の組み合わせを通して（例えば、異なるネットワークを通して）１つ以上のエンドポイントに伝送され、データの伝送は、データを再度組み合わせることができ（例えば、「結合解除」システムによって）、かつ元のデータを伝送されたデータから再生成することができるように促進される。

その機能の接続および割当てのそのような「結合」は、例えば出願人の米国特許第８，８７３，５６０号に記載されており、この特許は参照により本明細書に組み込まれる。

結合プロセスは典型的に、その結合されたネットワークまたはデータ接続を通して伝送されるデータフローを含むデータパケットのセグメント化を必要とするので、ＴＣＰに関する結合の使用という文脈には克服する必要がある特定の技術的課題が存在する。異なる種類のトラフィック（例えば、ボイスデータ、制御パケット、ビデオデータ、エラー制御）は、順序付け要求によって異なって影響される。

データの転送のために結合されたネットワークを実装するシステムの技術的検討事項としては、限定されるものではないが、結合／結合解除の容易性（例えば、利用可能な計算リソースと比較した場合に必要とされる計算リソースおよび総計算時間）、転送レイテンシ、パケットロス、冗長性、セキュリティ、最大スループット、平均スループットおよび輻輳管理が挙げられる。

複数のネットワークまたはデータ接続を使用する単純なラウンドロビン解決法は典型的に、接続が同一もしくはほぼ同一の特性（例えば、レイテンシ、容量）を有する場合にのみ利点を提供する。１つの接続が著しくより高いレイテンシを有する場合は、全ての他のパケットは遅延し、かつ潜在的に送信機および受信機によって失われているか遅延しているものとして扱われ、それにより送信機にその輻輳ウィンドウ（ｃｗｎｄ）を減少させ、その結果としてスループットが低下する。

１つの接続が著しくより高い容量を有する場合、より低い容量の接続がその限界に達すると、その接続上で送信される全ての他のパケットが失われる。

従って、単純なラウンドロビン解決法は典型的にロードバランシングおよび冗長性には役立つが、接続が異なる特性を有する場合には、スループットを犠牲にして成り立つ。

マルチパスＴＣＰ（ＲＦＣ６８２４）は、ＷｉＦｉおよびセルラーなどの無線ネットワークを結合するために一般に使用されるトランスポート層解決法である。以下に記載するように、いくつかの実施形態のシステムは、マルチパスＴＣＰ（ＭＰＴＣＰ）などの他の解決法と比較して有利な性能を提供することができる。その理由は以下のとおりである。
１）ＭＰＴＣＰは、ＭＰＴＣＰを使用して処理することができるようにするために両方のエンドポイント（クライアント（Ｃ）およびサーバ（Ｓ））を必要とする。両方のエンドポイントは複数のパスについて知っているので、それらのうちのそれぞれの上で独立した輻輳制御アルゴリズムを実行させ、かつエンドポイントは、標準的なＴＣＰスタックに関する上記問題に遭遇しない。対照的に、ここに開示されているシステムは、いくつかの実施形態では、エンドポイントがＭＰＴＣＰと同時に使用するように構成されていない場合に機能したり、あるいは複数のパスはエンドポイントに直接接続されていなかったりする（すなわち、複数のパスはエンドポイント間の中間ホップにのみ知られている）。
２）ＭＰＴＣＰは、輻輳リンク（「連結された輻輳制御」）を通る他の非ＭＰＴＣＰフローと競合する場合に公平になるように試みる。広範囲にわたって配備されない明示的輻輳通知（ＥＣＮ）を使用しない場合、ＭＰＴＣＰシステムは自身が見ている任意の輻輳が全てのサブフローによって共有されているリンク上にあるか否かを推測する。それは多くの場合に誤って推測し、予想よりも低いスループットが生じる。

図１に例解されているように、システム１００は、本システムの送信部上で改良されたスケジューリング手法を利用し、かつパケットの順序付けを行う受信側でバッファリングシステムを使用するように構成されているものとして図示されている。図示されている構成要素は一実施形態では、互いとの相互動作のために構成されているハードウェア構成要素である。別の実施形態では、当該構成要素は別個の構成要素ではなく、当該構成要素のうちの２つ以上は特定のハードウェア構成要素（例えば、２つ以上の構成要素の機能を実施するコンピュータチップ）上に実装することができる。

いくつかの実施形態では、当該構成要素は同じプラットフォーム（例えば、同じプリント回路基板）上に存在し、システム１００は、移動させ、かつデータセンタ／現場に持ち運び可能な（ｆｉｅｌｄ ｃａｒｒｙ－ａｂｌｅ）装置（例えば、堅牢なモバイル送信機）などに接続させることができる単一の装置である。別の実施形態では、当該構成要素は分散型であり、全てがごく近接して位置していなくてもよく、それどころか電気通信を通して電子的に通信する（例えば、処理および制御は局所的に行われるのではなく、分散されたリソース環境に存在する構成要素（例えばクラウド）によって行われる。

モバイルシナリオでは、信号品質、ネットワークの利用能、品質ネットワークなどが最適以下である場合に、結合された接続性を提供することが特に望ましい（例えば、専門的な取材／ビデオ作成は強力なネットワークインフラのない位置で行われる場合がある）。

接続１、接続２．．．接続Ｎとしてラベルが付された１つ以上のネットワーク（またはネットワークチャネル）を表す多くの異なるデータ接続１０６（例えば「パス」）が示されている。単一のネットワークを通る複数のデータ接続／パスまたは１つ以上のネットワークを使用することができる複数のデータ接続が存在してもよい。

システム１００は、データを要求および受信するために使用される複数のパス／接続１０６に関する任意の情報を有する必要がない各種エンドポイント１０２、１１０またはアプリケーションと通信するように構成されていてもよい（例えば、エンドポイント１０２、１１０はパスまたは接続１０６とは独立して機能することができる）。異なるパス／接続１０６の寄与から元の伝送を再生成することができるように、受信されたデータを例えば再構築することができる（使用シナリオの例は、データセンタ施設にあるサーバラックの中に差し込まれて既存の放送インフラと一体化されて、改良されたネットワーキング能力を提供するように構成されている受信機によるビデオの再生成である）。

システム１００は、ソースエンドポイント１０２から入力（データフロー）を受信し、かつ各種接続１０６を通したデータパケットの改良された配信をスケジュールし、次いで宛先エンドポイントアプリケーション１１０への伝送前にシステム１０８の他端でデータパケットを順序付けする。そうすることでシステム１００は、帯域幅を増加させて利用可能な各種パスの最大帯域幅の合計に近づくように構成されている。単一の接続を使用する場合と比較して、システム１００は改良された信頼性も提供し、これはイベントが行われている際のライブイベントでの取材などの時間が限られた高感度なシナリオにおける重要な検討事項であり得る。これらのイベントでは、高い信号輻輳（例えば、スポーツイベント）、または１つ以上のパスを通る不信頼性（例えば、自然災害後のニュースの報道）が存在する場合がある。

様々な実施形態では、スケジューラおよびシーケンサの両方をクラウドコンピューティング実装から、あるいはエンドポイントにおいて（データがエンドポイントにおいてアプリケーションによって消費される前）、あるいはそれらの様々な組み合わせで提供することができる。

システム１００を調整して、特に性能、最良のレイテンシ、最良のスループット、最小のジッター（２つのシステム間のパケットフロー上のレイテンシにおける変動）、接続コスト、特定のフローのための接続の組み合わせを最適化し、かつ／またはそれらの優先順位をつけてもよい（例えば、システム１００が、伝送（データフロー）が内容種別Ｘであるという情報を有する場合、システム１００は同様のレイテンシを有するデータ接続のみを使用するように構成されていてもよいが、内容種別Ｙはデータ接続のより広範囲の混合を可能にしてもよい（あるいは、データ接続の組み合わせによってのみ達成することができるより大きな正味容量を必要としてもよい））。この調整は一般に本システムに対して提供されてもよく、あるいは各フロー（または位置、スタートポイントもしくはエンドポイントの所有者またはそれらの組み合わせ、伝送時間、利用可能な通信リンクのセット、伝送のために必要なセキュリティなどに基づくフローのセット）に固有であってもよい。

システム１００は、各ゲートウェイ１０４、１０８が一般にＴＣＰトラフィック（またはＵＤＰトラフィック、ＴＣＰおよびＵＤＰトラフィックの組み合わせ、あるいは任意の種類の一般的なＩＰトラフィック）を取り扱うためのスケジューラおよびシーケンサを有するという点で一般に双方向性であってもよいが、いくつかの実施形態では、１つのみのゲートウェイが必要とされてもよい（例えば、サービスとして単純なディザスタリカバリーが示されている図１１を参照）。

本システムのスケジューリング部の特徴は、所与の接続の帯域幅を推定するための新しい手法である（例えば図８を参照）。

システム１００は、例えば既存のインターネット接続（例えば、ＶｏＩＰ電話システム、またはウェブへの企業接続）のフェイルオーバーまたは追加として様々なシナリオのために利用することができ、それによりドロップされた一次インターネット接続を途切れなく置き換えるためにさらなるネットワーク（またはパス）が追加されるか、あるいは一次インターネット接続が飽和である場合に（図１１および図１２に示されているように）、より高価なネットワークのみを含めるために結合が使用される。別の使用は、トラフィックを異なる属性を有する他のデータ接続にオフロードするのを可能にすることによって、衛星などの高コスト（多くの場合、埋没原価）の高信頼性データ接続の使用を最大化する手段を提供することである（図９および図１０）。

いくつかの実施形態では、本システムは、複数のネットワーク接続を通してデータフローをルーティングすることのために構成されたネットワークゲートウェイである。

図１は、それぞれがバッファマネージャ１５０と、動作エンジン１５２と、接続制御装置１５４と、フロー分類エンジン１５６（フロー識別および分類に関与する）と、スケジューラ１５８と、シーケンサ１６０と、ネットワーク特性監視ユニット１６１とを備え、かつ各ゲートウェイが特定のエンドポイント１０２、１１０に接続された状態でＮ個のデータ接続１０６によって連結された２つのゲートウェイ１０４および１０８を有するシステムの概略を提供する。参照文字ＡおよびＢは、２つのゲートウェイ１０４および１０８のそれぞれの構成要素を区別するために使用されている。

各ゲートウェイ１０４および１０８は、複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースを含むように構成されており、かつ複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、パケットのデータフローの少なくとも１つのパケットを解析してデータフローのためのデータフロークラスを特定することであって、そのデータフロークラスは、データフローの少なくとも１つのネットワークインタフェース要件を定めるかまたはそれ以外の方法でそれに関連づけられていることと、データフロークラスおよび時変ネットワーク伝送特性に基づいてデータフロー内のパケットを複数のネットワーク接続を通してルーティングすることとのために構成されたプロセッサを備える（例えば、設定されたハードウェア、ソフトウェアまたは組み込みファームウェアを備える）装置である。

バッファマネージャ１５０は、トラフィック（本システムを通過する個々のフローおよび複数の同時フローの組み合わせの両方）をより効率的に管理するように構成された本ゲートウェイ内のバッファを設定するように構成されている。いくつかの実施形態では、バッファマネージャは別個のプロセッサである。他の実施形態では、バッファマネージャは、数ある活動の中でもバッファ管理（１５０）を行うように構成されているプロセッサによって提供される計算ユニットである。

動作エンジン１５２は、ユーザ／クライアント、宛先／サーバ、接続（例えば、レイテンシ、スループット、コスト、ジッター、信頼性）、フローの種類／要求（例えば、ＦＴＰ対ＨＴＴＰ対ストリーミングビデオ）ごとのいずれかで、受信された入力データセット（例えば、フィードバック情報、ネットワーク輻輳情報、伝送特性）に基づく１つ以上の決定論的方法および／または論理演算を適用して、結合された接続に適用される制約について本システムに伝えるように構成されている。例えば動作エンジン１５２は、一例ではコストに基づいて特定の種類のフローを特定の接続またはデータ接続のセットに限定するように構成されていてもよいが、異なるユーザまたはフローの種類の場合、信頼性および低レイテンシがより重要になり得る。例えば、公知の情報の１つ以上の要素に応じて異なる条件、トリガー、方法を利用してもよい。動作エンジン１５２は例えば、バッファマネージャと１５０同じか異なるプロセッサに設けられていてもよい。

動作エンジン１５２は、Ｎ個のデータ接続１０６を通したルーティングを制御する論理演算を決定する１つ以上のルールセットを生成、適用またはそれ以外の方法で操作または使用するように構成されていてもよい。

フロー分類エンジン１５６は、伝送のためにマルチパスゲートウェイ１０４によって受信された各データフローを評価するように構成されており、かつまだ分かっていなければ送信されているトラフィックの種類およびその要求を決定するためのフロー分類手法を適用するように構成されている。いくつかの実施形態では、ディープパケットインスペクション技術がその決定を行うように構成されている。別の実施形態では、上記評価は発見的方法または生成された際にマークまたはラベル付けされたデータフローに基づいている。別の実施形態では、上記評価は、本システムのユーザ／管理者によって提供されるルールに基づいている。別の実施形態では、方法の組み合わせが使用される。フロー分類エンジン１５６は、１つ以上のネットワークインタフェースと同時に使用するように構成されており、かつ電子回路またはプロセッサを用いて実装されていてもよい。

フロー識別は、例えばパケットのヘッダー情報（例えば、ソース／宛先ＩＰ、トランスポートプロトコル、トランスポートプロトコルポート番号、ＤＳＣＰフラグなど）を検査するデータフローのパケット内に提供されている情報の分析により行うことができる。

いくつかの実施形態で提供されるように、異なるレベルの識別を行ってもよい。例えば、パケット本体のコンテンツを、例えばディープパケットインスペクション技術を用いてさらに検査してもよい。

フローが識別されたら、分類はその要求に基づいてフローをカテゴリー化することを含んでもよい。分類例としては、
１．低レイテンシ、低～中程度のジッター、乱れた順番であってもよいパケット、高帯域幅（ライブＨＤビデオ放送）、
２．特に低レイテンシ、低～中程度のジッター、乱れた順番であってもよいパケット、中帯域幅（Ｓｋｙｐｅ（商標）、ＦａｃｅＴｉｍｅ（商標））（ジッターはアーティファクトまたは通信の低下を引き起こす可能性があるため、リアルタイム通信において問題を含んでいる）、
３．低レイテンシ、低～中程度のジッター、乱れた順番であってもよいパケット、低帯域幅（ＤＮＳ、ＶｏＩＰ）、
４．低レイテンシ、ジッター要求なし、順番どおりであるのが好ましいパケット、低帯域幅（対話型ＳＳＨ）
５．レイテンシ要求なし、ジッター要求なし、順番どおりであるのが好ましいパケット、中～高帯域幅（例えば、ＳＣＰ、ＳＦＴＰ、ＦＴＰ、ＨＴＴＰ）、および
６．レイテンシ要求なし、ジッター要求なし、順番どおりであるのが好ましいパケット、帯域幅要求なし、持続的大容量データ転送（例えば、ファイル／システムのバックアップ）など
である。

分類を行うことができる１つ以上の寸法としては、限定されるものではないが、
ａ．レイテンシ、
ｂ．帯域幅／スループット、
ｃ．ジッター、
ｄ．パケットの順序付け、および
ｅ．データ転送の体積
が挙げられる。

以下でさらに説明されているように、これらの分類寸法は、効率的な通信フローを向上させるのに有用である。レイテンシおよび帯域幅／スループットの検討は、矛盾する要求を有するフローが存在する場合に特に重要である。ジッターが対処される実施形態の例は以下でさらに説明されており、本システムは、例えばスケジューラにおけるバッファリングまたは特定の接続にスティッキーなフローの維持によりジッターに対応するように構成されていてもよい。パケットの順序付けは特にＴＣＰのための例と共に以下でさらに説明されており、データの体積を、フローをある種類（低レイテンシ、低帯域幅）から別の種類（レイテンシセンシティブでない、高帯域幅）に再分類することができるインジケータとして使用することができる場合に、データの体積は関連する。

他の分類寸法および分類が可能であり、上記は分類例として提供されている。異なる寸法または分類および／または上記のその中での組み合わせを作成してもよい。例えばメディア放送において、本システムは、クリップ（例えば、ＧＰＳ情報、タイミング情報、ラベル）に関連づけられたビデオデータおよびメタデータまたはビデオストリームに関連するＦＥＣデータを分類するように構成されていてもよい。

フロー分類を利用して、本システムが行うのを防止するように構成されている伝送（例えば、場合によってはピアツーピアファイル共有、または著作権下にあることが知られているマテリアル）、または段階的サービスを提供するという文脈において本システムが好むように構成されていてもよいトラフィック（例えば、別のものも特定のユーザまたはソフトウェアプログラムを好む）を除去および／または濾過して取り除くことができる。

例えばインターネットバックアップ利用のシナリオにおいて、結合されたバックアップが利用能において限られている場合があるとしても、本システムは、サポート組織へ／からのＶｏＩＰコールが当該組織内のコールよりも高いレベルのサービスを受けるように、そのように構成されていてもよい（ここでは、本システムは制約下にある場合に、エンドポイントがいくつかのコールの音声品質を他のコールよりも低下させたり、帯域幅制約がある場合に特定のコールをまとめて低下させたりする命令を生成することができる）。

スケジューラ１６０は、どのパケットがどの接続１０６に送信されるべきかに関する決定を行うように構成されている。スケジューラ１６０は改良されたＱｏＳエンジンとみなしてもよい。スケジューラ１６０は、いくつかの実施形態では、コンパレータ回路またはＦＰＧＡなどの１つ以上のプロセッサまたは独立型チップまたは構成された回路を用いて実装されている。スケジューラ１６０は、決定を行うために確認される一連の論理ゲートを備えていてもよい。

典型的なＱｏＳエンジンは単一の接続を管理するものであり、それはフロー識別および分類を行うように構成されていてもよいが、最終的な結果は、ＱｏＳエンジンがパケットを再順序付けした後それらを１つの接続上で送信するというものである。

対照的に、スケジューラ１６０は、フロー識別、分類およびパケット順序付けを行うように構成されているが、いくつかの実施形態のスケジューラ１６０は、データフローに改良された伝送特性を与え、かつ／またはユーザ／管理者によってフローのために設定されている（または各種ルールに提示されている）ポリシーを満たすために、どの接続にパケットを送信するかについての決定を行うようにさらに構成されている。スケジューラ１６０は、制御信号のセットをネットワークインタフェースに伝送してそれらのスイッチをオンまたはオフにするか、あるいはどれを使用してデータをルーティングすべきかを示すことによって、例えばネットワークインタフェース動作特性を修正してもよい。制御信号は、パケットのタイミング、特定の種類のトラフィックのためのネットワークインタフェースの予約などの、所望のルーティングの固有の特性を示す命令セットであってもよい。

例えば、以下の特性を有する２つの接続が検討される。
１）接続１：１ｍｓの往復時間（ＲＴＴ）、０．５Ｍｂｐｓの推定帯域幅、および
２）接続２：３０ｍｓのＲＴＴ、１０Ｍｂｐｓの推定帯域幅。

スケジューラ１６０は、もっぱらＤＮＳトラフィック（小さいパケット、低レイテンシ）のために接続１を予約することを試みることができる。この例では、接続１の容量に達する非常に多くのＤＮＳトラフィックが存在してもよく、スケジューラ１６０はトラフィックを接続２までオーバーフローさせるように構成することができるが、スケジューラ１６０は選択的に他の決定または因子に基づいてそのようなことを行うことができる。例えば、スケジューラ１６０が公正な決定を提供するように構成されている場合、スケジューラ１６０は最初に、過去Ｘ秒以内にかなりの量のＤＮＳトラフィックを既に送信したＩＰアドレスからのトラフィックをオーバーフローさせるように構成することができる。

スケジューラ１６０は、例えばハードウェアにおける１つ以上のプロセッサまたは同様の実装（例えばＦＰＧＡ）と一緒に動作するプロセスまたは方法に基づいて決定を処理するように構成されていてもよい。これらの装置は動作エンジン１５２の制御下での動作のために構成されていてもよく、データストリームをデータパケットに分割し、次いでデータパケットをバッファ（バッファマネージャによって管理される）の中にルーティングし、バッファはデータ接続の特性を考慮にいれながらパケット配信を最適化しようとするルールに従ってデータパケットをデータ接続に送る。

主要基準は、いくつかの実施形態ではレイテンシおよび帯域幅に基づくものであるが、いくつかの実施形態では、パス最大伝送ユニット（ＰＭＴＵ）も利用されてもよい。例えば、１つの接続が他の接続よりも著しく小さい（例えば、１５００バイトに対して５００バイトの）ＰＭＴＵを有する場合、その接続上で送信されるパケットが断片化される必要があるので、それはオーバーフローのための悪い候補として指定される（と共に、例えば回避されるか優先度が下げられてもよい）。

スケジューラ１６０は、いくつかの実施形態では、パケットを正しい順番で通して通信するように構成されている必要はなく、むしろ所望のＱｏＳ／ＱｏＥメトリクス（そのうちのいくつかはネットワーク制御装置によって定められてもよく、それ以外はユーザ／顧客によって定められてもよい）を満たすかまたは超えるために、パケットを多様な接続を通して通信することのために構成されている。パケットを乱れた順番で通信し得る場合は、シーケンサ１６２およびバッファマネージャを利用して受信されたパケットを再順序付けしてもよい。

パケットの順次バーストは、ネットワークインタフェースを通して伝送され、パケットの順次バースト内のパケットが受信ノードで受信された場合に記録されるタイムスタンプおよびパケットのサイズに基づいて、第１のネットワークインタフェースの帯域幅の推定値が生成される。次いで、第１のネットワークインタフェースの生成された帯域幅に基づきネットワーク接続のセットを通る順次パケットのデータフロー内のパケットをルーティングするために、その推定値を利用する。以下に記載するように、いくつかの実施形態では、バースト内の最初もしくは最後のパケットと合体されていないバースト内のパケットのタイムスタンプに基づいて帯域幅の推定値を生成して、下限帯域幅値を推定することができると共に上限帯域幅値を推定することができる（例えば、パケットの置換により）。送信されるパケットは、テストパケット、データパケット上のテストパケット「ピギーバッキング」またはハイブリッドパケットであってもよい。データパケットが「ピギーバッキング」のために使用される場合、いくつかの実施形態は、増加した冗長性についてそのようなデータパケットにフラグを設定することを含む（例えば、失われたパケットのため、特に帯域幅テスト目的のために使用されるパケットのために許容差を増大させるため）。

順次パケットは、シーケンサ１６２が消費のためにパケットを再構成することができるように、順番通りに、あるいはその順番からの許容される逸脱の範囲内で受信してもよい。いくつかの実施形態では、シーケンサ１６２は、信号を受信し、かつ再構成された信号である出力信号を生成する放送インフラの中に組み込むことができる物理的なハードウェア装置である。例えば物理的なハードウェア装置は、信号の受信および再構築のための第１段階として機能するラックマウント式のアプライアンスであってもよい。

シーケンサ１６２は、フローのために不必要なパケットの再要求または他のエラー訂正を減らすために、エンドポイントにおいて受信されたパケットを順序付けしてそれらを許容される順番でアプリケーションに伝送するように構成されている。その順番は、いくつかの実施形態では元の順番に従っている。他の実施形態では、その順番は、シーケンサ１６２がなおデータフローを再構築することができるような順番の許容限度内である。シーケンサ１６２は、例えば受信されたフローを滑らかにするためのバッファまたは他の機構を含んでいてもよく、いくつかの実施形態では、複数のネットワーク接続の伝送特性の監視および順次パケットのデータフローの受信における不均等分配に基づいて、肯定応答の送信およびパケットの格納を制御するように構成されている。

シーケンサ１６２は、例えばプロセッサ上に設けられているか、バッファから抽出された受信されたデータパケットからデータフローを再構築するように構成された動作エンジン１５２の制御下に設けられているハードウェア（例えば、フィールドプログラマブルゲートアレイ）に実装されていてもよい。

シーケンサ１６２は、フロー毎ベースで、各フローに許容されない複数の接続間のレイテンシの差を隠すように構成されている。

動作エンジン１５２は、他の構成要素（１５４を含む）によって提供される情報のアグリゲーターとして動作可能であり、シーケンサ１６２が所与のフローに対してどのように動作すべきかを示す１つ以上の制御信号によりシーケンサ１６２に指示を与える。

ＴＣＰなどのプロトコルのために構成されたシステムがパケットを受信するときは、本システムは一般に、パケットが順番通りに到着することを期待する（が要求しない）ように構成されている。但し本システムは、乱れた順番のパケットが到着することを予想するときに関して時間限界（通常は、何回かの複数回の往復時間すなわちＲＴＴ）を確立するように構成されている。また本システムは、発見的手法に基づく時間限界になるや否や失われたパケットを再送するように構成されていてもよい（例えば、３回のＤＵＰ ＡＣＫによってトリガーされる最初の再送）。

パケットが著しく異なるレイテンシを有する接続上でシーケンサ１６２に到着する場合、シーケンサ１６２（フロー毎ベースで）は、パケットを宛先に向かって前方に送信する前にそれらがおよそ同じ年齢（遅延）になるまでパケットをバッファするように構成されていてもよい。例えばフローが一致するレイテンシおよび低ジッターを要求する場合に、シーケンサ１６２はこれを行う。

シーケンサ１６２は、必ずしもデータパケットの信頼できる厳密に順番どおりの配信を提供する必要はなく、いくつかの実施形態では、プロトコル（例えば、ＵＤＰの上のＴＣＰまたはアプリケーション）を使用する本システムが、パケットがネットワークによって失われていると早まって決定しないために、必要なものを提供するように構成されている。

いくつかの実施形態では、シーケンサ１６２は、パケットロスと共に各データ接続のレイテンシの変動（ジッター）を（動作エンジン１５２によって維持されるデータに基づいて）監視して、どのデータ接続がフローによって予想以上にパケットを遅延させる可能性があるかを接続信頼性に基づいて予測するように構成されている（エンドポイント１０２および１１０がそれらが失われているとみなし、かつそれらのエラー訂正ルーチンを呼び出すことを意味する）。

乱れた順番の状況の場合、シーケンサ１６２は例えば、より大きなレイテンシの変動を示す接続上でより大きなジッターバッファを利用してもよい。パケットの再送の場合、シーケンサ１６２は、「最良の」（最も信頼できる最も低いレイテンシ）接続を通して失われたパケットを即座に要求するように構成されていてもよい。

シナリオの一例では、帯域幅遅延積の推定は全体的に正確でなくてもよく、レイテンシスパイクが接続において経験される。その結果、パケットは中間のゲートウェイにおいて乱れた順番で受信される。

これらの実施形態では、シーケンサ１６２は、プロトコル（および／または関連するアプリケーション）が誤った順番のパケットに関してどのように行動することができるかに関して予測的決定を行い、かつ下流のシステムが、ネットワークが容量に達した（従ってその伝送速度を抑える）と誤ってみなし、かつ／または失われていないパケットの再送を不要に要求する可能性が低くなるように、パケットを再順序付けする命令を生成するように構成されていてもよい。

例えば、多くのＴＣＰ実装は、３回の連続した二重の肯定応答（ＤＵＰ ＡＣＫ）を、ＤＵＰ ＡＣＫの後のパケットが失われる可能性があるというヒントとして使用する。この例では、受信機がパケット１、２、４、５、６を受信する場合、それはＡＣＫ（２）を３回送信する（パケット４／５／６のそれぞれに対して１回）。次いで送信機は、このイベントはパケット３がネットワークにおいて失われる可能性があることをほのめかし得るものであると認識し、かつあらゆる正常な再送タイムアウト（ＲＴＯ）タイマーが期限切れになる前にそれを先制して再送するように構成されている。

いくつかの実施形態では、シーケンサ１６２は、そのような予測的決定を補償するように構成されていてもよい。上記例のように、シーケンサ１６２がバッファされたパケット１、２、４、５、６、３を有する場合、シーケンサ１６２はパケットを再順序付けして、パケットがそれらの適切な順番で伝送されることを保証してもよい。但し、パケットが１、２、４、３、５、６の順番で既にバッファされていた場合、シーケンサ１６２は、この例では予測的決定がトリガーされないため（パケット３の位置決めを考慮して）、伝送前にそれらを再順序付けするのを邪魔しないように構成されていてもよい。

接続制御装置１５４は異なる接続パス１０６間で実際のルーティングを行うように構成されており、これは例えば、結合されたリンクへの接続１０６が物理的なゲートウェイ１０４、１０８上に存在している必要がないことを示すために提供されている（例えば物理的なゲートウェイは、他の場所にあってもよい（およびアンテナなどに関して異なる場所にあってもよい）物理的な送信／受信装置または衛星機器へのいくつかのリンク（イーサネット（登録商標）またはそれ以外）を有していてもよい）。従って、エンドポイントは論理的に接続されており、かつ様々な方法で物理的に分離されていてもよい。

一実施形態では、システム１００はＴＣＰ加速法として知られている方法を提供するように構成されており、ここでは本ゲートウェイは、パケットを受信するとプレバッファを作成し、かつ受信エンドポイントが既に受信されたパケットを有するかのように肯定応答信号（例えばＡＣＫフラグ）を送信エンドポイントに提供し、実際のパケットがエンドポイントに配信される前に、送信エンドポイント１０２により多くのパケットをシステム１００の中に送信させることができる。いくつかの実施形態では、プレバッファリングはＴＣＰ加速法のために使用される（得られるデータのバッファリングと組み合わせた日和見的肯定応答（ＡＣＫｉｎｇ））。

このプレバッファは、送信エンドポイント１０２への第１のリンクの前またはエンドポイント１１０への伝送路の中のどこか他の場所に存在することができる。このプレバッファのサイズはマルチパスネットワークからのフィードバックに応じて異なってもよく、これは、いくつかの実施形態では、帯域幅遅延積の推定または測定あるいは所定の論理演算のセットに基づいている（ここでは、特定のアプリケーションまたはユーザは、速度、レイテンシ、スループットなどの特定の特性を有するプレバッファを受信する）。

プレバッファは、例えば実装内の様々な位置に存在してもよく、例えばプレバッファは、ゲートウェイ１０４への入口点または１１０への伝送路（最終的な宛先の前）までのいずれかに存在してもよい。一実施形態では、一連のプレバッファが存在し、例えばデータはエンドポイント１からエンドポイント２まで流れるので、ゲートウェイＡおよびゲートウェイＢの両方の上にプレバッファが存在する。

プレバッファの中に受け入れられ、かつエンドポイント１０２に日和見的に肯定応答されたデータをエンドポイント１１０に確実に送信することはシステム１００の責任となる。肯定応答は、エンドポイント１１０がデータを受信し、故にその正常なＴＣＰ機構を介する再送をもはや取り扱う必要がないことを元のエンドポイント１０２に伝える。

プレバッファリングおよび日和見的肯定応答は、接続１０６のロスおよび他の非理想的行動を取り扱うのに利用可能なシステム１００が有する時間制限を取り除くので、有利である。ＴＣＰ加速法を使用しない時間制限は、システム１００の制御下にない値であるエンドポイント１０２によって計算されるＴＣＰ ＲＴＯに基づいている。この時間制限が超過された場合、エンドポイント１０２は、ａ）システム１００が既にバッファリングしているかもしれないデータを再送し、かつｂ）そのｃｗｎｄを減少させ、従ってスループットが低下する。

メモリ使用量に制限を加えるためにプレバッファのサイズを制限しなければならない場合があり、これはマルチパスゲートウェイ１０４および１０８間のフロー制御情報の通信を必要とする。例えば、ゲートウェイ１０８とエンドポイント１１０との通信リンクが全ての接続１０６の総スループットよりも低いスループットを有する場合、１０８でバッファされるデータの量は絶えず増加する。バッファされる量が限界を超えた場合、フロー制御メッセージが１０４に送信されて、エンドポイント１０２から送信されるデータを日和見的に肯定応答することを一時的に停止するようにそれに命令する。バッファされる量が最終的に限界未満まで低下した場合、フロー制御メッセージが１０４に送信されて日和見的に肯定応答することを再開するようにそれに指示を与える。限界は静的閾値であってもよく、あるいは、例えば全ての接続１０６の総ＢＤＰおよび本システムによって現在取り扱われているデータフローの総数などの因子を考慮しながら動的に計算される。フロー制御の開始／停止メッセージが送信される閾値は同じである必要はない（例えば、ヒステリシスが存在してもよい）。

同様に、マルチパスゲートウェイそれ自体の中にフロー制御信号情報が存在してもよい。例えば、接続１０６の総スループットがエンドポイント１０２とゲートウェイ１０４との間のスループットよりも小さい場合、１０４内のプレバッファは絶えず増加する。限界（先に記載したように計算してもよい）を超えた後、エンドポイント１０２から入って来るデータの日和見的肯定応答を一時的に停止し、次いでデータの量が適当な閾値未満に低下した場合に再開することを必要としてもよい。

先の例は、エンドポイント１０２から１１０に送信されるデータのためのＴＣＰ加速法について説明するものである。同じ説明が反対方向に送信されるデータに当てはまる。

別の実施形態では、バッファマネージャは、接続ネットワークの行動における可変性と、ネットワークに対する他の活動およびソース伝送の潜在的に「バースト性」である性質とを補償するために通信リンクごとの進行中の伝送に対して過剰バッファリングを提供するように構成されている。

過剰バッファリングとは、例えば出力側での接続のＢＤＰよりも多くのパケットを入力側で意図的に受け入れることが取り扱い可能であるということを指してもよい。「過剰バッファリング」と「バッファリング」との違いは、バッファマネージャがフロー要求に基づき、かつ接続ＢＤＰがリアルタイムでどのように変わるかに基づいて異なる量をバッファすることができるという点である。

この過剰バッファリングにより、ゲートウェイ１０４にそうでない場合に対応する準備ができている量よりも多くの（例えば、それが「容易にこなせる」量よりも多くの）データを送信エンドポイント１０２から受け入れさせてバッファさせる。過剰バッファリングは、全体的に行うことができるか（例えば、本システムは、総スループットにおいて利用可能な本システムが推定するよりも多くを利用するように構成されている）、あるいは接続ごとに接続制御装置の中に移動させて管理することができるか、両方の組み合わせ（例えば、伝送ごとの複数のオーバーバッファ）で提供することができる。

例えば、システム１００が所与のリンクのセットを通して２０Ｍｂｐｓを送信できるということのみを推定する場合であっても、システム１００は当面は送信エンドポイント１０２からそれを超えて（例えば３０Ｍｂｐｓを）受け取り、恐らくネットワーク特性監視ユニット１６１よって提供されるネットワーク特性の統計学的かつ履歴的知識に基づきネットワーク条件が変わり得るという決定、または送信エンドポイント１０２（または他の入って来るか出て行く伝送）がそのデータ伝送速度を減速し得る時間が存在し得るという決定に基づいて、それが即座に送信できないデータをバッファリングする場合がある。

フロー分類エンジン１５６は、いくつかの実施形態では、特定の種類のトラフィックにフラグを設定するように構成されており、動作エンジン１５２は、いくつかの実施形態では、バッファマネージャにフロー毎ベースでプレバッファリングおよび／または過剰バッファリングのサイズを決めて管理することを指示するように構成されていてもよく、任意の数の基準（データの種類、ユーザ、行動に関する履歴データ、フローの要求）に基づいてバッファのサイズを選択する。

いくつかの実施形態では、これらのバッファのサイズは伝送ごとに決定され、かつゲートウェイごとにも決定される（一度で本ゲートウェイを介してルーティングされる多くの伝送が存在し得るからである）。一実施形態では、プレバッファリングおよび過剰バッファリング技術が並行して利用される。

いくつかの実施形態では、過剰バッファリングのサイズは、帯域幅遅延積（ＢＤＰ）に実質的に比例するように決定される。例えば本システムは、ネットワークが高いＢＤＰ（例えば、１０Ｍｂｐｓ＠４００ｍｓ＝＞５００ＫＢ）を有する場合、バッファは、ネットワーク／パイプラインをパケットで一杯にし続けるのに利用可能な十分なデータが常に存在するようにより大きくすべきように構成されていてもよい。逆に、低いＢＤＰネットワークの場合、本システムは、過剰なバッファブロートを生じさせないためにより少ないバッファリングが存在するように構成されていてもよい。

バッファブロートとは、例えば高レイテンシおよび低スループットを生じさせるネットワーク内での過剰なバッファリングを指してもよい。より安価かつより容易に利用可能なメモリの出現を考慮すると、多くの装置は今ではそのようなバッファの影響を考慮することなく過剰なバッファを利用している。バッファブロートについては、例えば、「バッファブロート：インターネットのどこが悪いのか？（Ｂｕｆｆｅｒｂｌｏａｔ：Ｗｈａｔ’ｓ Ｗｒｏｎｇ ｗｉｔｈ ｔｈｅ Ｉｎｔｅｒｎｅｔ？）」という名称の論文（２０１１年１２月７日）、および「バッファブロート：インターネットにおけるダークバッファ（Ｂｕｆｆｅｒｂｌｏａｔ：Ｄａｒｋ Ｂｕｆｆｅｒｓ ｉｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ）」という名称の論文（２０１１年１１月２９日）などの米国計算機学会によって公開されている論文により詳細に記載されており、これらの論文はどちらも参照により本明細書に組み込まれる。

ビットレートおよびレイテンシに関して過剰バッファリングサイズを決定する一例として、本システムが過剰バッファリングによりネットワークのベースレイテンシに対して５０％を超えて追加すべきではないという要求に関するルールが実装されていてもよい。この例では、このルールは、過剰バッファリングサイズが「ビットレート×ベースレイテンシ×１．５」であるということを示している。

一実施形態では、動作エンジン１５２がマルチパスゲートウェイ１０４、１０８に含まれていてもよい。別の実施形態では、動作エンジン１５２はクラウドに存在し、かつ１つ以上のゲートウェイ１０４、１０８に適用してもよい。一実施形態では、単一のマルチパスゲートウェイ１０４、１０８に接続する複数のエンドポイント１０２、１１０が存在してもよい。一実施形態では、エンドポイント１０２、１１０およびマルチパスゲートウェイ１０４、１０８は同じ装置に存在してもよい。

一実施形態では、接続制御装置１５４はマルチパスゲートウェイ１０４、１０８とは別個であってもよい（かつ１つ以上の接続装置（例えば、無線インタフェースまたは有線接続）に物理的に関連づけられていていてもよい）。別の実施形態では、接続制御装置は本ゲートウェイ上に存在していてもよいが、物理的な接続（例えばインタフェースまたは有線接続）は別個のユニット、１つの装置または複数の装置上に存在していてもよい。

エンドポイントは論理的に接続されている必要があるが、それらは接続１０６に依存しないように接続されていてもよい（例えば、マルチパスゲートウェイ１０４、１０８によって取り扱われる通信）。いくつかの実施形態では、所与のゲートウェイに利用可能な接続１０６のセットは動的であってもよい（例えば、特定の時間または特定のユーザにおいてのみ利用可能な特定のネットワーク）。

一実施形態では、エンドポイント１０２から入って来るトラフィックは、システム１００からの動的フィードバックに基づいてシステム１００によって制御可能であってもよい（例えば、本システムは、エンドポイントで始まるビデオ伝送のビットレートを変更するように構成されていてもよい）。別の実施形態では、エンドポイント１０２から入って来るトラフィックはシステム１００によって制御可能でなくてもよい（例えば、エンドポイントから生じるウェブ要求）。

別の実施形態では、伝送路の中に２セット以上のマルチパスゲートウェイ１０４、１０８が存在してもよい（例えば図１３）。例えば、いくつかの実装では、クラウド内のゲートウェイに接続する遠隔マルチパスゲートウェイによるＴＣＰ伝送が存在してもよく、次いでこの伝送はクラウドのエッジにある別のマルチパスゲートウェイに非マルチパス接続を提供し、次いで別のマルチパス遠隔ゲートウェイに伝送が行われる。

遠隔現場オペレータが大きな容量のデータを別の遠隔位置に伝送しなければならない場合がある陸軍使用の事例などの各種使用事例が可能であってもよい。オペレータのシステム１００は、データをより広域のインターネットに提供するために複数のパスが利用される送信機構と共にセットアップされていてもよい。次いで、システム１００はインターネットのエッジ上の他のどこかに伝送するために高容量のバックホールを使用し、次いでそこではそれが第２の遠隔エンドポイントに着くために別のマルチパス伝送を必要とする。

一実施形態では、ゲートウェイＡ１０４およびＢ１０８は、利用可能な接続パスのうちの１つを介して互いの間で制御情報を送信するように構成されていてもよい。

図２は、インターネットユーザが様々なネットワーク特性を有するトランスポートリンクを利用するゲートウェイの組み合わせを介してウェブに接続するシナリオを説明する。

図２は図１に関連しているが、クライアント２０２とサーバ２０４との異なる対話の例が示されている。本システムは究極的には両方向システムであってもよいが、伝送が単方向であるか最初は単方向であってもよい状況（例えば、データを提供するウェブページからデータを要求する）が存在してもよい。

クライアント２０２であってもよい装置は、例えばモノのインターネット（ＩｏＴ）装置などの通信することができる各種装置であってもよい。他のエンドポイントはＩｏＴハブなどのサーバであってもよい。図示されている接続２０６は、例えばＬＴＥネットワーク、３Ｇネットワーク、衛星接続などを含んでもよい。他の接続の種類としては、特に有線ネットワーク、ＷｉＦｉネットワーク（例えば、８０２．１１規格）、ブルートゥース（登録商標）、マイクロ波接続、光接続、他の無線接続が挙げられる。これらのネットワークおよび／または接続のそれぞれの信頼性および接続性は、マルチパスフェージング、干渉、ノイズなどの様々な因子によって影響を受ける場合がある。

帯域幅、レイテンシ、ジッター、パケットロスなどは影響を受ける場合があり、いくつかの実施形態では、エンドポイント２０２、２１０および／またはマルチパスゲートウェイ２０４、２０８は移動中である場合があり、利用可能な接続２０６の数および種類さえ動的に利用可能になったり利用不可能になったりする場合がある。例えば、電気通信装備ＶＡＮは、携帯電話通信可能範囲や衛星受信可能範囲などに出たり入ったりする場合がある。

図３は、図２のネットワークに基づく例に係る６つのパケットの順序付けを実証することによってシーケンサ１６０によって行われる方法のより詳細な例を示すために提供されている。図３の例では、パケットは単純なラウンドロビン式で送信される。その例は非限定的であり、他のパケット送信法が可能である。

特にレイテンシ特性に焦点を当てて、マルチパス送信機のスケジューラとマルチパス受信機のシーケンサとの間の以下の３種類の接続：
１．ＬＴＥ：３０Ｍｂｐｓ、５０ｍｓのレイテンシ、
２．３Ｇ：２Ｍｂｐｓ、１２０ｍｓのレイテンシ、および
３．衛星：１０Ｍｂｐｓ、５００ｍｓのレイテンシ
を検討する。

この例では、マルチパス送信機３０４を介して接続されたクライアント機械（Ｃ）３０２が、マルチパス受信機３０８を介して到達可能なサーバ（Ｓ）３１０にＴＣＰトラフィックを送信しようと試みており、かつシステム３００が先に記載したＴＣＰ加速法技術を用いていないと仮定する。

これらの接続のうち６つのＩＰパケットをラウンドロビンし、かつ「スマート」以外は何もしない単純なアルゴリズムを検討する。レイテンシの極端な差により、ＴＣＰストリームを受信するサーバ（Ｓ）は、以下の順番：
パケット１＠ｔ＝５０ｍｓ（ＬＴＥを介して送信される）
パケット４＠ｔ＝５０＋ｍｓ（ＬＴＥを介して送信される）
パケット２＠ｔ＝１２０ｍｓ（３Ｇを介して送信される）
パケット５＠ｔ＝１２０＋ｍｓ（３Ｇを介して送信される）
パケット３＠ｔ＝５００ｍｓ（衛星を介して送信される）
パケット６＠ｔ＝５００＋ｍｓ（衛星を介して送信される）
で到達するパケットを観察する。

ＴＣＰは、パケットの主要な再順序付けおよびそれらの間の大きなレイテンシを取り扱うのに十分には設計されていない。当該サーバは、パケット１のために複数の二重のＡＣＫを送信し（当該サーバが失われたパケットをまだ待っているということをクライアントが知っていることを確認するために）、あらゆる／全てのパケット２／３／５／６を再送させるが、パケットは失われておらず、ただまだ伝送中であるのでこれは不必要である。特にこの理由のために、極めて様々な（または異なる）レイテンシの接続を結合しようと試みる場合に、多くの既存の解決法は非常に乏しいスループットを提供する。

ゲートウェイ１０４、１０８のシーケンサ１６２の順序付け機能は、当該サーバが、最終的にそれらが送信された順番でパケットを受信するように、パケットをバッファリングしてそれらを順番通りに送信することによる技術的解決法を提供する。得られる順番は、
パケット１＠ｔ＝５０ｍｓ（ＬＴＥを介して送信される）
パケット２＠ｔ＝１２０ｍｓ（３Ｇを介して送信される）
パケット３＠ｔ＝５００ｍｓ（衛星を介して送信される）
パケット４＠ｔ＝５００＋ｍｓ（ＬＴＥを介して送信され、かつシーケンサによってバッファされる）
パケット５＠ｔ＝５００＋ｍｓ（３Ｇを介して送信され、かつシーケンサによってバッファされる）
パケット６＠ｔ＝５００＋ｍｓ（衛星を介して送信される）
である。

バッファがどの程度の大きさであるかを決定する際に、スケジューラ１６０は当該決定が少なくとも部分的に帯域幅遅延積に基づくように構成されていてもよい。いくつかの実施形態では、バッファの長さは、例えばフロー要求、ジッター、接続セットの性能のための履歴データ（例えば、配信はそれらの接続に対してどの程度可変であったか、本システムがすぐに到着したパケットを再要求したこと（例えば、バッファは非常に小さい場合がある）、または最小のソーティングがシーケンサによって要求された回数（例えば、バッファは不必要に大きい場合がある）をどの程度頻繁に認識したか）に基づいてサイズ決めされていてもよい。

例えば、同様のレイテンシを有する多くの同様のネットワークが使用される場合、誤順序付けが生じる機会がより少なくなるため、スケジューラ１６０はより小さい受信／シーケンサバッファを提供してもよい。

他方で、本システムは、送信エンドポイントまたは当該接続のいずれかが「バースト性」である場合に、ネットワーク／パイプラインが常にフルであり続けることができることを保証するために、スケジューラ上のより大きなバッファを選択するように構成されていてもよい。バッファのサイズ決めは、どちら側であるかまたはフロー要求によって決まってもよい。エンドポイント２に対してより低いレイテンシが必要であり、かつ当該接続がそれ以外は良好／予測可能である場合、あるいはフローがパケット順序付けに対して厳しい要求を有しない場合に、バッファのサイズ決めはシーケンサ上ではより小さいバッファとなる傾向がある。

スケジューラ１６０上のバッファは、接続１０６がエンドポイント１によって一杯にされることを保証するように構成されていてもよく、かつシーケンサ１６２上のバッファはパケットの再要求の必要性を最小限に抑えるが、大き過ぎることによってパケットのエンドポイント２への配信に対して不必要な遅延を引き起こさないように構成されていてもよい。

いくつかの実施形態では、スケジューラ１６０およびシーケンサ１６２は、パケットの完全に保証された順番の信頼できる配信を提供するように構成されておらず、それどころかスケジューラ１６０およびシーケンサ１６２は、プロトコル（例えばＴＣＰ）またはアプリケーションがまだバッファ／転送されているパケットを失われたものとして誤って処理しないようにパケットを十分に再順序付けすることのみを必要とする。例えば、各種プロトコル／アプリケーションは複数のＲＴＴをインジケータとして使用して、パケットが失われているか否かを決定してもよい。従ってスケジューラ１６０および／またはシーケンサ１６２は、パケットのバッファ時間における極度の可変性を減らすために動作可能であってもよい。

一実施形態では、本システムはスループットを最大化するために本システムの両側にバッファを設け、ここでは第１のバッファはトリガーによりコンテンツをネットワークに放出する。一実施形態では、この２つのバッファは、特定の全体的バッファ長さを維持するために一緒に調整することができる（ゲートウェイＡのスケジューラ１６０およびゲートウェイＢのシーケンサにおいて）。従って、当該バッファは一斉に動作して、送信機または受信機のいずれかの上での過度に長いバッファ（バッファブロート）を回避しながらも全体的バッファ長さを提供してスループットを向上させてもよい。別の実施形態では、当該バッファは互いに独立して動作してもよい。

図４は、スケジューラ１６０が「スマート」であるように構成されており、かつその決定においてレイテンシを利用するように構成されている場合の説明である。図４では、３つのネットワークが同じ帯域幅を有するが、異なるレイテンシを有する単純化された例が例示を目的として提供されている。

この例では、帯域幅は計算の単純性のために「１パケット」として定められているが、他の帯域幅が可能である。この仮定により、パケット１は＠ｔ＝５０ｍｓで到着し、パケット２は＠ｔ＝１００ｍｓで到着するという単純化された分析が可能になる。接続の帯域幅が１パケットよりも大きい場合、パケット２は、第１のパケットの後ろにパイプライン化されているので、ｔ＝５１ｍｓで到着する（例えば１ｍｓの処理／パイプライン化遅延と仮定する）。別の例では、ＭｂｐｓまたはＫｂｐｓを単位として当該分析を定めることが望まれる場合、その導出は全てのパケットが１５００バイトであり、かつ接続が１２Ｋｂｐｓ（１５００×８）の帯域幅を有するという仮定を含んでもよい。他の仮定が可能であり、例えば、
接続１－１パケットの帯域幅、レイテンシ５０ｍｓ、
接続２－１パケットの帯域幅、レイテンシ１２０ｍｓ、および
接続３－１パケットの帯域幅、レイテンシ５００ｍｓ
である。

スマートスケジューラ１６０は、各種リンクの潜在的に時間で変化するレイテンシがリアルタイムで考慮されるようにパケットをルーティングするように構成されている。これにより、接続３を介して１パケットのみを送信することができるよりも速く全てのパケットに肯定応答することができるので（例えばＲＴＴに基づいて）、スケジューラ１６０がパケットを接続１および２にのみ送信するという事例が生じる。

マルチパス受信機４０８上のシーケンサ１６２は、以下の順番：
パケット１＠ｔ＝５０ｍｓ（接続１を介して送信される）
パケット２＠ｔ＝１００ｍｓ（接続１を介して送信される）
パケット３＠ｔ＝１２０ｍｓ（接続２を介して送信される）
パケット４＠ｔ＝１５０ｍｓ（接続１を介して送信される）
パケット５＠ｔ＝２００ｍｓ（接続１を介して送信される）
パケット６＠ｔ＝２４０ｍｓ（接続２を介して送信される）
でパケットを受信する。

ネットワーク上にドロップされたパケットや輻輳がないものと仮定すると、パケットは順番通りに到着し、かつシーケンサ１６２は再順序付けまたはバッファリングを必要とすることなく単にパケットを順番通りに通過させる。複数の接続が同様の特性を有する一実施形態では、本システムは、履歴的接続特性および信頼性に基づいてパケットを伝送させることを選択してもよい。

パケットが乱れた順番で受信されたり失われていたりする場合、シーケンサ１６２は、決定された最も信頼できる接続を通してパケットが再送されることを要求するように構成されていてもよい。マルチパス受信機４０８は例えば、フローの総レイテンシをそれが低い可変性を有するように維持することを試みるように構成されていてもよい。マルチパス受信機４０８がパケットを期待し、かつそれがまだ到着していない場合（パケットが失われていたり、当該接続がそれを予想外に再順序付けしたりしているため）、再要求を行うか、ただ継続するかどうかは（ロスを取り扱うためのプロトコル（ＴＣＰ）またはアプリケーションに依存する）は、例えばフローおよびその要求に対して決定される影響によって決まってもよい。

図５は、帯域幅遅延積（ＢＤＰ）の使用およびＴＣＰパケットのマルチデータ接続ルーティングに関するスティッキー性を示すために提供されている。パケットを送信機５０４、接続５０６および受信機５０８を介して出力装置５１０に送信する入力装置５０２が示されていると共に、システム５００が先に記載されているＴＣＰ加速技術を用いていないことが示されている。

図５の事例を検討すると、５０６に示されている３種類の接続のそれぞれは異なる帯域幅遅延積（ＢＤＰ）を有する。図示されているＢＤＰおよびレイテンシは単に例として提供されており、他の値が可能である。ＢＤＰは、例えば帯域幅に遅延（レイテンシ）を掛けて決定してもよい。

３Ｇリンク（例えば、接続１）は最も小さいＢＤＰ（２Ｍｂｐｓ×１２０ｍｓ＝約３０ＫＢ）を有し、それがフルになったら（すなわち、約３０ＫＢの未肯定応答のパケットが送信されてパイプラインにおいてインフライト状態にある）、別のデータパケットをそのリンクを介して送信してはならず、さもなくばデータパケットはドロップおよび／またはバッファされ、これによりＴＣＰフローにチャネル容量に達したと誤って認識させたり、当該接続のレイテンシを増加させたりする。

従って正しい手法は、代わりにそのデータパケットを異なるリンク（例えば、接続２または３）を通して送信することである。全てのリンクがそれらのフルＢＤＰに達した場合にのみ、システム１００はパケットをドロップする（あるいは、任意にそれを３つの接続のうちのいずれかに送信する）ように構成されるべきであり、それによりＴＣＰフローは総チャネル容量に達したことを最終的に決定し、ＴＣＰフローに（例えば、送信ソース５０２）にその応答における総伝送速度を低下させる。

生じる技術的課題は、システム１００が典型的には各接続の容量に関する情報を有しない点である。いくつかの実施形態では、帯域幅推定手法を適用して、改良されたルーティング決定を適用する（例えば、単純な帯域幅推定に対して期待されるスループットを確率的に向上させる）ことができるように、不完全な情報を考慮して帯域幅値を推定する。

推定がなければシステム１００は、システム１００がパケットロスおよび／またはレイテンシの増加を観察した場合にしか接続１０６がチャネル容量に達したときを決定することができないので、帯域幅の推定値は（正確性がほんの若干であるとしても）有用である。推定があればシステム１００は、伝送速度が推定値に近づき始めた際にＦＥＣの割合を追加するなどの技術を使用するように有利に構成することができる。

受信機１０８がＦＥＣを用いて開始することが必要になると、送信機１０４はこれがチャネル容量に達したことを示していると決定してもよい。どんな回復不可能なロスも生じさせることなくチャネル容量が決定されるので、これはＦＥＣを使用しないシステムよりも改良されている。

いくつかの実施形態では、より正確な帯域幅推定手法は、システム１００が重み付けされたラウンドロビンなどの改良された送信機構を呼び出すべきであると決定するのに有用であり得る。

但し、完璧な帯域幅推定アルゴリズムを用いる場合であっても、システム１００は重み付けされたラウンドロビン機構を利用するのに最適なものでなくてもよい。フローがフルチャネル容量を必要としない場合、受信側でバッファリング／再順序付けが必要とならないように、そのパケットの全ては単一の接続に対して「スティッキー」な状態に維持されるべきである。すなわち、フローをデータ接続に割り当てたら、そのフローはその接続を使用し続けるべきである。フローの必要性がそれが割り当てられたデータ接続の容量を超えた場合にのみ、そのフローは別のデータ接続に「オーバーフロー」すべきである。

オーバーフロー接続の選択は、レイテンシ、スループット、信頼性、ジッター、コストなどあるいはこれらの因子の任意の組み合わせの面で様々な利点を提供するために、任意の数のパラメータを決定論理の中に組み込むことができる。例えば、ＬＴＥ ＢＤＰは３０Ｍｂｐｓ×５０ｍｓ＝約１８７．５ＫＢであり、かつ衛星リンクは１０Ｍｂｐｓ×５００ｍｓ＝約６２５ＫＢである。衛星リンクが高コストであり、かつその目標が低レイテンシおよび低コストであれば、ＬＴＥ接続は、衛星接続が使用される前にデータで「一杯」になるであろう。あるいは、衛星接続がＬＴＥ接続よりも著しく信頼でき、かつその目標が信頼性である場合、衛星接続は、ＬＴＥ接続が利用される前にデータで「一杯」になるであろう。

また、同様の特性（レイテンシ、スループット、ジッターおよびパケットロス）を有する接続が互いにグループ化されるように、接続１０６は有利にはプールされてもよい。プーリングは接続制御装置内でより少ない決定を行うことを必要とすることを意味するので、これにより接続制御装置１５４によって行わなければならない接続管理が単純化される。接続特性は時間と共に変化するので、接続は必要に応じてプールをリアルタイムで結合および分離させて、信頼できるデータ通信を保証してもよい。全ての他の接続とは著しく異なる特性を有する任意の接続はプールされず、個々の接続として使用される。

プールされた接続は、矛盾する要求を有するフローの必要性を満たすのを可能にもする。例えば、全てが一貫して低レイテンシを有するが非常に様々なスループットを有する接続１０６のセットを検討する。このシナリオでは、最大で可能なスループットを達成するためにかなりの過剰バッファリングが必要とされ、これによりバッファブロートにおける著しい増加が生じ得る。一方が高スループットを必要とし、かつ他方が低レイテンシおよび低スループットを必要とする２つのフローが現在アクティブであれば、利用可能な接続１０６を、１つのプールがかなりの過剰バッファリングを利用し、かつ他方がそれを利用しない２つのプールに分割することにより、両方のフローはそれらの理想的な経験品質を達成することができる。

帯域幅推定手法の説明が図８Ａ、図８Ｂ、図８Ｃ、図８Ｄおよび図８Ｅに提供されており、ここには、ネットワーク能力に関して分かっている情報を利用して、送信されるパケットの数およびパケットサイズに基づいて利用可能な帯域幅を推定する推定例が記載されている。実際の実装では非理想性を補償するために修正が適用され、これにより割り込み調停に関して合体などが生じることがある。各パケットに関連づけられたエラーレベルを決定して、帯域幅推定を向上させるのに利用してもよく、このエラーはビットレートによって決まってもよい（例えば、ビットレートが増加するにつれて、このエラーは取るに足らないものになり得る）。

当該技術分野でよく知られている輻輳制御技術（Ｒｅｎｏ、Ｖｅｇａｓ、ＣＵＢＩＣおよび、ＢＢＲのようなより新しい手法）を用いて、接続のスループットおよびレイテンシ（ひいては接続の帯域幅遅延積すなわちＢＤＰ）も推定することができる。個々の（またはプールされた）接続の特性および／または入って来るデータフローの要求に応じて異なる輻輳制御手法を動的に使用すると有利であり得る。また単一の接続（または接続のプール）のために輻輳制御手法をパラメトリックに組み合わせることにより、接続（またはプールされた接続）および／または入って来るデータフローの必要性により良好に適合し得る手法が可能になるため、利点も得られる。

図６は、フロー要求の寸法（サイズおよびレイテンシに対する感度）を追加したものである。異なる入力装置６０２および６０３が存在してもよく、ここには図示されているように異なる種類のデータが提供されてもよい（６０２はＦＴＰ要求であり、６０３はＳＳＨセッションである）。これらのフローは、ゲートウェイ６０４による分類を必要としてもよく、かつ有利にはフロー分類に基づく受信ゲートウェイ６０８への接続６０６を介し、かつＦＴＰサーバ６１０および／または入力装置２に接続されたＳＳＨ接続６１２を介して提供されてもよい。

従って、フローの適切な識別および分類を用いて、データ接続（または接続のプール）へのデータパケットのさらに改良された割り当てを実装することができる。例えば、フローをＤＮＳトラフィックとして特定するためにゲートウェイ６０４が動作可能である場合、ゲートウェイ６０４は、データストリームが小さく、かつレイテンシセンシティブであることを決定することができるため、ゲートウェイ６０４はこのデータストリームを最も低いレイテンシを有する接続または接続のプールに「スティッキー」な状態に維持する。逆に、ゲートウェイ６０４がデータストリームが大容量のＦＴＰ転送であることを特定した場合、ゲートウェイ６０４は、最初により高いレイテンシを有する接続へのルーティングの優先、および必要な場合および過剰な容量が存在する場合は、より低いレイテンシ接続または接続のプールへのオーバーフローのみを示すように構成されるべきである。

図示されている実施形態は最初の行にトラフィック識別子を含むが、他の解決法は、ディープパケットインスペクション、データストリームの種類を特定するためのデータパケットまたはデータストリームのラベリングを使用し、かつフロー分類エンジンによる適切な取り扱いを保証することができる。そのような手法はルーティングを支援してもよい（例えば、ＳＳＨ：より低いレイテンシ接続を使用する、ＨＴＴＰ：より高いレイテンシ接続を使用する）。一実施形態では、いくつかのトラフィックの種類は常にスティッキーである（故にシーケンサ１６２は受信側で必要とされない）。

一実施形態では、フローの識別／分類を支援するために、送信機による（例えば、ＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）を介する）パケットのマーク付けを使用して、接続へのパケットの割り当ておよびデータフローをさらに向上させることができる。

別の実施形態では、観察された行動に基づく発見的手法を用いてフローの性質を推定する（例えば、開始プログラムに戻る一方向の性質および高帯域幅を考慮して、ゲートウェイ６０４は、デフォルトによってこれがＦＴＰフローであるとみなし、それに応じて接続割当てを調整するように構成することができる）。

別の実施形態では、当該分類はフローの行動に基づいて動的に変更することができる。例えば、ＳＳＨフローが最初に開始した場合、それは低帯域幅、レイテンシセンシティブなフローとして分類される場合がある。しかし、フローがデータを転送し続けるにつれて、それが特定の閾値の体積を通過すると、その分類はレイテンシセンシティブでない大容量のデータ転送（例えば、ＳＣＰ／ＳＦＴＰ動作）に変更される場合がある。

図６では、フロー分類エンジンは、入力装置１（６０２）からのトラフィックの性質がＦＴＰトラフィックであると決定（推定）するように構成されており、レイテンシセンシティブでない大きなフローのデータを予想して、システム１００は最初にトラフィックを高いＢＤＰ衛星接続を通してルーティングし、必要に応じてＬＴＥ接続にオーバーフローさせる。

またフロー分類エンジン１５６は、入力装置２（６０３）からのフローがＳＳＨセッションであると決定するように構成されていてもよく、次いでゲートウェイ６０４は、フローを取り扱うために低レイテンシ接続１（または低レイテンシ接続のプール）を選択するように構成されていてもよい。フロー分類エンジン１５６は、いくつかの実施形態では、ストリームの種類を特定するのを助けるために利用される入って来るデータストリームに関する統計学的情報を監視および／または受信する。

一実施形態では、システム１００は、複数のフローの種類のその認識をリアルタイムで組み合わせて、接続の混合または使用される接続のプールの混合を動的に調整する。

図７に示されている一実施形態では、システム１００は、送信マルチパスゲートウェイ７０４、受信マルチパスゲートウェイ７０８または両方のマルチパスゲートウェイにネットワーク特性監視ユニット７０１を取り入れている。各種因子をシステム１００によって監視および／または推定して、データトラフィックが各種接続に割り当てられる方法を制御する。

これらの因子は、例えばパケットの伝送を向上させる方法を決定するために使用される接続信頼性の決定により確立されてもよい（例えば場合によっては、全体的信頼性はピーク速度よりも重要である）。

接続信頼性は、例えば特に帯域幅、レイテンシ、ジッター、パケットロス、可変性を含む１つ以上の因子の複合物として測定してもよい。

一例では、ネットワーク特性監視ユニット７０１は、スループット、パケットロス、ジッター、レイテンシ、パケット順序付けなどの生データを収集し、かつこの収集されたデータに関する統計量、典型的には限定されるものではないが、平均、分散、尖度、順序統計量、ランク統計量、事前に設定された／所定の閾値を超えるか下回る回数、および他の導出される統計量を計算する。

受信機７０４および送信機７０８の両方にネットワーク特性監視ユニットが存在する場合、これらのネットワーク特性監視ユニットは１つ以上の接続７０６を通して、それらの導出された統計量をリアルタイムまたは所定の間隔で共有するように構成されていてもよい（フィードバック７０２で示されている）。向上した信頼性のために、共有される導出された統計量を複数の接続（または接続のプール）を通して繰り返して信頼性を高めてもよい。

一実施形態では、受信側にあるネットワーク特性監視ユニット７０１は、どの位多くのビットが特定の接続７０６で送信される各パケットのための前方誤り訂正（ＦＥＣ）によって訂正されるかの測定を取り入れている。この情報は、接続のためのエラー率に関する洞察を提供するために処理されてもよく、かつ導出される統計量の一部として提供される。

図８Ａ、図８Ｂ、図８Ｃ、図８Ｄおよび図８Ｅは、いくつかの実施形態に係る帯域幅推定方法の例示である。帯域幅推定は、実際のボトルネック帯域幅のいずれかに近い速度で伝送させることなく、送信機と受信機との間のボトルネック帯域幅（帯域幅の制約）についての適度に正確な推定値を得るために提供される。

推定帯域幅は、所与のデータ接続のための全体的スコアまたは適合レベル（例えば、ネットワーク「適合度（ｇｏｏｄｎｅｓｓ）」）を決定するために他の因子と共に使用される。本システムは、各種データ接続へのパケットの伝送に重み付けするために、利用可能なデータ接続（例えばネットワーク）の全ての期待される帯域幅の決定のために構成されていてもよい。

図８Ａを参照すると、図表８００に示されているように、提供されている例は、送信機８０２からのそれぞれ１４００バイトの８つのパケットの伝送バーストを含む。ネットワークの理想的なモデルでは、ボトルネックリンクは、各パケット間の等しい遅延を効率的に挿入することができる正にその速度でこれらの８つのパケットを伝送する。この例では、ネットワークは２５Ｍｂｐｓで伝送することができるので、それは４４８マイクロ秒の遅延を各パケット間に挿入する。

受信機８０４では、パケットが受信され、かつタイムスタンプが正確に４４８マイクロ秒間隔で記録される。帯域幅推定は、全てのパケットを転送するのに必要な時間で割ったパケットサイズの合計（第１のパケットを除外する）に基づいている。第１のパケットのサイズはネットワークで費やされる時間が分からないため除外される。但し、それが受信された時間は、第２のパケットがボトルネックリンクからのその送信を開始する時間を示す。

図８Ｂに示すように実際には、送信機、受信機および中間ルーティングシステムは、他のトラフィックとの競争、処理時間の可変性、割り込み調停などのネットワークインタフェースカード（ＮＩＣ）の最適化などにより、帯域幅の推定値にエラーを導入する可能性がある。例えば、各種統計学的方法（例えば、平均値、中央値など）の使用によりエラーの補償を行ってもよい。エラーの補償により本システムの効率およびスループットを高めてもよく、いくつかの実施形態では、ルーティングの特性の適応修正が行われてもよい。

エラー補償のための別の技術は、一番最近の帯域幅の推定値に応じて各バースト内のパケットの数を適応的に変化させることである。一般に、バーストのヘッドおよびテールにおいてパケット間到着時間に導入されるエラーのみが帯域幅の推定値計算に影響を与えるので、バーストが長くなるほど推定値がより正確になる。バーストが長くなるほど、総バースト持続期間と比較してヘッドおよびテールのエラーがさらに取るに足らないものになる。但し、ネットワークが低帯域幅を有する場合、長いバーストは実用的なものになり得ない。

図８Ａ、図８Ｂ、図８Ｃ、図８Ｄおよび図８Ｅの例を分かりやすくするために、バーストは８つの等しいサイズのパケットを含むが、バーストごとのパケットの数およびバースト内の各パケットのサイズは固定されている必要はない。帯域幅の推定値の計算は、パケットの全体サイズおよびバーストの全持続期間を知ることのみを必要とする。但し、過度に小さいパケットおよび／または短いバーストは、バーストのヘッドおよびテールに導入されるエラーを拡大させる可能性がある。

いくつかの実施形態では、バースト内のパケットは真のデータも含むことができる（伝送されるデータの上に帯域幅推定アルゴリズムのために必要なメタデータを本質的にピギーバッキングする）。このメタデータのために第１のパケット（これは廃棄される）を使用してもよい。信頼性の向上のために、バースト内のその後のパケットは、このメタデータを繰り返してもよい。

ピギーバッキングが可能でない場合、または伝送するのに不十分な真のデータが存在する場合、このバーストは「ダミー」データと共に伝送されてもよいが、バーストが実際のデータ伝送を可能な限り僅かにだけ干渉するように、バースト長さをさらにより短くしてもよい。

ＮＩＣ割り込みの取り扱いに関する技術などの、いくつかの種類のエラーを部分的に補償するための技術を使用してもよい。

図８Ｃは、いくつかの実施形態に係る、ＮＩＣ割り込みが著しい遅延に関して対処されるものとしてモデル化されている受信機についてのタイミング例を示す。図８Ｃに示されている方法は、ＮＩＣ割り込みの結果として生じるレイテンシおよびパケットバーストを補正するために利用される。

この例には、割り込みレイテンシを補正するための決定が示されており、これは単純なボトルネック帯域幅の推定とは対照的である。これらの割り込み遅延は、例えば受信されたパケットにボトルネックを生じさせる送信機と受信機とのネットワークリンクにより生じ得、その結果、均等に離間されている図８Ａの例とは対照的にバーストとしてパケットが受信される。

パケットが受信された場合に割り込みが発生するが、著しい遅延の後（この例では５００マイクロ秒）まで実行されない。この遅延の間にハンドラがやっと実行されると、それが全てのパケット（割り込みをトリガーした第１のパケット＋遅延の間に到着した任意のパケット）を収集してそれらを同時にアプリケーションに配信するように、より多くのパケットが到着することができる。

グループ内の全てのパケットが同じ受信時間でスタンプされている状態でバースト内のいくつかのパケットがグループに合体されているので、エラーがこのモデルに導入されている。合体されているパケットがバーストのヘッドおよびテールから「トリミングされている」場合に（それらが帯域幅の推定値の計算から除外されるということを意味する）、得られるパケットの分散パターンは非遅延割り込みの場合と同一であるという観察により、このエラーを補正することができる。唯一の違いは、バーストの事実上の持続期間がトリミングによりさらに短くなっているという点と、パケット受信時間のそれぞれが割り込み遅延によって同等に時間でシフトされているという点である。

バーストのヘッドからのトリミングは、単一のパケットのみを含む第１のグループを見つけることを必要とする。テールからのトリミングは、バーストの最後のグループ内の最初のパケット以外の全てを無視することのみを必要とする。

従って、いくつかの実施形態では、ネットワーク特性監視ユニット７０１は、パケット受信特性を追跡する（例えば、ボトルネック帯域幅の推定値を決定することによる）。図８Ｃに示すように、いくつかの実施形態のネットワーク特性監視ユニット７０１は、例えば合体されたパケットをトリミングし、かつ時間シフトを組み込むことによって割り込みレイテンシをさらに補正するように構成されている。

図８Ｄは、２つ以上のパケットを含む全てのグループにより、バーストのヘッドからのトリミングが可能でない場合に、割り込みレイテンシを補償するために使用することができる技術を示す。

この技術を例えばネットワーク特性監視ユニット７０１によって実施して、ボトルネックリンクにおいて生じる割り込みレイテンシを補正してもよい。従って、ネットワーク特性監視ユニット７０１は、バーストのヘッドからトリミングすることができるようにするための要求を含まない割り込みレイテンシに適応することができる。

ネットワーク特性監視ユニット７０１は、パケットの受信時間がボトルネックリンクからのその後のパケットの送信時間に等しい（すなわち、ｔ（Ｎ－１）_受信＝＝ｔＮ_送信）というボトルネックリンクの理想化モデルを適用するように構成されている。この例から分かるように、この置換（この場合、ｔ２_送信からｔ１_受信に）を行った後に、バーストのヘッドをトリミングしない場合であっても推定値を計算することができることは明らかである。

図８Ｅは、ＮＩＣが割り込み調停技術を用いてネットワーク特性監視ユニット７０１によってモデル化されている受信機を示し、これは、割り込みハンドラが固定されたタイマー上で（この例では１０００マイクロ秒ごとに）起動することを意味し得る。

ハンドラの最後の実行以降に受信されたあらゆるパケットが収集されてアプリケーションに配信される。

パケットの実際の受信時間はもはやアプリケーションには見えないので、これによりエラーが推定値に導入され、推定値は割り込みが発生する時間に基づく。

割り込み調停間隔が分かっていれば（例えば、それはシステム定数であるか、恐らくパケットのグループがアプリケーションに到着する頻度に基づいてリアルタイムで測定されているので）、帯域幅の推定値のために上限値および下限値を計算することができる。従って、いくつかの実施形態では、ネットワーク特性監視ユニット７０１は、追跡されるデータ値のコーパスから得られるような最新の推定される割り込み調停間隔を表すデータ構造を維持するように構成されており、このデータ構造は帯域幅の推定値の上限値および下限値を含む割り込み間隔を推定するために利用される。

上限値は、第２の最後の割り込みの直後にバースト内の最後のグループが実際に受信されたと仮定して計算する。下限値は最後の割り込みの直前に最後のグループが受信されたと仮定して計算する。

一実施形態では、下限値はＦＥＣが生成されて当該接続上で伝送され始める閾値である。

いくつかのシステム上で、割り込み調停にも関わらず、各パケットの実際の受信時間は、ＮＩＣまたはオペレーティングシステムカーネルによってアプリケーションに利用可能にすることができる。これらのシステム上で、割り込み合体によるエラーの明示的補償は必要とされない。

ネットワーク特性監視ユニット７０１は、いくつかの実施形態では、再構築のためにパケット受信特性を決定する際に下限値および上限値を利用するように構成されている。

図９は、ゲートウェイＡ９０２とゲートウェイＢ９０８との間の衛星オフロードの単純な例（単一の入力）を示すように構成された図表９００である。破線は構成要素間の論理接続を表し、物理接続は結合されたリンクを通るフローを表す。

トラフィックマネージャ９０４が制御することができる（ネットワーク上にいる人および優先帯域幅を得る人などを制御することができる、ネットワークパラメータなどを調整することができる）１つのネットワーク（例えば、衛星またはマイクロ波）、およびトラフィックマネージャ９０４が制御しない他のネットワーク（例えば、第三者セルラーネットワーク）が存在する例を検討する。被制御ネットワークが、トラフィックの一部を他のネットワークにオフロードすることを意味するとしても、それがトラフィックで「一杯」になる（コストを減らすか収入を最大化するために）のを確実にするためにそれを有利にさせる特定の特性（例えば、既に支払い済みであるので帯域幅が固定された「チャンク」として月単位で購入される）を有し得るということをさらに検討する。

例はビデオの送信であり、ここではセルラーネットワークによって保証することも場合によっては提供するさえもできない特定のレベルの伝送信頼性を配信することが望まれる。この場合、目標レベルの信頼性を保証することが必要とされるので、衛星ネットワークを通したビデオと同じ位多くを送信することが望ましい場合がある。また、衛星接続がフル容量でなければ（１つまたは複数のゲートウェイが同時に送信すると仮定する）、さらなるセルラーデータを使用する増分コストを減らすために可能な限り多くの衛星接続を使用することも有利であり得る。ＦＥＣ情報またはメタデータまたはビデオストリームの実際の部分などのビデオと組み合わせた他のデータも、組み合わせられた接続を通して送信することができることに留意されたい。別の実施形態では、良好なセルラー帯域幅を有するゲートウェイがより少ない衛星帯域幅を使用するように指示されるようなネットワークブレンダ／トラフィックマネージャ９０４の制御下で、データを衛星からセルラーにオフロードすることが有利であり得る。

ネットワークブレンダ／トラフィックマネージャ９０４は、ネットワークの最適な組み合わせを決定するように構成されている（いくつかの実施形態では、１つ以上のネットワークが制御され、そのような場合にはネットワークブレンダ／トラフィックマネージャ９０４は、全てのネットワークに対する監視を提供し、かつスループット、信頼性、パケットロスなどのリアルタイム測定に基づいてルーティングするので、なお有用性がある）。一実施形態では、１つ以上の利用可能なネットワーク接続は「制御」されており（上記のとおり）、かつネットワークブレンダ／トラフィックマネージャ９０４は、本ゲートウェイからリアルタイム情報を受信し、かつネットワーク全体がネットワークブレンダ／トラフィックマネージャ９０４によって管理されるように、本ゲートウェイ（「エッジノード」）によって使用される帯域幅を制御するように構成されている。

一実施形態では、被制御ネットワーク管理システム（ＣＮＭＳ）９０６は、特定の条件下で（例えば、ユーザまたはトラフィックの種類、コストに基づく優先順位、信頼性などに関して）特定のトラフィックの許可を決定するための論理演算のセット（例えば、静的論理演算、動的論理演算）を有していてもよい。論理演算のセットは、各種データ記憶装置に提供され、かつ本ゲートウェイ、ソース／エンドポイントまたはクラウドに格納されているものに基づいていてもよい。

いくつかの実施形態では、論理演算のセットがトラフィックマネージャ９０４にも格納されており、トラフィックマネージャ９０４は、被制御ネットワーク管理システム９０６からの論理演算を、伝送全体に適用する他の論理演算と組み合わせて利用してもよい（例えば、ユーザは制御されている衛星のために多くを支払わなくてもよく、かつ意図的に制御されている衛星から押し出される場合もあるが、伝送全体のために支払ってもよく、従ってより高コスト／信頼性の非被制御ネットワークの選択または割当てに関して優遇措置が存在し得るように、システム１００のデータ接続の残りについて優先順位を受信する）。

一実施形態では、ネットワークブレンダ／トラフィックマネージャ９０４はＣＮＭＳ９０６と対話して、ネットワークブレンダ／トラフィックマネージャ９０４に被制御ネットワークおよびネットワークブレンダ／トラフィックマネージャ９０４が管理することができる任意の他の伝送の両方をより良好に利用させることができるようにシステム１００を構成することができるような一般的なネットワーク条件に関して、本システム、マルチパスゲートウェイ９０２またはマルチパスゲートウェイに接続された装置に知らせてもよい。

例えば複数の接続が利用可能であってもよく、接続のそれぞれに影響を与えるネットワーク条件は時間と共に変わってもよい。例えば、輻輳としてロスおよびノイズが接続のそれぞれによって経験され、これらの接続は有利には、例えばそれらの接続特性に基づく使用または機能に割り当てられてもよい。その機能の接続および割当てのそのような「結合」は出願人の米国特許第９，３５７，４２７号に記載されており、この特許は参照により組み込まれる。

図１０は、複数の被制御および非被制御ネットワークに接続された複数のゲートウェイが存在する混合の例を提供する図表１０００である。

破線は構成要素間の論理接続を表し、かつ物理接続は結合されたリンクを通るフローを表す。

Ｎ個のマルチパスゲートウェイ（例えば、１００２、１００３）が存在してもよく、それぞれが、複数のエンドポイントから複数のゲートウェイを通るフローが被制御ネットワーク上のリソースのためのコンテンション（１００４および１００６の制御下）、これらのゲートウェイの所有者によって購入されるサービスレベル、これらのゲートウェイに取り付けられた非被制御ネットワーク上の接続性の品質および利用能、これらのゲートウェイを通るトラフィックを生成するフローおよびアプリケーションの要求などの因子を考慮して最良の経験品質で提供されるように、ネットワークブレンダ／トラフィックマネージャ１００４およびＣＮＭＳ１００６に関して一斉に作動する。伝送は最終的にマルチパスゲートウェイＡＡ～ＮＮ（例えば、１００８、１０１０）に提供されてもよい。これらのゲートウェイは、ネットワーク上の各ゲートウェイのためのサービスの公知かつ制御された品質を有する結合された機能性を与える。この文脈では、サービスの品質は、ネットワークブレンダ／トラフィックマネージャ１００４およびＣＮＭＳ１００６によって提供される帯域幅のスマート管理による特定のアプリケーションまたはアプリケーションのクラスのための帯域幅の割当てを意味する。

これらのゲートウェイは、異なるレベルの接続信頼性で販売（または保証）されていてもよい。ゲートウェイに高信頼性が保証され（またはそれが高信頼性を動的に要求し）、かつそれが高信頼性を受信していない場合、ネットワークブレンダ／トラフィックマネージャ１００４は、別のゲートウェイからより信頼できる（例えば衛星）帯域幅をプロビジョニング（例えば、「スチール」）して、この増加した信頼性をより高い信頼性を要求した（またはそれが保証された）ゲートウェイに与えるように構成されていてもよい。

ネットワークブレンダ／トラフィックマネージャ１００４は、複数のゲートウェイからの被制御ネットワークを介するトラフィックの割当てを管理し、ネットワーク特性のリアルタイム測定（本ゲートウェイによって提供される）および設定された静的もしくは動的論理演算（サービスルールの品質）に基づいて伝送のセットを最適化する。

一実施形態では、ネットワークブレンダ／トラフィックマネージャ１００４は、特定のユーザ／組織のトラフィックの管理に特化していてもよい。別の実施形態では、ネットワークブレンダ／トラフィックマネージャ１００４は、多種多様なユーザにサービスを提供するように構成されていてもよい。複数のネットワークブレンダ／トラフィックマネージャ１００４が存在し得る場合、そのリソースは必要に応じて互いに通信し、かつ必要に応じて提供されてもよく、ここでは、リソースは必要に応じてプロビジョニングされる／プロビジョニング解除される（「スピンアップまたはスピンダウン」される）。ネットワークブレンダ／トラフィックマネージャ１００４および被制御ネットワーク管理システム１００６は、いくつかの実施形態では、分散されたネットワークリソースの形態で提供されていてもよい（例えば、クラウド構成では「クラウド内で」実行されてもよい）。

被制御ネットワークを通した新しい伝送が生じた場合に被制御ネットワークをどのように利用するかについて取り組むために、動的論理演算が提供されてもよい（例えば、任意の特定の伝送に与えられる優先順位は進行中の他の伝送によって決まってもよい）。

図１１は、結合されていないディザスタリカバリー／ロードバランシング用途のために構成された１対１のシナリオを例解するために提供されている図表１１００である。この状況では、個々のフローはどんな結合も有さずに特定の接続にスティッキーなままであってもよく、ここでは、当該バッファは受信側で必要とされないため、第２のゲートウェイは存在しない。フローの接続への割り当てのためのアルゴリズムは、フロー要求、接続品質／信頼性、伝送コスト、本ゲートウェイ上での計算限界などの因子を考慮に入れる静的もしくは動的ルールに基づいていてもよい。

一実施形態では、ゲートウェイ１１０２は必要に応じて（例えば、スループットまたはトラフィックの種類に応じて）、通信の２つのエンドポイント間に個々のソケットを結合するのではなくセットアップする接続リンクを追加または除去するように構成されている。

いくつかの実施形態では、接続は結合されていてもよいがデータを全く伝送せず、そのような実装はフェイルオーバーシナリオにおいて技術的利点を提供することができ、このシナリオでは接続が作動中であることを知っている必要があってもよく、接続をアクティブにすることにより、本システムは接続を定期的にテストして動作を確認し、かつ／またはその必要性が生じた場合には新しい接続を通してデータストリーム（またはフロー）を移動させることができる。

一実施形態では、ディザスタリカバリーのシナリオに直面しているサイトからの特定の種類のトラフィックは、コストを減らし、セキュリティを高め、レイテンシ、ジッターまたはそのような因子の任意の組み合わせなどを最小限に抑えるために、特定のバックアップリンク（またはリンクのセット）を介してルーティングされるように構成されていてもよい。

例えば、受信機／第２のゲートウェイを介してルーティングすることを必要としないサービスツール（または適応ロードバランサー）としてのディザスタリカバリーのための本システムの使用が存在してもよく、ここでは上記解決法の実施形態を利用して、よりロバストな接続性を提供してもよい。

図１２は、結合されたディザスタリカバリー／ロードバランシング用途のサンプルを示すために提供されている図表１２００であり、ここでは、トラフィックはいくつかの実施形態に従って結合され、かつ第２のゲートウェイ１２０４を介してルーティングされる。

図１２に示すように、一実施形態では、大きな組織（またはセキュリティを必要とする組織）は、（比較的）閉鎖されたシステムにおいて２つの専用のゲートウェイ１２０２および１２０４を有し得る。別の実施形態では、顧客には単に「クラウド内の」公開ゲートウェイ１２０４が割り当てられていてもよい。図１２の実装は、段階的ゲートウェイの使用によりインターネットからの潜在的に悪意のある攻撃からネットワークを分離し、かつ入って来て出て行くデータストリーム（またはフロー）のためのサービスの品質を含むセキュリティポリシーおよびプロトコルを適用するための協調的部分を提供するので、高いセキュリティを提供するように機能する。

図１３は、２つ以上のエンドポイント１３０２および１３１０を接続する一連のマルチパスゲートウェイ１３０４、１３０６および１３０８を示す図表１３００である。図１３は、エンドポイント１（１３０２）の現場オペレータが伝送を行うために複数のパスを有するという利点を必要とするシナリオ（例えば、遠隔位置にいる兵士は状況認識情報を本部に提供するビデオおよび他のデータを送信する）を示す。これを達成するためにマルチパスゲートウェイの組み合わせ（例えば、ゲートウェイ１３０４、１３０６および１３０８）が必要とされてもよい。例えばトランジットの第１のホップは、現場からのデータを近くの前進作戦基地に送るために複数のＷｉＦｉネットワークを使用することを必要としてもよい。次いで前進作戦基地においてゲートウェイは、異なるセットの通信リンク（例えば多くのセルラーネットワーク）を介して全国本部にデータを送信してもよく、次いでここでは別のゲートウェイは、データを全国本部に送るために１つ以上のファイバーリンクを使用し、次いでこれは異なる組み合わせのリンクを使用してデータを異なる現場位置に送り戻してもよい。

一実施形態では、データはトランジットに沿った１つ以上の停止部においてアプリケーションに利用可能である。別の実施形態では、データは、途中でアプリケーションによってアクセスされることなく端から端まで伝送される。

いくつかの実施形態では、ネットワークの重複プールを用いて複数のスタート／エンドポイントを管理することのために構成されているシステムが提供されてもよく、ここでは、インテリジェントエンジンは各種装置および各種ネットワークの活動の知識を使用して伝送のフローをより良好に管理する。そのような実装では、本システムは、データレジデンシー論理演算（例えば、論理ルール）に従って順序付けを行うかネットワーク使用量を管理するように構成されていてもよい。

図１４は、境界ゲートウェイプロトコル（ＢＧＰ）に基づくエッジルーターを含む典型的なトランジットおよび／またはピアリング構成を用いて複数のリンクを通してインターネットに接続された２つのサイトを示す図表１４００である。この例では、サイトＡは、サブネットＡのためのＢＧＰ経路をその上流のピア／トランジットプロバイダに知らせ、サイトＢはサブネットＢのためのＢＧＰ経路を知らせる。

ＢＧＰは「粗い」ディスタンスベクタ型ルーティングプロトコルであり、これはパケットをルーティングすることを決定する方法における主要因子が、パケットが宛先サブネットに到着するために横切る自律システム（ＡＳ）の数に基づくことを意味する。それは各ＡＳ内の輻輳を考慮することもなければ、本来はマルチホーミングをサポートすることもない。

例えば、ネットワークパストランジットＡ１がサブネットＢからサブネットＡへのトラフィックのための最も短いパスとみなされた場合、サブネットＡへの全てのインバウンドトラフィックは、たとえ輻輳されているとしても、トランジットＡ１を介して到着する。全ての他のリンク（トランジットＡ２、ピアＡ１、ピアＡ２など）は利用されない。

この限界に対処するための手法は、サブネットＡをより小さいサブネットに仕切り、かつリンクのサブセットを通してそれらを選択的に宣伝することである。より小さいサブネットのそれぞれにおけるトラフィックパターンは全ての時間において所与のリンクの中で所望の分割を表さない可能性が高いので、これは最適以下である。より小さいサブネットはグローバルＢＧＰテーブルサイズの増加にも寄与するが、一般的に言って、／２４よりも小さいサブネットはグローバルＢＧＰテーブルにおいて受け入れられない。

２つのサイト間のＢＧＰルーティングとの比較がこの図では一例として使用されているが、これは要件ではない。この２つのサイトは単に、公に宣伝されているサブネットを有しない異なるプロバイダを介するマルチホームであってもよい。そのような状況では、２つのマルチパスゲートウェイ間の完全に接続されたグラフがなお確立され、その際この２つのサイト間のトラフィックは、任意の先に述べた基準（例えば、接続コスト、フロー要求、接続品質／信頼性など）に従って接続上でルーティングされる。

図１５は、２つのマルチパスゲートウェイシステム１００に接続された同じ２つのサイトを示す図表１５００を含む。接続制御装置１５４は、トランジットＡ１を（トランジットＢ１、トランジットＢ２、ピアＢ１）の全てに、トランジットＡ２を（トランジットＢ１、トランジットＢ２、ピアＢ１）の全てに．．．のように接続する完全に接続されたグラフを形成している。

サブネットＡおよびＢ上のホストおよびアプリケーションによって生成されるフローは、宣伝されているＢＧＰルートに基づいてもはやルーティングされないが、代わりにトランジットおよび／またはピアリングネットワーク上のＩＰアドレスを介して直接通信する２つのマルチパスシステム１０４および１０８間のプロトコル内にカプセル化されている。

これにより、マルチパスシステムは任意の数の上記基準（例えば、各フローのレイテンシおよびスループット要求、検出される輻輳／コンテンション、ジッター、コスト、管理者ポリシーなど）に基づいてパケットをルーティングすることができる。

いくつかの実施形態では、本明細書に記載されているシステムおよび／または方法の１つ以上の態様は、各伝送のための全てのレイテンシおよびパケットロス制約を満たしながらも、複数のリンクを通る伝送の総フローのスループットを最大化することを求めることができる。

場合によっては、リンク上の過剰なバッファリングによって生じるレイテンシであるバッファブロートを管理することによってこれらの問題のいくつかに対処してもよい。バッファブロートによりパケット遅延の変動（ジッター）やレイテンシの増加が生じる可能性がある。

接続が過負荷された場合、過負荷された接続上でレイテンシが増加し、これにより帯域幅遅延積（ＢＤＰ）が増加するが、スループットの対応する増加は生じない。

いくつかの実施形態では、バッファブロートの管理は、様々な接続型のＢＤＰを反映するバッファサイズの選択を必要とする場合がある。これは以下：

のように表すことができ、式中、「ｉ」は接続の数であり、「ｋ_ｉ」は本ゲートウェイ上でバッファリングを管理するために使用される定数であり（以下に概説されている）、

であり、式中、ＲｔＰｒｏｐ_ｉ（ｔ）は接続のベース伝搬遅延である。

スループット_ｉ（ｔ）およびＲｔＰｒｏｐ_ｉ（ｔ）が時間と共に変化しないか非常にゆっくりと変化する単純な接続では、レイテンシ制約を満たしながらも総スループットを最大にすることは、
・全てのＲｔＰｒｏｐ_ｉ（ｔ）が＜＝低レイテンシフローのレイテンシ要求である接続のサブセットが存在し、かつ
・サブセットの少なくとも１つを通る［ｋ_ｉ×ｂｄｐ_ｉ（ｔ）］の合計が＞＝低レイテンシフローによって生成されるデータの体積である、
という条件である限り解決することができる。

この基準を満たすサブセットが存在する場合、全ての残りの接続を通る［ｋ_ｉ×ｂｄｐ_ｉ（ｔ）］の合計（および低レイテンシフローによって完全に消費されない接続の部分的ＢＤＰを含む）は、レイテンシセンシティブでないフローのために使用することができる。

最大化問題は、スループット_ｉ（ｔ）およびＲｔＰｒｏｐ_ｉ（ｔ）が急激に、かつ本システムがｂｄｐ_ｉ（ｔ）の瞬時値に正確に従うことができないそのような大きな範囲の値にわたって変化する接続が存在する場合に明らかになる。これらの種類の接続のために、本システムはｂｄｐ＿ｍｉｎ_ｉ（ｔ）およびｂｄｐ＿ｍａｘ_ｉ（ｔ）（スループット_ｉおよびＲｔＰｒｏｐ_ｉのｍｉｎ／ｍａｘから測定される）を測定／観察するように構成することができる。

スループット_ｉ（ｔ）およびＲｔＰｒｏｐ_ｉ（ｔ）が変化する事例の場合、観察されたスループット_ｉ（ｔ）およびＲｔＰｒｏｐ_ｉ（ｔ）の分配に基づく統計学的手法を使用することができる。場合によっては、これは条件付き確率または反復的発見的手法に依存してもよい。機械学習または人工知能手法も用いてもよい。

本システムは、接続の最適な分割を決定する場合にレイテンシ制約を満たしながらも最大化問題に対処するように構成されている。これらの制約を満たす複数の接続サブセットが存在してもよい。
・低レイテンシサブセット
・ＲｔＰｒｏｐ＿ｍｉｎ_ｉ（ｔ）が＜＝低レイテンシフローのレイテンシ要求である全ての接続を見つけ、かつ
・ｂｄｐ＿ｍｉｎ_ｉ（ｔ）の合計が＞＝低レイテンシフローによって生成されるデータの体積であるこれらの接続を通る全てのサブセットを見つける
・高レイテンシサブセット
・残りの接続（サブセットの中にない接続）上にある上で計算した各実行可能なサブセットの場合、ｂｄｐ＿ｍａｘ_ｉ（ｔ）を合計する。その目標はこの合計を最大化するサブセットを見つけることである

ｋ_ｉの決定
単純な事例では、ｋ_ｉは定数であり、故に接続のためのバッファサイズを接続のためのＢＤＰのいくらかの割合として選択する。経験に基づいて、ｋ_ｉ＝１．２の値が実際に十分に機能することを見出した（例えば、本システムは所与のリンクのＢＤＰの２０％超をバッファするように構成されている）。

複雑な事例では、ｋ_ｉは、接続ｉを通して移動するフローの種類（およびそれらのフローの種類に関する任意の制約）、ｂｄｐ_ｉ（ｔ）の分散（ｋ_ｉをリアルタイムで調整するためにこれをリアルタイムで計算して使用してもよい）、および接続特性（レイテンシ、ジッター、スループット）の関数であり、ここでは、どの位のレイテンシがフローの種類のために必要であるか、およびどの位のスループットが必要とされるか（および、それらのフローの種類のためにどの組み合わせが最小で許容可能であるか）を決定し、これはｋ_ｉがフローの種類、ＢＤＰ分散および接続特性の関数であることを意味している。

ＷｉＦｉおよびＬＴＥ接続を用いる場合、レイテンシの変動はかなり急激であり得、かつ数規模の大きさに及ぶ範囲をカバーすることができる（例えば、ＷｉＦｉは＜１０ｍｓかつ＞１００ｍｓで移動することができる）。

選択されたバッファリングの量が＜１０ｍｓのレイテンシである（すなわち、小さいｋ_ｉ）と仮定した場合、実際のレイテンシが＞１００ｍｓであるときはいつでもネットワークをフルに維持するのに利用可能なデータが不十分であり、最適以下の平均スループットが得られる。

バッファリングの量が＞１００ｍｓのレイテンシである（すなわち、大きなｋ_ｉ）と仮定した場合、ネットワークを常にフルまたはフルに近い状態に維持することができる（最適な平均スループットが得られる）が、実際のレイテンシが＜１０ｍｓであるときはいつでもバッファリング（バッファブロート）によりさらなるレイテンシが存在する。

この例では、低レイテンシを必要とするフローが存在すれば、本システムは妥協して、低レイテンシのフロー伝送のために使用される接続上のバッファリングを＜１０ｍｓのレイテンシと想定されるレベル（すなわち、ｋ_ｉおよびｂｄｐ＿ｍｉｎ_ｉ（ｔ）のために保存的／小さい値）に維持しなければならない。場合によっては、これにより、全体的により低い平均スループットとなる場合があるが、フローの要求を邪魔するバッファブロートは導入されない。本システムは、高スループットを必要とし、かつレイテンシセンシティブでないであるフローのために残りの接続上で会話するように構成することができる。

上記考察は、本発明の主題の多くの例示的な実施形態を提供している。各実施形態は発明要素の単一の組み合わせを表しているが、本発明の主題はここに開示されている要素の全ての可能な組み合わせを含むものとみなされる。従って、一実施形態が要素Ａ、ＢおよびＣを含み、かつ第２の実施形態が要素ＢおよびＤを含む場合、たとえ明示的に開示されていないとしても、本発明の主題はＡ、Ｂ、ＣまたはＤの他の残りの組み合わせも含むものとみなされる。

本明細書に記載されている装置、システムおよび方法の実施形態は、ハードウェアおよびソフトウェアの両方の組み合わせで実装されていてもよい。これらの実施形態はプログラム可能なコンピュータに実装されていてもよく、各コンピュータは、少なくとも１つのプロセッサ、データ記憶システム（揮発性メモリまたは不揮発性メモリまたは他のデータ記憶要素あるいはそれらの組み合わせを含む）、および少なくとも１つの通信インタフェースを備える。

プログラムコードは、本明細書に記載されている機能を実施して出力情報を生成するための入力データに適用される。この出力情報は１つ以上の出力装置に適用される。いくつかの実施形態では、通信インタフェースはネットワーク通信インタフェースであってもよい。要素を組み合わせることができる実施形態では、通信インタフェースは、プロセス間通信のためのインタフェースなどのソフトウェア通信インタフェースであってもよい。さらに他の実施形態では、ハードウェア、ソフトウェアおよびそれらの組み合わせとして実装されている通信インタフェースの組み合わせが存在してもよい。

実施形態の技術的解決法はソフトウェア製品の形態であってもよい。ソフトウェア製品は、コンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、ＵＳＢフラッシュディスクまたは取外し可能なハードディスクであってもよい不揮発性もしくは非一時的記憶媒体に記憶されていてもよい。ソフトウェア製品は、コンピュータ装置（パーソナルコンピュータ、サーバまたはネットワーク装置）に当該実施形態よって提供される方法を実行させることができる多くの命令を含む。

ネットワーク接続を通してデータフローを制御するためのネットワークゲートウェイは、対応する方法、装置およびコンピュータ可読メディアと共に本明細書に記載されている。本ゲートウェイは、いくつかの実施形態では、プログラムコードまたはコンピュータ論理の形態のソフトウェアおよび組み込みファームウェアを代表とする命令セットに従ってデータパケットを受信してルーティングするように構成された、プロセッサ、インタフェース、バス、電源、メモリ（ＲＯＭ、ＲＡＭ、フラッシュ）などの構成要素を備える物理的なハードウェア装置であってもよい。

プログラムコードおよび／またはコンピュータ論理は制御論理および装置を含み、いくつかの実施形態では、制御装置、ルーター、スイッチ、アクセス点などとして動作してもよく、上記装置は、最終使用者に透過であるように動作するように構成されていてもよい（可能な性能改善は別にして、特に大きな量のデータが上記装置を通るため）。

本ネットワークゲートウェイは一例では、本明細書中のいくつかの例に記載されているようにＴＣＰ接続を結合するために特に最適化された専門の計算装置であってもよい。本ネットワークゲートウェイは他の例では、より大きなシステムの一部としてプロセッサおよび／または他のコンピューティングハードウェアを用いて実装されていてもよい。本ネットワークゲートウェイは単一の装置であってもよく、あるいは場合によっては一斉に動作する複数の装置であってもよい。

本明細書に記載されている実施形態は、計算装置、サーバ、受信機、送信機、プロセッサ、メモリ、表示装置およびネットワークを備える物理的コンピュータハードウェアによって実装されている。本明細書に記載されている実施形態は、有用な物理的機械および特に設定されたコンピュータハードウェア構成を提供する。本明細書に記載されている実施形態は、様々な情報を表す電磁信号を処理および変形させるのに適した電子機械および電子機械によって実行される方法に関する。

本明細書に記載されている実施形態は、広範囲かつ一体的に機械およびそれらの使用に関し、本明細書に記載されている実施形態は、コンピュータハードウェア、機械および各種ハードウェア構成要素によるそれらの使用以外の意味または実用的適用性を有さない。例えば特にメンタルステップを用いる非物理的ハードウェアのために各種動作を実行するように構成された物理的ハードウェアの置き換えは、当該実施形態が作動する方法に実質的に影響を与える場合がある。そのようなコンピュータハードウェアの限界は本明細書に記載されている実施形態の明らかに必須の要素であり、それらは本明細書に記載されている実施形態の動作および構造に対して重大な影響を与えることなく省略することもメンタル手段と置き換えることもできない。コンピュータハードウェアは本明細書に記載されている様々な実施形態を実施するために必須であり、かつ迅速かつ効率的に工程を行うために単に使用されるものではない。

当該実施形態は詳細に記載されているが、当然のことながら本範囲から逸脱することなく本明細書では様々な変形、置換および変更を行うことができる。

さらに本出願の範囲は、本明細書に記載されているプロセス、機械、製造、物質の組成、手段、方法および工程の特定の実施形態に限定されるものではない。当業者であれば本開示から容易に理解するように、本明細書に記載されている対応する実施形態として実質的に同じ機能を行うか実質的に同じ結果を達成する現在存在するか後に開発されるプロセス、機械、製造、物質の組成、手段、方法または工程を利用してもよい。従って、添付の特許請求の範囲は、それらの範囲内でそのようなプロセス、機械、製造、物質の組成、手段、方法または工程を含むことが意図されている。

理解することができるように、上に記載され、かつ図示されている例は単に例示であることが意図されている。

Claims (39)

1. 複数のネットワーク接続を通してデータフローをルーティングするためのネットワークゲートウェイであって、前記ネットワークゲートウェイは、
   前記複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースと、
   少なくとも１つのプロセッサであって、
   前記複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、
   パケットのデータフローの少なくとも１つのパケットを解析して前記データフローのためのデータフロークラスを特定することであって、前記データフロークラスは、前記データフローの少なくとも１つのネットワークインタフェース要件に関連づけられていることと、
   前記データフロークラスおよび前記時変ネットワーク伝送特性に基づいて前記データフロー内のパケットを前記複数のネットワーク接続を通してルーティングすることと、
   前記データフロー内のパケットの各パケットのために、前記データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、前記複数のネットワーク接続の監視されたレイテンシに基づく前記複数のネットワーク接続および前記データフロー内の他のパケットのネットワーク接続のうちの１つを通してルーティングするために前記パケットを提供することと、
   のために構成された、プロセッサと、
   を備える、ネットワークゲートウェイ。
2. 前記時変ネットワーク伝送特性を監視することは、前記監視される時変ネットワーク伝送特性に基づいて前記複数のネットワークの少なくとも１つのネットワークインタフェースの帯域幅遅延積を生成することを含み、かつ前記データフロー内のパケットをルーティングすることは、前記少なくとも１つのネットワークインタフェースの帯域幅遅延積に基づいている、請求項１に記載のネットワークゲートウェイ。
3. 前記少なくとも１つのプロセッサは、
   パケットの複数のデータフローのそれぞれの少なくとも１つのパケットを解析し、かつ
   前記複数のデータフローのそれぞれのデータフロークラス、および前記それぞれのデータフローのデータフロークラスに対応している前記ネットワーク接続の利用可能な帯域幅に基づいて、前記複数のデータフローのそれぞれの中のパケットをルーティングする
   ように構成されている、請求項１に記載のネットワークゲートウェイ。
4. 前記少なくとも１つのプロセッサは、
   前記複数のネットワークインタフェースの第１のネットワークインタフェースを通してパケットの順次バーストを送信することと、
   前記パケットの順次バースト内のパケットが受信ノードにおいて受信される際に記録されるタイムスタンプおよび前記パケットのサイズに基づいて、前記第１のネットワークインタフェースの帯域幅の推定値を生成することと、
   前記第１のネットワークインタフェースの生成された帯域幅の推定値に基づいて前記複数のネットワーク接続を通して前記データフロー内のパケットをルーティングすることと、
   のために構成されている、請求項１に記載のネットワークゲートウェイ。
5. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の第１のパケットと前記バースト内の第２のパケットとの間のパケットのパケットサイズの合計を前記第１のパケットのためのタイムスタンプと前記第２のパケットのためのタイムスタンプとの間で経過した時間で割ることを含み、ここでは前記第１のパケットは前記バースト内の最初のパケットではなく、かつ前記第２のパケットは前記バースト内の第１のパケットの後のものである、請求項４に記載のネットワークゲートウェイ。
6. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の最初もしくは最後のパケットと合体されていない前記バースト内のパケットのタイムスタンプに基づいて前記帯域幅を生成することを含む、請求項４に記載のネットワークゲートウェイ。
7. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の特定のパケットの受信タイムスタンプを前記特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含む、請求項４に記載のネットワークゲートウェイ。
8. 前記受信ノードが定期的な間隔で受信されたパケットを処理する場合、前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、
   前記帯域幅決定においてエンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、
   前記エンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを前記エンドパケットに先行する前記バースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することと、
   を含む、請求項４に記載のネットワークゲートウェイ。
9. 前記所望のシーケンスは前記データフロー内のパケットの元のシーケンスである、請求項１に記載のネットワークゲートウェイ。
10. 前記所望のシーケンスは、前記シーケンス内でのパケットの再送をトリガーしないパケットの少なくとも１つの誤順序付けを含むシーケンスである、請求項１に記載のネットワークゲートウェイ。
11. 前記少なくとも１つのプロセッサは、
    前記複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、
    前記パケットを前記宛先ノードにルーティングする前に肯定応答を前記ソースインタフェースに送信することと、
    前記パケットが前記宛先ノードにルーティングされる前に前記パケットを少なくとも１つのバッファに格納することと、
    のために構成されている、請求項１に記載のネットワークゲートウェイ。
12. 前記少なくとも１つのプロセッサは、前記複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて前記少なくとも１つのバッファのサイズを動的に制御することのために構成されている、請求項１１に記載のネットワークゲートウェイ。
13. 前記少なくとも１つのプロセッサは、前記複数のネットワーク接続の伝送特性の監視および前記データフローの受信における不均等分配に基づいて、前記パケットの肯定応答の送信および格納を制御することのために構成されている、請求項１１に記載のネットワークゲートウェイ。
14. 前記少なくとも１つのプロセッサは、前記複数のネットワーク接続の帯域幅の推定値、およびそれを通して前記データフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも１つに基づいて前記パケットをルーティングするように構成されている、請求項１に記載のネットワークゲートウェイ。
15. 前記少なくとも１つのプロセッサは、前記複数のデータフローのパケットをグループ化し、かつ前記複数のデータフローの分類に基づいてグループ化されたパケットを前記複数のネットワーク接続を通してルーティングするように構成されている、請求項３に記載のネットワークゲートウェイ。
16. 前記複数のデータフローの１つのデータフロークラスは、対応するデータフローの閾値体積のデータがルーティングされると自動的に変わる、請求項１に記載のネットワークゲートウェイ。
17. 前記パケットのデータフローはビデオおよび音声データのうちの少なくとも１つを含むデータパケットである、請求項１に記載のネットワークゲートウェイ。
18. 前記パケットの順次バーストは、帯域幅の推定値の決定を行うために利用されるテストパケットならびにビデオおよび音声データのうちの少なくとも１つを含むデータパケットの両方を含む、請求項４に記載のネットワークゲートウェイ。
19. 前記パケットの順次バーストを通して伝送される前記ビデオおよび音声データのうちの少なくとも１つを含む前記データパケットは、冗長データパケットである、請求項１８に記載のネットワークゲートウェイ。
20. 複数のネットワーク接続を通してデータを伝送するために複数のネットワークインタフェースを通してデータフローをルーティングするための方法であって、前記方法は、
    前記複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、
    パケットのデータフローの少なくとも１つのパケットを解析して前記データフローのためのデータフロークラスを特定することであって、前記データフロークラスは、前記データフローの少なくとも１つのネットワークインタフェース要件に関連づけられていることと、
    前記データフロークラスおよび前記時変ネットワーク伝送特性に基づいて前記データフロー内のパケットを前記複数のネットワーク接続を通してルーティングすることと、
    前記データフロー内のパケットの各パケットのために、前記データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、前記複数のネットワーク接続の監視されたレイテンシに基づく前記複数のネットワーク接続および前記データフロー内の他のパケットのネットワーク接続のうちの１つを通してルーティングするために前記パケットを提供することと、
    を含む、方法。
21. 前記時変ネットワーク伝送特性を監視することは、前記監視される時変ネットワーク伝送特性に基づいて前記複数のネットワークの少なくとも１つのネットワークインタフェースの帯域幅遅延積を生成することを含み、かつ前記データフロー内のパケットをルーティングすることは、前記少なくとも１つのネットワークインタフェースの帯域幅遅延積に基づいている、請求項２０に記載の方法。
22. パケットの複数のデータフローのそれぞれの少なくとも１つのパケットを解析することと、
    前記複数のデータフローのそれぞれのデータフロークラス、および前記それぞれのデータフローのデータフロークラスに対応している前記ネットワーク接続の利用可能な帯域幅に基づいて、前記複数のデータフローのそれぞれの中のパケットをルーティングすることと、
    を含む、請求項２０に記載の方法。
23. 前記複数のネットワークインタフェースの第１のネットワークインタフェースを通してパケットの順次バーストを送信することと、
    前記パケットの順次バースト内のパケットが受信ノードにおいて受信される際に記録されるタイムスタンプおよび前記パケットのサイズに基づいて、前記第１のネットワークインタフェースの帯域幅の推定値を生成することと、
    前記第１のネットワークインタフェースの生成された帯域幅の推定値に基づいて前記複数のネットワーク接続を通して前記データフロー内のパケットをルーティングすることと、
    を含む、請求項２０に記載の方法。
24. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の第１のパケットと前記バースト内の第２のパケットとの間のパケットのパケットサイズの合計を前記第１のパケットのためのタイムスタンプと前記第２のパケットのためのタイムスタンプとの間で経過した時間で割ることを含み、ここでは前記第１のパケットは前記バースト内の最初のパケットではなく、かつ前記第２のパケットは前記バースト内の第１のパケットの後のものである、請求項２３に記載の方法。
25. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の最初もしくは最後のパケットと合体されていない前記バースト内のパケットのタイムスタンプに基づいて前記帯域幅を生成することを含む、請求項２３に記載の方法。
26. 前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の特定のパケットの受信タイムスタンプを前記特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含む、請求項２３に記載の方法。
27. 前記受信ノードが定期的な間隔で受信されたパケットを処理する場合、前記第１のネットワークインタフェースの帯域幅の推定値を生成することは、
    前記帯域幅決定においてエンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、
    前記エンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを前記エンドパケットに先行する前記バースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することと、
    を含む、請求項２３に記載の方法。
28. 前記所望のシーケンスは前記データフロー内のパケットの元のシーケンスである、請求項２０に記載の方法。
29. 前記所望のシーケンスは、前記シーケンス内でのパケットの再送をトリガーしないパケットの少なくとも１つの誤順序付けを含むシーケンスである、請求項２０に記載の方法。
30. 前記複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、
    前記パケットを前記宛先ノードにルーティングする前に肯定応答を前記ソースインタフェースに送信することと、
    前記パケットが前記宛先ノードにルーティングされる前に前記パケットを少なくとも１つのバッファに格納することと、
    を含む、請求項２０に記載の方法。
31. 前記複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて前記少なくとも１つのバッファのサイズを動的に制御することを含む、請求項３０に記載の方法。
32. 前記複数のネットワーク接続の伝送特性の監視および前記データフローの受信における不均等分配に基づいて、前記パケットの肯定応答の送信および格納を制御することを含む、請求項３０に記載の方法。
33. 前記複数のネットワーク接続の帯域幅、およびそれを通して前記データフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも１つに基づいて前記パケットをルーティングすることを含む、請求項２０に記載の方法。
34. 前記複数のデータフローのパケットをグループ化することと、前記複数のデータフローの分類に基づいてグループ化されたパケットを前記複数のネットワーク接続を通してルーティングすることとを含む、請求項２２に記載の方法。
35. 前記複数のデータフローの１つのデータフロークラスは、対応するデータフローの閾値体積のデータがルーティングされると自動的に変わる、請求項２０に記載の方法。
36. 前記パケットのデータフローはビデオおよび音声データのうちの少なくとも１つを含むデータパケットである、請求項２０に記載の方法。
37. 前記パケットの順次バーストは、帯域幅の推定値の決定を行うために利用されるテストパケットならびにビデオおよび音声データのうちの少なくとも１つを含むデータパケットの両方を含む、請求項２３に記載の方法。
38. 前記パケットの順次バーストを通して伝送される前記ビデオおよび音声データのうちの少なくとも１つを含む前記データパケットは、冗長データパケットである、請求項３７に記載の方法。
39. 実行されると、１つ以上のプロセッサに請求項２０～３８のいずれか１項に記載の方法を行わせる機械解釈可能命令のセットを格納するコンピュータ可読媒体。

Images