JPWO2008013218A1 - 移動通信方法及びアクセスルータ - Google Patents

Abstract

通常のモバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させ、更にパケットロスも減少させる技術が開示され、その技術によればＭＮが移動元のＡＲ２配下から移動先のＡＲ３配下に移動する場合、ＭＮがＡＲ２に送信するＮＳをＡＲ３で受信し、ＡＲ２宛のＮＳを受信したＡＲ３がＡＲ２に対して「Location Update」を送信し、「Location Update」を受信したＡＲ２が該当ＭＮのＭＮ管理テーブルを用いて「Prefix Information」を作成してＡＲ３に返信し、ＡＲ２とＡＲ３のアクセスルータの間で「Prefix Information」を用いてトンネルを確立し、ＭＮ宛てのパケットをトンネルを介してＭＮに転送する。

Description

本発明は、移動通信方法及びアクセスルータに関する。

現在、携帯電話などの移動通信においてＩＰ通信における移動制御方法が検討されているが、１つのネットワーク管理者がサービスを行う、エリアの限定されたローカルモビリティにおいては、端末が移動時にＩＰアドレスの変更を行うこと無く移動制御を行う方法が検討されている（IETF netlmm グループなど）。このような要求においては、ネットワーク側の装置が端末の移動処理をサポートし、移動端末が接続される適切な基地局に対してＩＰパケットが転送されるように制御を行うことが必要である。具体的な要求条件を示したドラフトによると、このようなアクセスネットワークにおいては、ハンドオーバのパフォーマンスを改善するために、ネットワークの有線区間の利用効率の向上、同様に無線区間の利用効率の向上などが示されると同時に、端末のＩＰアドレスの変更を行うことなく移動制御ができることが要求されており、さらにこれらを実行するために端末のＩＰスタックに変更を加えないことが要求事項として挙げられている。

代表的な移動制御であるMobile ＩＰでは、ホストのアドレスを示すＩＰアドレス（Home Address：以下、ＨｏＡ）と、ロケーションを示すＩＰアドレス（Care-of-Address：以下、ＣｏＡ）を用いたトンネル技術により正しいロケーションにパケットが転送される。しかし、Mobile ＩＰ（ＭＩＰ）では端末自身が新たなアドレス（ＣｏＡ）の生成と、このアドレスのマッピングの登録をＨＡ（Home Agent）に行うなど、端末での処理が発生し、これがハンドオーバのパフォーマンスを低下させる要因となっている。またトンネルが端末で終端されるため、無線区間でもトンネルが使用されることになり、データに対するトンネルヘッダのオーバヘッドが問題になっている。またＭＩＰではハンドオーバのパフォーマンスを改善するために、限定されたエリアにおいて位置登録を管理するＭＡＰ（Mobile Anchor Point）を導入したＨＭＩＰも検討されている。この場合、ある限定されたエリア内では、位置登録をＭＡＰに行うだけで済むため、シグナリング距離と時間が短縮されるが、２重のトンネルヘッダが必要になり、ネットワークのリソースが減少するほか、端末が新たにＭＡＰに対するシグナリングを行う必要があるため、端末のＩＰスタックに変更を加える必要がある。このため、前述したような、１つのネットワーク管理者がサービスを行うアクセスネットワークにおいて、端末に変更を加えることなくローカルモビリティを効率的に行うための各種提案がなされている。

図６は下記の非特許文献１に示すアクセスネットワークの構成を示したものである。アクセスネットワークであるＬＭＭＤ（Localized Mobility Management Domain）＃１は、相手先（Correspondent Node：以下、ＣＮ）が接続される外部ネットワーク（External Network）との接続点となるボーダーゲートウェイ（ＢＧ）と、モバイル端末（Mobile Node：以下、ＭＮ）を接続する無線基地局機能を有するアクセスルータ（ＡＲ＃１、ＡＲ＃２、ＡＲ＃３）が中継装置として接続されるネットワークである。本例では説明を簡単にするためアクセスルータと無線基地局（ＢＳ若しくはＡＰ）が同一の装置の機能として提供されているとする。このようなネットワークの領域を以降、「Netlmm」ドメインと呼ぶ。

このNetlmmドメインでは、各ＡＲ＃１、ＡＲ＃２、ＡＲ＃３は、それぞれ異なるプレフィックス（prefix#1、prefix#2、prefix#3）を有しており、さらにそれぞれのＡＲ＃１、ＡＲ＃２、ＡＲ＃３は、「prefix#1」、「prefix#2」、「prefix#3」より、その「prefix#1」、「prefix#2」、「prefix#3」を有するＡＲ＃１、ＡＲ＃２、ＡＲ＃３のＩＰアドレスを取得できるテーブルを有している。

図６において、
１．ＭＮ＃１は起動時に、接続したＡＲ＃１から「prefix#1」を取得し、自身のＩＰアドレス（ＩＰ−ＭＮ＃１）を生成する。このときのＡＲ＃１をＨＡＲ（Home Access Router）と呼ぶ。ＭＮ＃１はルーティング可能な「prefix#1」より生成したＩＰアドレス（ＩＰ−ＭＮ＃１）を用いて通信するため、ＨＡＲ配下に接続している場合は、ＣＮとの通信においてトンネルを用いることなく通常のＩＰルーティングによる通信を行うことが可能である。

ＭＮ＃１が他のＡＲ配下に移動した場合、次の処理が発生する。
２．ＭＮ＃１が移動前のＡＲ＃１からの切断を認識してルータ要請（Router Solicitation）メッセージ（以下、ＲＳと言う）を送信して新しいＡＲからルータ広告（Router Advertisement）メッセージ（以下、ＲＡと言う）を受信した場合や、新しいＡＲからの定期的なＲＡを受信するなどして、異なる「Prefix」を受信した場合、ＭＮ＃１は自身が他のＡＲ（ここではＡＲ＃２）配下に移動したことを認識する。このとき、ＭＮ＃１は自身が使用しているGlobal ＩＰアドレスを用いて、通信を行いたいということを示すメッセージ（Activate message）を送信する。

３．これを受信したＡＲ＃２は、使用されているGlobal ＩＰアドレスより「Prefix#1」を認識して、該当「Prefix#1」を有するＡＲ＃１に対して位置更新のメッセージ（Location Update）を送信する。このようなＡＲ＃２をＶＡＲ（Visited Access Router）と呼ぶ。
４．これを受信したＨＡＲ（＝ＡＲ＃１）は自身の配下にいたＭＮ＃１がＶＡＲ（＝ＡＲ＃２）配下に移動したことを認識して、ＨＡＲ（＝ＡＲ＃１）とＶＡＲ（＝ＡＲ＃２）間にトンネルを構成し、ＭＮ＃１宛のパケットを受信するとトンネルを用いてＶＡＲ（＝ＡＲ＃２）に転送を行う。これによりＶＡＲ（＝ＡＲ＃２）は受信したＭＮ＃１宛のパケットを自身の配下に接続しているＭＮ＃１に送信することができる。このようにＨＡＲとＶＡＲのトンネルを用いることでＭＮは「Netlmm」ドメイン内では、常に同じＩＰアドレスを使用して通信を継続することが可能となっている。

図７に、ＭＮ移動時のトンネルを使用した通信の概要を示す。図７の（ａ）に示すようにＭＮの電源を入れて起動（Power on）したとき、ＭＮは接続したＡＲ１から「Prefix1」を取得しアドレスＩＰ１を生成する。その後、図７の（ｂ）に示すようにＭＮが移動によりＡＲ２に接続すると（Start Communication）、ＭＮはＩＰ１を用いた「Activate Message」を送信する。これによりＡＲ２はＭＮのＶＡＲとして動作し、ＡＲ１とＡＲ２間にトンネルが構成される。ここで、ＭＮがＡＲ２配下にいるときにＣＮと通信を始めたとしても、ＡＲ１とＡＲ２のトンネルを用いて通信を行う。さらに図７の（ｃ）に示すようにＭＮがＡＲ３配下に移動すると（Continue Communication）、ＡＲ３がこのＭＮのＶＡＲとなり、ＡＲ１とＡＲ３間にトンネルを変更することでＩＰ１宛のパケットの転送が行われることになる。このようにして、ＭＮは「Netlmm」ドメインを移動する場合、ＩＰアドレスの変更を行うことなく通信を継続することができる。
また、他の従来例として、近隣発見について下記の非特許文献２に記載されている。
draft-diaretta-netlmm-protocol-00-txt, Figure 1 - Reference architecture, October 14, 2005, RFC2461

しかし、「Netlmm」がＭＮの構成を変更しないことを要求しているのに対し、このような方法を用いた場合、ＭＮが移動時に自身の使用したいＩＰアドレスを「Activate Message」として通知する必要があり、ＭＮの構成を変更することを必要とするという課題がある。

「Netlmm」の要求事項に従って、構成が変更されていない通常のＭＮを使用した場合、以下のような動作が考えられる。通常、ＭＮは新しい「Prefix」を受信した場合、その「Prefix Option」中のＡビットがセットされている場合は新しいＩＰアドレスを生成し、重複アドレス検出（Duplicate Address Detection：以下、ＤＡＤ）を行う。この場合、新しいアドレスのＤＡＤを確認するための近隣要請（Neighbor Solicitaion）メッセージ（以下、ＮＳ）を受信したＡＲは、ＭＮの移動を認識することができず、そのＭＮの該当するアドレスのＨＡＲとして動作すると考えられる。しかし、この場合、ＭＮは異なるネットワークに移動したとしてＭＩＰの実装されているＭＮであれば、ＣｏＡを変更し、結合更新（Binding Update）メッセージ（以下、ＢＵ）をＨＡに送信する。

非特許文献２に示す、ネットワークの移動の検知を行うＤＮＡ(Detecting Network Attachment)を使用していると考えた場合、ＭＮは異なるネットワークに移動したという認識を行うことはないが、新しいＩＰアドレスを生成してＤＡＤを行うことに変わりはない。この場合も、ＭＮは移動するたびにＩＰアドレスを生成し、複数のＩＰアドレスを保持していくことになる。このような場合、ＭＮが移動前のアドレスを用いて通信を行う（若しくは行っている）ことも考えられる、このような場合は、該当する「Prefix」を持つＡＲとの間にトンネルを構成し、パケットの転送を正しく行う必要がある。しかし、通常、移動先のＡＲではＭＮから移動前の「Prefix」を用いたパケットを受信するまで、どのＡＲをＨＡＲとしたアドレスを用いてＭＮが通信を行っているのか知ることはできない。このため、ＭＮからのデータ受信があるまで、トンネルは構成されることがなく、パケットロスを発生させることになる。さらにネットワークはＭＮがどのＩＰアドレスを使用するのか制御することはできないため、ＭＮが使用する複数のＩＰアドレスに対して多くのトンネルを構成し、移動のたびにトンネルの再構成を行うなど制御のシグナリング量が増加するという課題を生む。

以下に、「Netlmm」の要求事項を満足するために通常のＭＮを用いた場合の動作を説明する。図８に移動時の通信の概要を示し、図９に移動時のシーケンスを示す。図８ではＡＲ１〜ＡＲ５までのＡＲがあり、ＭＮはＡＲ１で起動し、ＡＲ５の方向に移動している。ＭＮは移動のたびにＡＲ１〜ＡＲ５から受信する「Prefix」を用いてアドレスを生成し、このアドレスを用いて通信を行っている。図８の（ａ）はＭＮがＡＲ３配下で通信を行っている状態を示す。このときＭＮはＡＲ１、ＡＲ２、ＡＲ３のそれぞれに接続中に、それぞれのアドレスを用いて通信を開始したと仮定する。このため、アドレスＩＰ１、ＩＰ２、ＩＰ３のＨＡＲはそれぞれＡＲ１、ＡＲ２、ＡＲ３となり、それぞれの通信についてＶＡＲとなるＡＲ３との間にトンネルを構成し通信を行う。

ＭＮがＡＲ５まで移動した状態を図８の（ｂ）に示す。３つの通信が継続されている場合、ＡＲ５ではＭＮからのデータを受信するたびに、「Prefix」からＨＡＲとなるＡＲを認識し、トンネルの再構成を行う。アドレスＩＰ４を用いた通信を行っていなかった場合、ＡＲ４との間にトンネルが構成されることはない。このように、ＭＮが移動するたびに生成するアドレスが増えていくため、ＭＮに使用されるＩＰアドレスが増えるにつれて、移動時のトンネルの再構成の負荷が大きくなっていく。

また図９に移動時のシーケンスを示している。この図ではＡＲ２配下で通信を行っていたＭＮがＡＲ３配下に移動してきたときの処理の流れを示している。ＭＮはＡＲ２の前にＡＲ１に接続しており、そのときのアドレスＩＰ１を用いて通信を行っていたとする。ＡＲ２からＡＲ３へのレイヤ２のハンドオーバ（L2 HO from AR2 to AR3）が終了すると、それまでデフォルトルータ（ＤＲ）であったＡＲ２への接続がなくなる。このため、ＭＮはＡＲ２との接続を確認するため、ＮＳをＡＲ２宛に送信する。このＮＳに対して応答を行うＡＲ２はもはやＭＮと接続関係にないため、ＭＮは応答パケットを受信することはなく、３回のＮＳの失敗によりＤＲ（＝ＡＲ２）との接続が切れたことを認識する（Detect unreachability to AR2）。

その後、ＭＮは新しいリンクでのルータ情報を取得するためにＲＳを送信し、ＡＲ３により応答されるＲＡにより新たに「Prefix3」のリンクにいることを確認する。このときＤＮＡにより同じ「Landmark Option」を用いるなどして「IP link」の変更がないことを認識させることはできる。ＭＮは受信した「Prefix3」よりアドレスＩＰ３を生成する（Create new IP address）。このときＭＮのＩＰアドレスの状態は、「望ましい（Preferred）ステート」／望ましくない（Deprecated）ステート」のうち、ＩＰ１、ＩＰ２、ＩＰ３がすべて「Preferred」で保持されている。このためＭＮはどのアドレスを新規の通信に用いることも可能である。

ＭＮはアドレスＩＰ３の生成後、ＤＡＤによりアドレスの重複がないかを確認する。これによりＡＲ３は自身がＩＰ３のＨＡＲになることを認識する。その後、ＭＮが通信中のデータパケットを出力したタイミングで異なる「Prefix」を用いるＩＰアドレス（ＩＰ１）があることをＡＲ３は認識する。これにより該当ＭＮの他のＨＡＲ（＝ＡＲ１）をあらかじめ設定されているテーブルより取得し、ＨＡＲ（＝ＡＲ１）に対してＩＰ１の「Location Update」を行う。これによりＩＰ１に関しては新しく移動したＡＲ３へのトンネルが構成され、通信が再開できる。

しかし、このときＭＮが送信するパケットが少ないアプリケーションを用いて通信を行っていた場合（ＭＮが受信するデータがほとんどのＵＤＰ（User Datagram Protocol）アプリケーションなどである。）、ＭＮがデータ（Data (IP-1)）を出力するまでＡＲ３はそのアドレスをＭＮが使用して通信を行っていることを知ることはできない。このため図９に示すようにＩＰ２に関しては、これまで通りＡＲ２が受信するＩＰ２宛のパケットは転送先が不明のまま廃棄されることになる。ＭＮがＩＰ２をソースアドレスに持つパケットを送信して初めてＡＲ３はＡＲ２と通信の必要性があることを認識してトンネルを構成することになる。このように、変更のない通常のＭＮを用いた場合、複数のトンネルの移動管理を行うためのシグナリングが増えるだけでなく、移動して即座にトンネルの再構成を行うことができないためパケットロスを増加させることになる。

本発明は上記の問題点に鑑み、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができる移動通信方法及びアクセスルータを提供することを目的とする。

本発明の移動通信方法は上記目的を達成するために、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信方法において、
前記モバイルノードが前記第１のアクセスルータに対して接続確認のパケットを送信するステップと、
前記第２のアクセスルータが前記第１のアクセスルータに対して出力された接続確認のパケットを受信するステップと、
前記接続確認のパケットを受信した前記第２のアクセスルータが受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信するステップと、
前記位置更新メッセージを受信した前記第１のアクセスルータが前記第２のアクセスルータに対して、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を送信するステップと、
前記第１、第２のアクセスルータの間で構成されているトンネルに対して、前記プリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送するステップと、
前記第１、第２のアクセスルータの間のトンネルを介して転送された前記パケットを前記第２のアクセスルータから前記モバイルノードに転送するステップとを、
備えた方法とした。
この方法により、モバイルノードの移動時のトンネルの再構成のためのシグナリングを移動先の第２のアクセスルータから第１の移動元のアクセスルータに行うので、シグナリングを減少させることができ、さらにパケットロスも減少させることができる。

また、本発明の移動通信方法は、前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記第２のアクセスルータから前記モバイルノードに対して、前記第２のアクセスルータ自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信するステップと、
前記モバイルノードが前記ルータ広告メッセージ中の前記第２のアクセスルータのプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するステップとを、
更に備えた方法とした。
この方法により、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができる。

また、本発明の移動通信方法は、前記アクセスルータは、自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信することを特徴とする。
また、前記第１のアクセスルータは、自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信することを特徴とする。
また、移動元アクセスルータである前記第１のアクセスルータは、移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記第１のアクセスルータ自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする。
この方法により、トンネルを削減することができる。

また、本発明のアクセスルータは、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第２のアクセスルータであって、
モバイルノードが前記第１のアクセスルータに対して送信する接続確認のパケットを受信する手段と、
前記受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信する手段と、
前記位置更新メッセージに応答して前記第１のアクセスルータが送信した、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信する手段と、
前記第１のアクセスルータの間で構成されているトンネルに対して、前記受信したプリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送する手段と、
前記トンネルを介して転送された前記パケットを前記モバイルノードに転送する手段とを備えた。
この構成により、モバイルノードの移動時のトンネルの再構成のためのシグナリングを移動先の第２のアクセスルータから第１の移動元のアクセスルータに行うので、シグナリングを減少させることができ、さらにパケットロスも減少させることができる。

また、本発明のアクセスルータは、前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記モバイルノードに対して、自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信する手段を更に備え、
前記モバイルノードが前記ルータ広告メッセージ中の前記自身のプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するようにしたことを特徴とする。
この構成により、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができる。
また、本発明のアクセスルータは、自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信する手段を更に備えた。

また、本発明のアクセスルータは、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第１のアクセスルータであって、
自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信する手段を備えた。
また、本発明のアクセスルータは、移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする。
この構成により、トンネルを削減することができる。

本発明によれば、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができる。また、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができ、さらに、トンネルを削減することができる。

本発明に係る移動通信方法及びルータの一実施の形態の通信シーケンスを示す説明図 図１のアクセスルータにおけるＭＮ管理テーブルの一例を示す説明図 図２のＭＮ管理テーブルの状態であるネットワークを示す説明図 図１のアクセスルータが送信するルータ広告メッセージを示す説明図 図１の移動通信方法及びアクセスルータの動作を示す説明図 従来の移動通信方法の通信シーケンスを示す説明図 図６の移動通信方法の通信シーケンスを詳しく示す説明図 図６の移動通信方法の課題を示す説明図 図６の移動通信方法の他の課題を示す説明図

以下、図面を参照して本発明の実施の形態について説明する。図１は本発明に係る移動通信方法及びアクセスルータの一実施の形態の通信シーケンスを示す説明図である。図１は図９と同様に、ＭＮが移動元のＡＲ２（ｏＡＲ）から移動先のＡＲ３（ｎＡＲ）へ移動したときの動作を示したものである。このため、ＭＮはＡＲ３に移動する前は、ＡＲ１、ＡＲ２からの各「Prefix」に基づいてそれぞれＩＰ１、ＩＰ２を生成してＩＰ１、ＩＰ２のステートを「Preferred」に設定している。本発明では、各ＡＲ１、ＡＲ２、ＡＲ３は「promiscuous」モードで動作し、ＭＮからのすべてのフレームを受信すると仮定する。
１．これにより、ＡＲ３はＭＮからＡＲ２宛のＮＳパケットを受信する。ＮＳパケットの宛先アドレスとしては、ＡＲ２のリンクローカルアドレスが使用されており、各ＡＲ１、ＡＲ２、ＡＲ３がリンクローカルアドレスとＡＲ１、ＡＲ２、ＡＲ３のＩＰアドレスをマッピングしたテーブルをあらかじめ設定して保持しておくことで、ＭＮがどのＡＲから移動してきたかを認識することができるようになる。

２．移動元のＡＲ（ｏＡＲ）がＡＲ２であることを識別したＡＲ３は、ＡＲ２に対して「Location Update」を送信する。このとき「Location Update」に含まれるのは、ＭＮの「Link Local IP address」と、ＭＮ ＩＤとしてＭＮの「Link Layer」のアドレス（ＭＡＣアドレス）などである。
３．「Location Update」を受信したＡＲ２は、該当ＭＮのＭＮ管理テーブル（後述する図２）を用いて 「Prefix Information」を作成し、ＡＲ３に返信する。「Prefix Information」の内容については後述（図４）する。
４．ＡＲ３はこの「Prefix Information」により、該当ＭＮが現在使用している（使用する可能性のある）ＩＰアドレスを知り、ＭＮ管理テーブルに該当ＭＮのエントリを作成し追加する。
５．このとき、ＡＲ２とＡＲ３間には、「Prefix Information」で通知したＭＮのすべてのＩＰアドレスに関してトンネルのマッピングが構成され、ＭＮ宛のパケットがＡＲ２からトンネルを介してＡＲ３へ転送され始める。このトンネルにより、ＭＮは自身の使用するＩＰアドレスをＡＲ３に通知することなく、使用していたすべてのＩＰアドレス宛のパケットに関してＡＲ２から転送されてくることになる。

６．その後、ＡＲ３は「Prefix Information」を用いてＭＮに対して、後述（図４）するタイプ２（RA_Type2）のＲＡメッセージを送信する。この「RA_Type2」のＲＡメッセージには、通常のＡＲ３の「Prefix」以外に、ＡＲ２の「Prefix」及びその他のトンネルを使用して通信を継続しているアドレスの「Prefix」も含まれる。さらに常に同じ「IP Link」にいるという認識をＭＮに持たせるために、Ａビットのセットされていない「Netlmm」ドメインに共通の「Prefix」を含んでいる（詳細は図４を用いて後述する）。
７．「RA_Type2」のＲＡメッセージを受信したＭＮは、「Prefix Option」に含まれる、新しいＡＲ３の「Prefix」を認識すると、これを用いてアドレス（ＩＰ３）を生成する。
８．ＭＮは、ＤＡＤ（ＮＳ ｆｏｒ ＤＡＤ）を実行する。ＡＲ３はこのＤＡＤのパケットを用いて、新たにＭＮのＭＮ管理テーブルにＩＰ３の情報を追加する。

ここで、６．で「RA_Type2」のＲＡメッセージを受信したＭＮは、その他の「Prefix Option」により、７．で自身の保有するＩＰアドレスのステートの変更を行う。図１の場合、新たに受信するＡＲ３の「Prefix」以外は図４に示す「Preferred Life Time」（PL Time）が０であるため、アドレスのステートは「Preferred」から「Deprecated」に変更になる。「Deprecated」になったＩＰアドレスに関しては、「ＭＮが新たなコネクションを生成する場合に使用するべきでない」ことがＲＦＣ２４６１に規定されている。これは、ＭＮが新たに通信を開始する場合は、トンネルを生成する必要のない現在接続中のＡＲから取得した「Prefix」を用いたＩＰアドレスを用いることを示しており、新たな通信に関して効率的な通信ができることを示している。ただし、「Deprecated」になったアドレスでも継続中の通信に使用することは可能である。このため、通信を継続しているＩＰアドレスについては、アドレスを保持する必要がある。本発明では、従来技術と異なり、「prefix option」の「Valid Time」を「Infinity」に設定しない。このためＡＲは該当「Prefix」に関して、ＭＮが使用を継続する場合は、「Valid Time」が満了（expire）する前に該当「Prefix Option」を含むＲＡメッセージを送信して、「refresh」する必要がある。

本発明では、ＭＮの使用するＩＰアドレス（Prefix情報）を接続中のＡＲが管理することで、必要なＲＡを生成し、ＭＮのアドレス状態（「Preferred」／「Deprecated」）をコントロールする。これにより、ＭＮ内部のアドレス状態に依存することなく、ネットワーク側でトンネル生成と維持をコントロールすることが可能となる。また常に接続中のＡＲがＭＮとトンネルの情報を管理していることで、移動時にはこれまでのように、すべてのＨＡＲにシグナリングを行う必要はなく、移動元のＡＲにのみ通知を行うことで、トンネルの延長と必要な「Prefix」情報を取得することが可能となり、トンネルの再構築のためのシグナリングを減少させることが可能となる。また、ＭＮが出力するｏＡＲ（ＡＲ２）の接続確認を行うためのＮＳパケットをｎＡＲ（ＡＲ３）の発見のために使用するため、シグナリングの開始が早く、ＭＮからのデータの送信がなくても、すべてのアドレスのためのトンネルのマッピングを構築することができるので、パケットロスを減少することが可能となる。またＭＮ宛のすべてのデータは移動元ＡＲ（ＡＲ２）まで送信されているため、移動時に移動元ＡＲ（ＡＲ２）でのみパケットのバッファリンクを行っておくことでパケットロスを減少させることも可能である。

次に図２を用いて、ＡＲが管理するＭＮ管理テーブルについて説明する。ここで、図２は一例として、図３に示す構成のネットワークにおけるＡＲ３の管理するＭＮ管理テーブルを示す。ＭＮ管理テーブルではＭＮ別（図３に示す構成ではＭＮ１、ＭＮ２、ＭＮ３別）にエントリがある。各フィールドについて以下に説明する。ＭＮ ＩＤはＭＮを示す固有のＩＤ（例えばＭＡＣ／ＬＬ address）である。オン・リンク・フラグ（On Link Flag）は現在そのＭＮが自身（ここではＡＲ３）に接続しているかどうか（図３に示す構成ではＭＮ１、ＭＮ２が接続中：On Link Flag＝１、ＭＮ３が非接続：On Link Flag＝０）を示している。これは自身で接続の確認ができなくなった場合、および他のＡＲから「Location Update」を受信した場合に、On Link Flag＝０に変更される。

リフレッシュ・タイマ（Refresh Timer：ＲＴ）はＭＮ別に構成されたタイマであり、自身の「Prefix」から生成されたアドレス以外のアドレスが使用されている場合に、その有効ライフ・タイマ（Valid Life Timer）（図４のVL Timer）をコントロールするためのタイマである。ＲＴはＲＡの「Prefix Option」に使用される値を基準として「expire」までの時間を示している。「トンネルを使用しているＩＰアドレス」（IP address(es) using tunnel）は、他のＡＲからのトンネルにマッピングされているＩＰアドレスを示している。このアドレスより、接続中のＡＲは「refresh」のための「Prefix」情報を取得することができる。次の「本ＡＲにより生成されたＩＰアドレス」（IP address generated by this AR）は、接続中のＡＲから取得した「Prefix」で生成されたＩＰアドレスを示している。

トランスミッション・タイマ（Transmission timer）は前記接続中のＡＲから取得した「Prefix」で生成されたＩＰアドレスのパケットが送受信されてからトンネルを削除するまでの残り時間を示している。このタイマは初期値が０で、パケットが送受信されるたびに所定のトンネル維持時間（Tunnel Life time）にリセットされ、時間の経過と共に減少する。つまりこの値が０を示している場合、一度も通信が行われていないか、通信が終了してから所定のトンネル維持時間以上が経過していることを示している。

具体的に図２の場合を説明する。ＭＮ１は図３に示すように、ＡＲ１配下からＡＲ２配下→ＡＲ３配下と移動してきたＭＮであり、ＡＲ１とＡＲ２に接続中に通信を開始してそれが継続している。図２のテーブルでは接続中（On Link）であり、トンネルを使用しているのがＭＮ１−１とＭＮ１−２の２つのアドレスであることを示し、アドレス維持のための「refresh」まで３５分４０秒（＝Refresh Timer）残っていることを示している。さらにＡＲ３のPrefixを用いて生成したアドレス（IP address generated by this AR）はＭＮ１−３であり、このアドレスを用いた通信は、一度も行われていないか、若しくは通信後トンネル維持時間以上が経過していることを示している（Transmission timer＝０）。

次にＭＮ２に関しては、「On Link」であり、他のアドレスを使用したトンネルはないことを示している 。またＡＲ３から生成したアドレス（IP address generated by this AR）はＭＮ２−３であり、このアドレスを使用したトンネル維持時間（Transmission timer）は残り５５分１２秒である。

ＭＮ３に関しては、自身（ＡＲ３）に接続していない端末であることを示している（On Link Flag＝０）。ＭＮ３は自身に接続していないため「Refresh」のためのＲＡをＡＲ３が出力する必要はなく、「Refresh timer」は使用されない。またＭＮ３がＡＲ３配下で生成したアドレス（IP address generated by this AR）はＭＮ３−３であり、「Transmission Timer」が「expire」していないので（Transmission Timer＝１５分５６秒）、まだトンネルを維持する必要があることを示している。

「On link」でないＭＮの「Transmission Timer」が「expire」した場合、これはネットワーク側でこれ以上このトンネルの維持を行う必要がないことを示している。このため、ＡＲは接続されているトンネルの相手となるＡＲに対し、該当ＭＮのトンネルのマッピングを削除するようにメッセージを送信する。これを受信したＡＲは自身に該当ＭＮが接続していない場合（トンネルがさらに続く場合）、自身のＭＮ管理テーブルから該当アドレスを削除して、さらにトンネルの接続先のＡＲに同様にマッピングの削除メッセージを送信する。あるＭＮに関して管理対象となるすべてのアドレスが削除された場合、そのＡＲは該当ＭＮのエントリを削除する。

次に図４を用いてＡＲが出力するＲＡメッセージについて説明する。本発明では、ＡＲは３つのタイプ（RA_Type1、RA_Type2、RA_Type3）のＲＡメッセージを送信する。「RA_Type1」は、標準で使用される定期的に出力されるＲＡメッセージの内容である。本発明では、デフォルトで２つの「Prefix Option」を有している。１つがＡＲ自身の「Prefix」（nAR's prefix）であり、ＭＮがこの「Prefix」を用いてＩＰアドレスを生成することを示すＡビットをセットし、さらに「Preferred Life time」（PL time）と「Valid Life time」（VL time）には、アドレスをリフレッシュするための時間である「Refresh Time」（ＲＴ）を規定して使用する。この値ＲＴは定期的に送信する「RA_Type1」のＲＡの間隔よりも十分長い時間を設定するため、通常、接続中のＡＲから受信する「prefix」に関しては、常に受信時にリフレッシュされることになる。またこのＡＲに固有の「Prefix」以外に、この「Netlmm」ドメインで共通の特別な「prefix」（Special prefix of this netlmm domain）を使用する。この「Prefix」にはＡビットを設定しない。これによりＭＮはこの「prefix」を用いてアドレスを生成し、使用することはない。ただし、「Prefix」リスト中で管理されるため、移動時に同じ「prefix」を受信することで、同じ「IP Link」にいると認識することが可能になる（図４に記載の＊１）。

「RA_Type2」のＲＡは前述したように、本発明のポイントとなる部分であり、ｏＡＲからのＰＩ受信時に送信される。「RA_Type2」では「RA_Type1」の「nAR's prefix」と「Special prefix of this netlmm domain」に加えて、移動元のＡＲ（ｏＡＲ）の「prefix」（oAR's prefix）と、トンネルを使用している場合、その使用しているＩＰアドレスの「Prefix」（Other Prefix(es) using tunnel）に関しても「Prefix Option」で通知される。移動元となるｏＡＲのprefix（oAR's prefix）に関しては、Ａビットはセットされるが、「Preferred Life time」は０に設定される。これにより、ＭＮは移動すると必ず、移動元（ｏＡＲ）で生成したアドレスのステートを「deprecated」に変更することになる。そのため、新たに接続先のｎＡＲから生成したアドレスのみが「preferred」のステートとなり、ＭＮは新たな通信を開始する場合に、現在接続しているＡＲ（ｎＡＲ）のアドレスを用いて通信を行うことになる。このため、新しい通信はトンネルを用いないでパケットの転送を行うことが可能となり、ネットワークリソースを有効に使用することができる。また、古い通信は終了すると、そのアドレスを使用した通信がＭＮから開始されないためトンネルを使用した通信はだんだんと無くなっていく。

また、このｏＡＲの「prefix」の「Valid Life time」（図４に記載の＊２）について説明すると、これはｏＡＲから受信した「Prefix information」の内容によって変化する。ｎＡＲ（図１ではＡＲ３）から「Location Update」を受信したｏＡＲ（図１ではＡＲ２）は、以下の情報を「Prefix Information」としてｎＡＲに通知する。
（１）トンネルを使用しているＩＰアドレス
（２）ｏＡＲから生成されたＩＰアドレス
（３）伝送状態「Transmission state」

「Transmission state」は、（２）で示されたｏＡＲで生成されたアドレスのトンネル維持状況を示す。具体的には「Location Update」を受信したときの「Transmission timer」が０か０でないかを示している。「Transmission state」が０の場合、つまり「Transmission timer」が０であった場合、これはｏＡＲ配下で生成したアドレスに対してトンネルの生成、維持を行わないことを示している。このため、ｏＡＲの「prefix」の「Valid Life time」については、「Transmission state」が０の場合には「Valid life time」＝０に、１の場合には「Refresh Time」（ＲＴ）の値を用いて通知する（図４に記載の＊２）。「Valid Life time」＝０は現状の標準仕様では、そのアドレスを「invalid」にして削除するのではなく、単に値の更新をしないことを意味する。このため、移動時に一度「Valid Life time」＝０をセットされた「prefix」に関しては、それ以前にｏＡＲに接続中に受信した値が「expire」するのを待つだけの処理となる。

また、「Transmission state」が１の場合、これはトンネルの維持生成を行う必要があることを示しており、（１）に示したトンネルを使用しているＩＰアドレスと同様の処理となる。その（１）のトンネルを使用しているＩＰアドレスであるが、これらのアドレスの「prefix」に関しては、Ａビットをセットし、「Preferred Life time」＝０、「Valid Life time」＝ＲＴの設定で通知される。ただし、「Prefix Information」の中に、このアドレスが含まれない場合は、この「Prefix Option」は使用されない。これはｏＡＲとｎＡＲ間のトンネルにマッピングされるＩＰアドレスを示しており、既に「preferred」の状態ではあるが、通信を継続しているアドレスである。このため「Valid Life time」が通信中に「expire」しないように、「refresh」する必要がある。

ＭＮ中の「deprecated」アドレスの「refresh」のタイミングであるが、「RA_Type2」に示すように、新しいＡＲに移動時に必ず「refresh」を行う。こうすることで個別のアドレスのタイマ管理を行うことなく、接続中のＡＲのみが一貫してＭＮのアドレスステートの管理を行えばよいことになる。このＭＮの内部のアドレスステート管理と、実際のネットワーク中のトンネルの管理が独立していることが特徴である。

またＡＲは自身の「Refresh timer」が「expire」すると、そのときにテーブルに設定されている「IP address using tunnel」のＩＰアドレスに関する「prefix」のみに対して、「RA_Type3」のメッセージを送信してＭＮのアドレスステートの更新を行う。例えば、「Prefix Information」で「IP address using tunnel」が何もなく、「transmission state」も０である情報を受信したｎＡＲの場合、新たにＭＮのエントリを図２に示すＭＮ管理テーブルに追加するが、「refresh timer」と「IP address(es) using tunnel」のフィールドには何も入らない。ＭＮが自身の「Prefix」を用いてアドレスを生成し、ＤＡＤを行ってきた場合にそのアドレスを「IP address generated by this AR」に追加するだけである。

このように、本発明では、ｎＡＲがｏＡＲから必要な情報のみを引き継ぎ、ＭＮのアドレス状態の管理をＲＡを用いて行うと同時に、必要最小限のトンネルを構成することになる。具体的な動作例を図５を用いて説明する。図５にはＭＮが起動してからの動作が示してある。図５の（ａ）は起動（Power on）時を示し、ＭＮはＡＲ１配下でＡＲ１の「Prefix1」を用いて最初のアドレスＩＰ１を生成し、また、ＩＰ１のステートは「preferred」である。ただし、このとき通信は行っていない。

図５の（ｂ）でＭＮはＡＲ２配下に移動後、ＡＲ２からの「RA_Type2」のＲＡによりアドレスＩＰ１のステートを「preferred」から「deprecated」にして、ＡＲ２の「Prefix2」を用いて生成したアドレスＩＰ２のみが「preferred」のステートになる。このとき通信を始めたＭＮはアドレスＩＰ２を使用して、通信を行う。このため、ＨＡＲはＡＲ２であり、従来技術のようにＡＲ１とＡＲ２の間にトンネルを構成することなく通信を行うことができる。このときアドレスＩＰ１に関しては通信を行っていなかったため、「transmission state」＝０であり、移動後は一度も「valid timer」が「refresh」されることはない。またＡＲ２のＭＮ管理テーブルにはアドレスＩＰ２の情報しか入らないため（ＩＰ１がトンネルを使用する状態でないため：「transmission state」＝０）、ＡＲ２は「refresh」の管理を行うアドレスはなく、「refresh timer」も動作しない。

次にＭＮがＡＲ４まで順に移動した様子を図５の（ｃ）に示す。ＭＮは各ＡＲ１〜ＡＲ４からの「prefix1」〜「prefix4」により、それぞれアドレスＩＰ１〜ＩＰ４を生成している。ただしＡＲ４に接続時点で「preferred」状態のアドレスはＩＰ４のみである。図５の（ｃ）では、ＡＲ２配下とＡＲ３配下で生成したアドレスでも通信が継続しており、ＡＲ２−ＡＲ３間、ＡＲ３−ＡＲ４間のトンネルにそれぞれのアドレスＩＰ２、ＩＰ３がマッピングされて転送されている。また、この時点では通信が継続しているため、ＡＲ４はアドレスＩＰ２、ＩＰ３に対して「refresh timer」による「refresh」を行っており、ＭＮのアドレス状態としてアドレスＩＰ１以外は「Valid timer」が更新されている。

図５の（ｄ）は最後にＭＮがＡＲ５まで移動した場合の様子である。このとき、ＭＮはＡＲ５の「prefix5」によるアドレス生成を同様に行うが、「refresh」の行われなかったアドレスＩＰ１に関しては「Valid Life timer」が「expire」した時点でＭＮのアドレスから削除されている。またＡＲ２とＡＲ３に関しては、ＡＲ４とＡＲ５間でトンネルが生成される場合に、何の影響も受けることなく、トンネルを再構成するためのシグナリングも必要ない。単に、ＭＮが「Prefix」を用いて生成したＩＰアドレス（この場合ＩＰ２やＩＰ３）に関して「Transmission timer」の更新を継続して行い、「Transmission timer」が「expire」した場合に、ＡＲ５が該当アドレスに関してトンネルを構成する相手（ＡＲ２、ＡＲ３、ＡＲ４）にマッピングの削除を通知するのみである。

本発明は、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができるという効果を有し、モバイルノードの構成を変更しないことを要求している「Netlmm」などに利用することができる。

本発明は、移動通信方法及びアクセスルータに関する。

現在、携帯電話などの移動通信においてＩＰ通信における移動制御方法が検討されているが、１つのネットワーク管理者がサービスを行う、エリアの限定されたローカルモビリティにおいては、端末が移動時にＩＰアドレスの変更を行うこと無く移動制御を行う方法が検討されている（IETF netlmm グループなど）。このような要求においては、ネットワーク側の装置が端末の移動処理をサポートし、移動端末が接続される適切な基地局に対してＩＰパケットが転送されるように制御を行うことが必要である。具体的な要求条件を示したドラフトによると、このようなアクセスネットワークにおいては、ハンドオーバのパフォーマンスを改善するために、ネットワークの有線区間の利用効率の向上、同様に無線区間の利用効率の向上などが示されると同時に、端末のＩＰアドレスの変更を行うことなく移動制御ができることが要求されており、さらにこれらを実行するために端末のＩＰスタックに変更を加えないことが要求事項として挙げられている。

代表的な移動制御であるMobile ＩＰでは、ホストのアドレスを示すＩＰアドレス（Home Address：以下、ＨｏＡ）と、ロケーションを示すＩＰアドレス（Care-of-Address：以下、ＣｏＡ）を用いたトンネル技術により正しいロケーションにパケットが転送される。しかし、Mobile ＩＰ（ＭＩＰ）では端末自身が新たなアドレス（ＣｏＡ）の生成と、このアドレスのマッピングの登録をＨＡ（Home Agent）に行うなど、端末での処理が発生し、これがハンドオーバのパフォーマンスを低下させる要因となっている。またトンネルが端末で終端されるため、無線区間でもトンネルが使用されることになり、データに対するトンネルヘッダのオーバヘッドが問題になっている。またＭＩＰではハンドオーバのパフォーマンスを改善するために、限定されたエリアにおいて位置登録を管理するＭＡＰ（Mobile Anchor Point）を導入したＨＭＩＰも検討されている。この場合、ある限定されたエリア内では、位置登録をＭＡＰに行うだけで済むため、シグナリング距離と時間が短縮されるが、２重のトンネルヘッダが必要になり、ネットワークのリソースが減少するほか、端末が新たにＭＡＰに対するシグナリングを行う必要があるため、端末のＩＰスタックに変更を加える必要がある。このため、前述したような、１つのネットワーク管理者がサービスを行うアクセスネットワークにおいて、端末に変更を加えることなくローカルモビリティを効率的に行うための各種提案がなされている。

図６は下記の非特許文献１に示すアクセスネットワークの構成を示したものである。アクセスネットワークであるＬＭＭＤ（Localized Mobility Management Domain）＃１は、相手先（Correspondent Node：以下、ＣＮ）が接続される外部ネットワーク（External Network）との接続点となるボーダーゲートウェイ（ＢＧ）と、モバイル端末（Mobile Node：以下、ＭＮ）を接続する無線基地局機能を有するアクセスルータ（ＡＲ＃１、ＡＲ＃２、ＡＲ＃３）が中継装置として接続されるネットワークである。本例では説明を簡単にするためアクセスルータと無線基地局（ＢＳ若しくはＡＰ）が同一の装置の機能として提供されているとする。このようなネットワークの領域を以降、「Netlmm」ドメインと呼ぶ。

このNetlmmドメインでは、各ＡＲ＃１、ＡＲ＃２、ＡＲ＃３は、それぞれ異なるプレフィックス（prefix#1、prefix#2、prefix#3）を有しており、さらにそれぞれのＡＲ＃１、ＡＲ＃２、ＡＲ＃３は、「prefix#1」、「prefix#2」、「prefix#3」より、その「prefix#1」、「prefix#2」、「prefix#3」を有するＡＲ＃１、ＡＲ＃２、ＡＲ＃３のＩＰアドレスを取得できるテーブルを有している。

図６において、
１．ＭＮ＃１は起動時に、接続したＡＲ＃１から「prefix#1」を取得し、自身のＩＰアドレス（ＩＰ−ＭＮ＃１）を生成する。このときのＡＲ＃１をＨＡＲ（Home Access Router）と呼ぶ。ＭＮ＃１はルーティング可能な「prefix#1」より生成したＩＰアドレス（ＩＰ−ＭＮ＃１）を用いて通信するため、ＨＡＲ配下に接続している場合は、ＣＮとの通信においてトンネルを用いることなく通常のＩＰルーティングによる通信を行うことが可能である。

ＭＮ＃１が他のＡＲ配下に移動した場合、次の処理が発生する。
２．ＭＮ＃１が移動前のＡＲ＃１からの切断を認識してルータ要請（Router Solicitation）メッセージ（以下、ＲＳと言う）を送信して新しいＡＲからルータ広告（Router Advertisement）メッセージ（以下、ＲＡと言う）を受信した場合や、新しいＡＲからの定期的なＲＡを受信するなどして、異なる「Prefix」を受信した場合、ＭＮ＃１は自身が他のＡＲ（ここではＡＲ＃２）配下に移動したことを認識する。このとき、ＭＮ＃１は自身が使用しているGlobal ＩＰアドレスを用いて、通信を行いたいということを示すメッセージ（Activate message）を送信する。

３．これを受信したＡＲ＃２は、使用されているGlobal ＩＰアドレスより「Prefix#1」を認識して、該当「Prefix#1」を有するＡＲ＃１に対して位置更新のメッセージ（Location Update）を送信する。このようなＡＲ＃２をＶＡＲ（Visited Access Router）と呼ぶ。
４．これを受信したＨＡＲ（＝ＡＲ＃１）は自身の配下にいたＭＮ＃１がＶＡＲ（＝ＡＲ＃２）配下に移動したことを認識して、ＨＡＲ（＝ＡＲ＃１）とＶＡＲ（＝ＡＲ＃２）間にトンネルを構成し、ＭＮ＃１宛のパケットを受信するとトンネルを用いてＶＡＲ（＝ＡＲ＃２）に転送を行う。これによりＶＡＲ（＝ＡＲ＃２）は受信したＭＮ＃１宛のパケットを自身の配下に接続しているＭＮ＃１に送信することができる。このようにＨＡＲとＶＡＲのトンネルを用いることでＭＮは「Netlmm」ドメイン内では、常に同じＩＰアドレスを使用して通信を継続することが可能となっている。

図７に、ＭＮ移動時のトンネルを使用した通信の概要を示す。図７の（ａ）に示すようにＭＮの電源を入れて起動（Power on）したとき、ＭＮは接続したＡＲ１から「Prefix1」を取得しアドレスＩＰ１を生成する。その後、図７の（ｂ）に示すようにＭＮが移動によりＡＲ２に接続すると（Start Communication）、ＭＮはＩＰ１を用いた「Activate Message」を送信する。これによりＡＲ２はＭＮのＶＡＲとして動作し、ＡＲ１とＡＲ２間にトンネルが構成される。ここで、ＭＮがＡＲ２配下にいるときにＣＮと通信を始めたとしても、ＡＲ１とＡＲ２のトンネルを用いて通信を行う。さらに図７の（ｃ）に示すようにＭＮがＡＲ３配下に移動すると（Continue Communication）、ＡＲ３がこのＭＮのＶＡＲとなり、ＡＲ１とＡＲ３間にトンネルを変更することでＩＰ１宛のパケットの転送が行われることになる。このようにして、ＭＮは「Netlmm」ドメインを移動する場合、ＩＰアドレスの変更を行うことなく通信を継続することができる。
また、他の従来例として、近隣発見について下記の非特許文献２に記載されている。
draft-diaretta-netlmm-protocol-00-txt, Figure 1 - Reference architecture, October 14, 2005, RFC2461

しかし、「Netlmm」がＭＮの構成を変更しないことを要求しているのに対し、このような方法を用いた場合、ＭＮが移動時に自身の使用したいＩＰアドレスを「Activate Message」として通知する必要があり、ＭＮの構成を変更することを必要とするという課題がある。

「Netlmm」の要求事項に従って、構成が変更されていない通常のＭＮを使用した場合、以下のような動作が考えられる。通常、ＭＮは新しい「Prefix」を受信した場合、その「Prefix Option」中のＡビットがセットされている場合は新しいＩＰアドレスを生成し、重複アドレス検出（Duplicate Address Detection：以下、ＤＡＤ）を行う。この場合、新しいアドレスのＤＡＤを確認するための近隣要請（Neighbor Solicitaion）メッセージ（以下、ＮＳ）を受信したＡＲは、ＭＮの移動を認識することができず、そのＭＮの該当するアドレスのＨＡＲとして動作すると考えられる。しかし、この場合、ＭＮは異なるネットワークに移動したとしてＭＩＰの実装されているＭＮであれば、ＣｏＡを変更し、結合更新（Binding Update）メッセージ（以下、ＢＵ）をＨＡに送信する。

非特許文献２に示す、ネットワークの移動の検知を行うＤＮＡ(Detecting Network Attachment)を使用していると考えた場合、ＭＮは異なるネットワークに移動したという認識を行うことはないが、新しいＩＰアドレスを生成してＤＡＤを行うことに変わりはない。この場合も、ＭＮは移動するたびにＩＰアドレスを生成し、複数のＩＰアドレスを保持していくことになる。このような場合、ＭＮが移動前のアドレスを用いて通信を行う（若しくは行っている）ことも考えられる、このような場合は、該当する「Prefix」を持つＡＲとの間にトンネルを構成し、パケットの転送を正しく行う必要がある。しかし、通常、移動先のＡＲではＭＮから移動前の「Prefix」を用いたパケットを受信するまで、どのＡＲをＨＡＲとしたアドレスを用いてＭＮが通信を行っているのか知ることはできない。このため、ＭＮからのデータ受信があるまで、トンネルは構成されることがなく、パケットロスを発生させることになる。さらにネットワークはＭＮがどのＩＰアドレスを使用するのか制御することはできないため、ＭＮが使用する複数のＩＰアドレスに対して多くのトンネルを構成し、移動のたびにトンネルの再構成を行うなど制御のシグナリング量が増加するという課題を生む。

以下に、「Netlmm」の要求事項を満足するために通常のＭＮを用いた場合の動作を説明する。図８に移動時の通信の概要を示し、図９に移動時のシーケンスを示す。図８ではＡＲ１〜ＡＲ５までのＡＲがあり、ＭＮはＡＲ１で起動し、ＡＲ５の方向に移動している。ＭＮは移動のたびにＡＲ１〜ＡＲ５から受信する「Prefix」を用いてアドレスを生成し、このアドレスを用いて通信を行っている。図８の（ａ）はＭＮがＡＲ３配下で通信を行っている状態を示す。このときＭＮはＡＲ１、ＡＲ２、ＡＲ３のそれぞれに接続中に、それぞれのアドレスを用いて通信を開始したと仮定する。このため、アドレスＩＰ１、ＩＰ２、ＩＰ３のＨＡＲはそれぞれＡＲ１、ＡＲ２、ＡＲ３となり、それぞれの通信についてＶＡＲとなるＡＲ３との間にトンネルを構成し通信を行う。

ＭＮがＡＲ５まで移動した状態を図８の（ｂ）に示す。３つの通信が継続されている場合、ＡＲ５ではＭＮからのデータを受信するたびに、「Prefix」からＨＡＲとなるＡＲを認識し、トンネルの再構成を行う。アドレスＩＰ４を用いた通信を行っていなかった場合、ＡＲ４との間にトンネルが構成されることはない。このように、ＭＮが移動するたびに生成するアドレスが増えていくため、ＭＮに使用されるＩＰアドレスが増えるにつれて、移動時のトンネルの再構成の負荷が大きくなっていく。

また図９に移動時のシーケンスを示している。この図ではＡＲ２配下で通信を行っていたＭＮがＡＲ３配下に移動してきたときの処理の流れを示している。ＭＮはＡＲ２の前にＡＲ１に接続しており、そのときのアドレスＩＰ１を用いて通信を行っていたとする。ＡＲ２からＡＲ３へのレイヤ２のハンドオーバ（L2 HO from AR2 to AR3）が終了すると、それまでデフォルトルータ（ＤＲ）であったＡＲ２への接続がなくなる。このため、ＭＮはＡＲ２との接続を確認するため、ＮＳをＡＲ２宛に送信する。このＮＳに対して応答を行うＡＲ２はもはやＭＮと接続関係にないため、ＭＮは応答パケットを受信することはなく、３回のＮＳの失敗によりＤＲ（＝ＡＲ２）との接続が切れたことを認識する（Detect unreachability to AR2）。

その後、ＭＮは新しいリンクでのルータ情報を取得するためにＲＳを送信し、ＡＲ３により応答されるＲＡにより新たに「Prefix3」のリンクにいることを確認する。このときＤＮＡにより同じ「Landmark Option」を用いるなどして「IP link」の変更がないことを認識させることはできる。ＭＮは受信した「Prefix3」よりアドレスＩＰ３を生成する（Create new IP address）。このときＭＮのＩＰアドレスの状態は、「望ましい（Preferred）ステート」／望ましくない（Deprecated）ステート」のうち、ＩＰ１、ＩＰ２、ＩＰ３がすべて「Preferred」で保持されている。このためＭＮはどのアドレスを新規の通信に用いることも可能である。

ＭＮはアドレスＩＰ３の生成後、ＤＡＤによりアドレスの重複がないかを確認する。これによりＡＲ３は自身がＩＰ３のＨＡＲになることを認識する。その後、ＭＮが通信中のデータパケットを出力したタイミングで異なる「Prefix」を用いるＩＰアドレス（ＩＰ１）があることをＡＲ３は認識する。これにより該当ＭＮの他のＨＡＲ（＝ＡＲ１）をあらかじめ設定されているテーブルより取得し、ＨＡＲ（＝ＡＲ１）に対してＩＰ１の「Location Update」を行う。これによりＩＰ１に関しては新しく移動したＡＲ３へのトンネルが構成され、通信が再開できる。

しかし、このときＭＮが送信するパケットが少ないアプリケーションを用いて通信を行っていた場合（ＭＮが受信するデータがほとんどのＵＤＰ（User Datagram Protocol）アプリケーションなどである。）、ＭＮがデータ（Data (IP-1)）を出力するまでＡＲ３はそのアドレスをＭＮが使用して通信を行っていることを知ることはできない。このため図９に示すようにＩＰ２に関しては、これまで通りＡＲ２が受信するＩＰ２宛のパケットは転送先が不明のまま廃棄されることになる。ＭＮがＩＰ２をソースアドレスに持つパケットを送信して初めてＡＲ３はＡＲ２と通信の必要性があることを認識してトンネルを構成することになる。このように、変更のない通常のＭＮを用いた場合、複数のトンネルの移動管理を行うためのシグナリングが増えるだけでなく、移動して即座にトンネルの再構成を行うことができないためパケットロスを増加させることになる。

本発明は上記の問題点に鑑み、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができる移動通信方法及びアクセスルータを提供することを目的とする。

本発明の移動通信方法は上記目的を達成するために、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信方法において、
前記モバイルノードが前記第１のアクセスルータに対して接続確認のパケットを送信するステップと、
前記第２のアクセスルータが前記第１のアクセスルータに対して出力された接続確認のパケットを受信するステップと、
前記接続確認のパケットを受信した前記第２のアクセスルータが受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信するステップと、
前記位置更新メッセージを受信した前記第１のアクセスルータが前記第２のアクセスルータに対して、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を送信するステップと、
前記第１、第２のアクセスルータの間で構成されているトンネルに対して、前記プリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送するステップと、
前記第１、第２のアクセスルータの間のトンネルを介して転送された前記パケットを前記第２のアクセスルータから前記モバイルノードに転送するステップとを、
備えた方法とした。
この方法により、モバイルノードの移動時のトンネルの再構成のためのシグナリングを移動先の第２のアクセスルータから第１の移動元のアクセスルータに行うので、シグナリングを減少させることができ、さらにパケットロスも減少させることができる。

また、本発明の移動通信方法は、前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記第２のアクセスルータから前記モバイルノードに対して、前記第２のアクセスルータ自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信するステップと、
前記モバイルノードが前記ルータ広告メッセージ中の前記第２のアクセスルータのプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するステップとを、
更に備えた方法とした。
この方法により、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができる。

また、本発明の移動通信方法は、前記アクセスルータは、自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信することを特徴とする。
また、前記第１のアクセスルータは、自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信することを特徴とする。
また、移動元アクセスルータである前記第１のアクセスルータは、移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記第１のアクセスルータ自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする。
この方法により、トンネルを削減することができる。

また、本発明のアクセスルータは、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第２のアクセスルータであって、
モバイルノードが前記第１のアクセスルータに対して送信する接続確認のパケットを受信する手段と、
前記受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信する手段と、
前記位置更新メッセージに応答して前記第１のアクセスルータが送信した、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信する手段と、
前記第１のアクセスルータの間で構成されているトンネルに対して、前記受信したプリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送する手段と、
前記トンネルを介して転送された前記パケットを前記モバイルノードに転送する手段とを備えた。
この構成により、モバイルノードの移動時のトンネルの再構成のためのシグナリングを移動先の第２のアクセスルータから第１の移動元のアクセスルータに行うので、シグナリングを減少させることができ、さらにパケットロスも減少させることができる。

また、本発明のアクセスルータは、前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記モバイルノードに対して、自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信する手段を更に備え、
前記モバイルノードが前記ルータ広告メッセージ中の前記自身のプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するようにしたことを特徴とする。
この構成により、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができる。
また、本発明のアクセスルータは、自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信する手段を更に備えた。

また、本発明のアクセスルータは、モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第１のアクセスルータであって、
自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信する手段を備えた。
また、本発明のアクセスルータは、移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする。
この構成により、トンネルを削減することができる。

本発明によれば、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができる。また、モバイルノードの構成を変更しないことを要求している「Netlmm」に対応することができ、さらに、トンネルを削減することができる。

以下、図面を参照して本発明の実施の形態について説明する。図１は本発明に係る移動通信方法及びアクセスルータの一実施の形態の通信シーケンスを示す説明図である。図１は図９と同様に、ＭＮが移動元のＡＲ２（ｏＡＲ）から移動先のＡＲ３（ｎＡＲ）へ移動したときの動作を示したものである。このため、ＭＮはＡＲ３に移動する前は、ＡＲ１、ＡＲ２からの各「Prefix」に基づいてそれぞれＩＰ１、ＩＰ２を生成してＩＰ１、ＩＰ２のステートを「Preferred」に設定している。本発明では、各ＡＲ１、ＡＲ２、ＡＲ３は「promiscuous」モードで動作し、ＭＮからのすべてのフレームを受信すると仮定する。
１．これにより、ＡＲ３はＭＮからＡＲ２宛のＮＳパケットを受信する。ＮＳパケットの宛先アドレスとしては、ＡＲ２のリンクローカルアドレスが使用されており、各ＡＲ１、ＡＲ２、ＡＲ３がリンクローカルアドレスとＡＲ１、ＡＲ２、ＡＲ３のＩＰアドレスをマッピングしたテーブルをあらかじめ設定して保持しておくことで、ＭＮがどのＡＲから移動してきたかを認識することができるようになる。

２．移動元のＡＲ（ｏＡＲ）がＡＲ２であることを識別したＡＲ３は、ＡＲ２に対して「Location Update」を送信する。このとき「Location Update」に含まれるのは、ＭＮの「Link Local IP address」と、ＭＮ ＩＤとしてＭＮの「Link Layer」のアドレス（ＭＡＣアドレス）などである。
３．「Location Update」を受信したＡＲ２は、該当ＭＮのＭＮ管理テーブル（後述する図２）を用いて 「Prefix Information」を作成し、ＡＲ３に返信する。「Prefix Information」の内容については後述（図４）する。
４．ＡＲ３はこの「Prefix Information」により、該当ＭＮが現在使用している（使用する可能性のある）ＩＰアドレスを知り、ＭＮ管理テーブルに該当ＭＮのエントリを作成し追加する。
５．このとき、ＡＲ２とＡＲ３間には、「Prefix Information」で通知したＭＮのすべてのＩＰアドレスに関してトンネルのマッピングが構成され、ＭＮ宛のパケットがＡＲ２からトンネルを介してＡＲ３へ転送され始める。このトンネルにより、ＭＮは自身の使用するＩＰアドレスをＡＲ３に通知することなく、使用していたすべてのＩＰアドレス宛のパケットに関してＡＲ２から転送されてくることになる。

６．その後、ＡＲ３は「Prefix Information」を用いてＭＮに対して、後述（図４）するタイプ２（RA_Type2）のＲＡメッセージを送信する。この「RA_Type2」のＲＡメッセージには、通常のＡＲ３の「Prefix」以外に、ＡＲ２の「Prefix」及びその他のトンネルを使用して通信を継続しているアドレスの「Prefix」も含まれる。さらに常に同じ「IP Link」にいるという認識をＭＮに持たせるために、Ａビットのセットされていない「Netlmm」ドメインに共通の「Prefix」を含んでいる（詳細は図４を用いて後述する）。
７．「RA_Type2」のＲＡメッセージを受信したＭＮは、「Prefix Option」に含まれる、新しいＡＲ３の「Prefix」を認識すると、これを用いてアドレス（ＩＰ３）を生成する。
８．ＭＮは、ＤＡＤ（ＮＳ ｆｏｒ ＤＡＤ）を実行する。ＡＲ３はこのＤＡＤのパケットを用いて、新たにＭＮのＭＮ管理テーブルにＩＰ３の情報を追加する。

ここで、６．で「RA_Type2」のＲＡメッセージを受信したＭＮは、その他の「Prefix Option」により、７．で自身の保有するＩＰアドレスのステートの変更を行う。図１の場合、新たに受信するＡＲ３の「Prefix」以外は図４に示す「Preferred Life Time」（PL Time）が０であるため、アドレスのステートは「Preferred」から「Deprecated」に変更になる。「Deprecated」になったＩＰアドレスに関しては、「ＭＮが新たなコネクションを生成する場合に使用するべきでない」ことがＲＦＣ２４６１に規定されている。これは、ＭＮが新たに通信を開始する場合は、トンネルを生成する必要のない現在接続中のＡＲから取得した「Prefix」を用いたＩＰアドレスを用いることを示しており、新たな通信に関して効率的な通信ができることを示している。ただし、「Deprecated」になったアドレスでも継続中の通信に使用することは可能である。このため、通信を継続しているＩＰアドレスについては、アドレスを保持する必要がある。本発明では、従来技術と異なり、「prefix option」の「Valid Time」を「Infinity」に設定しない。このためＡＲは該当「Prefix」に関して、ＭＮが使用を継続する場合は、「Valid Time」が満了（expire）する前に該当「Prefix Option」を含むＲＡメッセージを送信して、「refresh」する必要がある。

本発明では、ＭＮの使用するＩＰアドレス（Prefix情報）を接続中のＡＲが管理することで、必要なＲＡを生成し、ＭＮのアドレス状態（「Preferred」／「Deprecated」）をコントロールする。これにより、ＭＮ内部のアドレス状態に依存することなく、ネットワーク側でトンネル生成と維持をコントロールすることが可能となる。また常に接続中のＡＲがＭＮとトンネルの情報を管理していることで、移動時にはこれまでのように、すべてのＨＡＲにシグナリングを行う必要はなく、移動元のＡＲにのみ通知を行うことで、トンネルの延長と必要な「Prefix」情報を取得することが可能となり、トンネルの再構築のためのシグナリングを減少させることが可能となる。また、ＭＮが出力するｏＡＲ（ＡＲ２）の接続確認を行うためのＮＳパケットをｎＡＲ（ＡＲ３）の発見のために使用するため、シグナリングの開始が早く、ＭＮからのデータの送信がなくても、すべてのアドレスのためのトンネルのマッピングを構築することができるので、パケットロスを減少することが可能となる。またＭＮ宛のすべてのデータは移動元ＡＲ（ＡＲ２）まで送信されているため、移動時に移動元ＡＲ（ＡＲ２）でのみパケットのバッファリンクを行っておくことでパケットロスを減少させることも可能である。

次に図２を用いて、ＡＲが管理するＭＮ管理テーブルについて説明する。ここで、図２は一例として、図３に示す構成のネットワークにおけるＡＲ３の管理するＭＮ管理テーブルを示す。ＭＮ管理テーブルではＭＮ別（図３に示す構成ではＭＮ１、ＭＮ２、ＭＮ３別）にエントリがある。各フィールドについて以下に説明する。ＭＮ ＩＤはＭＮを示す固有のＩＤ（例えばＭＡＣ／ＬＬ address）である。オン・リンク・フラグ（On Link Flag）は現在そのＭＮが自身（ここではＡＲ３）に接続しているかどうか（図３に示す構成ではＭＮ１、ＭＮ２が接続中：On Link Flag＝１、ＭＮ３が非接続：On Link Flag＝０）を示している。これは自身で接続の確認ができなくなった場合、および他のＡＲから「Location Update」を受信した場合に、On Link Flag＝０に変更される。

リフレッシュ・タイマ（Refresh Timer：ＲＴ）はＭＮ別に構成されたタイマであり、自身の「Prefix」から生成されたアドレス以外のアドレスが使用されている場合に、その有効ライフ・タイマ（Valid Life Timer）（図４のVL Timer）をコントロールするためのタイマである。ＲＴはＲＡの「Prefix Option」に使用される値を基準として「expire」までの時間を示している。「トンネルを使用しているＩＰアドレス」（IP address(es) using tunnel）は、他のＡＲからのトンネルにマッピングされているＩＰアドレスを示している。このアドレスより、接続中のＡＲは「refresh」のための「Prefix」情報を取得することができる。次の「本ＡＲにより生成されたＩＰアドレス」（IP address generated by this AR）は、接続中のＡＲから取得した「Prefix」で生成されたＩＰアドレスを示している。

トランスミッション・タイマ（Transmission timer）は前記接続中のＡＲから取得した「Prefix」で生成されたＩＰアドレスのパケットが送受信されてからトンネルを削除するまでの残り時間を示している。このタイマは初期値が０で、パケットが送受信されるたびに所定のトンネル維持時間（Tunnel Life time）にリセットされ、時間の経過と共に減少する。つまりこの値が０を示している場合、一度も通信が行われていないか、通信が終了してから所定のトンネル維持時間以上が経過していることを示している。

具体的に図２の場合を説明する。ＭＮ１は図３に示すように、ＡＲ１配下からＡＲ２配下→ＡＲ３配下と移動してきたＭＮであり、ＡＲ１とＡＲ２に接続中に通信を開始してそれが継続している。図２のテーブルでは接続中（On Link）であり、トンネルを使用しているのがＭＮ１−１とＭＮ１−２の２つのアドレスであることを示し、アドレス維持のための「refresh」まで３５分４０秒（＝Refresh Timer）残っていることを示している。さらにＡＲ３のPrefixを用いて生成したアドレス（IP address generated by this AR）はＭＮ１−３であり、このアドレスを用いた通信は、一度も行われていないか、若しくは通信後トンネル維持時間以上が経過していることを示している（Transmission timer＝０）。

次にＭＮ２に関しては、「On Link」であり、他のアドレスを使用したトンネルはないことを示している 。またＡＲ３から生成したアドレス（IP address generated by this AR）はＭＮ２−３であり、このアドレスを使用したトンネル維持時間（Transmission timer）は残り５５分１２秒である。

ＭＮ３に関しては、自身（ＡＲ３）に接続していない端末であることを示している（On Link Flag＝０）。ＭＮ３は自身に接続していないため「Refresh」のためのＲＡをＡＲ３が出力する必要はなく、「Refresh timer」は使用されない。またＭＮ３がＡＲ３配下で生成したアドレス（IP address generated by this AR）はＭＮ３−３であり、「Transmission Timer」が「expire」していないので（Transmission Timer＝１５分５６秒）、まだトンネルを維持する必要があることを示している。

「On link」でないＭＮの「Transmission Timer」が「expire」した場合、これはネットワーク側でこれ以上このトンネルの維持を行う必要がないことを示している。このため、ＡＲは接続されているトンネルの相手となるＡＲに対し、該当ＭＮのトンネルのマッピングを削除するようにメッセージを送信する。これを受信したＡＲは自身に該当ＭＮが接続していない場合（トンネルがさらに続く場合）、自身のＭＮ管理テーブルから該当アドレスを削除して、さらにトンネルの接続先のＡＲに同様にマッピングの削除メッセージを送信する。あるＭＮに関して管理対象となるすべてのアドレスが削除された場合、そのＡＲは該当ＭＮのエントリを削除する。

次に図４を用いてＡＲが出力するＲＡメッセージについて説明する。本発明では、ＡＲは３つのタイプ（RA_Type1、RA_Type2、RA_Type3）のＲＡメッセージを送信する。「RA_Type1」は、標準で使用される定期的に出力されるＲＡメッセージの内容である。本発明では、デフォルトで２つの「Prefix Option」を有している。１つがＡＲ自身の「Prefix」（nAR's prefix）であり、ＭＮがこの「Prefix」を用いてＩＰアドレスを生成することを示すＡビットをセットし、さらに「Preferred Life time」（PL time）と「Valid Life time」（VL time）には、アドレスをリフレッシュするための時間である「Refresh Time」（ＲＴ）を規定して使用する。この値ＲＴは定期的に送信する「RA_Type1」のＲＡの間隔よりも十分長い時間を設定するため、通常、接続中のＡＲから受信する「prefix」に関しては、常に受信時にリフレッシュされることになる。またこのＡＲに固有の「Prefix」以外に、この「Netlmm」ドメインで共通の特別な「prefix」（Special prefix of this netlmm domain）を使用する。この「Prefix」にはＡビットを設定しない。これによりＭＮはこの「prefix」を用いてアドレスを生成し、使用することはない。ただし、「Prefix」リスト中で管理されるため、移動時に同じ「prefix」を受信することで、同じ「IP Link」にいると認識することが可能になる（図４に記載の＊１）。

「RA_Type2」のＲＡは前述したように、本発明のポイントとなる部分であり、ｏＡＲからのＰＩ受信時に送信される。「RA_Type2」では「RA_Type1」の「nAR's prefix」と「Special prefix of this netlmm domain」に加えて、移動元のＡＲ（ｏＡＲ）の「prefix」（oAR's prefix）と、トンネルを使用している場合、その使用しているＩＰアドレスの「Prefix」（Other Prefix(es) using tunnel）に関しても「Prefix Option」で通知される。移動元となるｏＡＲのprefix（oAR's prefix）に関しては、Ａビットはセットされるが、「Preferred Life time」は０に設定される。これにより、ＭＮは移動すると必ず、移動元（ｏＡＲ）で生成したアドレスのステートを「deprecated」に変更することになる。そのため、新たに接続先のｎＡＲから生成したアドレスのみが「preferred」のステートとなり、ＭＮは新たな通信を開始する場合に、現在接続しているＡＲ（ｎＡＲ）のアドレスを用いて通信を行うことになる。このため、新しい通信はトンネルを用いないでパケットの転送を行うことが可能となり、ネットワークリソースを有効に使用することができる。また、古い通信は終了すると、そのアドレスを使用した通信がＭＮから開始されないためトンネルを使用した通信はだんだんと無くなっていく。

また、このｏＡＲの「prefix」の「Valid Life time」（図４に記載の＊２）について説明すると、これはｏＡＲから受信した「Prefix information」の内容によって変化する。ｎＡＲ（図１ではＡＲ３）から「Location Update」を受信したｏＡＲ（図１ではＡＲ２）は、以下の情報を「Prefix Information」としてｎＡＲに通知する。
（１）トンネルを使用しているＩＰアドレス
（２）ｏＡＲから生成されたＩＰアドレス
（３）伝送状態「Transmission state」

「Transmission state」は、（２）で示されたｏＡＲで生成されたアドレスのトンネル維持状況を示す。具体的には「Location Update」を受信したときの「Transmission timer」が０か０でないかを示している。「Transmission state」が０の場合、つまり「Transmission timer」が０であった場合、これはｏＡＲ配下で生成したアドレスに対してトンネルの生成、維持を行わないことを示している。このため、ｏＡＲの「prefix」の「Valid Life time」については、「Transmission state」が０の場合には「Valid life time」＝０に、１の場合には「Refresh Time」（ＲＴ）の値を用いて通知する（図４に記載の＊２）。「Valid Life time」＝０は現状の標準仕様では、そのアドレスを「invalid」にして削除するのではなく、単に値の更新をしないことを意味する。このため、移動時に一度「Valid Life time」＝０をセットされた「prefix」に関しては、それ以前にｏＡＲに接続中に受信した値が「expire」するのを待つだけの処理となる。

また、「Transmission state」が１の場合、これはトンネルの維持生成を行う必要があることを示しており、（１）に示したトンネルを使用しているＩＰアドレスと同様の処理となる。その（１）のトンネルを使用しているＩＰアドレスであるが、これらのアドレスの「prefix」に関しては、Ａビットをセットし、「Preferred Life time」＝０、「Valid Life time」＝ＲＴの設定で通知される。ただし、「Prefix Information」の中に、このアドレスが含まれない場合は、この「Prefix Option」は使用されない。これはｏＡＲとｎＡＲ間のトンネルにマッピングされるＩＰアドレスを示しており、既に「preferred」の状態ではあるが、通信を継続しているアドレスである。このため「Valid Life time」が通信中に「expire」しないように、「refresh」する必要がある。

ＭＮ中の「deprecated」アドレスの「refresh」のタイミングであるが、「RA_Type2」に示すように、新しいＡＲに移動時に必ず「refresh」を行う。こうすることで個別のアドレスのタイマ管理を行うことなく、接続中のＡＲのみが一貫してＭＮのアドレスステートの管理を行えばよいことになる。このＭＮの内部のアドレスステート管理と、実際のネットワーク中のトンネルの管理が独立していることが特徴である。

またＡＲは自身の「Refresh timer」が「expire」すると、そのときにテーブルに設定されている「IP address using tunnel」のＩＰアドレスに関する「prefix」のみに対して、「RA_Type3」のメッセージを送信してＭＮのアドレスステートの更新を行う。例えば、「Prefix Information」で「IP address using tunnel」が何もなく、「transmission state」も０である情報を受信したｎＡＲの場合、新たにＭＮのエントリを図２に示すＭＮ管理テーブルに追加するが、「refresh timer」と「IP address(es) using tunnel」のフィールドには何も入らない。ＭＮが自身の「Prefix」を用いてアドレスを生成し、ＤＡＤを行ってきた場合にそのアドレスを「IP address generated by this AR」に追加するだけである。

このように、本発明では、ｎＡＲがｏＡＲから必要な情報のみを引き継ぎ、ＭＮのアドレス状態の管理をＲＡを用いて行うと同時に、必要最小限のトンネルを構成することになる。具体的な動作例を図５を用いて説明する。図５にはＭＮが起動してからの動作が示してある。図５の（ａ）は起動（Power on）時を示し、ＭＮはＡＲ１配下でＡＲ１の「Prefix1」を用いて最初のアドレスＩＰ１を生成し、また、ＩＰ１のステートは「preferred」である。ただし、このとき通信は行っていない。

図５の（ｂ）でＭＮはＡＲ２配下に移動後、ＡＲ２からの「RA_Type2」のＲＡによりアドレスＩＰ１のステートを「preferred」から「deprecated」にして、ＡＲ２の「Prefix2」を用いて生成したアドレスＩＰ２のみが「preferred」のステートになる。このとき通信を始めたＭＮはアドレスＩＰ２を使用して、通信を行う。このため、ＨＡＲはＡＲ２であり、従来技術のようにＡＲ１とＡＲ２の間にトンネルを構成することなく通信を行うことができる。このときアドレスＩＰ１に関しては通信を行っていなかったため、「transmission state」＝０であり、移動後は一度も「valid timer」が「refresh」されることはない。またＡＲ２のＭＮ管理テーブルにはアドレスＩＰ２の情報しか入らないため（ＩＰ１がトンネルを使用する状態でないため：「transmission state」＝０）、ＡＲ２は「refresh」の管理を行うアドレスはなく、「refresh timer」も動作しない。

次にＭＮがＡＲ４まで順に移動した様子を図５の（ｃ）に示す。ＭＮは各ＡＲ１〜ＡＲ４からの「prefix1」〜「prefix4」により、それぞれアドレスＩＰ１〜ＩＰ４を生成している。ただしＡＲ４に接続時点で「preferred」状態のアドレスはＩＰ４のみである。図５の（ｃ）では、ＡＲ２配下とＡＲ３配下で生成したアドレスでも通信が継続しており、ＡＲ２−ＡＲ３間、ＡＲ３−ＡＲ４間のトンネルにそれぞれのアドレスＩＰ２、ＩＰ３がマッピングされて転送されている。また、この時点では通信が継続しているため、ＡＲ４はアドレスＩＰ２、ＩＰ３に対して「refresh timer」による「refresh」を行っており、ＭＮのアドレス状態としてアドレスＩＰ１以外は「Valid timer」が更新されている。

図５の（ｄ）は最後にＭＮがＡＲ５まで移動した場合の様子である。このとき、ＭＮはＡＲ５の「prefix5」によるアドレス生成を同様に行うが、「refresh」の行われなかったアドレスＩＰ１に関しては「Valid Life timer」が「expire」した時点でＭＮのアドレスから削除されている。またＡＲ２とＡＲ３に関しては、ＡＲ４とＡＲ５間でトンネルが生成される場合に、何の影響も受けることなく、トンネルを再構成するためのシグナリングも必要ない。単に、ＭＮが「Prefix」を用いて生成したＩＰアドレス（この場合ＩＰ２やＩＰ３）に関して「Transmission timer」の更新を継続して行い、「Transmission timer」が「expire」した場合に、ＡＲ５が該当アドレスに関してトンネルを構成する相手（ＡＲ２、ＡＲ３、ＡＲ４）にマッピングの削除を通知するのみである。

本発明は、通常の（専用の機能を新たに実装しない）モバイルノードを用いた場合に、モバイルノードの移動時のトンネルの再構成のためのシグナリングを減少させることができ、さらにパケットロスも減少させることができるという効果を有し、モバイルノードの構成を変更しないことを要求している「Netlmm」などに利用することができる。

本発明に係る移動通信方法及びルータの一実施の形態の通信シーケンスを示す説明図 図１のアクセスルータにおけるＭＮ管理テーブルの一例を示す説明図 図２のＭＮ管理テーブルの状態であるネットワークを示す説明図 図１のアクセスルータが送信するルータ広告メッセージを示す説明図 図１の移動通信方法及びアクセスルータの動作を示す説明図 従来の移動通信方法の通信シーケンスを示す説明図 図６の移動通信方法の通信シーケンスを詳しく示す説明図 図６の移動通信方法の課題を示す説明図 図６の移動通信方法の他の課題を示す説明図

Claims (10)

1. モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信方法において、
   前記モバイルノードが前記第１のアクセスルータに対して接続確認のパケットを送信するステップと、
   前記第２のアクセスルータが前記第１のアクセスルータに対して出力された接続確認のパケットを受信するステップと、
   前記接続確認のパケットを受信した前記第２のアクセスルータが受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信するステップと、
   前記位置更新メッセージを受信した前記第１のアクセスルータが前記第２のアクセスルータに対して、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を送信するステップと、
   前記第１、第２のアクセスルータの間で構成されているトンネルに対して、前記プリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送するステップと、
   前記第１、第２のアクセスルータの間のトンネルを介して転送された前記パケットを前記第２のアクセスルータから前記モバイルノードに転送するステップとを、
   備えたことを特徴とする移動通信方法。
2. 前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記第２のアクセスルータから前記モバイルノードに対して、前記第２のアクセスルータ自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信するステップと、
   前記モバイルノードが前記ルータ広告メッセージ中の前記第２のアクセスルータのプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するステップとを、
   更に備えた請求項１に記載の移動通信方法。
3. 前記アクセスルータは、自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信することを特徴とする請求項１に記載の移動通信方法。
4. 前記第１のアクセスルータは、自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信することを特徴とする請求項１に記載の移動通信方法。
5. 移動元アクセスルータである前記第１のアクセスルータは、移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記第１のアクセスルータ自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする請求項４に記載の移動通信方法。
6. モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第２のアクセスルータであって、
   モバイルノードが前記第１のアクセスルータに対して送信する接続確認のパケットを受信する手段と、
   前記受信した接続確認パケットより前記第１のアクセスルータのアドレスを取得し、前記第１のアクセスルータに対して位置更新メッセージを送信する手段と、
   前記位置更新メッセージに応答して前記第１のアクセスルータが送信した、前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信する手段と、
   前記第１のアクセスルータの間で構成されているトンネルに対して、前記受信したプリフィックス情報をマッピングし、前記トンネルを介して前記モバイルノード宛てのパケットを転送する手段と、
   前記トンネルを介して転送された前記パケットを前記モバイルノードに転送する手段とを、
   備えたアクセスルータ。
7. 前記第１のアクセスルータから前記モバイルノードが使用している１つ、もしくは複数のＩＰアドレスに関するプリフィックス情報を受信後、前記モバイルノードに対して、自身のプリフィックスと、前記第１のアクセスルータのプリフィックス及び前記第１のアクセスルータのプリフィックスから生成したＩＰアドレスがもう望ましくないことを示す情報を含むルータ広告メッセージを送信する手段を更に備え、
   前記モバイルノードが前記ルータ広告メッセージ中の前記自身のプリフィックスに基づいて新しいＩＰアドレスを生成して、前記新しいＩＰアドレスを「望ましい」ステートに設定するとともに、前記ルータ広告メッセージ中の前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスがもう望ましくないことを示す情報に基づいて前記第１のアクセスルータのプリフィックスから生成した前記ＩＰアドレスを「望ましくない」ステートに設定するようにしたことを特徴とする請求項６に記載のアクセスルータ。
8. 自身に接続している前記モバイルノードのうち現在トンネルを使用しているモバイルノードについて、前記ＩＰアドレスとその有効時間を管理し、規定のリフレッシュ時間が経過するごとに該当モバイルノードに対して必要な前記ＩＰアドレスの有効時間を延長するためのルータ広告メッセージを「望ましくない」という情報と共に送信する手段を更に備えた請求項６に記載のアクセスルータ。
9. モバイルノードが移動元の第１のアクセスルータ配下から移動先の第２のアクセスルータ配下に移動する場合のハンドオーバを制御する移動通信ネットワークにおける前記第１のアクセスルータであって、
   自身のプリフィックスより生成されたアドレスを用いた通信を監視し、この通信開始から所定の通信監視時間の間、一度も通信のなかったアドレスに関して、トンネルのマッピングを削除するメッセージを前記第２のアクセスルータに対して送信する手段を、
   備えたアクセスルータ。
10. 移動先アクセスルータである前記第２のアクセスルータからの位置更新メッセージを受信した場合に、前記自身のプリフィックスから生成したアドレスに関して、通信監視時間の間一度も通信がなかった場合、もしくは通信監視時間未満でも一度も通信を行うことなく移動したモバイルノードである場合、移動先でリフレッシュの必要がないことを通知することを特徴とする請求項９に記載のアクセスルータ。