JPWO2009037843A1 - ＱｏＳリソース予約方法及びその方法で用いられる移動端末 - Google Patents

Abstract

ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるＱｏＳリソース予約方法などを提供する技術が開示され、その技術によれば移動端末１１０が、ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを通信端末１００に向けて送信するステップと、移動端末が、ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、ＱｏＳリソースの予約を取り除くための第２のメッセージをハンドオーバ前の自身から通信端末までの経路に送信するステップとを有する。

Description

本発明は、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末に関する。

パケットスイッチの通信ネットワークにおいて、ＭＮ（Mobile Node）は通信相手であるＣＮ（Corresponding Node）と通信することが可能である。下記の非特許文献１に記載されているように、通信におけるＱｏＳリソースを予約するため、ＭＮはＱＵＥＲＹメッセージ（以下、単にＱＵＥＲＹとも言う）を送信し、ＭＮからＣＮまでの経路が利用可能な十分なＱｏＳリソースを有しているならば、ＣＮはＲＥＳＥＲＶＥメッセージ（以下、単にＲＥＳＥＲＶＥとも言う）を送信し、ＭＮはそのＲＥＳＥＲＶＥメッセージを受信する。
J. Manner (ed.), "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-11, June 2006 G. Ash (ed.), "QoS NSLP QSPEC Template", Internet Draft draft-ietf-nsis-qspec-14, January 2007 T. Sanda (ed.), "Path type support for NSIS signaling", Internet Draft draft-sanda-nsis-path-type-03.txt, October 24, 2005 国際公開公報ＷＯ２００６／０４１１８３ 国際公開公報ＷＯ２００７／０６１１１８

ＱＵＥＲＹ処理が進行中にマルチホームのＭＮがハンドオーバすると、ＭＮは、ＱＵＥＲＹ処理をハンドオーバ後に再度行うため、ＱｏＳ予約の構築において遅延が生じる。この問題を解決する方法の１つとして、ＭＮにＱＵＥＲＹの結果（最適な経路の情報及び２番目に最適な経路の情報を含む）をＢＩＣＡＳＴ（２つの異なる経路、すなわち最適な経路及び２番目に最適な経路に送信）する。これにより、ＭＮは、最適な経路のインタフェースがハンドオーバしたならば、２番目に最適な経路のインタフェースを介してＱＵＥＲＹ処理の結果を受信することができる。このとき、経路（２番目に最適な経路）に予約はされない。しかし、この方法では、別のＲＥＳＥＲＶＥが２番目に最適な経路に送信される必要があるため、ＱｏＳ経路の構築において遅延が未だに生じる。

また、他の解決方法の１つとして、２番目に最適な経路における予約処理を促進させるために、２番目の最適な経路を通じてＭＮへＱＵＥＲＹの結果を送信すると同時にPassive予約を２番目に最適な経路上にする。２番目に最適な経路上にPassive予約の状態がインストールされることにより、後で必要となれば、予約処理が促進される。しかし、最適な経路に接続したインタフェースがハンドオーバする場合、選択された／最適な経路上のＱｏＳリソースの浪費になる。なぜなら、選択された経路上におけるＱｏＳ予約状態は、ＱＮＥのソフトステートタイマーが終了した後に取り除かれるだけであるからである。

本発明は、上記の問題点に鑑み、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるＱｏＳリソース予約方法及びその方法で用いられる移動端末を提供することを目的とする。

上記目的を達成するために、本発明によれば、移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを前記通信端末に向けて送信するステップと、前記移動端末が、前記ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを前記ハンドオーバ前の前記自身から前記通信端末までの経路に送信するステップとを、有するＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が複数のインタフェースを有する場合、前記移動端末が、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含めることは、本発明の好ましい態様である。この構成により、ＱｏＳ予約の構築による遅延を防ぐことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が複数のインタフェースを有する場合、前記移動端末が、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続する中継ノードの情報を前記第２のメッセージに含め、前記第２のメッセージを受信する前記中継ノードが、自身が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差するクロスオーバノードであるか否かを判断し、前記クロスオーバノードであると判断した場合、前記第２の経路における前記ＱｏＳリソースの予約をするための情報と、前記ハンドオーバしなかったインタフェースから前記通信端末までの第３の経路における前記ＱｏＳリソースの予約をするための情報とを比較した結果に基づいて、最適な経路に前記ＱｏＳリソースの予約がなされるための処理を行うことは、本発明の好ましい態様である。この構成により、より最適な経路にＱｏＳリソースを予約することができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第２のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第３のメッセージを送信するステップを、有するＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、前記通信端末が、前記ハンドオーバする旨を伝えるための前記メッセージに基づいて、前記ハンドオーバするインタフェースの接続先の中継ノードに前記ＱｏＳリソースの予約をするための情報を収集するメッセージを送信し、前記移動端末が、前記通信端末から受信するメッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が、前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに、前記ＱｏＳリソースの予約をさせる第２のメッセージ及び前記ＱｏＳリソースの予約準備を促す第３のメッセージを送信するステップと、前記移動端末が、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信するステップと、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差する中継ノードであるクロスオーバノードが、前記ＱｏＳリソースの予約をするための情報を収集するメッセージを前記ハンドオーバ先で接続する中継ノードに送信するステップと、前記移動端末が、前記ハンドオーバ先で接続する中継ノードから受信する前記メッセージに基づいて、前記準最適経路と前記第２の経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信するステップとを、備えるＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記クロスオーバノードが、所定の期間が経過した場合、前記第２の経路を使用することができない旨を含む前記第４のメッセージを前記通信端末に送信し、前記通信端末が、受信する前記第４のメッセージに基づいて、前記ＱｏＳリソースの予約をさせるメッセージを前記準最適経路に送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第４のメッセージを送信する場合、前記移動端末が、所定の期間が経過した場合、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択し、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、移動端末と前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを生成するメッセージ生成手段と、生成された前記第１のメッセージを前記通信端末に向けて送信する送信手段と、前記ＱｏＳリソースの予約処理の間に前記移動端末自身がハンドオーバしたか否かを判断する判断手段とを備え、前記判断手段によって前記移動端末自身がハンドオーバしたと判断された場合、前記メッセージ生成手段が、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを生成し、前記送信手段が、前記第２のメッセージを前記ハンドオーバ前の前記移動端末自身から前記通信端末までの経路に送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記移動端末が複数のインタフェースを有する場合、前記メッセージ生成手段が、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含めることは、本発明の好ましい態様である。この構成により、ＱｏＳ予約の構築による遅延を防ぐことができる。

また、本発明の移動端末において、前記移動端末が複数のインタフェースを有する場合、前記メッセージ生成手段が、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続するノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードの情報を前記第２のメッセージに含めることは、本発明の好ましい態様である。この構成により、より最適な経路にＱｏＳリソースを予約することができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、前記第１のメッセージを受信する受信手段とを備え、前記送信手段が、前記第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第３のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に、前記メッセージ生成手段によって生成された前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記送信手段が、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、前記受信手段が、前記ハンドオーバするインタフェースの接続先のノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードへ前記通信端末によって送信された前記ＱｏＳリソースの予約をするための情報を収集するメッセージを受信し、前記メッセージ生成手段が、受信された前記メッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、前記送信手段が、生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明の移動端末において、前記受信手段が前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記送信手段が前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記メッセージ生成手段が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、前記送信手段が、生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、前記第１のメッセージを受信する受信手段とを備え、前記メッセージ生成手段が、前記第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに対して、前記ＱｏＳリソースの予約をさせる第３のメッセージ及び前記ＱｏＳリソースの予約準備を促す第４のメッセージを生成し、前記送信手段が、前記第３のメッセージ及び前記第４のメッセージを送信し、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための前記メッセージ生成手段によって生成された第５のメッセージを送信し、前記ハンドオーバ先で接続する中継ノードから受信する前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて、前記準最適経路と前記ハンドオーバ後の前記インタフェースから前記通信端末までの経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記受信手段が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第５のメッセージを送信する場合、所定の期間が経過した場合に、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択する判断手段を更に備え、前記メッセージ生成手段が、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを生成し、前記送信手段が生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

本発明のＱｏＳリソース予約方法及びその方法で用いられる移動端末は、上記構成を有し、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

本発明の第１の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第１の実施の形態におけるＱｏＳリソース予約のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱＵＥＲＹメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態に係るＭＮの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱＮＥの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱＮＥでのＰＲＥ−ＴＥＡＲの処理フローの一例を示すフローチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＣＮの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態における通信ネットワークの他の一例を示すネットワーク図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態に係るＭＮの構成の他の一例を示す構成図 本発明の第１の実施の形態におけるＣＮの構成の他の一例を示す構成図 本発明の第１の実施の形態における修正ＱＵＥＲＹメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの他の一例を示す図 本発明の第１の実施の形態におけるＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＱＮＥの構成の他の一例を示す構成図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第２、４の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第２の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図 本発明の第２の実施の形態に係るＭＮの構成の一例を示す構成図 本発明の第２の実施の形態におけるＱＮＥの構成の一例を示す構成図 本発明の第２の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第２の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図 本発明の第２の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図 本発明の第３の実施の形態におけるＯＰＰＴのフォーマットの一例を示す図 本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート

＜第１の実施の形態＞
図１に示すように、ＭＮ１１０は、１つのネットワークインタフェースを有しており、ＱＮＥ（ＱｏＳ ＮＳＩＳ Ｅｎｔｉｔｙ）１０８、ＱＮＥ１０６、ＱＮＥ１０４、ＱＮＥ１０２を通じる通信ネットワークを介してＣＮ１００と接続している。

ＭＮ１１０がＣＮ１００にデータを送信したい場合、ＭＮ１１０は、経路上の利用可能なＱｏＳを見つけるために、図２に示すように、ＣＮ１００に向けてＱＵＥＲＹメッセージ２００（以下、単にＱＵＥＲＹとも言う）を送信する。

ＱＵＥＲＹメッセージは、上述した非特許文献２で定義された形式をとることが可能である。ＱＵＥＲＹメッセージのフォーマットの一例を図３に示す。ＱＵＥＲＹメッセージはデータ経路に沿って利用可能なＱｏＳ情報を収集する。

ＱＵＥＲＹメッセージ２０８を受信したＣＮ１００は、ＲＥＳＥＲＶＥメッセージ（以下、単にＲＥＳＥＲＶＥとも言う）を生成し、図２に示すように、ＭＮ１１０からＣＮ１００へ送信されたＱＵＥＲＹメッセージが通った同じ経路に沿って生成されたＲＥＳＥＲＶＥメッセージ２１０をＭＮ１１０へ送信する。

ＲＥＳＥＲＶＥメッセージのパラメータは非特許文献２に定義されている。ＲＥＳＥＲＶＥメッセージはデータ経路上の中間に位置するＱＮＥ１０２、１０４、１０６、１０８でＱｏＳ予約をするものである。ＲＥＳＥＲＶＥメッセージのフォーマットの一例を図４に示す。

ＱｏＳ予約処理の間に、ＭＮ１１０が、ネットワークのアクセスポイント（ＡＰ：Access Point）を介したネットワーク接続が間もなく変更するとわかると、ＭＮ１１０（若しくはＭＮ１１０に隣接するＱＮＥ）はＡＰの変更／ハンドオーバが実際に起こる前に、その経路上のＣＮ１００にメッセージを送信する。このメッセージはＰＲＥ−ＴＥＡＲメッセージ（以下、単にＰＲＥ−ＴＥＡＲとも言う）と呼ぶ。ＰＲＥ−ＴＥＡＲは以下の要素から構成される。

ＰＲＥ−ＴＥＡＲ：＝メッセージタイプ識別情報
セッションＩＤ
フローＩＤ

メッセージタイプ識別情報（MESSAGE TYPE IDENTIFIER）５０１はＰＲＥ−ＴＥＡＲを示す際に用いられる。セッションＩＤ（SESSION ID）５０２は、ＣＮ１００によって送信されるＲＥＳＥＲＶＥメッセージのものと同じものである（先にＭＮ１１０によって送信されたＱＵＥＲＹのものと同じ）。フローＩＤ（FLOW ID）５０３は先にこの経路に送信されたＱＵＥＲＹのものと同じである。ここで、ＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を図５に示す。ＰＲＥ−ＴＥＡＲは、ハンドオーバしようとする経路（ハンドオーバする直前につながっている経路）上に予約されたＱｏＳリソースを取り除く機能を有する。

図６はＭＮの機能ブロックの一例を示す。ＭＮは、受信手段６０６、送信手段６０２、ＱｏＳ予約機能手段６００、Ｐｒｅ−Ｔｅａｒ生成機能手段６０４から構成されている。Ｐｒｅ−Ｔｅａｒ生成機能手段６０４は、ＰＲＥ−ＴＥＡＲメッセージを生成し、送信手段６０２に送信させる。図７はＭＮとＣＮとの間に位置する中間のＱＮＥ１０２、１０４、１０６、１０８などの機能ブロックの一例を示す。ＱＮＥは、送信手段７０２、受信手段７０６、ＱｏＳ予約機能手段７００、Ｐｒｅ−Ｔｅａｒ処理機能手段７０４から構成されている。

ＱＮＥがＰＲＥ−ＴＥＡＲを受信すると、ＱＮＥは、図７の機能ブロック図に示されるＰｒｅ−Ｔｅａｒ処理機能手段７０４によってＰｒｅ−Ｔｅａｒ処理を実行する。ＰＲＥ−ＴＥＡＲの処理の一例を図８に示す。図８に示すように、ＰＲＥ−ＴＥＡＲがＱＮＥに受信されると（ステップＳ８０１）、ＱＮＥは、ＰＲＥ−ＴＥＡＲに含まれるセッションＩＤとフローＩＤのコンビネーションに相当するＱｏＳ予約状態が既にインストールされているかをチェックする（ステップＳ８０２）。

そのようなセッションＩＤとフローＩＤのＱｏＳ予約状態が存在しない場合、そのセッションＩＤとフローＩＤに相当するその後のＲＥＳＥＲＶＥメッセージを破棄するために、Ｐｒｅ−Ｔｅａｒ状態がインストールされ、ＰＲＥ−ＴＥＡＲがＣＮ１００に向けて次のＱＮＥに転送される（ステップＳ８０６）。一方、そのようなセッションＩＤとフローＩＤのＱｏＳ予約状態がＱＮＥ上に存在する場合、ＱｏＳ予約は取り除かれ、ＱＮＥは、図９に示すように、自身からＣＮ１００に向けたデータ経路上のＱＮＥ上のそのセッションＩＤとフローＩＤにおけるＱｏＳ予約を取り除くためにメッセージを送信する（ステップＳ８０４）。

このメッセージは、ＣＮ１００に向かうこのＱＮＥで生成されたＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲメッセージ９２０（非特許文献１を参照）になり、ＣＮ１００に至るまでのすべての経路に転送される。なお、ＱＮＥは、ステップＳ８０４において、存在するＱｏＳ予約状態を取り除いた後、図１０に示すように、受信したＰＲＥ−ＴＥＡＲ１０１４をＣＮ１００に向けて次のＱＮＥに転送するようにしてもよい。ＰＲＥ−ＴＥＡＲ１０２０が、ＣＮ１００に向けたデータ経路上の次のＱＮＥによって受信されると、上述した同じ処理が実行される。

図１１はＣＮの機能ブロックの一例を示す。ＣＮは、送信手段１１０２、受信手段１１０６、ＱｏＳ予約応答機能手段１１００、Ｐｒｅ−Ｔｅａｒ処理機能手段１１０４から構成されている。ＣＮ１００がＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲメッセージを受信すると、ＱｏＳ予約応答機能手段１１００は、ＱｏＳ状態を取り除き、必要であればＲＥＳＰＯＮＳＥメッセージ（非特許文献１を参照）を送信する。ＣＮ１００がＰＲＥ−ＴＥＡＲメッセージを受信すると、Ｐｒｅ−Ｔｅａｒ処理機能手段１１０４は、ＱｏＳ状態を取り除くトリガを行い、今後、そのＳＩＤとＦＩＤのペアに相当するＲＥＳＥＲＶＥメッセージによるＣＮ１００での予約を防ぐためのｐｒｅ−ｔｅａｒ状態をインストールする。

ステップＳ８０４において、ＱＮＥは、インストールされたＱｏＳ予約を取り除く代わりに、ＣＮ１００に向けてＰＲＥ−ＴＥＡＲを転送することも可能である。この場合、ＱＮＥはＰＲＥ−ＴＥＡＲ内に状態が除かれないことを示す付加的な指示情報を挿入する。ＣＮ１００がＰＲＥ−ＴＥＡＲメッセージを受け取り、そのような指示情報が検出されると、ＣＮ１００のＰｒｅ−Ｔｅａｒ処理機能手段１１０４は、図１２に示すように、相当するＱｏＳ予約状態を取り除くために別のメッセージ（ＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲ１２２４）をＭＮ１１０に向けて送信する。

図１３は他のネットワーク構成を示す。この場合、ＭＮ１３１４は、ＣＮ１３００と複数の接続を有しており、ＭＮ１３１４は、図１４に示すように、ＣＮ１３００に向けて複数のＱＵＥＲＹ１４００、１４０２、１４０４を送信する。それぞれのＱＵＥＲＹはＭＮ１３１４からＣＮ１３００まで流れ、それぞれの経路上のＱｏＳ情報を収集する。

ＣＮ１３００若しくは様々な経路のＣＲＮ（CRossover Node）は、ＭＮ１３１４によってＱＵＥＲＹの中に明示された基準に基づいて最適な経路を選択し、その経路にＲＥＳＥＲＶＥ１４１８若しくはアグリゲートされた（集められた）ＱＵＥＲＹ結果を送信する。このとき、ＣＮ１３００は、ＱＵＥＲＹ１４００、１４０２、１４０４を受信し、最適な経路（例えば、ＣＮ１３００からＱＮＥ１３０２、１３０８を経由するＭＮ１３１４までの経路）を選択する。選択の際、例えば、ＣＮ１３００が受信したＱＵＥＲＹ１４００、１４０２、１４０４を格納し、すべてのＱＵＥＲＹが届くまで、若しくは時間Ｔが経過するまでに決定をする。

ＣＮ１３００がＲＥＳＥＲＶＥを送信する経路上のＭＮ１３１４のインタフェースがハンドオーバする場合、ＱＵＥＲＹ処理（ＭＮ１３１４のすべてのインタフェースからＱＵＥＲＹを送信する処理）は、ＭＮ１３１４によって再度行われる必要がある。これは、ＭＮ１３１４がＲＥＳＥＲＶＥやＱＵＥＲＹの結果を受信することができないからである。ＭＮ１３１４におけるＣＮ１３００との他の接続が変更せずに残っていたとしても、ＱＵＥＲＹの結果が失われるため、ＭＮ１３１４は即座にＱｏＳ予約を開始することができない。そのような中断は以下のようにすることで回避することができる。

すなわち、ＭＮ１３１４は、最適な経路側のインタフェースがハンドオーバした場合に２番目に最適な経路にトラフィックを向けることができるように、バックアップ経路を選択し、その経路にＱＵＥＲＹ処理の結果を送信することをＣＮ１３００に指示する。すなわち、ＭＮ１３１４がＱＵＥＲＹにＢＩＣＡＳＴフラグをセットすることによりなされる。さらに、ＭＮ１３１４は、トラフィックを２番目に最適な経路に向ける必要がある場合に、ＭＮ１３１４が早急にＱｏＳ予約をすることができるように、２番目に最適な経路にＰＡＳＳＩＶＥ予約を構築することをＣＮ１３００に指示する。ＭＮ１３１４はＰＡＳＳＩＶＥ予約フラグをＱＵＥＲＹにセットする。

改良として、ＱＵＥＲＹの中のＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグは、１つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグとを合わせたフラグ）に置き換えられることが可能である。１つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグとを合わせたフラグ）は、ＰＡＳＳＩＶＥ予約を構築する２番目に最適な経路に沿ってＱＵＥＲＹ処理の結果を送信することをＣＮ１３００に知らせるためのものである。

上述の処理をサポートするＭＮの一例の構成が図１５に示されている。図６に示すＭＮの構成と比較すると、上述したフラグをＱＵＥＲＹにセットするPassive予約機能手段１５０２が付加されている。また、上述の処理をサポートするＣＮの一例の構成が図１６に示されている。図１１に示すＣＮの構成と比較すると、上述したフラグがセットされたＱＵＥＲＹを処理するPassive予約機能手段１６０２が付加されている。

上述の処理の修正ＱＵＥＲＹメッセージのフォーマットの一例が図１７に示されている。修正ＱＵＥＲＹメッセージは、ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグ（BICAST&PASSIVE RESERVEATION FLAG）１７０１を含む。また、必要とするシナリオにおいてパスタイプＩＤ１７０２（特許文献１を参照）を含むこともある。

修正ＱＵＥＲＹがＣＮ１３００に到達すると、ＣＮ１３００は、それぞれの経路で利用可能なＱｏＳ（ＱＵＥＲＹによって収集された情報）又はＭＮ１３１４によって明示された他の基準に基づいて、個々のＱＵＥＲＹが通った経路のランク付けをする。２つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグ）がＱＵＥＲＹの中に存在する場合、ＣＮ１３００は、相当するＱＵＥＲＹに記述された最も高いＱｏＳを有する２つの経路、又はＭＮ１３１４によって明示された基準による２つの経路を選択する。ＣＮ１３００は、図１８に示すように、利用可能なＱｏＳが最も高い経路にＲＥＳＥＲＶＥ１８１８を送信し、２番目に最適なＱｏＳを有する経路にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ１８２４を送信する。

ここでのＲＥＳＥＲＶＥメッセージのフォーマットの一例が図１９に示されている。ＲＥＳＥＲＶＥメッセージは、非特許文献１に記載のフィールドに加え、さらにパスタイプＩＤ（PATH TYPE ID）１９０１（特許文献１を参照）、ＱＵＥＲＹの結果（QUERY RESULT）１９０２を付加したものである。パスタイプＩＤ１９０１はオプションである。ＱＵＥＲＹの結果１９０２は最適な経路及び２番目に最適な経路の情報を含む。

また、ここでのＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージのフォーマットの一例が図２０に示されている。ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージは、非特許文献１に記載のフィールドに加え、さらにＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージタイプ（PASSIVE RESERVE MESSAGE TYPE）２００１、パスタイプＩＤ（PATH TYPE ID）２００２（特許文献１を参照）、ＱＵＥＲＹの結果（QUERY RESULT）２００３を付加したものである。

上述の処理をサポートするＱＮＥの構成の一例が図２１に示されている。図７に示すＱＮＥと比較すると、Passive予約機能手段２１０２が付加されている。例えば、ＱＮＥがＣＮからＭＮへのＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを受信すると、Passive予約機能手段２１０２は、ＧＩＳＴ（General Internet Signaling Transport）状態の構築のみをする、若しくはＧＩＳＴ状態に沿って“ゼロ予約”（ＱｏＳパラメータ０での予約）のＱｏＳ ＮＳＬＰ状態を構築する。

ＱＵＥＲＹ処理が進行している間にＭＮ１３１４のインタフェースの１つがハンドオーバする場合、ＭＮ１３１４は、その経路（ハンドオーバするインタフェースからＣＮまでの経路）上にこれまで構築されたＱｏＳ予約を取り除くため、又は行われようとしている予約を事前に阻止するために、ＰＲＥ−ＴＥＡＲ２２２２を送信する。詳細なシグナリングが図２２に示されている。

ここで、ＣＮ１３００が２番目に最適な経路（本実施の形態ではＱＮＥ１３０４、１３１０）に既にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを送信しており、かつＭＮ１３１４で、選択された最適な経路（本実施の形態ではＱＮＥ１３０２、１３０８）の方のインタフェースがハンドオーバした場合、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ２２２８の中のＱＵＥＲＹ処理の結果を受ける。ＭＮ１３１４は、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ２２２８を受信した２番目に最適な経路に完全な予約を行うため、ＲＥＳＥＲＶＥ２２３０を送信する。

同じ予約におけるＲＥＳＥＲＶＥが双方の終端（例えば、送信側及び受信側）から送信されることが可能である場合、図２３に示すように、ＣＮ／ＣＲＮはＰＲＥ−ＴＥＡＲ２３２５を受信すると、ＲＥＳＥＲＶＥ２３３２を生成し、既にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージを送った２番目に最適な経路にＲＥＳＥＲＶＥ２３３２を送信する。これにより、ＣＮ／ＣＲＮからのＲＥＳＥＲＶＥ２３３４がＭＮ１３１４からのＲＥＳＥＲＶＥ２３３０と途中（２番目に最適な経路上）で出会うため、２番目に最適な経路上のＱｏＳ予約を促進させることができる。

なお、インストールされたＰｒｅ−Ｔｅａｒ状態は、該当するＲＥＳＥＲＶＥ若しくはＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを阻止した後、明示的に取り除かれてもよいし、また一定時間経った場合に取り除かれてもよい。

＜第２の実施の形態＞
他のシナリオとして図２４に示すように、データ方向がＭＮ２４１４からＣＮ２４００において、ＱＵＥＲＹ処理が進行中にＭＮ２４１４のインタフェースの１つがハンドオーバする場合、ＭＮ２４１４は、２番目に最適な経路にスイッチする可能性がある。しかし、ハンドオーバしたインタフェースを介した経路は、ＭＮ２４１４で残っているインタフェース（ハンドオーバしなかったインタフェース）を介したＭＮ２４１４からＣＮ２４００までの残りの経路と比較して、よりよいＱｏＳを有してＣＮ２４００に接続する可能性がある。

このような可能性（例えば、ハンドオーバした経路（ハンドオーバ後の経路）が、ＱＵＥＲＹ処理から選択される２番目に最適な経路と比較して、よりよいＱｏＳを有すること）を確かめるために、ＭＮ２４１４は、ハンドオーバ先アクセスポイントであるプレディクティブ（予想）アクセスポイント（Ｐ−ＡＰ）２４１２のロケーション／アドレスを何らかの手段によって知る。ＭＮ２４１４から送信されるＰＲＥ−ＴＥＡＲはＰ−ＡＰ２４１２についての情報（PREDICTIVE ACCESS POINT）２５０１を運ぶ。ここでのＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例が図２５に示されている。

図２６は上述する処理をサポートするＭＮの構成の一例を示す。このＭＮはプレディクティブ予約機能手段２６０８を含み、プレディクティブ予約機能手段２６０８はＰ−ＡＰについての情報を得ることができ、新たなＰＲＥ−ＴＥＡＲを生成する。図２７は上述する処理をサポートするＱＮＥの構成の一例を示す。このＱＮＥはプレディクティブ予約機能手段２７０８を含み、プレディクティブ予約機能手段２７０８は、Ｐ−ＡＰの情報を有するＰＲＥ−ＴＥＡＲを処理することができる。

ＰＲＥ−ＴＥＡＲ内のＰ−ＡＰの情報は、その経路上におけるＣＲＮ（ＱＮＥ）２４０４を見つけるのに役立つ。例えば、それぞれのＱＮＥはＰ−ＡＰに関するルーティング状態をチェックし、自身がＣＲＮであるか否かを判断する。なお、ＣＲＮ２４０４はあらかじめ決められたノードであってもよい。例えば、３Ｇ環境においては、オリジナルロケーションとＰ−ＡＰの双方を管理するゲートウェイであってもよい。詳細なシグナリング処理の一例が図２８に示されている。

図２８に示すように、ＣＲＮ（ＱＮＥ）２４０４がＰＲＥ−ＴＥＡＲ２８２２を受信すると、ＣＲＮ２４０４はＰ−ＡＰ２４１２にＴｒｉｇｇｅｒ ｆｏｒ ＱＵＥＲＹ（ＴＦＱ）２８２６を送信する。ＴＦＱに用いられるフォーマットの一例が図２９に示されている。ＴＦＱ２８２６を受信したＰ−ＡＰ２４１２は、ＣＮ２４００に向けてＱＵＥＲＹ２８２８を送信する。

ハンドオーバがなければ最適とされた経路とハンドオーバ先における経路（プレディクティブ経路）とが交差するＣＲＮ２４０４によってＱＵＥＲＹ２８２８がインタセプトされ、ＣＲＮ２４０４は、ＣＲＮ２４０４からＰ−ＡＰ２４１２までのプレディクティブ経路と２番目に最適な経路とで利用可能なＱｏＳを比較する。プレディクティブ経路における利用可能なＱｏＳが２番目に最適な経路における利用可能なＱｏＳより多い場合、ＣＲＮ（プレディクティブ経路のＣＲＮ）２４０４は、プレディクティブ経路にＲＥＳＥＲＶＥ２８３０を送信し、ＱＵＥＲＹ２８２８を破棄する。

一方、プレディクティブ経路における利用可能なＱｏＳが２番目に最適な経路における利用可能なＱｏＳより少ない場合、ＣＲＮ２４０４は、最適な経路（ハンドオーバがなければ最適とされた経路）と２番目に最適な経路との間におけるＣＲＮにＱＵＥＲＹを流す。図２４の例では、図３０に示すように、そのようなＣＲＮは存在せず、ＣＮ２４００はＰ−ＡＰ２４１２からのＱＵＥＲＹ３０３０を受信し、２番目に最適な経路上における利用可能なＱｏＳと比較し、２番目に最適な経路にＲＥＳＥＲＶＥ３０３２を送信する。

＜第３の実施の形態＞
図３１は、データ方向がＣＮ３１００からＭＮ３１１４の場合のシナリオである。このシナリオでのシグナリング処理の一例が図３２に示されている。図３２に示すように、ＭＮ３１１４はＣＮ３１００に向けてＴＲＩＧＧＥＲ ｆｏｒ ＱＵＥＲＹ（ＴＦＱ）３２００を送信する。ＴＦＱのフォーマットの一例が図３３に示されている。ＴＦＱ３２００は、通常のＱＵＥＲＹに含まれる情報に加え、さらにメッセージタイプＩＤ（TFQ MESSAGE TYPE IDENTIFIER）３３０１とＭＮ３１１４が有するすべてのインタフェースのアドレス（ADDRESS OF ALL INTERFACES OF MN）３３０２の２つの付加的なフィールドを含む。

ＴＦＱ３２００を受信するＣＮ３２００は、ＴＦＱ３２００にリストされた経路／インタフェースのそれぞれにＱＵＥＲＹを送信する。

ＭＮ３１１４が、ＭＮ３１１４のインタフェースの１つがハンドオーバしようとしていることを察知し、ＭＮ３１１４がそのインタフェースでＱＵＥＲＹをまだ受信していない場合、ＭＮ３１１４は、ＣＮ３１００にＯＦＦ ＰＡＴＨ ＰＲＥ−ＴＥＡＲ（ＯＰＰＴ）３２０１を送信する。ＯＰＰＴ３２０１は、ＴＦＱ３２００にリストされた経路の１つがハンドオーバしようとしている状態であることを伝えるためのものである。

そのインタフェース（ハンドオーバしようとしているインタフェース）のＩＰアドレスは、ＯＰＰＴ３２０１の“ハンディングオーバインタフェースアドレス”フィールドに示されている。ＯＰＰＴ３２０１はＣＮ３１００に直接送信されてもよい。ＯＰＰＴのフォーマットの一例が図３４に示されている。ＯＰＰＴはＲＥＳＥＲＶＥ ｗｉｔｈ ＴＥＡＲ（非特許文献１を参照）の情報を含み、さらにメッセージタイプＩＤ（OPPT MESSAGE TYPE IDENTIFIER）３４０１、ハンディングオーバインタフェースアドレス（HANDINGOVER INTERFACE ADDRESS）３４０２を含む。

ＣＮ３１００がＭＮ３１１４に向けてＱＵＥＲＹを送信する前にＯＰＰＴ３２０１を受信すると、ＣＮ３１００は、ＯＰＰＴ３２０１のハンディングオーバインタフェースアドレス３４０２のフィールドに示されるようなハンドオーバをすると予測される経路上にＱＵＥＲＹを送信することを禁じる。すべてのＱＵＥＲＹを受信するＭＮ３１１４は、最適な経路を選択し、最適な経路上にＲＥＳＥＲＶＥ３２１４を送信する。

図３５に示すように、ＭＮ３１１４がすべてのＱＵＥＲＹ３５０６、３５１２を受信した後でＲＥＳＥＲＶＥを送信する前にハンドオーバが起こることを知る場合、ＭＮ３１１４は、ハンドオーバしようとする経路を避けて（たとえ、最適な経路であっても）、最適な経路上（相当するＱＵＥＲＹにリストされた利用可能なＱｏＳのインタフェース）にＲＥＳＥＲＶＥ３５１４を送信する。

例えば、最適な経路がＣＮ３１００−ＱＮＥ３１０４−ＱＮＥ３１１０−ＭＮ３１１４であるが、その経路につながっているインタフェースがハンドオーバしようとしている場合、ＭＮ３１１４はその経路を選択せず、２番目に最適な経路、例えばＣＮ３１００−ＱＮＥ３１０２−ＱＮＥ３１０８−ＭＮ３１１４を選択する。そして、ＭＮ３１１４は、２番目に最適な経路（ＱＵＥＲＹ処理に基づいて、ＭＮにＣＮをつなぐすべての経路において比較した中で、２番目に最適な経路）上にＲＥＳＥＲＶＥ３５１４を送信する。

最後に、図３６に示すように、ＭＮ３１１４がインタフェース上（ＱＵＥＲＹに基づく最適な経路）にＲＥＳＥＲＶＥ３６１４を送信した後、ハンドオーバしそうであると認識すると、ＭＮ３１１４は選択された経路にＲＥＳＥＲＶＥ ｗｉｔｈ ＴＥＡＲ３６２６を送信する。そして、ＭＮ３１１４は、既に先に送信したＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ３６２０が通る２番目に最適な経路にＲＥＳＥＲＶＥ３６３２を送信する。

＜第４の実施の形態＞
データ方向がＣＮからＭＮの場合のシナリオについて図２４を参照する。ＱＵＥＲＹ処理がまだ進行中でＭＮ２４１４のインタフェースの１つがハンドオーバする場合、ＭＮ２４１４は、２番目に最適な経路にスイッチする可能性がある。しかし、ハンドオーバしたインタフェースは、ＭＮ２４１４で残っているインタフェース（ハンドオーバしなかったインタフェース）を介したＣＮ２４００からＭＮ２４１４までの残りの経路と比較して、よりよいＱｏＳを有する経路を介してＣＮ２４００に接続する可能性がある。

図３７はそのようなシナリオに本発明を適用するシグナリング処理の一例を示す。図３７に示すように、ＭＮ２４１４は、ＰＲＥ−ＴＥＡＲ３７２６にプレディクティブ（予測）アクセスポイント（Ｐ−ＡＰ）の位置（ロケーション）を埋め込む。そして、利用可能なＱｏＳをチェックするために、ＣＮ２４００又はＣＲＮ２４０４は、プレディクティブハンドオーバ経路にＱＵＥＲＹ３７３２を送信する。

ＰＲＥ−ＴＥＡＲが送信された場合に基づくシナリオは２つある。１つ目は、図３７に示すように、ＭＮ２４１４がＲＥＳＥＲＶＥ３７１４を送信した後に、ＰＲＥ−ＴＥＡＲ３７２６が送信された場合、ＣＲＮ（この場合、ＱＮＥ２４０４）はＰ−ＡＰ２４１２にＱＵＥＲＹ３７３２を送信する。ＭＮ２４１４がＰ−ＡＰ２４１２に接続すると、Ｐ−ＡＰ２４１２はＭＮ２４１４にＱＵＥＲＹ情報を転送する。ＭＮ２４１４は、最適な経路（２番目に最適な経路かプレディクティブ経路のどちらか）を決定し選択することが可能である。例えば、図３７に示すように、ＭＮ２４１４はプレディクティブ経路を選択し、プレディクティブ経路上にＲＥＳＥＲＶＥ３７３６を送信する。

なお、図３８に示すように、ＣＲＮ２４０４は、ＰＡＳＳＩＶＥ予約を予約に変えるために２番目に最適な経路上にメッセージを送信するようＣＮ２４００に伝えるＰＲＥ−ＴＥＡＲ３８３４をＣＮ２４００に向けて送信することができる。例えば、これは、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ若しくはＲＥＳＥＲＶＥに対するＲＥＳＰＯＮＳＥ３８３６になり得る。この場合において、ＭＮ２４１４がプレディクティブ経路に新たなＲＥＳＥＲＶＥを送信すると、ＭＮ２１２４がプレディクティブ経路にスイッチバックさせることができる。

若しくは、ＣＲＮ２４０４は、プレディクティブ経路にＱＵＥＲＹを送信した後、ＰＲＥ−ＴＥＡＲを送信する前に短い時間待つことが可能である。ＭＮがＰ−ＡＰに接続することができ、ＲＥＳＥＲＶＥを早く（即座に）送信する場合、２番目に最適な経路へのスイッチを避けることができる。

２つ目のシナリオは、図３９に示すように、ＭＮ２４１４がＱＵＥＲＹ３９０６とＱＵＥＲＹ３９１４を受信する前にＰＲＥ−ＴＥＡＲ３９１２を送信する。本シナリオにおいて、ＰＲＥ−ＴＥＡＲ受信経路とプレディクティブ経路の間のＣＲＮ２４０４は、プレディクティブＡＰ２４１２に向けてＱＵＥＲＹ３９１８を送信する。ＰＲＥ−ＴＥＡＲを送信した後、ＭＮ２４１４は経路を選択するためにＱＵＥＲＹの受信に関して長い時間をセットすることも可能である。

さらに、ＰＲＥ−ＴＥＡＲ３９１２を受信したＱＮＥ２４１０は、オプションとして、ＭＮ２４１４に向けてＱＵＥＲＹ３９１４を転送してもよい。これは、ＰＲＥ−ＴＥＡＲ３９１２がＭＮ２４１４からプレディクション（予測）に基づいて送信されるのみだからである（常に正確ではないからである）。

なお、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。

本発明に係るＱｏＳリソース予約方法及びその方法で用いられる移動端末は、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるため、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末などに有用である。

本発明は、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末に関する。

パケットスイッチの通信ネットワークにおいて、ＭＮ（Mobile Node）は通信相手であるＣＮ（Corresponding Node）と通信することが可能である。下記の非特許文献１に記載されているように、通信におけるＱｏＳリソースを予約するため、ＭＮはＱＵＥＲＹメッセージ（以下、単にＱＵＥＲＹとも言う）を送信し、ＭＮからＣＮまでの経路が利用可能な十分なＱｏＳリソースを有しているならば、ＣＮはＲＥＳＥＲＶＥメッセージ（以下、単にＲＥＳＥＲＶＥとも言う）を送信し、ＭＮはそのＲＥＳＥＲＶＥメッセージを受信する。
J. Manner (ed.), "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-11, June 2006 G. Ash (ed.), "QoS NSLP QSPEC Template", Internet Draft draft-ietf-nsis-qspec-14, January 2007 T. Sanda (ed.), "Path type support for NSIS signaling", Internet Draft draft-sanda-nsis-path-type-03.txt, October 24, 2005 国際公開公報ＷＯ２００６／０４１１８３ 国際公開公報ＷＯ２００７／０６１１１８

ＱＵＥＲＹ処理が進行中にマルチホームのＭＮがハンドオーバすると、ＭＮは、ＱＵＥＲＹ処理をハンドオーバ後に再度行うため、ＱｏＳ予約の構築において遅延が生じる。この問題を解決する方法の１つとして、ＭＮにＱＵＥＲＹの結果（最適な経路の情報及び２番目に最適な経路の情報を含む）をＢＩＣＡＳＴ（２つの異なる経路、すなわち最適な経路及び２番目に最適な経路に送信）する。これにより、ＭＮは、最適な経路のインタフェースがハンドオーバしたならば、２番目に最適な経路のインタフェースを介してＱＵＥＲＹ処理の結果を受信することができる。このとき、経路（２番目に最適な経路）に予約はされない。しかし、この方法では、別のＲＥＳＥＲＶＥが２番目に最適な経路に送信される必要があるため、ＱｏＳ経路の構築において遅延が未だに生じる。

また、他の解決方法の１つとして、２番目に最適な経路における予約処理を促進させるために、２番目の最適な経路を通じてＭＮへＱＵＥＲＹの結果を送信すると同時にPassive予約を２番目に最適な経路上にする。２番目に最適な経路上にPassive予約の状態がインストールされることにより、後で必要となれば、予約処理が促進される。しかし、最適な経路に接続したインタフェースがハンドオーバする場合、選択された／最適な経路上のＱｏＳリソースの浪費になる。なぜなら、選択された経路上におけるＱｏＳ予約状態は、ＱＮＥのソフトステートタイマーが終了した後に取り除かれるだけであるからである。

本発明は、上記の問題点に鑑み、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるＱｏＳリソース予約方法及びその方法で用いられる移動端末を提供することを目的とする。

上記目的を達成するために、本発明によれば、移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを前記通信端末に向けて送信するステップと、前記移動端末が、前記ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを前記ハンドオーバ前の前記自身から前記通信端末までの経路に送信するステップとを、有するＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が複数のインタフェースを有する場合、前記移動端末が、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含めることは、本発明の好ましい態様である。この構成により、ＱｏＳ予約の構築による遅延を防ぐことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が複数のインタフェースを有する場合、前記移動端末が、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続する中継ノードの情報を前記第２のメッセージに含め、前記第２のメッセージを受信する前記中継ノードが、自身が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差するクロスオーバノードであるか否かを判断し、前記クロスオーバノードであると判断した場合、前記第２の経路における前記ＱｏＳリソースの予約をするための情報と、前記ハンドオーバしなかったインタフェースから前記通信端末までの第３の経路における前記ＱｏＳリソースの予約をするための情報とを比較した結果に基づいて、最適な経路に前記ＱｏＳリソースの予約がなされるための処理を行うことは、本発明の好ましい態様である。この構成により、より最適な経路にＱｏＳリソースを予約することができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第２のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第３のメッセージを送信するステップを、有するＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、前記通信端末が、前記ハンドオーバする旨を伝えるための前記メッセージに基づいて、前記ハンドオーバするインタフェースの接続先の中継ノードに前記ＱｏＳリソースの予約をするための情報を収集するメッセージを送信し、前記移動端末が、前記通信端末から受信するメッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が、前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに、前記ＱｏＳリソースの予約をさせる第２のメッセージ及び前記ＱｏＳリソースの予約準備を促す第３のメッセージを送信するステップと、前記移動端末が、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信するステップと、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差する中継ノードであるクロスオーバノードが、前記ＱｏＳリソースの予約をするための情報を収集するメッセージを前記ハンドオーバ先で接続する中継ノードに送信するステップと、前記移動端末が、前記ハンドオーバ先で接続する中継ノードから受信する前記メッセージに基づいて、前記準最適経路と前記第２の経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信するステップとを、備えるＱｏＳリソース予約方法が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明のＱｏＳリソース予約方法において、前記クロスオーバノードが、所定の期間が経過した場合、前記第２の経路を使用することができない旨を含む前記第４のメッセージを前記通信端末に送信し、前記通信端末が、受信する前記第４のメッセージに基づいて、前記ＱｏＳリソースの予約をさせるメッセージを前記準最適経路に送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明のＱｏＳリソース予約方法において、前記移動端末が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第４のメッセージを送信する場合、前記移動端末が、所定の期間が経過した場合、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択し、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、移動端末と前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを生成するメッセージ生成手段と、生成された前記第１のメッセージを前記通信端末に向けて送信する送信手段と、前記ＱｏＳリソースの予約処理の間に前記移動端末自身がハンドオーバしたか否かを判断する判断手段とを備え、前記判断手段によって前記移動端末自身がハンドオーバしたと判断された場合、前記メッセージ生成手段が、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを生成し、前記送信手段が、前記第２のメッセージを前記ハンドオーバ前の前記移動端末自身から前記通信端末までの経路に送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記移動端末が複数のインタフェースを有する場合、前記メッセージ生成手段が、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含めることは、本発明の好ましい態様である。この構成により、ＱｏＳ予約の構築による遅延を防ぐことができる。

また、本発明の移動端末において、前記移動端末が複数のインタフェースを有する場合、前記メッセージ生成手段が、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続するノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードの情報を前記第２のメッセージに含めることは、本発明の好ましい態様である。この構成により、より最適な経路にＱｏＳリソースを予約することができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、前記第１のメッセージを受信する受信手段とを備え、前記送信手段が、前記第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第３のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に、前記メッセージ生成手段によって生成された前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記送信手段が、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、前記受信手段が、前記ハンドオーバするインタフェースの接続先のノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードへ前記通信端末によって送信された前記ＱｏＳリソースの予約をするための情報を収集するメッセージを受信し、前記メッセージ生成手段が、受信された前記メッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、前記送信手段が、生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明の移動端末において、前記受信手段が前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記送信手段が前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記メッセージ生成手段が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、前記送信手段が、生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

また、本発明によれば、複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、前記第１のメッセージを受信する受信手段とを備え、前記メッセージ生成手段が、前記第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに対して、前記ＱｏＳリソースの予約をさせる第３のメッセージ及び前記ＱｏＳリソースの予約準備を促す第４のメッセージを生成し、前記送信手段が、前記第３のメッセージ及び前記第４のメッセージを送信し、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための前記メッセージ生成手段によって生成された第５のメッセージを送信し、前記ハンドオーバ先で接続する中継ノードから受信する前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて、前記準最適経路と前記ハンドオーバ後の前記インタフェースから前記通信端末までの経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信する移動端末が提供される。この構成により、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

また、本発明の移動端末において、前記受信手段が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第５のメッセージを送信する場合、所定の期間が経過した場合に、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択する判断手段を更に備え、前記メッセージ生成手段が、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを生成し、前記送信手段が生成された前記メッセージを送信することは、本発明の好ましい態様である。この構成により、より効率的にＱｏＳリソースの予約を行うことができる。

本発明のＱｏＳリソース予約方法及びその方法で用いられる移動端末は、上記構成を有し、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができる。

＜第１の実施の形態＞
図１に示すように、ＭＮ１１０は、１つのネットワークインタフェースを有しており、ＱＮＥ（ＱｏＳ ＮＳＩＳ Ｅｎｔｉｔｙ）１０８、ＱＮＥ１０６、ＱＮＥ１０４、ＱＮＥ１０２を通じる通信ネットワークを介してＣＮ１００と接続している。

ＭＮ１１０がＣＮ１００にデータを送信したい場合、ＭＮ１１０は、経路上の利用可能なＱｏＳを見つけるために、図２に示すように、ＣＮ１００に向けてＱＵＥＲＹメッセージ２００（以下、単にＱＵＥＲＹとも言う）を送信する。

ＱＵＥＲＹメッセージは、上述した非特許文献２で定義された形式をとることが可能である。ＱＵＥＲＹメッセージのフォーマットの一例を図３に示す。ＱＵＥＲＹメッセージはデータ経路に沿って利用可能なＱｏＳ情報を収集する。

ＱＵＥＲＹメッセージ２０８を受信したＣＮ１００は、ＲＥＳＥＲＶＥメッセージ（以下、単にＲＥＳＥＲＶＥとも言う）を生成し、図２に示すように、ＭＮ１１０からＣＮ１００へ送信されたＱＵＥＲＹメッセージが通った同じ経路に沿って生成されたＲＥＳＥＲＶＥメッセージ２１０をＭＮ１１０へ送信する。

ＲＥＳＥＲＶＥメッセージのパラメータは非特許文献２に定義されている。ＲＥＳＥＲＶＥメッセージはデータ経路上の中間に位置するＱＮＥ１０２、１０４、１０６、１０８でＱｏＳ予約をするものである。ＲＥＳＥＲＶＥメッセージのフォーマットの一例を図４に示す。

ＱｏＳ予約処理の間に、ＭＮ１１０が、ネットワークのアクセスポイント（ＡＰ：Access Point）を介したネットワーク接続が間もなく変更するとわかると、ＭＮ１１０（若しくはＭＮ１１０に隣接するＱＮＥ）はＡＰの変更／ハンドオーバが実際に起こる前に、その経路上のＣＮ１００にメッセージを送信する。このメッセージはＰＲＥ−ＴＥＡＲメッセージ（以下、単にＰＲＥ−ＴＥＡＲとも言う）と呼ぶ。ＰＲＥ−ＴＥＡＲは以下の要素から構成される。

ＰＲＥ−ＴＥＡＲ：＝メッセージタイプ識別情報
セッションＩＤ
フローＩＤ

メッセージタイプ識別情報（MESSAGE TYPE IDENTIFIER）５０１はＰＲＥ−ＴＥＡＲを示す際に用いられる。セッションＩＤ（SESSION ID）５０２は、ＣＮ１００によって送信されるＲＥＳＥＲＶＥメッセージのものと同じものである（先にＭＮ１１０によって送信されたＱＵＥＲＹのものと同じ）。フローＩＤ（FLOW ID）５０３は先にこの経路に送信されたＱＵＥＲＹのものと同じである。ここで、ＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を図５に示す。ＰＲＥ−ＴＥＡＲは、ハンドオーバしようとする経路（ハンドオーバする直前につながっている経路）上に予約されたＱｏＳリソースを取り除く機能を有する。

図６はＭＮの機能ブロックの一例を示す。ＭＮは、受信手段６０６、送信手段６０２、ＱｏＳ予約機能手段６００、Ｐｒｅ−Ｔｅａｒ生成機能手段６０４から構成されている。Ｐｒｅ−Ｔｅａｒ生成機能手段６０４は、ＰＲＥ−ＴＥＡＲメッセージを生成し、送信手段６０２に送信させる。図７はＭＮとＣＮとの間に位置する中間のＱＮＥ１０２、１０４、１０６、１０８などの機能ブロックの一例を示す。ＱＮＥは、送信手段７０２、受信手段７０６、ＱｏＳ予約機能手段７００、Ｐｒｅ−Ｔｅａｒ処理機能手段７０４から構成されている。

ＱＮＥがＰＲＥ−ＴＥＡＲを受信すると、ＱＮＥは、図７の機能ブロック図に示されるＰｒｅ−Ｔｅａｒ処理機能手段７０４によってＰｒｅ−Ｔｅａｒ処理を実行する。ＰＲＥ−ＴＥＡＲの処理の一例を図８に示す。図８に示すように、ＰＲＥ−ＴＥＡＲがＱＮＥに受信されると（ステップＳ８０１）、ＱＮＥは、ＰＲＥ−ＴＥＡＲに含まれるセッションＩＤとフローＩＤのコンビネーションに相当するＱｏＳ予約状態が既にインストールされているかをチェックする（ステップＳ８０２）。

そのようなセッションＩＤとフローＩＤのＱｏＳ予約状態が存在しない場合、そのセッションＩＤとフローＩＤに相当するその後のＲＥＳＥＲＶＥメッセージを破棄するために、Ｐｒｅ−Ｔｅａｒ状態がインストールされ、ＰＲＥ−ＴＥＡＲがＣＮ１００に向けて次のＱＮＥに転送される（ステップＳ８０６）。一方、そのようなセッションＩＤとフローＩＤのＱｏＳ予約状態がＱＮＥ上に存在する場合、ＱｏＳ予約は取り除かれ、ＱＮＥは、図９に示すように、自身からＣＮ１００に向けたデータ経路上のＱＮＥ上のそのセッションＩＤとフローＩＤにおけるＱｏＳ予約を取り除くためにメッセージを送信する（ステップＳ８０４）。

このメッセージは、ＣＮ１００に向かうこのＱＮＥで生成されたＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲメッセージ９２０（非特許文献１を参照）になり、ＣＮ１００に至るまでのすべての経路に転送される。なお、ＱＮＥは、ステップＳ８０４において、存在するＱｏＳ予約状態を取り除いた後、図１０に示すように、受信したＰＲＥ−ＴＥＡＲ１０１４をＣＮ１００に向けて次のＱＮＥに転送するようにしてもよい。ＰＲＥ−ＴＥＡＲ１０２０が、ＣＮ１００に向けたデータ経路上の次のＱＮＥによって受信されると、上述した同じ処理が実行される。

図１１はＣＮの機能ブロックの一例を示す。ＣＮは、送信手段１１０２、受信手段１１０６、ＱｏＳ予約応答機能手段１１００、Ｐｒｅ−Ｔｅａｒ処理機能手段１１０４から構成されている。ＣＮ１００がＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲメッセージを受信すると、ＱｏＳ予約応答機能手段１１００は、ＱｏＳ状態を取り除き、必要であればＲＥＳＰＯＮＳＥメッセージ（非特許文献１を参照）を送信する。ＣＮ１００がＰＲＥ−ＴＥＡＲメッセージを受信すると、Ｐｒｅ−Ｔｅａｒ処理機能手段１１０４は、ＱｏＳ状態を取り除くトリガを行い、今後、そのＳＩＤとＦＩＤのペアに相当するＲＥＳＥＲＶＥメッセージによるＣＮ１００での予約を防ぐためのｐｒｅ−ｔｅａｒ状態をインストールする。

ステップＳ８０４において、ＱＮＥは、インストールされたＱｏＳ予約を取り除く代わりに、ＣＮ１００に向けてＰＲＥ−ＴＥＡＲを転送することも可能である。この場合、ＱＮＥはＰＲＥ−ＴＥＡＲ内に状態が除かれないことを示す付加的な指示情報を挿入する。ＣＮ１００がＰＲＥ−ＴＥＡＲメッセージを受け取り、そのような指示情報が検出されると、ＣＮ１００のＰｒｅ−Ｔｅａｒ処理機能手段１１０４は、図１２に示すように、相当するＱｏＳ予約状態を取り除くために別のメッセージ（ＲＥＳＥＲＶＥ−ｗｉｔｈ−ＴＥＡＲ１２２４）をＭＮ１１０に向けて送信する。

図１３は他のネットワーク構成を示す。この場合、ＭＮ１３１４は、ＣＮ１３００と複数の接続を有しており、ＭＮ１３１４は、図１４に示すように、ＣＮ１３００に向けて複数のＱＵＥＲＹ１４００、１４０２、１４０４を送信する。それぞれのＱＵＥＲＹはＭＮ１３１４からＣＮ１３００まで流れ、それぞれの経路上のＱｏＳ情報を収集する。

ＣＮ１３００若しくは様々な経路のＣＲＮ（CRossover Node）は、ＭＮ１３１４によってＱＵＥＲＹの中に明示された基準に基づいて最適な経路を選択し、その経路にＲＥＳＥＲＶＥ１４１８若しくはアグリゲートされた（集められた）ＱＵＥＲＹ結果を送信する。このとき、ＣＮ１３００は、ＱＵＥＲＹ１４００、１４０２、１４０４を受信し、最適な経路（例えば、ＣＮ１３００からＱＮＥ１３０２、１３０８を経由するＭＮ１３１４までの経路）を選択する。選択の際、例えば、ＣＮ１３００が受信したＱＵＥＲＹ１４００、１４０２、１４０４を格納し、すべてのＱＵＥＲＹが届くまで、若しくは時間Ｔが経過するまでに決定をする。

ＣＮ１３００がＲＥＳＥＲＶＥを送信する経路上のＭＮ１３１４のインタフェースがハンドオーバする場合、ＱＵＥＲＹ処理（ＭＮ１３１４のすべてのインタフェースからＱＵＥＲＹを送信する処理）は、ＭＮ１３１４によって再度行われる必要がある。これは、ＭＮ１３１４がＲＥＳＥＲＶＥやＱＵＥＲＹの結果を受信することができないからである。ＭＮ１３１４におけるＣＮ１３００との他の接続が変更せずに残っていたとしても、ＱＵＥＲＹの結果が失われるため、ＭＮ１３１４は即座にＱｏＳ予約を開始することができない。そのような中断は以下のようにすることで回避することができる。

すなわち、ＭＮ１３１４は、最適な経路側のインタフェースがハンドオーバした場合に２番目に最適な経路にトラフィックを向けることができるように、バックアップ経路を選択し、その経路にＱＵＥＲＹ処理の結果を送信することをＣＮ１３００に指示する。すなわち、ＭＮ１３１４がＱＵＥＲＹにＢＩＣＡＳＴフラグをセットすることによりなされる。さらに、ＭＮ１３１４は、トラフィックを２番目に最適な経路に向ける必要がある場合に、ＭＮ１３１４が早急にＱｏＳ予約をすることができるように、２番目に最適な経路にＰＡＳＳＩＶＥ予約を構築することをＣＮ１３００に指示する。ＭＮ１３１４はＰＡＳＳＩＶＥ予約フラグをＱＵＥＲＹにセットする。

改良として、ＱＵＥＲＹの中のＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグは、１つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグとを合わせたフラグ）に置き換えられることが可能である。１つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグとを合わせたフラグ）は、ＰＡＳＳＩＶＥ予約を構築する２番目に最適な経路に沿ってＱＵＥＲＹ処理の結果を送信することをＣＮ１３００に知らせるためのものである。

上述の処理をサポートするＭＮの一例の構成が図１５に示されている。図６に示すＭＮの構成と比較すると、上述したフラグをＱＵＥＲＹにセットするPassive予約機能手段１５０２が付加されている。また、上述の処理をサポートするＣＮの一例の構成が図１６に示されている。図１１に示すＣＮの構成と比較すると、上述したフラグがセットされたＱＵＥＲＹを処理するPassive予約機能手段１６０２が付加されている。

上述の処理の修正ＱＵＥＲＹメッセージのフォーマットの一例が図１７に示されている。修正ＱＵＥＲＹメッセージは、ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグ（BICAST&PASSIVE RESERVEATION FLAG）１７０１を含む。また、必要とするシナリオにおいてパスタイプＩＤ１７０２（特許文献１を参照）を含むこともある。

修正ＱＵＥＲＹがＣＮ１３００に到達すると、ＣＮ１３００は、それぞれの経路で利用可能なＱｏＳ（ＱＵＥＲＹによって収集された情報）又はＭＮ１３１４によって明示された他の基準に基づいて、個々のＱＵＥＲＹが通った経路のランク付けをする。２つのフラグ（ＢＩＣＡＳＴフラグとＰＡＳＳＩＶＥ予約フラグ）がＱＵＥＲＹの中に存在する場合、ＣＮ１３００は、相当するＱＵＥＲＹに記述された最も高いＱｏＳを有する２つの経路、又はＭＮ１３１４によって明示された基準による２つの経路を選択する。ＣＮ１３００は、図１８に示すように、利用可能なＱｏＳが最も高い経路にＲＥＳＥＲＶＥ１８１８を送信し、２番目に最適なＱｏＳを有する経路にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ１８２４を送信する。

ここでのＲＥＳＥＲＶＥメッセージのフォーマットの一例が図１９に示されている。ＲＥＳＥＲＶＥメッセージは、非特許文献１に記載のフィールドに加え、さらにパスタイプＩＤ（PATH TYPE ID）１９０１（特許文献１を参照）、ＱＵＥＲＹの結果（QUERY RESULT）１９０２を付加したものである。パスタイプＩＤ１９０１はオプションである。ＱＵＥＲＹの結果１９０２は最適な経路及び２番目に最適な経路の情報を含む。

また、ここでのＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージのフォーマットの一例が図２０に示されている。ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージは、非特許文献１に記載のフィールドに加え、さらにＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージタイプ（PASSIVE RESERVE MESSAGE TYPE）２００１、パスタイプＩＤ（PATH TYPE ID）２００２（特許文献１を参照）、ＱＵＥＲＹの結果（QUERY RESULT）２００３を付加したものである。

上述の処理をサポートするＱＮＥの構成の一例が図２１に示されている。図７に示すＱＮＥと比較すると、Passive予約機能手段２１０２が付加されている。例えば、ＱＮＥがＣＮからＭＮへのＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを受信すると、Passive予約機能手段２１０２は、ＧＩＳＴ（General Internet Signaling Transport）状態の構築のみをする、若しくはＧＩＳＴ状態に沿って“ゼロ予約”（ＱｏＳパラメータ０での予約）のＱｏＳ ＮＳＬＰ状態を構築する。

ＱＵＥＲＹ処理が進行している間にＭＮ１３１４のインタフェースの１つがハンドオーバする場合、ＭＮ１３１４は、その経路（ハンドオーバするインタフェースからＣＮまでの経路）上にこれまで構築されたＱｏＳ予約を取り除くため、又は行われようとしている予約を事前に阻止するために、ＰＲＥ−ＴＥＡＲ２２２２を送信する。詳細なシグナリングが図２２に示されている。

ここで、ＣＮ１３００が２番目に最適な経路（本実施の形態ではＱＮＥ１３０４、１３１０）に既にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを送信しており、かつＭＮ１３１４で、選択された最適な経路（本実施の形態ではＱＮＥ１３０２、１３０８）の方のインタフェースがハンドオーバした場合、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ２２２８の中のＱＵＥＲＹ処理の結果を受ける。ＭＮ１３１４は、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ２２２８を受信した２番目に最適な経路に完全な予約を行うため、ＲＥＳＥＲＶＥ２２３０を送信する。

同じ予約におけるＲＥＳＥＲＶＥが双方の終端（例えば、送信側及び受信側）から送信されることが可能である場合、図２３に示すように、ＣＮ／ＣＲＮはＰＲＥ−ＴＥＡＲ２３２５を受信すると、ＲＥＳＥＲＶＥ２３３２を生成し、既にＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージを送った２番目に最適な経路にＲＥＳＥＲＶＥ２３３２を送信する。これにより、ＣＮ／ＣＲＮからのＲＥＳＥＲＶＥ２３３４がＭＮ１３１４からのＲＥＳＥＲＶＥ２３３０と途中（２番目に最適な経路上）で出会うため、２番目に最適な経路上のＱｏＳ予約を促進させることができる。

なお、インストールされたＰｒｅ−Ｔｅａｒ状態は、該当するＲＥＳＥＲＶＥ若しくはＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥを阻止した後、明示的に取り除かれてもよいし、また一定時間経った場合に取り除かれてもよい。

＜第２の実施の形態＞
他のシナリオとして図２４に示すように、データ方向がＭＮ２４１４からＣＮ２４００において、ＱＵＥＲＹ処理が進行中にＭＮ２４１４のインタフェースの１つがハンドオーバする場合、ＭＮ２４１４は、２番目に最適な経路にスイッチする可能性がある。しかし、ハンドオーバしたインタフェースを介した経路は、ＭＮ２４１４で残っているインタフェース（ハンドオーバしなかったインタフェース）を介したＭＮ２４１４からＣＮ２４００までの残りの経路と比較して、よりよいＱｏＳを有してＣＮ２４００に接続する可能性がある。

このような可能性（例えば、ハンドオーバした経路（ハンドオーバ後の経路）が、ＱＵＥＲＹ処理から選択される２番目に最適な経路と比較して、よりよいＱｏＳを有すること）を確かめるために、ＭＮ２４１４は、ハンドオーバ先アクセスポイントであるプレディクティブ（予想）アクセスポイント（Ｐ−ＡＰ）２４１２のロケーション／アドレスを何らかの手段によって知る。ＭＮ２４１４から送信されるＰＲＥ−ＴＥＡＲはＰ−ＡＰ２４１２についての情報（PREDICTIVE ACCESS POINT）２５０１を運ぶ。ここでのＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例が図２５に示されている。

図２６は上述する処理をサポートするＭＮの構成の一例を示す。このＭＮはプレディクティブ予約機能手段２６０８を含み、プレディクティブ予約機能手段２６０８はＰ−ＡＰについての情報を得ることができ、新たなＰＲＥ−ＴＥＡＲを生成する。図２７は上述する処理をサポートするＱＮＥの構成の一例を示す。このＱＮＥはプレディクティブ予約機能手段２７０８を含み、プレディクティブ予約機能手段２７０８は、Ｐ−ＡＰの情報を有するＰＲＥ−ＴＥＡＲを処理することができる。

ＰＲＥ−ＴＥＡＲ内のＰ−ＡＰの情報は、その経路上におけるＣＲＮ（ＱＮＥ）２４０４を見つけるのに役立つ。例えば、それぞれのＱＮＥはＰ−ＡＰに関するルーティング状態をチェックし、自身がＣＲＮであるか否かを判断する。なお、ＣＲＮ２４０４はあらかじめ決められたノードであってもよい。例えば、３Ｇ環境においては、オリジナルロケーションとＰ−ＡＰの双方を管理するゲートウェイであってもよい。詳細なシグナリング処理の一例が図２８に示されている。

図２８に示すように、ＣＲＮ（ＱＮＥ）２４０４がＰＲＥ−ＴＥＡＲ２８２２を受信すると、ＣＲＮ２４０４はＰ−ＡＰ２４１２にＴｒｉｇｇｅｒ ｆｏｒ ＱＵＥＲＹ（ＴＦＱ）２８２６を送信する。ＴＦＱに用いられるフォーマットの一例が図２９に示されている。ＴＦＱ２８２６を受信したＰ−ＡＰ２４１２は、ＣＮ２４００に向けてＱＵＥＲＹ２８２８を送信する。

ハンドオーバがなければ最適とされた経路とハンドオーバ先における経路（プレディクティブ経路）とが交差するＣＲＮ２４０４によってＱＵＥＲＹ２８２８がインタセプトされ、ＣＲＮ２４０４は、ＣＲＮ２４０４からＰ−ＡＰ２４１２までのプレディクティブ経路と２番目に最適な経路とで利用可能なＱｏＳを比較する。プレディクティブ経路における利用可能なＱｏＳが２番目に最適な経路における利用可能なＱｏＳより多い場合、ＣＲＮ（プレディクティブ経路のＣＲＮ）２４０４は、プレディクティブ経路にＲＥＳＥＲＶＥ２８３０を送信し、ＱＵＥＲＹ２８２８を破棄する。

一方、プレディクティブ経路における利用可能なＱｏＳが２番目に最適な経路における利用可能なＱｏＳより少ない場合、ＣＲＮ２４０４は、最適な経路（ハンドオーバがなければ最適とされた経路）と２番目に最適な経路との間におけるＣＲＮにＱＵＥＲＹを流す。図２４の例では、図３０に示すように、そのようなＣＲＮは存在せず、ＣＮ２４００はＰ−ＡＰ２４１２からのＱＵＥＲＹ３０３０を受信し、２番目に最適な経路上における利用可能なＱｏＳと比較し、２番目に最適な経路にＲＥＳＥＲＶＥ３０３２を送信する。

＜第３の実施の形態＞
図３１は、データ方向がＣＮ３１００からＭＮ３１１４の場合のシナリオである。このシナリオでのシグナリング処理の一例が図３２に示されている。図３２に示すように、ＭＮ３１１４はＣＮ３１００に向けてＴＲＩＧＧＥＲ ｆｏｒ ＱＵＥＲＹ（ＴＦＱ）３２００を送信する。ＴＦＱのフォーマットの一例が図３３に示されている。ＴＦＱ３２００は、通常のＱＵＥＲＹに含まれる情報に加え、さらにメッセージタイプＩＤ（TFQ MESSAGE TYPE IDENTIFIER）３３０１とＭＮ３１１４が有するすべてのインタフェースのアドレス（ADDRESS OF ALL INTERFACES OF MN）３３０２の２つの付加的なフィールドを含む。

ＴＦＱ３２００を受信するＣＮ３２００は、ＴＦＱ３２００にリストされた経路／インタフェースのそれぞれにＱＵＥＲＹを送信する。

ＭＮ３１１４が、ＭＮ３１１４のインタフェースの１つがハンドオーバしようとしていることを察知し、ＭＮ３１１４がそのインタフェースでＱＵＥＲＹをまだ受信していない場合、ＭＮ３１１４は、ＣＮ３１００にＯＦＦ ＰＡＴＨ ＰＲＥ−ＴＥＡＲ（ＯＰＰＴ）３２０１を送信する。ＯＰＰＴ３２０１は、ＴＦＱ３２００にリストされた経路の１つがハンドオーバしようとしている状態であることを伝えるためのものである。

そのインタフェース（ハンドオーバしようとしているインタフェース）のＩＰアドレスは、ＯＰＰＴ３２０１の“ハンディングオーバインタフェースアドレス”フィールドに示されている。ＯＰＰＴ３２０１はＣＮ３１００に直接送信されてもよい。ＯＰＰＴのフォーマットの一例が図３４に示されている。ＯＰＰＴはＲＥＳＥＲＶＥ ｗｉｔｈ ＴＥＡＲ（非特許文献１を参照）の情報を含み、さらにメッセージタイプＩＤ（OPPT MESSAGE TYPE IDENTIFIER）３４０１、ハンディングオーバインタフェースアドレス（HANDINGOVER INTERFACE ADDRESS）３４０２を含む。

ＣＮ３１００がＭＮ３１１４に向けてＱＵＥＲＹを送信する前にＯＰＰＴ３２０１を受信すると、ＣＮ３１００は、ＯＰＰＴ３２０１のハンディングオーバインタフェースアドレス３４０２のフィールドに示されるようなハンドオーバをすると予測される経路上にＱＵＥＲＹを送信することを禁じる。すべてのＱＵＥＲＹを受信するＭＮ３１１４は、最適な経路を選択し、最適な経路上にＲＥＳＥＲＶＥ３２１４を送信する。

図３５に示すように、ＭＮ３１１４がすべてのＱＵＥＲＹ３５０６、３５１２を受信した後でＲＥＳＥＲＶＥを送信する前にハンドオーバが起こることを知る場合、ＭＮ３１１４は、ハンドオーバしようとする経路を避けて（たとえ、最適な経路であっても）、最適な経路上（相当するＱＵＥＲＹにリストされた利用可能なＱｏＳのインタフェース）にＲＥＳＥＲＶＥ３５１４を送信する。

例えば、最適な経路がＣＮ３１００−ＱＮＥ３１０４−ＱＮＥ３１１０−ＭＮ３１１４であるが、その経路につながっているインタフェースがハンドオーバしようとしている場合、ＭＮ３１１４はその経路を選択せず、２番目に最適な経路、例えばＣＮ３１００−ＱＮＥ３１０２−ＱＮＥ３１０８−ＭＮ３１１４を選択する。そして、ＭＮ３１１４は、２番目に最適な経路（ＱＵＥＲＹ処理に基づいて、ＭＮにＣＮをつなぐすべての経路において比較した中で、２番目に最適な経路）上にＲＥＳＥＲＶＥ３５１４を送信する。

最後に、図３６に示すように、ＭＮ３１１４がインタフェース上（ＱＵＥＲＹに基づく最適な経路）にＲＥＳＥＲＶＥ３６１４を送信した後、ハンドオーバしそうであると認識すると、ＭＮ３１１４は選択された経路にＲＥＳＥＲＶＥ ｗｉｔｈ ＴＥＡＲ３６２６を送信する。そして、ＭＮ３１１４は、既に先に送信したＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ３６２０が通る２番目に最適な経路にＲＥＳＥＲＶＥ３６３２を送信する。

＜第４の実施の形態＞
データ方向がＣＮからＭＮの場合のシナリオについて図２４を参照する。ＱＵＥＲＹ処理がまだ進行中でＭＮ２４１４のインタフェースの１つがハンドオーバする場合、ＭＮ２４１４は、２番目に最適な経路にスイッチする可能性がある。しかし、ハンドオーバしたインタフェースは、ＭＮ２４１４で残っているインタフェース（ハンドオーバしなかったインタフェース）を介したＣＮ２４００からＭＮ２４１４までの残りの経路と比較して、よりよいＱｏＳを有する経路を介してＣＮ２４００に接続する可能性がある。

図３７はそのようなシナリオに本発明を適用するシグナリング処理の一例を示す。図３７に示すように、ＭＮ２４１４は、ＰＲＥ−ＴＥＡＲ３７２６にプレディクティブ（予測）アクセスポイント（Ｐ−ＡＰ）の位置（ロケーション）を埋め込む。そして、利用可能なＱｏＳをチェックするために、ＣＮ２４００又はＣＲＮ２４０４は、プレディクティブハンドオーバ経路にＱＵＥＲＹ３７３２を送信する。

ＰＲＥ−ＴＥＡＲが送信された場合に基づくシナリオは２つある。１つ目は、図３７に示すように、ＭＮ２４１４がＲＥＳＥＲＶＥ３７１４を送信した後に、ＰＲＥ−ＴＥＡＲ３７２６が送信された場合、ＣＲＮ（この場合、ＱＮＥ２４０４）はＰ−ＡＰ２４１２にＱＵＥＲＹ３７３２を送信する。ＭＮ２４１４がＰ−ＡＰ２４１２に接続すると、Ｐ−ＡＰ２４１２はＭＮ２４１４にＱＵＥＲＹ情報を転送する。ＭＮ２４１４は、最適な経路（２番目に最適な経路かプレディクティブ経路のどちらか）を決定し選択することが可能である。例えば、図３７に示すように、ＭＮ２４１４はプレディクティブ経路を選択し、プレディクティブ経路上にＲＥＳＥＲＶＥ３７３６を送信する。

なお、図３８に示すように、ＣＲＮ２４０４は、ＰＡＳＳＩＶＥ予約を予約に変えるために２番目に最適な経路上にメッセージを送信するようＣＮ２４００に伝えるＰＲＥ−ＴＥＡＲ３８３４をＣＮ２４００に向けて送信することができる。例えば、これは、ＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥ若しくはＲＥＳＥＲＶＥに対するＲＥＳＰＯＮＳＥ３８３６になり得る。この場合において、ＭＮ２４１４がプレディクティブ経路に新たなＲＥＳＥＲＶＥを送信すると、ＭＮ２１２４がプレディクティブ経路にスイッチバックさせることができる。

若しくは、ＣＲＮ２４０４は、プレディクティブ経路にＱＵＥＲＹを送信した後、ＰＲＥ−ＴＥＡＲを送信する前に短い時間待つことが可能である。ＭＮがＰ−ＡＰに接続することができ、ＲＥＳＥＲＶＥを早く（即座に）送信する場合、２番目に最適な経路へのスイッチを避けることができる。

２つ目のシナリオは、図３９に示すように、ＭＮ２４１４がＱＵＥＲＹ３９０６とＱＵＥＲＹ３９１４を受信する前にＰＲＥ−ＴＥＡＲ３９１２を送信する。本シナリオにおいて、ＰＲＥ−ＴＥＡＲ受信経路とプレディクティブ経路の間のＣＲＮ２４０４は、プレディクティブＡＰ２４１２に向けてＱＵＥＲＹ３９１８を送信する。ＰＲＥ−ＴＥＡＲを送信した後、ＭＮ２４１４は経路を選択するためにＱＵＥＲＹの受信に関して長い時間をセットすることも可能である。

さらに、ＰＲＥ−ＴＥＡＲ３９１２を受信したＱＮＥ２４１０は、オプションとして、ＭＮ２４１４に向けてＱＵＥＲＹ３９１４を転送してもよい。これは、ＰＲＥ−ＴＥＡＲ３９１２がＭＮ２４１４からプレディクション（予測）に基づいて送信されるのみだからである（常に正確ではないからである）。

なお、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。

本発明に係るＱｏＳリソース予約方法及びその方法で用いられる移動端末は、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるため、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末などに有用である。

本発明の第１の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第１の実施の形態におけるＱｏＳリソース予約のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱＵＥＲＹメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態に係るＭＮの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱＮＥの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱＮＥでのＰＲＥ−ＴＥＡＲの処理フローの一例を示すフローチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＣＮの構成の一例を示す構成図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態における通信ネットワークの他の一例を示すネットワーク図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態に係るＭＮの構成の他の一例を示す構成図 本発明の第１の実施の形態におけるＣＮの構成の他の一例を示す構成図 本発明の第１の実施の形態における修正ＱＵＥＲＹメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの他の一例を示す図 本発明の第１の実施の形態におけるＰＡＳＳＩＶＥ ＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図 本発明の第１の実施の形態におけるＱＮＥの構成の他の一例を示す構成図 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第２、４の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第２の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図 本発明の第２の実施の形態に係るＭＮの構成の一例を示す構成図 本発明の第２の実施の形態におけるＱＮＥの構成の一例を示す構成図 本発明の第２の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第２の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図 本発明の第２の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態における通信ネットワークの一例を示すネットワーク図 本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図 本発明の第３の実施の形態におけるＯＰＰＴのフォーマットの一例を示す図 本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第３の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート 本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート

Claims (17)

1. 移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
   前記移動端末が、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを前記通信端末に向けて送信するステップと、
   前記移動端末が、前記ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを前記ハンドオーバ前の前記自身から前記通信端末までの経路に送信するステップとを、
   有するＱｏＳリソース予約方法。
2. 前記移動端末が複数のインタフェースを有する場合、
   前記移動端末は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１に記載のＱｏＳリソース予約方法。
3. 前記移動端末が複数のインタフェースを有する場合、
   前記移動端末は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続する中継ノードの情報を前記第２のメッセージに含め、
   前記第２のメッセージを受信する前記中継ノードは、自身が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差するクロスオーバノードであるか否かを判断し、前記クロスオーバノードであると判断した場合、前記第２の経路における前記ＱｏＳリソースの予約をするための情報と、前記ハンドオーバしなかったインタフェースから前記通信端末までの第３の経路における前記ＱｏＳリソースの予約をするための情報とを比較した結果に基づいて、最適な経路に前記ＱｏＳリソースの予約がなされるための処理を行う請求項１に記載のＱｏＳリソース予約方法。
4. 複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
   前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第２のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第３のメッセージを送信するステップを、
   有するＱｏＳリソース予約方法。
5. 前記移動端末は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
   前記通信端末は、前記ハンドオーバする旨を伝えるための前記メッセージに基づいて、前記ハンドオーバするインタフェースの接続先の中継ノードに前記ＱｏＳリソースの予約をするための情報を収集するメッセージを送信し、
   前記移動端末は、前記通信端末から受信するメッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
6. 前記移動端末は、前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
7. 複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
   前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに、前記ＱｏＳリソースの予約をさせる第２のメッセージ及び前記ＱｏＳリソースの予約準備を促す第３のメッセージを送信するステップと、
   前記移動端末が、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信するステップと、
   前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差する中継ノードであるクロスオーバノードが、前記ＱｏＳリソースの予約をするための情報を収集するメッセージを前記ハンドオーバ先で接続する中継ノードに送信するステップと、
   前記移動端末が、前記ハンドオーバ先で接続する中継ノードから受信する前記メッセージに基づいて、前記準最適経路と前記第２の経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信するステップとを、
   備えるＱｏＳリソース予約方法。
8. 前記クロスオーバノードは、所定の期間が経過した場合、前記第２の経路を使用することができない旨を含む前記第４のメッセージを前記通信端末に送信し、
   前記通信端末は、受信する前記第４のメッセージに基づいて、前記ＱｏＳリソースの予約をさせるメッセージを前記準最適経路に送信する請求項７に記載のＱｏＳリソース予約方法。
9. 前記移動端末が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第４のメッセージを送信する場合、
   前記移動端末は、所定の期間が経過した場合、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択し、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを送信する請求項７に記載のＱｏＳリソース予約方法。
10. 移動端末と前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
    前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを生成するメッセージ生成手段と、
    生成された前記第１のメッセージを前記通信端末に向けて送信する送信手段と、
    前記ＱｏＳリソースの予約処理の間に前記移動端末自身がハンドオーバしたか否かを判断する判断手段とを備え、
    前記判断手段によって前記移動端末自身がハンドオーバしたと判断された場合、前記メッセージ生成手段が、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを生成し、
    前記送信手段が、前記第２のメッセージを前記ハンドオーバ前の前記移動端末自身から前記通信端末までの経路に送信する移動端末。
11. 前記移動端末が複数のインタフェースを有する場合、
    前記メッセージ生成手段は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１０に記載の移動端末。
12. 前記移動端末が複数のインタフェースを有する場合、
    前記メッセージ生成手段は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続するノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードの情報を前記第２のメッセージに含める請求項１０に記載の移動端末。
13. 複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
    前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
    生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
    前記第１のメッセージを受信する受信手段とを備え、
    前記送信手段が、前記第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第３のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に、前記メッセージ生成手段によって生成された前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信する移動端末。
14. 前記送信手段は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
    前記受信手段は、前記ハンドオーバするインタフェースの接続先のノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードへ前記通信端末によって送信された前記ＱｏＳリソースの予約をするための情報を収集するメッセージを受信し、
    前記メッセージ生成手段は、受信された前記メッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
    前記送信手段は、生成された前記メッセージを送信する請求項１３に記載の移動端末。
15. 前記受信手段が前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記送信手段が前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、
    前記メッセージ生成手段は、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
    前記送信手段が、生成された前記メッセージを送信する請求項１３に記載の移動端末。
16. 複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
    前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
    生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
    前記第１のメッセージを受信する受信手段とを備え、
    前記メッセージ生成手段が、前記第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに対して、前記ＱｏＳリソースの予約をさせる第３のメッセージ及び前記ＱｏＳリソースの予約準備を促す第４のメッセージを生成し、
    前記送信手段が、前記第３のメッセージ及び前記第４のメッセージを送信し、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための前記メッセージ生成手段によって生成された第５のメッセージを送信し、前記ハンドオーバ先で接続する中継ノードから受信する前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて、前記準最適経路と前記ハンドオーバ後の前記インタフェースから前記通信端末までの経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信する移動端末。
17. 前記受信手段が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第５のメッセージを送信する場合、
    所定の期間が経過した場合に、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択する判断手段を更に備え、
    前記メッセージ生成手段が、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを生成し、
    前記送信手段が生成された前記メッセージを送信する請求項１６に記載の移動端末。

Images