(57)【要約】【課題】ネットワーク・プロトコルスタックを最適化する。【解決手段】このモジュールは、ネットワーク・プロトコルスタック(308)とこのネットワーク・プロトコルスタック(308)を利用するアプリケーション(306)に対してトランスペアレントである。このモジュールは、セッション・デテクタ(402)および補助マネージャ(410)を含む。更に、このモジュールは、リクエスト・インターセプタ(404)、リクエスト・アナライザ(406)およびコントローラ(408)を含んでもよい。セッション・デテクタ(402)は、ホストからリモートホストへ送信されるオリジナル・セッションを検出する。補助セッション・マネージャ(410)は、オリジナル・セッションをサポートする複数の補助セッションをオープンして管理する。リクエスト・インターセプタ(404)は、アプリケーション発行のオリジナル・リクエストを検出する。【選択図】図１
2010504688.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク・プロトコルスタックの品質最適化およびハンドオフを実装するためのモジュールであって、
ホストからリモートホストへ送信されるオリジナル・セッションを検出するためのセッション・デテクタと、
オリジナル・セッションをサポートするために、複数の補助セッションをオープンし管理する補助セッション・マネージャとを備え、
ネットワーク・プロトコルスタックとこのネットワーク・プロトコルスタックを利用するアプリケーションに対してトランスペアレントであるモジュール。
【請求項２】
前記補助セッション・マネージャは、オリジナル・セッションのオープンの検出に応答して、補助セッションをオープンする請求項１に記載のモジュール。
【請求項３】
コンテンツを取得するためにアプリケーションによって発行されたオリジナル・リクエストを検出するリクエスト・インターセプタと、
インターセプトされたオリジナル・リクエストを分析するために設けられたリクエスト・アナライザと、
オリジナル・セッションと補助セッションを利用し、前記分析結果に基づいて、コンテンツを取得するリクエスト・コントローラと
を更に備えた請求項１に記載のモジュール。
【請求項４】
前記リクエスト・コントローラは、少なくとも一つの補助リクエストを生成し、補助リクエストの各々が、補助セッションの１つを介して、コンテンツの１つの分割片を取得する請求項３に記載のモジュール。
【請求項５】
前記リクエスト・コントローラは、オリジナル・セッションを介してコンテンツの一部だけを要求するように、オリジナル・リクエストのアプリケーション層ヘッダを修正する請求項４に記載のモジュール。
【請求項６】
修正されたオリジナル・リクエストおよび補助リクエストに応答して受信した分割片に基づいて、コンテンツを組み立てるレスポンス・マネージャを更に備える請求項５に記載のモジュール。
【請求項７】
夫々の分割片がコンテンツのどの位置を占めるかに関する情報を保持する記憶装置を更に備え、
前記レスポンス・マネージャは、夫々の分割片を用いてコンテンツを組み立てるにあたって、この位置情報を利用する請求項６に記載のモジュール。
【請求項８】
前記ネットワーク・プロトコルスタックは、TCP/IPスタックである請求項１に記載のモジュール。
【請求項９】
前記モジュールは、前記TCP/IPスタックのトランスポート層とアプリケーション層との間に位置し、オリジナル・セッションおよび補助セッションは、TCP/IPセッションである請求項８に記載のモジュール。
【請求項１０】
前記オリジナル・セッションは、第１のネットワークを介して確立され、前記補助セッション・マネージャは、ホストが第２のネットワークに接続する際に、これに応じて補助セッションをオープンさせ、前記モジュールは、更に
前記オリジナル・セッションを介してコンテンツを取得するためにアプリケーションによって発行されたオリジナル・リクエストを検出するリクエスト・インターセプタと、
インターセプトされたオリジナル・リクエストを分析するために設けられたリクエスト・アナライザと、
補助セッションを介してコンテンツの継続的な取得を行うように設計されたリクエスト・コントローラを更に備えた請求項１に記載のモジュール。
【請求項１１】
オリジナル・セッションと補助セッションを介して重複してバイトを受信した場合、レスポンス・マネージャは、後に受信したバイトを破棄する請求項１０に記載のモジュール。
【請求項１２】
ネットワーク・プロトコルスタックの品質最適化を実装するための方法であって、
オリジナル・セッションを検出し、
オリジナル・セッションをサポートするために、複数の補助セッションをオープンし、
オリジナル・セッションと補助セッションを利用して、ネットワーク・プロトコルスタックによってアプリケーションが発行したオリジナル・リクエストを実行し、
前記方法は、前記アプリケーションとネットワーク・プロトコルスタックに対してトランスペアレントである方法。
【請求項１３】
補助セッションは、オリジナル・セッションのオープンの検出に応答して、オープンされる請求項１２に記載の方法。
【請求項１４】
前記オリジナル・リクエストは、コンテンツを取得するために発行され、前記利用する処理では、
前記オリジナル・リクエストをインターセプトし、
前記コンテンツを組み合わせてカバーする少なくとも一つの分割片を決定し、
オリジナル・セッションおよび補助セッションを介してコンテンツの分割片を取得し、
前記分割片をマージしてコンテンツの組み立てを行い、
前記アプリケーションにコンテンツを提供する請求項１２に記載の方法。
【請求項１５】
前記取得する処理では、
オリジナル・リクエストに基づいて各々前記分割片の１つを要求する少なくとも１つリクエストを生成し、
前記オリジナル・セッションおよび補助セッションを介して、前記生成されたリクエストを送信し、
前記オリジナル・セッションおよび補助セッションを介して、前記コンテンツの分割片を受信する請求項１４に記載の方法。
【請求項１６】
前記決定する処理では、夫々の分割片がコンテンツのどの位置を占めるかに関する情報を保持し、
前記マージ処理では、前記保持された位置情報を取得し、前記保持された位置情報に基づいて前記分割片をマージする請求項１４に記載の方法。
【請求項１７】
前記生成する処理では、オリジナル・リクエストの所定のパケットのペイロードを修正し、
前記マージ処理では、
前記補助セッションで受信したパケットが、アプリケーションに配信されなかったコンテンツの分割片を含むか否かを決定し、
もし、前記受信パケットが、アプリケーションに配信されなかったコンテンツの分割片を含む場合には、前記受信パケットの送信元アドポート・フィールド、宛て先アドポート・フィールド、シーケンス番号フィールドおよび／または確認応答数値フィールドの値を修正し、
前記受信パケットが、送信終了パケットであるか否かを決定し、
もし、前記受信パケットが送信終了パケットであれば、この受信パケットがコンテンツの末尾の受信を示しているか否かを決定し、
もし、前記受信パケットがコンテンツの末尾の受信を示している場合には、オリジナル・セッションで送信完了状態となるまで、前記受信パケットの配信を待つ請求項１５に記載の方法。
【請求項１８】
前記ネットワーク・プロトコルスタックは、TCP/IPスタックである請求項１２に記載の方法。
【請求項１９】
前記方法は、前記TCP/IPスタックのトランスポート層とアプリケーション層との間で実行され、オリジナル・セッションおよび補助セッションは、ＴＣＰ／ＩＰセッションである請求項１８に記載の方法。
【請求項２０】
ネットワーク・プロトコルスタックのハンドオフを実装するための方法であって、
前記ネットワーク・プロトコルスタックを用いるアプリケーションによって第１のネットワークを介して確立されたオリジナル・セッションを検出し、
第２のネットワークの上の補助セッションをオープンして、オリジナル・セッションをサポートし、
オリジナル・セッションの切断を行い、
前記方法は、前記アプリケーションとネットワーク・プロトコルスタックに対してトランスペアレントである方法。
【請求項２１】
第２のネットワークに接続する際に、これに応じて補助セッションがオープンされ、前記方法では、更に
コンテンツを取得するためのオリジナル・リクエストを検出し、
オリジナル・セッションを介してコンテンツの取得を開始し、
補助セッションを介してコンテンツの継続的な取得を実行する請求項２０に記載の方法。
【請求項２２】
前記実行する処理では、
コンテンツの取得を続けるための補助リクエストを作成し、
前記補助セッションを介して前記補助リクエストを送信し、
前記補助セッションによるコンテンツの取得を継続し、
ある１バイトが、オリジナル・セッションおよび補助セッションを介して、重複して受信した場合、後に受信した１バイトを廃棄する請求項２１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、主にネットワーク・プロトコルスタックを最適化するための方法およびモジュールに関し、特に、ネットワーク・プロトコルスタックのハンドオフおよび／または品質最適化を実装するためのトランスペアレントで片側実装可能な方法およびモジュールに関する。
【背景技術】
【０００２】
大部分のネットワークプロトコル・セットは一連の階層（レイヤー）として構築される。そして、それらの階層は、しばしばプロトコルスタックと呼ばれる。この点に関して、ＯＳＩ（Open Systems Interconnect）参照モデルでは、７つの階層による構造として、ネットワークの動作を記述している。ここで、各々の階層は、一つ以上のプロトコルに関連付けられる。図１に示すように、ＯＳＩ参照モデルのプロトコル階層は、最上位（階層７）から、最下位（階層１）まで規定されている。
【０００３】
ＯＳＩ参照モデルにより定義される動作は、純粋に概念的であり、いかなる特定のネットワークプロトコル・セットにも、的を絞ったものではない。例えば、ＯＳＩネットワークプロトコル・セットは、ＯＳＩ参照モデルの全ての７つの階層を実装するものである。これに対して、インターネット環境において、最も普通に用いられるネットワークプロトコル・セットの一つであるTCP/IPは、ＯＳＩ参照モデルに直接対応するものではなく、いくつかのＯＳＩ階層を合わせて単一階層としている。図２には、最上位の階層（アプリケーション層）から、最下位の階層（物理ネットワーク層）まで、TCP/IP実装の階層が示されている。図２は、TCP/IPのプロトコルスタックの階層と、対応するＯＳＩモデルの階層と、これら各々のレベルで利用可能なプロトコルの例を示している。
【０００４】
TCP/IPのプロトコルスタックの階層の中で、ネットワーク物理層は、ネットワークで使用されるハードウェアの特性を規定する。例えば、この階層では、通信メディアの物理的特性を特定する。データリンク層は、パケットのネットワークプロトコル・タイプを特定する。また、データリンク層では、エラー制御と「フレーミング」が行われる。インターネット層は、ネットワーク層とも呼ばれ、ネットワークのパケットを受理し配送する階層である。更に、トランスポート層プロトコルは、伝送制御プロトコル（TCP）を含んでおり、データ受信の確認を行い、失われたパケットを再送信することによって、パケットをエラーなく順に送信することを確実とするものである。TCPは、アプリケーション同士があたかも物理的な回路で互いに接続されているかのように、通信することを可能とする。
【０００５】
アプリケーション層は、標準的なインターネット・サービスと、ネットワーク・アプリケーションを定義する。これらのサービスは、データを送受信するためにトランスポート層で動作する。アプリケーション層のプロトコルの例としては、HTTP（HyperText Transfer Protocol）、FTP（File Transfer Protocol）、TelnetおよびNFS（Network File System）等がある。大部分のアプリケーション層のプロトコルは、リモートホストに対するセッションを管理する。コマンドおよびデータは、セッションを介して送信される。例えば、ホストがHTTPリクエストを発行して、リモートホストにおいて特定のコンテンツを取得する場合、HTTPリクエストはホストのアプリケーション層から、ホストとリモートホスト間で確立されたセッションを介して、リモートホストのアプリケーション層へ送信される。さらに、このHTTPリクエストに応答して、リモートホストは同じセッションを介して、要求されたコンテンツを、HTTPレスポンスとしてホストへ送信する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来のネットワークプロトコル・セットの各々の階層では、１つのマシンの特定の階層で送受信されるオブジェクトと、別のマシンの対応する階層で送受信されるオブジェクトとは、正確に同じ（すなわち一対一対応）となるように設計される。しかしながら、この一対一対応は、ネットワーク・バンド幅とリモートホストの処理リソースを目一杯に利用しようとする場合の妨げとなる。
【０００７】
TCP/IPプロトコル・セットは、無線ネットワーク環境において、いよいよ一般的になってきている。無線ネットワーク環境においては、ホストが１つのネットワークから別のネットワークへ移動できるので、高品質のサービスを提供するシームレスで且つ費用対効果の高いハンドオフ実現への要求が強い。しかしながら、上記の通り、従来のネットワークプロトコル・セットは、一対一に対応するセッションを採用しているため、このようなシームレスで費用対効果の高いハンドオフを提供することは非常に困難となっている。
【０００８】
更に、従来のクライアント・アプリケーションおよびサーバー・プログラムは、従来のTCP/IPプロトコル・セットに基づいて設計されている。したがって、従来のクライアント・アプリケーションおよびサーバー・プログラムの使用を続けるためには、上記の不都合に対する解決手段としては、トランスペアレントであり且つ片側実装可能でなければならない。ここで、本願明細書において用いる「トランスペアレント」という用語は、通信ホストにおいて、既存のアプリケーション、ネットワーク・プロトコルスタックおよびソケット実装に対しても、また新しいサーバやその他のインフラストラクチャーに対しても、何らの修正を要しないということを意味する。また、「片側実装可能」という用語は、その解決手段が、セッションにおいて使用されている通信ホストの一方のみで実装されていれば良いことを意味する。
【０００９】
したがって、本発明の目的は、サービス品質（QoS）の改善とネットワーク間で行われるセッションのハンドオフを実現する、トランスペアレントで片側実装可能な方法を提供することである。本発明の別の目的は、サービス品質（QoS）の改善とネットワーク間で行われるセッションのハンドオフを実現可能なトランスペアレントで片側実装可能なモジュールを提供することである。
【課題を解決するための手段】
【００１０】
本発明の一つの様相では、ネットワーク・プロトコルスタックのためのハンドオフおよび／または品質最適化を実装するためのモジュールが提供される。このモジュールは、ネットワーク・プロトコルスタックとこのネットワーク・プロトコルスタックを利用するアプリケーションに対してトランスペアレントである。このモジュールは、セッション・デテクタおよび補助セッション・マネージャを含む。セッション・デテクタは、ホストからリモートホストへ送信されるオリジナル・セッションを検出し、補助セッション・マネージャは、オリジナル・セッションをサポートする複数の補助セッションをオープンして管理する。また、このモジュールは、リクエスト・インターセプタ、リクエスト・アナライザおよびリクエスト・コントローラを含む。リクエスト・インターセプタは、アプリケーション発行のオリジナル・リクエストを検出する。このオリジナル・リクエストは、特定のコンテンツを取得するためのものである。リクエスト・アナライザは、インターセプトされたオリジナル・リクエストを解析する。リクエスト・コントローラは、解析の結果に基づき、オリジナル・セッションおよび補助セッションを介してコンテンツを取得する。
【００１１】
本発明の別の様相では、ネットワーク・プロトコルスタックのための品質最適化を実装するための方法が提供される。この方法は、オリジナル・セッションを検出して、このオリジナル・セッションをサポートする複数の補助セッションをオープンする。オリジナル・セッションおよび補助セッションを用いて、ネットワーク・プロトコルスタックを使用しているアプリケーションが発行したオリジナル・リクエストを実行する。ここでの方法は、アプリケーションおよびネットワーク・プロトコルスタックに対してトランスペアレントである。更に、特定のコンテンツを取得するために、オリジナル・リクエストが発行することができる。この場合、オリジナル・セッションおよび補助セッションの利用に関連して、オリジナル・リクエストをインターセプトし、組み合わせてコンテンツをカバーする一つ以上の分割片を決定し、オリジナル・セッションおよび補助セッションを介して、コンテンツの分割片を取得し、分割片をマージして、コンテンツの組み立てを行い、アプリケーションにコンテンツを提供することができる。
【００１２】
本発明の更に別の様相によれば、ネットワーク・プロトコルスタックのためのハンドオフを実装するための方法が提供される。この方法では、ネットワーク・プロトコルスタックを用いるアプリケーションによって第１のネットワークを介して確立されたオリジナル・セッションを検出し、第２のネットワークの上の補助セッションをオープンして、オリジナル・セッションをサポートする。この方法では、更に、オリジナル・セッションの切断が行われる。この方法は、アプリケーションおよびネットワーク・プロトコルスタックに対してトランスペアレントである。ここでは、第２のネットワークに接続する際に、これに応じて補助セッションがオープンされる。また、この方法では、オリジナル・リクエストを検出して、特定のコンテンツを取得される。この場合、この方法では、オリジナル・セッションを介してコンテンツの取得を始め、補助セッションで更にコンテンツの継続的な取得を実行する。
【００１３】
本明細書において、下記の通り、用語の意味を定義する。アドポート（Adport）及びエンドポイント（endpoint）は、インターネット・セッションのエンドポイントを特定するIPアドレスとポート番号の対を意味する。「送信完了状態」は、TCP/IPスタックに配信されたセッションのパケットが、そのセッションで要求されているコンテンツの全てをカバーしている状態を意味する、「送信終了パケット（End-of-transfer packet）」は、TCP/IPセッションの終了に関係するパケット（例えばTCP FINまたはRSTパケット）を意味する、そして、「パケットの累積的確認応答数」とは数ｂであって、そのパケットに属するTCP/IPセッションの間に、数ｂ以前のコンテンツの全てのバイトが受信されていることの保証を意味する。
【図面の簡単な説明】
【００１４】
本発明の上記および他の目的や機能は、添付の図面と共に以下の好適な実施例の記述から明確となる。
【図１】図１は、最上位（レイヤー７）から、最下位（レイヤー１）までのＯＳＩ参照モデルのプロトコル階層を示す。
【図２】図２は、TCP/IPスタックのレイヤーと、対応するＯＳＩモデルのレイヤーと、スタックの各々のレベルで利用可能なプロトコルの例を示す。
【図３】図３は、本発明の第１の好適な実施例によって設計されているモジュールを採用したシステムの例を示す概略図である。
【図４】図４は、第１の好適な実施例によって設計されたモジュールの構造例を示す。
【図５】図５は、本発明の第２の好適な実施例によって設計されているモジュールを採用したシステムの例を示す概略図である。
【図６】図６は、第２の好適な実施例に従って設計されたモジュールの構造例を示す。
【図７】図７は、本発明の第３の好適な実施例による方法を示すフローチャートである。
【図８】図８は、本発明の第４の好適な実施例による方法を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明を全体的に理解するための具体的な内容を詳細に記述する。なお、これらの具体的な内容の詳細全体が必須という訳ではなく、適宜省略等しても本発明を実装できることは、当業者にとって明らかであろう。また、不必要に本発明を分かりにくくしないために、良く知られた処理の詳細については、適宜省略している。
【００１６】
図３は、本発明の第１の好適な実施例によって設計されているモジュールを採用したシステムの例を示す概略図である。図３を参照すれば、ホスト302は、TCP/IPスタック308を介してリモートホスト304と通信するTCP/IPアプリケーション306を含んでいる。例えば、TCP/IPアプリケーション306は、ウェブ・ブラウザである。ホスト302は、HTTPセッションＳをオープンして、リモートホスト304からサイズＰのウェブ・ページＷをダウンロードする。ここで、ウェブ・ページＷは、HTMLドキュメント、埋め込みデータ、イメージなどを含む、一つのウェブ・ページのコンテンツの全てを意味する。この実施例の説明では、簡単のためTCP/IPおよびHTTPを使用しているが、本発明はこれに限定されるものではない。すなわち、本発明は、FTPを含む他のアプリケーションプロトコルや、他のネットワークプロトコルに対しても、同じように実装できる。
【００１７】
この第１の好適な実施例では、ホスト302は、モジュール310としてHQO（ハンドオフ/QoS最適化モジュール）を含んでいる。HQOモジュール310は、TCP/IPアプリケーション306（またはアプリケーション層）およびTCP/IPスタック308（またはトランスポート層）の間に介在し、それらと信号のやりとりを行う。
【００１８】
図４は、第１の好適な実施例によって設計されたHQOモジュール310の構造例を示す。図４に示すように、HQOモジュール310は、一般にセッション・デテクタ402、リクエスト・インターセプタ404、リクエスト・アナライザ406、リクエスト・コントローラ408、補助セッション・マネージャ410、レスポンス・デテクタ412、レスポンス・マネージャ414および記憶装置416を含む。
【００１９】
セッション・デテクタ402は、リモートホスト304に対するホスト302からのオリジナル・セッションＳの開始を検出して、このオリジナル・セッションＳをインターセプトする。この検出が行われると、補助セッション・マネージャ410は、オリジナル・セッションＳをサポートする一つ以上の補助セッションをオープンして管理する。ここでは、補助セッションは、同じリモートホストへ送信する必要はなく、一般的には、リモートホスト304とは異なる複数のリモートホストに対して立ち上げることができる。
【００２０】
リクエスト・インターセプタ404は、オリジナル・セッションＳを介して送信されたHTTPリクエストを検出する。検出されたHTTPリクエストは、リクエスト・アナライザ406に渡され、そこで解析・分析される。リクエスト・コントローラ408は、解析結果を受信して、ウェブ・ページＷの分割片の適当な数を決定する。これらの分割片は、組み合わせれば、ウェブ・ページＷの全体をカバーするが、互いにオーバーラップしてもしなくとも良く、また、同じサイズを有する必要もない。これらの分割片を決定する際に、リクエスト・コントローラ408は、補助セッションに関する情報を参照できる。例えば、リクエスト・コントローラ408は、この適当な数を決定するために、現在確立している補助セッションの数を参照する。例えば、三つの補助セッションがオリジナル・セッションＳをサポートすべく確立された場合、リクエスト・コントローラ408は、この「適当な数」として４を決定する。この決定に際しては、リクエスト・コントローラ408は、オリジナル・セッションＳまたは補助セッションのうちの１つを介して、決定された分割片の各々に対する要求する。また、リクエスト・コントローラ408は、分割片の数を１と決定しても良い。この場合、ウェブ・ページＷ全体をダウンロードすることになる。
【００２１】
リクエスト・コントローラ408からのリクエストに応答して、リモートホスト304は、オリジナル・セッションＳおよび補助セッションを介して、要求されたウェブ・ページＷの分割片の送信を行う。補助セッションで送信される分割片は、補助セッション・マネージャ410によりレスポンス・マネージャ414に提供される。更に、レスポンス・デテクタ412は、オリジナル・セッションＳを介して送信される分割片をインターセプトして、レスポンス・マネージャ414にこの分割片を提供する。レスポンス・マネージャ414は、受信した分割片に基づいてウェブ・ページＷの全体を組み立てて、HTTPレスポンスとして組み立てたウェブ・ページＷをTCP/IPアプリケーションに提供する。
【００２２】
リクエスト・コントローラ408で行われる処理を、以下の実例によって、更に詳細に後述する。
【００２３】
一つの例において、分割片の数が４であると決定された場合、リクエスト・コントローラ408は、オリジナル・セッションＳおよび補助セッションを用いて、各々４分の１のウェブ・ページＷをダウンロードする。すなわち、ウェブ・ページＷがサイズＰであるとすると、リクエスト・コントローラ408は、例えば、第１バイトから第Ｐ／４バイトまでをオリジナル・セッションＳを介してダウンロードし、第Ｐ／４＋１バイトから第Ｐ／２バイトまでを第１の補助セッションを介してダウンロードし、第Ｐ／２＋１バイトから第３Ｐ／４バイトまでを第２の補助セッションを介してダウンロードし、第３Ｐ／４＋１バイトから第Ｐバイトまでを第３の補助セッションを介してダウンロードする。ウェブ・ページＷの一部のみの要求は、リクエスト・ヘッダ・フィールドの"Range"ヘッダを用いることで行うことができ、今日、大部分のウェブ・サーバにおいてサポートされている。"Range"ヘッダは、HTTP/1.1（RFC 2616）のSections 5.3および14.35において記述されている。
【００２４】
より詳しく述べれば、リクエスト・コントローラ408は、オリジナルのHTTPリクエストを修正し、修正されたHTTPリクエストによって、ウェブ・ページＷの全体ではなく、その一部のみを要求するようにできる。この修正を、オリジナル・セッションＳの切り詰めと呼ぶ。例えば、リクエスト・コントローラ408は、HTTPリクエストのHTTP ヘッダに"Range"フィールドを導入すれば良い。そして、リクエスト・コントローラ408は、オリジナル・セッションＳを介して、修正されたHTTPリクエストを送信する。更に、リクエスト・コントローラ408は、ウェブ・ページＷの他の分割片を要求する補助HTTPリクエストを生成して、補助セッションを介して送信する。補助HTTPリクエストを送信すると共に、リクエスト・コントローラ408は、各々の分割片がウェブ・ページＷの全体に対してどの位置を占めるかに関する位置情報を、補助セッション・マネージャ410に提供する。補助セッション・マネージャ410は、提供された位置情報を、記憶装置416に格納しておく。ウェブ・ページＷの各分割片が補助セッションで受信されると、補助セッション・マネージャ410は、記憶装置416から位置情報を読み出して、レスポンス・マネージャ414に提供する。レスポンス・マネージャ414は、この位置情報に基づいて、ウェブ・ページＷの全体を構築する。例えば、レスポンス・マネージャ414は、HTTPレスポンスを解析して、その本体(body)から、ウェブ・ページＷの分割片を取り出して、位置情報に基づいて分割片を組み立て、ウェブ・ページＷの全体を構築する。
【００２５】
別の例では、ウェブ・ページＷは、HTMLドキュメント、埋め込みデータ、イメージなどを含む、一つのウェブ・ページのコンテンツの全てからなる。このようなウェブ・ページＷの様々な要素は、複数のURI（汎用リソース識別子）によって指定できる。この場合、リクエスト・コントローラ408は、それぞれのURIにより指定された要素として、ウェブ・ページＷの分割片を決定することができる。例えば、ウェブ・ページＷは、基礎となるHTMLドキュメントと、２つの埋め込みイメージＡおよびB含むこともある。ここで、イメージＡおよびBのURIは、基礎となるHTMLドキュメントに含まれる。この場合、リクエスト・コントローラ408は、ウェブ・ページＷの個々の分割片として、基礎となるHTMLドキュメント、イメージAおよびイメージBを決定できる。したがって、これら基礎となるHTMLドキュメント、イメージAおよびイメージBは、各々のURIに基づいて、オリジナル・セッションＳおよび補助セッションを介して、並行してダウンロードできる。HTTPヘッダの修正は、必須という訳ではない。
【００２６】
さらに、オリジナル・セッションＳおよび補助セッションは、リモートホスト304に対して、異なるパスを有することができる。例えば、いくつかのセッションは、比較的遅いネットワーク（例えば、CDMA）の上のリモートホスト304に対する接続あり、他のセッションは、比較的速いネットワーク（例えばWiFiアクセス）を介して確立されるということも有り得る。この場合、リクエスト・コントローラ408は、より大きい分割片をより速いルートでダウンロードし、より小さい分割片をより遅いルートでダウンロードすることによって、可能な限り夫々の分割片が同時にダウンロードすることが可能となる。例えば、イメージAが大きいサイズを有し、イメージBが小さいサイズを有する場合、リクエスト・コントローラ408は、速いWiFiアクセスで確立されたセッションによってイメージAをダウンロードし、遅いCDMAリンクで確立されたセッションによってイメージＢをダウンロードするように制御を行うことができる。
【００２７】
上記の実施例によれば、アプリケーションおよびリモートホストを修正せずに、ダウンロードを大きく加速することができる。特に、コンテンツの複数の分割片を、並行してダウンロードすることができる。したがって、実際のダウンロードは、既存のプログラムにいかなる修正も加えることなく劇的に加速される。例えば、ボトルネックを伴ったウェブ・サーバまたはネットワーク・ルートが使われていると仮定すると、上記の方法で、小さくしたオリジナル・セッションおよび３つの補助セッションによって、ウェブ・ページＷの４分の一毎並行してダウンロードする場合、ウェブ・ページＷのダウンロードは、ほぼ４倍高速になる。より詳しく述べると、補助セッションの数を十分に大きく設定した場合、ダウンロードを加速して、ホストとリモートホスト間のネットワーク経路で利用できるボトルネック・バンド幅を効率的に利用し尽くすことができる。なお、オリジナル・セッションおよび補助セッションは、組み合わせて、仮想的な高速TCP接続を形成し、開始動作の遅延を防止する。
【００２８】
更に、レスポンス・マネージャ414は、通常のHTTPレスポンスとして、コンテンツの全てを提供するので、TCP/IPアプリケーションはHQOモジュール310の存在を知る必要はない。すなわち、TCP/IPアプリケーションは、HQOモジュール310がない場合と同じHTTPリクエストを送信し、HQOモジュール310がない場合と同一のHTTP レスポンスを受信する。したがって、HQOモジュール310は、TCP/IPアプリケーションに対してトランスペアレントであり、いかなる既存のアプリケーションもそのまま使うことができる。さらに、HQOモジュール310および補助セッションは、従来のTCP/IPスタックおよびリモートホストに対しても、完全にトランスペアレントである。リクエスト・コントローラ408からのHTTPリクエストは、HTTP規格を満たしている通常のHTTPリクエストであるので、リモートホスト304は、一般的なウェブ・サーバであれば良い。したがって、リモートホスト304に対する修正は不要である。言い換えれば、リモートホスト304は、HQOモジュール310に対応するモジュールやレイヤーを必要としない。したがって、本実施例は、完全にトランスペアレントで片側実装可能なソリューションを提供する。
【００２９】
更に、図１では図示はしていないが、リクエスト・コントローラ408は、リモートホスト304にリクエストを送信して、ウェブ・ページＷのサイズＰを取得してから、分割片を決めることもできる。例えば、リクエスト・コントローラ408は、リモートホスト304から受け取ったHTTPレスポンスのHTTPヘッダから、サイズＰ上の情報を得ることができる。
【００３０】
上記の実施例において、HQOモジュール310は、TCP/IPアプリケーション（またはアプリケーション層）およびTCP/IPスタック（またはトランスポート層）の間に設けられる。しかしながら、本発明は、これに限定される訳ではない。HQOモジュール310は、トランスポート層の下で存在できる。
【００３１】
この場合、リクエスト・コントローラ408は、リクエストの適当なパケットのペイロードを修正することができる。例えば、リクエスト・コントローラ408は、パケットのペイロードに含まれるアプリケーション層のヘッダを修正して、リモートホスト304に、コンテンツの全てではなく、一部のみを送信させる（オリジナル・セッションの切り詰め）ようにしてもよい。また、オリジナル・セッションの切り詰めを行うと共に、リクエスト・コントローラ408は、コンテンツの残りの分割片の補助リクエストを含むパケットを組み立てる。組み立てられたパケットは、補助セッション・マネージャ410で送信される。
【００３２】
レスポンス・マネージャ414は、補助セッション・マネージャ410およびレスポンス・デテクタ412を介して、リモートホスト304からコンテンツの分割片を受信する。分割片は組み合わせてコンテンツの全体をカバーするので、レスポンス・マネージャ414は、受信した分割片を用いて、コンテンツの全て（分割片のマージ処理）を組み立てて、上位層に提供することができる。マージ処理の１つの例では、レスポンス・マネージャ414は、オリジナル・セッションおよび補助セッションの各々から受信したIPパケットのバッファリングを行っている。バッファされたIPパケットは、コンテンツの全てがオリジナル・セッションを介して要求された場合に受信するような正確にオリジナルな順序とフォーマットで、上位層に提供される。この目的で、レスポンス・マネージャ414は、これらパケットの各々について、アドポート値に対する適当な変更を行って、パケットがオリジナル・セッションから得られたかのように見せるようにしても良い。更に、レスポンス・マネージャ414は、これらパケットの各々について確認応答フィールドおよびTCPシーケンス番号をシフトさせることによって、オリジナル・セッションから得られるのと同じように、パケット列にその正しい位置を反映させる。この例は、後で、更に詳細に記述する。
【００３３】
補助セッション・マネージャ410からの各々の着信パケットpについて、レスポンス・マネージャ414は、このパケットpが、レスポンス・マネージャ414から上位層に配信されていないウェブ・ページＷの分割片を含むか否かを決定する。もしも配信されていないウェブ・ページＷの分割片を含んでいる場合、レスポンス・マネージャ414は、パケットpの送信元および送信先の"adport"フィールドを、オリジナル・セッションの送信元および送信先の"adport"フィールドで置き換え、パケットpの（そのようなフィールドが存在するなら）シーケンス番号フィールドの値を、ウェブ・ページＷにおけるパケットpの最初のペイロード・バイトの当初の位置で置き換え、そして、パケットpの（そのようなフィールドが存在するなら）確認応答数値フィールドの値を、パケットpのレイヤー４の長さとローカル・変数「latest_seen_ack_number」との和で置き換える。
【００３４】
また、レスポンス・マネージャ414は、パケットpが送信最終パケットであるか否かを決定する。送信最終パケットであれば、レスポンス・マネージャ414は、それを直ちに上位層へ転送することはしない。パケットpを直ちに転送する代わりに、レスポンス・マネージャ414は、パケットpがウェブ・ページＷの末尾の受信を示しているかどうかをチェックする。もし、末尾の受信を示しているなら、送信最終パケットpは、バッファに保持される。オリジナル・セッションＳで送信完了状態となった場合、送信終了パケットpはバッファから取得されて、上位層に届けられる。マージ処理は、リクエスト・アナライザ406およびリクエスト・コントローラ408において行われる以下の動作を更に含んでもよい。上位層から受信した補助セッションの各々の出力パケットpについて、リクエスト・アナライザ406は、そのパケットpが階層４のプロトコル（通常TCP）の確認応答パケットであるか否かをチェックする。もし確認応答パケットであれば、リクエスト・コントローラ408は、ローカル・変数「latest_seen_ack_number」をパケットpのシーケンス番号フィールドの値に更新する。更に、リクエスト・アナライザ406は、パケットpの累積的確認応答数が、オリジナル・セッションＳによって実際に要求された分割片の最後のバイトよりも大きいか否かをチェックする。もし、大きい場合には、リクエスト・コントローラ408は、パケットpを捨て、大きくない場合には、下位階層にパケットpを送る。
【００３５】
補助セッションは、オリジナル・セッションと同じエンドポイントを有する必要はない。具体的には、補助セッションのリモート・エンドポイントは、オリジナル・セッションのリモートホスト304のオリジナル・エンドポイントとは異なることもありえる。同様に、補助セッションのホスト302のローカル・エンドポイントは、オリジナル・セッションのホスト302のローカル・エンドポイントとは異なることもありえる。したがって、分割片は複数の異なるリモートホストから並行してダウンロードできる。この種の一般的方法は、本発明の範囲内において、多種多様なQoS改善およびアプリケーション・ハンドオフをもたらす。
【００３６】
本発明の第２の好適な実施例を以下に示す。図５は、本発明の第２の好適な実施例によって設計されているモジュールを採用したシステムの例を示す概略図である。図５に示すように、ホスト502は、TCP/IPスタック508を介してリモートホスト504と通信するTCP/IPアプリケーション506を含んでいる。ホスト502は、この実施例によって設計されているHQOモジュール510を更に含む。
【００３７】
図６は、第２の好適な実施例に従って設計されるHQOモジュール510の典型的な構造を示す。図６に示すように、HQOモジュール510は、一般にセッション・デテクタ602、リクエスト・インターセプタ604、リクエスト・アナライザ606、リクエスト・コントローラ608、補助セッション・マネージャ610、レスポンス・デテクタ612、レスポンス・マネージャ614および記憶装置616を含む。
【００３８】
以下の説明は、HQOモジュール510を備えたホスト502が、第１のネットワーク512から第２のネットワーク514へ移動するという想定で行う。例えば、ホスト502は、デュアルモードCDMA-WiFi電話であり、CDMAセルからWiFiホットスポットへのユーザーの移動を考える。第１のネットワーク512はCDMAである。そして、第２のネットワーク514はWiFiホットスポットである。しかしながら、これは一つの例に過ぎず、いかなる形であれ本発明を制限するものではない。
【００３９】
例えば、ホスト502が第１のネットワーク512の範囲内に存在する時に、TCP/IPアプリケーション506は、大きいファイルをダウンロードしようとする。この場合、このダウンロードのために、第１のネットワーク512の範囲でオリジナル・セッションＳが確立され、このオリジナル・セッションＳを介して、ダウンロードのリクエストが送信される。このリクエストに応答して、リモートホスト504は、オリジナル・セッションＳによって要求されたファイルの送信を開始する。ここで、セッション・デテクタ602は、オリジナル・セッションＳを検出し、リクエスト・インターセプタ604 は、リクエストを検出する。検出されたリクエストは、将来の使用のために、記憶装置616に保存される。後に、要求されたファイルが転送中にホスト502が第２のネットワーク514の範囲に入る時、補助セッション・マネージャ610は、第２のネットワーク514を介して補助セッションをオープンして管理する。第１のネットワーク512の上のオリジナル・セッションＳが壊れる前であっても、補助セッションをオープンすることが好ましい。一方、記憶装置616に格納されるリクエストは、リクエスト・アナライザ606に提供され、リクエスト・アナライザ606によって解析される。この解析結果に基づいて、リクエスト・コントローラ608は、補助セッション・マネージャ610により管理される補助セッションを介して送信されるべき補助リクエストを形成する。
【００４０】
補助リクエストを形成する際に、リクエスト・コントローラ608は、既に受信されたデータの量を参照する。例えば、ハンドオフの開始時に、ファイルのNバイトまで、オリジナル・セッションＳを介して受信されているものとする。図６においては示されていないが、レスポンス・デテクタ612は、受信したバイトの数Nを検出し、この数Nをリクエスト・コントローラ608に通知する。そして、リクエスト・コントローラ608は、ファイルのバイトN+l以降の分割片だけを要求する補助リクエストを形成する。リクエスト・コントローラ608は、補助セッション・マネージャ610により管理される補助セッションを介して、補助リクエストをリモートホスト504に送信する。この補助リクエストに応答して、リモートホスト504は、レスポンス・マネージャ614に提供された補助セッションを介して、ファイルのバイトN+l以降の分割片の送信を開始する。オリジナル・セッションＳは、ハンドオフの間、開いたままとしておき、このオリジナル・セッションＳによるファイルのダウンロードは、そのまま実行中としても良い。したがって、N+lバイトからのM バイト迄の若干のバイトは、オリジナル・セッションＳと補助セッションの双方を介して二重にダウンロードされることになる。レスポンス・デテクタ612は、オリジナル・セッションＳを介してダウンロードされているデータをインターセプトして、レスポンス・マネージャ614に提供する。レスポンス・マネージャ614がレスポンス・デテクタ612および補助セッション・マネージャ610から二重にダウンロードされた分割片を受信するとき、レスポンス・マネージャ614は、オリジナル・バイトがTCP/IPアプリケーション506に既に配信されている要求されたファイルの重複バイトを自動的に廃棄する。このように、本実施例によって、シームレスで且つ費用対効果の高いアプリケーション・モビリティが提供される。
【００４１】
本実施例では、ファイル・ダウンロードを例として記載しているが、本発明がそれに限定されるものではない。むしろ、本発明は、他の多くの場合に適用できる。
【００４２】
例えば、HQOモジュール510を、SIPプロキシ・サーバで提供されているSIP会議をサポートするVoIPまたはSIP-IMSセッションといった、SIPセッションのハンドオフに利用することができる。この場合は、オリジナル・セッションＳおよび補助セッションは、会議モードで、オープンすることになる。ホスト502が１つのネットワークから他のネットワークへ移動する時に、補助セッション・マネージャ610は、別のSIP呼出しを作ることによって、リモートホスト504に補助セッションを確立する。この別のSIP呼出しは、現在の会議で使用中のセッションのエンドポイントとは異なるセッション・エンドポイントを介して、この会議に接続される。補助セッションが確立した後、リクエスト・コントローラ608は、オリジナル・セッションＳを、会議と切り離して削除し、この補助セッションに置き換える。このようにして、補助セッションは、シームレスに、オリジナル・セッションＳを引き継ぐ。
【００４３】
本発明の第３の好適な実施例を以下に示す。図７は、本発明の第３の好適な実施例による方法を示すフローチャートである。この方法は、例えば、第１の好適な実施例のHQOモジュールによって実行することができる。このモジュールは、オリジナル・セッションを検出し(702)、このオリジナル・セッションをサポートするための補助セッションをオープンする(704)。ここで、補助セッションは、オリジナル・セッションのオープンの検出に応答して、オープンされる。その後、モジュールは、オリジナル・セッションおよび補助セッションを用いて、TCP/IPアプリケーションまたはアプリケーション層が発行したオリジナル・リクエストを実行する。より詳しく述べれば、モジュールは、アプリケーション層発行のオリジナル・リクエストをインターセプトする（706）。このオリジナル・リクエストは、特定のコンテンツを取得するためのものである。そして、モジュールは、組み合わせてコンテンツの全てをカバーするコンテンツの一つ以上の分割片を決定する（708）。また、モジュールは、オリジナル・セッションおよび補助セッションを介して、コンテンツの分割片を取得する。具体的には、モジュールは、各々一つの分割片を要求する一つ以上のリクエストを作成する（710）。これらのリクエストを作成するにあたって、モジュールは、オリジナル・リクエストを参照する。特に、オリジナル・リクエストを修正して、これらのリクエストを作成するようにする。モジュールは、オリジナル・セッションおよび補助セッションを介して、作成されたリクエストを送信する(712)。そして、オリジナル・セッションおよび補助セッションを介して、コンテンツの分割片を受信する（714）。モジュールは、これらの分割片をマージして、コンテンツの全体を組み立てる（716）。最後に、モジュールは、アプリケーション層に、組み立てたコンテンツを提供する（718）。
【００４４】
本実施例によれば、TCP/IPアプリケーション、TCP/IPスタックおよびリモートホストに対して、いかなる修正も必要としない。更に、この方法は、通信ホストの一つでのみ、特にオリジナル・リクエストを発行しているホストでのみ、実行することができる。したがって、本実施例は、完全にトランスペアレントで片側実装可能なソリューションを提供する。
【００４５】
本発明の第４の好適な実施例を以下に示す。図８  は、本発明の第４の好適な実施例による方法を示すフローチャートである。この方法は、例えば、第２の好適な実施例のHQOモジュールによって実行することができる。このモジュールは、第１のネットワークに対して確立されたオリジナル・セッションを検出する(802)。そして、このモジュールは、あるコンテンツの取得を行うオリジナル・リクエストを検出し(804)、オリジナル・セッションを介して、このコンテンツの取得を開始する(806)。コンテンツの取得が行われている間に、このモジュールを備えたホストが第２のネットワークに入る場合、このモジュールは、第２のネットワークに補助セッションをオープンする(808)。そして、このモジュールは、コンテンツの取得を続けるべく補助セッションを作成し(810)、この補助セッションを介して補助リクエストを送信し(812)、この補助セッションを介してコンテンツの取得を続ける(814)。補助セッションによるコンテンツの取得は、オリジナル・セッションによるものと、部分的に重複することがある。ある１バイトが、オリジナル・セッションおよび補助セッションを介して、重複して受信した場合、このモジュールは、後に受信した１バイトを廃棄する。その後、このモジュールは、オリジナル・セッションの切断を行い(816)、このオリジナル・セッションを補助セッションで置き換える(818)。ここでも、本実施例によって、シームレスで且つ費用対効果の高いアプリケーション・モビリティが提供される。
【００４６】
上記実施例の説明では、TCP/IPプロトコル・セットの使用を想定しているが、本発明はこれに限定されるものではない。本発明は、ＯＳＩプロトコル・セットのような他の適当なプロトコル・セットに対しても適用可能である。
【００４７】
本発明は、完全にトランスペアレントで片側実装可能なソリューションを提供するものであり、QoSの改善とTCP/IPセッションについてネットワーク間ハンドオフを実現する。特に、異なる無線ネットワークを横断するユーザーのために、シームレスで且つ費用対効果の高いアプリケーション・モビリティが提供できる。また、多くの一般的なデュアルモード携帯電話機を使用する状況において、本発明によれば、遅延のないハンドオフが可能となる。すなわち、モバイル・ユーザにとって、セッション中断、終了またはダウンロード効率低下を感じる必要がなくなる。特に効果的な応用としては、VoIP（Voice over IP）、モバイル・テレビ、ストリーミングまたはダウンロードVOD（Video-On-Demand）、標準的なP2Pアプリケーション、および他のインターネット上の一般的なユーザー処理等がある。さらに、本発明によって、ウェブ・ページのダウンロードが大幅に加速される。典型的xDSLユーザーにとって、ウェブ・ページのダウンロードを、現在の速度の２倍から８倍の範囲で、劇的に加速される。インターネット・サービス・プロバイダ（ISP）またはコンテンツ・プロバイダ（CP）は、QoS改善のために新たにインフラを設ける必要もなくなる。ダウンロードの加速のために、ユーザーが要求されるのは、自身のコンピュータや端末に、本発明のHQOモジュールを、ダウンロードしてインストールすることだけである。したがって、ネットワーク・インフラやコンテンツ・サーバに、いかなるモビリティ・インフラも必要としない（トランスペアレント）。ユーザーは、自身のコンピュータや端末に、本発明を適用するだけで良い。
【００４８】
本発明は、好適な実施例に関して、図を参照して示され記載されているが、当業者であれば、添付の請求の範囲に記載の本発明の精神と範囲から逸脱することなく、様々な変更及び改変がなされることは明らかである。
【図１】
2010504688.tif 000003
【図２】
2010504688.tif 000004
【図３】
2010504688.tif 000005
【図４】
2010504688.tif 000006
【図５】
2010504688.tif 000007
【図６】
2010504688.tif 000008
【図７】
2010504688.tif 000009
【図８】
2010504688.tif 000010
【国際調査報告】
2010504688.tif 000011