JP4865888B2 - ハンドオーバ時におけるリソースの最適な使用方法 - Google Patents

Description

本発明は、データネットワークにおけるリソースの予約に関し、特に、ハンドオーバ中にリソースを最適に使用する方法に関する。

近年、モバイルコンピューティングが爆発的に成長し、新しい無線技術が急速に出現しつつある。次世代の移動通信システムの成功の鍵は、時間、場所、そして方法を問わず、シームレスなサービスをユーザに提供することである。そのためには、ユーザの移動、およびユーザまたはプロバイダの選択によるハンドオーバ中にサービス品質（ＱｏＳ）を保証することが必要である。ハンドオーバには、従来より水平ハンドオーバと垂直ハンドオーバの２つのタイプがある。本明細書における水平ハンドオーバは、同種の無線ネットワークインターフェースを使用する、管理ドメインが同じ基地局間のハンドオーバと定義する。また、本明細書の垂直ハンドオーバは、異種の無線ネットワークインターフェースを使用する、管理ドメインが異なる基地局間のハンドオーバと定義する。また、ハイパーハンドオーバは垂直ハンドオーバよりも広く定義され、異なる管理ドメイン間や異種の無線ネットワークインターフェース間のハンドオーバに加えて、異なる端末間や異なるアプリケーション間のハンドオーバも含まれる。

ＩＰネットワークにおけるモビリティサポートの現在の標準は、ＩＥＴＦのＲＦＣ２００２に記載のインターネットプロトコル（ＩＰ）モビリティサポート（モバイルＩＰ）である。モバイルＩＰでは、モビリティサポートを提供するエンティティとして、ホームエージェントと外部エージェントの２つが定義されている。無線端末宛てのパケットは、ホームエージェントが受け取り、カプセル化して、外部エージェントへトンネル経由で転送する。外部エージェントは、カプセルからパケットを取り出して無線端末へ直接転送する。モバイルＩＰが提供する枠組みにより、無線端末のユーザは通信の混乱なくホームネットワークの外へ移動することができる。

しかしながら、モバイルＩＰは、広域無線ネットワークで使用したり、管理ドメインが同じである隣接する基地局間の移動（マイクロモビリティ）を管理できるように設計されていない。モバイルＩＰは、あらゆる形態の移動を一律に扱うため、管理ドメインが同じである隣接する基地局間などの短距離を移動するユーザは、遠く離れたホームエージェントへ頻繁に登録を行うことによって生ずる、損失や遅延等の著しい混乱を被る可能性がある。モバイルＩＰでは、基地局間をハンドオーバする際に常に新しい気付アドレスが設定されるが、これにより、新しいＱｏＳ予約またはパス設定に複雑性や遅れが生じてしまう。さらに、モバイルＩＰはＱｏＳに対するサポートを提供しない。

マイクロモビリティについては、Cellular IPやHawaii等のプロトコルが開発されている。これらのプロトコルは、ネットワークトポロジに応じて階層型外部エージェントかスマート外部エージェントのいずれかを採用することにより、局所的な移動によって生ずるグローバルな更新の制限を試みている。しかしながら、これらのプロトコルは全て、同種媒体からなるネットワーク（Homogeneous Network）や管理ドメインが共通していることを想定しており、水平ハンドオーバの問題を対象としている。垂直ハンドオーバについては、２つの別々の管理ドメインに共通するエージェントが常に存在するわけではない為、これらのプロトコルが常に機能するとは限らない。

ＱｏＳをサポートする枠組みとして、Integrated Service（"Inte-Serv"）、Differentiated Service（"Diff-Serv"）、そしてMulti-Protocol Label Switching（"MPLS"）等がある。ここでは、予約確立後にＱｏＳを最も保証するInte-Servを取り上げる。

ＩＰネットワークにおけるInte-Servサポートの現在の標準は、リソース予約プロトコル（ＲＳＶＰ）である。周知のとおり、コアネットワークで用いられるＱｏＳメカニズムがいかなる種類のものであれ、サービスを保証するためには、エッジルータにおいてある種の予約か或いはアドミッション制御が必要である。ＲＳＶＰやその発展型は、ホストによって使用され、特定のデータフローに対する一定のＱｏＳの保証をネットワークに要求する。ＲＳＶＰは、ルータによっても使用され、データフローの経路上にある全ノードにＱｏＳ要求を送信して、要求されたサービスの確立と維持を行う。また、ＲＳＶＰは、フロー特定（Flow Specification）、ルーティング、アドミッション制御、ポリシー制御、およびパケットスケジューリング等のInte-Servの他のコンポーネントと密接に機能する
。また、ＲＳＶＰは、ユニキャストおよびマルチキャストデータフローの両方をサポートする。ＲＳＶＰは、異種媒体の受信者（Heterogeneous Receiver）やマルチキャストグループのメンバー変更に容易に対応する、受信者主導型の予約プロトコルである。また、ＲＳＶＰは、帯域幅の効率的な利用や、同じマルチキャストグループの複数の送信者の多重送信を可能にするために様々な予約形態を提供する。また、ＲＳＶＰは中間ルータのソフトステートを使用し、このソフトステートは、経路変更や障害に適切に対応するよう所定の時間が経過すると自動的に期限切れになる。

ＲＳＶＰは、その受信者主導型アルゴリズムにおいてモビリティをサポートしていない。従って、モビリティをサポートするために、ＲＳＶＰの発展型である、モバイルＲＳＶＰ（ＭＲＳＶＰ）等の他のプロトコルが開発されている。これらのプロトコルは、アプリケーションデータが経由すると思われる基地局においてリソースの予約を積極的に設定する。しかしながら、このような積極的な予約（Proactive Reservation）では、帯域幅を浪費したり、ＲＳＶＰソフトステートをリフレッシュするために多数の制御メッセージを必要とする可能性がある。

ＩＰ‐ＩＰトンネルを使用するＲＳＶＰは、別の発展型によってサポートされている。経路最適化を伴わないモバイルＩＰの場合、無線端末と相手端末の通信は、ホームエージェントと外部エージェントを結ぶＩＰ‐ＩＰトンネルを経由して行われる。従って、無線端末と相手端末のエンドツーエンドＲＳＶＰセッションは、ホームエージェントと外部エージェントの間でトンネル転送されるＲＳＶＰセッションによってマッピングやサポートされる必要がある。無線端末が外部エージェント間を移動する場合、ホームエージェントと新しい外部エージェントの間には新しいトンネル経由ＲＳＶＰセッションが設定される。新旧のトンネル経由ＲＳＶＰセッションは互いについて知らないため、２つのトンネルに共通するルータのリソースを二重に予約することになる。

こうした状況から、ハンドオーバ時のサービス品質の混乱を最小限にする、モビリティに対応したＱｏＳ維持方法の提供が望まれる。また、ＱｏＳ状態を変更する、ネットワークのデータフロー経路を限定し、ハンドオーバ後に旧データフロー経路上のＱｏＳ状態を解放する、モビリティに対応したＱｏＳ維持方法の提供が望まれる。また、積極的な予約に依拠しないことによりリソースの過剰使用を抑制する、モビリティに対応したＱｏＳ維持方法の提供が望まれる。さらに、ハイパーハンドオーバにも使用可能な程度に汎用性がある、モビリティに対応したＱｏＳ維持方法の提供が望まれる。

本発明は、無線通信網においてサービス品質を維持する方法を提供する。ホームエージェントと第１の外部エージェントの間の第１のデータパスにおいて、ホームエージェントと無線端末の間のデータフローのための予約が確立される。この無線端末は第２の外部エージェントと関連付けられ、第１の外部エージェントと第２の外部エージェントの間にサービス品質をサポートする第２のデータパスが確立される。データフローは、そのサービス品質を維持するために第１および第２のデータパスを経由して転送される。

無線端末は、第２の外部エージェントと関連付けられるために第１の外部エージェントとの関連付けを解かれてもよい。予約は、データフローのサービス品質を維持するために、ホームエージェントと第２の外部エージェントの間の第３のデータパスにおいて確立される。また、予約は、ホームエージェントと相手端末の間の第４のデータパスにおいて確立され、データフローは、第１、第２および第４のデータパスを経由して相手端末や無線端末に送信される。トンネルは、第１のデータパスにおいて確立され、トンネルに対する
予約が確立される。

本発明は、相手端末に通信接続されたホームエージェントと、無線端末と通信接続された外部エージェントとを含む無線通信網を提供する。無線通信網には、相手端末から無線端末へ送信される第１のデータフローや、無線端末から相手端末へ送信される第２のデータフローも含まれる。下流トンネルは、ホームエージェントと外部エージェントを結び、ホームエージェントから外部エージェントへ第１のデータフローを第１のサービス品質で送信するためにリソースを予約する。逆方向トンネルは、ホームエージェントと外部エージェントを結び、外部エージェントからホームエージェントへ第２のデータフローを第２のサービス品質で送信するためにリソースを予約する。

本発明は、無線通信網においてサービス品質を維持する方法を提供する。第１の予約は、ホームエージェントと第１の外部エージェントの間の第１のデータパスにおいて確立される。この第１のデータパスには、ルータとホームエージェントの間の第１の区間と、ルータと第１の外部エージェントの間の第２の区間が含まれる。第２の予約は、ホームエージェントと第２の外部エージェントの間の第２のデータパスにおいて確立される。この第２のデータパスには、ルータとホームエージェントの間の第１の区間と、ルータと第２の外部エージェントの間の第２の区間が含まれる。第２の予約は、第１のデータパスの第１の区間において使用される。

Shared Explicit（ＳＥ）スタイルを使用し、且つ送信者リストに第１および第２の外部エージェントのアドレスを含む予約メッセージがホームエージェントからルータへ送信される。また、第１のデータパスに関連付けられた第１のセッションオブジェクトと第２のデータパスに関連付けられた第２のセッションオブジェクトとを含む予約メッセージがホームエージェントからルータへ送信される。第２のセッションオブジェクトは、ルータのメモリにおいて第１のセッションで置換される。

第１のデータパスは、本質的に、第１の外部エージェントからホームエージェントへデータを送信する逆方向トンネルからなる。第２のデータパスは、本質的に、第２の外部エージェントからホームエージェントへデータを送信する逆方向トンネルからなる。

無線端末のデータは、第１または第２の外部エージェントを経由してホームエージェントへ送信される。無線端末は、第１または第２の外部エージェントと関連付けられる。無線端末が第２の外部エージェントに関連付けられた場合には、第１の外部エージェントとの関連付けが解かれる。

本発明は、無線通信網においてサービス品質を維持する方法を提供する。第１の予約は、ホームエージェントとルータの間の第１のデータパスにおいて第１のセッションオブジェクトを使用して確立される。また、第１の予約は、ルータと第１の外部エージェントの間の第２のデータパスにおいても第１のセッションオブジェクトを使用して確立される。第２の予約は、ルータと第２の外部エージェントの間の第３のデータパスにおいて第１のセッションオブジェクトと第２のセッションオブジェクトを使用して確立される。また、第２の予約は、第１のデータパスにおいても第１および第２のセッションオブジェクトを使用して確立される。第１および第２の予約によって、第１のデータパス上のリソースが予約される。

第１および第２のセッションオブジェクトを含む予約要求メッセージは、第２の外部エージェントからホームエージェントへルータを経由して送信される。

第２のセッションオブジェクトの情報はルータのメモリに記憶される。ルータが、第１のセッションオブジェクトを含むパス解除メッセージを受信すると、第１のセッションオブジェクトは第２のセッションオブジェクトで置換される。第１および第２のデータパスには、ホームエージェントから第１の外部エージェントへデータを送信する転送トンネルが確立される。第１および第３のデータパスには、ホームエージェントから第２の外部エージェントへデータを送信する転送トンネルが確立される。データは、ホームエージェントから第１の外部エージェントを経由して無線端末へ送信され、またホームエージェントから第２の外部エージェントを経由して無線端末へ送信される。

本発明によれば、ハンドオーバ中であっても要求されたサービス品質を保証することができる。

データネットワーク１００を示すシステムレベルのブロック図である。 リソース予約プロトコルで使用されるメッセージおよびオブジェクトを示すブロック図である。 ホームエージェント１０３の動作を示すフローチャートである。 最初のハンドオーバのパケット通信について説明するフローチャートである。 最初のハンドオーバに続く次のハンドオーバのパケット通信について説明するフローチャートである。 ルータ１１０の動作を示すフローチャートである。 無線端末１０２が受信者である場合におけるハンドオーバのパケット通信について説明するフローチャートである。 ルータ１１０の動作を示すフローチャートである。 相手端末１０１の動作を説明するフローチャートである。 サービス合成サーバ１００２を含むネットワークを示すブロック図である。

本発明は、ＱｏＳを維持すると同時にリソースを最適に使用する方法を提供する。まず、上述した方法の様々な側面について論じるために、垂直ハンドオーバをサポートする実施形態について説明する。その次に、上述した方法が、ハイパーハンドオーバ等にどのように適用されるかを示すその他の実施形態について説明する。
図１は、データネットワーク１００を示すシステムレベルのブロック図である。データネットワーク１００は、１以上の端末が１以上のその他の端末と通信するコンピューティング環境であればよく、図１に示されるデータネットワーク１００の構成は例示的なものにすぎない。データネットワーク１００には、１以上の無線端末１０２、１以上の相手端末１０１、外部エージェント１０４、外部エージェント１０５、ホームエージェント１０３、および少なくとも１のルータ１１０が含まれる。

無線端末１０２は、データネットワーク１００を介して相手端末１０１と通信する。データネットワーク１００は、インターネット、Wide Area Network（ＷＡＮ）、またはLocal Area Network（ＬＡＮ）等のグローバルなネットワークである。データネットワーク１００は、無線通信ネットワーク、衛星ネットワーク、ブルートゥースネットワーク、またはその他のネットワークであってもよい。図１において、データネットワーク１００の構成要素はそれぞれ直接接続されているが、当該構成要素はそれぞれ間接的に接続されてもよいし、地理的に離れていてもよい。図１の接続形態は、通信経路をより明確に示すために単純化されている。

端末１０１および１０２は、それぞれデスクトップコンピュータ、サーバ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、ポケットＰＣ、無線電話、またはその他の通信可能な装置である。端末１０１および１０２は、それぞれ送信者であると同時に受信者でもある。また、端末１０１および１０２は、クライアント、サーバ、またはピアツーピア通信を行う装置として構成されてもよい。ピアツーピア通信には、Voice over IP（ＶｏＩＰ）、テレビ会議、テキスト通信、ファイル共有、映像ストリーミング、音声ストリーミング、またはその他の直接的な通信が含まれる。端末１０１および１０２は、無線通信を行うことが可能であり、データネットワーク１００とは物理的に接続しても、無線インターフェースを介して接続してもよい。端末１０１および１０２は、それぞれ動作の命令を記憶するメモリを備えている。

無線端末１０２は、データネットワーク１００への接続点を、あるネットワークまたはサブネットワークから別のネットワークへ変更することができる。例えば、無線端末１０２は、ホームエージェント１０３から外部エージェント１０４へ接続点を変更（ハンドオーバ）できる。無線端末１０２は、ホームアドレスを変更することなく位置を変更できるためハンドオーバ後でも通信を継続することができる。

ホームエージェント１０３は、無線端末１０２のホームネットワーク内のルータである。ホームエージェント１０３は、無線端末１０２の現在位置情報を保持し、無線端末１０２が外部エージェント１０４に接続した場合には、データグラムやパケットをトンネル経由で無線端末１０２に転送する。

トンネリングとは、データグラムやパケットをネットワークの一部を経由して転送する方法で、展開中のルーティングアーキテクチャの挙動を補助または修正する。トンネルは、モバイルＩＰを利用するために使用される。ホームエージェント１０３は、データグラムやパケットが、ＩＰまたはＵＤＰヘッダ等のトンネル出口を示すヘッダを追加されてカプセル化されるトンネル入口である。従来のベストエフォート型ＩＰパケット配信の見地からすると、トンネルはリンクのように振る舞う。パケットは、リソースに対する過負荷やエラーによって失われない限り、トンネル出入口の一方から他方へと転送される。

外部エージェント１０４および１０５は、無線端末１０２が接続する外部ネットワーク内のルータである。外部エージェント１０４および１０５は、無線端末１０２に対して経路制御サービスを提供する。外部エージェント１０４および１０５は、ホームエージェント１０３によってトンネル経由で転送されたデータグラムやパケットをカプセルから取り出すトンネル出口である。外部エージェント１０４および１０５は、トンネル転送されたデータグラムやパケットを無線端末１０２に転送し、そして無線端末１０２によって送信されるデータグラムやパケットを転送するデフォルトルータとなる。

無線端末１０２は、ホームエージェント１０３と関連する、ホームネットワークのホームアドレスを有している。ホームアドレスは、無線端末１０２がデータネットワーク１００に接続するポイントにかかわらず変化しない。無線端末１０２が外部エージェント１０４を介してデータネットワーク１００に接続する場合には、無線端末１０２は、現在の接続点についての情報を示す気付アドレスと関連付けられる。この気付アドレスは、ホームエージェント１０３に登録される。ホームエージェント１０３は無線端末１０２宛てのパケットを受け取り、外部エージェント１０４へのトンネルを経由して無線端末１０２に転送する。

ルータ１１０は、パケットをルーティングする。各ルータ１１０は、受信したパケットを転送すべき次のネットワークノードを判断して、当該ノードにパケットを転送することができる。ネットワークノードとは、端末、ゲートウェイ、ブリッジ、またはルータである。図１に示されるルータ１１０の配置は例示的なものにすぎず、データネットワーク１００に含まれるルータ１１０の多寡は問わない。

＜リソース予約プロトコルの概要＞
図１および２を参照して、リソース予約プロトコル（Resource Reservation Protocol, RSVP）について説明する。リソース予約プロトコルは、送信者から情報を受信する受信者によって使用され、受信者は、受信者側で動作するアプリケーションのデータフローに対するＱｏＳを要求する。受信者は、相手端末１０１、無線端末１０２、ホームエージェント１０３、外部エージェント１０４および１０５である。送信者もまた、相手端末１０１、無線端末１０２、ホームエージェント１０３、外部エージェント１０４および１０５である。リソース予約プロトコルは、正常に機能した場合、送受信者間において十分なリソースを割り当て、要求されたＱｏＳを確立および維持する。

ここで、データフローに対するリソースの割り当てを予約と定義する。各データフローには、固有のセッションオブジェクト２０２が付与され、すべてのメッセージ、データグラム、またはパケットは、データフローを特定するセッションオブジェクト２０２を含んでいる。セッションオブジェクト２０２は、宛先アドレス、プロトコル識別子、および宛先ポート番号を含む。

リソース予約プロトコルは、予約を確立するために使用される。リソース予約プロトコルでは、予約要求メッセージ２０４、パスメッセージ２０６、解除メッセージ、確認応答メッセージ、およびエラーメッセージが使用される。予約要求メッセージ２０４は、フロースペックオブジェクト、フィルタスペックオブジェクト、およびスタイルオブジェクトを含むことが好ましい。フロースペックオブジェクトは、２組の数値パラメータからなる。第１の数値パラメータは、要求されるＱｏＳのレベルを示すＲＳＰＥＣであり、第２の数値パラメータは、データフローのトラフィック特性を示すＴＳＰＥＣである。

フィルタスペックは、少なくとも送信者アドレスと送信者ポート番号とを含み、フロースペックによって定義されるＱｏＳの対象となるデータパケットを定義する。フロースペックは、ルータ１１０のパケットスケジューラにおいてパラメータを設定するために使用され、フィルタスペックは、ルータ１１０のパケットクラシファイアにおいてパラメータを設定するために使用される。

スタイルオブジェクトは二次元の値であり、同一セッション中の様々な送信者に対する予約の取り扱いや、送信者を選択する方法を示す。セッション毎の予約は、上流の送信者ごとに個別に設定されるか、或いは選択された送信者のグループによって共有される。送信者の選択は、セッション中の送信者の明示的なリストに基づいている。ここで述べる２つのスタイルとは、Fixed-Filter（ＦＦ）スタイルとShared Explicit（ＳＥ）スタイルである。ＦＦスタイルの場合、予約要求メッセージによって要求される予約は特定の送信者からのデータパケットを対象とし、この予約は、同一セッションの他の送信者と共有されることがない。ＳＥスタイルの場合、予約要求メッセージによって要求される予約は同一セッションの指定された送信者間で共有される。

パスメッセージ２０６は、送信者テンプレート、送信者ＴＳＰＥＣ、ＡＤＳＰＥＣ、およびスタイルオブジェクトを含む。送信者テンプレートは、フィルタスペックの形式をとる。送信者ＴＳＰＥＣは、予約要求メッセージと同様にデータフローのトラフィック特性を示す。ＡＤＳＰＥＣは、"one pass with advertising"（ＯＰＷＡ）情報のパッケージであり、受信者は、この情報を使用してエンドツーエンドのＱｏＳレベルを予測する。パスメッセージ中のＡＤＳＰＥＣは、ルータ１１０のトラフィック制御モジュールにおいて処理され、トラフィック制御モジュールはＡＤＳＰＥＣを更新する。更新されたＡＤＳＰＥＣは、ルータ１１０によって転送されるパスメッセージ２０６に含まれる。

解除メッセージは、当該メッセージが生成された地点の下流に位置する全ルータ１１０のパスおよび予約状態を削除する。確認応答メッセージは、予約要求メッセージ中に予約確認オブジェクトが出現した結果として送信される。エラーメッセージには、パスエラーメッセージと予約要求エラーメッセージがある。パスエラーメッセージはパスエラーの結果として生成され、各ルータを経由して受信者に転送される。予約要求エラーメッセージは、予約要求メッセージのエラーの結果として生成され、当該予約要求メッセージを送信した受信者に送信される。

実施に際して、受信者ノードは、予約要求メッセージ２０４を生成して送信者ノードに送信する。予約要求メッセージ２０４は、データパス上の各ルータ１１０において予約状態を確立する。予約要求メッセージ２０４が送信者ノードに到達すると、受信者ノードは、データパス上の第１番目のホップに対して適切なトラフィック制御パラメータを設定することができる。

各送信者ノードは、パスメッセージ２０６を生成して、ユニキャストまたはマルチキャストデータパスに沿って送信する。当該メッセージは、データパス上の各ルータ１１０（外部エージェント１０４および１０５、またはホームエージェント１０３など）間を転送される。パスメッセージ２０６は、データパス上の各ルータ１１０にパス状態を記憶させる。パス状態は、少なくとも前のホップ、すなわちルータ１１０のユニキャストアドレスを含み、このアドレスは、予約要求メッセージ２０４を送信した受信者ノードに対して、各ルータ１１０を経由して逆方向に当該メッセージを転送するために使用される。

図１を参照して、リソース予約プロトコルを使用して予約を確立する具体例について説明する。相手端末１０１は、ホームエージェント１０３および外部エージェント１０４を介して端末１０１および１０２と通信を行う。無線端末１０２は、送信者であると同時に受信者でもある。図１には相手端末１０１が１つしか図示されていないが、複数の相手通信端末が無線端末１０２と通信を行ってもよい。

ホームエージェント１０３と外部エージェント１０４の間には、２つのトンネルがある。無線端末１０２が受信者である場合には、下流トンネル１０６を経由してホームエージェント１０３から外部エージェント１０４へデータグラムまたはパケットが転送される。無線端末１０２が送信者である場合には、逆方向トンネル１０７を経由して外部エージェント１０４からホームエージェント１０３へデータグラムまたはパケットが転送される。

無線端末１０２が外部エージェント１０５へハンドオーバする場合には、下流トンネル１０８と逆方向トンネル１０９が新たに確立される。無線端末１０２が送信者である場合には、経路最適化を行うのではなく逆方向トンネル１０９が使用される。これは、ユニキャストおよびマルチキャストに対応し、マルチキャストツリーの再構築に要するオーバーヘッドを減らすためである。

エントツーエンド予約が、無線端末１０２と相手端末１０１との間で確立されるのだが、予約の確立を容易にするために、この予約は、当該無線端末間の２つの区間で確立される。第１の区間は、相手端末１０１とホームエージェント１０３の間であり、第２の区間は、ホームエージェント１０３と外部エージェント１０４との間である。

エンドツーエンド予約要求メッセージ２０４およびパスメッセージ２０６は、通常のパケットとしてカプセル化されて透過的にトンネル転送される。トンネル１０６、１０７、１０８、および１０９は、エンドツーエンドの見地からすると単一のリンクのように振る舞う。各トンネル１０６、１０７、１０８、および１０９にとって、予約は、ホームエージェント１０３と外部エージェント１０４または１０５との間で確立される。下流トンネル１０６および１０８については、ホームエージェント１０３が、エンドツーエンド予約と各下流トンネル予約の間のマッピングを行う。逆方向トンネル１０７および１０９については、外部エージェント１０４または１０５が同様なマッピングを行う。

エンドツーエンド予約は、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、そしてプロトコル識別子の５つの値によって識別される。トンネル１０６、１０７、１０８、および１０９の予約は、ホームエージェント１０３と外部エージェント１０４または１０５のアドレスおよびポート情報によって識別される。ホームエージェント１０３と外部エージェント１０４および１０５との間に複数のデータフローが存在する場合には、各データフロー毎に固有の送信元ポート番号を使用して、トンネル１０６、１０７、１０８、および１０９のリソースを予約する。この固有の送信元ポート番号によって、これらデータフロー毎に予約を区別することが容易になる。

各送信元ポートに対する５つの値のマッピングは、ホームエージェント１０３、外部エージェント１０４または１０５のいずれかによって記憶される。このマッピングにより、２段階のカプセル化、すなわちＩＰ‐ＵＤＰ‐ＩＰカプセル化が必要となる。まず、端末１０１および１０２のＩＰパケットは、マッピングに基づく固有の送信元ポートを含むＵＤＰヘッダを用いてカプセル化される。次に、ＵＤＰパケットは、ＩＰヘッダを用いてカプセル化され、トンネル内において指定されたＱｏＳを提供される。

＜リソース共有（無線端末が送信者である場合）＞
無線端末１０２が、旧外部エージェント１０４から新外部エージェント１０５へハンドオーバする間、無線端末１０２が送信者である場合には、逆方向トンネル１０７と１０９との間でリソースが共有される。外部エージェント１０４と外部エージェント１０５との間にＱｏＳサポートパス１１１を確立してもよい。ＱｏＳサポートパス１１１は、下流トンネル１０８および逆方向トンネル１０９における予約が確立されるまで、指定されたＱｏＳを達成するために、端末１０１および１０２間のエンドツーエンド通信に対する下流トンネル１０６および逆方向トンネル１０７の使用を促進する。外部エージェント１０４および１０５間のＱｏＳサポートパス１１１は、様々な方法で確立可能である。予め確立しておくことも、無線端末１０２が外部エージェント１０５と関連付けられた後に動的に確立することも可能である。

相手端末１０１とホームエージェント１０３との間のデータパスは、ハンドオーバ後も変わらないため、予約も変更されない。しかしながら、ホームエージェント１０３を一端とするトンネルは、トンネル１０６および１０７からトンネル１０８および１０９に変更される。

従来のトンネル予約では、ＦＦスタイルを使用して各トンネル毎にリソースが予約されていた。トンネル予約では、セッションオブジェクト２０２中の３つの値（宛先ＩＰアドレス、宛先ポート、およびプロトコル識別子）を使用して、セッションと予約を識別する。また、送信者テンプレートおよびフィルタスペック中の２つの値（送信元ＩＰアドレスおよび送信元ポート）を使用して、入力パケットをフィルタし、予約を利用する送信者を判断する。従来のトンネル予約では、ＦＦスタイルを使用しているために同一セッション中の異なる送信者間でリソースを共有することができずモビリティをサポートしていない。従って、セッション中の各送信者毎に別々の予約が確立されなければならない。

トンネル予約においてリソースの共有を可能にするために、本発明の好適な実施形態では、外部エージェント１０４および１０５とホームエージェント１０３を結ぶ逆方向トンネル１０７および１０９のトンネル予約にＳＥスタイルが使用される。ＳＥスタイルは、以下の理由により好適であるといえる。第１に、無線端末１０２が送信者である場合、セッションオブジェクト２０２中の３つの値はハンドオーバの間に変わることがない。ホームエージェント１０３が受信者なので、ホームエージェント１０３のＩＰアドレス、ポート番号、およびプロトコル識別子（ここでは、ＵＤＰ）を使用して、セッションオブジェクトが一定に保たれる。このように、各ルータ１１０において予約は一義的に指定される。

第２に、無線端末１０２のパケットは、同時に両逆方向トンネル１０７および１０９を経由して転送されることはない。パケットは、新しい予約が確立されるまでは旧逆方向トンネル１０７を経由して転送され、確立後は逆方向トンネル１０９を経由して転送される。これにより、逆方向トンネル１０７および１０９のリソースの共有が容易になる。さらに、外部エージェント１０４および１０５は１つの予約を完全に共有してもよく、これによりリソースを浪費せずに済む。第３に、相手端末１０１は、ハンドオーバの間、送信者アドレスとして異なる気付アドレスを使用してリソースを予約する。従って、ルータ１１０に変更を加えることなく透過的にリソースが共有される。

異なる無線端末１０２毎に逆方向トンネル１０７および１０９を区別するために、ホームエージェント１０３は、異なる宛先ポート番号を使用してエンドツーエンド予約をマッピングする。無線端末１０２は、外部エージェント１０５に接続すると、ホームエージェント１０３の同じ宛先ポートに対して予約を行わなければならない。

図３は、ホームエージェント１０３の動作についての詳細なアルゴリズムを示す図である。ブロック３０１において新しいパスメッセージ２０６を受信すると、ホームエージェント１０３は、このパスメッセージ２０６が既知の無線端末１０２による予約の更新なのか、それとも新しい無線端末１０２による予約なのかを判断する。ＩＡＮＡによって割り当てられたＩＰトンネルのデフォルト宛先ポートが３６３なので、宛先ポートが３６３である場合は新しいトンネルの予約ということになる。この場合、ブロック３０３においてホームエージェント１０３は、未使用であり固有のポート番号を割り当てて、この無線端末１０２のトンネルと他のトンネルとを区別する。

ブロック３０４において、新しいセッションオブジェクト２０２が生成され、このセッションオブジェクト２０２は、ホームエージェント１０３のアドレスと、新しく割り当てられた固有の宛先ポートと、ＵＤＰのプロトコル識別子とを含む。外部エージェント１０４または１０５のパスメッセージ２０６には、ホームエージェント１０３のＩＰアドレスと、デフォルト宛先ポート３６３と、ＵＤＰのプロトコル識別子とを含むセッションオブジェクト２０２が使用される。新しいセッションオブジェクト２０２は、予約要求メッセージ２０４の最後に付加される。

ルータ１１０は、以前のセッションオブジェクト２０２を新たに更新されたセッションオブジェクト２０２に取り替えるための拡張を有してもよい。図６は、このような拡張について説明している。この拡張によれば、予約要求メッセージ２０４は無線端末１０２に返信され、各ルータ１１０の全てのセッションオブジェクト２０２が同時に更新される。

しかしながら、ブロック３０２においてパスメッセージ２０６が既知の無線端末１０２による更新であると判断された場合は、ブロック３０５において既知のセッションオブジェクト２０２とＳＥスタイルとを使用して予約要求メッセージ２０４が生成される。この予約要求メッセージ２０４のフィルタスペックは、受信したパスメッセージ２０６の送信者テンプレートの値と同じである。ルータ１１０が予約要求メッセージ２０４を受信した際に、気付アドレスが変わらない場合には、単に予約状態が更新される。気付アドレスが新外部エージェント１０５の新しい気付アドレスである場合には、ルータ１１０は予約共有送信者リストに当該気付アドレスを追加する。以前の気付アドレスの更新は中止され、それに対応するルータ１１０の状態はタイムアウトする。当該気付アドレスがルータ１１０の唯一の送信者のものである場合には、リソースの予約が解消される。以前の気付アドレスと新しい気付アドレスがルータ１１０に同時に存在する場合には、以前の気付アドレスが予約共有送信者リストから削除される。無線端末１０２は、新外部エージェント１０５に新たに登録した場合には、新外部エージェント１０５が適切なパスメッセージ２０６を生成できるように当該外部エージェントに対してホームエージェント１０３の宛先ポートを通知する。

ホームエージェント１０３と、新たに接続する外部エージェント１０４の間にトンネルを確立するために最初に生成されるパスメッセージ２０６では、ＦＦスタイルが使用されるべきである。これは、ホームエージェント１０３と外部エージェント１０４の間において、複数のエンドツーエンドセッションがトンネル経由で行われている可能性があるからである。最初のパスメッセージ２０６にＳＥスタイルが使用される場合、デフォルト宛先ポートが３６３であるために、別々の無線端末１０２による複数のセッションによって予約が共有されてしまうが、これは好ましくない。ＦＦスタイルが使用される場合には、各無線端末１０２のパスメッセージ２０６毎に送信者テンプレートが異なるため、予約が共有されることがない。ＦＦスタイルは、予約要求メッセージ２０４が返信される際にＳＥスタイルに変更される。各セッションには固有の宛先ポートが割り当てられ、予約は共有されない。

本発明では、ルータ１１０が、セッションオブジェクト２０２の交換および更新をサポートする拡張を有する必要はないが、無線端末１０２、外部エージェント１０４および１０５は、セッションオブジェクト２０２の更新を可能にする拡張を有している。従って、外部エージェント１０４および１０５が新しいセッションオブジェクト２０２を使用して送信したパスメッセージ２０６は、拡張を有しないルータ１１０によっては新しい予約として扱われるが、拡張を有する各ルータ１１０には、新しいセッションオブジェクト２０２を含むパスメッセージ２０６を更新として扱われる。ホームエージェント１０３が予約要求メッセージ２０４を返信すると、新しい予約が確立され、以前のセッションオブジェクト２０２が使用される予約は、各ルータ１１０においてタイムアウトとなり、この予約に割り当てられたリソースは開放される。

しかしながら、このままではパスメッセージ２０６による次の更新までＱｏＳが保証されない。ＱｏＳを保証する１つの方法として、外部エージェント１０４および１０５に対して、最初の予約要求メッセージ２０４を受信後に、新しいセッションオブジェクト２０２を使用してパスメッセージ２０６を即座に再送して、さらに以前のセッションオブジェクト２０２を使用して解除メッセージを送信することを要求する方法がある。無線端末１０２がホームエージェント１０３の宛先ポートを受信すると、その後のハンドオーバの際にＱｏＳが保証される。

図４は、最初のハンドオーバのパケット通信について説明するフローチャートである。このハンドオーバでは、無線端末１０２がホームエージェント１０３から外部エージェント１０４へ接続点を移動する。ブロック４０２において、無線端末１０２は外部エージェント１０４に登録し、パスメッセージ２０６を送信して外部エージェント１０４に予約の確立を要求する。予約の確立は、登録メッセージの拡張フィールド等の別の配送形態で要求してもよい。外部エージェント１０４は、逆方向トンネル１０７を経由して相手端末１０１にエンドツーエンドパスメッセージ２０６を送信する。同時に、外部エージェント１０４は、このパスメッセージ２０６を自身の固有の送信者ポート番号にマッピングして、ホームエージェント１０３宛てのトンネルパスメッセージ２０６を生成する。

ブロック４０４では、無線端末１０２の最初の気付アドレスを示す対応付け更新（binding update）メッセージが、外部エージェント１０４からホームエージェント１０３へ送信される。ブロック４０６では、トンネルパスメッセージ２０６が、外部エージェント１０４からホームエージェント１０３へ送信される。このトンネルパスメッセージ２０６には、外部エージェント１０４のアドレスおよび固有の送信者ポート、プロトコル識別子、ホームエージェント１０３のアドレス、宛先ポート３６３、およびＦＦスタイルが含まれる。

ブロック４０８では、トンネル予約要求メッセージ２０４が、ホームエージェント１０３から外部エージェント１０４へ送信される。このトンネル予約要求メッセージ２０４には、ＦＦスタイル、外部エージェント１０４のアドレスおよび固有の送信者ポート、プロトコル識別子、ホームエージェント１０３のアドレス、宛先ポート３６３、新しい固有の宛先ポートを含む新しいセッションオブジェクト２０２、およびＳＥスタイルが含まれる。ホームエージェント１０３は、トンネル転送されたエンドツーエンドパスメッセージ２０６を受信すると、ブロック４１０において無線端末１０２にパスメッセージ２０６を送信する。

図５は、最初のハンドオーバに続く次のハンドオーバのパケット通信について説明するフローチャートである。ブロック５０２、５０４、および５１０は、最初のハンドオーバについて説明する図４のブロック４０２、４０４、および４１０とそれぞれ同じである。ブロック５０６においてトンネルパスメッセージ２０６が、外部エージェント１０５からホームエージェント１０３へ送信される。トンネルパスメッセージ２０６には、外部エージェント１０５のアドレスおよび固有の送信者ポート、プロトコル識別子、ホームエージェント１０３のアドレスおよび固有の宛先ポート、およびＳＥスタイルが含まれる。

ブロック５０８では、トンネル予約要求メッセージ２０４が、ホームエージェント１０３から外部エージェント１０５へ送信される。トンネル予約要求メッセージ２０４には、外部エージェント１０５のアドレスおよび固有の送信者ポート、プロトコル識別子、ホームエージェント１０３のアドレスおよび固有の宛先ポート、およびＳＥスタイルが含まれる。

図６は、無線端末１０２が送信者である場合におけるルータ１１０の交換拡張についての詳細なアルゴリズムを示す図である。ここで、ルータ１１０とは、ホームエージェント１０３、外部エージェント１０４および１０５以外の、データパス上の全てのルータである。セッションオブジェクト２０２の更新を可能にする交換拡張は必ずしも必要ではないが、交換拡張がない場合には、各ルータ１１０が以前のセッションオブジェクト２０２を使用して予約を確立するため、パフォーマンスに不利な条件が生じる可能性がある。

ブロック６０２において、ルータ１１０はメッセージを受信する。このメッセージがパスメッセージ２０６である場合は、ブロック６０４において、ルータ１１０は通常の予約状態の設定を開始する。このメッセージが予約要求メッセージ２０４である場合には、ブロック６０６において、ルータ１１０はリソースを予約して、予約要求メッセージ２０４を上流に転送する。

ブロック６０８においてルータ１１０が、予約要求メッセージ２０４に、代わりのセッションオブジェクト２０２が含まれていないと判断した場合には、当該アルゴリズムはブロック６１０において終了する。他方、予約要求メッセージ２０４に、代わりのセッションオブジェクト２０２が含まれている場合、ブロック６１２においてルータ１１０は、以前のセッションオブジェクト２０２に関する情報を維持しながら、以前のセッションオブジェクト２０２と代わりのセッションオブジェクト２０２とを交換する。

ブロック６０２において受信したメッセージが予約エラーメッセージである場合、ブロック６１４においてルータ１１０は、代わりのセッションオブジェクト２０２か又は以前のセッションオブジェクト２０２をＳＥスタイルにマッピングする。ブロック６１６において、ルータ１１０は予約を解除して、予約エラーメッセージを上流に転送する。

＜リソース共有（無線端末が受信者である場合）＞
無線端末１０２が受信者である場合、ホームエージェント１０３は下流トンネル１０６または１０８の送信者側となり、外部エージェン１０４または１０５は当該トンネルの受信者側になる。無線端末１０２の気付アドレスは、ハンドオーバ中に、外部エージェント１０４のアドレスから外部エージェント１０５のアドレスに変わる。

ここでは、以前のセッションオブジェクト２０２に代えて新しいセッションオブジェクト２０２を使用して、予約したリソースを旧セッションから新しいセッションに割り当てる方法について説明する。また、新しいトンネルでは使用されないために新しいトンネルに割り当てられないリソースの迅速な解放を可能にする方法についても説明する。

図７は、無線端末１０２が受信者である場合におけるハンドオーバのパケット通信について説明するフローチャートである。ブロック７０２において無線端末１０２は、以前の予約情報を含む登録メッセージを使用して外部エージェント１０５への登録を行う。この予約情報とは、ホームエージェント１０３と旧外部エージェント１０４の間の下流トンネルの予約を識別するための５つの値である。ブロック７０４では、無線端末１０２の新しいアドレスを示す対応付け更新メッセージが、外部エージェント１０５からホームエージェント１０３へ送信される。

ブロック７０６では、エンドツーエンド予約要求メッセージ２０４が、ホームエージェント１０３から相手端末１０１へ送信される。ブロック７０８では、新しい気付アドレスを含むトンネルパスメッセージ２０６が、ホームエージェント１０３から新外部エージェント１０５へ送信される。ブロック７１０では、新しい下流トンネル１０８に対するトンネル予約要求メッセージ２０４が、新外部エージェント１０５からホームエージェント１０３へ送信される。このトンネル予約要求メッセージ２０４には、交換用の新しいセッションオブジェクト２０２、以前のセッションオブジェクト２０２、およびＦＦスタイルが含まれる。ブロック７１２では、以前のセッションオブジェクト２０２を含む、下流トンネル１０６に対するパス解除メッセージが、ホームエージェント１０３から外部エージェント１０５へ送信される。

新しい予約要求メッセージ２０４に以前のセッションオブジェクト２０２が含まれている場合、交換拡張を有する無線端末１０２は、リソースを新たに予約するのではなく以前に予約されたリソースを新しいセッションに割り当てることができる。これにより予約の成功数が増加するが、これは共通リンクの以前に予約されたリソースが常に利用可能な為である。ここで、共通リンクとは、旧下流トンネル１０６と新しい下流トンネル１０８に共通するデータパスおよびリソースと定義する。

旧下流トンネル１０６がハンドオーバの際にも使用されたり、新しい予約が上流で失敗する可能性があるため、新しい予約が正常に確立されるまではリソースの委譲を完了することができない。従って、各ルータ１１０は、予約要求メッセージ２０４を受信後にすぐに旧セッションから新しいセッションにリソースを割り当てずに、新しいセッションに関連する情報を記録して、ホームエージェント１０３からの予約確認メッセージを待つ。

旧下流トンネル１０６のうち共通リンクでない部分の使用されないリソースを迅速に解放するために、ホームエージェント１０３は、予約要求メッセージ２０４を受信すると旧外部エージェント１０４にパス解除メッセージを送信する。パス解除メッセージは、以下の２つの役割を果たす。第１に、パス解除メッセージによって、旧下流トンネル１０６と新しい下流トンネル１０８に共通しないルータ１１０のリソースが解放される。第２に、旧下流トンネル１０６と新しい下流トンネル１０８に共通するルータ１１０では、パス解除メッセージによって、旧下流トンネル１０６から新しい下流トンネル１０８へのリソースの割り当てが完了する。予約が完了すると、相手端末１０１のパケットは新しい下流トンネル１０８を経由して転送され、シームレスにＱｏＳがサポートされる。ルータ１１０の詳細な予約アルゴリズムについては図８に図示する。

予約を識別するための以前のセッションオブジェクト２０２の５つの値が、旧外部エージェント１０４または無線端末１０２によって直接、新外部エージェント１０５に提供される。または、ホームエージェント１０３が、新外部エージェント１０５から対応付け更新を受信した後に、トンネルパスメッセージ２０６を使用して以前のセッションオブジェクト２０２の５つの値を新外部エージェント１０５に提供してもよい。この場合、トンネルパスメッセージ２０６に必要な情報に５つの値を相乗りさせることで時間の遅れを生じずに済む。また、新しい下流トンネル１０８における予約成功の最終確認は、パス解除メッセージ以外の方法で行われてもよい。例えば、新しい下流トンネル１０８を経由する最初のパケットを、セッションオブジェクト２０２の交換を完了するトリガとしてもよい。

図８は、無線端末１０２が受信者である場合におけるルータ１１０の交換拡張についての詳細なアルゴリズムを示す図である。ブロック８０２において、ルータ１１０はメッセージを受信する。このメッセージがパスメッセージ２０６である場合、ブロック８０４においてルータ１１０は通常の予約状態の設定を開始する。このメッセージが予約要求メッセージ２０４である場合、ブロック８０６においてルータ１１０は、予約要求メッセージ２０４に、代わりのセッションオブジェクト２０２が含まれているか否かを判断する。含まれていない場合、ルータ１１０はリソースを予約して、予約要求メッセージ２０４を上流に転送する。

予約要求メッセージ２０４に、代わりのセッションオブジェクト２０２が含まれている場合、ブロック８１０においてルータ１１０は、当該セッションオブジェクト２０２が自身のメモリに記憶されているか否かを判断する。記憶されていない場合、ブロック８１２においてルータ１１０は、代わりのセッションオブジェクト２０２を無視してリソースを予約し、予約要求メッセージ２０４を上流に転送する。他方、代わりのセッションオブジェクト２０２がメモリに記憶されている場合、ブロック８１４においてルータ１１０は、新しいセッションオブジェクト２０２と以前のセッションオブジェクト２０２とを関連付けることによって交換情報を一時的に記憶する。

ブロック８０２において受信したメッセージがパス解除メッセージである場合、ブロック８１６においてルータ１１０は、現時点で代わりのセッションが存在するか否かを判断する。存在しない場合、ブロック８１８においてルータ１１０は、パスを解除してパス解除メッセージを上流に転送する。代わりのセッションが現時点で存在する場合、ブロック８２０においてルータ１１０は、旧セッションから新しいセッションへリソースを割り当て、旧セッションの記録を消去する。

＜その他の実施形態＞
ここまで説明してきた実施形態（第１実施形態）では、無線端末１０２が送信者または受信者として移動する場合に、新旧の予約間でリソースが再使用されるが、この実施形態はモバイルＩＰｖ４を使用して実施してもよい。この場合、無線端末１０２が送信者である際に、逆方向トンネル１０７および１０９が、外部エージェント１０４および１０５からホームエージェント１０３への通信にそれぞれ使用される。また、第１実施形態は、最も複雑な実施方法の１つであると考えられているＩＰ‐ＩＰトンネリングを使用して実施してもよい。別の実施形態では、より複雑でない実施方法であると考えられているモバイルＩＰｖ６や経路最適化を伴うＩＰｖ４を使用して、新旧の予約間でリソースが再使用される。

第１実施形態では、逆方向トンネル１０７および１０９が、無線端末１０２が送信者である場合に、外部エージェント１０４および１０５とホームエージェント１０３の間の通信のために使用されていた。別の実施形態では、逆方向トンネル１０７および１０９が、他の目的のために使用されるか、または全く使用されない。

＜第２実施形態：逆方向トンネルを使用しないＩＰｖ４＞
第１実施形態では、無線端末１０２が送信者である場合、逆方向トンネル１０７および１０９が、外部エージェント１０４および１０５とホームエージェント１０３との間の通信のためにそれぞれ使用されていた。第２実施形態では、逆方向トンネル１０７および１０９を使用せずに、無線端末１０２のアドレスを使用してパケットが相手端末１０１に直接転送される。無線端末１０２が受信者である場合は、第１実施形態の方法と同様である。

第２実施形態でも相手端末１０１のアドレスが固定されている為、セッションオブジェクト２０２の宛先アドレスはハンドオーバに伴って変化しない。従って、相手端末１０１は、上述のＳＥスタイルを使用した予約を直接行う。相手端末１０１は、第１実施形態のホームエージェント１０３が有する全ての機能を果たし、この機能には、トンネリング、固有ポートの割り当て、およびセッションオブジェクト２０２の変換が含まれる。

さらに、無線端末１０２がトンネルを経由せずに相手端末１０１と直接通信する場合、予約要求メッセージ２０４に使用するポート番号は、ＩＰ‐ＩＰトンネリングを利用する場合に要求される３６３に限定されない。予約要求メッセージ２０４には、ＳＥスタイルや現在の固有のポート番号が使用されてもよいため、相手端末１０１にはセッションオブジェクト２０２の変換機能のみが要求される。これは、予約要求メッセージ２０４に使用するポート番号が、ＩＰ‐ＩＰトンネリングを利用する場合に要求される３６３に限定されない為である。

図９は、相手端末１０１の動作を説明するフローチャートである。ブロック９０２において、相手端末１０１はパスメッセージ２０６を受信する。トンネル経由のセッションでない場合、ブロック９０６において相手端末１０１は、現在の固有のポート番号とＳＥスタイルを使用して予約要求メッセージ２０４を送信する。他方、トンネル経由のセッションである場合、ブロック９０８において相手端末１０１は当該セッションに固有のポート番号を割り当てる。ブロック９１０では、相手端末１０１は、以前のセッションオブジェクト２０２を使用してＦＦスタイルを含む予約要求メッセージ２０４を送信する。この予約要求メッセージ２０４には、新しいセッションオブジェクト２０２とＳＥスタイルが付加されている。

第２実施形態と第１実施形態の主な相違点は、以前のデータパスと新しいデータパスに共通するパスの割合である。第１の別の実施形態とは異なり、第１実施形態では、ホームエージェント１０３と相手端末１０１の間のパスがデータパスの新旧を問わず常に共通している。この第１実施形態に対する第１の別の実施形態の利点は、ユニキャストの場合においてエンドツーエンドパスが全体として短くなるという点である。

第１の別の実施形態は、マルチキャストの場合でも有用である。この場合、リソースを共有する受信者である無線端末１０２のマルチキャストツリーが形成される。無線端末１０２の気付アドレスが異なる場合には、マルチキャストツリーの複数の送信者のものとして扱われ、ここまで上述した方法と同様に処理される。

＜第３実施形態：経路最適化を伴うモバイルＩＰｖ４＞
第３実施形態は、第２実施形態の変形例である。この実施形態では、無線端末１０２が受信者であり、相手端末１０１は、無線端末１０２の新しい気付アドレスを宛先アドレスとして使用して、ホームエージェント１０３を経由せずに直接パケットを無線端末１０２に送信する。相手端末１０１は、第１実施形態のホームエージェント１０３のように振る舞う。予約されたリソースは共有され、新しい予約要求メッセージ２０４に以前のセッションオブジェクト２０２を付加することによって、旧セッションから新しいセッションへのリソースの割り当てが行われる。

＜第４実施形態：モバイルＩＰｖ６＞
ＩＰｖ６とＩＰｖ４の主な相違点は、ＩＰｖ６の場合、外部エージェント１０４が必要ないという点である。これは、ＩＰｖ６の場合、無線端末１０２が特定の外部エージェントなしに気付アドレスを取得できるためである。また、ＩＰｖ６を実装するルータ１１０は、ＩＰｖ６のリンクローカルアドレスを使用してパケットを無線端末１０２に転送し、無線端末１０２は、ホームエージェント１０３と相手端末１０１の両方に対応付け更新メッセージを送信する。従って、端末１０１および１０２は、ホームエージェント１０３を使用することなく直接通信を行う。

モバイルＩＰｖ６を使用する第４実施形態は、上述した第２および第３実施形態と類似している。ホームエージェント１０３は、第１実施形態と同様に上流および下流方向の両方で使用され、トラフィックは、モバイルＩＰｖ４を使用する実施形態と同様に、逆方向トンネルを経由せずに無線端末１０２から相手端末１０１へ直接転送される。

また、第４実施形態では、第２実施形態と同様に相手端末１０１が、対応付け更新を新たに受信した後に無線端末１０２に直接パケットを送信する。第３の別の実施形態の予約では、第２実施形態と同様にセッションオブジェクト２０２が使用されるが、ＩＰｖ６のアドレスが長いという点で異なっている。従って、単にＩＰｖ４アドレスに代えてＩＰｖ６アドレスを使用して、第２実施形態の方法を実施してもよい。

ＩＰｖ６のフローラベル（Flow Label）は、ＩＰｖ４には存在しない新しい概念であり、個々のセッションを識別するために使用される。しかしながら、フローラベルのサポートは標準化されていない為、フローラベルと送信元ＩＰアドレスの両方を使用してノード間の個々のセッションが識別される。フローラベルのサポートが標準化されるまで、第４実施形態では、セッションオブジェクト２０２にポート情報とフローラベル情報が含まれる必要がある。将来的には、第４実施形態において、フローラベルのみを使用してノード間の個々のセッションを識別できる。

＜第５実施形態：適用事例＞
ここまで説明してきたリソースの共有および予約方法は汎用性を有し、様々な状況で使用可能である。ハンドオーバ時のＱｏＳサポートは、ほんの一例であり、その他の２つの例について図１０を参照して説明する。

第１の例では、サービス合成サーバ１００２が、サービスプロバイダ１１００乃至１１０４の単方向サービスを統合して、合成サービスをユーザ１２０１乃至１２０３に提供する。トラフィックは、サービス合成サーバ１００２とユーザ１２０１乃至１２０３の間、またはサービスプロバイダ１１００乃至１１０４とユーザ１２０１乃至１２０３の間に限られるが、サービス合成サーバ１００２によって中継される。本明細書に記載のリソース予約および共有方法は、ユーザ１２０１乃至１２０３に対するサービスを保証するために使用される。リソースの予約および共有は、ユーザ１２０１乃至１２０３の１人が、あるサブネットワークまたはアクセスネットワークから別のネットワークへと移動する際に行われる。また、リソースの予約および共有は、サービス対象のユーザが、ユーザ１２０１乃至１２０３のうちのあるユーザから別のユーザに変わる際に共有ポリシーに従って行われる。さらに、本明細書に記載のリソース予約および共有方法は、ユーザ１２０１乃至１２０３とサービス合成サーバ１００２の間のパス上にあるリソースを割り当てるために使用してもよい。

第２の例では、一単方向サービスが、ＱｏＳや価格等の様々な属性を有する複数のサービスプロバイダ１１００乃至１１０４によって提供される。ネットワークトポロジは第１の例と同様であるが、サービス合成サーバ１００２の振る舞いが異なっている。サービス合成サーバ１００２は、ユーザ１２０１乃至１２０３にとって最も適したサービスプロバイダ１１００乃至１１０４を動的に選択する。もちろん、本明細書に記載のリソース予約および共有方法が、サービスプロバイダ１１００乃至１１０４とサービス合成サーバ１００２の間のリソースを予約するために使用されてもよい。

本発明に係るシステムおよび方法はソフトウェアプログラムコードや、当該プログラムコードを記録したコンピュータ読み取り可能な記録媒体として実現されてもよい。また、本発明に係るシステムおよび方法は上記ソフトウェアプログラムコードをエンコードした電気信号として実現され、この電気信号は有線または無線通信網を介して送受信されてもよい。

以上、本発明の様々な実施形態について説明してきたが、本発明の範囲から逸脱することなくこれらの実施形態に対して種々の変更が可能であることは当業者にとって明白である。従って、本発明は、特許請求の範囲とその均等の範囲によってのみ限定される。

１００…データネットワーク、１０１…相手端末、１０２…無線端末、１０３…ホームエージェント、１０４…外部エージェント、１０５…外部エージェント、１０６、１０８…下流トンネル、１０７、１０９…逆方向トンネル、１１０…ルータ、１１１…ＱｏＳサポートパス、２０２…セッションオブジェクト、２０４…予約要求メッセージ、２０６…パスメッセージ、１００２…サービス合成サーバ、１１００〜１１０４…サービスプロバイダ、１２０１〜１２０３…ユーザ

Claims (9)

1. 無線通信網においてルータのリソースを予約する方法であって、
   第１のエージェントが、第２のエージェントに対して、当該第１のエージェントの識別情報を含む第１のパスメッセージを送信するステップと、
   前記第１のパスメッセージを受信した前記第２のエージェントが、前記第１のエージェントに対して、前記第１のエージェントの識別情報と第１のセッションオブジェクトとを含む第１の予約要求メッセージを送信するステップと、
   前記第２のエージェントと前記第１のエージェントの間の経路上に位置し、前記第１の予約要求メッセージを中継するルータが、当該第１の予約要求メッセージに含まれる前記第１のエージェントの識別情報に対応づけて自身のリソースを予約するステップと、
   前記第１のエージェントとは異なる第３のエージェントが、前記第２のエージェントに対して、当該第３のエージェントの識別情報を含む第２のパスメッセージを送信するステップと、
   前記第２のパスメッセージを受信した前記第２のエージェントが、前記第３のエージェントに対して、前記第３のエージェントの識別情報と第２のセッションオブジェクトとを含む第２の予約要求メッセージを送信するステップと、
   前記第２のエージェントと前記第３のエージェントの間の経路上に位置し、前記第２の予約要求メッセージを中継するルータが、当該第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報に対応づけて自身のリソースを予約するステップと
   を有し、
   前記第２の予約要求メッセージを中継するルータのうち、前記第１の予約要求メッセージを中継したルータは、前記第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトと、前記第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトとが同一の内容を示す情報であって、前記第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報と、前記第１の予約要求メッセージに含まれる前記第１のエージェントの識別情報とが異なる内容を示す情報である場合には、前記第３のエージェントの識別情報に対応づけて、前記第１のエージェントの識別情報に対応づけて予約したリソースを予約することを特徴とする方法。
2. 前記第１のエージェントの識別情報は、前記第１のエージェントのアドレスとポート番号のうち少なくともいずれか１を含み、前記第３のエージェントの識別情報は、前記第３のエージェントのアドレスとポート番号のうち少なくともいずれか１を含むことを特徴とする請求項１に記載の方法。
3. 前記第１及び第２のセッションオブジェクトは、前記第２のエージェントのアドレス、前記第２のエージェントのポート番号、及びプロトコル識別子のうちの少なくとも１を含むことを特徴とする請求項１又は２に記載の方法。
4. 無線通信網においてルータのリソースを予約するシステムであって、
   第１のエージェントと、
   前記第１のエージェントと通信を行う第２のエージェントと、
   前記第１のエージェントと前記第２のエージェントの間の経路上に存在するルータと、
   前記第２のエージェントと通信を行う、前記第１のエージェントとは異なる第３のエージェントと、
   前記第２のエージェントと前記第３のエージェントの間の経路上に存在するルータと
   を有し、
   前記第１のエージェントは、第２のエージェントに対して、当該第１のエージェントの識別情報を含む第１のパスメッセージを送信し、
   前記第１のパスメッセージを受信した前記第２のエージェントは、前記第１のエージェントに対して、前記第１のエージェントの識別情報と第１のセッションオブジェクトとを含む第１の予約要求メッセージを送信し、
   前記第２のエージェントと前記第１のエージェントの間の経路上に位置し、前記第１の予約要求メッセージを中継するルータは、当該第１の予約要求メッセージに含まれる前記第１のエージェントの識別情報に対応づけて自身のリソースを予約し、
   前記第３のエージェントは、前記第２のエージェントに対して、当該第３のエージェントの識別情報を含む第２のパスメッセージを送信し、
   前記第２のパスメッセージを受信した前記第２のエージェントは、前記第３のエージェントに対して、前記第３のエージェントの識別情報と第２のセッションオブジェクトとを含む第２の予約要求メッセージを送信し、
   前記第２のエージェントと前記第３のエージェントの間の経路上に位置し、前記第２の予約要求メッセージを中継するルータは、当該第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報に対応づけて自身のリソースを予約し、
   前記第２の予約要求メッセージを中継するルータのうち、前記第１の予約要求メッセージを中継したルータは、前記第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトと、前記第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトとが同一の内容を示す情報であって、前記第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報と、前記第１の予約要求メッセージに含まれる前記第１のエージェントの識別情報とが異なる内容を示す情報である場合には、前記第３のエージェントの識別情報に対応づけて、前記第１のエージェントの識別情報に対応づけて予約したリソースを予約することを特徴とするシステム。
5. 第１のエージェントから第２のエージェントに対して送信され、前記第２のエージェントの識別情報と第１のセッションオブジェクトとを含む第１の予約要求メッセージを受信する第１の受信手段と、
   前記第１の予約要求メッセージに含まれる前記第２のエージェントの識別情報に対応づけて自身のリソースを予約する第１の予約手段と、
   前記第１のエージェントから、前記第２のエージェントとは異なる第３のエージェントに対して送信され、前記第３のエージェントの識別情報と第２のセッションオブジェクトとを含む第２の予約要求メッセージを受信する第２の受信手段と、
   前記第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報に対応づけて自身のリソースを予約する第２の予約手段と
   を有するルータであって、
   前記第２の予約手段は、前記第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトと、前記第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトとが同一の内容を示す情報であって、前記第２の予約要求メッセージに含まれる前記第３のエージェントの識別情報と、前記第１の予約要求メッセージに含まれる前記第１のエージェントの識別情報とが異なる内容を示す情報である場合には、前記第３のエージェントの識別情報に対応づけて、前記第２のエージェントの識別情報に対応づけて予約したリソースを予約することを特徴とするルータ。
6. 無線通信網においてルータのリソースを予約する方法であって、
   第１のエージェントが、第２のエージェントに対して、第１のセッションオブジェクトを含む第１の予約要求メッセージを送信するステップと、
   前記第１のエージェントと前記第２のエージェントの間の経路上に位置し、前記第１の予約要求メッセージを中継するルータが、当該第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトに対応づけて自身のリソースを予約するステップと、
   前記第１のエージェントとは異なる第３のエージェントが、前記第２のエージェントに対して、前記第１のセッションオブジェクトと、前記第１のセッションオブジェクトとは異なる第２のセッションオブジェクトとを含む第２の予約要求メッセージを送信するステップと、
   前記第３のエージェントと前記第２のエージェントの間の経路上に位置し、前記第２の予約要求メッセージを中継するルータが、当該第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトに対応づけて自身のリソースを予約するステップと
   を有し、
   前記第２の予約要求メッセージを中継するルータは、前記第２の予約要求メッセージに含まれる前記第１のセッションオブジェクトと自身のリソースが対応づけられている場合には、当該第１のセッションオブジェクトに代えて前記第２のセッションオブジェクトを当該リソースに対応づけることを特徴とする方法。
7. 前記第１のセッションオブジェクトは、前記第１のエージェントのアドレス、前記第１のエージェントのポート番号、及びプロトコル識別子のうちの少なくとも１を含み、前記第２のセッションオブジェクトは、前記第３のエージェントのアドレス、前記第３のエージェントのポート番号、及びプロトコル識別子のうちの少なくとも１を含むことを特徴とする請求項６に記載の方法。
8. 無線通信網においてルータのリソースを予約するシステムであって、
   第１のエージェントと、
   第１のエージェントと通信を行う第２のエージェントと、
   前記第１のエージェントと前記第２のエージェントの間の経路上に存在するルータと、
   前記第２のエージェントと通信を行う、前記第１のエージェントとは異なる第３のエージェントと、
   前記第２のエージェントと前記第３のエージェントの間の経路上に存在するルータと
   を有し、
   前記第１のエージェントは、前記第２のエージェントに対して、第１のセッションオブジェクトを含む第１の予約要求メッセージを送信し、
   前記第１のエージェントと前記第２のエージェントの間の経路上に位置し、前記第１の予約要求メッセージを中継するルータは、当該第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトに対応づけて自身のリソースを予約し、
   前記第３のエージェントは、前記第２のエージェントに対して、前記第１のセッションオブジェクトと、前記第１のセッションオブジェクトとは異なる第２のセッションオブジェクトとを含む第２の予約要求メッセージを送信し、
   前記第３のエージェントと前記第２のエージェントの間の経路上に位置し、前記第２の予約要求メッセージを中継するルータは、当該第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトに対応づけて自身のリソースを予約し、
   前記第２の予約要求メッセージを中継するルータは、前記第２の予約要求メッセージに含まれる前記第１のセッションオブジェクトと自身のリソースが対応づけられている場合に、当該第１のセッションオブジェクトに代えて前記第２のセッションオブジェクトを当該リソースに対応づけることを特徴とするシステム。
9. 第１のエージェントから第２のエージェントに対して送信され、第１のセッションオブジェクトを含む第１の予約要求メッセージを受信する第１の受信手段と、
   前記第１の予約要求メッセージに含まれる前記第１のセッションオブジェクトに対応づけて自身のリソースを予約する第１の予約手段と、
   前記第１のエージェントとは異なる第３のエージェントから前記第２のエージェントに対して送信され、前記第１のセッションオブジェクトと、前記第１のセッションオブジェクトとは異なる第２のセッションオブジェクトとを含む第２の予約要求メッセージを受信する第２の受信手段と、
   前記第２の予約要求メッセージに含まれる前記第２のセッションオブジェクトに対応づけて自身のリソースを予約する第２の予約手段と
   を有するルータであって
   前記第２の予約要求メッセージに含まれる前記第１のセッションオブジェクトが自身のリソースが対応づけられている場合に、当該第１のセッションオブジェクトに代えて前記第２のセッションオブジェクトを当該リソースに対応づけることを特徴とするルータ。

Images