(57)【特許請求の範囲】
【請求項１】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されている通信システムにおいて、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路を設定するための新規経路設定方法であって、
前記移動端末が前記第１のアクセスルータに接続された状態で、前記移動端末から前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージが送信され、前記メッセージが経由する前記第１のアクセスルータから、前記第２のアクセスルータ又はこれに隣接した所定のノードまでの経路と、前記第１の経路との重複状態に基づいて、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードが決定されるように構成されている新規経路設定方法。
【請求項２】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されている通信システムにおいて、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路を設定するための新規経路設定方法であって、
前記移動端末が、前記第１のアクセスルータに接続された状態で、前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージを送信するステップと、
前記メッセージを転送するネットワークノードの一部又は全部が、前記第１の経路の経由ポイントとなっているか否かを示す情報を前記メッセージに付加して、前記メッセージを転送するステップと、
前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記メッセージを受信し、前記ネットワークノードによって前記メッセージに付加された前記第１の経路の経由ポイントとなっているか否かを示す情報を参照することによって、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードを認識するステップとを、
有する新規経路設定方法。
【請求項３】
前記メッセージに含まれる前記第１の経路に係る情報が、前記第１の経路に係るフロー及び／又はセッションを識別するための情報であるように構成されている請求項２に記載の新規経路設定方法。
【請求項４】
前記ネットワークノードの一部又は全部は、前記第１の経路の経由ポイントとなっているか否かを示す情報を付加する際に、前記メッセージを最終的に受信する前記第２のアクセスルータ又はこれに隣接した所定のノードが前記メッセージを参照した場合に、最後に付加された前記第１の経路の経由ポイントとなっているか否かを示す情報が把握できるよう、前記第１の経路の経由ポイントとなっているか否かを示す情報を付加するように構成されている請求項２に記載の新規経路設定方法。
【請求項５】
前記ネットワークノードの一部又は全部が前記メッセージに付加する前記第１の経路の経由ポイントとなっているか否かを示す情報として、前記第１の経路に利用されている前記ネットワークノードのインタフェースアドレスを使用するように構成されている請求項２に記載の新規経路設定方法。
【請求項６】
前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記クロスオーバノードに対して、リソース予約を行うためのリソース予約用メッセージを送信するステップを有する請求項２に記載の新規経路設定方法。
【請求項７】
前記リソース予約用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記移動端末までの前記第１の経路の一部分における経路ステートを解放するための動作を開始するステップを有する請求項６に記載の新規経路設定方法。
【請求項８】
前記リソース予約用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記所定の通信相手端末までの前記第１の経路及び前記第２の経路の重複部分における経路ステータスを更新するための動作を開始するステップを有する請求項６に記載の新規経路設定方法。
【請求項９】
前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記クロスオーバノードに対して、リソース予約を依頼するためのリソース予約依頼用メッセージを送信するステップを有する請求項２に記載の新規経路設定方法。
【請求項１０】
前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記移動端末までの前記第１の経路の一部分における経路ステートを解放するための動作を開始するステップを有する請求項９に記載の新規経路設定方法。
【請求項１１】
前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記所定の通信相手端末までの前記第１の経路及び前記第２の経路の重複部分における経路ステータスを更新するための動作を開始するステップを有する請求項９に記載の新規経路設定方法。
【請求項１２】
前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記第２のアクセスルータ又はこれに隣接した所定のノードまでのリソースを予約するための動作を開始するステップを有する請求項９に記載の新規経路設定方法。
【請求項１３】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおける移動端末であって、
前記第２のアクセスルータ又はこれに隣接した所定のノードのアドレスを取得するアドレス取得手段と、
前記第１のアクセスルータに接続された状態で、前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージを送信するメッセージ送信手段とを、
有する移動端末。
【請求項１４】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおいて、前記移動端末が前記第１のアクセスルータに接続された状態で、前記移動端末から前記第２のアクセスルータ又はこれに隣接した所定のノードに対して送信される前記第１の経路に係る情報が含まれているメッセージを転送するネットワークノード内の経路管理装置であって、
前記メッセージを受信するメッセージ受信手段と、
前記ネットワークノードが前記第１の経路の経由ポイントとなっているか否かを把握し、前記ネットワークノードが前記第１の経路の経由ポイントとなっている場合には、前記第１の経路の経由ポイントとなっていることを示す情報を前記メッセージに付加する情報付加手段と、
前記メッセージを送信するメッセージ送信手段とを、
有する経路管理装置。
【請求項１５】
それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおいて、前記第１のアクセスルータに接続された状態の前記移動端末から、前記第１の経路に係る情報が含まれているメッセージであって、前記メッセージを転送するネットワークノードの一部又は全部において、前記ネットワークノードの一部又は全部が前記第１の経路の経由ポイントとなっているか否かを示す情報が前記メッセージに付加された前記メッセージを受信することが可能なネットワークノードにおける経路管理装置であって、
前記メッセージを受信するメッセージ受信手段と、
前記ネットワークノードによって前記メッセージに付加された前記第１の経路の経由ポイントとなっているか否かを示す情報を参照して、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードを決定するクロスオーバノード決定手段とを、
有する経路管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバの際に、モバイルノードが使用している経路（例えば、ＱｏＳ経路）の設定を行うための新規経路設定方法及び移動端末並びに経路管理装置に関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（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）が挙げられる（例えば、下記の非特許文献３参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末への経路（フロー）上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。
【００１３】
サブネット２０、３０間のハンドオーバを行うＭＮ１０に関しては、ハンドオーバ前に受けていたＱｏＳ保証を始めとする付加的サービスを、ハンドオーバ後においても継続して受けられるべきであるという要請があるが、上述したＲＳＶＰは、特に下記の点において上記の要請を満たすことができず、ＭＮ１０の移動に対応不可能である。図６は、従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図である。
【００１４】
ＲＳＶＰでは、ＭＮ１０の通信相手端末（ＣＮ：Correspondent Node）６０からＭＮ１０への２点間経路（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が各ＱＮＥで予約可能かどうかを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッセージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献５に記載されている。
【００２１】
また、ＱＵＥＲＹは、ＱｏＳリソースの入手可能性を調べるだけでなく、リソース予約を行う経路を前もって調べることにも使われる。すなわち、リソース予約を行う前に、データの送信側からデータの受信側に向けてＱＵＥＲＹメッセージを流すことにより、データが通り得る経路を特定することが可能となる。なお、リソース予約は、このＱＵＥＲＹによって特定された経路上のＱＮＥに対して行われることとなる。
【００２２】
しかしながら、実際のネットワークにおいては、データ経路がリソース予約を行った経路を外れることも考えられる。これを回避する方法については、現在ほとんど議論されていないが、例えば、下記の非特許文献８には、route pinningなどの、データが通る経路をあらかじめ固定しておく方法が、解決策の１つとして挙げられている。
【００２３】
次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、二重のリソース予約の回避方法を、図１０を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路１２４）が確立されているとき、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。この時のフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立するためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路１２４）は、ＭＮ１０の移動後すぐに解放されることはない。
【００２４】
前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路１２４におけるフロー識別子Ｘと、経路１３４におけるフロー識別子（この経路１３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインタフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここで２つのフロー識別子Ｘとフロー識別子Ｚとを比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、二重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（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.
【非特許文献４】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
【非特許文献９】三田貴子他、“モビリティをサポートしたシームレスなＱｏＳ経路確立方法に関する提案”、電子情報通信学会モバイルマルチメディア通信（ＭｏＭｕＣ）研究会、２００４年５月
【００２７】
図１０において、例えば、ハンドオーバ前に接続しているサブネット２０においてＱｏＳ保証を受けているＭＮ１０が、サブネット３０へのハンドオーバを行い、ハンドオーバ後に接続するサブネット３０において、ハンドオーバ前に受けていたＱｏＳ保証を継続して受けることを考えてみる。
【００２８】
この場合、ＭＮ１０がハンドオーバ前に接続しているサブネット２０とのハンドオフを行ってから、ハンドオーバ後に接続するサブネット３０において付加的サービス（ここではＱｏＳ保証）を受けた状態となるまでの時間は、ＭＮ１０がＱｏＳ保証を受けられない時間となり、ＭＮ１０はＱｏＳ保証を全く受けられないか、あるいは、デフォルトのＱｏＳ転送処理が行われてしまうこととなり、ＱｏＳの破綻が起きる。
【００２９】
したがって、上述のように、ハンドオーバ後のＭＮ１０に対しては、ＱｏＳ保証が迅速に提供される必要がある。このことを解決するため、ＩＥＴＦにおけるＮＳＩＳに関する現在の議論（例えば、非特許文献６）では、例えばＭＮ１０がハンドオーバを行う前、又は終える前に、新しいＱｏＳ経路を確立するための何らかの準備を行うこと、又は新しいＱｏＳ経路の確立を前もって行うことが必要である旨の提案がある。これに関し、例えば非特許文献９において、ＭＮ１０がハンドオーバを行う前に、移動先サブネット内若しくは近傍にあるプロキシが、ＣＮ６０とシグナリングメッセージを送受信することにより、あらかじめＱｏＳ経路確立のための準備を行う方法が示されている。しかしＭＮ１０が、離れた場所に存在するＣＮ６０と通信している場合、シグナリングメッセージのラウンドトリップが、スムーズなハンドオーバを妨げるということも考えられる。
【発明の開示】
【発明が解決しようとする課題】
【００３０】
本発明は、上記の問題点に鑑み、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることを可能とする新規経路設定方法及び移動端末並びに経路管理装置を提供することを目的とする。
【課題を解決するための手段】
【００３１】
上記目的を達成するために、本発明の新規経路設定方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されている通信システムにおいて、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路を設定するための新規経路設定方法であって、
前記移動端末が前記第１のアクセスルータに接続された状態で、前記移動端末から前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージが送信され、前記メッセージが経由する前記第１のアクセスルータから、前記第２のアクセスルータ又はこれに隣接した所定のノードまでの経路と、前記第１の経路との重複状態に基づいて、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードが決定されるように構成されている。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることが可能となる。
【００３２】
また、本発明の新規経路設定方法は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されている通信システムにおいて、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路を設定するための新規経路設定方法であって、
前記移動端末が、前記第１のアクセスルータに接続された状態で、前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージを送信するステップと、
前記メッセージを転送するネットワークノードの一部又は全部が、前記第１の経路の経由ポイントとなっているか否かを示す情報を前記メッセージに付加して、前記メッセージを転送するステップと、
前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記メッセージを受信し、前記ネットワークノードによって前記メッセージに付加された前記第１の経路の経由ポイントとなっているか否かを示す情報を参照することによって、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードを認識するステップとを有している。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることが可能となる。
【００３３】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記メッセージに含まれる前記第１の経路に係る情報が、前記第１の経路に係るフロー及び／又はセッションを識別するための情報であるように構成されている。
上記の構成により、例えば、ＱｏＳ保証されている経路を確実に特定することが可能となる。
【００３４】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記ネットワークノードの一部又は全部は、前記第１の経路の経由ポイントとなっているか否かを示す情報を付加する際に、前記メッセージを最終的に受信する前記第２のアクセスルータ又はこれに隣接した所定のノードが前記メッセージを参照した場合に、最後に付加された前記第１の経路の経由ポイントとなっているか否かを示す情報が把握できるよう、前記第１の経路の経由ポイントとなっているか否かを示す情報を付加するように構成されている。
上記の構成により、メッセージの最終的な受信者が、受信したメッセージを参照することによって、クロスオーバノードとして機能し得るネットワークノードを容易に特定することが可能となる。
【００３５】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記ネットワークノードの一部又は全部が前記メッセージに付加する前記第１の経路の経由ポイントとなっているか否かを示す情報として、前記第１の経路に利用されている前記ネットワークノードのインタフェースアドレスを使用するように構成されている。
上記の構成により、クロスオーバノードとして機能し得るネットワークノードが容易に特定可能となるとともに、そのネットワークノードのインタフェースアドレスを取得することが可能となる。
【００３６】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記クロスオーバノードに対して、リソース予約を行うためのリソース予約用メッセージを送信するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードまでの経路に係るリソース予約を行うとともに、このノードに対して、クロスオーバノードである旨を通知することも可能となる。
【００３７】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記リソース予約用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記移動端末までの前記第１の経路の一部分における経路ステートを解放するための動作を開始するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードが、その下流（移動端末側）の古い経路（移動端末がハンドオーバ前に使用していた経路）の設定を解放することが可能となる。
【００３８】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記リソース予約用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記所定の通信相手端末までの前記第１の経路及び前記第２の経路の重複部分における経路ステータスを更新するための動作を開始するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードが、その上流（通信相手端末側）における古い経路の経路ステータスを、新たな経路用に更新することが可能となる。
【００３９】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記第２のアクセスルータ又はこれに隣接した所定のノードが、前記クロスオーバノードに対して、リソース予約を依頼するためのリソース予約依頼用メッセージを送信するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードに対して、リソース予約を行うよう依頼することが可能となる。
【００４０】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記移動端末までの前記第１の経路の一部分における経路ステートを解放するための動作を開始するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードが、その下流（移動端末側）の古い経路（移動端末がハンドオーバ前に使用していた経路）の設定を解放することが可能となる。
【００４１】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記所定の通信相手端末までの前記第１の経路及び前記第２の経路の重複部分における経路ステータスを更新するための動作を開始するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードが、その上流（通信相手端末側）における古い経路の経路ステータスを、新たな経路用に更新することが可能となる。
【００４２】
また、本発明の新規経路設定方法は、上記の構成に加えて、前記リソース予約依頼用メッセージを受信した前記クロスオーバノードが、前記クロスオーバノードから前記第２のアクセスルータ又はこれに隣接した所定のノードまでのリソースを予約するための動作を開始するステップを有している。
上記の構成により、クロスオーバノードとして決定されたノードが、その下流（移動端末側）に新たな経路（移動端末がハンドオーバ後に使用可能な経路）を設定することが可能となる。
【００４３】
また、本発明の移動端末は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおける移動端末であって、
前記第２のアクセスルータ又はこれに隣接した所定のノードのアドレスを取得するアドレス取得手段と、
前記第１のアクセスルータに接続された状態で、前記第２のアクセスルータ又はこれに隣接した所定のノードに対して、前記第１の経路に係る情報が含まれているメッセージを送信するメッセージ送信手段とを有している。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることが可能となる。
【００４４】
また、本発明の経路管理装置は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおいて、前記移動端末が前記第１のアクセスルータに接続された状態で、前記移動端末から前記第２のアクセスルータ又はこれに隣接した所定のノードに対して送信される前記第１の経路に係る情報が含まれているメッセージを転送するネットワークノード内の経路管理装置であって、
前記メッセージを受信するメッセージ受信手段と、
前記ネットワークノードが前記第１の経路の経由ポイントとなっているか否かを把握し、前記ネットワークノードが前記第１の経路の経由ポイントとなっている場合には、前記第１の経路の経由ポイントとなっていることを示す情報を前記メッセージに付加する情報付加手段と、
前記メッセージを送信するメッセージ送信手段とを有している。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることが可能となる。
【００４５】
また、本発明の経路管理装置は、それぞれがサブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネットワークに接続されている所定の通信相手端末と、第１のアクセスルータに接続されている移動端末との間で設定されている第１の経路に基づいて、前記通信ネットワークに接続されている前記所定の通信相手端末と、前記第１のアクセスルータから第２のアクセスルータにハンドオーバを行って前記第２のアクセスルータに接続された状態となった前記移動端末との間の第２の経路が設定されるように構成されている通信システムにおいて、前記第１のアクセスルータに接続された状態の前記移動端末から、前記第１の経路に係る情報が含まれているメッセージであって、前記メッセージを転送するネットワークノードの一部又は全部において、前記ネットワークノードの一部又は全部が前記第１の経路の経由ポイントとなっているか否かを示す情報が前記メッセージに付加された前記メッセージを受信することが可能なネットワークノードにおける経路管理装置であって、
前記メッセージを受信するメッセージ受信手段と、
前記ネットワークノードによって前記メッセージに付加された前記第１の経路の経由ポイントとなっているか否かを示す情報を参照して、前記第１の経路から前記第２の経路に経路変更を行う際の、前記第１の経路及び第２の経路のクロスオーバノードを決定するクロスオーバノード決定手段とを有している。
上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることが可能となる。
【００４６】
本発明は、上記の構成により、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることを可能とするという効果を有する。
【発明を実施するための最良の形態】
【００４７】
以下、図面を参照しながら、本発明の実施の形態について説明する。図１は、本発明の実施の形態における通信システムの構成を示す模式図である。図１には、ＭＮ１０が、ハンドオーバ前にサブネット２０に接続されている状態において、ＣＮ６０との間で確立されているＱｏＳ経路（経路２４）が実線で図示されている。この経路２４上には、ＭＮ１０からＣＮ６０に向かって、ＡＲ２１、ＱＮＥ６２、ＱＮＥ６３、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。
【００４８】
また、後述の通り、ＭＮ１０がサブネット３０にハンドオーバすることを決めた後、ＭＮ１０はプロキシ（ＱＮＥ６８）に対してメッセージ（後述のメッセージＡ）を送信する。このメッセージＡの通過する経路（経路３４）が点線で図示されている。この経路３４上には、ＭＮ１０からＱＮＥ（プロキシ）６８に向かって、ＡＲ２１、ＱＮＥ６２、ＱＮＥ６３、ＱＮＥ６７が存在する。また、移動後の新しい経路（経路３５）は、図１において、太実線で図示されている。この経路３５上には、ＡＲ３１からＣＮ６０に向かって、ＱＮＥ（プロキシ）６８、ＱＮＥ６７、ＱＮＥ６３、ＮＥ６４、ＱＮＥ６５、ＱＮＥ６６が存在する。なお、ここで、ＭＮ１０とＣＮ６０との間で送受信されるデータは、あらかじめ用意されたＱｏＳ経路を正確に通るよう、経路が固定（route pinning）されているものとする。また、経路３５は、ハンドオーバ後にＡＲ３１に接続したＭＮ１０まで、任意の方法で延長されることによって、ＭＮ１０とＣＮ６０との間の経路に拡張されることが望ましい。
【００４９】
本発明では、例えば、ＭＮ１０がサブネット２０に接続した状態（ＭＮ１０のハンドオーバ前の状態）において、ＭＮ１０とＣＮ６０との間のＱｏＳ経路として使用されていた経路２４を、ＭＮ１０がサブネット３０にハンドオーバを行う旨を決定した直後に、使用され得る経路３５に、迅速に変更可能とするものである。
【００５０】
次に、ＭＮ１０の機能について説明する。図２は、本発明の実施の形態におけるＭＮの構成を示すブロック図である。なお、図２では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図１２、図１３に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。
【００５１】
図２に示すＭＮ１０は、ハンドオーバ先候補決定手段１０１、無線受信手段１０２、無線送信手段１０３、プロキシ決定手段１０４、メッセージ生成手段１０５、ＮＣｏＡ生成手段１０６を有している。また、ＭＮ１０は、プロキシ情報格納手段１０７を有してもよい。
【００５２】
ハンドオーバ先候補決定手段１０１は、例えば、異なる複数のＡＰからのシグナルを受信して、Ｌ２ハンドオーバ可能なＡＰ一覧を探す手段である。なお、ＭＮ１０は、ハンドオーバ先候補決定手段１０１によるＬ２ハンドオーバ先候補の決定を行うことなく、直接、後述のプロキシ決定手段１０４による処理を行うこともできる。また、無線受信手段１０２及び無線送信手段１０３は、それぞれ無線通信によるデータ受信及びデータ送信を行うための手段であり、これらには、無線通信を行うために必要な様々な機能が含まれている。
【００５３】
また、プロキシ決定手段１０４は、プロキシを発見する手段である。プロキシ決定手段１０４によって発見されるプロキシとは、ＭＮ１０の代理となって、ＭＮ１０がハンドオーバ後に付加的サービス（ここではＱｏＳとする）を寸断されることなく受けられるよう、あらかじめ準備することのできる、ＱｏＳ提供機能を持ったＮＳＩＳノード（ＱＮＥ）のことであり、ＭＮ１０がハンドオーバした際に張られる予定のＱｏＳ経路上に存在する。
【００５４】
このプロキシの発見を行うためには、複数の方法が考えられる。例えば、ハンドオーバ先候補決定手段１０１によって取得されたＡＰ一覧の情報を基に、ＭＮ１０内にローカルに蓄えられているプロキシ情報４０（プロキシ情報格納手段１０７に格納されているプロキシ情報４０）を参照し、ＡＰが接続されているサブネットワーク上で、ＣＮ６０と通信するために適したプロキシ情報４０を検索して決定する方法や、このＡＰ一覧の情報をＩＰネットワーク１５上に存在するサーバ（プロキシ検索サーバとする）などに送信し、前述の最も適したプロキシに係る情報を返してもらう方法、又は、プロキシ情報４０に蓄えられている、すべてのプロキシを選択する方法などが挙げられる。なお、ハンドオーバ先候補のＡＲそのものがＱＮＥであり、プロキシになる場合もあり得る。また、本発明において利用可能なプロキシの発見方法は、上述のものに限定されず、他のプロキシの発見方法を利用することも可能である。
【００５５】
図１１には、プロキシ情報４０の内容の一例が図示されている。なお、図１１に示すプロキシ情報４０は、図５におけるネットワーク構成を参照して作成された一例である。図１１に示すプロキシ情報４０は、ＭＮ１０が各ＡＰと接続されている場合において、プロキシとして選択可能なノードのＩＰアドレスを有しており、ＭＮ１０は、このプロキシ情報４０を参照することによって、プロキシの選択及び特定を行うことが可能となる。なお、プロキシとしては、各ＡＰを配下に有するＡＲの近く（ネットワーク構成上のＡＲ近傍）に存在するＱＮＥが設定されることが望ましい。
【００５６】
また、メッセージ生成手段１０５は、プロキシにおいて、ＭＮ１０がハンドオーバ後にＱｏＳを寸断されることなく受けられるよう、あらかじめ準備するために必要な情報、例えば、現在使用されているセッション識別子の情報や、データの流れの方向（ＭＮ１０からＣＮ６０（アップリンク：uplink）方向か、ＣＮ６０からＭＮ１０（ダウンリンク：downlink）方向か）などを含むメッセージを生成するための手段である。なお、さらにこのメッセージに、フロー識別子を挿入することも可能である。また、このメッセージは、現在隣り合っているＱＮＥ（ＱＮＥ６２）を必ず通って送信されるよう生成される。なお、メッセージ生成手段１０５によって生成される上記のメッセージをメッセージＡとする。また、このメッセージＡとして、例えば、後述のように、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているＱＵＥＲＹメッセージを拡張して利用することが可能である。
【００５７】
また、ＭＮ１０は移動先を特定して、そこで使用するＮＣｏＡを生成し、それを移動先のプロキシに送ることも可能である。このＮＣｏＡを生成するための手段がＮＣｏＡ生成手段１０６であり、生成されたＮＣｏＡはメッセージ生成手段１０５において、フロー識別子などと共にメッセージＡ内に格納された状態で送られてもよい。ＮＣｏＡ生成方法については、例えば、ＭＮ１０が図１４（図１１と同様に、図５を参照して作成された一例）に示すようなＡＰ−ＡＲ対応情報４１をローカルに持ち、ハンドオーバ先候補決定手段１０１によって得られたＡＰの情報を基にして、このＡＰ−ＡＲ対応情報４１を検索し、ＡＰがつながっている先のＡＲの情報（例えば、ＡＲのリンクレイヤアドレス、ＡＲの属するサブネットのネットワークプリフィックスやプリフィックスレングスなど）を得ることにより、ＮＣｏＡをステートレスに自動生成する方法が考えられる。
【００５８】
ただし、この場合には、ＮＣｏＡはステートレスに自動生成されたものであるため、実際に、このＮＣｏＡがハンドオーバ先のサブネットで使用可能なものであるかどうかを確認する手段が必要となることがある。このような場合には、例えばハンドオーバ先として、ＡＲそのものがプロキシとなることのできるサブネットを選び、このＡＲにＮＣｏＡを含んだメッセージＡを送ることにより、このプロキシ機能を持ったＡＲに、ＮＣｏＡの妥当性を調べてもらうようにすればよい。また、他のＮＣｏＡ獲得方法として、現在通信中のＡＲ（ハンドオーバ前のサブネット２０に属するＡＲ２１）が、近隣のサブネットワークのＤＨＣＰサーバより、使用可能なＣｏＡの一部をあらかじめ受け取り、ＭＮ１０が別のＡＲ（ハンドオーバ後のサブネット３０に属するＡＲ３１）に移動を行う前に、そのサブネットのＤＨＣＰサーバからもらったＣｏＡのうちの１つをＭＮ１０に割り当てる方法も可能である。なお、この場合には、ＣｏＡはステートフルに割り当てられるので、ＣｏＡに係る妥当性のチェックが行われる必要はなく、前述のように、プロキシ機能を持ったＡＲを選ぶという制限はなくなる。また、メッセージＡには、これ以外の情報も含めることができる。
【００５９】
次に、ＭＮ１０からメッセージＡを受け取るプロキシ（ＱＮＥ６８）の機能について説明する。なお、ここで、ＭＮ１０はプロキシの１つとして、図１中のＱＮＥ６８を選んだ場合を考える。図３は、本発明の実施の形態におけるプロキシの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図３に示すプロキシ６８が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図１２、図１３に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。
【００６０】
図３に示すプロキシ６８は、受信手段６８１、送信手段６８２、メッセージ処理手段６８３、メッセージ生成手段６８４、６８５を有している。また、プロキシ６８は、経路情報格納手段６８６を有してもよい。
【００６１】
受信手段６８１及び送信手段６８２は、データ受信及びデータ送信を行うための手段である。また、メッセージ処理手段６８３は、図２に示すＭＮ１０のメッセージ生成手段１０５で生成され、無線送信手段１０３で送信されたメッセージ（メッセージＡ）を受信、処理するための手段である。例えば、メッセージＡ中に含まれるデータの流れの情報を確認し、どのような形でＱｏＳ経路を確立するのが望ましいかを判断する。なお、この判断の結果により、メッセージ生成手段６８４及びメッセージ生成手段６８５のどちらに対して、メッセージの生成指示を行うかが定められる。
【００６２】
また、メッセージＡには、ＭＮ１０から当該プロキシ６８に到達するまでに通過したＱＮＥ（例えば、経路３４上のＱＮＥ）によって情報が付加されるが、メッセージ処理手段６８３は、このメッセージＡに付加された情報に基づいて、経路２４と経路３４とが枝分かれになるポイントのＱＮＥ（仮クロスオーバノード）を特定することが可能である。なお、仮クロスオーバノードは、経路２４と経路３４との枝分かれになるポイントに過ぎず、必ずしも、新たに設定されることになる経路３５を最適な経路とするための経由ポイント（最適クロスオーバノード）と一致するものではない。このことから、本明細書で探索されるクロスオーバノードを、最適な経路３５を実現する最適クロスオーバノードに対して、あくまでも迅速な経路変更の実現を可能とする仮クロスオーバノードと呼ぶことにする。この特定されたＱＮＥが、この仮クロスオーバノード（ここではＱＮＥ６３）の情報を基に、プロキシ６８は、ＭＮ１０のハンドオーバ後のＱｏＳ経路を迅速に確立するための処理を行うことが可能である。この処理を行うには、複数の方法が考えられる。例えば、この情報を経路情報格納手段６８６に渡し、ＭＮ１０がハンドオーバしてきた時点で、ＱｏＳ経路の設定に係る任意の処理を行ってもよく、また、ＭＮ１０のＮＣｏＡの情報があらかじめ取得できていた場合（例えば、メッセージＡの受信とほぼ同時にＮＣｏＡの情報を取得できる場合など）には、情報を経路情報格納手段６８６に渡すことなく、直ちにリソース予約の処理を行ってもよい。
【００６３】
また、メッセージ生成手段６８４は、リソース予約のためのメッセージ（以下、メッセージＢと呼ぶ）を生成する。なお、このメッセージＢとして、例えば、後述のように、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているＲＥＳＥＲＶＥメッセージを拡張して利用することが可能である。ＭＮ１０のＮＣｏＡの情報を受け取った後、メッセージ生成手段６８４では、リソース予約のためのメッセージＢが生成され、メッセージＡに付加された情報に基づいて特定される仮クロスオーバノード（ＱＮＥ６３）に対して、メッセージＢが送信される。このメッセージＢには、ＭＮ１０がハンドオーバ時に寸断なしにＱｏＳサービスを受けるために必要な情報、例えば、ＭＮ１０がハンドオーバ前に使っていたセッション識別子や、ＭＮ１０のＮＣｏＡを基に作られたフロー識別子の情報などが含まれるようにすることが可能である。また、メッセージＢには、メッセージＢがＱＮＥ６３に到着した際、ＱＮＥ６３がＣＮ６０に向けて経路２４を更新するメッセージ（後述のメッセージＤ）を送り、新しい経路（経路３５）の一部とするための指示や、ＱＮＥ６３が経路２４と経路３４との重複部分（図１のＱＮＥ６３〜ＱＮＥ６２〜ＡＲ２１の部分）の経路を解放するメッセージ（後述のメッセージＥ）を送るための指示が含まれるようにしてもよい。
【００６４】
また、メッセージ生成手段６８５は、プロキシ６８がＭＮ１０のＮＣｏＡの情報を受け取った後に、仮クロスオーバノード（ＱＮＥ６３）から、ＱＮＥ６８に向かってリソース予約を行う依頼をするためのメッセージ（メッセージＣ）を生成する。なお、このメッセージＣとして、例えば、ＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているＱＵＥＲＹメッセージを拡張して利用することが可能である。上述のメッセージＢと同様に、このメッセージＣにも、ＭＮ１０がハンドオーバ時に寸断なしにＱｏＳサービスを受けるために必要な情報、例えばＭＮ１０がハンドオーバ前に使っていたセッション識別子や、ＭＮ１０のＮＣｏＡを基に作られたフロー識別子の情報などが含まれるようにすることが可能である。
【００６５】
また、メッセージＣには、メッセージＣがＱＮＥ６３に到着した際、ＱＮＥ６３がＣＮ６０に向けて経路２４を更新するメッセージ（後述のメッセージＤ）を送り、新しい経路（経路３５）の一部とするための指示や、ＱＮＥ６３が経路２４と経路３４との重複部分（ＱＮＥ６３〜ＱＮＥ６２〜ＡＲ２１）の経路を解放するメッセージ（後述のメッセージＥ）を送るための指示が含まれるようにしてもよい。
【００６６】
以上のように、プロキシとして機能するＱＮＥ６８は、ＭＮ１０からメッセージＡを受信し、そのメッセージＡの内容に応じて、メッセージ生成手段６８４によるメッセージＢ（リソース予約を行うためのメッセージ）の生成処理、又は、メッセージ生成手段６８５によるメッセージＣ（リソース予約を行う依頼を行うためのメッセージ）の生成処理を行うように構成されている。
【００６７】
次に、経路３４上の中間のＱＮＥの機能について、ＱＮＥ６３を例に取って説明する。図４は、本発明の実施の形態における経路３４上のＱＮＥの構成を示すブロック図である。なお、図２に示すＭＮ１０と同様に、図４に示すＱＮＥ６３が有する各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図１２、図１３に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。
【００６８】
図４に示すＱＮＥ６３は、受信手段６３１、送信手段６３２、メッセージ処理手段６３３、６３４、６３５、メッセージ生成手段６３６、６３７、６３８、６３９を有している。受信手段６３１、送信手段６３２は、図３に示すプロキシ６８の受信手段６８１、送信手段６８２と同じ機能を有している。
【００６９】
メッセージ処理手段６３３は、前述のメッセージＡを受け取った際、その中に含まれているセッション識別子に対し、ＱＮＥ６３内にリソース予約が存在しているかどうかを調べる手段である。メッセージＡに含まれるセッション識別子に係るリソース予約が無かった場合は、メッセージ処理手段６３３では何も行われずに、送信手段６３２を経由して次のＱＮＥにメッセージＡが転送される。一方、リソース予約があった場合は、メッセージ生成手段６３６において、そのインタフェースのＩＰアドレスが、受信したメッセージＡ内に格納され、メッセージ生成手段６３６で生成された新たなメッセージＡ（インタフェースのＩＰアドレスが格納されたメッセージＡ）が、送信手段６３２を経由して次のＱＮＥ（ＱＮＥ６３の場合には、ＱＮＥ６７）に送信される。なお、既に前段のＱＮＥにおいてインタフェースのＩＰアドレスがメッセージＡに付加されている場合には、その前段のＱＮＥのインタフェースのＩＰアドレスに上書きする方法で、新たに自身のインタフェースのＩＰアドレスを付加してもよく、また、付加順序を明確にして、前段のＱＮＥのインタフェースのＩＰアドレスを残しながら、自身のインタフェースのＩＰアドレスを付加してもよい。
【００７０】
また、メッセージ処理手段６３４は、前述のメッセージＢを受け取った際、ＣＮ６０に向けて経路２４を更新するメッセージ（メッセージＤ）を送るか、又は経路２４と経路３４との重複部分（ＱＮＥ６３〜ＱＮＥ６２〜ＡＲ２１）の経路を解放するメッセージ（メッセージＥ）を送るかの判断を行う。この判断には、このメッセージをいつ送信するかということも含まれ得る。なお、この判断は、メッセージＢに含まれる指示に基づいて行ってもよいし、メッセージ処理手段６３４内で判断してもよい。また、メッセージＤは、メッセージ生成手段６３７で生成され、メッセージＥは、メッセージ生成手段６３８で生成される。なお、このメッセージＤやメッセージＥとして、例えば、後述のように、ＱｏＳ ＮＳＬＰで定義されているＲＥＳＥＲＶＥメッセージを拡張して利用することが可能である。
【００７１】
また、メッセージ処理手段６３５は、前述のメッセージＣを受け取った際、このメッセージＣに含まれる情報をメッセージ生成手段６３９に渡す。メッセージ生成手段６３９は、前述のメッセージＢ（リソース予約を行うためのメッセージ）を生成することが可能であり、このメッセージＢは、送信手段６３２を経由してＱＮＥ６８に向けて送信される。なお、メッセージＣに含まれる指示内容によっては、生成されたメッセージＢは、移動したＭＮ１０あてに送られてもよい。
【００７２】
さらに、メッセージ処理手段６３５は、ＣＮ６０に向けて経路２４を更新するメッセージ（メッセージＤ）を送るか、又は経路２４と経路３４との重複部分（ＱＮＥ６３〜ＱＮＥ６２〜ＡＲ２１）の経路を解放するメッセージ（メッセージＥ）を送るかの判断を行うことも可能である。この判断には、このメッセージをいつ送信するかということも含まれ得る。なお、この判断は、メッセージＢに含まれる指示に基づいて行ってもよいし、メッセージ処理手段６３５内で判断してもよい。また、メッセージＤは、メッセージ生成手段６３７で生成され、メッセージＥは、メッセージ生成手段６３８で生成される。
【００７３】
次に、ＭＮ１０がハンドオーバする際、ＭＮ１０からＱＮＥ６８に仮クロスオーバノードを特定するためのメッセージＡを送ることによって、ＱＮＥ６８が仮クロスオーバノードを特定できるようにし、さらに、この仮クロスオーバノードを経由するＱｏＳ経路を張るまでの動作について説明する。図１２には、本発明の実施の形態において、ＭＮ１０がプロキシ６８に識別子（セッション識別子）の情報を送り、プロキシ６８が仮クロスオーバノード（ＱＮＥ６３）を特定し、仮クロスオーバノード経由でダウンリンク用の新しいＱｏＳ経路を確立する動作例を示すシーケンスチャートが図示されている。また、図１３には、本発明の実施の形態において、ＭＮ１０がプロキシ６８に識別子（セッション識別子）の情報を送り、プロキシ６８が仮クロスオーバノード（ＱＮＥ６３）を特定し、仮クロスオーバノード経由でアップリンク用の新しいＱｏＳ経路を確立する動作例を示すシーケンスチャートが図示されている。なお、図１２及び図１３に示すシーケンスチャートは、図１に示すネットワークシステムにおいて、ＭＮ１０によって、プロキシ６８がプロキシとして選ばれている場合のものである。
【００７４】
また、ここでは、前述のメッセージＡ、メッセージＢ、メッセージＣ、メッセージＤ、メッセージＥの具体例として、それぞれＮＳＩＳのＱｏＳ ＮＳＬＰで定義されているメッセージである、ＱＵＥＲＹメッセージやＲＥＳＥＲＶＥメッセージを使用する場合について説明する。なお、メッセージＡはＱＵＥＲＹメッセージ、メッセージＢはＲＥＳＥＲＶＥメッセージ（リソース予約用）、メッセージＣはＱＵＥＲＹメッセージ、メッセージＤにはＲＥＳＥＲＶＥメッセージ（経路ステータス更新用）、メッセージＥはＲＥＳＥＲＶＥメッセージ（経路ステート解放用）にそれぞれ対応している。
【００７５】
まず、ダウンリンク方向の新しいＱｏＳ経路を確立する動作について、図１２を参照しながら説明する。近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ５０１：ハンドオーバ先候補を決定）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ５０３：ＱＮＥ６８をプロキシの１つ（プロキシ６８）として決定）。プロキシを決定したＭＮ１０は、経路２４でのdownlink用セッション識別子をＱＵＥＲＹメッセージにセットするとともに、downlinkであるという情報もＱＵＥＲＹメッセージにセットして（ステップＳ５０５：経路２４でのセッション識別子、及びデータの流れ方向をセット）、選んだプロキシ（ここではＱＮＥ６８）にＱＵＥＲＹメッセージを送信する（ステップＳ５０７）。
【００７６】
経路３４に属するＱＮＥであるＱＮＥ６２は、ステップＳ５０７で送られたＱＵＥＲＹメッセージをいったん受け取り、このステップＳ５０５でセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６２内に存在するか否かを調べる。そして、このセッション識別子に対するリソースの予約が存在する場合には、ＱＮＥ６２は、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加し（ステップＳ５０９：セッション識別子に対する登録のあるインタフェースアドレスをパラメータとして追加）、さらに、通常のＱＵＥＲＹ処理を行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５１１）。なお、ここでは、前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６２内に存在するものとしているが、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６２内に存在しない場合には、ＱＮＥ６２は、通常のＱＵＥＲＹ処理のみを行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信することになる。
【００７７】
経路３４に属する次のＱＮＥであるＱＮＥ６３は、同様にステップＳ５１１で送られたＱＵＥＲＹメッセージをいったん受け取り、ステップＳ５０５でＱＵＥＲＹメッセージ内にセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６３内に存在するか否かを調べる。そして、セッション識別子に対するリソースの予約が存在する場合には、ＱＮＥ６３は、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加し（ステップＳ５１３：セッション識別子に対する登録のあるインタフェースアドレスをパラメータとして追加）、さらに、通常のＱＵＥＲＹ処理を行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５１５）。なお、上述のＱＮＥ６２の場合と同様に、前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６３内に存在するものとしているが、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６３内に存在しない場合には、ＱＮＥ６３は、通常のＱＵＥＲＹ処理のみを行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信することになる。
【００７８】
経路３４に属する次のＱＮＥであるＱＮＥ６７は、同様にステップＳ５１５で送られたＱＵＥＲＹメッセージをいったん受け取り、ステップＳ５０５でＱＵＥＲＹメッセージ内にセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６７内に存在するか否かを調べる。前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６７内に存在しないので、ＱＮＥ６７は、通常のＱＵＥＲＹ処理のみを行い、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５１７）。なお、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６７内に存在する場合には、ＱＮＥ６７は、通常のＱＵＥＲＹ処理と共に、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加する処理を行うことになる。
【００７９】
ＱＮＥ（プロキシ）６８は、ＭＮ１０から経路３４上のＱＮＥ６２、６３、６７を通して受け取ったＱＵＥＲＹメッセージ内の情報から、仮クロスオーバノードを特定する（ステップＳ５１９：仮クロスオーバノード（ＱＮＥ６３）の特定）。例えば、ＱＮＥ６８は、このＱＵＥＲＹメッセージ内に追加されたＱＮＥ６２、６３のインタフェースのアドレスを参照して、最も新しく（すなわち、最後に）インタフェースのアドレスを追加したＱＮＥ（ここでは、ＱＮＥ６３）が、経路２４と経路３４との枝分かれとなるＱＮＥであり、すなわち、仮クロスオーバノードとなり得ることを把握することができる。なお、ＱＮＥ６３は、このＱＵＥＲＹメッセージに係る転送処理を行うためにルーティングテーブルなどを参照した際に、経路２４と経路３４とが異なるリンクに向かうことを把握できる場合もあり、また隣り合うＱＮＥのステートを参照することによって、次にＱＵＥＲＹメッセージを受け取る隣のＱＮＥがＱＮＥ６５からＱＮＥ６７に変わったことが把握できる場合もある。この場合には、その時点で、ＱＮＥ６３自身が、自分が経路２４と経路３４との枝分かれとなるＱＮＥであることを把握することも可能となる。
【００８０】
さらに、ＱＮＥ６８は、ＭＮ１０のＮＣｏＡの情報を取得すると（ステップＳ５２１：ＭＮの新規ＩＰアドレス情報取得）、ＱＮＥ６８からＱＮＥ６３に向けて経路３５（ＱＮＥ６３とＱＮＥ６８との間の経路３４と同一経路）上に新規リソース予約を行うためのＲＥＳＥＲＶＥメッセージ（リソース予約用のＲＥＳＥＲＶＥメッセージ：図１２ではＲＥＳＥＲＶＥと記載）を生成し、ＱＮＥ６３に向けて送信する（ステップＳ５２３）。なお、ステップＳ５２１においてＱＮＥ６８が取得するＭＮ１０のＮＣｏＡの情報は、例えば、ＱＮＥ６８が受信したＱＵＥＲＹメッセージに含まれている場合もあるし、ＭＮ１０がＡＲ３１配下のネットワークに移動して、ＮＣｏＡを取得した際にＱＮＥ６８に通知される場合も考えられる。
【００８１】
経路３５に属するＱＮＥであるＱＮＥ６７は、ステップＳ５２３で送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ処理を行って、このＲＥＳＥＲＶＥメッセージを送信先（ＱＮＥ６３）に向けて送信する（ステップＳ５２５）。
【００８２】
ＱＮＥ６３は、ＱＮＥ６８より送られたＲＥＳＥＲＶＥメッセージを受け取ることにより、例えば、このＲＥＳＥＲＶＥメッセージの終点アドレスに自身（ＱＮＥ６３）のアドレスが設定されていることを参照して、自分が仮クロスオーバノードであるということを認識し（ステップＳ５２７：仮クロスオーバノードであることを認識）、ＣＮ６０に向けて、経路２４のステート情報を経路３５のステート情報に変更するための更新を指示するＲＥＳＥＲＶＥメッセージ（経路ステータス更新用のＲＥＳＥＲＶＥメッセージ）を送信する（ステップＳ５２９）。なお、経路２４の一部（ＱＮＥ６３とＣＮ６０との間の経路）と、経路３５の一部（ＱＮＥ６３とＣＮ６０との間の経路）とは、同一であることが望ましい。なお、上述の終点アドレスを参照する方法以外に、例えば、ＱＮＥ６８より送られたＲＥＳＥＲＶＥメッセージに、ＱＮＥ６３が仮クロスオーバノードであるという情報が明示的に含まれるようにすることによって、ＱＮＥ６８が、自分がクロスオーバノードであることを認識できるようにすることも可能である。さらに、このＲＥＳＥＲＥＶＥメッセージには、仮クロスオーバノードが、その後どのような処理を行うのか（例えば、ＣＮ６０方向に、経路２４に沿った更新を行うためのＲＥＳＥＲＶＥをかけに行く処理など）の指示が含まれるようにすることも可能である。
【００８３】
経路２４に属するＱＮＥであるＱＮＥ６５は、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（update）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＣＮ６０）に向けて送信する（ステップＳ５３１）。
【００８４】
経路２４に属するＱＮＥであるＱＮＥ６６は、ＱＮＥ６５同様、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（update）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＣＮ６０）に向けて送信する（ステップＳ５３３）。このＲＥＳＥＲＥＶＥメッセージがＣＮ６０に届くことにより、ＱＮＥ６３とＣＮ６０との間の経路２４に係るステート情報は、ＱＮＥ６３とＣＮ６０との間の経路３５に係るステート情報に更新されて、経路３５に対するリソース予約が完了する。なお、この後にＣＮ６０からＭＮ１０に向けて送られるデータは、経路３５を正確に通るよう、route pinningされて送信されることが望ましい。
【００８５】
また、ＱＮＥ６３は、ステップＳ５２７においてＲＥＳＥＲＶＥメッセージを送信すると同時か、又はしばらく後に、古い経路（経路２４と経路３４の重複部分）に対して、ステートの解放を行うために、経路ステート解放用のＲＥＳＥＲＶＥメッセージ（図１２ではＲＥＳＥＲＶＥ（release）と記載）をＭＮ１０の古いＣｏＡに向けて送信する（ステップＳ５３５）ことも可能であり、これによって、ＭＮ１０の移動に伴って不要となったリソース予約を迅速に解放することが可能となる。
【００８６】
このとき、経路２４と経路３４の重複部分に属するＱＮＥであるＱＮＥ６２は、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（release）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＭＮ１０の古いＣｏＡ）に対して送信する（ステップＳ５３７）。ただし、ＱＮＥ６２が、ＭＮ１０が移動したということを既に知っていた場合には、ステートの解放処理だけを行い、ＲＥＳＥＲＶＥメッセージの送信（ステップＳ５３７）は行わないようにすることも可能である。
【００８７】
次に、アップリンク方向の新しいＱｏＳ経路を確立する動作について、図１３を参照しながら説明する。なお、以下の説明には、上述のダウンリンクの場合と同一のＱＮＥや経路が用いられるが、経路がダウンリンクとは異なる場合にも、同様の手段により同様の結論が得られる。
【００８８】
ステップＳ５５１からステップＳ５７１までの処理に関しては、図１２のステップＳ５０１からステップＳ５２１とそれぞれ同様である。すなわち、近隣のＬ２シグナル到達可能なＡＰからＬ２情報を受け取ったＭＮ１０は、まず、その情報に基づいて、ハンドオーバを行うことのできるサブネットワークを決定し（ステップＳ５５１：ハンドオーバ先候補を決定）、その後、ＡＰのＬ２情報を基にしてハンドオーバ候補先のプロキシを決定する（ステップＳ５５３：ＱＮＥ６８をプロキシの１つ（プロキシ６８）として決定）。プロキシを決定したＭＮ１０は、経路２４でのuplink用セッション識別子をＱＵＥＲＹメッセージにセットするとともに、uplinkであるという情報もＱＵＥＲＹメッセージにセットして（ステップＳ５５５：経路２４でのセッション識別子、及びデータの流れ方向をセット）、選んだプロキシ（ここではＱＮＥ６８）にＱＵＥＲＹメッセージを送信する（ステップＳ５５７）。
【００８９】
経路３４に属するＱＮＥであるＱＮＥ６２は、ステップＳ５５７で送られたＱＵＥＲＹメッセージをいったん受け取り、ステップＳ５５５でＱＵＥＲＹメッセージ内にセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６２内に存在するか否かを調べる。そして、セッション識別子に対するリソースの予約が存在する場合には、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加し（ステップＳ５５９：セッション識別子に対する登録のあるインタフェースアドレスをパラメータとして追加）、さらに、通常のＱＵＥＲＹ処理を行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５６１）。なお、前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６２内に存在するものとしているが、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６２内に存在しない場合には、ＱＮＥ６２は、通常のＱＵＥＲＹ処理のみを行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信することになる。
【００９０】
経路３４に属する次のＱＮＥであるＱＮＥ６３は、同様にステップＳ５６１で送られたＱＵＥＲＹメッセージをいったん受け取り、ステップＳ５５５でＱＵＥＲＹメッセージ内にセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６３内に存在するか否かを調べる。そして、セッション識別子に対するリソースの予約が存在する場合には、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加し（ステップＳ５６３：セッション識別子に対する登録のあるインタフェースアドレスをパラメータとして追加）、さらに、通常のＱＵＥＲＹ処理を行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５６５）。なお、上述のＱＮＥ６２の場合と同様に、前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６３内に存在するものとしているが、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６３内に存在しない場合には、ＱＮＥ６３は、通常のＱＵＥＲＹ処理のみを行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信することになる。
【００９１】
経路３４に属する次のＱＮＥであるＱＮＥ６７は、同様にステップＳ５６５で送られたＱＵＥＲＹメッセージをいったん受け取り、ステップＳ５５５でＱＵＥＲＹメッセージ内にセットされたセッション識別子に対するリソースの予約が現在ＱＮＥ６７内に存在するか否かを調べる。前提とするネットワーク構成（図１参照）において、このセッション識別子に対するリソースの予約がＱＮＥ６７内に存在しないので、通常のＱＵＥＲＹ処理のみを行い、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５６７）。なお、仮に、このセッション識別子に対するリソースの予約がＱＮＥ６７内に存在する場合には、ＱＮＥ６７は、通常のＱＵＥＲＹ処理と共に、その予約が存在するインタフェースのアドレスを、このＱＵＥＲＹメッセージに追加する処理を行うことになる。
【００９２】
ＱＮＥ（プロキシ）６８では、上述のダウンリンク方向の新しいＱｏＳ経路を確立する場合と同様に、ＭＮ１０から経路３４上のＱＮＥ６２、６３、６７を通して受け取ったＱＵＥＲＹメッセージ内の情報から、仮クロスオーバノードを特定する（ステップＳ５６９：仮クロスオーバノード（ＱＮＥ６３）の特定）。そして、ＱＮＥ６８は、ＭＮ１０のＮＣｏＡの情報を取得すると（ステップＳ５７１：ＭＮの新規ＩＰアドレス情報取得）、ＱＮＥ６３からＱＮＥ６８に向けて経路３５（ＱＮＥ６３とＱＮＥ６８との間の経路３４と同一経路）上に新規リソース予約を行うためのＲＥＳＥＲＶＥメッセージ（リソース予約用のＲＥＳＥＲＶＥメッセージ：図１３ではＲＥＳＥＲＶＥ（update）と記載）の送信を依頼するためにＱＵＥＲＹメッセージを生成し、ＱＮＥ６３に向けて送信する（ステップＳ５７３）。なお、ステップＳ５７１においてＱＮＥ６８が取得するＭＮ１０のＮＣｏＡの情報は、例えば、ＱＮＥ６８が受信したＱＵＥＲＹメッセージに含まれている場合もあるし、ＭＮ１０がＡＲ３１配下のネットワークに移動して、ＮＣｏＡを取得した際にＱＮＥ６８に通知される場合も考えられる。
【００９３】
経路３５に属するＱＮＥであるＱＮＥ６７は、ステップＳ５７３で送られたＱＵＥＲＹメッセージをいったん受け取り、通常のＱＵＥＲＹ処理を行って、このＱＵＥＲＹメッセージを送信先（ＱＮＥ６３）に向けて送信する（ステップＳ５７５）。
【００９４】
ＱＮＥ６３は、ＱＮＥ６８より送られたＱＵＥＲＹメッセージを受け取ることにより、自分が仮クロスオーバノードであるということを認識し（ステップＳ５７７：仮クロスオーバノードであることを認識）、ＣＮ６０に向けて、経路２４のステート情報を経路３５のステート情報に変更するための更新を指示するＲＥＳＥＲＶＥメッセージ（経路ステータス更新用のＲＥＳＥＲＶＥメッセージ）を送信する（ステップＳ５７９）。なお、経路２４の一部（ＱＮＥ６３とＣＮ６０との間の経路）と、経路３５の一部（ＱＮＥ６３とＣＮ６０との間の経路）とは、同一であることが望ましい。
【００９５】
経路２４に属するＱＮＥであるＱＮＥ６５は、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（update）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＣＮ６０）に向けて送信する（ステップＳ５８１）。
【００９６】
経路２４に属するＱＮＥであるＱＮＥ６６は、ＱＮＥ６５同様、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（update）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＣＮ６０）に向けて送信する（ステップＳ５８３）。このＲＥＳＥＲＥＶＥメッセージがＣＮ６０に届くことにより、ＱＮＥ６３とＣＮ６０との間の経路２４に係るステート情報は、ＱＮＥ６３とＣＮ６０との間の経路３５に係るステート情報に更新されて、経路３５に対するリソース予約が完了する。なお、この後にＣＮ６０からＭＮ１０に向けて送られるデータは、経路３５を正確に通るよう、route pinningされて送信されることが望ましい。
【００９７】
また、ＱＮＥ６３は、ステップＳ５７９においてＲＥＳＥＲＶＥメッセージを送信すると同時に、ＱＮＥ６８に向けて経路３４上にＱｏＳリソースを予約するためのＲＥＳＥＲＶＥメッセージを作成し、このＲＥＳＥＲＶＥメッセージ（図１３ではＲＥＳＥＲＶＥ（update）と記載）をＱＮＥ６８に向けて送信することが可能である（ステップＳ５８５）。なお、既にＭＮ１０がＡＲ３１配下に移動していた場合には、ＭＮ１０に向けて送信することも可能である。
【００９８】
このとき、経路３５に属するＱＮＥであるＱＮＥ６７は、ステップＳ５８５で送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＱＮＥ６８）に向けて送信する（ステップＳ５８７）。このＲＥＳＥＲＥＶＥメッセージがＱＮＥ６８に届くことにより、経路３５に対する、リソース予約が完了する。この後にＭＮ１０からＣＮ６０に向けて送られるデータは、経路３５を正確に通るよう、route pinningされて送信される。
【００９９】
また、ＱＮＥ６３は、ステップＳ５７９やステップＳ５８５のＲＥＳＥＲＶＥメッセージを送信すると同時か、又はしばらく後に、古い経路（経路２４と経路３４の重複部分）に対して、ステートの解放を行うために、ＲＥＳＥＲＶＥメッセージ（図１３ではＲＥＳＥＲＶＥ（release）と記載）をＭＮ１０の古いＣｏＡに向けて送信する（ステップＳ５８９）ことも可能であり、これによって、ＭＮ１０の移動に伴って不要となったリソース予約を迅速に解放することが可能となる。
【０１００】
このとき、経路２４と経路３４の重複部分に属するＱＮＥであるＱＮＥ６２は、ＱＮＥ６３より送られたＲＥＳＥＲＶＥメッセージをいったん受け取り、通常のＲＥＳＥＲＶＥ（update）処理を行い、このＲＥＳＥＲＶＥメッセージを送信先（ＭＮ１０の古いＣｏＡ）に対して送信する（ステップＳ５９１）。ただし、ＱＮＥ６２が、ＭＮ１０が移動したということを既に知っていた場合には、ステートの解放処理だけを行い、ＲＥＳＥＲＶＥメッセージの送信（ステップＳ５９１）は行わないようにすることも可能である。
【０１０１】
このようにＭＮ１０がハンドオーバする際、ＭＮ１０が所定のプロキシに対してメッセージを送信することによって仮クロスオーバノードを特定し、この仮クロスオーバノードを経由するＱｏＳ経路を張って、その経路上でデータを送受信するようにすることにより、シグナリングメッセージの無駄なラウンドトリップを回避することができ、迅速にＱｏＳ経路を張ることが可能となる。また、セッション識別子に束ねられているフローが複数あった場合にも、この複数のフローに対し、一度に迅速にＱｏＳ経路を確立することが可能である。
【０１０２】
また、上述の実施の形態では、ＭＮ１０がハンドオーバを行う前にＭＮ１０とＣＮ６０との間に設定されているＱｏＳ経路が１つの場合について説明したが、ＭＮ１０とＣＮ６０との間に複数のＱｏＳ経路が設定されていたり、ＭＮ１０とそれぞれ異なる複数のＣＮ６０との間にＱｏＳ経路が設定されていたりする場合も存在する。
【０１０３】
このように、ＭＮ１０が複数のＱｏＳ経路を有しており、これらの複数のＱｏＳ経路において、ＭＮ１０の隣接ＱＮＥ（例えば、図１におけるＱＮＥ６２）が複数存在する場合には、ＭＮ１０は、各隣接ＱＮＥを経由して、各隣接ＱＮＥのそれぞれを経由するＱｏＳ経路に対応したＱｏＳ経路をハンドオーバ後に設定する準備を行うために必要な情報（すなわち、上述のメッセージＡに含まれる情報）を送信するように制御することが望ましい。これにより、複数の隣接ＱＮＥが存在する場合に、ＭＮ１０から各隣接ＱＮＥに対して、各隣接ＱＮＥを通るＱｏＳ経路に対応した情報を含むメッセージＡが送信され、各ＱｏＳ経路に関して、それぞれ上述の経路切り換え設定動作を行うことが可能となる。
【０１０４】
なお、本明細書に記述されている送信先という表現（例えば、ＣＮ６０あてに送信するという表現）は、必ずしもＩＰヘッダの送信先アドレスにＣＮ６０のアドレスを指定して送信するという意味ではなく、最終的にメッセージを受け取る相手がＣＮ６０であるという意味である。
【０１０５】
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１０６】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１０７】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１０８】
本発明に係る新規経路設定方法及び移動端末並びに経路管理装置は、ハンドオーバを行う移動端末が、ハンドオーバ後においても、ハンドオーバ前に受けていた付加的サービスを迅速、かつ継続して受けられるようにすることを可能とするという効果を有しており、無線通信を行う移動端末のハンドオーバの際に、新たな経路の設定を行うための技術分野に適用され、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６プロトコルを利用した無線通信を行う移動端末のハンドオーバの際に、新たな経路の設定を行うための技術分野や、ＮＳＩＳを用いたＱｏＳ保証に係る技術分野に適用可能である。
【図面の簡単な説明】
【０１０９】
【図１】本発明の実施の形態における通信システムの構成を示す模式図
【図２】本発明の実施の形態におけるＭＮの構成を示すブロック図
【図３】本発明の実施の形態におけるプロキシの構成を示すブロック図
【図４】本発明の実施の形態におけるＱＮＥの構成を示すブロック図
【図５】本発明及び従来の技術に共通した無線通信システムの構成を示す模式図
【図６】従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図
【図７】従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図
【図８】従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図
【図９】従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図
【図１０】従来の技術におけるＮＳＩＳにおいて、どのように二重のリソース予約を回避するかを説明する模式図
【図１１】本発明の実施の形態におけるＭＮ内に格納されるプロキシ情報の一例を示す模式図
【図１２】本発明の実施の形態における通信システムにおいて、データの送信方向がＣＮからＭＮだった場合、ＭＮがハンドオーバする際に、プロキシに仮クロスオーバノードを特定するためのメッセージを送って仮クロスオーバノードを特定し、特定された仮クロスオーバノードを経由するＱｏＳ経路を張って、その経路上でデータを送受信する際の動作を示すものであり、メッセージとして、従来のＮＳＩＳで使われるＱＵＥＲＹ及びＲＥＳＥＲＶＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１３】本発明の実施の形態における通信システムにおいて、データの送信方向がＭＮからＣＮだった場合、ＭＮがハンドオーバする際に、プロキシに仮クロスオーバノードを特定するためのメッセージを送って仮クロスオーバノードを特定し、特定された仮クロスオーバノードを経由するＱｏＳ経路を張って、その経路上でデータを送受信する際の動作を示すものであり、メッセージとして、従来のＮＳＩＳで使われるＱＵＥＲＹ及びＲＥＳＥＲＶＥメッセージを利用した場合の動作の一例を示すシーケンスチャート
【図１４】本発明の実施の形態におけるＭＮ内に格納されるＡＰ−ＡＲ対応情報の一例を示す模式図
【図１】
0004543041.tif 000002
【図２】
0004543041.tif 000003
【図３】
0004543041.tif 000004
【図４】
0004543041.tif 000005
【図５】
0004543041.tif 000006
【図６】
0004543041.tif 000007
【図７】
0004543041.tif 000008
【図８】
0004543041.tif 000009
【図９】
0004543041.tif 000010
【図１０】
0004543041.tif 000011
【図１１】
0004543041.tif 000012
【図１２】
0004543041.tif 000013
【図１３】
0004543041.tif 000014
【図１４】
0004543041.tif 000015