(57)【要約】  ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるＱｏＳリソース予約方法などを提供する技術が開示され、その技術によれば移動端末１１０が、ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを通信端末１００に向けて送信するステップと、移動端末が、ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、ＱｏＳリソースの予約を取り除くための第２のメッセージをハンドオーバ前の自身から通信端末までの経路に送信するステップとを有する。
2009037843.tif 000002
【特許請求の範囲】
【請求項１】
移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを前記通信端末に向けて送信するステップと、
前記移動端末が、前記ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを前記ハンドオーバ前の前記自身から前記通信端末までの経路に送信するステップとを、
有するＱｏＳリソース予約方法。
【請求項２】
前記移動端末が複数のインタフェースを有する場合、
前記移動端末は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１に記載のＱｏＳリソース予約方法。
【請求項３】
前記移動端末が複数のインタフェースを有する場合、
前記移動端末は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続する中継ノードの情報を前記第２のメッセージに含め、
前記第２のメッセージを受信する前記中継ノードは、自身が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差するクロスオーバノードであるか否かを判断し、前記クロスオーバノードであると判断した場合、前記第２の経路における前記ＱｏＳリソースの予約をするための情報と、前記ハンドオーバしなかったインタフェースから前記通信端末までの第３の経路における前記ＱｏＳリソースの予約をするための情報とを比較した結果に基づいて、最適な経路に前記ＱｏＳリソースの予約がなされるための処理を行う請求項１に記載のＱｏＳリソース予約方法。
【請求項４】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第２のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第３のメッセージを送信するステップを、
有するＱｏＳリソース予約方法。
【請求項５】
前記移動端末は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
前記通信端末は、前記ハンドオーバする旨を伝えるための前記メッセージに基づいて、前記ハンドオーバするインタフェースの接続先の中継ノードに前記ＱｏＳリソースの予約をするための情報を収集するメッセージを送信し、
前記移動端末は、前記通信端末から受信するメッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
【請求項６】
前記移動端末は、前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
【請求項７】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに、前記ＱｏＳリソースの予約をさせる第２のメッセージ及び前記ＱｏＳリソースの予約準備を促す第３のメッセージを送信するステップと、
前記移動端末が、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信するステップと、
前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差する中継ノードであるクロスオーバノードが、前記ＱｏＳリソースの予約をするための情報を収集するメッセージを前記ハンドオーバ先で接続する中継ノードに送信するステップと、
前記移動端末が、前記ハンドオーバ先で接続する中継ノードから受信する前記メッセージに基づいて、前記準最適経路と前記第２の経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信するステップとを、
備えるＱｏＳリソース予約方法。
【請求項８】
前記クロスオーバノードは、所定の期間が経過した場合、前記第２の経路を使用することができない旨を含む前記第４のメッセージを前記通信端末に送信し、
前記通信端末は、受信する前記第４のメッセージに基づいて、前記ＱｏＳリソースの予約をさせるメッセージを前記準最適経路に送信する請求項７に記載のＱｏＳリソース予約方法。
【請求項９】
前記移動端末が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第４のメッセージを送信する場合、
前記移動端末は、所定の期間が経過した場合、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択し、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを送信する請求項７に記載のＱｏＳリソース予約方法。
【請求項１０】
移動端末と前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを生成するメッセージ生成手段と、
生成された前記第１のメッセージを前記通信端末に向けて送信する送信手段と、
前記ＱｏＳリソースの予約処理の間に前記移動端末自身がハンドオーバしたか否かを判断する判断手段とを備え、
前記判断手段によって前記移動端末自身がハンドオーバしたと判断された場合、前記メッセージ生成手段が、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを生成し、
前記送信手段が、前記第２のメッセージを前記ハンドオーバ前の前記移動端末自身から前記通信端末までの経路に送信する移動端末。
【請求項１１】
前記移動端末が複数のインタフェースを有する場合、
前記メッセージ生成手段は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１０に記載の移動端末。
【請求項１２】
前記移動端末が複数のインタフェースを有する場合、
前記メッセージ生成手段は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続するノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードの情報を前記第２のメッセージに含める請求項１０に記載の移動端末。
【請求項１３】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
前記第１のメッセージを受信する受信手段とを備え、
前記送信手段が、前記第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第３のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に、前記メッセージ生成手段によって生成された前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信する移動端末。
【請求項１４】
前記送信手段は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
前記受信手段は、前記ハンドオーバするインタフェースの接続先のノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードへ前記通信端末によって送信された前記ＱｏＳリソースの予約をするための情報を収集するメッセージを受信し、
前記メッセージ生成手段は、受信された前記メッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
前記送信手段は、生成された前記メッセージを送信する請求項１３に記載の移動端末。
【請求項１５】
前記受信手段が前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記送信手段が前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、
前記メッセージ生成手段は、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
前記送信手段が、生成された前記メッセージを送信する請求項１３に記載の移動端末。
【請求項１６】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
前記第１のメッセージを受信する受信手段とを備え、
前記メッセージ生成手段が、前記第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに対して、前記ＱｏＳリソースの予約をさせる第３のメッセージ及び前記ＱｏＳリソースの予約準備を促す第４のメッセージを生成し、
前記送信手段が、前記第３のメッセージ及び前記第４のメッセージを送信し、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための前記メッセージ生成手段によって生成された第５のメッセージを送信し、前記ハンドオーバ先で接続する中継ノードから受信する前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて、前記準最適経路と前記ハンドオーバ後の前記インタフェースから前記通信端末までの経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信する移動端末。
【請求項１７】
前記受信手段が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第５のメッセージを送信する場合、
所定の期間が経過した場合に、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択する判断手段を更に備え、
前記メッセージ生成手段が、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを生成し、
前記送信手段が生成された前記メッセージを送信する請求項１６に記載の移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末に関する。
【背景技術】
【０００２】
パケットスイッチの通信ネットワークにおいて、ＭＮ（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）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【００７７】
本発明に係るＱｏＳリソース予約方法及びその方法で用いられる移動端末は、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるため、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末などに有用である。
【図１】
2009037843.tif 000003
【図２】
2009037843.tif 000004
【図３】
2009037843.tif 000005
【図４】
2009037843.tif 000006
【図５】
2009037843.tif 000007
【図６】
2009037843.tif 000008
【図７】
2009037843.tif 000009
【図８】
2009037843.tif 000010
【図９】
2009037843.tif 000011
【図１０】
2009037843.tif 000012
【図１１】
2009037843.tif 000013
【図１２】
2009037843.tif 000014
【図１３】
2009037843.tif 000015
【図１４】
2009037843.tif 000016
【図１５】
2009037843.tif 000017
【図１６】
2009037843.tif 000018
【図１７】
2009037843.tif 000019
【図１８】
2009037843.tif 000020
【図１９】
2009037843.tif 000021
【図２０】
2009037843.tif 000022
【図２１】
2009037843.tif 000023
【図２２】
2009037843.tif 000024
【図２３】
2009037843.tif 000025
【図２４】
2009037843.tif 000026
【図２５】
2009037843.tif 000027
【図２６】
2009037843.tif 000028
【図２７】
2009037843.tif 000029
【図２８】
2009037843.tif 000030
【図２９】
2009037843.tif 000031
【図３０】
2009037843.tif 000032
【図３１】
2009037843.tif 000033
【図３２】
2009037843.tif 000034
【図３３】
2009037843.tif 000035
【図３４】
2009037843.tif 000036
【図３５】
2009037843.tif 000037
【図３６】
2009037843.tif 000038
【図３７】
2009037843.tif 000039
【図３８】
2009037843.tif 000040
【図３９】
2009037843.tif 000041
【手続補正書】
【提出日】平成22年3月15日(2010.3.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを前記通信端末に向けて送信するステップと、
前記移動端末が、前記ＱｏＳリソースの予約処理の間に自身のハンドオーバを検知した場合、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを前記ハンドオーバ前の前記自身から前記通信端末までの経路に送信するステップとを、
有するＱｏＳリソース予約方法。
【請求項２】
前記移動端末が複数のインタフェースを有する場合、
前記移動端末は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１に記載のＱｏＳリソース予約方法。
【請求項３】
前記移動端末が複数のインタフェースを有する場合、
前記移動端末は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続する中継ノードの情報を前記第２のメッセージに含め、
前記第２のメッセージを受信する前記中継ノードは、自身が、前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差するクロスオーバノードであるか否かを判断し、前記クロスオーバノードであると判断した場合、前記第２の経路における前記ＱｏＳリソースの予約をするための情報と、前記ハンドオーバしなかったインタフェースから前記通信端末までの第３の経路における前記ＱｏＳリソースの予約をするための情報とを比較した結果に基づいて、最適な経路に前記ＱｏＳリソースの予約がなされるための処理を行う請求項１に記載のＱｏＳリソース予約方法。
【請求項４】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第２のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第３のメッセージを送信するステップを、
有するＱｏＳリソース予約方法。
【請求項５】
前記移動端末は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
前記通信端末は、前記ハンドオーバする旨を伝えるための前記メッセージに基づいて、前記ハンドオーバするインタフェースの接続先の中継ノードに前記ＱｏＳリソースの予約をするための情報を収集するメッセージを送信し、
前記移動端末は、前記通信端末から受信するメッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
【請求項６】
前記移動端末は、前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを送信する請求項４に記載のＱｏＳリソース予約方法。
【請求項７】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末と、前記移動端末と前記通信端末との通信経路上に存在し、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する１つ以上の中継ノードとを備える通信システムで、前記移動端末と前記通信端末との間の前記通信経路上にＱｏＳリソースの予約を行うＱｏＳリソース予約方法であって、
前記移動端末が、前記通信端末から受信するメッセージであって、前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに、前記ＱｏＳリソースの予約をさせる第２のメッセージ及び前記ＱｏＳリソースの予約準備を促す第３のメッセージを送信するステップと、
前記移動端末が、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信するステップと、
前記ハンドオーバ前の前記インタフェースから前記通信端末までの第１の経路と、前記ハンドオーバ後の前記インタフェースから前記通信端末までの第２の経路とが交差する中継ノードであるクロスオーバノードが、前記ＱｏＳリソースの予約をするための情報を収集するメッセージを前記ハンドオーバ先で接続する中継ノードに送信するステップと、
前記移動端末が、前記ハンドオーバ先で接続する中継ノードから受信する前記メッセージに基づいて、前記準最適経路と前記第２の経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信するステップとを、
備えるＱｏＳリソース予約方法。
【請求項８】
前記クロスオーバノードは、所定の期間が経過した場合、前記第２の経路を使用することができない旨を含む前記第４のメッセージを前記通信端末に送信し、
前記通信端末は、受信する前記第４のメッセージに基づいて、前記ＱｏＳリソースの予約をさせるメッセージを前記準最適経路に送信する請求項７に記載のＱｏＳリソース予約方法。
【請求項９】
前記移動端末が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第４のメッセージを送信する場合、
前記移動端末は、所定の期間が経過した場合、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択し、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを送信する請求項７に記載のＱｏＳリソース予約方法。
【請求項１０】
移動端末と前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージを生成するメッセージ生成手段と、
生成された前記第１のメッセージを前記通信端末に向けて送信する送信手段と、
前記ＱｏＳリソースの予約処理の間に前記移動端末自身がハンドオーバしたか否かを判断する判断手段とを備え、
前記判断手段によって前記移動端末自身がハンドオーバしたと判断された場合、前記メッセージ生成手段が、前記ＱｏＳリソースの予約を取り除くための第２のメッセージを生成し、
前記送信手段が、前記第２のメッセージを前記ハンドオーバ前の前記移動端末自身から前記通信端末までの経路に送信する移動端末。
【請求項１１】
前記移動端末が複数のインタフェースを有する場合、
前記メッセージ生成手段は、前記通信端末に指示するためのフラグであって、前記通信端末が前記第１のメッセージに基づいて選択した最適な経路に前記ＱｏＳリソースの予約をさせる第３のメッセージを送信するだけでなく、前記第３のメッセージに含まれる情報を含み、前記最適な経路の次に適した経路である準最適経路に前記ＱｏＳリソースの予約準備を促す第４のメッセージを前記準最適経路にも送信するよう指示する前記フラグを前記第１のメッセージに含める請求項１０に記載の移動端末。
【請求項１２】
前記移動端末が複数のインタフェースを有する場合、
前記メッセージ生成手段は、前記第２のメッセージを送信する際、前記複数のインタフェースのうちの１つのインタフェースが前記ハンドオーバ先で接続するノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードの情報を前記第２のメッセージに含める請求項１０に記載の移動端末。
【請求項１３】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
前記第１のメッセージを受信する受信手段とを備え、
前記送信手段が、前記第１のメッセージに基づいて選択された最適な経路に対して、前記ＱｏＳリソースの予約をさせるための第３のメッセージを送信した後に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に、前記メッセージ生成手段によって生成された前記ＱｏＳリソース予約を取り除くための第４のメッセージを送信する移動端末。
【請求項１４】
前記送信手段は、前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、ハンドオーバする旨を伝えるためのメッセージを前記通信端末に送信し、
前記受信手段は、前記ハンドオーバするインタフェースの接続先のノードであって、前記移動端末と前記通信端末との間で送受信されるシグナリングを中継する中継ノードへ前記通信端末によって送信された前記ＱｏＳリソースの予約をするための情報を収集するメッセージを受信し、
前記メッセージ生成手段は、受信された前記メッセージに基づいて選択された最適な経路に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
前記送信手段は、生成された前記メッセージを送信する請求項１３に記載の移動端末。
【請求項１５】
前記受信手段が前記第１のメッセージを受信し、かつ受信した前記第１のメッセージに基づいて選択された最適な経路に対して前記送信手段が前記ＱｏＳリソースの予約をさせるためのメッセージを送信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、
前記メッセージ生成手段は、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路以外に前記ＱｏＳリソースの予約をさせるためのメッセージを生成し、
前記送信手段が、生成された前記メッセージを送信する請求項１３に記載の移動端末。
【請求項１６】
複数のインタフェースを有する移動端末と、前記移動端末の通信相手となる通信端末との間の通信経路上にＱｏＳリソースの予約の処理を行う前記移動端末であって、
前記ＱｏＳリソースの予約をするための情報を収集する第１のメッセージ（Query）を送信するよう要求するための第２のメッセージ（TFQ）を生成するメッセージ生成手段と、
生成された前記第２のメッセージを前記通信端末に向けて送信する送信手段と、
前記第１のメッセージを受信する受信手段とを備え、
前記メッセージ生成手段が、前記第１のメッセージに基づいて選択した最適な経路及び前記最適な経路の次に適した経路である準最適経路のそれぞれに対して、前記ＱｏＳリソースの予約をさせる第３のメッセージ及び前記ＱｏＳリソースの予約準備を促す第４のメッセージを生成し、
前記送信手段が、前記第３のメッセージ及び前記第４のメッセージを送信し、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバした場合、前記ハンドオーバ前の前記インタフェースから前記通信端末までの経路に前記ＱｏＳリソース予約を取り除くための前記メッセージ生成手段によって生成された第５のメッセージを送信し、前記ハンドオーバ先で接続する中継ノードから受信する前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて、前記準最適経路と前記ハンドオーバ後の前記インタフェースから前記通信端末までの経路のうちの一方の経路を選択して前記ＱｏＳリソースの予約をさせるメッセージを送信する移動端末。
【請求項１７】
前記受信手段が前記第１のメッセージを受信する前に、前記複数のインタフェースのうちの１つのインタフェースがハンドオーバし、前記第５のメッセージを送信する場合、
所定の期間が経過した場合に、既に受信している前記ＱｏＳリソースの予約をするための情報を収集するメッセージに基づいて前記ＱｏＳリソースの予約をする経路を選択する判断手段を更に備え、
前記メッセージ生成手段が、選択された前記経路に前記ＱｏＳリソースの予約をさせるメッセージを生成し、
前記送信手段が生成された前記メッセージを送信する請求項１６に記載の移動端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末に関する。
【背景技術】
【０００２】
パケットスイッチの通信ネットワークにおいて、ＭＮ（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）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【００７６】
本発明に係るＱｏＳリソース予約方法及びその方法で用いられる移動端末は、ＱｏＳ予約の構築に遅延を生じさせず、さらにＱｏＳリソースの浪費を避けることができるため、移動端末と、その通信相手となる通信端末との間の通信経路上にＱｏＳリソースを予約するＱｏＳリソース予約方法及びその方法で用いられる移動端末などに有用である。
【図面の簡単な説明】
【００７７】
【図１】本発明の第１の実施の形態における通信ネットワークの一例を示すネットワーク図
【図２】本発明の第１の実施の形態におけるＱｏＳリソース予約のシーケンスの一例を示すシーケンスチャート
【図３】本発明の第１の実施の形態におけるＱＵＥＲＹメッセージのフォーマットの一例を示す図
【図４】本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図
【図５】本発明の第１の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図
【図６】本発明の第１の実施の形態に係るＭＮの構成の一例を示す構成図
【図７】本発明の第１の実施の形態におけるＱＮＥの構成の一例を示す構成図
【図８】本発明の第１の実施の形態におけるＱＮＥでのＰＲＥ−ＴＥＡＲの処理フローの一例を示すフローチャート
【図９】本発明の第１の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート
【図１０】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図１１】本発明の第１の実施の形態におけるＣＮの構成の一例を示す構成図
【図１２】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図１３】本発明の第１の実施の形態における通信ネットワークの他の一例を示すネットワーク図
【図１４】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図１５】本発明の第１の実施の形態に係るＭＮの構成の他の一例を示す構成図
【図１６】本発明の第１の実施の形態におけるＣＮの構成の他の一例を示す構成図
【図１７】本発明の第１の実施の形態における修正ＱＵＥＲＹメッセージのフォーマットの一例を示す図
【図１８】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図１９】本発明の第１の実施の形態におけるＲＥＳＥＲＶＥメッセージのフォーマットの他の一例を示す図
【図２０】本発明の第１の実施の形態におけるＰＡＳＳＩＶＥ  ＲＥＳＥＲＶＥメッセージのフォーマットの一例を示す図
【図２１】本発明の第１の実施の形態におけるＱＮＥの構成の他の一例を示す構成図
【図２２】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図２３】本発明の第１の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図２４】本発明の第２、４の実施の形態における通信ネットワークの一例を示すネットワーク図
【図２５】本発明の第２の実施の形態におけるＰＲＥ−ＴＥＡＲメッセージのフォーマットの一例を示す図
【図２６】本発明の第２の実施の形態に係るＭＮの構成の一例を示す構成図
【図２７】本発明の第２の実施の形態におけるＱＮＥの構成の一例を示す構成図
【図２８】本発明の第２の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート
【図２９】本発明の第２の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図
【図３０】本発明の第２の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図３１】本発明の第３の実施の形態における通信ネットワークの一例を示すネットワーク図
【図３２】本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート
【図３３】本発明の第３の実施の形態におけるＴＦＱメッセージのフォーマットの一例を示す図
【図３４】本発明の第３の実施の形態におけるＯＰＰＴのフォーマットの一例を示す図
【図３５】本発明の第３の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート
【図３６】本発明の第３の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図３７】本発明の第４の実施の形態におけるＱｏＳリソース予約の際のシーケンスの一例を示すシーケンスチャート
【図３８】本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【図３９】本発明の第４の実施の形態におけるＱｏＳリソース予約の際の他のシーケンスの一例を示すシーケンスチャート
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2009037843.tif 000042
【図２】
2009037843.tif 000043
【図３】
2009037843.tif 000044
【図４】
2009037843.tif 000045
【図５】
2009037843.tif 000046
【図６】
2009037843.tif 000047
【図７】
2009037843.tif 000048
【図８】
2009037843.tif 000049
【図９】
2009037843.tif 000050
【図１０】
2009037843.tif 000051
【図１１】
2009037843.tif 000052
【図１２】
2009037843.tif 000053
【図１３】
2009037843.tif 000054
【図１４】
2009037843.tif 000055
【図１５】
2009037843.tif 000056
【図１６】
2009037843.tif 000057
【図１７】
2009037843.tif 000058
【図１８】
2009037843.tif 000059
【図１９】
2009037843.tif 000060
【図２０】
2009037843.tif 000061
【図２１】
2009037843.tif 000062
【図２２】
2009037843.tif 000063
【図２３】
2009037843.tif 000064
【図２４】
2009037843.tif 000065
【図２５】
2009037843.tif 000066
【図２６】
2009037843.tif 000067
【図２７】
2009037843.tif 000068
【図２８】
2009037843.tif 000069
【図２９】
2009037843.tif 000070
【図３０】
2009037843.tif 000071
【図３１】
2009037843.tif 000072
【図３２】
2009037843.tif 000073
【図３３】
2009037843.tif 000074
【図３４】
2009037843.tif 000075
【図３５】
2009037843.tif 000076
【図３６】
2009037843.tif 000077
【図３７】
2009037843.tif 000078
【図３８】
2009037843.tif 000079
【図３９】
2009037843.tif 000080
【国際調査報告】
2009037843.tif 000081
2009037843.tif 000082
2009037843.tif 000083
2009037843.tif 000084