特表2022-545179 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ デジェロ　ラブス　インコーポレイテッドの特許一覧

特表2022-545179データパケット通信を管理するためのシステムおよび方法

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4A
4B
5A
5B
6
7A
7B
8
9
10
11
12
13
14

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-10-26

(54)【発明の名称】データパケット通信を管理するためのシステムおよび方法

(51)【国際特許分類】

H04L 47/20 20220101AFI20221019BHJP

H04L 45/243 20220101ALI20221019BHJP

【ＦＩ】

H04L47/20

H04L45/243

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022506839

(86)(22)【出願日】2020-08-07

(85)【翻訳文提出日】2022-02-02

(86)【国際出願番号】 CA2020051090

(87)【国際公開番号】W WO2021022383

(87)【国際公開日】2021-02-11

(31)【優先権主張番号】62/884,514

(32)【優先日】2019-08-08

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＦＲＡＭ

(71)【出願人】

【識別番号】517351983

【氏名又は名称】デジェロラブスインコーポレイテッド

(74)【代理人】

【識別番号】110001036

【氏名又は名称】弁理士法人暁合同特許事務所

(72)【発明者】

【氏名】アザームイマド

(72)【発明者】

【氏名】ジーダビッドプイキョング

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA03

5K030LB06

5K030LC01

5K030MA04

5K030MB09

(57)【要約】

種々の実施形態において、１つ以上のデータパケットが、マルチパスネットワークリンクのセットにわたって通信されているデータパケット送達フローを管理するためのシステムが説明され、システムは、一緒に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視し、１つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、１つ以上のデータパケットを遅延させ、それにより１つ以上のデータパケットが必要なペースで通信されているように見えるように、少なくとも監視された総スループットに基づいて、１つ以上のデータパケットのうちの少なくとも１つのデータパケットに対応する特性を変更することによって、パケット間隔操作を実行するように適合されている。
【選択図】図５Ａ

【特許請求の範囲】

【請求項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】

前記１つ以上のタイムスタンプを前記変更することが、前記１つ以上のタイムスタンプを非単調であるタイムスタンプを有するように変更することをさらに含む、請求項２６に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、「ＳＹＳＴＥＭＳＡＮＤＭＥＴＨＯＤＳＦＯＲＭＡＮＡＧＩＮＧＤＡＴＡＰＡＣＫＥＴＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」と題された、２０１９年８月８日に提出された米国特許出願第６２／８８４５１４号の優先権を含む、非暫定的な利益であり、すべての利益を主張する。

【0002】

本出願は、２０１７年１２月２１日に出願され、同じくその全体が参照により本明細書に組み込まれる、「ＰＡＣＫＥＴＴＲＡＮＳＭＩＳＳＩＯＮＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤ」と題された米国特許出願第１６／４８２９７２号にも関連する、ＰＣＴ出願第ＰＣＴ／ＣＡ２０１７／０５１５８４号に関連する。

【0003】

本開示の実施形態は、概して電子データ通信の分野に関し、より具体的には、実施形態は、データパケット通信を管理するためのデバイス、システム、および方法に関する。

【背景技術】

【0004】

はじめに
通信リンクにわたるデータパケット伝送は、例えば、種々の通信ボトルネックに起因する輻輳の問題によって影響を受けている。そのため、ネットワーク化された通信は、輻輳の問題を低減するために、バッファリングおよびペーシングのアプローチを利用して、データパケット通信の改善（例えば、損失パケットの削減、全体的なスループットの改善）に役立てている。

【0005】

例えば、ＴＣＰデータパケットペーシングは、ＡＣＫクロックされている（すなわち、特定の伝送レートではなく、輻輳ウィンドウに基づいてインフライトにパケットを送信する）ＴＣＰ送信機によって送信されるパケットのバースト性を制御する機構として利用することができる。

【0006】

輻輳の問題は、通信ネットワークを通じたサービス品質の低下の主因となる。特に、ペーシングの問題は、パケットの紛失または順不同によって影響を受け得る特定の受信要件がある「ハンドシェイク」または他の誤り訂正プロトコルに関して、上記で述べたような特定の技術的問題を生じさせるネットワークの輻輳をもたらす。

【0007】

特定のプロトコルベースの要件は、中断されると、紛失したと考えられるパケットの不注意な再伝送などのさらなる下流の問題を引き起こし、パフォーマンスをさらに低下させる。したがって、一部のシナリオでは、永続的にパフォーマンスが低下し続ける可能性がある。

【発明の概要】

【0008】

本明細書に記載されるように、データ通信変更アプローチは、データパケットペーシングおよび／またはタイミングに関連する個別の技術的問題を解決するために提案されている。これらのアプローチは、元のペーシングを復元する／新しいペーシングを確立するためにデータパケットペーシングを変更するように適合された特定の技術的ソリューションを提供し、それによって、輻輳を減らすか、または「バースト的な」通信の影響を減らすなどの全体的なデータ伝送特性を改善する。改善されたペーシングは、例えば、バーストが非常に大きく、バッファ制限を超え、結果としてパケットが誤ってドロップされる状況（早期ドロップ）で役立つ。

【0009】

また、代替の提案された実施形態は、例えば、実際のデータペイロードと冗長ペイロード（例えば、フォワード誤り訂正ペイロード）とを区別するためのパケット監視またはフラグ付けアプローチの使用に基づいてペーシングを決定／確立するための特定のアプローチについて説明される。種々のアプローチにより、ペーシングが無効化、有効化、変更された種々のシナリオのテストを通じて実験的に検証され、バーストのタイミングがネットワーク全体の通信品質にどのように影響するかが監視され、検証された。

【0010】

本明細書に記載のアプローチは、物理ネットワークデバイス（例えば、ルータ、シーケンサ、ハブ、マルチパスゲートウェイ、スイッチ、データパケットフォワーダ）、物理デバイスによって実行されるコンピュータ実装方法、および／または結合されたプロセッサ（複数可）上で実行するための非一時的コンピュータ可読媒体上で符号化された機械解釈可能命令セットの形態のソフトウェアまたは組み込みファームウェアとして確立することができる。

【0011】

特に、物理ネットワークデバイスは、物理ネットワークデバイスによって遭遇したデータパケットの指示および／またはルーティングを制御するデータリポジトリ／ストレージ媒体に記憶されたルーティングテーブルまたはルーティングポリシーを変更または別様で確立するように適合され得る。

【0012】

一部の実施形態では、物理ネットワークデバイスは、インフライト変更のために適合される。他の実施形態では、物理ネットワークデバイスは、受信機ノードに適合または結合され得、受信機ノードへのプロビジョニングの前に（例えば、再シーケンサとして）シーケンス修正／ペーシング変更を行う。これは、既存のネットワークインフラストラクチャが後付けに適合している場合に特に有用である。さらなる実施形態では、インフライト変更デバイスおよびエンドポイントリシーケンサデバイスの両方を協働して使用することができる。

【0013】

例示的な説明が本明細書に提供される。単一の通信リンクシナリオでは、データパケット通信プロトコルは、送信デバイスと受信デバイスとの間の直接的な交渉として行われ得る。しかしながら、例えば、ボンディングされた接続セットとして一緒に利用される複数の通信リンクがある場合、データパケットバッファリングおよびデータパケットペーシングに関する技術的課題が増加する。共に利用される複数の通信リンクは、単一の通信パスが信頼できないか、またはそれ自体で適切な送信を提供しないシナリオにおいて特に有用である。

【0014】

例示的なシナリオは、大規模なビデオまたはバルクデータの送信が必要とされるシナリオ（例えば、大量のネットワークトラフィックも存在する大規模スポーツイベントでのライブキャスティング）、地方での通信（例えば、地理的距離および地理的特徴からのスペクトル干渉に起因する）、または緊急対応状況（例えば、プライマリ通信リンクが動作可能ではなく、セカンダリ通信リンクが必要とされる）を含む。

【0015】

データパケット管理は、スループットがデータパケット損失率に逆相関する関数としてモデル化され得るため、有益である（例えば、ＴＣＰスループットは、損失確率の平方根に反比例するように一般的にモデル化される）。しかしながら、単一のリンクにわたる通信間で利用されるパケット管理アプローチは、複数の通信リンクが一緒に使用される場合には最適ではない。

【0016】

本明細書に記載されるように、物理ネットワークデバイス（例えば、改善されたルータ）、ネットワークトラフィックコントローラ、ならびに一緒に利用される複数の通信リンクでの使用に適合された、対応する方法およびコンピュータプログラム製品（例えば、プロセッサ上で実行するための機械解釈可能な命令を記憶する非一時的コンピュータ可読媒体）を含む、技術データパケットおよびデータバッファ／キュー管理機構に関して、技術ソリューションが提案されている。例えば、一部の実施形態のパケット間隔操作は、データパケットが単一のネットワークリンクを介して通信された場合、ペーシングと実質的に同様のパケット通信ペースでデータパケットに復元されるように適合される。パケットモニタ／パケット監視デバイスを使用することによって接続フローを改善するように適合される種々の実施形態に関連して、特定の技術的アプローチが本明細書で説明される。

【0017】

これらのパケット監視／変更ソリューションは、データ通信の特性を変更することによって全体的なスループットを改善するように適合されている。デバイスは、種々の実施形態に従って、送信側（例えば、伝送側）、受信側（例えば、受信機側）、通信リンクコントローラ上（例えば、インフライト）で、またはそれらの組み合わせで動作するように構成されてもよい。例えば、パケットペーシング（例えば、パケット間隔）は、送信側（もしくはインフライト）で変更されてもよく、またはパケットは、受信機側でのバッファリングまたは仲介機構によって離間して配置されてもよい。

【0018】

通信を要求または受信する上流または下流デバイスについて、データパケット管理アクティビティは、透明であり得る（例えば、伝送が要求かつ送信されており、上流または下流デバイスは、通信の態様が成功し、特定の期間を必要としたことを観察するだけである）。

【0019】

例えば、データパケットが、マルチパスネットワークリンクのセットからデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されたときに、パケット間隔操作を実行することができ、かつ／またはデータパケットが、元のデータフローシーケンスまたは間隔配置に基づいて、マルチパスネットワークリンクのセットにわたって伝送するためにデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されたときに、パケット間隔操作を実行することができる。

【0020】

第１の実施形態では、データパケット送達フロー（例えば、データパケットペーシング）を管理するためのシステムが説明されており、これは、データパケットがマルチパスネットワークリンクのセット全体で通信されている場合に適合される。マルチパスネットワークリンクのセットは、共に動作することによって、特定のデータ通信に関連するデータパケットを協働して通信するように、共にボンディングすることができる。データパケットは、通信（例えば、伝送）中に互いに離間され、一部の実施形態では、この間隔は、データパケットが伝送機、仲介ルータ、受信機、またはそれらの組み合わせによってどのように扱われるかを変更するタイムスタンプなどの情報をデータパケットに添付することによって提供される。

【0021】

このアプローチにおけるマルチパスネットワークリンクの利用における技術的課題は、ペーシングが確立されにくく、ペーシング不良がデータパケットを失うことである。データパケットを紛失すると、上層プロトコルに表示されるレイテンシが増加する可能性がある。例えば、アプリケーション層は、ペースの悪いパケットがドロップされ、ＴＣＰ層が再伝送する必要があるため、よりレイテンシが高くなる。

【0022】

一部のデータ転送プロトコルでは、ペースの悪いパケットは、望ましくない動作をもたらし得る。例えば、送信機は、ペーシング不良で発生するパケットの大きなバーストにより、中間ルータまたは他のネットワークホップによってドロップされるパケットを再伝送する必要がある。

【0023】

システムは、共に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視するように構成されたプロセッサを含む。例えば、それぞれが異なる通信特性を提供する３つのネットワークリンクが存在してもよい。第１のネットワークリンクは５Ｍｂｐｓの帯域幅を有し、第２は１５Ｍｂｐｓ、および第３は３０Ｍｂｐｓの帯域幅を有し、合計で５０Ｍｂｐｓになり得る。総スループットは、必ずしもマルチパスネットワークリンクのセットのすべてに及ぶ必要はない。例えば、総スループットは、サブセットにわたって追跡され得るか、または複数の総スループットは、ネットワークリンクの１つ以上のサブセットにわたって監視され得る。

【0024】

パケットペーシングは、１つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、データパケットが必要なペースで通信されている／通信されているように見えるように遅延されるように、少なくとも監視された総スループットに基づいてデータパケットの特性を変更することによって行われる。例えば、変更される特性は、少なくとも監視された総スループットに基づいているデータパケットの各々の受信タイムスタンプ間の（例えば、相対的または絶対的な）パケット間の間隔（例えば、アイデアのパケット間の間隔を通じて確立される必要なペース）であり得る。一部の実施形態では、タイムスタンプの変更は、少なくとも１つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含み得る。

【0025】

監視された総スループットの変化に応答して、プロセッサは、タイムスタンプの理想的なシーケンスが何であるべきであったか（例えば、何が監視された総スループットの変化について事前に知られていたはずであったか）を判定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていないデータパケット上のタイムスタンプのパケット間の間隔を修正するようにさらに構成され得る。

【0026】

一部の実施形態では、バッファは、タイムスタンプされたデータパケットを記憶するために使用され、データパケットが通信される順序を示すキューを定義する固定サイズが存在しないように、サイズを動的に増減するように適合され、データパケットのサブセットは、キュー内のデータパケットの対応する経年（タイムスタンプに基づいて計算される）に基づいてバッファから定期的に削除される。かかるバッファは、意図されたサイズ制限を有していない場合があるが、予想される挙動では、パケットのバーストをバッファリングし、ペーシングレートでそれらを宛先にメータリングすると、ＡＣＫクロックされたバースト的なアプリケーションが、ペーシングレートでその後続のパケットを伝送することを間接的にもたらすため、その結果、後続のパケットのバッファ消費がはるかに小さくなる。しかしながら、実際の実施形態では、ＡＣＫクロックされていないアプリケーションを扱うために、実際のバッファ制限を課さなければならない。これらのアプリケーションは、ペーシングレートに関係なく伝送レートを有するため、最終的に、バッファはその制限に達し、パケットは、任意の数のアクティブキュー管理（ＡＱＭ）アプローチ（例えば、ＲＥＤ、ＦＩＦＯ、ＣｏＤｅｌなど）に従ってドロップされる必要がある。

【図面の簡単な説明】

【0027】

図において、実施形態は、例として示される。説明および図面は、例示の目的のためにのみおよび理解の補助としてのみであることが明示的に理解されるべきである。

【0028】

ここで、実施形態は、例としてのみ、添付の図面を参照して説明される。

【0029】

【図1】一部の実施形態による、データパケット送達フローを管理するための例示的なシステムのブロック概略図である。

【図2】一部の実施形態による、データバッファに関するパケットを示すパケットペーシング図である。

【図3】一部の実施形態による、単一の接続の例を示すパケットペーシング図である。

【図4A】一部の実施形態による、ペーシングなしの複数の接続の例を示す図である。

【図4B】一部の実施形態による、ペーシングなしで損失が発生したときの複数の接続の例を示す図である。

【図5A】一部の実施形態による、ペーシングを伴う複数の接続の例を示す図である。

【図5B】一部の実施形態による、ペーシングおよび損失が発生しない複数の接続の例を示す図である。

【図6】一部の実施形態による、総帯域幅が減少するときの理想的なタイムスタンプと変更されたタイムスタンプとの調整を示すパケットペーシング図である。

【図7A】一部の実施形態による、総帯域幅が増加するときの理想的なタイムスタンプと変更されたタイムスタンプとの調整を示すパケットペーシング図である。

【図7B】一部の実施形態による、総帯域幅が増加するときに、変更されたタイムスタンプを早くまたは遅く調整する効果を示すパケットペーシング図である。

【図8】一部の実施形態による、インフライト変更システムにおける例の構成要素を示すブロック図である。

【図9】一部の実施形態による、例示的な伝送側システムの構成要素を示すブロック図である。

【図10】一部の実施形態による、例示的な受信側システムの構成要素を示すブロック図である。

【図11】一部の実施形態による、インフライトパケットを変更するために仲介ネットワーク要素と連動して動作する例示的なマルチパス送信機および受信機の構成要素を示すブロック図である。

【図12】一部の実施形態による、連結して動作する例示的な伝送側および受信側システムの構成要素を示すブロック図である。

【図13】一部の実施形態による、データパケット送達フローを管理する方法を例示するプロセス図である。

【図14】一部の実施形態による、例示的なコンピューティングデバイスである。

【発明を実施するための形態】

【0030】

本開示の実施形態は、概して電子通信の分野に関し、より具体的には、実施形態は、データパケット通信を管理するためのデバイス、システム、および方法に関する。

【0031】

単一の通信リンクシナリオでは、データパケット通信プロトコルは、送信デバイスと受信デバイスとの間の直接的な交渉として行われ得る。しかしながら、例えば、ボンディングされた接続セットとして一緒に利用される複数の通信リンクがある場合、データパケットバッファリングおよびデータパケットペーシングに関する課題が増加する。共に利用される複数の通信リンクは、単一の通信パスが信頼できないか、またはそれ自体で適切な送信を提供しないシナリオにおいて特に有用である。

【0032】

【0033】

【0034】

このアプローチにおけるマルチパスネットワークリンクの利用における技術的課題は、ペーシングが確立されにくく、ペーシング不良がデータパケットを失うことである。一部のデータ転送プロトコルでは、ペースの悪いパケットは、望ましくない動作をもたらし得る。例えば、送信機は、ペーシング不良で発生するパケットの大きなバーストにより、中間ルータまたは他のネットワークホップによってドロップされるパケットを再伝送する必要がある。

【0035】

利用可能な接続間のレイテンシ、帯域幅、および信頼性の差異を正規化するために、パケットのバッファリングおよび並べ替えを必要とするマルチパスネットワーキングシステムは、例えば、参照によりその全体が本明細書に組み込まれる、「ＰＡＣＫＥＴＴＲＡＮＳＭＩＳＳＩＯＮＳＹＳＴＥＭＡＮＤＭＥＴＨＯＤ」と題された出願人の米国特許出願第１６／４８２９７２号／ＰＣＴ出願第ＰＣＴ／ＣＡ２０１７／０５１５８４号に記載されている。

【0036】

このバッファリングは、ＴＣＰなどのＡＣＫクロックされたプロトコルと組み合わせると、パケットのバースト的な伝送を引き起こす可能性がある。例えば、マルチパスシステムは、ＴＣＰパケットが順番になるまでバッファ／遅延し、次いでそれらをバーストで宛先に解放し得る。宛先は、バーストでＴＣＰセグメントを受信し、バーストでＴＣＰＡＣＫも生成する。これらは、バーストでＴＣＰ送信機に到着する。ＡＣＫクロックされたＴＣＰ送信機、特に低速開始フェーズの送信機は、確認されたバーストと同様のサイズの新しいパケットのバーストと、ネットワークがより多くのデータを送達できるかどうかを検出するのに役立つ同様のサイズの新しいパケットの追加のバーストとを伝送することによって、ＡＣＫのバーストに応答する。全体的な結果は、ＡＣＫのバーストに応答して、さらに大きなパケットインフライトのバースト（確認されたバーストの２倍のサイズ）を伝送することである。これは、いくつかのサイクルにわたって繰り返され、最終的に、バーストが非常に大きくなり、マルチパスネットワークシステムのバッファリング制限を超え、ＴＣＰセグメントの一部をドロップさせる可能性がある。ＴＣＰ送信機は、これらのドロップを輻輳と誤って解釈し、伝送レートを低下させる。

【0037】

予期しないドロップは、マルチパスシステムのサイズベースのバッファリング制限に起因し得る。この制限は、早期のドロップを防止または遅延させるために増加され得るが、大量のデータバーストをバッファリングすることは、マルチパスシステムの利用可能な接続が、妥当な時間内にバッファをクリアするのに十分な伝送容量を有する場合にのみ許容される。その容量が利用できないか、または著しく変動する場合、大きなバーストを受け入れるが、それらを迅速にクリアしないと、過度のバッファブロートが生じ、ここで、インフライトパケットが長時間にわたってバッファリングされ、これは、通信アプリケーションによって、高レイテンシまたは送達タイムアウトとして見られる。

【0038】

このトレードオフに対処するために、サイズによってバッファを制限するのではなく、キュー内のパケットの滞在（待機）時間に基づいてバッファを制限することは、不十分なパケットペーシングの効果を遅延させるのに役立つ一つの手法である。マルチパスシステムに大量の総伝送容量がある場合、ペーシング不良による大きなバーストは速やかにクリアでき、早期のドロップは発生しない。

【0039】

しかし、この無制限のサイズ、滞在時間の制限されたキューは、避けられない遅延を引き起こすだけである。前述の例に続いて、最終的に送信機は、マルチパスシステムのバッファ内のパケットの滞在時間が制限を超え、サイズ制限されたキューで起こるのと同じようにドロップされるように、非常に大きなバーストでＴＣＰセグメントを伝送する。例えば、ネットワークが８Ｍｂ／秒のドレインレートおよび５００ｍｓの滞在時間制限を有するバッファを有すると仮定する。かかるネットワークによる１ＭＢのパケットバッファのバーストには、１秒間のドレインが必要になる。したがって、そのバーストの末尾にある一部のパケットは、５００ｍｓの滞在時間制限を超え、ネットワークを終了する機会を得る前にバッファによってドロップされる。パケットペーシングの目的は、マルチパスシステムがバッファからパケットを強制的にドロップされないように、アプリケーションを１秒間にわたって１ＭＢのパケットバーストのより均等に配置するように誘導することである。システム全体のスループットは、（アプリケーションではロスが発生しないために）向上して、マルチパスシステムのバッファ稼働率も低下する。

【0040】

本明細書に記載されるように、物理ネットワークデバイス（例えば、改善されたルータ）、ネットワークトラフィックコントローラ、および対応する方法ならびにコンピュータプログラム製品（例えば、プロセッサ上で実行するための機械解釈可能な命令を記憶する非一時的コンピュータ可読媒体）を含む、技術データパケットおよびデータバッファ／キュー管理機構に関して、技術ソリューションが提案されている。例えば、一部の実施形態のパケット間隔操作は、データパケットが単一のネットワークリンクを介して通信された場合、ペーシングと実質的に同様のパケット通信ペースでデータパケットに復元されるように適合される。変形実施形態では、異なるペーシングまたは新しいペーシングも同様に確立することができる（例えば、すべての実施形態が実質的に同様のペーシングに限定されるわけではない）。ペーシングは、ルーティングテーブルまたはルーティングポリシーの変更、遅延の注入、タイムスタンプの変更などによって確立することができる。

【0041】

本システムは、一部の実施形態では、単一の接続ケースで自然に発生するペーシングアクティビティを人工的に再現するように適合される。多重接続シナリオでは、ある程度の調整が必要であり、一部の状況では、通信システムは、データパケットのペーシングをある程度制御する。しかしながら、データパケットのペーシングの制御をアサートすることで、制御機構を課すことによって発生する計算コスト、構成要素コスト、およびデバイス複雑性コストも生じる。

【0042】

図１は、一部の実施形態による、データパケット送達フローを管理するための例示的なシステムのブロック概略図である。変形が可能であり、システムは、種々のハードウェア構成要素を有する適切に構成された物理的ハードウェアデバイスであり得る。

【0043】

図１に示されるように、システム１００は、データパケット間のパケット間隔を改善し、変更されたパケット通信ペースを確立することで、システムの伝送部分上の改善されたスケジューリングアプローチおよび受信端上のバッファリングシステムを利用するように構成されている。

【0044】

一実施形態では、図示される構成要素は、互いに相互作用するように構成されたハードウェア構成要素である。別の実施形態では、構成要素は別個の構成要素ではなく、２つ以上の構成要素を特定のハードウェア構成要素（例えば、構成要素のうちの２つ以上の機能を実行するコンピュータチップ）上に実装することができる。プロセッサは、機械可読命令セットを実行するように構成される。一部の場合では、システムは、パケットペーシングを修正するように特別に適合された特別な目的のコンピュータである。一部の場合では、システムは、コンピュータサーバである。一部の場合では、システムは構成されたネットワークデバイスである。

【0045】

いくつかの実施形態では、構成要素は、同じプラットフォーム（例えば、同じ印刷回路基板）上に存在し、システム１００は、輸送可能であり、データセンター／フィールド携帯可能なデバイス（例えば、頑強なモバイル伝送機）などに接続可能である、単数のデバイスである。別の実施形態では、構成要素は分散されており、すべてが近接して配置されているわけではなく、むしろ、電気通信を通じて電子的に通信する（例えば、ローカルで実行されるのではなく、処理および制御は、分散されたリソース環境（例えば、クラウド）に常駐する構成要素によって行われる）。構成要素は、例えば、集積回路またはプリント基板上に結合するためのチップまたはチップセット上のシステムの形態で提供され得る。

【0046】

ボンディングされた接続性の提供は、信号品質、ネットワークの可用性、品質ネットワークなどが最適ではないモバイルシナリオにおいて特に望ましい（例えば、プロフェッショナルのニュース収集／ビデオ作成は、強力なネットワークインフラストラクチャのない場所で行われ得る）。

【0047】

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

【0048】

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

【0049】

システム１００は、ソースエンドポイント１０２から入力（データフロー）を受信し、種々の接続１０６にわたって改善されたデータパケットの送達をスケジュールし、次いで、宛先エンドポイントアプリケーション１１０に伝送する前に、システム１０８の他方の端部でデータパケットをシーケンスする。そうすることによって、システム１００は、利用可能な種々のパスの最大帯域幅の合計に近づくために帯域幅を増加させるように構成される。単一の接続を使用することと比較して、システム１００はまた、改善された信頼性を提供する。これは、イベントが発生しているときにライブイベントでニュースを収集するなど、時間制限のある、非常に機密性の高いシナリオにおける重要な考慮事項となり得る。これらのイベントでは、高信号の輻輳（スポーツイベントなど）、または１つ以上のパスにわたる低信頼性（自然災害後のニュースの報告など）が存在し得る。

【0050】

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

【0051】

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

【0052】

システム１００は、各ゲートウェイ１０４、１０８が、一般に、ＴＣＰトラフィック（またはＵＤＰトラフィック、もしくはＴＣＰとＵＤＰトラフィックの組み合わせ、または任意の種類の一般的なＩＰトラフィック）を扱うためのスケジューラおよびシーケンサを有するという点で、概して双方向であり得るが、一部の実施形態では、１つのゲートウェイのみが必要とされ得る。

【0053】

システムのスケジューリング部分の特徴は、所与の接続の帯域幅を推定するための新しいアプローチである。推定は、例えば、冗長（例えば、ＦＥＣパケット）および非冗長ペイロードが、推定の目的のために互いに区別される、改善された監視アプローチに基づき得る。

【0054】

システム１００は、種々のシナリオ、例えば、既存のインターネット接続（例えば、ＶｏＩＰ電話システムまたはウェブへの企業接続）のためのフェールオーバーまたは補足として利用されてもよく、それによって追加のネットワーク（またはパス）が追加されて、ドロップされたプライマリインターネット接続をシームレスに置き換えるか、またはボンディングが使用されて、プライマリインターネット接続が飽和している場合にのみコストの高いネットワークが含まれる。別の用途として、異なる属性を有する他のデータ接続へのトラフィックのオフロードを可能にすることによって、衛星などの高コスト（しばしばサンクコスト）、高信頼性データ接続の使用を最大化する手段を提供することがある。

【0055】

一部の実施形態では、システムは、複数のネットワーク接続にわたってデータフローをルーティングするように構成されたネットワークゲートウェイである。

【0056】

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

【0057】

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

【0058】

バッファマネージャ１５０は、（個々のフローと、システムを通過する複数の同時フローの組み合わせとの両方の）トラフィックをより効率的に管理するように適合されたゲートウェイ内のバッファを設定するように構成されている。一部の実施形態では、バッファマネージャは、別個のプロセッサである。他の実施形態では、バッファマネージャは、他のアクティビティの中でバッファ管理１５０を実行するように構成されたプロセッサによって提供されるコンピューティングユニットである。

【0059】

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

【0060】

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

【0061】

フロー分類エンジン１５６は、伝送のためにマルチパスゲートウェイ１０４によって受信された各データフローを評価するように構成され、既知でない場合、送信されているトラフィックのタイプおよびその要件を決定するためにフロー分類アプローチを適用するように構成される。一部の実施形態では、ディープパケット検査技術は、判定を実行するように適合される。別の実施形態では、評価は、生成されたときにマーキングまたはラベル付けされたヒューリスティックな方法またはデータフローに基づく。別の実施形態では、評価は、システムのユーザ／管理者によって提供されるルールに基づいている。別の実施形態では、方法の組み合わせが使用される。フロー分類エンジン１５６は、１つ以上のネットワークインターフェースと相互作用するように構成され、電子回路またはプロセッサを使用して実装され得る。

【0062】

例えば、フロー識別は、データフローのパケットで提供される情報の分析、パケットヘッダ情報（例えば、ソース／宛先ＩＰ、トランスポートプロトコル、トランスポートプロトコルポート番号、ＤＳＣＰフラグ）の検査を通じて行われ得る。一部の状況では、送信デバイスは、例えば、ヘッダフラグまたは他のメタデータにおいて、ペイロード内にどのような種類の情報があるかを単純に示すことができる。これは、例えば、ペイロードが暗号化された情報を搬送し、送信されているペイロードの種類を確認することが困難である場合に有用であり得る。一部の実施形態では、（例えば、どのタイプの情報がペイロード内にあるかが不確かな場合）ディープパケット検査アプローチも使用することができる。

【0063】

一部の実施形態で提供されるように、差別化されたレベルの識別が生じてもよい。例えば、パケット本体のコンテンツは、例えば、ディープパケット検査技術を使用してさらに検査されてもよい。

【0064】

フローが特定されると、分類は、その要件に基づいてフローを分類することを含み得る。分類の例としては、以下のようなものがある。

【0065】

１．低レイテンシ、低～中ジッタ、順不同であり得るパケット、高帯域幅（ライブＨＤビデオブロードキャスト）。
２．低レイテンシ、低～中ジッタ、順不同であり得るパケット、中帯域幅（Ｓｋｙｐｅ（商標）、ＦａｃｅＴｉｍｅ（商標））など（ジッタは、アーチファクトまたは通信の劣化を引き起こす可能性があるため、リアルタイム通信で問題となる）。
３．低レイテンシ、低～中ジッタ、順不同であり得るパケット、低帯域幅（ＤＮＳ、ＶｏＩＰ）。
４．低レイテンシ、ジッタ要件なし、パケットは順序どおりであることが望ましい、低帯域幅（インタラクティブＳＳＨ）。
５．レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、中～高帯域幅（例えば、ＳＣＰ、ＳＦＴＰ、ＦＴＰ、ＨＴＴＰ）。
６．レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、帯域幅要件なし、持続的なバルクデータ転送（例えば、ファイル／システムバックアップ）など。

【0066】

分類を行い得る１つ以上の次元には、以下が含まれるが、これらに限定されない。
ａ．レイテンシ
ｂ．帯域幅／スループット
ｃ．ジッタ
ｄ．パケットの順序
ｅ．データ転送量

【0067】

以下にさらに説明するように、これらの分類次元は、効率的な通信フローを改善するのに有用である。レイテンシおよび帯域幅／スループットの考慮事項は、競合する要件を有するフローがある場合に特に重要である。ジッタが扱われる例示的な実施形態は、以下でさらに説明されており、システムは、例えば、スケジューラでのバッファリングを通して、またはフローを特定の接続に固定することによって、ジッタに対応するように構成され得る。パケット順序付けは、具体的にはＴＣＰのための例を用いてさらに以下に説明されており、データ量は、１つのタイプ（低レイテンシ、低帯域幅）から別のタイプ（レイテンシの影響を受けない、高帯域幅）へのフローを再分類し得るインジケータとしてデータ量が使用され得る場所に関連する。

【0068】

他の分類次元および分類が可能であり、上記は例示的な分類として提供される。異なる次元もしくは分類、および／またはその組み合わせを、上記のうちから作成することができる。例えば、メディアブロードキャストにおいて、システムは、ビデオデータおよびクリップに関連付けられたメタデータ（例えば、ＧＰＳ情報、タイミング情報、ラベル）、またはビデオストリームに関連付けられたＦＥＣデータを分類するように構成されてもよい。

【0069】

フロー分類は、システムが発生を防止するように構成された伝送（例えば、一部の例では、ピアツーピアのファイル共有、もしくは著作権の保護下にあることが既知である資料）、またはシステムが階層化されたサービスを提供する文脈で好むように構成され得るトラフィック（例えば、別のユーザまたはソフトウェアプログラムより上位の特定のユーザまたはソフトウェアプログラム）を削除および／またはフィルタリングするために利用され得る。

【0070】

例えば、インターネットバックアップの使用シナリオでは、ボンディングされたバックアップでも可用性が制限され得るため、システムは、サポート組織との間のＶｏＩＰ呼び出しが、組織内の呼び出しよりも高いレベルのサービスを受信するように構成され得る（この場合、システムは、制約下にあるとき、エンドポイントに他の呼び出しよりも一部の呼び出しの音声品質を低下させるか、または帯域幅の制約を考慮して特定の呼び出しを完全にドロップする命令を生成することができる）。

【0071】

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

【0072】

典型的なＱｏＳエンジンは、単一の接続を管理するが、フロー識別および分類を実行するように構成することができ、最終的な結果は、ＱｏＳエンジンが１つの接続で送信される前にパケットを並べ替えることになる。

【0073】

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

【0074】

例えば、以下の特性を有する２つの接続を考慮する。

【0075】

１）接続１：１ｍｓのラウンドトリップタイム（ＲＴＴ）、０．５Ｍｂｐｓの推定帯域幅。
２）接続２：３０ｍｓのＲＴＴ、１０Ｍｂｐｓの推定帯域幅。

【0076】

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

【0077】

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

【0078】

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

【0079】

スケジューラ１６０は、一部の実施形態では、正しい順序でパケットを通信するように構成される必要はなく、むしろ、所望のＱｏＳ／ＱｏＥメトリック（そのうちの一部は、ネットワークコントローラによって定義されてもよく、他のものは、ユーザ／顧客によって定義されてもよい）を満たすか、または超えるように、多様な接続にわたってパケットを通信するように構成される。パケットが順不同で通信されてもよい場合、シーケンサ１６２およびバッファマネージャを利用して、受信したパケットを並べ替えてもよい。

【0080】

パケットの連続的バーストは、ネットワークインターフェースを介して伝送され、パケットの連続的バースト内のパケットが受信ノードで受信されるときに記録されるタイムスタンプ、およびパケットのサイズに基づいて、第１のネットワークインターフェースの帯域幅の推定値が生成される。次いで、推定値は、第１のネットワークインターフェースの生成された帯域幅に基づいて、ネットワーク接続のセット全体のシーケンシャルパケットのデータフロー内のパケットをルーティングするために利用される。以下に説明するように、一部の実施形態では、帯域幅の推定値は、バースト内の初期パケットまたは最終パケットと合体されていないバースト内のパケットのタイムスタンプに基づいて生成され、より低い帯域幅の値を推定することができ、（例えば、パケットの置換を通じて）より高い帯域幅の値を推定することができる。送信されるパケットは、テストパケット、データパケット上のテストパケット「ピギーバック」、またはハイブリッドパケットであり得る。データパケットが「ピギーバック」のために使用される場合、一部の実施形態には、冗長性を増加させるために（例えば、特に帯域幅テスト目的で使用されるパケットのために、損失パケットに対する許容度を強化するために）かかるデータパケットにフラグを立てることが含まれる。

【0081】

シーケンシャルパケットは、順番に、またはシーケンサ１６２が消費のためにパケットを再配置することができるように、順序からの許容可能な偏差内で受信され得る。一部の実施形態では、シーケンサ１６２は、信号を受信し、再組み立てされた信号である出力信号を生成するブロードキャストインフラストラクチャに組み込まれ得る物理的ハードウェアデバイスである。例えば、物理的ハードウェアデバイスは、信号受信および再組み立ての第１の段階として機能するラックマウント型アプライアンスであってもよい。

【0082】

シーケンサ１６２は、フローに対する不必要なパケット再要求または他の誤り訂正を低減するために、受信したパケットを順序付けし、許容できる順序でエンドポイントでそれらをアプリケーションに伝送するように構成されている。この順序は、一部の実施形態では、元の順序に従っている。他の実施形態では、順序は、受信エンドポイントが依然としてデータフローを利用することができるように、許容可能な誤差の範囲内である。シーケンサ１６２は、例えば、受信フローのレイテンシおよびジッタを平滑化するためのバッファまたは他の機構を含んでもよく、一部の実施形態では、複数のネットワーク接続の伝送特性の監視、およびシーケンシャルパケットのデータフローの受信における不均一な分布に基づいて、パケットの確認応答およびストレージの伝送を制御するように構成されてもよい。

【0083】

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

【0084】

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

【0085】

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

【0086】

ＴＣＰなどのプロトコル用に構成されたシステムがパケットを受信するとき、システムは、概して、パケットが順番に到着することを予測する（ただし、要求しない）ように構成される。しかしながら、システムは、順不同パケットが到着すると予想されるとき（通常、ラウンドトリップタイムまたはＲＴＴの数倍）に、制限時間を確立するように構成されている。システムはまた、ヒューリスティックに基づいて制限された時間よりも早く欠落したパケットを再伝送（例えば、３つのＤＵＰＡＣＫによってトリガされる高速再伝送）するように構成され得る。

【0087】

パケットが著しく異なるレイテンシを有する接続上でシーケンサ１６２に到着する場合、シーケンサ１６２は、パケットを宛先に送信する前に、（フローごとに）パケットがおよそ同じ経年（遅延）になるまでパケットをバッファリングするように構成されてもよい。例えば、フローに一貫したレイテンシおよび低ジッタの要件がある場合、これを実行する。

【0088】

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

【0089】

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

【0090】

順不同の状況のために、シーケンサ１６２は、例えば、より大きなレイテンシ変動を示す接続上のより大きなジッタバッファを利用し得る。パケット再伝送のために、シーケンサ１６２は、「最良」（最も信頼性が高く、最小のレイテンシ）接続を介してすぐに損失パケットを要求するように構成されてもよい。

【0091】

例示的なシナリオでは、帯域幅遅延積の推定は完全に正確ではなくてもよく、接続において、レイテンシスパイクが生じる。結果として、パケットは仲介ゲートウェイで順不同で受信される。

【0092】

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

【0093】

例えば、多くのＴＣＰ実装形態は、ＤＵＰＡＣＫの後のパケットが失われる可能性が高いことを示すヒントとして、複数の（例えば、３つの）連続した重複確認応答（ＤＵＰＡＣＫ）を使用する。これらの確認応答は、例えば、パケット監視機構によって追跡され得る。この例では、受信機がパケット１、２、４、５、６を受信した場合、ＡＣＫ（２）を３回（パケット４／５／６の各１回）送信する。次いで、送信機は、このイベントが、パケット３がネットワーク内で失われている可能性が高いことをヒントにし得ることを認識するように構成され、任意の通常の再伝送タイムアウト（ＲＴＯ）タイマーが期限切れになる前に、それを先制的に再伝送する。

【0094】

一部の実施形態では、シーケンサ１６２は、かかる予測的判定を説明するように構成され得る。上記の例に従って、シーケンサ１６２がパケット１、２、４、５、６、３をバッファリングしている場合、シーケンサ１６２は次いで、パケットが適切な順序で伝送されることを確実にするために、パケットを並べ替えてもよい。しかしながら、パケットが１、２、４、３、５、６の順番で既にバッファリングされている場合、予測判定は（パケット３の位置決めが与えられた）この例ではトリガされないので、シーケンサ１６２は、伝送前にそれらをわざわざ並べ替えないように構成され得る。

【0095】

接続コントローラ１５４は、異なる接続パス１０６間で実際のルーティングを実行するように構成され、例えば、ボンディングされたリンクへの接続１０６が物理ゲートウェイ１０４、１０８上に存在する必要がないことを示すために提供される（例えば、物理ゲートウェイは、他の場所にあり得る（およびアンテナなどの異なる場所であり得る）物理的な伝送／受信デバイスまたは衛星機器への一部のリンク（イーサネットまたは他の方法で）を有し得る）。したがって、エンドポイントは、論理的に接続され、種々の方法で物理的に分離され得る。

【0096】

一実施形態では、システム１００は、ＴＣＰアクセラレーションとして知られているものを提供するように構成され、ゲートウェイは、パケットを受信するとプリバッファを作成し、受信エンドポイントが既にパケットを受信したかのように、送信エンドポイントに確認応答信号（例えば、ＡＣＫフラグ）を提供し、実際のパケットがエンドポイントに送達される前に、送信エンドポイント１０２がより多くのパケットをシステム１００に送信することを可能にする。一部の実施形態では、プリバッファリングは、ＴＣＰアクセラレーション（結果として生じるデータのバッファリングと組み合わせられる機会的確認応答（ＡＣＫｉｎｇ））のために使用される。

【0097】

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

【0098】

プリバッファは、例えば、実装形態内の種々のポイントに存在してもよく、例えば、プリバッファは、ゲートウェイ１０４へのエントリポイントに存在してもよく、またはラインを下って（最終的な宛先の前ではあるが）１１０までの任意の場所に存在してもよい。実施形態では、エンドポイント１からエンドポイント２へのデータフローとして、一連のプリバッファ、例えば、ゲートウェイＡおよびゲートウェイＢの両方のプリバッファが存在する。

【0099】

プリバッファに受け入れられ、エンドポイント１０２に日和見的にＡＣＫされたデータは、エンドポイント１１０に確実に伝送するシステム１００の責任となる。ＡＣＫは、エンドポイント１１０がデータを受信したことを元のエンドポイント１０２に伝えるので、その通常のＴＣＰ機構を介した再伝送を扱う必要はない。

【0100】

プリバッファリングおよび日和見的ＡＣＫは、接続１０６の損失および他の非理想的な挙動を処理するためにシステム１００が利用可能な時間制限を取り除くので、有利である。ＴＣＰ加速なしの時間制限は、エンドポイント１０２によって計算されるＴＣＰＲＴＯに基づいており、これは、システム１００の制御に含まれない値である。この時間制限を超えた場合、エンドポイント１０２は、ａ）システム１００が既にバッファリングしている可能性のあるデータを再伝送し、ｂ）そのｃｗｎｄを低減し、それによりスループットを低減する。

【0101】

プリバッファのサイズは、メモリ使用量にバインドを配置するために制限される必要があり得、マルチパスゲートウェイ１０４と１０８との間のフロー制御情報の通信を必要とする。例えば、ゲートウェイ１０８とエンドポイント１１０との間の通信リンクが、すべての接続１０６の総スループットよりも低いスループットを有する場合、１０８でバッファリングされたデータの量は、継続的に増加する。

【0102】

バッファリングされた量が制限を超える場合、フロー制御メッセージを１０４に送信し、エンドポイント１０２から送信されたＡＣＫデータを一時的に停止するように伝える。

【0103】

最終的にバッファリングされた量が制限を下回ると、フロー制御メッセージが１０４に送信され、機会的にＡＣＫを再開するように通知される。制限は、静的閾値であってもよく、または例えば、すべての接続１０６の総ＢＤＰ、およびシステムによって現在処理されているデータフローの総数などの要因を考慮して動的に判定／計算されてもよい。フロー制御開始／停止メッセージが送信される閾値は、同じである必要はない（例えば、ヒステリシスが存在する可能性がある）。

【0104】

同様に、マルチパスゲートウェイ自体内にフロー制御シグナリング情報が存在してもよい。例えば、接続１０６の総スループットが、エンドポイント１０２とゲートウェイ１０４との間のスループットよりも小さい場合、１０４内のプリバッファは、継続的に増加する。制限を超えた後（これは前述のように計算され得る）、エンドポイント１０２から来るデータの日和見ＡＣＫは、一時的に停止され、次いでデータの量が適切な閾値を下回ったときに再開される必要があり得る。

【0105】

前述の例は、エンドポイント１０２から１１０に送信されるデータに対するＴＣＰアクセラレーションを説明している。同様の説明は、データが反対方向に送信される場合にも適用される。

【0106】

別の実施形態では、バッファマネージャは、接続ネットワークの挙動のばらつきと、ネットワーク上の他のアクティビティの潜在的な「バースト的な」性質と、送信元の送信の性質とを考慮して、通信リンクごとの発信伝送上でオーバーバッファリングを提供するように構成される。

【0107】

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

【0108】

このオーバーバッファリングにより、ゲートウェイ１０４は、伝送エンドポイント１０２からのデータを、それ以外の場合収容するために準備されるよりも多く（例えば、それが「快適である」よりも多く）受け入れ、バッファリングすることになる。オーバーバッファリングは、全体的に実行され得る（例えば、システムは、システム推定値が総スループットで利用可能であるよりも多くを取るように構成される）か、もしくは接続コントローラに移動され、接続ごとに管理され得るか、または両方の組み合わせ（例えば、伝送ごとに複数のオーバーバッファ）で提供され得る。

【0109】

例えば、システム１００は、所与のリンクのセットにわたって２０Ｍｂｐｓを送信することができると推定し得るだけであっても、ネットワーク条件が、ネットワーク特性監視ユニット１６１によって提供されるネットワーク特性の統計的、履歴的な知識に基づいて変化する可能性があるという判定、または伝送エンドポイント１０２（または他の入出力伝送）がそのデータ伝送速度を遅くする可能性がある時間があるという判定に基づいて、一時は２０Ｍｂｐｓを超えるもの（例えば、３０Ｍｂｐｓ）を伝送エンドポイント１０２から受け入れ、直ちに送信できないものをバッファリングすることができる。

【0110】

フロー分類エンジン１５６は、一部の実施形態では、特定のタイプのトラフィックにフラグを立てるように構成され、動作エンジン１５２は、一部の実施形態では、バッファマネージャに、フローごとに事前バッファリングおよび／またはオーバーバッファリングをサイズ設定および管理するように指示し、任意の数の基準（データ型、ユーザ、挙動に関する履歴データ、フローの要件）に基づいてバッファのサイズを選択するように構成され得る。

【0111】

一部の実施形態では、（一度にゲートウェイを通ってルーティングされる伝送が多数存在し得るため）これらのバッファのサイズは、伝送ごと、およびゲートウェイごとに決定される。一実施形態において、プレバッファリングおよびオーバーバッファリング技術は、連動して利用される。

【0112】

一部の実施形態では、オーバーバッファリングのサイズは、帯域幅遅延積（ＢＤＰ）に実質的に比例すると判定される。例えば、システムは、ネットワークが高いＢＤＰ（例えば、１０Ｍｂｐｓ＠４００ｍｓ＝＞５００ＫＢ）を有する場合、バッファは、パケットで満たされたネットワーク／パイプラインを維持するのに十分なデータを常に利用できるように、バッファを大きくする必要があるように構成されてもよい。逆に、低いＢＤＰネットワークでは、システムは、過度のバッファブロートを導入しないように、バッファリングが少なくなるように構成されてもよい。

【0113】

バッファブロートは、例えば、ネットワーク内の過剰なバッファリングを指し得、高レイテンシおよびスループットの低下をもたらす。より安価でより容易に利用可能なメモリの出現を考慮すると、多くのデバイスは、現在、かかるバッファの影響を考慮することなく、過剰なバッファを利用する。バッファブロートは、バッファの膨張については、国際計算機学会が発行した論文で詳しく説明されており、これには、例えば、「ＢｕｆｆｅｒＢｌｏａｔ：Ｗｈａｔ’ｓＷｒｏｎｇｗｉｔｈｔｈｅＩｎｔｅｒｎｅｔ？」と題する２０１１年１２月７日の論文、および「Ｂｕｆｆｅｒｂｌｏａｔ：ＤａｒｋＢｕｆｆｅｒｓｉｎｔｈｅＩｎｔｅｒｎｅｔ」と題する２０１１年１１月２９日の論文が含まれ、どちらも参照により本明細書に組み込まれる。

【0114】

ビットレートおよびレイテンシに関連してオーバーバッファリングサイズを決定する例として、ルールは、システムがオーバーバッファリングに起因してネットワークのベースレイテンシに５０％を超えて追加してはならないという要件に関連して実装され得る。この例では、ルールは、オーバーバッファリングのサイズがＢｉｔｒａｔｅ＊ＢａｓｅＬａｔｅｎｃｙ＊１．５であることを示している。他のルールも可能である。

【0115】

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

【0116】

一実施形態では、接続コントローラ１５４は、マルチパスゲートウェイ１０４、１０８（および１つ以上の接続デバイス（例えば、無線インターフェース、または有線接続）に物理的に関連付けられている）とは異なってもよい。別の実施形態では、接続コントローラは、ゲートウェイ上に存在し得るが、物理的接続（例えば、インターフェースまたは有線接続）は、別個のユニット、デバイス、またはデバイス上に存在し得る。

【0117】

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

【0118】

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

【0119】

別の実施形態では、伝送チェーン（例えば、図１３）内に、２つ以上のマルチパスゲートウェイ１０４、１０８のセットが存在してもよい。例えば、一部の実装形態では、クラウド内のゲートウェイに接続するリモートマルチパスゲートウェイを備えたＴＣＰ伝送が存在してもよく、伝送は次に、クラウドのエッジ上の別のマルチパスゲートウェイへの非マルチパス接続を提供し、伝送は次に、別のマルチパスリモートゲートウェイへの非マルチパス接続を提供する。

【0120】

種々の使用例が可能であり得、これには、リモートフィールドオペレータが大量のデータを別の遠隔地に伝送する必要性があり得る軍事的な使用例が含まれる。オペレータのシステム１００は、複数のパスを利用して、より広範なインターネットにデータを提供する伝送機構を備えてもよい。次に、システム１００は、大容量バックホールを使用してインターネットの端部の別の場所に送信し、そこでシステム１００は、第２の遠隔エンドポイントに到達するために別のマルチパス伝送を必要とする。

【0121】

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

【0122】

これらのソリューションは、データ通信の特性を変更することによって全体的なスループットを向上させるように適合されており、図１に示す例に限定されない。例えば、デバイスは、種々の実施形態に従って、送信側（例えば、伝送側）、受信側（例えば、受信機側）、通信リンクコントローラ上（例えば、インフライト）で、またはそれらの組み合わせで動作するように構成されてもよい。

【0123】

例えば、パケット間の間隔は、所望のペーシングレートを反映する各パケットのタイムスタンプの形態でメタデータを受信機に通信することによって、送信側（またはインフライト）で変更され得る。次いで、受信機は、タイムスタンプに基づいて、各パケットの伝送決定を行うことができる。

【0124】

【0125】

例えば、データパケットが、マルチパスネットワークリンクのセットからデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されたときにパケット間隔操作を実行することができ、かつ／またはデータパケットが、元のデータフローシーケンスに基づいて、マルチパスネットワークリンクのセットにわたって伝送するためにデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されたときに、パケット間隔操作を実行することができる。

【0126】

第１の実施形態では、データパケット送達フローを管理するためのシステムが説明され、データパケットがマルチパスネットワークリンクのセット全体で通信されている場合に適合される。マルチパスネットワークリンクのセットは、共に動作することによって、特定のデータ通信に関連するデータパケットを協働して通信するように、共にボンディングすることができる。

【0127】

システムは、共に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視するように構成されたプロセッサを含む。例えば、それぞれが異なる通信特性を提供する３つのネットワークリンクがあってもよい。第１のネットワークリンクは５Ｍｂｐｓの帯域幅を有し、第２は１５Ｍｂｐｓ、および第３は３０Ｍｂｐｓの帯域幅を有し、合計で５０Ｍｂｐｓになり得る。

【0128】

パケットペーシングは、１つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、特性が１つ以上のデータパケットが必要なペースで通信されているように見えるように変更されるように、少なくとも監視された総スループットに基づいてデータパケットの特性を変更することによって行われる。例えば、変更される特性は、マルチパス送信機によって受信されるデータパケットの各々に対応するメタデータ内のタイムスタンプであり得る。一部の実施形態では、タイムスタンプの変更は、少なくとも１つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含み得る。

【0129】

プロセッサは、マルチパスネットワークリンクの各々上で伝送される異なるタイプのパケットを監視するようにさらに構成され得る。例えば、送信機が受信機に通信しようとしているデータペイロードパケットは、監視された総スループットに寄与するべき１つのタイプのパケットである。送信機がネットワークリンクのネットワークプロパティを評価するために使用できるテストパケットは、貢献しないオーバーヘッドパケットの一種である。損失レポートに応答して送信された、または損失の可能性または予測された損失を防ぐために先制的に送信された過去に伝送されたデータパケットの複製である再伝送パケットは、寄与してはならない冗長パケットの一種である。複数の他のタイプのパケットが存在し得る。所与の時点で、これらのすべてのタイプのパケットの混合物は、マルチパスネットワークリンクの１つ以上にわたって同時にインフライトであり得る。したがって、監視された総スループットは、データパケットによって具体的に使用されている部分（非オーバーヘッドおよび非冗長パケット）を反映するように調整され得る。

【0130】

一実施形態では、プロセッサは、アカウンティング／パケット特性判定機能、例えば、パケットカウントまたはバイトカウントを実行し、スライドウィンドウ期間にわたって結果を平均化して、データパケットが消費している監視された総スループットの一部を判定することができる。前述の例に続いて、総スループットが３０Ｍｂｐｓの第３のネットワークリンクが、２０Ｍｂｐｓのデータパケット（例えば、前の１秒で２０Ｍｂ）、６Ｍｂｐｓのテストパケット（例えば、同じ１秒で６Ｍｂ）、および４Ｍｂｐｓの伝送パケット（例えば、同じ１秒で４Ｍｂ）を伝送していた場合、データパケットのペーシングを行うときに、２０Ｍｂｐｓ部分のみが考慮される。この例では、ペーシング目的で監視された総スループットは、４０Ｍｂｐｓに調整される。これらは、例えば、パケットモニタによって追跡され得る。

【0131】

他の実施形態では、インフライトバイトカウントをビットレートに変換することは、接続の総推定ビットレートおよび総輻輳ウィンドウ（ＣＷＮＤ）に基づいている。例えば、合計推定ビットレートが３０Ｍｂｐｓ、合計ＣＷＮＤが５００ＫＢ、インフライトデータパケットが１００ＫＢの接続は、

【数1】

の総スループットに寄与することになる。

【0132】

監視された総スループットの変化に応答して、プロセッサは、タイムスタンプの理想的なシーケンスが何であるべきであったか（例えば、何が監視された総スループットの変化について事前に知られていたはずであったか）を決定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていないデータパケット上のタイムスタンプのパケット間の間隔を修正するようにさらに構成され得る。ネットワークリンクの変更が検出または測定されるとき、例えば、デボンダからフィードバックが受信されるとき、またはインフライトパケットの混合が変更されるとき、例えば、過去に送信されたパケットが確認され、おそらく異なるタイプの他のパケットがそれに応じて送信されるとき、監視された総スループットの変更が生じる。

【0133】

一部の実施形態では、データパケットのためのバッファであって、バッファは、データパケットが通信される順序を示すキューを定義する固定サイズが存在しないように、サイズを動的に増減するように適合され、データパケットのサブセットは、キュー内のデータパケットの対応する経年（例えば、滞在時間）に基づいてバッファから定期的に削除される。滞在時間は、タイムスタンプを比較することによって決定することができる。

【0134】

図２は、データバッファに関するパケットを示すパケットペーシング図２００である。

【0135】

図２００は、ペースの良い送信機が、同じネットワークを介してバースト的な送信機よりも高いスループットを実現することができる方法を示している。図は、２つの送信機を示しており、１つはペースが良く、もう他方はバースト的である。両方の送信機は、１０ＭＢ／秒の速度で１ＭＢのパケットを伝送し、そのパケットは、最大バッファサイズが５ＭＢ、およびドレインレートが１０ＭＢ／秒のボトルネックリンクを通過する。

【0136】

ペースの良い送信機は、１００ミリ秒ごとに１ＭＢのパケットを伝送する。これらのパケットがボトルネックリンクに到着すると、５ＭＢのネットワークバッファに短時間滞在し、すぐにボトルネックレートで排出される。この送信機が実現した平均スループットは、完全な１０ＭＢ／秒である。

【0137】

バースト的な送信機は、毎秒１０個の１ＭＢパケットを伝送する。すべてのバーストの第１の５パケットは、ボトルネックリンクの５ＭＢバッファにキューに入れられ、第２の５パケットはバッファが満杯になるとドロップされる。ボトルネックリンクはその後、１０ＭＢ／秒の速度でバッファを排出し、これは、１００ミリ秒ごとに１ＭＢのパケットを意味する。１秒ごとに、第１の５００ｍｓはボトルネックリンクがアクティブであるが、伝送するパケットがない（ドロップされた）ため、第２の５００ｍｓはアイドル状態である。このバースト的な送信機が実現した平均スループットは５ＭＢ／秒である。

【0138】

ＴＣＰ輻輳制御アルゴリズム（例えば、Ｒｅｎｏ、ＣＵＢＩＣ）は、ＡＣＫクロックされる。つまり、特定のビットレートでパケットを伝送せず、代わりに輻輳ウィンドウ（ｃｗｎｄ）の概念を維持することを意味する。

【0139】

インフライトのバイト数（受信機によって未確認）がｃｗｎｄ未満である限り、それらはできるだけ速く伝送される（新しいバイトが伝送可能であると仮定する）。インフライトがｃｗｎｄになると、送信機は伝送を停止する。インフライトバイトの確認応答（ＡＣＫ）が受信されたときにのみ再開される。したがって、伝送のビットレートおよびバースティック性は、ＡＣＫが到達する速度によって完全に支配される。

【0140】

以下の説明では、ＴＣＰ送信機がアプリケーションに制限されることはないと仮定する。つまり、インフライトがｃｗｎｄ未満であるため、ＴＣＰ送信機がバイトを伝送することを望むたびに、バイトが利用可能であることを意味する。また、ＴＣＰ送信機が受信機ウィンドウ（ｒｗｉｎ）に制限されていないと仮定する。つまり、ＴＣＰ受信機は常に、少なくともｃｗｎｄからインフライトを引いたバイト数を受け入れることができるとアドバタイズする。

【0141】

図３は、シングルパス接続のボトルネックリンクが、ＴＣＰＲｅｎｏおよびＣＵＢＩＣなどのＡＣＫクロックされたプロトコルのパケットを自然にペーシングすることができる方法を示す図３００である。

【0142】

新しいＴＣＰフローのｃｗｎｄは、低い妥当な値（初期のｃｗｎｄと称される）で開始される。図では、これは時刻ｔ＝０ｍｓで示されている。この送信機の初期ｃｗｎｄは５パケットである。インフライトは最初は０に等しいため、送信機は最初のｃｗｎｄに等しいパケットのバーストを送信する。これらのパケットがネットワーク（この図では、合計１００ｍｓの一方向レイテンシを有する）を通過するとき、各ホップは、そのボトルネックレート（物理的に維持可能なビットレート）でのみバイトを伝送することができる。

【0143】

最終的に、パケットはボトルネックであるホップに到着する。この例では、ボトルネックは、９パケットのバッファサイズ、および１０ｍｓごとの５パケットのドレインレート（すなわち、２ｍｓのパケット間の間隔）を有する。このボトルネックは、パケットが受信機に到着すると、５つのパケットがボトルネックレートを反映するパケット間の間隔を有する（ｔ＝１０２、１０４、１０６、１０８、および１１０ｍｓに到着する）ように、パケットを時間内に「自然に」離間する。パケットは、ボトルネックリンクの自然なペーシング、５パケット／１０ｍｓを使用している。

【0144】

ＴＣＰ受信機は、パケットが到着するとＡＣＫを生成するため、ＡＣＫは同じペースで伝送される（ｔ＝１０２、１０４、１０６、１０８、および１１０ｍｓで伝送される）。ＡＣＫは同じペースでＴＣＰ送信機に戻り（ｔ＝２０２、２０４、２０６、２０８、および２１０ｍｓに到着）、インフライトが同じペースで減少する。

【0145】

結果として、インフライトが最初に０であったときのｔ＝０での最初の伝送中のように、バーストではなく、ボトルネックレートで、インフライトをｃｗｎｄに戻すためのＴＣＰ送信機による後続の伝送が自然に発生する。

【0146】

それはまた、インフライトを減少させることに加えて、ＴＣＰ送信機が受信した各ＡＣＫについて、ｃｗｎｄへの増加をもたらす可能性がある。増加の速度および大きさは、輻輳制御アルゴリズムとその内部状態に依存する。この例では、送信機はＴＣＰＲｅｎｏを使用しており、「スロースタート」フェーズにある。このように、ｃｗｎｄは、ＡＣＫされるパケットの数と同じ数だけ増加する。

【0147】

これにより、「ペーシングバースト」が発生し、ＡＣＫされた各パケットでは、インフライトが１減少し、ｃｗｎｄが１増加し、ＴＣＰ送信機が次のバーストで２パケットを伝送できるようになる。これらの小さなバーストは、上述の機構に従って、ボトルネックリンクによって再び「離間」（ペーシング）される。例えば、パケット６および７は、ｔ＝２０２ｍｓで伝送された２つのパケットの最初の「ペーシングバースト」であるが、１パケット／２ｍｓのボトルネックレートによって離間された受信機に到着する。したがって、ｔ＝３０４ｍｓおよびｔ＝３０６ｍｓに到達する。

【0148】

このサイクルは、ＴＣＰ送信機が伝送レートを増加させる原因となる。ＴＣＰ送信機がボトルネックリンクのスループットよりも高いビットレートに達すると、ボトルネックバッファにパケットを伝送するレートが、ボトルネックがバッファをドレインするレートを超え、バッファが充填される。やがてバッファが満杯になり、ＴＣＰフローが引き戻される（ｃｗｎｄを減らす）ことを知らせるパケットがドロップされる。

【0149】

ＴＣＰフローは、後で同様の方法でスループットを増やそうと繰り返し試みる。したがって、ＴＣＰフローのスループットは、ボトルネックリンクのスループットの周りで変動する。

【0150】

図４Ａは、ＴＣＰＲｅｎｏまたはＣＵＢＩＣフローが、ペーシングを明示的に考慮しないナイーブマルチパスボンディングシステム１００を通過するときに何が起こるかを示す図４００Ａである。システムには、次の３つのパスがある。

【0151】

５００ｍｓレイテンシ、１パケット／１０ｍｓドレインレート、２パケットバッファ

【0152】

１２０ｍｓレイテンシ、２パケット／１０ｍｓドレインレート、３パケットバッファ

【0153】

５０ｍｓレイテンシ、２パケット／１０ｍｓドレインレート、４パケットバッファ

【0154】

前述と同様に、初期インフライトは０パケットであり、初期ｃｗｎｄは５パケットであるため、ＴＣＰ送信機は時刻ｔ＝０ｍｓで５パケットのバーストを伝送する。マルチパスボンディングシステムの例は、パケットをパスのドレインレートに比例して分割し、第１の接続にわたって１パケット、および他の接続にそれぞれ２パケットを意味する。

【0155】

各接続は、異なるスループットおよびレイテンシを有するため、シーケンサ１６２は、宛先ＴＣＰ受信機にそれらを解放する前に、パケットをバッファリングし、並べ替える必要がある。この例では、パケット番号１は、時刻ｔ＝５１０ｍｓでシーケンサ１６２に最後に到着し、この時点で、５つすべてのパケットが宛先ＴＣＰ受信機にフラッシュされる。この動作は、非マルチパスシナリオで前述した「自然な」ペーシングを除去する。

【0156】

ナイーブシーケンサ１６２を有するＴＣＰ受信機によって見られるパケットのバーストは、ＡＣＫのバーストを生成する。この例では、マルチパスシステムは、最速リンク上でＡＣＫを送信するので、それらはすべて、時間ｔ＝５６０でバーストとしてＴＣＰ送信機に到着する。前述の例のように、ＴＣＰ送信機は「スロースタート」フェーズにあるため、このときｃｗｎｄは最大１０パケットを開放する。

【0157】

図４Ｂは、次に何が起こるかを示す図４００Ｂである。インフライトが０であり、ｃｗｎｄが１０であるため、ＴＣＰ送信機は、マルチパスシステムを通じてバーストで１０のパケットを伝送する。また、１０個のパケットを帯域幅に比例したパスに分割する。ただし、第２の接続には３つのバッファスロットしかないため、４つのパケットを伝送するには不十分であることを想起されたい。このように、パケット番号１１はドロップされる。

【0158】

ＴＣＰ送信機は、これらのドロップを輻輳と解釈し、ｃｗｎｄを制限することによって、例えばその値を半分にするなどして、直ちにこの認識された輻輳を解決するためにアクションを実行する。ただし、この認識された輻輳は、ペーシングの欠如によって引き起こされる誤検知であることに留意されたい。それによって、ｃｗｎｄの早期縮小は、伝送レートを低下させ、このＴＣＰ接続上で実行されるアプリケーションは、スループットを低下させる。この例は、固定サイズバッファによるパケットのドロップを示すマルチパス接続を示しているが、マルチパスシステム自体がドロップのソースになる可能性もある。接続速度の異なる混合については、ＴＣＰ送信機バーストサイズが十分に大きくなると、マルチパスシステムの入力バッファ（バッファサイズではなくパケット滞在時間に基づいてドロップするバッファであっても）がパケットをドロップすることができる。

【0159】

ＴＣＰスループットに対するパケットバーストの負の副作用を回避するために、ボンディングシステム１００がパケットへのペーシングを復元することが不可欠である。次の段落では、種々のアプローチが提案されている。

【0160】

ボンディングされた接続は、単一の接続としてＴＣＰフローに表示される。したがって、ボンディング接続の場合、パケットは、ボンディング接続の総スループットに等しいスループットを有する単一の接続上でパケットが伝送された場合に観察されるペーシングと同様のペーシングを示す必要がある。

【0161】

図５Ａは、元のパケットへのペーシングを復元するマルチパスシステムを示す図５００Ａである。これまでと同様に、パケット番号１はシーケンサ１６２に最後に到着するが、今回は、５つのパケットをすべて一度にフラッシュするのではなく、各パケットを遅延させることによってペーシングを復元し、最悪の接続のレイテンシ（５１０ｍｓ）によってすべて遅延され、すべての接続の総レート（５パケット／１０ｍｓ）で伝送されたように見える。これは、２ｍｓのパケット間の間隔を意味する。

【0162】

一実施形態では、これらの遅延の実装形態は、パケット上のタイムスタンプの形態のメタデータを使用して、送信機および受信機を通じて実現される。タイムスタンプを使用できるが、必ずしも送信機と受信機との間のクロックから同期させる必要はない。図５Ａの例の目的のために、クロックは同期される。

【0163】

マルチパス送信機は、０、２、４、６、および８ｍｓのタイムスタンプで５つのＴＣＰデータセグメントをマーキングする。マルチパス受信機では、これらのパケットが受信され、バッファ内に配置されると、それらの現在の経年は、常に現在の時間からそれらのタイムスタンプを減算することによって計算することができる。この例では、マルチパス受信機は、各ＴＣＰセグメントがシステム内で５１０ｍｓを消費するまで、そのバッファ内の各ＴＣＰセグメントを保持する（遅延させる）。これは、マルチパス受信機が、その経年が５１０、５１２、５１４、５１６、および５１８ｍｓに達したときにのみ、それらを（それぞれ）ＴＣＰ受信機エンドポイントに伝送することを意味する。

【0164】

結果として、ＴＣＰＡＣＫは、同じペーシングレートでＴＣＰ受信機によって生成および送信され、結果として、同じ２ｍｓのパケット間の間隔で（マルチパスシステムを介して）ＴＣＰ送信機に戻る。次に、２ｍｓごとに１パケットのレートでインフライトを減らし、２ｍｓごとに１パケットのレートでｃｗｎｄを増加させる。

【0165】

図５Ｂは、図３の単一パスの例と同様に、適切なペースのＡＣＫがどのように適切なペースのバーストをもたらすかを示す図５００Ｂである。イベントのタイムラインは次のとおりである。

【0166】

ＡＣＫはｔ＝５６０ｍｓに到達し、インフライト時間を１時間短縮し、ｃｗｎｄを１時間増加させ、２つのパケットを伝送することができる。

【0167】

パケット番号６および７は、伝送され、その伝送レートに比例して利用可能なパスに分割される。すなわち、第１のパス上のパケット６、第２のパス上のパケット７である。

【0168】

ＡＣＫはｔ＝５６２ｍｓに到着し、さらに２つのパケットを伝送することができる。

【0169】

パケット番号８および９は、利用可能なパスに比例して分割されて伝送される。すなわち、第３のパスのパケット８、第２のパスのパケット９である。最初のパスは、他の２つのパスの容量の半分に比例しているため、スキップされる。

【0170】

プロセスは繰り返され、今回は図４Ｂとは異なり、第２のパスのバッファサイズ制限に達することはないため、パケットはドロップされない。結果として、ＴＣＰ送信機はこの時点で輻輳を認識しないので、ｃｗｎｄを早期に減少させず、したがって伝送レートを早期に引き戻さない。ＴＣＰ送信機は、ｃｗｎｄをインクリメントし続け、最終的には、ボンディングされたネットワークの完全な集約機能を真に反映する正しい大きな値に落ち着き、それによって全体的なスループットが向上する。

【0171】

他の実施形態では、これは、シーケンサ１６２内の受信側で、送信機から受信側に直接または間接的に通信されるボンディングされた接続の総スループットに基づいて実現される。

【0172】

一実施形態では、監視された総スループットは、独立制御チャネルを介して送信機から受信機に直接通信される。

【0173】

別の実施形態では、送信機は、欠落した情報の一部を受信機に通信し、受信機は、次いで、送信機と同じアルゴリズムを実行して、総スループットを間接的に判定する。欠落情報は、総スループットの値よりもサイズが小さくてもよい。この代替アプローチは、ネットワークの使用量および遅延を節約できるが、受信機において複雑なコンピュータ処理機能を必要とする。かかるアプローチの一例は、参照によりその全体が本明細書に組み込まれる、ＩＥＴＦドラフトのｄｒａｆｔ－ｃｈｅｎｇ－ｉｃｃｒｇ－ｄｅｌｉｖｅｒｙ－ｒａｔｅ－ｅｓｔｉｍａｔｉｏｎ－００に記載されている。これは、送達速度、すなわち、一定期間に送信機から受信機に送達されるバイト数を計算することによって、ネットワークリンクのスループットを決定する。送達レートを正確に計算するには、
１）受信機に送達されたバイト数、
２）これらのバイトが送達された期間、および
３）伝送イベントごとに送信機でバイトが利用可能かどうか、の３つの情報が必要である。それ以外の場合はリンクが完全に利用されず（「アプリケーション制限」と称される）、計算された送達速度はリンクの実際のスループットよりも低い。

【0174】

最初の２つの情報は、受信機がパケットを受信する際に、受信機によって決定される。任意の２つのパケット受信イベントが与えられた場合、受信機に送達されるバイト数は、最初のイベントのパケットを除外し、最後のイベントのパケットを含めた、これら２つのイベント間で受信されたすべてのパケットの合計サイズ（バイト単位）である。これらのバイトが送達された期間は、これら２つのイベントが発生した時間の差である。

【0175】

ただし、第３の情報は、純粋に送信機のイベントに関連しているため、受信機で個別に決定することはできない。この欠落している情報は、１ビットで表すことができる。例えば、０のビット値は、送信機がすべての伝送イベントで利用可能なバイトを有していなかったことを示し（すなわち、スループット推定値が不正確であり得る）、１のビット値は、伝送機がすべての送信イベントで利用可能なバイトを有していたことを示す（すなわち、スループット推定値が正確である）。１ビットがネットワークリンクを介して通信可能な情報の最小量であることを考えると、スループット推定値を直接通信するための任意の代替のアプローチでは、少なくとも同等以上の量のビットが消費される。

【0176】

受信機が総帯域幅の値を有すると、外部機構を使用してシーケンサ１６２バッファを排出することができる。例えば、一部のネットワークインターフェースは、特定のビットレートでパケットをリリースするようにハードウェアまたはドライバレベルで構成することができる。デボンダは、パケットを書き込むネットワークインターフェースを構成して、総スループットでパケットを解放することができる。別の実施形態では、受信機は、必要なペーシングを実現するために、パケットのサイズおよび総スループットを使用して、適切な時間にパケットを解放することができる。

【0177】

別の実施形態では、マルチパス送信機は、自然なペーシングを得るために、利用可能な接続の特性を利用することができる。例えば、特定のＴＣＰフローに属するパケットは、利用可能な接続のサブセット上でのみ伝送されてもよい。これらの接続のプロパティが同じ場合（またはサブセットに１つの接続しか含まれていない場合）、送信機または受信機による明示的な通信またはその他の意図的なアクションがなければ、ペーシングは自然に発生する。

【0178】

別の実施形態では、パケットペーシングは、送信側のスケジューラ１６０内のパケットを変更することによっても復元され得る。このアプローチは、受信側でのデボンダへの総ボンディングスループットの通信を必要としないという利点を有する。フロー分類エンジン１５６は、送信側からのパケットに、エンドポイント１０２から受信される時間を含むメタデータをスタンプする。したがって、シングルバーストで受信されたパケットは、すべて同じタイムスタンプでスタンプされる。

【0179】

前述のように、デボンダバッファでのシーケンサ１６２は、ジッタおよび並べ替えを低減するために、リリース前にパケットを再順序付けし、保持する。これは、メタデータのタイムスタンプに対するパケットの経年を比較することによって行われる。したがって、ペーシングなしの一実施形態では、フロー分類エンジン１５６でシングルバーストで受信されたパケットは、最終的に、シーケンサ１６２によって同時にすべて解放される。ボンダのスケジューラ１６０がパケットのタイムスタンプを変更し、デボンダのシーケンサ１６２が必要なペーシングを反映する異なる時間にそれらを解放するように、パケットペーシングを実現することができる。

【0180】

一実施形態では、スケジューラ１６０によって使用される機構は、入力パケットのタイムスタンプを、ボンディングされた接続の総スループットと比較することである。パケット間の間隔が、パケットが総スループットよりも速い速度で受信されていることを示す場合、それらのタイムスタンプは、それらが必要なペースで受信されたように見えるように修正される。これらの修正は、タイムスタンプを未来にプッシュする可能性があることに留意されたい。

【0181】

これは、正確には、図５Ａに記載されているとおりである。パケット１～５はすべて、０ｍｓのパケット間の間隔であるｔ＝０で受信されている。この例では、実際の総スループットは５パケット／１０ｍｓで、パケット間の間隔は２ｍｓである。スケジューラ１６０は、パケット１＝０ｍｓ、パケット２＝２ｍｓ、パケット３＝４ｍｓ、パケット４＝６ｍｓ、およびパケット５＝８ｍｓとなるように、パケット上のタイムスタンプを調整する。パケット２～５はいずれも未来のタイムスタンプが付されている。この調整は、例えば、調整されているタイムスタンプを含む、送信機での各パケットに関連付けられたメタデータを変更することによって行われ得る。調整は、パケットをカプセル化するオーバーヘッドフィールドでも実行できる。これらのフィールドは、正しい時間に受信エンドポイントにパケットを送達するためにシーケンサ１６２によって使用される。

【0182】

その後の総スループットの変更は、未来から使用される過去に修正されたタイムスタンプの一部が異なるはずであることを意味し得る。パケットがインフライト（すでに送信済み）である場合、これらのタイムスタンプは変更できなくなる。かかる場合、アルゴリズムは、タイムスタンプの理想的なシーケンスが何であるべきであったかを判定する。その結果は、変更されたタイムスタンプと理想的なタイムスタンプとが最終的に整列するように、まだインフライトしていないパケットのタイムスタンプのパケット間の間隔を修正する際に考慮される。

【0183】

図６は、図６００であり、アプローチが、総スループットが減少するとき、例えば、寄与するネットワークインターフェースの１つが電源を切るとき、または寄与するセルラーインターフェースが、セルラーサービスプロバイダのユーザの数が増加したために、より少ないスループットを提供するときに、どのように動作させることができるかの例を示している。時間ｔ１において、８つのパケットがフロー分類エンジン１５６に到着する。スケジューラ１６０は、ｔ１における総帯域幅を反映するようにそれらのタイムスタンプのパケット間の間隔を調整し、パケットは伝送される（それらはインフライトである）。理想的なタイムスタンプと変更されたタイムスタンプとは、この時点で等しい。

【0184】

ｔ２（インフライトパケット５のタイムスタンプと一致する）の後の時点で、総帯域幅は５０％減少する。パケット５～８はインフライトであり、新規かつより遅い総帯域幅を反映するようにそれらのタイムスタンプを変更することはできない。しかしながら、タイムスタンプの理想的なセットは、新しいより遅い総帯域幅に従ってパケット５～８が離間されたかのようにシミュレートすることによって決定／計算され得る（遅い帯域幅は、パケット間の間隔が増加し、パケットを未来にさらに押し込むことを意味する）。

【0185】

まだインフライトされていないパケットは、スケジューラ１６０によってタイムスタンプが修正され、パケット８が修正可能である場合に受信するはずの理想的な未来のタイムスタンプの後に開始される。このようにして、平均ペーシングレートは、時間ｔ２における新たに検出された値と一致する。

【0186】

図７Ａは、総スループットが増加したときのアプローチの動作の例を示す図７００Ａである。パケット１～８は、時間ｔ１でフロー分類エンジン１５６によって受信され、それらのタイムスタンプのパケット間の間隔は、ｔ１での総帯域幅と一致するように、スケジューラ１６０によって補正され、パケットは伝送される（それらはインフライトである）。理想的なタイムスタンプと変更されたタイムスタンプとは、この時点で等しい。

【0187】

時間ｔ２（インフライトパケット５のタイムスタンプと一致する）で、総帯域幅は５０％増加する。パケット５～８はインフライトであり、帯域幅の新たな増加を反映するためにそれらのタイムスタンプを変更することはできない。しかしながら、理想的なセットのタイムスタンプを計算することができ、新しいより高い総帯域幅に従ってパケット５～８が離間して配置されているかのようにシミュレートする（帯域幅が広いということは、パケット間の間隔が狭くなり、理想的なタイムスタンプが未来から現在に近づくことを意味する）。

【0188】

時間ｔ２において、パケット９～１２もフロー分類エンジン１５６によって受信される。スケジューラ１６０は、パケット１２のターゲット理想的なタイムスタンプを決定するために、インフライトパケット５～８の新しい理想的なタイムスタンプに対するこれらのパケットのパケット間の間隔を決定する。しかしながら、インフライトパケット５～８の実際のタイムスタンプは変更できないため、パケット９～１２は、パケット８の実際のタイムスタンプとパケット１２の理想的なタイムスタンプとの間のどこかで変更されたタイムスタンプを割り当てる必要がある。一実施形態は、タイムスタンプを、それらの２つの時間点の間に均等に配置する。理想的なタイムスタンプおよび変更されたタイムスタンプは、この操作の後に等しくなり、その後のパケット（１３＋）が理想的なタイムスタンプに対してペーシングされることを可能にする。

【0189】

いくつかの実施形態は、未来のパケットの理想的なケースを対象とするように、変更されたタイムスタンプを必ずしも修正しない。図７Ｂの図７００Ｂからわかるように、変更されたケースは、パケットのタイムスタンプが非常に小さいパケット間の間隔を有する（またはパケット間の間隔がない）ことを強制する可能性があるため、過度のバーストをもたらす可能性がある（これは、このアプローチが回避しようとしている元の問題である）。

【0190】

目的はバーストを減らすことであるため、最小の許容パケット間の間隔の下限が適用され、パケットの現在のバーストのタイムスタンプが理想的なポイントを超えて（および再び未来に）移動する可能性がある。

【0191】

フロアが現在の総スループットの理想的なパケット間の間隔よりも小さい限り、パケットの変更されたタイムスタンプは、より多くのパケットのペースと送信が行われるため、最終的に理想的なポイントと一致する（例えば「キャッチアップ」する）。

【0192】

一部の実施形態では、最小の許容パケット間の間隔のフロアは、管理者の好みまたはアプリケーション要件などの入力に基づいて構成または決定することができるパラメータである。このパラメータで生じるトレードオフでは、総帯域幅が増加すると、より小さいフロアは、パケットの短期バーストを犠牲にして、増加した総帯域幅をより早く使用することを可能にする（これは、前述のように、ＡＣＫクロックされたプロトコルのパケット損失を引き起こす可能性がある）。

【0193】

一部の実施形態では、シーケンサ１６２は、遅延パケットまたは損失パケットをどのように扱うべきかについて構成され得る。例えば、図５Ａでは、パケット１がデボンダに到達しない場合、パケット２～５を宛先にフラッシュすることを決定するポイントは、管理上の好み、アプリケーション／プロトコル要件、接続挙動の統計分析などを考慮に入れることができる。例えば、受信アプリケーションが、これらのパケットが送信アプリケーションによって生成された後１秒後に送達されるパケットに対して使用しない場合、シーケンサ１６２は、パケット１がまだ欠落しているか、またはパケット１の再伝送がまだ到着していない場合であっても、１秒の期限に達する前に、パケット２～５をデボンダにフラッシュ（すなわち送達）する必要がある。言い換えれば、アプリケーションは、遅すぎて使用できなくなったときに５つのパケットすべてを受信するよりも、合理的な時間枠で５つのパケットのうち４つを受信する方がよい。重要なことは、パケット２～５のパケット間の間隔は、このプロセスの結果として変化しないことである。修正されたペーシングは維持される、すべてのパケットは、同じ量だけ時間的にオフセットされる。

【0194】

パケット１が最終的に到着した場合、それを宛先に遅く転送するか、それともそれをドロップするかの決定は、管理者の好み、アプリケーション／プロトコル要件、接続挙動の統計分析なども考慮に入れることができる。遅延パケットを宛先に転送することが決定された場合、その前後に順次伝送されたパケットはすでに宛先に伝送されていたため、そのペーシングは保持されない。一部の実施形態では、遅延パケットのペーシングは、シーケンサ１６２によって考慮されてもよく、例えば、過度のバーストを防止するために遅延パケットの伝送をさらに遅延させる。
さらに別の実施形態では、マルチパス送信機および受信機は、所望のペーシングを実現するために一緒に動作することができる。例えば、スケジューラ１６０は、図６、７Ａ、および７Ｂについて先に説明したように、現在の所望のペーシングレートを反映するようにパケットメタデータ内のタイムスタンプを変更することによって、パケット間の間隔を変更することができる。ペーシングレートがその後変化する場合、スケジューラ１６０は、インフライトパケット上のタイムスタンプが何らかの形で修正されたことにして、パケット間の間隔を変更し続けることができる。総帯域幅が増加する場合、これは、非単調タイムスタンプ（すなわち、時間を遡るように見えるタイムスタンプ）を有する連続パケットをもたらす。非単調タイムスタンプの修正は、パケットを宛先にフラッシュする前にシーケンサ１６２で行われ得る。

【0195】

図８は、一部の実施形態による、例示的なシステム８００の構成要素を示すブロック図である。この例では、上流デバイス８０２は、下流デバイス８１０と通信している。通信は、一方向（例えば、上流デバイス８０２および下流デバイス８１０の一方が伝送機デバイスとして動作し、反対側が受信機デバイスとして動作する）であっても、双方向であってもよく、上流デバイス８０２および下流デバイス８１０の両方が、データパケットを通信するために伝送機および受信機として動作する。

【0196】

図８の図８００の簡略化された例では、マルチパスゲートウェイ機構８０４および８０８は、伝送側８０４および受信側８０８として示され、８０６で潜在的なインフライト変更が行われる（破線で示される）。本明細書の種々の実施形態で説明されるように、伝送側８０４および受信側８０８として示される１つ以上の、８０６における潜在的なインフライト変更（破線で示される）を有するものは、データパケット送達フロー変更機構（例えば、プロトコル）を行う（例えば、または強制する）ために使用され得る。

【0197】

（新規の接続が利用可能になる／実現可能になる、および／または既存の接続が利用不可能になる／利用不可能になるにつれてメンバーシップが動的であり得る）ボンディングされた接続のセットが評価され、全体的なスループットまたは他の総通信特性が確立され、次いで、データパケットペーシング／間隔が変更され得るように、伝送側８０４および受信側８０８、またはインフライト変更デバイス８０６のうちの少なくとも１つに通信される。

【0198】

特に、データパケットが監視された総スループットまたは他の集約された通信特性よりも速い速度で通信されている場合、データパケットが伝送されている（またはインフライトで、または受信機でバッファリングされている）ことに対応する特性は、少なくとも監視された総スループットに基づいて変更され得る。

【0199】

図９の図９００に示されるように、通常のシーケンサ１６０と組み合わせて動作するスマートスケジューラ１５８が存在し得る。この例では、マルチパス伝送機９０４は、接続１、２、および３を含むことができる接続９０６にわたる伝送中／伝送前に、入力デバイス９０２からのデータパケットの特性を変更するように適合される。この例におけるマルチパス受信機９０８のシーケンサ１６０は、変更された特性を認識しない場合があり、出力デバイス９１０に送達するためのデータパケットを受信する。

【0200】

図１０の図１０００に示されるような代替の変形例が可能であり、ここで、マルチパス伝送機１００４のスケジューラが、接続１００６にわたってパケット間隔／ペーシングを行うことなく、クライアント１００２からデータパケットを伝送し、マルチパス受信機１００８におけるバッファが、シーケンス順序を認識し、タイムスタンプおよび通信された総帯域幅（または他のネットワーク特性）に基づいて、データパケットをサーバ１０１０にフラッシュする前に、データパケットを並べ替えている。

【0201】

図１１の図１１００に示されるような別の代替の変形例が可能であり、入力デバイス１１０２がデータパケットを伝送機１１０４に提供して、最終的に受信機１１０８を介して出力デバイス１１１０に伝送している。この例では、インフライト変更調整エンジン１１１２は、データパケットが総帯域幅または他のネットワーク特性に基づいて移動する中間ルータを制御するように適合される。次いで、中間ルータは、種々の実施形態に従って、データパケットペーシング／間隔を変更する。最も遅い中間ルータは、一部の実施形態では、すべてのボンディングされた接続に必要な間隔を確立する。

【0202】

図１２の図１２００に示されるように、スマートスケジューラ１５８は、スマートシーケンサ１６０と連携して動作することができる。この例では、スマートスケジューラ１５８がスマートシーケンサ１６０と協働して、パケット間隔機構を確立および実施するシステムによって、より大きな複雑性が利用される。例えば、複数の接続１２０６にわたって、入力デバイス１２０２と出力デバイス１２１０との間の通信のために双方向のトラフィックフローが離間されるように、異なる役割が割り当てられてもよい。異なる役割には、タイムスタンプを変更するスマートスケジューラ１５８またはスマートシーケンサ１６０の一方が含まれ得、他方はバッファリングプロトコルを確立する。

【0203】

図１３は、ステップ１３０２、１３０４、１３０６、および１３０８を示す、一部の実施形態による、データパケット送達フローを管理する方法を例示するプロセス図１３００である。他のステップが可能であり、図１３００は例示的な目的のための例である。

【0204】

図１４は、一実施形態の例であるコンピューティングデバイス１４００の概略図である。描写されるように、コンピューティングデバイス１４００は、少なくとも１つのプロセッサ１４０２、メモリ１４０４、少なくとも１つのＩ／Ｏインターフェース１４０６、および少なくとも１つのネットワークインターフェース１４０８を含む。

【0205】

各プロセッサ１４０２は、例えば、マイクロプロセッサまたはマイクロコントローラ、デジタル信号処理（ＤＳＰ）プロセッサ、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、リコンフィギュラブルプロセッサ、プログラマブル読み取り専用メモリ（ＰＲＯＭ）、またはそれらの組み合わせであり得る。

【0206】

メモリ１４０４は、例えば、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、コンパクトディスク読み取り専用メモリ（ＣＤＲＯＭ）、電気光学メモリ、磁気光学メモリ、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、および電気消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、強誘電性ＲＡＭ（ＦＲＡＭ）などの内部または外部のいずれかに位置するコンピュータメモリの組み合わせを含んでもよい。

【0207】

各Ｉ／Ｏインターフェース１４０６は、コンピューティングデバイス１４００が、キーボード、マウス、カメラ、タッチスクリーン、およびマイクロフォンなどの１つ以上の入力デバイス、またはディスプレイ画面およびスピーカなどの１つ以上の出力デバイスと相互接続することを可能にする。

【0208】

各ネットワークインターフェース１４０８は、コンピューティングデバイス１４００が、インターネット、イーサネット、プレーンオールドテレフォンサービス（ＰＯＴＳ）回線、公衆交換電話ネットワーク（ＰＳＴＮ）、統合サービスデジタルネットワーク（ＩＳＤＮ）、デジタル加入者回線（ＤＳＬ）、同軸ケーブル、光ファイバ、衛星、モバイル、無線（例えばＷｉ－Ｆｉ、ＷｉＭＡＸ）、ＳＳ７信号通信ネットワーク、固定回線、ローカルエリアネットワーク、ワイドエリアネットワーク、およびこれらの組み合わせを含む他のものを含むデータを搬送し得るネットワーク（または複数のネットワーク）に接続することによって、他の構成要素と通信し、他の構成要素とデータを交換し、ネットワークリソースにアクセスおよび接続し、アプリケーションを提供し、他のコンピューティングアプリケーションを実行することを可能にする。

【0209】

別の実施形態では、特殊目的機械は、使用のために構成され、提供される。かかる特殊目的機械は、限定された範囲の機能で構成され、組み込みファームウェアまたはソフトウェアからの命令に従って特定の機能を実行するようにプログラムされた効率的なデバイスに特徴を提供するように特別に構成される。この実施形態では、専用機械は、一般的なコンピューティング機能を提供しない。例えば、コントローラボードおよびスケジューラを含む特定のデバイスは、特定用途向け集積回路などの集積回路の形態で提供され得る。

【0210】

この特定用途向け集積回路は、ゲートの特定の構成を通じて、上述のような複雑な機能を実行するために一緒に組み合わされるプログラムされたゲートを含み得る。これらのゲートは、例えば、互いの間にセルおよび電気的接続を有する下位レベルの構築物を形成し得る。特定用途向け集積回路の潜在的な利点は、効率の向上、伝播遅延の低減、および消費電力の低減である。特定用途向け集積回路は、回路の空間と体積が関連する要因である小型化要件を満たすのにも役立ち得る。

【0211】

「接続された」または「結合された」という用語は、直接結合（互いに結合された２つの要素が互いに接触する）および間接結合（少なくとも１つの追加の要素が２つの要素の間に位置する）の両方を含み得る。

【0212】

実施形態は詳細に説明されているが、本明細書では、範囲から逸脱することなく、種々の変更、置換、および改変を行うことができることを理解されたい。さらに、本出願の範囲は、本明細書に記載されるプロセス、機械、製造、物質の組成、手段、方法およびステップの特定の実施形態に限定されることを意図しない。

【0213】

当業者が本開示から容易に理解するように、本明細書に記載される対応する実施形態と実質的に同じ機能を実行するか、または実質的に同じ結果を実現する、現在存在するか、または後に開発される物質、手段、方法、またはステップのプロセス、機械、製造、組成物が利用され得る。したがって、添付の実施形態は、かかるプロセス、機械、製造、物質の組成物、手段、方法、またはステップをそれらの範囲内に含むことが意図される。

【0214】

理解され得るように、上記に記載され、例示される実施例は、例示的なものに過ぎないことが意図される。

【図1】