(57)【要約】ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことを可能とさせるクロスオーバノード検出方法などを提供する技術が開示され、その技術によれば移動端末１０が、自身及び他の移動端末の過去の移動履歴情報を有する装置に対して、クロスオーバノードを検出するために必要な情報を含むメッセージを送信するステップと、装置が、受信したメッセージに含まれる情報に基づいて、自身が有する移動履歴情報に、対応するクロスオーバノードの情報が存在するか判断し、存在する場合にクロスオーバノードの情報を移動端末へ送信するステップと、移動端末が、装置から送信されたクロスオーバノードの情報を受信するステップとを有する。
2006118188.tif 000002
【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出する方法であって、
前記移動端末が、自身及び他の移動端末の過去の移動履歴情報を有する装置に対して、前記クロスオーバノードを検出するために必要な情報を含むメッセージを送信するステップと、
前記装置が、受信した前記メッセージに含まれる情報に基づいて、自身が有する前記移動履歴情報に、対応する前記クロスオーバノードの情報が存在するか判断し、存在する場合に前記クロスオーバノードの情報を前記移動端末へ送信するステップと、
前記移動端末が、前記装置から送信された前記クロスオーバノードの情報を受信するステップとを、
有するクロスオーバノード検出方法。
【請求項２】
前記移動履歴情報は、移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報、前記移動により新旧の通信経路が交わるクロスオーバノードの情報、前記移動後のサブネットを構成するアクセスルータから前記新旧の通信経路の交わる前記クロスオーバノードへのリンク情報、前記新旧の通信経路の交わる前記クロスオーバノードから前記移動後のサブネットを構成するアクセスルータへのリンク情報のうち、少なくとも１つ以上の情報から構成される請求項１に記載のクロスオーバノード検出方法。
【請求項３】
前記クロスオーバノードを検出するために必要な情報は、前記移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報のうち、少なくとも１つ以上の情報である請求項１に記載のクロスオーバノード検出方法。
【請求項４】
前記移動履歴情報を有する前記装置が、前記移動端末の移動後の前記サブネットを構成するアクセスルータである請求項１に記載のクロスオーバノード検出方法。
【請求項５】
前記移動履歴情報を有する前記装置が、前記移動端末の移動前の前記サブネットを構成するアクセスルータである請求項１に記載のクロスオーバノード検出方法。
【請求項６】
前記移動履歴情報を有する前記装置が、前記新旧の通信経路が交わり、かつ分岐する前記クロスオーバノードである請求項１に記載のクロスオーバノード検出方法。
【請求項７】
請求項１から６のいずれか１つに記載のクロスオーバノード検出方法をコンピュータにより実行するためのクロスオーバノード検出用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Ｍｏｂｉｌｅ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ６）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関する。
【背景技術】
【０００２】  移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰｖ６を利用したものが普及してきている。このモバイルＩＰｖ６を利用した無線通信システムについて、図２４を参照しながら説明する。なお、以下に説明するモバイルＩＰｖ６の技術に関しては、例えば、下記の非特許文献１に開示されている。【０００３】  図２４に示す無線通信システムは、インターネットなどのＩＰネットワーク（通信ネットワーク）１５、ＩＰネットワーク１５に接続する複数のサブネット（サブネットワークとも呼ばれる）２０、３０、これらの複数のサブネット２０、３０のいずれかに接続することが可能な移動端末（ＭＮ：Ｍｏｂｉｌｅ  Ｎｏｄｅ）１０を含んでいる。なお、図２４では、複数のサブネット２０、３０として、２つのサブネット２０、３０が図示されている。【０００４】  サブネット２０は、ＩＰパケット（パケットデータ）に対するルーティングを行うアクセスルータ（ＡＲ：Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ）２１、固有の無線カバーエリア（通信可能領域）２８、２９をそれぞれ形成する複数のアクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）２２、２３により構成されている。これらのＡＰ２２、２３は、それぞれＡＲ２１に接続されており、ＡＲ２１は、ＩＰネットワーク１５に接続されている。なお、図２４では、複数のＡＰ２２、２３として、２つのＡＰ２２、２３が図示されている。また、サブネット３０に関しても、ＡＲ３１及び複数のＡＰ３２、３３により、上述のサブネット２０と同一の接続態様によって構成されている。【０００５】  また、サブネット２０の構成要素であるＡＲ２１と、サブネット３０の構成要素であるＡＲ３１とは、ＩＰネットワーク１５を通じて通信を行うことが可能であり、すなわち、サブネット２０とサブネット３０とは、ＩＰネットワーク１５を通じてつながっている。【０００６】  図２４に示す無線通信システムにおいて、ＭＮ１０が、無線カバーエリア２９内でＡＰ２３との無線通信を開始したとする。このとき、ＭＮ１０に割り当てられているＩＰｖ６アドレスが、サブネット２０のＩＰアドレス体系に適さない場合、無線カバーエリア２９内に存在するＭＮ１０は、ＡＰ２３との間における無線通信を介して、サブネット２０に適合したＩＰｖ６アドレス、すなわち気付アドレス（ＣｏＡ：Ｃａｒｅ  ｏｆ  Ａｄｄｒｅｓｓ）を取得する。【０００７】  なお、ＭＮ１０がＣｏＡを取得する方法には、ＤＨＣＰｖ６（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ＩＰｖ６）などの方法によりＤＨＣＰサーバからステートフルに割り当ててもらう方法と、サブネット２０のネットワークプリフィックス及びプリフィックスレングスをＡＲ２１から取得し、ＭＮ１０において、ＡＲ２１から取得したネットワークプリフィックス及びプリフィックスレングスと、ＭＮ１０のリンクレイヤアドレスなどとを組み合わせて、ステートレスにＣｏＡを自動生成する方法とが存在する。【０００８】  そして、ＭＮ１０は、��得したＣｏＡを自分のホームネットワーク上のルータ（ホームエージェント）や特定の通信相手（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ：ＣＮ）に対して登録（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ：ＢＵ）することによって、サブネット２０内において、パケットデータの送信又は受信が行えるようになる。【０００９】  これにより、所定の通信相手からＭＮ１０に対して送信されたパケットデータは、ＭＮ１０のＣｏＡに基づいて、ＡＲ２１及びＡＰ２３を介して、ＭＮ１０に伝えられる一方、ＭＮ１０が所望の通信相手に対して送信したパケットデータは、ＡＰ２３及びＡＲ２１を介して上記所望の通信相手に伝えられる。また、ＭＮ１０あてにホームネットワークに送信されてきたパケットデータも、ホームエージェントに登録されたＭＮ１０のＣｏＡに基づいてサブネット２０のＡＲ２１に送られ、ＡＰ２３を介してＭＮ１０に伝えられる。【００１０】  上述のように、図２４に示すモバイルＩＰｖ６を利用した無線通信システムは、ＭＮ１０があるサブネットから別のサブネットにハンドオーバを行った場合でも、ＣｏＡを利用して、ＭＮ１０における無線通信が継続されるよう構成されている。このハンドオーバ処理を高速化するための技術としては、例えば、下記の非特許文献２に開示されているファストハンドオーバ技術が知られている。【００１１】  このファストハンドオーバ技術では、ＭＮ１０がＬ２ハンドオーバを行う前に、ＭＮ１０は、サブネット３０で使用する新しい（Ｎｅｗ）ＣｏＡ（以降、ＮＣｏＡと呼ぶ）をあらかじめ取得して、このＮＣｏＡをＡＲ２１に通知することによって、ＡＲ２１とＡＲ３１との間にトンネルを生成することが可能となり、ＭＮ１０がＬ２ハンドオーバを行ってＡＰ２３からＡＰ３２に接続を切り換えてから、サブネット３０に移動して、あらかじめ取得したＮＣｏＡを正式に登録（ＢＵ）するまでの間でも、サブネット２０で使用していたＭＮ１０の古い（Ｐｒｅｖｉｏｕｓ）ＣｏＡ（以降、ＰＣｏＡと呼ぶ）あてに送られたパケットデータは、トンネル経由でＡＲ３１及びＡＰ３２を介してＭＮ１０に転送されるようになるとともに、ＭＮ１０から送信されるパケットデータも、ＡＰ３２及びＡＲ３１を介してトンネル経由でＡＲ２１に到達して、ＡＲ２１から通信相手に送られるようになる。【００１２】  一方、ネットワークを利用した通信においては、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）が挙げられる（例えば、下記の非特許文献３参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。【００１３】  サブネット２０、３０間のハンドオーバを行うＭＮ１０に関しては、ハ���ドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられなければならないという要請があるが、上述したＲＳＶＰは、特に下記の点において上記の要請を満たすことができず、ＭＮ１０の移動に対応不可能である。図２５は、従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図である。【００１４】  ＲＳＶＰでは、ＭＮ１０の通信相手端末６０からＭＮ１０への２点間経路（ｅｎｄ−ｔｏ−ｅｎｄ  ｐａｔｈ）においてＱｏＳ経路が設定され、ＭＮ１０及びＣＮ６０のアドレスに基づいて、２点間経路の間をつなぐ複数の中継ノード６１によるデータ転送が行われる。したがって、例えば、ＭＮ１０がサブネット２０、３０間でハンドオーバを行い、ＭＮ１０のＣｏＡが変更された場合には、ＱｏＳ経路において、フローの変更に加えてアドレス変更に係る処理が行われる必要があるが、ＲＳＶＰは、このような変更に対応できずに、結果的にＱｏＳ保証が破綻することとなる（第１の問題点：ＱｏＳ経路の変更が困難）。さらに、新たにＱｏＳ経路が設定された場合でも、ハンドオーバ前後においてＱｏＳ経路が重複する部分が発生した場合には、この重複する部分において２重のリソース予約（ｄｏｕｂｌｅ  ｒｅｓｅｒｖａｔｉｏｎ）が起こってしまう可能性もある（第２の問題点：２重のリソース予約）。【００１５】  上述のような問題点を解決するために、現在、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）において、ＮＳＩＳ（Ｎｅｘｔ  Ｓｔｅｐ  ｉｎ  Ｓｉｇｎａｌｉｎｇ）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献４参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献５〜９参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献６及び非特許文献９参照）。【００１６】  図２６には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（ＮＳＩＳ  Ｓｉｇｎａｌｉｎｇ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（ＮＳＩＳ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳ  ＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。【００１７】  また、図２７は、従来の技術におけるＮＳＩＳのノードであるＮＥ（ＮＳＩＳ  Ｅｎｔｉｔｙ）やＱＮＥ（ＱｏＳ  ＮＳＩＳ  Ｅｎｔｉｔｙ）が「隣り合う」という概念を説明するための模式図である。図２７に示すように、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥと呼ぶことにする。なお、ＮＥになり得るのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳ  ＮＳＬＰを持たないＮＥが複数存在することもあり得る。【００１８】  次に、従来のＱｏＳ経路確立方法（ＱｏＳリソース予約）の一例を、図２８を用いて説明する。サブネット２０でＡＲ２１に接続されているＭＮ１０は、ある目的（セッション）のために、ＣＮ６０からデータを受信する予定であるか、若しくは受信している（受信中である）ものとする。ＭＮ１０は、ＱｏＳ経路の確立を行う場合には、ＱｏＳ経路確立のためのＲＥＳＥＲＶＥメッセージをＣＮ６０に向けて送信する。ＲＥＳＥＲＶＥメッセージには、ＣＮ６０からのデータ受信のために所望されるＱｏＳの情報（ＱＳｐｅｃ）が含まれている。送信されたＲＥＳＥＲＶＥメッセージはＡＲ２１とＮＥ６２及びその他のＮＳＩＳ機能を持たないルータを経由し、ＱＮＥ６３に到着する。ＱＮＥ６３のＮＳＬＰは、ＲＥＳＥＲＶＥメッセージ中に含まれるＱＳｐｅｃに記されているＱｏＳリソースを、このセッションのために予約する。ＱＮＥ６３を通過したＲＥＳＥＲＶＥメッセージは、さらに、ＮＥ６４やその他のＮＳＩＳの機能を持たないルータを経由し、ＱＮＥ６５に到着する。ＱＮＥ６５においても、ＱＮＥ６３と同様の処理が行われ、ＱｏＳリソースの予約が行われる。この操作が繰り返され、最終的にＲＥＳＥＲＶＥメッセージがＣＮ６０に届けられることによって、ＭＮ１０とＣＮ６０との間において、ＱｏＳ経路が確立される。【００１９】  また、リソース予約を識別するために、フロー識別子（ｆｌｏｗ  ｉｄｅｎｔｉｆｉｅｒ）及びセッション識別子（ｓｅｓｓｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）が使われる。フロー識別子はＭＮ１０のＣｏＡやＣＮ６０のＩＰアドレスに依存するものであり、各ＱＮＥ６３、６５は各データパケットの送信元・送信先のＩＰアドレスを確認することにより、このデータパケットに対するリソース予約の有無を知ることができる。なお、ＭＮ１０が他のサブネットに移動してＣｏＡが変わる場合には、ＭＮ１０のＣｏＡの変更に応じて、フロー識別子も変わる。一方、セッション識別子は、セッションのための一連のデータ伝送を識別するためのものであり、フロー識別子のように端末の移動に伴い変化するものではない。【００２０】  また、任意の経路に対してＱｏＳリソースの入手可能性などを調べる方法として、ＱＵＥＲＹという手法が存在する。この方法は、例えば、ＭＮ１０からＣＮ６０に対してＱｏＳ経路の確立が行われる際に、所望するＱＳｐｅｃが各ＱＮＥで予約可能かどうかを前もって調べるための方法であり、所望するＱＳｐｅｃが各ＱＮＥで予約可能かど��かを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッセージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献６に記載されている。【００２１】  次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、２重のリソース予約の回避方法を、図２９を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路２４）が確立されているとき、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。このときのフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立するためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路２４）は、ＭＮ１０の移動後すぐに解放されることはない。【００２２】  前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路２４におけるフロー識別子Ｘと、経路３４におけるフロー識別子（この経路３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインタフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここでフロー識別子を比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、２重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（Ｃｒｏｓｓｏｖｅｒ  Ｎｏｄｅ：クロスオーバノード）と呼ばれている。なお、ＣＲＮとは、実際に経路が交わり始めるルータ（図２９ではＮＥ６４）を指す場合もあるが、ＱｏＳ経路の議論を行う場合は、古い経路（経路２４）と新しい経路（経路３４）において、片方の隣り合うＱＮＥ（図２９ではＱＮＥ６６）は同じであるが、もう片方の隣り合うＱＮＥ（図２９ではＱＮＥ６３とＱＮＥ６７）は異なっているようなＱＮＥ（図２９ではＱＮＥ６５）を指す。【００２３】  また、非特許文献６や非特許文献９によると、このようなＲＥＳＥＲＶＥメッセージ、ＱＵＥＲＹメッセージ、ＮＯＴＩＦＹメッセージに関しては、データパケットの送信先や送信元である末端の端末（ＭＮ１０やＣＮ６０）だけではなく、任意のＱＮＥが送信元となることもできる。【００２４】  なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。
【非特許文献１】Ｄ．Ｊｏｈｎｓｏｎ，Ｃ．Ｐｅｒｋｉｎｓ  ａｎｄ  Ｊ．Ａｒｋｋｏ，″Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６″，ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−２４，Ｊｕｎｅ  ２００３
【非特許文献２】Ｒａｊｅｅｖ  Ｋｏｏｄｌｉ″Ｆａｓｔ  Ｈａｎｄｏｖｅｒｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰｖ６″，ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｆａｓｔ−ｍｉｐｖ６−０８，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献３】Ｒ．Ｂｒａｄｅｎ，Ｌ．Ｚｈａｎｇ，Ｓ．Ｂｅｒｓｏｎ，Ｓ．Ｈｅｒｚｏｇ  ａｎｄ  Ｓ．Ｊａｍｉｎ，″Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ−Ｖｅｒｓｉｏｎ  １  Ｆｕｎｃｔｉｏｎａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ″，ＲＦＣ  ２２０５，Ｓｅｐｔｅｍｂｅｒ  １９９７
【非特許文献４】ＮＳＩＳ  ＷＧ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｎｓｉｓ−ｃｈａｒｔｅｒ．ｈｔｍｌ）
【非特許文献５】Ｈ．Ｃｈａｓｋａｒ，Ｅｄ，″Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｏｆ  ａ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）Ｓｏｌｕｔｉｏｎ  ｆｏｒ  Ｍｏｂｉｌｅ  ＩＰ″，ＲＦＣ３５８３，Ｓｅｐｔｅｍｂｅｒ  ２００３
【非特許文献６】Ｓｖｅｎ  Ｖａｎ  ｄｅｎ  Ｂｏｓｃｈ，Ｇｅｏｒｇｉｏｓ  Ｋａｒａｇｉａｎｎｉｓ  ａｎｄ  Ａｎｄｒｅｗ  ＭｃＤｏｎａｌｄ″ＮＳＬＰ  ｆｏｒ  Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ  ｓｉｇｎａｌｌｉｎｇ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｑｏｓ−ｎｓｌｐ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献７】Ｘ．Ｆｕ，Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ，Ｈ．Ｔｓｃｈｏｆｅｎｉｇ，″Ｍｏｂｉｌｉｔｙ  ｉｓｓｕｅｓ  ｉｎ  Ｎｅｘｔ  Ｓｔｅｐ  ｓｉｇｎａｌｉｎｇ″，ｄｒａｆｔ−ｆｕ−ｎｓｉｓ−ｍｏｂｉｌｉｔｙ−０１．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献８】Ｒｏｌａｎｄ  Ｂｌｅｓｓ，ｅｔ．Ａｌ．，″Ｍｏｂｉｌｉｔｙ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  Ｓｉｇｎａｌｉｎｇ  Ｐｒｏｔｏｃｏｌ″，ｄｒａｆｔ−ｍａｎｙｆｏｌｋｓ−ｓｉｇｎａｌｉｎｇ−ｐｒｏｔｏｃｏｌ−ｍｏｂｉｌｉｔｙ−００．ｔｘｔ，Ｊａｎｕａｒｙ  ２００４
【非特許文献９】Ｒ．Ｈａｎｃｏｃｋ（ｅｄｉｔｏｒ），″Ｎｅｘｔ  Ｓｔｅｐｓ  ｉｎ  Ｓｉｇｎａｌｉｎｇ：Ｆｒａｍｅｗｏｒｋ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｆｗ−０５．ｔｘｔ，Ｏｃｔｏｂｅｒ  ２００３
【非特許文献１０】Ｓ．Ｌｅｅ，ｅｔ  ａｌ．，″Ａｐｐｌｉｃａｂｉｌｉｔｙ  Ｓｔａｔｅｍｅｎｔ  ｏｆ  ＮＳＩＳ  Ｐｒｏｔｏｃｏｌｓ  ｉｎ  Ｍｏｂｉｌｅ  Ｅｎｖｉｒｏｎｍｅｎｔｓ″，ｄｒａｆｔ−ｍａｎｙｆｏｌｋｓ−ｓｉｇｎａｌｉｎｇ−ｐｒｏｔｏｃｏｌ−０１．ｔｘｔ，Ｊｕｌｙ  ２００４
【非特許文献１１】Ｍ．Ｂｒｕｎｎｅｒ（Ｅｄｉｔｏｒ），″Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  Ｓｉｇｎａｌｉｎｇ  Ｐｒｏｔｏｃｏｌｓ″，ｄｒａｆｔ−ｉｅｔｆ−ｎｓｉｓ−ｒｅｑ−０９．ｔｘｔ，Ａｕｇｕｓｔ  ２００３
【００２５】  図２９において、例えば、ハンドオーバ前に接続しているサブネット２０においてＱｏＳ保証を受けているＭＮ１０が、サブネット３０へのハンドオーバを行い、ハンドオーバ後に接続するサブネット３０において、ハンドオーバ前に受けていたＱｏＳ保証を継続して受けることを考えてみる。【００２６】  この場合、ＭＮ１０がハンドオーバ前に接続しているサブネット２０とのハンドオフを行ってから、ハンドオーバ後に接続するサブネット３０において付加的サービス（ここではＱｏＳ保証）を受けた状態となるまでの時間は、ＭＮ１０がＱｏＳ保証を受けられない時間となり、ＭＮ１０はＱｏＳ保証を全く受けられないか、あるいは、デフォルトのＱｏＳ転送処理が行われてしまうこととなり、ＱｏＳの破局が起きる。【００２７】  したがって、上述のように、ハンドオーバ後のＭＮ１０に対しては、ＱｏＳ保証が迅速に提供される必要がある。このことを解決するため、ＩＥＴＦにおけるＮＳＩＳに関する現在の議論（例えば、非特許文献７）では、例えばＭＮ１０がハンドオーバを行う前、又は終える前に、新しいＱｏＳ経路を確立するための何かしらの準備を行うこと、又は新しいＱｏＳ経路の確立を前もって行うことも必要である旨の提案がある。しかしながら、こうした提案のみがなされているだけで、具体的な実現方法に関しては一切開示されていない。また、新しい経路を確立するための準備として、前述のＣＲＮを先に見つけておくことも必要とされてはいるが、これに関しても、具体的な実現方法は開示されていない。このように、前もってＣＲＮを見つけることはＱｏＳハンドオーバにおいては重要な問題である。ただし、ＣＲＮの発見は、ハンドオーバによる中断を避けるため、若しくは最小限に抑えるため、素早くなされなければならない。【００２８】  また別の問題点として、ＭＮ１０がＣＮ６０と通信を行うための、ＱｏＳリソースの予約が経路２４上に存在するときに、例えば、ＭＮ１０がサブネット３０に移動し、そこでＣＮ６０に対してＱＵＥＲＹを行う場合を考える。この場合には、上述のように、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約は、ＭＮ１０が移動した後しばらくは解放されることがないため、ＱＮＥ６５及びＱＮＥ６６には、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約がしばらくの間、残ったままとなる。これを空きリソースとしてＭＮ１０に返す（ＭＮ１０の移動後における新たな経路に利用する）ことができず、その結果、ＭＮ１０は正確なリソースの空き情報を得ることができない。この問題は、移動したＭＮ１０がＱＵＥＲＹメッセージによるリクエストを出すときばかりではなく、例えば、経路３４上の任意のＱＮＥ（例えばＱＮＥ６７）がＱＵＥＲＹメッセージのリクエストを送信する場合にも、同様に引き起こされる問題である。
【発明の開示】
【００２９】  本発明は、上記の問題点に鑑み、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことを可能とさせるクロスオーバノード検出方法及びその方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムを提供することを目的とする。
【００３０】  上記目的を達成するために、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出する方法であって、前記移動端末が、自身及び他の移動端末の過去の移動履歴情報を有する装置に対して、前記クロスオーバノードを検出するために必要な情報を含むメッセージを送信するステップと、前記装置が、受信した前記メッセージに含まれる情報に基づいて、自身が有する前記移動履歴情報に、対応する前記クロスオーバノードの情報が存在するか判断し、存在する場合に前記クロスオーバノードの情報を前記移動端末へ送信するステップと、前記移動端末が、前記装置から送信された前記クロスオーバノードの情報を受信するステップとを有するクロスオーバノード検出方法が提供される。この構成により、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことが可能となる。
【００３１】  また、本発明のクロスオーバノード検出方法において、前記移動履歴情報が、移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報、前記移動により新旧の通信経路が交わるクロスオーバノードの情報、前記移動後のサブネットを構成するアクセスルータから前記新旧の通信経路の交わる前記クロスオーバノードへのリンク情報、前記新旧の通信経路の交わる前記クロスオーバノードから前記移動後のサブネットを構成するアクセスルータへのリンク情報のうち、少なくとも１つ以上の情報から構成されることは、本発明の好ましい態様である。この構成により、容易にＣＲＮを見つけ出すことが可能となる。
【００３２】  また、本発明のクロスオーバノード検出方法において、前記クロスオーバノードを検出するために必要な情報が、前記移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報のうち、少なくとも１つ以上の情報であることは、本発明の好ましい態様である。この構成により、即座に情報を収集することが可能となる。
【００３３】  また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記移動端末の移動後の前記サブネットを構成するアクセスルータであることは、本発明の好ましい態様である。この構成により、移動後のサブネットの情報は移動後のサブネットを構成するアクセスルータが知っているため、移動後のサブネットの情報は必要がなくなる。
【００３４】  また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記移動端末の移動前の前記サブネットを構成するアクセスルータであることは、本発明の好ましい態様である。この構成により、移動前のサブネットの情報は移動前のサブネットを構成するアクセスルータが知っているため、移動前のサブネットの情報は必要がなくなる。
【００３５】  また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記新旧の通信経路が交わり、かつ分岐する前記クロスオーバノードであることは、本発明の好ましい態様である。この構成により、ＣＲＮの情報はＣＲＮ自身が知っているため、ＣＲＮの情報は必要がなくなり、更新も必要がなくなる。
【００３６】  また、本発明によれば、上記発明のいずれか１つに記載のクロスオーバノード検出方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムが提供される。この構成により、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことが可能となる。
【００３７】  本発明のクロスオーバノード検出方法及びその方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムは、上記構成を有し、ＣＲＮを見つけ出す処理をできるだけ抑え、素早くＣＲＮを見つけ出すことによりハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けることが可能である。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施の形態における通信システムの構成を示す模式図
【図２】本発明の実施の形態におけるＭＮの構成を示すブロック図
【図３】本発明の実施の形態におけるＭＮ内に格納されるプロキシ情報の一例を示す模式図
【図４】本発明の実施の形態におけるＭＮ内に格納されるＡＰ−ＡＲ対応情報の一例を示す模式図
【図５】本発明の実施の形態におけるＡＲの構成を示すブロック図
【図６】本発明の実施の形態における他のＡＲの構成を示すブロック図
【図７】本発明の実施の形態におけるＣＲＮの構成を示すブロック図
【図８】本発明の実施の形態におけるＭＮと移動履歴情報を有する装置との間で行われるＣＲＮの情報の抽出からプロキシへの送信までの動作の一例を示すシーケンスチャート
【図９】本発明の実施の形態におけるプロキシの構成を示すブロック図
【図１０】本発明の実施の形態におけるＱＮＥの構成を示すブロック図
【図１１】本発明の実施の形態におけるＣＮの構成を示すブロック図
【図１２】本発明の実施の形態において、プロキシ及びＣＮが送受信し合うメッセージに、どのようにＱＮＥによって処理された情報が格納されるかの一例を示す模式図
【図１３】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図１４】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図１５】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１６】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１７】本発明の実施の形態において、別の処理方法を実現するプロキシの構成を示すブロック図
【図１８】本発明の実施の形態において、別の処理方法を実現するＣＮの構成を示すブロック図
【図１９】本発明の実施の形態における通信システムにおいて、プロキシがＣＲＮにＱｏＳ経路確立の依頼を行う際の動作の一例を示すシーケンスチャート
【図２０】本発明の実施の形態における通信システムにおいて、プロキシがＣＲＮにＱｏＳ経路確立の依頼を行う際の他の動作の一例を示すシーケンスチャート
【図２１】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図２２】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図２３】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の他の動作の一例を示すシーケンスチャート
【図２４】本発明及び従来の技術に共通した無線通信システムの構成を示す模式図
【図２５】従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図
【図２６】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図２７】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図２８】従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図
【図２９】従来の技術におけるＮＳＩＳにおいて、どのように２重のリソース予約を回避するとされているかを説明するための模式図
【発明を実施するための最良の形態】
【００３９】  以下、本発明の実施の形態について図１から図２３を用いて説明する。図１は本発明の実施の形態における通信システムの構成を示す模式図である。図１には、ＭＮ１０が、ハンドオーバ前にサブネット２０に接続されている状態において、ＣＮ６０との間で確立されているＱｏＳ経路（経路２４）が実線で図示されている。この経路２４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ２１、ＮＥ６２、ＱＮＥ６３、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。また、同様に、ＭＮ１０が、ハンドオーバ後にサブネット３０に接続した場合に、ＣＮ６０との間で確立されるＱｏＳ経路（経路３４）が点線で図示されている。この経路３４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ３１、ＱＮＥ（プロキシ）６８、ＱＮＥ６７、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。したがって、古い経路（経路２４）と新しい経路（経路３４）とが交わり始めるＱＮＥ（ＣＲＮ）は、ＱＮＥ６５である。【００４０】  次に、ＭＮ１０の機能について説明する。図２は、本発明の実施の形態におけるＭＮの構成を示すブロック図である。なお、図２では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００４１】  図２に示すＭＮ１０は、ハンドオーバ先候補決定手段１０１、無線受信手段１０２、無線送信手段１０３、ＣＲＮ検出メッセージ生成手段１０４、プロキシ決定手段１０５、メッセージ生成手段１０６、メッセージ受信手段１０７を有している。また、オプションとして、ＮＣｏＡ生成手段１０８、プロキシ情報格納手段１０９、ＣＲＮ抽出手段１１０、移動履歴情報格納手段１１１を有してもよい。なお、図２では、オプション部分に関しては、点線で図示されている。ＣＲＮ抽出手段１１０及び移動履歴情報格納手段１１１は、後述するように、ＭＮ１０が自身が有する移動履歴情報に基づいてＣＲＮを抽出する際に動作する手段である。【００４２】  ハンドオーバ先候補決定手段１０１は、例えば、異なる複数のＡＰからのシグナルを受信して、Ｌ２ハンドオーバ可能なＡＰ一覧を探す手段である。なお、ＭＮ１０は、ハンドオーバ先候補決定手段１０１によるＬ２ハンドオーバ先候補の決定を行うことなく、直接、後述のプロキシ決定手段１０５による処理を行うこともできる。また、無線受信手段１０２及び無線送信手段１０３は、それぞれ無線通信によるデータ受信及びデータ送信を行うための手段であり、これらには、無線通信を行うために必要な様々な機能が含まれている。【００４３】  また、ＣＲＮ検出メッセージ生成手段１０４は、ＣＲＮ（ＱＮＥ６５）を検出する（見つけ出す）ために必要な情報を含めた、自身及び他のＭＮの過去の移動履歴情報を有する装置に送信するためのメッセージを生成する手段である。移動履歴情報に関しては後述する。ここで、ＣＲＮ（ＱＮＥ６５）を検出するために必要な情報としては、例えば、ＭＮ１０のハンドオーバ前のサブネット２０の情報、ＭＮ１０のハンドオーバ後のサブネット３０の情報、ＭＮ１０の通信先であるＣＮ６０の不図示のサブネットの情報などが挙げられ、これらの情報の少なくとも１つ以上の情報がＣＲＮ（Ｑ��Ｅ６５）を検出するために必要な情報としてメッセージに含められる。なお、サブネットの情報とは、例えばサブネットの識別子などの情報を言い、それぞれのサブネットに固有の情報である。なお、ＣＲＮ検出メッセージ生成手段１０４によって生成される上記のメッセージをメッセージＸとする。【００４４】  また、上述した無線送信手段１０３は、ＣＲＮ検出メッセージ生成手段１０４によって生成されたメッセージＸを、移動履歴情報を有する装置に対して送信する。そして、上述した無線受信手段１０２は、無線送信手段１０３によって送信されたメッセージＸを受信した移動履歴情報を有する装置から、メッセージＸに含まれるＣＲＮ（ＱＮＥ６５）を検出するために必要な情報に基づいて抽出された対応するＣＲＮ（ＱＮＥ６５）の情報を受信する。そして、無線送信手段１０３は、受信したＣＲＮ（ＱＮＥ６５）の情報を後述するプロキシ（図１ではＱＮＥ６８）に送信して、受信したプロキシはＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。ＱｏＳ経路を確立するための処理については後述する。また、無線受信手段１０２は、移動履歴情報を有する装置によって対応するＣＲＮ（ＱＮＥ６５）の情報が抽出されなかった場合には、抽出されなかった旨の情報を移動履歴情報を有する装置から受信するようにしてもよい。この場合には、後述するプロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出し、ＱｏＳ経路を確立するための処理がなされる。【００４５】  ここで、ＭＮ１０が移動履歴情報を有する装置に対して、ＭＮ１０のハンドオーバ前のサブネット２０の情報、ＭＮ１０のハンドオーバ後のサブネット３０の情報、ＭＮ１０の通信先であるＣＮ６０の不図示のサブネットの情報などを含めたメッセージＸを送信する際、ＭＮ１０はこれらの情報を取得する必要がある。これらの情報の取得を可能にするのがＮＳＩＳ  Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ（ＮＴＬＰ  ｏｒ  ＧＩＭＰＳ）であり、ＮＴＬＰ  ｏｒ  ＧＩＭＰＳは、フロー識別子がデータの送信元と受信先のＩＰアドレスを含むため、上述した情報を得ることが可能となる。このとき、ＭＮ１０は前もってプレフィックスレングスを知っておく必要がある。【００４６】  また、プロキシ決定手段１０５は、プロキシを発見する手段である。プロキシ決定手段１０５によって発見されるプロキシとは、ＭＮ１０の代理となって、ＭＮ１０がハンドオーバ後に付加的サービス（ここではＱｏＳとする）を寸断されることなく受けられるよう、あらかじめ準備することのできる、ＱｏＳ提供機能を持ったＮＳＩＳノード（ＱＮＥ）のことであり、ＭＮ１０がハンドオーバした際に張られる予定のＱｏＳ経路上に存在する。プロキシの機能については後述する。【００４７】  このプロキシの発見を行うためには、複数の方法が考えられる。例えば、ハンドオーバ先候補決定手段１０１によって取得されたＡＰ一覧の情報を基に、ＭＮ１０内にローカルに蓄えられているプロキシ情報４０（プロキシ情報格納手段１０９に格納されているプロキシ情報４０）を参照し、ＡＰが接続されているサブネットワーク上で、ＣＮ６０と通信するために適したプロキシ情報４０を検索���て決定する方法や、このＡＰ一覧の情報をＩＰネットワーク上に存在するサーバ（プロキシ検索サーバとする）などに送信し、前述の最も適したプロキシに係る情報を返してもらう方法、又は、プロキシ情報４０に蓄えられている、すべてのプロキシを選択する方法などが挙げられる。なお、ハンドオーバ先候補のＡＲそのものがＱＮＥであり、プロキシになる場合もあり得る。図３には、プロキシ情報４０の内容の一例が図示されている。なお、図３に示すプロキシ情報４０は、図２４におけるネットワーク構成を参照して作成された一例である。図３に示すプロキシ情報４０は、ＭＮが各ＡＰと接続されている場合において、プロキシとして選択可能なノードのＩＰアドレスを有しており、ＭＮは、このプロキシ情報４０を参照することによって、プロキシの選択及び特定を行うことが可能となる。なお、プロキシとしては、各ＡＰを配下に有するＡＲの近く（ネットワーク構成上のＡＲ近傍）に存在するＱＮＥが設定されることが望ましい。【００４８】  また、メッセージ生成手段１０６は、プロキシにおいて、ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報を含むメッセージを生成するための手段である。ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報としては、例えば、現在使用しているフロー識別子とセッション識別子や、データの流れの方向（ＭＮ１０からＣＮ６０の方向か、ＣＮ６０からＭＮ１０の方向か、または双方向通信か）などが挙げられる。なお、メッセージ生成手段１０６によって生成される上記のメッセージをメッセージＡとする。なお、無線受信手段１０２によって受信したＣＲＮ（ＱＮＥ６５）の情報をメッセージＡに含めてもよい。【００４９】  また、メッセージ受信手段１０７は、プロキシが前述の準備を行った際に、準備が成功したかどうかという情報を含むメッセージ（メッセージＤとする）を、プロキシから受信するための手段であり、新しいＱｏＳ経路を張る手法によっては省略可能である。なお、このメッセージＤには、プロキシが前述の準備を行った際に得られた情報などを含めることもできる。【００５０】  また、ＭＮ１０は移動先を特定して、そこで使用するＮＣｏＡを生成し、それを移動先のプロキシに送ることも可能である。このＮＣｏＡを生成するための手段がＮＣｏＡ生成手段１０８であり、生成されたＮＣｏＡはメッセージ生成手段１０６において、フロー識別子などと共にメッセージＡ内に格納される。ＮＣｏＡ生成方法については、例えば、ＭＮ１０が図４（図３と同様に、図１３を参照して作成された一例）に示すようなＡＰ−ＡＲ対応情報４１をローカルに持ち、ハンドオーバ先候補決定手段１０１によって得られたＡＰの情報を基にして、このＡＰ−ＡＲ対応情報４１を検索し、ＡＰが繋がっている先のＡＲの情報（例えば、ＡＲのリンクレイヤアドレス、ＡＲの属するサブネットのネットワークプリフィックスやプリフィックスレングスなど）を得ることにより、ＮＣｏＡをステートレスに自動生成する方法が考えられる。【００５１】  ただし、この場合には、ＮＣｏＡはステートレスに自動生成されたもので��るため、実際に、このＮＣｏＡがハンドオーバ先のサブネットで使用可能なものであるかどうかを確認する手段が必要である。このため、例えばハンドオーバ先として、ＡＲそのものがプロキシとなることのできるサブネットを選び、このＡＲにＮＣｏＡを含んだメッセージＡを送ることにより、このプロキシ機能を持ったＡＲに、ＮＣｏＡの妥当性を調べてもらうなどの処理が必要である。また、他のＮＣｏＡ獲得方法としては、現在通信中のＡＲ（ハンドオーバ前のサブネット２０に属するＡＲ）が、近隣のサブネットワークのＤＨＣＰサーバより、使用可能なＣｏＡの一部をあらかじめ受け取り、ＭＮ１０が別のＡＲ（ハンドオーバ後のサブネット３０に属するＡＲ）に移動を行う前に、そのサブネットのＤＨＣＰサーバからもらったＣｏＡのうちの１つをＭＮ１０に割り当てる方法も可能である。この場合には、ＣｏＡはステートフルに割り当てられるので、ＣｏＡに係る妥当性のチェックが行われる必要はなく、前述のように、プロキシ機能を持ったＡＲを選ぶという制限はなくなる。また、メッセージＡには、これ以外の情報（例えば、ＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）のＩＰアドレスなどの情報）も含めることができる。【００５２】  次に、ＭＮ１０からメッセージＸを受信する装置の機能について説明する。なお、この装置は、特定の装置に限られず、例えば、ハンドオーバ前のサブネット２０を構成するＡＲ２１、ハンドオーバ後のサブネット３０を構成するＡＲ３１、ＣＲＮ（ＱＮＥ６５）などであってもよい。以下では、移動履歴情報を有する装置が、ＡＲ２１、ＡＲ３１、ＣＲＮ（ＱＮＥ６５）のそれぞれの場合について説明する。また、ＭＮ１０自身が移動履歴情報を有する場合についても説明する。図５は本発明の実施の形態におけるメッセージＸを受信するＡＲ２１の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図５に示すＡＲ２１が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００５３】  図５に示すＡＲ２１は、受信手段２１１、送信手段２１２、制御手段２１３、移動履歴情報格納手段２１４を有している。受信手段２１１は、例えばＭＮ１０から送信されたメッセージＸや経路２４を流れるデータなどを受信する手段である。また、送信手段２１２は、例えば後述する制御手段２１３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段２１３は、例えば受信手段２１１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段２１４に格納された移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。なお、抽出された結果によって必ずしも最適な経路を確立できるとは限らないが、ＱｏＳは保証されることになる。後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）の場合にも同様である。また、移動履歴情報格納手段２１４に格納された移動履歴情報は、例えば所定の期間が経過するまでの情報であって、所定の期間が経過した場合には削除されるようにしてもよい。後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）の移動履歴情報についても同様である。【００５４】  具体的な例と��て、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。なお、この場合、メッセージＸにはサブネット２０の情報を含めなくてもよい。ＡＲ２１はサブネット２０の情報を有するなどしているからである。受信手段２１１によってメッセージＸを受信すると、制御手段２１３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段２１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段２１３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段２１２は、抽出されたＣＲＮの情報をＭＮ１０へ送信する。【００５５】  なお、ＣＲＮの情報を受信したＭＮ１０は、受信したＣＲＮの情報の正当性を確認するためにシグナリングを出すようにしてもよい。具体的には、ＭＮ１０は、情報として得たＣＲＮに対して、現在のフローＩＤ（フロー識別子）及びセッションＩＤ（セッション識別子）を含む確認メッセージを送信し、該当するＩＤが存在すればそのＣＲＮは現在の旧ＱｏＳパス上に存在することが確認できる。ただし、最適であるとは限らない。仮に、該当するＩＤが存在しなければそのＣＲＮはパス上に存在しないことになり、その場合にはプロキシ決定手段１０５によって発見されるプロキシを通じてＣＲＮを見つけ出す処理がなされる。ＣＲＮの情報の正当性を確認する処理は、後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）に関する場合でも同様である。【００５６】  ここで、制御手段２１３によって移動履歴情報格納手段２１４には該当するデータが存在しないとされた場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、制御手段２１３は、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮ１０の通信先のサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段２１４に格納する。【００５７】  次に、移動履歴情報を有する装置がＡＲ３１の場合について図６を用いて説明する。図６は本発明の実施の形態におけるメッセージＸを受信するＡＲ３１の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図６に示すＡＲ３１が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００５８】  図６に示すＡＲ３１は、受信手段３１１、送信手段３１２、制御手段３１３、移動履歴情報格納手段３１４を有している。受信手段３１１は、例えばＭＮ１０から送信されたメッセージＸや経路３４を流れるデータなどを受信する手段である。また、送信手段３１２は、例えば後述する制御手段３１３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段３１３は、例えば受信手段３１１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段３１４に格納された前記移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。【００５９】  具体的な例として、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。なお、この場合、メッセージＸにはサブネット３０の情報を含めなくてもよい。ＡＲ３１はサブネット３０の情報を有するなどしているからである。受信手段３１１によってメッセージＸを受信すると、制御手段３１３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段３１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段３１３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段３１２は、抽出されたＣＲＮの情報をＭＮ１０へ送信する。【００６０】  ここで、制御手段３１３によって移動履歴情報格納手段３１４には該当するデータが存在しないとされた場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、制御手段３１３は、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、図５に示すＡＲ２１の制御手段２１３と同様に、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮ１０の通信先のサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段３１４に格納する。【００６１】  次に、移動履歴情報を有する装置がＣＲＮ（ＱＮＥ６５）の場合について図７を用いて説明する。図７は本発明の実施の形態におけるメッセージＸを受信するＣＲＮ（ＱＮＥ６５）の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図７に示すＣＲＮ（ＱＮＥ６５）が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００６２】  図７に示すＣＲＮ（ＱＮＥ６５）は、受信手段６５１、送信手段６５２、制御手段６５３、移動履歴情報格納手段６５４を有している。受信手段６５１は、例えばＭＮ１０から送信されたメッセージＸや経路２４及び３４を流れるデータなどを受信する手段である。また、送信手段６５２は、例えば後述する制御手段６５３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段６５３は、例えば受信手段６５１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段６５４に格納された移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。【００６３】  具体的な例として、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。まず、ＭＮ１０が旧ＱｏＳパス上にＣＮ６０に向かってメッセージＸを送信すると、そのＱｏＳパス上に存在するＱＮＥは該当する移動履歴情報が自身に存在するか否かを判断し、存在しない場合に次のＱＮＥに向かってメッセージＸを転送する。そして、メッセージＸを受信手段６５１によって受信すると、制御手段６５３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段６５４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段６５３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段６５２は、抽出されたＣＲＮの情報及び自身のインタフェース情報などをＭＮ１０へ送信する。【００６４】  ここで、制御手段６５３によって移動履歴情報格納手段６５４には該当するデータが存在しないとされた場合には、次のＱＮＥに向かってメッセージＸを転送する。そして、該当する移動履歴情報を有するＱＮＥが存在しない場合には、ＣＮ６０はＭＮ１０に対して該当するＣＲＮが存在しないことを通知する。これにより、ＭＮ１０はプロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、該当するＣＲＮ（ＱＮＥ）の制御手段は、図５に示すＡＲ２１の制御手段２１３や図６に示すＡＲ３１の制御手段３１３と同様に、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮの通信先それぞれのサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段６５４に格納する。【００６５】  次に、移動履歴情報を有する装置がＭＮ１０の場合について図２を用いて説明する。移動履歴情報は移動履歴情報格納手段１１１に格納されており、具体的にはＭＮ１０の過去の移動履歴の情報が格納されている。ＣＲＮ抽出手段１１０は、ＣＲＮ検出メッセージ生成手段１０４によってメッセージＸが生成される際に含まれる情報に基づいて、移動履歴情報格納手段１１１から該当する移動履歴情報が存在するか否かを判断し、存在する場合には該当するＣＲＮの情報を抽出する。そして、無線送信手段１０３は、抽出されたＣＲＮの情報をプロキシに送信する。一方、存在しないと判断された場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す処理が開始される。このように、ＭＮ１０自身が過去の移動履歴を利用することにより、あるパターンの行動を何度もするＭＮには有効である。ただし、このようなＭＮ１０自身が移動履歴情報を有する場合、ＣＲＮの情報の正当性の確認が必要になる。また、複数のＭＮ間での移動履歴情報のやりとり（共有）をすることも可能である。【００６６】  次に、ＭＮ１０と移動履歴情報を有する装置（例えば、ＡＲ２１）との間で行われるＣＲＮの情報の抽出からプロキシへの送信までについて図８を用いて説明する。ＭＮ１０が、現在通信中の不図示のＡＰが接続されたＡＲ２１のサブネット２０からサブネット３０を構成するＡＲ３１に接続する不図示のＡＰへハンドオーバする際に、ＭＮ１０は、ＣＲＮを検出するためにサブネット２０の情報、サブネット３０の情報、ＣＮ６０のサブネットの情報などをメッセージＸに含め（ステップＳ８０１）、メッセージＸをＡＲ２１に送信する（ステップＳ８０２）。なお、ＭＮ１０は、ハンドオーバ後にステップＳ８０１、Ｓ８０２の処理を開始するようにしてもよい。ＭＮ１０からのメッセージＸを受信したＡＲ２１は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段２１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報のデータが存在するか否かを判断し、存在すると判断した場合には、対応するＣＲＮの情報を抽出する（ステップＳ８０３）。そして、ＡＲ２１は、抽出されたＣＲＮの情報をＭＮ１０へ送信する（ステップＳ８０４）。【００６７】  そして、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ８０５）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ８０６）。プロキシを決定したＭＮ１０は、ＡＲ２１から受信したＣＲＮの情報と、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子をメッセージＡにセットするとともに、双方向通信であるという情報もメッセージＡにセットして（ステップＳ８０７）、選んだプロキシ６８にメッセージＡを送信する（ステップＳ８０８）。このように、あらかじめＣＲＮがわかっていれば、ＣＲＮ（ＱＮＥ６５）に対してＲＥＳＥＲＶＥメッセージを流すことができる。ここでは特に、プロキシ群のうちの１つであるプロキシ６８に対してメッセージＡが送られた場合を想定している。【００６８】  なお、ＡＲ２１において、該当するＣＲＮの情報が抽出されなかった場合には、例えば、ＡＲ２１はＭＮ１０に対して該当するＣＲＮの情報が存在しない旨の情報を送信するようにしてもよい。これにより、ＭＮ１０はメッセージＡにＣＲＮの情報を含めないため、プロキシ側で該当するＣＲＮを見つけ出すことになる。【００６９】  次に、ＭＮ１０からメッセージを受け取るプロキシ（ＱＮＥ６８）の機能について説明する。なお、ここで、ＭＮ１０はプロキシの１つとして、図１中のＱＮＥ６８をプロキシの１つとして選んだ場合を考える。図９は、本発明の実施の形態におけるプロキシの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図９に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００７０】  図９に示すプロキシ６８は、受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６を有している。また、オプションとして、メッセージ生成手段６８７、及び経路情報格納手段６８８を有してもよい。なお、図９では、オプション部分に関しては、点線で図示されている。【００７１】  受信手段６８１及び送信手段６８２は、データ受信及びデータ送信を行うための手段である。また、メッセージ処理手段６８３は、図２に示すＭＮ１０のメッセージ生成手段１０６で生成され、無線送信手段１０３で送信されたメッセージ（メッセージＡ）を受信、処理するための手段である。例えば、メッセージＡ中に含まれるデータの流れの情報を確認し、どのような形でＱｏＳ経路を確立するのが望ましいかを判断する。また、メッセージＡにＣＲＮの情報が含まれている場合には、メッセージ処理手段６８３は、このＣＲＮの情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。一方、メッセージ処理手段６８３がＭＮ１０からＣＲＮの情報を受信しない場合には、後述するメッセージ生成手段６８５、メッセージ処理手段６８４などによりＣＲＮを発見し、このＣＲＮ情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。ＱｏＳ経路を確立する処理方法については後述する。なお、受信したＣＲＮの情報は、双方向通信を行っているとすると、後述するようなｕｐｓｔｒｅａｍ用のＣＲＮの情報とｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報である。また、データの流れによるＱｏＳ経路確立方法の変化に関しては、後述の中間のＱＮＥの機能と共に説明する。【００７２】  また、メッセージ生成手段６８５は、メッセージ処理手段６８３で受け取ったフロー識別子（例えば、経路２４のフロー識別��Ｘ）、セッション識別子（例えば、経路２４及び経路３４に共通のセッション識別子Ｙ）を含むメッセージ（メッセージＢとする）を生成する。メッセージ生成手段６８５によって生成される上記のメッセージＢは、ＣＲＮを発見するためのメッセージであり、送信手段６８２を介してＣＮ６０に向けて送信される。なお、このフロー識別子の中には、ＣＮ６０のＩＰアドレス情報が含まれている。【００７３】  また、メッセージ処理手段６８４は、メッセージ生成手段６８５で生成され、送信されたメッセージＢを受け取ったＣＮ６０から、経路３４上の各ＱＮＥを介して送られてきたメッセージ（メッセージＣとする）を受信、処理する手段である。このメッセージＣには、ＣＲＮの情報が含まれている。メッセージ処理手段６８４では、このＣＲＮ情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。この処理を行うには、複数の方法が考えられる。例えば、この情報を経路情報格納手段６８８に渡し、ＭＮ１０がハンドオーバして来た時点で何かしらの処理を行ってもよく、また、その情報をさらにメッセージ生成手段６８６に渡して、ＭＮ１０への返信メッセージ（前述のメッセージＤ）としてもよい。ただしこの場合には、ＭＮ１０には、図２のメッセージ受信手段１０７が設けられている必要がある。なお、前述の通り、メッセージＤには準備が成功したかどうかという情報が含まれてもよい。また、さらに、メッセージＤには、これ以外の情報が含まれてもよい。また、ＭＮ１０からＣＲＮの情報が送信されてきた場合には、ＭＮ１０への返信メッセージを送信しなくてよい。【００７４】  また、メッセージ処理手段６８３で、ＭＮ１０のＮＣｏＡの情報を受け取っていた場合には、メッセージ生成手段６８７で、このＮＣｏＡを基に新しいフロー識別子を生成し、メッセージ処理手段６８３又はメッセージ処理手段６８４で受け取ったＣＲＮの情報を基に、ＲＥＳＥＲＶＥメッセージをＣＮ６０に送信することによって、経路３４上に新しいＱｏＳ経路を生成してもよい。ただしこの場合には、ＲＥＳＥＲＶＥメッセージにＣＲＮの情報を持たせ、該当するＣＲＮは、そこからＣＮ６０までのリソース予約を２重予約にならないようにするなど、別の機能が必要になる。なお、ＱｏＳ経路確立に必要となり、ＲＥＳＥＲＶＥメッセージに含まれるべきＱＳｐｅｃの情報などに関しては、例えば、メッセージ処理手段６８３で受信されるＣＲＮの情報又はメッセージＣに含まれるＣＲＮの情報を参照して、このＣＲＮから取得することができる。【００７５】  また、メッセージＡにＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）の情報が含まれている場合には、ＱＮＥ６３から取得することもできる。また、前述のように送られたＮＣｏＡが、妥当性のチェックが必要なものだった場合には、そのチェックを行わなければならない。もし、このプロキシがＮＣｏＡの妥当性チェック機能を有していなかった場合、又は妥当性チェックを行った結果、妥当で無かった場合には、例えば、ＭＮ１０にエラー通知を行うためのエラーメッセージを返す必要がある。このエラー通知は、メッセージＤに含めることも可能であり、また、別のメッセージ（例えば、ＦＭＩＰにおける��ＢＡｃｋメッセージ）として返すことも可能である。また、メッセージ生成手段６８５で生成されるメッセージＢには、上記以外の情報（例えば、妥当であることが確認されたＮＣｏＡや、メッセージＡに含まれているＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）などの情報）を含めることもできる。【００７６】  次に、経路３４上の中間のＱＮＥの機能について、ＱＮＥ６５を例に取って説明する。図１０は、本発明の実施の形態における経路３４上の中間ＱＮＥの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図１０に示すＱＮＥ６５が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、前述した図７のように、ＱＮＥ６５が移動履歴情報を有する装置である場合には、制御手段６５３や移動履歴情報格納手段６５４を有する構成となる。【００７７】  図１０に示すＱＮＥ６５は、受信手段６５１１、送信手段６５１２、メッセージ処理手段６５１３、メッセージ生成手段６５１４を有している。受信手段６５１１、送信手段６５１２は、図９に示すプロキシ６８の受信手段６８１、送信手段６８２と同じ機能を有している。また、メッセージ処理手段６５１３は、前述のメッセージＢ又はメッセージＣを受け取った際、その中に含まれているフロー識別子とセッション識別子の組で、すでにＱＮＥ６５内にリソース予約が無いかどうかを調べる手段である。予約が無かった場合は、メッセージ生成手段６５１４では何も行われずに、送信手段６５１２を経由して次のＱＮＥにメッセージＢ又はメッセージＣが転送される。一方、予約があった場合は、メッセージ生成手段６５１４において、そのインタフェースのＩＰアドレスが同メッセージ内に格納され、メッセージ生成手段６５１４で生成された新たなメッセージが、送信手段６５１２を経由して次のＱＮＥに送信される。ただし、メッセージＢやメッセージＣが、他の何かしらの処理をＱＮＥに求めるものだった場合、例えば、ＱＵＥＲＹメッセージやそれに対するＲＥＳＰＯＮＳＥメッセージの拡張だった場合には、これらのメッセージに特有の処理が行われる。【００７８】  メッセージＢ、メッセージＣのどちらで上述の処理を行うかは、データの流れの方向、及びその他のＮＳＩＳの機能により異なる。一例としては、データの流れがＣＮ６０からＭＮ１０の方向のみだった場合、ＲＳＶＰ（非特許文献３参照）のＱｏＳ経路確定方法の考え方に従えば、ＣＮ６０から送られるメッセージＣを受け取った際に、上述の処理を行うのが妥当である。【００７９】  なお、データやシグナリングが通る経路は、ＭＮ１０からＣＮ６０の方向（ｕｐｓｔｒｅａｍとする）と、ＣＮ６０からＭＮ１０の方向（ｄｏｗｎｓｔｒｅａｍとする）で違う場合も考えられるので、実際問題として、メッセージＣは経路３４を通る（経路３４を確定することができる）が、メッセージＢは経路３４を通らないということも考えられる。したがって、経路３４上の各ＱＮＥでは、メッセージＢ及びメッセージＣのどちらか一方のみしか受け取らないこともあり得る。【００８０】  逆に、同じ考え方を採用した場合、データの流れがｕｐｓｔｒｅａｍだった場合にはメッセージＢにより経路３４が確定され、上述のメッセ���ジ処理手段６５１３及びメッセージ生成手段６５１４にて処理が行われる。この場合には、メッセージＣは各ＱＮＥによって、メッセージＢを受け取った際に処理された結果をプロキシ６８に返すためのみのメッセージとなり得る。しかしながら、ＮＳＩＳではＮＴＬＰの機能を活用することにより、必ずしもＲＳＶＰの経路確定方法の考え方が当てはまるとは限らない。例えば、ｄｏｗｎｓｔｒｅａｍ方向のデータの流れに対し、メッセージＢが経路３４を通り、必要な情報を集めることも可能になり得る。【００８１】  次に、ＣＮ６０の機能について説明する。図１１は、本発明の実施の形態におけるＣＮの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図１１に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。【００８２】  図１１に示すＣＮ６０は、受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、経路情報格納手段６０５を有している。受信手段６０１、送信手段６０２は、図９に示すプロキシ６８の受信手段６８１、送信手段６８２や、図１０に示す受信手段６５１１、送信手段６５１２と同じ機能を有している。また、メッセージ処理手段６０３は、メッセージＢを受け取って処理する機能を有している。例えば、メッセージ処理手段６０３では、メッセージＢがｕｐｓｔｒｅａｍに対して出されたものか、ｄｏｗｎｓｔｒｅａｍに対して出されたものかが判断される。また、メッセージＢにｕｐｓｔｒｅａｍ用のＣＲＮの情報が含まれている場合には、メッセージ処理手段６０３は、そのＣＲＮの情報を経路情報格納手段６０５に渡して保有させることも可能である。ＣＮ６０は、経路情報格納手段６０５に格納された情報を使うことによって、ＭＮ１０のＮＣｏＡの情報が得られたときに、ＲＥＳＥＲＶＥメッセージを用いたＱｏＳ経路確立処理を行うことができる。【００８３】  なお、ＭＮ１０のＮＣｏＡの情報は、メッセージＢに含まれている場合にはメッセージＢの受信と同時に取得することが可能であり、また、ＭＮ１０からのＢＵメッセージより取得することも可能である。また、ＲＥＳＥＲＶＥメッセージに含まれるべきＱＳｐｅｃの情報などに関しては、前述の通り、ＣＲＮから取得することも可能であり、また、メッセージＢがＱＮＥ６３のＩＰアドレスを含んでいる場合には、ＱＮＥ６３から取得することも可能である。また、メッセージ生成手段６０４ではメッセージＣを生成し、送信手段６０２を通じてメッセージＣを送信する手段である。なお、メッセージＢに経路情報（どのＱＮＥがリソース予約を持っていたか）が含まれていた場合には、それをメッセージＣに含めて送信することも可能である。また、メッセージＣは、上記以外の情報を含んでいてもよい。【００８４】  次に、メッセージＢ及びメッセージＣを送受信することにより、どのようにＣＮ６０やプロキシ６８がＣＲＮの情報を得ることができるかについて説明する。今、ＭＮ１０とＣＮ６０が、例えばＩＰテレフォニなどを使って、双方向通信を行っているとする。この場合、データの流れはｕｐｓｔｒｅａｍとｄｏｗｎｓｔｒｅａｍの両方があり、これら双方向のデータは必ずしも同じ経路（同じ��ータ）を通るとは限らないので、ＣＲＮもｕｐｓｔｒｅａｍ側とｄｏｗｎｓｔｒｅａｍ側でそれぞれ違うと考えられる。ここでは、図１を参照しながら、双方向のデータが同じ経路を通ると仮定するが、双方向のデータが違う経路を通る場合においても、後述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。なお、双方向通信の場合には、それぞれの方向の通信経路に関して、フロー識別子とセッション識別子とが存在しており、プロキシは、これら２方向のフロー識別子、セッション識別子の組をＭＮ１０からもらい、メッセージＢに埋め込んでＣＮ６０に送るようにすればよい。【００８５】  図１２には、メッセージＢ及びＣの送受信により、プロキシが得ることのできる情報の一例が図示されている。メッセージＢ及びメッセージＣには、各メッセージが持っているフロー識別子、セッション識別子のペアに対するリソースの予約を持つＱＮＥを通過するたびに、そのリソース予約を持つインタフェースのＩＰアドレスの情報が、各メッセージの最後に付加される。例えばメッセージＢの場合には、ＱＮＥ６５を通過する際、ｕｐｓｔｒｅａｍのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８１：ＱＮＥ６５の、上側（ＱＮＥ６６側）インタフェースのＩＰアドレス）が付けられ、ＱＮＥ６６を通過する際には、その更に後ろに、ＱＮＥ６６内のｕｐｓｔｒｅａｍのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８２：ＱＮＥ６６の、上側（ＣＮ６０側）インタフェースのＩＰアドレス）が付けられる。このメカニズムにより、この情報がＣＮ６０やプロキシ６８に返された場合には、ＣＮ６０やプロキシ６８は、最初に付けられたインタフェースのＩＰアドレス（情報８１のＩＰアドレス）を持つＱＮＥが、ｕｐｓｔｒｅａｍのＣＲＮだと判断することができる。【００８６】  また、ｄｏｗｎｓｔｒｅａｍに関しては順序が逆になるので、プロキシ６８は、情報８３及び情報８４のうち、最後に付けられたインタフェースのＩＰアドレス（情報８４のＩＰアドレス）を持つＱＮＥが、ｄｏｗｎｓｔｒｅａｍのＣＲＮだと判断することができる。なお、ＱｏＳ経路は、ネットワークの状態などの要因によって変化する可能性があり、ＱｏＳ経路の変化に応じて、ＣＲＮも変化する可能性がある。このようなＣＲＮの変化が生じる可能性に対処するため、ＣＮ６０やプロキシ６８が保持するＣＲＮの情報に対して有効期限を設定し、その有効期限が切れる前に、ＣＮ６０やプロキシ６８が、ＣＲＮに変化が生じていないかの確認を行ったり、最新のＣＲＮの情報を取得したりすることによって、正確なＣＲＮの情報を保持できるようにすることも可能である。なお、この有効期限の設定は、ＣＲＮの情報を受け取るＣＮ６０やプロキシ６８が行ってもよく、また、ＭＮ１０がメッセージＡを送る際に、ＣＮ６０やプロキシ６８に対して、有効期限を通知してもよい。【００８７】  次に、ＭＮ１０が、メッセージＡにＣＲＮの情報を含めることができない場合に、プロキシ６８にＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作につい��説明する。図１３及び図１４には、本発明の実施の形態において、ＭＮ１０がプロキシ６８に識別子（フロー識別子及びセッション識別子）の情報を送り、プロキシ６８とＣＮ６０とが中間ＱＮＥ６５〜６７を介してメッセージをやり取りすることにより、ｕｐｓｔｒｅａｍやｄｏｗｎｓｔｒｅａｍのＣＲＮを見つける動作例を示すシーケンスチャートが図示されている。なお、図１３及び図１４に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものであり、ここでは、プロキシ６８がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている。また、図１３及び図１４に示すシーケンスチャートには、一連の動作が示されており、図１３及び図１４のシーケンスチャートに図示されているステップＳ１３１２の処理は同一である。【００８８】  近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ１３０１）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ１３０２）。プロキシを決定したＭＮ１０は、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子をメッセージＡにセットするとともに、双方向通信であるという情報もメッセージＡにセットして（ステップＳ１３０３）、選んだプロキシ群（複数のプロキシ）にメッセージＡを送信する（ステップＳ１３０４）。ここでは特に、プロキシ群のうちの１つであるプロキシ６８に対してメッセージＡが送られた後の処理に限って説明する。【００８９】  プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでｕｐｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｄｏｗｎｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ１３０５）、ＣＮ６０にメッセージＢを送信する（ステップＳ１３０６）。なお、このとき、プロキシ６８はフロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。【００９０】  プロキシ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７は、メッセージＢの中身を確認し、その中のｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ内に存在するかどうかを確認する。そして、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥは、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加して、ＣＮ６０に向けて送る。一方、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。【００９１】  なお、ＱＮＥ６７には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ１３０７、１３０８）。また、ＱＮＥ６５には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後（ステップＳ１３０９）、メッセージＢは転送される（ステップＳ１３１０）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後（ステップＳ１３１１）、メッセージＢは転送される（ステップＳ１３１２）。【００９２】  そして、最終的にメッセージＢはＣＮ６０に到着し、このメッセージＢを受け取ったＣＮ６０は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでｄｏｗｎｓｔｒｅａｍ用経路の情報を収集できるようにパラメータをセットして（ステップＳ１３１３）、プロキシ６８に向けて送信する（ステップＳ１３１４）。また、ＣＮ６０からプロキシ６８への経路上にある各ＱＮＥ６５〜６７は、上述のメッセージＢに対する処理と同様の処理をｄｏｗｎｓｔｒｅａｍ用のメッセージＣに対して行う。【００９３】  すなわち、ＱＮＥ６６には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後（ステップＳ１３１５）、メッセージＣは転送される（ステップＳ１３１６）。また、ＱＮＥ６５と同様に、ＱＮＥ６５にも、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後（ステップＳ１３１７）、メッセージＣは転送される（ステップＳ１３１８）。また、ＱＮＥ６７には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＣはそのまま転送される（ステップＳ１３１９、１３２０）。【００９４】  このようにしてメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を特定することが可能となり、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセットして（ステップＳ１３２１）、ＭＮ１０にメッセージＤを送信する（ステップＳ１３２２）。【００９５】  なお、前述のＭＮ１０の機能で説明した通り、プロキシ６８はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ＭＮ１０は、ＣＲＮの情報を早期に知ることにより、例えば、サブネットを移動した後にリソース予約を行う際、このＣＲＮの情報をＲＥＳＥＲＶＥメッセージに含ませて送ることができる。また、ＣＲＮの情報を含むＲＥＳＥＲＶＥメッセージを該���するＣＲＮが受け取った場合には、該当するＣＲＮは、その先のＣＮ６０までのリソースを２重予約しないようにする処理を行うことが可能である。例えば、該当するＣＲＮは、新規にリソースを予約するのではなく、古い予約を更新するなどの処理を行うことも可能である。【００９６】  このようにＣＲＮの特定が前もってなされると、たとえＭＮ１０のハンドオーバ後のリソース予約であったとしても、従来の技術のように、ＣＲＮを探しながらのリソース予約とはならないために、迅速にＱｏＳ経路を張ることが可能となる。また、前述の通り、ＣＲＮの情報を得たプロキシ６８が、ＭＮ１０に情報を返すことなく、前もってリソース予約を行うようにすることも可能であり、より迅速なＱｏＳ経路確立が実現できる。【００９７】  また、さらに、前述の通り、メッセージＢやメッセージＣを既存のメッセージ、例えばＱＵＥＲＹメッセージやＲＥＳＰＯＮＳＥメッセージやＮＯＴＩＦＹメッセージに書き換えることも可能である。図１５及び図１６には、ＱＵＥＲＹメッセージにメッセージＢの機能を、ＲＥＳＰＯＮＳＥメッセージにメッセージＣの機能を持たせた場合のシーケンスチャートが図示されている。ここでは、やり取りされるメッセージが、ｕｐｓｔｒｅａｍ及びｄｏｗｎｓｔｒｅａｍのＣＲＮを見つける機能のほかに、本来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージが持つ機能（空きリソースの情報の取得機能など）を有している。なお、図１５及び図１６中のステップＳ１５０１〜Ｓ１５２２は、図１３及び図１４中のステップＳ１３０１〜Ｓ１３２２と対応関係にあり、ＱＵＥＲＹメッセージとメッセージＣ、ＲＥＳＰＯＮＳＥメッセージとメッセージＤがそれぞれ対応関係にある。【００９８】  前述の通り、従来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージを利用した場合には、ＭＮ１０などの移動を行う端末は通信相手との間で行っている現在の通信で予約されているリソースの情報を知る術を持たないため、ＣＲＮとＣＮ６０間において、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができない。しかし、ＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージがＭＮ１０の現在のフロー識別子及びセッション識別子の情報を有することにより、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができる。【００９９】  なお、非特許文献６によると、リソースの空き情報を得られるのはＲＥＳＰＯＮＳＥメッセージによってのみである。つまり、図１５及び図１６に示すように、プロキシ６８からＣＮ６０にＱＵＥＲＹメッセージを送信し、ＣＮ６０からプロキシ６８にＲＥＳＰＯＮＳＥメッセージを返信する場合には、ｄｏｗｎｓｔｒｅａｍのリソースの空き情報しか得られない可能性がある。よって、双方向の空きリソースの情報が必要な場合は、プロキシ６８からＱＵＥＲＹメッセージを受け取ったＣＮ６０が、ＲＥＳＰＯＮＳＥメッセージをＭＮ１０に返すと同時に、別のＱＵＥＲＹメッセージをプロキシ６８に送信する必要も考えられる。また、ＮＳＩＳの他の機能と組み合わせることにより、一度のＱＵＥＲＹ及びＲＥＳＰＯ��ＳＥメッセージの送受信で、双方向のリソースの空き情報を得ることができる可能性もある。【０１００】  なお、プロキシ６８が図９のメッセージ処理手段６８４によって得たＣＲＮの情報（メッセージＣに含まれるＣＲＮの情報）又はメッセージ処理手段６８３によって得たＣＲＮの情報（ＭＮ１０から送信されたメッセージＡに含まれるＣＲＮの情報）を処理する方法、及び、ＣＮ６０が図１１のメッセージ処理手段６０３によって得たＣＲＮの情報（メッセージＢに含まれるＣＲＮの情報）を処理する方法は、前述以外の方法も考えられる。これらの方法を、図１７及び図１８を参照しながら説明する。【０１０１】  図１７は、本発明の実施の形態において、メッセージＣの受信後又はメッセージＡの受信後における処理方法を実現するプロキシの構成を示すブロック図である。なお、図９に示すプロキシ６８と同様に、図１７に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図１７における受信手段６８１１、送信手段６８１２、メッセージ処理手段６８１３、６８１４、メッセージ生成手段６８１５、６８１６、６８１７、及び経路情報格納手段６８１８は、図９における受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６、６８７、及び経路情報格納手段６８８にそれぞれ等しい機能を持つので、ここでの説明は省略する。【０１０２】  図１７のメッセージ生成手段６８１９は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成し、送信手段６８１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６８１４のメッセージＢに係る処理によって特定されたＣＲＮ又はメッセージＡに含まれるＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認されたＭＮ１０のＮＣｏＡや、ＣＮ６０のＩＰアドレスなど）が含まれる。プロキシ６８が送信したメッセージＥを受け取ったＣＲＮは、例えば、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。【０１０３】  また、図１８は、本発明の実施の形態において、メッセージＢの受信後における別の処理方法を実現するＣＮの構成を示すブロック図である。なお、図１１に示すＣＮ６０と同様に、図１８に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図１８における受信手段６０１１、送信手段６０１２、メッセージ処理手段６０１３、メッセージ生成手段６０１４、及び経路情報格納手段６０１５は、図１１における受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、及び経路情報格納手段６０５にそれぞれ等しい機能を持つので、ここでの説明は省略する。【０１０４】  図１８のメッセージ生成手段６０１６は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成���、送信手段６０１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６０１３のメッセージＢに係る処理によって特定されたＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認された、前述の方法によって取得されたＭＮ１０のＮＣｏＡや、メッセージＢの送信元であるプロキシ６８のＩＰアドレスなど）が含まれる。メッセージＥを受け取ったＣＲＮは、例えば、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。【０１０５】  次に、プロキシ６８が、メッセージＣの受信によって特定されたＣＲＮ又はメッセージＡの受信によって特定されたＣＲＮに、ＱｏＳ経路の生成の依頼を行う際の動作について説明する。なお、ここでは、双方向データ通信であって、双方向の経路が等しい場合を仮定するが、ｕｐｓｔｒｅａｍ側又はｄｏｗｎｓｔｒｅａｍ側のどちらか一方のみの場合、あるいは、双方向データ通信で、双方向の経路がｕｐｓｔｒｅａｍ側とｄｏｗｎｓｔｒｅａｍ側とで異なる場合においても、後述する方法と同様の方法をｕｐｓｔｒｅａｍ用経路、又は双方向経路に別々に用いることによって、ＱｏＳ経路生成依頼が行われるようにすることが可能である。【０１０６】  図１９には、本発明の実施の形態において、ＭＮ１０から、ＮＣｏＡを含むメッセージ（メッセージＡ）を受け取ったプロキシ６８が、ＣＮ６０とのメッセージ（メッセージＢ及びメッセージＣ）のやり取りで特定されたｄｏｗｎｓｔｒｅａｍ用ＣＲＮ宛てに、新しいＱｏＳ経路の作成を依頼する動作例を示すシーケンスチャートが図示されている。なお、図１９に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものである。また、図１９のステップＳ１９０３と、ステップＳ１９０４の間には、図１３のステップＳ１３０６からステップＳ１３１２、及び図１４のステップＳ１３１３からステップＳ１３２０と同様の処理が行われるが、ここでは省略されている。【０１０７】  プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、プロキシ６８は、メッセージＢでｕｐｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｄｏｗｎｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセット（メッセージＢの送信準備）して（ステップＳ１９０１）、ＣＮ６０にメッセージＢを送信する（ステップＳ１９０３）。なお、このとき、プロキシ６８は、フロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。また、プロキシ６８は、ステップＳ１９０１におけるメッセージＢの送信準備と共に、メッセージＡに含まれているＭＮ１０のＮＣｏＡの妥当性のチェックを行う（ステップＳ１９０２）。【０１０８】  そして、ステ��プＳ１９０３で送信したメッセージＢの返信メッセージであるメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を得る（ステップＳ１９０４）。プロキシ６８は、これらのＣＲＮが新しいＱｏＳ経路を確立するために必要な情報をメッセージＥにセットし（ステップＳ１９０５）、ステップＳ１９０４によって得られたｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮのそれぞれに対して、メッセージＥを送信する（ステップＳ１９０６及びステップＳ１９０７）。ここでは、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮが共にＱＮＥ６５となるが、ステップＳ１９０４で取得したｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮのインタフェースアドレスがそれぞれ異なっていることも考えられるため（ＱＮＥ６５内の別々のインタフェースアドレスが、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮとしてステップＳ１９０４で取得される）、メッセージＥはｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用それぞれ別々に送信されている。なお、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報としては、例えば、新しいＱｏＳ経路で使われるフロー識別子などが考えられる。この新しいフロー識別子は、ステップＳ１９０２で妥当性が確認されたＭＮ１０のＮＣｏＡを基に生成されることが可能である。また、このほかに、さらに、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報は、ＣＮ６０のＩＰアドレスやセッション識別子なども考えられる。【０１０９】  メッセージＥを受け取ったＱＮＥ６５は、ＣＮ６０宛てにＱｏＳ経路を更新するためのＲＥＳＥＲＶＥメッセージを送信し（ステップＳ１９０８）、また、プロキシ６８宛てにＱｏＳ経路を新規で生成するためのＲＥＳＥＲＶＥメッセージを送信する（ステップ１９０９）。なお、ここでは、ステップＳ１９０８により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が更新され、ステップＳ１９０９により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が新規に生成される場合が示されている。【０１１０】  一方、図２０には、本発明の実施の形態において、ＭＮ１０から、ＣＲＮの情報及びＮＣｏＡを含むメッセージ（メッセージＡ）を受け取ったプロキシ６８が、受信したｄｏｗｎｓｔｒｅａｍ用ＣＲＮ宛てに、新しいＱｏＳ経路の作成を依頼する動作例を示すシーケンスチャートが図示されている。なお、図２０に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものである。【０１１１】  プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基に、メッセージＡに含まれているＭＮ１０のＮＣｏＡの妥当性のチェックを行う（ステップＳ２００１）。そして、プロキシ６８は、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮが新しいＱｏＳ経路を確立するために必要な情報をメッセージＥにセットし（ステップＳ２００２）、ステップＳ２００１によって得られたｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用��ＲＮのそれぞれに対して、メッセージＥを送信する（ステップＳ２００３及びステップＳ２００４）。ここでは、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮが共にＱＮＥ６５となるが、ステップＳ２００１で取得したｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮのインタフェースアドレスがそれぞれ異なっていることも考えられるため（ＱＮＥ６５内の別々のインタフェースアドレスが、ｕｐｓｔｒｅａｍ用ＣＲＮ及びｄｏｗｎｓｔｒｅａｍ用ＣＲＮとしてステップＳ２００１で取得される）、メッセージＥはｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用それぞれ別々に送信されている。なお、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報としては、例えば、新しいＱｏＳ経路で使われるフロー識別子などが考えられる。この新しいフロー識別子は、ステップＳ２００１で妥当性が確認されたＭＮ１０のＮＣｏＡを基に生成されることが可能である。また、このほかに、さらに、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報は、ＣＮ６０のＩＰアドレスやセッション識別子なども考えられる。【０１１２】  メッセージＥを受け取ったＱＮＥ６５は、ＣＮ６０宛てにＱｏＳ経路を更新するためのＲＥＳＥＲＶＥメッセージを送信し（ステップＳ２００５）、また、プロキシ６８宛てにＱｏＳ経路を新規で生成するためのＲＥＳＥＲＶＥメッセージを送信する（ステップ２００６）。なお、ここでは、ステップＳ２００５により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が更新され、ステップＳ２００６により、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用の両方のＱｏＳ経路が新規に生成される場合が示されている。【０１１３】  また、ＣＮ６０がｕｐｓｔｒｅａｍ用ＣＲＮの情報を取得した後に、ｕｐｓｔｒｅａｍ用ＣＲＮに対して新しいＱｏＳ経路を生成する依頼をする場合にも、同様の方法を用いることが可能である。この場合には、図１８に図示されているＣＮ６０がｕｐｓｔｒｅａｍ用ＣＲＮの情報と、ＭＮ１０の妥当なＮＣｏＡを取得した後、ｕｐｓｔｒｅａｍ用ＣＲＮに対して、メッセージＥを送信する。なお、この場合には、メッセージＥにプロキシ６８のＩＰアドレスの情報を含めることも可能である。【０１１４】  また、図２に示されるＭＮ１０のプロキシ決定手段１０５において、ＭＮ１０はプロキシとしてＣＮ６０を選ぶことも可能である。また、ＣＮ６０は、図９に示されるプロキシ６８と同様の機能を、図１１に示されるＣＮ６０の機能と併せて持つことも可能であり、プロキシ６８は、図１１に示されるＣＮ６０の機能と同様の機能を、図９に示されるプロキシ６８の機能と併せて持つことも可能である。この場合、ＭＮ１０からメッセージＡを受け取ったＣＮ６０が、プロキシ６８との間でメッセージＢ及びメッセージＣを送受信することによりＣＲＮの情報を得ること、又はメッセージＡにＣＲＮの情報が含まれている場合には即座にＣＲＮの情報を得ることが可能である。【０１１５】  このように、プロキシ６８としてＣＮ６０が選択された場合であって、メッセージＡにＣＲＮの情報が含まれていない場合の動作について、図２１及び図２２に示すシーケンスチャートを参照しながら説明する。なお、図２１及び図２２に示すシーケンスチャートには、メッセージＡにＣＲＮの情報が含まれていない場合の一連の動作が示されており、図２１及び図２２のシーケンスチャートに図示されているステップＳ２１１２は同一の処理である。また、図２１及び図２２に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０の移動先サブネットワークの候補として、サブネット３０が選ばれている場合のものであり、ここでは、ＣＮ６０がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている場合が示されている。一方、図２３に示すシーケンスチャートには、メッセージＡにＣＲＮの情報が含まれている場合の一連の動作が示されている。また、図２３に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０の移動先サブネットワークの候補として、サブネット３０が選ばれている場合のものが示されている。【０１１６】  図２１において、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定（ハンドオーバ先候補を決定）し（ステップＳ２１０１）、その後、ＡＰのＬ２情報を基にして、ＭＮ１０がそのサブネットワークに移動した際に確立されるＱｏＳ経路上で、ＭＮ１０と隣り合うＱＮＥ（図１においてサブネット３０を移動先とした場合、経路３４上で最もＡＲ３１に近いＱＮＥ）を判定する（ステップＳ２１０２）。この判定は、前述の実施の形態で、ＭＮ１０がプロキシを決定する方法と同様の方法を利用することが可能である。【０１１７】  ＭＮ１０は、ステップＳ２１０２で判定されたＱＮＥ（ＱＮＥ６８）の情報をメッセージＡにセットする（ステップＳ２１０３）。ここでは、特に、ステップＳ２１０２で判定されたＱＮＥの情報の１つとして、ＱＮＥ６８の情報がメッセージＡにセットされた場合について記述する。なお、メッセージＡには、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子、双方向通信であるという情報もセットされることが可能である。その後、ＭＮ１０はこのメッセージＡをＣＮ６０に送信する（ステップＳ２１０４）。【０１１８】  ＣＮ６０は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでｄｏｗｎｓｔｒｅａｍ、返信メッセージ（メッセージＣ）でｕｐｓｔｒｅａｍの情報を、途中のルータから得られるようにパラメータをセットし、フロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ２１０５）、ＱＮＥ６６にメッセージＢを送信する（ステップＳ２１０６）。なお、メッセージＢにセットすべきフロー識別子、セッション識別子の情報がメッセージＡに含まれている場合には、メッセージＡに含まれているこれらの情報をメッセージＢにコピーすることも可能である。一方、フロー識別子、セッション識別子の情報がメッセージＡに含まれていない場合においても、ＣＮ６０は、ＭＮ１０との現在の通信において使用しているフロー識別子、セッション識別子の情報をメッセージＢにセットすることが可能である。【０１１９】  ＣＮ６０からＱＮＥ６８への経路上に存在する各ＱＮＥ６５〜６７は、メッセージＢの内容を確認し、その中のｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ６５〜６７内に存在するかどうかを確認する。そして、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥ６５〜６７は、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加した後に、そのメッセージＢをＱＮＥ６８に向けて送る。一方、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。【０１２０】  なお、ＱＮＥ６６には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ２１０７、Ｓ２１０８）。また、ＱＮＥ６６と同様に、ＱＮＥ６５にも、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ２１０９、Ｓ２１１０）。一方、ＱＮＥ６７には、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ２１１１、Ｓ２１１２）。【０１２１】  そして、最終的にメッセージＢはＱＮＥ６８に到着し、このメッセージＢを受け取ったＱＮＥ６８は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでｕｐｓｔｒｅａｍ用経路の情報を収集できるようにパラメータをセットして（ステップＳ２１１３）、ＣＮ６０に向けて送信する（ステップＳ２１１４）。また、ＱＮＥ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７では、メッセージＣを受信した場合、上述のメッセージＢに対する処理と同様の処理がｕｐｓｔｒｅａｍ用のメッセージＣに対して行われる。【０１２２】  すなわち、ＱＮＥ６７には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＣはそのまま転送される（ステップＳ２１１５、Ｓ２１１６）。また、ＱＮＥ６５には、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ２１１７、Ｓ２１１８）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、ｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ２１１���、Ｓ２１２０）。【０１２３】  このようにしてメッセージＣを受け取ったＣＮ６０は、メッセージＣを参照することによって、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報を特定することが可能となり、ｕｐｓｔｒｅａｍ用及びｄｏｗｎｓｔｒｅａｍ用のＣＲＮの情報をメッセージＤにセットして（ステップＳ２１２１）、ＭＮ１０にメッセージＤを送信する（ステップＳ２１２２）。【０１２４】  一方、プロキシ６８としてＣＮ６０が選択された場合であって、メッセージＡにＣＲＮの情報が含まれている場合の動作について図２３に示すシーケンスチャートを参照しながら説明する。図２３において、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定（ハンドオーバ先候補を決定）し（ステップＳ２３０１）、その後、ＡＰのＬ２情報を基にして、ＭＮ１０がそのサブネットワークに移動した際に確立されるＱｏＳ経路上で、ＭＮ１０と隣り合うＱＮＥ（図１においてサブネット３０を移動先とした場合、経路３４上で最もＡＲ３１に近いＱＮＥ）を判定する（ステップＳ２３０２）。この判定は、前述の実施の形態で、ＭＮ１０がプロキシを決定する方法と同様の方法を利用することが可能である。【０１２５】  ＭＮ１０は、ステップＳ２３０２で判定されたＱＮＥ（ＱＮＥ６８）の情報及び前述のように発見されたＣＲＮの情報をメッセージＡにセットする（ステップＳ２３０３）。ここでは、特に、ステップＳ２３０２で判定されたＱＮＥの情報の１つとして、ＱＮＥ６８の情報がメッセージＡにセットされた場合について記述する。なお、メッセージＡには、経路２４でのｕｐｓｔｒｅａｍ用フロー識別子及びセッション識別子、ｄｏｗｎｓｔｒｅａｍ用フロー識別子及びセッション識別子、双方向通信であるという情報もセットされることが可能である。その後、ＭＮ１０はこのメッセージＡをＣＮ６０に送信する（ステップＳ２３０４）。ＣＮ６０は、ＭＮ１０から受け取ったメッセージＡに含まれるＣＲＮの情報などを基にＱｏＳ経路を確立するための処理に移る（ステップＳ２３０５）。【０１２６】  なお、前述のＭＮ１０の機能で説明した通り、ＣＮ６０はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ここでは、データが双方向通信であり、双方向のデータが同じ経路を通ると仮定したが、双方向のデータが違う経路を通る場合においても、前述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。【０１２７】  なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０１２８】  また、集積回路化の手法はＬＳＩに限るものではなく���専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。【０１２９】  さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。【０１３０】  なお、本明細書に記述されている送信先という表現、例えばＣＮ６０宛てに送信するという表現は、必ずしもＩＰヘッダの送信先アドレスにＣＮ６０のアドレスを指定して送信するという意味ではなく、最終的にメッセージを受け取る相手がＣＮ６０であるという意味である。
【産業上の利用可能性】
【０１３１】  本発明に係るクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムは、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことを可能とさせるため、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムなどに有用である。
【図１】
2006118188.tif 000003
【図２】
2006118188.tif 000004
【図３】
2006118188.tif 000005
【図４】
2006118188.tif 000006
【図５】
2006118188.tif 000007
【図６】
2006118188.tif 000008
【図７】
2006118188.tif 000009
【図８】
2006118188.tif 000010
【図９】
2006118188.tif 000011
【図１０】
2006118188.tif 000012
【図１１】
2006118188.tif 000013
【図１２】
2006118188.tif 000014
【図１３】
2006118188.tif 000015
【図１４】
2006118188.tif 000016
【図１５】
2006118188.tif 000017
【図１６】
2006118188.tif 000018
【図１７】
2006118188.tif 000019
【図１８】
2006118188.tif 000020
【図１９】
2006118188.tif 000021
【図２０】
2006118188.tif 000022
【図２１】
2006118188.tif 000023
【図２２】
2006118188.tif 000024
【図２３】
2006118188.tif 000025
【図２４】
2006118188.tif 000026
【図２５】
2006118188.tif 000027
【図２６】
2006118188.tif 000028
【図２７】
2006118188.tif 000029
【図２８】
2006118188.tif 000030
【図２９】
2006118188.tif 000031
【手続補正書】
【提出日】平成19年10月19日(2007.10.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出する方法であって、
前記移動端末が、自身及び他の移動端末の過去の移動履歴情報を有する装置に対して、前記クロスオーバノードを検出するために必要な情報を含むメッセージを送信するステップと、
前記装置が、受信した前記メッセージに含まれる情報に基づいて、自身が有する前記移動履歴情報に、対応する前記クロスオーバノードの情報が存在するか判断し、存在する場合に前記クロスオーバノードの情報を前記移動端末へ送信するステップと、
前記移動端末が、前記装置から送信された前記クロスオーバノードの情報を受信するステップとを、
有するクロスオーバノード検出方法。
【請求項２】
前記移動履歴情報は、移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報、前記移動により新旧の通信経路が交わるクロスオーバノードの情報、前記移動後のサブネットを構成するアクセスルータから前記新旧の通信経路の交わる前記クロスオーバノードへのリンク情報、前記新旧の通信経路の交わる前記クロスオーバノードから前記移動後のサブネットを構成するアクセスルータへのリンク情報のうち、少なくとも１つ以上の情報から構成される請求項１に記載のクロスオーバノード検出方法。
【請求項３】
前記クロスオーバノードを検出するために必要な情報は、前記移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報のうち、少なくとも１つ以上の情報である請求項１に記載のクロスオーバノード検出方法。
【請求項４】
前記移動履歴情報を有する前記装置が、前記移動端末の移動後の前記サブネットを構成するアクセスルータである請求項１に記載のクロスオーバノード検出方法。
【請求項５】
前記移動履歴情報を有する前記装置が、前記移動端末の移動前の前記サブネットを構成するアクセスルータである請求項１に記載のクロスオーバノード検出方法。
【請求項６】
前記移動履歴情報を有する前記装置が、前記新旧の通信経路が交わり、かつ分岐する前記クロスオーバノードである請求項１に記載のクロスオーバノード検出方法。
【請求項７】
請求項１から６のいずれか１つに記載のクロスオーバノード検出方法をコンピュータにより実行するためのクロスオーバノード検出用プログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Mobile Internet Protocol version 6）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関する。
【背景技術】
【０００２】
移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰｖ６を利用したものが普及してきている。このモバイルＩＰｖ６を利用した無線通信システムについて、図２４を参照しながら説明する。なお、以下に説明するモバイルＩＰｖ６の技術に関しては、例えば、下記の非特許文献１に開示されている。
【０００３】
図２４に示す無線通信システムは、インターネットなどのＩＰネットワーク（通信ネットワーク）１５、ＩＰネットワーク１５に接続する複数のサブネット（サブネットワークとも呼ばれる）２０、３０、これらの複数のサブネット２０、３０のいずれかに接続することが可能な移動端末（ＭＮ：Mobile Node）１０を含んでいる。なお、図２４では、複数のサブネット２０、３０として、２つのサブネット２０、３０が図示されている。
【０００４】
サブネット２０は、ＩＰパケット（パケットデータ）に対するルーティングを行うアクセスルータ（ＡＲ：Access Router）２１、固有の無線カバーエリア（通信可能領域）２８、２９をそれぞれ形成する複数のアクセスポイント（ＡＰ：Access Point）２２、２３により構成されている。これらのＡＰ２２、２３は、それぞれＡＲ２１に接続されており、ＡＲ２１は、ＩＰネットワーク１５に接続されている。なお、図２４では、複数のＡＰ２２、２３として、２つのＡＰ２２、２３が図示されている。また、サブネット３０に関しても、ＡＲ３１及び複数のＡＰ３２、３３により、上述のサブネット２０と同一の接続態様によって構成されている。
【０００５】
また、サブネット２０の構成要素であるＡＲ２１と、サブネット３０の構成要素であるＡＲ３１とは、ＩＰネットワーク１５を通じて通信を行うことが可能であり、すなわち、サブネット２０とサブネット３０とは、ＩＰネットワーク１５を通じてつながっている。
【０００６】
図２４に示す無線通信システムにおいて、ＭＮ１０が、無線カバーエリア２９内でＡＰ２３との無線通信を開始したとする。このとき、ＭＮ１０に割り当てられているＩＰｖ６アドレスが、サブネット２０のＩＰアドレス体系に適さない場合、無線カバーエリア２９内に存在するＭＮ１０は、ＡＰ２３との間における無線通信を介して、サブネット２０に適合したＩＰｖ６アドレス、すなわち気付アドレス（ＣｏＡ：Care of Address）を取得する。
【０００７】
なお、ＭＮ１０がＣｏＡを取得する方法には、ＤＨＣＰｖ６(Dynamic Host Configuration Protocol for IPv6)などの方法によりＤＨＣＰサーバからステートフルに割り当ててもらう方法と、サブネット２０のネットワークプリフィックス及びプリフィックスレングスをＡＲ２１から取得し、ＭＮ１０において、ＡＲ２１から取得したネットワークプリフィックス及びプリフィックスレングスと、ＭＮ１０のリンクレイヤアドレスなどとを組み合わせて、ステートレスにＣｏＡを自動生成する方法とが存在する。
【０００８】
そして、ＭＮ１０は、取得したＣｏＡを自分のホームネットワーク上のルータ（ホームエージェント）や特定の通信相手（Correspondent Node：ＣＮ）に対して登録（Binding Update：ＢＵ）することによって、サブネット２０内において、パケットデータの送信又は受信が行えるようになる。
【０００９】
これにより、所定の通信相手からＭＮ１０に対して送信されたパケットデータは、ＭＮ１０のＣｏＡに基づいて、ＡＲ２１及びＡＰ２３を介して、ＭＮ１０に伝えられる一方、ＭＮ１０が所望の通信相手に対して送信したパケットデータは、ＡＰ２３及びＡＲ２１を介して上記所望の通信相手に伝えられる。また、ＭＮ１０あてにホームネットワークに送信されてきたパケットデータも、ホームエージェントに登録されたＭＮ１０のＣｏＡに基づいてサブネット２０のＡＲ２１に送られ、ＡＰ２３を介してＭＮ１０に伝えられる。
【００１０】
上述のように、図２４に示すモバイルＩＰｖ６を利用した無線通信システムは、ＭＮ１０があるサブネットから別のサブネットにハンドオーバを行った場合でも、ＣｏＡを利用して、ＭＮ１０における無線通信が継続されるよう構成されている。このハンドオーバ処理を高速化するための技術としては、例えば、下記の非特許文献２に開示されているファストハンドオーバ技術が知られている。
【００１１】
このファストハンドオーバ技術では、ＭＮ１０がＬ２ハンドオーバを行う前に、ＭＮ１０は、サブネット３０で使用する新しい（New）ＣｏＡ（以降、ＮＣｏＡと呼ぶ）をあらかじめ取得して、このＮＣｏＡをＡＲ２１に通知することによって、ＡＲ２１とＡＲ３１との間にトンネルを生成することが可能となり、ＭＮ１０がＬ２ハンドオーバを行ってＡＰ２３からＡＰ３２に接続を切り換えてから、サブネット３０に移動して、あらかじめ取得したＮＣｏＡを正式に登録（ＢＵ）するまでの間でも、サブネット２０で使用していたＭＮ１０の古い（Previous）ＣｏＡ（以降、ＰＣｏＡと呼ぶ）あてに送られたパケットデータは、トンネル経由でＡＲ３１及びＡＰ３２を介してＭＮ１０に転送されるようになるとともに、ＭＮ１０から送信されるパケットデータも、ＡＰ３２及びＡＲ３１を介してトンネル経由でＡＲ２１に到達して、ＡＲ２１から通信相手に送られるようになる。
【００１２】
一方、ネットワークを利用した通信においては、ＱｏＳ（Quality of Service）保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Resource Reservation Protocol）が挙げられる（例えば、下記の非特許文献３参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。
【００１３】
サブネット２０、３０間のハンドオーバを行うＭＮ１０に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられなければならないという要請があるが、上述したＲＳＶＰは、特に下記の点において上記の要請を満たすことができず、ＭＮ１０の移動に対応不可能である。図２５は、従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図である。
【００１４】
ＲＳＶＰでは、ＭＮ１０の通信相手端末６０からＭＮ１０への２点間経路（end-to-end path）においてＱｏＳ経路が設定され、ＭＮ１０及びＣＮ６０のアドレスに基づいて、２点間経路の間をつなぐ複数の中継ノード６１によるデータ転送が行われる。したがって、例えば、ＭＮ１０がサブネット２０、３０間でハンドオーバを行い、ＭＮ１０のＣｏＡが変更された場合には、ＱｏＳ経路において、フローの変更に加えてアドレス変更に係る処理が行われる必要があるが、ＲＳＶＰは、このような変更に対応できずに、結果的にＱｏＳ保証が破綻することとなる（第１の問題点：ＱｏＳ経路の変更が困難）。さらに、新たにＱｏＳ経路が設定された場合でも、ハンドオーバ前後においてＱｏＳ経路が重複する部分が発生した場合には、この重複する部分において２重のリソース予約（double reservation）が起こってしまう可能性もある（第２の問題点：２重のリソース予約）。
【００１５】
上述のような問題点を解決するために、現在、ＩＥＴＦ（Internet Engineering Task Force）において、ＮＳＩＳ（Next Step in Signaling）と呼ばれる新しいプロトコルを標準化するための議論が行われている（下記の非特許文献４参照）。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献５〜９参照）。以下に、現在ＩＥＴＦのＮＳＩＳワーキンググループでドラフト仕様となっているＮＳＩＳの概要と、ＱｏＳ経路確立の方法を説明する（非特許文献６及び非特許文献９参照）。
【００１６】
図２６には、従来の技術におけるＮＳＩＳのプロトコル構成を説明するために、ＮＳＩＳ及びその下位層のプロトコルスタックが図示されている。ＮＳＩＳプロトコル層はＩＰ及び下位層のすぐ上に位置する。さらにＮＳＩＳプロトコル層は、それぞれの付加的サービスを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであるＮＳＬＰ（NSIS Signaling Layer Protocol）と、ＮＳＬＰのシグナリングメッセージのルーティングを行うＮＴＬＰ（NSIS Transport Layer Protocol）の２層からなる。ＮＳＬＰには、ＱｏＳのためのＮＳＬＰ（ＱｏＳ  ＮＳＬＰ）や、その他のある付加的サービス（サービスＡやサービスＢ）のためのＮＳＬＰ（サービスＡのＮＳＬＰ、サービスＢのＮＳＬＰ）など、様々なＮＳＬＰが存在している。
【００１７】
また、図２７は、従来の技術におけるＮＳＩＳのノードであるＮＥ（NSIS Entity）やＱＮＥ（QoS NSIS Entity）が「隣り合う」という概念を説明するための模式図である。図２７に示すように、ＮＳＩＳ機能を持ったすべてのノード（ＮＥ）には、少なくともＮＴＬＰが実装されている。このＮＴＬＰの上には、ＮＳＬＰが必ずしも存在しなくてもよく、また、１つ以上のＮＳＬＰが存在してもよい。なお、ここでは、特に、ＱｏＳのためのＮＳＬＰを持ったＮＥをＱＮＥと呼ぶことにする。なお、ＮＥになり得るのは端末やルータである。また、隣り合うＮＥの間には、ＮＥではない複数のルータが存在することもあり得るし、隣り合うＱＮＥの間には、ＮＥではないルータ及びＱｏＳ  ＮＳＬＰを持たないＮＥが複数存在することもあり得る。
【００１８】
次に、従来のＱｏＳ経路確立方法（ＱｏＳリソース予約）の一例を、図２８を用いて説明する。サブネット２０でＡＲ２１に接続されているＭＮ１０は、ある目的（セッション）のために、ＣＮ６０からデータを受信する予定であるか、若しくは受信している（受信中である）ものとする。ＭＮ１０は、ＱｏＳ経路の確立を行う場合には、ＱｏＳ経路確立のためのＲＥＳＥＲＶＥメッセージをＣＮ６０に向けて送信する。ＲＥＳＥＲＶＥメッセージには、ＣＮ６０からのデータ受信のために所望されるＱｏＳの情報（QSpec）が含まれている。送信されたＲＥＳＥＲＶＥメッセージはＡＲ２１とＮＥ６２及びその他のＮＳＩＳ機能を持たないルータを経由し、ＱＮＥ６３に到着する。ＱＮＥ６３のＮＳＬＰは、ＲＥＳＥＲＶＥメッセージ中に含まれるQSpecに記されているＱｏＳリソースを、このセッションのために予約する。ＱＮＥ６３を通過したＲＥＳＥＲＶＥメッセージは、さらに、ＮＥ６４やその他のＮＳＩＳの機能を持たないルータを経由し、ＱＮＥ６５に到着する。ＱＮＥ６５においても、ＱＮＥ６３と同様の処理が行われ、ＱｏＳリソースの予約が行われる。この操作が繰り返され、最終的にＲＥＳＥＲＶＥメッセージがＣＮ６０に届けられることによって、ＭＮ１０とＣＮ６０との間において、ＱｏＳ経路が確立される。
【００１９】
また、リソース予約を識別するために、フロー識別子（flow identifier）及びセッション識別子（session identifier）が使われる。フロー識別子はＭＮ１０のＣｏＡやＣＮ６０のＩＰアドレスに依存するものであり、各ＱＮＥ６３、６５は各データパケットの送信元・送信先のＩＰアドレスを確認することにより、このデータパケットに対するリソース予約の有無を知ることができる。なお、ＭＮ１０が他のサブネットに移動してＣｏＡが変わる場合には、ＭＮ１０のＣｏＡの変更に応じて、フロー識別子も変わる。一方、セッション識別子は、セッションのための一連のデータ伝送を識別するためのものであり、フロー識別子のように端末の移動に伴い変化するものではない。
【００２０】
また、任意の経路に対してＱｏＳリソースの入手可能性などを調べる方法として、ＱＵＥＲＹという手法が存在する。この方法は、例えば、ＭＮ１０からＣＮ６０に対してＱｏＳ経路の確立が行われる際に、所望するQSpecが各ＱＮＥで予約可能かどうかを前もって調べるための方法であり、所望するQSpecが各ＱＮＥで予約可能かどうかを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッセージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献６に記載されている。
【００２１】
次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、２重のリソース予約の回避方法を、図２９を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路２４）が確立されているとき、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。このときのフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立するためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路２４）は、ＭＮ１０の移動後すぐに解放されることはない。
【００２２】
前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路２４におけるフロー識別子Ｘと、経路３４におけるフロー識別子（この経路３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインタフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここでフロー識別子を比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、２重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（Crossover Node：クロスオーバノード）と呼ばれている。なお、ＣＲＮとは、実際に経路が交わり始めるルータ（図２９ではＮＥ６４）を指す場合もあるが、ＱｏＳ経路の議論を行う場合は、古い経路（経路２４）と新しい経路（経路３４）において、片方の隣り合うＱＮＥ（図２９ではＱＮＥ６６）は同じであるが、もう片方の隣り合うＱＮＥ（図２９ではＱＮＥ６３とＱＮＥ６７）は異なっているようなＱＮＥ（図２９ではＱＮＥ６５）を指す。
【００２３】
また、非特許文献６や非特許文献９によると、このようなＲＥＳＥＲＶＥメッセージ、ＱＵＥＲＹメッセージ、ＮＯＴＩＦＹメッセージに関しては、データパケットの送信先や送信元である末端の端末（ＭＮ１０やＣＮ６０）だけではなく、任意のＱＮＥが送信元となることもできる。
【００２４】
なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。
【非特許文献１】D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24, June 2003
【非特許文献２】Rajeev Koodli "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-08, October 2003
【非特許文献３】R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, "Resource ReSerVation Protocol - Version 1 Functional Specification", RFC 2205, September 1997
【非特許文献４】NSIS WG（http://www.ietf.org/html.charters/nsis-charter.html）
【非特許文献５】H. Chaskar, Ed, "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC3583, September 2003
【非特許文献６】Sven Van den Bosch, Georgios Karagiannis and Andrew McDonald "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-01.txt, October 2003
【非特許文献７】X. Fu, H. Schulzrinne, H. Tschofenig, "Mobility issues in Next Step signaling", draft-fu-nsis-mobility-01.txt, October 2003
【非特許文献８】Roland Bless, et. Al., "Mobility and Internet Signaling Protocol", draft-manyfolks-signaling-protocol-mobility-00.txt, January 2004
【非特許文献９】R. Hancock (editor), "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-05.txt, October 2003
【非特許文献１０】S. Lee, et al., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-manyfolks-signaling-protocol-01.txt, July 2004
【非特許文献１１】M. Brunner (Editor), "Requirements for Signaling Protocols", draft-ietf-nsis-req-09.txt, August 2003
【発明の開示】
【発明が解決しようとする課題】
【００２５】
図２９において、例えば、ハンドオーバ前に接続しているサブネット２０においてＱｏＳ保証を受けているＭＮ１０が、サブネット３０へのハンドオーバを行い、ハンドオーバ後に接続するサブネット３０において、ハンドオーバ前に受けていたＱｏＳ保証を継続して受けることを考えてみる。
【００２６】
この場合、ＭＮ１０がハンドオーバ前に接続しているサブネット２０とのハンドオフを行ってから、ハンドオーバ後に接続するサブネット３０において付加的サービス（ここではＱｏＳ保証）を受けた状態となるまでの時間は、ＭＮ１０がＱｏＳ保証を受けられない時間となり、ＭＮ１０はＱｏＳ保証を全く受けられないか、あるいは、デフォルトのＱｏＳ転送処理が行われてしまうこととなり、ＱｏＳの破局が起きる。
【００２７】
したがって、上述のように、ハンドオーバ後のＭＮ１０に対しては、ＱｏＳ保証が迅速に提供される必要がある。このことを解決するため、ＩＥＴＦにおけるＮＳＩＳに関する現在の議論（例えば、非特許文献７）では、例えばＭＮ１０がハンドオーバを行う前、又は終える前に、新しいＱｏＳ経路を確立するための何かしらの準備を行うこと、又は新しいＱｏＳ経路の確立を前もって行うことも必要である旨の提案がある。しかしながら、こうした提案のみがなされているだけで、具体的な実現方法に関しては一切開示されていない。また、新しい経路を確立するための準備として、前述のＣＲＮを先に見つけておくことも必要とされてはいるが、これに関しても、具体的な実現方法は開示されていない。このように、前もってＣＲＮを見つけることはＱｏＳハンドオーバにおいては重要な問題である。ただし、ＣＲＮの発見は、ハンドオーバによる中断を避けるため、若しくは最小限に抑えるため、素早くなされなければならない。
【００２８】
また別の問題点として、ＭＮ１０がＣＮ６０と通信を行うための、ＱｏＳリソースの予約が経路２４上に存在するときに、例えば、ＭＮ１０がサブネット３０に移動し、そこでＣＮ６０に対してＱＵＥＲＹを行う場合を考える。この場合には、上述のように、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約は、ＭＮ１０が移動した後しばらくは解放されることがないため、ＱＮＥ６５及びＱＮＥ６６には、経路２４におけるＭＮ１０、ＣＮ６０間の通信のためのリソース予約がしばらくの間、残ったままとなる。これを空きリソースとしてＭＮ１０に返す（ＭＮ１０の移動後における新たな経路に利用する）ことができず、その結果、ＭＮ１０は正確なリソースの空き情報を得ることができない。この問題は、移動したＭＮ１０がＱＵＥＲＹメッセージによるリクエストを出すときばかりではなく、例えば、経路３４上の任意のＱＮＥ（例えばＱＮＥ６７）がＱＵＥＲＹメッセージのリクエストを送信する場合にも、同様に引き起こされる問題である。
【００２９】
本発明は、上記の問題点に鑑み、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことを可能とさせるクロスオーバノード検出方法及びその方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムを提供することを目的とする。
【課題を解決するための手段】
【００３０】
上記目的を達成するために、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出する方法であって、前記移動端末が、自身及び他の移動端末の過去の移動履歴情報を有する装置に対して、前記クロスオーバノードを検出するために必要な情報を含むメッセージを送信するステップと、前記装置が、受信した前記メッセージに含まれる情報に基づいて、自身が有する前記移動履歴情報に、対応する前記クロスオーバノードの情報が存在するか判断し、存在する場合に前記クロスオーバノードの情報を前記移動端末へ送信するステップと、前記移動端末が、前記装置から送信された前記クロスオーバノードの情報を受信するステップとを有するクロスオーバノード検出方法が提供される。この構成により、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことが可能となる。
【００３１】
また、本発明のクロスオーバノード検出方法において、前記移動履歴情報が、移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報、前記移動により新旧の通信経路が交わるクロスオーバノードの情報、前記移動後のサブネットを構成するアクセスルータから前記新旧の通信経路の交わる前記クロスオーバノードへのリンク情報、前記新旧の通信経路の交わる前記クロスオーバノードから前記移動後のサブネットを構成するアクセスルータへのリンク情報のうち、少なくとも１つ以上の情報から構成されることは、本発明の好ましい態様である。この構成により、容易にＣＲＮを見つけ出すことが可能となる。
【００３２】
また、本発明のクロスオーバノード検出方法において、前記クロスオーバノードを検出するために必要な情報が、前記移動端末の移動前のサブネットの情報、前記移動端末の移動後のサブネットの情報、前記移動端末の通信先のサブネットの情報のうち、少なくとも１つ以上の情報であることは、本発明の好ましい態様である。この構成により、即座に情報を収集することが可能となる。
【００３３】
また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記移動端末の移動後の前記サブネットを構成するアクセスルータであることは、本発明の好ましい態様である。この構成により、移動後のサブネットの情報は移動後のサブネットを構成するアクセスルータが知っているため、移動後のサブネットの情報は必要がなくなる。
【００３４】
また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記移動端末の移動前の前記サブネットを構成するアクセスルータであることは、本発明の好ましい態様である。この構成により、移動前のサブネットの情報は移動前のサブネットを構成するアクセスルータが知っているため、移動前のサブネットの情報は必要がなくなる。
【００３５】
また、本発明のクロスオーバノード検出方法において、前記移動履歴情報を有する前記装置が、前記新旧の通信経路が交わり、かつ分岐する前記クロスオーバノードであることは、本発明の好ましい態様である。この構成により、ＣＲＮの情報はＣＲＮ自身が知っているため、ＣＲＮの情報は必要がなくなり、更新も必要がなくなる。
【００３６】
また、本発明によれば、上記発明のいずれか１つに記載のクロスオーバノード検出方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムが提供される。この構成により、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことが可能となる。
【発明の効果】
【００３７】
本発明のクロスオーバノード検出方法及びその方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムは、上記構成を有し、ＣＲＮを見つけ出す処理をできるだけ抑え、素早くＣＲＮを見つけ出すことによりハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速かつ継続して受けることが可能である。
【発明を実施するための最良の形態】
【００３８】
以下、本発明の実施の形態について図１から図２３を用いて説明する。図１は本発明の実施の形態における通信システムの構成を示す模式図である。図１には、ＭＮ１０が、ハンドオーバ前にサブネット２０に接続されている状態において、ＣＮ６０との間で確立されているＱｏＳ経路（経路２４）が実線で図示されている。この経路２４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ２１、ＮＥ６２、ＱＮＥ６３、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。また、同様に、ＭＮ１０が、ハンドオーバ後にサブネット３０に接続した場合に、ＣＮ６０との間で確立されるＱｏＳ経路（経路３４）が点線で図示されている。この経路３４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ３１、ＱＮＥ（プロキシ）６８、ＱＮＥ６７、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。したがって、古い経路（経路２４）と新しい経路（経路３４）とが交わり始めるＱＮＥ（ＣＲＮ）は、ＱＮＥ６５である。
【００３９】
次に、ＭＮ１０の機能について説明する。図２は、本発明の実施の形態におけるＭＮの構成を示すブロック図である。なお、図２では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００４０】
図２に示すＭＮ１０は、ハンドオーバ先候補決定手段１０１、無線受信手段１０２、無線送信手段１０３、ＣＲＮ検出メッセージ生成手段１０４、プロキシ決定手段１０５、メッセージ生成手段１０６、メッセージ受信手段１０７を有している。また、オプションとして、ＮＣｏＡ生成手段１０８、プロキシ情報格納手段１０９、ＣＲＮ抽出手段１１０、移動履歴情報格納手段１１１を有してもよい。なお、図２では、オプション部分に関しては、点線で図示されている。ＣＲＮ抽出手段１１０及び移動履歴情報格納手段１１１は、後述するように、ＭＮ１０が自身が有する移動履歴情報に基づいてＣＲＮを抽出する際に動作する手段である。
【００４１】
ハンドオーバ先候補決定手段１０１は、例えば、異なる複数のＡＰからのシグナルを受信して、Ｌ２ハンドオーバ可能なＡＰ一覧を探す手段である。なお、ＭＮ１０は、ハンドオーバ先候補決定手段１０１によるＬ２ハンドオーバ先候補の決定を行うことなく、直接、後述のプロキシ決定手段１０５による処理を行うこともできる。また、無線受信手段１０２及び無線送信手段１０３は、それぞれ無線通信によるデータ受信及びデータ送信を行うための手段であり、これらには、無線通信を行うために必要な様々な機能が含まれている。
【００４２】
また、ＣＲＮ検出メッセージ生成手段１０４は、ＣＲＮ（ＱＮＥ６５）を検出する（見つけ出す）ために必要な情報を含めた、自身及び他のＭＮの過去の移動履歴情報を有する装置に送信するためのメッセージを生成する手段である。移動履歴情報に関しては後述する。ここで、ＣＲＮ（ＱＮＥ６５）を検出するために必要な情報としては、例えば、ＭＮ１０のハンドオーバ前のサブネット２０の情報、ＭＮ１０のハンドオーバ後のサブネット３０の情報、ＭＮ１０の通信先であるＣＮ６０の不図示のサブネットの情報などが挙げられ、これらの情報の少なくとも１つ以上の情報がＣＲＮ（ＱＮＥ６５）を検出するために必要な情報としてメッセージに含められる。なお、サブネットの情報とは、例えばサブネットの識別子などの情報を言い、それぞれのサブネットに固有の情報である。なお、ＣＲＮ検出メッセージ生成手段１０４によって生成される上記のメッセージをメッセージＸとする。
【００４３】
また、上述した無線送信手段１０３は、ＣＲＮ検出メッセージ生成手段１０４によって生成されたメッセージＸを、移動履歴情報を有する装置に対して送信する。そして、上述した無線受信手段１０２は、無線送信手段１０３によって送信されたメッセージＸを受信した移動履歴情報を有する装置から、メッセージＸに含まれるＣＲＮ（ＱＮＥ６５）を検出するために必要な情報に基づいて抽出された対応するＣＲＮ（ＱＮＥ６５）の情報を受信する。そして、無線送信手段１０３は、受信したＣＲＮ（ＱＮＥ６５）の情報を後述するプロキシ（図１ではＱＮＥ６８）に送信して、受信したプロキシはＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。ＱｏＳ経路を確立するための処理については後述する。また、無線受信手段１０２は、移動履歴情報を有する装置によって対応するＣＲＮ（ＱＮＥ６５）の情報が抽出されなかった場合には、抽出されなかった旨の情報を移動履歴情報を有する装置から受信するようにしてもよい。この場合には、後述するプロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出し、ＱｏＳ経路を確立するための処理がなされる。
【００４４】
ここで、ＭＮ１０が移動履歴情報を有する装置に対して、ＭＮ１０のハンドオーバ前のサブネット２０の情報、ＭＮ１０のハンドオーバ後のサブネット３０の情報、ＭＮ１０の通信先であるＣＮ６０の不図示のサブネットの情報などを含めたメッセージＸを送信する際、ＭＮ１０はこれらの情報を取得する必要がある。これらの情報の取得を可能にするのがNSIS Transport Layer Protocol（ＮＴＬＰ ｏｒ ＧＩＭＰＳ）であり、ＮＴＬＰ ｏｒ ＧＩＭＰＳは、フロー識別子がデータの送信元と受信先のＩＰアドレスを含むため、上述した情報を得ることが可能となる。このとき、ＭＮ１０は前もってプレフィックスレングスを知っておく必要がある。
【００４５】
また、プロキシ決定手段１０５は、プロキシを発見する手段である。プロキシ決定手段１０５によって発見されるプロキシとは、ＭＮ１０の代理となって、ＭＮ１０がハンドオーバ後に付加的サービス（ここではＱｏＳとする）を寸断されることなく受けられるよう、あらかじめ準備することのできる、ＱｏＳ提供機能を持ったＮＳＩＳノード（ＱＮＥ）のことであり、ＭＮ１０がハンドオーバした際に張られる予定のＱｏＳ経路上に存在する。プロキシの機能については後述する。
【００４６】
このプロキシの発見を行うためには、複数の方法が考えられる。例えば、ハンドオーバ先候補決定手段１０１によって取得されたＡＰ一覧の情報を基に、ＭＮ１０内にローカルに蓄えられているプロキシ情報４０（プロキシ情報格納手段１０９に格納されているプロキシ情報４０）を参照し、ＡＰが接続されているサブネットワーク上で、ＣＮ６０と通信するために適したプロキシ情報４０を検索して決定する方法や、このＡＰ一覧の情報をＩＰネットワーク上に存在するサーバ（プロキシ検索サーバとする）などに送信し、前述の最も適したプロキシに係る情報を返してもらう方法、又は、プロキシ情報４０に蓄えられている、すべてのプロキシを選択する方法などが挙げられる。なお、ハンドオーバ先候補のＡＲそのものがＱＮＥであり、プロキシになる場合もあり得る。図３には、プロキシ情報４０の内容の一例が図示されている。なお、図３に示すプロキシ情報４０は、図２４におけるネットワーク構成を参照して作成された一例である。図３に示すプロキシ情報４０は、ＭＮが各ＡＰと接続されている場合において、プロキシとして選択可能なノードのＩＰアドレスを有しており、ＭＮは、このプロキシ情報４０を参照することによって、プロキシの選択及び特定を行うことが可能となる。なお、プロキシとしては、各ＡＰを配下に有するＡＲの近く（ネットワーク構成上のＡＲ近傍）に存在するＱＮＥが設定されることが望ましい。
【００４７】
また、メッセージ生成手段１０６は、プロキシにおいて、ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報を含むメッセージを生成するための手段である。ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報としては、例えば、現在使用しているフロー識別子とセッション識別子や、データの流れの方向（ＭＮ１０からＣＮ６０の方向か、ＣＮ６０からＭＮ１０の方向か、または双方向通信か）などが挙げられる。なお、メッセージ生成手段１０６によって生成される上記のメッセージをメッセージＡとする。なお、無線受信手段１０２によって受信したＣＲＮ（ＱＮＥ６５）の情報をメッセージＡに含めてもよい。
【００４８】
また、メッセージ受信手段１０７は、プロキシが前述の準備を行った際に、準備が成功したかどうかという情報を含むメッセージ（メッセージＤとする）を、プロキシから受信するための手段であり、新しいＱｏＳ経路を張る手法によっては省略可能である。なお、このメッセージＤには、プロキシが前述の準備を行った際に得られた情報などを含めることもできる。
【００４９】
また、ＭＮ１０は移動先を特定して、そこで使用するＮＣｏＡを生成し、それを移動先のプロキシに送ることも可能である。このＮＣｏＡを生成するための手段がＮＣｏＡ生成手段１０８であり、生成されたＮＣｏＡはメッセージ生成手段１０６において、フロー識別子などと共にメッセージＡ内に格納される。ＮＣｏＡ生成方法については、例えば、ＭＮ１０が図４（図３と同様に、図１３を参照して作成された一例）に示すようなＡＰ−ＡＲ対応情報４１をローカルに持ち、ハンドオーバ先候補決定手段１０１によって得られたＡＰの情報を基にして、このＡＰ−ＡＲ対応情報４１を検索し、ＡＰが繋がっている先のＡＲの情報（例えば、ＡＲのリンクレイヤアドレス、ＡＲの属するサブネットのネットワークプリフィックスやプリフィックスレングスなど）を得ることにより、ＮＣｏＡをステートレスに自動生成する方法が考えられる。
【００５０】
ただし、この場合には、ＮＣｏＡはステートレスに自動生成されたものであるため、実際に、このＮＣｏＡがハンドオーバ先のサブネットで使用可能なものであるかどうかを確認する手段が必要である。このため、例えばハンドオーバ先として、ＡＲそのものがプロキシとなることのできるサブネットを選び、このＡＲにＮＣｏＡを含んだメッセージＡを送ることにより、このプロキシ機能を持ったＡＲに、ＮＣｏＡの妥当性を調べてもらうなどの処理が必要である。また、他のＮＣｏＡ獲得方法としては、現在通信中のＡＲ（ハンドオーバ前のサブネット２０に属するＡＲ）が、近隣のサブネットワークのＤＨＣＰサーバより、使用可能なＣｏＡの一部をあらかじめ受け取り、ＭＮ１０が別のＡＲ（ハンドオーバ後のサブネット３０に属するＡＲ）に移動を行う前に、そのサブネットのＤＨＣＰサーバからもらったＣｏＡのうちの１つをＭＮ１０に割り当てる方法も可能である。この場合には、ＣｏＡはステートフルに割り当てられるので、ＣｏＡに係る妥当性のチェックが行われる必要はなく、前述のように、プロキシ機能を持ったＡＲを選ぶという制限はなくなる。また、メッセージＡには、これ以外の情報（例えば、ＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）のＩＰアドレスなどの情報）も含めることができる。
【００５１】
次に、ＭＮ１０からメッセージＸを受信する装置の機能について説明する。なお、この装置は、特定の装置に限られず、例えば、ハンドオーバ前のサブネット２０を構成するＡＲ２１、ハンドオーバ後のサブネット３０を構成するＡＲ３１、ＣＲＮ（ＱＮＥ６５）などであってもよい。以下では、移動履歴情報を有する装置が、ＡＲ２１、ＡＲ３１、ＣＲＮ（ＱＮＥ６５）のそれぞれの場合について説明する。また、ＭＮ１０自身が移動履歴情報を有する場合についても説明する。図５は本発明の実施の形態におけるメッセージＸを受信するＡＲ２１の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図５に示すＡＲ２１が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００５２】
図５に示すＡＲ２１は、受信手段２１１、送信手段２１２、制御手段２１３、移動履歴情報格納手段２１４を有している。受信手段２１１は、例えばＭＮ１０から送信されたメッセージＸや経路２４を流れるデータなどを受信する手段である。また、送信手段２１２は、例えば後述する制御手段２１３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段２１３は、例えば受信手段２１１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段２１４に格納された移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。なお、抽出された結果によって必ずしも最適な経路を確立できるとは限らないが、ＱｏＳは保証されることになる。後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）の場合にも同様である。また、移動履歴情報格納手段２１４に格納された移動履歴情報は、例えば所定の期間が経過するまでの情報であって、所定の期間が経過した場合には削除されるようにしてもよい。後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）の移動履歴情報についても同様である。
【００５３】
具体的な例として、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。なお、この場合、メッセージＸにはサブネット２０の情報を含めなくてもよい。ＡＲ２１はサブネット２０の情報を有するなどしているからである。受信手段２１１によってメッセージＸを受信すると、制御手段２１３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段２１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段２１３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段２１２は、抽出されたＣＲＮの情報をＭＮ１０へ送信する。
【００５４】
なお、ＣＲＮの情報を受信したＭＮ１０は、受信したＣＲＮの情報の正当性を確認するためにシグナリングを出すようにしてもよい。具体的には、ＭＮ１０は、情報として得たＣＲＮに対して、現在のフローＩＤ（フロー識別子）及びセッションＩＤ（セッション識別子）を含む確認メッセージを送信し、該当するＩＤが存在すればそのＣＲＮは現在の旧ＱｏＳパス上に存在することが確認できる。ただし、最適であるとは限らない。仮に、該当するＩＤが存在しなければそのＣＲＮはパス上に存在しないことになり、その場合にはプロキシ決定手段１０５によって発見されるプロキシを通じてＣＲＮを見つけ出す処理がなされる。ＣＲＮの情報の正当性を確認する処理は、後述するＡＲ３１、ＣＲＮ（ＱＮＥ６５）に関する場合でも同様である。
【００５５】
ここで、制御手段２１３によって移動履歴情報格納手段２１４には該当するデータが存在しないとされた場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、制御手段２１３は、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮ１０の通信先のサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段２１４に格納する。
【００５６】
次に、移動履歴情報を有する装置がＡＲ３１の場合について図６を用いて説明する。図６は本発明の実施の形態におけるメッセージＸを受信するＡＲ３１の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図６に示すＡＲ３１が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００５７】
図６に示すＡＲ３１は、受信手段３１１、送信手段３１２、制御手段３１３、移動履歴情報格納手段３１４を有している。受信手段３１１は、例えばＭＮ１０から送信されたメッセージＸや経路３４を流れるデータなどを受信する手段である。また、送信手段３１２は、例えば後述する制御手段３１３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段３１３は、例えば受信手段３１１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段３１４に格納された前記移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。
【００５８】
具体的な例として、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。なお、この場合、メッセージＸにはサブネット３０の情報を含めなくてもよい。ＡＲ３１はサブネット３０の情報を有するなどしているからである。受信手段３１１によってメッセージＸを受信すると、制御手段３１３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段３１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段３１３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段３１２は、抽出されたＣＲＮの情報をＭＮ１０へ送信する。
【００５９】
ここで、制御手段３１３によって移動履歴情報格納手段３１４には該当するデータが存在しないとされた場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、制御手段３１３は、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、図５に示すＡＲ２１の制御手段２１３と同様に、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮ１０の通信先のサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段３１４に格納する。
【００６０】
次に、移動履歴情報を有する装置がＣＲＮ（ＱＮＥ６５）の場合について図７を用いて説明する。図７は本発明の実施の形態におけるメッセージＸを受信するＣＲＮ（ＱＮＥ６５）の構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図７に示すＣＲＮ（ＱＮＥ６５）が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００６１】
図７に示すＣＲＮ（ＱＮＥ６５）は、受信手段６５１、送信手段６５２、制御手段６５３、移動履歴情報格納手段６５４を有している。受信手段６５１は、例えばＭＮ１０から送信されたメッセージＸや経路２４及び３４を流れるデータなどを受信する手段である。また、送信手段６５２は、例えば後述する制御手段６５３が抽出したＣＲＮ（ＱＮＥ６５）の情報やその他のデータなどを送信する手段である。制御手段６５３は、例えば受信手段６５１によって受信したメッセージＸに含まれる情報に基づいて、移動履歴情報格納手段６５４に格納された移動履歴情報中に対応するＣＲＮの情報が存在するか否かを判断し、存在すると判断した場合にはＣＲＮの情報を抽出する。
【００６２】
具体的な例として、ＭＮ１０がサブネット２０からサブネット３０へハンドオーバをするとき、ＭＮ１０がメッセージＸに、サブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を含めた場合を考える。まず、ＭＮ１０が旧ＱｏＳパス上にＣＮ６０に向かってメッセージＸを送信すると、そのＱｏＳパス上に存在するＱＮＥは該当する移動履歴情報が自身に存在するか否かを判断し、存在しない場合に次のＱＮＥに向かってメッセージＸを転送する。そして、メッセージＸを受信手段６５１によって受信すると、制御手段６５３は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段６５４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報とするデータが存在するか否かを判断する。制御手段６５３は、存在すると判断した場合には、対応するＣＲＮの情報を抽出する。そして、送信手段６５２は、抽出されたＣＲＮの情報及び自身のインタフェース情報などをＭＮ１０へ送信する。
【００６３】
ここで、制御手段６５３によって移動履歴情報格納手段６５４には該当するデータが存在しないとされた場合には、次のＱＮＥに向かってメッセージＸを転送する。そして、該当する移動履歴情報を有するＱＮＥが存在しない場合には、ＣＮ６０はＭＮ１０に対して該当するＣＲＮが存在しないことを通知する。これにより、ＭＮ１０はプロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す必要がある。なお、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮが見つけ出された場合には、該当するＣＲＮ（ＱＮＥ）の制御手段は、図５に示すＡＲ２１の制御手段２１３や図６に示すＡＲ３１の制御手段３１３と同様に、見つけ出されたＣＲＮの情報と共に、ハンドオーバ前後のサブネットの情報、ＭＮの通信先それぞれのサブネットの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして移動履歴情報格納手段６５４に格納する。
【００６４】
次に、移動履歴情報を有する装置がＭＮ１０の場合について図２を用いて説明する。移動履歴情報は移動履歴情報格納手段１１１に格納されており、具体的にはＭＮ１０の過去の移動履歴の情報が格納されている。ＣＲＮ抽出手段１１０は、ＣＲＮ検出メッセージ生成手段１０４によってメッセージＸが生成される際に含まれる情報に基づいて、移動履歴情報格納手段１１１から該当する移動履歴情報が存在するか否かを判断し、存在する場合には該当するＣＲＮの情報を抽出する。そして、無線送信手段１０３は、抽出されたＣＲＮの情報をプロキシに送信する。一方、存在しないと判断された場合には、プロキシ決定手段１０５によって発見されたプロキシを通じてＣＲＮを見つけ出す処理が開始される。このように、ＭＮ１０自身が過去の移動履歴を利用することにより、あるパターンの行動を何度もするＭＮには有効である。ただし、このようなＭＮ１０自身が移動履歴情報を有する場合、ＣＲＮの情報の正当性の確認が必要になる。また、複数のＭＮ間での移動履歴情報のやりとり（共有）をすることも可能である。
【００６５】
次に、ＭＮ１０と移動履歴情報を有する装置（例えば、ＡＲ２１）との間で行われるＣＲＮの情報の抽出からプロキシへの送信までについて図８を用いて説明する。ＭＮ１０が、現在通信中の不図示のＡＰが接続されたＡＲ２１のサブネット２０からサブネット３０を構成するＡＲ３１に接続する不図示のＡＰへハンドオーバする際に、ＭＮ１０は、ＣＲＮを検出するためにサブネット２０の情報、サブネット３０の情報、ＣＮ６０のサブネットの情報などをメッセージＸに含め（ステップＳ８０１）、メッセージＸをＡＲ２１に送信する（ステップＳ８０２）。なお、ＭＮ１０は、ハンドオーバ後にステップＳ８０１、Ｓ８０２の処理を開始するようにしてもよい。ＭＮ１０からのメッセージＸを受信したＡＲ２１は、ハンドオーバ前、ハンドオーバ後、ＭＮの通信先のサブネットの情報、ハンドオーバによるＣＲＮの情報、ハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側からＣＲＮ側へのリンク情報、ＣＲＮ側からハンドオーバ後のサブネットを構成するアクセスルータ（プロキシ）側へのリンク情報を１組の関連したデータとして格納する移動履歴情報格納手段２１４に、メッセージＸに含まれるサブネット２０の情報、サブネット３０の情報、通信先のＣＮ６０のサブネットの情報を１組の関連した情報のデータが存在するか否かを判断し、存在すると判断した場合には、対応するＣＲＮの情報を抽出する（ステップＳ８０３）。そして、ＡＲ２１は、抽出されたＣＲＮの情報をＭＮ１０へ送信する（ステップＳ８０４）。
【００６６】
そして、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ８０５）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ８０６）。プロキシを決定したＭＮ１０は、ＡＲ２１から受信したＣＲＮの情報と、経路２４でのupstream用フロー識別子及びセッション識別子、downstream用フロー識別子及びセッション識別子をメッセージＡにセットするとともに、双方向通信であるという情報もメッセージＡにセットして（ステップＳ８０７）、選んだプロキシ６８にメッセージＡを送信する（ステップＳ８０８）。このように、あらかじめＣＲＮがわかっていれば、ＣＲＮ（ＱＮＥ６５）に対してＲＥＳＥＲＶＥメッセージを流すことができる。ここでは特に、プロキシ群のうちの１つであるプロキシ６８に対してメッセージＡが送られた場合を想定している。
【００６７】
なお、ＡＲ２１において、該当するＣＲＮの情報が抽出されなかった場合には、例えば、ＡＲ２１はＭＮ１０に対して該当するＣＲＮの情報が存在しない旨の情報を送信するようにしてもよい。これにより、ＭＮ１０はメッセージＡにＣＲＮの情報を含めないため、プロキシ側で該当するＣＲＮを見つけ出すことになる。
【００６８】
次に、ＭＮ１０からメッセージを受け取るプロキシ（ＱＮＥ６８）の機能について説明する。なお、ここで、ＭＮ１０はプロキシの１つとして、図１中のＱＮＥ６８をプロキシの１つとして選んだ場合を考える。図９は、本発明の実施の形態におけるプロキシの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図９に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００６９】
図９に示すプロキシ６８は、受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６を有している。また、オプションとして、メッセージ生成手段６８７、及び経路情報格納手段６８８を有してもよい。なお、図９では、オプション部分に関しては、点線で図示されている。
【００７０】
受信手段６８１及び送信手段６８２は、データ受信及びデータ送信を行うための手段である。また、メッセージ処理手段６８３は、図２に示すＭＮ１０のメッセージ生成手段１０６で生成され、無線送信手段１０３で送信されたメッセージ（メッセージＡ）を受信、処理するための手段である。例えば、メッセージＡ中に含まれるデータの流れの情報を確認し、どのような形でＱｏＳ経路を確立するのが望ましいかを判断する。また、メッセージＡにＣＲＮの情報が含まれている場合には、メッセージ処理手段６８３は、このＣＲＮの情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。一方、メッセージ処理手段６８３がＭＮ１０からＣＲＮの情報を受信しない場合には、後述するメッセージ生成手段６８５、メッセージ処理手段６８４などによりＣＲＮを発見し、このＣＲＮ情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。ＱｏＳ経路を確立する処理方法については後述する。なお、受信したＣＲＮの情報は、双方向通信を行っているとすると、後述するようなupstream用のＣＲＮの情報とdownstream用のＣＲＮの情報である。また、データの流れによるＱｏＳ経路確立方法の変化に関しては、後述の中間のＱＮＥの機能と共に説明する。
【００７１】
また、メッセージ生成手段６８５は、メッセージ処理手段６８３で受け取ったフロー識別子（例えば、経路２４のフロー識別子Ｘ）、セッション識別子（例えば、経路２４及び経路３４に共通のセッション識別子Ｙ）を含むメッセージ（メッセージＢとする）を生成する。メッセージ生成手段６８５によって生成される上記のメッセージＢは、ＣＲＮを発見するためのメッセージであり、送信手段６８２を介してＣＮ６０に向けて送信される。なお、このフロー識別子の中には、ＣＮ６０のＩＰアドレス情報が含まれている。
【００７２】
また、メッセージ処理手段６８４は、メッセージ生成手段６８５で生成され、送信されたメッセージＢを受け取ったＣＮ６０から、経路３４上の各ＱＮＥを介して送られてきたメッセージ（メッセージＣとする）を受信、処理する手段である。このメッセージＣには、ＣＲＮの情報が含まれている。メッセージ処理手段６８４では、このＣＲＮ情報を基に、ＭＮ１０がハンドオーバ時にＱｏＳ経路を迅速に確立するための処理を行う。この処理を行うには、複数の方法が考えられる。例えば、この情報を経路情報格納手段６８８に渡し、ＭＮ１０がハンドオーバして来た時点で何かしらの処理を行ってもよく、また、その情報をさらにメッセージ生成手段６８６に渡して、ＭＮ１０への返信メッセージ（前述のメッセージＤ）としてもよい。ただしこの場合には、ＭＮ１０には、図２のメッセージ受信手段１０７が設けられている必要がある。なお、前述の通り、メッセージＤには準備が成功したかどうかという情報が含まれてもよい。また、さらに、メッセージＤには、これ以外の情報が含まれてもよい。また、ＭＮ１０からＣＲＮの情報が送信されてきた場合には、ＭＮ１０への返信メッセージを送信しなくてよい。
【００７３】
また、メッセージ処理手段６８３で、ＭＮ１０のＮＣｏＡの情報を受け取っていた場合には、メッセージ生成手段６８７で、このＮＣｏＡを基に新しいフロー識別子を生成し、メッセージ処理手段６８３又はメッセージ処理手段６８４で受け取ったＣＲＮの情報を基に、ＲＥＳＥＲＶＥメッセージをＣＮ６０に送信することによって、経路３４上に新しいＱｏＳ経路を生成してもよい。ただしこの場合には、ＲＥＳＥＲＶＥメッセージにＣＲＮの情報を持たせ、該当するＣＲＮは、そこからＣＮ６０までのリソース予約を２重予約にならないようにするなど、別の機能が必要になる。なお、ＱｏＳ経路確立に必要となり、ＲＥＳＥＲＶＥメッセージに含まれるべきQSpecの情報などに関しては、例えば、メッセージ処理手段６８３で受信されるＣＲＮの情報又はメッセージＣに含まれるＣＲＮの情報を参照して、このＣＲＮから取得することができる。
【００７４】
また、メッセージＡにＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）の情報が含まれている場合には、ＱＮＥ６３から取得することもできる。また、前述のように送られたＮＣｏＡが、妥当性のチェックが必要なものだった場合には、そのチェックを行わなければならない。もし、このプロキシがＮＣｏＡの妥当性チェック機能を有していなかった場合、又は妥当性チェックを行った結果、妥当で無かった場合には、例えば、ＭＮ１０にエラー通知を行うためのエラーメッセージを返す必要がある。このエラー通知は、メッセージＤに含めることも可能であり、また、別のメッセージ（例えば、ＦＭＩＰにおけるＦＢＡｃｋメッセージ）として返すことも可能である。また、メッセージ生成手段６８５で生成されるメッセージＢには、上記以外の情報（例えば、妥当であることが確認されたＮＣｏＡや、メッセージＡに含まれているＭＮ１０の現在の隣り合うＱＮＥ（ＱＮＥ６３）などの情報）を含めることもできる。
【００７５】
次に、経路３４上の中間のＱＮＥの機能について、ＱＮＥ６５を例に取って説明する。図１０は、本発明の実施の形態における経路３４上の中間ＱＮＥの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図１０に示すＱＮＥ６５が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、前述した図７のように、ＱＮＥ６５が移動履歴情報を有する装置である場合には、制御手段６５３や移動履歴情報格納手段６５４を有する構成となる。
【００７６】
図１０に示すＱＮＥ６５は、受信手段６５１１、送信手段６５１２、メッセージ処理手段６５１３、メッセージ生成手段６５１４を有している。受信手段６５１１、送信手段６５１２は、図９に示すプロキシ６８の受信手段６８１、送信手段６８２と同じ機能を有している。また、メッセージ処理手段６５１３は、前述のメッセージＢ又はメッセージＣを受け取った際、その中に含まれているフロー識別子とセッション識別子の組で、すでにＱＮＥ６５内にリソース予約が無いかどうかを調べる手段である。予約が無かった場合は、メッセージ生成手段６５１４では何も行われずに、送信手段６５１２を経由して次のＱＮＥにメッセージＢ又はメッセージＣが転送される。一方、予約があった場合は、メッセージ生成手段６５１４において、そのインタフェースのＩＰアドレスが同メッセージ内に格納され、メッセージ生成手段６５１４で生成された新たなメッセージが、送信手段６５１２を経由して次のＱＮＥに送信される。ただし、メッセージＢやメッセージＣが、他の何かしらの処理をＱＮＥに求めるものだった場合、例えば、ＱＵＥＲＹメッセージやそれに対するＲＥＳＰＯＮＳＥメッセージの拡張だった場合には、これらのメッセージに特有の処理が行われる。
【００７７】
メッセージＢ、メッセージＣのどちらで上述の処理を行うかは、データの流れの方向、及びその他のＮＳＩＳの機能により異なる。一例としては、データの流れがＣＮ６０からＭＮ１０の方向のみだった場合、ＲＳＶＰ（非特許文献３参照）のＱｏＳ経路確定方法の考え方に従えば、ＣＮ６０から送られるメッセージＣを受け取った際に、上述の処理を行うのが妥当である。
【００７８】
なお、データやシグナリングが通る経路は、ＭＮ１０からＣＮ６０の方向（upstreamとする）と、ＣＮ６０からＭＮ１０の方向（downstreamとする）で違う場合も考えられるので、実際問題として、メッセージＣは経路３４を通る（経路３４を確定することができる）が、メッセージＢは経路３４を通らないということも考えられる。したがって、経路３４上の各ＱＮＥでは、メッセージＢ及びメッセージＣのどちらか一方のみしか受け取らないこともあり得る。
【００７９】
逆に、同じ考え方を採用した場合、データの流れがupstreamだった場合にはメッセージＢにより経路３４が確定され、上述のメッセージ処理手段６５１３及びメッセージ生成手段６５１４にて処理が行われる。この場合には、メッセージＣは各ＱＮＥによって、メッセージＢを受け取った際に処理された結果をプロキシ６８に返すためのみのメッセージとなり得る。しかしながら、ＮＳＩＳではＮＴＬＰの機能を活用することにより、必ずしもＲＳＶＰの経路確定方法の考え方が当てはまるとは限らない。例えば、downstream方向のデータの流れに対し、メッセージＢが経路３４を通り、必要な情報を集めることも可能になり得る。
【００８０】
次に、ＣＮ６０の機能について説明する。図１１は、本発明の実施の形態におけるＣＮの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図１１に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。
【００８１】
図１１に示すＣＮ６０は、受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、経路情報格納手段６０５を有している。受信手段６０１、送信手段６０２は、図９に示すプロキシ６８の受信手段６８１、送信手段６８２や、図１０に示す受信手段６５１１、送信手段６５１２と同じ機能を有している。また、メッセージ処理手段６０３は、メッセージＢを受け取って処理する機能を有している。例えば、メッセージ処理手段６０３では、メッセージＢがupstreamに対して出されたものか、downstreamに対して出されたものかが判断される。また、メッセージＢにupstream用のＣＲＮの情報が含まれている場合には、メッセージ処理手段６０３は、そのＣＲＮの情報を経路情報格納手段６０５に渡して保有させることも可能である。ＣＮ６０は、経路情報格納手段６０５に格納された情報を使うことによって、ＭＮ１０のＮＣｏＡの情報が得られたときに、ＲＥＳＥＲＶＥメッセージを用いたＱｏＳ経路確立処理を行うことができる。
【００８２】
なお、ＭＮ１０のＮＣｏＡの情報は、メッセージＢに含まれている場合にはメッセージＢの受信と同時に取得することが可能であり、また、ＭＮ１０からのＢＵメッセージより取得することも可能である。また、ＲＥＳＥＲＶＥメッセージに含まれるべきQSpecの情報などに関しては、前述の通り、ＣＲＮから取得することも可能であり、また、メッセージＢがＱＮＥ６３のＩＰアドレスを含んでいる場合には、ＱＮＥ６３から取得することも可能である。また、メッセージ生成手段６０４ではメッセージＣを生成し、送信手段６０２を通じてメッセージＣを送信する手段である。なお、メッセージＢに経路情報（どのＱＮＥがリソース予約を持っていたか）が含まれていた場合には、それをメッセージＣに含めて送信することも可能である。また、メッセージＣは、上記以外の情報を含んでいてもよい。
【００８３】
次に、メッセージＢ及びメッセージＣを送受信することにより、どのようにＣＮ６０やプロキシ６８がＣＲＮの情報を得ることができるかについて説明する。今、ＭＮ１０とＣＮ６０が、例えばＩＰテレフォニなどを使って、双方向通信を行っているとする。この場合、データの流れはupstreamとdownstreamの両方があり、これら双方向のデータは必ずしも同じ経路（同じルータ）を通るとは限らないので、ＣＲＮもupstream側とdownstream側でそれぞれ違うと考えられる。ここでは、図１を参照しながら、双方向のデータが同じ経路を通ると仮定するが、双方向のデータが違う経路を通る場合においても、後述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。なお、双方向通信の場合には、それぞれの方向の通信経路に関して、フロー識別子とセッション識別子とが存在しており、プロキシは、これら２方向のフロー識別子、セッション識別子の組をＭＮ１０からもらい、メッセージＢに埋め込んでＣＮ６０に送るようにすればよい。
【００８４】
図１２には、メッセージＢ及びＣの送受信により、プロキシが得ることのできる情報の一例が図示されている。メッセージＢ及びメッセージＣには、各メッセージが持っているフロー識別子、セッション識別子のペアに対するリソースの予約を持つＱＮＥを通過するたびに、そのリソース予約を持つインタフェースのＩＰアドレスの情報が、各メッセージの最後に付加される。例えばメッセージＢの場合には、ＱＮＥ６５を通過する際、upstreamのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８１：ＱＮＥ６５の、上側（ＱＮＥ６６側）インタフェースのＩＰアドレス）が付けられ、ＱＮＥ６６を通過する際には、その更に後ろに、ＱＮＥ６６内のupstreamのフロー識別子、セッション識別子に対するリソース予約を持つインタフェースのＩＰアドレス（情報８２：ＱＮＥ６６の、上側（ＣＮ６０側）インタフェースのＩＰアドレス）が付けられる。このメカニズムにより、この情報がＣＮ６０やプロキシ６８に返された場合には、ＣＮ６０やプロキシ６８は、最初に付けられたインタフェースのＩＰアドレス（情報８１のＩＰアドレス）を持つＱＮＥが、upstreamのＣＲＮだと判断することができる。
【００８５】
また、downstreamに関しては順序が逆になるので、プロキシ６８は、情報８３及び情報８４のうち、最後に付けられたインタフェースのＩＰアドレス（情報８４のＩＰアドレス）を持つＱＮＥが、downstreamのＣＲＮだと判断することができる。なお、ＱｏＳ経路は、ネットワークの状態などの要因によって変化する可能性があり、ＱｏＳ経路の変化に応じて、ＣＲＮも変化する可能性がある。このようなＣＲＮの変化が生じる可能性に対処するため、ＣＮ６０やプロキシ６８が保持するＣＲＮの情報に対して有効期限を設定し、その有効期限が切れる前に、ＣＮ６０やプロキシ６８が、ＣＲＮに変化が生じていないかの確認を行ったり、最新のＣＲＮの情報を取得したりすることによって、正確なＣＲＮの情報を保持できるようにすることも可能である。なお、この有効期限の設定は、ＣＲＮの情報を受け取るＣＮ６０やプロキシ６８が行ってもよく、また、ＭＮ１０がメッセージＡを送る際に、ＣＮ６０やプロキシ６８に対して、有効期限を通知してもよい。
【００８６】
次に、ＭＮ１０が、メッセージＡにＣＲＮの情報を含めることができない場合に、プロキシ６８にＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作について説明する。図１３及び図１４には、本発明の実施の形態において、ＭＮ１０がプロキシ６８に識別子（フロー識別子及びセッション識別子）の情報を送り、プロキシ６８とＣＮ６０とが中間ＱＮＥ６５〜６７を介してメッセージをやり取りすることにより、upstreamやdownstreamのＣＲＮを見つける動作例を示すシーケンスチャートが図示されている。なお、図１３及び図１４に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものであり、ここでは、プロキシ６８がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている。また、図１３及び図１４に示すシーケンスチャートには、一連の動作が示されており、図１３及び図１４のシーケンスチャートに図示されているステップＳ１３１２の処理は同一である。
【００８７】
近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ１３０１）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ１３０２）。プロキシを決定したＭＮ１０は、経路２４でのupstream用フロー識別子及びセッション識別子、downstream用フロー識別子及びセッション識別子をメッセージＡにセットするとともに、双方向通信であるという情報もメッセージＡにセットして（ステップＳ１３０３）、選んだプロキシ群（複数のプロキシ）にメッセージＡを送信する（ステップＳ１３０４）。ここでは特に、プロキシ群のうちの１つであるプロキシ６８に対してメッセージＡが送られた後の処理に限って説明する。
【００８８】
プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでupstream、返信メッセージ（メッセージＣ）でdownstreamの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ１３０５）、ＣＮ６０にメッセージＢを送信する（ステップＳ１３０６）。なお、このとき、プロキシ６８はフロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。
【００８９】
プロキシ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７は、メッセージＢの中身を確認し、その中のupstream用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ内に存在するかどうかを確認する。そして、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥは、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加して、ＣＮ６０に向けて送る。一方、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。
【００９０】
なお、ＱＮＥ６７には、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ１３０７、１３０８）。また、ＱＮＥ６５には、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後（ステップＳ１３０９）、メッセージＢは転送される（ステップＳ１３１０）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後（ステップＳ１３１１）、メッセージＢは転送される（ステップＳ１３１２）。
【００９１】
そして、最終的にメッセージＢはＣＮ６０に到着し、このメッセージＢを受け取ったＣＮ６０は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでdownstream用経路の情報を収集できるようにパラメータをセットして（ステップＳ１３１３）、プロキシ６８に向けて送信する（ステップＳ１３１４）。また、ＣＮ６０からプロキシ６８への経路上にある各ＱＮＥ６５〜６７は、上述のメッセージＢに対する処理と同様の処理をdownstream用のメッセージＣに対して行う。
【００９２】
すなわち、ＱＮＥ６６には、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後（ステップＳ１３１５）、メッセージＣは転送される（ステップＳ１３１６）。また、ＱＮＥ６５と同様に、ＱＮＥ６５にも、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後（ステップＳ１３１７）、メッセージＣは転送される（ステップＳ１３１８）。また、ＱＮＥ６７には、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＣはそのまま転送される（ステップＳ１３１９、１３２０）。
【００９３】
このようにしてメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、upstream用及びdownstream用のＣＲＮの情報を特定することが可能となり、upstream用及びdownstream用のＣＲＮの情報をメッセージＤにセットして（ステップＳ１３２１）、ＭＮ１０にメッセージＤを送信する（ステップＳ１３２２）。
【００９４】
なお、前述のＭＮ１０の機能で説明した通り、プロキシ６８はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ＭＮ１０は、ＣＲＮの情報を早期に知ることにより、例えば、サブネットを移動した後にリソース予約を行う際、このＣＲＮの情報をＲＥＳＥＲＶＥメッセージに含ませて送ることができる。また、ＣＲＮの情報を含むＲＥＳＥＲＶＥメッセージを該当するＣＲＮが受け取った場合には、該当するＣＲＮは、その先のＣＮ６０までのリソースを２重予約しないようにする処理を行うことが可能である。例えば、該当するＣＲＮは、新規にリソースを予約するのではなく、古い予約を更新するなどの処理を行うことも可能である。
【００９５】
このようにＣＲＮの特定が前もってなされると、たとえＭＮ１０のハンドオーバ後のリソース予約であったとしても、従来の技術のように、ＣＲＮを探しながらのリソース予約とはならないために、迅速にＱｏＳ経路を張ることが可能となる。また、前述の通り、ＣＲＮの情報を得たプロキシ６８が、ＭＮ１０に情報を返すことなく、前もってリソース予約を行うようにすることも可能であり、より迅速なＱｏＳ経路確立が実現できる。
【００９６】
また、さらに、前述の通り、メッセージＢやメッセージＣを既存のメッセージ、例えばＱＵＥＲＹメッセージやＲＥＳＰＯＮＳＥメッセージやＮＯＴＩＦＹメッセージに書き換えることも可能である。図１５及び図１６には、ＱＵＥＲＹメッセージにメッセージＢの機能を、ＲＥＳＰＯＮＳＥメッセージにメッセージＣの機能を持たせた場合のシーケンスチャートが図示されている。ここでは、やり取りされるメッセージが、upstream及びdownstreamのＣＲＮを見つける機能のほかに、本来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージが持つ機能（空きリソースの情報の取得機能など）を有している。なお、図１５及び図１６中のステップＳ１５０１〜Ｓ１５２２は、図１３及び図１４中のステップＳ１３０１〜Ｓ１３２２と対応関係にあり、ＱＵＥＲＹメッセージとメッセージＣ、ＲＥＳＰＯＮＳＥメッセージとメッセージＤがそれぞれ対応関係にある。
【００９７】
前述の通り、従来のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージを利用した場合には、ＭＮ１０などの移動を行う端末は通信相手との間で行っている現在の通信で予約されているリソースの情報を知る術を持たないため、ＣＲＮとＣＮ６０間において、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができない。しかし、ＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージがＭＮ１０の現在のフロー識別子及びセッション識別子の情報を有することにより、現在の通信で予約されているリソース情報を、ＭＮ１０が移動してきたときに使うことのできるリソース情報と判断することができる。
【００９８】
なお、非特許文献６によると、リソースの空き情報を得られるのはＲＥＳＰＯＮＳＥメッセージによってのみである。つまり、図１５及び図１６に示すように、プロキシ６８からＣＮ６０にＱＵＥＲＹメッセージを送信し、ＣＮ６０からプロキシ６８にＲＥＳＰＯＮＳＥメッセージを返信する場合には、downstreamのリソースの空き情報しか得られない可能性がある。よって、双方向の空きリソースの情報が必要な場合は、プロキシ６８からＱＵＥＲＹメッセージを受け取ったＣＮ６０が、ＲＥＳＰＯＮＳＥメッセージをＭＮ１０に返すと同時に、別のＱＵＥＲＹメッセージをプロキシ６８に送信する必要も考えられる。また、ＮＳＩＳの他の機能と組み合わせることにより、一度のＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージの送受信で、双方向のリソースの空き情報を得ることができる可能性もある。
【００９９】
なお、プロキシ６８が図９のメッセージ処理手段６８４によって得たＣＲＮの情報（メッセージＣに含まれるＣＲＮの情報）又はメッセージ処理手段６８３によって得たＣＲＮの情報（ＭＮ１０から送信されたメッセージＡに含まれるＣＲＮの情報）を処理する方法、及び、ＣＮ６０が図１１のメッセージ処理手段６０３によって得たＣＲＮの情報（メッセージＢに含まれるＣＲＮの情報）を処理する方法は、前述以外の方法も考えられる。これらの方法を、図１７及び図１８を参照しながら説明する。
【０１００】
図１７は、本発明の実施の形態において、メッセージＣの受信後又はメッセージＡの受信後における処理方法を実現するプロキシの構成を示すブロック図である。なお、図９に示すプロキシ６８と同様に、図１７に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図１７における受信手段６８１１、送信手段６８１２、メッセージ処理手段６８１３、６８１４、メッセージ生成手段６８１５、６８１６、６８１７、及び経路情報格納手段６８１８は、図９における受信手段６８１、送信手段６８２、メッセージ処理手段６８３、６８４、メッセージ生成手段６８５、６８６、６８７、及び経路情報格納手段６８８にそれぞれ等しい機能を持つので、ここでの説明は省略する。
【０１０１】
図１７のメッセージ生成手段６８１９は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成し、送信手段６８１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６８１４のメッセージＢに係る処理によって特定されたＣＲＮ又はメッセージＡに含まれるＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認されたＭＮ１０のＮＣｏＡや、ＣＮ６０のＩＰアドレスなど）が含まれる。プロキシ６８が送信したメッセージＥを受け取ったＣＲＮは、例えば、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。
【０１０２】
また、図１８は、本発明の実施の形態において、メッセージＢの受信後における別の処理方法を実現するＣＮの構成を示すブロック図である。なお、図１１に示すＣＮ６０と同様に、図１８に示すＣＮ６０が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。また、図１８における受信手段６０１１、送信手段６０１２、メッセージ処理手段６０１３、メッセージ生成手段６０１４、及び経路情報格納手段６０１５は、図１１における受信手段６０１、送信手段６０２、メッセージ処理手段６０３、メッセージ生成手段６０４、及び経路情報格納手段６０５にそれぞれ等しい機能を持つので、ここでの説明は省略する。
【０１０３】
図１８のメッセージ生成手段６０１６は、ＱｏＳ経路生成を、別のノードに依頼するためのメッセージ（メッセージＥとする）を生成し、送信手段６０１２に渡す機能を有している。メッセージＥの送信先としては、例えば、メッセージ処理手段６０１３のメッセージＢに係る処理によって特定されたＣＲＮが考えられる。この場合、メッセージＥには、ＣＲＮがＱｏＳ経路を生成するのに必要な情報（例えば、妥当性が確認された、前述の方法によって取得されたＭＮ１０のＮＣｏＡや、メッセージＢの送信元であるプロキシ６８のＩＰアドレスなど）が含まれる。メッセージＥを受け取ったＣＲＮは、例えば、ＲＥＳＥＲＶＥメッセージをＣＮ６０及びプロキシ６８の両方に送信することによって、ＣＲＮからＣＮ６０の間ではＱｏＳ経路の更新が行われ、ＣＲＮからプロキシ６８の間ではＱｏＳ経路の新規生成が行われるようにすることが可能である。
【０１０４】
次に、プロキシ６８が、メッセージＣの受信によって特定されたＣＲＮ又はメッセージＡの受信によって特定されたＣＲＮに、ＱｏＳ経路の生成の依頼を行う際の動作について説明する。なお、ここでは、双方向データ通信であって、双方向の経路が等しい場合を仮定するが、upstream側又はdownstream側のどちらか一方のみの場合、あるいは、双方向データ通信で、双方向の経路がupstream側とdownstream側とで異なる場合においても、後述する方法と同様の方法をupstream用経路、又は双方向経路に別々に用いることによって、ＱｏＳ経路生成依頼が行われるようにすることが可能である。
【０１０５】
図１９には、本発明の実施の形態において、ＭＮ１０から、ＮＣｏＡを含むメッセージ（メッセージＡ）を受け取ったプロキシ６８が、ＣＮ６０とのメッセージ（メッセージＢ及びメッセージＣ）のやり取りで特定されたdownstream用ＣＲＮ宛てに、新しいＱｏＳ経路の作成を依頼する動作例を示すシーケンスチャートが図示されている。なお、図１９に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものである。また、図１９のステップＳ１９０３と、ステップＳ１９０４の間には、図１３のステップＳ１３０６からステップＳ１３１２、及び図１４のステップＳ１３１３からステップＳ１３２０と同様の処理が行われるが、ここでは省略されている。
【０１０６】
プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、プロキシ６８は、メッセージＢでupstream、返信メッセージ（メッセージＣ）でdownstreamの情報を、途中のルータから得られるようにパラメータをセットし、さらにメッセージＡによって送られてきたフロー識別子、セッション識別子をメッセージＢにセット（メッセージＢの送信準備）して（ステップＳ１９０１）、ＣＮ６０にメッセージＢを送信する（ステップＳ１９０３）。なお、このとき、プロキシ６８は、フロー識別子の情報より、ＣＮ６０のアドレスを得る必要がある。また、プロキシ６８は、ステップＳ１９０１におけるメッセージＢの送信準備と共に、メッセージＡに含まれているＭＮ１０のＮＣｏＡの妥当性のチェックを行う（ステップＳ１９０２）。
【０１０７】
そして、ステップＳ１９０３で送信したメッセージＢの返信メッセージであるメッセージＣを受け取ったプロキシ６８は、メッセージＣを参照することによって、upstream用及びdownstream用のＣＲＮの情報を得る（ステップＳ１９０４）。プロキシ６８は、これらのＣＲＮが新しいＱｏＳ経路を確立するために必要な情報をメッセージＥにセットし（ステップＳ１９０５）、ステップＳ１９０４によって得られたupstream用及びdownstream用ＣＲＮのそれぞれに対して、メッセージＥを送信する（ステップＳ１９０６及びステップＳ１９０７）。ここでは、upstream用ＣＲＮ及びdownstream用ＣＲＮが共にＱＮＥ６５となるが、ステップＳ１９０４で取得したupstream用ＣＲＮ及びdownstream用ＣＲＮのインタフェースアドレスがそれぞれ異なっていることも考えられるため（ＱＮＥ６５内の別々のインタフェースアドレスが、upstream用ＣＲＮ及びdownstream用ＣＲＮとしてステップＳ１９０４で取得される）、メッセージＥはupstream用及びdownstream用それぞれ別々に送信されている。なお、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報としては、例えば、新しいＱｏＳ経路で使われるフロー識別子などが考えられる。この新しいフロー識別子は、ステップＳ１９０２で妥当性が確認されたＭＮ１０のＮＣｏＡを基に生成されることが可能である。また、このほかに、さらに、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報は、ＣＮ６０のＩＰアドレスやセッション識別子なども考えられる。
【０１０８】
メッセージＥを受け取ったＱＮＥ６５は、ＣＮ６０宛てにＱｏＳ経路を更新するためのＲＥＳＥＲＶＥメッセージを送信し（ステップＳ１９０８）、また、プロキシ６８宛てにＱｏＳ経路を新規で生成するためのＲＥＳＥＲＶＥメッセージを送信する（ステップ１９０９）。なお、ここでは、ステップＳ１９０８により、upstream用及びdownstream用の両方のＱｏＳ経路が更新され、ステップＳ１９０９により、upstream用及びdownstream用の両方のＱｏＳ経路が新規に生成される場合が示されている。
【０１０９】
一方、図２０には、本発明の実施の形態において、ＭＮ１０から、ＣＲＮの情報及びＮＣｏＡを含むメッセージ（メッセージＡ）を受け取ったプロキシ６８が、受信したdownstream用ＣＲＮ宛てに、新しいＱｏＳ経路の作成を依頼する動作例を示すシーケンスチャートが図示されている。なお、図２０に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシの１つに選ばれている場合のものである。
【０１１０】
プロキシ６８は、ＭＮ１０から受け取ったメッセージＡの情報を基に、メッセージＡに含まれているＭＮ１０のＮＣｏＡの妥当性のチェックを行う（ステップＳ２００１）。そして、プロキシ６８は、upstream用及びdownstream用のＣＲＮが新しいＱｏＳ経路を確立するために必要な情報をメッセージＥにセットし（ステップＳ２００２）、ステップＳ２００１によって得られたupstream用及びdownstream用ＣＲＮのそれぞれに対して、メッセージＥを送信する（ステップＳ２００３及びステップＳ２００４）。ここでは、upstream用ＣＲＮ及びdownstream用ＣＲＮが共にＱＮＥ６５となるが、ステップＳ２００１で取得したupstream用ＣＲＮ及びdownstream用ＣＲＮのインタフェースアドレスがそれぞれ異なっていることも考えられるため（ＱＮＥ６５内の別々のインタフェースアドレスが、upstream用ＣＲＮ及びdownstream用ＣＲＮとしてステップＳ２００１で取得される）、メッセージＥはupstream用及びdownstream用それぞれ別々に送信されている。なお、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報としては、例えば、新しいＱｏＳ経路で使われるフロー識別子などが考えられる。この新しいフロー識別子は、ステップＳ２００１で妥当性が確認されたＭＮ１０のＮＣｏＡを基に生成されることが可能である。また、このほかに、さらに、ＣＲＮが新しいＱｏＳ経路を確立するために必要な情報は、ＣＮ６０のＩＰアドレスやセッション識別子なども考えられる。
【０１１１】
メッセージＥを受け取ったＱＮＥ６５は、ＣＮ６０宛てにＱｏＳ経路を更新するためのＲＥＳＥＲＶＥメッセージを送信し（ステップＳ２００５）、また、プロキシ６８宛てにＱｏＳ経路を新規で生成するためのＲＥＳＥＲＶＥメッセージを送信する（ステップ２００６）。なお、ここでは、ステップＳ２００５により、upstream用及びdownstream用の両方のＱｏＳ経路が更新され、ステップＳ２００６により、upstream用及びdownstream用の両方のＱｏＳ経路が新規に生成される場合が示されている。
【０１１２】
また、ＣＮ６０がupstream用ＣＲＮの情報を取得した後に、upstream用ＣＲＮに対して新しいＱｏＳ経路を生成する依頼をする場合にも、同様の方法を用いることが可能である。この場合には、図１８に図示されているＣＮ６０がupstream用ＣＲＮの情報と、ＭＮ１０の妥当なＮＣｏＡを取得した後、upstream用ＣＲＮに対して、メッセージＥを送信する。なお、この場合には、メッセージＥにプロキシ６８のＩＰアドレスの情報を含めることも可能である。
【０１１３】
また、図２に示されるＭＮ１０のプロキシ決定手段１０５において、ＭＮ１０はプロキシとしてＣＮ６０を選ぶことも可能である。また、ＣＮ６０は、図９に示されるプロキシ６８と同様の機能を、図１１に示されるＣＮ６０の機能と併せて持つことも可能であり、プロキシ６８は、図１１に示されるＣＮ６０の機能と同様の機能を、図９に示されるプロキシ６８の機能と併せて持つことも可能である。この場合、ＭＮ１０からメッセージＡを受け取ったＣＮ６０が、プロキシ６８との間でメッセージＢ及びメッセージＣを送受信することによりＣＲＮの情報を得ること、又はメッセージＡにＣＲＮの情報が含まれている場合には即座にＣＲＮの情報を得ることが可能である。
【０１１４】
このように、プロキシ６８としてＣＮ６０が選択された場合であって、メッセージＡにＣＲＮの情報が含まれていない場合の動作について、図２１及び図２２に示すシーケンスチャートを参照しながら説明する。なお、図２１及び図２２に示すシーケンスチャートには、メッセージＡにＣＲＮの情報が含まれていない場合の一連の動作が示されており、図２１及び図２２のシーケンスチャートに図示されているステップＳ２１１２は同一の処理である。また、図２１及び図２２に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０の移動先サブネットワークの候補として、サブネット３０が選ばれている場合のものであり、ここでは、ＣＮ６０がＣＲＮの情報を得た後に、ＭＮ１０に対して、その情報を返すようにしている場合が示されている。一方、図２３に示すシーケンスチャートには、メッセージＡにＣＲＮの情報が含まれている場合の一連の動作が示されている。また、図２３に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０の移動先サブネットワークの候補として、サブネット３０が選ばれている場合のものが示されている。
【０１１５】
図２１において、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定（ハンドオーバ先候補を決定）し（ステップＳ２１０１）、その後、ＡＰのＬ２情報を基にして、ＭＮ１０がそのサブネットワークに移動した際に確立されるＱｏＳ経路上で、ＭＮ１０と隣り合うＱＮＥ（図１においてサブネット３０を移動先とした場合、経路３４上で最もＡＲ３１に近いＱＮＥ）を判定する（ステップＳ２１０２）。この判定は、前述の実施の形態で、ＭＮ１０がプロキシを決定する方法と同様の方法を利用することが可能である。
【０１１６】
ＭＮ１０は、ステップＳ２１０２で判定されたＱＮＥ（ＱＮＥ６８）の情報をメッセージＡにセットする（ステップＳ２１０３）。ここでは、特に、ステップＳ２１０２で判定されたＱＮＥの情報の１つとして、ＱＮＥ６８の情報がメッセージＡにセットされた場合について記述する。なお、メッセージＡには、経路２４でのupstream用フロー識別子及びセッション識別子、downstream用フロー識別子及びセッション識別子、双方向通信であるという情報もセットされることが可能である。その後、ＭＮ１０はこのメッセージＡをＣＮ６０に送信する（ステップＳ２１０４）。
【０１１７】
ＣＮ６０は、ＭＮ１０から受け取ったメッセージＡの情報を基にメッセージＢを生成する。ここでは双方向通信を考えているので、メッセージＢでdownstream、返信メッセージ（メッセージＣ）でupstreamの情報を、途中のルータから得られるようにパラメータをセットし、フロー識別子、セッション識別子をメッセージＢにセットして（ステップＳ２１０５）、ＱＮＥ６６にメッセージＢを送信する（ステップＳ２１０６）。なお、メッセージＢにセットすべきフロー識別子、セッション識別子の情報がメッセージＡに含まれている場合には、メッセージＡに含まれているこれらの情報をメッセージＢにコピーすることも可能である。一方、フロー識別子、セッション識別子の情報がメッセージＡに含まれていない場合においても、ＣＮ６０は、ＭＮ１０との現在の通信において使用しているフロー識別子、セッション識別子の情報をメッセージＢにセットすることが可能である。
【０１１８】
ＣＮ６０からＱＮＥ６８への経路上に存在する各ＱＮＥ６５〜６７は、メッセージＢの内容を確認し、その中のdownstream用フロー識別子及びセッション識別子に対するリソース予約がＱＮＥ６５〜６７内に存在するかどうかを確認する。そして、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在する場合には、各ＱＮＥ６５〜６７は、そのリソース予約が存在するインタフェースのＩＰアドレスをメッセージＢに付加した後に、そのメッセージＢをＱＮＥ６８に向けて送る。一方、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しない場合には、情報の付加を行わずにメッセージＢをそのまま転送する。
【０１１９】
なお、ＱＮＥ６６には、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ２１０７、Ｓ２１０８）。また、ＱＮＥ６６と同様に、ＱＮＥ６５にも、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＢに付加された後、メッセージＢは転送される（ステップＳ２１０９、Ｓ２１１０）。一方、ＱＮＥ６７には、downstream用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＢはそのまま転送される（ステップＳ２１１１、Ｓ２１１２）。
【０１２０】
そして、最終的にメッセージＢはＱＮＥ６８に到着し、このメッセージＢを受け取ったＱＮＥ６８は、各ＱＮＥ６５〜６７によって付加された情報（各ＱＮＥ６５〜６７によってメッセージＢに付加された情報）をメッセージＣにセットするとともに、メッセージＣでupstream用経路の情報を収集できるようにパラメータをセットして（ステップＳ２１１３）、ＣＮ６０に向けて送信する（ステップＳ２１１４）。また、ＱＮＥ６８からＣＮ６０への経路上にある各ＱＮＥ６５〜６７では、メッセージＣを受信した場合、上述のメッセージＢに対する処理と同様の処理がupstream用のメッセージＣに対して行われる。
【０１２１】
すなわち、ＱＮＥ６７には、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しないので、情報の付加が行われずにメッセージＣはそのまま転送される（ステップＳ２１１５、Ｓ２１１６）。また、ＱＮＥ６５には、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ２１１７、Ｓ２１１８）。また、ＱＮＥ６５と同様に、ＱＮＥ６６にも、upstream用フロー識別子及びセッション識別子に対するリソース予約が存在しており、そのリソース予約が存在するインタフェースのＩＰアドレスがメッセージＣに付加された後、メッセージＣは転送される（ステップＳ２１１９、Ｓ２１２０）。
【０１２２】
このようにしてメッセージＣを受け取ったＣＮ６０は、メッセージＣを参照することによって、upstream用及びdownstream用のＣＲＮの情報を特定することが可能となり、upstream用及びdownstream用のＣＲＮの情報をメッセージＤにセットして（ステップＳ２１２１）、ＭＮ１０にメッセージＤを送信する（ステップＳ２１２２）。
【０１２３】
一方、プロキシ６８としてＣＮ６０が選択された場合であって、メッセージＡにＣＲＮの情報が含まれている場合の動作について図２３に示すシーケンスチャートを参照しながら説明する。図２３において、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定（ハンドオーバ先候補を決定）し（ステップＳ２３０１）、その後、ＡＰのＬ２情報を基にして、ＭＮ１０がそのサブネットワークに移動した際に確立されるＱｏＳ経路上で、ＭＮ１０と隣り合うＱＮＥ（図１においてサブネット３０を移動先とした場合、経路３４上で最もＡＲ３１に近いＱＮＥ）を判定する（ステップＳ２３０２）。この判定は、前述の実施の形態で、ＭＮ１０がプロキシを決定する方法と同様の方法を利用することが可能である。
【０１２４】
ＭＮ１０は、ステップＳ２３０２で判定されたＱＮＥ（ＱＮＥ６８）の情報及び前述のように発見されたＣＲＮの情報をメッセージＡにセットする（ステップＳ２３０３）。ここでは、特に、ステップＳ２３０２で判定されたＱＮＥの情報の１つとして、ＱＮＥ６８の情報がメッセージＡにセットされた場合について記述する。なお、メッセージＡには、経路２４でのupstream用フロー識別子及びセッション識別子、downstream用フロー識別子及びセッション識別子、双方向通信であるという情報もセットされることが可能である。その後、ＭＮ１０はこのメッセージＡをＣＮ６０に送信する（ステップＳ２３０４）。ＣＮ６０は、ＭＮ１０から受け取ったメッセージＡに含まれるＣＲＮの情報などを基にＱｏＳ経路を確立するための処理に移る（ステップＳ２３０５）。
【０１２５】
なお、前述のＭＮ１０の機能で説明した通り、ＣＮ６０はＣＲＮの情報を集めた後に、ＭＮ１０にＣＲＮの情報を送る以外にも、様々な手段を取ることができる。また、ここでは、データが双方向通信であり、双方向のデータが同じ経路を通ると仮定したが、双方向のデータが違う経路を通る場合においても、前述する方法と同様の方法を用いることによって、双方向通信のそれぞれにおけるＣＲＮを決定することができる。
【０１２６】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２７】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１２８】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【０１２９】
なお、本明細書に記述されている送信先という表現、例えばＣＮ６０宛てに送信するという表現は、必ずしもＩＰヘッダの送信先アドレスにＣＮ６０のアドレスを指定して送信するという意味ではなく、最終的にメッセージを受け取る相手がＣＮ６０であるという意味である。
【産業上の利用可能性】
【０１３０】
本発明に係るクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムは、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるよう、ＣＲＮを素早く見つけ出すことを可能とさせるため、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムに関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出方法及びこの方法をコンピュータにより実行するためのクロスオーバノード検出用プログラムなどに有用である。
【図面の簡単な説明】
【０１３１】
【図１】本発明の実施の形態における通信システムの構成を示す模式図
【図２】本発明の実施の形態におけるＭＮの構成を示すブロック図
【図３】本発明の実施の形態におけるＭＮ内に格納されるプロキシ情報の一例を示す模式図
【図４】本発明の実施の形態におけるＭＮ内に格納されるＡＰ−ＡＲ対応情報の一例を示す模式図
【図５】本発明の実施の形態におけるＡＲの構成を示すブロック図
【図６】本発明の実施の形態における他のＡＲの構成を示すブロック図
【図７】本発明の実施の形態におけるＣＲＮの構成を示すブロック図
【図８】本発明の実施の形態におけるＭＮと移動履歴情報を有する装置との間で行われるＣＲＮの情報の抽出からプロキシへの送信までの動作の一例を示すシーケンスチャート
【図９】本発明の実施の形態におけるプロキシの構成を示すブロック図
【図１０】本発明の実施の形態におけるＱＮＥの構成を示すブロック図
【図１１】本発明の実施の形態におけるＣＮの構成を示すブロック図
【図１２】本発明の実施の形態において、プロキシ及びＣＮが送受信し合うメッセージに、どのようにＱＮＥによって処理された情報が格納されるかの一例を示す模式図
【図１３】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図１４】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図１５】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１６】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備に使われるメッセージとして、従来のＮＳＩＳで使われるＲＥＳＰＯＮＳＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１７】本発明の実施の形態において、別の処理方法を実現するプロキシの構成を示すブロック図
【図１８】本発明の実施の形態において、別の処理方法を実現するＣＮの構成を示すブロック図
【図１９】本発明の実施の形態における通信システムにおいて、プロキシがＣＲＮにＱｏＳ経路確立の依頼を行う際の動作の一例を示すシーケンスチャート
【図２０】本発明の実施の形態における通信システムにおいて、プロキシがＣＲＮにＱｏＳ経路確立の依頼を行う際の他の動作の一例を示すシーケンスチャート
【図２１】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す１枚目のシーケンスチャート
【図２２】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の動作の一例を示す２枚目のシーケンスチャート
【図２３】本発明の実施の形態における通信システムにおいて、ＭＮがプロキシにＱｏＳ経路の確立を準備する依頼をし、その準備が行われる際の他の動作の一例を示すシーケンスチャート
【図２４】本発明及び従来の技術に共通した無線通信システムの構成を示す模式図
【図２５】従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図
【図２６】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図２７】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図２８】従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図
【図２９】従来の技術におけるＮＳＩＳにおいて、どのように２重のリソース予約を回避するとされているかを説明するための模式図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006118188.tif 000032
【図２】
2006118188.tif 000033
【図３】
2006118188.tif 000034
【図４】
2006118188.tif 000035
【図５】
2006118188.tif 000036
【図６】
2006118188.tif 000037
【図７】
2006118188.tif 000038
【図８】
2006118188.tif 000039
【図９】
2006118188.tif 000040
【図１０】
2006118188.tif 000041
【図１１】
2006118188.tif 000042
【図１２】
2006118188.tif 000043
【図１３】
2006118188.tif 000044
【図１４】
2006118188.tif 000045
【図１５】
2006118188.tif 000046
【図１６】
2006118188.tif 000047
【図１７】
2006118188.tif 000048
【図１８】
2006118188.tif 000049
【図１９】
2006118188.tif 000050
【図２０】
2006118188.tif 000051
【図２１】
2006118188.tif 000052
【図２２】
2006118188.tif 000053
【図２３】
2006118188.tif 000054
【図２４】
2006118188.tif 000055
【図２５】
2006118188.tif 000056
【図２６】
2006118188.tif 000057
【図２７】
2006118188.tif 000058
【図２８】
2006118188.tif 000059
【図２９】
2006118188.tif 000060
【国際調査報告】
2006118188.tif 000061
2006118188.tif 000062
2006118188.tif 000063