JPWO2007015539A1 - クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末 - Google Patents

クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末 Download PDF

Info

Publication number
JPWO2007015539A1
JPWO2007015539A1 JP2007529520A JP2007529520A JPWO2007015539A1 JP WO2007015539 A1 JPWO2007015539 A1 JP WO2007015539A1 JP 2007529520 A JP2007529520 A JP 2007529520A JP 2007529520 A JP2007529520 A JP 2007529520A JP WO2007015539 A1 JPWO2007015539 A1 JP WO2007015539A1
Authority
JP
Japan
Prior art keywords
qne
layers
network
message
query
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2007529520A
Other languages
English (en)
Inventor
上　豊樹
豊樹 上
貴子 堀
貴子 堀
荒牧　隆
隆 荒牧
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2007015539A1 publication Critical patent/JPWO2007015539A1/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

ＭＮがハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のネットワークレイヤ）のうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合の最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができるクロスオーバノード検出前処理方法などを提供する技術が開示され、その技術によれば移動端末１０が、入れ子のように重なっている複数のネットワークレイヤのうち、いずれのネットワークレイヤまでクロスオーバノードの検出のための処理を実行するかを決め、複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められたネットワークレイヤまでのレイヤ数を決定するステップと、決定されたレイヤ数の情報を含むメッセージを生成するステップとを有する。

Description

本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Mobile Internet Protocol version 6）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関する。
移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰｖ６を利用したものが普及してきている。このモバイルＩＰｖ６を利用した無線通信システムについて、図１１を参照しながら説明する。なお、以下に説明するモバイルＩＰｖ６の技術に関しては、例えば、下記の非特許文献１に開示されている。
図１１に示す無線通信システムは、インターネットなどのＩＰネットワーク（通信ネットワーク）１５、ＩＰネットワーク１５に接続する複数のサブネット（サブネットワークとも呼ばれる）２０、３０、これらの複数のサブネット２０、３０のいずれかに接続することが可能な移動端末（ＭＮ：Mobile Node）１０を含んでいる。なお、図１１では、複数のサブネット２０、３０として、２つのサブネット２０、３０が図示されている。
サブネット２０は、ＩＰパケット（パケットデータ）に対するルーティングを行うアクセスルータ（ＡＲ：Access Router）２１、固有の無線カバーエリア（通信可能領域）２８、２９をそれぞれ形成する複数のアクセスポイント（ＡＰ：Access Point）２２、２３により構成されている。これらのＡＰ２２、２３は、それぞれＡＲ２１に接続されており、ＡＲ２１は、ＩＰネットワーク１５に接続されている。なお、図１１では、複数のＡＰ２２、２３として、２つのＡＰ２２、２３が図示されている。また、サブネット３０に関しても、ＡＲ３１及び複数のＡＰ３２、３３により、上述のサブネット２０と同一の接続態様によって構成されている。
また、サブネット２０の構成要素であるＡＲ２１と、サブネット３０の構成要素であるＡＲ３１とは、ＩＰネットワーク１５を通じて通信を行うことが可能であり、すなわち、サブネット２０とサブネット３０とは、ＩＰネットワーク１５を通じてつながっている。
図１１に示す無線通信システムにおいて、ＭＮ１０が、無線カバーエリア２９内でＡＰ２３との無線通信を開始したとする。このとき、ＭＮ１０に割り当てられているＩＰｖ６アドレスが、サブネット２０のＩＰアドレス体系に適さない場合、無線カバーエリア２９内に存在するＭＮ１０は、ＡＰ２３との間における無線通信を介して、サブネット２０に適合したＩＰｖ６アドレス、すなわち気付アドレス（ＣｏＡ：Care of Address）を取得する。
なお、ＭＮ１０がＣｏＡを取得する方法には、ＤＨＣＰｖ６などの方法によりＤＨＣＰサーバからステートフルに割り当ててもらう方法と、サブネット２０のネットワークプリフィックス及びプリフィックスレングスをＡＲ２１から取得し、ＭＮ１０において、ＡＲ２１から取得したネットワークプリフィックス及びプリフィックスレングスと、ＭＮ１０のリンクレイヤアドレスなどとを組み合わせて、ステートレスにＣｏＡを自動生成する方法とが存在する。
そして、ＭＮ１０は、取得したＣｏＡを自分のホームネットワーク上のルータ（ホームエージェント）や特定の通信相手（ＣＮ：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が各ＱＮＥで予約可能かどうかを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッセージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献６に記載されている。
次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、２重のリソース予約の回避方法を、図１６を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路２４）が確立されているとき、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。このときのフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立するためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路２４）は、ＭＮ１０の移動後すぐに解放されることはない。
前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路２４におけるフロー識別子Ｘと、経路３４におけるフロー識別子（この経路３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインターフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここでフロー識別子を比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、２重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（cross over node：クロスオーバノード）と呼ばれている。なお、ＣＲＮとは、実際に経路が交わり始めるルータ（図１６ではＮＥ６４）を指す場合もあるが、ＱｏＳ経路の議論を行う場合は、古い経路（経路２４）と新しい経路（経路３４）において、片方の隣り合うＱＮＥ（図１６ではＱＮＥ６６）は同じであるが、もう片方の隣り合うＱＮＥ（図１６ではＱＮＥ６３とＱＮＥ６７）は異なっているようなＱＮＥ（図１６ではＱＮＥ６５）を指す。
このように、ＣＲＮはハンドオーバの際に２重のリソース予約を避けるために重要な役割を果たす。そのため、ＣＲＮを発見することはハンドオーバにおいて重要な問題の１つである。
ここで、ネットワーク内でのシグナリングなどを減らすため、多数フローにおける予約を一緒にまとめる（入れ子集合させる）ことが考えられる。図１７には入れ子集合予約の例を示す。ＣＮ６０とＭＮ１０との間（end-to-end）におけるフロー予約は、通常どおり開始される。アグリゲーターでは入れ子集合フローの予約が開始される。アグリゲーターは、入れ子集合予約においてQoS NSIS Initiator（ＱＮＩ）として振る舞う。アグリゲーターは、個別フロー予約の代わりに入れ子集合予約（例えば、トンネルなど）のためのフローＩＤを有している。また、入れ子集合予約として振る舞う際に用いられるマーキングは、中間のルータが個別フロー予約を調べる必要がないようにするために用いられる。デアグリゲーターは、end-to-endにおけるフロー予約の次のＱＮＥとなる。デアグリゲーターは、入れ子集合予約においてQoS NSIS Responder（ＱＮＲ）として振る舞う。
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, et al.,"NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-05.txt, October 2004 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 et al.,"Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07.txt, November 2004 S. Lee, et al., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-00.txt, October 2004 M. Brunner (Editor), "Requirements for Signaling Protocols", RFC3726, April 2004 T.Ue,T.Sanda,K.Honma,"QoS Mobility Support with Proxy-assisted Fast Crossover Node Discovery", WPMC2004,September 2004
図１７で説明した例と上述したアグリゲーターのない例との主な違いは、入れ子集合予約のためのフローＩＤがend-to-end予約におけるフローＩＤと異なるところである。入れ子集合予約は、end-to-end予約とは独立して更新することが可能である。ＭＮがハンドオーバをし、ＣＲＮ検出を開始すると、アグリゲーター又はデアグリゲーターは、実際のＣＲＮは集合の中に存在するがend-to-end予約におけるＣＲＮとして検出する。この場合、２重予約がend-to-end予約におけるＣＲＮと実際のＣＲＮとの間に起こる。ＣＲＮ検出は２重予約を避けるためにも入れ子集合になった内側まで行う必要がある。しかしながら、入れ子集合におけるＣＲＮ検出を完全に行うには時間がかかり、ＱｏＳハンドオーバにおける遅延の原因にもなる。結果としてＱｏＳの破綻が起こってしまう。
本発明は、上記の問題点に鑑み、移動端末がハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のレイヤ）のうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のレイヤ）の最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができるクロスオーバノード検出前処理方法、その方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末を提供することを目的とする。
上記目的を達成するために、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法であって、前記移動端末が、入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定するステップと、決定された前記レイヤ数の情報を含むメッセージを生成するステップとを有するクロスオーバノード検出前処理方法が提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。なお、ネットワークレイヤとは、後述するend-to-end層やネスト層を言い、コンピュータの持つべき通信機能を階層構造に分割したＯＳＩモデルにおける層とは異なる。以下ではネットワークレイヤを単にレイヤとも言う。
また、本発明のクロスオーバノード検出前処理方法において、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数が、前記通信ネットワークを管理する管理装置によって決定されることは、本発明の好ましい態様である。この構成により、通信ネットワーク側でレイヤ数を決定することが可能となる。
また、本発明のクロスオーバノード検出前処理方法において、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数が、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定されることは、本発明の好ましい態様である。この構成により、より適切なレイヤ数を決定することができる。
また、本発明のクロスオーバノード検出前処理方法において、前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数が、前記移動端末によって送信される前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出されることは、本発明の好ましい態様である。この構成により、通信ネットワーク全体のレイヤ数を把握することができる。なお、ネットワークレイヤのエッジに位置するエッジノードとは、後述するアグリゲーター又はデアグリゲーターを言う。
また、本発明によれば、上記発明のいずれかに記載のクロスオーバノード検出前処理方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラムが提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
また、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法で用いられる前記移動端末であって、入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定する決定手段と、決定された前記レイヤ数の情報を含むメッセージを生成するメッセージ生成手段とを備える移動端末が提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
また、本発明の移動端末における前記決定手段が、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定することは、本発明の好ましい態様である。この構成により、より適切なレイヤ数を決定することができる。
また、本発明の移動端末において、前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数が、前記メッセージ生成手段によって生成された前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出されることは、本発明の好ましい態様である。この構成により、通信ネットワーク全体のレイヤ数を把握することができる。
本発明のクロスオーバノード検出前処理方法、その方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末は、上記構成を有し、移動端末がハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のネットワークレイヤ）のうち、いずれのネットワークレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合の最も外側に位置するネットワークレイヤから決められたネットワークレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
本発明の実施の形態における通信ネットワークの構成を示す模式図 本発明の実施の形態における通信ネットワークの入れ子集合予約を示す模式図 本発明の実施の形態に係る移動端末の構成を示す構成図 本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて説明するためのフローチャート 本発明の実施の形態の新たな上流リンクパスにおけるＣＲＮ検出の一例を説明するためのシーケンスチャート 本発明の実施の形態におけるＱＵＥＲＹとＲＥＳＥＲＶＥメッセージを使った状態予約の手続きの一例について説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の検出方法を説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャート 本発明及び従来の技術に共通した無線通信システムの構成を示す模式図 従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図 従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図 従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図 従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図 従来の技術におけるＮＳＩＳにおいて、どのように２重のリソース予約を回避するとされているかを説明するための模式図 通信ネットワークが入れ子状態にある場合の入れ子集合予約の一例を説明するための模式図
以下、本発明の実施の形態について図１から図１０を用いて説明する。図１は本発明の実施の形態における通信ネットワークの構成を示す模式図である。図２は本発明の実施の形態における通信ネットワークの入れ子集合予約を示す模式図である。図３は本発明の実施の形態に係る移動端末の構成を示す構成図である。図４は本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて説明するためのフローチャートである。図５は本発明の実施の形態の新たな上流リンクパスにおけるＣＲＮ検出の一例を説明するためのシーケンスチャートである。図６は本発明の実施の形態におけるＱＵＥＲＹとＲＥＳＥＲＶＥメッセージを使った状態予約の手続きの一例について説明するためのシーケンスチャートである。
図７は本発明の実施の形態における通信ネットワークのレイヤ数の検出方法を説明するためのシーケンスチャートである。図８は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。図９は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。図１０は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。
まず、本発明の実施の形態における通信ネットワークの構成について図１を用いて説明する。図１に示すように、ＭＮ１０とＣＮ６０との間における通信ネットワークは入れ子になった複数のレイヤ（ここでは、ネストとも言う）から構成されており、図１では３つのレイヤ（end-to-end、ネストＢ、ネストＣ）から構成されている。その構成の様子を図２に示す。ＱＮＥ-Ｂ０、ＱＮＥ-Ｂ１、ＱＮＥ-Ｂ２はネストＢにおけるアグリゲーター／デアグリゲーターに相当する位置にある。ＱＮＥ-Ｃ０、ＱＮＥ-Ｃ１、ＱＮＥ-Ｃ２はネストＣにおけるアグリゲーター／デアグリゲーターに相当する位置にある。この場合、実際のＣＲＮはＱＮＥ-Ｃ３である。
現在、ＭＮ１０は、ハンドオーバする前のパス（ＱＮＥ-Ａ０−ＱＮＥ-Ｂ０−ＱＮＥ-Ｃ０−ＱＮＥ-Ｃ３−ＱＮＥ-Ｃ２−ＱＮＥ-Ｂ２−ＱＮＥ-Ａ２）に沿ってＣＮ６０と通信を行っているとする。そして、ＭＮ１０がハンドオーバをすると、ＭＮ１０は新たなパス（ＱＮＥ-Ａ１−ＱＮＥ-Ｂ１−ＱＮＥ-Ｃ１−ＱＮＥ-Ｃ３−ＱＮＥ-Ｃ２−ＱＮＥ-Ｂ２−ＱＮＥ-Ａ２）に沿ってＣＮ６０と通信を行うことになる。end-to-endにおける予約状態は、それぞれハンドオーバ前ではＱＮＥ-Ａ０、ＱＮＥ-Ｂ０、ＱＮＥ-Ｂ２、ＱＮＥ-Ａ２、ハンドオーバ後ではＱＮＥ-Ａ１、ＱＮＥ-Ｂ１、ＱＮＥ-Ｂ２、ＱＮＥ-Ａ２となっている。end-to-endの場合にＣＲＮ検出が行われると、ＱＮＥ-Ｂ２がＣＲＮとして検出される。この場合の２重予約はＱＮＥ-Ｂ２と実際のＣＲＮ（ＱＮＥ-Ｃ３）との間で起こる。
ＭＮ１０が更にＣＲＮ検出をすることを決めるのであれば、検出の処理はネストＢにおいてもなされる。予約状態は、ハンドオーバ前ではＱＮＥ-Ｂ０、ＱＮＥ-Ｃ０、ＱＮＥ-Ｃ２、ＱＮＥ-Ｂ２、ハンドオーバ後ではＱＮＥ-Ｂ１、ＱＮＥ-Ｃ１、ＱＮＥ-Ｃ２、ＱＮＥ-Ｂ２とそれぞれなっている。この場合、ＱＮＥ-Ｃ２がＣＲＮとして検出され、２重予約はＱＮＥ-Ｃ２と実際のＣＲＮ（ＱＮＥ-Ｃ３）との間で起こる。実際のＣＲＮ（ＱＮＥ-Ｃ３）を検出するにはネストＣまで検出処理を行わなければならない。そのときの予約状態は、ハンドオーバ前ではＱＮＥ-Ｃ０、ＱＮＥ-Ｃ３、ＱＮＥ-Ｃ２、ハンドオーバ後ではＱＮＥ-Ｃ１、ＱＮＥ-Ｃ３、ＱＮＥ-Ｃ２とそれぞれなっている。これにより、ＱＮＥ-Ｃ３がＣＲＮとして検出され、ＱＮＥ-Ｃ３が実際のＣＲＮとなる。結果として、ＣＲＮの検出処理はこの実施の形態の場合、３回繰り返す必要がある。この繰り返す回数に関しては、通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求などに基づいてＭＮ１０又は通信ネットワーク側（例えば、通信ネットワークを管理する管理装置など）によって決定される。なお、この決定された回数の情報は、ＣＲＮ検出のための初期のシグナリングに含まれる。
次に、本発明の実施の形態に係る移動端末（ＭＮ１０）の構成について図３を用いて説明する。なお、図３では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。図３に示すように、ＭＮ１０は、受信手段３００、決定手段３０１、メッセージ生成手段３０２、送信手段３０３、情報格納手段３０４から構成されている。受信手段３００は、例えばＭＮ１０自身の通信相手となるＣＮ６０から送信されたメッセージやデータなどを受信する手段である。また、送信手段３０３は、例えば後述するメッセージ生成手段３０２によって生成されたメッセージやその他のデータなどを送信する手段である。
決定手段３０１は、図１で示した通信ネットワークのように、入れ子のように重なっている複数のレイヤのうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、複数のレイヤの最も外側に位置するレイヤ（図１の場合、end-to-end）から決められたレイヤまでのレイヤ数（以下、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数とも言う）を決定する手段である。なお、決定手段３０１は、複数のレイヤの最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を、例えば通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定する。また、複数のレイヤの最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定手段３０１が決定するのではなく、例えば通信ネットワークを管理する側の不図示の管理装置などが決定するようにしてもよい。
メッセージ生成手段３０２は、決定されたレイヤ数の情報を含むメッセージを生成する手段である。生成されるメッセージには、決定されたレイヤ数の情報以外に、例えばＭＮ１０を識別するための識別情報、タイムアウト情報などが含まれるようにしてもよい。ここで、タイムアウト情報とは、決定されたレイヤ数までのＣＲＮ検出の処理が終わらなくても強制的に処理を打ち切らせる時間を言い、例えば処理開始から３０秒などといった情報である。タイムアウト情報の設定により、時間のかかるＣＲＮ検出によるＱｏＳハンドオーバの遅延を解消することが可能となる。なお、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定せず、メッセージにＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を挿入しないでタイムアウト情報のみを挿入したメッセージを生成するようにしてもよい。
次に、本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて図４を用いて説明する。まず、ＭＮ１０が現在接続しているＱＮＥ-Ａ０からハンドオーバをしてＱＮＥ-Ａ１に接続する場合に、ＭＮ１０は、例えば通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定する（ステップＳ４０１）。ＭＮ１０は、決定されたレイヤ数の情報を含むメッセージを生成する（ステップＳ４０２）。そして、ＭＮ１０は、例えばＱＮＥ機能を有する新たな接続先のサブネットのＮＡＲ（New Access Router）であって、ＣＲＮ検出の処理のプロキシとして振る舞うＮＡＲに対して生成されたメッセージを送信する（ステップＳ４０３）。なお、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数は、ＭＮ１０が決定するのではなく、通信ネットワークを管理する不図示の管理装置が決定をしてＮＡＲに送信するようにしてもよい。
このように、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定して、決定されたレイヤ数をＮＡＲに送信することにより、ＮＡＲは受信したレイヤ数に基づいてＣＲＮ検出の処理を開始する。ＣＲＮを検出する方法は１つに限られるものではなく、様々な方法で検出することができる。以下では、ＣＲＮの検出の方法の一例として、非特許文献１２に示された、ＷＰＭＣ２００４という国際会議において２００４年９月に発表されたQoS Mobility Support with Proxy-assisted Fast Crossover Node Discoveryに記載された方法を挙げて説明する。
ここでは、拡張されたＱｏＳ ＮＳＬＰメッセージを使ったＣＲＮ検出の手続きの一例について図５を用いて説明する。図５は新しい上流リンクパスにおけるＣＲＮ検出のシーケンスチャートである。図５のシーケンスチャートは上述した図１の通信ネットワークに基づくものであり、プロキシは図１に示すＱＮＥ-Ａ１として説明する。まず、ＭＮ１０は、ＱＵＥＲＹ（メッセージ）をＱＮＥ-Ａ１（以下、プロキシとも言う）に送信する（ステップＳ５０１）。このとき、上述したレイヤの数の情報を含んだメッセージ（以下、メッセージＡとも言う）もプロキシに送信される。また、ＭＮ１０は、そのとき、実際のハンドオーバの前に新たな上流リンクパスに沿ってリソース情報を集めるようにプロキシに要求する。ＱＵＥＲＹメッセージは、従来のパラメータに加えて、上流リンク（ＭＮ１０からＣＮ６０）と下流リンク（ＣＮ６０からＭＮ１０）における現在のフロー識別子とセッション識別子とを含んでいる。
そして、ＭＮ１０からＱＵＥＲＹメッセージを受信すると、プロキシはＣＮ６０に対してＱＵＥＲＹメッセージを転送する（ステップＳ５０２）。このとき、メッセージＡもＱＵＥＲＹメッセージと同様に転送する。なお、レイヤ数の情報をＱＵＥＲＹメッセージに含めるようにしてもよい。また、ＣＮ６０のＩＰアドレスはフロー識別子に含まれている。上流リンクのend-to-endレイヤ上に位置するＱＮＥは、ＱＵＥＲＹメッセージとメッセージＡを取得し、ＱＵＥＲＹメッセージにリソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する（ステップＳ５０３）。それと同時にそれぞれのＱＮＥは、ＱＵＥＲＹメッセージのフロー識別子とセッション識別子のペアが上流リンクで存在する予約状態と合う（マッチする）か否かをチェックする。もし合えば、ＱＮＥはＱＵＥＲＹメッセージにインターフェースのＩＰアドレスを付加する（ステップＳ５０４）。ＱＵＥＲＹメッセージとメッセージＡがＣＮ６０に到達したとき、ＱＵＥＲＹメッセージは、end-to-endレイヤ上において現在の上流リンクパス（ＭＮ１０からＣＮ６０）と新たな上流リンクパス（プロキシからＣＮ６０）の間でオーバーラップしている（重なっている）インターフェースのＩＰアドレスを含んでいる。
ここで、メッセージＡに含まれるレイヤ数の情報が図１に示すネストＢまでのＣＲＮ検出の処理をさせる旨の情報である場合を考える。このとき、ＱＮＥ-Ｂ１はＱＵＥＲＹメッセージにリソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する。そうすると、転送されたＱＵＥＲＹメッセージとメッセージＡはＱＮＥ-Ｂ２に到達する。そして、ＱＮＥ-Ｂ２はＱＵＥＲＹメッセージにリソースが利用可能である旨の情報及びインターフェースのＩＰアドレスを付加し、上流リンクに転送する。それと同時にＱＮＥ−Ｂ２は、メッセージＡに含まれるレイヤ数の情報に基づいてネストＢ内のＣＲＮ検出を実施することを決定し（ステップＳ５０５）、処理を開始するためのメッセージをＱＮＥ−Ｂ１に向けて送信する（ステップＳ５０６）。
このメッセージ（ＱＵＥＲＹ−ｔｒｇ）は、ネストＢ内のＣＲＮ検出に必要な情報として、ＱＮＥ−Ｂ０とＱＮＥ−Ｂ２との間で確立されているフロー識別子とセッション識別子を含んでいる。また、メッセージＡも同様に送信される。なお、メッセージＡに含まれるレイヤ数の情報を、ＱＵＥＲＹ−ｔｒｇメッセージに含めてもよい。ＱＵＥＲＹ−ｔｒｇメッセージ及びメッセージＡを受信したＱＮＥ−Ｂ１は、識別子情報及びレイヤ数情報を含んだＱＵＥＲＹメッセージを、ＱＮＥ−Ｂ２に向けてネストＢレイヤ上を転送させる（ステップＳ５０７）。ネストＢレイヤでは、ＱＮＥ−Ｃ２においてフロー識別子とセッション識別子のペアがマッチするため、ＱＮＥ−Ｃ２はリソースが利用可能である旨の情報とともにインターフェースのＩＰアドレスをＱＵＥＲＹメッセージに付加し、上流リンクに転送する。
それと同時にＱＮＥ−Ｃ２は、メッセージＡに含まれるレイヤ数の情報に基づいてネストＣ内のＣＲＮ検出を実施しないことを決定する（ステップＳ５０８）。ネストＢレイヤ上のＱＵＥＲＹメッセージを受信したＱＮＥ−Ｂ２は、ＱＵＥＲＹメッセージ内のリソース利用可能情報とＩＰアドレス情報をＲＥＳＰＯＮＳＥメッセージに付加し(ステップＳ５０９)、ＱＮＥ−Ｂ１に対して送信する（ステップＳ５１０）。ＲＥＳＰＯＮＳＥメッセージは、ネストＢ上のＱＵＥＲＹメッセージにおける逆方向のパスに沿ってＱＮＥ−Ｂ１に届けられる。ＲＥＳＰＯＮＳＥメッセージを受信すると、ＱＮＥ−Ｂ１は付加されたＩＰアドレスの情報から最初に付加されたＩＰアドレスを抽出することにより、ネストＢレイヤ上のＣＲＮ（ＱＮＥ−Ｃ２）を検出する（ステップＳ５１１）。
end-to-endレイヤ上においても、同様の処理が行われる。ＱＵＥＲＹメッセージを受信すると、ＣＮ６０はＲＥＳＰＯＮＳＥメッセージをプロキシに対して送信する（ステップＳ５１２）。ＲＥＳＰＯＮＳＥメッセージには、上流リンクにおける、集められたリソースが利用可能である旨の情報と、ＱＵＥＲＹメッセージに付加されたＩＰアドレスの情報が含まれている。ＲＥＳＰＯＮＳＥメッセージは、ＱＵＥＲＹメッセージにおける逆方向のパスに沿ってプロキシに届けられる。ＲＥＳＰＯＮＳＥメッセージを受信すると、プロキシは付加されたＩＰアドレスの情報から最初に付加されたＩＰアドレスを抽出することにより上流リンクのＣＲＮ（ＱＮＥ−Ｂ２）を検出する。また、プロキシは新たな上流リンクパス上における、集められたリソースが利用可能である旨の情報を得ることもできる。
ＲＥＳＰＯＮＳＥメッセージの伝達と平行して、ＣＮ６０はプロキシにＱＵＥＲＹメッセージとメッセージＡをend-to-endレイヤ上において送信する。このＱＵＥＲＹメッセージは下流リンクにおける現在のフロー識別子とセッション識別子を含み、それらは上流リンクＱＵＥＲＹメッセージから抽出される。上流リンクにおける方法と同様に、下流リンクのシグナリングパス上におけるそれぞれのＱＮＥはＱＵＥＲＹメッセージを取得し、リソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する。それと同時に、それぞれのＱＮＥは、ＱＵＥＲＹメッセージのフロー識別子とセッション識別子のペアが下流リンクで存在する予約状態と合う（マッチする）か否かをチェックする。
もし合えば、ＱＮＥはＱＵＥＲＹメッセージにインターフェースのＩＰアドレスを付加する。ＱＵＥＲＹメッセージがプロキシに到達したとき、ＱＵＥＲＹメッセージは、end-to-endレイヤ上において現在の下流リンクパス（ＣＮ６０からＭＮ１０）と新たな下流リンクパス（ＣＮ６０からプロキシ）の間でオーバーラップしている（重なっている）インターフェースのＩＰアドレスを含んでいる。プロキシは、付加されたＩＰアドレスの情報から最後に付加されたＩＰアドレスを抽出することにより下流リンクのＣＲＮを検出する。また、プロキシは新たな下流リンクパス上における、集められたリソースが利用可能である旨の情報を得ることもできる。下流リンクにおけるネストＢレイヤ上のＣＲＮ検出においても上流リンクにおけるＣＲＮ検出と同様に考えられる。
プロキシは、end-to-endレイヤ上に対して、ハンドオーバ後に実際の予約におけるＣＲＮやリソースの利用可能性の情報を保持する。プロキシは、ＭＮ１０がハンドオーバ先の決定でリソースが利用可能である旨の情報を利用できるようにＭＮ１０にＲＥＳＰＯＮＳＥメッセージを送信するようにしてもよい。また、ＱＮＥ−Ｂ１は、ネストＢレイヤに対して、ハンドオーバ後の実際の予約におけるＣＲＮやリソースの利用可能性の情報を保持する。
上述した方法はハンドオーバ前のＣＲＮ検出の手続き（方法）である。上述した方法は、プロキシとＣＮ６０がＣＲＮ検出と平行して予約を開始することができる。以下では、ＱＵＥＲＹメッセージとＲＥＳＥＲＶＥメッセージを使った状態の予約の手続きの一例について図６を用いて説明する。図６は新たな上流リンクパスにおける状態の予約のシーケンスチャートである。まず、ＭＮ１０は、上述した方法のＱＵＥＲＹメッセージをプロキシに送信する（ステップＳ６０１）。このとき、ＱＵＥＲＹメッセージにはハンドオーバ先で使用するＮＣｏＡが含まれている。また、上述した方法と同様に、レイヤの数の情報を含んだメッセージＡもプロキシに送信される。
プロキシは、受信したＮＣｏＡでＤＡＤ（Duplicate Address Detection:２重アドレス検出）を行い、パスすれば（問題がなければ）プロキシはＮＣｏＡの情報を含めてＣＮ６０に向けてＱＵＥＲＹメッセージを送信する（ステップＳ６０２）。それぞれのＱＮＥは上述したＣＲＮ検出と同様の方法を行う。ＱＵＥＲＹメッセージから、ＣＮ６０はend-to-endレイヤ上における上流リンクのＣＲＮ（ＱＮＥ−Ｂ２）を検出し、予約のための新たなフロー識別子がＮＣｏＡから得られる（ステップＳ６０９）。同様に、ＱＮＥ−Ｂ２はネストＢレイヤ上における上流リンクのＣＲＮ（ＱＮＥ−Ｃ２）を検出する。ＣＮ６０はＱＵＥＲＹメッセージにおける逆方向のパスに沿って、ＲＥＳＰＯＮＳＥメッセージの代わりにＲＥＳＥＲＶＥメッセージをend-to-endレイヤ上に送信する（ステップＳ６１０）。ＱＮＥ−Ｂ２はＲＥＳＥＲＶＥメッセージを受信すると、end-to-endレイヤのためのＲＥＳＥＲＶＥメッセージをＱＮＥ−Ｂ１に送信するとともに、ネストＢレイヤのためのＲＥＳＥＲＶＥメッセージをＱＮＥ−Ｂ１に向けて送信する。
インターフェースがオーバーラップしている（すなわち、end-to-endレイヤ上ではＣＮ６０からＣＲＮであるＱＮＥ−Ｂ２までの間、また、ネストＢレイヤ上ではＱＮＥ−Ｂ２からＣＲＮであるＱＮＥ−Ｃ２までの間の）ＱＮＥは、２重予約を避けるために予約状態を更新する。新たな上流リンクパス上（end-to-endレイヤ上ではＣＲＮであるＱＮＥ−Ｂ２からプロキシまでの間、また、ネストＢレイヤ上ではＣＲＮであるＱＮＥ−Ｃ２からＱＮＥ−Ｂ１までの間）における他のＱＮＥは新たな予約状態を生成する。このようにして新たな下流リンクパスにおいても同様の方法で予約状態の更新や生成を行うことができる。ＭＮ１０が実際のハンドオーバを行うときに、新たな予約状態はＭＮ１０とプロキシとの間で生成される。そして、結果として新たなend-to-endのＱｏＳパスが構築される。
ここで、ＭＮ１０又は通信ネットワークを管理する側の不図示の管理装置が、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定する際に基礎となる通信ネットワークのレイヤ数（ネスト数とも言う）の検出方法について以下に４つ述べる。
１つ目は、アグリゲーターがＱＵＥＲＹを受信したときにカウントする方法である。具体的に図７を用いて説明する。なお、以下で説明する４つの検出方法におけるＱＵＥＲＹ（ＱＵＥＲＹメッセージ）にはカウントしたネストの数を示すネストカウント（すなわち、上位のネットワークレイヤの数を示すネストカウント）を設ける。なお、ここでのＱＵＥＲＹは、上述したレイヤ数検出メッセージに相当し、このメッセージはＭＮ１０のメッセージ生成手段３０２によって生成され、送信手段３０３によって送信される。図７に示すように、ＭＮ１０（例えば、メッセージ生成手段３０２）はネストカウントをリセット（ネストカウント＝０）する（ステップＳ７０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ネストＢのアグリゲーターであるＱＮＥ−Ｂ１は、ネストカウント＝１とカウントアップする（ステップＳ７０２）。すなわち、ネストカウントの値に１を加える。
ＱＮＥ−Ｂ１はカウントアップしたＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹを受信した、ネストＣのアグリゲーターであるＱＮＥ−Ｃ１はネストカウント＝２とカウントアップする（ステップＳ７０３）。ＱＮＥ−Ｃ１はカウントアップしたＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥ（ＲＥＳＰＯＮＳＥメッセージ）をＭＮ１０に向けて送信する。これにより、ＭＮ１０は通信ネットワークのレイヤ数を検出することができる。なお、このときＱＵＥＲＹに対するＲＥＳＰＯＮＳＥ要求は、最上層のＱＵＥＲＹにのみ付加される。後述する３つの検出方法においても同様である。
２つ目は、デアグリゲーターがＱＵＥＲＹを受信したときにカウントする方法である。具体的に図８を用いて説明する。図８に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ８０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信した、ネストＢのデアグリゲーターであるＱＮＥ−Ｂ２はネストカウント＝１とカウントアップする（ステップＳ８０２）。
ＱＮＥ−Ｂ２は受信したＱＵＥＲＹの応答として、ネストカウントの情報を含めたＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、ネストカウントの情報を含めたＱＵＥＲＹをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹを受信したネストＣのエッジに位置するＱＮＥ−Ｃ１は、ＱＮＥ−Ｃ２にＱＵＥＲＹを転送する。ＱＵＥＲＹを受信した、ネストＣのデアグリゲーターであるＱＮＥ−Ｃ２はネストカウント＝２とカウントアップする（ステップＳ８０３）。ＱＵＥＲＹを受信したＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
３つ目は、アグリゲーターがＱＵＥＲＹ−ｔｒｇを受信したときにカウントする方法である。具体的に図９を用いて説明する。図９に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ９０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。
ＱＵＥＲＹ−ｔｒｇを受信した、ネストＢのアグリゲーターであるＱＮＥ−Ｂ１はネストカウント＝１とカウントアップする（ステップＳ９０２）。そして、ＱＮＥ−Ｂ１はＱＵＥＲＹをネストＣのＱＮＥ−Ｃ１に送信する。ＱＮＥ−Ｃ１は受信したＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信した、ネストＣのアグリゲーターであるＱＮＥ−Ｃ１はネストカウント＝２とカウントアップする（ステップＳ９０３）。ＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
４つ目は、デアグリゲーターがＱＵＥＲＹ−ｔｒｇに対応した内部的なＱＵＥＲＹを受信したときにカウントする方法である。具体的に図１０を用いて説明する。図１０に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ１００１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ―Ｂ１に送信する。
ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、ネストを検出するためにＱＵＥＲＹをネストＣのアグリゲーターであるＱＮＥ−Ｃ１に送信する。ＱＮＥ−Ｃ１は受信したＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、ネストを検出するためにＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。ＱＵＥＲＹを受信したＱＮＥ−Ｃ３は、ネストＣ内にありそのＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。
ＱＵＥＲＹを受信した、ネストＣのデアグリゲーターであるＱＮＥ−Ｃ２はネストカウント＝１とカウントアップする（ステップＳ１００２）。そして、ＱＮＥ−Ｃ２はそのＱＵＥＲＹをネストＢのデアグリゲーターであるＱＮＥ−Ｂ２に送信する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はネストカウント＝２とカウントアップする（ステップＳ１００３）。そして、ＱＮＥ−Ｂ２はそのＱＵＥＲＹをＣＮ６０に向けて送信する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
なお、これら４つの検出方法におけるシグナリングは、ＭＮ１０がハンドオーバをする前でも後でも可能である。ハンドオーバをする前の場合にはプロキシを利用することになる。
以上説明したように、本発明の実施の形態によれば、ＭＮがハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のレイヤ）のうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のレイヤ）の最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。
本発明に係るクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末は、ハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のネットワークレイヤ）のうち、いずれのネットワークレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のネットワークレイヤ）の最も外側に位置するネットワークレイヤから決められたネットワークレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができるため、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Mobile Internet Protocol version 6）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末などに有用である。
本発明は、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Mobile Internet Protocol version 6）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関する。
移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰｖ６を利用したものが普及してきている。このモバイルＩＰｖ６を利用した無線通信システムについて、図１１を参照しながら説明する。なお、以下に説明するモバイルＩＰｖ６の技術に関しては、例えば、下記の非特許文献１に開示されている。
図１１に示す無線通信システムは、インターネットなどのＩＰネットワーク（通信ネットワーク）１５、ＩＰネットワーク１５に接続する複数のサブネット（サブネットワークとも呼ばれる）２０、３０、これらの複数のサブネット２０、３０のいずれかに接続することが可能な移動端末（ＭＮ：Mobile Node）１０を含んでいる。なお、図１１では、複数のサブネット２０、３０として、２つのサブネット２０、３０が図示されている。
サブネット２０は、ＩＰパケット（パケットデータ）に対するルーティングを行うアクセスルータ（ＡＲ：Access Router）２１、固有の無線カバーエリア（通信可能領域）２８、２９をそれぞれ形成する複数のアクセスポイント（ＡＰ：Access Point）２２、２３により構成されている。これらのＡＰ２２、２３は、それぞれＡＲ２１に接続されており、ＡＲ２１は、ＩＰネットワーク１５に接続されている。なお、図１１では、複数のＡＰ２２、２３として、２つのＡＰ２２、２３が図示されている。また、サブネット３０に関しても、ＡＲ３１及び複数のＡＰ３２、３３により、上述のサブネット２０と同一の接続態様によって構成されている。
また、サブネット２０の構成要素であるＡＲ２１と、サブネット３０の構成要素であるＡＲ３１とは、ＩＰネットワーク１５を通じて通信を行うことが可能であり、すなわち、サブネット２０とサブネット３０とは、ＩＰネットワーク１５を通じてつながっている。
図１１に示す無線通信システムにおいて、ＭＮ１０が、無線カバーエリア２９内でＡＰ２３との無線通信を開始したとする。このとき、ＭＮ１０に割り当てられているＩＰｖ６アドレスが、サブネット２０のＩＰアドレス体系に適さない場合、無線カバーエリア２９内に存在するＭＮ１０は、ＡＰ２３との間における無線通信を介して、サブネット２０に適合したＩＰｖ６アドレス、すなわち気付アドレス（ＣｏＡ：Care of Address）を取得する。
なお、ＭＮ１０がＣｏＡを取得する方法には、ＤＨＣＰｖ６などの方法によりＤＨＣＰサーバからステートフルに割り当ててもらう方法と、サブネット２０のネットワークプリフィックス及びプリフィックスレングスをＡＲ２１から取得し、ＭＮ１０において、ＡＲ２１から取得したネットワークプリフィックス及びプリフィックスレングスと、ＭＮ１０のリンクレイヤアドレスなどとを組み合わせて、ステートレスにＣｏＡを自動生成する方法とが存在する。
そして、ＭＮ１０は、取得したＣｏＡを自分のホームネットワーク上のルータ（ホームエージェント）や特定の通信相手（ＣＮ：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が各ＱＮＥで予約可能かどうかを調べるためのＱＵＥＲＹメッセージが送信され、このＱＵＲＥＹメッセージの応答であるＲＥＳＰＯＮＳＥメッセージによって、その結果を受け取ることが可能である。なお、このＱＵＥＲＹ及びＲＥＳＰＯＮＳＥメッセージにより、現在のリソース予約の状態が変わることは一切ない。また、ＱＮＥが他のＱＮＥに対して何らかの通知を行うためには、ＮＯＴＩＦＹメッセージの使用が可能である。このＮＯＴＩＦＹメッセージは、例えば、エラー通知などのために使われる。上記のＲＥＳＥＲＶＥ、ＱＵＥＲＹ、ＲＥＳＰＯＮＳＥ及びＮＯＴＩＦＹメッセージは、いずれもＱｏＳ保証のためのＮＳＬＰのメッセージであり、非特許文献６に記載されている。
次に、従来の技術において、ＭＮ１０がサブネット２０からサブネット３０へ移動した際の、２重のリソース予約の回避方法を、図１６を用いて説明する。ＭＮ１０がＣＮ６０からデータを受信中であり、ＱｏＳ経路（経路２４）が確立されているとき、ＱＮＥ６３、ＱＮＥ６５及びＱＮＥ６６には、それぞれＭＮ１０が所望したＱｏＳリソースが予約されている。このときのフロー識別子とセッション識別子をそれぞれＸ、Ｙとする。実際、フロー識別子Ｘには、前述の通り、ＭＮ１０の現在のＩＰアドレスと、ＣＮ６０のＩＰアドレスとが含まれ、また、セッション識別子Ｙには、十分大きな任意の数値が設定されている。この状態で、ＭＮ１０がサブネット３０に移動した後、新しいＱｏＳ経路を確立するためにＣＮ６０にＲＥＳＥＲＶＥメッセージを送る。なお、古い経路（経路２４）は、ＭＮ１０の移動後すぐに解放されることはない。
前述の通り、ＭＮ１０の移動に伴ってフロー識別子は変わるので、経路２４におけるフロー識別子Ｘと、経路３４におけるフロー識別子（この経路３４におけるフロー識別子をＺとする）は、異なるものとなる。ＱＮＥ６７はどのインターフェースにもセッション識別子Ｙに対するリソース予約が無いので、新規の経路確立であると判断して、フロー識別子Ｚ及びセッション識別子Ｙに対するリソース予約を行う。一方、ＱＮＥ６５及びＱＮＥ６６には、セッション識別子Ｙに対するリソースの予約が存在している。ＱＮＥ６５やＱＮＥ６６は、ここでフロー識別子を比較し、フロー識別子がＸからＺに変わっていることを確認することによって、ＭＮ１０の移動に伴う新しい経路確立であると判断し、２重のリソース予約を避けるために、新しくリソースを予約することなく、古い予約を更新するなどの手段を取る。この古い経路と新しい経路とが交わり始めるＱＮＥは、ＣＲＮ（cross over node：クロスオーバノード）と呼ばれている。なお、ＣＲＮとは、実際に経路が交わり始めるルータ（図１６ではＮＥ６４）を指す場合もあるが、ＱｏＳ経路の議論を行う場合は、古い経路（経路２４）と新しい経路（経路３４）において、片方の隣り合うＱＮＥ（図１６ではＱＮＥ６６）は同じであるが、もう片方の隣り合うＱＮＥ（図１６ではＱＮＥ６３とＱＮＥ６７）は異なっているようなＱＮＥ（図１６ではＱＮＥ６５）を指す。
このように、ＣＲＮはハンドオーバの際に２重のリソース予約を避けるために重要な役割を果たす。そのため、ＣＲＮを発見することはハンドオーバにおいて重要な問題の１つである。
ここで、ネットワーク内でのシグナリングなどを減らすため、多数フローにおける予約を一緒にまとめる（入れ子集合させる）ことが考えられる。図１７には入れ子集合予約の例を示す。ＣＮ６０とＭＮ１０との間（end-to-end）におけるフロー予約は、通常どおり開始される。アグリゲーターでは入れ子集合フローの予約が開始される。アグリゲーターは、入れ子集合予約においてQoS NSIS Initiator（ＱＮＩ）として振る舞う。アグリゲーターは、個別フロー予約の代わりに入れ子集合予約（例えば、トンネルなど）のためのフローＩＤを有している。また、入れ子集合予約として振る舞う際に用いられるマーキングは、中間のルータが個別フロー予約を調べる必要がないようにするために用いられる。デアグリゲーターは、end-to-endにおけるフロー予約の次のＱＮＥとなる。デアグリゲーターは、入れ子集合予約においてQoS NSIS Responder（ＱＮＲ）として振る舞う。
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, et al.,"NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-05.txt, October 2004 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 et al.,"Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07.txt, November 2004 S. Lee, et al., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-00.txt, October 2004 M. Brunner (Editor), "Requirements for Signaling Protocols", RFC3726, April 2004 T.Ue,T.Sanda,K.Honma,"QoS Mobility Support with Proxy-assisted Fast Crossover Node Discovery", WPMC2004,September 2004
図１７で説明した例と上述したアグリゲーターのない例との主な違いは、入れ子集合予約のためのフローＩＤがend-to-end予約におけるフローＩＤと異なるところである。入れ子集合予約は、end-to-end予約とは独立して更新することが可能である。ＭＮがハンドオーバをし、ＣＲＮ検出を開始すると、アグリゲーター又はデアグリゲーターは、実際のＣＲＮは集合の中に存在するがend-to-end予約におけるＣＲＮとして検出する。この場合、２重予約がend-to-end予約におけるＣＲＮと実際のＣＲＮとの間に起こる。ＣＲＮ検出は２重予約を避けるためにも入れ子集合になった内側まで行う必要がある。しかしながら、入れ子集合におけるＣＲＮ検出を完全に行うには時間がかかり、ＱｏＳハンドオーバにおける遅延の原因にもなる。結果としてＱｏＳの破綻が起こってしまう。
本発明は、上記の問題点に鑑み、移動端末がハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のレイヤ）のうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のレイヤ）の最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができるクロスオーバノード検出前処理方法、その方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末を提供することを目的とする。
上記目的を達成するために、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法であって、前記移動端末が、入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定するステップと、決定された前記レイヤ数の情報を含むメッセージを生成するステップとを有するクロスオーバノード検出前処理方法が提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。なお、ネットワークレイヤとは、後述するend-to-end層やネスト層を言い、コンピュータの持つべき通信機能を階層構造に分割したＯＳＩモデルにおける層とは異なる。以下ではネットワークレイヤを単にレイヤとも言う。
また、本発明のクロスオーバノード検出前処理方法において、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数が、前記通信ネットワークを管理する管理装置によって決定されることは、本発明の好ましい態様である。この構成により、通信ネットワーク側でレイヤ数を決定することが可能となる。
また、本発明のクロスオーバノード検出前処理方法において、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数が、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定されることは、本発明の好ましい態様である。この構成により、より適切なレイヤ数を決定することができる。
また、本発明のクロスオーバノード検出前処理方法において、前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数が、前記移動端末によって送信される前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出されることは、本発明の好ましい態様である。この構成により、通信ネットワーク全体のレイヤ数を把握することができる。なお、ネットワークレイヤのエッジに位置するエッジノードとは、後述するアグリゲーター又はデアグリゲーターを言う。
また、本発明によれば、上記発明のいずれかに記載のクロスオーバノード検出前処理方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラムが提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
また、本発明によれば、それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法で用いられる前記移動端末であって、入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定する決定手段と、決定された前記レイヤ数の情報を含むメッセージを生成するメッセージ生成手段とを備える移動端末が提供される。この構成により、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
また、本発明の移動端末における前記決定手段が、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定することは、本発明の好ましい態様である。この構成により、より適切なレイヤ数を決定することができる。
また、本発明の移動端末において、前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数が、前記メッセージ生成手段によって生成された前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出されることは、本発明の好ましい態様である。この構成により、通信ネットワーク全体のレイヤ数を把握することができる。
本発明のクロスオーバノード検出前処理方法、その方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末は、上記構成を有し、移動端末がハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のネットワークレイヤ）のうち、いずれのネットワークレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合の最も外側に位置するネットワークレイヤから決められたネットワークレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
以下、本発明の実施の形態について図１から図１０を用いて説明する。図１は本発明の実施の形態における通信ネットワークの構成を示す模式図である。図２は本発明の実施の形態における通信ネットワークの入れ子集合予約を示す模式図である。図３は本発明の実施の形態に係る移動端末の構成を示す構成図である。図４は本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて説明するためのフローチャートである。図５は本発明の実施の形態の新たな上流リンクパスにおけるＣＲＮ検出の一例を説明するためのシーケンスチャートである。図６は本発明の実施の形態におけるＱＵＥＲＹとＲＥＳＥＲＶＥメッセージを使った状態予約の手続きの一例について説明するためのシーケンスチャートである。
図７は本発明の実施の形態における通信ネットワークのレイヤ数の検出方法を説明するためのシーケンスチャートである。図８は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。図９は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。図１０は本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。
まず、本発明の実施の形態における通信ネットワークの構成について図１を用いて説明する。図１に示すように、ＭＮ１０とＣＮ６０との間における通信ネットワークは入れ子になった複数のレイヤ（ここでは、ネストとも言う）から構成されており、図１では３つのレイヤ（end-to-end、ネストＢ、ネストＣ）から構成されている。その構成の様子を図２に示す。ＱＮＥ-Ｂ０、ＱＮＥ-Ｂ１、ＱＮＥ-Ｂ２はネストＢにおけるアグリゲーター／デアグリゲーターに相当する位置にある。ＱＮＥ-Ｃ０、ＱＮＥ-Ｃ１、ＱＮＥ-Ｃ２はネストＣにおけるアグリゲーター／デアグリゲーターに相当する位置にある。この場合、実際のＣＲＮはＱＮＥ-Ｃ３である。
現在、ＭＮ１０は、ハンドオーバする前のパス（ＱＮＥ-Ａ０−ＱＮＥ-Ｂ０−ＱＮＥ-Ｃ０−ＱＮＥ-Ｃ３−ＱＮＥ-Ｃ２−ＱＮＥ-Ｂ２−ＱＮＥ-Ａ２）に沿ってＣＮ６０と通信を行っているとする。そして、ＭＮ１０がハンドオーバをすると、ＭＮ１０は新たなパス（ＱＮＥ-Ａ１−ＱＮＥ-Ｂ１−ＱＮＥ-Ｃ１−ＱＮＥ-Ｃ３−ＱＮＥ-Ｃ２−ＱＮＥ-Ｂ２−ＱＮＥ-Ａ２）に沿ってＣＮ６０と通信を行うことになる。end-to-endにおける予約状態は、それぞれハンドオーバ前ではＱＮＥ-Ａ０、ＱＮＥ-Ｂ０、ＱＮＥ-Ｂ２、ＱＮＥ-Ａ２、ハンドオーバ後ではＱＮＥ-Ａ１、ＱＮＥ-Ｂ１、ＱＮＥ-Ｂ２、ＱＮＥ-Ａ２となっている。end-to-endの場合にＣＲＮ検出が行われると、ＱＮＥ-Ｂ２がＣＲＮとして検出される。この場合の２重予約はＱＮＥ-Ｂ２と実際のＣＲＮ（ＱＮＥ-Ｃ３）との間で起こる。
ＭＮ１０が更にＣＲＮ検出をすることを決めるのであれば、検出の処理はネストＢにおいてもなされる。予約状態は、ハンドオーバ前ではＱＮＥ-Ｂ０、ＱＮＥ-Ｃ０、ＱＮＥ-Ｃ２、ＱＮＥ-Ｂ２、ハンドオーバ後ではＱＮＥ-Ｂ１、ＱＮＥ-Ｃ１、ＱＮＥ-Ｃ２、ＱＮＥ-Ｂ２とそれぞれなっている。この場合、ＱＮＥ-Ｃ２がＣＲＮとして検出され、２重予約はＱＮＥ-Ｃ２と実際のＣＲＮ（ＱＮＥ-Ｃ３）との間で起こる。実際のＣＲＮ（ＱＮＥ-Ｃ３）を検出するにはネストＣまで検出処理を行わなければならない。そのときの予約状態は、ハンドオーバ前ではＱＮＥ-Ｃ０、ＱＮＥ-Ｃ３、ＱＮＥ-Ｃ２、ハンドオーバ後ではＱＮＥ-Ｃ１、ＱＮＥ-Ｃ３、ＱＮＥ-Ｃ２とそれぞれなっている。これにより、ＱＮＥ-Ｃ３がＣＲＮとして検出され、ＱＮＥ-Ｃ３が実際のＣＲＮとなる。結果として、ＣＲＮの検出処理はこの実施の形態の場合、３回繰り返す必要がある。この繰り返す回数に関しては、通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求などに基づいてＭＮ１０又は通信ネットワーク側（例えば、通信ネットワークを管理する管理装置など）によって決定される。なお、この決定された回数の情報は、ＣＲＮ検出のための初期のシグナリングに含まれる。
次に、本発明の実施の形態に係る移動端末（ＭＮ１０）の構成について図３を用いて説明する。なお、図３では、ＭＮ１０が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。図３に示すように、ＭＮ１０は、受信手段３００、決定手段３０１、メッセージ生成手段３０２、送信手段３０３、情報格納手段３０４から構成されている。受信手段３００は、例えばＭＮ１０自身の通信相手となるＣＮ６０から送信されたメッセージやデータなどを受信する手段である。また、送信手段３０３は、例えば後述するメッセージ生成手段３０２によって生成されたメッセージやその他のデータなどを送信する手段である。
決定手段３０１は、図１で示した通信ネットワークのように、入れ子のように重なっている複数のレイヤのうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、複数のレイヤの最も外側に位置するレイヤ（図１の場合、end-to-end）から決められたレイヤまでのレイヤ数（以下、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数とも言う）を決定する手段である。なお、決定手段３０１は、複数のレイヤの最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を、例えば通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定する。また、複数のレイヤの最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定手段３０１が決定するのではなく、例えば通信ネットワークを管理する側の不図示の管理装置などが決定するようにしてもよい。
メッセージ生成手段３０２は、決定されたレイヤ数の情報を含むメッセージを生成する手段である。生成されるメッセージには、決定されたレイヤ数の情報以外に、例えばＭＮ１０を識別するための識別情報、タイムアウト情報などが含まれるようにしてもよい。ここで、タイムアウト情報とは、決定されたレイヤ数までのＣＲＮ検出の処理が終わらなくても強制的に処理を打ち切らせる時間を言い、例えば処理開始から３０秒などといった情報である。タイムアウト情報の設定により、時間のかかるＣＲＮ検出によるＱｏＳハンドオーバの遅延を解消することが可能となる。なお、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定せず、メッセージにＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を挿入しないでタイムアウト情報のみを挿入したメッセージを生成するようにしてもよい。
次に、本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて図４を用いて説明する。まず、ＭＮ１０が現在接続しているＱＮＥ-Ａ０からハンドオーバをしてＱＮＥ-Ａ１に接続する場合に、ＭＮ１０は、例えば通信ネットワークのリソース、通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定する（ステップＳ４０１）。ＭＮ１０は、決定されたレイヤ数の情報を含むメッセージを生成する（ステップＳ４０２）。そして、ＭＮ１０は、例えばＱＮＥ機能を有する新たな接続先のサブネットのＮＡＲ（New Access Router）であって、ＣＲＮ検出の処理のプロキシとして振る舞うＮＡＲに対して生成されたメッセージを送信する（ステップＳ４０３）。なお、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数は、ＭＮ１０が決定するのではなく、通信ネットワークを管理する不図示の管理装置が決定をしてＮＡＲに送信するようにしてもよい。
このように、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定して、決定されたレイヤ数をＮＡＲに送信することにより、ＮＡＲは受信したレイヤ数に基づいてＣＲＮ検出の処理を開始する。ＣＲＮを検出する方法は１つに限られるものではなく、様々な方法で検出することができる。以下では、ＣＲＮの検出の方法の一例として、非特許文献１２に示された、ＷＰＭＣ２００４という国際会議において２００４年９月に発表されたQoS Mobility Support with Proxy-assisted Fast Crossover Node Discoveryに記載された方法を挙げて説明する。
ここでは、拡張されたＱｏＳ ＮＳＬＰメッセージを使ったＣＲＮ検出の手続きの一例について図５を用いて説明する。図５は新しい上流リンクパスにおけるＣＲＮ検出のシーケンスチャートである。図５のシーケンスチャートは上述した図１の通信ネットワークに基づくものであり、プロキシは図１に示すＱＮＥ-Ａ１として説明する。まず、ＭＮ１０は、ＱＵＥＲＹ（メッセージ）をＱＮＥ-Ａ１（以下、プロキシとも言う）に送信する（ステップＳ５０１）。このとき、上述したレイヤの数の情報を含んだメッセージ（以下、メッセージＡとも言う）もプロキシに送信される。また、ＭＮ１０は、そのとき、実際のハンドオーバの前に新たな上流リンクパスに沿ってリソース情報を集めるようにプロキシに要求する。ＱＵＥＲＹメッセージは、従来のパラメータに加えて、上流リンク（ＭＮ１０からＣＮ６０）と下流リンク（ＣＮ６０からＭＮ１０）における現在のフロー識別子とセッション識別子とを含んでいる。
そして、ＭＮ１０からＱＵＥＲＹメッセージを受信すると、プロキシはＣＮ６０に対してＱＵＥＲＹメッセージを転送する（ステップＳ５０２）。このとき、メッセージＡもＱＵＥＲＹメッセージと同様に転送する。なお、レイヤ数の情報をＱＵＥＲＹメッセージに含めるようにしてもよい。また、ＣＮ６０のＩＰアドレスはフロー識別子に含まれている。上流リンクのend-to-endレイヤ上に位置するＱＮＥは、ＱＵＥＲＹメッセージとメッセージＡを取得し、ＱＵＥＲＹメッセージにリソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する（ステップＳ５０３）。それと同時にそれぞれのＱＮＥは、ＱＵＥＲＹメッセージのフロー識別子とセッション識別子のペアが上流リンクで存在する予約状態と合う（マッチする）か否かをチェックする。もし合えば、ＱＮＥはＱＵＥＲＹメッセージにインターフェースのＩＰアドレスを付加する（ステップＳ５０４）。ＱＵＥＲＹメッセージとメッセージＡがＣＮ６０に到達したとき、ＱＵＥＲＹメッセージは、end-to-endレイヤ上において現在の上流リンクパス（ＭＮ１０からＣＮ６０）と新たな上流リンクパス（プロキシからＣＮ６０）の間でオーバーラップしている（重なっている）インターフェースのＩＰアドレスを含んでいる。
ここで、メッセージＡに含まれるレイヤ数の情報が図１に示すネストＢまでのＣＲＮ検出の処理をさせる旨の情報である場合を考える。このとき、ＱＮＥ-Ｂ１はＱＵＥＲＹメッセージにリソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する。そうすると、転送されたＱＵＥＲＹメッセージとメッセージＡはＱＮＥ-Ｂ２に到達する。そして、ＱＮＥ-Ｂ２はＱＵＥＲＹメッセージにリソースが利用可能である旨の情報及びインターフェースのＩＰアドレスを付加し、上流リンクに転送する。それと同時にＱＮＥ−Ｂ２は、メッセージＡに含まれるレイヤ数の情報に基づいてネストＢ内のＣＲＮ検出を実施することを決定し（ステップＳ５０５）、処理を開始するためのメッセージをＱＮＥ−Ｂ１に向けて送信する（ステップＳ５０６）。
このメッセージ（ＱＵＥＲＹ−ｔｒｇ）は、ネストＢ内のＣＲＮ検出に必要な情報として、ＱＮＥ−Ｂ０とＱＮＥ−Ｂ２との間で確立されているフロー識別子とセッション識別子を含んでいる。また、メッセージＡも同様に送信される。なお、メッセージＡに含まれるレイヤ数の情報を、ＱＵＥＲＹ−ｔｒｇメッセージに含めてもよい。ＱＵＥＲＹ−ｔｒｇメッセージ及びメッセージＡを受信したＱＮＥ−Ｂ１は、識別子情報及びレイヤ数情報を含んだＱＵＥＲＹメッセージを、ＱＮＥ−Ｂ２に向けてネストＢレイヤ上を転送させる（ステップＳ５０７）。ネストＢレイヤでは、ＱＮＥ−Ｃ２においてフロー識別子とセッション識別子のペアがマッチするため、ＱＮＥ−Ｃ２はリソースが利用可能である旨の情報とともにインターフェースのＩＰアドレスをＱＵＥＲＹメッセージに付加し、上流リンクに転送する。
それと同時にＱＮＥ−Ｃ２は、メッセージＡに含まれるレイヤ数の情報に基づいてネストＣ内のＣＲＮ検出を実施しないことを決定する（ステップＳ５０８）。ネストＢレイヤ上のＱＵＥＲＹメッセージを受信したＱＮＥ−Ｂ２は、ＱＵＥＲＹメッセージ内のリソース利用可能情報とＩＰアドレス情報をＲＥＳＰＯＮＳＥメッセージに付加し(ステップＳ５０９)、ＱＮＥ−Ｂ１に対して送信する（ステップＳ５１０）。ＲＥＳＰＯＮＳＥメッセージは、ネストＢ上のＱＵＥＲＹメッセージにおける逆方向のパスに沿ってＱＮＥ−Ｂ１に届けられる。ＲＥＳＰＯＮＳＥメッセージを受信すると、ＱＮＥ−Ｂ１は付加されたＩＰアドレスの情報から最初に付加されたＩＰアドレスを抽出することにより、ネストＢレイヤ上のＣＲＮ（ＱＮＥ−Ｃ２）を検出する（ステップＳ５１１）。
end-to-endレイヤ上においても、同様の処理が行われる。ＱＵＥＲＹメッセージを受信すると、ＣＮ６０はＲＥＳＰＯＮＳＥメッセージをプロキシに対して送信する（ステップＳ５１２）。ＲＥＳＰＯＮＳＥメッセージには、上流リンクにおける、集められたリソースが利用可能である旨の情報と、ＱＵＥＲＹメッセージに付加されたＩＰアドレスの情報が含まれている。ＲＥＳＰＯＮＳＥメッセージは、ＱＵＥＲＹメッセージにおける逆方向のパスに沿ってプロキシに届けられる。ＲＥＳＰＯＮＳＥメッセージを受信すると、プロキシは付加されたＩＰアドレスの情報から最初に付加されたＩＰアドレスを抽出することにより上流リンクのＣＲＮ（ＱＮＥ−Ｂ２）を検出する。また、プロキシは新たな上流リンクパス上における、集められたリソースが利用可能である旨の情報を得ることもできる。
ＲＥＳＰＯＮＳＥメッセージの伝達と平行して、ＣＮ６０はプロキシにＱＵＥＲＹメッセージとメッセージＡをend-to-endレイヤ上において送信する。このＱＵＥＲＹメッセージは下流リンクにおける現在のフロー識別子とセッション識別子を含み、それらは上流リンクＱＵＥＲＹメッセージから抽出される。上流リンクにおける方法と同様に、下流リンクのシグナリングパス上におけるそれぞれのＱＮＥはＱＵＥＲＹメッセージを取得し、リソースが利用可能である旨の情報を付加し、メッセージＡに含まれるレイヤ数の情報に基づいてＱＵＥＲＹメッセージとメッセージＡを転送する。それと同時に、それぞれのＱＮＥは、ＱＵＥＲＹメッセージのフロー識別子とセッション識別子のペアが下流リンクで存在する予約状態と合う（マッチする）か否かをチェックする。
もし合えば、ＱＮＥはＱＵＥＲＹメッセージにインターフェースのＩＰアドレスを付加する。ＱＵＥＲＹメッセージがプロキシに到達したとき、ＱＵＥＲＹメッセージは、end-to-endレイヤ上において現在の下流リンクパス（ＣＮ６０からＭＮ１０）と新たな下流リンクパス（ＣＮ６０からプロキシ）の間でオーバーラップしている（重なっている）インターフェースのＩＰアドレスを含んでいる。プロキシは、付加されたＩＰアドレスの情報から最後に付加されたＩＰアドレスを抽出することにより下流リンクのＣＲＮを検出する。また、プロキシは新たな下流リンクパス上における、集められたリソースが利用可能である旨の情報を得ることもできる。下流リンクにおけるネストＢレイヤ上のＣＲＮ検出においても上流リンクにおけるＣＲＮ検出と同様に考えられる。
プロキシは、end-to-endレイヤ上に対して、ハンドオーバ後に実際の予約におけるＣＲＮやリソースの利用可能性の情報を保持する。プロキシは、ＭＮ１０がハンドオーバ先の決定でリソースが利用可能である旨の情報を利用できるようにＭＮ１０にＲＥＳＰＯＮＳＥメッセージを送信するようにしてもよい。また、ＱＮＥ−Ｂ１は、ネストＢレイヤに対して、ハンドオーバ後の実際の予約におけるＣＲＮやリソースの利用可能性の情報を保持する。
上述した方法はハンドオーバ前のＣＲＮ検出の手続き（方法）である。上述した方法は、プロキシとＣＮ６０がＣＲＮ検出と平行して予約を開始することができる。以下では、ＱＵＥＲＹメッセージとＲＥＳＥＲＶＥメッセージを使った状態の予約の手続きの一例について図６を用いて説明する。図６は新たな上流リンクパスにおける状態の予約のシーケンスチャートである。まず、ＭＮ１０は、上述した方法のＱＵＥＲＹメッセージをプロキシに送信する（ステップＳ６０１）。このとき、ＱＵＥＲＹメッセージにはハンドオーバ先で使用するＮＣｏＡが含まれている。また、上述した方法と同様に、レイヤの数の情報を含んだメッセージＡもプロキシに送信される。
プロキシは、受信したＮＣｏＡでＤＡＤ（Duplicate Address Detection:２重アドレス検出）を行い、パスすれば（問題がなければ）プロキシはＮＣｏＡの情報を含めてＣＮ６０に向けてＱＵＥＲＹメッセージを送信する（ステップＳ６０２）。それぞれのＱＮＥは上述したＣＲＮ検出と同様の方法を行う。ＱＵＥＲＹメッセージから、ＣＮ６０はend-to-endレイヤ上における上流リンクのＣＲＮ（ＱＮＥ−Ｂ２）を検出し、予約のための新たなフロー識別子がＮＣｏＡから得られる（ステップＳ６０９）。同様に、ＱＮＥ−Ｂ２はネストＢレイヤ上における上流リンクのＣＲＮ（ＱＮＥ−Ｃ２）を検出する。ＣＮ６０はＱＵＥＲＹメッセージにおける逆方向のパスに沿って、ＲＥＳＰＯＮＳＥメッセージの代わりにＲＥＳＥＲＶＥメッセージをend-to-endレイヤ上に送信する（ステップＳ６１０）。ＱＮＥ−Ｂ２はＲＥＳＥＲＶＥメッセージを受信すると、end-to-endレイヤのためのＲＥＳＥＲＶＥメッセージをＱＮＥ−Ｂ１に送信するとともに、ネストＢレイヤのためのＲＥＳＥＲＶＥメッセージをＱＮＥ−Ｂ１に向けて送信する。
インターフェースがオーバーラップしている（すなわち、end-to-endレイヤ上ではＣＮ６０からＣＲＮであるＱＮＥ−Ｂ２までの間、また、ネストＢレイヤ上ではＱＮＥ−Ｂ２からＣＲＮであるＱＮＥ−Ｃ２までの間の）ＱＮＥは、２重予約を避けるために予約状態を更新する。新たな上流リンクパス上（end-to-endレイヤ上ではＣＲＮであるＱＮＥ−Ｂ２からプロキシまでの間、また、ネストＢレイヤ上ではＣＲＮであるＱＮＥ−Ｃ２からＱＮＥ−Ｂ１までの間）における他のＱＮＥは新たな予約状態を生成する。このようにして新たな下流リンクパスにおいても同様の方法で予約状態の更新や生成を行うことができる。ＭＮ１０が実際のハンドオーバを行うときに、新たな予約状態はＭＮ１０とプロキシとの間で生成される。そして、結果として新たなend-to-endのＱｏＳパスが構築される。
ここで、ＭＮ１０又は通信ネットワークを管理する側の不図示の管理装置が、ＣＲＮの検出のための処理を行わせるレイヤまでのレイヤ数を決定する際に基礎となる通信ネットワークのレイヤ数（ネスト数とも言う）の検出方法について以下に４つ述べる。
１つ目は、アグリゲーターがＱＵＥＲＹを受信したときにカウントする方法である。具体的に図７を用いて説明する。なお、以下で説明する４つの検出方法におけるＱＵＥＲＹ（ＱＵＥＲＹメッセージ）にはカウントしたネストの数を示すネストカウント（すなわち、上位のネットワークレイヤの数を示すネストカウント）を設ける。なお、ここでのＱＵＥＲＹは、上述したレイヤ数検出メッセージに相当し、このメッセージはＭＮ１０のメッセージ生成手段３０２によって生成され、送信手段３０３によって送信される。図７に示すように、ＭＮ１０（例えば、メッセージ生成手段３０２）はネストカウントをリセット（ネストカウント＝０）する（ステップＳ７０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ネストＢのアグリゲーターであるＱＮＥ−Ｂ１は、ネストカウント＝１とカウントアップする（ステップＳ７０２）。すなわち、ネストカウントの値に１を加える。
ＱＮＥ−Ｂ１はカウントアップしたＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹを受信した、ネストＣのアグリゲーターであるＱＮＥ−Ｃ１はネストカウント＝２とカウントアップする（ステップＳ７０３）。ＱＮＥ−Ｃ１はカウントアップしたＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥ（ＲＥＳＰＯＮＳＥメッセージ）をＭＮ１０に向けて送信する。これにより、ＭＮ１０は通信ネットワークのレイヤ数を検出することができる。なお、このときＱＵＥＲＹに対するＲＥＳＰＯＮＳＥ要求は、最上層のＱＵＥＲＹにのみ付加される。後述する３つの検出方法においても同様である。
２つ目は、デアグリゲーターがＱＵＥＲＹを受信したときにカウントする方法である。具体的に図８を用いて説明する。図８に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ８０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信した、ネストＢのデアグリゲーターであるＱＮＥ−Ｂ２はネストカウント＝１とカウントアップする（ステップＳ８０２）。
ＱＮＥ−Ｂ２は受信したＱＵＥＲＹの応答として、ネストカウントの情報を含めたＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、ネストカウントの情報を含めたＱＵＥＲＹをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹを受信したネストＣのエッジに位置するＱＮＥ−Ｃ１は、ＱＮＥ−Ｃ２にＱＵＥＲＹを転送する。ＱＵＥＲＹを受信した、ネストＣのデアグリゲーターであるＱＮＥ−Ｃ２はネストカウント＝２とカウントアップする（ステップＳ８０３）。ＱＵＥＲＹを受信したＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
３つ目は、アグリゲーターがＱＵＥＲＹ−ｔｒｇを受信したときにカウントする方法である。具体的に図９を用いて説明する。図９に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ９０１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｂ１に送信する。
ＱＵＥＲＹ−ｔｒｇを受信した、ネストＢのアグリゲーターであるＱＮＥ−Ｂ１はネストカウント＝１とカウントアップする（ステップＳ９０２）。そして、ＱＮＥ−Ｂ１はＱＵＥＲＹをネストＣのＱＮＥ−Ｃ１に送信する。ＱＮＥ−Ｃ１は受信したＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信した、ネストＣのアグリゲーターであるＱＮＥ−Ｃ１はネストカウント＝２とカウントアップする（ステップＳ９０３）。ＱＮＥ−Ｃ１は、更なるネストがあるかを検出するためＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。
この例では、ＱＮＥ−Ｃ３はネストＣ内にありＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２は受信したＱＵＥＲＹをＣＮ６０に向けて転送する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
４つ目は、デアグリゲーターがＱＵＥＲＹ−ｔｒｇに対応した内部的なＱＵＥＲＹを受信したときにカウントする方法である。具体的に図１０を用いて説明する。図１０に示すように、ＭＮ１０はネストカウントをリセット（ネストカウント＝０）する（ステップＳ１００１）。ＭＮ１０はネストカウントをリセットしたＱＵＥＲＹをプロキシ（ＱＮＥ−Ａ１）に送信する。ＱＵＥＲＹを受信したプロキシはＱＵＥＲＹをＱＮＥ−Ｂ１に転送する。ＱＮＥ−Ｂ１は受信したＱＵＥＲＹをＱＮＥ−Ｂ２に転送する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ―Ｂ１に送信する。
ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｂ１は、ネストを検出するためにＱＵＥＲＹをネストＣのアグリゲーターであるＱＮＥ−Ｃ１に送信する。ＱＮＥ−Ｃ１は受信したＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。ＱＮＥ−Ｃ２はその応答としてＱＵＥＲＹ−ｔｒｇをＱＮＥ−Ｃ１に送信する。ＱＵＥＲＹ−ｔｒｇを受信したＱＮＥ−Ｃ１は、ネストを検出するためにＱＵＥＲＹをＱＮＥ−Ｃ３に送信する。ＱＵＥＲＹを受信したＱＮＥ−Ｃ３は、ネストＣ内にありそのＱＵＥＲＹをＱＮＥ−Ｃ２に転送する。
ＱＵＥＲＹを受信した、ネストＣのデアグリゲーターであるＱＮＥ−Ｃ２はネストカウント＝１とカウントアップする（ステップＳ１００２）。そして、ＱＮＥ−Ｃ２はそのＱＵＥＲＹをネストＢのデアグリゲーターであるＱＮＥ−Ｂ２に送信する。ＱＵＥＲＹを受信したＱＮＥ−Ｂ２はネストカウント＝２とカウントアップする（ステップＳ１００３）。そして、ＱＮＥ−Ｂ２はそのＱＵＥＲＹをＣＮ６０に向けて送信する。そして、ＱＵＥＲＹを受信したＣＮ６０は、例えばカウントされたネスト数の情報を含めたＲＥＳＰＯＮＳＥをＭＮ１０に向けて送信する。
なお、これら４つの検出方法におけるシグナリングは、ＭＮ１０がハンドオーバをする前でも後でも可能である。ハンドオーバをする前の場合にはプロキシを利用することになる。
以上説明したように、本発明の実施の形態によれば、ＭＮがハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のレイヤ）のうち、いずれのレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のレイヤ）の最も外側に位置するレイヤから決められたレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができる。
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えばバイオ技術の適応などが可能性としてあり得る。
本発明に係るクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末は、ハンドオーバをしてＣＲＮを検出する際、入れ子のように重なっている集合（複数のネットワークレイヤ）のうち、いずれのネットワークレイヤまでＣＲＮの検出のための処理を実行するかを決め、集合（複数のネットワークレイヤ）の最も外側に位置するネットワークレイヤから決められたネットワークレイヤまでのレイヤ数を決定することにより、ＣＲＮ検出に時間がかからず、２重予約をできるだけ少なくすることができ、ＱｏＳ破綻を避けることができるため、無線通信を行う移動端末（モバイルノード）のハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末に関し、特に、次世代インターネットプロトコルであるモバイルＩＰｖ６（Mobile Internet Protocol version 6）プロトコルを利用した無線通信を行うモバイルノードにおけるハンドオーバによるクロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末などに有用である。
本発明の実施の形態における通信ネットワークの構成を示す模式図 本発明の実施の形態における通信ネットワークの入れ子集合予約を示す模式図 本発明の実施の形態に係る移動端末の構成を示す構成図 本発明の実施の形態に係るクロスオーバノード検出前処理のフローについて説明するためのフローチャート 本発明の実施の形態の新たな上流リンクパスにおけるＣＲＮ検出の一例を説明するためのシーケンスチャート 本発明の実施の形態におけるＱＵＥＲＹとＲＥＳＥＲＶＥメッセージを使った状態予約の手続きの一例について説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の検出方法を説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャートである。 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャート 本発明の実施の形態における通信ネットワークのレイヤ数の他の検出方法を説明するためのシーケンスチャート 本発明及び従来の技術に共通した無線通信システムの構成を示す模式図 従来の技術におけるＲＳＶＰがＭＮの移動に対応不可能であることを説明するための模式図 従来の技術におけるＮＳＩＳのプロトコル構成を説明するための模式図 従来の技術におけるＮＳＩＳのノードであるＮＥやＱＮＥが「隣り合う」という概念を説明するための模式図 従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図 従来の技術におけるＮＳＩＳにおいて、どのように２重のリソース予約を回避するとされているかを説明するための模式図 通信ネットワークが入れ子状態にある場合の入れ子集合予約の一例を説明するための模式図

Claims (8)

  1. それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法であって、
    前記移動端末が、入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定するステップと、
    決定された前記レイヤ数の情報を含むメッセージを生成するステップとを、
    有するクロスオーバノード検出前処理方法。
  2. 前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数は、前記通信ネットワークを管理する管理装置によって決定される請求項１に記載のクロスオーバノード検出前処理方法。
  3. 前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数は、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定される請求項１に記載のクロスオーバノード検出前処理方法。
  4. 前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数は、
    前記移動端末によって送信される前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出される請求項１に記載のクロスオーバノード検出前処理方法。
  5. 請求項１に記載のクロスオーバノード検出前処理方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム。
  6. それぞれがサブネットを構成する複数のアクセスルータが、複数のネットワークレイヤが入れ子のように重なって構成された通信ネットワークを介して接続されており、固有の通信可能領域を形成するアクセスポイントが前記複数のアクセスルータのそれぞれに少なくとも１つ以上接続されている通信システムで、前記通信可能領域内で前記アクセスポイントとの無線通信を通じて、前記アクセスポイントが接続されている前記アクセスルータとの通信を行うよう構成されている移動端末が、移動により、現在通信中のアクセスポイントから別のアクセスポイントへ接続が切り替わる場合の、前記通信ネットワーク上の新旧の通信経路が交わり、かつ分岐するクロスオーバノードを検出するために必要な情報を取得するクロスオーバノード検出前処理方法で用いられる前記移動端末であって、
    入れ子のように重なっている前記複数のネットワークレイヤのうち、いずれのネットワークレイヤまで前記クロスオーバノードの検出のための処理を実行するかを決め、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を決定する決定手段と、
    決定された前記レイヤ数の情報を含むメッセージを生成するメッセージ生成手段とを、
    備える移動端末。
  7. 前記決定手段は、前記複数のネットワークレイヤの最も外側に位置するネットワークレイヤから決められた前記ネットワークレイヤまでのレイヤ数を、少なくとも前記通信ネットワークリソース、前記通信ネットワークのポリシー、ＱｏＳ要求の情報に基づいて決定する請求項６に記載の移動端末。
  8. 前記クロスオーバノードの検出のための処理を実行する際に基礎となる、前記入れ子のように重なっている前記複数のネットワークレイヤの数は、
    前記メッセージ生成手段によって生成された前記複数のネットワークレイヤの数を検出するためのレイヤ数検出メッセージを受信する、前記複数のネットワークレイヤの各ネットワークレイヤのエッジに位置するエッジノードが、前記レイヤ数検出メッセージを受信したときに、前記レイヤ数検出メッセージに含まれる、上位のネットワークレイヤの数を示すネストカウントの値に１を加える前記レイヤ数検出メッセージに基づいて検出される請求項６に記載の移動端末。
JP2007529520A 2005-08-03 2006-08-03 クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末 Withdrawn JPWO2007015539A1 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2005225998 2005-08-03
JP2005225998 2005-08-03
JP2006207188 2006-07-28
JP2006207188 2006-07-28
PCT/JP2006/315373 WO2007015539A1 (ja) 2005-08-03 2006-08-03 クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末

Publications (1)

Publication Number Publication Date
JPWO2007015539A1 true JPWO2007015539A1 (ja) 2009-02-19

Family

ID=37708819

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007529520A Withdrawn JPWO2007015539A1 (ja) 2005-08-03 2006-08-03 クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末

Country Status (3)

Country Link
US (1) US20100157939A1 (ja)
JP (1) JPWO2007015539A1 (ja)
WO (1) WO2007015539A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010004714A1 (ja) * 2008-07-07 2010-01-14 パナソニック株式会社 ハンドオーバ処理方法、その方法で用いられる移動端末及び通信管理装置
JP2010103745A (ja) * 2008-10-23 2010-05-06 Kddi Corp 移動ノード、アクセスゲートウェイ、ビーコン信号生成装置および移動通信ネットワークシステム
EP2433443B1 (en) * 2009-05-18 2014-12-17 Telefonaktiebolaget LM Ericsson (publ) Methods and apparatuses for a dynamic resource reservation

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4572476B2 (ja) * 2001-03-13 2010-11-04 ソニー株式会社 通信処理システム、通信処理方法、および通信端末装置、データ転送制御装置、並びにプログラム
US7339928B2 (en) * 2001-08-29 2008-03-04 Alcatel Lucent Micro-mobility network routing system and method
KR100568152B1 (ko) * 2003-10-20 2006-04-07 삼성전자주식회사 이동망 환경에서의 크로스오버 라우터 탐색방법,자원예약방법 및 이를 이용하는 자원 예약 시스템

Also Published As

Publication number Publication date
US20100157939A1 (en) 2010-06-24
WO2007015539A1 (ja) 2007-02-08

Similar Documents

Publication Publication Date Title
US7693093B2 (en) QoS-aware handover procedure for IP-based mobile ad-hoc network environments
JP4543041B2 (ja) 新規経路設定方法及び移動端末並びに経路管理装置
US20070223420A1 (en) Communication Handover Method, Communication Message Processing Method and Program for Executing These Methods by use of a Computer
Helmy et al. Multicast-based mobility: A novel architecture for efficient micromobility
JP2004536535A (ja) モバイルノード（ＭＮ）と通信先ノード（ＣＮ）との間のＩＰに基づく、特にモバイルＩＰｖ６に基づく第１および第２の通信経路間におけるＱｏＳに適応したハンドオフの実行方法
WO2005081560A1 (ja) 通信ハンドオーバ方法、通信メッセージ処理方法及びこれらの方法をコンピュータにより実行するためのプログラム並びに通信システム
US20090022106A1 (en) Crossover node detection method and crossover node detection program for causing computer to execute the method
JPWO2007119598A1 (ja) 高速ＱｏＳハンドオーバ方法及びその方法で用いられる処理ノード
JP6092179B2 (ja) 順方向リンク及び逆方向リンクのサービングアクセスポイントの変更
US20090190551A1 (en) Route Setting Method and Route Management Device
JPWO2007015539A1 (ja) クロスオーバノード検出前処理方法、この方法をコンピュータにより実行するためのクロスオーバノード検出前処理用プログラム、及びこの方法で用いられる移動端末
JP4664965B2 (ja) 通信システム及び通信ノード
WO2007061118A1 (ja) アグリゲーション管理方法、アグリゲートノード、デアグリゲートノード
EP1933508A1 (en) Aggregation management method, aggregate node, and deaggregate node
JP4750115B2 (ja) クロスオーバノード検出方法、この方法をコンピュータにより実行するためのクロスオーバノード検出用プログラム、クロスオーバノード検出方法で用いられる移動端末及び中継装置
JPWO2009037843A1 (ja) ＱｏＳリソース予約方法及びその方法で用いられる移動端末
Jeon et al. Link layer assisted multicast-based mobile RSVP (LM-MRSVP)
Lee et al. Selective establishment of pseudo reservations for QoS guarantees in mobile Internet
KR20100023205A (ko) 차세대 시그널링 프로토콜을 이용한 멀티미디어 전송 서비스 품질 보장 시스템 및 그 방법
JP2008283417A (ja) クロスオーバノード選択方法及びその方法で用いられる中継ノード

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20091006