JP2006246466A - 通信ネットワーク上でデータを伝送する方法、データ・ネットワーク上で伝送するためにデータを処理する方法、コンピュータ読み取り可能な命令の組を含む媒体または波形、および集積回路チップ - Google Patents

Abstract

【課題】ビデオ／オーディオ伝送用混雑状態フィードバック付きマルチチャンネルTCP接続。
【解決手段】通信ネットワーク上でデータを伝送する方法は混雑度のフィードバックを有する。方法はテレビ会議プログラムなどの、複数のＴＣＰ接続を開設する送信アプリケーションを含む。送信アプリケーションはデータ・パケットをカプセル化モジュールに提供し、これが各データ・パケットにＴＣＰヘッダを添付する。各カプセル化データ・パケットに対し、パケット送信モジュールがパケット伝送のために複数のＴＣＰ接続の内最も混雑の少ないものを選択する。パケット取り込みライブラリはＴＣＰドライバの前のネットワーク・スタックに入り込み、複数のＴＣＰ接続の各々における混雑度を反映する利用可能な枠サイズを計算する。モニタ・モジュールが複数のＴＣＰ接続をモニタし、混雑情報をパケット送信モジュールに提供する。
【選択図】図１

Description

本発明は一般的にインターネットをはさんだ情報の伝送に関連し、より具体的にはインターネットをはさんで、ならびにネットワークおよびネットワーク化されたシステム内において高速かつリアルタイムで情報を伝送する方法、システム、および装置に関連する。

インターネットに基づくアプリケーションの多くは有効に実装するためにデータのリアルタイムの伝送および交換を必要とする。例えば、Ｈ．３２３インターネット・テレビ会議プロトコルは高速かつリアルタイムのデータ交換を提供し、現場および遠隔設定の参加者にビデオおよびオーディオ・データを呈示する。必要なリアルタイムのデータ交換の利点を実現するために、データは通常信頼性のないユーザ・データグラム・プロトコル／インターネット・プロトコル（ＵＤＰ／ＩＰ、または簡単にＵＤＰ）上で伝送される。信頼性のある伝送制御プロトコル（ＴＣＰ，またＴＣＰ／ＩＰ）の代わりに信頼性のないＵＤＰを使用する利点は主に信頼性のあるデータ伝送を必要としないリアルタイムのアプリケーションにとっての速度の利点である。ＵＤＰはパケット応答、パケット検証、パケット再伝送要求、等々を伝送しないのでオーバーヘッドがより少ない。リアルタイムのネディア伝送および再生において、このような伝送および検証処理はシステムの運転にマイナスの影響を与える。

ＴＣＰは現在のインターネットで支配的なトランスポート層のプロトコルである。ＴＣＰはすべてのデータが受信され、正しい順序で受信され、かつ受信データは伝送されたデータと一貫性があることを確実にし、極めて高い信頼性の度合いを維持している。多くのアプリケーションにおいて、このような信頼性は有効なデータ伝送の上で最優先事項である。

ＴＣＰはほとんどの産業用および消費者用ファイアウォールにより広く受け入れられているので、ビデオおよびオーディオのストリームがＴＣＰ接続上で送れることが望ましい。またＴＣＰのストリームはＵＤＰのストリームに比べネットワーク・セキュリティに対しても都合が良いことが知られている。

しかし、現在のＴＣＰ実装はビデオおよびオーディオのストリームを配信するために理想的に適してはいないことがはっきりと認められている。例えば、ＴＣＰ接続はデータの配信において相当な遅延やスループットの変動をもたらし得る。ＴＣＰの設計目標は、リアルタイムで一定流量のネットワーク接続ではなく、信頼性のあるネットワーク接続を提供することにある。従って、典型的なＴＣＰ接続のスループットはネットワークのパケット配信状況によって変動する。

米国特許出願公開第2003/0210711号明細書

板ばさみとなる問題は、オーディオやビデオを配信するのにＵＤＰを使用すると、ファイアウォールで阻止される可能性が高い反面、オーディオやビデオを配信するのにＴＣＰを使用すると、ビデオおよびオーディオのスッタをもたらすことである。ビデオおよびオーディオのスタッタはデータ・パケットが行方不明になると起こる。ＴＣＰ受信側は行方不明のパケットが再送信され受信されるまで、後続パケットを保持して待っている。行方不明のパケットが再送信され、受信されると保持されていたパケットはすべて一度にアプリケーションに配信される。これがオーディオおよびビデオのストリームの配信チャンネルとしてＴＣＰを使用した場合に起こる失速‐早送り症状の原因となる。

上記に鑑み、必要なものはＴＣＰ接続においてパケットが行方不明になった時失速‐早送り症状の危険を最小限にし、または取り除き、既存のファイアウォールを通してテレビ会議データを通信する方法およびシステムである。

おおまかに言って、本発明はパケットが行方不明になった場合の失速‐早送り症状の危険を削減するためにＴＣＰ／ＩＰドライバからネットワークの混雑状態のフィードバックを有する複数のＴＣＰ接続を用いることによってこれらのニーズを満足する。本発明はシステム、方法、またはコンピュータ読み取り可能な媒体を含み、数々の方法で実施することができる。本発明の実施形態がいくつか以下に説明される。

一実施形態で、通信ネットワーク上でデータを伝送する方法が提供される。方法は複数の伝送制御プロトコル（ＴＣＰ）接続を開設することを含む。各ＴＣＰ接続は伝送すべきデータを有するアプリケーションにより開設される。方法はさらにデータを伝送するためにデータ・パケットを形成し、データ・パケットにＴＣＰヘッダを添付することを含む。方法は次にデータ・パケットを伝送するためにＴＣＰ接続の１つを選択し、選択されたＴＣＰ接続を通してデータ・パケットを伝送する方法を提供する。

別の実施形態で、データ・ネットワーク上で伝送するデータを処理する方法が提供される。方法はデータ伝送のために複数の伝送制御プロトコル（ＴＣＰ）接続を開設し、データ・ネットワーク上で伝送するデータの複数の初期データ・パケットを形成する方法を提供する。初期データ・パケットの各々はＴＣＰヘッダでカプセル化され、複数の伝送データ・パケットの１つとなる。次に方法は伝送データ・パケットの各々を伝送するためにＴＣＰ接続の１つを選択する方法を提供する。各伝送データ・パケットはデータ・ネットワークを通して伝送するために、その選択されたＴＣＰ接続を通してネットワーク・ドライバに送信される。各伝送データ・パケットはＴＣＰ接続各々の混雑状態を判断するために調べられる。

さらなる実施形態で、通信ネットワーク上でデータを伝送するためのプログラム命令を有するコンピュータ読み取り可能な媒体が提供される。コンピュータ読み取り可能な媒体は複数の伝送制御プロトコル（ＴＣＰ）接続を開設するためのプログラム命令を含む。ＴＣＰ接続の各々は伝送すべきデータを有するアプリケーションにより開設される。コンピュータ読み取り可能な媒体はさらにデータを伝送するためにデータ・パケットを形成するプログラム命令およびデータ・パケットにＴＣＰヘッダを添付するためのプログラム命令を含む。加えてコンピュータ読み取り可能な媒体はデータ・パケットを伝送するためにＴＣＰ接続の１つを選択するためのプログラム命令、および選択されたＴＣＰ接続上でデータ・パケットを伝送するためのプログラム命令を含む。

さらに別の実施形態で、コンピュータ・システム間でデータ交換を確立する集積回路チップが提供される。集積回路チップはデータ・パケットを伝送するために複数の伝送制御プロトコル（ＴＣＰ）接続を開設するためのロジックを提供する。また伝送用のオーディオおよびビデオを含むデータ・パケットを形成するロジックも含まれる。集積回路チップはさらにデータ・パケットにＴＣＰヘッダを添付するロジック、および添付ＴＣＰヘッダを有するデータ・パケットを伝送するためにＴＣＰ接続の１つを選択するロジックも含む。最後に、集積回路チップは添付ＴＣＰヘッダを有するデータ・パケットを選択されたＴＣＰ接続上で伝送するロジックを含む。

本発明の利点は発明の原理を例示する添付図面と併せて以下の詳細な説明により明らかにされる。

好ましい実施形態の詳細な説明
複数のＴＣＰ接続が開設され、ＴＣＰ／ＩＰドライバから混雑状態がフィードバックされる発明が提供される。以下の説明で本発明の充分な理解を提供するために多数の具体的な詳細が記述される。しかし本発明はこれら具体的な詳細の一部またはすべてなしでも実施できることが当業者には明らかであろう。その他、本発明を不必要に不明瞭にしないために周知のプロセス操作は詳しく説明されていない。

概要として、本発明の実施形態は一般的にビデオおよびオーディオ・データを含むデータ伝送用に混雑状態のフィードバックを有する複数のＴＣＰ接続を提供している。例えば、テレビ会議アプリケーションが起動されると、アプリケーションは複数のＴＣＰ接続を開設し、パケット取り込みライブラリを用いてＴＣＰドライバ・スタックの下のパケット活動をモニタする。パケット取り込みライブラリは各接続に対するＴＣＰの枠を計算する機能を提供する。

送信側でＴＣＰの利用可能な枠のサイズ（使用できる枠サイズとしても知られる）が減少すると、一般的に接続が失速していることを示している。一般的に認められ、本明細書で使用されるＴＣＰの利用可能な枠は確認応答されたシーケンス番号に関連している。データ・パケットは一般的に規定範囲内にあるよう定義される、割り当てられたまたは決められたシーケンス番号（ＳＥＱ）および確認応答番号（ＡＣＫ）が付いて伝送される。ＳＥＱが範囲の上限に到達すると番号付けは範囲の下限から再開始される。利用可能な枠サイズは枠サイズにおける総バイト数からまだ確認応答されないバイト数を引いて決められる。確認未応答のバイト数が増えるにつれ、利用可能な枠は減少し、失速接続の可能性を示す。行方不明のパケットがあり、受信側が再送信を要求したか、パケットの再送信を待っているかもしれない。そのようなＴＣＰ接続に遭遇した場合、受信側で失速している可能性が大きいので送信側はさらにビデオおよびオーディオ・データを送信するためにそのチャンネルを使用することは避けるべきである。その代わりに最大の利用可能な枠を有するＴＣＰ接続を選択して次のビデオまたはオーディオ・パケットを送るべきである。このような接続は受信側が行方不明のパケットを待ち、または送信側から再送信パケットを待っていることのない、障害のないＴＣＰ接続を表しているはずである。

本発明の実施形態によると、送信側が送りたいパケットがある場合、送信側は利用可能なＴＣＰ接続を評価し、ＴＣＰの利用可能な枠が最も大きいＴＣＰ接続を選択する。パケットが伝送中行方不明になった場合、続くパケットは失速しない。そのような後続パケットはその他のＴＣＰ接続のいずれか経由で伝送される。すべてのＴＣＰ接続が失速する可能性は非常に低い。

図１は本発明の一実施形態によりオーディオおよびビデオ・パケットの配信用に混雑状態のフィードバックを有するマルチチャンネルＴＣＰ接続のハイレベル・システム図100である。送信側のアプリケーション102がオーディオおよびビデオ・データのデータ・パケット伝送を可能にするために起動、実行、または何らかの形で活性化すると、送信側のアプリケーション102は複数のＴＣＰ接続104を開設する。一実施形態で、ＴＣＰ接続104経由で伝送されるデータ・パケットはパケット取り込みモジュール106で調べられ、これは１つより多く複数までのＴＣＰ接続104の各々におけるデータ・パケットに対する利用可能な枠サイズを判断する。本発明の一実施形態で、パケット取り込みモジュール106は各ＴＣＰ接続104の利用可能な枠サイズを計算し、送信側のアプリケーション102が最適なＴＣＰ接続104をデータ伝送用に選ぶことを可能にする。

送信側のアプリケーション102はオーディオおよびビデオ・データを伝送またはストリーミングするのに使用する任意のアプリケーションであり得ることが理解されよう。例にはWebEx Meetingなどインターネットのテレビ会議アプリケーションが含まれる。

周知のように、典型的なインターネットのテレビ会議アプリケーションはオーディオおよびビデオ・データを交換するために複数のＵＤＰ接続を開設するように構成される。「背景」で説明した通り、ＵＤＰはオーディオおよびビデオ・データには最適であるが、現代のファイアウォール環境はネットワークを越えてまたはインターネット上でＵＤＰを伝送する能力を排除とまでは行かずとも非常に限定している。2003年10月8日に出願され、「コネクションレスＴＣＰ／ＩＰデータ交換」と題する同時係属中の米国特許出願10/681,732号では、例えばＵＤＰデータ・パケットのようなデータ・パケットが発明的なＴＣＰヘッダでカプセル化され、ＴＣＰ接続経由でカプセル化されたパケットの伝送を可能にする方法およびシステムが記載されている。ＴＣＰ接続経由でネットワークを越え、またはインターネット上で伝送されるデータ・パケットは発明的なＴＣＰヘッダを取り除く受信アプリケーションによって受信された上、元のデータ・パケットとして処理される。本発明と同じ譲受人に譲渡される同時係属中の米国特許出願 10/681,732号は引用によりあらゆる目的用に本明細書に組み込まれる。

周知のように、ＴＣＰ接続は基本的にＩＰアドレスおよびＩＰポートの対によって定義される。すなわち、送信側のＩＰアドレスとポート、および受信側のＩＰアドレスおよびポートがデータ・パケットの交換を可能にする接続、チャンネル、または経路（以後経路と呼ばれる）を定義する。受信側は例えば送信側から複数のデータ・パケットを受信し、これらの受信されたパケットを受信アプリケーションに転送し、次に受信データを組み立て配信して伝送通信をテキスト、オーディオ、ビデオ等々、としてもたらすことができる。

図２はＴＣＰデータ伝送の経路を図式的に示す。送信側のＴＣＰ・ＩＰアドレスおよびポート120がデータ伝送の送り元を定義し、受信側ＴＣＰ・ＩＰアドレスおよびポート122がデータ伝送の送り先を定義する。例えばオーディオ・データ、テキスト、画像、ビデオ・データ等々、任意の種類のデータがデータ・パケットにフォーマットされ、送信側ＴＣＰ・ＩＰアドレスおよびポート120から受信側ＴＣＰ・ＩＰアドレスおよびポート122に伝送される。一旦受信側ＴＣＰ・ＩＰアドレスおよびポート122に受信されると、個々のデータ・パケットが伝送されたオーディオ・データ、テキスト、画像、ビデオ・データ等々、として確認、解凍、組み立て、および解釈される。従って、しばしば異なった種類のデータを含む複数のデータ・パケットが送信側ＴＣＰ・ＩＰアドレスおよびポート120で処理の上、受信側ＴＣＰ・ＩＰアドレスおよびポート122に伝送され、次に確認され、組み立てられ、適当な解釈アプリケーション等々に転送される。

ＴＣＰプロトコルに従い、受信データ・パケットは確認され、すべてのデータが受信されたこと、すべてのデータが正しい順序で受信されたこと、および受信されたデータは正確で、伝送されたデータと一致していることを確かめる。上述のように、このプロセスは、例えばパケットが落とされことにより受信側がタイムアウトになり、再送信の要請、パケットの再送信などがあると、かなりの遅延をもたらすこともあり得る。

本発明の実施形態は通常単一のＴＣＰ接続で運ばれるようなデータ交換に対し複数のＴＣＰ接続を提供する。言い換えれば、本発明の実施形態は複数のＴＣＰ接続を開設することによりデータ交換に対し複数の経路、路線、チャンネル等々、を提供する。複数のＴＣＰ接続はオーディオおよびビデオ・データの伝送に良く適しており、前述の失速‐早送り症状を最小限にし、または取り除く。本発明の実施形態による複数のＴＣＰ接続はデータ伝送の速度は速めないことが理解されよう。この理由の１つは複数のＴＣＰ接続を操作することはシステムのオーバーヘッドを増加させるため、より多くのシステム・リソースを要するからである。従って全体的なスループットは増加するということではなく、一定なデータ伝送が維持されるわけである。

図３はＴＣＰデータ伝送の複数の路線または経路を提供する複数のＴＣＰ接続を図式的に示す。送信側ＴＣＰ・ＩＰアドレスおよびポート130-1 130-5はデータ伝送の送り元を定義し、受信側ＴＣＰ・ＩＰアドレスおよびポート132はデータ伝送の 送り先を定義する。周知のように、送信アプリケーションは各ＴＣＰ接続に対し異なったまたは固有のＴＣＰ・ＩＰアドレスおよびポート130-1 130-5を、各々同じ送り先または受信側ＴＣＰ・ＩＰアドレスおよびポート132を有するように開設することができ、それにより固有のＴＣＰ接続を定義することができる。一実施形態で、受信側ＴＣＰ・ＩＰアドレスおよびポートはＨＴＴＰ伝送用でＴＣＰトンネリング・データに使用されるポート80を含む。例えばオーディオ・データ、ビデオ・データ、市場価格更新データ等々、信頼性のある伝送を必要としない任意の種類のデータはデータ・パケットにフォーマットされ送信側ＴＣＰ・ＩＰアドレスおよびポート130-1 130-5から受信側ＴＣＰ・ＩＰアドレスおよびポート132に送信される。一旦受信側ＴＣＰ・ＩＰアドレスおよびポート132に受信されると、データ・パケットが伝送された接続の数に関係なく個々のデータ・パケットは再度確認され、組み立てられ、伝送されたオーディオ・データ、テキスト、画像、ビデオ・データ等々として解釈される。

図３に示すような複数のＴＣＰ接続はリアルタイムのオーディオおよびビデオ送信の質をかなり向上させるデータの定流の可能性を高める。パケットが１つのＴＣＰ接続で落とされ、タイムアウト、再送信の要請、再送信等々で伝送を失速させても、残りのＴＣＰ接続がデータ・パケットの伝送を続けることができる。一実施形態で、ＴＣＰ接続の数は２つのＴＣＰ接続から１０個のＴＣＰ接続の範囲であり得る。一実施形態で、ＴＣＰ接続の数は少なくとも５つのＴＣＰ接続である。

本発明の実施形態はオーディオおよびビデオ・データなど定流のリアルタイム・データを伝送するために理想的に実施される。もちろん本発明がデータ伝送を非常に向上させる状況は他に多数ある。図４は本発明の一実施形態によるデータ伝送用の送信側操作の図式150である。例えばテレビ会議アプリケーションなどの送信側アプリケーション152が伝送用にデータを提供する。伝送用のデータはリアルタイムのオーディオおよびビデオ・データをふくむかも知れず、送信側アプリケーション152は通常データ伝送用にＴＣＰおよびＵＤＰ双方の接続を複数開設するしかし本発明の実施形態に従えば、データは最初にカプセル化モジュール154に送られる。カブセル化モジュール154はデータ・パケットを標準ＴＣＰプロトコルに従いＴＣＰヘッダ付きのＴＣＰパケットとしてパッケージする。言い換えれば、データは送信側アプリケーションが通常ＵＤＰ接続上でデータを伝送する場合でもＴＣＰデータ・パケットとしてパッケージされる。一実施形態でＴＣＰヘッダはステートフルで、ＴＣＰプロトコルに完全に遵守している。

2004年11月16日に出願され、「１つのシミュレーションされたステートフルなＴＣＰを用いてデータをトンネリングする方法および装置」と題する同時係属中の米国特許出願10/990,274号において、例えばＵＤＰデータ・パケットなどのデータ・パケットがファイアウォールを通過するために１つのＨＴＴＰポート経由でトンネリングされる方法およびシステムが記載される。本発明の実施形態は同時係属中の米国特許出願10/990,274号に記載される方法およびシステムをさらに拡張し、以下により詳細に記述される如く、完全にＴＣＰに遵守した複数のＴＣＰ接続を提供することができる。本発明と同じ譲受人に譲渡される同時係属中の米国特許出願10/990,274号は引用によりあらゆる目的用に本明細書に組み込まれる。

図４に戻り、一旦データがカプセル化モジュール154でカプセル化されると、データはパケット送信モジュール156で処理される。発明の一実施形態でパケット送信モジュール156は各データ・パケットを選択し複数のＴＣＰ接続158の内の１つに送信する。図式150においてＴＣＰ接続158は、本発明の実施形態に従いデータ伝送用に開設された複数のＴＣＰ接続を表す複数のＴＣＰ接続クラス160を含む。データ・パケットを送信すべき最良のＴＣＰ接続を判断するために、各ＴＣＰ接続クラス160におけるデータ・パケットの「キュー」をモニタするモニタ・モジュール162が提供され、これはさらに詳細に後述する。モニタ・モジュール162はパケット送信モジュール156にデータ・キュー情報を提供し、次にパケット送信モジュール156はデータ・パケットを伝送用に１つのＴＣＰ接続クラスに送信する。

本発明の一実施形態で、モニタ・モジュール162は複数のＴＣＰ接続クラス160の各々において伝送される各データ・パケットに対する利用可能な枠を調べることにより各ＴＣＰ接続クラス160のデータ・パケット・キューを評価する。標準ＴＣＰプロトコルに従い、利用可能な枠はデータ・フローを測るために使用することができる。利用可能な枠が減少することは、データ損失の可能性、またはデータ伝送の遅延を意味する。一実施形態において、利用可能な枠がゼロまで落ちると、データ伝送は失速し、 送信側はデータ・パケットの送信を停止しなければならず、行方不明または落ちこぼれたパケットが回収、再送信、確認等々されるまでデータ・フローは基本的に停止する。

本発明の実施形態は各ＴＣＰ接続クラス160から各データ・パケットの利用可能な枠のサイズを判断またはモニタするためにパケット取り込みライブラリを利用する。本発明の実施形態によれば、パケット取り込みライブラリは送信システムのＴＣＰスタックに入り込み、ＴＣＰドライバ下の利用可能な枠をモニタする。標準のシステム呼び出しにより各データ・パケットをＴＣＰ接続クラス160各々からネットワーク・スタックおよびＴＣＰドライバに伝送し、これが次にデータ・パケットをネットワーク、インターネット等々に伝送する。発明の一実施形態で、パケット取り込みライブラリはデータ・パケットを伝送する際ＴＣＰ接続クラス160およびＴＣＰドライバの後に各データ・パケット、具体的には各データ・パケットの利用可能な枠のサイズ、を評価する。パケット取り込みライブラリを用いてデータ・パケットを調べることにより、本発明の実施形態は標準ＴＣＰプロトコルに従い各データ・パケットのＳＥＱおよびＡＣＫフィールドを用い、かつ上述の如く各ＴＣＰ接続クラス160に対する利用可能な枠のサイズを計算する。このようにパケット取り込みライブラリは各ＴＣＰ接続クラス160におけるデータ・パケットの利用可能な枠のサイズをモニタすることができる。利用可能な枠サイズはそこで複数のＴＣＰ接続クラス160の各々に現れるキューを計算するために用いられる。一実施形態で、小さく、かつ減少する利用可能な枠のサイズはキューが伸びていることを示す。一実施形態でモニタ・モジュール162は複数のＴＣＰ接続クラス160の各々のキューを評価し、パケット送信モジュール156にその情報を提供し、これが次に最小のキューを有するＴＣＰ接続クラス160にパケットを送信する。

図５は本発明の一実施形態によりパケット取り込みライブラリ164の機能を示す。複数のＴＣＰ接続クラス160の各々はデータ・パケットをネットワーク・スタックに送信し、そこでＴＣＰドライバ166がデータ・パケットをインターネット168に伝送する。パケット取り込みライブラリ（ＰＣａｐライブラリ）164はネットワーク・スタックに入り込み、ＴＣＰ接続クラス160各々から各データ・パケットに対する利用可能な枠のサイズを取得する。発明の一実施形態で、取得された利用可能な枠のサイズは複数のＴＣＰ接続クラス160の各々に対するもので、それにより複数のＴＣＰ接続クラス160の各々に対しキューの目安が提供される。モニタ・モジュール162（図４参照）はそこで複数のＴＣＰ接続クラスの各々に対する枠のサイズまたはキューをモニタし、その情報をパケット送信モジュール156（図４参照）に提供することができ、これが次に最小のキューを有するＴＣＰ接続クラス160に各データ・パケットを送信することができる。

図６は本発明の一実施形態により複数のＴＣＰチャンネルを利用したデータ伝送の方法操作を示すフローチャート図200である。方法は操作202で始まり、ここで複数のＴＣＰ接続が開設される。発明の一実施形態で送信側アプリケーションは複数のＴＣＰ接続クラスを開設し、データを伝送するために複数のＴＣＰ接続を提供する。ＴＣＰ接続クラスは１つのＴＣＰ接続を開設するのに用いられる周知のプログラミング操作に従って開設される。

方法は操作204で継続され、ここでデータ・パケットがカプセル化モジュールに受信され、次に操作206で受信されたデータ・パケットがＴＣＰデータ・パケットとしてカプセル化される。一実施形態で、カプセル化モジュールは伝送用に標準のステートフルなＴＣＰヘッダを データ・パケットに添付する。通常ＵＤＰパケットとして伝送されるデータ・パケットは恭順ＴＣＰヘッダでカプセル化されることにより、ＵＤＰデータを有するＴＣＰパケットが伝送用に有効に作成される。一実施形態で、受信側の対応するモジュールがＴＣＰプロトコルに従い伝送処理を行なった後、データ・パケットを解凍し、ＵＤＰとしてデータを処理する。

操作208で複数のＴＣＰ接続は評価され、複数の接続中最も混雑の少ないＴＣＰ接続が判断される。一実施形態で、最も混雑の少ないＴＣＰ接続は最大の利用可能な枠を有するＴＣＰ接続である。上述のように、利用可能な枠サイズは複数のＴＣＰ接続の各々により伝送されるデータ・パケットのキューを評価するために用いられる。一実施形態で、第１の伝送は「空のキュー」、つまり伝送中のパケット、確認を待つパケット等々、がないことを示す。この場合、本発明の一実施形態は複数のＴＣＰ接続の各々に対するデータ・パケットの順次または「連続」の割り当てを提供する。別の実施形態で、複数のＴＣＰ接続の各々のキュー・サイズが同一であると判断された場合、データ・パケットは順次または連続に割り当てられる。しかし通常の状況では、最も混雑か少ないＴＣＰ接続を示唆する最大の利用可能な枠サイズ、または最小のキューを有する接続クラスにデータ・パケットが割り当てられる。

本発明の別の実施形態で、テレビ会議アプリケーションで伝送されるデータ・パケットなどのネットワーク・トラフィックに対する混雑フィードバックがネットワーク・ルータによって提供される。一例はパケットのパスにルータによって送信されるＩＣＭＰ（インターネット制御メッセージ・プロトコル）。である。ＩＣＭＰプロトコルの考察は本開示の範囲を超える。

操作210でデータ・パケットは伝送用に最も混雑の少ないＴＣＰ接続に送信される。

方法は次に決定ブロック212に進み、ここでさらにデータ・パケットがあるか判断される。決定ブロック212は方法においてすべてのデータ・パケットを送信するためのループを作成する。データ・パケットが引き続き伝送用に提供される限り、決定ブロック212は「はい」となり、方法は上述の如き処理のためにカプセル化モジュールにデータ・パケットを受信する操作204に戻る。データ・パケットが残っておらずデータ伝送が完了すると、決定ブロック212は「いいえ」となり、方法は終了する。

本発明の実施形態は標準のプログラミングを実施して送信側アプリケーションにより複数のＴＣＰ接続を作成の上、複数のＴＣＰ接続各々の利用可能な枠サイズをモニタし、最大の利用可能な枠サイズを有するＴＣＰ接続にデータ・パケットを送信する。周知のように、同じ結果を得るために広範囲の異なったプログラミング言語、操作、および方法を実施することができる。発明の一実施形態を例示するために典型的なプログラミング・アルゴリズムが提供されるが限定的または排他的とみなされるものではない。一実施形態で本発明を実施するアルゴリズムにSendPacket Functionがある、

上述の如く、本発明の実施形態は同時係属中の米国特許出願10/990,274号に記述される方法およびシステムを拡張するように実施し、完全にＴＣＰに準拠した複数のＴＣＰ接続を提供することができる。本発明の一実施形態で、完全にＴＣＰに準拠し、複数のＴＣＰ接続を有するトンネリングを行なうＴＣＰ接続は以下の操作に従い実施することができる、
送信側モジュールが起動、実行、またはその他の方法で活性化されると、いくつかのＳＹＮおよびＳＹＮ＋ＡＣＫパケットを送信することにより複数の論理的ＴＣＰ接続が確立される。

送信側アプリケーションがパケットを伝送する場合、最小の枠サイズを有する論理的ＴＣＰ接続にパケットを送信する。各パケットは本発明の実施形態で記述されたようにまずカプセル化されるが、使用されるＴＣＰヘッダは同時係属中の米国特許出願10/990,274号に記載される改質または発明的なＴＣＰヘッダである。受信側は送信側にＲＥＳＥＮＤ要求を決して送信しない。ＲＥＳＥＮＤ要求は通常標準的なＴＣＰ実施において送信側にパケットの再送信を要求するために受信側が送信する。

受信側は常にＡＣＫフラグをＰＵＳＨパケットに抱き合わせにする。しかし、すべてのシーケンス番号が確認されるわけではなく、最新のシーケンス番号が確認される。
混雑制御は実施されない。

まとめると、本発明の実施形態はオーディオおよびビデオ・ストリームの配信に理想的に適した、混雑のフィードバックを有する複数のＴＣＰ接続の使用を提供する。送信側アプリケーションが複数のＴＣＰ接続を解説しすべてのデータ・パケットをＴＣＰデータ・パケットとして伝送するためにカプセル化する。パケット取り込みライブラリはＴＣＰドライバ・スタック下のパケット活動をモニタし、複数のＴＣＰ接続の各々におけるデータ・パケット伝送用に利用可能な枠サイズを判断する。モニタ・モジュールがキュー情報をパケット送信モジュールに提供し、これが伝送用のデータ・パケットを複数のＴＣＰ接続の内最も混雑の少ないものに割り当てる。送信側に送信すべきパケットがあると、その利用可能なＴＣＰ接続を調べ、最大の利用可能なＴＣＰの枠サイズを有するものを選択する。これにより、パケット配信中に１つパケットが行方不明になっても後続パケットは失速せず、他のＴＣＰ接続に届く。すべてのＴＣＰ接続が失速する可能性は極めて少ない。

上記実施形態を念頭に、発明はコンピュータ・システムに格納されるデータに関わるコンピュータで実施される操作を用いることができることが理解されよう。これらの操作は物理的な量の物理的な操作を必要とするものである。必ずしもではないが、これらの量は通常格納、転送、組み合わせ、比較およびその他の方法で操作できる電気的または磁気的信号の形を取る。さらに、実行される操作はしばしば生成、特定、判断、または比較などの用語で引き合いにされる。

発明はまたコンピュータ読み取り可能な媒体上のコンピュータ読み取り可能なコードとして実施することができる。コンピュータ読み取り可能な媒体とは後にコンピュータ・システムにより読み取れるデータを格納することができるデータ記憶装置である。コンピュータ読み取り可能な媒体はコンピュータ・コードが包含される電磁搬送波も含む。コンピュータ読み取り可能な媒体の例はハード・ドライブ、ネットワーク接続記憶装置（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、ならびにその他光学的および非光学的データ記憶装置を含む。またコンピュータ読み取り可能な媒体はコンピュータ読み取り可能なコードが分散された形で格納され実行されるようにネットワーク結合のコンピュータ・システム上に分散されても良い。

前記の発明は明瞭な理解を図るためかなり詳細に説明されたが、添付請求項の範囲内で一定の変更および修正を実施することは可能であることは明らかであろう。従って、本実施形態は例示とみなされるもので限定するものではなく、発明はここで叙述された詳細に限定されるものではなく、添付請求項の範囲および同等内容において修正できるものである。請求項において、要素および／あるいは工程は、請求項で明示的に記述されない限り操作の特定な順序を示すものではない。

本発明の一実施形態によりオーディオおよびビデオ・パケットの配信用に混雑状態のフィードバックを有するマルチチャンネルＴＣＰ接続のハイレベル・システム図。 ＴＣＰデータ伝送の路線または経路を図式的に表したもの。 ＴＣＰデータ伝送の複数の路線または経路を提供する複数のＴＣＰ接続を図式的に表したもの。 本発明の一実施形態によるデータ伝送用の送信側操作の図式。 本発明の一実施形態によりパケット取り込みライブラリの機能。 本発明の一実施形態により複数のＴＣＰチャンネルを利用したデータ伝送の方法を示すフローチャート図。

符号の説明

102 送信アプリケーション
104 ＴＣＰ接続
106 パケット取り込みモジュール（接続の枠サイズを計算）
152 送信アプリケーション
154 カプセル化モジュール
156 パケット送信モジュール
158 ＴＣＰ接続
160 ＴＣＰ接続クラス
162 モニタ・モジュール
160 ＴＣＰ接続クラス
166 ＴＣＰドライバ
164 ＰＣａｐライブラリ
202 複数のＴＣＰ接続を開設
204 パケットをカプセル化モジュールに受信
206 パケットをカプセル化
208 複数のＴＣＰ接続の内最も混雑が少ないものを判断
210 最も混雑が少ないＴＣＰ接続にパケットを送信
212 さらにパケットがあるか？

Claims (20)

1. 通信ネットワーク上でデータを伝送する方法であって、
   複数の伝送制御プロトコル（ＴＣＰ）接続を開設するステップ、前記複数のＴＣＰ接続の各々は伝送するデータを有するアプリケーションによって開設されるものであり、
   前記データの伝送のためにデータ・パケットを形成するステップと、
   データ・パケットにＴＣＰヘッダを添付するステップと、
   前記データ・パケットを伝送するために複数のＴＣＰ接続の１つを選択するステップと、
   複数のＴＣＰ接続から選択された接続上でデータ・パケットを伝送するステップ、
   を含む方法。
2. さらに、複数のＴＣＰ接続の各々をモニタして、前記複数のＴＣＰ接続の各々上で伝送されるデータのキューを判断することを含む請求項１に記載される方法。
3. 伝送するデータがオーディオ・データおよびビデオ・データを含む、請求項１に記載される方法。
4. 伝送は複数のＴＣＰ接続から選択された接続上で、ＴＣＰプロトコルに従い行なわれる、請求項１に記載される方法。
5. データを伝送するために複数のＴＣＰ接続の１つを選択することが、複数のＴＣＰ接続の内最小のキューを有する１つを選択することを含む請求項２に記載される方法。
6. 伝送するデータのキューが、複数のＴＣＰ接続の各々を通して伝送されるデータ・パケットの利用可能な枠サイズを調べることにより判断される請求項２に記載される方法。
7. 複数のＴＣＰ接続の各々上で伝送されるデータのキューが、複数のＴＣＰ接続の各々上で伝送されるデータ・パケットの利用可能な枠サイズを調べることにより判断され、利用可能な枠サイズはＴＣＰドライバ下のネットワーク・スタックに各データ・パケットを代行受信して調べられる、請求項２に記載される方法。
8. 伝送されるデータのキューは複数のＴＣＰ接続の各々における混雑度の指標である、請求項２に記載される方法。
9. データ・ネットワーク上で伝送するためにデータを処理する方法で、
   データを伝送するために複数の伝送制御プロトコル（ＴＣＰ）接続を開設するステップ、
   データ・ネットワーク上で伝送するデータの複数の初期データ・パケットを形成するステップと、
   複数の初期データ・パケットの各々をＴＣＰヘッダでカプセル化するステップであって、複数のカプセル化初期データ・パケットは複数の伝送用データ・パケットであるステップと、
   複数の伝送用データ・パケットの各々に対しデータ伝送用の複数のＴＣＰ接続の内１つを選択するステップ、
   データ・ネットワーク上で伝送するために複数の伝送用データ・パケットの各々を複数のＴＣＰ接続の内選択されたものを通して送信するステップと、
   複数のＴＣＰ接続の各々の混雑状態を判断するために複数の伝送用データ・パケットの各々を調べるステップと、
   を含む方法。
10. 請求項９に記載される方法で、さらに、
    複数の伝送用データ・パケットをネットワーク・ドライバの前にネットワーク・スタックに代行受信するステップと、
    複数の伝送用データ・パケットの各々に対し利用可能な枠サイズを判断することで、判断された利用可能な枠サイズは複数のＴＣＰ接続の各々の混雑状態を反映するステップ
    を含む方法。
11. 複数の伝送用データ・パケットの各々に対しデータ伝送用に複数のＴＣＰ接続の内１つを選択する場合、複数のＴＣＰ接続の内最も混雑が少ないものが選択される、請求項９に記載される方法。
12. 請求項１の方法を実施するように適応されたコンピュータ読み取り可能な命令の組を含む媒体または波形。
13. 請求項２の方法を実施するように適応されたコンピュータ読み取り可能な命令の組を含む媒体または波形。
14. 請求項５の方法を実施するように適応されたコンピュータ読み取り可能な命令の組を含む媒体または波形。
15. 請求項７の方法を実施するように適応されたコンピュータ読み取り可能な命令の組を含む媒体または波形。
16. コンピュータ・システム間のデータ交換を確立するための集積回路チップで、
    データ・パケットを伝送するために複数の伝送制御プロトコル（ＴＣＰ）接続を開設するように構成された論理、
    伝送用にデータ・パケットを形成するように構成された論理で、伝送用に形成されたデータ・パケットはオーディオ・データおよびビデオ・データを含む論理、
    データ・パケットにＴＣＰヘッダを添付するように構成された論理、
    添付ＴＣＰヘッダを有するデータ・パケットを伝送するために複数のＴＣＰ接続の内１つを選択するように構成された論理と、
    添付ＴＣＰヘッダを有するデータ・パケットを複数のＴＣＰ接続の内選択された接続上で伝送するように構成された論理、
    を含む集積回路チップ。
17. 請求項１６に記載される集積回路チップで、さらに、
    データ・パケットを伝送するために複数のＴＣＰ接続の各々の混雑度を判断するように構成される論理と、
    データ・パケットを伝送するために複数のＴＣＰ接続の内最も混雑の少ないものを選択するように構成される論理、
    を含む集積回路チップ。
18. 複数のＴＣＰ接続の各々の混雑度が、複数のＴＣＰ接続の各々により伝送されるデータ・パケットの利用可能な枠サイズを判断することにより判断される、請求項１７に記載される集積回路チップ。
19. 添付ＴＣＰヘッダを有するデータ・パケットを複数のＴＣＰ接続の内選択された接続上で伝送することがＴＣＰプロトコルに従うものである、請求項１６に記載される集積回路チップ。
20. 複数のＴＣＰ接続の各々により伝送されるデータ・パケットの利用可能な枠サイズが、ＴＣＰドライバ下のネットワーク・スタックにおいて添付ＴＣＰヘッダを有するデータ・パケットを調べることにより判断される、請求項１８に記載される集積回路チップ。

Images