JP4841098B2 - ウェブ・ページのダウンローディング - Google Patents

Description

【０００１】
［発明の属する技術分野］
本発明は、セッション内で連続的伝送制御プロトコル（ＴＣＰ）コネクションを用いるセッション又はアプリケーション・プロトコルを用いて、時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム又は有線モデム・アクセス・プロトコル上でのウェブ・サイトのダウンローディングに関する。詳細には、本発明は、そのようなダウンロードに関係する時間オーバヘッドを低減し、そしてそのようなシステムにおけるランダム・アクセス競合数を低減する方法に関する。
【０００２】
［従来の技術］
クライアント（ウェブ・ブラウザ）がウェブ・アクセスを開始するとき、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）コネクションは、図１に示されるように、クライアントとウェブ・サーバとの間に確立される。そのコネクションは、スリーウェイ・ハンドシェーク（ｔｈｒｅｅ−ｗａｙ ｈａｎｄｓｈａｋｅ）として知られているものを利用して確立される。最初に、クライアントは、ＳＹＮ（同期信号文字）信号をサーバに送り、次いでサーバは、ＳＹＮ信号をクライアントに送り返す。次いで、クライアントは、肯定応答信号をサーバに送り、それによりサーバのＳＹＮ信号の受け取りを確認し、そしてコネクションが完了する。
【０００３】
一旦コネクションがクライアントとサーバとの間で確立されてしまうと、クライアントは、ハイパー・テキスト・マークアップ言語（ＨＴＭＬ）要求をサーバに送る。そのような要求は、単一のＴＣＰメッセージとして送られ得て、又は２つのそのようなメッセージに分割され得る。コネクションは、スロー・スタート機構と呼ばれるものにより特徴付けられる。クライアントは、単一のＨＴＭＬ要求を送り、応答（典型的には要求されたデータを含む）をサーバから待ち、肯定応答をサーバに送る。肯定応答の送信後に、複数のデータ信号が、サーバから受信され、そのような受け取りがクライアントにより促進される。一旦全てのデータが受信されると、サーバは終了信号を送る。終了肯定応答信号がクライアントからサーバに送られ、次いで終了信号も送られる。
【０００４】
ウェブ・ページのダウンローディングは、幾つかのＴＣＰ／ＩＰコネクション確立及び解体（ｔｅａｒ ｄｏｗｎ）シークエンスを含む。これは、ダウンロードされるべきウェブ・ページが２以上のインライン・イメージを備える場合、別個のＴＣＰセッションが、各イメージのサーバからクライアントへの転送のために要求されるからである。図１はこの問題を示し、その問題により一旦終了信号１０２がクライアントにより送信されてしまうと、クライアントは、ダウンロードされたページをパース（検査）して、もっとデータが要求されているか否かを確認する。図１の事例では、イメージはダウンローディングを要求し、そこで、前述のコネクション確立及び解体シークエンスが再び実行される。この場合、送られるべき１無線リンク制御（ＲＬＣ）パケットより小さい単一のデータ・エレメントのみが存在し、従ってサーバは、終了信号が続く単一のデータ信号を送る。この場合、スロー・スタート機構は関係しない。
【０００５】
従って、複数のイメージを含むウェブ・ページをダウンロードするため、ある一定数のＴＣＰコネクションが、クライアントとサーバとの間に行われなければならないことは明らかである。これは、ウェブ・ページの全体的なダウンロードに対する時間オーバヘッドの面で望ましくない。
【０００６】
ＴＤＭＡ無線パケット・データ・システム及び有線モデム・アクセス・プロトコル上のセッション内で連続的ＴＣＰコネクションを用いるセッション又はアプリケーション・プロトコルを用いて、ワールドワイド・ウェブ（ＷＷＷ）にアクセスするのに問題が存在する。これは、グローバル・パケット無線システム（ＧＰＲＳ）上でのハイパー・テキスト転送プロトコル（ＨＴＴＰ）の使用を参照して以降に説明される。ブラウザがＨＴＴＰ要求を送るとき、その要求はＳＹＮ信号として送信される。しかしながら、ＳＹＮ信号がＧＰＲＳ上に送られるたびに、ネットワークに、そしてそれにより遠隔のＷＷＷサーバに接続して、要求したウェブ・ページのダウンロードを促進にするため利用される移動局（ＭＳ）によりなされるランダム・アクセスの試みがある。
【０００７】
ランダム・アクセスの試みが生じると直ぐに、ＭＳは、そのＭＳが送るべきデータを有するというメッセージをネットワークに送受信機基地局（ＢＳ）を介して送る。ＭＳは、ネットワークがデータを送り得るという信号をネットワークから受信するとき、ＭＳは、そのデータを送るべき将来の時間のある一定数のパケットを割り当てられる。しかしながら、ネットワークに対して同時に２つの要求が行われた場合、アクセスの試みの衝突が起こり得る。この場合、ＳＹＮ信号は、ネットワークにより送信されないであろうし、そしてＭＳは、後の時間に更なるランダム・アクセスの試みをしなければならない。これは、ランダム・アクセス競合解決として知られている。
【０００８】
以下に説明されるように、存在する問題は、全てのＴＣＰ／ＩＰセッションに対して無線リンク制御（ＲＬＣ）リンクを確立する必要性があることである。無線リンク制御は、ＭＳとネットワークとの間での情報のブロックの転送を制御するプロトコルである。それは、順序付けられた配信及び誤り訂正を実行する。別個の無線リンクを確立する必要性が、ウェブ・ページ及びその中に含まれるイメージをダウンロードする際にユーザが経験する遅延を実質的に増大する。現在の形式のＲＬＣプロトコルがカウントダウン手順を用いてリンクを閉めることを要求するならば、遅延は更に強められる。そのような手順は、送るべきブロックの残りの数をプリセット数からゼロにカウントダウンすることから成る。リンクのシャットダウンはゼロと同時に生じる。
【０００９】
ウェブ・ページのダウンロード中に生じる遅延は、図２を参照することにより最も良く分かり、その図２は、ＳＹＮメッセージのクライアントからサーバへの及びサーバからクライアントへの送信に関係するメッセージ交換を図示するはしご型の図を示す。次の一般的仮定は、そのはしご型の図の構成においてなされた。これらの仮定は純粋に例示的であることが強調されるべきである。
【００１０】
１． 主要時間遅延は、例えば、大西洋横断コネクションを行うときの衛星遅延のような、一時的ブロック・フロー（ｔｅｍｐｏｒａｒｙ ｂｌｏｃｋ ｆｌｏｗ）（ＴＢＦ）の確立及び広域ネットワーク（ＷＡＮ）及びデータ転送時間のせいである。
２． アップリンクＴＢＦの生成のための時間オーバヘッドは、ダウンリンクＴＢＦがアクティブである間におけるアップリンクＴＢＦの生成のための時間オーバヘッドより大きい。
３． ダウンリンクＴＢＦの確立は、アップリンクＴＢＦの確立のための時間オーバヘッドより小さい時間オーバヘッドを持つ。
４． データ転送は、１０％の関連したブロック誤り率（ＢＬＲ）を持つ。
５． データ転送に対するＲＬＣラウンドトリップ遅延は１０個のＲＬＣブロックである。
６． データは、最低のコード・レート（ｃｏｄｅ ｒａｔｅ）（最高スループット）で転送される。
【００１１】
これらの仮定内で用いられる専門用語は、図２に関連した以下の記載に照らしてみればより明瞭になるであろう。
図２において見られ得るように、ＧＰＲＳ上のウェブ・ブラウザと遠隔のサーバとの間のコネクションは、通信リンクを生成するのを可能にするため、互いに相互作用している様々な制御の層（レイヤ）に関係する。ブラウザは、伝送制御プロトコル（ＴＣＰ）層を介して通信し、その伝送制御プロトコル（ＴＣＰ）層は論理リンク制御（ＬＬＣ）層と通信し、その論理リンク制御（ＬＬＣ）層は移動局無線リンク制御（ＲＬＣ−ＭＳ）層と通信する。これから、メッセージは、ＭＳからＢＳへそれらの間に形成された無線リンクをこえて同報通信される。基地局無線リンク制御（ＲＬＣ−ＢＳ）レベルで受信されたメッセージは、論理リンク制御／伝送制御プロトコル（ＬＬＣ／ＴＣＰ）層へ通信され、そしてその層の上で遠隔サーバのＴＣＰ層へ通信される。勿論、これは反対方向にも動作する。
【００１２】
再び図２を参照すると、ブラウザはＨＴＴＰ要求２を送り、そのＨＴＴＰ要求２はＴＣＰ層によりＳＹＮ信号４として送られる。この信号は、セット同期均衡モード（ＳＡＢＭ）信号６としてＬＬＣ層によりＲＬＣ−ＭＳ層へ送られる。この段階で、アップリンクＴＢＦ１０、即ちＲＬＣブロックに関して情報の転送のためのＭＳとＢＳとの間のコネクションが確立される。
【００１３】
アップリンクの確立後に、ＴＣＰ信号は、ＲＬＣ−ＢＳ層からＬＬＣ／ＴＣＰ層へコネクション指示（Ｃｏｎｎ−ｉｎｄ）信号１２として渡される。肯定応答信号１４が、この層からＬＬＣ層へ送り返され、ＬＬＣ層は次いで、ＴＣＰ情報及びＳＹＮ信号を備える情報フレーム１６をＬＬＣ／ＴＣＰ層に送り返す。次の段階は、ＳＹＮ信号１８をＬＬＣ／ＴＣＰ層からＴＣＰ遠隔サーバへの送信を伴う。従って、これは、ＳＹＮ信号２０を送り返し、そのＳＹＮ信号２０は、ＳＡＢＭ信号２２としてＲＬＣ−ＢＳへ送信される。
【００１４】
ここで、ＲＬＣブロックのＢＳからＭＳへの送信のためのダウンリンクＴＢＦコネクションが確立される。このステップは全体的に参照番号２４として示されている。ダウンリンクの確立後に、コネクション指示（Ｃｏｎｎ−ｉｎｄ）信号２６は、ＬＬＣ層へ送られる。これは、ＭＳとＢＳとの間のエア・インターフェースを介してＬＬＣ／ＴＣＰ層へ渡る肯定応答信号２８により確認する。それらから、情報フレームは、無線リンクを介してそしてブラウザＴＣＰ層へ送られる。
【００１５】
ここで、ダウンリンクＴＢＦが、関連の予約されたブロック期間（ＲＲＢＰ）を用いてポーリングした後に閉じられると仮定する。ＢＳは、ＲＲＢＰセットを有するメッセージを送り得て、それによりＭＳは、ある一定数のＲＬＣブロック内においてＲＬＣレベルで肯定応答信号を用いて応答しなければならない。ＲＲＢＰは、ダウンリンクがそのような肯定応答に対して開いたままであることを要求しない場合、ダウンリンクが閉じられるであろう。
【００１６】
これら２つの信号、即ち、図１に示されている最初の２つは、渡されるために特定の時間（τ）を要したことが明らかに分かる。そのようなコネクションが、いずれの１つのウェブ・ページのダウンロード操作においてある一定回数行われなければならない。従って、ＧＰＲＳ上でＨＴＴＰを用いてウェブ・ページをダウンローディングするための要件が非常に高い場合がある点で問題が存在する。上記で述べた問題は、時間期間に関して例証されるときもっと重大となる。イメージを含まない単一のウェブ・ページのダウンロードに対して、３つのコネクション及び解体シークエンスを実行しなければならない。そのデータを確立するためのシークエンスが要求され、サーバに何のデータかを知らせるためそしてそのデータを受信するためのシークエンスが要求され、そして肯定応答するため最後のシークエンスが要求される。これは、明らかに、ダウンロードされるべき全てのイメージに対する更なるコネクション及び解体シークエンスの持続時間により増大するであろう。従って、解決を必要とする問題は、ＴＤＭＡ無線パケット・データ・システム又は有線モデム・アクセス・プロトコル上のセッション内で連続的ＴＣＰコネクションを用いるセッション又はアプリケーション・プロトコルを用いて、ウェブ・ページをダウンローディングするための時間要件を低減し、こうして効率及びユーザの満足を増大する仕方である。
【００１７】
［発明が解決しようとする課題］
本発明は、上記の欠点の幾らか又は全てに対処することを意図している。
［課題を解決するための手段］
本発明は、特許請求の範囲に記載されているように、時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム又は有線モデム・アクセス・プロトコル上のセッション内で連続的伝送制御プロトコル（ＴＣＰ）コネクションを用いるセッション又はアプリケーション・プロトコルを増強する方法において、一時的ブロック・フロー（ＴＢＦ）が連鎖化される方法を提供する。本発明はまた、時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム又は有線モデム・アクセス・プロトコルにおいて、ウェブ・ページのダウンロード時間の低減のための方法及びランダム・アクセス競合の低減のための方法、及び全てＴＢＦ連鎖化を利用する時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム又は有線モデム・アクセス・プロトコルを提供する。
【００１８】
本発明の好適な実施形態に従って、存在するダウンリンクＴＢＦがランデブー・ポイントをネットワークから要求するため利用される方法が提供される。
本発明の別の局面において、存在するアップリンクが、その閉鎖の前にランデブー・ポイントをネットワークから要求するため利用される方法が提供される。
【００１９】
本発明の別の局面において、ネットワークがダウンリンクＴＢＦを常にアクティブに維持する方法が提供される。
本発明の異なる局面は、別々に、又は任意の組み合わせで利用され得る。それらはまた、ウェブ・ページ全体をダウンロードするため要求されるＴＣＰセッション数を決定するステップと、それにより残っている数の要求されたＴＢＦに関連する情報をネットワークに送信するステップとを利用し得る。
【００２０】
本発明の追加の特有の利点は、図面の以下の説明から明らかである。
［発明の実施の形態］
本発明がここで、上記で詳述した添付図面を参照して説明される。
【００２１】
本発明は、たとえ何のデータも転送されていないときでもＴＢＦがある方法でアクティブのままである場合、ＭＳとネットワークとの間で各通信のためのスタンドアローンのＴＢＦ確立が要求されないであろうということに基づいて動作する。これは、ＴＢＦ連鎖化と呼ばれる。
【００２２】
図３から分かり得るように、一旦アップリンクＴＢＦがクライアントとサーバとのＲＬＣ−ＭＳとＲＬＣ−ＢＳとの間で確立されてしまう（３０２、３０４、３０６）と、ＨＴＭＬ要求が送られ得て（３０８）、それは、データ及び終了信号３１０、３１２がサーバからクライアントへ戻すよう渡されることをもたらす。この段階で、アップリンクＴＢＦはアクティブのままである。従って、その後送信３１８が、ＲＬＣ／ＭＡＣチャネル資源割当て手続き後に起こることが可能である。アップリンクＴＢＦコネクションに関連の時間オーバヘッドを有するそのアップリンクＴＢＦコネクションを生成する必要がない。この結果は、図４から図９を参照して以下に説明される多くの異なる方法で達成される。
【００２３】
図４は、ダウンリンクＴＢＦを用いてランデブー・ポイント（ｒｅｎｄｅｚｖｏｕｓ ｐｏｉｎｔ）をアップリンクＴＢＦから要求するとき、ＭＳとＢＳとの間に渡されるメッセージを示す。図４は、ＭＳとＢＳとの間で渡されるメッセージを示すはしご型の図の抜粋を表す。ＢＳからＭＳへ渡される第１の信号４０２、即ちＬＬＣレベル信号は、ＢＳからＭＳへの確立されたダウンリンクを通して送られる最後の通信を表す。この信号の受け取り後で且つダウンリンクの閉鎖の前に、ＭＳは、ランデブーの要求、即ちＲＬＣレベル信号を送る。換言すると、ＭＳは、そのＭＳが何かをＴＣＰ／ＨＴＴＰ条件に基づいて送信するのを希望することを示すメッセージを、ダウンリンクの閉鎖の前にそのダウンリンクを介して送り返す。実際上、ＲＲＢＰがポーリングされるとき（図２を参照）、ＭＳはメッセージを、資源を要求しているＢＳへ送る。ＭＳは、最小数のＲＬＣブロックの満了前にそのＭＳがデータを送信する準備ができていないであろうその最小数のＲＬＣブロックの詳細を与える。これに応答して、ＢＳは、この目的のため競合から自由である資源を割り当てる。この資源は、ＭＳの使用のためにのみ割り当てられた時間のブロックから成る。そのブロックは、要求後にある一定数のＲＬＣブロックを割り当てられ、それはランデブー・ポイントと名付けられる。
【００２４】
ＭＳの使用のため割り当てられたブロックは、ＭＳがＢＳにそのＭＳが送信すべきいずれかのもっと多くのデータを有するかどうかを知らせるのを可能にする。従って、ＭＳは、このブロックを用いて、サーバからクライアントへ転送されるべきデータのための必要な資源を要求するか、又はＭＳが送信すべきものを更に何も持っていないことを指示するか、又は更なるランデブー・ポイントを要求するかのいずれかを行い得る。
【００２５】
この手順は、アップリンクＴＢＦを生成する時間を、アップリンクＴＢＦ確立時間（スタンドアローン）から、ダウンリンクＴＢＦを介してアップリンクＴＢＦを生成するに要する時間まで低減する。しかしながら、ランデブー・ポイントに到達したときＭＳは送信すべき更なるものを何も持たず、従って割り当てられたＲＬＣブロックを用いない場合、割り当てられたＲＬＣブロックの帯域幅が空費されることに注目すべきである。その上、生じているランダム・アクセス競合数は、アップリンク要求のための資源が既に割り当てられてしまっているので、低減される。
【００２６】
ランデブー・ポイントが要求されている時間は、ＭＳが保持する時間及びデータを用いて計算される。ＭＳは、各ウェブ又はインターネット・プロトコル（ＩＰ）アドレス当たり（又は、循環記憶領域における限定数のアドレスに対して、）１つのタイミング記録を保持する。ＭＳはまた、現在サービス状態にあるネットワークに対して無線リンク制御／メディア・アクセス制御（ＲＬＣ／ＭＡＣ）レベル（前には唯ＲＬＣと呼ばれた。）でタイミング記録を保持する。各ＩＰアドレスに対して、測定中に用いられるＲＬＣ／ＭＡＣネットワーク・インターフェースが格納される。そのような記録を保持するため、ＭＳは、次の複数のタイミングが要求された時に、関係した様々なプロトコルにより何が割り当てられるかに従って、次の複数のタイミングを測定する。ＭＳは、測定値を保持するための任意の方法を用い得る。そのような方法は、ある一定数の前の測定値を平均化すること、又は単純に最後の測定値を用いることを含み得る。
【００２７】
１． スタンドアローンのアップリンク確立時間： これは、ＲＬＣ／ＭＡＣアップリンクＴＢＦ確立時間であり、そして最初のランダム・アクセスの試みと「パケット割当て」メッセージ（データをアップリンク上で送信するための資源の割当てを指示するメッセージ）の受け取りとの間の時間である。
２． スタンドアローンのダウンリンク確立時間： これは、「パケット・ダウンリンク割当て」メッセージの受け取りと最初の有効なＲＬＣブロックの受け取りとの間の時間である。
３． ダウンリンクＴＢＦが依然アクティブである間のアップリンクＴＢＦ確立時間
４． アップリンクＴＢＦがアクティブのままである間のダウンリンクＴＢＦ確立時間
５． ＴＣＰラウンドトリップ時間： これは、ＴＣＰメッセージがクライアント又はＭＳのＴＣＰ層から、サーバ（遠隔やその他）のＴＣＰ層へ及びＭＳへ戻すように送信される時間である。
【００２８】
上記のパラメータに加えて、ＭＳはまた、ランデブー・ポイント位置のための所望の時間を決定するとき、アップリンク及びダウンリンク・データ速度及びそれらのそれぞれのブロック誤り率を考慮する。
【００２９】
図５は、図４の実施形態のＭＳがランデブー・ポイントを要求する仕方を図示する。機能ボックス５０２において、ＭＳは、もっと多くのデータを送るのを、また残りのデータの大きさを必要とするか否かを決定する。これは、ＨＴＴＰ及び／又はＴＣＰの条件から決定される。これは、ダウンリンクＴＢＦがアクティブであるいずれの時間に生じる可能性がある。
【００３０】
機能ボックス５０４において、ＭＳは、現在送られているダウンリンクＴＣＰメッセージの大きさを知るまで待つ。次いで、ＭＳは、ダウンリンクデータ速度及びブロック誤り率を考慮して、それが完全なダウンリンク・メッセージを受信してしまう筈である時刻を計算する。その計算はまた、クライアント／サーバ・インターフェース内で様々なレベルの制御で処理されることが必要であるメッセージを考慮する。
【００３１】
機能ボックス５０６は、資源要求の送信ステップを詳述する。ここで、ＭＳは、機能ボックス５０４で決定された時刻に等しいランデブー・ポイントでアップリンクの１個のＲＬＣブロックの要求を送信する。ＴＣＰラウンドトリップ時間は、ランデブー・ポイントを早すぎる時刻に対して要求されることから防止するためのベンチマークとして用いられる。要求されたポイントがＴＣＰラウンドトリップ時間より早い時間に当たる場合、ネットワークは、送るべきものが何もない前に資源を確立する準備ができることになろう。同様に、ランデブー・ポイントがＲＬＣアップリンクＴＢＦ確立時間よりはるかに長い場合か、又はアップリンクＴＢＦがアクティブである場合、要求は送られない。ネットワークは、資源の要求を許可、遅延又は拒否する権利を確保しておく。
【００３２】
機能ボックス５０８は、ＭＳにより行われる判断を示す。ランデブー要求と割り当てられたブロックとの間のその一定数のブロックの後で、ＭＳが送信すべきもっと多くのデータを有する場合、そのデータは、機能ボックス５１０に詳述されるように、ＢＳに送信される。しかしながら、ＭＳが送信すべき更なるデータを有しない場合、ＭＳは、ランデブー要求が割り当てられたか否かを決定する（機能ボックス５１２）。これは、ＭＳが連続的に同報通信される、ネットワークのシステム情報メッセージを聴くことにより行われる。ネットワークは、１ビットをこれらのメッセージ内にセットして、ランデブー要求が受け入れられるか否かを指示する。ＭＳは、呼出しを行う前にこの情報を聴くであろう。
【００３３】
ランデブー要求が受け入れられる場合、ランデブー要求再試行が許可された否かを確立する（機能ボックス５１４）。この情報は、ランデブー要求が受け入れられた否かに関して詳述したのと同じ方法で入手可能である。
【００３４】
両方の要求及び再試行が受け入れられる場合、機能ボックス５０２に戻る。しかしながら、これらの要求のいずれか、又は両方がネットワークにより受け入れられない場合、ＭＳとネットワークとの間の通信は終わる（機能ボックス５１６）。
【００３５】
ＴＢＦを連鎖する第２の方法が図６に示されている。この方法では、ＭＳは、次のアップリンクＴＢＦのためランデブー・ポイントを要求する際にＲＬＣレベルのカウントダウン手順を利用する。
【００３６】
機能ボックス６０２はＲＬＣカウントダウンを指示する。ＲＬＣプロトコルは、ＭＳが送るべきデータのより少数のブロックを持つことを開始するので、ＭＳはネットワークに知らせなければならないことを要求する。そのように、送信されるため残っているプリセット数のブロックからゼロへのカウントダウンが実行される。これにより、ネットワークに、どのくらいのデータが残っているか、及び送信を完了するであろう時を知らせることが可能になる。カウントがゼロに達するとき、データの終わりにまた達する。この実施形態において、ＭＳはカウントダウンを平行処理し（ｐａｒａｌｅｌｌ）、そしてカウントダウンがゼロに等しくなる（機能ボックス６０４）とき、ＭＳは、割り当てられるべき単一の資源の要求を送る。ブロックは、データ転送を要求する目的のため、ある将来の時刻に割り当てられることを要求される。そのようにして、ＭＳは、ブロックの割当てのためランデブー・ポイントを指示する。これは、存在しているアップリンクＴＢＦが閉じられると同じ時刻に実行される。カウントダウンがゼロに等しくない間は、ＭＳは、このことに関して何も動作を行わない（機能ボックス６０８）。
【００３７】
この方法は、ブロックが次のアップリンクＴＢＦに対して資源を要求するため既に割り当てられてしまうので、前に説明したような、ランダム・アクセスの試みに固有の競合解決手順を回避する点で有利である。これは、更なるアップリンクＴＢＦ（即ち、最初の又は主たるアップリンク後に確立されたアップリンク）を確立するための時間オーバヘッドを、スタンドアローンのアップリンク確立持続時間から開いているダウンリンクを通してのアップリンク確立の持続時間まで低減する。
【００３８】
図６の実施形態において利用されたランデブー要求手順は、図５の手順と同じパラメータを用いている。しかしながら、ランデブー・ポイントを要求するプロセスは、異なり、図７を参照して説明される。
【００３９】
機能ボックス７０２は、ランデブー・ポイントを要求するプロセスにおける最初のステップを示す。このステップは、現在のＴＣＰラウンドトリップ時間の知識が使用のため使用可能であることを要求する。ＭＳは、記号ＴＥで示される、ランデブー・ポイントを要求する判断が行われる時刻における現在のＴＣＰメッセージの開始から経過した時間を計算する。機能ボックス７０４に詳述されている次のステップは、ＲＬＣカウントダウンがゼロに達したときに起こる。ここで、ＭＳは、ＴＣＰラウンドトリップ時間（Ｔ_TCPR）とステップ７０２で計算された値との差として与えられる将来の時間にランデブー・ポイントを要求する。再び、ネットワークは、受信された要求を許可するか、遅延するか、拒否するかのいずれかを行う権利を確保しておく。機能ボックス７０６は、例えば、ランデブー・ポイントに達したとき肯定応答信号か又は資源の要求かの形式で、送信すべき更なるデータを有するか否かに関してＭＳにより取られた判断を詳述する。ＭＳが更なるデータを有する場合、そのデータは、機能ボックス７０８に示されるように送信される。さもなければ、ランデブー要求が許可されるか否かが決定される（機能ボックス７１０）。これは、ＭＳが連続的に同報通信される、ネットワークのシステム情報メッセージを聴くことにより行われる。ネットワークは、１ビットをこれらのメッセージ内にセットして、ランデブー要求が受け入れられるか否かを指示する。ＭＳは、呼出しを行う前にこの情報を聴くであろう。
【００４０】
ランデブー要求が受け入れられる場合、ランデブー要求再試行が許可されるかどうかが確立される（機能ボックス７１２）。この情報は、ランデブー要求が受け入れられるかどうかに関して詳述したのと同じ方法で入手可能である。
【００４１】
両方の要求及び再試行が受け入れられる場合、機能ボックス７０２に戻る。しかしながら、これらの要求のいずれか又は両方がネットワークにより受け入れられない場合、ＭＳとネットワークとの間の通信は終わる（機能ボックス７１４）。１つ又はそれより多い訂正係数がこの手順内で利用され得ることに注目すべきである。
【００４２】
ネットワークが開いているダウンリンクＴＢＦを全ての時間に保持する、ＴＢＦを連鎖する第３の方法が、図８を参照して説明される。図８から分かり得るように、この方法は、ダウンリンクＴＢＦ（図２の参照番号２４参照）が、ＨＴＴＰ又はＴＣＰ／ＩＰセッション処理が実行されてしまった後にＢＳにより開いたままに保たれることに依拠している。
【００４３】
機能ボックス８０２は、ＢＳが最小数の将来ＲＬＣブロックの、ＭＳからの推定を受信するステップを詳述する。なお、そのステップの前には、ＢＳが更なるデータを送信することができないであろう。この情報は、ＭＳがその情報を、現在のラウンドトリップＴＣＰ遅延が遭遇されていることを詳述する情報と共に送ることができる程頻繁に送られる。
【００４４】
次のステップ８０４は、ＢＳがＭＳを周期的にポーリングして、ＭＳがいずれかのアップリンク資源要求をしたか否かを知ることから成る。要求が行われた場合、アップリンクＴＢＦは、ダウンリンクＴＢＦが開いたままであるので、前に詳述した２つの確立オーバヘッドのうちの小さい方で確立される（８０６、８０８）。要求が行われなかった場合、ＢＳはＭＳを周期的にポーリングするのを継続する。
【００４５】
この方法は、ネットワーク制御手順を与える。ＢＳが特定の時間にネットワーク・トラフィックの高い割合に対処中である場合、ＢＳは資源要求のためＭＳをポーリングしないことを選定し得る。ＢＳは、そのＢＳが次ぎにＭＳをポーリングするであろう時間を遅延させ得る。従って、この方法は、衝突を処理するネットワークにより制御される機構を与える。ランダム・アクセス競合が起こりそうなときＢＳがＭＳのポーリングを単に遅延させるので、ランダム・アクセス競合は回避され得る。従って、競合から自由である資源が与えられる。この方法は、前の方法のように同じ時間節約を提供する。
【００４６】
ＴＢＦの連鎖化に対して補完的である最後の方法が図９に詳述されている。この方法は、上記の３つの連鎖化の方法のいずれとも一緒に用い得る。この方法はＭＳにおいて始まる。ＭＳは、ステップ９０２で、ウェブ・ページをダウロードするため要求されるであろうＴＣＰコネクション／解体シークエンスの数を決定する。既に説明したように、個々のシークエンスは、ダウンロードされるべき各インライン・イメージに対して要求される。このステップはＨＴＴＰページ・パーシングを利用する。
【００４７】
機能ボックス９０４において、ダウンロードを完了するため確立を依然要求しているＴＢＦの数の指示がネットワークに渡される。この指示はカウンタにより作られる。その上、ＭＳは、そのＭＳが将来のＴＢＦにおいてアップリンク上に転送しなければならないかも知れないデータのオクテット（バイト）数を指示することができる。これは、特に、イベントの性質が似ているアップロードで生じる。
【００４８】
上記の方法は全て一緒に用い得て、ＧＰＲＳ上でＨＴＴＰを用いたウェブ・ページのダウロードにおいてＴＢＦ連鎖化を提供する。しかしながら、最も有りそうでそして好適な組み合わせは、図４、図８及び図９の態様、及び図６、図８及び図９の態様である。
【００４９】
しかしながら、上記の方法は、ＧＰＲＳにおいてＨＴＴＰを用いてＴＢＦ確立の時間オーバヘッドを低減するよう働く。例示的ダウンロードのシナリオにおいて、ＴＢＦ連鎖化の使用により達成される利益がここで説明される。４つのイメージを含むページのダウンロードにおいて、５つのＴＣＰコネクションが要求されるであろう。ページに対して１つのコネクションであり、そして各イメージに対して１つのコネクションである。これらのコネクションのそれぞれに対して、最大４つのアップリンクＴＢＦ確立及び最大３つのダウンリンクＴＢＦ確立があろう。従って、そのようなリンクのそれぞれを確立するに要する時間を低減することはダウンロードに対する時間オーバヘッドの全体を著しく低減するであろうことは明らかである。また、ＨＴＴＰが良くなるので、ボトルネックは、コネクション確立及びスロー・スタートに対するＴＣＰラウンドトリップ時間の形式に留まるのみであろう。更に、ＴＢＳを連鎖化することは、最も希望している範囲での顕著な改良を提供する。
【００５０】
ＴＢＦ連鎖化と関連した帯域幅利得もある。クライアントとサーバとの両方における制御レベル間で交換されたメッセージの数（即ちコネクションを確立するため）が低減されるので、接続するため、より少数のＲＬＣブロックしか必要でない。従って、より多くのＲＬＣブロックが、データ転送等のためユーザにとって使用可能である。更に、ランダム・アクセス競合数の低減は衝突の著しい低減をもたらし、それは、前述したように、関連した時間節約となる。
【００５１】
前述の説明は、そのような方法を利用してＧＰＲＳ及びＧＰＲＳシステム上でのＨＴＴＰの使用を改善し、それによりランデブー・ポイントを予測し、そしてＨＴＴＰを利用してＧＰＲＳにおける衝突及び競合解決を回避する方法を提供する。これらの方法は、ＧＰＲＳに関連しながら説明されたが、しかしいずれの時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム及びいずれの有線モデム・アクセス・プロトコルに対して等しく適用される。更に、本発明の方法及びシステムがハイパー・テキスト転送プロトコルを参照して説明されたが、それらは、セッション内の連続的伝送制御プロトコル（ＴＣＰ）コネクションを利用していずれのセッション又はアプリケーション・プロトコルに対して等しく適用される。
【００５２】
本発明が例示によってのみ説明され、詳細な変更が本発明の範囲から逸脱することなく行い得ることが勿論理解されるであろう。
【図面の簡単な説明】
【図１】 図１は、ウェブ・ページのダウンロード中にクライアントとサーバとの間で交換されるメッセージを示す。
【図２】 図２は、ＧＰＲＳ上でＨＴＴＰを用いたスリーウェイ・ハンドシェークにおいて最初の２つの信号中に交換されるメッセージを示す。
【図３】 図３は、クライアントとホストとの間のコネクションが開いたままであるシナリオを図示するはしご型の図を示す。
【図４】 図４は、ランデブー要求を図示するはしご型の図を示す。
【図５】 図５は、図４のランデブーのための時間位置計算を図示するフロー図を示す。
【図６】 図６は、閉じているアップリンクを用いたＴＢＦ連鎖方法を図示するフロー図を示す。
【図７】 図７は、図６のランデブー・ポイントに対する時間位置計算を図示するフロー図を示す。
【図８】 図８は、ダウンリンクが常にアクティブのままであるＴＢＦ連鎖方法を図示するフロー図を示す。
【図９】 図９は、ネットワークに状態情報を知らせる方法を図示するフロー図を示す。

Claims (20)

1. 時分割多元接続（ＴＤＭＡ）無線パケット・データ・システム及び有線モデム・アクセス・プロトコル上のセッション内で連続的伝送制御プロトコル（ＴＣＰ）コネクションを用いるセッション又はアプリケーション・プロトコルを使用してデータをダウンロードする方法において、
   クライアントとネットワークとの間の通信を提供するために一時的ブロック・フロー（ＴＢＦ）を連鎖化するステップと、
   前記クライアントが、既存のＴＢＦを使用して、ランデブー要求後の将来の時間における前記クライアントへの資源の割り当てのために、前記ネットワークからランデブー・ポイントを要求するステップであって、前記ランデブー・ポイントはアップリンクＴＢＦが要求され得るある時点において配置されるよう要求される、ステップと
   を含む方法。
2. 前記セッション又はアプリケーション・プロトコルが、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含み、
   前記ＴＤＭＡ無線パケット・データ・システム及び有線モデム・アクセス・プロトコルが、グローバル・パケット無線システム（ＧＰＲＳ）及び増強型ＧＰＲＳ（ＥＧＰＲＳ）を含む
   請求項１に記載の方法。
3. 前記クライアントが、既存のダウンリンクＴＢＦを利用して、前記ランデブー・ポイントをネットワークから要求するステップを備える請求項１又は２のいずれか一項に記載の方法。
4. 前記のランデブー・ポイントの位置が計算され、前記計算は、
   前記クライアントが、更なるデータを前記ネットワークに送る必要があるか否かを決定し、且つ当該データの大きさを決定するステップと、
   前記クライアントが、現在のダウンリンク信号が完全であるべき時刻を推定するステップと
   を備える、請求項３記載の方法。
5. 前記ランデブー・ポイントがアップリンクの単一の無線リンク制御（ＲＬＣ）ブロックを備える請求項２から４のいずれか一項に記載の方法。
6. 前記ランデブー・ポイントが前記ネットワークにより許可される場合で、前記ランデブー・ポイントが到達されるときで、且つ送信されるべきデータが存在する場合、前記クライアントが、アップリンクのブロックを利用して、アップリンクＴＢＦを要求するステップを更に備える請求項５記載の方法。
7. 前記クライアントが、既存のアップリンクＴＢＦを利用して、前記ランデブー・ポイントを前記ネットワークから要求するステップを備える請求項１又は２のいずれか一項に記載の方法。
8. 前記要求は、データ送信が終わるとき行われる請求項７記載の方法。
9. 前記要求は、ＲＬＣカウンタがゼロに達するとき行われる請求項７又は８記載の方法。
10. 前記ランデブー・ポイントは、次のステップ、即ち
    前記クライアントが、現在のＴＣＰメッセージの送信の時から経過した時間を計算するステップ、及び
    前記クライアントが、前記ランデブー・ポイントを、前記の経過した時間といずれかの要求された訂正係数を考慮したＴＣＰラウンドトリップ時間との差として推定するステップ
    に従って計算される、請求項７から９のいずれか一項に記載の方法。
11. 前記ランデブー・ポイントがアップリンクの単一のＲＬＣブロックを備える請求項７から１０のいずれか一項に記載の方法。
12. 前記ランデブー・ポイントが前記ネットワークにより許可される場合で、前記ランデブー・ポイントが到達されるときで、且つ送信されるべきデータが存在する場合、前記クライアントが、アップリンクのブロックを利用して、アップリンクＴＢＦを要求するステップを更に備える請求項１１記載の方法。
13. 前記ランデブー・ポイントが前記ネットワークにより拒否される場合、前記クライアントが、ランデブー要求が前記ネットワークにより受け入れられるか否かを決定するステップと、
    ランデブー要求が前記ネットワークにより受け入れられる場合、前記クライアントが、再要求が前記ネットワークにより受け入れられるか否かを決定するステップと、
    再要求が許可される場合、前記のランデブー要求手順を繰り返すステップと
    を更に備える請求項６から１２のいずれか一項に記載の方法。
14. 前記ネットワークがダウンリンクＴＢＦをアクティブ状態に維持するステップを備える請求項１から１３のいずれか一項に記載の方法。
15. 前記ネットワークにおいて、最小数のＲＬＣブロックの前に前記クライアントが送信すべきものを持たない前記最小数のＲＬＣブロックの、前記クライアントからの推定を受信するステップと、
    前記ネットワークが、アップリンク資源要求のため前記クライアントをポーリングするステップと
    を更に備える請求項１４記載の方法。
16. 資源要求が識別される場合、前記ネットワークが、アップリンクＴＢＦを前記クライアントと前記ネットワークとの間で開くステップを備える請求項１５記載の方法。
17. ランデブー・ポイントの要求が行われるネットワークが、前記要求を受け入れ、拒否、又は遅延させ得る請求項１から１６のいずれか一項に記載の方法。
18. 前記クライアントが、ウェブ・ページをダウンロードするため要求されるＴＣＰセッション数を決定するステップと、
    前記クライアントが、残っている要求されたＴＢＦの指示をネットワークに送信するステップと
    を更に備える請求項１から１７のいずれか一項に記載の方法。
19. 前記クライアントが、将来のＴＢＦにおいてアップロードされるべきデータの大きさの推定を前記ネットワークに送信するステップを更に備える請求項１８記載の方法。
20. クライアントとネットワークとの間の通信を提供するために一時的ブロック・フロー（ＴＢＦ）が連鎖化されるＴＤＭＡ無線パケット・データ・システムであって、
    既存のＴＢＦを使用して、ランデブー要求後の将来の時間における前記クライアントへの資源の割り当てのために、前記ネットワークからランデブー・ポイントを要求するクライアントを備え、前記ランデブー・ポイントはアップリンクＴＢＦが要求され得るある時点において配置されるよう要求される、ＴＤＭＡ無線パケット・データ・システム。

Images