(57)【要約】モデムをゲートウェイに結合する無線リンク上でハイパーテキスト転送プロトコル（ＨＴＴＰ）ウェブ・ページをダウンロードするための方法および装置。伝送制御プロトコル（ＴＣＰ）リンクがゲートウェイとモデムとの間で開設される。ＨＴＴＰの一様なリソース識別子（ＵＲＩ）がモデムにおいてウェブ・ブラウザから受信され、そこでは、ＨＴＴＰ ＵＲＩは起点サーバのＨＴＴＰウェブ・ページに対応する。ウェブ・ブラウザがＵＲＩを提供する前に、ＴＣＰリンクはよく構成される。ＨＴＴＰ ＵＲＩはゲートウェイに送られる。インターネットプロトコル（ＩＰ）アドレスがゲートウェイによってＨＴＴＰ ＵＲＩの中で示されたドメイン名に対して決定される。ＨＴＴＰウェブ・ページは、モデムがそれを要求することなしに、インターネットを使用してゲートウェイによって検索される。ＨＴＴＰウェブ・ページは衛星モデムに送信される。ＨＴＴＰウェブ・ページ中で参照されたオブジェクトは、同様にＨＴＴＰウェブ・ページにアクセスされるが、しかし、オブジェクトはまた並列にアクセスされることができる。ある場合には、帯域幅がモデムのローディングに従ってＴＣＰリンクのために基準化される。【選択図】      図５Ａ
2007531405.tif 000002
【特許請求の範囲】
【請求項１】
衛星モデムを衛星ゲートウェイに結合する衛星リンク上でハイパーテキスト転送プロトコル（ＨＴＴＰ）ウェブ・ページをダウンロードする方法であって、
衛星ゲートウェイと衛星モデムの間の伝送制御プロトコル（ＴＣＰ）リンクを開設し、
衛星モデムにおいてウェブ・ブラウザからＨＴＴＰの一様なリソース識別子（ＵＲＩ）を受信し、
ここに、ＨＴＴＰ ＵＲＩは、起点サーバのＨＴＴＰウェブ・ページに対応し、また、開設ステップは受信ステップの前に行なわれ、
ＴＣＰリンク上で衛星ゲートウェイへＨＴＴＰ ＵＲＩを送付し、
衛星ゲートウェイによってＨＴＴＰ ＵＲＩで示されたドメイン名のためのインターネットプロトコル（ＩＰ）アドレスの決定し、
ＨＴＴＰウェブ・ページを検索し、
ここに、検索ステップは送付ステップによって引き起こされ、また、ＨＴＴＰウェブ・ページは複数の埋め込まれたＵＲＩを含み、
衛星モデムにＨＴＴＰウェブ・ページを送信し、
ＴＣＰリンク上で衛星ゲートウェイへ埋め込まれたＵＲＩの複数の少なくとも５つを送り、ここに少なくとも５つは５つのオブジェクトに対応し、
５つのオブジェクトを衛星モデムへ送信し、ここに、衛星ゲートウェイは少なくとも５つを持っているが、５つのオブジェクトのどれも完全に送信されていないステップを含む方法。
【請求項２】
送付ステップの前にＨＴＴＰ ＵＲＩを圧縮するステップをさらに含む、請求項１で記述されたような衛星モデムを衛星ゲートウェイに結合する衛星リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項３】
衛星モデムから別な場所へＩＰアドレスを送るステップをさらに含む、請求項１で記述されたような衛星モデムを衛星ゲートウェイに結合する衛星リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項４】
衛星モデムはウェブ・ブラウザの観点から明示的なプロキシを含むように見える、請求項１で記述されたような衛星モデムを衛星ゲートウェイに結合する衛星リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項５】
ＨＴＴＰ ＵＲＩを他のインターネットリクエストから区別するステップをさらに含む、請求項１で記述されたような衛星モデムを衛星ゲートウェイに結合する衛星リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項６】
衛星モデムから別な場所へウェブ・ページを送るステップをさらに含む、請求項１で記述されたような衛星モデムを衛星ゲートウェイに結合する衛星リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項７】
請求項１の衛星リンク上でＨＴＴＰウェブ・ページをダウンロードするコンピュータ実行可能な方法を行なうためのコンピュータ実行可能な命令を有するコンピュータ可読媒体。
【請求項８】
無線リンク上でＨＴＴＰウェブ・ページを送る無線ダウンロードシステムであって、
ウェブ・ブラウザからＨＴＴＰ ＵＲＩを受信する無線モデムと、
無線モデムから遠隔に位置されている無線ゲートウェイとを含み、
ＨＴＴＰ ＵＲＩが起点サーバのＨＴＴＰウェブ・ページに対応し、
プロトコル・リンクが無線モデムおよび無線ゲートウェイを連結し、かつ
プロトコル・リンクは無線モデムがＨＴＴＰ ＵＲＩを受信する前に開設され、
ＨＴＴＰ ＵＲＩは無線ゲートウェイへ送られ、
インターネットプロトコル（ＩＰ）アドレスがＨＴＴＰ ＵＲＩの中で示されたドメイン名のために無線ゲートウェイによって決定され、
ＨＴＴＰウェブ・ページがインターネットを使用して無線ゲートウェイによって検索され、
無線モデムが無線ゲートウェイへＨＴＴＰ ＵＲＩを送るどんな行動もとること無しに、ＨＴＴＰウェブ・ページが無線モデムに送信される無線ダウンロードシステム。
【請求項９】
無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法であって、
無線モデムとポイントとの間のＴＣＰリンクを開設し、
ウェブ・ブラウザから無線モデムでＨＴＴＰ ＵＲＩを受信し、ここに
ＨＴＴＰ ＵＲＩが起点サーバのＨＴＴＰウェブ・ページに対応し、かつ
受信ステップの前に開設ステップが行なわれ、
ポイントにＨＴＴＰ ＵＲＩを送り、
無線モデムでＩＰアドレスを決定することなく、ポイントからウェブ・ページを受け取り、ここにＩＰアドレスはＨＴＴＰ ＵＲＩの中で示されたドメインに対応し、
ＨＴＴＰウェブ・ページをウェブ・ブラウザに送信するステップを含む方法。
【請求項１０】
ポイントでＨＴＴＰ ＵＲＩの中で示されたドメイン名のためのＩＰアドレスを決定するステップをさらに含む、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１１】
ポイントでウェブ・ページを検索するステップをさらに含む、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１２】
ポイントが無線ゲートウェイに対応する、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１３】
衛星リンクがポイントに無線モデムを結合する、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１４】
セルラー基地局が無線モデムをポイントに結合する、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１５】
ＨＴＴＰ ＵＲＩを圧縮するステップをさらに含む、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１６】
ドメインのためのＩＰアドレスが無線モデム内のキャッシュに入れられるかどうか判断するステップをさらに含む、請求項９で記述されたような無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードする方法。
【請求項１７】
請求項９の無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードするコンピュータ実行可能な方法を行なうためのコンピュータ実行可能な命令を有するコンピュータ可読媒体。
【請求項１８】
請求項９の無線モデムと無線モデムから離れた場所のポイントとの間の無線リンク上でＨＴＴＰウェブ・ページをダウンロードするコンピュータ実行可能な方法を行なうように適応された電子システム。
【請求項１９】
無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法であって、
無線ゲートウェイとパケット交換を使用するポイントとの間のプロトコル・リンクを開設し、
無線ゲートウェイでポイントからのＨＴＴＰ ＵＲＩを受信し、ここに
ＨＴＴＰ ＵＲＩは起点サーバのＨＴＴＰウェブ・ページに対応し、かつ
プロトコル・リンクはＨＴＴＰ ＵＲＩがポイントで公式化される前に開設され、
ＨＴＴＰ ＵＲＩの中で示されたドメイン名のためのＩＰアドレスを決定し、
ＩＰアドレスからウェブ・ページを検索し、
ＨＴＴＰウェブ・ページをポイントに送信し、ここに、ＩＰアドレスはポイントに送信されないステップを含む方法。
【請求項２０】
ポイントが無線モデムに対応する、請求項１９で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法。
【請求項２１】
複数の埋め込まれたＵＲＩを受信し、ここに、埋め込まれたＵＲＩはＨＴＴＰウェブ・ページに関係しており、
複数の埋め込まれたＵＲＩに対応する複数のオブジェクトを検索し、
ポイントに複数のオブジェクトを送信し、ここに、複数のオブジェクトの少なくとも５つは直接先行する検索ステップでリクエストされたが、送信ステップにおいて完全には送られないステップをさらに含む、
請求項１９で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法。
【請求項２２】
衛星リンクが無線ゲートウェイをポイントに結合する、請求項１９で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法。
【請求項２３】
セルラー基地局が無線ゲートウェイをポイントに結合する、請求項１９で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法。
【請求項２４】
ＨＴＴＰ ＵＲＩを逆圧縮するステップをさらに含む、請求項１９で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する方法。
【請求項２５】
請求項１９の無線ゲートウェイと無線ゲートウェイから離れ場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索するためのコンピュータ実行可能な方法を行なうためのコンピュータ実行可能な命令を有するコンピュータ可読媒体。
【請求項２６】
請求項１９の無線ゲートウェイと無線ゲートウェイから離れ場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索するためのコンピュータ実行可能な方法を行なうように適応された電子システム。
【請求項２７】
無線ゲートウェイと無線ゲートウェイかた離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索するための無線ダウンロードシステムであって、
無線ゲートウェイとポイントとの間のＴＣＰリンクを開設する手段と、
無線ゲートウェイでポイントからＨＴＴＰ ＵＲＩを受信する手段と、ここに
ＨＴＴＰ ＵＲＩは起点サーバのＨＴＴＰウェブ・ページに対応し、また、
ＨＴＴＰ ＵＲＩがポイントで公式化される前に、ＴＣＰリンクが開設され、
ＨＴＴＰ ＵＲＩの中で示されたドメイン名のためのＩＰアドレスを決定する手段と、
ＩＰアドレスからウェブ・ページを検索する手段と、
ＨＴＴＰウェブ・ページをポイントに送信する手段と、ここに、ＩＰアドレスはポイントに送信されないことを含む無線ダウンロードシステム。
【請求項２８】
ＴＣＰリンクについて不活発な期間の後にＴＣＰリンクを閉じる手段をさらに含む、請求項２７で記述されたような無線ゲートウェイと無線ゲートウェイから離れた場所のポイントとの間の無線リンクからリクエストされたＨＴＴＰウェブ・ページを検索する無線ダウンロードシステム。
【請求項２９】
インターネット情報をダウンロードするための無線システムであって、
リターン・リンク・バッファがある無線モデムと、
無線ゲートウェイと、
無線モデムを無線ゲートウェイと結合する永続データリンクとを含み、ここに
永続データリンクは無線モデムのために専用される第1のリターン・リンク帯域幅を持ち、
無線ゲートウェイは、リターン・リンク・バッファのローディングに少なくとも一部分基づく第２のリターン・リンク帯域幅を持つように永続データリンクを変更することができ、
第1のリターン・リンク帯域幅は第２のリターン・リンク帯域幅より小さい無線システム。
【請求項３０】
永続データリンクは第1または第2のリターン・リンク帯域幅より大きな帯域幅を有する順方向リンクを持っている、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３１】
永続データリンクは複数の無線モデムによって共有される順方向リンクを有する、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３２】
永続データリンクは衛星を含んでいる、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３３】
永続データリンクはセルラー基地局を含んでいる、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３４】
永続データリンクは圧縮された本文の情報を運ぶリターン・リンクを持っている、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３５】
永続データリンクは圧縮されたＨＴＴＰ ＵＲＩを運ぶリターン・リンクを持っている、請求項２９で記述されたようなインターネット情報をダウンロードするための無線システム。
【請求項３６】
無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法であって、
無線モデムをリターン・リンクで無線ゲートウェイと結合し、ここに、リターン・リンクは無線モデムのために専用される第1の帯域幅を持っており、
無線モデムにおいてリターン・リンクのために予定された情報のバックログ・サイズを決定し、
リターン・リンクに追加帯域幅を割り当て、ここに、リターン・リンクは時間の期間について追加帯域幅を割り当てられるステップを含む方法。
【請求項３７】
決定するステップはバックログ・サイズが予め定められた閾値に達したことを判断するステップを含む、請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項３８】
バックログ・サイズの無線ゲートウェイに通知するステップをさらに含む、請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項３９】
バックログ・サイズが予め定められた閾値に達したことを無線ゲートウェイに通知するステップをさらに含む、請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項４０】
リターン・リンクのためのデータを圧縮するステップをさらに含む、請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項４１】
リターン・リンクのためのＨＴＴＰ情報を圧縮するステップをさらに含む、請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項４２】
本文であるデータを発見し、
発見するステップに基づいてデータを圧縮するステップをさらに含む、
請求項３６で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理する方法。
【請求項４３】
請求項３６の無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するコンピュータ実行可能な方法を行なうためのコンピュータ実行可能な命令を有するコンピュータ可読媒体。
【請求項４４】
無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システムであって、
無線モデムのために専用される第1の帯域幅を持っているリターン・リンクで、無線モデムを無線ゲートウェイと結合する手段と、
無線モデムにおいてリターン・リンクのために予定された情報のバックログ・サイズを決定する手段と、
リターン・リンクに追加帯域幅を割り当て、リターン・リンクは時間の期間について追加帯域幅を割り当てられる手段とを含む広帯域システム。
【請求項４５】
無線モデムがまた、複数の無線モデムによって共有された順方向リンクで無線ゲートウェイと結合される、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【請求項４６】
リターン・リンクは衛星を含んでいる、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【請求項４７】
リターン・リンクはセルラー基地局を含んでいる、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【請求項４８】
リターン・リンクは圧縮された本文の情報を運ぶ、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【請求項４９】
リターン・リンク伝導時間の待ち時間は１００ミリセカンドより少なくない、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【請求項５０】
リターン・リンク伝導時間の待ち時間は２００ミリセカンドより少なくない、請求項４４で記述されたような無線モデムと無線ゲートウェイとの間でインターネット情報を渡すために使用される無線データリンクを管理するための広帯域システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、２００４年３月２２日に申請された非仮出願である米国出願シリアルＮｏ．６０／５５５，６０５の利益を要求し、その出願はその全体を参照することにより組み込まれる。
【０００２】
この出願は、“ＳＡＴＥＬＬＩＴＥ  ＡＮＴＩＣＩＰＡＴＯＲＹ  ＢＡＮＤＷＩＤＴＨ  ＡＣＣＥＬＥＲＡＴＩＯＮ”（代理人事件Ｎ０．０４０３６６によって参照される）と題する本出願と同じ日付で申請された米国特許出願と関係があり、その出願はその全体を参照することにより組み込まれる。
【０００３】
この開示は一般に広帯域の最適化に関係し、より明確には、限定するものではないが、高い待ち時間のデータリンク上のＨＴＴＰ最適化に関する。
【背景技術】
【０００４】
広帯域の静止衛星は、任意の輸送に対しておよそ２５０ミリセカンドの伝播遅延を課する。これは受け手が与えられた通信に反応しかつ応答することができる前に、送り手側のどんな通信も４分の１秒遅らせられるという明白な意味合いを持つ。ＴＣＰ／ＩＰプロトコルは送り手と受け手間の双方向のインタラクションを必要とする。これは、受け手が送り手の通信を認めることができる（そして恐らく応答する）のにおよそ５００ミリセカンドのラウンド・トリップ時間（ＲＴＴ）を引き起こす。
【０００５】
広帯域の静止衛星の使用で経験された障害のすべては、その比較的大きな伝播遅延のこの根本的原因にさかのぼることができると主張することができる。遅れの影響は、リクエストをブラウズするｗｗｗのような、ユーザインタラクションのますます小さな要素の送り手と受け手間の同期を要求するプロトコルのやり方によって拡大される。
【０００６】
ユーザは、例としてのインターネット・エクスプローラ(Internet Explorer登録商標)またはネットスケープ・ナビゲータ（Netscape Navigator登録商標) のようなブラウザとして知られているソフトウエアコンポーネントのサービスによってＷＷＷトランザクションを呼び出す。ブラウザは、起点サーバ上で作動するウエブサーバ・アプリケーション（例えばアパッチ、Apache登録商標）として知られている他のソフトウエアコンポーネントとインタラクションするだろう。インタラクションは、全面的なトランザクションの様々な要素についてＵＤＰおよびＴＣＰプロトコルの両方を使用して、インターネット上に進む。そのトランザクションは５つの別個のクラスのサブトランザクションへ取り壊されてもよい。これらは、１つ以上のＤＮＳトランザクション、接続確立トランザクション（即ち、ＳＹＮ、ＳＹＮ−ＡＣＫ、ＡＣＫ）、ＨＴＴＰトランザクション、ＴＣＰ転送トランザクション、および接続取り壊しトランザクション（即ち、ＦＩＮ、ＦＩＮ−ＡＣＫ、ＡＣＫ）である。
【０００７】
ここの用語トランザクションは、トランザクションが閉じられ（即ち、始めと終わりの状態を持っている）、および一貫している（即ち、始めと終わりの状態が文脈に関して有効な状態である）の両方である独立したインタラクションである含意で使用されている。通信リンク上で閉じられるべきトランザクションは、少なくとも１つの送り手−受け手交換を要求する。広帯域の静止衛星については、これは最小およそ５００ミリセカンドトランザクション時間を意味し、それはトランザクションが開いたままである時間である。
【０００８】
ワールド・ワイド・ウェブ（ＷＷＷ）トランザクションの１つの重要な態様は、サブトランザクションを構成している幾つかを直列化する性質である。前のトランザクションが終了されるまで１つのトランザクションが開始できないことの意味は、固有の並列の全面的なトランザクションを拒む。これは、どんなサブトランザクションも他のすべてのサブトランザクションと直列化すると言うことではなく、実際にＨＴＴＰトランザクションのいくつかの場合とＴＣＰ転送トランザクションのほとんどの場合に並列の多くの機会がある。
【０００９】
ＷＷＷトランザクションは、ホスト名を含んでいるユニバーサル・リソース・ロケータ（ＵＲＬ）を検索するリクエストから始まる。ホスト名はＤＮＳルックアップサービスを使用してＩＰアドレスに回帰する。メインページ中の多くの埋め込まれたオブジェクトがそれら自身のＤＮＳルックアップを要求する別個のホスト名を有するＵＲＬへの言及を含むことを考慮するとき、ＷＷＷトランザクションのそれ以上の部分は負担にならない。さらに、単純な無国籍の質問／返答プロトコルとしてのＤＮＳは、オリジナルの質問の再送により後続される固定タイムアウトの使用によりアプリケーション層のパケット損失を扱う。しばしば１秒に設定されるタイムアウトは、オリジナルなＤＮＳ質問（あるいは返答）が失われる場合、遅れ負担を課することができる。
【００１０】
ＨＴＴＰプロトコルは根本的な輸送プロトコルとしてＴＣＰを使用する。ＴＣＰはそれ自身コネクション指向のプロトコルであり、それはＴＣＰ接続の開始で接続確立を要求する。この接続確立は少なくとも１つのＲＴＴを完成することを要求する３方向ハンドシェイクである。万一、パケットが３方向ハンドシェイクに失われれば、秒で測られたタイマを不履行にし、再送が送られることができる前に終了しなくてはならない。ここでまた、ＤＮＳルックアップのように、パケット損失が重要な遅れ負担を課することができる。
【００１１】
典型的なＷＷＷトランザクションは、主なウェブ・ページに埋め込まれたオブジェクトのための多くのＨＴＴＰ ＧＥＴリクエストを生成するだろう。これらのリクエストは、リクエストの大部分に役立っている通常１つ以上のサーバを有する別個のサーバにしばしば向けられる。ＨＴＴＰ１．０明細、ＲＦＣ１９４５およびＨＴＴＰ１．１明細、ＲＦＣ２６１６は、１つのサーバ当たり４つおよび２つの最大の同時のＴＣＰ接続をそれぞれ推奨する。
【００１２】
ブラウザは、これらの２つあるいは４つの接続だけにより役立った単一サーバへの多くのリクエストを待ち行列にしてもよい。各リクエストは次のものが送られる前に終わる。したがって、最小の遅れ負担（経路のＲＴＴにおいて）は、同時接続の数で割られて取り出されるべきオブジェクトの数である。埋め込まれたオブジェクトの大きな数については、この遅れ負担が全く重要になり得ることが続く。例えば、１つのサーバに置かれた４０の埋め込まれたオブジェクトを備えたアマゾン（Amazon登録商標）ウェブ・ページが与えられると、埋め込まれたオブジェクトをすべて取って来るために１０（あるいは２０）を越えるＲＴＴを要求するだろう。
【００１３】
相互の利益は、インターネット上のＴＣＰトラフィック輻輳の回避に由来する。この理由のため、ＴＣＰセッションは“遅いスタート”として知られている手順を使用して、休止期間の後に輸送を始めるか、あるいは輸送を継続する。さらに、輻輳ウィンドウ（未解決の不認可のセグメントの最大値）は最大の処理能力をＲＴＴで割られたウィンドウサイズに減少する。広帯域の静止衛星の場合には、その処理能力が一般に２倍のウィンドウサイズに制限されている。
【００１４】
遅いスタートは、セグメント中の負荷を、高々２つのセグメントであるようにＲＦＣ２５８１によって要求された初期負荷から着実に増加することを許容する。確かに、高いＲＴＴを有するリンクについては、各ＡＣＫサイクルは負荷が単一のセグメントによって増加することのみを許容するので、遅いスタートは非常に重い遅れ負担になり得る。リンクの完全利用に達する時間は、ＲＴＴと帯域幅が大きいところで、非常に重要になり得る。大きなサイズ・ウェブ・ページ（即ち、１０から１００キロバイト）に媒体を取り出すための時間は、転送のＴＣＰ遅いスタート段階によって増加させられる。実際に、そのような転送については、処理能力はこの遅いスタート段階によって支配される。
【００１５】
低い帯域幅リンク（１２８ｋｂｐｓ未満）が測定可能な伝送遅延を導入することは注目されるべきである。そのようなリンクに関して輸送された大規模なオブジェクトについては、伝送遅延に帰せられる全面的なトランザクション遅れの部分がより重要になる。アマゾン（Amazon登録商標）ウェブ・ページの前の例の使用では、すべてのＧＥＴリクエストの合計サイズは３０キロバイトのオーダーである。ほぼ３０ｋｂｐｓのリターン・リンク伝送レートを使用することは、例えば、全面的なトランザクション遅れに８秒を加えることができる。
【００１６】
以前に述べたように、ＴＣＰは必要なとき確立されるべき接続を要求し、もはや必要でない時取り壊しを要求するような接続指向のプロトコルである。それは起こるとき、ＨＴＴＰ１．０および１．１の両仕様において、サーバはそれらの接続を閉じることをクライアントに要求してもよい。これが生じる場合、常にＨＴＴＰ１．０のために行うので、その接続はセッション取り壊しを通じて進まねばならない。セッション開始のように、セッション取り壊しは、完成するのに少なくともＲＴＴ上で、さらに要求する３方向のハンドシェイクである。
【００１７】
セッション取り壊しに重要なことは、ブラウザが同時の接続のための仕様より多い与えられたサーバとの新しい接続を確立することができないということである。そのため、セッションが取り壊されているのと同じサーバに対しマルチ接続を出すことを要求する場合に限り、遅れ負担が経験される。
【００１８】
定義によって、プロキシは他のエンティティに代わって作用する。それらは、ソフトウェアエージェントのクラスであるために理解されたソフトウェア産業内にある。それらはそれらが代理になるエンティティと関連して近くあるいは遠くに置かれ得る。またそれらは、それらが仕えるエンティティと、それらが仕えるそれらの代わりにそれらがインタラクションするエンティティとの間のいくつかの場所に分配されてもよい。プロキシは、それらのクライアント（即ち、暗黙のプロキシ）にトランスペアレントであるか、それらのクライアント（即ち、明示的なプロキシ）に非トランスペアレントであるそれらにグループ化することができる。更に、それらは、ＡＰＩプロキシ、あるいはそれらがクライアントの代わりとして実現するプロトコルにより識別されるプロトコルプロキシ（アプリケーション、プレゼンテーション、セッションあるいはトランスポート層でそれである）として広く分類することができる。
【００１９】
それは、それらが仕えるクライアントを支援するためにキャッシュすることとして知られている技術を使用させるＡＰＩプロキシあるいはプロトコルプロキシのいずれかには珍しくない。そのようなプロキシは、常にキャッシュ・コヒーレンスおよびレプリケーションの影響を処理しなければならない。ある場合には、広帯域の衛星リンクでは、同期トランザクション要素を加えないようにするために、プロキシは必要上伝達遅れの回避を優先的にしてもよい。このアプローチのための最良の例は同期トランザクション要素を加える際にある。このアプローチのための１つの例は、キャッシュ・コヒーレンシイを維持するためにインターネット通信プロトコル（ＩＣＰ）を使用するＨＴＴＰプロキシにある。
【００２０】
それが接続上に輸送されたデータの整理編集を達成するために同期トランザクション要素を加えるので、ＩＣＰ（それはＨＴＴＰ接続上に実際に輸送されたデータ量を本質的に縮小することができる）は、実際に広帯域の衛星リンク上でユーザ経験待ち時間（ＵＥＬ）に壊滅的な影響を及ぼす。
【００２１】
ＤＮＳプロキシ（ローカルのＤＮＳサーバにおけるような）は、照会しているクライアントに近いすべてのＤＮＳサーバの部分集合を突き止める。これは、クライアントの観点からＤＮＳルックアップトランザクションを短くする意味合いを持つ。ＤＮＳプロキシは、将来の照会のために以前に得られた答えを保持するキャッシュを維持する技術を使用する。
【００２２】
ＴＣＰプロキシまたはＳＯＣＫＳプロキシは、ＴＣＰプロキシにクライアントの接続をすべて委任する明示的な手段を提示する。これは、実際の交換からクライアント（または複数のクライアント）の協会に役立つ意味合いを持つ。それは、接続パラメータが、接続が役立つクライアントと無関係にプロキシによって一定の方法で確立されることを可能にする。
【００２３】
ＨＴＴＰプロキシは、ＨＴＴＰプロキシにクライアントのＨＴＴＰ（したがってＴＣＰ）トランザクションをすべて委任する明示的な手段を提示する。これは、ＷＷＷトランザクション（ＤＮＳルックアップを含んで）に役立つトランザクション要素の根本的な接続のパラメータおよび品質を隠すのと同様に、両方とも全面的なトランザクションを短くする意味合いを持つ。
【発明の開示】
【発明が解決しようとする課題】
【００２４】
この開示は、ＨＴＴＰウェブ・ページを得るのに必要なインタラクションの縮小により、広帯域の無線リンクを加速することに関係がある。
【課題を解決するための手段】
【００２５】
一実施例では、無線リンクは、約２５０ミリセカンドの遅れあるいは待ち時間を導入する静止衛星を含んでいる。衛星リンクの待ち時間は、ユーザの衛星モデムにＨＴＴＰプロセッサを、および衛星ゲートウェイまたは基地局にＨＴＴＰフェッチャを持つことによって縮小される。特別のＵＲＩがＨＴＴＰタイプ・リクエストであることを知ることによって、最初のＨＴＴＰウェブ・ページは単一の通信における無線ゲートウェイから衛星モデムによってリクエストされることができる。ＨＴＴＰウェブ・ページの埋め込まれたオブジェクトは並列に要求することができ、その結果単一のＲＴＴだけが埋め込まれたオブジェクトの全部のために必要とされる。これは、従来システムによって要求される多数の往復遅延を縮小する。
【００２６】
一実施例では、ＴＣＰあるいは他のリンクはＨＴＴＰウェブ・ページ・リクエストを受信するのに先立って良好に構成される。一旦ＨＴＴＰプロセッサがＨＴＴＰウェブ・ページ・リクエストを受け取れば、それは無線リンク上で無線ゲートウェイへ転送される。無線ゲートウェイのＨＴＴＰフェッチャはＤＮＳルックアップを行ない、ＨＴＴＰウェブ・ページ・リクエストで示されたドメインのＩＰアドレスを見つける。一旦ＩＰアドレスが知られれば、埋め込まれたオブジェクトへのリンクを含んでいる最初のウェブ・ページは、無線モデムによるさらなるアクションを必要とせずに、無線ゲートウェイによってリクエストされる。最初のウェブ・ページは構成されたＴＣＰリンクを使用して、無線モデムへ転送される。最初のウェブ・ページの埋め込まれたオブジェクトは、約１ＲＴＴ中にそれらを受信する並列方法でリクエストすることができる。
【００２７】
開示に様々な他の態様がある。例えば、無線モデムおよび/または無線ゲートウェイのいずれかは、ＤＮＳキャッシュおよび/またはＨＴＴＰキャッシュを含むことができる。別の例として、ＨＴＴＰウェブ・ページ・リクエストは無線リンク上で圧縮され得る。いくつかの実施例は、無線リンクの衛星および/またはセルラー基地局のどちらかを使用することができる。
【００２８】
無線広帯域システムのトポロジーは、例えば３Ｍｂｐｓのダウンリンク順方向チャネルおよび５−４０Ｋｂｐｓアップリンク・リターンチャネルのような非対称のデータリンクを示す。比較的制限のあるアップリンク帯域幅は、必要によってスケーラブルである。最小のリターンチャネル（即ち、毎秒数キロビットまたはそれ以上）はそれが使用されているにもかかわらず各衛星モデムに常に利用可能であり、それは、衛星リンク上の帯域幅リクエスト・トランザクションの回避により低い待ち時間のリクエストを許容する。一旦特定のモデムがそのリターンチャネル・データをアップリンクすると、それはより多くの帯域幅の割当てを要求することができる。衛星ゲートウェイ（帯域幅が許されている）は、現在の必要によるアップリンクの帯域幅を拡大するために衛星モデムに認可を与えることができる。
【００２９】
開示の１つの態様では、リターンチャネルは、低い帯域幅リターンチャネル（上に議論されたように）によって招かれた伝送遅延を克服するために圧縮を使用することができる。圧縮は、リターンチャネルで送られた情報のタイプに適合され得る。例えば、ＨＴＴＰリクエストは、比較的制限のあるアップリンク帯域幅のデータ搬送容量を有効に増加させるためにテキスト特定アルゴリズムを使用することができる。
【００３０】
開示の実施例の特徴、目的および利点は、同様な要素が同様な参照番号をもつ図面と共に取られる時、下に示された詳細な記述からより明白になるだろう。さらに、同一タイプの様々な構成要素は、ダッシュによる参照ラベル、および同様の構成要素中で識別する別のラベルに従うことにより識別されるかもしれない。最初の参照ラベルが明細書中で使用される場合のみ、記述は、別の参照ラベルに関係なく同じ最初の参照ラベルを持っている同様の構成要素のうちの任意の１つに適用可能である。
【発明を実施するための最良の形態】
【００３１】
本開示は、広帯域の衛星あるいは他の高い待ち時間のデータリンク上でブラウズするワールド・ワイド・ウェブ（ＷＷＷ）の問題を緩和または除去する実施例を提供する。実施例によって取り組まれた問題の１つはユーザに経験された待ち時間の減少である。次の記述では、特定の詳細が実施例の完全な理解を提供するために与えられる。しかしながら、実施例がこれらの特定の詳細なしで恐らく実施されることが当業者により理解されるだろう。例えば、回路は実施例を不必要に詳細に不明瞭にしないようにブロック図で示されるかもしれない。他の例では、よく知られた回路、構造および技術が実施例を不明瞭にしないように詳細に示されるかもしれない。
【００３２】
さらに、実施例が、フローチャート、流れ図、構造図あるいはブロック図として描かれるプロセスとして記述されることが注目される。フローチャートは逐次プロセスとして動作を記述するが、動作の多くは並列または同時に行なわれることができる。さらに、動作の順序は再配列され得る。その動作が完了したときプロセスは終了する。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応してもよい。プロセスが機能に対応する場合、その終了は呼出し機能あるいは主機能へ機能を戻すことに対応する。
【００３３】
さらに、ここに示されるように、用語“記憶媒体”は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置および/または情報の記憶のための他の機械可読媒体を含むデータを記憶するための１つ以上の装置を表わすかもしれない。用語“機械可読媒体”は、限定するわけではないが、ポータブルまたは固定記憶装置、光学的記憶装置、命令および/またはデータを記憶、保持、搬送することの可能な無線チャネルおよび様々な他の媒体を含んでいる。
【００３４】
更に、実施例は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコードあるいはそれの任意の組合せによって実施されてもよい。ソフトウェア、ファームウェア、ミドルウェアあるいはマイクロコードで実施されるとき、必要なタスクを行なうプログラムコードあるいはコードセグメントは、記憶媒体のような機械可読媒体に記憶されてもよい。プロセッサが必要なタスクを行なってもよい。コードセグメントは手順、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラスあるいは命令、データ構造あるいはプログラムステイトメントの任意の組合せを表わしてもよい。コードセグメントは、情報、データ、変数、パラメータあるいはメモリ内容を渡すおよび/または受けることにより、別のコードセグメントあるいはハードウェア回路と結合されてもよい。情報、変数、パラメータ、データなどは、メモリ共有、メッセージ・パッシング、トークン・パッシング、ネットワーク伝送などを含む任意の適切な手段を介して渡され、転送され、送信されてもよい。
【００３５】
問題分析の評価および広帯域の衛星リンクの基本的な影響とともに、実施例は全面的なＷＷＷトランザクションの根本的なサブトランザクションの各々で見つかった固有の問題を覆うか緩和する努力について記述した。
【００３６】
ＤＮＳサブトランザクション
ＤＮＳサブトランザクションは、様々な実施例において少なくとも２つの別個の技術を使用して覆うことができるのと同様に緩和することができる。第1の技術（それはＤＮＳサブトランザクションのコストを緩和する）は、クライアント側ＤＮＳキャッシュ・プロキシである。このプロキシは以前に獲得した答えを生存する長い時間（即ち、終了時間）に備えてキャッシュに入れる。与えられた照会が再度出される場合、オリジナルの遅れ負担はすべての再提起上でならされる。
【００３７】
第２の技術（それはＤＮＳサブトランザクションを含むＷＷＷトランザクション内のサブトランザクションの幾つかのコストを覆う）は、地球上側のＨＴＴＰフェッチャにより役立たされたクライアント側ＨＴＴＰプロセッサを含んでいる。ＨＴＴＰプロセッサは、本質的にＨＴＴＰフェッチャにＤＮＳサブトランザクション全体を分配し、それによって、ＤＮＳサブトランザクションの広帯域の衛星リンクの影響を除去する。さらに、セッション開始およびセッション取り壊しＴＣＰサブトランザクションは同様に緩和することができる。これらの２つの技術は１つ以上の広帯域の衛星リンクラウンドトリップ時間（ＲＴＴ）を節約し、それらを地球上のＲＴＴで置換する。
【００３８】
セッション開始およびセッション取り壊しサブトランザクション
これらの２つのサブトランザクションは、地球上側のＨＴＴＰフェッチャにより役立たされたクライアント側ＨＴＴＰプロセッサを使用して緩和することができる。ここで、クライアント・ブラウザがクライアント側ＨＴＴＰプロセッサとのその関係を確立し、必要とされるときに開かれかつ閉じられ得るので、これらのサブトランザクションのコストは完全に覆われる。しかしながら、ＨＴＴＰプロセッサおよびＨＴＴＰフェッチャの間の接続は、無期限に（非常に長いタイムアウト）維持される。この技術は、ＴＣＰ接続を設定および取り壊すために必要な広帯域の衛星リンクＲＴＴを除去し、衛星モデムのＨＴＴＰプロセッサとゲートウェイ構成要素のＨＴＴＰフェッチャとの間の単一のＴＣＰ設定および取り壊しでそれらを置換する。
【００３９】
ＨＴＴＰサブトランザクション（ＧＥＴ／ＲＥＰＬＹ直列化）
ＨＴＴＰ ＧＥＴ／ＲＥＰＬＹ直列化は、ＲＦＣ基準が課する制約に起因する。ほとんどのブラウザはこれらの制約に付着する。ＨＴＴＰ ＧＥＴ／ＲＥＰＬＹ直列化は２つの関連する技術を使用して緩和することができる。
【００４０】
第1の技術（それはＨＴＴＰ１．０トランザクションのためのＨＴＴＰ ＧＥＴ／ＲＥＰＬＹ直列化インパクトを緩和する）は、衛星モデムでブラウザからクライアント側ＨＴＴＰプロセッサへ並列ＴＣＰ接続を使用することである。この技術は、ＨＴＴＰ１．１トランザクションにさらに利用可能であるが、ＲＦＣの中で指定された接続限界に従う。ＲＦＣがクライアント・ブラウザに小さな接続制限を課することはここで注目されるべきである。クライアント側ＨＴＴＰプロセッサおよびその地球上のＨＴＴＰフェッチャは、同時接続の合理的に開終了数をサポートするために実行される。
【００４１】
第２の技術（それはＨＴＴＰ１．１トランザクションのためのＨＴＴＰ ＧＥＴ／ＲＥＰＬＹ直列化インパクトを緩和する）は、パイプラインを実行するＨＴＴＰ １．１ブラウザのためのＨＴＴＰプロセッサおよびＨＴＴＰフェッチャのＧＥＴパイプラインをサポートすることである。これらの技術は両方とも、埋め込まれたオブジェクトの大きい数を備えた特に大きなサイトのための直列化結果を減少することができる。さらに、これらの２つの技術はともに使用することができる。
【００４２】
これらの２つの方法のうちの１つによってＨＴＴＰ ＧＥＴ／ＲＥＰＬＹの直列化を削除することによって、この実施例中のすべてのオブジェクトへのアクセスは、すべてのオブジェクトについてほぼ１つの代わりに、合計の広帯域の衛星リンク遅れを約１つあるいは２つに減らすことができる。
【００４３】
ＴＣＰ輸送サブトランザクション
広帯域の衛星リンクがＴＣＰ輸送で持っているインパクトは２つの技術を使用して緩和することができる。第1の技術は、７５０キロバイトのウィンドウを許すことにより処理能力に対するＲＴＴの影響を無効にする。これは、以下に表示される第２の技術と共に、リンクがほとんど即座に完全利用に達することを可能にする。第２の技術は、ＴＣＰスタックからの遅いスタートを緩和する。これは、２つのエンドポイント間で、リンク輻輳を受けない衛星リンクだけがあるという事実によって正当化される。ＴＣＰの動作のこれらの変更は、ＨＴＴＰトランザクションでの要求されたオブジェクトの転送からいくつかの広帯域の衛星リンクラウンドトリップを取り除くことができる。
【００４４】
伝送遅延の影響（ＧＥＴ／ＲＥＰＬＹサイズ）
ＨＴＴＰ ＧＥＴおよびＨＴＴＰ ＲＥＰＬＹの両方のデータ圧縮を使用することは、ＨＴＴＰトランザクションの伝送遅延の影響を緩和することができる。多くのサイトのためのＨＴＴＰ ＧＥＴおよびＲＥＰＬＹの内容の分析は、ＨＴＴＰ ＧＥＴのための達成可能な圧縮比がほぼ９０％またはそれより良く、ＨＴＴＰ ＲＥＰＬＹのための達成可能な圧縮比がおよそ５０％またはそれより良いことを示す。この高い圧縮率は、特にリターン・リンク上のＨＴＴＰ ＧＥＴのために、低速リターン・リンクレートが他のシステム設計目的のために実施されているとき、重要な時間を節約することができる。テキストデータ上で有効な任意のタイプの圧縮アルゴリズムが、例えば、Ｌｅｍｐｅｌ−Ｚｉｖ圧縮を使用することができる
最初に図１Ａを参照すると、無線広帯域システム１００−１の実施例のブロック図が、衛星リンクを利用することで示される。静止衛星１４０は双方向の方法で第1の衛星ディッシュ（椀形アンテナ）１１６を第2の衛星ディッシュ１３０と結合する。この双方向リンクの各方向の待ち時間は約２５０ミリセカンドであるが、様々な実施例で決して１００ミリセカンドあるいは２００ミリセカンドより小さくはない。いくつかの実施例は、単一方向の衛星リンク、および別の方向のための他のあるメディア、例えばダイアルアップのモデム接続を使用する。一実施例は衛星リンクにおいて地球静止軌道にない低軌道周回衛星の星座を使用する。別の実施例では、ゲートウェイ１１８または地上局にダウンリンクする前に多数の衛星がそれら自身の間でルートを取ることができる。
【００４５】
無線広帯域システム１００は、ユーザまたはビジネスのコンピュータ設備１１２がインターネット１１０と通信することを可能にする。コンピュータ設備１１２は、インターネット１１０と通信することができるあらゆるパソコン、メインフレーム、ワークステーション、ＶＯＩＰターミナル、ＰＤＡ、消費者設備、事務機器、ネットワーク、ビデオ機器などを含むことができる。少なくとも１つのウェブ・ブラウザ・アプリケーションがコンピュータ設備１１２に含まれている。ウェブ・ブラウザはコンピュータ設備１１２によってウェブ・ブラウザにより使用されるプロトコルに制限されているかもしれない明示的なプロキシを使用するように構成される。いくつかの実施例では、ウェブ・ブラウザ情報だけを選択するために、暗黙のプロキシはすべてのＴＣＰ／ＩＰ情報を通してふるいにかけることができる。
【００４６】
コンピュータ設備１１２は衛星モデム１２２と通信する。衛星モデム１２２が、コンピュータ設備への明示的なプロキシとして現われる。ウェブ・ブラウザまたはオペレーティング・システムはプロキシとして衛星モデム１２２を使用するように構成されなければならない。衛星モデム１２２はコンピュータ設備１１２へのプロキシとして現われるが、プロキシ機能は、以下にさらに説明されるように衛星モデム１２２と衛星ゲートウェイ１１８の間で分割される。
【００４７】
この実施例中の衛星モデム１２２はスタンド・アロン・ユニットである。それはソフトウェア、ハードウェアおよびモデム１２２の機能性を実施する１台以上のプロセッサを含んでいる。記憶装置は揮発性あるいは不揮発性メモリの形であることができる。モデム１２２中のキャッシュは不揮発性磁気あるいは光メモリか、揮発性のソリッドステイト・メモリで実施することができる。いくつかの実施例では、キャッシュは電力損失を浪費する。ゲートウェイ１１８は、キャッシュが取り除いたパワーアップについて通知され、プロセスは以前の記憶装置を再生し始める。
【００４８】
衛星モデム１２２は、コンピュータ設備１１２および衛星ディッシュ１１６と通信するためにポートを含んでいる。コンピュータ設備１１２用のポートは様々な衛星モデム１２２の機器構成のためにＵＳＢ、イーサネット（登録商標）、ＩｒＤＡ、Ｆｉｒｅｗｉｒｅ、ＷｉＦｉ、ＵＷＢ、ＷｉＭａｘ、搬送電流などを含むことができる。衛星ポートは衛星ディッシュ１１６との通信を許容する。ＲＦ信号は典型的にこのポートのために使用されるが、いくつかの実施例はディジタルインタフェースを使用することができる。
【００４９】
コンピュータ設備１１２のインターネットリクエストをサービスするために、衛星ゲートウェイ１１８は衛星ディッシュ１３０およびインターネット１１０間で通信する。様々な実施例は様々な方法で分布された多くの衛星ゲートウェイ１１８を持つことができる。一実施例は様々な位置からリクエストを受信し、ある遠隔地のゲートウェイ１１８へそれらを送ることができる。他の実施例は、リクエストを分割するために一群のゲートウェイを使用することができる。任意の他の機器構成も衛星ゲートウェイ１１８の機能を行なうことができる。
【００５０】
標準のインターネットリクエストは、衛星ゲートウェイ１１８によってインターネット１１０へ引き起こされる。ドメイン名サーバ（ＤＮＳ）１０４はドメイン名をインターネットプロトコル（ＩＰ）アドレスに翻訳するために使用される。ＩＰアドレスは一様なリソース識別子（ＵＲＩ）中で示されたオブジェクトを出す起点サーバ１２６に対応する。示されていないが、インターネット機器構成のタイプの他の変化が可能である。例えば、起点サーバ１２６は内容ミラーあるいは内容配信ネットワークを使用してもよい。
【００５１】
衛星ゲートウェイ１１８の実施は任意の数の機器構成をとることができる。コンピュータとサーバはディジタル処理および記憶タスクをすべて実施する。ルータ、スイッチ、ゲートウェイおよびモデムは、インターネットおよび衛星ゲートウェイ１１８の様々な構成要素とのインターフェースに使用される。衛星ゲートウェイ１１８の部分は地理的に雑多なネットワークに広げることができる。衛星ディッシュ１３０あるいは他の無線等価物とインターフェースするＲＦ機能は、その目的のために設計されたハードウェアデバイスで実施される。
【００５２】
標準のインターネットリクエストは、衛星ゲートウェイ１１８によってインターネット１１０へ引き起こされる。ドメイン名サーバ（ＤＮＳ）１０４はドメイン名をインターネットプロトコル（ＩＰ）アドレスに翻訳するために使用される。ＩＰアドレスは一様なリソース識別子（ＵＲＩ）中で示されたオブジェクトを出す起点サーバ１２６に対応する。示されていないが、インターネット機器構成の他の変化が可能である。例えば、起点サーバ１２６は内容ミラーあるいは内容配信ネットワークを使用してもよい。
【００５３】
図１Ｂに関して、無線広帯域システム１００−２の別の実施例のブロック図が無線セルラーリンクを利用することで示される。無線モデム１４０は、様々なタイプのコンピュータ設備１１２が電話能力を持つ必要なく無線ゲートウェイ１１８と通信することを可能にするプラグ・イン・カードであり得る。一実施例では、無線モデム１４０およびコンピュータ設備１１２の両方はブラウザ能力を持つ電話機送受話器に統合される。各無線ゲートウェイ１１８は無線で無線モデム１４０に結合されるセルラー基地局１３６に連結される。セルラーリンクの待ち時間は本質的にほとんどの場合衛星リンク未満である。
【００５４】
次に図２Ａを参照すると、衛星または無線モデム１２２−１の実施例のブロック図が示される。コンピュータ・ポート２０４はコンピュータ設備１１２と通信するが、他の実施例は多くの異なる有線または無線ポート２０４およびプロトコルをサポートすることができる。プロトコル弁別器２０６は、コンピュータ・ポート２０４のＴＣＰ／ＩＰトラフィックをすべて管理する。ＨＴＴＰタイプ・トラフィックはプロトコル弁別器２０６によって他のＴＣＰ／ＩＰトラフィックから分離れているようにしておかれる。ＨＴＴＰトラフィックをＴＣＰ／ＩＰトラフィックの残りから分離しておくために、ＩＰアドレス、ポートあるいは他のメカニズムを使用することができる。どんな場合も、プロトコル弁別器２０６はＨＴＴＰトラフィックをＨＴＴＰプロセッサ２１２に伝え、残るＴＣＰ／ＩＰトラフィックをＴＣＰ／ＩＰプロセッサ２０８に伝える。
【００５５】
ＴＣＰ／ＩＰプロセッサ２０８は、ＨＴＴＰトラフィックでないインターネットトラフィックを扱う。いくつかの実施例は、ここに記述された技術のうちのいくつかを使用して、非ＨＴＴＰトラフィックの取り扱いを向上させてもよい。ＴＣＰ／ＩＰプロセッサは、圧縮機能２３２および逆圧縮機能２２８の使用により、圧縮した形式で無線リンク上で通信する。無線周波数（ＲＦ）送信器２２０およびＲＦ受信機２１６は搬送周波数上にディジタル信号を変調し復調する。他の実施例が異なるＲＦ機器構成を持っていてもよい。
【００５６】
ＨＴＴＰプロセッサ２１２はＨＴＴＰトラフィックを管理する。ＨＴＴＰトラフィックが検知される場合、衛星モデム１２２と衛星ゲートウェイ１１８の間のＴＣＰ接続は、順方向とリターン・リンクの両方でＨＴＴＰプロセッサによって開かれる。不活発の期間の後に、このＴＣＰ接続は例えば２０分の後に閉じたれることができる。不活発期間が切断を引き起こしていないと仮定して、多くの様々なＨＴＴＰトランザクションがＴＣＰリンクを通して流れるだろう。通常のシステムは各ＨＴＴＰトランザクションのためにＴＣＰリンクを設定および取り壊すであろう。ＨＴＴＰプロセッサ２１２はコンピュータ設備１１２からＨＴＴＰ ＧＥＴを集めて、対応するＨＴＴＰ ＲＥＰＬＹを供給する。
【００５７】
いくつかの実施例は、順方向および/またはリターン・リンクのためにＴＣＰ以外のプロトコルを使用することができる。これらのプロトコルはＨＴＴＰトランザクションを受信するのに先立って構成され、多くのＨＴＴＰトランザクションをサービスするため開いたままである。典型的には、ＲＴＴ遅れはリターン・リンクのためのプロトコルを構成するように使用されるが、この実施例はＲＴＴ遅れの最初の時間のリターン・リンクが構成されることのみ経験する。
【００５８】
順方向およびリターン・リンクは、帯域幅必要条件を縮小するために圧縮を使用する。圧縮アルゴリズムはこの実施例において特定のデータに適合される。例えば、１つのアルゴリズムはテキストに使用されてもよく、別のものはファイルに使用してもよい。リターン・リンクを通り抜けるデータは、有効な本文のアルゴリズムが、例えば、Ｌｅｍｐｅｌ−Ｚｉｖを使用されるような大部分テキストである。順方向リンクは、本文および非本文の情報に有効な別のアルゴリズムを使用してもよい。どんな場合も、しかし、圧縮および逆圧縮機能２３２、２２８はこの実施例の中で損失がない圧縮を使用する。圧縮および逆圧縮機能２３２、２２８はハードウェアおよび/またはソフトウェアで実施することができる。多数のアルゴリズムが使用される場合、圧縮データ用のヘッダーは、リンクの受信端がデータを逆圧縮することを可能にするために、どのアルゴリズムが圧縮データのために使用されたか示すことができる。
【００５９】
図２Ｂを参照すると、衛星または無線モデム１２２−２の別の実施例のブロック図がＤＮＳキャッシュ２３６を含んで示される。ＤＮＳキャッシュ２３６は、ゲートウェイ１１８を使用した以前に得られたＤＮＳルックアップを保持するため、ＨＴＴＰプロセッサ２１２およびＴＣＰ／ＩＰプロセッサ２０８によって使用される。ウェブ・ブラウザあるいは他のアプリケーションがＤＮＳルックアップを要求するとき、それが以前に決定されたかどうか判断するためにＤＮＳキャッシュは参照されることができる。どんなキャッシュに入れられたＩＰアドレスも、後のＤＮＳルックアップ操作に使用することができる。
【００６０】
次に図２Ｃを参照すると、モデム１２２−３の別の実施例のブロック図がリターン・リンクのための帯域幅管理を含んで示される。リターン・バッファ２２４は、データがリターン・リンク・マネージャー２４０によってスプールされることができるまで、リターン・リンクのために予定されたデータを保持する。リターン・リンクは、リターン・リンク・マネージャー２４０に常に利用可能な名目上２０−４０Ｋｂｐｓチャネルである。
【００６１】
リターン・バッファ２２４が、リターン・リンクの待ち時間を増加させるポイントに充填し始めれば、帯域幅は時間の期間中スケールアップされることができる。リターン・リンク・マネージャー２４０はより多くの帯域幅を要求するか、ゲートウェイ１１８へ充填レベルを報告することができる。ゲートウェイ１８８はリクエストを評価し、リターン・リンクがより低い帯域幅チャネルへ戻る前に、時間の期間中より高い帯域幅を割り当てることができる。符号分割多元接続トポロジーでは、これはより高い帯域幅を持っていた新しいチャネルコードを送ることを含むことができるが、任意のトポロジーが様々な実施例（ＴＤＭＡなど）に使用することができる。
【００６２】
図２Ｄを参照すると、モデム１２２−４のまだ別の実施例のブロック図が帯域幅管理および圧縮の両方を含んで示される。この実施例では、リターン・バッファ２４４のコンテンツはリターン・リンク上にそれらを送る前に圧縮される。リターン・バッファ中のすべての情報がゲートウェイ１１８のために予定されるので、同じＴＣＰ接続は、分離した接続を設定および取り壊すよりもむしろすべての情報のために使用されることができる。いくつかの実施例は、永続接続を開設することができかつ情報のパケットの転送を管理することができるＴＣＰ以外のプロトコルを使用することができる。
【００６３】
次に図３Ａを参照すると、衛星または無線ゲートウェイ１１８−１の実施例のブロック図が示される。描かれた実施例は、無線モデム１２２を反映する機器構成の中で圧縮機能２３２、逆圧縮機能２２８、ＲＦ送信機２２０、ＲＦ受信機２１６および無線ポート２２４を使用する。一旦リターン・リンクからの情報が復調され逆圧縮されれば、トラフィック弁別器３１８は情報がＨＴＴＰに関係するかどうかを判断する。ＨＴＴＰフェッチャ３０８はＨＴＴＰトラフィックを扱い、ＴＣＰ／ＩＰフェッチャ３０４はその残りを扱う。ＨＴＴＰ、ＴＣＰ／ＩＰフェッチャ３０８、３０４の両方はインターネット１１０と対話し、モデム１２２への順方向リンク用インターネット情報を集めて戻す。
【００６４】
ＨＴＴＰフェッチャ３０８は、モデム１２２から受信されたそれらのドメイン名を備えたＵＲＩをデコードする。ドメイン名はインターネット１１０上でＤＮＳ１０４を使用して、ＩＰアドレスに翻訳される。一旦ＩＰアドレスが知られると、ＵＲＩはＨＴＴＰオブジェクトを提供するために特別の起点サーバ１２６に出される。要求されたオブジェクトおよび続いて要求された埋め込まれたオブジェクトが、それらが到着するときに順方向リンク上で圧縮され送られる。ＨＴＴＰフェッチャの他の実施例は、ウェブ・ページ・オブジェクト中のすべての埋め込まれたリンクに従い、またさらに要求されているリンクしたページのうちの１つを予期して、ＨＴＴＰプロセッサ２１２へこれらのリンクしたページを送る。
【００６５】
帯域幅アロケータ３２２は、無線広帯域システム１００中の様々なモデム１２２から付加的なリターン帯域幅の要求を受信する。これらの要求はある量の帯域幅を求めることができ、あるいはリターン・バッファ２２４に充填レベルの報告がちょうどあり得る。充填レベルはバッファされたデータ量であり得るか、バッファ２２４のどれだけが消費されたかを示すことができる。一実施例において、２ビットがモデム１２２からのパケットのヘッダーで使用され、３つの異なる閾値、例えば全体の三分の一、全体の三分の二および略全体がバッファで達成されたかどうかを示す。
【００６６】
図３Ｂを参照すると、衛星または無線のゲートウェイ１１８−２の別の実施例のブロック図が示される。この実施例はＨＴＴＰキャッシュ３１２およびＤＮＳキャッシュ２３６をゲートウェイ１１８−２へ統合する。多くのモデム１２２がオブジェクトをリクエストするので、ＤＮＳ情報およびＨＴＴＰページが記憶される。同じ情報の後のリクエストは
キャッシュ２３６および３１２から供給することができる。ＴＣＰ／ＩＰおよびＨＴＴＰフェッチャ３０４、３０８はＤＮＳキャッシュ２３６を使用し、また、ＨＴＴＰフェッチャ３０８はＨＴＴＰキャッシュ３１２を使用する。多くのオブジェクトがカスタマイズされるので、ＨＴＴＰキャッシュ３１２は任意の１人のユーザに特有でないパラメータ化されていない情報を単に戻す。
【００６７】
次に図４Ａを参照すると、無線リンク上でブジェクトをダウンロードするプロセス４００−１の実施例のフローチャートが示される。プロセス４００−１の描かれた部分はステップ４０４に始まり、そこではこのＨＴＴＰ ＧＥＴがＨＴＴＰプロセッサに出される前に、モデム１２２とゲートウェイ１１８の間の永続ＴＣＰリンクが構成される。このＴＣＰリンクは、低い待ち時間でどんなリターン・リンク・データもサービスするために、利用可能な制限された帯域幅を有する。コンピュータ設備１１２上のブラウザはプロキシとしてＨＴＴＰプロセッサ２１２を使用するように構成されるが、しかし、プロキシ機能性はＨＴＴＰプロセッサ２１２とＨＴＴＰフェッチャ３０８との間で分割される。
【００６８】
ステップ４０８において、ブラウザはＨＴＴＰプロセッサ２１２へＨＴＴＰ ＧＥＴコマンドを出す。この実施例では、ブラウザはＤＮＳルックアップおよびＨＴＴＰプロセッサ２１２への外部ＩＰアドレスの取り扱いを延期する。ＨＴＴＰ ＧＥＴコマンドおよび関連するＵＲＩは、ステップ４１２においてリターン・リンクによってＨＴＴＰフェッチャ３０８へ渡される。ステップ４１６において、ＵＲＩからドメイン名のＩＰアドレスを得るために、ＤＮＳルックアップがＨＴＴＰフェッチャ３０８によって行なわれる。
【００６９】
オブジェクトはステップ４２０で起点サーバ１２６からリクエストされる。オブジェクトが起点サーバ１２６から送られるので、ステップ４２４において、それは順方向リンクを使用してＨＴＴＰプロセッサ２１２へ転送される。ステップ４２８において、ウェブ・ブラウザのオリジナルのＨＴＴＰ ＧＥＴコマンドは、ＨＴＴＰプロセッサ２１２によって遂行される。任意の後のＨＴＴＰ ＧＥＴコマンドはステップ４２８からステップ４０８にループすることにより満たされる。
【００７０】
図４Ｂを参照すると、無線リンク上でオブジェクトをダウンロードするプロセス４００−２の別の実施例のフローチャートが示される。この実施例は順方向およびリターン・リンクの圧縮をサポートする。ステップ４１０でＨＴＴＰ ＧＥＴコマンドを圧縮するステップが行なわれ、また、ステップ４２６でオブジェクトを逆圧縮するステップが行なわれる。他の実施例の付加ステップは、変更がプロトコル、内容、アプリケーションなどに基づいている異なる圧縮アルゴリズムをサポートすることができる。
【００７１】
図４Ｃを参照すると、無線リンク上で一群のオブジェクトをダウンロードするプロセス４００−３の実施例のためのフローチャートが示される。ステップ４０２において、コンピュータ設備１１２は、モデム１２２へのＨＴＴＰ接続の推奨される最大量以上を許容する非標準のやり方で構成される。コンピュータ設備の構成はブラウザ設定を変更すること、レジストリ・エントリまたは他の機器構成への変更を含んでもよい。様々な実施例では、ＴＣＰ接続の数は、少なくとも５、１０、１６、３２、６４、１２８、２５６あるいは５を越える任意の他の整数であり得る。
【００７２】
ＴＣＰあるいは他の接続はステップ４０４で衛星リンクに上で確立される。このＴＣＰ接続は初期のＨＴＴＰ ＧＥＴで確立されてもよく、または現在のＨＴＴＰ ＧＥＴの結果として確立することができる。どんな場合も、ＴＣＰ接続はプロセス４００−３の残りの間中、恐らくさらに長く開いたままである。この実施例では、他のオブジェクトへの埋め込まれたリンクを備えたオブジェクトに関する最初のＨＴＴＰ ＧＥＴリクエストは、ステップ４０６におけるＨＴＴＰ ＲＥＰＬＹで満足される。これはコンピュータ設備１１２とモデム１２２との間のＴＣＰ接続を構成することを含むだろう。
【００７３】
一旦最初のオブジェクトがＨＴＴＰ ＲＥＰＬＹで戻されると、多くの埋め込まれたリンクはコンピュータ設備１１２によって引出される。利用可能なＨＴＴＰ接続の非標準の数と一致して、埋め込まれたリンクはすべて、並列の方法で４０６ステップの数でリクエストすることができる。特別なウェブ・ブラウザが矢継ぎ早にＨＴＴＰ ＧＥＴコマンドを連続して出してもよいが、利用可能なＨＴＴＰ接続の増大数のために、これらのＨＴＴＰ ＧＥＴコマンドを出し続けることができる。ＨＴＴＰ接続の限界が達成されると、ウェブ・ブラウザは開かれたＨＴＴＰ接続のうちの１つが閉じるのを待つだろう。
【００７４】
次に図５Ａを参照すると、無線広帯域システム１００中の無線リターン・リンクを加速するプロセス５００−１の実施例のフローチャートが示される。リターン・リンク・マネージャー２４０は、適切なリターン・リンク帯域幅を提供するため、帯域幅アロケータ３２２と協力して働く。プロセス５００−１の描かれた部分は、ステップ５０４で始まり、通信が永続低帯域幅リターン・リンク上で行なわれる。一旦閾値を超過すれば、この実施例はバッファ充填レベルを単に報告するが、他の実施例は各パケットでまたは周期的にパケットでバッファ状態を戻すことができる。
【００７５】
ステップ５０８において、リターン・バッファ消費はリターン・リンク・マネージャー２４０によって監視される。予め定められた閾値がステップ５１２において超過しない限り、リターン・リンク・マネージャーは追加帯域幅を要求せず、処理ループはステップ５０４に戻る。ステップ５１２において、バッファ閾値が超過された場合、処理はステップ５１６に続き追加帯域幅を要求する。この実施例では、閾値は全体の三分の一になるリターン・バッファである。他の実施例は、現在の帯域幅割当てを与えられたバッファを空にする遅れとして閾値を定義する。例えば、バッファが空になるために１００ミリセカンド以上をとる場合、追加帯域幅の要求がなされる。
【００７６】
ステップ５１６において、バッファ充填レベルは次のパケットでゲートウェイ１１８へ報告される。この報告はバッファ中の量、バッファを空にするのに必要な時間、および/または丁度閾値が超過された指示であり得る。帯域幅アロケータ３２２はステップ５２０で充填レベル情報を受信し、リターン・リンクを共有する他のものの必要に関してリクエストしているモデム１２２の必要を分析する。すべてのリクエストが融通され得ない場合、リクエストの承認は、待ち時間の結果がすべてのモデム１２２を横切って分配されるように、任意にラウンドロビン方法で許可されるか、または他のある方法によって許可されてもよい。
【００７７】
許可される場合、より高い帯域幅のリターン・リンクがステップ５２４で時間の期間に割り当てられる。より高い帯域幅リンクは追加リンクあるいは先のリンクと交換するものであり得る。時間の期間が終了した後、他のリターン・リンクが異なる帯域幅で示されることができる。任意の一連のリンクおよび時限が帯域幅アロケータ３２２によって指定され得る。例えば、７５０Ｋｂｐｓのリンクは３秒で直ちに割り当てられることができ、また、２００Ｋｂｐｓのリンクは２秒の遅れの後に利用可能になり、その後１０秒の間利用可能なままであり得る。帯域幅アロケータ３２２が、モデム１２２に通知して異なるものとリンクを取り替えることによりその位置を変更する場合、リンクの異なる割当てが後で行なわれ得る。
【００７８】
時限定義が終了するまで新しいリンクが使用される。ある場合には、モデム１２２が他の方法で通知されるまで使用が継続することができるように、リンクが終了を持っていない。例えば、モデムは次の１０秒の間５００Ｋｂｐｓリンクを与えられ、その後モデム１２２が新しい命令を受けるまで使用することができる２５Ｋｂｐｓリンクを与えられてもよい。
【００７９】
図５Ｂを参照すると、無線広帯域システム１００中のリターン・リンクを加速するプロセス５００−２の別の実施例のフローチャートが示される。この実施例では、ループ中のステップ５０４、５０８、５１６および５２０を行なうことにより、充填レベルは各パケットで、数パケットごとに、または周期的に報告される。ステップ５３２およびステップ５２０の後において、帯域幅アロケータ３２２は追加帯域幅が利用可能になるかどうか決めている。どれも利用可能にならない場合、処理はステップ５３２からステップ５０４にループバックする。より多くが利用可能になる場合、ステップ５３２で決定されるように、ステップ５２４および５２８がステップ５０４にループバックする前に行なわれる。
【００８０】
示された実施例の上記の記述はどんな当業者も開示を作るか使用することを可能にするために提供される。これらの実施例への様々な変更は当業者に容易に明白であり、ここに定義された総括的な原理は、開示の精神または範囲から逸脱することなく他の実施例に適用されるかもしれない。したがって、その開示は、ここに示された実施例に限定されることを意図されず、ここに示された原理と新規な特徴と一致する最も広い範囲を与えられるべきである。
【図面の簡単な説明】
【００８１】
【図１Ａ】無線広帯域システムの実施例のブロック図である。
【図１Ｂ】無線広帯域システムの実施例のブロック図である。
【図２Ａ】衛星モデムの実施例のブロック図である。
【図２Ｂ】衛星モデムの実施例のブロック図である。
【図２Ｃ】衛星モデムの実施例のブロック図である。
【図２Ｄ】衛星モデムの実施例のブロック図である。
【図３Ａ】衛星ゲートウェイの実施例のブロック図である。
【図３Ｂ】衛星ゲートウェイの実施例のブロック図である。
【図４Ａ】無線リンク上でＨＴＴＰオブジェクトをダウンロードするプロセスの実施例のフローチャートである。
【図４Ｂ】無線リンク上でＨＴＴＰオブジェクトをダウンロードするプロセスの実施例のフローチャートである。
【図４Ｃ】無線リンク上でＨＴＴＰオブジェクトをダウンロードするプロセスの実施例のフローチャートである。
【図５Ａ】リターン・リンクを加速するプロセスの実施例のフローチャートである。
【図５Ｂ】リターン・リンクを加速するプロセスの実施例のフローチャートである。
【図１Ａ】
2007531405.tif 000003
【図１Ｂ】
2007531405.tif 000004
【図２Ａ】
2007531405.tif 000005
【図２Ｂ】
2007531405.tif 000006
【図２Ｃ】
2007531405.tif 000007
【図２Ｄ】
2007531405.tif 000008
【図３Ａ】
2007531405.tif 000009
【図３Ｂ】
2007531405.tif 000010
【図４Ａ】
2007531405.tif 000011
【図４Ｂ】
2007531405.tif 000012
【図４Ｃ】
2007531405.tif 000013
【図５Ａ】
2007531405.tif 000014
【図５Ｂ】
2007531405.tif 000015
【国際調査報告】
2007531405.tif 000016
2007531405.tif 000017
2007531405.tif 000018
2007531405.tif 000019
2007531405.tif 000020