JP3814678B2 - Internet via satellite - Google Patents

Internet via satellite Download PDF

Info

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
Application number
JP2000597684A
Other languages
Japanese (ja)
Other versions
JP2004520725A5 (en
JP2004520725A (en
Inventor
トポレク，ジェローム・ディ
パルター，ディビッド・シィ
マッコーイ，ジェレミー・エイ
ハッソン，マート・ビィ
ハートリック，ティモシー・ダブリュ
ガイヤー，ケイ・エイ
Original Assignee
パケッティー・インコーポレーテッド
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US09/243,185 external-priority patent/US6529477B1/en
Priority claimed from US09/243,554 external-priority patent/US6584083B1/en
Priority claimed from US09/306,678 external-priority patent/US6460085B1/en
Priority claimed from US09/306,236 external-priority patent/US6654344B1/en
Priority claimed from US09/493,338 external-priority patent/US6934255B1/en
Application filed by パケッティー・インコーポレーテッド filed Critical パケッティー・インコーポレーテッド
Publication of JP2004520725A publication Critical patent/JP2004520725A/en
Publication of JP2004520725A5 publication Critical patent/JP2004520725A5/ja
Application granted granted Critical
Publication of JP3814678B2 publication Critical patent/JP3814678B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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

【０００１】
（関連出願の相互参照）
本出願は、１９９９年２月２日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ａｐｐａｒａｔｕｓ」と題された米国仮特許出願第６０／１１８２２７号（整理番号１６６２５−００１１００）の優先権を主張し、その完全な開示が、参照により、本明細書に組み込まれる。
【０００２】
また、本出願は、下記の５つの共有される同時係属出願からの優先権も主張し、これらも、その全体が参照により、本明細書に組み込まれる。
１．１９９９年２月２日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ」と題された米国特許出願第０９／２４３１８５号（整理番号１６６２５−００１２００）
２．１９９９年２月２日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ｍｅｔｈｏｄ」と題された米国特許出願０９／２４３５５４号（整理番号１６６２５−００１３００）
３．１９９９年５月６日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍａｎａｇｉｎｇ Ｍｅｍｏｒｙ ｉｎ ａｎ Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ｃｏｎｎｅｃｔｉｏｎ」と題された米国特許出願第０９／３０６６７８号（整理番号１６６２５−００１２１０）
４．１９９９年５月６日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｔｒｏｌｌｉｎｇ Ｄａｔａ Ｆｌｏｗ ｉｎ ａｎ Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ｃｏｎｎｅｃｔｉｏｎ」と題された米国特許出願第０９／３０６２３６号（整理番号１６６２５−００１２２０）
５．２０００年１月２８日、Ｊｅｒｏｍｅ Ｄ．Ｔｏｐｏｒｅｋ他の名義で出願され、「Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｓａｔｅｌｌｉｔｅ Ａｐｐａｒａｔｕｓ」と題され、やはり米国仮特許出願第６０／１１８２２７号の優先権を主張する米国特許出願第＿＿＿＿＿＿＿＿号（整理番号１６６２５−００１１１０）
【０００３】
（発明の背景）
本発明は、遠隔通信の装置、システム、および技法に関する。より詳細には、本発明は、インターネットなどのコンピュータのワイド・エリア・ネットワーク内での使用のために、サテライト・システムを介するＴＣＰ接続を使用して、メモリを管理し、かつ／または情報を伝送するための装置、システム、および方法を提供する。本発明は、例えば、Ｘｐｒｅｓｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（本明細書では、「ＸＴＰ」）プロトコルを使用して、サテライト・システムを介して、遠隔ロケーションに対する信号の高速、高品質の伝送を提供する。また、本発明は、例えば、ＸＴＰプロトコルを使用する、サテライト・システムを介して、遠隔ロケーションに対する信号の高速、高品質の伝送のための装置内での制御されたメモリ管理も提供する。ただし、本発明はずっと広範囲の適用可能性を有することを理解されたい。これは、専用ブリッジされたネットワーク、地上無線ネットワーク・リンクなどにも適用できる。
【０００４】
インターネットは、数百万の個別コンピュータ・ネットワークおよび個別コンピュータを一緒に接続する国際的「スーパー・ネットワーク」である。インターネットは、一般的に、単一エンティティではない。それは、どの単一エンティティも完全な権限または制御を有さない、極めて拡散した複雑なシステムである。インターネットは、ワールド・ワイド・ウェブ（本明細書では「ウェブ」）を介して情報を提供する方法のうちの１つとして広く知られているが、一般的なインターネット・プロトコルおよびインフラストラクチャに基づいて現在、利用可能な多くの他のサービスが存在する。
【０００５】
ウェブは、一般的に、コンピュータに慣れていない人々にとっても使用することが容易である。ウェブ上の情報は、同一セットのデータ・ファイル（すなわち、ウェブ・サイト）内、あるいは他のコンピュータ・ネットワーク上にあるデータ・ファイル内の他のページに対する「リンク」を含む、グラフィックスおよびテキストの「ページ」上に提供することができる。ユーザは、しばしば、カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｒｐｏｒａｔｉｏｎ、またはワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって製造されるものなどの「ブラウザ」プログラムを使用して、ウェブで情報にアクセスすることができる。ブラウザ・プログラムは、ウェブ・サイトからの情報を処理して、その情報をグラフィックス、サウンド、およびアニメーションを使用して表示する。したがって、ウェブは、商品およびサービスを消費者に宣伝するための人気のある媒体となっている。
【０００６】
インターネットは、多くの他の形式の通信をサポートする。例えば、インターネットは、通常、「ｅメール」として知られている電子メールを介する１対１通信を可能にする。インターネットは、また、他の人々がそれを読み、それに応答するカラフルなテキストおよびグラフィックスを掲示するために、ユーザによって使用される「掲示板」も有する。リアルタイム通信のため、インターネットは、「チャット・ルーム」などを有する。これらでタイプ入力したメッセージを使用して、ユーザが互いに通信を行うことができる。いくつかのケースでは、インターネットは、ユーザ間の音声通信のためにも使用することができる。これらの形式の通信のすべてが、少なくとも部分的に、重要な接続を使用して可能であり、この接続によって、情報が、インターネット上の多くの異なるサーバから伝送されることを可能にする。
【０００７】
インターネットは、ＴＣＰ／ＩＰプロトコルに基づいている。ネットワーク層で、ＩＰとして知られるインターネット・プロトコルが、個々のコンピュータにアドレス指定されたパケットを送るための機構を提供する。インターネットは、ＩＰを実施する複数のコンピュータ・システムを有し、これらは、一般的に、ローカル・エリア・ネットワークおよび専用伝送回線を使用して互いに相互接続されて、コンピュータのワイド・エリア・ネットワークを形成する。ＩＰパケットは、ベスト・エフォート基準で送達され、その目的の宛先に到着することが保証されず、これは、「信頼できない」サービスとして知られる。
【０００８】
信頼できるデータ送達サービスを必要とする多くの適用形態の場合、インターネットは、ＴＣＰとして知られる伝送制御プロトコルと呼ばれる接続機構を使用する。ＴＣＰは、それがインターネットで通信するのに適している様々な望ましい特性を有する。例えば、ＴＣＰは、送信サーバから通信メディアを介して受信サーバに送信するデータ・サイズまたは最適サイズ・セグメントのデータを考慮する。さらに、ＴＣＰはタイマを維持する。これは、受信サーバが、送信サーバからのデータ・セグメントの受信の肯定応答を送信するのを待つ。肯定応答が受信される前に、タイマがタイムアウトになった場合、ＴＣＰは、データ・セグメントを再送信し、これが、通信での信頼性を提供する。また、ＴＣＰは、そのヘッダおよびデータ上にチェックサムを維持する。これが転送中のデータ内のいかなる変更も監視する。データが、無効なチェックサムを伴って到着した場合、ＴＣＰは、そのデータを廃棄して、そのデータを受信したことを認知しない。データ・セグメントが、誤った順序で到着した場合、ＴＣＰは、それらのセグメントを受信サーバで順序正しく再結合することもできる。さらに、ＴＣＰは、フロー制御を提供する。これは、有限量のデータだけが、受信サーバ上のバッファに送信されるようにする。これは、高速サーバ・コンピュータが、より遅いサーバ・コンピュータ上のすべてのバッファをオーバーフローさせるのを防止する。
【０００９】
ＴＣＰは、同様の特性を有する従来の電話システムおよび電話回線を使用して互いに結合された複数のサーバ間で、インターネット・データを伝送するのによく適しているが、多くの限界も有する。例えば、ＴＣＰは、「短いホップ」に適しているが、しばしば、相当な待ち時間を有し得る極めて長距離にわたる通信（例えば、サテライトを介する大陸間ホップ）をスローダウンする。この場合、フロー制御機能および肯定応答機能が、送信および受信をするのに時間がかかり過ぎ、これが、通信を遅くする。さらに、効率を高める機会がまだ存在する。詳細には、ＴＣＰは、遅いことが判明しており、例えば、サテライト・ネットワークを介するインターネット・データの伝送には面倒である。さらに、例えば、モデムなどの比較的遅い受信側に対しての、サテライト・ネットワークを介するインターネット・データの高速伝送は、輻輳を引き起こす可能性がある。さらに、ＴＣＰ接続のさらなる減速につながるシステム内でのリソースの消耗を引き起こし得る、サテライトを使用するネットワーキングでの異常な状態が発生する可能性がある。さらに、サテライトを使用するネットワーキングは、しばしば、ＴＣＰ接続のさらなる減速につながる相当なビット・エラー率に遭遇する。これらの限界および他の限界を、下記の図により、さらに完全に説明する。
【００１０】
以上のことから、無線通信メディアを使用する広い地理的領域にわたる、インターネット・サービスをトランスポートするより効率的な方法、およびその伝送で、メモリを管理するより効率的な方法が、大変、望ましい。
【００１１】
（発明の概要）
本発明によれば、無線ワイド・エリア・ネットワーク上でのＴＣＰパフォーマンスを改善するための技法が提供される。例としての実施態様では、本発明は、ＴＣＰ接続を使用する情報を、例えば、Ｘｐｒｅｓｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（本明細書では、「ＸＴＰ」）接続に変換するための装置、システム、および方法を提供し、後者の接続は、サテライト・システムなどの無線ネットワーク・システムを介する伝送により適している。
【００１２】
本発明によれば、ＴＣＰ接続での情報フローを制御するための技法、および無線ワイド・エリア・ネットワーク上の１つまたは複数のＴＣＰ接続を介して通信される情報を記憶するためのメモリを管理する技法が提供される。例としての実施態様では、本発明は、情報のバッファリングおよび／または、情報がＴＣＰ接続を介して、例えば、Ｘｐｒｅｓｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（本明細書では、「ＸＴＰ」）接続に流れる速度を制御する方法およびシステムを提供する。
【００１３】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送するための通信装置を提供する。この装置は、ＴＣＰ接続を使用して、データおよびヘッダを有する双方向フローの情報を提供するための、サテライト・ゲートウェイ・インターフェースに結合されたＴＣＰインターフェースを含む。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはＴＣＰ／ＩＰプロトコルを使用する任意のネットワークからのものでよい。また、この装置は、ＴＣＰ接続を使用して、サテライト・リンクを介する伝送のためのサテライト・プロトコルに情報を変換するプロセッサも含む。このサテライト・プロトコルは、サテライト・リンクを介するそうした情報の伝送のための適切な特性を有する。このプロトコルには、とりわけ、ＸＴＰ、ＸＴＰ様のプロトコルなどが含まれ得る。
【００１４】
代替の実施態様では、本発明は、ＴＣＰ接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立するための通信装置を提供する。この装置は、第１クライアント（例えば、ユーザ・コンピュータ）と第１サテライト・ゲートウェイの間での第１通信接続を形成するためのＴＣＰインターフェースを含む。また、この装置は、サテライト・リンクを介して第１サテライト・ゲートウェイと第２サテライト・ゲートウェイの間で第２通信接続を形成するためのサテライト・ゲートウェイ・インターフェースも含む。第１接続の特性（例えば、送信元および宛先のＩＰアドレスおよびポート番号）を記述する情報が、第２サテライト・ゲートウェイに伝送される。第３通信接続が、第２サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第１クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【００１５】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送する通信システムを提供する。このシステムは、データおよびヘッダを有する双方向フローの情報を提供するためのコードを有する第１ゲートウェイを含み、この第１ゲートウェイは、ＴＣＰ接続に結合されている。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはＴＣＰ／ＩＰプロトコルを使用する任意のネットワークからのものでよい。また、このシステムは、ＴＣＰプロトコルからの情報をサテライト・リンクを介する伝送のためのサテライト・プロトコルに変換するためのコードも含む。また、このシステムは、サテライト・リンクを介して、第１ゲートウェイからの情報を受信するための第２ゲートウェイも含む。第２ゲートウェイは、サテライト・リンクを介する伝送のための適切な特性を有するサテライト・プロトコルからの情報をＴＣＰプロトコルに変換するためのコードも含む。このサテライト・プロトコルには、とりわけ、ＸＴＰ、ＸＴＰ様のプロトコルなどが含まれ得る。
【００１６】
代替の実施態様では、本発明は、ＴＣＰ接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立することができる通信システムを提供する。このシステムは、第１クライアント（例えば、ユーザ・コンピュータ）と第１サテライト・ゲートウェイの間での第１通信接続をインターセプトするためのコードを含む。また、このシステムは、サテライト・リンクを介して第１サテライト・ゲートウェイと第２サテライト・ゲートウェイの間で第２通信接続を形成するためのコードも含む。第１接続の特性（例えば、送信元および宛先のＩＰアドレスおよびポート番号）を記述する情報が、第２サテライト・ゲートウェイに伝送される。第３通信接続が、第２サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第１クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【００１７】
特定の実施態様では、本発明は、サテライト・リンクを介して情報を伝送するための通信方法を提供する。この方法は、ＴＣＰ接続を使用して、データおよびヘッダを有する双方向フローの情報を提供するステップを含む。単に例としてあげると、双方向フローの情報は、インターネット、またはコンピュータのインターネット様のネットワーク、あるいはＴＣＰ／ＩＰプロトコルを使用する任意のネットワークからのものでよい。また、この方法は、ＴＣＰ接続を使用して、サテライト・リンクを介する伝送のためのサテライト・プロトコルに情報を変換するステップも含む。このサテライト・プロトコルは、サテライト・リンクを介するそうした情報の伝送のための適切な特性を有する。このプロトコルには、とりわけ、ＸＴＰ、ＸＴＰ様のプロトコルなどが含まれ得る。
【００１８】
代替の実施態様では、本発明は、ＴＣＰ接続を使用するサテライト・リンクを介した情報の伝送のために、複数の接続を確立する通信方法を提供する。この方法は、第１クライアント（例えば、ユーザ・コンピュータ）と第１サテライト・ゲートウェイの間での第１通信接続をインターセプトするステップを含む。また、この方法は、サテライト・リンクを介して第１サテライト・ゲートウェイと第２サテライト・ゲートウェイの間で第２通信接続を形成するステップも含む。第１接続の特性（例えば、送信元および宛先のＩＰアドレスおよびポート番号）を記述する情報が、第２サテライト・ゲートウェイに伝送される。第３通信接続が、第２サテライト・ゲートウェイと宛先サーバの間で形成される。これらの接続の結合が、元の第１クライアントから宛先サーバまでのトランスペアレントな接続を形成する。
【００１９】
特定の実施態様では、本発明は、メモリを管理するため、かつサテライト・リンクを介して確立されたインターネット接続を介して通信される情報をバッファリングする方法を提供する。この方法は、１つまたは複数のクライアントと、１つまたは複数のサーバと、少なくとも１つのクライアントに接続された第１ゲートウェイと、少なくとも１つのサーバに接続された第２ゲートウェイと、これらのゲートウェイ間の無線遠隔通信リンクとを含むシステムなどの、多種多様なシステム上で実行できる。この方法は、クライアントによって開始されたサーバとの接続の試行をインターセプトするステップを含む。クライアントは、第１特性データ通信速度を有することになる接続を試みる。接続は、サテライト・リンクまたはそれに類するものであり得る遠隔通信リンクを介して、第１ゲートウェイと第２ゲートウェイの間で確立される。この接続は、第２特性データ通信速度を有することになる。第１ゲートウェイは、遠隔通信リンクを介して第２ゲートウェイから受信した情報を記憶するバッファと、クライアントに送信される情報を記憶するバッファとを含む。この方法は、受信バッファ内の状態を判定するステップを実行することができる。その状態は、遠隔通信リンク内での特性データ通信速度が、クライアントに対する特性データ通信速度よりも相当に高いかどうかを示すことができる。クライアントに対して遠隔通信リンクを介して受信されるデータの量を抑えるように、第１ゲートウェイで、クライアントに対する受信ウィンドウ・サイズを設定するステップもまた、この方法の一部であり得る。これらのステップの結合が、第１ゲートウェイ内で遠隔通信リンクから着信する情報をバッファリングするためにメモリを管理する方法を提供することができる。
【００２０】
本発明の別の態様では、サテライトを介する情報のフローを制御するシステムが提供される。このシステムは、複数の潜在的クライアントのうちから選択された少なくとも１つのクライアントと、複数の潜在的サーバのうちから選択された少なくとも１つのサーバとを含み得る。また、このシステムは、第１遠隔通信リンクによってクライアントに接続された第１ゲートウェイと、第２遠隔通信リンクによってサーバに接続された第２ゲートウェイとを含み得る。また、第１ゲートウェイと第２ゲートウェイを接続する第３遠隔通信リンクも、このシステムの一部であることが可能である。このシステムは、クライアントによって開始された、第１特性データ通信速度での、サーバとの接続の試行をインターセプトするように動作する。次に、このシステムは、第３遠隔通信リンクを介して、第１ゲートウェイと第２ゲートウェイの間での接続を確立することができる。この接続は、第２特性データ通信速度を有することになる。第１バッファが、第３遠隔通信リンクを介して受信した情報を記憶して、第２バッファが、クライアントに送信される情報を記憶する。このシステムは、第１バッファ内での状態を判定することができる。その状態は、第３遠隔通信リンク内の第２特性データ通信速度が、クライアントに対する第１特性データ通信速度よりも高いことを示す。また、このシステムは、クライアントに対して第３遠隔通信リンクを介して受信されるデータの量を抑えるように、第１ゲートウェイで、クライアントに対する受信ウィンドウ・サイズを設定することもできる。
【００２１】
本発明によるさらなる態様では、無線データ・リンクを介する情報のフローを制御するコンピュータ・プログラム製品が提供される。このデータ・リンクは、１つまたは複数の接続を含み得る。このコンピュータ・プログラム製品は、複数のコードを保持するコンピュータ可読記憶媒体を含む。クライアントによって開始された、第１特性データ通信速度での、サーバとの接続の試行をインターセプトするコードが、このプログラム製品に含まれる。さらに、遠隔通信リンクを介して、第２特性データ通信速度で、第１ゲートウェイと第２ゲートウェイの間で接続を確立するコードも含まれる。第１ゲートウェイ内の第１バッファが、遠隔通信リンクを介して受信された情報を記憶して、第２バッファが、クライアントに送信される情報を記憶する。この製品は、また、第１バッファ内の状態を判定するコードも含む。その状態は、遠隔通信リンクの特性データ通信速度が、クライアントのそれよりも相当に高い状況を示す。この状況が検出された場合には、この製品は、クライアントに対する遠隔通信リンクを介して受信されるデータの量を抑えるように、第１ゲートウェイでクライアントに対する受信ウィンドウを設定するコードを呼び出す。
【００２２】
特定の実施態様では、本発明は、サテライト・リンクを介して確立されたインターネット接続を介する情報のフローを制御する方法を提供する。この方法は、１つまたは複数のクライアントと、１つまたは複数のサーバと、少なくとも１つのクライアントに接続された第１ゲートウェイと、少なくとも１つのサーバに接続された第２ゲートウェイと、これらのゲートウェイ間の無線遠隔通信リンクとを含むシステムなどの、多種多様なシステム上で実行され得る。この方法は、クライアントによって開始されたサーバとの接続の試行をインターセプトするステップを含む。接続は、サテライト・リンクまたはそれに類するものであり得る遠隔通信リンクを介して、第１ゲートウェイと第２ゲートウェイの間に確立され得る。この方法は、データが、クライアントからサーバまで接続を介して伝わるのにかかる往復時間を判定するステップを含み得る。接続に関するデータ通信速度を判定することができる。往復トリップ時間およびデータ通信速度から、帯域幅遅延積(bandwidth-delay product）が、この方法によって判定され得る。この方法は、また、その帯域幅遅延積から、その接続に対するフロー制御制限を決定することもできる。フロー制御制限に基づいて、接続を介するデータ転送を制限するステップをこの方法の一部としてもよい。こられのようなステップの結合が、無線通信メディアなどを使用する、広い地理的領域にわたるネットワーク上で、ＴＣＰデータのフローを制御する方法を提供する。
【００２３】
別の実施態様では、本発明は、接続のうちから、フロー制御されることによって利用可能なシステム・リソースに有益であり得るものを選択することができる。いくつかの実施態様は、フロー制御のために、初期設定中ではない接続、あるいはしきい値を下回って、またはしきい値を上回って、ブロックでデータを転送している接続などをスクリーニングすることができる。多くの実施態様では、接続に関する帯域幅遅延積は、往復時間とデータ通信速度を掛けることによって判定される。いくつかの実施態様では、接続に対するフロー制御制限は、帯域幅遅延積に倍率を掛けて、そのリンクに関する接続の数でそれを割ることによって決定される。
【００２４】
本発明の別の態様では、サテライトを介する情報のフローを制御するシステムが提供される。このシステムは、複数の潜在的クライアントのうちから選択された、少なくとも１つのクライアントと、複数の潜在的サーバのうちから選択された少なくとも１つのサーバとを含む。また、このシステムは、第１遠隔通信リンクによってクライアントに接続された第１ゲートウェイと、第２遠隔通信リンクによってサーバに接続された第２ゲートウェイとを含み得る。また、第１ゲートウェイと第２ゲートウェイを接続する第３遠隔通信リンクも、このシステムの一部であることが可能である。このシステムは、データが、クライアントから、第１遠隔通信リンク、第２遠隔通信リンク、および第３遠隔通信リンクを介して、接続上でサーバまで渡るのにかかる往復時間を判定するように動作する。このシステムは、その接続に関するデータ通信速度を判定することができる。さらに、このシステムは往復時間とデータ通信速度から帯域幅遅延積を判定することができる。このシステムは、帯域幅遅延積から接続に対するフロー制御制限を決定して、そのフロー制御制限に基づいて、その接続を介するデータ転送を制限することができる。そうした方式でデータ転送を制限することは、例えば、遠隔通信リンク上での比較的高速のデータ転送をクライアントでの比較的遅いデータ転送にインターフェースすることができる。
【００２５】
本発明によるさらなる態様では、無線データ・リンクを介する情報のフローを制御するコンピュータ・プログラム製品が提供される。データ・リンクは、１つまたは複数の接続を含み得る。このコンピュータ・プログラム製品は、複数のコードを保持するコンピュータ可読記憶媒体を含む。データが、接続を介して無線データ・リンクを渡るのにかかる往復時間を判定するコードが、この製品の一部であり得る。さらに、このコンピュータ・プログラム製品は、接続に関するデータ通信速度を判定するコードを含み得る。また、往復時間およびデータ通信速度から帯域幅遅延積を判定するコードも含まれ得る。帯域幅遅延積から接続に対するフロー制御制限を決定するコード、およびそのフロー制御制限に基づいて、その接続を介するデータ転送を制限するためにコードもまた、このコンピュータ・プログラム製品の一部であり得る。
【００２６】
本発明の別の態様では、サテライトなどの、ネットワーク内の所定ポイントを通って流れる情報に関するデータ通信速度を、そのネットワーク上の遠隔ポイントのデータ通信速度能力にマッチさせるための技法が提供される。一実施態様では、本発明は、サテライト装置を介する適切なデータ通信速度または所定のデータ通信速度を維持するため、転送速度制御を提供する。この転送速度制御は、着信データをバッファリングする複数の待ち行列を提供する。着信データは、所定の長さに照らして検査される。その所定の長さを越えるデータが、その待ち行列内に記憶される。所定の間隔で、情報が、１つまたは複数の待ち行列から取り出されて、発信データ・パスに沿って伝送される。この処理は、本発明によるシステムが、サテライト・リンクなどのネットワークに沿った特定のポイントを通るデータ通信速度制御を提供することを可能にする。
【００２７】
本発明の別の態様では、クライアントとサーバの間のＴＣＰプロトコルでのパケット化された情報をトランスポートする通信システムを、クライアントとサーバの間のサテライト・プロトコルでのパケット化された情報をトランスポートするシステムに変換する方法が、クライアントからサーバへの接続をインターセプトするように動作可能に構成された第１ゲートウェイを設置するステップを含む。第１ゲートウェイは、さらに、ＴＣＰプロトコルからサテライト・プロトコルにパケット化された情報を変換することができる。また、サーバとの接続を確立することができ、さらに、サテライト・プロトコルからＴＣＰプロトコルにパケット化された情報を変換するように動作可能に構成された第２ゲートウェイを設置するステップも、この方法に含まれる。第１ゲートウェイおよび第２ゲートウェイは、共通遠隔通信リンクを介して接続を確立することができる。これらの要素の結合が、ＴＣＰ遠隔通信のためのシステムをサテライト・プロトコル通信に変換する方法を提供することができる。
【００２８】
本発明を使用して、従来の技法に優る多数の利点が実現される。特定の実施態様では、本発明は、従来のシステムよりも高いスループットを提供する。さらに、本発明は、サテライト・ネットワークを介するＴＣＰパフォーマンスをトランスペアレントに向上させる方法を提供する。他の実施態様では、本発明は、サテライト通信に特有の長い待ち時間、高い損失、および非対称帯域幅条件に適した斬新なプロトコルを提供する。
【００２９】
特定の実施態様では、本発明による技法は、受信ウィンドウを迅速にサイズ変更して、サテライト・リンクを介する、送信側のデータ通信速度とＴＣＰ接続の受信側のデータ通信速度との間のマッチを実現することができる。いくつかの実施態様では、本発明の技法は、各サテライト接続に別々に提供することが可能であり、したがって、１つの遅い受信側が、同一リンクを介する他の接続のパフォーマンスを低下させることがない。いくつかの実施態様では、本発明は、サテライト通信に特有の、長い待ち時間、高い損失、および非対称性帯域幅条件に適した斬新なプロトコルでのバッファ・メモリの管理を提供する。特定の実施態様では、本発明は、従来システムよりも均等なネットワーク・リソースの配分を提供する。本発明による多くの実施態様は、接続間でネットワーク・リンク／サテライト・リンクを共用することを提供する。多くの実施態様では、１つの特定の接続からのデータのバーストが、他の接続に対するデータに先立って、リンクを介する伝送のために待ち行列化される可能性がより低い。他の実施態様では、本発明は、サテライト通信に特有の長い待ち時間、高い損失、および非対称帯域幅条件でのデータ・フロー制御を提供する。
【００３０】
また、本発明は、従来のサテライト・システム内での比較的簡単な実装、またはそれとの比較的簡単なインターフェースを提供する。実施態様に応じて、これらの利点のうちの１つまたは複数が存在し得る。これらの、また他の利点および利益は、本明細書全体にわたって記載しており、また下記により詳細に記載する。
【００３１】
本発明のこれらの実施態様および他の実施態様は、下記のテキストおよび添付の図に関連して、より詳細に記載する。
【００３２】
（特定の実施形態の説明）
様々な実施形態を論ずる前に、サテライト・ネットワークを介してＴＣＰを使用することの制限をより完全に理解することは読者の助けとなろう。以下でこの制限をより完全に説明する。
【００３３】
輻輳回避： 輻輳ネットワーク・メルトダウンの可能性を回避するために、一般にＴＣＰは、全てのデータ損失が輻輳によって引き起こされ、伝送速度を減少させることによって応答すると想定する。しかし、サテライト・リンクを介して、ＴＣＰは、しばしば長い往復時間およびビット・エラーを輻輳と誤解し、不適切に応答する。同様に、ＴＣＰ「スロー・スタート（ｓｌｏｗ ｓｔａｒｔ）」アルゴリズムは、地上のインフラストラクチャを介して新しい接続が既に輻輳したネットワークを氾濫するのを防止し、サテライトを介して新しい各接続に対して過剰に長いランプアップ（ｒａｍｐ−ｕｐ）を強制する。これらの輻輳回避機構は、経路指定環境で重要であるが、サテライト・リンクにはしばしば不適切である。
【００３４】
データ肯定応答： ＴＣＰによって使用される単純でヒューリスティックなデータ肯定応答方式は、一般に長い待ち時間または非常に非対称な帯域幅条件に対してはあまり適合しない。信頼できるデータ伝送とするために、ＴＣＰ受信機は、しばしば、送信側に送り返されるデータに対する肯定応答を絶えず送信する。送信側は、一般に肯定応答を受信することなく多数の往復時間が経過するまで、何らかのデータが紛失または壊れるとは想定しない。パケットが紛失または壊れた場合、ＴＣＰは、最初の欠落パケットから始まるデータの全てを再送信する。アルゴリズムは、往復時間が長く、エラー率が高いサテライト・ネットワークを介しては十分には応答することができない。さらに、肯定応答の一定ストリームは、しばしば貴重なバック・チャネル帯域幅を浪費する。バック・チャネル帯域幅が小さい場合、送信側への肯定応答の戻りは、ある場合には、システム・ボトルネックとなる可能性がある。
【００３５】
ウィンドウ・サイズ： ＴＣＰは、スライド式ウィンドウ機構を使用してフライト中のデータ量を制限する。ウィンドウが実質上満杯になった場合、送信側は、宛先サーバからの新しい肯定応答を受け取るまでデータの送信を停止する。肯定応答の戻りが低速なサテライト・ネットワークを介して、ＴＣＰウィンドウ・サイズは、一般に最大データ・スループット・レートに対して厳しい制限を設定する。エラーのないリンクを完全に利用するためにしばしば必要な、「帯域幅遅延積」として知られる最小ウィンドウ・サイズは、例えばＴ１サテライト・リンクに対しては１００Ｋバイトであり、１０ＭＢｐｓリンクに対しては６７５Ｋバイトである。ビット・エラーは、必要なウィンドウ・サイズをさらに増加させる可能性がある。しかし、ＴＣＰ／ＩＰの大部分の実装は、しばしば最大ウィンドウ・サイズ６４ＫＢに制限され、多くの共通オペレーティング・システムは、デフォルト・ウィンドウ・サイズ８ＫＢのみを使用し、データ・パイプの帯域幅に関わらず、サテライト・リンクを介する最大スループット速度が１接続あたり１２８Ｋｂｐｓとなる。
【００３６】
本発明によれば、広域無線ネットワークを介するＴＣＰ接続を行う技術が提供される。例示的実施形態では、本発明は、ＸＴＰ接続へのＴＣＰ接続を使用して情報を変換する装置、システム、および方法を提供する。ＸＴＰ接続は、サテライト・システムなどの無線ネットワーク・システムを介した伝送により適している。
【００３７】
さらに、本発明によれば、ＴＣＰ接続中の情報フローを制御し、無線広域ネットワークを介する１つまたは複数のＴＣＰ接続に対してメモリを管理する技術が提供される。例示的実施形態では、本発明は、無線ネットワーク・システムを介して送信される、情報のフローおよび／またはバッファリング情報のためのメモリ管理を制御する方法およびシステムを提供する。ＸＴＰ接続は、サテライト・システムなどの無線ネットワーク・システムを介した伝送により適している。本発明の詳細を本明細書を通して、より具体的に以下で説明する。
【００３８】
図１は、本発明の実施形態によるサテライト・システム１００の単純化したダイアグラムである。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。とりわけ、システム１００は、サテライト１０１を有するサテライト・ネットワーク・システムを含む。サテライト１０１は、複数の地上局１０７、１０８、またはサテライト・ディッシュの間で情報を受信し、送信する。各サテライト地上局は、サテライト・ディッシュ、およびサテライト・モデム１０９Ａ、１０９Ｂ、またはＶＳＡＴインドア・ユニットなどの他の形態の受信機を含む。ＶＳＡＴインドア・ユニットは、サテライト・ゲートウェイ１１１Ａ、１１１Ｂに直接に、または間接に結合する。
【００３９】
サテライト・アンテナ１０８は、サテライト１０１を介して信号１０３を受信し、送信する。サテライト・アンテナ１０８は、インターネット１２９またはインターネットなどの広域ネットワークに結合するサテライト・ゲートウェイ１１１Ｂに接続する。広域ネットワークは、サーバ１３１に結合する。ゲートウェイ１１１Ｂも、サテライト・モデム１０９Ｂを介して結合する。サーバおよびインターネット通信は、ＴＣＰ／ＩＰ、ＵＤＰ／ＩＰなどの共通プロトコルで行われる。サテライト・ゲートウェイを以下でより詳細に説明する。
【００４０】
サテライト・アンテナ１０７は、サテライト１０１を介して信号１０５を受信し、送信する。サテライト・アンテナ１０７は、イーサネット、トークン・リング、ＦＤＤＩなどのローカル・エリア・ネットワーク１２１に結合するサテライト・ゲートウェイ１１１Ａに接続する。ローカル・エリア・ネットワーク１２１は、端末１２３またはクライアントに結合する。ここで、サテライト・ゲートウェイは、モデム１１９を介してラップトップ１１７に結合する。クライアント、ラップトップ、およびローカル・エリア・ネットワークは、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸなどの共通接続フォーマットを使用する。サテライト・ゲートウェイを以下でより詳細に説明する。
【００４１】
特定の実施形態では、サテライト・ゲートウェイ１１１Ａは、クライアントからのＴＣＰ接続をインターセプトし、サテライト１０１を介して送信するためにデータ１０５をサテライト・プロトコルに変換する。ゲートウェイ１１１Ａは、データをサテライト１０１に送信するサテライト・モデム１０９Ａを介しても結合する。サテライト・リンクの反対側のサテライト・ゲートウェイ１１１Ｂは、サーバ１３１と通信するためにサテライト・プロトコルでのデータをＴＣＰに変換し戻す。特定の実施形態では、本発明は、従来技術を超えて性能を向上させる。加えて、本発明の技術は、実質上エンド・ユーザにトランスペアレントのままであり、完全にインターネットまたはインターネット・インフラストラクチャと適合する。全ての態様でないとしても、多くの場合、クライアントまたはサーバには実質上の変更は必要ではない。好ましい実施形態では、アプリケーションは、実質上のハードウェアおよび／またはソフトウェア修正なしに引き続き機能する。
【００４２】
上記では、特定のネットワーキング・ダイアグラムの点から説明したが、他の構成でこのサテライト・ゲートウェイを実装することが可能である。例えば、このサテライト・ゲートウェイは、複数のリモート・ゲートウェイの働きをする１つの「ハブ」または中央ゲートウェイでよい。各リモート・ゲートウェイは、中央ゲートウェイに接続され、個々のサテライト・リンクが作成される。
【００４３】
他の共通ネットワーク・トポロジも使用することができる。さらに、ある実施形態では、異なる電気通信リンクを使用して、接続の順方向または逆方向パスを搬送することができる。例えば、サテライト・リンクを使用して、順方向パス上でデータを搬送することができ、同時に逆方向パスのために電話線を使用することができる。本発明の範囲を逸脱することなく、ここで述べた例示的ハードウェアを他のタイプの電気通信ハードウェアで置き換えることもできる。
【００４４】
加えて、このサテライト・ゲートウェイを一般に独立型ユニットとして説明する。しかし、このゲートウェイをクライアント・マシン中に実装または一体化することができることは理解されよう。例えば、このゲートウェイは、サテライト・カードを使用してパーソナル・コンピュータ上に実装することができる。このサテライト・カードは、ウィンドウズ（商標）９８マシン中に挿入することができる。このゲートウェイは、ウィンドウズＮＴ、ＭａｃＯＳ、およびＬｉｎｕｘなどの他のオペレーティング・システム上に実装することもできる。もちろん、実装の厳密な方式は、アプリケーションに依存することになる。加えて、このサテライト・ゲートウェイは、独立型サテライト・モデム、ＶＳＡＴハードウェア、ルータ、または他のネットワーク装置中に一体化することもできる。
【００４５】
Ｉ．プロトコル設計
特定の実施形態では、本発明は、サテライト・ネットワークについてのスループットを向上する新規サテライト・プロトコルを含む。本プロトコルは、典型的なサテライト待ち時間、ビット・エラー、および非対称な帯域幅条件に対して効果的に応答するように設計することができる。このプロトコルは、固定帯域幅を有するポイントツーポイント・リンク上で可能な最適化も利用することができる。ＸＴＰなどのサテライト・プロトコルに関するより詳しい情報は、Ｔｉｍ Ｓｔｒａｙｅｒの「Ａ Ｂｒｉｅｆ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ ｔｈｅ Ｘｐｒｅｓｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ，」から得ることができ、その全体を参照することにより実際上本明細書に組み込む。このサテライト・プロトコルのこれらおよび他の特徴を以下でより詳細に説明する。
【００４６】
このプロトコルは、効果的なデータの肯定応答用選択的再送信アルゴリズムを利用する。サテライトを介するホップが、中間経路指定を用いないポイントツーポイント・リンクのために、パケット中のどんなギャップも破壊によるデータ紛失であると想定することができる。受信側サテライト・ゲートウェイは、送信側サテライト・ゲートウェイからの欠落データを検出すると即時に再送信を要求する。
【００４７】
このプロトコルは、実質上従来のＴＣＰの頻繁な肯定応答機能に束縛されない。ある実施形態では、このプロトコルは、紛失データを識別する主な手段のようには肯定応答機能を使用しない。これらの実施形態において、このプロトコルで必要なのはデータ到着およびバッファを消去する低頻度の肯定応答機能だけである。（従来のＴＣＰは、リバース・チャネルを介して肯定応答の一定ストリームを送信する。）このプロトコルは、７０％以上バック・チャネル使用を低減し、それによって限定的バック・チャネル帯域幅がシステムのボトルネックであるネットワークの性能を向上する。
【００４８】
このプロトコルは、サテライト・ゲートウェイ間でデータを転送するのに十分大きいウィンドウ・サイズを提供する。サテライト・ゲートウェイ間のサテライトを介する帯域幅遅延積が、サテライト・ゲートウェイからエンド・ノードへの帯域幅遅延積よりもずっと大きいので、この大きいプロトコル・ウィンドウにより、ウィンドウ・サイズ比に対する帯域幅遅延の生成が比較的一定のままとどまることが可能となる。このゲートウェイは、ネットワークに対するバッファとなり、クライアントおよびサーバのウィンドウ・サイズに依存しない高スループットが可能となる。
【００４９】
このプロトコルは、一般には、サテライト・ゲートウェイ間のサテライトを介するホップ用の不必要な輻輳回避機構を使用しないが、このゲートウェイとエンド・ノードの間の地上接続用の「スロー・スタート」および全ての他の標準ＴＣＰ輻輳回避アルゴリズムを引き続き使用する。このプロトコルは、ストリームライン式ハンドシェーク機構を使用して、接続セットアップに必要な往復回数を低減することもできる。
【００５０】
この装置、システム、および方法は、経路指定ネットワークとの互換性を有するようにＩＰを介して実行することができる。あるいは、この装置は、大部分の例で性能を実質上向上させるために、リンク層を介して直接実行することができる。実施形態に応じてこれらの機能のうちの１つまたは複数を利用することができる。
【００５１】
上記を本サテライト・プロトコルの望ましい特徴によって一般的に説明した。多くの他のタイプの特徴が利用可能であることを理解されよう。加えて、本発明は、必ずしも前述の各特徴を必要としない。適用例に応じてどんな組み合わせも使用することができる。他の変形形態、修正形態、および代替形態を当業者は理解されよう。
【００５２】
ＩＩ．ＸＰＲＥＳＳ移送プロトコル
好ましい実施形態では、本発明は、一般にＸＴＰとして知られている「Ｘｐｒｅｓｓ移送プロトコル」を提供する。ＸＴＰは、ポリシーからの実装の分離、転送速度およびフロー制御の分離、マルチキャスト用の明示的ファーストクラス・サポート、およびデータ送達サービス独立性のための直交プロトコル機能を提供する。ＸＴＰは、サテライト・リンクを介したデータの送信に適した様々な特徴を有し、それらを以下でより完全に説明する。
【００５３】
特定の実施形態では、本プロトコルは、その機能性が直交性である１組の機構を含む。この最も特筆すべき効果は、ＸＴＰが、利用されるエラー制御ポリシーから通信機構（例えば、データグラム、仮想回路、トランザクションなど）を分離することである（未修正でも完全に信頼できる）。さらに、通信に対してフローおよび転送速度制御ならびにエラー制御を手元で調整することができる。望む場合には、これらの制御処理のどんな組もオフにすることができる。
【００５４】
本プロトコルは、転送速度およびフロー制御の分離も提供する。一般には、フロー制御は、エンドツーエンド・バッファ空間上で動作する。転送速度制御は、プロセッサ速度および輻輳を考慮に入れる生成側／消費側の概念である。ＴＣＰは、転送速度制御を提供せず、スロースタートおよび他のヒューリスティックを用いて輻輳に対処する。ＸＴＰは、転送速度制御およびフロー制御を独立に形成する機構を提供する。
【００５５】
特定の実施形態では、本プロトコルは、明示的マルチキャスト・サポートを提供する。ここで、マルチキャストは、ＸＴＰ中の追加部分ではない。ユニキャスト通信をするために使用される各機構はマルチキャストでも利用可能である。
【００５６】
本プロトコルは、データ送達サービス独立性も有する。具体的には、ＸＴＰは、トランスポート・プロトコルであるが、経路指定ネットワークではなく交換ネットワークの出現に伴って、従来のネットワーキング層サービスは、あらゆる例において適切ではない可能性がある。ＸＴＰは、基礎となるデータ送達サービスがあるＸＴＰ装備ホストから別のＸＴＰ装備ホストにパケットをフレーム指示し、送ることを一般に必要とする。これは、ロウＭＡＣまたはＩＰまたはＡＡＬ５でよい。ＸＴＰは、パラメトリック・アドレス指定も利用し、パケットをいくつかの標準アドレス指定フォーマットのうちのいずれか１つでアドレス指定することが可能となる。ＸＴＰの他の特徴には、とりわけ仮想回線パラダイムに対する暗黙高速接続セットアップ、キーベース・アドレス指定ルックアップ、メッセージ優先度およびスケジューリング、カプセル化および収束プロトコルに対するサポート、選択的再送信および肯定応答、ならびに固定サイズ６４ビット位置合わせフレーム設計が含まれる。
【００５７】
ＸＴＰは、１つの末端システムから１つまたは複数の他の末端システムにユーザ・データを送るのに必要な機構を定義する。各ＸＴＰ実装は、その各通信の状態を維持する。ユーザ・データまたは制御情報を含む明確なパケット構造は、ユーザ・データの転送を実施するために交換される。制御情報は、正確な要求された層を提供し、転送を効果的に行うよう助けるために使用される。正確さの保証は、エラー制御アルゴリズムおよび接続状態マシンの維持を介して行われる。可能な限り効果的に要求されたサービスの品質を提供するためにフローおよび転送速度制御アルゴリズム、あるプロトコル・モード、およびトラフィック形成情報が使用される。
【００５８】
末端システムでのＸＴＰ状態を含む情報のコレクションは、コンテキストと呼ばれる。この情報は、２つ（またはそれ以上）のアクティブ通信の１つのインスタンスを表す。コンテキストは、ＸＴＰパケットを送信または受信する前に作成し、インスタンス化すべきである。末端システムで各アクティブ会話またはメッセージについての多くのアクティブ・コンテキストがある可能性がある。
【００５９】
各コンテキストは、発信データ・ストリームおよび着信データ・ストリームのどちらも管理する。データ・ストリームは、各バイトがシーケンス番号によって表される連続バイトの任意長ストリングである。アクティブ・コンテキストの対の集合およびそれらの間のデータ・ストリームは、アソシエーションと呼ばれる。
【００６０】
末端システムでのコンテキストは、初めは静止状態にある。通信サービスを必要とするユーザは、コンテキストが聴取状態に配置されることを要求する。次いでコンテキストは適切なＦＩＲＳＴパケットを求めて聴取する。ＦＩＲＳＴパケットは、アソシエーションの初期パケットである。ＦＩＲＳＴパケットは、明示的アドレス指定情報を含む。ユーザは、ＸＴＰが着信ＦＩＲＳＴパケットと聴取コンテキストとをマッチングするのに必要な情報の全てを提供する。
【００６１】
別の末端システムでは、ユーザは、ＸＴＰからの通信サービスを要求する。このユーザは、アソシエーションを開始するので、コンテキストは、静止状態からアクティブ状態に直接移る。アクティブ・コンテキストは、ＦＩＲＳＴパケットを構築し、ユーザからの明示的アドレス指定情報で完成する。ＦＩＲＳＴパケットは、基礎となるデータ送達サービスを介して送信される。
【００６２】
ＦＩＲＳＴパケットが第１ホストのＸＴＰ実装で受信されたとき、アドレスが、全ての聴取コンテキストに対して比較される。マッチが見つかった場合、聴取コンテキストは、アクティブ状態に移る。この点から、アソシエーションの転送が確立され、通信を完全に対称とすることができる。アソシエーション中で、各方向の２つのデータ・ストリームがあるからである。さらに、アソシエーションの存続期間の間に他のパケットは、明示的アドレス指定情報を搬送しないことになる。むしろ、パケットを適切なコンテキストにマップする固有「キー」が各パケット中で搬送される。
【００６３】
あるユーザから全てのデータが送信されると、そのユーザのコンテキストからのそのデータ・ストリームを閉じることができる。パケット中のオプションの形態の標識が、交換され、接続が適切にクローズされる。他の形態のより適切さの欠けるクロージングも、この交換を省略することによって可能である。両方のユーザが行い、両方のデータ・ストリームがクローズしたとき、コンテキストは、非アクティブ状態に移行する。コンテキストのうちの１つは、アソシエーションの解消を引き起こす標識を送信することになる。この時点では、両方のコンテキストは静止状態に戻る。
【００６４】
一般には、ＸＴＰのパケット・タイプの全ては共通ヘッダ構造を使用する。処理の適切な点にパケットのペイロードをステアするのに必要な情報の全ては、ヘッダ中で搬送する。ＸＴＰコンテキストの動作の仕方の多くは、パケット・ヘッダ中の１つのフィールドに集中する１組のビット・フラグによって制御される。接続シャットダウンを制御するビット・フラグ、肯定応答ポリシーを制御するビット・フラグ、データ・ストリーム中のマーカであるビット・フラグを含む１５個のフラグが定義される。残りのビット・フラグは、エンドツーエンド・オペレーティング・モードを制御する。例は、エラー制御またはフロー制御のイネーブルまたはディセーブル、あるいはマルチキャスト・モードのイネーブルを含む。
【００６５】
ＸＴＰは、６４ビット・シーケンス番号および６４ビット・スライド式ウィンドウに基づく。ＸＴＰは、転送速度制御も提供し、それによって末端システムまたは中間システムは、接続時に受け入れることになる最大帯域幅およびバースト・サイズを指定することができる。トラフィック・セグメントは、トラフィックの形状を指定する手段を提供し、その結果末端システムおよび中間システムが、そのリソースを管理し、サービス品質保証を容易にすることができる。
【００６６】
ＸＴＰでのエラー制御は、正および適切なときには負の肯定応答を取り込み、欠落または損傷データ・パケットの再送信を実施する。再送信は、ｇｏ−ｂａｃｋ−Ｎまたは選択式のいずれかで良い。再送信アルゴリズムは保守的である。すなわち、制御メッセージを介して欠落していることが示されるデータのみを送信することができる。これは、スプリアスおよび可能な輻輳誘発再送信を回避する。エラー制御アルゴリズムは、基本的には保守的ながら、活動的になることもできる。すなわち、速動エラー通知に関するシステム、技術、および方法が提供される。
【００６７】
ＸＴＰは、エラー制御をマルチキャスト環境に拡張する技術も指定する。マルチキャストでのエラー制御アルゴリズムは、ユニキャスト・アルゴリズムと同一である。とはいえ、状態変数を管理し、連続ストリーミングを実現するために追加の高度化が必要である。したがって、ＸＴＰは、本発明による好ましいサテライト・プロトコルである。
【００６８】
前述ではＸＴＰプロトコルを用いて一般に説明したが、他のタイプのプロトコルも使用することができることを理解されよう。例えば、プロトコルは、修正ＴＣＰ、修正ＸＴＰなどで良い。加えて、プロトコルは、サテライトを介する伝送に適するどんなものでも良い。加えて、当業者は、他の変形形態、修正形態、および代替形態を理解されよう。
【００６９】
図２は、本発明の実施形態によるシステム・アーキテクチャ２００の単純化したダイアグラムである。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。システム・アーキテクチャ２００は、少なくともクライアント２０１を含み、クライアント２０１はサテライト・ゲートウェイ２０３に結合し、サテライト・ゲートウェイ２０３は、サテライト・リンク２０９を介してサテライト・ゲートウェイ２０５からの情報を送受信する。サテライト・ゲートウェイ２０５は、サーバ２０７に結合する。サテライト・ゲートウェイおよびサーバは、インターネットまたはインターネットライクなコンピュータのネットワークを介して互いに結合する。
【００７０】
クライアント２０１は、アプリケーションおよび物理層を含む多層で表すことができる。この層は、ブラウザ２１１を含むことができる。ブラウザ２１１により、ゲートウェイに送信するために、ユーザがアプリケーション層から物理層に情報を通信することが可能となる。ブラウザ２１１は、一般には、情報を提供するアプリケーション層中にある。例えば、ブラウザは、カリフォルニア州マウンテンビューのＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐｏｒａｔｉｏｎ、またはワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎと呼ばれる会社、あるいは他の会社によって行われた適切な設計のうちの１つとすることができる。ブラウザに加えて、ＦＴＰファイル転送を含む他のＴＣＰアプリケーションも、クライアントとサーバ間で通信するために使用することができる。
【００７１】
情報は、トランスポート層（例えばＴＣＰ）を介して、次いでＩＰ層２１５を介して進む。ＩＰ層２１５は、ネットワーキング層である。トランスポート層は、クライアントとゲートウェイとの間のデータのフローを提供する。ＩＰ層は、クライアントとゲートウェイ、または他のネットワークとの間のパケットを含むデータの移動を扱う。情報は、物理層を介して送信され、物理層はドライバ２１７を含む。ドライバ２１７は、電気通信リンク２２１を介してゲートウェイ２０３に接続されるハードウェア２１９を介してゲートウェイ２０３に情報を送信する。電気通信リンク２２１は、ワイヤ、ケーブル、光ファイバ、または他の物理通信媒体でよい。あるいは、ドライバ２１７は、リンク２２１およびハードウェア２１９を介してゲートウェイ２０３から情報を受信する。例えば、ドライバは、クライアント・コンピュータ中のネットワーク・インターフェース・カードを有するネットワーク・オペレーティング・システムで良い。
【００７２】
情報は、物理接続２２１からゲートウェイ２０３へわたる。ゲートウェイは、物理層２２３を有し、物理層２２３はドライバ２２５と対話する。ゲートウェイは、ネットワーキング層２２７およびトランスポート層２２９も含む。トランスポート層２２９は、変換モジュール２３１に結合する。ネットワーキング層２２７は、情報をサテライト・プロトコルを介して発送できるかどうかを判定する。発送できる場合は、データは、上部のトランスポート層２２９に渡される。発送できない場合は、データは、非変換形態でサテライト・リンク２３９に送るために転送速度制御モジュール２３４に即時に転送される。変換モジュール２３１は、衛星リンクを介して使用するのに適したサテライト・プロトコル２３３に情報を変換する。転送速度制御モジュール２３４は、情報を即時にサテライト接続に渡すことができるか、それとも後に送るために待ち行列化するどうかを判定する。サテライト接続は、ドライバ２３５によって物理層２３７に結合し、ドライバ２３５は、情報を衛星２０９に、かつそこから伝送する。情報は、無線媒体２３９、２４１中を衛星に向かって、かつ衛星から送られる。
【００７３】
情報は、サテライト・ゲートウェイ２０５によって受信される。サテライト・ゲートウェイ２０５は、物理層、および他の層の多層を含む。物理層２４３は、ドライバ２４５に結合する。ネットワーキング層およびトランスポート層は、サテライト・プロトコル２４７および転送速度制御２４４を含む。ネットワークおよびトランスポート層は、変換モジュール２４９を含むセッション層に接続する。変換モジュールは、サテライト・プロトコルを使用して情報をＴＣＰ／ＩＰに変換し戻す。情報は、トランスポート層（すなわちＴＣＰ）２５１およびネットワーキング層（すなわちＩＰ）を通って送られる。サテライト・ゲートウェイ２０５からの情報は、ドライバ２５５を介して物理層２５７に入る。ドライバは、電気通信リンク２５９を介して情報をサーバ２０７に送信する。ドライバ２５５は、逆方向パスでサーバ２０７から情報を受信することもできる。
【００７４】
電気通信リンク２５９から、情報は、物理層２６１を介してサーバ２０７中のドライバ２６３に送られる。情報は、ドライバからネットワーキング層に移る。ネットワーキング層はＩＰ ２６５を含む。情報は、ネットワーキングからトランスポート層にも送られる。トランスポート層は、ＴＣＰ ２６７を含む。情報は、例えばウェブ・サーバ・アプリケーション２６９に送られる。サーバ２０７およびサテライト・ゲートウェイ２０５の間は、アプリケーションに応じて、インターネットまたは別のＩＰネットワークとなる。
【００７５】
特定の実施形態では、情報は、トランスポートおよびアプリケーション層を完全に迂回して、ネットワーク層ゲートウェイ２０３、２０５などのゲートウェイを介して流れることができる。例えば、ゲートウェイ２０３では、情報は、電気通信リンク２２１を介してクライアント２０１から入ることができる。物理層２２３は、情報をドライバ２２５に渡す。その結果、ドライバ２２５は、ネットワーク層２２７に情報を渡す。ネットワーク層２２７は、ＩＰを使用して情報をその宛先に発送することができる。次いで情報は、ネットワーク層２２７からドライバ２３５に流れる。ドライバ２３５は、物理層２３７と対話し、電気通信リンク２３９を介して、サテライト２０９に沿って情報を渡す。
【００７６】
特定の実施形態では、変換モジュールは、ＴＣＰ接続を使用してサテライト・システムを介する伝送に適した接続に情報を変換する。サテライトに適した接続は、一般にＯｒｉｏｎ Ｗｏｒｏｌｄｃａｓｔ（商標）またはＰａｎＡｍＳａｔ（商標） ＳｐｏｔＢｙｔｅ（商標）サービスなどの無線ネットワークを介した伝送に対して回復力がある。この接続は、長い待ち時間および非対称帯域幅条件にも適しているべきである。この接続はクライアントまたはサーバ位置のエンド・ユーザにトランスペアレントでもあるべきである。長い待ち時間は、一般にサテライト・ホップあたり約２００ミリ秒〜約７００ミリ秒であるが、その値に限定されない。
【００７７】
特定の実施形態では、例えば図２Ａに示すように、この変換モジュールは、サテライト・リンクを介して伝送するためにＴＣＰ接続を使用して情報をＸＴＰ、修正ＴＣＰまたはＸＴＰライク・プロトコルに変換する。ここで、ＴＣＰモジュールは、ＴＣＰ接続を含む情報３５０を受信する。この情報は、データ３３３、ＴＣＰヘッダ３３５、およびＩＰヘッダ３３７を含む。ＴＣＰモジュールは、情報３５１が実質上全てのデータ３３３を含み、あるＴＣＰヘッダ情報と共に変換モジュールにデータを渡すように、この情報からＴＣＰヘッダを削除する。変換モジュールは、サテライト・プロトコル・ヘッダ３３９がデータ上に付加されるサテライト・プロトコル・モジュールに、データまたはデータの部分を渡す。ヘッダは、ＸＴＰヘッダなどである。次いで情報３５２は、サテライト・リンクを介した伝送に適したＸＴＰヘッダを含む。特定の実装に応じて、ＸＴＰヘッダおよびデータにサテライト・リンクを介して伝送するためにＩＰヘッダを付加することもできる。具体的には、この情報は、物理層およびドライバに転送される。ドライバおよび物理層は、追加のヘッダを付加することができる受信側サテライト・ゲートウェイに情報を送信する。
【００７８】
サテライト・リンクからは、ＸＴＰヘッダを含む情報が受信側ＸＴＰモジュールに入る。受信側ＸＴＰまたはサテライト・プロトコル・モジュールは、データ３５３を残し、ＸＴＰヘッダを情報から削除する。受信側サテライト・プロトコル・モジュールは変換モジュールにデータを渡す。変換モジュールはデータを適切なプロトコルに経路指定するために使用される経路指定モジュールで良い。次いで変換モジュールは、ＴＣＰモジュールにデータを渡す。受信側ＴＣＰモジュールは、データ上にＴＣＰヘッダ３４３およびＩＰヘッダ３４１を付加し、次いでネットワークを介して受信側サーバ宛先に伝送する準備ができた情報を形成する。ＴＣＰ接続を使用する情報は、ネットワークを介して宛先サーバに横切る。
【００７９】
他の実施形態では、変換モジュールは、データおよびＴＣＰ／ＩＰヘッダを含む情報の部分をＸＴＰプロトコルを使用する情報に変換することもできる。あるいは、変換モジュールは、多数のＴＣＰ／ＩＰヘッダを含む情報の複数のセグメントを、サテライト・リンクを介して伝送するＸＴＰヘッダを含む情報の単一の部分に変換することもできる。アプリケーションに応じて、変換モジュールは、ＴＣＰ接続を含む情報を上記のいずれか１つまたはいずれかの組み合わせに変換することができる。これらの技術や他のより一層の詳細を以下でより詳細に説明する。
【００８０】
図３Ａおよび３Ｂは、本発明の実施形態によるプロセス・ダイアグラムの単純化したダイアグラムである。これらのダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。特定の実施形態では、本発明は、図３Ａに図示する接続プロセス３００を使用する。この接続プロセスは、エンド・ユーザにトランスペアレントなＴＣＰ接続を行うサテライト・システム中で「ハンドシェーキング・ルーチン」を使用する、複数の別々の接続を使用する。サテライト・システムは、本明細書で説明するシステムに類似するようにできるが、それに限定されない。このプロセスは、ステップ３０１のスタートで始まる。特定の実施形態では、複数の接続が提供される。具体的には、このプロセスは、ステップ３０３の第１接続を行う。第１接続は、クライアントと、サテライト・リンクへのインターフェースをとるクライアント側ゲートウェイとの間のＴＣＰ接続である。このプロセスは、ステップ３０５の第２接続を行う。第２接続は、無線（例えばサテライト）リンクを介するクライアント側ゲートウェイと宛先ゲートウェイとの間の接続を行う。無線リンクは、ＸＴＰまたはＸＴＰライク接続などのどんな適切な接続でも良い。このプロセスは、ステップ３０７の第３接続を行う。第３接続は、宛先ゲートウェイと宛先サーバとの間のＴＣＰ接続を形成し、インターネットまたはインターネットを介して横切ることができる。これらの接続が行われた後は、これらの接続は、維持される（ステップ３０９）。このプロセスは、ストップ３１１で終了し、そこで全ての３つの接続が終了する。
【００８１】
特定の実施形態では、このプロセスは、ステップの選択したシーケンスによって行われる。ここで、ＴＣＰ ＳＹＮパケットは、サテライト・ゲートウェイによってトランスペアレントにインターセプトされる。サテライト・ゲートウェイは、サテライト・リンクを横切って他のサテライト・ゲートウェイへの新しいＸＴＰ接続を確立する。ＩＤアドレスおよびポート番号を含む、要求側クライアントおよび宛先サーバについての情報は、サテライト・リンクを介して他のサテライト・ゲートウェイに転送される。次いで宛先ゲートウェイは、クライアントのアドレス指定情報を使用して宛先サーバとのＴＣＰ接続をセットアップし、その結果、サーバは、クライアント自体が接続を確立した場合と同様にＴＣＰ接続を認識する。サテライト・ゲートウェイは、パケットをサテライト電気通信リンクを介して送付すべきかどうかを決定するために、ゲートウェイに入るパケットのＩＰヘッダ中の送信元および宛先アドレスに基づいて経路指定の決定を行う。サーバへのＴＣＰ接続が確立された後は、宛先ゲートウェイは、送信側ゲートウェイに通信し戻し、次いで送信側ゲートウェイは、クライアントとの接続を確認する。
【００８２】
１つまたは複数の実施形態では、ステップのこのシーケンスは利点を有する。具体的には、クライアントは、サーバがこの接続を受諾するまでは、接続が確立されているとはみなさず、これにより正常接続確立の偽の指示を減らし、さらにはなくす傾向がある。加えて、クライアントおよびサーバのどちらも、サテライト接続がクライアントとサーバとの間に生じていることを検出せずに、そのうちの２つの間で即座に生じているものとして接続を認識する。すなわち、本発明は、実質上接続の「エンドツーエンド・セマンティクス」を保持する。他の実施形態では、接続性は対称である。ここで、「クライアント」は、サテライト・リンクのどちらの側にも存在することができ、かつ「サーバ」はどちらの側にも存在することができる。一方の側のシステムは、他方の側のシステムに接続を要求することができ、サテライト・ゲートウェイは接続をインターセプトすることになる。
【００８３】
図３Ｂは、本発明による特定の実施形態での、開始ステップ３２１で始まる新規経路指定プロセス３２０の単純化した流れ図である。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。ステップ３２３では、クライアント・ホストは、特定のＩＰアドレス宛てのＴＣＰパケットをサテライト・ゲートウェイに送信する。ある例では、サテライト・ゲートウェイは、前述の１１１Ａと同様にすることができるが、他のものにすることもできる。決定ステップ３２５では、サテライト・ゲートウェイは、パケットを受信し、送信する前に、ＸＴＰ接続を介してパケットを搬送すべきかどうかを判定する。ＸＴＰプロトコルの例を本明細書で説明したが、請求の範囲を制限するものではない。本発明のある実施形態に従って、どんな適切なサテライト・プロトコルも使用することができる。ＴＣＰパケットの宛先アドレスが、ＸＴＰプロトコル・フォーマットに変換されるように構成される場合、パケットは、ステップ３３１でＸＴＰプロトコルに変換される。そうでない場合、パケットは、そのＴＣＰフォーマットで、ステップ３２７への代替分岐を介して送信される。この決定プロセスによって、単一サテライト・ゲートウェイが、一部がＸＴＰプロトコルと互換のゲートウェイを有し、他のサイトが対応するゲートウェイを含まない多数のリモート・サイトと通信するサイトに対して、本発明は有用である。加えて、本発明により、ネットワーク管理者の方針決定に基づいて、特定のアドレスをプロトコル変換用に構成し、他のアドレスを非変換用に構成することが可能となる。
【００８４】
特定の実施形態では、本発明は、転送速度制御ステップ（ステップ３２７）も備えている。ステップ３２７では、サテライト装置を介する適切な、または所定のデータ通信速度を維持するために処理が実行される。ステップ３２７の処理は、サテライト・リンクに過負荷をかけることを回避するために、図１の１０５および１０３などのパケットのバッファリングを必要とする可能性がある。これは、図３Ｃ〜３Ｄに示すプロセスを使用して実施することができるが、このプロセスに限定されない。次いで、ステップ３２９では、送信側サテライト・ゲートウェイからサテライト・リンクをたどって送信されたパケットが接続に沿って送信される。次いで、ステップ３３３では、パケットがステップ３３１で変換された場合に、パケットがＴＣＰに変換し戻される。次いで、ステップ３３５では、パケットがそのリモート宛先に送付される。単一サテライト・ゲートウェイが、一部がＸＴＰプロトコルと互換であり、他のサイトが互換ではない多数のリモート・ゲートウェイと通信するサイトに対して本発明は特に有用である。ある構成ではサテライト・ゲートウェイごとに多数のリモート・サイトを有することができる。これらのサイトの一部は、インストールされたサテライト・ゲートウェイを有し、他のサイトはインストールされたサテライト・ゲートウェイを有さないようにすることができる。したがってリモート側では、サテライト・ゲートウェイが存在することができず、ＩＰ経路指定構成だけが存在する。このプロセスは、情報が宛先サーバ１３１に入ったときに経路指定を完了し（ステップ３３５）、宛先サーバ１３１は、宛先クライアントに情報を転送する。このプロセスは、接続が終了したときに停止する（ステップ３３７）。
【００８５】
本発明による特定の実施形態では、ＴＣＰ接続は、接続の宛先側可能な限り早く送らなければならないプロトコル・ヘッダ中の１つの情報を時々渡す。この１つの情報は、「緊急ポインタ」として知られる。実施形態の選択において、例えば図２のサテライト・ゲートウェイ２０３などの、クライアント側サテライト・ゲートウェイの部分であるＴＣＰ実装は、ＴＣＰヘッダからこの緊急ポインタを抽出することができる。しかし、このオぺレーションは、図２のシステムでは必要ではなく、請求の範囲を制限するものではない。例えば図２のＴＣＰモジュール２２９などのＴＣＰモジュールは、緊急ポインタを抽出することができ、サテライト・ゲートウェイ変換モジュールにそれを渡すことができる。サテライト・ゲートウェイ変換モジュールは、図２のサテライト・ゲートウェイ変換モジュール２３１またはその均等物でよい。緊急ポインタは、図２のサテライト・プロトコル・モジュール２３３またはその均等物などのサテライト・プロトコル・モジュールに渡される。次いで緊急ポインタは、サテライト・プロトコル・ヘッダ中で図２のサテライト・ゲートウェイ２０５または他の受信側サテライト・ゲートウェイなどのサテライト・ゲートウェイに搬送することができる。受信側サテライト・ゲートウェイでは、緊急ポインタは、図２のサテライト・プロトコル・モジュール２４７などのサテライト・プロトコル・モジュールによって抽出し、変換モジュール２４９または別のサテライト変換モジュールなどの変換モジュールに渡すことができる。変換モジュールは、ＴＣＰモジュール２５１などのＴＣＰモジュールに緊急ポインタを送ることができる。次いでＴＣＰモジュールは、サーバ２０７などの末端サーバに即時に送るために、ＴＣＰヘッダ中のそのターゲット・フィールドに緊急ポインタを取り込む。サーバに送るこのヘッダは、第２サテライト・ゲートウェイ・マシンにまだ到着していないデータ・ストリーム中の点を参照する。いくつかの実施形態では、適切な緊急ポインタ処理が誤動作を緩和する。
【００８６】
図３Ｃは、本発明による特定の実施形態での図３Ｂのデータ通信速度制御ステップ３２７などのデータ通信速度制御プロセスの単純化した流れ図を示す。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図３Ｃは、着信パケットが到着する時にキューが空であるかどうかを判定する第１決定ステップ３４１を示す。現在好ましい実施形態では、高優先度（ＨＩＰＲＩ）トラフィックを待ち行列化するキューと、「通常の」トラフィックを待ち行列化するキューの２つのキューがある。キューの数は、本発明による実施形態を直接的に拡張することによって、拡張または減少させることができることを当業者は理解されよう。キューが空である場合、処理は決定ステップ３４３に進む。そうでない場合、処理は、決定ステップ３４５に進む。
【００８７】
決定ステップ３４３は、現システム・クロック・チック・カウントが格納されたクロック・チック・カウントと同じであるかどうかを判定する。システム・クロック・チックおよび格納されたクロック・チックが同じである場合、処理は決定ステップ３９４に進む。決定ステップ３９４は、ここでは「ＭＡＸ」として示す所望の送信速度に基づいて、バイト・カウンタおよび着信パケットの長さが所定の最大値よりも大きいかどうかを判定する。最大値を超過しない場合、処理はステップ３５５に進む。ステップ３５５では、パケットが送信され、バイト・カウンタがパケット長だけ増分される。そうではなく、ステップ３４９で最大値を超過する場合は、処理は、ステップ３５７に進む。ステップ３５７では、ＭＡＸと、バイト・カウンタの現在の値との間の差が「ＥＸＴＲＡ」として格納され、タイマをスタートさせることができる。次いで処理は、ステップ３４５に進む。そうではなく、ステップ３４３でクロック・チックと格納されたクロック・チックが異なる場合、処理はステップ３４７に進む。ステップ３４７では、バイト・カウンタがクリアされ、格納されたクロック・チックが更新される。次いで処理は、前述と同様にステップ３５５に進む。
【００８８】
決定ステップ３４１がキューのうちの少なくとも１つが空でないと判定した場合、またはパケット長がステップ３４９でＭＡＸを超えてバイト・カウンタを増加させた場合、決定ステップ３４５では、着信パケットが再送信であるかどうかの判定が行われる。パケットが再送信である場合、ステップ３５１では、パケットが高優先度（ＨＩＰＲＩ）キューに加えられる。そうでない場合、ステップ３５３では、パケットが通常キューに加えられる。
【００８９】
図３Ｄは、本発明による特定の実施形態での、図３Ｃで示したデータ通信速度制御プロセスと共に有用なタイマ・サービス・プロセスの単純化した流れ図を示す。このダイアグラムは、単に図示したに過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図３Ｄは、ステップ３５７でのタイマ・セットが満了するときにはいつでも起動されるステップ３６１を示す。ステップ３４１では、バイト・カウンタがクリアされ、ローカルの最大が、ＥＸＴＲＡに加えられる最大ＭＡＸに設定される。次いで、ステップ３６３では、高優先度（ＨＩＰＲＩ）キューがチェックされ、パケットがキュー上にあるかどうかが判定される。パケットがＨＩＰＲＩキュー上にある場合、処理は決定ステップ３６５に進む。そうでない場合、処理は、決定ステップ３６７に進む。
【００９０】
ＨＩＰＲＩキュー上にパケットがある場合、決定ステップステップ３６５では、バイト・カウンタおよびパケット長がローカルの最大よりも小さいかどうかの判定が行われる。実際にこれが当てはまる場合、処理はステップ３６９に進む。ステップ３６９では、パケットがＨＩＰＲＩキューから待機解除され、送信される。さらに、パケット中のデータの長さを反映するようにバイト・カウンタが増分される。そうでない場合、決定ステップ３６５は、バイト・カウンタおよびパケット長がローカルの最大を超過するかどうかが判定され、次いでステップ３７１ではタイマが再スタートし、処理は起動プロセスに戻る。処理は、タイマが満了するときに続行することができる。
【００９１】
決定ステップ３６３がＨＩＰＲＩキュー上にパケットが無いと判定した場合、処理は決定ステップ３６７に進む。決定ステップ３６７は、通常キュー上にパケットがあるかどうかを判定する。決定ステップ３６７が通常キュー上にパケットがないと判定した場合、処理はステップ３７５に進み、ステップ３７５では現クロック・チックがグローバル・セル中に格納される。そうでない場合、決定ステップ３６７が、パケットが通常キューであると判定した場合、処理は決定ステップ３７３に進む。決定ステップ３７３では、バイト・カウンタおよびパケット長がローカルの最大よりも小さいかどうかが判定される。実際にそうである場合、処理はステップ３７７に進む。ステップ３７７では、パケットが通常キューから待機解除され、送信される。さらに、バイト・カウンタがパケット中のデータの長さを反映するように増分される。そうでない場合、決定ステップ３７３がバイト・カウンタおよびパケット長がローカルの最大を超過するかどうかを判定し、ステップ３７９ではタイマが再スタートし、処理は起動プロセスに戻る。処理は、タイマが満了するときに続行することができる。
【００９２】
図３Ｅは、本発明による特定の実施形態での代表的システムの概観を示す。このダイアグラムは、単に例示に過ぎず、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。クライアント３８０は、ＴＣＰサーバ３８８への接続要求を開始する。サテライト・ゲートウェイ３８４は、接続要求をインターセプトし、第２サテライト・ゲートウェイ３８６との第２接続３８５を確立する。次いで第２サテライト・ゲートウェイ３８６は、サーバ３８８との第３接続３８７を開始する。接続３８７が確立され、情報がサテライト・ゲートウェイ３８４に戻されると、クライアント３８０とサテライト・ゲートウェイ３８４との間の第１ＴＣＰ接続３８３を確認することができる。
【００９３】
ある実施形態では、ＴＣＰ接続がデータをクライアント３８０に送信するサテライト・ゲートウェイ３８４および／またはサテライト・ゲートウェイ３８６によってバッファに入れられるデータの集合量を制限するのに有用なデータ・フロー制御プロセス３８２が提供される。選択実施形態は、例えばデータがその接続上のクライアントに対してバッファに入れられたとき、ＴＣＰ上のデータ・フローを制御することができる。図３Ｆからわかるように、データ・フロー制御プロセス３８２を介してクライアント３８０とサテライト・ゲートウェイ３８４との間で第１ＴＣＰ接続３８３を確認することができる。選択実施形態では、データ・フロー制御プロセス３８２は、接続３８５の両側のサテライト・ゲートウェイ３８４およびサテライト・ゲートウェイ３８６に格納されるデータ量を制御する目的で、クライアントＴＣＰ接続３８３などのクライアントＴＣＰ接続がサテライト・ゲートウェイ３８４などのサテライト・ゲートウェイに送ることができるメモリ量を制限することができる。接続３８３内のクライアント３８０とサテライト・ゲートウェイ３８４との間に挿入された別々の制御プロセス３８２によって示したが、本発明は、他の形態でも実施することができる。例えば、制御プロセス３８２は、クライアント３８０のマシン内の第１サテライト・ゲートウェイ内に共通に位置するか、または別々のマシン内の第１サテライト・ゲートウェイ３８４などと共に配置することができる。
【００９４】
サテライトおよびサテライト・ゲートウェイによって示したが、本発明は、他の形態のネットワーク・ハードウェアでも実施することができる。例えば、第１ゲートウェイ３８４および第２ゲートウェイ３８６を無線ネットワークなどによって接続することができる。
【００９５】
図３Ｇは、本発明による特定の実施形態での接続フロー接続選択プロセスの単純化した流れ図を示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。当業者は、他の変形形態、修正形態、および代替形態を理解されよう。図３Ｇは、入力データ・フロー３９０を示す。決定ステップ３９１は、入力データ・フロー３９０が受信される接続が新しい接続かどうかを判定する。新しい接続である場合、この新しい接続は、フロー制御に対してマークされない。新しい接続でない場合、決定ステップ３９２では、接続に関連するバッファの内容のサイズがしきい値に対してチェックされる。バッファの内容がしきい値を超過する場合、ステップ３９３では、フロー制御制限計算に対して接続が選択される。そうでない場合、接続はフロー制御に対して選択されない。図３Ｇに示すステップは、初期化中またはデータを断続的に転送している接続を遮蔽する能力を有する実施形態を提供することができる。そのような接続は、フロー制御計算に対して選択される必要はない。そのような接続は、十分大きいシステム・リソースを消費しないからである。新しい接続は、データのしきい値量が新しい接続に対してバッファに入れられるまで、フロー制御計算に対して選択される必要はない。現在好ましい実施形態では、接続がメモリ中にデータのしきい値量をバッファに入れた場合に、しきい値に達する。この特定の実施形態では、しきい値量よりも小さいデータを送り、待機し、次いでより多くのデータを送信する接続は、フロー制御制限計算に対して選択する必要はない。データのしきい値量のうちのすべてが一度にメモリ中に常駐しないからである。しかし、別の実施形態では、バッファ中のデータの平均または特定の時間間隔にわたるデータのバッファ化した量は、本発明の範囲から逸脱することなく、接続上のフローを制御する基礎として使用することもできる。現在好ましい実施形態では、しきい値限界は、５０Ｋバイトにすることができる。しかし、当業者は、本発明の方法およびシステムを他のしきい値に容易に適用することができる。
【００９６】
図３Ｈは、本発明による特定の実施形態での、図３Ｆに示すサテライト・ゲートウェイ・システムに関して有用なデータ・フロー制御プロセスの単純化した流れ図を示す。このダイアグラムは、単なる例であって、本明細書の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図３Ｈは、特定の接続に対する入力データ・フロー３９４を示す。決定ステップ３９５は、入力データ３９４に対応する接続がフロー制御されているものかどうかを判定する。フロー制御されているものである場合、ステップ３９６ではリンクを渡ってデータのバイトを送信し、接続に対して送信し戻すための往復時間（ＲＴＴ）を判定することがきる。往復時間は、ユーザからの入力によって、またはデータのサンプルの１つがリンクを横切る時間などを自動的に判定することができる。次いでステップ３９７では、接続に対するデータ通信速度、または帯域幅が判定される。データ通信速度は、ユーザからの入力によって、またはデータのサンプルの１つなどによって自動的に判定することができる。この実施形態では、ユーザは、転送速度および往復時間を別々の入力として入力する。しかし、他の実施形態も、ユーザが事前計算した帯域幅遅延積を入力することを可能とし、またはリンクを検出することによって往復時間を判定することができる。次いでステップ３９８では、帯域幅遅延積は、バイト単位のリンクの帯域幅に、往復時間を乗じることによって決定することができる。
【００９７】
ステップ３９９では、接続に対するフロー制御制限を決定することができる。フロー制御制限は、接続に対するバッファへのデータ量などにすることができる。現在好ましい実施形態では、フロー制御制限は、図３Ｇで詳述した処理の間に選択される各アクティブ・データ接続に割り振られるメモリ量にすることができる。フロー制御制限は、帯域幅遅延積に倍数を乗じ、次いでその合計をアクティブデータ接続で除算することによって計算することができる。この倍数は、ネットワーク・リンクを完全に使用し続けるために、十分なデータをバッファに入れることが可能となるように選ばれる。現在好ましい実施形態では、倍数８が選ばれる。しかし、実施形態は、本発明の範囲から逸脱することなく、他の倍数またはスケーリング関数、あるいは複数の規格化因子の組み合わせを使用することができる。次いで、ステップ４０１では、接続上のデータを着信データを最大ステップ３９９によって決定される制限まで接続上のバッファに入れることによって、制限することができる。システムは、物理システム・メモリで利用可能な割り振られた空間よりも多くバッファリングすることを抑制することができる。
【００９８】
本発明による多くの実施形態が、アクティブ接続の変更に適合することができることは注目に値する。１つの接続がアクティブである場合、その接続は、帯域幅全体の使用を許可されることになる。第２接続アクティブであるとき、フロー制御制限は、新しいデータが到着したときはいつでも、フロー制御制限を計算することによって、第１および第２接続のどちらに対しても調整することができる。この方式では、接続が確立された順番には関わりなく接続の間で帯域幅を割り振ることができる。加えて、本発明による実施形態により、１つの特定の接続からのデータのバーストが、他の接続についてのデータの前に、リンクを介する送信のために待ち行列化される可能性を低減させることによって接続間でサテライト・リンクを共用することが可能となる。これにより、ネットワーク・スループットが多数の接続にわたってより一貫したものとなる。
【００９９】
図３Ｉは、本発明による特定の実施形態の代表的バッファ・アーキテクチャの単純化した構造構成要素ダイアグラムを示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図３Ｉは、サテライト・ゲートウェイ３８４を示す。サテライト・ゲートウェイ３８４は、接続３８３を介して図３Ｅのクライアント３８０などのクライアントとインターフェースをとるＴＣＰバッファ４０５を備える。さらに、サテライト・ゲートウェイ３８４は、接続３８５を介して図３Ｅのサテライト１０１などのサテライトとインターフェースをとるサテライト・プロトコル・バッファ４０６を備える。サテライト・システム３８４を介するＴＣＰは、サテライト・ゲートウェイ３８４中のＴＣＰプロトコル層およびサテライト・プロトコル層によって制御される１つまたは複数のバッファ中に、データを一時的に格納することができる。例えば図３Ｅのクライアント３８０などの端点へのデータは、ＴＣＰバッファ４０５などの、１つまたは複数のＴＣＰバッファから導出することができる。空間がＴＣＰバッファ４０５中で利用可能となったとき、データは、サテライト・プロトコル・バッファ４０６からＴＣＰバッファ４０５に転送することができる。空間がサテライト・プロトコル・バッファ４０６中で利用可能になったとき、サテライト・プロトコルにより、より多くのデータを例えば図３Ｅのサテライト・リンク３８５などのサテライト・リンクを介して送信することが可能となる。本発明による実施形態の適用の代表例では、サテライト・ゲートウェイ３８４などのサテライト・ゲートウェイは、複数のモデムにデータを供給することができる。モデム・リンクは、サテライト・リンクと同じ転送速度でデータを受諾することができない。そのような状況では、本発明による技術は、モデムについてのデータを保持する比較的大きな量のバッファ空間を消費することを回避することができる。
【０１００】
図３Ｊは、本発明による特定の実施形態の代表的バッファ・アーキテクチャの単純化した構造構成要素ダイアグラムを示す。このダイアグラムは、単なる例示であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図３Ｊは、例えば図３Ｉのサテライト・プロトコル・バッファ４０６中に常駐することができる出力データ４０２を示す。受諾可能な転送速度でデータがＴＣＰ層からエンド・クライアントに送達されていないとき、サテライト・リンク中の輻輳が生じる可能性がある。この輻輳は、サテライト・プロトコルによって決定ステップ４０３で検出することができる。決定ステップ４０３では、サテライト・プロトコルがサテライト・プロトコル・バッファ４０６の状態が飽和に達したかどうかを判定する。ある実施形態では、バッファに対してしきい値を確立することができる。このしきい値を超過することにより、飽和条件があることを示すことができる。プロトコル・バッファが飽和した場合、ステップ４０４では、サテライト・プロトコルは、サテライト・リンク３８５にわたって受け入れられることになるデータに対する最大受信ウィンドウを減少因子だけ減少させる。現在好ましい実施形態では、減少因子５０％を使用することができる。特定の実施形態では、ウィンドウがゼロにまで減少しないことを保証するように、受信ウィンドウに対する最小値を構成することができる。そうでない場合、クライアントがシステムのデータ通信速度と互換のデータ通信速度で受信している場合、飽和条件には到達しないことになる。
【０１０１】
本発明による実施形態では、比較的遅いデータ通信速度を有する、例えばクライアント３８４などの受信側への接続は、フルサイズの受信ウィンドウで開始することができる。本発明による技術を用いて、受信ウィンドウは送信側のデータ通信速度と受信側のデータ通信速度との間の一致を達成するようにサイズ変更することができる。したがって、ある実施形態では、新しい接続は、システムがより低いデータ通信速度受験を検出し、追加の新しいデータが接続のためにバッファに入れられる量を制限する前に、メモリのフル・ウィンドウを消費する能力を有する。現在好ましい実施形態では、本発明の技術は、各サテライト接続に別々に適用することができ、その結果ある低速な受信側が同じリンクを介する他の接続の性能を低下させることがないことになる。
【０１０２】
図７は、本発明による特定の実施形態での代表的装置を示す。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。図７は、プロトコル・ゲートウェイ１１１Ａなどの、本発明による特定の実施形態でのプロトコル・ゲートウェイのブロック・ダイアグラムを示す。プロトコル・ゲートウェイ１１１Ａは、中央処理装置１１４などの主要なサブシステムと相互接続するバス１１２と、システム・メモリ１１６（一般にはＲＡＭ）と、表示アダプタ１２６を介する表示画面１２４、キーボード１３２、および入出力コントローラ１１８を介するマウス１４６、フロッピィ・ディスク１３８を受けるように動作するフロッピィ・ディスク・ドライブ１３６などのいくつかの追加の外部装置を含む。記憶インターフェース１３４は、固定ディスク・ドライブ１４４への記憶インターフェースとして動作することができる。ＣＤ−ＲＯＭ１４２を受け入れるように動作する任意選択のＣＤ−ＲＯＭプレーヤ１４０も含むことができる。フラッシュ・メモリ１４７などの他の形態の記憶装置も含むことができる。ネットワーク・インターフェース１４８Ａは、電話線を介するリモート・サーバへの直接接続、またはＴＣＰ／ＩＰなどの共通プロトコルを使用するインターネットへの直接接続を実現することができる。ネットワーク・インターフェース１４８Ａは、１つまたは複数の外部ネットワークとインターフェースをとることができる。その外部ネットワークは、イーサネット、トークン・リング、ＡＴＭ、ＩＥＥＥ ８０２．３、Ｘ．２５、シリアル・リンク・インターネット・プロトコル（ＳＬＩＰ）、ＦＤＤＩなどの、当技術分野で周知の何らかのネットワーク・フォーマットを利用することができる。ネットワーク・インターフェース１４８Ｂは、サテライト・ゲートウェイ１０９Ａ、あるいは他のネットワーク相互接続装置またはコンピュータ・システムなどのサテライト・ゲートウェイに接続することもできる。ネットワーク・インターフェース１４８Ａは、１つまたは複数の外部ネットワークとインターフェースをとることができる。その外部ネットワークは、イーサネット、トークン・リング、ＡＴＭ、ＩＥＥＥ ８０２．３、Ｘ．２５、シリアル・リンク・インターネット・プロトコル（ＳＬＩＰ）、ＦＤＤＩなどの、当技術分野で周知の何らかのネットワーク・フォーマットを利用することができる。多くの他の装置またはサブシステム（図示せず）も、同様に接続することができる。さらに、以下で論ずるように、本発明を実施するためには、図７に示す装置のすべてが存在する必要はない。この装置およびサブシステムは、様々な実施形態において、図７に示すのとは異なる方式で相互接続することができる。本発明を実装するコードは、システム・メモリ１１６、固定ディスク１４４、ＣＤ−ＲＯＭ１４０、またはフロッピィ・ディスク１３８などのコンピュータ可読格納媒体中に操作可能に配置または格納することができる。
【０１０３】
システム１１１Ａは、本発明を実施する構成の単なる１つの例である。多くのシステム・タイプ、構成、および上記装置の組み合わせが、本開示に照らした使用に適していることは当業者には明らかであろう。
【０１０４】
上記は、特定のシステム、方法、および実施形態により本発明を一般的に説明したが、本発明は、より広い範囲の適用可能性を有する。具体的には、本発明はサテライト通信に限定されず、改良および最適化プロトコルをネットワークの特定の部分を介して使用することが望ましく、エンド・システムが改良プロトコルを使用するために更新することができないどんなネットワーキング状態にも適用することができる。したがって、ある実施形態では、サテライト・ゲートウェイは、すべての種類の無線または有線ネットワークおよびインターネットワークへのアクセスを提供することができる。もちろん、当業者は他の変形形態、修正形態、および代替形態を理解されよう。
【０１０５】
実験：
このシステムの原理およびオペレーションを検証するために、実験を実行した。この実験では、従来のＴＣＰと本発明とを多様な異なるＴＣＰウィンドウ・サイズ、リンク帯域幅、往復遅延時間、およびビット・エラー率にわたって比較する一連の単一クライアントＦＴＰファイル転送スループット・テストを実行した。１つの実験では、例えば図４のダイアグラム４００で示すように、「ウィンドウ・サイズ」を「スループット」に対して比較した。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。性能向上またはＴＣＰウィンドウ・サイズ・チューニングを行わない場合、大部分のクライアントは、往復時間が５４０ｍｓのときにスループット速度が１００Ｋｂｐｓに制限された。図４のデータが示すように、３２ＫＢウィンドウを有するクライアントでも、単にスループット４００Ｋｂｐｓにしか到達することができなかった。このシステムにより、クライアントまたはサーバのウィンドウ・サイズに関わらず、クライアントが利用可能帯域幅を利用することが可能となった。
【０１０６】
代替実験では、例えば図５の単純化したダイアグラム５００に示すように、「往復遅延」が「スループット」に対して解析された。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。ここで、本発明は、ネットワークの往復時間へのＴＣＰの依存を除いた。性能は、エラーのない対称２Ｍｂｐｓおよび１０Ｍｂｐｓリンクを介して測定された。ＴＣＰは、地上低遅延ネットワークを完全に飽和することができるが、遅延が増加するにつれてＴＣＰ性能は急速に降下することをこれらの結果は示した。それとは対称的に、このシステムを使用したネットワークは、ネットワークの往復時間に関わらず、リンクのほぼ完全な使用を維持することができた。
【０１０７】
代替実験では、「ビット・エラー率」が、例えば図６の単純化したダイアグラム６００によって示される「スループット」に対してモニタされた。このダイアグラムは、単なる例であって、本明細書の請求の範囲を制限するものではない。他の変形形態、修正形態、および代替形態を当業者は理解されよう。本発明を取り込んだネットワークは、リンクのビット・エラー率にも敏感である。このダイアグラムは、スループットを、往復時間５４０ｍｓおよびＴＣＰウィンドウ・サイズ１ＭＢの対称１０Ｍｂｐｓサテライト・ネットワークに対するビット・エラー率の関数として示す。低エラー率であっても、ＴＣＰは、１．２Ｍｂｐｓしか送ることができなかった。エラー率１．０×１０-5では、ＴＣＰのスループットは、０．０５Ｍｂｐｓに落ち込んだ。本発明を使用したネットワークは、低エラー率でリンクを完全に飽和し、エラー率１．０×１０-5でも２．７Ｍｂｐｓを送ることができた。
【０１０８】
上記は、特定の実施形態の完全な説明であるが、様々な修正形態、代替構造、および均等物を使用することができる。例えば、上記は、ＸＴＰをサテライト・プロトコルとして使用することによって一般に説明した。他のタイプのプロトコルも利用可能である。例えば、プロトコルは、修正したＴＣＰなどを含むことができる。したがって、前述の説明および図示は、添付の請求の範囲によって定義される本発明の範囲を限定するものとして用いたのではない。
【図面の簡単な説明】
【図１】 本発明の一実施形態によるサテライト・システムの単純化した図である。
【図２】 本発明の一実施形態によるシステム・アーキテクチャの単純化した図である。
【図２Ａ】 本発明の一実施形態によるシステム・アーキテクチャの単純化した図である。
【図３Ａ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｂ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｃ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｄ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｅ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｆ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｇ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｈ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｉ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図３Ｊ】 本発明の一実施形態によるプロセス図の単純化した図である。
【図４】 本発明の一実施形態による実験データの単純化した図である。
【図５】 本発明の一実施形態による実験データの単純化した図である。
【図６】 本発明の一実施形態による実験データの単純化した図である。
【図７】 本発明の一実施形態によるゲートウェイ・インターフェースの単純化した図である。[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 satellite system 100 according to an embodiment of 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. In particular, the system 100 includes a satellite network system having a satellite 101. The satellite 101 receives and transmits information between a plurality of ground stations 107 and 108 or satellite dishes. Each satellite ground station includes a satellite dish and other forms of receivers such as satellite modems 109A, 109B, or VSAT indoor units. The VSAT indoor unit couples directly or indirectly to the satellite gateways 111A, 111B.
[0039]
The satellite antenna 108 receives and transmits the signal 103 via the satellite 101. The satellite antenna 108 connects to the Internet 129 or a satellite gateway 111B that couples to a wide area network such as the Internet. The wide area network is coupled to the server 131. The gateway 111B is also coupled via the satellite modem 109B. Server and Internet communications are performed using common protocols such as TCP / IP and UDP / IP. The satellite gateway is described in more detail below.
[0040]
The satellite antenna 107 receives and transmits the signal 105 via the satellite 101. The satellite antenna 107 is connected to a satellite gateway 111A coupled to a local area network 121 such as Ethernet, token ring, or FDDI. The local area network 121 is coupled to a terminal 123 or a client. Here, the satellite gateway is coupled to the laptop 117 via the modem 119. Clients, laptops, and local area networks use common connection formats such as TCP / IP, IPX / SPX. The satellite gateway is described in more detail below.
[0041]
In certain embodiments, the satellite gateway 111A intercepts the TCP connection from the client and converts the data 105 to a satellite protocol for transmission via the satellite 101. The gateway 111A also couples via a satellite modem 109A that transmits data to the satellite 101. The satellite gateway 111B on the other side of the satellite link converts the data in the satellite protocol back to TCP in order to communicate with the server 131. In certain embodiments, the present invention improves performance over the prior art. In addition, the technology of the present invention remains substantially transparent to the end user and is completely compatible with the Internet or Internet infrastructure. In many, if not all, cases, no substantial changes are required on the client or server. In the preferred embodiment, the application continues to function without substantial hardware and / or software modifications.
[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 system architecture 200 according to an embodiment of 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 system architecture 200 includes at least a client 201 that is coupled to a satellite gateway 203 that transmits and receives information from the satellite gateway 205 via a satellite link 209. Satellite gateway 205 is coupled to server 207. The satellite gateway and server are coupled to each other via the Internet or a network of Internet-like computers.
[0070]
Client 201 can be represented in multiple layers including application and physical layers. This layer can include a browser 211. The browser 211 allows the user to communicate information from the application layer to the physical layer for transmission to the gateway. The browser 211 is generally in an application layer that provides information. For example, the browser can be one of the appropriate designs made by a company called Netscape Communications Corporation of Mountain View, California, or Microsoft Corporation of Redmond, Washington, or other companies. In addition to the browser, other TCP applications including FTP file transfer can also be used to communicate between the client and server.
[0071]
Information travels through the transport layer (eg, TCP) and then through the IP layer 215. The IP layer 215 is a networking layer. The transport layer provides a flow of data between the client and the gateway. The IP layer handles the movement of data including packets between clients and gateways or other networks. Information is transmitted through the physical layer, which includes a driver 217. Driver 217 transmits information to gateway 203 via hardware 219 connected to gateway 203 via telecommunications link 221. The telecommunications link 221 may be a wire, cable, optical fiber, or other physical communication medium. Alternatively, the driver 217 receives information from the gateway 203 via the link 221 and the hardware 219. For example, the driver may be a network operating system having a network interface card in a client computer.
[0072]
Information passes from the physical connection 221 to the gateway 203. The gateway has a physical layer 223 that interacts with the driver 225. The gateway also includes a networking layer 227 and a transport layer 229. The transport layer 229 is coupled to the conversion module 231. The networking layer 227 determines whether the information can be routed via the satellite protocol. If so, the data is passed to the upper transport layer 229. If it cannot be shipped, the data is immediately transferred to the transfer rate control module 234 for transmission to the satellite link 239 in an unconverted form. The conversion module 231 converts the information into a satellite protocol 233 suitable for use via a satellite link. The transfer rate control module 234 determines whether information can be immediately passed to the satellite connection or queued for later transmission. The satellite connection is coupled to the physical layer 237 by driver 235, which transmits information to and from satellite 209. Information is sent in and out of the wireless media 239, 241 to the satellite.
[0073]
Information is received by the satellite gateway 205. The satellite gateway 205 includes multiple layers of physical layers and other layers. The physical layer 243 is coupled to the driver 245. The networking and transport layers include satellite protocol 247 and transfer rate control 244. The network and transport layer connects to a session layer that includes a conversion module 249. The conversion module converts the information back to TCP / IP using a satellite protocol. Information is sent through the transport layer (ie TCP) 251 and the networking layer (ie IP). Information from the satellite gateway 205 enters the physical layer 257 via the driver 255. The driver sends information to server 207 via telecommunication link 259. The driver 255 can also receive information from the server 207 in the reverse path.
[0074]
Information is sent from the telecommunications link 259 to the driver 263 in the server 207 via the physical layer 261. Information moves from the driver to the networking layer. The networking layer includes IP 265. Information is also sent from the networking to the transport layer. The transport layer includes TCP 267. The information is sent to the web server application 269, for example. Between the server 207 and the satellite gateway 205 is the Internet or another IP network depending on the application.
[0075]
In certain embodiments, information can flow through gateways such as network layer gateways 203, 205, bypassing the transport and application layers completely. For example, at the gateway 203, information can enter from the client 201 via the telecommunications link 221. The physical layer 223 passes information to the driver 225. As a result, the driver 225 passes information to the network layer 227. The network layer 227 can route information to its destination using IP. Information then flows from the network layer 227 to the driver 235. The driver 235 interacts with the physical layer 237 and passes information along the satellite 209 via the telecommunication link 239.
[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 information 350 including the TCP connection. This information includes data 333, TCP header 335, and IP header 337. The TCP module removes the TCP header from this information so that the information 351 includes substantially all the data 333 and passes the data to the conversion module along with some TCP header information. The conversion module passes the data or portion of data to the satellite protocol module where a satellite protocol header 339 is added onto the data. The header is an XTP header or the like. Information 352 then includes an XTP header suitable for transmission over the satellite link. Depending on the particular implementation, an IP header can also be added to the XTP header and data for transmission over the satellite link. Specifically, this information is transferred to the physical layer and the driver. The driver and physical layer send information to the receiving satellite gateway where additional headers can be added.
[0078]
From the satellite link, information including the XTP header enters the receiving side XTP module. The receiving XTP or satellite protocol module leaves data 353 and deletes the XTP header from the information. The receiving satellite protocol module passes the data to the conversion module. The conversion module may be a routing module that is used to route data to an appropriate protocol. The conversion module then passes the data to the TCP module. The receiving TCP module adds a TCP header 343 and an IP header 341 on the data, and then forms information ready to be transmitted over the network to the receiving server destination. Information using the TCP connection crosses the destination server via the network.
[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 connection process 300 illustrated in FIG. 3A. This connection process uses multiple separate connections that use a “handshaking routine” in a satellite system that makes a TCP connection transparent to the end user. The satellite system can be similar to the system described herein, but is not limited thereto. This process begins at the start of step 301. In certain embodiments, multiple connections are provided. Specifically, this process makes the first connection at step 303. The first connection is a TCP connection between the client and the client-side gateway that interfaces to the satellite link. This process makes the second connection in step 305. The second connection is a connection between the client-side gateway and the destination gateway via a wireless (for example, satellite) link. The wireless link may be any suitable connection such as an XTP or XTP-like connection. This process makes the third connection in step 307. The third connection forms a TCP connection between the destination gateway and the destination server and can be traversed over the Internet or the Internet. After these connections are made, these connections are maintained (step 309). The process ends at stop 311 where all three connections are terminated.
[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 new routing process 320 that begins at start step 321 in certain embodiments 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. In step 323, the client host sends a TCP packet addressed to a specific IP address to the satellite gateway. In one example, the satellite gateway can be similar to 111A described above, but can be other. In decision step 325, the satellite gateway determines whether it should carry the packet over the XTP connection before receiving and transmitting the packet. While examples of the XTP protocol have been described herein, they do not limit the scope of the claims. Any suitable satellite protocol can be used in accordance with an embodiment of the present invention. If the destination address of the TCP packet is configured to be converted to the XTP protocol format, the packet is converted to the XTP protocol at step 331. Otherwise, the packet is sent in its TCP format via an alternative branch to step 327. This decision process allows the present invention for a site where a single satellite gateway communicates with a number of remote sites, some of which have gateways compatible with the XTP protocol and other sites do not include a corresponding gateway. Is useful. In addition, according to the present invention, it is possible to configure specific addresses for protocol conversion and other addresses for non-conversion based on the policy decision of the network administrator.
[0084]
In certain embodiments, the present invention also includes a transfer rate control step (step 327). In step 327, processing is performed to maintain an appropriate or predetermined data communication rate via the satellite device. The process of step 327 may require buffering of packets such as 105 and 103 in FIG. 1 to avoid overloading the satellite link. This can be done using the process shown in FIGS. 3C-3D, but is not limited to this process. Next, in step 329, the packet transmitted from the transmitting satellite gateway along the satellite link is transmitted along the connection. Next, in step 333, if the packet is converted in step 331, the packet is converted back to TCP. Step 335 then sends the packet to its remote destination. The invention is particularly useful for sites where a single satellite gateway communicates with a number of remote gateways, some of which are compatible with the XTP protocol and other sites are not compatible. Some configurations can have multiple remote sites per satellite gateway. Some of these sites may have installed satellite gateways, while other sites may not have installed satellite gateways. Thus, on the remote side, no satellite gateway can exist and only an IP routing configuration exists. This process completes routing when information enters the destination server 131 (step 335), and the destination server 131 forwards the information to the destination client. This process stops when the connection is terminated (step 337).
[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, satellite gateway 203 in FIG. 2, can extract this urgent pointer from the TCP header. However, this operation is not necessary in the system of FIG. 2 and does not limit the scope of the claims. For example, a TCP module such as TCP module 229 of FIG. 2 can extract the emergency pointer and pass it to the satellite gateway conversion module. The satellite gateway conversion module may be the satellite gateway conversion module 231 of FIG. 2 or an equivalent thereof. The urgent pointer is passed to a satellite protocol module such as the satellite protocol module 233 of FIG. 2 or its equivalent. The urgent pointer can then be carried in a satellite protocol header to a satellite gateway such as satellite gateway 205 of FIG. 2 or other receiving satellite gateway. At the receiving satellite gateway, the urgent pointer can be extracted by a satellite protocol module, such as satellite protocol module 247 of FIG. 2, and passed to a conversion module, such as conversion module 249 or another satellite conversion module. The conversion module can send an urgent pointer to a TCP module such as TCP module 251. The TCP module then captures an urgent pointer in its target field in the TCP header for immediate delivery to an end server such as server 207. This header sent to the server refers to a point in the data stream that has not yet arrived at the second satellite gateway machine. In some embodiments, proper urgent pointer processing mitigates malfunctions.
[0086]
FIG. 3C shows a simplified flow diagram of a data rate control process such as the data rate control step 327 of FIG. 3B 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. 3C shows a first decision step 341 that determines whether the queue is empty when an incoming packet arrives. In the presently preferred embodiment, there are two queues: a queue that queues high priority (HIPRI) traffic and a queue that queues “normal” traffic. Those skilled in the art will appreciate that the number of queues can be expanded or decreased by directly expanding embodiments according to the present invention. If the queue is empty, processing proceeds to decision step 343. Otherwise, the process proceeds to decision step 345.
[0087]
Decision step 343 determines whether the current system clock tick count is the same as the stored clock tick count. If the system clock tick and the stored clock tick are the same, processing proceeds to decision step 394. Decision step 394 determines whether the byte counter and the length of the incoming packet are greater than a predetermined maximum value based on the desired transmission rate, here denoted as “MAX”. If the maximum value is not exceeded, processing proceeds to step 355. In step 355, the packet is transmitted and the byte counter is incremented by the packet length. Otherwise, if the maximum value is exceeded at step 349, processing proceeds to step 357. In step 357, the difference between MAX and the current value of the byte counter is stored as “EXTRA” and the timer can be started. Processing then proceeds to step 345. Otherwise, if the clock tick stored at step 343 is different from the stored clock tick, processing proceeds to step 347. In step 347, the byte counter is cleared and the stored clock tick is updated. Next, the processing proceeds to step 355 as described above.
[0088]
If decision step 341 determines that at least one of the queues is not empty, or if the packet length exceeds MAX in step 349 and increments the byte counter, decision step 345 indicates that the incoming packet is a retransmission. A determination is made whether or not. If the packet is a retransmission, at step 351, the packet is added to a high priority (HIPRI) queue. Otherwise, in step 353, the packet is added to the normal queue.
[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 step 361 being activated whenever the timer set in step 357 expires. In step 341, the byte counter is cleared and the local maximum is set to the maximum MAX added to EXTRA. Next, in step 363, the high priority (HIPRI) queue is checked to determine if the packet is on the queue. If the packet is on the HIPRI queue, processing proceeds to decision step 365. Otherwise, processing proceeds to decision step 367.
[0090]
If there are packets on the HIPRI queue, decision step 365 determines whether the byte counter and packet length are less than the local maximum. If this is the case, processing proceeds to step 369. In step 369, the packet is dequeued from the HIPRI queue and transmitted. In addition, a byte counter is incremented to reflect the length of the data in the packet. Otherwise, decision step 365 determines if the byte counter and packet length exceed the local maximum, then in step 371 the timer is restarted and processing returns to the startup process. Processing can continue when the timer expires.
[0091]
If decision step 363 determines that there are no packets on the HIPRI queue, processing proceeds to decision step 367. Decision step 367 determines whether there are any packets on the normal queue. If decision step 367 determines that there are no packets on the normal queue, processing proceeds to step 375 where the current clock tick is stored in the global cell. Otherwise, if decision step 367 determines that the packet is a normal queue, processing proceeds to decision step 373. In decision step 373, it is determined whether the byte counter and packet length are less than the local maximum. If so, processing proceeds to step 377. In step 377, the packet is released from the normal queue and transmitted. In addition, the byte counter is incremented to reflect the length of the data in the packet. Otherwise, decision step 373 determines whether the byte counter and packet length exceed the local maximum, step 379 restarts the timer, and processing returns to the startup process. Processing can continue when the timer expires.
[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 client 380 starts a connection request to the TCP server 388. The satellite gateway 384 intercepts the connection request and establishes a second connection 385 with the second satellite gateway 386. Second satellite gateway 386 then initiates a third connection 387 with server 388. Once connection 387 is established and information is returned to satellite gateway 384, the first TCP connection 383 between client 380 and satellite gateway 384 can be verified.
[0093]
In one embodiment, a data flow control process 382 is provided that is useful for limiting the amount of data buffered by satellite gateway 384 and / or satellite gateway 386 over which a TCP connection sends data to client 380. Is done. Alternative embodiments can control the data flow over TCP, for example when data is buffered for clients on that connection. As can be seen from FIG. 3F, the first TCP connection 383 can be verified between the client 380 and the satellite gateway 384 via the data flow control process 382. In selected embodiments, the data flow control process 382 is configured so that the client TCP connection, such as the client TCP connection 383, is a satellite for the purpose of controlling the amount of data stored in the satellite gateway 384 and satellite gateway 386 on both sides of the connection 385. Limit the amount of memory that can be sent to a satellite gateway such as gateway 384. Although illustrated by a separate control process 382 inserted between client 380 and satellite gateway 384 in connection 383, the present invention may be implemented in other forms. For example, the control process 382 may be commonly located within a first satellite gateway within the client 380 machine, or may be co-located with a first satellite gateway 384 within a separate machine, or the like.
[0094]
Although illustrated by satellites and satellite gateways, the present invention may be implemented with other forms of network hardware. For example, the first gateway 384 and the second gateway 386 can be connected by a wireless network or the like.
[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 input data flow 390. Decision step 391 determines whether the connection from which input data flow 390 is received is a new connection. If it is a new connection, this new connection is not marked for flow control. If not a new connection, decision step 392 checks the size of the buffer contents associated with the connection against a threshold. If the buffer content exceeds the threshold, then in step 393 a connection is selected for the flow control limit calculation. Otherwise, no connection is selected for flow control. The steps shown in FIG. 3G can provide an embodiment that has the ability to shield connections that are initializing or transferring data intermittently. Such a connection need not be selected for flow control calculations. Such a connection does not consume sufficiently large system resources. A new connection need not be selected for flow control calculations until a threshold amount of data is buffered for the new connection. In the presently preferred embodiment, the threshold is reached when the connection buffers a threshold amount of data in memory. In this particular embodiment, a connection that sends and waits for data less than a threshold amount and then sends more data need not be selected for the flow control limit calculation. This is because not all of the threshold amount of data is resident in memory at once. However, in another embodiment, the average of the data in the buffer or the buffered amount of data over a specific time interval can be used as a basis for controlling the flow over the connection without departing from the scope of the invention. You can also. In the presently preferred embodiment, the threshold limit can be 50 Kbytes. However, one of ordinary skill in the art can readily apply the method and system of the present invention to other thresholds.
[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 input data flow 394 for a particular connection. A decision step 395 determines whether the connection corresponding to the input data 394 is flow controlled. If so, step 396 can determine the round trip time (RTT) to send a byte of data across the link and send it back to the connection. The round trip time can be automatically determined, such as by input from a user or when one of the samples of data crosses the link. Next, in step 397, the data communication speed or bandwidth for the connection is determined. The data communication speed can be determined automatically, such as by input from a user or by one of a sample of data. In this embodiment, the user enters the transfer rate and round trip time as separate inputs. However, other embodiments also allow the user to enter a pre-computed bandwidth delay product or can determine the round trip time by detecting the link. Then, in step 398, the bandwidth delay product can be determined by multiplying the bandwidth of the link in bytes by the round trip time.
[0097]
In step 399, flow control limits for the connection can be determined. The flow control limit can be, for example, the amount of data to the buffer for the connection. In the presently preferred embodiment, the flow control limit can be the amount of memory allocated to each active data connection selected during the process detailed in FIG. 3G. The flow control limit can be calculated by multiplying the bandwidth delay product by a multiple and then dividing the sum by the active data connection. This multiple is chosen so that enough data can be buffered to keep the network link fully used. In the presently preferred embodiment, a multiple of 8 is chosen. However, embodiments may use other multiples or scaling functions or combinations of multiple normalization factors without departing from the scope of the present invention. Then, in step 401, the data on the connection can be limited by buffering incoming data up to the limit determined by step 399. The system can suppress buffering more than the allocated space available in physical system memory.
[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 satellite gateway 384. The satellite gateway 384 includes a TCP buffer 405 that interfaces with a client, such as the client 380 of FIG. In addition, the satellite gateway 384 includes a satellite protocol buffer 406 that interfaces with a satellite, such as the satellite 101 of FIG. TCP over satellite system 384 may temporarily store data in one or more buffers controlled by the TCP protocol layer and satellite protocol layer in satellite gateway 384. For example, data to an endpoint such as client 380 in FIG. 3E can be derived from one or more TCP buffers, such as TCP buffer 405. Data can be transferred from satellite protocol buffer 406 to TCP buffer 405 when space becomes available in TCP buffer 405. When space becomes available in the satellite protocol buffer 406, the satellite protocol allows more data to be transmitted over the satellite link, such as the satellite link 385 of FIG. 3E. . In a representative example of application of an embodiment according to the present invention, a satellite gateway, such as satellite gateway 384, can supply data to multiple modems. The modem link cannot accept data at the same transfer rate as the satellite link. In such a situation, the technique according to the invention can avoid consuming a relatively large amount of buffer space holding data about the modem.
[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 satellite protocol buffer 406 of FIG. 3I. When data is not being delivered from the TCP layer to the end client at an acceptable transfer rate, congestion in the satellite link can occur. This congestion can be detected at decision step 403 by the satellite protocol. In decision step 403, the satellite protocol determines whether the state of the satellite protocol buffer 406 has reached saturation. In some embodiments, a threshold can be established for the buffer. Exceeding this threshold can indicate that there is a saturation condition. If the protocol buffer is saturated, at step 404, the satellite protocol reduces the maximum receive window for data that will be accepted over satellite link 385 by a decrement factor. In the presently preferred embodiment, a reduction factor of 50% can be used. In certain embodiments, a minimum value for the receive window can be configured to ensure that the window does not decrease to zero. Otherwise, the saturation condition will not be reached if the client is receiving at a data rate compatible with the system's data rate.
[0101]
In an embodiment according to the present invention, a connection to a receiver, such as a client 384, having a relatively slow data transmission rate can be initiated with a full-size reception window. Using the technique according to the present invention, the receive window can be resized to achieve a match between the data communication rate on the sending side and the data communication rate on the receiving side. Thus, in one embodiment, a new connection consumes a full window of memory before the system detects a lower data rate test and limits the amount of additional new data buffered for the connection. Have the ability to In the presently preferred embodiment, the technique of the present invention can be applied separately to each satellite connection, so that some slow receivers do not degrade the performance of other connections over the same link.
[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 protocol gateway 111A. Protocol gateway 111A includes a bus 112 that interconnects with major subsystems such as central processing unit 114, system memory 116 (typically RAM), display screen 124 via display adapter 126, keyboard 132, and input / output. It includes a number of additional external devices such as mouse 146 via controller 118 and floppy disk drive 136 that operates to receive floppy disk 138. Storage interface 134 can operate as a storage interface to fixed disk drive 144. An optional CD-ROM player 140 that operates to accept a CD-ROM 142 may also be included. Other forms of storage devices such as flash memory 147 may also be included. The network interface 148A can implement a direct connection to a remote server via a telephone line or a direct connection to the Internet using a common protocol such as TCP / IP. Network interface 148A may interface with one or more external networks. The external network includes Ethernet, Token Ring, ATM, IEEE 802.3, X. 25, any network format known in the art can be utilized, such as Serial Link Internet Protocol (SLIP), FDDI. Network interface 148B may also connect to satellite gateway 109A, or to a satellite gateway such as another network interconnect device or computer system. Network interface 148A may interface with one or more external networks. The external network includes Ethernet, Token Ring, ATM, IEEE 802.3, X. 25, any network format known in the art can be utilized, such as Serial Link Internet Protocol (SLIP), FDDI. Many other devices or subsystems (not shown) can be connected as well. Further, as discussed below, not all of the apparatus shown in FIG. 7 need be present to implement the present invention. The devices and subsystems can be interconnected in different ways than shown in FIG. 7 in various embodiments. Code that implements the present invention may be operatively located or stored in a computer readable storage medium such as system memory 116, fixed disk 144, CD-ROM 140, or floppy disk 138.
[0103]
System 111A is just one example of a configuration that implements the present invention. It will be apparent to those skilled in the art that many system types, configurations, and combinations of the above devices are suitable for use in light of the present disclosure.
[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)

遠隔通信システム内のサテライト・リンクを介してパケット化した情報を伝送する通信装置であって、前記情報がデータとヘッダをそれぞれが含む複数のパケットを含み、前記システムが、複数の潜在的クライアントのうちから選択されたクライアントと、複数の潜在的サーバのうちから選択されたサーバと、第１遠隔通信リンクによって前記クライアントに接続された第１ゲートウェイと、第２遠隔通信リンクによって前記サーバに接続された第２ゲートウェイと、前記第１ゲートウェイを前記第２ゲートウェイに接続する第３遠隔通信リンクとを含み、
前記第１ゲートウェイを前記クライアントとリンクするためのネットワーク・インターフェースと、
サテライト・ゲートウェイ・インターフェースと、
システム・メモリと、
前記ネットワーク・インターフェース、前記サテライト・ゲートウェイ・インターフェース、前記システム・メモリをプロセッサと相互接続するバスであって、そのプロセッサは、
前記通信が前記クライアントによって開始され、前記サーバとの接続をインターセプトし、
前記第１ゲートウェイと前記第２ゲートウェイの間の接続を、前記遠隔通信リンクを介して確立し、
前記第１ゲートウェイと前記第２ゲートウェイの間の前記接続を使用して、前記クライアントから前記サーバに対する、また前記サーバから前記クライアントに対する情報の双方向フローを提供し、前記クライアントとサーバにトランスペアレントに行われることとを実行するように動作可能に構成されているバスとを含む装置。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. 請求項１に記載の装置において、
前記プロセッサが、前記第１ゲートウェイで、前記情報を第１プロトコルから第２プロトコルに前記遠隔通信リンクを介する伝送のために変換し、かつ前記第２ゲートウェイで、前記第２プロトコルを前記第１プロトコルに変換するようにさらに、動作可能に構成された装置。 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. 請求項２に記載の装置において、
前記第１プロトコルがＴＣＰを含み、かつ前記第２プロトコルがＸＴＰを含む装置。 The apparatus of claim 2.
Wherein the first protocol comprises TCP, and the second protocol apparatus including XTP. クライアントとサーバの間で、ＴＣＰプロトコルでのパケット化された情報をトランスポートするための通信システム内で、サテライト・プロトコルでのパケット化された情報をトランスポートするシステムに前記通信システムを変換する方法であって、
第１ゲートウェイを設置するステップであって、前記第１ゲートウェイが、前記クライアントから前記サーバに対する接続をインターセプトするように動作可能に構成され、前記第１ゲートウェイが、さらに、前記パケット化された情報をＴＣＰプロトコルからサテライト・プロトコルに変換するように動作可能に構成されているステップと、
第２ゲートウェイを設置するステップであって、前記第２ゲートウェイが、前記サーバとの接続を確立するように構成され、前記第２ゲートウェイが、さらに、前記パケット化された情報をサテライト・プロトコルからＴＣＰプロトコルに変換するように動作可能に構成され、前記第１ゲートウェイおよび前記第２ゲートウェイが、共通遠隔通信リンクを介して接続を確立するように動作可能に構成されているステップとを含む方法。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. システム内で情報を伝送するための通信方法であって、前記情報がデータおよびヘッダをそれぞれが含む複数のパケットを含み、前記システム内に
複数の潜在的クライアントのうちから選択されたクライアントと、
複数の潜在的サーバのうちから選択されたサーバと、
第１遠隔通信リンクによって前記クライアントに接続された第１ゲートウェイと、
第２遠隔通信リンクによって前記サーバに接続された第２ゲートウェイと、
前記第１ゲートウェイを前記第２ゲートウェイに接続する第３遠隔通信リンクとを含み、前記通信方法は、
前記クライアントによって開始された、前記サーバとの接続の試行をインターセプトするステップと、
前記第１ゲートウェイと前記第２ゲートウェイの間の接続を、前記第３遠隔通信リンクを介して確立するステップと、
前記第１ゲートウェイと前記第２ゲートウェイの間の前記接続を使用して、前記クライアントから前記サーバに対する、または前記サーバから前記クライアントに対する情報の双方向フローを提供するステップであって、前記双方向フローの提供が、前記クライアントとサーバにトランスペアレントに行われるステップとを含む方法。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. 請求項５に記載の方法において、
前記情報を前記第１ゲートウェイで、第１プロトコルから第２プロトコルに、前記第３遠隔通信リンクを介する伝送のために変換するステップと、
前記第２プロトコルを前記第１プロトコルに前記第２ゲートウェイで変換するステップとをさらに含む方法。 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. 請求項６に記載の方法において、
第１プロトコルが、ＴＣＰを含み、かつ第２プロトコルが、ＸＴＰを含む方法。 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. 請求項５に記載の方法において、
前記第１ゲートウェイは、前記第３遠隔通信リンクを介して前記サーバから送信された情報を記憶する第１バッファと、前記クライアントが受信できるよう前記第１遠隔通信リンクに送り出される情報を記憶する第２バッファとを有しており、さらに、前記第２遠隔通信リンク及び前記第３遠隔通信リンクを介して送られる前記サーバから前記クライアントへの情報を前記第１ゲートウェイが受信する際に、
前記第１バッファの状態が飽和状態に達したか否かを判定するステップと、
前記第１バッファが飽和状態に達した場合、前記クライアントの前記第３遠隔通信リンクを介して受信されるデータの量を抑えるように、前記第１ゲートウェイで前記クライアントの受信ウィンドウ・サイズを減少設定するステップとを含む方法。 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: 請求項１０記載の方法において、
前記飽和状態は、前記第１バッファに所定のしきい値を越えて情報が蓄積された状態である方法。 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. 請求項５記載の方法において、さらに、
データが、前記第１ゲートウェイから前記第２ゲートウェイまで前記第３遠隔通信リンクを介して伝わるのにかかる往復時間を判定するステップと、
前記第３遠隔通信リンクに関するデータ通信速度を判定するステップと、
前記往復時間および前記データ通信速度から帯域幅遅延積を判定するステップと、
前記帯域幅遅延積から前記第３遠隔通信リンクに対するフロー制御制限量を判定するステップと、
前記フロー制御制限量に基づいて前記第３遠隔通信リンクを介するデータ転送量を制限するステップとを含む方法。 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. 請求項１２記載の方法において、
前記第３遠隔通信リンクが、サテライト・プロトコルを使用する方法。 The method of claim 12, wherein
The method wherein the third telecommunications link uses a satellite protocol . 請求項１２記載の方法において、
前記第３遠隔通信リンクに関する往復時間を判定する前記ステップが、ユーザから前記往復時間を得るステップをさらに含む方法。 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. 請求項１２記載の方法において、
前記第３遠隔通信リンクに関するデータ通信速度を判定する前記ステップが、ユーザから前記往復時間を得るステップをさらに含む方法。 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. 請求項１２記載の方法において、
前記第３遠隔通信リンクに関する帯域幅遅延積を判定する前記ステップが、前記往復時間と前記データ通信速度を掛けるステップをさらに含む方法。 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. 請求項１２記載の方法において、
前記第３遠隔通信リンクに対するフロー制御制限量を判定する前記ステップが、前記帯域幅遅延積に倍率を掛けて、それを前記リンクに関する接続の数で割るステップをさらに含む方法。 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. 請求項１７記載の方法において、
前記倍率が８である方法。 The method of claim 17, wherein
The method wherein the magnification is 8.
JP2000597684A 1999-02-02 2000-02-02 Internet via satellite Expired - Lifetime JP3814678B2 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US11822799P 1999-02-02 1999-02-02
US09/243,185 US6529477B1 (en) 1999-02-02 1999-02-02 Internet over satellite system
US09/243,554 US6584083B1 (en) 1999-02-02 1999-02-02 Internet over satellite method
US09/306,678 US6460085B1 (en) 1999-02-02 1999-05-06 Method and system for managing memory in an internet over satellite connection
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/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)

* Cited by examiner, † Cited by third party
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
US7463582B2 (en) 2000-04-14 2008-12-09 Hughes Network Systems, Llc System and method for scaling 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
US6987741B2 (en) 2000-04-14 2006-01-17 Hughes Electronics Corporation System and method for managing bandwidth in a two-way satellite system
US6965581B2 (en) 2000-04-14 2005-11-15 Hughes Electronics Corp. Transceiver in 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
US20010048669A1 (en) * 2000-04-14 2001-12-06 Frank Kelly System interfaces in a two-way satellite system
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
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
EP1671453A4 (en) * 2003-09-10 2010-01-20 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)

* Cited by examiner, † Cited by third party
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
JPH09510596A (en) * 1994-06-08 1997-10-21 エイチイー・ホールディングス・インコーポレーテッド・ディー ビーエー・ヒューズ・エレクトロニクス 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
EP0988642A4 (en) * 1996-11-12 2001-08-01 Starguide Digital Networks 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
EP0890907B1 (en) * 1997-07-11 2000-06-14 ICO Services Ltd. Providing web access to users in a vehicle

Also Published As

Publication number Publication date
CA2361433A1 (en) 2000-08-10
EP1151375A4 (en) 2003-10-22
EP1151375A1 (en) 2001-11-07
WO2000046669A9 (en) 2001-09-07
WO2000046669A8 (en) 2001-03-22
JP2004520725A (en) 2004-07-08
WO2000046669A1 (en) 2000-08-10
IL144658A0 (en) 2002-05-23

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
JP5020076B2 (en) High performance TCP suitable for low frequency ACK system
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
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
WO2020154872A1 (en) Transmission control protocol acceleration method and apparatus
CN116131923B (en) Data transmission method, device and storage medium based on satellite communication
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