JP2007281721A - 移動通信制御方法、移動通信システム及びルータ - Google Patents

Abstract

【課題】モバイルノードがドメイン内のルータ間をハンドオーバする際にモバイルノードのレイヤ３アドレスが変化しないシステムにおいて、ハンドオーバ先のルータがモバイルノードあてのパケットを即座にモバイルノードに転送する。
【解決手段】ハンドオーバ先のＡＲ_２はＭＮのＬ２アドレスとＩＰアドレスを含むトンネル確立要請メッセージを受信すると、ＭＮのＬ２アドレスとＩＰアドレスが対応したプロキシ近隣キャッシュを生成し、AggＡＲの間でトンネルを確立してAggＡＲから受信したＭＮあてのパケットをバッファリングし、ＭＮが自己にハンドオーバしたときにバッファリングしていたＭＮあてのパケットをプロキシ近隣キャッシュに基づいてＭＮに送信する。
【選択図】図２

Description

本発明は、移動通信制御方法、移動通信システム及びルータに関する。

現在、モバイル端末でのインターネットアクセスを可能とする「モバイルアクセス網」の改善と開発がなされている。特に、ＩＰでの通信が可能であり、通信が途絶することなく移動が可能となるモバイル網の実現が望まれている。

下記の特許文献１では、図３に示すようにモバイル端末（Mobile Node：以下、ＭＮ）がモバイルＩＰを利用する環境下において、ＭＮがハンドオーバ時にルータ情報を得るために、（１）でルータ要請メッセージ（Router Solicitation：以下、ＲＳ）をハンドオーバ先アクセスルータ（new Access Router：以下、ｎＡＲ）に送信して、ルータ広告メッセージ（Router Advertisement：以下、ＲＡ）を要求して（２）で受信するか、若しくは定期的にルータが送信するＲＡを受信することを前提とするモバイルノード（ＭＮ）に着目している。このＭＮは、（３）でＲＡを受信してから気付アドレス（Care-of-Address：以下、ＣｏＡ）を生成し、ホームエージェント（Home Agent：以下、ＨＡ）にＣｏＡを通知するために結合更新メッセージ（Binding Update：以下、ＢＵ）をｎＡＲに送信する。このとき、ｎＡＲにおいて近隣キャッシュ（Neighbor Cache）が存在していないので、ＢＵに対するＡｃｋである結合確認メッセージ（Binding Acknowledgement：以下、ＢＡ）をＭＮに転送する際に、近隣探索（Neighbor Discovery）を行って、ＭＮのＬ２アドレス解決を行う必要がある。この間、ｎＡＲではＭＮあてのパケットが送信されずにバッファされて送信待ちの状態となる。したがって、ＭＮのパケット受信時間の遅延や、ＡＲのバッファ領域を超えるパケットが転送されてきた場合には、パケットロスを発生することもあり、ハンドオーバ後の通信の再開を妨げる。

この問題を解決するために、特許文献１では、（３）でＢＵを送信したＭＮは、同時に（４）でｎＡＲに対してエコー要求メッセージ（ICMP echo request）を送信することを提案している。この間の処理のシーケンスを図３に記載してある。（４）でICMP（Internet Control Message Protocol）echo requestを受信したｎＡＲは、（７）でエコー応答メッセージ（ICMP echo reply）をＭＮに送信するためにＬ２アドレスの解決が必要となる。このため、（５）でｎＡＲは近隣要請メッセージ（Neighbor Solicitaion：以下、ＮＳ）をＭＮに送信し、（６）でＭＮから近隣広告メッセージ（Neighbor Advertisement：以下、ＮＡ）を受信することで、ｎＡＲは近隣キャッシュ（Neighbor Cache）を生成し、（７）でICMP echo requestをＭＮあてに送信する。この結果、ｎＡＲにＭＮのNeighbor Cacheができるので、ｎＡＲはＭＮあてのＢＡを（８）で、データパケットを（９）（１０）（１１）で受信した際に、近隣探索（Neighbor Discovery）を行ってＬ２アドレス解決をすることなく、パケット転送を行うことが可能となる。

また、下記の非特許文献１にはＩＰトンネルを用いた移動制御が開示されている。非特許文献１に記載されている技術はProxy Mobile IP（以下、Proxy MIP）と呼ばれるものである。Proxy MIPは、図４のようにサービスノード（Service Node：以下、ＳＮ）と基地局（Base Station：以下、ＢＳ）の間でＩＰトンネルを用いて、相手先（Correspondent Node：以下、ＣＮ）からＭＮへのパケット転送経路を決定している。図４において、パケットに付加されているＩＰヘッダのアドレスは以下のものである。ただし、ＩＰはversion6のＩＰである。
* ＭＮＨＡ（Mobile Node Home Address）：ＭＮのＨｏＡ。
* ＣＮＡ（Correspondent Node Address）：ＣＮのＩＰアドレス。
* ＣｏＡ（Care of Address) ：ＭＮが通信を行うに際して使用するインタフェースに付与しているＩＰアドレス。ＣｏＡのprefixはＳＮが割り当てる。Mobile IPでの動きと同様に、ＣｏＡはＨＡにＢＵ（Binding Update）をすることでＨｏＡとの対応を通知する。
* ＨＡＡ(Home Agent Address)：ＭＮのＨＡのＩＰアドレス。
* ＡＲ＠：ＭＮがリンクしているＢＳに付与されたＩＰアドレス。ＢＳを特定可能とするためにＢＳと一対一に割り当てられたprefix（６４bit）とＭＮのインタフェースＩＤ（６４bit）から生成する。ＢＳがこのアドレスをＳＮに通知することで、ＳＮはＭＮの位置を把握することが可能となる。

Proxy MIPを使ったパケット転送では、図４において、ＣＮがＭＮ（ＨｏＡがＭＮＨＡ)あてに送信したパケットが、ＭＮまでに転送されるまでの処理の説明をする。ＭＮＨＡあてに送信したパケット（図４の１．）は、ＨＡで送信元をＨＡＡ、送信先をＣｏＡとしたＩＰカプセル化をされて転送される（図４の２．）。この処理は、Mobile IPでの処理である。このＣｏＡあてのパケットはＳＮまで転送されて、ＳＮでアクセスネットワーク（access network）内でのパケット転送用のトンネリングを行う。このトンネリングには、パケットの送信先（ＣｏＡ）をＭＮがリンクしているＢＳのアドレスであるＡＲ＠へと変更して転送することで行う（図４の３．）。ＢＳ内部にＣｏＡとＡＲ＠の対応を記録しておくことで、ＢＳは送信先（ＡＲ＠）から本来の送信先であるＣｏＡを特定することができる。ＢＳで送信先（ＡＲ＠）をＣｏＡに戻されたパケットは、ＭＮに向けて無線リンクを転送される（図４の４．）。

ＢＳはＭＮがリンクしてきたら、ＢＳと一対一の関係にあるprefixとＭＮのＣｏＡのインタフェースＩＤを使って、ＡＲ＠を生成してＳＮにＣｏＡとＡＲ＠の対応を通知する。このようなアドレス生成をすることで、ＳＮではこのＡＲ＠のprefixからＭＮがリンクしているＢＳを特定することが可能となる。また、ＢＳでは、転送されてきた不特定のパケットの送信先アドレスであるＡＲ＠のインタフェースＩＤから、本来の転送先であるＣｏＡを特定することができる。

このように、ＢＳがＳＮにＭＮの位置を報告することが目的で、ＣｏＡとＡＲ＠の対応を通知するメッセージに、Mobile IPでのＢＵ（Binding Update）を用いる。ＢＳがＭＮの代わりに位置登録のＢＵを送信するので、この技術は、Proxy MIPと呼ばれている。このProxy MIPでは、ＢＳとＳＮ間でＩＰトンネリングが用いられているので、このアクセスネットワーク内でのハンドオーバを行っている限り、ＣｏＡの変更が起こらない。したがって、昨今、検討が盛んに行われているマイクロモビリティの制御に適している。マイクロモビリティでは、Mobile IPのようにグローバルネットワークでの移動制御を実現するのではなく、管理範囲を限定して、処理負荷やメッセージ送受信といった制御負荷の少ない移動制御を実施することを目的としている。

また、マイクロモビリティに対する要求の高まりを受けて、非特許文献１で挙げたようなトンネリングを用いた移動制御方式の検討を行い、標準化を実施する動向が起こっている。現在（２００５年１０月５日）、この標準化は、下記の非特許文献２に示すように、IETFのnetlmmというグループにて実施が試みられている。まだ、検討が始まったばかりであるため、システムアーキテクチャへのrequirementが提示されたのみである。非特許文献２に示されているrequirementでは、図５に示すようなネットワーク構成が考えられている。この構成のネットワークをＬＭＭ（Localized Mobility Management）ネットワーク又はドメインと呼ぶこととする。

ＣＮ側の外部ネットワークと接続するアグリゲーションＡＲ（Aggregation AR：以下、AggＡＲ）と、ＭＮと接続するＡＲ_１、ＡＲ_２、ＡＲ_３の間のネットワーク（ＬＭＭドメイン１００）では、非特許文献１で挙げたようなＩＰトンネルの技術を用いて、データパケットの転送パスを生成している。ＭＮは、Mobile IPを用いてＣｏＡを生成し、ＨＡにＣｏＡとＨｏＡ（Home Address）との対応をＢＵメッセージによって通知している。ただし、ＭＮは、AggＡＲの管理下にあるＡＲ_１、ＡＲ_２、ＡＲ_３間をハンドオーバしている際にはＣｏＡの変化を起こさない。そのため、ＭＮからＨＡへのＢＵを行っての位置登録処理は、ＬＭＭドメイン１００間でのハンドオーバを行ったときだけ行われる。

このアドレス変更を起こさない移動制御を行う領域をＬＭＭドメインと呼ぶこととし、以下では、「ハンドオーバ」と記載した場合は「ＬＭＭドメイン内のＡＲ間でのハンドオーバ」を指し、「ＬＭＭドメイン間ハンドオーバ」と記載した場合は「ＬＭＭドメインを跨いでのＡＲ間のハンドオーバ」を指すこととする。ＬＭＭネットワークの検討は、始まったばかりであり、明確な仕様はまだない。そのため、ＬＭＭドメイン内でのＩＰトンネルの生成方法及び制御方法に対しての仕様もない。そのため、現状での検討では、Proxy Mobile IP以外にもIP-in-IPトンネリングを使う手法など様々な手法が提案されている。しかし、どの手法でのプロトコル策定がなされたとしてもＡＲが、ＭＮにとってのfirst hop routerとなることでは共通している。
特開２００５−２７０４７号公報（要約書、図４） Local mobility for 3GPP System Architecture Evolution（ノキア提出）http://www.3gpp.org/ftp/Joint_Meetings/S2R3_0605_Montreal/Docs/SRJ-050061.zip netlmm：draft-kempf-netlmm-nohost-ps-00.txt、draft-kempf-netlmm-nohost-req-00.txt（これらは、IETFに提出されたInternet draftの文章である。）

図６は本発明が解決しようとする課題を説明するためのシステム及びその通信シーケンスを示す説明図である。図６に示すように、通常、ハンドオーバを行ったＭＮは、ハンドオーバ先のＡＲ_１、ＡＲ_２、ＡＲ_３が広告するprefixを知ることとＡＲ_１、ＡＲ_２、ＡＲ_３のリンクローカルアドレスを知るために、ＡＲ_１、ＡＲ_２、ＡＲ_３にそれぞれＲＡ_１、ＲＡ_２、ＲＡ_３の送信を要求するＲＳを送信する。一方、ＬＭＭドメイン１００内でのハンドオーバを行ったＭＮも、ＭＮ内部のＩＰスタック若しくはＭＩＰスタックでの処理によって、ＲＳを送信する。このとき、ＲＡから、ＡＲのリンクローカルアドレスの情報を得て、ＭＮ内でdefault routerを設定する。ＬＭＭドメイン１００内でのハンドオーバ時には、ＭＮのＩＰアドレスが変わらないことを保証するシステムであることが要求されている。したがって、ＭＮはＲＡを受信してもＲＡのprefixを使ってＣｏＡを生成し直すことはないような機能の実現を検討している。１つの方法としては、各ＡＲが広告するＲＡに持たせるprefixをすべて同一のものとする方法がある。

しかし、このような方法を取ったとしても、ＡＲはＭＮにとってfirst hop routerとなるので、ＭＮのdefault routerはハンドオーバ先のＡＲとする必要がある。このため、ハンドオーバ後のＭＮでは、default routerの変更処理を完了するまで、データパケットの送信を行えない。また、ＬＭＭドメイン内にて、ＡＲが広告するprefixを単一のものとしてＭＮのＩＰアドレス変更を回避することで、シームレスハンドオーバを実現したとしても、ＡＲがＭＮのＮＣ（Neighbor Cache）を持っていないとＭＮあてのパケットをＭＮへの転送を開始できない。

そのため、特許文献１のような手法を取ることで、ＭＮあてのデータパケットがＡＲに到達する前にＮＣを生成することは有効である。しかし、特許文献１では、ハンドオーバのたびにＭＮがICMP echo requestをＡＲに向けて送信する必要があり、ＭＮは、標準のＩＰに対して特殊となる処理を行う必要がある。したがって、この手法は、汎用的な運用を妨げる方法であり、端末への特殊変更を回避するというＮＥＴＬＭＭの要求事項にも反している。また、特許文献１の手法では、各ＭＮがハンドオーバのたびに、ＭＮとＡＲ間でICMP echo requestとICMP echo replyの送受信が起こるので、制御メッセージがＭＮとＡＲ間の無線リンク上の帯域を圧迫する原因となることも問題である。以上の問題は、非特許文献１においても、非特許文献２においても触れられておらず、解決方法の提示もない。

本発明は上記従来の技術の問題点に鑑み、モバイルノードがドメイン内のルータ間をハンドオーバする際にモバイルノードのレイヤ３アドレスが変化しないシステムにおいて、ハンドオーバ先のルータがモバイルノードあてのパケットを、ＮＤ（Neighbor Discovery）の処理を行わずに即座にモバイルノードに転送することができる移動通信制御方法、移動通信システム及びルータを提供することを目的とする。

本発明は上記目的を達成するために、モバイルノードがドメイン内のルータ間をハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信制御方法であって、
前記モバイルノードが現在接続している第１のルータと前記ドメインのアグリゲーション・ルータの間でトンネルを確立してパケットを転送するステップと、
前記第１のルータから近隣の第２のルータに対し、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを送信するステップと、
前記トンネル確立要請メッセージを受信した前記第２のルータにおいて前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成するステップと、
前記第２のルータと前記アグリゲーション・ルータの間でトンネルを確立するステップと、
前記トンネルが確立した後、前記第２のルータ上の前記プロキシ近隣キャッシュを有効にするとともに、前記第２のルータにおいて前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングするステップと、
前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記第２のルータが前記バッファリングしていた前記モバイルノードあてのパケットを前記プロキシ近隣キャッシュに基づいて前記モバイルノードに送信するステップとを、
有するようにした。
上記方法により、ハンドオーバ先のルータがモバイルノードあてのパケットを、ＮＤ（Neighbor Discovery）の処理を行わずに即座にモバイルノードに転送することができる。

また、本発明は、前記第１のルータが、あらかじめ保持している近隣のルータの設置情報を参照して、前記トンネル確立要請メッセージの送信先となる前記第２のルータを決定するステップを更に有するようにした。
また、本発明は、前記アグリゲーション・ルータがあらかじめ各ルータの設置情報を保持しており、前記第１のルータが、前記アグリゲーション・ルータに問い合わせることによって、前記トンネル確立要請メッセージの送信先となる前記第２のルータを把握するステップを有するようにした。
また、本発明は、前記モバイルノードが周辺のルータを探索して前記第１のルータに通知することにより、前記第１のルータが前記トンネル確立要請メッセージの送信先となる前記第２のルータを把握するステップを有するようにした。

また、本発明は上記目的を達成するために、モバイルノードがドメイン内のルータ間をハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信システムであって、
前記モバイルノードが現在接続している第１のルータと前記ドメインのアグリゲーション・ルータの間でトンネルを確立してパケットを転送する手段と、
前記第１のルータから近隣の第２のルータに対し、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを送信する手段と、
前記トンネル確立要請メッセージを受信した前記第２のルータにおいて前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成する手段と、
前記第２のルータと前記アグリゲーション・ルータの間でトンネルを確立する手段と、
前記トンネルが確立した後、前記第２のルータ上の前記プロキシ近隣キャッシュを有効にするとともに、前記第２のルータにおいて前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングする手段と、
前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記第２のルータが前記プロキシ近隣キャッシュに基づいて前記バッファリングしていた前記モバイルノードあてのパケットを前記モバイルノードに送信する手段とを、
有する構成とした。
上記構成により、ハンドオーバ先のルータがモバイルノードあてのパケットを、ＮＤ（Neighbor Discovery）の処理を行わずに即座にモバイルノードに転送することができる。

また、本発明は上記目的を達成するために、モバイルノードがドメイン内の第１のルータから第２のルータにハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信システムにおける前記第２のルータであって、
前記第１のルータと現在接続している前記モバイルノードが送信した、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを受信した場合に、前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成するプロキシ近隣キャッシュ生成手段と、
前記ドメイン内のアグリゲーション・ルータの間でトンネルを確立するトンネル確立手段と、
前記トンネルが確立した後、前記プロキシ近隣キャッシュを有効にするとともに、前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングするバッファリング手段と、
前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記バッファリングしていた前記モバイルノードあてのパケットを前記プロキシ近隣キャッシュに基づいて前記モバイルノードに送信する手段とを、
有する構成とした。
上記構成により、ハンドオーバ先のルータがモバイルノードあてのパケットを、ＮＤ（Neighbor Discovery）の処理を行わずに即座にモバイルノードに転送することができる。

本発明によれば、ＬＭＭドメインなどの内部においてモバイルノードのハンドオーバ完了後に、ハンドオーバ先のルータに転送されてきたデータパケットを、ＮＤＰ（Neighbor Discovery Protocol）の処理を行わずに即座にＭＮに転送できる。また、モバイルノードからのパケット送信もハンドオーバ完了後にＮＤＰ処理を行わずに即座にできる。この結果、モバイルノードのハンドオーバ後にモバイルノードとハンドオーバ先のルータでのパケット送受信の再開をシームレスに行うことが可能となる。

以下、図面を参照して本発明の実施の形態について説明する。図１は本発明に係る移動通信システムの一実施の形態を示す構成図、図２は図１の移動通信システムの通信シーケンスを示す説明図である。

本発明は、図３のネットワーク構成を持つＬＭＭドメイン１００内部で、移動通信を行うＭＮとＭＮのリンク先であるＡＲに着目する。図１に解決手法を図示し、図２にその際の処理のシーケンス図を示す。図１、図２は、ＡＲ_１に接続していたＭＮがＡＲ_２にハンドオーバしている状態を示している。図１のＬＭＭドメイン１００内をパケット転送する経路として、ＡggＡＲと、ＭＮがリンクしているＡＲ_１の周辺に位置しているＡＲ_２へのＰ２ＭＰ（point-to-multipoint）を構築しているとする。AggＡＲでは、ＭＮあてのパケットがＬＭＭドメイン１００の外部から転送されてくると、Ｐ２ＭＰパス上にパケットを複製して転送する。各ＡＲ_１、ＡＲ_２、ＡＲ_３では、AggＡＲで複製されて転送されてくるパケットをバッファリングし、ＭＮがリンクしてきたら、このバッファしていたパケットをＭＮあてに転送する。このことで、ＡＲ_１、ＡＲ_２、ＡＲ_３間をハンドオーバするＭＮに対して、ハンドオーバ処理中のパケットロスを回避させ、ソフトハンドオーバを提供することを可能としている。

以下に、本発明の一実施の形態の説明を行う。最初に、ハンドオーバを行ったＭＮが、ハンドオーバ先のＡＲに対するＮＤ（Neighbor Discovery）を行わないことで、パケット送信を即座に再開するための手法の説明を行う。ＬＭＭドメイン１００内にある各ＡＲ_１、ＡＲ_２、ＡＲ_３は、ＲＡ（Router Advertisement）で広告する自ノード情報を同じものとする。これは、ＭＮは、ＬＭＭドメイン１００内部をハンドオーバしても、default router（＝AggＡＲ）の変更が起こらないようにするためである。各ＲＡで共通して広告する自ノード情報は、ＡＲ_１、ＡＲ_２、ＡＲ_３のＬ２アドレス、ＡＲ_１、ＡＲ_２、ＡＲ_３のＬ３リンクローカルアドレス（以下、ＬＬアドレス）である。なお、default routerの有効時間を示すrouter lifetimeは、各ＡＲ_１、ＡＲ_２、ＡＲ_３で任意に設定しても構わないし、各ＡＲ_１、ＡＲ_２、ＡＲ_３で共通にしても構わない。

ＭＮが、自動アドレス生成を行う場合には、Ｌ３アドレス生成のために、ＲＡでprefixの広告を行うが、このprefixは、ＬＭＭドメイン１００内部で唯一のものでもよいし、ＭＮごとに異なるものでもよい。ＭＮがＬＭＭドメイン１００内部でのＡＲ_１、ＡＲ_２、ＡＲ_３間のハンドオーバを行う際に、Ｌ３アドレスの変更が起こらないことが保証された機能を持っていれば、prefixのＭＮへの広告手法と管理については、限定しない。本説明においては、prefixはＬＭＭドメイン１００内部にて、唯一のものがＭＮに対して広告されているとする。

以上のことより、ＭＮでは、default routerとして共通のアドレスを保持しているので、ハンドオーバ前にＡＲ_１とリンクしていたＭＮが持つＮＣ（Neighbor Cache）には、ＡＲ_２からＲＡを受信してもＭＮのＮＣは同一である。したがって、ＡＲ_１からＡＲ_２へのハンドオーバを完了したＭＮは、default routerの変更とＮＣの変更を行う必要がないため、パケット送信を即座に再開できる。

次に、AggＡＲからＭＮあてに転送したパケットをＭＮのハンドオーバ先のＡＲ_２から即座にＭＮに転送するための手法の説明をする。ＭＮがリンクしているＡＲの周辺のＡＲに対して、ＭＮのＬ２アドレスとＬＬアドレス及びＬ３のグローバルアドレス（以下、この３つのアドレスをＭＮアドレス情報と呼ぶ）を保持させる。このＭＮアドレス情報は、ＭＮがリンクしているＡＲが周辺ＡＲに対して通知する。各ＡＲでは、このＭＮアドレス情報をＮＣ（以下では、proxy Neighbor Cache）として保持する。このＮＣの状態を、「ＭＮがリンクをしていないが、ハンドオーバをしてくる可能性がある状態」として「proxy」という状態を定義して保持させる。ＭＮがリンクしてきたら、ＡＲでは、即座に「proxy」の状態から「reachable」の状態への状態遷移を起こし、ＡＲでバッファしていたパケットの転送を開始する。なお、ＭＮがリンクしているＡＲの「周辺のＡＲ」の選別には、ＡＲの周辺に地理的に近隣に設置されているＡＲをその選別の対象としてもよい。また、ＭＮの無線伝送機能を使って、ＭＮ周辺にあるＡＲをＭＮのリンク先ＡＲに通知させ、その情報を使って、ＭＮのリンク先ＡＲがＭＮの周辺のＡＲを選別する方法もある。

図２のハンドオーバ時の処理のシーケンスを使って、proxy Neighbor Cache（proxy ＮＣ）の使用方法について説明する。図２中のＡ〜Ｅは図１のＡ〜Ｅに対応している。図２では、ＭＮがＡＲ_１の配下で電源を投入した場合の説明をしている。このとき、proxy ＮＣの生成過程の説明を行うために、次の２点が行われていない。１つ目は、ＭＮはＡＲ_１とリンクしているが、AggＡＲとＡＲ_２間の経路がＭＮ用のＰ２ＭＰパスに含まれていない。２つ目には、ＡＲ_２にproxy ＮＣがない。この２点を満たす処理は、ＭＮがＡＲ間のハンドオーバを実行するたびに、リンク先ＡＲ_１の周辺にあるＡＲ_２に対して行う。

（１）ＡＲ_１とのリンクしたＭＮは、ＡＲ_１との間で、ＩＰ通信の開始時に行うＮＤＰを実施する。この結果、ＡＲ_１は、ＭＮにＬＭＭドメイン１００のprefixを通知し、ＭＮはアドレスを生成する。また、ＭＮは通信に先立ってＭＮアドレス情報をＡＲ_１にＮＤＰに従って通知する。若しくは、ＡＲ_１からのＭＮあてパケットを転送するために、ＡＲ_１がＮＤＰに従ってＭＮアドレス情報を収集する。なお、この過程は、ＩＰの標準的な処理であり、図２に図示していない。

（２）（１）でＭＮがＡＲ_１とリンクした直後に、ＡＲ_１とAggＡＲ間の経路を確立するために、ＡＲ_１はＭＮのＩＰアドレス（MN-IPaddr）とＡＲ_１のＩＰアドレス（AR_1-IPaddr）を含むトンネル確立要求メッセージをAggＡＲに送信する。このメッセージには、ＭＮアドレス情報を含めて通知することで、AggＡＲ内で、ＭＮ用のパスを識別するＩＤとして使用する。
（３）AggＡＲはＡＲ_１にＭＮのＩＰアドレス（MN-IPaddr）とＡＲ_１のＩＰアドレス（AR_1-IPaddr）を含むトンネル確立応答メッセージを送信して、AggＡＲとＡＲ_１間のパスを確立する。なお、このとき、トンネル確立応答メッセージにＡＲ_１の周辺にあるＡＲのリストを含めて通知してもよい。ＡＲ_１は、パスが確立されたら、ＭＮあてのパケット及びＭＮが送信したパケットの転送を開始する。

Ａ．また、ＡＲ_１は、ＭＮがハンドオーバする可能性のある周辺のＡＲ（図２ではＡＲ_２）に対して、Ｐ２ＭＰパスへの参加とproxy ＮＣの生成を要請するために、ＭＮのＬ２アドレス（MN-L2addr）とＩＰアドレス（MN-IPaddr）を含むトンネル確立要請メッセージを送信する。このメッセージには、ＭＮアドレス情報を含む。
（４）トンネル確立要請メッセージを受信したＡＲ_２は、ＭＮアドレス情報をproxy ＮＣとして保持する。このＮＣの状態は、「proxy」として、このアドレスに対するパケットの転送を行ってはならない。また、このＮＣに対してのパケットバッファリングを「invalid」とする。
（５）proxy ＮＣを生成したＡＲ_２は、ＭＮのＰ２ＭＰパスへの参加とAggＡＲで複製するパケット転送の開始を要求するために、ＭＮのＩＰアドレス（MN-IPaddr）とＡＲ_２のＩＰアドレス（AR_2-IPaddr）を含むトンネル確立要求メッセージをAggＡＲに向けて送信する。このメッセージには、ＭＮアドレス情報を含めている。
（６）AggＡＲは、ＭＮのＩＰアドレス（MN-IPaddr）とＡＲ_２のＩＰアドレス（AR_2-IPaddr）を含むトンネル確立応答メッセージをＡＲ_２に送信して、AggＡＲとＡＲ_２間にパスを確立し、ＭＮ用のＰ２ＭＰパスへＡＲ_２を収容する。なお、ＡＲ_２からのＭＮアドレス情報の通知を受けたAggＡＲは、すでにＭＮ用のパスが存在しているか、初めてトンネル確立の要求が来たのかをＭＮアドレス情報から識別する。

Ｂ．トンネル確立応答メッセージを受信したＡＲ_２では、proxy ＮＣのエントリに対するパケットバッファリングを「valid」にする。
（７）これ以降、AggＡＲからＭＮあてのパケットが転送されてくると、バッファする。
（８）この後、ＭＮが、ＡＲ_１とのリンクを外れ、ＡＲ_２とリンクをすると、ＭＮはＡＲ_２とのリンクを確立するために、ＭＮのＬ２アドレス（MN-L2addr）を含むＬ２リンク確立メッセージをＡＲ_２に送信する。
（９）ＡＲ_２は、ＭＮにＭＮのＬ２アドレス（MN-L2addr）を含むＬ２リンク確立応答メッセージを送信して、ＭＮとのリンク確立処理の完了をＭＮに通知する。

Ｃ．この結果、ＡＲ_２はＭＮとのリンクを確立するので、proxy ＮＣとして保持していたＭＮのエントリの状態を「reachable」とし、
Ｄ．バッファしていたパケット転送を開始する。
Ｅ．この後、ＡＲ_２は、周辺ＡＲに対して、（２）と同様なトンネル確立要請メッセージを送信して、ＡＲ_２の周辺にあるＡＲにproxy ＮＣの生成と、ＭＮ用のＰ２ＭＰパスへの参加を要請する。

なお、このリンク中のＡＲがトンネル確立要請メッセージを送信するハンドオーバ先ＡＲの決定は、各ＡＲが固定的に持っているＡＲの設置情報を基にしてもよい。また、ＡＲがAggＡＲに問い合わせて決定してもよい。また、ＭＮが、自ノードの周辺に存在するＡＲの情報を収拾してリンク中のＡＲに通知することで、ＡＲが把握してもよい。

本発明は、モバイルノードがドメイン内のルータ間をハンドオーバする際にモバイルノードのレイヤ３アドレスが変化しないシステムにおいて、ハンドオーバ先のルータがモバイルノードあてのパケットを、ＮＤ（Neighbor Discovery）の処理を行わずに即座にモバイルノードに転送することができるという効果を有し、ＬＭＭ（Localized Mobility Management）ネットワークなどに利用することができる。

本発明に係る移動通信システムの一実施の形態を示す構成図 図１の移動通信システムの通信シーケンスを示す説明図 従来の移動通信システムの通信シーケンスを示す説明図 他の従来の移動通信システム及びその通信シーケンスを示す説明図 さらに他の従来の移動通信システム及びその通信シーケンスを示す説明図 本発明が解決しようとする課題を説明するためのシステム及びその通信シーケンスを示す説明図

符号の説明

１００ ＬＭＭドメイン
ＭＮ モバイルノード
ＡＲ_１、ＡＲ_２、ＡＲ_３ アクセスルータ
AggＡＲ アグリゲーション・ルータ

Claims (6)

1. モバイルノードがドメイン内のルータ間をハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信制御方法であって、
   前記モバイルノードが現在接続している第１のルータと前記ドメインのアグリゲーション・ルータの間でトンネルを確立してパケットを転送するステップと、
   前記第１のルータから近隣の第２のルータに対し、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを送信するステップと、
   前記トンネル確立要請メッセージを受信した前記第２のルータにおいて前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成するステップと、
   前記第２のルータと前記アグリゲーション・ルータの間でトンネルを確立するステップと、
   前記トンネルが確立した後、前記第２のルータ上の前記プロキシ近隣キャッシュを有効にするとともに、前記第２のルータにおいて前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングするステップと、
   前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記第２のルータが前記バッファリングしていた前記モバイルノードあてのパケットを前記プロキシ近隣キャッシュに基づいて前記モバイルノードに送信するステップとを、
   有する移動通信制御方法。
2. 前記第１のルータが、あらかじめ保持している近隣のルータの設置情報を参照して、前記トンネル確立要請メッセージの送信先となる前記第２のルータを決定するステップを有する請求項１に記載の移動通信制御方法。
3. 前記アグリゲーション・ルータがあらかじめ各ルータの設置情報を保持しており、前記第１のルータが、前記アグリゲーション・ルータに問い合わせることによって、前記トンネル確立要請メッセージの送信先となる前記第２のルータを把握するステップを有する請求項１に記載の移動通信制御方法。
4. 前記モバイルノードが周辺のルータを探索して前記第１のルータに通知することにより、前記第１のルータが前記トンネル確立要請メッセージの送信先となる前記第２のルータを把握するステップを有する請求項１に記載の移動通信制御方法。
5. モバイルノードがドメイン内のルータ間をハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信システムであって、
   前記モバイルノードが現在接続している第１のルータと前記ドメインのアグリゲーション・ルータの間でトンネルを確立してパケットを転送する手段と、
   前記第１のルータから近隣の第２のルータに対し、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを送信する手段と、
   前記トンネル確立要請メッセージを受信した前記第２のルータにおいて前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成する手段と、
   前記第２のルータと前記アグリゲーション・ルータの間でトンネルを確立する手段と、
   前記トンネルが確立した後、前記第２のルータ上の前記プロキシ近隣キャッシュを有効にするとともに、前記第２のルータにおいて前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングする手段と、
   前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記第２のルータが前記プロキシ近隣キャッシュに基づいて前記バッファリングしていた前記モバイルノードあてのパケットを前記モバイルノードに送信する手段とを、
   有する移動通信システム。
6. モバイルノードがドメイン内の第１のルータから第２のルータにハンドオーバする際に前記モバイルノードのレイヤ３アドレスが変化しない移動通信システムにおける前記第２のルータであって、
   前記第１のルータと現在接続している前記モバイルノードが送信した、前記モバイルノードのレイヤ２アドレスと前記レイヤ３アドレスを含むトンネル確立要請メッセージを受信した場合に、前記モバイルノードの前記レイヤ２アドレスと前記レイヤ３アドレスが対応したプロキシ近隣キャッシュを生成するプロキシ近隣キャッシュ生成手段と、
   前記ドメイン内のアグリゲーション・ルータの間でトンネルを確立するトンネル確立手段と、
   前記トンネルが確立した後、前記プロキシ近隣キャッシュを有効にするとともに、前記アグリゲーション・ルータから受信した前記モバイルノードあてのパケットをバッファリングするバッファリング手段と、
   前記モバイルノードが前記第２のルータにハンドオーバしたときに、前記バッファリングしていた前記モバイルノードあてのパケットを前記プロキシ近隣キャッシュに基づいて前記モバイルノードに送信する手段とを、
   有するルータ。