JP2014518047A - 適応性の伝送キュー長を用いたデータパケット損失低減システムおよび方法 - Google Patents

Abstract

本発明は、複数のネットワークインターフェース用のデータパケット損失を低減するシステムおよび方法を提供する。特に、本発明は、ネットワーク状態の動的分析に基づくデータパケット損失低減用のクロスレイヤーシステムを提供する。さらに、本発明は、ネットワーク状態を推定し、さらに、関連するネットワークのチャンネル状態／利用可能な帯域に従って、複数のインターフェースの伝送キューを適応させるシステムおよび方法を提供する。
【選択図】図１

Description

本発明は、電気通信に関する。具体的には、本発明は、複数のアクティブ物理インターフェースを用いるクロスレイヤー帯域集約(cross layer bandwidth aggregation)システム用のネットワーク推定（network estimation）に基づき、伝送キュー（queue：待ち行列）長を適応（状況に合わせて変化）させることによるデータパケット損失の低減に関する。

通信ネットワークは、広域ネットワーク（ＷＡＮ）、パーソナルエリアネットワーク（ＰＡＮｓ）、ローカルエリアネットワーク（ＬＡＮｓ）、およびキャンパスエリアネットワーク（ＣＡＮｓ）のグループの組み合わせを含む。

広域ネットワーク（ＷＡＮ）や地域分散通信ネットワーク（geographically distributed telecommunication network）は、全世界のユーザーがデータを効率的に共有し、伝送することを可能としている。これにより、企業は、情報取引および事業活動を実行することができる。ロバストな（robust：堅牢な）ＷＡＮインフラストラクチャーは、混乱（disruption）なくビジネスを行うための会社の必須条件である。ＷＡＮネットワークを介したデータ転送は、パケット損失の低減を向上させるために広く研究されている。ネットワーク内でのパケット損失は、サービスクオリティ（ＱｏＳ：Quality of Services）およびアプリケーション用のダウンロードおよびアップロード率を低下させる。また、パケット損失は、ネットワークを介した情報取引の損失を引き起こす。そのため、パケット損失の低減に関する様々な研究が行われている。

本分野における当業者は、ネットワークアーキテクチャ（architecture：基本設計、基本構造）をベースとしたプロキシに基づくパケット損失、クライアントサーバーアーキテクチャに基づく、すなわち、他方の側における対応コンポーネント（counter component）を用いることによるパケット損失における低減、推定および帯域集約を理解している。最新技術のシステムは、クロスレイヤー認識（aware）ではない。既存のシステムは、フィードバックメカニズムに依存するネットワーク推定またはその他に基づき、スループットを向上させる如何なる伝送キュー適応も実行しない。また、既存のシステムは、送信者および受信者双方の関与、またはトランスポート層ウィンドウサイズ（window size：送達確認なしに連続して送受信できるデータ量のこと）を要求する。伝送キュー管理用の既存のメカニズムは、ＴＣＰウィンドウサイズを変更し、それにより伝送バッファーサイズを変更する。これは、ＩＰヘッダーのＥＣＮビット（ネットワーク内の混雑状態の指標）を、キュー管理のトリガー（きっかけ）として利用する。伝送キュー管理は、ルーター内で実行される。

利用可能な技術的解決方法および最新技術における短所を理解するために、我々にとって既知の従来技術のいくつかが、議論される。

ヴィタリオら（Vitalio et al.）による「サービスのＶｏＩＰクオリティにおけるアクティブキュー管理の影響について（On the impact of active queue management on VoIP quality of service）」は、混雑管理スキームに基づくルーターを開示している。明示された混雑通知を用いたアクティブキュー管理は、ＶｏＩＰの場合、ＱｏＳの改善のために用いられる。しかしながら、このスキームは、ＶｏＩＰ用にのみテストされたものであり、また、音声クオリティ低下発生時の混雑に対応するため、ユーザー介入が要求される。

ジアンら（Jian et al.）による「第３世代無線ネットワークを通じたリアルタイムトラフィック用のリンク層バッファーへのアクティブキュー管理の適用（Applying Active Queue Management to Link Layer Buffers for Real-time Traffic over Third Generation Wireless Networks）」は、３Ｇ無線システムにおける無線リンク制御層に適用されるアクティブキュー管理を開示している。ＨＡＲＱ（Hybrid ARQ：データ誤り訂正手法の１種）フィードバックメカニズムからの入力が、アクティブキュー管理に利用される。ユーザー装置と基地局（Base station）との間のチャンネル状態の評価が、混雑制御に利用される。しかしながら、このスキームは、物理データユニット（ＰＤＵ’ｓ）のキュー管理に適用されるものであって、パケットのキュー用に厳密に適用されるものではない。

上述の従来技術において存在する欠陥のいくつかは、これまでは、探索（research）が、目標における対応物（カウンターパート）の存在を必須としていたことである。これにより、ネットワーク推定に基づく伝送キュー管理を実行するための複数のインターフェースの同時使用ができない。また、これらアプローチは、如何なるクロスレイヤー技術も使用しない。

したがって、最終目標または任意のノードにおける如何なる対応するコンポーネントまたは特定のネットワークアーキテクチャも用いることなく、もしくは、任意のネットワークプロキシまたは管理ノードを用い、さらに物理層およびデータリンク層における如何なる変更も実行することなく、動的なネットワーク状態に基づき、パケット損失の低減という長年の課題を解決する必要性がある。

本発明の第１の目的は、インターフェースのネットワーク状態に基づき、アクティブインターフェースのそれぞれの伝送キュー長を適応（状況に合わせて変化）させることにより、パケット損失の低減を実行可能な、複数のインターフェースを通じた通信を行うクロスレイヤーシステムを提供することにある。

本発明の別の重要な目的は、アクティブな複数の物理インターフェースを用いて、帯域集約とともに同時にパケット損失を低減するシステムを適応させることにある。

本発明の目的は、主に無線ＷＡＮインターフェースにおけるデータパケット損失を低減する方法およびシステムを提供することにある。

本発明の別の目的は、関連インターフェースの利用可能な帯域／ネットワーク推定に従って、複数のインターフェースの伝送キューを同時に適応させることが可能な方法およびシステムを提供することにある。

また、本発明の別の目的は、ネットワーク推定の使用から、複数のインターフェースの伝送キューを変更する方法およびシステムを提供することにある。

本発明の方法、システム、およびハードウェアの実施可能性を記述する前に、本開示内で明確に説明されない本発明の複数の実施形態が存在可能なので、本発明は記述される特定のシステムおよび手法に限定されないことに留意されたい。また、本開示内で用いられる専門用語は、特定のバージョンまたは実施形態を記述する目的のみに用いられるのであって、本発明の範囲を限定することを意図していない。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。

本発明は、劣悪な（poor）ネットワーク状態におけるパケット損失を低減するクロスレイヤーシステムを提供する。該システムは、アクティブインターフェースのそれぞれ用に適切な伝送キュー長を適応させる。

本発明の別の様態は、アクティブインターフェースのそれぞれに関連付けられた現在の（current）伝送キュー長を決定する方法およびシステムを提供する。初期設定の伝送キュー長と、現在の伝送キュー長との比は、以前の時間間隔（time-interval）（設定）で決定された帯域と、現在の決定された帯域との比に比例する。

また、本発明の別の様態は、チャンネル／ネットワーク状態を推定し、推定に基づきアクティブ物理インターフェースのそれぞれに関連付けられた伝送キュー長を変更し、それにより、パケット損失を低減する方法およびシステムを提供する。

以下に示す好適な実施形態の詳細な説明と同様に、上述の要旨は、添付の図面と共に参照されることによって、より良く理解される。本発明を説明するため、添付の図面に本発明のいくつかの構成例が示される。しかしながら、本発明は、図に開示された特定の方法およびシステムに限定されるものではない。

図１は、複数のインターフェースを有する通信ネットワークにおけるデータパケット損失を低減させるプロセスを図示するフローダイアグラムである。

図２は、伝送キュー長を適応させることによって、パケット損失の低減を提供する帯域集約システムの機能ブロックを説明するフローダイアグラムである。

以下、説明されている全ての特徴、本発明の複数の実施形態が議論される。明細書中、「構成する」、「有する」、「含む」、「備える」およびそれらの他の形式は、同等な意味であり、限定を意味するものではなく、ある事項またはこれらの文言のいずれか１つに続く事項の包括的なリストであるような意味ではなく、また、列挙された事項のみに限定されるという意味ではない。また、明細書および添付の請求項において使用されるように、単数形“a”、“an”、“the”は、文脈が明確に示していなければ、複数形も含むことに注意しなければならない。ここで説明される方法およびシステムと同等、または類似の方法およびシステムは、本発明の実施形態の実施またはテストに使用されることができるが、好ましいシステムおよび方法は以下に説明される。開示される実施形態は、単に本発明の例示にすぎず、様々な形式で実装してもよい。

複数のインターフェースを有する通信ネットワークにおけるデータパケット損失を低減するシステムであって、
ａ．複数のアクティブインターフェースの帯域を集約し、前記通信に含まれる前記アクティブインターフェースのそれぞれに関連付けられた有効ネットワークチャンネル帯域比を推定する少なくとも１つのネットワークドライバーモジュールと、
ｂ．ユーザー定義の入力を受信する、前記ネットワークドライバーモジュールのユーザー空間コンポーネントと、
ｃ．初期設定のキュー長および前記アクティブインターフェースに関連付けられた適応性のキュー長を有する伝送キューと、
ｄ．前記実際の物理インターフェースのネットワークドライバーをカプセル化し、前記複数の物理インターフェースの前記伝送キュー長を適応させるネットワークドライバーモジュールと、
ｅ．前記インターフェースに関連付けられた帯域の利用可能度に従って、前記複数のインターフェースの前記伝送キュー長を変化させるよう構成された少なくとも２つの物理インターフェースと、を備える。

本発明のシステムの要素のそれぞれは、複数のインターフェースを有する通信ネットワークにおけるデータパケットの損失を低減する方法を実行するよう構成されている。該方法は、
ａ．仮想物理インターフェースを登録するネットワークドライバーモジュールを生成する工程と、
ｂ．前記インターフェースのそれぞれに関連付けられ、ユーザー入力に対応する複数の特性を取得する工程と、
ｃ．事前に定められた設定可能な時間間隔に基づいて、アクティブインターフェースに関連付けられた通信チャンネルの以前の帯域および現在の帯域を決定する工程と、
ｄ．前記通信に含まれる前記アクティブインターフェースに関連付けられた前記以前の時間間隔の帯域と、前記現在の帯域との比として特徴づけられる有効ネットワークチャンネル帯域比を推定する工程と、
ｅ．少なくとも１つの適応性の伝送キューを前記アクティブインターフェースに割り当てる工程と、
ｆ．前記アクティブインターフェースの現在の伝送キュー長を決定し、前記アクティブインターフェースの初期設定の伝送キュー長と、現在の伝送キュー長との比によって特徴づけられる有効伝送キュー長比を導出する工程と、
ｇ．前記有効伝送キュー長比が前記有効ネットワークチャンネル帯域比に比例し、比例定数が所定のしきい値と等しくなるよう前記アクティブインターフェース用の伝送キュー長を設定する工程と、
ｈ．ネットワークルーティングコンポーネントによる遮断なく、さらに、目標に関連付けられたアクティブインターフェースから送られたデータ状況を検索することなく、前記アクティブインターフェースに適応的に変更されたデータレートで、前記データパケットを送信する工程と、を備える。

本発明の実施形態の１つでは、ネットワークドライバーモジュールは、演算システム内に存在するアクティブ物理インターフェースの全てをカプセル化する“仮想物理”インターフェースを生成する。よって、前記システムは、存在する物理インターフェースの物理層およびデータリンク層における如何なる変更も実行しない。

図１は、本発明の１つの例の実施形態に従った、複数のインターフェースを有する通信ネットワークにおけるデータパケット損失を低減する方法を図示したフローダイアグラムである。プロセスは、仮想物理インターフェースを登録するネットワークドライバーモジュールを生成するステップ１０においてスタートする。ステップ２０において、システムは、インターフェースのデバイスの種類、ＩＰアドレス、ゲートウェイＩＰアドレス、および関連付けられたユーザー入力を含む、ネットワーク内のインターフェースの複数の特性を取得する。ステップ３０において、所定の時間間隔に基づいて、アクティブインターフェースのそれぞれに関連付けられた通信チャンネルの以前の帯域および現在の帯域の推定が、ネットワークドライバーモジュール内部のネットワーク推定コンポーネントによって決定される。ステップ４０において、通信に含まれる前述のアクティブインターフェースのそれぞれにネットワークによって関連付けられた有効ネットワークチャンネル帯域比が、ドライバーモジュールによって決定される。ステップ５０において、少なくとも１つの適応性の伝送キューが、前述のアクティブインターフェースのそれぞれに割り当てられる。ステップ６０において、インターフェースの現在の伝送キューが、ネットワークドライバー内部の伝送キュー適応モジュールによって決定される。

アクティブインターフェースのそれぞれの現在の伝送キューと、初期設定の伝送キューとの比は、帯域比、すなわち、（ステップ４０において決定された）インターフェースの有効ネットワークチャンネル帯域比に比例となるよう保たれている。比例定数は、所定のしきい値と等しく、固定された最小値を有する。ステップ７０において、アクティブインターフェースのそれぞれ用の伝送キュー長は、伝送キュー適応モジュールによって設定される。プロセスは、ステップ８０において終了する。ステップ８０では、データパケットは、ネットワークルーティングコンポーネントによって遮断されず、さらに、目標に関連付けられたアクティブインターフェースからのパケット損失通知と同様に、送られるデータ状況を検索することなく、推定された帯域に従って、適応的に変更されたデータレートで、前述のアクティブインターフェースに配布される。

図２は、ネットワークからのパッケージ損失の低減用の機能ブロックを説明するシステムアーキテクチャダイアグラムである。このシステムは、ネットワークドライバーモジュール２０４と、物理インターフェース２０８と、データリンク層２１０と、物理層２１２と、インターネットプロトコル（ＩＰ）２１４と、トランスポートプロトコルヘッダー２１６と、ポート番号２１８とを含む。ネットワークドライバーモジュール２０４は、帯域集約部と、帯域推定部と、伝送キュー適応部（図示せず）とをさらに含む。

本発明の実施形態の１つでは、システムは、ユーザー空間２０６（図示せず）と、カーネル空間２０７（図示せず）とをさらに含む。

本発明の好適な実施形態の１つによれば、ユーザー空間２０６は、システム取得の入力と同様に、ユーザー定義の入力を集めるため、ＡＰＩｓ（Application Programming Interfaces：ソフトウェアコンポーネントがデータ等を互いにやり取りするために用いられるインターフェースの仕様）を見えるようにする。前述のユーザー定義の入力は、以下を含む。
ａ．ネットワークインターフェースの利用可能な帯域の推定のために探索パケット（probe packets）が送信されるパブリックＩＰアドレスを有するサーバーのドメインネーム
ｂ．ネットワーク状態推定および帯域決定を実行するための時間間隔
ｃ．アプリケーションのＱｏＳ要求（オプショナル）
ｄ．その他オプショナルなパラメーター（ネットワーク推定の許可または無効化等）

ユーザー入力は、コマンドラインを介して、ユーザーによって提供される。システム定義の入力は、以下を含む。
ａ．帯域集約および推定に利用可能なネットワークインターフェースに関する情報（インターフェース識別子、ＩＰアドレス、もしあれば、ゲートウェイのＩＰアドレス）。システム取得の入力は、データグラムソケットを用いたｉｏｃｔｌ（）関数呼び出しを実行することにより取得される。
ｂ．アクティブ物理インターフェース／デバイスの状況に関する情報（すなわち、インターフェースがＵＰまたはＤＯＷＮであるか、または、インターフェース／デバイスの状況の変化）も取得される。

本発明の実施形態では、カーネル空間２０７は、アプリケーションと、実際のデータ処理との間の架け橋として機能する。ユーザー空間２０６およびカーネル空間２０７は、密接な結合（close bonding）を有し、これらコンポーネントは双方、以下のようなｒａｗソケット（raw socket：生のネットワークパケットへのダイレクト送受信を可能にするインターネットソケット）によるｉｏｃｔｌ（）関数呼び出しを用いて制御情報を交換している。
ａ．ＧＥＴＩＮＦＯ：カーネル空間モジュールに利用可能な、集約用のネットワークインターフェースについての情報を集める。
ｂ．ＳＥＴＩＮＦＯ：利用可能なネットワークインターフェースについての情報を、カーネル空間モジュールに送る。
ｃ．ＮＤＭＩＮＦＯ（Network Diagnostics）：帯域推定に関する情報をカーネル空間モジュールに送り、さらに、カーネル空間モジュールからネットワークインターフェースの利用可能な帯域についての情報を集める。

本発明の実施形態では、システムは、アプリケーション／上部層からスタートする、インターネットプロトコルＩＰ（インターネットプロトコル）２１４から物理層２１２への全てのデータ経路、またはその逆の全てのデータ経路のゲートウェイとして機能する。システムは、アプリケーションまたは初期設定を用いて特定されるサービスクオリティ（ＱｏＳ）要求に基づいて、存在するアクティブ物理インターフェース２０８間において伝送を行う際に、データパケットを配布する。システムが各インターフェース２０８からデータを受信し、各アプリケーションにデータを送る。

本発明の実施形態では、ネットワークドライバーモジュール２０４は、仮想インターフェースを生成し、ＩＰアドレスおよびネットマスクを仮想インターフェースに割り当て、さらに、このインターフェースをルーティングテーブル（routing table：パケットの送信先に関する経路情報）内の初期エントリーとして追加する。上位層から来る全てのアプリケーションデータは、ソースアドレスとして、このＩＰアドレスを使用する。

本発明の実施形態では、ネットワークドライバーモジュール２０４は、データをそれらインターフェースに配布している間に、自身のＩＰアドレスを、対応するアクティブ物理インターフェース２０８のＩＰアドレスと置き換え、さらに、要求に応じて、インターネットプロトコルＩＰ２１４およびトランスポートプロトコルヘッダー２１６用の必要なチェックサム計算を実行する。ネットワークドライバーモジュール２０４は、受信の間、それらインターフェースの実際のＩＰアドレスを、自身のＩＰアドレスと置き換え、さらに、インターネットプロトコルＩＰ２１４およびトランスポートプロトコルヘッダー２１６用の必要なチェックサム計算を実行する。

本発明の実施形態では、ネットワークドライバーモジュール２０４は、自身の従属インターネットインターフェス（slave internet interface）として、アクティブインターフェース／デバイスを使用する。ネットワークドライバーモジュール２０４は、いくつかの所定の識別子、例えば、ポート番号２１８（ＨＴＴＰパケットまたはＦＴＰパケット等）およびそのユーザー空間モジュール２０６を介したアプリケーション（オプショナル）によって特定されるサービスクオリティ（ＱｏＳ）要求に基づいて、アプリケーションからデータパケットを配布する。配布されたデータパケットは、その従属インターフェース、すなわち、アクティブ物理インターフェース２０８の伝送キューに直接送られる。ネットワークドライバーモジュール２０４は、パケットフィルタリング（ネットフィルター）メカニズムを使用し、この目的用のフック関数（hook function）を受信経路内で関連付ける。フック関数は、アクティブインターフェースによってパケットが受信された直後にパケットをフィルタリングするために用いられる。パケットフィルターの関連付けられたフック関数は、データパケットにおける必要な変更を実行し、アプリケーションに送信する前に、データパケットを構築する。

本発明の実施形態では、提案のシステムは、ネットワークチャンネル状態を測定するための所定のインターネットコントロールメッセージプロトコル（ＩＣＭＰ）エコーパケット２２２を使用する。インターネットコントロールメッセージプロトコル（ＩＣＭＰ）エコーパケットは、存在する複数のアクティブインターフェースを介して、ユーザーによって定義された任意のパブリックＩＰアドレス（例えば、www.google.com）に同時に送信される。パブリックＩＰアドレスを有する目標は、エコー応答（echo reply）をアクティブ物理インターフェース２０８に送り返す。提案のシステムは、送られたＩＣＭＰエコーパケットと、受信したＩＣＭＰエコー応答パケットとの時間差、すなわち、アクティブインターフェース用のラウンドトリップタイム（ＲＴＴ：往復遅延時間）を測定し、ネットワーク状態を推定する。より大きな時間差は、劣悪なネットワーク状態を意味する。システムは、エコーパケットが固定の時間間隔（設定可能）で送られるようにするタイマーを保持している。

また、本発明の実施形態では、提案のシステムは、トランスポートヘッダー（ＴＣＰ）２１６の統計値を分析し、トランスポートヘッダー２１６およびＩＣＭＰ探索パケットの双方から得られた平均ＲＴＴを取る。

本開示に示されたような提案のシステムの別の実施形態では、システムは、存在するインターフェースの物理層２１２およびデータリンク層２１０内での如何なる変更も実行することなく、ネットワークドライバーモジュール２０４によって、存在するアクティブ通信インターフェース（有線および無線）の利用可能帯域を合算することによって、システムの帯域を大幅に増加させてもよい。同時に、システムは、アクティブ物理インターフェース２０８のそれぞれに関連付けられたチャンネル／ネットワーク状態を推定する。システムは、最終目標または通信リンクの末端（end）システムを含む任意のノードにおける対応物（counterpart）または任意の対応するモジュールを必要としない。システムは、ＴＣＰ（Transmission Control Protocol：伝送制御プロトコル）およびＵＤＰ（User Datagram Protocol）のような任意のトランスポート層プロトコル用に用いることができる。重要なことは、システムは、如何なるサービスレベル同意（agreement）およびプロキシサポートも要求しないことである。システムは、適応性の帯域集約を実行することができる。

本発明の特定の実施形態では、ネットワーク推定の結果は、複数のインターフェースの伝送キュー長を変更する。提案のシステムは、劣悪なネットワーク状態におけるパケット損失を低減する。このシステムは、アクティブインターフェース２０８のそれぞれ用の適切な伝送キュー長を適応させるよう構成されている。もし、インターフェースに関連付けられたネットワーク状態が、上述のネットワーク推定方法に基づいて、劣悪であるならば、システムは、インターフェースの伝送キュー長（ｔｌ）を減少させる。システムは、所定の時間間隔（現在の間隔の１つ前の時間間隔）によって決定された以前の帯域（ｂｗ）および決定された現在の帯域に対する、初期設定の伝送キュー長と、現在の伝送キュー長との比例する比を保持する。

インターフェースの伝送キュー長は、所定の時間間隔で帯域推定モジュールによって決定される現在の帯域の値と、以前の帯域の値との比に従って、変化させられる。特に、以前の帯域と、現在の帯域との比（Ｒ）は、比例定数であり、１０より大きく、カットオフ飽和値よりも小さく、システムによって異なる定数“Ｋ”で乗算される。アクティブ物理インターフェース用の決定用数式は、以下のように与えられる。
新しいｔｘキュー長＝ｃｅｉｌ［（初期設定のｔｘキュー長）＊Ｒ＊Ｋ］
ここで、Ｒ＝ｃｅｉｌ［現在の帯域／以前の帯域］、１０≦Ｋ≦しきい値（カットオフ飽和値）であり、しきい値を超えると（crossing the threshold）、パケット損失の低減に如何なる影響も与えない。

ネットワークドライバーモジュール２０４は、探索パケットメカニズムを用いて、通信に含まれるアクティブインターフェースのそれぞれに関連付けられた有効ネットワークチャンネル帯域比を推定する。有効ネットワークチャンネル帯域は、所定の時間間隔に基づく、以前の帯域と、現在の帯域との比である。有効ネットワークは、対応するインターフェースの通信チャンネルの利用可能な帯域に適合するよう、伝送キュー長を動的に適応させる。

以上の本開示は、本発明の様々な実施形態を参照して示されている。本発明が属する分野および技術における当業者であれば、本発明の原理、概念および範囲から有意に離れることなく、示された構造および動作の方法における置換および変更が実行可能であることを十分に理解できるであろう。

Claims (17)

1. 複数のインターフェースを有する通信ネットワークにおけるデータパケット損失を低減する方法であって、
   仮想物理インターフェースを登録するネットワークドライバーモジュールを生成する工程と、
   前記インターフェースのそれぞれに関連付けられ、ユーザー入力に対応する複数の特性を取得する工程と、
   事前に定められた設定可能な時間間隔に基づいて、アクティブインターフェースのそれぞれに関連付けられた通信チャンネルの以前の帯域および現在の帯域を決定する工程と、
   前記通信に含まれる前記アクティブインターフェースに関連付けられた前記以前の時間間隔の帯域と、前記現在の帯域との比として特徴づけられる有効ネットワークチャンネル帯域比を推定する工程と、
   少なくとも１つの適応性の伝送キューを前記アクティブインターフェースのそれぞれに割り当てる工程と、
   前記アクティブインターフェースの現在の伝送キュー長を決定し、前記アクティブインターフェースの初期設定の伝送キュー長と、前記現在の伝送キュー長との比によって特徴づけられる有効伝送キュー長比を導出する工程と、
   前記有効伝送キュー長比が前記有効ネットワークチャンネル帯域比に比例し、比例定数が所定のしきい値と等しくなるよう前記アクティブインターフェース用の前記伝送キュー長を動的に設定する工程と、
   ネットワークルーティングコンポーネントによる遮断なく、さらに、目標に関連付けられた前記アクティブインターフェースから送られたデータ状況およびパケット損失フィードバック状況を検索することなく、前記アクティブインターフェースに適応的に変更されたデータレートで、前記データパケットを伝送する工程と、を備えることを特徴とする方法。
2. 前記有効ネットワークチャンネル帯域は、前記以前の帯域と、前記現在の帯域との比であり、前記有効伝送キュー長比は、前記初期設定の伝送キュー長と、前記現在の伝送キュー長との比であり、前記比のそれぞれは、動的に変化し、互いに比例関係にある請求項１に記載の方法。
3. 前記ネットワークドライバーモジュールは、所定のＩＣＰＭエコーリクエストパケットを用いて、前記通信に含まれる前記アクティブインターフェースに関連づけられた前記有効ネットワーク帯域比を推定する請求項１に記載の方法。
4. 前記有効ネットワークチャンネル帯域比および前記有効伝送キュー長比は、前記通信チャンネルの前記パケット損失を低減し、スループットを向上させるため、前記伝送キュー長を動的に適応させるよう促進する請求項１に記載の方法。
5. 前記比例定数は、ネットワークによって異なり、最大ネットワーク帯域に基づいて設定され、固定された最小値を有する請求項１に記載の方法。
6. 前記複数のインターフェースを介した前記データパケットの伝送は、前記目標のシステムにおいて主導される１つ以上の対応コンポーネントおよび対応するモジュールの介入を受け付けないよう構成されている請求項１に記載の方法。
7. 前記データパケットを伝送する工程は、前記対応するアクティブインターフェースから、１つ以上の前記パケット損失フィードバック状況を受信する必要がないよう構成されている請求項１に記載の方法。
8. 前記方法は、伝送制御プロトコル（ＴＣＰ）のウィンドウサイズのような特定のトランスポートプロトコルの如何なる特定の特性も必要とせず、任意のトランスポートプロトコルに適用可能である請求項１に記載の方法。
9. 前記方法は、トランスポートプロトコルの１つ以上の種類のレンダリングにおける柔軟性を提供するクロスレイヤー通信に適応される請求項１に記載の方法。
10. 複数のインターフェースを有する通信ネットワークにおけるデータパケットの損失を低減するシステムであって、
    複数のアクティブインターフェースの帯域を集約し、前記通信に含まれる前記アクティブインターフェースのそれぞれに関連付けられた有効ネットワークチャンネル帯域比を推定する少なくとも１つのネットワークドライバーモジュールと、
    複数のユーザー定義の入力を受信する、前記ネットワークドライバーモジュールのユーザー空間コンポーネントと、
    初期設定のキュー長および前記アクティブインターフェースに関連付けられた適応性のキュー長を有する伝送キューと、
    実際の物理インターフェースの対応するネットワークドライバーをカプセル化するよう構成されたネットワークドライバーモジュールと、
    前記インターフェースに関連付けられた帯域の利用可能度に従って、前記複数のアクティブインターフェースの前記伝送キュー長を変化させるよう構成された少なくとも２つの物理インターフェースと、を備え、
    前記少なくとも１つのネットワークモジュールは、帯域集約部と、帯域推定部と、伝送キュー適応部とを備えることを特徴とするシステム。
11. 前記有効ネットワークチャンネル帯域は、以前の帯域と、現在の帯域との比であり、前記有効伝送キュー長比は、前記初期設定の伝送キュー長と、現在の伝送キュー長との比であり、前記比のそれぞれは、動的に変化し、アクティブインターフェースに受信される前記対応するデータパケットに固有である請求項１０に記載のシステム。
12. 前記ネットワークドライバーモジュールは、ＩＣＰＭエコーリクエストパケットを用いて、前記通信に含まれる前記アクティブインターフェースに関連づけられた前記有効ネットワーク帯域比を推定する請求項１０に記載のシステム。
13. 前記有効ネットワークチャンネル帯域比および前記有効伝送キュー長比は、前記対応するインターフェースの前記通信チャンネルの前記利用可能な帯域に適合させるため、前記伝送キュー長を適応させるよう促進する請求項１０に記載のシステム。
14. 前記複数のインターフェースを介した前記データパケットの同時伝送は、目標のシステムにおいて主導される１つ以上の対応コンポーネントおよび対応するモジュールの介入を受け付けないよう適応されている請求項１０に記載のシステム。
15. 前記データパケットの伝送は、前記対応するアクティブインターフェースから、１つ以上のパケット損失フィードバック状況を受信する必要がないよう構成されている請求項１０に記載のシステム。
16. 前記システムは、伝送制御プロトコル（ＴＣＰ）のウィンドウサイズのような特定のトランスポートプロトコルの如何なる特定の特性も必要とせず、任意のトランスポートプロトコルに適用可能である請求項１０に記載のシステム。
17. 前記システムは、トランスポートプロトコルの１つ以上のタイプのレンダリングにおける柔軟性を提供するクロスレイヤー通信に適応する請求項１０に記載のシステム。

Images