(57)【要約】移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービス（例えば、ＱｏＳ保証）を迅速かつ継続して受けられるようにする技術が開示され、この技術によると移動端末（ＭＮ１０）がハンドオーバを行う場合、ＭＮは、移動先のサブネット３０に属するＡＲ（アクセスルータ）３１の近くに存在する（ネットワーク構成上のＡＲ近傍）ＱｏＳのためのＮＳＬＰを有するノード（ＱＮＥ（プロキシ）６８）をプロキシとして選択し、このプロキシに対して、ハンドオーバ前にＣＮ６０との間で確立されていた経路２４に係るフロー識別子及びセッション識別子を含むメッセージを送信する。プロキシは、ＣＮに対して、これらのフロー識別子及びセッション識別子を含むメッセージを送信し、そのメッセージの応答結果に基づいて、新たな経路３４を確立するとともに、２つの経路が交わり始めるクロスオーバノードを発見する。
2005076548.tif 000002
【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、前記別のアクセスポイントから前記別のアクセスポイントの情報を受信する受信ステップと、
前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記別のアクセスポイントに通信を切り換えた場合に前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得する情報取得ステップと、
現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを生成し、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報に基づいて、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップとを、
有する通信ハンドオーバ方法。
【請求項２】
前記移動端末が、前記移動端末が有する所定の情報格納手段に、前記アクセスポイントの情報と、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報との対応関係が記載された対応情報を格納する格納ステップを有する請求項１に記載の通信ハンドオーバ方法。
【請求項３】
前記情報取得ステップにおいて、前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記対応情報の中から前記別のアクセスポイントに関連付けられた前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得する請求項２に記載の通信ハンドオーバ方法。
【請求項４】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、前記別のアクセスポイントから前記別のアクセスポイントの情報を受信する受信ステップと、
前記受信ステップで受信した前記別のアクセスポイントの情報と、現在通信中に受けている付加的サービスに関する情報とが含まれるメッセージを生成し、前記アクセスポイントの情報に基づいて、前記別のアクセスポイントに通信を切り換えた場合に前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得することが可能な所定のサーバに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップとを、
有する通信ハンドオーバ方法。
【請求項５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを生成し、前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、通信切り換え後の付加的サービスを実現できる、前記移動端末によって選択されたすべての所定のルータに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップを有する通信ハンドオーバ方法。
【請求項６】
前記移動端末が、前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記別のアクセスポイントを配下に有するアクセスルータを特定するステップと、
前記別のアクセスポイントを配下に有する前記アクセスルータの情報を取得するステップと、
前記別のアクセスポイントを配下に有する前記アクセスルータの情報に基づいて、前記アクセスルータが属する前記サブネットで使用可能なアドレス情報を生成するアドレス生成ステップを有する請求項１、４、５のいずれか１つに記載の通信ハンドオーバ方法。
【請求項７】
前記情報送信ステップにおいて、前記アドレス生成ステップで生成されたアドレス情報を前記メッセージの中に含ませて、前記メッセージを送信する請求項６に記載の通信ハンドオーバ方法。
【請求項８】
前記付加的サービスが、ＱｏＳ保証である請求項１、４、５のいずれか１つに記載の通信ハンドオーバ方法。
【請求項９】
請求項１、４、５のいずれか１つに記載の通信ハンドオーバ方法をコンピュータにより実行するための通信ハンドオーバ用プログラム。
【請求項１０】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が前記アクセスポイントの通信を切り換える場合に、前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータにおける通信メッセージ処理方法であって、
前記移動端末から、前記移動端末が現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを受信する第１の情報受信ステップと、
前記付加的サービスの情報を基に、付加的サービスの準備を行うためのメッセージを生成するステップと、
前記移動端末が現在通信中に受けている付加的サービスに関する情報に基づいて、前記移動端末が現在通信中の相手端末を特定する端末特定ステップと、
前記移動端末が現在通信中に受けている付加的サービスに関する情報に基づいて、前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を取得するためのメッセージを生成し、前記メッセージを前記相手端末に送信する情報送信ステップと、
前記相手端末、又は、前記相手端末への前記メッセージの経路上に存在する任意のノードから、前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を含むメッセージを受信する第２の情報受信ステップとを、
有する通信メッセージ処理方法。
【請求項１１】
前記第２の情報受信ステップで、前記相手端末、又は、前記相手端末への前記メッセージの経路上に存在する任意のノードから受信した前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を格納する格納ステップを有する請求項１０に記載の通信メッセージ処理方法。
【請求項１２】
前記第２の情報受信ステップで前記相手端末から受信した、前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報が含まれるメッセージを生成して、前記移動端末に前記メッセージを送信するステップを有する請求項１０に記載の通信メッセージ処理方法。
【請求項１３】
前記第１の情報受信ステップで、前記アクセスルータが属する前記サブネット内に存在しない前記移動端末から受信した前記メッセージの中に、前記アクセスルータが属する前記サブネットで前記移動端末によって使用可能なアドレス情報が含まれている場合には、前記アドレス情報の妥当性を検証するステップと、
前記アドレス情報の妥当性が把握された場合には、前記アドレス情報に基づいて、前記移動端末が前記通信切り換え後に受ける前記付加的サービスのための経路を、あらかじめ確立するステップを有する請求項１２に記載の通信メッセージ処理方法。
【請求項１４】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断する予約判断ステップと、
前記予約判断ステップにおける判断結果を含むメッセージを前記所定の経路が設定されているか否かを調べるためのメッセージの送信元又は送信先に送信するステップとを、
有する通信メッセージ処理方法。
【請求項１５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断する予約判断ステップと、
前記予約判断ステップにおいて、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われていると判断された場合には、前記メッセージの所定の箇所に前記リソース予約に利用されているインタフェースのアドレス情報を付加して、前記メッセージの転送を行う転送ステップとを、
有する通信メッセージ処理方法。
【請求項１６】
前記所定の箇所によって、前記インタフェースのアドレス情報の付加順序が表されている請求項１５に記載の通信メッセージ処理方法。
【請求項１７】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末との間で通信を行い、前記移動端末との間で通信を行う際に、付加的サービスに係る経路を確立することが可能な通信ノードにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路を探索するためのメッセージを受信した場合には、前記メッセージ内の前記所定の経路の探索結果を含む新たなメッセージを生成して、前記メッセージの応答として送信するステップを有する通信メッセージ処理方法。
【請求項１８】
前記所定の経路が設定されているか否かを調べるためのメッセージ、又は、前記所定の経路を探索するためのメッセージが、前記経路に係るフロー識別子及びセッション識別子を含ませることが可能な領域を有しているＱＵＥＲＹメッセージ又はＲＥＳＰＯＮＳＥメッセージである請求項１４、１５、１７のいずれか１つに記載の通信メッセージ処理方法。
【請求項１９】
前記所定の経路が設定されているか否かを調べるためのメッセージ、又は、前記所定の経路を探索するためのメッセージが、空きリソースの情報を含ませることが可能な領域を有する請求項１４、１５、１７のいずれか１つに記載の通信メッセージ処理方法。
【請求項２０】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記セッション識別子に対するステートを有しているか否かを判断する予約判断ステップと、
前記予約判断ステップで前記セッション識別子に対するステートを有していないと判断された場合には、前記メッセージを前記所定の通信端末に向けて送信する送信ステップを有する通信メッセージ処理方法。
【請求項２１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記セッション識別子に対するステートを有しているか否かを判断する予約判断ステップと、
所定の経路に係るフローを特定する識別情報及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記フローを特定する識別情報に対するステートを有しているか否かを判断する予約判断ステップと、
前記予約判断ステップで前記セッション識別子に対する前記ステートを有していると判断された場合には、前記ステート及び前記メッセージ内のそれぞれにおいて、異なる隣り合うノード又はルータが指定されているか否かを判断する判断ステップと、
前記判断ステップで異なる前記隣り合うノード又はルータが指定されている場合には、自身がクロスオーバノードであると判断するＣＲＮ判断ステップとを、
有する通信メッセージ処理方法。
【請求項２２】
前記ＣＲＮ判断ステップで自身がクロスオーバノードであると判断された場合には、所定のノードに対して、自身がクロスオーバノードである旨を通知する通知ステップを有する請求項２１に記載の通信メッセージ処理方法。
【請求項２３】
前記付加的サービスに係る経路を構成する前記ノード又はルータが、各リソースと、フローを特定する情報との対応関係を格納するためのフロー識別リストを持っており、自身を経由する付加的サービスに係る経路に関連する前記フローを特定する情報を、前記フロー識別リストに追加又は削除するステップを有する請求項２１に記載の通信メッセージ処理方法。
【請求項２４】
前記ＣＲＮ判断ステップで自身がクロスオーバノードであると判断された場合には、受信する各ノード又はルータに対して、前記所定の経路に対する前記リソースが割り当てられている前記フロー識別リストに新たなフローを特定する情報を追加させるためのメッセージを前記通信端末に向けて送信する更新ステップを有する請求項２３に記載の通信メッセージ処理方法。
【請求項２５】
請求項１０、１４、１５、１７、２０、２１のいずれか１つに記載の通信メッセージ処理方法をコンピュータにより実行するための通信メッセージ処理用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバに係る通信ハンドオーバ方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムに関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Ｍｏｂｉｌｅ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ６）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバに係る通信ハンドオーバ方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムに関する。
【背景技術】
【０００２】  移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰｖ６を利用したものが普及してきている。このモバイルＩＰｖ６を利用した無線通信システムについて、図９を参照しながら説明する。なお、以下に説明するモバイルＩＰｖ６の技術に関しては、例えば、下記の非特許文献１に開示されている。【０００３】  図９に示す無線通信システムは、インターネットなどのＩＰネットワーク（通信ネットワーク）１５、ＩＰネットワーク１５に接続する複数のサブネット（サブネットワークとも呼ばれる）２０、３０、これらの複数のサブネット２０、３０のいずれかに接続することが可能な移動端末（ＭＮ：Ｍｏｂｉｌｅ  Ｎｏｄｅ）１０を含んでいる。なお、図９では、複数のサブネット２０、３０として、２つのサブネット２０、３０が図示されている。【０００４】  サブネット２０は、ＩＰパケット（パケットデータ）に対するルーティングを行うアクセスルータ（ＡＲ：Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ）２１、固有の無線カバーエリア（通信可能領域）２８、２９をそれぞれ形成する複数のアクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）２２、２３により構成されている。これらのＡＰ２２、２３は、それぞれＡＲ２１に接続されており、ＡＲ２１は、ＩＰネットワーク１５に接続されている。なお、図９では、複数のＡＰ２２、２３として、２つのＡＰ２２、２３が図示されている。また、サブネット３０に関しても、ＡＲ３１及び複数のＡＰ３２、３３により、上述のサブネット２０と同一の接続態様によって構成されている。【０００５】  また、サブネット２０の構成要素であるＡＲ２１と、サブネット３０の構成要素であるＡＲ３１とは、ＩＰネットワーク１５を通じて通信を行うことが可能であり、すなわち、サブネット２０とサブネット３０とは、ＩＰネットワーク１５を通じてつながっている。【０００６】  図９に示す無線通信システムにおいて、ＭＮ１０が、無線カバーエリア２９内でＡＰ２３との無線通信を開始したとする。このとき、ＭＮ１０に割り当てられているＩＰｖ６アドレスが、サブネット２０のＩＰアドレス体系に適さない場合、無線カバーエリア２９内に存在するＭＮ１０は、ＡＰ２３との間における無線通信を介して、サブネット２０に適合したＩＰｖ６アドレス、すなわち気付アドレス（ＣｏＡ：Ｃａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ）を取得する。【０００７】  なお、ＭＮ１０がＣｏＡを取得する方法には、ＤＨＣＰｖ６などの方法によりＤＨＣＰサーバからステートフルに割り当ててもらう方法と、サブネット２０のネットワークプリフィックス及びプリフィックスレングスをＡＲ２１から取得し、ＭＮ１０において、ＡＲ２１から取得したネットワークプリフィックス及びプリフィックスレングスと、ＭＮ１０のリンクレイヤアドレスなどとを組み合わせて、ステートレスにＣｏＡを自動生成する方法とが存在する。【０００８】  そして、ＭＮ１０は、取得したＣｏＡを自分のホームネットワーク上のルータ（ホームエージェント）や特定の通信相手（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ：ＣＮ）に対して登録（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ：ＢＵ）することによって、サブネット２０内において、パケットデータの送信又は受信が行えるようになる。【０００９】  これにより、所定の通信相手からＭＮ１０に対して送信されたパケットデータは、ＭＮ１０のＣｏＡに基づいて、ＡＲ２１及びＡＰ２３を介して、ＭＮ１０に伝えられる一方、ＭＮ１０が所望の通信相手に対して送信したパケットデータは、ＡＰ２３及びＡＲ２１を介して上記所望の通信相手に伝えられる。また、ＭＮ１０あてにホームネットワークに送信されてきたパケットデータも、ホームエージェントに登録されたＭＮ１０のＣｏＡに基づいてサブネット２０のＡＲ２１に送られ、ＡＰ２３を介してＭＮ１０に伝えられる。【００１０】  上述のように、図９に示すモバイルＩＰｖ６を利用した無線通信システムは、ＭＮ１０があるサブネットから別のサブネットにハンドオーバを行った場合でも、ＣｏＡを利用して、ＭＮ１０における無線通信が継続されるよう構成されている。このハンドオーバ処理を高速化するための技術としては、例えば、下記の非特許文献２に開示されているファストハンドオーバ技術が知られている。【００１１】  このファストハンドオーバ技術では、ＭＮ１０がＬ２ハンドオーバを行う前に、ＭＮ１０は、サブネット３０で使用する新しい（Ｎｅｗ）ＣｏＡ（以降、ＮＣｏＡと呼ぶ）をあらかじめ取得して、このＮＣｏＡをＡＲ２１に通知することによって、ＡＲ２１とＡＲ３１との間にトンネルを生成することが可能となり、ＭＮ１０がＬ２ハンドオーバを行ってＡＰ２３からＡＰ３２に接続を切り換えてから、サブネット３０に移動して、あらかじめ取得したＮＣｏＡを正式に登録（ＢＵ）するまでの間でも、サブネット２０で使用していたＭＮ１０の古い（Ｐｒｅｖｉｏｕｓ）ＣｏＡ（以降、ＰＣｏＡと呼ぶ）あてに送られたパケットデータは、トンネル経由でＡＲ３１及びＡＰ３２を介してＭＮ１０に転送されるようになるとともに、ＭＮ１０から送信されるパケットデータも、ＡＰ３２及びＡＲ３１を介してトンネル経由でＡＲ２１に到達して、ＡＲ２１から通信相手に送られるようになる。【００１２】  一方、ネットワークを利用した通信においては、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が挙げられる（例えば、下記の非特許文献３参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。【００１３】  サブネット２０、３０間のハンドオーバを行うＭＮ１０に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受け��れなければならないという要請があるが、上述したＲＳＶＰは、特に下記の点において上記の要請を満たすことができず、ＭＮ１０の移動に対応不可能である。図１０は、従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図である。【００１４】  ＲＳＶＰでは、ＭＮ１０の通信相手端末（ＣＮ：Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）６０からＭＮ１０への２点間経路（ｅｎｄ−ｔｏ−ｅｎｄ  ｐａｔｈ）においてＱｏＳ経路が設定され、ＭＮ１０及びＣＮ６０のアドレスに基づいて、２点間経路の間をつなぐ複数の中継ノード６１によるデータ転送が行われる。したがって、例えば、ＭＮ１０がサブネット２０、３０間でハンドオーバを行い、ＭＮ１０のＣｏＡが変更された場合には、ＱｏＳ経路において、フローの変更に加えてアドレス変更に係る処理が行われる必要があるが、ＲＳＶＰは、このような変更に対応できずに、結果的にＱｏＳ保証が破綻することとなる（第１の問題点：ＱｏＳ経路の変更が困難）。さらに、新たにＱｏＳ経路が設定された場合でも、ハンドオーバ前後においてＱｏＳ経路が重複する部分が発生した場合には、この重複する部分において２重のリソース予約（ｄｏｕｂｌｅ  ｒｅｓｅｒｖａｔｉｏｎ）が起こってしまう可能性もある（第２の問題点：２重のリソース予約）。【００１５】  上述のような問題点を解決するために、現在、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）において、ＮＳＩＳ（Ｎｅｘｔ  Ｓｔｅｐ  ｉｎ  Ｓｉｇｎａｌｉｎｇ）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献４参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献５〜９参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献６及び非特許文献９参照）。【００１６】  図１１には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（ＮＳＩＳ  Ｓｉｇｎａｌｉｎｇ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（ＮＳＩＳ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳ  ＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。【００１７】  また、図１２は、従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図である。図１２に示すよう���、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ：ＮＳＩＳ  Ｅｎｔｉｔｙ）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥ（ＱｏＳ  ＮＳＩＳ  Ｅｎｔｉｔｙ）と呼ぶことにする。なお、ＮＥになりうるのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳ  ＮＳＬＰを持たないＮＥが複数存在することもあり得る。【００１８】  次に、従来のＱｏＳ経路確立方法の一例を、図１３を用いて説明する。サブネット２０でＡＲ２１に接続されているＭＮ１０は、ある目的（セッション）のために、ＣＮ６０からデータを受信する予定であるか、もしくは受信している（受信中である）ものとする。ＭＮ１０は、ＱｏＳ経路（経路２４）の確立を行う場合には、ＱｏＳ経路確立のためのＲＥＳＥＲＶＥメッセージをＣＮ６０に向けて送信する。ＲＥＳＥＲＶＥメッセージには、ＣＮ６０からのデータ受信のために所望されるＱｏＳの情報（Ｑｓｐｅｃ）が含まれている。送信されたＲＥＳＥＲＶＥメッセージはＡＲ２１とＮＥ６２及びその他のＮＳＩＳ機能を持たないルータを経由し、ＱＮＥ６３に到着する。ＱＮＥ６３のＮＳＬＰは、ＲＥＳＥＲＶＥメッセージ中に含まれるＱｓｐｅｃに記されているＱｏＳリソースを、このセッションのために予約する。ＱＮＥ６３を通過したＲＥＳＥＲＶＥメッセージは、さらに、ＮＥ６４やその他のＮＳＩＳの機能を持たないルータを経由し、ＱＮＥ６５に到着する。ＱＮＥ６５においても、ＱＮＥ６３と同様の処理が行われ、ＱｏＳリソースの予約が行われる。この操作が繰り返され、最終的にＲＥＳＥＲＶＥメッセージがＣＮ６０に届けられることによって、ＭＮ１０とＣＮ６０との間において、ＱｏＳ経路が確立される。【００１９】  また、リソース予約を識別するために、フロー識別子（ｆｌｏｗ  ｉｄｅｎｔｉｆｉｅｒ）及びセッション識別子（ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）が使われる。フロー識別子はＭＮ１０のＣｏＡやＣＮ６０のＩＰアドレスに依存するものであり、各ＱＮＥ６３、６５は各データパケットの送信元・送信先のＩＰアドレスを確認することにより、このデータパケットに対するリソース予約の有無を知ることができる。なお、ＭＮ１０が他のサブネットに移動してＣｏＡが変わる場合には、ＭＮ１０のＣｏＡの変更に応じて、フロー識別子も変わる。一方、セッション識別子は、セッションのための一連のデータ伝送を識別するためのものであり、フロー識別子のように端末の移動に伴い変化するものではない。【００２０】  また、任意の経路に対してＱｏＳリソースの入手可能性などを調べる方法として、ＱＵＥＲＹという手法が存在する。この方法は、例えば、ＭＮ１０からＣＮ６０に対してＱｏＳ経路の確立が行われる際に、所望するＱｓｐｅｃが各ＱＮＥで予約可能かどうかを前もって調べるための方法であり、所望するＱｓｐｅｃが各ＱＮＥで予約可能かどうかを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッ���ージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献６に記載されている。【００２１】  次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、２重のリソース予約の回避方法を、図１４を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路２４）が確立されている時、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。この時のフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立のためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路２４）は、ＭＮ１０の移動後すぐに解放されることはない。【００２２】  前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路２４におけるフロー識別子Ｘと、経路３４におけるフロー識別子（この経路３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインタフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここでフロー識別子を比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、２重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（ｃｒｏｓｓｏｖｅｒ  ｎｏｄｅ：クロスオーバノード）と呼ばれている。なお、ＣＲＮとは、実際に経路が交わり始めるルータ（図１４ではＮＥ６４）を指す場合もあるが、ＱｏＳ経路の議論を行う場合は、古い経路（経路２４）と新しい経路（経路３４）において、片方の隣り合うＱＮＥ（図１４ではＱＮＥ６６）は同じであるが、もう片方の隣り合うＱＮＥ（図１４ではＱＮＥ６３とＱＮＥ６７）は異なっているようなＱＮＥ（図１４ではＱＮＥ６５）を指す。【００２３】  また、非特許文献６や非特許文献９によると、このようなＲＥＳＥＲＶＥメッセージ、ＱＵＥＲＹメッセージ、ＮＯＴＩＦＹメッセージに関しては、データパケットの送信先や送信元である末端の端末（ＭＮ１０や��Ｎ６０）だけではなく、任意のＱＮＥが送信元となることもできる。【００２４】  なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。
【非特許文献１】Ｄ．Ｊｏｈｎｓｏｎ，Ｃ．Ｐｅｒｋｉｎｓ  ａｎｄ  Ｊ．Ａｒｋｋｏ，″Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６″，ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−２４，Ｊｕｎｅ  ２００３
【非特許文献２】Ｒａｊｅｅｖ  Ｋｏｏｄｌｉ″Ｆａｓｔ  Ｈａｎｄｏｖｅｒｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰｖ６″，ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｆａｓｔ−ｍｉｐｖ６−０８，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献３】Ｒ．Ｂｒａｄｅｎ，Ｌ．Ｚｈａｎｇ，Ｓ．Ｂｅｒｓｏｎ，Ｓ．Ｈｅｒｚｏｇ  ａｎｄ  Ｓ．Ｊａｍｉｎ，″Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ  １  Ｆｕｎｃｔｉｏｎａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ″，ＲＦＣ  ２２０５，Ｓｅｐｔｅｍｂｅｒ  １９９７．
【非特許文献４】ＮＳＩＳ  ＷＧ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｎｓｉｓ−ｃｈａｒｔｅｒ．ｈｔｍｌ）
【非特許文献５】Ｈ．Ｃｈａｓｋａｒ，Ｅｄ，″Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｏｆ  ａ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）Ｓｏｌｕｔｉｏｎ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰ″，ＲＦＣ３５８３，Ｓｅｐｔｅｍｂｅｒ  ２００３
【非特許文献６】Ｓｖｅｎ  Ｖａｎ  ｄｅｎ  Ｂｏｓｃｈ，Ｇｅｏｒｇｉｏｓ  Ｋａｒａｇｉａｎｎｉｓ  ａｎｄ  Ａｎｄｒｅｗ  ＭｃＤｏｎａｌｄ″ＮＳＬＰ  ｆｏｒ  Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ  ｓｉｇｎａｌｌｉｎｇ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献７】Ｘ．Ｆｕ，Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｈ．Ｔｓｃｈｏｆｅｎｉｇ，″Ｍｏｂｉｌｉｔｙ  ｉｓｓｕｅｓ  ｉｎ  Ｎｅｘｔ  Ｓｔｅｐ  ｓｉｇｎａｌｉｎｇ″，ｄｒａｆｔ−ｆｕ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献８】Ｒｏｌａｎｄ  Ｂｌｅｓｓ，ｅｔ．Ａｌ．，″Ｍｏｂｉｌｉｔｙ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  Ｓｉｇｎａｌｉｎｇ  Ｐｒｏｔｏｃｏｌ″，ｄｒａｆｔ−ｍａｎｙｆｏｌｋｓ−ｓｉｇｎａｌｉｎｇ−ｐｒｏｔｏｃｏｌ−ｍｏｂｉｌｉｔｙ−００．ｔｘｔ，Ｊａｎｕａｒｙ  ２００４
【非特許文献９】Ｒ．Ｈａｎｃｏｃｋ（ｅｄｉｔｏｒ），″Ｎｅｘｔ  Ｓｔｅｐｓ  ｉｎ  Ｓｉｇｎａｌｉｎｇ：Ｆｒａｍｅｗｏｒｋ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｆｗ−０５．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【００２５】  図１４において、例えば、ハンドオーバ前に接続しているサブネット２０においてＱｏＳ保証を受けているＭＮ１０が、サブネット３０へのハンドオーバを行い、ハンドオーバ後に接続するサブネット３０において、ハンドオーバ前に受けていたＱｏＳ保証を継続して受けることを考えてみる。【００２６】  この場合、ＭＮ１０がハンドオーバ前に接続しているサブネット２０とのハンドオフを行ってから、ハンドオーバ後に接続するサブネット３０において付加的サービス（ここではＱｏＳ保証）を受けた状態となるまでの時間は、ＭＮ１０がＱｏＳ保証を受けられない時間となり、ＭＮ１０はＱｏＳ保証を全く受けられないか、あるいは、デフォルトのＱｏＳ転送処理が行われてしまうこととなり、ＱｏＳの破局が起きる。【００２７】  したがって、上述のように、ハンドオーバ後のＭＮ１０に対しては、ＱｏＳ保証が迅速に提供される必要がある。このことを解決するため、ＩＥＴＦにおけるＮＳＩＳに関する現在の議論（例えば、非特許文献７）では、例えばＭＮ１０がハンドオーバを行う前、又は終える前に、新しいＱｏＳ経路を確立するための何かしらの準備を行うこと、又は新しいＱｏＳ経路の確立を前もって行うことも必要である旨の提案がある。しかしながら、こうした提案のみがなされているだけで、具体的な実現方法に関しては一切開示されていない。また、新しい経路を確立するための準備として、前述のＣＲＮを先に見つけておくことも必要とされてはいるが、これに関しても、具体的な実現方法は開示されていない。【００２８】  また別の問題点として、ＭＮ１０がＣＮ６０と通信を行うための、ＱｏＳリソースの予約が経路２４上に存在するときに、例えば、ＭＮがサブネット３０に移動し、そこでＣＮ６０に対してＱＵＥＲＹを行う場合を考える。この場合には、上述のように、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約は、ＭＮ１０が移動した後しばらくは解放されることがないため、ＱＮＥ６５及びＱＮＥ６６には、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約がしばらくの間、残ったままとなる。これを空きリソースとしてＭＮ１０に返す（ＭＮ１０の移動後における新たな経路に利用する）ことができず、その結果、ＭＮ１０は正確なリソースの空き情報を得ることができない。この問題は、移動したＭＮ１０がＱＵＥＲＹメッセージによるリクエストを出すときばかりではなく、例えば、経路３４上の任意のＱＮＥ（例えばＱＮＥ６７）がＱＵＥＲＹメッセージのリクエストを送信する場合にも、同様に引き起こされる問題である。
【発明の開示】
【００２９】  本発明は、上記の問題点に鑑み、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようにすることを可能とする通信ハンドオーバ方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムを提供することを目的とする。
【００３０】  上記目的を達成するため、本発明の通信ハンドオーバ方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、前記別のアクセスポイントから前記別のアクセスポイントの情報を受信する受信ステップと、
前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記別のアクセスポイントに通信を切り換えた場合に前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得する情報取得ステップと、
現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを生成し、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報に基づいて、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップとを有している。
上記の構成により、移動端末がアクセスポイントの通信切り換えを行う前において、現在（通信切り換え前に）受けている付加的サービスをアクセスポイントの通信切り換え後も継続して受けるための処理が行われるようになり、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようになる。
【００３１】  さらに、本発明の通信ハンドオーバ方法は、上記の構成に加えて、前記移動端末が、前記移動端末が有する所定の情報格納手段に、前記アクセスポイントの情報と、前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報との対応関係が記載された対応情報を格納する格納ステップを有している。
上記の構成により、移動端末は、アクセスポイントの情報と関連付けて、通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を保持することが可能となる。
【００３２】  さらに、本発明の通信ハンドオーバ方法は、上記の構成に加えて、前記情報取得ステップにおいて、前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記対応情報の中から前記別のアクセスポイントに関連付けられた前記通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得する。
上記の構成により、現在通信を行っているアクセスポイントとは異なるアクセスポイントから情報を受信できるようになった場合、受信したアクセスポイントの情報に基づいて、通信切り換え後の付加的サービスに係る準備を行うための最適なルータを見つけることが可能となる。
【００３３】  また、上記目的を達成するため、本発明の通信ハンドオーバ方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、前記別のアクセスポイントから前記別のアクセスポイントの情報を受信する受信ステップと、
前記受信ステップで受信した前記別のアクセスポイントの情報と、現在通信中に受けている付加的サービスに関する情報とが含まれるメッセージを生成し、前記アクセスポイントの情報に基づいて、前記別のアクセスポイントに通信を切り換えた場合に前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得することが可能な所定のサーバに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップとを有している。
上記の構成により、移動端末は、通信切り換え後の付加的サービスに係る準備を行うことのできるルータの情報を取得することが可能な所定のサーバに対して、現在受けている付加的サービスに関する情報を提供することによって、現在受けている付加的サービスをアクセスポイントの通信切り換え後も継続して受けるための処理が行われるようになり、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようになる。
【００３４】  また、上記目的を達成するため、本発明の通信ハンドオーバ方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末における通信ハンドオーバ方法であって、
現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを生成し、前記移動端末が、現在通信中のアクセスポイントから別のアクセスポイントに通信の切り換えを行う際に、通信切り換え後の付加的サービスを実現できる、前記移動端末によって選択されたすべての所定のルータに対して、前記現在通信中のアクセスポイントを通じて、前記メッセージを送信する情報送信ステップを有している。
上記の構成により、例えば、移動端末があらかじめ把握している付加的サービスの実現機能を有する所定のルータに対して、現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを送信することによって、現在受けている付加的サービスをアクセスポイントの通信切り換え後も継続して受けるための処理が行われるようになり、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようになる。
【００３５】  さらに、本発明の通信ハンドオーバ方法は、上記の構成に加えて、前記移動端末が、前記受信ステップで受信した前記別のアクセスポイントの情報に基づいて、前記別のアクセスポイントを配下に有するアクセスルータを特定するステップと、
前記別のアクセスポイントを配下に有する前記アクセスルータの情報を取得するステップと、
前記別のアクセスポイントを配下に有する前記アクセスルータの情報に基づいて、前記アクセスルータが属する前記サブネットで使用可能なアドレス情報を生成するアドレス生成ステップを有している。
上記の構成により、移動端末は、アドレス情報のステートレス自動設定を行えるようになる。
【００３６】  さらに、本発明の通信ハンドオーバ方法は、上記の構成に加えて、前記情報送信ステップにおいて、前記アドレス生成ステップで生成されたアドレス情報を前記メッセージの中に含ませて、前記メッセージを送信する。
上記の構成により、移動端末は、現在通信中に受けている付加的サービスに関する情報と共に、ステートレス自動設定によって生成されたアドレス情報を１つのメッセージとして送信することが可能となる。
【００３７】  さらに、本発明の通信ハンドオーバ方法は、上記の構成に加えて、前記付加的サービスが、ＱｏＳ保証である。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていたＱｏＳ保証を迅速かつ継続して受けられるようになる。
【００３８】  また、本発明によれば、上記の通信ハンドオーバ方法をコンピュータにより実行するための通信ハンドオーバ用プログラムが提供される。
【００３９】  また、上記目的を達成するため、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が前記アクセスポイントの通信を切り換える場合に、前記移動端末が所望する通信切り換え後の付加的サービスに係る準備を行うことのできるルータにおける通信メッセージ処理方法であって、
前記移動端末から、前記移動端末が現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを受信する第１の情報受信ステップと、
前記付加的サービスの情報を基に、付加的サービスの準備を行うためのメッセージを生成するステップと、
前記移動端末が現在通信中に受けている付加的サービスに関する情報に基づいて、前記移動端末が現在通信中の相手端末を特定する端末特定ステップと、
前記移動端末が現在通信中に受けている付加的サービスに関する情報に基づいて、前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を取得するためのメッセージを生成し、前記メッセージを前記相手端末に送信する情報送信ステップと、
前記相手端末、又は、前記相手端末への前記メッセージの経路上に存在する任意のノードから、前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を含むメッセージを受信する第２の情報受信ステップとを有している。
上記の構成により、移動端末がアクセスポイントの通信切り換えを行う前において、現在（通信切り換え前に）受けている付加的サービスをアクセスポイントの通信切り換え後も継続して受けるための処理が行われるようになり、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようになる。
【００４０】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記第２の情報受信ステップで、前記相手端末、又は、前記相手端末への前記メッセージの経路上に存在する任意のノードから受信した前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を格納する格納ステップを有している。
上記の構成により、移動端末が現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを移動端末から受信したルータは、相手端末までの経路に係る情報を把握して、その情報を保持することが可能となる。
【００４１】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記第２の情報受信ステップで、前記相手端末から受信した前記通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報が含まれるメッセージを生成して、前記移動端末に前記メッセージを送信するステップを有している。
上記の構成により、移動端末が現在通信中に受けている付加的サービスに関する情報が含まれるメッセージを移動端末から受信したルータは、通信切り換え後の付加的サービスに係る準備を行うことを可能とする情報を取得した後、移動端末に対して通知することが可能となる。
【００４２】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記第１の情報受信ステップで、前記アクセスルータが属する前記サブネット内に存在しない前記移動端末から受信した前記メッセージの中に、前記アクセスルータが属する前記サブネットで前記移動端末によって使用可能なアドレス情報が含まれている場合には、前記アドレス情報の妥当性を検証するステップと、
前記アドレス情報の妥当性が把握された場合には、前記アドレス情報に基づいて、前記移動端末が前記通信切り換え後に受ける前記付加的サービスのための経路を、あらかじめ確立するステップを有している。
上記の構成により、付加的サービスのための経路の確立には、移動端末のアドレス情報が必要であり、例えば、移動端末によって、ステートレス自動設定により生成されたアドレス情報の妥当性が把握された場合に、移動端末に係る付加的サービスのための経路をあらかじめ確立することが可能となる。
【００４３】  また、上記目的を達成するため、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断する予約判断ステップと、
前記予約判断ステップにおける判断結果を含むメッセージを前記所定の経路が設定されているか否かを調べるためのメッセージの送信元又は送信先に送信するステップとを有している。
上記の構成により、所定の経路が設定されているか否かを調べるために、所定の経路に係るフロー識別子及びセッション識別子が含まれているメッセージを受信したノード又はルータは、このフロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断して、その結果をメッセージに関連する所定の送信元又は送信先に返すことが可能となる。
【００４４】  また、上記目的を達成するため、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断する予約判断ステップと、
前記予約判断ステップにおいて、前記メッセージに含まれる前記フロー識別子及びセッション識別子に対するリソース予約が行われていると判断された場合には、前記メッセージの所定の箇所に前記リソース予約に利用されているインタフェースのアドレス情報を付加して、前記メッセージの転送を行う転送ステップとを有している。
上記の構成により、所定の経路が設定されているか否かを調べるために、所定の経路に係るフロー識別子及びセッション識別子が含まれているメッセージを受信したノード又はルータは、フロー識別子及びセッション識別子に対するリソース予約が行われているか否かを判断し、リソース予約が行われている場合には、リソース予約に係る自装置のインタフェースのアドレス情報をメッセージ内に挿入して、このメッセージを転送することが可能となり、例えば、メッセージの内容を参照すれば、経路のリソース予約を行っているノード又はルータを特定することが可能となる。
【００４５】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記所定の箇所によって、前記インタフェースのアドレス情報の付加順序が表されている。
上記の構成により、インタフェースのアドレスの付加順序から、ノード又はルータの経路における配列を推測することが可能となる。
【００４６】  また、上記目的を達成するため、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムにおいて、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末との間で通信を行い、前記移動端末との間で通信を行う際に、付加的サービスに係る経路を確立することが可能な通信ノードにおける通信メッセージ処理方法であって、
所定の経路に係るフロー識別子及びセッション識別子が含まれており、前記所定の経路を探索するためのメッセージを受信した場合には、前記メッセージ内の前記所定の経路の探索結果を含む新たなメッセージを生成して、前記メッセージの応答として送信するステップを有している。
上記の構成により、例えば、移動端末と相手端末との間で確立されている付加的サービスの経路を探索するためのメッセージを相手端末に対して送信し、そのメッセージが収集した探索結果を含むメッセージを応答として返すことが可能となる。
【００４７】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記所定の経路が設定されているか否かを調べるためのメッセージ、又は、前記所定の経路を探索するためのメッセージが、前記経路に係るフロー識別子及びセッション識別子を含ませることが可能な領域を有しているＱＵＥＲＹメッセージ又はＲＥＳＰＯＮＳＥメッセージである。
これにより、従来存在するＱＵＥＲＹメッセージ及びＲＥＳＰＯＮＳＥメッセージを利用して、１回のメッセージの送受信で所定の経路に係る情報を取得することが可能となる。
【００４８】  さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記所定の経路が設定されているか否かを調べるためのメッセージ、又は、前記所定の経路を探索するためのメッセージが、空きリソースの情報を含ませることが可能な領域を有している。
上記の構成により、上記のメッセージによって、空きリソースの情報（例えば、リソースの解放状況）などを把握することが可能となる。
【００４９】  また、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記セッション識別子に対するステートを有しているか否かを判断する予約判断ステップと、
前記予約判断ステップで前記セッション識別子に対するステートを有していないと判断された場合には、前記メッセージを前記所定の通信端末に向けて送信する送信ステップを有している。
上記の構成により、例えば、移動端末が、移動端末と相手端末との間で確立されている付加的サービスの経路を探索するためのメッセージを相手端末方向に向けて送信し、このメッセージが相手端末に到達することなく、クロスオーバノードの発見を行うことが可能となって、より迅速なクロスオーバノードの発見が可能となる。
【００５０】  また、本発明の通信メッセージ処理方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されており、前記通信可能領域内に存在する移動端末が前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている通信システム内に配置されており、前記移動端末が所定の通信端末との通信を行う際の付加的サービスに係る経路を構成するノード又はルータにおける通信メッセージ処理方法であって、
所定の経路に係るセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記セッション識別子に対するステートを有しているか否かを判断する予約判断ステップと、
所定の経路に係るフローを特定する識別情報及びセッション識別子が含まれており、前記所定の経路が設定されているか否かを調べるためのメッセージを受信した場合には、前記フローを特定する識別情報に対するステートを有しているか否かを判断する予約判断ステップと、
前記予約判断ステップで前記セッション識別子に対する前記ステートを有していると判断された場合には、前記ステート及び前記メッセージ内のそれぞれにおいて、異なる隣り合うノード又はルータが指定されているか否かを判断する判断ステップと、
前記判断ステップで異なる前記隣り合うノード又はルータが指定されている場合には、自身がクロスオーバノードであると判断するＣＲＮ判断ステップとを、
有している。
上記の構成により、例えば、移動端末が、移動端末と相手端末との間で確立されている付加的サービスの経路を探索するためのメッセージを相手端末方向に向けて送信し、このメッセージが相手端末に到達することなく、クロスオーバノードの発見を行うことが可能となって、より迅速なクロスオーバノードの発見が可能となる。
【００５１】  また、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記ＣＲＮ判断ステップで自身がクロスオーバノードであると判断された場合には、所定のノードに対して、自身がクロスオーバノードである旨を通知する通知ステップを有している。
上記の構成により、例えば、プロキシとして機能するノードなどに対して、クロスオーバポイントの通知を行うことが可能となる。
【００５２】  また、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記付加的サービスに係る経路を構成する前記ノード又はルータが、各リソースと、フローを特定する情報との対応関係を格納するためのフロー識別リストを持っており、自身を経由する付加的サービスに係る経路に関連する前記フローを特定する情報を、前記フロー識別リストに追加又は削除するステップを有している。
上記の構成により、付加的サービスに係る経路の構成要素であるノード又はルータは、リソースと、フローを特定する情報との対応関係を把握することが可能となる。
【００５３】  また、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記ＣＲＮ判断ステップで自身がクロスオーバノードであると判断された場合には、受信する各ノード又はルータに対して、前記所定の経路に対する前記リソースが割り当てられている前記フロー識別リストに新たなフローを特定する情報を追加させるためのメッセージを前記通信端末に向けて送信する更新ステップを有している。
上記の構成により、新旧２つの経路における重複部分のリソース割り当て変更を迅速に行うことが可能となる。
【００５４】  また、本発明によれば、上記の通信ハンドオーバ方法をコンピュータにより実行するための通信メッセージ処理用プログラムが提供される。
【００５５】  本発明は、上述の構成を有する通信ハンドオーバ方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムを提供するものであり、前もって（ハンドオーバ前又はハンドオーバ直後に）ＣＲＮを見つけることによりハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようにするという効果を有する。また、ハンドオーバを行った端末、又は移動してくる端末の代理のルータ（プロキシ）が、新しい経路の情報を得るためにＱＵＥＲＹを行う場合、ＣＲＮとＣＮとの間で、ＭＮが移動前に行っていたリソース予約状況を考慮に入れ、正しい情報を返すことができる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施の形態における通信システムの構成を示す模式図
【図２】本発明の実施の形態におけるＭＮの構成を示すブロック図
【図３】本発明の実施の形態におけるプロキシの構成を示すブロック図
【図４】本発明の実施の形態におけるＱＮＥの構成を示すブロック図
【図５】本発明の実施の形態におけるＣＮの構成を示すブロック図
【図６】本発明の実施の形態において、プロキシ及びＣＮが送受信し合うメッセージに、どのようにＱＮＥによって処理された情報が格納されるかの一例を示す模式図
【図７】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図８】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図９】本発明及び従来の技術に共通した無線通信システムの構成を示す模式図
【図１０】従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図
【図１１】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図１２】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図１３】従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図
【図１４】従来の技術におけるＮＳＩＳにおいて、どのように２重のリソース予約を回避するとされているかを説明する模式図
【図１５】本発明の実施の形態におけるＭＮ内に格納されるプロキシ情報の一例を示す模式図
【図１６】本発明の実施の形態におけるＭＮ内に格納されるＡＰ−ＡＲ対応情報の一例を示す模式図
【図１７】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１８】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１９】本発明の実施の形態において、メッセージＣの受信後における別の処理方法を実現するプロキシの構成を示すブロック図
【図２０】本発明の実施の形態において、メッセージＢの受信後における別の処理方法を実現するＣＮの構成を示すブロック図
【図２１】本発明の実施の形態における通信システムにおいて、プロキシがＣＲＮにＱｏＳ経路確立の依頼を行う際の動作の一例を示すシーケンスチャート
【図２２】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図２３】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図２４】本発明の実施の形態における通信システムにおいて、ＭＮがメッセージをＣＮまで送ることなくＣＲＮを見つける際の動作の一例を示すシーケンスチャート
【図２５】本発明の実施の形態における通信システムにおいて、メッセージを受け取ったＱＮＥが、自分がＣＲＮであるか否かを判断する方法の一例を示すフローチャート
【発明を実施するための最良の形態】
【００５７】  以下、図１〜図８及び図１５、１６を参照しながら、本発明の実施の形態について説明する。図１は、本発明の実施の形態における通信システムの構成を示す模式図である。図１には、ＭＮ１０が、ハンドオーバ前にサブネット２０に接続されている状態において、ＣＮ６０との間で確立されているＱｏＳ経路（経路２４）が実線で図示されている。この経路２４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ２１、ＮＥ６２、ＱＮＥ６３、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。また、同様に、ＭＮ１０が、ハンドオーバ後にサブネット３０に接続した場合に、ＣＮ６０との間で確立されるＱｏＳ経路（経路３４）が点線で図示されている。この経路３４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ３１、ＱＮＥ（プロキシ）６８、ＱＮＥ６７、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。したがって、古い経路（経路２４）と新しい経路（経路３４）とが交わり始めるＱＮＥ（ＣＲＮ）は、ＱＮＥ６５である。【００５８】  次に、ＭＮ１０の機能について説明する。図２は、本発明の実施の形態におけるＭＮの構成を示すブロック図である。なお、図２では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図７に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。【００５９】  図２に示すＭＮ１０は、ハンドオーバ先候補決定手段１０１、無線受信手段１０２、無線送信手段１０３、プロキシ決定手段１０４、メッセージ生成手段１０５、メッセージ受信手段１０６を有している。また、オプションとして、ＮＣｏＡ生成手段１０７、プロキシ情報格納手段１０８を有してもよい。なお、図２では、オプション部分に関しては、点線で図示されている。【００６０】  ハンドオーバ先候補決定手段１０１は、例えば、異なる複数のＡＰからのシグナルを受信して、Ｌ２ハンドオーバ可能なＡＰ一覧を探す手段である。なお、ＭＮ１０は、ハンドオーバ先候補決定手段１０１によるＬ２ハンドオーバ先候補の決定を行うことなく、直接、後述のプロキシ決定手段１０４による処理を行うこともできる。また、無線受信手段１０２及び無線送信手段１０３は、それぞれ無線通信によるデータ受信及びデータ送信を行うための手段であり、これらには、無線通信を行うために必要な様々な機能が含まれている。【００６１】  また、プロキシ決定手段１０４は、プロキシを発見する手段である。プロキシ決定手段１０４によって発見されるプロキシとは、ＭＮ１０の代理となって、ＭＮ１０がハンドオーバ後に付加的サービス（ここではＱｏＳとする）を寸断されることなく受けられるよう、あらかじめ準備することのできる、ＱｏＳ提供機能を持ったＮＳＩＳノード（ＱＮＥ）のことであり、ＭＮ１０がハンドオーバした際に張られる予定のＱｏＳ経路上に存在する。【００６２】  このプロキシの発見を行うためには、複数の方法が考えられる。例えば、ハンドオーバ先候補決定手段１０１によって取得されたＡＰ一覧の情報を基に、ＭＮ１０内にローカルに蓄えられているプロキシ情報４０（プロキシ情報格納手段１０８に格納されているプロキシ情報４０）を参照し、ＡＰが接続されているサブネットワーク上で、ＣＮ６０と通信するために適したプロキシ情報４０を検索して決定する方法や、このＡＰ一覧の情報をＩＰネットワーク上に存在するサーバ（プロキシ検索サーバとする）などに送信し、前述の最も適したプロキシに係る情報を返してもらう方法、又は、プロキシ情報４０に蓄えられている、すべてのプロキシを選択する方法などが挙げられる。なお、ハンドオーバ先候補のＡＲそのものがＱＮＥであり、プロキシになる場合もあり得る。図１５には、プロキシ情報４０の内容の一例が図示されている。なお、図１５に示すプロキシ情報４０は、図９におけるネットワーク構成を参照して作成された一例である。図１５に示すプロキシ情報４０は、ＭＮが各ＡＰと接続されている場合において、プロキシとして選択可能なノードのＩＰアドレスを有しており、ＭＮは、このプロキシ情報４０を参照することによって、プロキシの選択及び特定を行うことが可能となる。なお、プロキシとしては、各ＡＰを配下に有するＡＲの近く（ネットワーク構成上のＡＲ近傍）に存在するＱＮＥが設定されることが望ましい。【００６３】  また、メッセージ生成手段１０５は、プロキシにおいて、ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報を含むメッセージを生成するための手段である。ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報としては、例えば、現在使用しているフロー識別子とセッション識別子や、データの流れの方向（ＭＮ１０からＣＮ６０の方向か、ＣＮ６０からＭＮ１０の方向か、または双方向通信か）などが挙げられる。なお、メッセージ生成手段１０５によって生成される上記のメッセージをメッセージＡとする。【００６４】  メッセージ受信手段１０６は、プロキシが前述の準備を行った際に、準備が成功したかどうかという情報を含むメッセージ（メッセージＤとする）を、プロキシから受信するための手段であり、新しいＱｏＳ経路を張る手法によっては省略可能である。なお、このメッセージＤには、プロキシが前述の準備を行った際に得られた情報などを含めることもできる。【００６５】  また、ＭＮ１０は移動先を特定して、そこで使用するＮＣｏＡを生成し、それを移動先のプロキシに送ることも可能である。このＮＣｏＡを生成するための手段がＮＣｏＡ生成手段１０７であり、生成されたＮＣｏＡはメッセージ生成手段１０５において、フロー識別子などと共にメッセージＡ内に格納される。ＮＣｏＡ生成方法については、例えば、ＭＮ１０が図１６（図１５と同様に、図９を参照して作成された一例）に示すようなＡＰ−ＡＲ対応情報４１をローカルに持ち、ハンドオーバ先候補決定手段１０１によって得られたＡＰの情報を基にして、このＡＰ−ＡＲ対応情報４１を検索し、ＡＰが繋がっている先のＡＲの情報（例えば、ＡＲのリンクレイヤアドレス、ＡＲの属するサブネットのネットワークプリフィックスやプリフィックスレングスなど）を得ることにより、ＮＣｏＡをステートレスに自動生成する方法が考えられる。【００６６】  ただし、この場合には、ＮＣｏＡはス���ートレスに自動生成されたものであるため、実際に、このＮＣｏＡがハンドオーバ先のサブネットで使用可能なものであるかどうかを確認する手段が必要である。このため、例えばハンドオーバ先として、ＡＲそのものがプロキシとなることのできるサブネットを選び、このＡＲにＮＣｏＡを含んだメッセージＡを送ることにより、このプロキシ機能を持ったＡＲに、ＮＣｏＡの妥当性を調べてもらうなどの処理が必要である。また、他のＮＣｏＡ獲得方法としては、現在通信中のＡＲ（ハンドオーバ前のサブネット２０に属するＡＲ）が、近隣のサブネットワークのＤＨＣＰサーバより、使用可能なＣｏＡの一部をあらかじめ受け取り、ＭＮ１０が別のＡＲ（ハンドオーバ後のサブネット３０に属するＡＲ）に移動を行う前に、そのサブネットのＤＨＣＰサーバからもらったＣｏＡのうちの１つをＭＮ１０に割り当てる方法も可能である。この場合には、ＣｏＡはステートフルに割り当てられるので、ＣｏＡに係る妥当性のチェックが行われる必要はなく、前述のように、プロキシ機能を持ったＡＲを選ぶという制限はなくなる。また、メッセージＡには、これ以外の情報（例えば、ＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）のＩＰアドレスなどの情報）も含めることができる。【００６７】  次に、ＭＮ１０からメッセージを受け取るプロキシ（ＱＮＥ６８）の機能について説明する。なお、ここで、ＭＮ１０はプロキシの１つとして、図１中のＱＮＥ６８をプロキシの１つとして選んだ場合を考える。図３は、本発明の実施の形態におけるプロキシの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図３に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図７に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。【００６８】  図３に示すプロキシ６８は、受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６を有している。また、オプションとして、メッセージ生成手段６８７、及び経路情報格納手段６８８を有してもよい。なお、図３では、オプション部分に関しては、点線で図示されている。【００６９】  受信手段６８１及び送信手段６８２は、データ受信及びデータ送信を行うための手段である。また、メッセージ処理手段６８３は、図２に示すＭＮ１０のメッセージ生成手段１０５で生成され、無線送信手段１０３で送信されたメッセージ（メッセージＡ）を受信、処理するための手段である。例えば、メッセージＡ中に含まれるデータの流れの情報を確認し、どのような形でＱｏＳ経路を確立するのが望ましいかを判断する。なお、データの流れによるＱｏＳ経路確立方法の変化に関しては、後述の中間のＱＮＥの機能と共に説明する。【００７０】  また、メッセージ生成手段６８５は、メッセージ処理手段６８３で受け取ったフロー識別子（例えば、経路２４のフロー識別子Ｘ）、セッション識別子（例えば、経路２４及び経路３４に共通のセッション識別子Ｙ）を含むメッセージ（メッセージＢとする）を生成する。メッセージ生成手段６８５によって生成される上記のメッセージＢは、ＣＲＮを発見するた��のメッセージであり、送信手段６８２を介してＣＮ６０に向けて送信される。なお、このフロー識別子の中には、ＣＮ６０のＩＰアドレス情報が含まれている。【００７１】  また、メッセージ処理手段６８４は、メッセージ生成手段６８５で生成され、送信されたメッセージＢを受け取ったＣＮ６０から、経路３４上の各ＱＮＥを介して送られてきたメッセージ（メッセージＣとする）を受信、処理する手段である。このメッセージＣには、ＣＲＮの情報が含まれている。メッセージ処理手段６８４では、このＣＲＮ情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。この処理を行うには、複数の方法が考えられる。例えば、この情報を経路情報格納手段６８８に渡し、ＭＮ１０がハンドオーバして来た時点で何かしらの処理を行ってもよく、また、その情報をさらにメッセージ生成手段６８６に渡して、ＭＮ１０への返信メッセージ（前述のメッセージＤ）としてもよい。ただしこの場合には、ＭＮ１０には、図２のメッセージ受信手段１０６が設けられている必要がある。なお、前述の通り、メッセージＤには準備が成功したかどうかという情報が含まれてもよい。また、さらに、メッセージＤには、これ以外の情報が含まれてもよい。【００７２】  また、メッセージ処理手段６８３で、ＭＮ１０のＮＣｏＡの情報を受け取っていた場合には、メッセージ生成手段６８７で、このＮＣｏＡを基に新しいフロー識別子を生成し、メッセージ処理手段６８４で受け取ったＣＲＮの情報を基に、ＲＥＳＥＲＶＥメッセージをＣＮ６０に送信することによって、経路３４上に新しいＱｏＳ経路を生成してもよい。ただしこの場合には、ＲＥＳＥＲＶＥメッセージにＣＲＮの情報を持たせ、該当するＣＲＮは、そこからＣＮ６０までのリソース予約を２重予約にならないようにするなど、別の機能が必要になる。なお、ＱｏＳ経路確立に必要となり、ＲＥＳＥＲＶＥメッセージに含まれるべきＱＳｐｅｃの情報などに関しては、例えば、メッセージＣに含まれるＣＲＮの情報を参照して、このＣＲＮから取得することができる。また、メッセージＡにＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）の情報が含まれている場合には、ＱＮＥ６３から取得することもできる。また、前述のように送られたＮＣｏＡが、妥当性のチェックが必要なものだった場合には、そのチェックを行わなければならない。もし、このプロキシがＮＣｏＡの妥当性チェック機能を有していなかった場合、又は妥当性チェックを行った結果、妥当で無かった場合には、例えば、ＭＮ１０にエラー通知を行うためのエラーメッセージを返す必要がある。このエラー通知は、メッセージＤに含めることも可能であり、また、別のメッセージ（例えば、ＦＭＩＰにおけるＦＢＡｃｋメッセージ）として返すことも可能である。また、メッセージ生成手段６８５で生成されるメッセージＢには、上記以外の情報（例えば、妥当であることが確認されたＮＣｏＡや、メッセージＡに含まれているＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）などの情報）を含めることもできる。【００７３】  次に、経路３４上の中間のＱＮＥの機能について、ＱＮＥ６５を例に取って説明する。図４は、本発明の実施の形態における経路３４��の中間ＱＮＥの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図４に示すＱＮＥ６５が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図７に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。【００７４】  図４に示すＱＮＥ６５は、受信手段６５１、送信手段６５２、メッセージ処理手段６５３、メッセージ生成手段６５４を有している。受信手段６５１、送信手段６５２は、図３に示すプロキシ６８の受信手段６８１、送信手段６８２と同じ機能を有している。また、メッセージ処理手段６５３は、前述のメッセージＢ又はメッセージＣを受け取った際、その中に含まれているフロー識別子とセッション識別子の組で、すでにＱＮＥ６５内にリソース予約が無いかどうかを調べる手段である。予約が無かった場合は、メッセージ生成手段６５４では何も行われずに、送信手段６５２を経由して次のＱＮＥにメッセージＢ又はメッセージＣが転送される。一方、予約があった場合は、メッセージ生成手段６５４において、そのインタフェースのＩＰアドレスが同メッセージ内に格納され、メッセージ生成手段６５４で生成された新たなメッセージが、送信手段６５２を経由して次のＱＮＥに送信される。ただし、メッセージＢやメッセージＣが、他の何かしらの処理をＱＮＥに求めるものだった場合、例えば、ＱＵＥＲＹメッセージやそれに対するＲＥＳＰＯＮＳＥメッセージの拡張だった場合には、これらのメッセージに特有の処理が行われる。【００７５】  メッセージＢ、メッセージＣのどちらで上述の処理を行うかは、データの流れの方向、及びその他のＮＳＩＳの機能により異なる。一例としては、データの流れがＣＮ６０からＭＮ１０の方向のみだった場合、ＲＳＶＰ（非特許文献３参照）のＱｏＳ経路確定方法の考え方に従えば、ＣＮ６０から送られるメッセージＣを受け取った際に、上述の処理を行うのが妥当である。【００７６】  なお、データやシグナリングが通る経路は、ＭＮ１０からＣＮ６０の方向（ｕｐｓｔｒｅａｍとする）と、ＣＮ６０からＭＮ１０の方向（ｄｏｗｎｓｔｒｅａｍとする）で違う場合も考えられるので、実際問題として、メッセージＣは経路３４を通る（経路３４を確定することができる）が、メッセージＢは経路３４を通らないということも考えられる。したがって、経路３４上の各ＱＮＥでは、メッセージＢ及びメッセージＣのどちらか一方のみしか受け取らないこともあり得る。【００７７】  逆に、同じ考え方を採用した場合、データの流れがｕｐｓｔｒｅａｍだった場合にはメッセージＢにより経路３４が確定され、上述のメッセージ処理手段６５３及びメッセージ生成手段６５４にて処理が行われる。この場合には、メッセージＣは各ＱＮＥによって、メッセージＢを受け取った際に処理された結果をプロキシ６８に返すためのみのメッセージとなり得る。しかしながら、ＮＳＩＳではＮＴＬＰの機能を活用することにより、必ずしもＲＳＶＰの経路確定方法の考え方が当てはまるとは限らない。例えば、ｄｏｗｎｓｔｒｅａｍ方向のデータの流れに対し、メッセージＢが経路３４を通り、必要な情報を集めることも可能になり得る。【００７８】  次���、ＣＮ６０の機能について説明する。図５は、本発明の実施の形態におけるＣＮの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図５に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図７に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。【００７９】  図５に示すＣＮ６０は、受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、経路情報格納手段６０５を有している。受信手段６０１、送信手段６０２は、図３に示すプロキシ６８の受信手段６８１、送信手段６８２や、図４に示す受信手段６５１、送信手段６５２と同じ機能を有している。また、メッセージ処理手段６０３は、メッセージＢを受け取って処理する機能を有している。例えば、メッセージ処理手段６０３では、メッセージＢがｕｐｓｔｒｅａｍに対して出されたものか、ｄｏｗｎｓｔｒｅａｍに対して出されたものかが判断される。また、メッセージＢにｕｐｓｔｒｅａｍ用のＣＲＮの情報が含まれている場合には、メッセージ処理手段６０３は、そのＣＲＮの情報を経路情報格納手段６０５に渡して保有させることも可能である。ＣＮ６０は、経路情報格納手段６０５に格納された情報を使うことによって、ＭＮ１０のＮＣｏＡの情報が得られたときに、ＲＥＳＥＲＶＥメッセージを用いたＱｏＳ経路確立処理を行うことができる。なお、ＭＮ１０のＮＣｏＡの情報は、メッセージＢに含まれている場合にはメッセージＢの受信と同時に取得することが可能であり、また、ＭＮ１０からのＢＵメッセージより取得することも可能である。また、ＲＥＳＥＲＶＥメッセージに含まれるべきＱＳｐｅｃの情報などに関しては、前述の通り、ＣＲＮから取得することも可能であり、また、メッセージＢがＱＮＥ６３のＩＰアドレスを含んでいる場合には、ＱＮＥ６３から取得することも可能である。また、メッセージ生成手段６０４ではメッセージＣを生成し、送信手段６０２を通じてメッセージＣを送信する手段である。なお、メッセージＢに経路情報（どのＱＮＥがリソース予約を持っていたか）が含まれていた場合には、それをメッセージＣに含めて送信することも可能である。また、メッセージＣは、上記以外の情報を含んでいてもよい。【００８０】  次に、メッセージＢ及びメッセージＣを送受信することにより、どのようにＣＮ６０やプロキシ６８がＣＲＮの情報を得ることができるかについて説明する。今、ＭＮ１０とＣＮ６０が、例えばＩＰテレフォニなどを使って、双方向通信を行っているとする。この場合、データの流れはｕｐｓｔｒｅａｍとｄｏｗｎｓｔｒｅａｍの両方があり、これら双方向のデータは必ずしも同じ経路（同じルータ）を通るとは限らないので、ＣＲＮもｕｐｓｔｒｅａｍ側とｄｏｗｎｓｔｒｅａｍ側でそれぞれ違うと考えられる。ここでは、図１を参照しながら、双方向のデータが同じ経路を通ると仮定するが、双方向のデータが違う経路を通る場合においても、後述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。なお、双方向通信の場合には、それぞれの方向の通信経路に関して、フロー識別子とセッション識別子とが存在しており、プロキシは、これら２方向のフロー識別子、セッション識別子の組をＭＮ１０からもらい、メッセージＢに埋め込んでＣＮ６０に送るようにすればよい。【００８１】  図６には、メッセージＢ及びＣの送受信により、プロキシが得ることのできる情報の一例が図示されている。メッセージＢ及びメッセージＣには、各メッセージが持っているフロー識別子、セッション識別子のペアに対するリソースの予約を持つＱＮＥを通過するたびに、そのリソース予約を持つインタフェースのＩＰアドレスの情報が、各メッセージの最後に付加される。例えばメッセージＢの場合には、ＱＮＥ６５を通過する際、ｕｐｓｔｒｅａｍのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８１：ＱＮＥ６５の上側（ＱＮＥ６６側）インタフェースのＩＰアドレス）が付けられ、ＱＮＥ６６を通過する際には、その更に後ろに、ＱＮＥ６６内のｕｐｓｔｒｅａｍのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８２：ＱＮＥ６６の上側（ＣＮ６０側）インタフェースのＩＰアドレス）が付けられる。このメカニズムにより、この情報がＣＮ６０やプロキシ６８に返された場合には、ＣＮ６０やプロキシ６８は、最初に付けられたインタフェースのＩＰアドレス（情報８１のＩＰアドレス）を持つＱＮＥが、ｕｐｓｔｒｅａｍのＣＲＮだと判断することができる。また、ｄｏｗｎｓｔｒｅａｍに関しては順序が逆になるので、プロキシ６８は、情報８３及び情報８４のうち、最後に付けられたインタフェースのＩＰアドレス（情報８４のＩＰアドレス）を持つＱＮＥが、ｄｏｗｎｓｔｒｅａｍのＣＲＮだと判断することができる。なお、ＱｏＳ経路は、ネットワークの状態などの要因によって変化する可能性があり、ＱｏＳ経路の変化に応じて、ＣＲＮも変化する可能性がある。このようなＣＲＮの変化が生じる可能性に対処するため、ＣＮ６０やプロキシ６８が保持するＣＲＮの情報に対して有効期限を設定し、その有効期限が切れる前に、ＣＮ６０やプロキシ６８が、ＣＲＮに変化が生じていないかの確認を行ったり、最新のＣＲＮの情報を取得したりすることによって、正確なＣＲＮの情報を保持できるようにすることも可能である。なお、この有効期限の設定は、ＣＲＮの情報を受け取るＣＮ６０やプロキシ６８が行ってもよく、また、ＭＮ１０がメッセージＡを送る際に、ＣＮ６０やプロキシ６８に対して、有効期限を通知してもよい。【００８２】  次に、ＭＮ１０が、プロキシ６８にＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作について説明する。図７及び図８には、本発明の実施の形態において、ＭＮ１０がプロキシ６８に識別子（フロー識別子及びセッション識別子）の情報を送り、プロキシ６８とＣＮ６０とが中間ＱＮＥ６５〜６７を介してメッセージをやり取りすることにより、ｕｐｓｔｒｅａｍやｄｏｗｎｓｔｒｅａｍのＣＲＮを見つける動作例を示すシーケンスチャートが図示されている。なお、図７及び図８に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに��ばれている場合のものであり、ここでは、プロキシ６８がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている。また、図７及び図８に示すシーケンスチャートには、一連の動作が示されており、図７及び図８のシーケンスチャートに図示されているステップＳ５２３の処理は同一である。【００８３】  近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ５０１：ハンドオーバ先候補を決定）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ５０３：ＱＮＥ６８をプロキシの１つ（プロキシ６８）として決定）。プロキシを決定したＭＮ１０は、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子をメッセージＡにセットするとともに、双方向通信であるという情報もメッセージＡにセットして（ステップＳ５０５：経路２４でのｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のフロー識別子、セッション識別子、及び“双方向通信”をメッセージＡにセット）、選んだプロキシ群（複数のプロキシ）にメッセージＡを送信する（ステップＳ５０７）。ここでは特に、プロキシ群のうちの１つであるプロキシ６８に対してメッセージＡが送られた後の処理に限って説明する。なお、メッセージＡには、メッセージＢの送信先の情報（ＩＰアドレスなど）が含まれていてもよい。メッセージＢの送信先は、図７及び図８の例ではＣＮ６０であるが、例えばモバイルＩＰｖ６における三角経路を用いた通信に対するＱｏＳ経路のＣＲＮ検索が行われる場合には、メッセージＢの送信先をＭＮ１０のホームエージェントとすることも可能である。【００８４】  プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでｕｐｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｄｏｗｎｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ５０９：メッセージＢでｕｐｓｔｒｅａｍ、メッセージＣでｄｏｗｎｓｔｒｅａｍの情報を得られるように、メッセージＢにパラメータをセットし、受信したフロー識別子及びセッション識別子もメッセージＢにセット）、ＣＮ６０にメッセージＢを送信する（ステップＳ５１１）。なお、このとき、プロキシ６８はフロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。【００８５】  プロキシ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７は、メッセージＢの中身を確認し、その中のｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ内に存在するかどうかを確認する。そして、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥは、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加して、ＣＮ６０に向けて送る。一方、ｕｐｓｔｒｅ��ｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。【００８６】  なお、ＱＮＥ６７には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ５１３：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約はないので、そのまま次に送信、ステップＳ５１５）。また、ＱＮＥ６５には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ５１７：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５１９）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ５２１：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５２３）。【００８７】  そして、最終的にメッセージＢはＣＮ６０に到着し、このメッセージＢを受け取ったＣＮ６０は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでｄｏｗｎｓｔｒｅａｍ用経路の情報を収集できるようにパラメータをセットして（ステップＳ５２５：メッセージＢの内容をメッセージＣにセットし、メッセージＣでｄｏｗｎｓｔｒｅａｍ用情報を集めるようパラメータをセット）、プロキシ６８に向けて送信する（ステップＳ５２７）。また、ＣＮ６０からプロキシ６８への経路上にある各ＱＮＥ６５〜６７は、上述のメッセージＢに対する処理と同様の処理をｄｏｗｎｓｔｒｅａｍ用のメッセージＣに対して行う。【００８８】  すなわち、ＱＮＥ６６には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ５２９：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５３１）。また、また、ＱＮＥ６５と同様に、ＱＮＥ６５にも、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ５３３：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５３５）。また、ＱＮ��６７には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ５３７：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約はないので、そのまま次に送信、ステップＳ５３９）。【００８９】  このようにしてメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を特定することが可能となり、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセットして（ステップＳ５４１：ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセット）、ＭＮ１０にメッセージＤを送信する（ステップＳ５４３）。【００９０】  なお、前述のＭＮ１０の機能で説明した通り、プロキシ６８はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ＭＮ１０は、ＣＲＮの情報を早期に知ることにより、例えば、サブネットを移動した後にリソース予約を行う際、このＣＲＮの情報をＲＥＳＥＲＶＥメッセージに含ませて送ることができる。また、ＣＲＮの情報を含むＲＥＳＥＲＶＥメッセージを該当するＣＲＮが受け取った場合には、該当するＣＲＮは、その先のＣＮ６０までのリソースを２重予約しないようにする処理を行うことが可能である。例えば、該当するＣＲＮは、新規にリソースを予約するのではなく、古い予約を更新するなどの処理を行うことも可能である。【００９１】  このようにＣＲＮの特定が前もってなされると、たとえＭＮ１０のハンドオーバ後のリソース予約であったとしても、従来の技術のように、ＣＲＮを探しながらのリソース予約とはならないために、迅速にＱｏＳ経路を張ることが可能となる。また、前述の通り、ＣＲＮの情報を得たプロキシ６８が、ＭＮ１０に情報を返すことなく、前もってリソース予約を行うようにすることも可能であり、より迅速なＱｏＳ経路確立が実現できる。【００９２】  また、さらに、前述の通り、メッセージＢやメッセージＣを既存のメッセージ、例えばＱＵＥＲＹメッセージやＲＥＳＰＯＮＳＥメッセージやＮＯＴＩＦＹメッセージに書き換えることも可能である。図１７及び図１８には、ＱＵＥＲＹメッセージにメッセージＢの機能を、ＲＥＳＰＯＮＳＥメッセージにメッセージＣの機能を持たせた場合のシーケンスチャートが図示されている。ここでは、やり取りされるメッセージが、ｕｐｓｔｒｅａｍ及びｄｏｗｎｓｔｒｅａｍのＣＲＮを見つける機能のほかに、本来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージが持つ機能（空きリソースの情報の取得機能など）を有している。なお、図１７及び図１８中のステップＳ５５１〜Ｓ５９３は、図７及び図８中のステップＳ５０１〜Ｓ５４３と対応関係にあり、ＱＵＥＲＹメッセージとメッセージＣ、ＲＥＳＰＯＮＳＥメッセージとメッセージＤがそれぞれ対応関係にある。【００９３】  前述の通り、従来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージを利用した場合には、ＭＮ１０などの移動を行う端末は通信相手との間で行っている現���の通信で予約されているリソースの情報を知る術を持たないため、ＣＲＮとＣＮ６０間において、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができない。しかし、ＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージがＭＮ１０の現在のフロー識別子及びセッション識別子の情報を有することにより、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができる。【００９４】  なお、非特許文献６によると、リソースの空き情報を得られるのはＲＥＳＰＯＮＳＥメッセージによってのみである。つまり、図１７及び図１８に示すように、プロキシ６８からＣＮ６０にＱＵＥＲＹメッセージを送信し、ＣＮ６０からプロキシ６８にＲＥＳＰＯＮＳＥメッセージを返信する場合には、ｄｏｗｎｓｔｒｅａｍのリソースの空き情報しか得られない可能性がある。よって、双方向の空きリソースの情報が必要な場合は、プロキシ６８からＱＵＥＲＹメッセージを受け取ったＣＮ６０が、ＲＥＳＰＯＮＳＥメッセージをＭＮ１０に返すと同時に、別のＱＵＥＲＹメッセージをプロキシ６８に送信する必要も考えられる。また、ＮＳＩＳの他の機能と組み合わせることにより、一度のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージの送受信で、双方向のリソースの空き情報を得ることができる可能性もある。【００９５】  なお、プロキシ６８が図３のメッセージ処理手段６８４によって得たＣＲＮの情報（メッセージＣに含まれるＣＲＮの情報）を処理する方法、及び、ＣＮ６０が図５のメッセージ処理手段６０３によって得たＣＲＮの情報（メッセージＢに含まれるＣＲＮの情報）を処理する方法は、前述以外の方法も考えられる。これらの方法を、図１９及び図２０を参照しながら説明する。【００９６】  図１９は、本発明の実施の形態において、メッセージＣの受信後における処理方法を実現するプロキシの構成を示すブロック図である。なお、図３に示すプロキシ６８と同様に、図１９に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図１９における受信手段６８１１、送信手段６８１２、メッセージ処理手段６８１３、６８１４、メッセージ生成手段６８１５、６８１６、６８１７、及び経路情報格納手段６８１８は、図３における受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６、６８７、及び経路情報格納手段６８８にそれぞれ等しい機能を持つので、ここでの説明は省略する。【００９７】  図１９のメッセージ生成手段６８１９は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成し、送信手段６８１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６８１４のメッセージＢに係る処理によって特定されたＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認されたＭＮ１０のＮＣｏＡや、ＣＮ６０のＩＰアドレスなど）が含まれる。プロキシ６８が送信したメッセージＥを受け取ったＣＲＮは、例え��、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。【００９８】  また、図２０は、本発明の実施の形態において、メッセージＢの受信後における別の処理方法を実現するＣＮの構成を示すブロック図である。なお、図５に示すＣＮ６０と同様に、図２０に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図２０における受信手段６０１１、送信手段６０１２、メッセージ処理手段６０１３、メッセージ生成手段６０１４、及び経路情報格納手段６０１５は、図５における受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、及び経路情報格納手段６０５にそれぞれ等しい機能を持つので、ここでの説明は省略する。【００９９】  図２０のメッセージ生成手段６０１６は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成し、送信手段６０１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６０１３のメッセージＢに係る処理によって特定されたＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認された、前述の方法によって取得されたＭＮ１０のＮＣｏＡや、メッセージＢの送信元であるプロキシ６８のＩＰアドレスなど）が含まれる。メッセージＥを受け取ったＣＲＮは、例えば、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。【０１００】  次に、プロキシ６８が、メッセージＣの受信によって特定されたＣＲＮに、ＱｏＳ経路の生成の依頼を行う際の動作について説明する。なお、ここでは、双方向データ通信であって、双方向の経路が等しい場合を仮定するが、ｕｐｓｔｒｅａｍ側又はｄｏｗｎｓｔｒｅａｍ側のどちらか一方のみの場合、あるいは、双方向データ通信で、双方向の経路がｕｐｓｔｒｅａｍ側とｄｏｗｎｓｔｒｅａｍ側とで異なる場合においても、後述する方法と同様の方法をｕｐｓｔｒｅａｍ用経路、又は双方向経路に別々に用いることによって、ＱｏＳ経路生成依頼が行われるようにすることが可能である。【０１０１】  図２１には、本発明の実施の形態において、ＭＮ１０から、ＮＣｏＡを含むメッセージ（メッセージＡ）を受け取ったプロキシ６８が、ＣＮ６０とのメッセージ（メッセージＢ及びメッセージＣ）のやり取りで特定されたｄｏｗｎｓｔｒｅａｍ用ＣＲＮ宛てに、新しいＱｏＳ経路の作成を依頼する動作例を示すシーケンスチャートが図示されている。なお、図２１に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものである。また、図２１のステップＳ５００５と、ステップＳ５００７の間には、図７のステップＳ５１１からステップＳ５２３、及び図８のステップＳ５２５からステップＳ５３９と同様の処理が行われるが、ここでは省略されている。【０１０２】  プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、プロキシ６８は、メッセージＢでｕｐｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｄｏｗｎｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ５００１：メッセージＡを受信し、メッセージＢの送信準備）、ＣＮ６０にメッセージＢを送信する（ステップＳ５００５：メッセージＢをＣＮ６０に向けて送信）。なお、このとき、プロキシ６８は、フロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。また、プロキシ６８は、ステップＳ５００１におけるメッセージＢの送信準備と共に、メッセージＡに含まれているＭＮ１０のＮＣｏＡの妥当性のチェックを行う（ステップＳ５００３：メッセージＡに含まれるＭＮ１０のＮＣｏＡの妥当性チェック）。【０１０３】  そして、ステップＳ５００５で送信したメッセージＢの返信メッセージであるメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を特定する（ステップＳ５００７：メッセージＣを受信し、ｄｏｗｎｓｔｒｅａｍ用及びｕｐｓｔｒｅａｍ用ＣＲＮ（ＱＮＥ６５）の情報を得る）。プロキシ６８は、これらのＣＲＮが新しいＱｏＳ経路を確立するために必要な情報をメッセージＥにセットし（ステップＳ５００９：ＣＲＮ（ＱＮＥ６５）が新しいＱｏＳ経路を生成するのに必要な情報を、メッセージＥにセット）、ステップＳ５００７によって得られたｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮのそれぞれに対して、メッセージＥを送信する（ステップＳ５０１１及びステップＳ５０１３）。ここでは、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮが共にＱＮＥ６５となるが、ステップＳ５００７で取得したｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮのインタフェースアドレスがそれぞれ異なっていることも考えられるため（ＱＮＥ６５内の別々のインタフェースアドレスが、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮとしてステップＳ５００７で取得される）、メッセージＥはｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用それぞれ別々に送信されている。なお、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報としては、例えば、新しいＱｏＳ経路で使われるフロー識別子などが考えられる。この新しいフロー識別子は、ステップＳ５００３で妥当性が確認されたＭＮ１０のＮＣｏＡを基に生成されることが可能である。また、このほかに、さらに、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報は、ＣＮ６０のＩＰアドレスやセッション識別子なども考えられる。【０１０４】  メッセージＥを受け取ったＱＮＥ６５は、ＣＮ６０宛てにＱｏＳ経路を更新するためのＲＥＳＥＲＶＥメッセージを送信し（ステップＳ５０１５）、また、プロキシ６８宛てにＱｏＳ経路を新規で生成するためのＲＥＳＥＲＶＥメッセージを送信する（ステップ５０１７）。なお、ここでは、ステップＳ５０１５により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が更新され、ステップＳ５０１７により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が新規に生成される場合が示されている。【０１０５】  また、ＣＮ６０がｕｐｓｔｒｅａｍ用ＣＲＮの情報を取得した後に、ｕｐｓｔｒｅａｍ用ＣＲＮに対して新しいＱｏＳ経路を生成する依頼をする場合にも、同様の方法を用いることが可能である。この場合には、図２０に図示されているＣＮ６０がｕｐｓｔｒｅａｍ用ＣＲＮの情報と、ＭＮ１０の妥当なＮＣｏＡを取得した後、ｕｐｓｔｒｅａｍ用ＣＲＮに対して、メッセージＥを送信する。なお、この場合には、メッセージＥにプロキシ６８のＩＰアドレスの情報を含めることも可能である。【０１０６】  また、図２に示されるＭＮ１０のプロキシ決定手段１０４において、ＭＮ１０はプロキシとしてＣＮ６０を選ぶことも可能である。また、ＣＮ６０は、図３に示されるプロキシ６８と同様の機能を、図５に示されるＣＮ６０の機能と併せて持つことも可能であり、プロキシ６８は、図５に示されるＣＮ６０の機能と同様の機能を、図３に示されるプロキシ６８の機能と併せて持つことも可能である。この場合、ＭＮ１０からメッセージＡを受け取ったＣＮ６０が、プロキシ６８との間でメッセージＢ及びメッセージＣを送受信することにより、ＣＲＮの情報を得ることが可能である。【０１０７】  このように、プロキシ６８としてＣＮ６０が選択された場合の動作について、図２２及び図２３に示すシーケンスチャートを参照しながら説明する。なお、図２２及び図２３に示すシーケンスチャートには、一連の動作が示されており、図２２及び図２３のシーケンスチャートに図示されているステップＳ５０４３は同一の処理である。また、図２２及び図２３に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０の移動先サブネットワークの候補として、サブネット３０が選ばれている場合のものであり、ここでは、ＣＮ６０がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている場合が示されている。【０１０８】  図２２において、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ５０２１：ハンドオーバ先候補を決定）、その後、ＡＰのＬ２情報を基にして、ＭＮ１０がそのサブネットワークに移動した際に確立されるＱｏＳ経路上で、ＭＮ１０と隣り合うＱＮＥ（図１においてサブネット３０を移動先とした場合、経路３４上で最もＡＲ３１に近いＱＮＥ）を判定する（ステップＳ５０２３：ＱＮＥ６８を経路３４上でＡＲ３１に最も近いＱＮＥと判定）。この判定は、前述の実施の形態で、ＭＮ１０がプロキシを決定する方法と同様の方法を利用することが可能である。【０１０９】  ＭＮ１０は、ステップＳ５０２３で判定されたＱＮＥ（ＱＮＥ６８）の情報をメッセージＡにセットする（ステップＳ５０２５：ＱＮＥ６８の情報をメッ��ージＡにセット）。ここでは、特に、ステップＳ５０２３で判定されたＱＮＥの情報の１つとして、ＱＮＥ６８の情報がメッセージＡにセットされた場合について記述する。なお、メッセージＡには、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子、双方向通信であるという情報もセットされることが可能である。その後、ＭＮ１０はこのメッセージＡをＣＮ６０に送信する（ステップＳ５０２７）。【０１１０】  ＣＮ６０は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでｄｏｗｎｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｕｐｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、フロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ５０２９：メッセージＢでｄｏｗｎｓｔｒｅａｍ、メッセージＣでｕｐｓｔｒｅａｍの情報を得られるように、メッセージＢにパラメータをセットし、フロー識別子、セッション識別子もメッセージＢにセット）、ＱＮＥ６６にメッセージＢを送信する（ステップＳ５０３１）。なお、メッセージＢにセットすべきフロー識別子、セッション識別子の情報がメッセージＡに含まれている場合には、メッセージＡに含まれているこれらの情報をメッセージＢにコピーすることも可能である。一方、フロー識別子、セッション識別子の情報がメッセージＡに含まれていない場合においても、ＣＮ６０は、ＭＮ１０との現在の通信において使用しているフロー識別子、セッション識別子の情報をメッセージＢにセットすることが可能である。【０１１１】  ＣＮ６０からＱＮＥ６８への経路上に存在する各ＱＮＥ６５〜６７は、メッセージＢの内容を確認し、その中のｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ６５〜６７内に存在するかどうかを確認する。そして、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥ６５〜６７は、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加した後に、そのメッセージＢをＱＮＥ６８に向けて送る。一方、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。【０１１２】  なお、ＱＮＥ６６には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ５０３３：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５０３５）。また、ＱＮＥ６６と同様に、ＱＮＥ６５にも、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（��テップＳ５０３７：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５０３９）。一方、ＱＮＥ６７には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ５０４１：受信したｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約はないので、そのまま次に送信、ステップＳ５０４３）。【０１１３】  そして、最終的にメッセージＢはＱＮＥ６８に到着し、このメッセージＢを受け取ったＱＮＥ６８は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでｕｐｓｔｒｅａｍ用経路の情報を収集できるようにパラメータをセットして（ステップＳ５０４５：メッセージＢの内容をメッセージＣにセットし、メッセージＣでｕｐｓｔｒｅａｍ用情報を集めるようパラメータをセット）、ＣＮ６０に向けて送信する（ステップＳ５０４７）。また、ＱＮＥ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７では、メッセージＣを受信した場合、上述のメッセージＢに対する処理と同様の処理がｕｐｓｔｒｅａｍ用のメッセージＣに対して行われる。【０１１４】  すなわち、ＱＮＥ６７には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＣはそのまま転送される（ステップＳ５０４９：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約はないので、そのまま次に送信、ステップＳ５０５１）。また、ＱＮＥ６５には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ５０５３：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５０５５）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ５０５７：受信したｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約のあるインタフェースのＩＰアドレスをセット、ステップＳ５０５９）。【０１１５】  このようにしてメッセージＣを受け取ったＣＮ６０は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を特定することが可能となり、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセットして（ステップＳ５０６１：ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセット）、ＭＮ１０にメッセージＤを送信する（ステップＳ５０６��）。【０１１６】  なお、前述のＭＮ１０の機能で説明した通り、ＣＮ６０はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ここでは、データが双方向通信であり、双方向のデータが同じ経路を通ると仮定したが、双方向のデータが違う経路を通る場合においても、前述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。【０１１７】  なお、本明細書に記述されている送信先という表現、例えばＣＮ６０宛てに送信するという表現は、必ずしもＩＰヘッダの送信先アドレスにＣＮ６０のアドレスを指定して送信するという意味ではなく、最終的にメッセージを受け取る相手がＣＮ６０であるという意味である。【０１１８】  また、データの流れの方向がｕｐｓｔｒｅａｍの場合、メッセージをＣＮ６０にまで送ることなく、ＣＲＮを見つけることができる。このような一例を図１、図２４、図２５を参照しながら説明する。【０１１９】  図２４は、本発明の実施の形態における通信システムにおいて、ＭＮがメッセージをＣＮまで送ることなくＣＲＮを見つける際の動作の一例を示すシーケンスチャートであり、メッセージとしてＱＵＥＲＹメッセージ及びＲＥＳＰＯＮＳＥメッセージを使った方法が示されている。【０１２０】  図２４に示すシーケンスチャートにおいて、まず、ＱＮＥ６８は、予測経路を確立するためのトリガを受け取る（ステップＳ２４０１：予測経路を確立するためのトリガを受け取る）。このトリガは、例えば、前述のＭＮ１０からプロキシ６８に送られるメッセージＡである。また、このトリガには、予測経路確立準備に必要な情報、例えば、ＭＮ１０とＣＮ６０とが現通信経路（経路２４）で使用しているセッション識別子の情報などが含まれる。なお、セッション識別子に対して、複数のフロー識別子が対応している可能性もあるので、どのフローに対して予測経路確立準備をするかを特定する識別情報（例えば、現在のフロー識別子など）がメッセージＡ内に含まれるようにすることも可能である。ここでは、メッセージＡには、経路２４で使われているフロー識別子が含まれているものとする。また、さらに、メッセージＡには、ＣＮ６０を特定するための情報（例えば、ＣＮ６０のＩＰアドレス）などが含まれるようにしてもよい。また、上述のように、メッセージＡには、メッセージＢの送信先の情報（ＩＰアドレスなど）が含まれていてもよく、例えばモバイルＩＰｖ６における三角経路を用いた通信に対するＱｏＳ経路のＣＲＮ検索が行われる場合には、メッセージＢの送信先をＣＮ６０ではなく、ＭＮ１０のホームエージェントとすることも可能である。【０１２１】  プロキシ６８はトリガを受けると、ＣＮ６０に向かってメッセージ（例えば、ＱＵＥＲＹメッセージを使うことが可能）を送信する（ステップＳ２４０３）。ここでプロキシ６８は、新しいフロー識別子（経路３４に対するフロー識別子）を生成する際、自分のＩＰアドレスを送信元アドレスとしてフロー識別子を生成してもよい。また、ＱＵＥＲＹメッセージには、ＭＮ１０とＣＮ６０とが現通信経路（経路２４）で使用しているセッション識別子の情報などが含まれる。なお、どの��ロー識別子に対して予測経路確立準備をするかを特定する識別情報（例えば、現在のフロー識別子など）が含まれるようにすることも可能である。【０１２２】  ＱＵＥＲＹメッセージを受け取ったＱＮＥ６７では、図２５に示されるような判断が行われる。図２５は、本発明の実施の形態における通信システムにおいて、メッセージを受け取ったＱＮＥが、自分がＣＲＮであるか否かを判断する方法の一例を示すフローチャートである。ＱＮＥ６７は、ＱＵＥＲＹメッセージを受け取った後（ステップＳ２５０１：メッセージを受け取る）、このＱＵＥＲＹメッセージに含まれるセッション識別子に対するステート（リソース予約）を持っているかどうかを調べる（ステップＳ２５０２：ＱＵＥＲＹメッセージに含まれるセッション識別子に対するステートを持っているか？）。ここで、ＱＮＥ６７は、このステートを持っていないので、自分がＣＲＮではないと判断する。そして、ＱＮＥ６７は、ＱＵＥＲＹメッセージをＣＮ６０に向けて送信する（ステップＳ２４０５）。【０１２３】  一方、ＱＵＥＲＹメッセージを受け取ったＱＮＥ６５においても、図２５に示されるような判断が行われる。ＱＵＥＲＹメッセージを受け取ったＱＮＥ６５は、ＱＵＥＲＹメッセージを受け取った後（ステップＳ２５０１：メッセージを受け取る）、ＱＵＥＲＹメッセージに含まれるセッション識別子に対するステート（リソース予約）を持っているかどうかを調べる（ステップＳ２５０２：ＱＵＥＲＹメッセージに含まれるセッション識別子に対するステートを持っているか？）。ここで、ＱＮＥ６５は、このステートを持っているので、次に、どのフローに対して予測経路確立準備をするかを特定する識別情報が、ＱＵＥＲＹメッセージ内に含まれているかどうかをチェックする（ステップＳ２５０３：ＱＵＥＲＹメッセージには、旧経路のフローを特定する識別子が含まれているか？）。ここでは、経路２４で使われているフロー識別子が、旧経路のフローを特定する識別子として含まれているので、次に、ＱＮＥ６７は、ステップＳ２５０１でチェックされた、セッション識別子に対するステートの中に、このフロー識別子が含まれるかどうかをチェックする（ステップＳ２５０４：特定されているフローに対するステートか？）。なお、セッション識別子に対するステートの中に、このフロー識別子が含まれない場合には、自分がＣＲＮではないと判断され、さらに、ＱＵＥＲＹメッセージが転送されることとなる。【０１２４】  ＱＮＥ６５は経路２４に所属しており、与えられたフロー識別子はステートの中に含まれるので、次に、ＱＮＥ６５は、ＱＵＥＲＹメッセージを送ってきた隣り合うＱＮＥの情報（ＳＩＩ：Ｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）をチェックする（ステップＳ２５０５：ＳＩＩは等しいか？）。すなわち、ＱＮＥ６５が持つステートの中には経路２４でのＳＩＩの情報が含まれており（つまり、ＱＮＥ６３がＳＩＩであるという情報を持っており）、ＱＮＥ６５は、この情報と、ステップＳ２４０５でＱＵＥＲＹメッセージを送ってきたＱＮＥに係る情報（つまり、ＱＮＥ６７に係る情報）との比較を行う。これらの情報が異なっていると判断された場合には、自分���ＣＲＮだと判断され、一方、同一の場合には、自分がＣＲＮではないと判断される。【０１２５】  ＱＮＥ６５が、自分がＣＲＮだと判断した場合（ステップＳ２４０７：セッション識別子やＳＩＩを比較し、自分がクロスオーバノードであることを認識）には、自分がＣＲＮであることをプロキシ（ＱＮＥ６８）に知らせるため、ＲＥＳＰＯＮＳＥメッセージをプロキシ６８に向けて送信する（ステップＳ２４０９、ステップＳ２４１１）。【０１２６】  なお、自分がＣＲＮであると認識したＱＮＥ（ここでは、ＱＮＥ６５）が、プロキシ６８に対して、自分がＣＲＮであることを知らせる以外にも、様々なＣＲＮの使用法が考えられる。例えば、ステップＳ２４０３及びステップＳ２４０５で送られるメッセージの中に、ＭＮ１０のＮＣｏＡやフロー識別子が含まれていた場合、自分がＣＲＮであると認識したＱＮＥ６５は、ＲＥＳＰＯＮＳＥメッセージを返さず、ＭＮ１０の方向に新しい経路を張るためのＲＥＳＥＲＶＥメッセージを、ＣＮ６０の方向に更新のためのＲＥＳＥＲＶＥメッセージを送信して、リソース予約に係る動作を行うようにすることも可能である。【０１２７】  また、リソース予約を行う際、どのパケットデータに対して予約したリソースを与えるかを識別するためには、必ずしもフロー識別子を用いる必要はない。この場合、例えば、別の識別子（ここではフィルタと呼ぶ）をメッセージ（ＱＵＥＲＹメッセージやＲＥＳＥＲＶＥメッセージなど）に持たせてもよい。また、この場合には、ＣＲＮを見つけるため、又は新しい経路にリソース予約をするために用いられる識別子として、フロー識別子ではなくフィルタを用いることも可能である。【０１２８】  なお、前述のような、どのパケットデータに対して予約したリソースを与えるかを識別するための識別子（フロー識別子又はフィルタ）は、１つのリソース予約に対し、複数存在してもよい。つまり、１つのリソース予約に対し、フロー識別子リスト又はフィルタリストが存在してもよく、この場合には、ＱＮＥは、リスト（フロー識別子リスト又はフィルタリスト）内に存在するいずれかの識別子と同じ内容の情報を持つデータパケットを受信した場合に、予約しているリソースを与えることが可能となる。【０１２９】  また、前述のように、ＣＲＮ（ＱＮＥ６５）からＣＮ６０までの間の予約を更新する場合などに、このリスト（フロー識別子リスト又はフィルタリスト）の概念を使うことも可能である。この一例を、図１及び図２１を用いて説明する。なお、ここでは、どのパケットデータに対して予約したリソースを与えるかを識別するための識別子として、フロー識別子が使われるものとし、リストはフロー識別子リストとする。【０１３０】  ＱＮＥ６５及びＱＮＥ６６には、現在、古い経路（経路２４）のリソース予約が存在している。つまり、ＱＮＥ６５及びＱＮＥ６６には、ＭＮ１０の移動前のＣｏＡを含むフロー識別子（又はこのフロー識別子を含むリスト）に対し、リソースが割り当てられている。【０１３１】  ＱＮＥ６５は、ステップＳ５０１３でメッセージＥを受け取った後、ＲＥＳＥＲＶＥ（ｕｐｄａｔｅ）処理として、メッセージＥ内に含まれる新しいフロー識別子（ＭＮ１０のＮＣｏＡを含む）を、経��２４に対するリソースが割り当てられているフロー識別子リストに追加して、ＲＥＳＥＲＶＥ（ｕｐｄａｔｅ）メッセージをＣＮ６０に向けて送信する（ステップＳ５０１５）。このＲＥＳＥＲＶＥ（ｕｐｄａｔｅ）メッセージを受け取ったＱＮＥ６６は、同様に、新しいフロー識別子を経路２４に対するリソースが割り当てられているフロー識別子リストに追加し、ＲＥＳＥＲＶＥ（ｕｐｄａｔｅ）メッセージをＣＮ６０に向けて送信する。これにより、ＱＮＥ６５及びＱＮＥ６６は経路２４及び経路３４の両方に対するリソース予約を持つことになる。なお、経路２４及びは経路３４に関しては、別々の予約をしているわけではなく、経路２４と経路３４とでリソースが共有されるようにしているので、二重のリソース予約は回避されることとなる。【０１３２】  また、この処理の後、経路２４のフロー識別子は、ＭＮ１０がサブネット３０に移動しデータの送受信を始めた後に、ＱＮＥ６５及びＱＮＥ６６のフロー識別子リストから削除されてもよい。なお、削除方法は、例えば、タイマを設けて、このタイマが所定の期間を超えたら、自動的に削除されるようにしたり、削除用のメッセージによって、明示的に削除されるようにしてもよい。
【産業上の利用可能性】
【０１３３】  本発明に係る通信ハンドオーバ方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムは、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるようにすることを可能とし、無線通信を行う移動端末のハンドオーバに係る技術分野に適用され、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６プロトコルを利用した無線通信を行う移動端末のハンドオーバ及びＮＳＩＳを用いたＱｏＳ保証に係る技術分野に適用可能である。
【図１】
2005076548.tif 000003
【図２】
2005076548.tif 000004
【図３】
2005076548.tif 000005
【図４】
2005076548.tif 000006
【図５】
2005076548.tif 000007
【図６】
2005076548.tif 000008
【図７】
2005076548.tif 000009
【図８】
2005076548.tif 000010
【図９】
2005076548.tif 000011
【図１０】
2005076548.tif 000012
【図１１】
2005076548.tif 000013
【図１２】
2005076548.tif 000014
【図１３】
2005076548.tif 000015
【図１４】
2005076548.tif 000016
【図１５】
2005076548.tif 000017
【図１６】
2005076548.tif 000018
【図１７】
2005076548.tif 000019
【図１８】
2005076548.tif 000020
【図１９】
2005076548.tif 000021
【図２０】
2005076548.tif 000022
【図２１】
2005076548.tif 000023
【図２２】
2005076548.tif 000024
【図２３】
2005076548.tif 000025
【図２４】
2005076548.tif 000026
【図２５】
2005076548.tif 000027
【国際調査報告】
2005076548.tif 000028
2005076548.tif 000029
2005076548.tif 000030
2005076548.tif 000031