JP3814678B2 - Internet via satellite - Google Patents
Internet via satellite Download PDFInfo
- Publication number
- JP3814678B2 JP3814678B2 JP2000597684A JP2000597684A JP3814678B2 JP 3814678 B2 JP3814678 B2 JP 3814678B2 JP 2000597684 A JP2000597684 A JP 2000597684A JP 2000597684 A JP2000597684 A JP 2000597684A JP 3814678 B2 JP3814678 B2 JP 3814678B2
- Authority
- JP
- Japan
- Prior art keywords
- gateway
- satellite
- protocol
- data
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims description 116
- 238000004891 communication Methods 0.000 claims description 70
- 239000000872 buffer Substances 0.000 claims description 42
- 230000005540 biological transmission Effects 0.000 claims description 40
- 238000006243 chemical reaction Methods 0.000 claims description 24
- 230000002457 bidirectional effect Effects 0.000 claims description 3
- 229920006395 saturated elastomer Polymers 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 59
- 230000008569 process Effects 0.000 description 44
- 238000012546 transfer Methods 0.000 description 29
- 238000012545 processing Methods 0.000 description 22
- 230000004048 modification Effects 0.000 description 20
- 238000012986 modification Methods 0.000 description 19
- 230000006855 networking Effects 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 11
- 238000004422 calculation algorithm Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 10
- 230000008901 benefit Effects 0.000 description 7
- 230000003139 buffering effect Effects 0.000 description 7
- 238000004590 computer program Methods 0.000 description 6
- 238000002474 experimental method Methods 0.000 description 6
- 235000008694 Humulus lupulus Nutrition 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000000926 separation method Methods 0.000 description 3
- 230000033001 locomotion Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000008054 signal transmission Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000006698 induction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000007493 shaping process Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000017260 vegetative to reproductive phase transition of meristem Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/185—Space-based or airborne stations; Stations for satellite systems
- H04B7/18578—Satellite systems for providing broadband data service to individual earth stations
- H04B7/18589—Arrangements for controlling an end to end session, i.e. for initialising, synchronising or terminating an end to end link
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Astronomy & Astrophysics (AREA)
- Aviation & Aerospace Engineering (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Radio Relay Systems (AREA)
Description
【0001】
(関連出願の相互参照)
本出願は、1999年2月2日、Jerome D.Toporek他の名義で出願され、「Internet Over Satellite Apparatus」と題された米国仮特許出願第60/118227号(整理番号16625−001100)の優先権を主張し、その完全な開示が、参照により、本明細書に組み込まれる。
【0002】
また、本出願は、下記の5つの共有される同時係属出願からの優先権も主張し、これらも、その全体が参照により、本明細書に組み込まれる。
1.1999年2月2日、Jerome D.Toporek他の名義で出願され、「Internet Over Satellite System」と題された米国特許出願第09/243185号(整理番号16625−001200)
2.1999年2月2日、Jerome D.Toporek他の名義で出願され、「Internet Over Satellite Method」と題された米国特許出願09/243554号(整理番号16625−001300)
3.1999年5月6日、Jerome D.Toporek他の名義で出願され、「Method and System for Managing Memory in an Internet Over Satellite Connection」と題された米国特許出願第09/306678号(整理番号16625−001210)
4.1999年5月6日、Jerome D.Toporek他の名義で出願され、「Method and System for Controlling Data Flow in an Internet Over Satellite Connection」と題された米国特許出願第09/306236号(整理番号16625−001220)
5.2000年1月28日、Jerome D.Toporek他の名義で出願され、「Internet Over Satellite Apparatus」と題され、やはり米国仮特許出願第60/118227号の優先権を主張する米国特許出願第________号(整理番号16625−001110)
【0003】
(発明の背景)
本発明は、遠隔通信の装置、システム、および技法に関する。より詳細には、本発明は、インターネットなどのコンピュータのワイド・エリア・ネットワーク内での使用のために、サテライト・システムを介するTCP接続を使用して、メモリを管理し、かつ/または情報を伝送するための装置、システム、および方法を提供する。本発明は、例えば、Xpress Transport Protocol(本明細書では、「XTP」)プロトコルを使用して、サテライト・システムを介して、遠隔ロケーションに対する信号の高速、高品質の伝送を提供する。また、本発明は、例えば、XTPプロトコルを使用する、サテライト・システムを介して、遠隔ロケーションに対する信号の高速、高品質の伝送のための装置内での制御されたメモリ管理も提供する。ただし、本発明はずっと広範囲の適用可能性を有することを理解されたい。これは、専用ブリッジされたネットワーク、地上無線ネットワーク・リンクなどにも適用できる。
【0004】
インターネットは、数百万の個別コンピュータ・ネットワークおよび個別コンピュータを一緒に接続する国際的「スーパー・ネットワーク」である。インターネットは、一般的に、単一エンティティではない。それは、どの単一エンティティも完全な権限または制御を有さない、極めて拡散した複雑なシステムである。インターネットは、ワールド・ワイド・ウェブ(本明細書では「ウェブ」)を介して情報を提供する方法のうちの1つとして広く知られているが、一般的なインターネット・プロトコルおよびインフラストラクチャに基づいて現在、利用可能な多くの他のサービスが存在する。
【0005】
ウェブは、一般的に、コンピュータに慣れていない人々にとっても使用することが容易である。ウェブ上の情報は、同一セットのデータ・ファイル(すなわち、ウェブ・サイト)内、あるいは他のコンピュータ・ネットワーク上にあるデータ・ファイル内の他のページに対する「リンク」を含む、グラフィックスおよびテキストの「ページ」上に提供することができる。ユーザは、しばしば、カリフォルニア州Mountain ViewのNetscape Communication Corporation、またはワシントン州RedmondのMicrosoft Corporationによって製造されるものなどの「ブラウザ」プログラムを使用して、ウェブで情報にアクセスすることができる。ブラウザ・プログラムは、ウェブ・サイトからの情報を処理して、その情報をグラフィックス、サウンド、およびアニメーションを使用して表示する。したがって、ウェブは、商品およびサービスを消費者に宣伝するための人気のある媒体となっている。
【0006】
インターネットは、多くの他の形式の通信をサポートする。例えば、インターネットは、通常、「eメール」として知られている電子メールを介する1対1通信を可能にする。インターネットは、また、他の人々がそれを読み、それに応答するカラフルなテキストおよびグラフィックスを掲示するために、ユーザによって使用される「掲示板」も有する。リアルタイム通信のため、インターネットは、「チャット・ルーム」などを有する。これらでタイプ入力したメッセージを使用して、ユーザが互いに通信を行うことができる。いくつかのケースでは、インターネットは、ユーザ間の音声通信のためにも使用することができる。これらの形式の通信のすべてが、少なくとも部分的に、重要な接続を使用して可能であり、この接続によって、情報が、インターネット上の多くの異なるサーバから伝送されることを可能にする。
【0007】
インターネットは、TCP/IPプロトコルに基づいている。ネットワーク層で、IPとして知られるインターネット・プロトコルが、個々のコンピュータにアドレス指定されたパケットを送るための機構を提供する。インターネットは、IPを実施する複数のコンピュータ・システムを有し、これらは、一般的に、ローカル・エリア・ネットワークおよび専用伝送回線を使用して互いに相互接続されて、コンピュータのワイド・エリア・ネットワークを形成する。IPパケットは、ベスト・エフォート基準で送達され、その目的の宛先に到着することが保証されず、これは、「信頼できない」サービスとして知られる。
【0008】
信頼できるデータ送達サービスを必要とする多くの適用形態の場合、インターネットは、TCPとして知られる伝送制御プロトコルと呼ばれる接続機構を使用する。TCPは、それがインターネットで通信するのに適している様々な望ましい特性を有する。例えば、TCPは、送信サーバから通信メディアを介して受信サーバに送信するデータ・サイズまたは最適サイズ・セグメントのデータを考慮する。さらに、TCPはタイマを維持する。これは、受信サーバが、送信サーバからのデータ・セグメントの受信の肯定応答を送信するのを待つ。肯定応答が受信される前に、タイマがタイムアウトになった場合、TCPは、データ・セグメントを再送信し、これが、通信での信頼性を提供する。また、TCPは、そのヘッダおよびデータ上にチェックサムを維持する。これが転送中のデータ内のいかなる変更も監視する。データが、無効なチェックサムを伴って到着した場合、TCPは、そのデータを廃棄して、そのデータを受信したことを認知しない。データ・セグメントが、誤った順序で到着した場合、TCPは、それらのセグメントを受信サーバで順序正しく再結合することもできる。さらに、TCPは、フロー制御を提供する。これは、有限量のデータだけが、受信サーバ上のバッファに送信されるようにする。これは、高速サーバ・コンピュータが、より遅いサーバ・コンピュータ上のすべてのバッファをオーバーフローさせるのを防止する。
【0009】
TCPは、同様の特性を有する従来の電話システムおよび電話回線を使用して互いに結合された複数のサーバ間で、インターネット・データを伝送するのによく適しているが、多くの限界も有する。例えば、TCPは、「短いホップ」に適しているが、しばしば、相当な待ち時間を有し得る極めて長距離にわたる通信(例えば、サテライトを介する大陸間ホップ)をスローダウンする。この場合、フロー制御機能および肯定応答機能が、送信および受信をするのに時間がかかり過ぎ、これが、通信を遅くする。さらに、効率を高める機会がまだ存在する。詳細には、TCPは、遅いことが判明しており、例えば、サテライト・ネットワークを介するインターネット・データの伝送には面倒である。さらに、例えば、モデムなどの比較的遅い受信側に対しての、サテライト・ネットワークを介するインターネット・データの高速伝送は、輻輳を引き起こす可能性がある。さらに、TCP接続のさらなる減速につながるシステム内でのリソースの消耗を引き起こし得る、サテライトを使用するネットワーキングでの異常な状態が発生する可能性がある。さらに、サテライトを使用するネットワーキングは、しばしば、TCP接続のさらなる減速につながる相当なビット・エラー率に遭遇する。これらの限界および他の限界を、下記の図により、さらに完全に説明する。
【0010】
以上のことから、無線通信メディアを使用する広い地理的領域にわたる、インターネット・サービスをトランスポートするより効率的な方法、およびその伝送で、メモリを管理するより効率的な方法が、大変、望ましい。
【0011】
(発明の概要)
本発明によれば、無線ワイド・エリア・ネットワーク上でのTCPパフォーマンスを改善するための技法が提供される。例としての実施態様では、本発明は、TCP接続を使用する情報を、例えば、Xpress Transport Protocol(本明細書では、「XTP」)接続に変換するための装置、システム、および方法を提供し、後者の接続は、サテライト・システムなどの無線ネットワーク・システムを介する伝送により適している。
【0012】
本発明によれば、TCP接続での情報フローを制御するための技法、および無線ワイド・エリア・ネットワーク上の1つまたは複数のTCP接続を介して通信される情報を記憶するためのメモリを管理する技法が提供される。例としての実施態様では、本発明は、情報のバッファリングおよび/または、情報がTCP接続を介して、例えば、Xpress Transport Protocol(本明細書では、「XTP」)接続に流れる速度を制御する方法およびシステムを提供する。
【0013】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送するための通信装置を提供する。この装置は、TCP接続を使用して、データおよびヘッダを有する双方向フローの情報を提供するための、サテライト・ゲートウェイ・インターフェースに結合されたTCPインターフェースを含む。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはTCP/IPプロトコルを使用する任意のネットワークからのものでよい。また、この装置は、TCP接続を使用して、サテライト・リンクを介する伝送のためのサテライト・プロトコルに情報を変換するプロセッサも含む。このサテライト・プロトコルは、サテライト・リンクを介するそうした情報の伝送のための適切な特性を有する。このプロトコルには、とりわけ、XTP、XTP様のプロトコルなどが含まれ得る。
【0014】
代替の実施態様では、本発明は、TCP接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立するための通信装置を提供する。この装置は、第1クライアント(例えば、ユーザ・コンピュータ)と第1サテライト・ゲートウェイの間での第1通信接続を形成するためのTCPインターフェースを含む。また、この装置は、サテライト・リンクを介して第1サテライト・ゲートウェイと第2サテライト・ゲートウェイの間で第2通信接続を形成するためのサテライト・ゲートウェイ・インターフェースも含む。第1接続の特性(例えば、送信元および宛先のIPアドレスおよびポート番号)を記述する情報が、第2サテライト・ゲートウェイに伝送される。第3通信接続が、第2サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第1クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【0015】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送する通信システムを提供する。このシステムは、データおよびヘッダを有する双方向フローの情報を提供するためのコードを有する第1ゲートウェイを含み、この第1ゲートウェイは、TCP接続に結合されている。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはTCP/IPプロトコルを使用する任意のネットワークからのものでよい。また、このシステムは、TCPプロトコルからの情報をサテライト・リンクを介する伝送のためのサテライト・プロトコルに変換するためのコードも含む。また、このシステムは、サテライト・リンクを介して、第1ゲートウェイからの情報を受信するための第2ゲートウェイも含む。第2ゲートウェイは、サテライト・リンクを介する伝送のための適切な特性を有するサテライト・プロトコルからの情報をTCPプロトコルに変換するためのコードも含む。このサテライト・プロトコルには、とりわけ、XTP、XTP様のプロトコルなどが含まれ得る。
【0016】
代替の実施態様では、本発明は、TCP接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立することができる通信システムを提供する。このシステムは、第1クライアント(例えば、ユーザ・コンピュータ)と第1サテライト・ゲートウェイの間での第1通信接続をインターセプトするためのコードを含む。また、このシステムは、サテライト・リンクを介して第1サテライト・ゲートウェイと第2サテライト・ゲートウェイの間で第2通信接続を形成するためのコードも含む。第1接続の特性(例えば、送信元および宛先のIPアドレスおよびポート番号)を記述する情報が、第2サテライト・ゲートウェイに伝送される。第3通信接続が、第2サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第1クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【0017】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送するための通信方法を提供する。この方法は、TCP接続を使用して、データおよびヘッダを有する双方向フローの情報を提供するステップを含む。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはTCP/IPプロトコルを使用する任意のネットワークからのものでよい。また、この方法は、TCP接続を使用して、サテライト・リンクを介する伝送のためのサテライト・プロトコルに情報を変換するステップも含む。このサテライト・プロトコルは、サテライト・リンクを介するそうした情報の伝送のための適切な特性を有する。このプロトコルには、とりわけ、XTP、XTP様のプロトコルなどが含まれ得る。
【0018】
代替の実施態様では、本発明は、TCP接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立する通信方法を提供する。この方法は、第1クライアント(例えば、ユーザ・コンピュータ)と第1サテライト・ゲートウェイの間での第1通信接続をインターセプトするステップを含む。また、この方法は、サテライト・リンクを介して第1サテライト・ゲートウェイと第2サテライト・ゲートウェイの間で第2通信接続を形成するステップも含む。第1接続の特性(例えば、送信元および宛先のIPアドレスおよびポート番号)を記述する情報が、第2サテライト・ゲートウェイに伝送される。第3通信接続が、第2サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第1クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【0019】
特定の実施態様では、本発明は、メモリを管理するため、かつサテライト・リンクを介して確立されたインターネット接続を介して通信される情報をバッファリングする方法を提供する。この方法は、1つまたは複数のクライアントと、1つまたは複数のサーバと、少なくとも1つのクライアントに接続された第1ゲートウェイと、少なくとも1つのサーバに接続された第2ゲートウェイと、これらのゲートウェイ間の無線遠隔通信リンクとを含むシステムなどの、多種多様なシステム上で実行できる。この方法は、クライアントによって開始されたサーバとの接続の試行をインターセプトするステップを含む。クライアントは、第1特性データ通信速度を有することになる接続を試みる。接続は、サテライト・リンクまたはそれに類するものであり得る遠隔通信リンクを介して、第1ゲートウェイと第2ゲートウェイの間で確立される。この接続は、第2特性データ通信速度を有することになる。第1ゲートウェイは、遠隔通信リンクを介して第2ゲートウェイから受信した情報を記憶するバッファと、クライアントに送信される情報を記憶するバッファとを含む。この方法は、受信バッファ内の状態を判定するステップを実行することができる。その状態は、遠隔通信リンク内での特性データ通信速度が、クライアントに対する特性データ通信速度よりも相当に高いかどうかを示すことができる。クライアントに対して遠隔通信リンクを介して受信されるデータの量を抑えるように、第1ゲートウェイで、クライアントに対する受信ウィンドウ・サイズを設定するステップもまた、この方法の一部であり得る。これらのステップの結合が、第1ゲートウェイ内で遠隔通信リンクから着信する情報をバッファリングするためにメモリを管理する方法を提供することができる。
【0020】
本発明の別の態様では、サテライトを介する情報のフローを制御するシステムが提供される。このシステムは、複数の潜在的クライアントのうちから選択された少なくとも1つのクライアントと、複数の潜在的サーバのうちから選択された少なくとも1つのサーバとを含み得る。また、このシステムは、第1遠隔通信リンクによってクライアントに接続された第1ゲートウェイと、第2遠隔通信リンクによってサーバに接続された第2ゲートウェイとを含み得る。また、第1ゲートウェイと第2ゲートウェイを接続する第3遠隔通信リンクも、このシステムの一部であることが可能である。このシステムは、クライアントによって開始された、第1特性データ通信速度での、サーバとの接続の試行をインターセプトするように動作する。次に、このシステムは、第3遠隔通信リンクを介して、第1ゲートウェイと第2ゲートウェイの間での接続を確立することができる。この接続は、第2特性データ通信速度を有することになる。第1バッファが、第3遠隔通信リンクを介して受信した情報を記憶して、第2バッファが、クライアントに送信される情報を記憶する。このシステムは、第1バッファ内での状態を判定することができる。その状態は、第3遠隔通信リンク内の第2特性データ通信速度が、クライアントに対する第1特性データ通信速度よりも高いことを示す。また、このシステムは、クライアントに対して第3遠隔通信リンクを介して受信されるデータの量を抑えるように、第1ゲートウェイで、クライアントに対する受信ウィンドウ・サイズを設定することもできる。
【0021】
本発明によるさらなる態様では、無線データ・リンクを介する情報のフローを制御するコンピュータ・プログラム製品が提供される。このデータ・リンクは、1つまたは複数の接続を含み得る。このコンピュータ・プログラム製品は、複数のコードを保持するコンピュータ可読記憶媒体を含む。クライアントによって開始された、第1特性データ通信速度での、サーバとの接続の試行をインターセプトするコードが、このプログラム製品に含まれる。さらに、遠隔通信リンクを介して、第2特性データ通信速度で、第1ゲートウェイと第2ゲートウェイの間で接続を確立するコードも含まれる。第1ゲートウェイ内の第1バッファが、遠隔通信リンクを介して受信された情報を記憶して、第2バッファが、クライアントに送信される情報を記憶する。この製品は、また、第1バッファ内の状態を判定するコードも含む。その状態は、遠隔通信リンクの特性データ通信速度が、クライアントのそれよりも相当に高い状況を示す。この状況が検出された場合には、この製品は、クライアントに対する遠隔通信リンクを介して受信されるデータの量を抑えるように、第1ゲートウェイでクライアントに対する受信ウィンドウを設定するコードを呼び出す。
【0022】
特定の実施態様では、本発明は、サテライト・リンクを介して確立されたインターネット接続を介する情報のフローを制御する方法を提供する。この方法は、1つまたは複数のクライアントと、1つまたは複数のサーバと、少なくとも1つのクライアントに接続された第1ゲートウェイと、少なくとも1つのサーバに接続された第2ゲートウェイと、これらのゲートウェイ間の無線遠隔通信リンクとを含むシステムなどの、多種多様なシステム上で実行され得る。この方法は、クライアントによって開始されたサーバとの接続の試行をインターセプトするステップを含む。接続は、サテライト・リンクまたはそれに類するものであり得る遠隔通信リンクを介して、第1ゲートウェイと第2ゲートウェイの間に確立され得る。この方法は、データが、クライアントからサーバまで接続を介して伝わるのにかかる往復時間を判定するステップを含み得る。接続に関するデータ通信速度を判定することができる。往復トリップ時間およびデータ通信速度から、帯域幅遅延積(bandwidth-delay product)が、この方法によって判定され得る。この方法は、また、その帯域幅遅延積から、その接続に対するフロー制御制限を決定することもできる。フロー制御制限に基づいて、接続を介するデータ転送を制限するステップをこの方法の一部としてもよい。こられのようなステップの結合が、無線通信メディアなどを使用する、広い地理的領域にわたるネットワーク上で、TCPデータのフローを制御する方法を提供する。
【0023】
別の実施態様では、本発明は、接続のうちから、フロー制御されることによって利用可能なシステム・リソースに有益であり得るものを選択することができる。いくつかの実施態様は、フロー制御のために、初期設定中ではない接続、あるいはしきい値を下回って、またはしきい値を上回って、ブロックでデータを転送している接続などをスクリーニングすることができる。多くの実施態様では、接続に関する帯域幅遅延積は、往復時間とデータ通信速度を掛けることによって判定される。いくつかの実施態様では、接続に対するフロー制御制限は、帯域幅遅延積に倍率を掛けて、そのリンクに関する接続の数でそれを割ることによって決定される。
【0024】
本発明の別の態様では、サテライトを介する情報のフローを制御するシステムが提供される。このシステムは、複数の潜在的クライアントのうちから選択された、少なくとも1つのクライアントと、複数の潜在的サーバのうちから選択された少なくとも1つのサーバとを含む。また、このシステムは、第1遠隔通信リンクによってクライアントに接続された第1ゲートウェイと、第2遠隔通信リンクによってサーバに接続された第2ゲートウェイとを含み得る。また、第1ゲートウェイと第2ゲートウェイを接続する第3遠隔通信リンクも、このシステムの一部であることが可能である。このシステムは、データが、クライアントから、第1遠隔通信リンク、第2遠隔通信リンク、および第3遠隔通信リンクを介して、接続上でサーバまで渡るのにかかる往復時間を判定するように動作する。このシステムは、その接続に関するデータ通信速度を判定することができる。さらに、このシステムは往復時間とデータ通信速度から帯域幅遅延積を判定することができる。このシステムは、帯域幅遅延積から接続に対するフロー制御制限を決定して、そのフロー制御制限に基づいて、その接続を介するデータ転送を制限することができる。そうした方式でデータ転送を制限することは、例えば、遠隔通信リンク上での比較的高速のデータ転送をクライアントでの比較的遅いデータ転送にインターフェースすることができる。
【0025】
本発明によるさらなる態様では、無線データ・リンクを介する情報のフローを制御するコンピュータ・プログラム製品が提供される。データ・リンクは、1つまたは複数の接続を含み得る。このコンピュータ・プログラム製品は、複数のコードを保持するコンピュータ可読記憶媒体を含む。データが、接続を介して無線データ・リンクを渡るのにかかる往復時間を判定するコードが、この製品の一部であり得る。さらに、このコンピュータ・プログラム製品は、接続に関するデータ通信速度を判定するコードを含み得る。また、往復時間およびデータ通信速度から帯域幅遅延積を判定するコードも含まれ得る。帯域幅遅延積から接続に対するフロー制御制限を決定するコード、およびそのフロー制御制限に基づいて、その接続を介するデータ転送を制限するためにコードもまた、このコンピュータ・プログラム製品の一部であり得る。
【0026】
本発明の別の態様では、サテライトなどの、ネットワーク内の所定ポイントを通って流れる情報に関するデータ通信速度を、そのネットワーク上の遠隔ポイントのデータ通信速度能力にマッチさせるための技法が提供される。一実施態様では、本発明は、サテライト装置を介する適切なデータ通信速度または所定のデータ通信速度を維持するため、転送速度制御を提供する。この転送速度制御は、着信データをバッファリングする複数の待ち行列を提供する。着信データは、所定の長さに照らして検査される。その所定の長さを越えるデータが、その待ち行列内に記憶される。所定の間隔で、情報が、1つまたは複数の待ち行列から取り出されて、発信データ・パスに沿って伝送される。この処理は、本発明によるシステムが、サテライト・リンクなどのネットワークに沿った特定のポイントを通るデータ通信速度制御を提供することを可能にする。
【0027】
本発明の別の態様では、クライアントとサーバの間のTCPプロトコルでのパケット化された情報をトランスポートする通信システムを、クライアントとサーバの間のサテライト・プロトコルでのパケット化された情報をトランスポートするシステムに変換する方法が、クライアントからサーバへの接続をインターセプトするように動作可能に構成された第1ゲートウェイを設置するステップを含む。第1ゲートウェイは、さらに、TCPプロトコルからサテライト・プロトコルにパケット化された情報を変換することができる。また、サーバとの接続を確立することができ、さらに、サテライト・プロトコルからTCPプロトコルにパケット化された情報を変換するように動作可能に構成された第2ゲートウェイを設置するステップも、この方法に含まれる。第1ゲートウェイおよび第2ゲートウェイは、共通遠隔通信リンクを介して接続を確立することができる。これらの要素の結合が、TCP遠隔通信のためのシステムをサテライト・プロトコル通信に変換する方法を提供することができる。
【0028】
本発明を使用して、従来の技法に優る多数の利点が実現される。特定の実施態様では、本発明は、従来のシステムよりも高いスループットを提供する。さらに、本発明は、サテライト・ネットワークを介するTCPパフォーマンスをトランスペアレントに向上させる方法を提供する。他の実施態様では、本発明は、サテライト通信に特有の長い待ち時間、高い損失、および非対称帯域幅条件に適した斬新なプロトコルを提供する。
【0029】
特定の実施態様では、本発明による技法は、受信ウィンドウを迅速にサイズ変更して、サテライト・リンクを介する、送信側のデータ通信速度とTCP接続の受信側のデータ通信速度との間のマッチを実現することができる。いくつかの実施態様では、本発明の技法は、各サテライト接続に別々に提供することが可能であり、したがって、1つの遅い受信側が、同一リンクを介する他の接続のパフォーマンスを低下させることがない。いくつかの実施態様では、本発明は、サテライト通信に特有の、長い待ち時間、高い損失、および非対称性帯域幅条件に適した斬新なプロトコルでのバッファ・メモリの管理を提供する。特定の実施態様では、本発明は、従来システムよりも均等なネットワーク・リソースの配分を提供する。本発明による多くの実施態様は、接続間でネットワーク・リンク/サテライト・リンクを共用することを提供する。多くの実施態様では、1つの特定の接続からのデータのバーストが、他の接続に対するデータに先立って、リンクを介する伝送のために待ち行列化される可能性がより低い。他の実施態様では、本発明は、サテライト通信に特有の長い待ち時間、高い損失、および非対称帯域幅条件でのデータ・フロー制御を提供する。
【0030】
また、本発明は、従来のサテライト・システム内での比較的簡単な実装、またはそれとの比較的簡単なインターフェースを提供する。実施態様に応じて、これらの利点のうちの1つまたは複数が存在し得る。これらの、また他の利点および利益は、本明細書全体にわたって記載しており、また下記により詳細に記載する。
【0031】
本発明のこれらの実施態様および他の実施態様は、下記のテキストおよび添付の図に関連して、より詳細に記載する。
【0032】
(特定の実施形態の説明)
様々な実施形態を論ずる前に、サテライト・ネットワークを介してTCPを使用することの制限をより完全に理解することは読者の助けとなろう。以下でこの制限をより完全に説明する。
【0033】
輻輳回避: 輻輳ネットワーク・メルトダウンの可能性を回避するために、一般にTCPは、全てのデータ損失が輻輳によって引き起こされ、伝送速度を減少させることによって応答すると想定する。しかし、サテライト・リンクを介して、TCPは、しばしば長い往復時間およびビット・エラーを輻輳と誤解し、不適切に応答する。同様に、TCP「スロー・スタート(slow start)」アルゴリズムは、地上のインフラストラクチャを介して新しい接続が既に輻輳したネットワークを氾濫するのを防止し、サテライトを介して新しい各接続に対して過剰に長いランプアップ(ramp−up)を強制する。これらの輻輳回避機構は、経路指定環境で重要であるが、サテライト・リンクにはしばしば不適切である。
【0034】
データ肯定応答: TCPによって使用される単純でヒューリスティックなデータ肯定応答方式は、一般に長い待ち時間または非常に非対称な帯域幅条件に対してはあまり適合しない。信頼できるデータ伝送とするために、TCP受信機は、しばしば、送信側に送り返されるデータに対する肯定応答を絶えず送信する。送信側は、一般に肯定応答を受信することなく多数の往復時間が経過するまで、何らかのデータが紛失または壊れるとは想定しない。パケットが紛失または壊れた場合、TCPは、最初の欠落パケットから始まるデータの全てを再送信する。アルゴリズムは、往復時間が長く、エラー率が高いサテライト・ネットワークを介しては十分には応答することができない。さらに、肯定応答の一定ストリームは、しばしば貴重なバック・チャネル帯域幅を浪費する。バック・チャネル帯域幅が小さい場合、送信側への肯定応答の戻りは、ある場合には、システム・ボトルネックとなる可能性がある。
【0035】
ウィンドウ・サイズ: TCPは、スライド式ウィンドウ機構を使用してフライト中のデータ量を制限する。ウィンドウが実質上満杯になった場合、送信側は、宛先サーバからの新しい肯定応答を受け取るまでデータの送信を停止する。肯定応答の戻りが低速なサテライト・ネットワークを介して、TCPウィンドウ・サイズは、一般に最大データ・スループット・レートに対して厳しい制限を設定する。エラーのないリンクを完全に利用するためにしばしば必要な、「帯域幅遅延積」として知られる最小ウィンドウ・サイズは、例えばT1サテライト・リンクに対しては100Kバイトであり、10MBpsリンクに対しては675Kバイトである。ビット・エラーは、必要なウィンドウ・サイズをさらに増加させる可能性がある。しかし、TCP/IPの大部分の実装は、しばしば最大ウィンドウ・サイズ64KBに制限され、多くの共通オペレーティング・システムは、デフォルト・ウィンドウ・サイズ8KBのみを使用し、データ・パイプの帯域幅に関わらず、サテライト・リンクを介する最大スループット速度が1接続あたり128Kbpsとなる。
【0036】
本発明によれば、広域無線ネットワークを介するTCP接続を行う技術が提供される。例示的実施形態では、本発明は、XTP接続へのTCP接続を使用して情報を変換する装置、システム、および方法を提供する。XTP接続は、サテライト・システムなどの無線ネットワーク・システムを介した伝送により適している。
【0037】
さらに、本発明によれば、TCP接続中の情報フローを制御し、無線広域ネットワークを介する1つまたは複数のTCP接続に対してメモリを管理する技術が提供される。例示的実施形態では、本発明は、無線ネットワーク・システムを介して送信される、情報のフローおよび/またはバッファリング情報のためのメモリ管理を制御する方法およびシステムを提供する。XTP接続は、サテライト・システムなどの無線ネットワーク・システムを介した伝送により適している。本発明の詳細を本明細書を通して、より具体的に以下で説明する。
【0038】
図1は、本発明の実施形態によるサテライト・システム100の単純化したダイアグラムである。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。とりわけ、システム100は、サテライト101を有するサテライト・ネットワーク・システムを含む。サテライト101は、複数の地上局107、108、またはサテライト・ディッシュの間で情報を受信し、送信する。各サテライト地上局は、サテライト・ディッシュ、およびサテライト・モデム109A、109B、またはVSATインドア・ユニットなどの他の形態の受信機を含む。VSATインドア・ユニットは、サテライト・ゲートウェイ111A、111Bに直接に、または間接に結合する。
【0039】
サテライト・アンテナ108は、サテライト101を介して信号103を受信し、送信する。サテライト・アンテナ108は、インターネット129またはインターネットなどの広域ネットワークに結合するサテライト・ゲートウェイ111Bに接続する。広域ネットワークは、サーバ131に結合する。ゲートウェイ111Bも、サテライト・モデム109Bを介して結合する。サーバおよびインターネット通信は、TCP/IP、UDP/IPなどの共通プロトコルで行われる。サテライト・ゲートウェイを以下でより詳細に説明する。
【0040】
サテライト・アンテナ107は、サテライト101を介して信号105を受信し、送信する。サテライト・アンテナ107は、イーサネット、トークン・リング、FDDIなどのローカル・エリア・ネットワーク121に結合するサテライト・ゲートウェイ111Aに接続する。ローカル・エリア・ネットワーク121は、端末123またはクライアントに結合する。ここで、サテライト・ゲートウェイは、モデム119を介してラップトップ117に結合する。クライアント、ラップトップ、およびローカル・エリア・ネットワークは、TCP/IP、IPX/SPXなどの共通接続フォーマットを使用する。サテライト・ゲートウェイを以下でより詳細に説明する。
【0041】
特定の実施形態では、サテライト・ゲートウェイ111Aは、クライアントからのTCP接続をインターセプトし、サテライト101を介して送信するためにデータ105をサテライト・プロトコルに変換する。ゲートウェイ111Aは、データをサテライト101に送信するサテライト・モデム109Aを介しても結合する。サテライト・リンクの反対側のサテライト・ゲートウェイ111Bは、サーバ131と通信するためにサテライト・プロトコルでのデータをTCPに変換し戻す。特定の実施形態では、本発明は、従来技術を超えて性能を向上させる。加えて、本発明の技術は、実質上エンド・ユーザにトランスペアレントのままであり、完全にインターネットまたはインターネット・インフラストラクチャと適合する。全ての態様でないとしても、多くの場合、クライアントまたはサーバには実質上の変更は必要ではない。好ましい実施形態では、アプリケーションは、実質上のハードウェアおよび/またはソフトウェア修正なしに引き続き機能する。
【0042】
上記では、特定のネットワーキング・ダイアグラムの点から説明したが、他の構成でこのサテライト・ゲートウェイを実装することが可能である。例えば、このサテライト・ゲートウェイは、複数のリモート・ゲートウェイの働きをする1つの「ハブ」または中央ゲートウェイでよい。各リモート・ゲートウェイは、中央ゲートウェイに接続され、個々のサテライト・リンクが作成される。
【0043】
他の共通ネットワーク・トポロジも使用することができる。さらに、ある実施形態では、異なる電気通信リンクを使用して、接続の順方向または逆方向パスを搬送することができる。例えば、サテライト・リンクを使用して、順方向パス上でデータを搬送することができ、同時に逆方向パスのために電話線を使用することができる。本発明の範囲を逸脱することなく、ここで述べた例示的ハードウェアを他のタイプの電気通信ハードウェアで置き換えることもできる。
【0044】
加えて、このサテライト・ゲートウェイを一般に独立型ユニットとして説明する。しかし、このゲートウェイをクライアント・マシン中に実装または一体化することができることは理解されよう。例えば、このゲートウェイは、サテライト・カードを使用してパーソナル・コンピュータ上に実装することができる。このサテライト・カードは、ウィンドウズ(商標)98マシン中に挿入することができる。このゲートウェイは、ウィンドウズNT、MacOS、およびLinuxなどの他のオペレーティング・システム上に実装することもできる。もちろん、実装の厳密な方式は、アプリケーションに依存することになる。加えて、このサテライト・ゲートウェイは、独立型サテライト・モデム、VSATハードウェア、ルータ、または他のネットワーク装置中に一体化することもできる。
【0045】
I.プロトコル設計
特定の実施形態では、本発明は、サテライト・ネットワークについてのスループットを向上する新規サテライト・プロトコルを含む。本プロトコルは、典型的なサテライト待ち時間、ビット・エラー、および非対称な帯域幅条件に対して効果的に応答するように設計することができる。このプロトコルは、固定帯域幅を有するポイントツーポイント・リンク上で可能な最適化も利用することができる。XTPなどのサテライト・プロトコルに関するより詳しい情報は、Tim Strayerの「A Brief Introduction to the Xpress Transport Protocol,」から得ることができ、その全体を参照することにより実際上本明細書に組み込む。このサテライト・プロトコルのこれらおよび他の特徴を以下でより詳細に説明する。
【0046】
このプロトコルは、効果的なデータの肯定応答用選択的再送信アルゴリズムを利用する。サテライトを介するホップが、中間経路指定を用いないポイントツーポイント・リンクのために、パケット中のどんなギャップも破壊によるデータ紛失であると想定することができる。受信側サテライト・ゲートウェイは、送信側サテライト・ゲートウェイからの欠落データを検出すると即時に再送信を要求する。
【0047】
このプロトコルは、実質上従来のTCPの頻繁な肯定応答機能に束縛されない。ある実施形態では、このプロトコルは、紛失データを識別する主な手段のようには肯定応答機能を使用しない。これらの実施形態において、このプロトコルで必要なのはデータ到着およびバッファを消去する低頻度の肯定応答機能だけである。(従来のTCPは、リバース・チャネルを介して肯定応答の一定ストリームを送信する。)このプロトコルは、70%以上バック・チャネル使用を低減し、それによって限定的バック・チャネル帯域幅がシステムのボトルネックであるネットワークの性能を向上する。
【0048】
このプロトコルは、サテライト・ゲートウェイ間でデータを転送するのに十分大きいウィンドウ・サイズを提供する。サテライト・ゲートウェイ間のサテライトを介する帯域幅遅延積が、サテライト・ゲートウェイからエンド・ノードへの帯域幅遅延積よりもずっと大きいので、この大きいプロトコル・ウィンドウにより、ウィンドウ・サイズ比に対する帯域幅遅延の生成が比較的一定のままとどまることが可能となる。このゲートウェイは、ネットワークに対するバッファとなり、クライアントおよびサーバのウィンドウ・サイズに依存しない高スループットが可能となる。
【0049】
このプロトコルは、一般には、サテライト・ゲートウェイ間のサテライトを介するホップ用の不必要な輻輳回避機構を使用しないが、このゲートウェイとエンド・ノードの間の地上接続用の「スロー・スタート」および全ての他の標準TCP輻輳回避アルゴリズムを引き続き使用する。このプロトコルは、ストリームライン式ハンドシェーク機構を使用して、接続セットアップに必要な往復回数を低減することもできる。
【0050】
この装置、システム、および方法は、経路指定ネットワークとの互換性を有するようにIPを介して実行することができる。あるいは、この装置は、大部分の例で性能を実質上向上させるために、リンク層を介して直接実行することができる。実施形態に応じてこれらの機能のうちの1つまたは複数を利用することができる。
【0051】
上記を本サテライト・プロトコルの望ましい特徴によって一般的に説明した。多くの他のタイプの特徴が利用可能であることを理解されよう。加えて、本発明は、必ずしも前述の各特徴を必要としない。適用例に応じてどんな組み合わせも使用することができる。他の変形形態、修正形態、および代替形態を当業者は理解されよう。
【0052】
II.XPRESS移送プロトコル
好ましい実施形態では、本発明は、一般にXTPとして知られている「Xpress移送プロトコル」を提供する。XTPは、ポリシーからの実装の分離、転送速度およびフロー制御の分離、マルチキャスト用の明示的ファーストクラス・サポート、およびデータ送達サービス独立性のための直交プロトコル機能を提供する。XTPは、サテライト・リンクを介したデータの送信に適した様々な特徴を有し、それらを以下でより完全に説明する。
【0053】
特定の実施形態では、本プロトコルは、その機能性が直交性である1組の機構を含む。この最も特筆すべき効果は、XTPが、利用されるエラー制御ポリシーから通信機構(例えば、データグラム、仮想回路、トランザクションなど)を分離することである(未修正でも完全に信頼できる)。さらに、通信に対してフローおよび転送速度制御ならびにエラー制御を手元で調整することができる。望む場合には、これらの制御処理のどんな組もオフにすることができる。
【0054】
本プロトコルは、転送速度およびフロー制御の分離も提供する。一般には、フロー制御は、エンドツーエンド・バッファ空間上で動作する。転送速度制御は、プロセッサ速度および輻輳を考慮に入れる生成側/消費側の概念である。TCPは、転送速度制御を提供せず、スロースタートおよび他のヒューリスティックを用いて輻輳に対処する。XTPは、転送速度制御およびフロー制御を独立に形成する機構を提供する。
【0055】
特定の実施形態では、本プロトコルは、明示的マルチキャスト・サポートを提供する。ここで、マルチキャストは、XTP中の追加部分ではない。ユニキャスト通信をするために使用される各機構はマルチキャストでも利用可能である。
【0056】
本プロトコルは、データ送達サービス独立性も有する。具体的には、XTPは、トランスポート・プロトコルであるが、経路指定ネットワークではなく交換ネットワークの出現に伴って、従来のネットワーキング層サービスは、あらゆる例において適切ではない可能性がある。XTPは、基礎となるデータ送達サービスがあるXTP装備ホストから別のXTP装備ホストにパケットをフレーム指示し、送ることを一般に必要とする。これは、ロウMACまたはIPまたはAAL5でよい。XTPは、パラメトリック・アドレス指定も利用し、パケットをいくつかの標準アドレス指定フォーマットのうちのいずれか1つでアドレス指定することが可能となる。XTPの他の特徴には、とりわけ仮想回線パラダイムに対する暗黙高速接続セットアップ、キーベース・アドレス指定ルックアップ、メッセージ優先度およびスケジューリング、カプセル化および収束プロトコルに対するサポート、選択的再送信および肯定応答、ならびに固定サイズ64ビット位置合わせフレーム設計が含まれる。
【0057】
XTPは、1つの末端システムから1つまたは複数の他の末端システムにユーザ・データを送るのに必要な機構を定義する。各XTP実装は、その各通信の状態を維持する。ユーザ・データまたは制御情報を含む明確なパケット構造は、ユーザ・データの転送を実施するために交換される。制御情報は、正確な要求された層を提供し、転送を効果的に行うよう助けるために使用される。正確さの保証は、エラー制御アルゴリズムおよび接続状態マシンの維持を介して行われる。可能な限り効果的に要求されたサービスの品質を提供するためにフローおよび転送速度制御アルゴリズム、あるプロトコル・モード、およびトラフィック形成情報が使用される。
【0058】
末端システムでのXTP状態を含む情報のコレクションは、コンテキストと呼ばれる。この情報は、2つ(またはそれ以上)のアクティブ通信の1つのインスタンスを表す。コンテキストは、XTPパケットを送信または受信する前に作成し、インスタンス化すべきである。末端システムで各アクティブ会話またはメッセージについての多くのアクティブ・コンテキストがある可能性がある。
【0059】
各コンテキストは、発信データ・ストリームおよび着信データ・ストリームのどちらも管理する。データ・ストリームは、各バイトがシーケンス番号によって表される連続バイトの任意長ストリングである。アクティブ・コンテキストの対の集合およびそれらの間のデータ・ストリームは、アソシエーションと呼ばれる。
【0060】
末端システムでのコンテキストは、初めは静止状態にある。通信サービスを必要とするユーザは、コンテキストが聴取状態に配置されることを要求する。次いでコンテキストは適切なFIRSTパケットを求めて聴取する。FIRSTパケットは、アソシエーションの初期パケットである。FIRSTパケットは、明示的アドレス指定情報を含む。ユーザは、XTPが着信FIRSTパケットと聴取コンテキストとをマッチングするのに必要な情報の全てを提供する。
【0061】
別の末端システムでは、ユーザは、XTPからの通信サービスを要求する。このユーザは、アソシエーションを開始するので、コンテキストは、静止状態からアクティブ状態に直接移る。アクティブ・コンテキストは、FIRSTパケットを構築し、ユーザからの明示的アドレス指定情報で完成する。FIRSTパケットは、基礎となるデータ送達サービスを介して送信される。
【0062】
FIRSTパケットが第1ホストのXTP実装で受信されたとき、アドレスが、全ての聴取コンテキストに対して比較される。マッチが見つかった場合、聴取コンテキストは、アクティブ状態に移る。この点から、アソシエーションの転送が確立され、通信を完全に対称とすることができる。アソシエーション中で、各方向の2つのデータ・ストリームがあるからである。さらに、アソシエーションの存続期間の間に他のパケットは、明示的アドレス指定情報を搬送しないことになる。むしろ、パケットを適切なコンテキストにマップする固有「キー」が各パケット中で搬送される。
【0063】
あるユーザから全てのデータが送信されると、そのユーザのコンテキストからのそのデータ・ストリームを閉じることができる。パケット中のオプションの形態の標識が、交換され、接続が適切にクローズされる。他の形態のより適切さの欠けるクロージングも、この交換を省略することによって可能である。両方のユーザが行い、両方のデータ・ストリームがクローズしたとき、コンテキストは、非アクティブ状態に移行する。コンテキストのうちの1つは、アソシエーションの解消を引き起こす標識を送信することになる。この時点では、両方のコンテキストは静止状態に戻る。
【0064】
一般には、XTPのパケット・タイプの全ては共通ヘッダ構造を使用する。処理の適切な点にパケットのペイロードをステアするのに必要な情報の全ては、ヘッダ中で搬送する。XTPコンテキストの動作の仕方の多くは、パケット・ヘッダ中の1つのフィールドに集中する1組のビット・フラグによって制御される。接続シャットダウンを制御するビット・フラグ、肯定応答ポリシーを制御するビット・フラグ、データ・ストリーム中のマーカであるビット・フラグを含む15個のフラグが定義される。残りのビット・フラグは、エンドツーエンド・オペレーティング・モードを制御する。例は、エラー制御またはフロー制御のイネーブルまたはディセーブル、あるいはマルチキャスト・モードのイネーブルを含む。
【0065】
XTPは、64ビット・シーケンス番号および64ビット・スライド式ウィンドウに基づく。XTPは、転送速度制御も提供し、それによって末端システムまたは中間システムは、接続時に受け入れることになる最大帯域幅およびバースト・サイズを指定することができる。トラフィック・セグメントは、トラフィックの形状を指定する手段を提供し、その結果末端システムおよび中間システムが、そのリソースを管理し、サービス品質保証を容易にすることができる。
【0066】
XTPでのエラー制御は、正および適切なときには負の肯定応答を取り込み、欠落または損傷データ・パケットの再送信を実施する。再送信は、go−back−Nまたは選択式のいずれかで良い。再送信アルゴリズムは保守的である。すなわち、制御メッセージを介して欠落していることが示されるデータのみを送信することができる。これは、スプリアスおよび可能な輻輳誘発再送信を回避する。エラー制御アルゴリズムは、基本的には保守的ながら、活動的になることもできる。すなわち、速動エラー通知に関するシステム、技術、および方法が提供される。
【0067】
XTPは、エラー制御をマルチキャスト環境に拡張する技術も指定する。マルチキャストでのエラー制御アルゴリズムは、ユニキャスト・アルゴリズムと同一である。とはいえ、状態変数を管理し、連続ストリーミングを実現するために追加の高度化が必要である。したがって、XTPは、本発明による好ましいサテライト・プロトコルである。
【0068】
前述ではXTPプロトコルを用いて一般に説明したが、他のタイプのプロトコルも使用することができることを理解されよう。例えば、プロトコルは、修正TCP、修正XTPなどで良い。加えて、プロトコルは、サテライトを介する伝送に適するどんなものでも良い。加えて、当業者は、他の変形形態、修正形態、および代替形態を理解されよう。
【0069】
図2は、本発明の実施形態によるシステム・アーキテクチャ200の単純化したダイアグラムである。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。システム・アーキテクチャ200は、少なくともクライアント201を含み、クライアント201はサテライト・ゲートウェイ203に結合し、サテライト・ゲートウェイ203は、サテライト・リンク209を介してサテライト・ゲートウェイ205からの情報を送受信する。サテライト・ゲートウェイ205は、サーバ207に結合する。サテライト・ゲートウェイおよびサーバは、インターネットまたはインターネットライクなコンピュータのネットワークを介して互いに結合する。
【0070】
クライアント201は、アプリケーションおよび物理層を含む多層で表すことができる。この層は、ブラウザ211を含むことができる。ブラウザ211により、ゲートウェイに送信するために、ユーザがアプリケーション層から物理層に情報を通信することが可能となる。ブラウザ211は、一般には、情報を提供するアプリケーション層中にある。例えば、ブラウザは、カリフォルニア州マウンテンビューのNetscape Communications Corporation、またはワシントン州レドモンドのMicrosoft Corporationと呼ばれる会社、あるいは他の会社によって行われた適切な設計のうちの1つとすることができる。ブラウザに加えて、FTPファイル転送を含む他のTCPアプリケーションも、クライアントとサーバ間で通信するために使用することができる。
【0071】
情報は、トランスポート層(例えばTCP)を介して、次いでIP層215を介して進む。IP層215は、ネットワーキング層である。トランスポート層は、クライアントとゲートウェイとの間のデータのフローを提供する。IP層は、クライアントとゲートウェイ、または他のネットワークとの間のパケットを含むデータの移動を扱う。情報は、物理層を介して送信され、物理層はドライバ217を含む。ドライバ217は、電気通信リンク221を介してゲートウェイ203に接続されるハードウェア219を介してゲートウェイ203に情報を送信する。電気通信リンク221は、ワイヤ、ケーブル、光ファイバ、または他の物理通信媒体でよい。あるいは、ドライバ217は、リンク221およびハードウェア219を介してゲートウェイ203から情報を受信する。例えば、ドライバは、クライアント・コンピュータ中のネットワーク・インターフェース・カードを有するネットワーク・オペレーティング・システムで良い。
【0072】
情報は、物理接続221からゲートウェイ203へわたる。ゲートウェイは、物理層223を有し、物理層223はドライバ225と対話する。ゲートウェイは、ネットワーキング層227およびトランスポート層229も含む。トランスポート層229は、変換モジュール231に結合する。ネットワーキング層227は、情報をサテライト・プロトコルを介して発送できるかどうかを判定する。発送できる場合は、データは、上部のトランスポート層229に渡される。発送できない場合は、データは、非変換形態でサテライト・リンク239に送るために転送速度制御モジュール234に即時に転送される。変換モジュール231は、衛星リンクを介して使用するのに適したサテライト・プロトコル233に情報を変換する。転送速度制御モジュール234は、情報を即時にサテライト接続に渡すことができるか、それとも後に送るために待ち行列化するどうかを判定する。サテライト接続は、ドライバ235によって物理層237に結合し、ドライバ235は、情報を衛星209に、かつそこから伝送する。情報は、無線媒体239、241中を衛星に向かって、かつ衛星から送られる。
【0073】
情報は、サテライト・ゲートウェイ205によって受信される。サテライト・ゲートウェイ205は、物理層、および他の層の多層を含む。物理層243は、ドライバ245に結合する。ネットワーキング層およびトランスポート層は、サテライト・プロトコル247および転送速度制御244を含む。ネットワークおよびトランスポート層は、変換モジュール249を含むセッション層に接続する。変換モジュールは、サテライト・プロトコルを使用して情報をTCP/IPに変換し戻す。情報は、トランスポート層(すなわちTCP)251およびネットワーキング層(すなわちIP)を通って送られる。サテライト・ゲートウェイ205からの情報は、ドライバ255を介して物理層257に入る。ドライバは、電気通信リンク259を介して情報をサーバ207に送信する。ドライバ255は、逆方向パスでサーバ207から情報を受信することもできる。
【0074】
電気通信リンク259から、情報は、物理層261を介してサーバ207中のドライバ263に送られる。情報は、ドライバからネットワーキング層に移る。ネットワーキング層はIP 265を含む。情報は、ネットワーキングからトランスポート層にも送られる。トランスポート層は、TCP 267を含む。情報は、例えばウェブ・サーバ・アプリケーション269に送られる。サーバ207およびサテライト・ゲートウェイ205の間は、アプリケーションに応じて、インターネットまたは別のIPネットワークとなる。
【0075】
特定の実施形態では、情報は、トランスポートおよびアプリケーション層を完全に迂回して、ネットワーク層ゲートウェイ203、205などのゲートウェイを介して流れることができる。例えば、ゲートウェイ203では、情報は、電気通信リンク221を介してクライアント201から入ることができる。物理層223は、情報をドライバ225に渡す。その結果、ドライバ225は、ネットワーク層227に情報を渡す。ネットワーク層227は、IPを使用して情報をその宛先に発送することができる。次いで情報は、ネットワーク層227からドライバ235に流れる。ドライバ235は、物理層237と対話し、電気通信リンク239を介して、サテライト209に沿って情報を渡す。
【0076】
特定の実施形態では、変換モジュールは、TCP接続を使用してサテライト・システムを介する伝送に適した接続に情報を変換する。サテライトに適した接続は、一般にOrion Woroldcast(商標)またはPanAmSat(商標) SpotByte(商標)サービスなどの無線ネットワークを介した伝送に対して回復力がある。この接続は、長い待ち時間および非対称帯域幅条件にも適しているべきである。この接続はクライアントまたはサーバ位置のエンド・ユーザにトランスペアレントでもあるべきである。長い待ち時間は、一般にサテライト・ホップあたり約200ミリ秒〜約700ミリ秒であるが、その値に限定されない。
【0077】
特定の実施形態では、例えば図2Aに示すように、この変換モジュールは、サテライト・リンクを介して伝送するためにTCP接続を使用して情報をXTP、修正TCPまたはXTPライク・プロトコルに変換する。ここで、TCPモジュールは、TCP接続を含む情報350を受信する。この情報は、データ333、TCPヘッダ335、およびIPヘッダ337を含む。TCPモジュールは、情報351が実質上全てのデータ333を含み、あるTCPヘッダ情報と共に変換モジュールにデータを渡すように、この情報からTCPヘッダを削除する。変換モジュールは、サテライト・プロトコル・ヘッダ339がデータ上に付加されるサテライト・プロトコル・モジュールに、データまたはデータの部分を渡す。ヘッダは、XTPヘッダなどである。次いで情報352は、サテライト・リンクを介した伝送に適したXTPヘッダを含む。特定の実装に応じて、XTPヘッダおよびデータにサテライト・リンクを介して伝送するためにIPヘッダを付加することもできる。具体的には、この情報は、物理層およびドライバに転送される。ドライバおよび物理層は、追加のヘッダを付加することができる受信側サテライト・ゲートウェイに情報を送信する。
【0078】
サテライト・リンクからは、XTPヘッダを含む情報が受信側XTPモジュールに入る。受信側XTPまたはサテライト・プロトコル・モジュールは、データ353を残し、XTPヘッダを情報から削除する。受信側サテライト・プロトコル・モジュールは変換モジュールにデータを渡す。変換モジュールはデータを適切なプロトコルに経路指定するために使用される経路指定モジュールで良い。次いで変換モジュールは、TCPモジュールにデータを渡す。受信側TCPモジュールは、データ上にTCPヘッダ343およびIPヘッダ341を付加し、次いでネットワークを介して受信側サーバ宛先に伝送する準備ができた情報を形成する。TCP接続を使用する情報は、ネットワークを介して宛先サーバに横切る。
【0079】
他の実施形態では、変換モジュールは、データおよびTCP/IPヘッダを含む情報の部分をXTPプロトコルを使用する情報に変換することもできる。あるいは、変換モジュールは、多数のTCP/IPヘッダを含む情報の複数のセグメントを、サテライト・リンクを介して伝送するXTPヘッダを含む情報の単一の部分に変換することもできる。アプリケーションに応じて、変換モジュールは、TCP接続を含む情報を上記のいずれか1つまたはいずれかの組み合わせに変換することができる。これらの技術や他のより一層の詳細を以下でより詳細に説明する。
【0080】
図3Aおよび3Bは、本発明の実施形態によるプロセス・ダイアグラムの単純化したダイアグラムである。これらのダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。特定の実施形態では、本発明は、図3Aに図示する接続プロセス300を使用する。この接続プロセスは、エンド・ユーザにトランスペアレントなTCP接続を行うサテライト・システム中で「ハンドシェーキング・ルーチン」を使用する、複数の別々の接続を使用する。サテライト・システムは、本明細書で説明するシステムに類似するようにできるが、それに限定されない。このプロセスは、ステップ301のスタートで始まる。特定の実施形態では、複数の接続が提供される。具体的には、このプロセスは、ステップ303の第1接続を行う。第1接続は、クライアントと、サテライト・リンクへのインターフェースをとるクライアント側ゲートウェイとの間のTCP接続である。このプロセスは、ステップ305の第2接続を行う。第2接続は、無線(例えばサテライト)リンクを介するクライアント側ゲートウェイと宛先ゲートウェイとの間の接続を行う。無線リンクは、XTPまたはXTPライク接続などのどんな適切な接続でも良い。このプロセスは、ステップ307の第3接続を行う。第3接続は、宛先ゲートウェイと宛先サーバとの間のTCP接続を形成し、インターネットまたはインターネットを介して横切ることができる。これらの接続が行われた後は、これらの接続は、維持される(ステップ309)。このプロセスは、ストップ311で終了し、そこで全ての3つの接続が終了する。
【0081】
特定の実施形態では、このプロセスは、ステップの選択したシーケンスによって行われる。ここで、TCP SYNパケットは、サテライト・ゲートウェイによってトランスペアレントにインターセプトされる。サテライト・ゲートウェイは、サテライト・リンクを横切って他のサテライト・ゲートウェイへの新しいXTP接続を確立する。IDアドレスおよびポート番号を含む、要求側クライアントおよび宛先サーバについての情報は、サテライト・リンクを介して他のサテライト・ゲートウェイに転送される。次いで宛先ゲートウェイは、クライアントのアドレス指定情報を使用して宛先サーバとのTCP接続をセットアップし、その結果、サーバは、クライアント自体が接続を確立した場合と同様にTCP接続を認識する。サテライト・ゲートウェイは、パケットをサテライト電気通信リンクを介して送付すべきかどうかを決定するために、ゲートウェイに入るパケットのIPヘッダ中の送信元および宛先アドレスに基づいて経路指定の決定を行う。サーバへのTCP接続が確立された後は、宛先ゲートウェイは、送信側ゲートウェイに通信し戻し、次いで送信側ゲートウェイは、クライアントとの接続を確認する。
【0082】
1つまたは複数の実施形態では、ステップのこのシーケンスは利点を有する。具体的には、クライアントは、サーバがこの接続を受諾するまでは、接続が確立されているとはみなさず、これにより正常接続確立の偽の指示を減らし、さらにはなくす傾向がある。加えて、クライアントおよびサーバのどちらも、サテライト接続がクライアントとサーバとの間に生じていることを検出せずに、そのうちの2つの間で即座に生じているものとして接続を認識する。すなわち、本発明は、実質上接続の「エンドツーエンド・セマンティクス」を保持する。他の実施形態では、接続性は対称である。ここで、「クライアント」は、サテライト・リンクのどちらの側にも存在することができ、かつ「サーバ」はどちらの側にも存在することができる。一方の側のシステムは、他方の側のシステムに接続を要求することができ、サテライト・ゲートウェイは接続をインターセプトすることになる。
【0083】
図3Bは、本発明による特定の実施形態での、開始ステップ321で始まる新規経路指定プロセス320の単純化した流れ図である。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。ステップ323では、クライアント・ホストは、特定のIPアドレス宛てのTCPパケットをサテライト・ゲートウェイに送信する。ある例では、サテライト・ゲートウェイは、前述の111Aと同様にすることができるが、他のものにすることもできる。決定ステップ325では、サテライト・ゲートウェイは、パケットを受信し、送信する前に、XTP接続を介してパケットを搬送すべきかどうかを判定する。XTPプロトコルの例を本明細書で説明したが、請求の範囲を制限するものではない。本発明のある実施形態に従って、どんな適切なサテライト・プロトコルも使用することができる。TCPパケットの宛先アドレスが、XTPプロトコル・フォーマットに変換されるように構成される場合、パケットは、ステップ331でXTPプロトコルに変換される。そうでない場合、パケットは、そのTCPフォーマットで、ステップ327への代替分岐を介して送信される。この決定プロセスによって、単一サテライト・ゲートウェイが、一部がXTPプロトコルと互換のゲートウェイを有し、他のサイトが対応するゲートウェイを含まない多数のリモート・サイトと通信するサイトに対して、本発明は有用である。加えて、本発明により、ネットワーク管理者の方針決定に基づいて、特定のアドレスをプロトコル変換用に構成し、他のアドレスを非変換用に構成することが可能となる。
【0084】
特定の実施形態では、本発明は、転送速度制御ステップ(ステップ327)も備えている。ステップ327では、サテライト装置を介する適切な、または所定のデータ通信速度を維持するために処理が実行される。ステップ327の処理は、サテライト・リンクに過負荷をかけることを回避するために、図1の105および103などのパケットのバッファリングを必要とする可能性がある。これは、図3C〜3Dに示すプロセスを使用して実施することができるが、このプロセスに限定されない。次いで、ステップ329では、送信側サテライト・ゲートウェイからサテライト・リンクをたどって送信されたパケットが接続に沿って送信される。次いで、ステップ333では、パケットがステップ331で変換された場合に、パケットがTCPに変換し戻される。次いで、ステップ335では、パケットがそのリモート宛先に送付される。単一サテライト・ゲートウェイが、一部がXTPプロトコルと互換であり、他のサイトが互換ではない多数のリモート・ゲートウェイと通信するサイトに対して本発明は特に有用である。ある構成ではサテライト・ゲートウェイごとに多数のリモート・サイトを有することができる。これらのサイトの一部は、インストールされたサテライト・ゲートウェイを有し、他のサイトはインストールされたサテライト・ゲートウェイを有さないようにすることができる。したがってリモート側では、サテライト・ゲートウェイが存在することができず、IP経路指定構成だけが存在する。このプロセスは、情報が宛先サーバ131に入ったときに経路指定を完了し(ステップ335)、宛先サーバ131は、宛先クライアントに情報を転送する。このプロセスは、接続が終了したときに停止する(ステップ337)。
【0085】
本発明による特定の実施形態では、TCP接続は、接続の宛先側可能な限り早く送らなければならないプロトコル・ヘッダ中の1つの情報を時々渡す。この1つの情報は、「緊急ポインタ」として知られる。実施形態の選択において、例えば図2のサテライト・ゲートウェイ203などの、クライアント側サテライト・ゲートウェイの部分であるTCP実装は、TCPヘッダからこの緊急ポインタを抽出することができる。しかし、このオぺレーションは、図2のシステムでは必要ではなく、請求の範囲を制限するものではない。例えば図2のTCPモジュール229などのTCPモジュールは、緊急ポインタを抽出することができ、サテライト・ゲートウェイ変換モジュールにそれを渡すことができる。サテライト・ゲートウェイ変換モジュールは、図2のサテライト・ゲートウェイ変換モジュール231またはその均等物でよい。緊急ポインタは、図2のサテライト・プロトコル・モジュール233またはその均等物などのサテライト・プロトコル・モジュールに渡される。次いで緊急ポインタは、サテライト・プロトコル・ヘッダ中で図2のサテライト・ゲートウェイ205または他の受信側サテライト・ゲートウェイなどのサテライト・ゲートウェイに搬送することができる。受信側サテライト・ゲートウェイでは、緊急ポインタは、図2のサテライト・プロトコル・モジュール247などのサテライト・プロトコル・モジュールによって抽出し、変換モジュール249または別のサテライト変換モジュールなどの変換モジュールに渡すことができる。変換モジュールは、TCPモジュール251などのTCPモジュールに緊急ポインタを送ることができる。次いでTCPモジュールは、サーバ207などの末端サーバに即時に送るために、TCPヘッダ中のそのターゲット・フィールドに緊急ポインタを取り込む。サーバに送るこのヘッダは、第2サテライト・ゲートウェイ・マシンにまだ到着していないデータ・ストリーム中の点を参照する。いくつかの実施形態では、適切な緊急ポインタ処理が誤動作を緩和する。
【0086】
図3Cは、本発明による特定の実施形態での図3Bのデータ通信速度制御ステップ327などのデータ通信速度制御プロセスの単純化した流れ図を示す。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図3Cは、着信パケットが到着する時にキューが空であるかどうかを判定する第1決定ステップ341を示す。現在好ましい実施形態では、高優先度(HIPRI)トラフィックを待ち行列化するキューと、「通常の」トラフィックを待ち行列化するキューの2つのキューがある。キューの数は、本発明による実施形態を直接的に拡張することによって、拡張または減少させることができることを当業者は理解されよう。キューが空である場合、処理は決定ステップ343に進む。そうでない場合、処理は、決定ステップ345に進む。
【0087】
決定ステップ343は、現システム・クロック・チック・カウントが格納されたクロック・チック・カウントと同じであるかどうかを判定する。システム・クロック・チックおよび格納されたクロック・チックが同じである場合、処理は決定ステップ394に進む。決定ステップ394は、ここでは「MAX」として示す所望の送信速度に基づいて、バイト・カウンタおよび着信パケットの長さが所定の最大値よりも大きいかどうかを判定する。最大値を超過しない場合、処理はステップ355に進む。ステップ355では、パケットが送信され、バイト・カウンタがパケット長だけ増分される。そうではなく、ステップ349で最大値を超過する場合は、処理は、ステップ357に進む。ステップ357では、MAXと、バイト・カウンタの現在の値との間の差が「EXTRA」として格納され、タイマをスタートさせることができる。次いで処理は、ステップ345に進む。そうではなく、ステップ343でクロック・チックと格納されたクロック・チックが異なる場合、処理はステップ347に進む。ステップ347では、バイト・カウンタがクリアされ、格納されたクロック・チックが更新される。次いで処理は、前述と同様にステップ355に進む。
【0088】
決定ステップ341がキューのうちの少なくとも1つが空でないと判定した場合、またはパケット長がステップ349でMAXを超えてバイト・カウンタを増加させた場合、決定ステップ345では、着信パケットが再送信であるかどうかの判定が行われる。パケットが再送信である場合、ステップ351では、パケットが高優先度(HIPRI)キューに加えられる。そうでない場合、ステップ353では、パケットが通常キューに加えられる。
【0089】
図3Dは、本発明による特定の実施形態での、図3Cで示したデータ通信速度制御プロセスと共に有用なタイマ・サービス・プロセスの単純化した流れ図を示す。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図3Dは、ステップ357でのタイマ・セットが満了するときにはいつでも起動されるステップ361を示す。ステップ341では、バイト・カウンタがクリアされ、ローカルの最大が、EXTRAに加えられる最大MAXに設定される。次いで、ステップ363では、高優先度(HIPRI)キューがチェックされ、パケットがキュー上にあるかどうかが判定される。パケットがHIPRIキュー上にある場合、処理は決定ステップ365に進む。そうでない場合、処理は、決定ステップ367に進む。
【0090】
HIPRIキュー上にパケットがある場合、決定ステップステップ365では、バイト・カウンタおよびパケット長がローカルの最大よりも小さいかどうかの判定が行われる。実際にこれが当てはまる場合、処理はステップ369に進む。ステップ369では、パケットがHIPRIキューから待機解除され、送信される。さらに、パケット中のデータの長さを反映するようにバイト・カウンタが増分される。そうでない場合、決定ステップ365は、バイト・カウンタおよびパケット長がローカルの最大を超過するかどうかが判定され、次いでステップ371ではタイマが再スタートし、処理は起動プロセスに戻る。処理は、タイマが満了するときに続行することができる。
【0091】
決定ステップ363がHIPRIキュー上にパケットが無いと判定した場合、処理は決定ステップ367に進む。決定ステップ367は、通常キュー上にパケットがあるかどうかを判定する。決定ステップ367が通常キュー上にパケットがないと判定した場合、処理はステップ375に進み、ステップ375では現クロック・チックがグローバル・セル中に格納される。そうでない場合、決定ステップ367が、パケットが通常キューであると判定した場合、処理は決定ステップ373に進む。決定ステップ373では、バイト・カウンタおよびパケット長がローカルの最大よりも小さいかどうかが判定される。実際にそうである場合、処理はステップ377に進む。ステップ377では、パケットが通常キューから待機解除され、送信される。さらに、バイト・カウンタがパケット中のデータの長さを反映するように増分される。そうでない場合、決定ステップ373がバイト・カウンタおよびパケット長がローカルの最大を超過するかどうかを判定し、ステップ379ではタイマが再スタートし、処理は起動プロセスに戻る。処理は、タイマが満了するときに続行することができる。
【0092】
図3Eは、本発明による特定の実施形態での代表的システムの概観を示す。このダイアグラムは、単に例示に過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。クライアント380は、TCPサーバ388への接続要求を開始する。サテライト・ゲートウェイ384は、接続要求をインターセプトし、第2サテライト・ゲートウェイ386との第2接続385を確立する。次いで第2サテライト・ゲートウェイ386は、サーバ388との第3接続387を開始する。接続387が確立され、情報がサテライト・ゲートウェイ384に戻されると、クライアント380とサテライト・ゲートウェイ384との間の第1TCP接続383を確認することができる。
【0093】
ある実施形態では、TCP接続がデータをクライアント380に送信するサテライト・ゲートウェイ384および/またはサテライト・ゲートウェイ386によってバッファに入れられるデータの集合量を制限するのに有用なデータ・フロー制御プロセス382が提供される。選択実施形態は、例えばデータがその接続上のクライアントに対してバッファに入れられたとき、TCP上のデータ・フローを制御することができる。図3Fからわかるように、データ・フロー制御プロセス382を介してクライアント380とサテライト・ゲートウェイ384との間で第1TCP接続383を確認することができる。選択実施形態では、データ・フロー制御プロセス382は、接続385の両側のサテライト・ゲートウェイ384およびサテライト・ゲートウェイ386に格納されるデータ量を制御する目的で、クライアントTCP接続383などのクライアントTCP接続がサテライト・ゲートウェイ384などのサテライト・ゲートウェイに送ることができるメモリ量を制限することができる。接続383内のクライアント380とサテライト・ゲートウェイ384との間に挿入された別々の制御プロセス382によって示したが、本発明は、他の形態でも実施することができる。例えば、制御プロセス382は、クライアント380のマシン内の第1サテライト・ゲートウェイ内に共通に位置するか、または別々のマシン内の第1サテライト・ゲートウェイ384などと共に配置することができる。
【0094】
サテライトおよびサテライト・ゲートウェイによって示したが、本発明は、他の形態のネットワーク・ハードウェアでも実施することができる。例えば、第1ゲートウェイ384および第2ゲートウェイ386を無線ネットワークなどによって接続することができる。
【0095】
図3Gは、本発明による特定の実施形態での接続フロー接続選択プロセスの単純化した流れ図を示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。当業者は、他の変形形態、修正形態、および代替形態を理解されよう。図3Gは、入力データ・フロー390を示す。決定ステップ391は、入力データ・フロー390が受信される接続が新しい接続かどうかを判定する。新しい接続である場合、この新しい接続は、フロー制御に対してマークされない。新しい接続でない場合、決定ステップ392では、接続に関連するバッファの内容のサイズがしきい値に対してチェックされる。バッファの内容がしきい値を超過する場合、ステップ393では、フロー制御制限計算に対して接続が選択される。そうでない場合、接続はフロー制御に対して選択されない。図3Gに示すステップは、初期化中またはデータを断続的に転送している接続を遮蔽する能力を有する実施形態を提供することができる。そのような接続は、フロー制御計算に対して選択される必要はない。そのような接続は、十分大きいシステム・リソースを消費しないからである。新しい接続は、データのしきい値量が新しい接続に対してバッファに入れられるまで、フロー制御計算に対して選択される必要はない。現在好ましい実施形態では、接続がメモリ中にデータのしきい値量をバッファに入れた場合に、しきい値に達する。この特定の実施形態では、しきい値量よりも小さいデータを送り、待機し、次いでより多くのデータを送信する接続は、フロー制御制限計算に対して選択する必要はない。データのしきい値量のうちのすべてが一度にメモリ中に常駐しないからである。しかし、別の実施形態では、バッファ中のデータの平均または特定の時間間隔にわたるデータのバッファ化した量は、本発明の範囲から逸脱することなく、接続上のフローを制御する基礎として使用することもできる。現在好ましい実施形態では、しきい値限界は、50Kバイトにすることができる。しかし、当業者は、本発明の方法およびシステムを他のしきい値に容易に適用することができる。
【0096】
図3Hは、本発明による特定の実施形態での、図3Fに示すサテライト・ゲートウェイ・システムに関して有用なデータ・フロー制御プロセスの単純化した流れ図を示す。このダイアグラムは、単なる例であって、本明細書の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図3Hは、特定の接続に対する入力データ・フロー394を示す。決定ステップ395は、入力データ394に対応する接続がフロー制御されているものかどうかを判定する。フロー制御されているものである場合、ステップ396ではリンクを渡ってデータのバイトを送信し、接続に対して送信し戻すための往復時間(RTT)を判定することがきる。往復時間は、ユーザからの入力によって、またはデータのサンプルの1つがリンクを横切る時間などを自動的に判定することができる。次いでステップ397では、接続に対するデータ通信速度、または帯域幅が判定される。データ通信速度は、ユーザからの入力によって、またはデータのサンプルの1つなどによって自動的に判定することができる。この実施形態では、ユーザは、転送速度および往復時間を別々の入力として入力する。しかし、他の実施形態も、ユーザが事前計算した帯域幅遅延積を入力することを可能とし、またはリンクを検出することによって往復時間を判定することができる。次いでステップ398では、帯域幅遅延積は、バイト単位のリンクの帯域幅に、往復時間を乗じることによって決定することができる。
【0097】
ステップ399では、接続に対するフロー制御制限を決定することができる。フロー制御制限は、接続に対するバッファへのデータ量などにすることができる。現在好ましい実施形態では、フロー制御制限は、図3Gで詳述した処理の間に選択される各アクティブ・データ接続に割り振られるメモリ量にすることができる。フロー制御制限は、帯域幅遅延積に倍数を乗じ、次いでその合計をアクティブデータ接続で除算することによって計算することができる。この倍数は、ネットワーク・リンクを完全に使用し続けるために、十分なデータをバッファに入れることが可能となるように選ばれる。現在好ましい実施形態では、倍数8が選ばれる。しかし、実施形態は、本発明の範囲から逸脱することなく、他の倍数またはスケーリング関数、あるいは複数の規格化因子の組み合わせを使用することができる。次いで、ステップ401では、接続上のデータを着信データを最大ステップ399によって決定される制限まで接続上のバッファに入れることによって、制限することができる。システムは、物理システム・メモリで利用可能な割り振られた空間よりも多くバッファリングすることを抑制することができる。
【0098】
本発明による多くの実施形態が、アクティブ接続の変更に適合することができることは注目に値する。1つの接続がアクティブである場合、その接続は、帯域幅全体の使用を許可されることになる。第2接続アクティブであるとき、フロー制御制限は、新しいデータが到着したときはいつでも、フロー制御制限を計算することによって、第1および第2接続のどちらに対しても調整することができる。この方式では、接続が確立された順番には関わりなく接続の間で帯域幅を割り振ることができる。加えて、本発明による実施形態により、1つの特定の接続からのデータのバーストが、他の接続についてのデータの前に、リンクを介する送信のために待ち行列化される可能性を低減させることによって接続間でサテライト・リンクを共用することが可能となる。これにより、ネットワーク・スループットが多数の接続にわたってより一貫したものとなる。
【0099】
図3Iは、本発明による特定の実施形態の代表的バッファ・アーキテクチャの単純化した構造構成要素ダイアグラムを示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図3Iは、サテライト・ゲートウェイ384を示す。サテライト・ゲートウェイ384は、接続383を介して図3Eのクライアント380などのクライアントとインターフェースをとるTCPバッファ405を備える。さらに、サテライト・ゲートウェイ384は、接続385を介して図3Eのサテライト101などのサテライトとインターフェースをとるサテライト・プロトコル・バッファ406を備える。サテライト・システム384を介するTCPは、サテライト・ゲートウェイ384中のTCPプロトコル層およびサテライト・プロトコル層によって制御される1つまたは複数のバッファ中に、データを一時的に格納することができる。例えば図3Eのクライアント380などの端点へのデータは、TCPバッファ405などの、1つまたは複数のTCPバッファから導出することができる。空間がTCPバッファ405中で利用可能となったとき、データは、サテライト・プロトコル・バッファ406からTCPバッファ405に転送することができる。空間がサテライト・プロトコル・バッファ406中で利用可能になったとき、サテライト・プロトコルにより、より多くのデータを例えば図3Eのサテライト・リンク385などのサテライト・リンクを介して送信することが可能となる。本発明による実施形態の適用の代表例では、サテライト・ゲートウェイ384などのサテライト・ゲートウェイは、複数のモデムにデータを供給することができる。モデム・リンクは、サテライト・リンクと同じ転送速度でデータを受諾することができない。そのような状況では、本発明による技術は、モデムについてのデータを保持する比較的大きな量のバッファ空間を消費することを回避することができる。
【0100】
図3Jは、本発明による特定の実施形態の代表的バッファ・アーキテクチャの単純化した構造構成要素ダイアグラムを示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図3Jは、例えば図3Iのサテライト・プロトコル・バッファ406中に常駐することができる出力データ402を示す。受諾可能な転送速度でデータがTCP層からエンド・クライアントに送達されていないとき、サテライト・リンク中の輻輳が生じる可能性がある。この輻輳は、サテライト・プロトコルによって決定ステップ403で検出することができる。決定ステップ403では、サテライト・プロトコルがサテライト・プロトコル・バッファ406の状態が飽和に達したかどうかを判定する。ある実施形態では、バッファに対してしきい値を確立することができる。このしきい値を超過することにより、飽和条件があることを示すことができる。プロトコル・バッファが飽和した場合、ステップ404では、サテライト・プロトコルは、サテライト・リンク385にわたって受け入れられることになるデータに対する最大受信ウィンドウを減少因子だけ減少させる。現在好ましい実施形態では、減少因子50%を使用することができる。特定の実施形態では、ウィンドウがゼロにまで減少しないことを保証するように、受信ウィンドウに対する最小値を構成することができる。そうでない場合、クライアントがシステムのデータ通信速度と互換のデータ通信速度で受信している場合、飽和条件には到達しないことになる。
【0101】
本発明による実施形態では、比較的遅いデータ通信速度を有する、例えばクライアント384などの受信側への接続は、フルサイズの受信ウィンドウで開始することができる。本発明による技術を用いて、受信ウィンドウは送信側のデータ通信速度と受信側のデータ通信速度との間の一致を達成するようにサイズ変更することができる。したがって、ある実施形態では、新しい接続は、システムがより低いデータ通信速度受験を検出し、追加の新しいデータが接続のためにバッファに入れられる量を制限する前に、メモリのフル・ウィンドウを消費する能力を有する。現在好ましい実施形態では、本発明の技術は、各サテライト接続に別々に適用することができ、その結果ある低速な受信側が同じリンクを介する他の接続の性能を低下させることがないことになる。
【0102】
図7は、本発明による特定の実施形態での代表的装置を示す。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図7は、プロトコル・ゲートウェイ111Aなどの、本発明による特定の実施形態でのプロトコル・ゲートウェイのブロック・ダイアグラムを示す。プロトコル・ゲートウェイ111Aは、中央処理装置114などの主要なサブシステムと相互接続するバス112と、システム・メモリ116(一般にはRAM)と、表示アダプタ126を介する表示画面124、キーボード132、および入出力コントローラ118を介するマウス146、フロッピィ・ディスク138を受けるように動作するフロッピィ・ディスク・ドライブ136などのいくつかの追加の外部装置を含む。記憶インターフェース134は、固定ディスク・ドライブ144への記憶インターフェースとして動作することができる。CD−ROM142を受け入れるように動作する任意選択のCD−ROMプレーヤ140も含むことができる。フラッシュ・メモリ147などの他の形態の記憶装置も含むことができる。ネットワーク・インターフェース148Aは、電話線を介するリモート・サーバへの直接接続、またはTCP/IPなどの共通プロトコルを使用するインターネットへの直接接続を実現することができる。ネットワーク・インターフェース148Aは、1つまたは複数の外部ネットワークとインターフェースをとることができる。その外部ネットワークは、イーサネット、トークン・リング、ATM、IEEE 802.3、X.25、シリアル・リンク・インターネット・プロトコル(SLIP)、FDDIなどの、当技術分野で周知の何らかのネットワーク・フォーマットを利用することができる。ネットワーク・インターフェース148Bは、サテライト・ゲートウェイ109A、あるいは他のネットワーク相互接続装置またはコンピュータ・システムなどのサテライト・ゲートウェイに接続することもできる。ネットワーク・インターフェース148Aは、1つまたは複数の外部ネットワークとインターフェースをとることができる。その外部ネットワークは、イーサネット、トークン・リング、ATM、IEEE 802.3、X.25、シリアル・リンク・インターネット・プロトコル(SLIP)、FDDIなどの、当技術分野で周知の何らかのネットワーク・フォーマットを利用することができる。多くの他の装置またはサブシステム(図示せず)も、同様に接続することができる。さらに、以下で論ずるように、本発明を実施するためには、図7に示す装置のすべてが存在する必要はない。この装置およびサブシステムは、様々な実施形態において、図7に示すのとは異なる方式で相互接続することができる。本発明を実装するコードは、システム・メモリ116、固定ディスク144、CD−ROM140、またはフロッピィ・ディスク138などのコンピュータ可読格納媒体中に操作可能に配置または格納することができる。
【0103】
システム111Aは、本発明を実施する構成の単なる1つの例である。多くのシステム・タイプ、構成、および上記装置の組み合わせが、本開示に照らした使用に適していることは当業者には明らかであろう。
【0104】
上記は、特定のシステム、方法、および実施形態により本発明を一般的に説明したが、本発明は、より広い範囲の適用可能性を有する。具体的には、本発明はサテライト通信に限定されず、改良および最適化プロトコルをネットワークの特定の部分を介して使用することが望ましく、エンド・システムが改良プロトコルを使用するために更新することができないどんなネットワーキング状態にも適用することができる。したがって、ある実施形態では、サテライト・ゲートウェイは、すべての種類の無線または有線ネットワークおよびインターネットワークへのアクセスを提供することができる。もちろん、当業者は他の変形形態、修正形態、および代替形態を理解されよう。
【0105】
実験:
このシステムの原理およびオペレーションを検証するために、実験を実行した。この実験では、従来のTCPと本発明とを多様な異なるTCPウィンドウ・サイズ、リンク帯域幅、往復遅延時間、およびビット・エラー率にわたって比較する一連の単一クライアントFTPファイル転送スループット・テストを実行した。1つの実験では、例えば図4のダイアグラム400で示すように、「ウィンドウ・サイズ」を「スループット」に対して比較した。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。性能向上またはTCPウィンドウ・サイズ・チューニングを行わない場合、大部分のクライアントは、往復時間が540msのときにスループット速度が100Kbpsに制限された。図4のデータが示すように、32KBウィンドウを有するクライアントでも、単にスループット400Kbpsにしか到達することができなかった。このシステムにより、クライアントまたはサーバのウィンドウ・サイズに関わらず、クライアントが利用可能帯域幅を利用することが可能となった。
【0106】
代替実験では、例えば図5の単純化したダイアグラム500に示すように、「往復遅延」が「スループット」に対して解析された。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。ここで、本発明は、ネットワークの往復時間へのTCPの依存を除いた。性能は、エラーのない対称2Mbpsおよび10Mbpsリンクを介して測定された。TCPは、地上低遅延ネットワークを完全に飽和することができるが、遅延が増加するにつれてTCP性能は急速に降下することをこれらの結果は示した。それとは対称的に、このシステムを使用したネットワークは、ネットワークの往復時間に関わらず、リンクのほぼ完全な使用を維持することができた。
【0107】
代替実験では、「ビット・エラー率」が、例えば図6の単純化したダイアグラム600によって示される「スループット」に対してモニタされた。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。本発明を取り込んだネットワークは、リンクのビット・エラー率にも敏感である。このダイアグラムは、スループットを、往復時間540msおよびTCPウィンドウ・サイズ1MBの対称10Mbpsサテライト・ネットワークに対するビット・エラー率の関数として示す。低エラー率であっても、TCPは、1.2Mbpsしか送ることができなかった。エラー率1.0×10-5では、TCPのスループットは、0.05Mbpsに落ち込んだ。本発明を使用したネットワークは、低エラー率でリンクを完全に飽和し、エラー率1.0×10-5でも2.7Mbpsを送ることができた。
【0108】
上記は、特定の実施形態の完全な説明であるが、様々な修正形態、代替構造、および均等物を使用することができる。例えば、上記は、XTPをサテライト・プロトコルとして使用することによって一般に説明した。他のタイプのプロトコルも利用可能である。例えば、プロトコルは、修正したTCPなどを含むことができる。したがって、前述の説明および図示は、添付の請求の範囲によって定義される本発明の範囲を限定するものとして用いたのではない。
【図面の簡単な説明】
【図1】 本発明の一実施形態によるサテライト・システムの単純化した図である。
【図2】 本発明の一実施形態によるシステム・アーキテクチャの単純化した図である。
【図2A】 本発明の一実施形態によるシステム・アーキテクチャの単純化した図である。
【図3A】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3B】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3C】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3D】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3E】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3F】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3G】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3H】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3I】 本発明の一実施形態によるプロセス図の単純化した図である。
【図3J】 本発明の一実施形態によるプロセス図の単純化した図である。
【図4】 本発明の一実施形態による実験データの単純化した図である。
【図5】 本発明の一実施形態による実験データの単純化した図である。
【図6】 本発明の一実施形態による実験データの単純化した図である。
【図7】 本発明の一実施形態によるゲートウェイ・インターフェースの単純化した図である。[0001]
(Cross-reference of related applications)
This application was filed on February 2, 1999, Jerome D. Claimed priority of US Provisional Patent Application No. 60/118227 (Docket No. 16625-001100) filed in the name of Toporek et al. And entitled “Internet Over Satellite Apparatus”, the complete disclosure of which is hereby incorporated by reference, Incorporated herein.
[0002]
This application also claims priority from the following five shared copending applications, which are also incorporated herein by reference in their entirety:
1. February 2, 1999, Jerome D. US patent application Ser. No. 09/243185 filed in the name of Toporek et al. And entitled “Internet Over Satellite System” (Docket No. 16625-001200)
2. February 2, 1999, Jerome D. US patent application Ser. No. 09/243554 (Docket No. 16625-001300) filed under the name of Toporek et al. And entitled “Internet Over Satellite Method”
3. On May 6, 1999, Jerome D. US patent application Ser. No. 09/306678 filed in the name of Toporek et al. And entitled “Method and System for Managing Memory in an Internet Over Satellite Connection” (Docket No. 16625-001210)
4. May 6, 1999, Jerome D. US patent application Ser. No. 09/306236 filed in the name of Toporek et al. And entitled “Method and System for Controlling Data Flow in an Internet Over Satellite Connection” (reference number 16625-001220)
5. January 28, 2000, Jerome D. US patent application ________ (Docket No. 16625-001110) filed in the name of Toporek et al., Entitled “Internet Over Satellite Apparatus”, which also claims the priority of US Provisional Patent Application No. 60/118227
[0003]
(Background of the Invention)
The present invention relates to devices, systems, and techniques for telecommunications. More particularly, the present invention uses a TCP connection through a satellite system to manage memory and / or transmit information for use within a wide area network of computers such as the Internet. An apparatus, system, and method are provided. The present invention provides high-speed, high-quality transmission of signals to remote locations via satellite systems using, for example, the Xpress Transport Protocol (herein “XTP”) protocol. The present invention also provides controlled memory management within the device for high speed, high quality transmission of signals to remote locations, for example, via satellite systems using the XTP protocol. However, it should be understood that the present invention has a much wider range of applicability. This can also be applied to dedicated bridged networks, terrestrial wireless network links, etc.
[0004]
The Internet is an international “super network” that connects millions of individual computer networks and individual computers together. The Internet is generally not a single entity. It is a very diffuse and complex system where no single entity has full authority or control. The Internet is widely known as one of the methods of providing information over the World Wide Web (herein “Web”), but based on common Internet protocols and infrastructure There are currently many other services available.
[0005]
The web is generally easy to use for people who are not familiar with computers. Information on the web includes graphics and text, including “links” to other pages in the same set of data files (ie web sites) or in data files on other computer networks. Can be provided on a “page”. Users can often access information on the web using a “browser” program such as the Netscape Communication Corporation of Mountain View, Calif., Or the Microsoft Corporation of Redmond, Washington. The browser program processes information from the web site and displays the information using graphics, sound, and animation. Thus, the web has become a popular medium for advertising goods and services to consumers.
[0006]
The Internet supports many other forms of communication. For example, the Internet typically allows one-to-one communication via email, known as “e-mail”. The Internet also has a “bulletin board” that is used by users to post colorful text and graphics that other people read and respond to. For real-time communication, the Internet has a “chat room” and the like. Users can communicate with each other using these typed messages. In some cases, the Internet can also be used for voice communication between users. All of these types of communication are possible, at least in part, using critical connections, which allow information to be transmitted from many different servers on the Internet.
[0007]
The Internet is based on the TCP / IP protocol. At the network layer, an Internet protocol known as IP provides a mechanism for sending addressed packets to individual computers. The Internet has multiple computer systems that implement IP, which are typically interconnected to each other using a local area network and a dedicated transmission line to create a wide area network of computers. Form. An IP packet is delivered on a best effort basis and is not guaranteed to arrive at its intended destination, which is known as an “unreliable” service.
[0008]
For many applications that require reliable data delivery services, the Internet uses a connection mechanism called a transmission control protocol known as TCP. TCP has various desirable properties that make it suitable for communicating over the Internet. For example, TCP considers data of the data size or optimal size segment transmitted from the transmission server to the reception server via the communication medium. In addition, TCP maintains a timer. This waits for the receiving server to send an acknowledgment of receipt of the data segment from the sending server. If the timer times out before an acknowledgment is received, TCP retransmits the data segment, which provides communication reliability. TCP also maintains a checksum on its header and data. This monitors any changes in the data being transferred. If the data arrives with an invalid checksum, TCP discards the data and does not recognize that it has been received. If data segments arrive out of order, TCP can also recombine them in order at the receiving server. In addition, TCP provides flow control. This ensures that only a finite amount of data is sent to the buffer on the receiving server. This prevents the high speed server computer from overflowing all buffers on the slower server computer.
[0009]
TCP is well suited for transmitting Internet data between servers connected to each other using conventional telephone systems and telephone lines with similar characteristics, but also has many limitations. For example, TCP is suitable for “short hops” but often slows down communications over very long distances (eg, intercontinental hops over satellites) that can have significant latency. In this case, the flow control function and the acknowledgment function take too long to send and receive, which slows down the communication. In addition, there are still opportunities to increase efficiency. In particular, TCP has proven to be slow and is cumbersome for the transmission of Internet data over, for example, a satellite network. In addition, high speed transmission of Internet data over a satellite network to a relatively slow receiver, such as a modem, can cause congestion. Furthermore, abnormal conditions can occur in networking using satellites that can cause resource exhaustion in the system leading to further slowdown of the TCP connection. In addition, networking using satellites often encounters considerable bit error rates that lead to further slowdown of TCP connections. These and other limitations are more fully illustrated by the following figure.
[0010]
In view of the foregoing, a more efficient way of transporting Internet services over a large geographical area using wireless communication media and a more efficient way of managing memory in its transmission are highly desirable.
[0011]
(Summary of Invention)
In accordance with the present invention, techniques are provided for improving TCP performance over a wireless wide area network. In an exemplary embodiment, the present invention provides an apparatus, system, and method for converting information using a TCP connection into, for example, an Xpress Transport Protocol (herein “XTP”) connection; The latter connection is more suitable for transmission over a wireless network system such as a satellite system.
[0012]
In accordance with the present invention, a technique for controlling information flow over a TCP connection and a memory for storing information communicated over one or more TCP connections over a wireless wide area network are managed. Techniques to do so are provided. In an exemplary embodiment, the present invention provides a method for controlling the buffering of information and / or the rate at which information flows over a TCP connection, eg, to an Xpress Transport Protocol (herein “XTP”) connection. And provide system.
[0013]
In certain embodiments, the present invention provides a communication device for transmitting information over a satellite link. The apparatus includes a TCP interface coupled to the satellite gateway interface for providing bi-directional flow information having data and headers using a TCP connection. By way of example only, bi-directional flow information may be from the Internet, or an Internet-like network of computers, or any network using the TCP / IP protocol. The apparatus also includes a processor that converts information to a satellite protocol for transmission over the satellite link using a TCP connection. This satellite protocol has the appropriate characteristics for the transmission of such information over satellite links. This protocol can include, among others, XTP, XTP-like protocols, and the like.
[0014]
In an alternative embodiment, the present invention provides a communication device for establishing multiple connections for the transmission of information over satellite links using TCP connections. The apparatus includes a TCP interface for forming a first communication connection between a first client (eg, a user computer) and a first satellite gateway. The apparatus also includes a satellite gateway interface for forming a second communication connection between the first satellite gateway and the second satellite gateway via the satellite link. Information describing the characteristics of the first connection (eg, source and destination IP addresses and port numbers) is transmitted to the second satellite gateway. A third communication connection is formed between the second satellite gateway and the destination server. The combination of these connections forms a transparent connection from the original first client to the destination server.
[0015]
In certain embodiments, the present invention provides a communication system for transmitting information over a satellite link. The system includes a first gateway having code for providing bi-directional flow information having data and a header, the first gateway being coupled to a TCP connection. By way of example only, bi-directional flow information may be from the Internet, or an Internet-like network of computers, or any network using the TCP / IP protocol. The system also includes code for converting information from the TCP protocol into a satellite protocol for transmission over the satellite link. The system also includes a second gateway for receiving information from the first gateway via the satellite link. The second gateway also includes code for converting information from the satellite protocol having appropriate characteristics for transmission over the satellite link to the TCP protocol. This satellite protocol may include, among others, XTP, an XTP-like protocol, and the like.
[0016]
In an alternative embodiment, the present invention provides a communication system in which multiple connections can be established for transmission of information over satellite links using TCP connections. The system includes code for intercepting a first communication connection between a first client (eg, a user computer) and a first satellite gateway. The system also includes code for forming a second communication connection between the first satellite gateway and the second satellite gateway via the satellite link. Information describing the characteristics of the first connection (eg, source and destination IP addresses and port numbers) is transmitted to the second satellite gateway. A third communication connection is formed between the second satellite gateway and the destination server. The combination of these connections forms a transparent connection from the original first client to the destination server.
[0017]
In certain embodiments, the present invention provides a communication method for transmitting information over a satellite link. The method includes providing information of a bidirectional flow having data and a header using a TCP connection. By way of example only, bi-directional flow information may be from the Internet, or an Internet-like network of computers, or any network using the TCP / IP protocol. The method also includes converting the information into a satellite protocol for transmission over the satellite link using a TCP connection. This satellite protocol has the appropriate characteristics for the transmission of such information over satellite links. This protocol can include, among others, XTP, XTP-like protocols, and the like.
[0018]
In an alternative embodiment, the present invention provides a communication method for establishing multiple connections for transmission of information over satellite links using TCP connections. The method includes intercepting a first communication connection between a first client (eg, a user computer) and a first satellite gateway. The method also includes forming a second communication connection between the first satellite gateway and the second satellite gateway via the satellite link. Information describing the characteristics of the first connection (eg, source and destination IP addresses and port numbers) is transmitted to the second satellite gateway. A third communication connection is formed between the second satellite gateway and the destination server. The combination of these connections forms a transparent connection from the original first client to the destination server.
[0019]
In certain embodiments, the present invention provides a method for buffering information communicated over an Internet connection established to manage memory and over a satellite link. The method includes: one or more clients, one or more servers, a first gateway connected to at least one client, a second gateway connected to at least one server, and between these gateways Can be run on a wide variety of systems, such as systems that include multiple wireless telecommunications links. The method includes intercepting a connection attempt with a server initiated by a client. The client attempts a connection that will have a first characteristic data rate. A connection is established between the first gateway and the second gateway via a telecommunications link, which can be a satellite link or the like. This connection will have a second characteristic data transmission rate. The first gateway includes a buffer for storing information received from the second gateway via the telecommunications link and a buffer for storing information transmitted to the client. The method can perform the step of determining the state in the receive buffer. The state can indicate whether the characteristic data communication rate within the telecommunications link is significantly higher than the characteristic data communication rate for the client. The step of setting a receive window size for the client at the first gateway so as to reduce the amount of data received over the telecommunications link for the client may also be part of the method. The combination of these steps can provide a way to manage the memory to buffer information coming from the telecommunications link in the first gateway.
[0020]
In another aspect of the invention, a system for controlling the flow of information through a satellite is provided. The system may include at least one client selected from a plurality of potential clients and at least one server selected from a plurality of potential servers. The system may also include a first gateway connected to the client by a first telecommunications link and a second gateway connected to the server by a second telecommunications link. A third telecommunications link connecting the first gateway and the second gateway can also be part of the system. The system operates to intercept a connection attempt with a server initiated by a client at a first characteristic data rate. The system can then establish a connection between the first gateway and the second gateway via the third telecommunications link. This connection will have a second characteristic data transmission rate. The first buffer stores information received via the third telecommunications link, and the second buffer stores information transmitted to the client. The system can determine the state in the first buffer. The state indicates that the second characteristic data communication rate in the third telecommunications link is higher than the first characteristic data communication rate for the client. The system can also set a receive window size for the client at the first gateway to reduce the amount of data received via the third telecommunications link for the client.
[0021]
In a further aspect according to the present invention, a computer program product for controlling the flow of information over a wireless data link is provided. This data link may include one or more connections. The computer program product includes a computer readable storage medium that retains a plurality of codes. Code for intercepting a connection attempt with the server at the first characteristic data rate initiated by the client is included in the program product. Also included is a code for establishing a connection between the first gateway and the second gateway at a second characteristic data rate over a telecommunications link. A first buffer in the first gateway stores information received via the telecommunications link, and a second buffer stores information sent to the client. The product also includes code that determines the state in the first buffer. That state indicates a situation in which the characteristic data rate of the telecommunications link is significantly higher than that of the client. If this situation is detected, the product calls code that sets the receive window for the client at the first gateway so as to reduce the amount of data received over the telecommunications link for the client.
[0022]
In certain embodiments, the present invention provides a method for controlling the flow of information over an internet connection established over a satellite link. The method includes: one or more clients, one or more servers, a first gateway connected to at least one client, a second gateway connected to at least one server, and between these gateways Can be implemented on a wide variety of systems, such as systems including multiple wireless telecommunications links. The method includes intercepting a connection attempt with a server initiated by a client. The connection may be established between the first gateway and the second gateway via a telecommunications link that may be a satellite link or the like. The method may include determining the round trip time it takes for the data to travel over the connection from the client to the server. The data communication speed related to the connection can be determined. From the round trip time and the data rate, the bandwidth-delay product can be determined by this method. The method can also determine a flow control limit for the connection from the bandwidth delay product. The step of limiting data transfer over the connection based on flow control restrictions may be part of the method. Such a combination of steps provides a way to control the flow of TCP data over a network over a large geographic area, such as using wireless communication media.
[0023]
In another embodiment, the present invention can select from the connections that may benefit the system resources available by being flow controlled. Some implementations screen for connections that are not in the process of initializing, or connections that are transferring data in blocks, below or above the threshold for flow control, etc. Can do. In many implementations, the bandwidth delay product for a connection is determined by multiplying the round trip time by the data communication rate. In some implementations, the flow control limit for a connection is determined by multiplying the bandwidth delay product by a factor and dividing it by the number of connections for that link.
[0024]
In another aspect of the invention, a system for controlling the flow of information through a satellite is provided. The system includes at least one client selected from a plurality of potential clients and at least one server selected from a plurality of potential servers. The system may also include a first gateway connected to the client by a first telecommunications link and a second gateway connected to the server by a second telecommunications link. A third telecommunications link connecting the first gateway and the second gateway can also be part of the system. The system operates to determine the round trip time it takes for data to travel from a client over a first telecommunications link, a second telecommunications link, and a third telecommunications link to a server. . The system can determine the data communication speed for the connection. Furthermore, the system can determine the bandwidth delay product from the round trip time and the data communication speed. The system can determine a flow control limit for the connection from the bandwidth delay product and limit data transfer over the connection based on the flow control limit. Limiting data transfer in such a manner can interface, for example, a relatively high speed data transfer over a telecommunications link to a relatively slow data transfer at the client.
[0025]
In a further aspect according to the present invention, a computer program product for controlling the flow of information over a wireless data link is provided. A data link may include one or more connections. The computer program product includes a computer readable storage medium that retains a plurality of codes. Code that determines the round trip time it takes for data to cross the wireless data link over the connection may be part of the product. In addition, the computer program product can include code for determining a data communication rate for the connection. Also included is a code for determining a bandwidth delay product from the round trip time and the data communication speed. The code that determines the flow control limit for the connection from the bandwidth delay product, and the code to limit data transfer over the connection based on the flow control limit, may also be part of the computer program product. .
[0026]
In another aspect of the present invention, techniques are provided for matching the data rate of information, such as satellites, that flow through a given point in a network to the data rate capability of a remote point on that network. In one embodiment, the present invention provides transfer rate control to maintain an appropriate data rate or a predetermined data rate through the satellite device. This transfer rate control provides multiple queues for buffering incoming data. Incoming data is checked against a predetermined length. Data that exceeds the predetermined length is stored in the queue. At predetermined intervals, information is removed from one or more queues and transmitted along the outgoing data path. This process allows the system according to the present invention to provide data rate control through a specific point along the network, such as a satellite link.
[0027]
In another aspect of the present invention, a communication system for transporting packetized information between a client and a server in the TCP protocol is transported, and a packetized information in a satellite protocol between the client and the server is transported. The method of converting to a system comprising: installing a first gateway operatively configured to intercept a client to server connection. The first gateway can further convert the packetized information from the TCP protocol to the satellite protocol. The method also includes the step of establishing a second gateway that can establish a connection with the server and that is operatively configured to convert the packetized information from the satellite protocol to the TCP protocol. included. The first gateway and the second gateway can establish a connection via a common telecommunications link. The combination of these elements can provide a way to convert a system for TCP telecommunications to satellite protocol communications.
[0028]
Using the present invention, a number of advantages over conventional techniques are realized. In certain embodiments, the present invention provides higher throughput than conventional systems. In addition, the present invention provides a method for transparently improving TCP performance over satellite networks. In other embodiments, the present invention provides a novel protocol suitable for the long latency, high loss, and asymmetric bandwidth requirements typical of satellite communications.
[0029]
In certain embodiments, the technique according to the present invention resizes the receive window quickly to provide a match between the data rate of the sender and the data rate of the receiver of the TCP connection over the satellite link. Can be realized. In some implementations, the techniques of the present invention can be provided separately for each satellite connection so that one slow receiver does not degrade the performance of other connections over the same link. . In some embodiments, the present invention provides buffer memory management with a novel protocol suitable for the long latency, high loss, and asymmetric bandwidth requirements typical of satellite communications. In certain embodiments, the present invention provides a more even distribution of network resources than conventional systems. Many embodiments according to the present invention provide for sharing network links / satellite links between connections. In many implementations, a burst of data from one particular connection is less likely to be queued for transmission over the link prior to data for the other connection. In other embodiments, the present invention provides data flow control with long latency, high loss, and asymmetric bandwidth conditions typical of satellite communications.
[0030]
The present invention also provides a relatively simple implementation within, or a relatively simple interface to, conventional satellite systems. Depending on the implementation, one or more of these advantages may exist. These and other advantages and benefits are described throughout this specification and are described in greater detail below.
[0031]
These and other embodiments of the present invention will be described in more detail in connection with the following text and accompanying figures.
[0032]
(Description of specific embodiments)
Before discussing the various embodiments, it will be helpful to the reader to understand more fully the limitations of using TCP over a satellite network. This limitation is described more fully below.
[0033]
Congestion Avoidance: In order to avoid the possibility of congestion network meltdown, TCP generally assumes that all data loss is caused by congestion and responds by reducing the transmission rate. However, over satellite links, TCP often misinterprets long round trip times and bit errors as congestion and responds inappropriately. Similarly, the TCP “slow start” algorithm prevents new connections from flooding already congested networks over the terrestrial infrastructure and overloads each new connection over satellites. Force a long ramp-up. These congestion avoidance mechanisms are important in routing environments, but are often inappropriate for satellite links.
[0034]
Data Acknowledgment: The simple and heuristic data acknowledgment scheme used by TCP is generally not very well suited for long latency or very asymmetric bandwidth conditions. To ensure reliable data transmission, TCP receivers often send continual acknowledgments for data sent back to the sender. The sender typically does not assume that any data is lost or corrupted until a number of round trip times have elapsed without receiving an acknowledgment. If a packet is lost or corrupted, TCP retransmits all of the data starting with the first missing packet. The algorithm cannot respond well over satellite networks with long round trip times and high error rates. In addition, a constant stream of acknowledgments often wastes valuable back channel bandwidth. If the back channel bandwidth is small, the return of acknowledgment to the sender may be a system bottleneck in some cases.
[0035]
Window size: TCP uses a sliding window mechanism to limit the amount of data in flight. If the window is substantially full, the sender stops sending data until it receives a new acknowledgment from the destination server. Through a satellite network with slow acknowledgment return, the TCP window size generally sets tight limits on the maximum data throughput rate. The minimum window size, often known as “bandwidth delay product”, that is often necessary to fully utilize error-free links is, for example, 100 Kbytes for T1 satellite links and for 10 MBps links. It is 675K bytes. Bit errors can further increase the required window size. However, most TCP / IP implementations are often limited to a maximum window size of 64 KB, and many common operating systems use only a default window size of 8 KB, regardless of the data pipe bandwidth. The maximum throughput rate over the satellite link is 128 Kbps per connection.
[0036]
According to the present invention, a technique for performing TCP connection via a wide area wireless network is provided. In an exemplary embodiment, the present invention provides an apparatus, system, and method for transforming information using a TCP connection to an XTP connection. XTP connections are more suitable for transmission over wireless network systems such as satellite systems.
[0037]
Furthermore, according to the present invention, there is provided a technique for controlling information flow during TCP connection and managing memory for one or more TCP connections via a wireless wide area network. In an exemplary embodiment, the present invention provides a method and system for controlling memory management for information flow and / or buffering information transmitted over a wireless network system. XTP connections are more suitable for transmission over wireless network systems such as satellite systems. Details of the present invention will be described more specifically below throughout this specification.
[0038]
FIG. 1 is a simplified diagram of a
[0039]
The
[0040]
The
[0041]
In certain embodiments, the
[0042]
Although described above in terms of a particular networking diagram, other configurations can implement this satellite gateway. For example, the satellite gateway may be a single “hub” or central gateway that acts as multiple remote gateways. Each remote gateway is connected to a central gateway and an individual satellite link is created.
[0043]
Other common network topologies can also be used. Further, in certain embodiments, different telecommunication links can be used to carry the forward or reverse path of the connection. For example, a satellite link can be used to carry data on the forward path while simultaneously using a telephone line for the reverse path. The exemplary hardware described herein can be replaced with other types of telecommunications hardware without departing from the scope of the present invention.
[0044]
In addition, the satellite gateway is generally described as a stand-alone unit. However, it will be appreciated that this gateway can be implemented or integrated into the client machine. For example, the gateway can be implemented on a personal computer using a satellite card. This satellite card can be inserted into a Windows ™ 98 machine. This gateway can also be implemented on other operating systems such as Windows NT, MacOS, and Linux. Of course, the exact implementation will depend on the application. In addition, the satellite gateway can be integrated into a stand-alone satellite modem, VSAT hardware, router, or other network device.
[0045]
I. Protocol design
In certain embodiments, the present invention includes a novel satellite protocol that improves throughput for satellite networks. The protocol can be designed to respond effectively to typical satellite latency, bit errors, and asymmetric bandwidth conditions. This protocol can also take advantage of optimizations possible over point-to-point links with fixed bandwidth. More detailed information on satellite protocols such as XTP can be obtained from Tim Strayer's “A Brif Induction to the Xpress Transport Protocol,” which is practically incorporated herein by reference in its entirety. These and other features of this satellite protocol are described in more detail below.
[0046]
This protocol utilizes a selective retransmission algorithm for effective data acknowledgment. For point-to-point links where hops through satellites do not use intermediate routing, it can be assumed that any gaps in the packet are data loss due to corruption. When the receiving satellite gateway detects missing data from the transmitting satellite gateway, it immediately requests retransmission.
[0047]
This protocol is virtually unconstrained by the frequent acknowledgment function of traditional TCP. In some embodiments, this protocol does not use an acknowledgment function as the primary means of identifying lost data. In these embodiments, all that is needed in this protocol is a low frequency acknowledgment function that clears data arrivals and buffers. (Traditional TCP sends a constant stream of acknowledgments over the reverse channel.) This protocol reduces back channel usage by over 70%, thereby reducing the limited back channel bandwidth to the system bottle. Improve the performance of the network that is the bottleneck.
[0048]
This protocol provides a window size that is large enough to transfer data between satellite gateways. Because the bandwidth delay product across satellites between satellite gateways is much larger than the bandwidth delay product from satellite gateways to end nodes, this large protocol window generates bandwidth delays relative to the window size ratio. Can remain relatively constant. This gateway serves as a buffer for the network and enables high throughput independent of the client and server window sizes.
[0049]
This protocol generally does not use unnecessary congestion avoidance mechanisms for hops between satellites between satellite gateways, but it does not use "slow start" for ground connections between this gateway and end nodes and all Continue to use other standard TCP congestion avoidance algorithms. This protocol can also use a streamlined handshake mechanism to reduce the number of round trips required for connection setup.
[0050]
The apparatus, system, and method can be performed over IP to be compatible with a routing network. Alternatively, the device can be run directly through the link layer to substantially improve performance in most cases. Depending on the embodiment, one or more of these functions may be utilized.
[0051]
The above has been generally described by the desirable features of the satellite protocol. It will be appreciated that many other types of features are available. In addition, the present invention does not necessarily require the features described above. Any combination can be used depending on the application. Other variations, modifications, and alternatives will be appreciated by those skilled in the art.
[0052]
II. XPRES transport protocol
In a preferred embodiment, the present invention provides an “Xpress transport protocol” commonly known as XTP. XTP provides orthogonal protocol functions for implementation separation from policy, transfer rate and flow control separation, explicit first class support for multicast, and data delivery service independence. XTP has various features that are suitable for transmission of data over satellite links, which are described more fully below.
[0053]
In certain embodiments, the protocol includes a set of mechanisms whose functionality is orthogonal. The most notable effect is that XTP decouples communication mechanisms (eg, datagrams, virtual circuits, transactions, etc.) from the error control policy used (unmodified and fully reliable). In addition, flow and transfer rate control and error control can be adjusted at hand for communication. If desired, any set of these control processes can be turned off.
[0054]
The protocol also provides separation of transfer rate and flow control. In general, flow control operates on an end-to-end buffer space. Transfer rate control is a producer / consumer concept that takes processor speed and congestion into account. TCP does not provide transfer rate control and uses slow start and other heuristics to deal with congestion. XTP provides a mechanism for forming transfer rate control and flow control independently.
[0055]
In certain embodiments, the protocol provides explicit multicast support. Here, multicast is not an additional part in XTP. Each mechanism used for unicast communication can also be used for multicast.
[0056]
The protocol also has data delivery service independence. Specifically, XTP is a transport protocol, but with the advent of switching networks rather than routing networks, traditional networking layer services may not be appropriate in every example. XTP generally requires framing and sending packets from an XTP-equipped host with an underlying data delivery service to another XTP-equipped host. This may be raw MAC or IP or AAL5. XTP also utilizes parametric addressing, allowing packets to be addressed in any one of several standard addressing formats. Other features of XTP include, among other things, implicit fast connection setup for virtual circuit paradigms, key-based addressing lookups, message priority and scheduling, support for encapsulation and convergence protocols, selective retransmission and acknowledgment, and fixed A size 64 bit alignment frame design is included.
[0057]
XTP defines the mechanisms necessary to send user data from one end system to one or more other end systems. Each XTP implementation maintains its communication state. A well-defined packet structure containing user data or control information is exchanged to implement the transfer of user data. The control information is used to provide the exact required layer and help to make the transfer effective. Accuracy guarantees are made through error control algorithms and connection state machine maintenance. Flow and transfer rate control algorithms, certain protocol modes, and traffic shaping information are used to provide the requested quality of service as effectively as possible.
[0058]
A collection of information including XTP state at the end system is called a context. This information represents one instance of two (or more) active communications. The context should be created and instantiated before sending or receiving XTP packets. There may be many active contexts for each active conversation or message at the end system.
[0059]
Each context manages both outgoing and incoming data streams. A data stream is an arbitrary length string of consecutive bytes, each byte represented by a sequence number. The collection of active context pairs and the data stream between them is called an association.
[0060]
The context at the end system is initially stationary. A user who needs a communication service requests that the context be placed in a listening state. The context then listens for the appropriate FIRST packet. The FIRST packet is an initial packet for association. The FIRST packet includes explicit addressing information. The user provides all of the information necessary for XTP to match the incoming FIRST packet with the listening context.
[0061]
In another end system, the user requests a communication service from XTP. Since this user initiates the association, the context moves directly from the quiescent state to the active state. The active context constructs a FIRST packet and completes with explicit addressing information from the user. The FIRST packet is transmitted via the underlying data delivery service.
[0062]
When the FIRST packet is received at the first host's XTP implementation, the address is compared against all listening contexts. If a match is found, the listening context moves to the active state. From this point, association transfer is established and communication can be made completely symmetric. This is because there are two data streams in each direction during the association. Furthermore, other packets will not carry explicit addressing information during the lifetime of the association. Rather, a unique “key” that maps the packet to the appropriate context is carried in each packet.
[0063]
Once all data has been transmitted from a user, the data stream from the user's context can be closed. Optional form indicators in the packet are exchanged and the connection is properly closed. Other forms of less appropriate closing are also possible by omitting this exchange. When both users do and both data streams are closed, the context transitions to the inactive state. One of the contexts will send an indicator that causes the association to be broken. At this point, both contexts return to a quiescent state.
[0064]
In general, all XTP packet types use a common header structure. All of the information necessary to steer the packet payload to the appropriate point of processing is carried in the header. Much of how the XTP context operates is controlled by a set of bit flags that concentrate on one field in the packet header. Fifteen flags are defined, including a bit flag that controls connection shutdown, a bit flag that controls the acknowledgment policy, and a bit flag that is a marker in the data stream. The remaining bit flags control the end-to-end operating mode. Examples include enabling or disabling error control or flow control, or enabling multicast mode.
[0065]
XTP is based on a 64-bit sequence number and a 64-bit sliding window. XTP also provides transfer rate control, which allows the end system or intermediate system to specify the maximum bandwidth and burst size that it will accept at connection time. The traffic segment provides a means to specify the shape of the traffic so that end systems and intermediate systems can manage their resources and facilitate quality of service assurance.
[0066]
Error control in XTP captures negative acknowledgments when positive and appropriate, and performs retransmission of missing or damaged data packets. The retransmission can be either go-back-N or selective. The retransmission algorithm is conservative. That is, it is possible to transmit only data indicated as missing via the control message. This avoids spurs and possible congestion-induced retransmissions. The error control algorithm is basically conservative but can also be active. That is, systems, techniques, and methods for fast motion error notification are provided.
[0067]
XTP also specifies a technique for extending error control to a multicast environment. The error control algorithm in multicast is the same as the unicast algorithm. Nevertheless, additional sophistication is needed to manage state variables and achieve continuous streaming. XTP is therefore a preferred satellite protocol according to the present invention.
[0068]
Although the foregoing has generally been described using the XTP protocol, it will be appreciated that other types of protocols may be used. For example, the protocol may be modified TCP, modified XTP, or the like. In addition, the protocol can be anything suitable for transmission over satellites. In addition, those skilled in the art will appreciate other variations, modifications, and alternatives.
[0069]
FIG. 2 is a simplified diagram of a
[0070]
[0071]
Information travels through the transport layer (eg, TCP) and then through the
[0072]
Information passes from the
[0073]
Information is received by the
[0074]
Information is sent from the telecommunications link 259 to the
[0075]
In certain embodiments, information can flow through gateways such as
[0076]
In certain embodiments, the conversion module converts information into a connection suitable for transmission through a satellite system using a TCP connection. Connections suitable for satellites are generally resilient to transmission over wireless networks such as Orion Worldcast ™ or PanAmSat ™ SpotByte ™ services. This connection should also be suitable for long latency and asymmetric bandwidth conditions. This connection should also be transparent to the end user at the client or server location. Long latency is generally about 200 milliseconds to about 700 milliseconds per satellite hop, but is not limited to that value.
[0077]
In certain embodiments, for example, as shown in FIG. 2A, the conversion module converts information to XTP, modified TCP, or XTP-like protocol using a TCP connection for transmission over a satellite link. Here, the TCP module receives the
[0078]
From the satellite link, information including the XTP header enters the receiving side XTP module. The receiving XTP or satellite protocol module leaves
[0079]
In other embodiments, the conversion module can also convert the portion of information, including data and TCP / IP headers, into information using the XTP protocol. Alternatively, the conversion module can convert multiple segments of information including multiple TCP / IP headers into a single piece of information including an XTP header for transmission over a satellite link. Depending on the application, the conversion module can convert the information including the TCP connection into any one or any combination of the above. These techniques and other more details are described in more detail below.
[0080]
3A and 3B are simplified diagrams of process diagrams according to embodiments of the present invention. These diagrams are merely illustrative and do not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. In certain embodiments, the present invention uses a
[0081]
In certain embodiments, this process is performed by a selected sequence of steps. Here, the TCP SYN packet is intercepted transparently by the satellite gateway. A satellite gateway establishes a new XTP connection across satellite links to other satellite gateways. Information about the requesting client and destination server, including the ID address and port number, is transferred to other satellite gateways via the satellite link. The destination gateway then uses the client's addressing information to set up a TCP connection with the destination server, so that the server recognizes the TCP connection as if the client itself established the connection. The satellite gateway makes a routing decision based on the source and destination addresses in the IP header of the packet entering the gateway to determine whether the packet should be sent over the satellite telecommunications link. After the TCP connection to the server is established, the destination gateway communicates back to the sending gateway, which then confirms the connection with the client.
[0082]
In one or more embodiments, this sequence of steps has advantages. Specifically, the client does not consider the connection established until the server accepts this connection, which tends to reduce and even eliminate false indications of normal connection establishment. In addition, both the client and the server do not detect that a satellite connection is occurring between the client and the server, but recognize the connection as occurring immediately between the two. That is, the present invention retains substantially “end-to-end semantics” of connectivity. In other embodiments, the connectivity is symmetric. Here, a “client” can exist on either side of the satellite link, and a “server” can exist on either side. The system on one side can request a connection from the system on the other side, and the satellite gateway will intercept the connection.
[0083]
FIG. 3B is a simplified flow diagram of the
[0084]
In certain embodiments, the present invention also includes a transfer rate control step (step 327). In
[0085]
In a particular embodiment according to the present invention, a TCP connection sometimes passes one piece of information in a protocol header that must be sent as soon as possible on the destination side of the connection. This one piece of information is known as an “emergency pointer”. In selecting an embodiment, a TCP implementation that is part of a client-side satellite gateway, such as, for example,
[0086]
FIG. 3C shows a simplified flow diagram of a data rate control process such as the data
[0087]
[0088]
If
[0089]
FIG. 3D shows a simplified flow diagram of a timer service process useful with the data rate control process shown in FIG. 3C, in a specific embodiment according to the present invention. This diagram is merely an illustration and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. FIG. 3D shows
[0090]
If there are packets on the HIPRI queue,
[0091]
If
[0092]
FIG. 3E shows an overview of an exemplary system in a particular embodiment according to the present invention. This diagram is merely an illustration and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. The
[0093]
In one embodiment, a data flow control process 382 is provided that is useful for limiting the amount of data buffered by
[0094]
Although illustrated by satellites and satellite gateways, the present invention may be implemented with other forms of network hardware. For example, the
[0095]
FIG. 3G shows a simplified flow diagram of a connection flow connection selection process in a specific embodiment according to the present invention. This diagram is merely an example and should not limit the scope of the claims herein. Those skilled in the art will appreciate other variations, modifications, and alternatives. FIG. 3G shows the
[0096]
FIG. 3H shows a simplified flow diagram of a data flow control process useful for the satellite gateway system shown in FIG. 3F, in a specific embodiment according to the present invention. This diagram is merely an example and should not limit the scope of the specification. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. FIG. 3H shows the
[0097]
In
[0098]
It is noteworthy that many embodiments according to the present invention can be adapted to changing active connections. If one connection is active, that connection will be allowed to use the entire bandwidth. When the second connection is active, the flow control limit can be adjusted for both the first and second connections by calculating the flow control limit whenever new data arrives. In this scheme, bandwidth can be allocated between connections regardless of the order in which the connections were established. In addition, embodiments according to the present invention reduce the likelihood that a burst of data from one particular connection will be queued for transmission over the link before the data for the other connection. Makes it possible to share satellite links between connections. This makes network throughput more consistent across many connections.
[0099]
FIG. 3I shows a simplified structural component diagram of an exemplary buffer architecture of a particular embodiment according to the present invention. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. FIG. 3I shows the
[0100]
FIG. 3J shows a simplified structural component diagram of an exemplary buffer architecture of a particular embodiment according to the present invention. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. FIG. 3J shows output data 402 that may reside, for example, in the
[0101]
In an embodiment according to the present invention, a connection to a receiver, such as a
[0102]
FIG. 7 shows a representative apparatus in a particular embodiment according to the present invention. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. FIG. 7 shows a block diagram of a protocol gateway in a specific embodiment according to the present invention, such as
[0103]
[0104]
Although the above has generally described the invention with particular systems, methods, and embodiments, the invention has a wider range of applicability. Specifically, the present invention is not limited to satellite communications, it is desirable to use refinement and optimization protocols over specific parts of the network, and end systems may be updated to use the refinement protocol. It can be applied to any networking situation that cannot. Thus, in one embodiment, the satellite gateway can provide access to all types of wireless or wired networks and internetworks. Of course, those skilled in the art will recognize other variations, modifications, and alternatives.
[0105]
Experiment:
Experiments were performed to verify the principle and operation of this system. In this experiment, a series of single client FTP file transfer throughput tests were performed comparing traditional TCP and the present invention over a variety of different TCP window sizes, link bandwidths, round trip delay times, and bit error rates. . In one experiment, “window size” was compared against “throughput”, for example as shown in diagram 400 of FIG. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. Without performance enhancement or TCP window size tuning, most clients were limited to a throughput rate of 100 Kbps when the round trip time was 540 ms. As the data of FIG. 4 shows, even a client having a 32 KB window could only reach a throughput of 400 Kbps. This system allows clients to use available bandwidth regardless of the client or server window size.
[0106]
In an alternative experiment, “round trip delay” was analyzed for “throughput”, as shown, for example, in the simplified diagram 500 of FIG. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. Here, the present invention removes the dependence of TCP on the round trip time of the network. Performance was measured over error free symmetrical 2 Mbps and 10 Mbps links. Although TCP can fully saturate terrestrial low-latency networks, these results indicate that TCP performance drops rapidly as delay increases. In contrast, a network using this system was able to maintain almost full use of the link regardless of the round trip time of the network.
[0107]
In an alternative experiment, the “bit error rate” was monitored against the “throughput” shown, for example, by the simplified diagram 600 of FIG. This diagram is merely an example and should not limit the scope of the claims herein. Other variations, modifications, and alternatives will be appreciated by those skilled in the art. A network incorporating the present invention is also sensitive to the bit error rate of the link. The diagram shows the throughput as a function of bit error rate for a symmetric 10 Mbps satellite network with a round trip time of 540 ms and a TCP window size of 1 MB. Even with a low error rate, TCP could only send 1.2 Mbps. Error rate 1.0 × 10 -Five Then, TCP throughput dropped to 0.05 Mbps. A network using the present invention fully saturates the link with a low error rate and an error rate of 1.0 × 10 -Five But I was able to send 2.7Mbps.
[0108]
While the above is a complete description of specific embodiments, various modifications, alternative constructions, and equivalents can be used. For example, the above has generally been described by using XTP as the satellite protocol. Other types of protocols are also available. For example, the protocol can include a modified TCP or the like. Accordingly, the foregoing description and illustrations have not been used as limiting the scope of the invention as defined by the appended claims.
[Brief description of the drawings]
FIG. 1 is a simplified diagram of a satellite system according to an embodiment of the present invention.
FIG. 2 is a simplified diagram of a system architecture according to one embodiment of the present invention.
FIG. 2A is a simplified diagram of a system architecture according to one embodiment of the present invention.
FIG. 3A is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3B is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3C is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3D is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3E is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3F is a simplified diagram of a process diagram according to one embodiment of the invention.
FIG. 3G is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3H is a simplified diagram of a process diagram according to one embodiment of the invention.
FIG. 3I is a simplified diagram of a process diagram according to one embodiment of the present invention.
FIG. 3J is a simplified diagram of a process diagram according to an embodiment of the present invention.
FIG. 4 is a simplified diagram of experimental data according to one embodiment of the present invention.
FIG. 5 is a simplified diagram of experimental data according to one embodiment of the present invention.
FIG. 6 is a simplified diagram of experimental data according to one embodiment of the present invention.
FIG. 7 is a simplified diagram of a gateway interface according to an embodiment of the present invention.
Claims (18)
前記第1ゲートウェイを前記クライアントとリンクするためのネットワーク・インターフェースと、
サテライト・ゲートウェイ・インターフェースと、
システム・メモリと、
前記ネットワーク・インターフェース、前記サテライト・ゲートウェイ・インターフェース、前記システム・メモリをプロセッサと相互接続するバスであって、そのプロセッサは、
前記通信が前記クライアントによって開始され、前記サーバとの接続をインターセプトし、
前記第1ゲートウェイと前記第2ゲートウェイの間の接続を、前記遠隔通信リンクを介して確立し、
前記第1ゲートウェイと前記第2ゲートウェイの間の前記接続を使用して、前記クライアントから前記サーバに対する、また前記サーバから前記クライアントに対する情報の双方向フローを提供し、前記クライアントとサーバにトランスペアレントに行われることとを実行するように動作可能に構成されているバスとを含む装置。A communication device for transmitting packetized information over a satellite link in a telecommunications system, wherein the information includes a plurality of packets each including data and a header, wherein the system includes a plurality of potential clients. A client selected from among; a server selected from among a plurality of potential servers; a first gateway connected to the client by a first telecommunications link; and a server connected by a second telecommunications link. A second gateway, and a third telecommunications link connecting the first gateway to the second gateway,
A network interface for linking the first gateway with the client;
Satellite gateway interface;
System memory,
A bus that interconnects the network interface, the satellite gateway interface, and the system memory with a processor, the processor comprising:
The communication is initiated by the client to intercept a connection with the server;
Establishing a connection between the first gateway and the second gateway via the telecommunications link;
The connection between the first gateway and the second gateway is used to provide a bi-directional flow of information from the client to the server and from the server to the client, and is transparent to the client and server. And a bus configured to be operable to perform the operation.
前記プロセッサが、前記第1ゲートウェイで、前記情報を第1プロトコルから第2プロトコルに前記遠隔通信リンクを介する伝送のために変換し、かつ前記第2ゲートウェイで、前記第2プロトコルを前記第1プロトコルに変換するようにさらに、動作可能に構成された装置。 The apparatus of claim 1, wherein
The processor converts the information at the first gateway from a first protocol to a second protocol for transmission over the telecommunications link, and at the second gateway, converts the second protocol to the first protocol. A device that is further operatively configured to convert to.
前記第1プロトコルがTCPを含み、かつ前記第2プロトコルがXTPを含む装置。 The apparatus of claim 2.
Wherein the first protocol comprises TCP, and the second protocol apparatus including XTP.
第1ゲートウェイを設置するステップであって、前記第1ゲートウェイが、前記クライアントから前記サーバに対する接続をインターセプトするように動作可能に構成され、前記第1ゲートウェイが、さらに、前記パケット化された情報をTCPプロトコルからサテライト・プロトコルに変換するように動作可能に構成されているステップと、
第2ゲートウェイを設置するステップであって、前記第2ゲートウェイが、前記サーバとの接続を確立するように構成され、前記第2ゲートウェイが、さらに、前記パケット化された情報をサテライト・プロトコルからTCPプロトコルに変換するように動作可能に構成され、前記第1ゲートウェイおよび前記第2ゲートウェイが、共通遠隔通信リンクを介して接続を確立するように動作可能に構成されているステップとを含む方法。Method for converting the communication system to a system for transporting packetized information in a satellite protocol within a communication system for transporting packetized information in a TCP protocol between a client and a server Because
Installing a first gateway, wherein the first gateway is configured to be operable to intercept a connection from the client to the server, the first gateway further comprising the packetized information; Steps operatively configured to convert from a TCP protocol to a satellite protocol;
Installing a second gateway, wherein the second gateway is configured to establish a connection with the server, and the second gateway further transmits the packetized information from a satellite protocol to a TCP Operatively configured to convert to a protocol, wherein the first gateway and the second gateway are operatively configured to establish a connection via a common telecommunications link.
複数の潜在的クライアントのうちから選択されたクライアントと、
複数の潜在的サーバのうちから選択されたサーバと、
第1遠隔通信リンクによって前記クライアントに接続された第1ゲートウェイと、
第2遠隔通信リンクによって前記サーバに接続された第2ゲートウェイと、
前記第1ゲートウェイを前記第2ゲートウェイに接続する第3遠隔通信リンクとを含み、前記通信方法は、
前記クライアントによって開始された、前記サーバとの接続の試行をインターセプトするステップと、
前記第1ゲートウェイと前記第2ゲートウェイの間の接続を、前記第3遠隔通信リンクを介して確立するステップと、
前記第1ゲートウェイと前記第2ゲートウェイの間の前記接続を使用して、前記クライアントから前記サーバに対する、または前記サーバから前記クライアントに対する情報の双方向フローを提供するステップであって、前記双方向フローの提供が、前記クライアントとサーバにトランスペアレントに行われるステップとを含む方法。A communication method for transmitting information in a system, wherein the information includes a plurality of packets each including data and a header, and a client selected from a plurality of potential clients in the system;
A server selected from a plurality of potential servers;
A first gateway connected to the client by a first telecommunications link;
A second gateway connected to the server by a second telecommunications link;
A third telecommunications link connecting the first gateway to the second gateway, the communication method comprising:
Intercepting a connection attempt initiated by the client with the server;
Establishing a connection between the first gateway and the second gateway via the third telecommunications link;
Providing a bidirectional flow of information from the client to the server or from the server to the client using the connection between the first gateway and the second gateway, the bidirectional flow Providing is transparent to the client and the server.
前記情報を前記第1ゲートウェイで、第1プロトコルから第2プロトコルに、前記第3遠隔通信リンクを介する伝送のために変換するステップと、
前記第2プロトコルを前記第1プロトコルに前記第2ゲートウェイで変換するステップとをさらに含む方法。 The method of claim 5, wherein
Converting the information at the first gateway from a first protocol to a second protocol for transmission over the third telecommunications link;
The method further comprises the step of converting the second protocol at the second gateway to the first protocol.
第1プロトコルが、TCPを含み、かつ第2プロトコルが、XTPを含む方法。 The method of claim 6 wherein:
First protocol comprises a TCP, and a second protocol, the method comprising the XTP.
前記変換するステップが、前記ヘッダを除去して、前記データを実質的にそのままにしておくステップを含む方法。 The method of claim 6 wherein:
Wherein the step of conversion, by removing the header, the method comprising the steps to keep substantially intact the data.
前記変換するステップが、前記ヘッダを除去して、前記データを実質的にそのままにしておくステップと、前記データをサテライト・プロトコル・ヘッダを使用してカプセル化するステップとを含む方法。 The method of claim 6, wherein
Wherein the step of converting is, how to remove the header, comprising the steps to keep substantially intact the data, and a step of encapsulating by using the satellite protocol header said data.
前記第1ゲートウェイは、前記第3遠隔通信リンクを介して前記サーバから送信された情報を記憶する第1バッファと、前記クライアントが受信できるよう前記第1遠隔通信リンクに送り出される情報を記憶する第2バッファとを有しており、さらに、前記第2遠隔通信リンク及び前記第3遠隔通信リンクを介して送られる前記サーバから前記クライアントへの情報を前記第1ゲートウェイが受信する際に、
前記第1バッファの状態が飽和状態に達したか否かを判定するステップと、
前記第1バッファが飽和状態に達した場合、前記クライアントの前記第3遠隔通信リンクを介して受信されるデータの量を抑えるように、前記第1ゲートウェイで前記クライアントの受信ウィンドウ・サイズを減少設定するステップとを含む方法。 The method of claim 5, wherein
The first gateway stores a first buffer for storing information transmitted from the server via the third telecommunications link, and a first buffer for storing information sent to the first telecommunications link for reception by the client. And when the first gateway receives information from the server to the client sent via the second telecommunications link and the third telecommunications link,
Determining whether the state of the first buffer has reached saturation ;
If the first buffer has reached a saturated state, so as to suppress the amount of data received via the third telecommunication link of the client, reducing set the receive window size of the client in the first gateway Comprising the steps of:
前記飽和状態は、前記第1バッファに所定のしきい値を越えて情報が蓄積された状態である方法。 The method of claim 10, wherein:
Wherein the saturated state is a state in which information exceeds a predetermined threshold value to the first buffer is accumulated.
データが、前記第1ゲートウェイから前記第2ゲートウェイまで前記第3遠隔通信リンクを介して伝わるのにかかる往復時間を判定するステップと、
前記第3遠隔通信リンクに関するデータ通信速度を判定するステップと、
前記往復時間および前記データ通信速度から帯域幅遅延積を判定するステップと、
前記帯域幅遅延積から前記第3遠隔通信リンクに対するフロー制御制限量を判定するステップと、
前記フロー制御制限量に基づいて前記第3遠隔通信リンクを介するデータ転送量を制限するステップとを含む方法。 The method of claim 5, further comprising:
Determining the round trip time it takes for data to travel from the first gateway to the second gateway via the third telecommunications link ;
Determining a data communication speed for the third telecommunications link ;
Determining a bandwidth delay product from the round trip time and the data communication speed;
Determining a flow control limit amount with respect to the third telecommunication link from the bandwidth delay product,
Method comprising the step of limiting the amount of data transferred through said third telecommunication link in accordance with the flow control limit amount.
前記第3遠隔通信リンクが、サテライト・プロトコルを使用する方法。 The method of claim 12, wherein
The method wherein the third telecommunications link uses a satellite protocol .
前記第3遠隔通信リンクに関する往復時間を判定する前記ステップが、ユーザから前記往復時間を得るステップをさらに含む方法。 The method of claim 12, wherein
Wherein said determining a round trip time for the third telecommunications link, the method further comprising the step of obtaining the round-trip time from the user.
前記第3遠隔通信リンクに関するデータ通信速度を判定する前記ステップが、ユーザから前記往復時間を得るステップをさらに含む方法。 The method of claim 12, wherein
The third step determines the data communication rate for the remote communications link, the method further comprising the step of obtaining the round-trip time from the user.
前記第3遠隔通信リンクに関する帯域幅遅延積を判定する前記ステップが、前記往復時間と前記データ通信速度を掛けるステップをさらに含む方法。 The method of claim 12, wherein
The third said determining the bandwidth delay product related telecommunication link step further comprising the step of subjecting the data communication speed and the round trip time.
前記第3遠隔通信リンクに対するフロー制御制限量を判定する前記ステップが、前記帯域幅遅延積に倍率を掛けて、それを前記リンクに関する接続の数で割るステップをさらに含む方法。 The method of claim 12, wherein
The third step determines the flow control limit amount for the telecommunications link, multiplied by the magnification to the bandwidth delay product, further comprising the step of dividing it by the number of connections for the link.
前記倍率が8である方法。 The method of claim 17, wherein
The method wherein the magnification is 8.
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11822799P | 1999-02-02 | 1999-02-02 | |
US09/243,554 US6584083B1 (en) | 1999-02-02 | 1999-02-02 | Internet over satellite method |
US09/243,185 US6529477B1 (en) | 1999-02-02 | 1999-02-02 | Internet over satellite system |
US09/306,236 US6654344B1 (en) | 1999-02-02 | 1999-05-06 | Method and system for controlling data flow in an internet over satellite connection |
US09/306,678 US6460085B1 (en) | 1999-02-02 | 1999-05-06 | Method and system for managing memory in an internet over satellite connection |
US09/493,338 US6934255B1 (en) | 1999-02-02 | 2000-01-28 | Internet over satellite apparatus |
PCT/US2000/002891 WO2000046669A1 (en) | 1999-02-02 | 2000-02-02 | Internet over satellite |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2004520725A JP2004520725A (en) | 2004-07-08 |
JP2004520725A5 JP2004520725A5 (en) | 2004-12-24 |
JP3814678B2 true JP3814678B2 (en) | 2006-08-30 |
Family
ID=27557925
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000597684A Expired - Lifetime JP3814678B2 (en) | 1999-02-02 | 2000-02-02 | Internet via satellite |
Country Status (5)
Country | Link |
---|---|
EP (1) | EP1151375A4 (en) |
JP (1) | JP3814678B2 (en) |
CA (1) | CA2361433A1 (en) |
IL (1) | IL144658A0 (en) |
WO (1) | WO2000046669A1 (en) |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9929882D0 (en) * | 1999-12-18 | 2000-02-09 | Roke Manor Research | TCP/IP enhancement for long latency links |
US6650869B2 (en) | 2000-04-14 | 2003-11-18 | Hughes Electronics Corporation | System and method for managing return channel bandwidth in a two-way satellite system |
US6987741B2 (en) | 2000-04-14 | 2006-01-17 | Hughes Electronics Corporation | System and method for managing bandwidth in a two-way satellite system |
US20010048669A1 (en) * | 2000-04-14 | 2001-12-06 | Frank Kelly | System interfaces in a two-way satellite system |
US7164661B2 (en) | 2000-04-14 | 2007-01-16 | Hughes Networks Systems, Llc | System and method for providing a two-way satellite system |
US7463582B2 (en) | 2000-04-14 | 2008-12-09 | Hughes Network Systems, Llc | System and method for scaling a two-way satellite system |
US6441782B2 (en) | 2000-04-14 | 2002-08-27 | Hughes Electronics Corporation | Method and system of directing an antenna in a two-way satellite system |
US6965581B2 (en) | 2000-04-14 | 2005-11-15 | Hughes Electronics Corp. | Transceiver in a two-way satellite system |
US7839890B1 (en) * | 2000-11-02 | 2010-11-23 | Fisher-Rosemount Systems, Inc. | Multiplexed data transmissions through a communication link |
WO2002045353A1 (en) * | 2000-11-30 | 2002-06-06 | Inalambrica.Net Costa Rica Sociedad Anonima | Integrated high-speed data reception and distribution system |
US7305697B2 (en) * | 2001-02-02 | 2007-12-04 | Opentv, Inc. | Service gateway for interactive television |
SE522101C2 (en) * | 2001-04-20 | 2004-01-13 | Swe Dish Satellite Sys Ab | A communication device and a link system for satellite communication |
US7054902B2 (en) | 2001-10-23 | 2006-05-30 | Packeteer, Inc. | Multicast delivery systems and methods |
DE10200165A1 (en) * | 2002-01-04 | 2003-07-10 | Klaus Rock | Method for reducing the latency in interactive data communication via a satellite network |
JP3800107B2 (en) * | 2002-02-27 | 2006-07-26 | 日本電気株式会社 | Data transfer method and disk array apparatus in data copy system |
DE10315111A1 (en) * | 2003-04-02 | 2004-10-14 | Klaus Rock | Method for reducing the latency in interactive data communication between a terminal server and a terminal server client in a geostationary satellite network |
US7359395B2 (en) * | 2003-06-16 | 2008-04-15 | Packeteer, Inc. | Pre-fetch communication systems and methods |
WO2005026912A2 (en) | 2003-09-10 | 2005-03-24 | Hyperdata Technologies, Inc. | Internet protocol optimizer |
DE102004048343B4 (en) | 2004-10-01 | 2022-09-22 | Satcloud Ip Holding Llc | Method for reducing the latency in interactive data communication between a terminal server and a terminal server client in a telecommunications network, in particular a GSM or a UMTS network |
US20080294749A1 (en) * | 2007-05-21 | 2008-11-27 | Derenge Charles L | System and method for globally sharing fms data or other files from aerial platforms or other sources anywhere in the world |
JP5258938B2 (en) | 2011-07-26 | 2013-08-07 | 株式会社日立製作所 | Communication device |
JP5699985B2 (en) * | 2012-05-29 | 2015-04-15 | 三菱電機株式会社 | TCP communication acceleration device |
CN105897665B (en) * | 2015-01-26 | 2020-01-14 | 中兴通讯股份有限公司 | Method for realizing TCP transmission in satellite network environment and corresponding gateway |
JP2018157483A (en) * | 2017-03-21 | 2018-10-04 | 株式会社富士通アドバンストエンジニアリング | Connection controller and network system |
CN116248172B (en) * | 2023-05-08 | 2023-07-07 | 银河航天(北京)网络技术有限公司 | Data transmission method, device and storage medium based on TCP/IP protocol and CCSDS protocol |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5163046A (en) * | 1989-11-30 | 1992-11-10 | At&T Bell Laboratories | Dynamic window sizing in a data network |
US5426635A (en) * | 1993-09-08 | 1995-06-20 | At&T Corp. | Method for adaptive control of windows and rates in networks |
US5594490A (en) * | 1994-05-23 | 1997-01-14 | Cable Services Technologies, Inc. | System for distributing video/audio files from central location to a plurality of cable headends |
AU706160B2 (en) * | 1994-06-08 | 1999-06-10 | Hughes Electronics Corporation | Apparatus and method for hybrid network access |
US5572530A (en) * | 1994-10-07 | 1996-11-05 | Comsat Corporation | Technique for efficient integration of integrated services digital network (ISDN) into satellite system |
US5850517A (en) * | 1995-08-31 | 1998-12-15 | Oracle Corporation | Communication link for client-server having agent which sends plurality of requests independent of client and receives information from the server independent of the server |
FI100684B (en) * | 1995-11-30 | 1998-01-30 | Nokia Oy Ab | Use of packet identifiers in the packet-switched communication format only to indicate requesters |
US6038216A (en) * | 1996-11-01 | 2000-03-14 | Packeteer, Inc. | Method for explicit data rate control in a packet communication environment without data rate supervision |
AU727421B2 (en) * | 1996-11-12 | 2000-12-14 | Starguide Digital Networks, Inc. | High bandwidth broadcast system having localized multicast access to broadcast content |
US5896558A (en) * | 1996-12-19 | 1999-04-20 | Globalstar L.P. | Interactive fixed and mobile satellite network |
DE69702308T2 (en) * | 1997-07-11 | 2000-12-28 | Ico Services Ltd., London | Web access for users in a vehicle |
-
2000
- 2000-02-02 CA CA002361433A patent/CA2361433A1/en not_active Abandoned
- 2000-02-02 JP JP2000597684A patent/JP3814678B2/en not_active Expired - Lifetime
- 2000-02-02 IL IL14465800A patent/IL144658A0/en active IP Right Grant
- 2000-02-02 WO PCT/US2000/002891 patent/WO2000046669A1/en not_active Application Discontinuation
- 2000-02-02 EP EP00907155A patent/EP1151375A4/en not_active Ceased
Also Published As
Publication number | Publication date |
---|---|
EP1151375A4 (en) | 2003-10-22 |
EP1151375A1 (en) | 2001-11-07 |
WO2000046669A1 (en) | 2000-08-10 |
JP2004520725A (en) | 2004-07-08 |
IL144658A0 (en) | 2002-05-23 |
WO2000046669A8 (en) | 2001-03-22 |
WO2000046669A9 (en) | 2001-09-07 |
CA2361433A1 (en) | 2000-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3814678B2 (en) | Internet via satellite | |
US6654344B1 (en) | Method and system for controlling data flow in an internet over satellite connection | |
US6584083B1 (en) | Internet over satellite method | |
US6934255B1 (en) | Internet over satellite apparatus | |
US6529477B1 (en) | Internet over satellite system | |
US6460085B1 (en) | Method and system for managing memory in an internet over satellite connection | |
US8169911B2 (en) | Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium | |
US7839783B2 (en) | Systems and methods of improving performance of transport protocols | |
US8090859B2 (en) | Decoupling TCP/IP processing in system area networks with call filtering | |
US7133361B2 (en) | Method and system for improvement of network performance over asymmetic links | |
US20050195821A1 (en) | Method and apparatus for dynamically controlling traffic in wireless station | |
EP1344359B1 (en) | Method of enhancing the efficiency of data flow in communication systems | |
JP5020076B2 (en) | High performance TCP suitable for low frequency ACK system | |
CN101436978A (en) | Method for authentic data transmission using UDP protocol | |
US9781626B2 (en) | Wireless channel allocation in a base station processor | |
JP2005503051A (en) | Persistent links between hierarchical proxies for mobile communications | |
CA2422919A1 (en) | Dynamic tcp configuration for low latency voice/data traffic | |
CN116131923B (en) | Data transmission method, device and storage medium based on satellite communication | |
WO2020154872A1 (en) | Transmission control protocol acceleration method and apparatus | |
IL144658A (en) | Internet over satellite | |
US11997179B2 (en) | Distributed proxy for encrypted transport protocols with efficient multi-priority multiplexed transport for improving user's traffic QOS | |
WO2023226918A1 (en) | Redundant transmission control method and related device | |
WO2023225172A1 (en) | Distributed proxy for encrypted transport protocol with efficient multi-priority multiplexed transport for improving user's traffic qos | |
Fairhurst | Techniques for optimising satcom packet data networks | |
Zhou | Congestion management and medium access control in satellite data networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051118 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051213 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060307 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060418 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20060515 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060515 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060515 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3814678 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100616 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110616 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110616 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130616 Year of fee payment: 7 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |