JP3573098B2 - 移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 - Google Patents
移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 Download PDFInfo
- Publication number
- JP3573098B2 JP3573098B2 JP2001070120A JP2001070120A JP3573098B2 JP 3573098 B2 JP3573098 B2 JP 3573098B2 JP 2001070120 A JP2001070120 A JP 2001070120A JP 2001070120 A JP2001070120 A JP 2001070120A JP 3573098 B2 JP3573098 B2 JP 3573098B2
- Authority
- JP
- Japan
- Prior art keywords
- mobile terminal
- access router
- mobile
- binding update
- sub
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の相互に接続されたサブネットワークを備え、任意のサブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における移動端末管理システムに関する。
【０００２】
【従来の技術】
インタネットの爆発的な進展に伴い、従来音声サービスが中心であった移動網においてもデータサービスが急激に立ち上がり始めており、早晩データトラフィックが音声トラフィックを上回ることが予想されている。これに伴い移動網も音声中心のネットワークからモバイルインタネットに適したネットワークへと進化すべく３ＧＰＰやＧＰＰ２でＡＬＬ ＩＰの検討が進められている。またＩＥＴＦでもこれに呼応する形で、従来ＬＡＮ ユースのＩＰモビリティを議論していたＭＯＢＩＬＥ ＩＰ ＷＧが第三世代移動通信システムをスコープにいれ標準化を検討するようになってきた。本ＷＧでは、特に今後アドレス枯渇が懸念されているＩＰＶ４にかわるＩＰＶ６のＩＰモビリティ（Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６ ＜ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１２．ｔｘｔ ＞）の検討が活発化してきている。従来のＭｏｂｉｌｅ ＩＰＶ６ では、ＭＮ（Ｍｏｂｉｌｅ Ｎｏｄｅ） が新たにサブネットワークへ移動した場合、ＭＮはＨＡ（Ｈｏｍｅ Ａｇｅｎｔ）に対し登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ：以下ＢＵとも記す）を行う。ＭＮは相手端末（ＣＮ）からのパケットがＨＡ経由でＭｏｂｉｌｅ ＩＰＶ４ と同様トンネリングで送信された場合には、該ＣＮがＭＮのＣＯＡ（Ｃａｒｅ ｏｆ ａｄｄｒｅｓｓ）を知らないと判断し、ＣＮに対し自分のＨｏｍｅ ａｄｄｒｅｓｓとＣＯＡ のペア情報であるｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を送付する。これ以降、ＣＮはＭＮへパケット送信する場合、パケットをＭＮ宛に直接送信できるようになる。これにより、Ｍｏｂｉｌｅ ＩＰＶ６ では、Ｍｏｂｉｌｅ ＩＰＶ４ の欠点であったトライアングルルーチングを解決するｒｏｕｔｅ ｏｐｔｉｍａｚａｔｉｏｎ機能がサポートできるようになった。
【０００３】
更にハンドオフ時のパケットロスを極力回避するためＳＭＯＯＴＨ ＨＡＮＤＯＦＦ機能がサポートされる。Ｍｏｂｉｌｅ ＩＰＶ６ は、かかるＭｏｂｉｌｅ ＩＰＶ４ からの改善策を持つ一方、ネットワークモデルは、Ｍｏｂｉｌｅ ＩＰＶ４ と同じくＨＡとＭＮとのフラットなモデルとしている。このため、ＭＮがＨＡと物理的に遠く離れたネットワークへローミングした場合等には、ＲＥＧＩＳＴＲＡＴＩＯＮ要求がＭＮとＨＡ間のＲＯＵＮＤ ＴＲＩＰ ＤＥＬＡＹだけ遅延する欠点を有したままとなっている。これを解決する目的でＨｉｅｒａｒｃｈｉｃａｌ ＭＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ＜ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｈｍｉｐｖ６−０１．ｔｘｔ ＞というＩｎｔｅｒｎｅｔ Ｄｒａｆｔ（ 以下Ｉ−Ｄ と記す） が提案されている。図９に示すように本Ｉ−Ｄ ではネットワークモデルとして、ＭＮ−ＡＲ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）−ＭＡＰ（Ｍｏｂｉｌｉｔｙ Ａｎｃｈｏｒ Ｐｏｉｎｔ）−ＨＡからなる階層化構成を採用している。そしてＭｏｂｉｌｉｔｙ Ａｎｃｈｏｒ Ｐｏｉｎｔ（ＭＡＰ）がＨＡの代理機能をサポートすることにより、上記ＭＮの登録要求の遅延を削減することを可能にしている。
【０００４】
またこれとは別に、図１０に示すようなＨＡおよびＨｏｍｅ ａｄｄｒｅｓｓを不要にした新たなＩ−Ｄ（Ｈｏｍｅｌｅｓｓ Ｍｏｂｉｌｅ ＩＰｖ６＜ｄｒａｆｔ−ｎｉｋａｎｄｅｒ−ｍｏｂｉｌｅｉｐ−ｈｏｍｅｌｅｓｓｖ６−００．ｔｘｔ ＞） が２０００．１２．１１〜１２．１５ の期間開催されたＩＥＴＦ ＷＧ で提案されている。もともとＭｏｂｉｌｅ ＩＰＶ６ では、ＭＮとＣＮ間でやりとりされるｂｉｎｄｉｎｇ ｕｐｄａｔｅが、ＭＮとＣＮ間とで移動管理情報を共有し合うために用いられる。本Ｉ−Ｄ ではこのｂｉｎｄｉｎｇ ｕｐｄａｔｅを継承しＭＮでＨｏｓｔ Ｃａｃｈｅなる情報を保持することによりＨＡなしでも移動管理が実現できるとしている。本Ｉ−Ｄ のメリットとしてＨｏｍｅｌｅｓｓ ｓｕｐｐｏｒｔｉｎｇ Ｈｏｓｔ間同士のパケット送信では、Ｍｏｂｉｌｅ ＩＰＶ６ で用いるＲｏｕｔｉｎｇ ｈｅａｄｅｒおよびＨｏｍｅ ａｄｄｒｅｓｓ ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ が不要になりＩＰＶ６ヘッダのみでパケットを送受できることを挙げている。これにより９２バイトから４０バイトのパケット長の削減が図れるとしている。
【０００５】
【発明が解決しようとする課題】
以上のようにＭｏｂｉｌｅ ＩＰ ＷＧでは、Ｍｏｂｉｌｅ ＩＰＶ６ の改善提案が活発に行われている。しかし、現状提案されているＩ−Ｄ ではまだ以下のような課題が存在する。
【０００６】
まず、Ｈｉｅｒａｒｃｈｉｃａｌ ＭＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔでは以下のように欠点が指摘できる。本Ｉ−Ｄ の５．１ ＭＮ Ｏｐｅｒａｔｉｏｎｓ につぎのような記述がある。
Ｉｔ ｃａｎ ａｌｓｏ ｓｅｎｄ ａ ｓｉｍｉｌａｒ ＢＵ （ｉ．ｅ． ｔｈａｔ ｓｐｅｃｉｆｉｅｓ ｔｈｅ ｂｉｎｄｉｎｇ ｂｅｔｗｅｅｎ ｔｈｅ Ｈｏｍｅ Ａｄｄｒｅｓｓ ａｎｄ ｔｈｅ ＲＣｏＡ） ｔｏ ｉｔｓ ｃｕｒｒｅｎｔ ＣＮｓ．すなわち、Ｍｏｂｉｌｅ ＩＰＶ６ 同様ＭＮとＣＮ（相手が移動端末の場合はＭＮ）同士は互いにｂｉｎｄｉｎｇ ｕｐｄａｔｅをやりとりし、ｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を更新し合わないといけない。ここでｂｉｎｄｉｎｇ ｕｐｄａｔｅはエリアを跨いだ時に加え、リフレッシュのため定期的に更新する必要があるためｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りする相手端末が多い場合、ＭＮは頻繁にｂｉｎｄｉｎｇ ｕｐｄａｔｅを送受信することになる。このため、端末は待ちうけ時でもｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信するため送信モードとなる必要があり端末のバッテリ消費を早めることになる。このｂｉｎｄｉｎｇ ｕｐｄａｔｅ保持には端末のリソース（メモリ、ＣＰＵ 負荷）が必要であり、バッテリ消費に加え端末の小型化にも影響を与えることになる。
【０００７】
またｂｉｎｄｉｎｇ ｕｐｄａｔｅを移動端末間でやり取りするため、大規模移動網ではｂｉｎｄｉｎｇ ｕｐｄａｔｅトラフィックが大量に無線区間を飛び交うことになり、これによる無線リソースの消費が無視できなくなる。
【０００８】
更に以下の記述もある。
Ｔｈｅ ＭＡＰ ｗｉｌｌ ｒｅｃｅｉｖｅ ｐａｃｋｅｔｓ ａｄｄｒｅｓｓｅｄ ｔｏ ｔｈｅ ＭＮ’ｓ ＲＣＯＡ （ｆｒｏｍ ｔｈｅ ＨＡ ｏｒ ＣＮｓ）． Ｐａｃｋｅｔｓ ｗｉｌｌ ｂｅ ｔｕｎｎｅｌｌｅｄ ｆｒｏｍ ｔｈｅ ＭＡＰ ｔｏ ｔｈｅ ＭＮ’ｓ ＬＣＯＡ． Ｔｈｅ ＭＮ ｗｉｌｌ ｄｅｃａｐｓｕｌａｔｅ ｔｈｅ ｐａｃｋｅｔｓ ａｎｄ ｐｒｏｃｅｓｓ ｔｈｅ ｐａｃｋｅｔ ｉｎ ｔｈｅ ｎｏｒｍａｌ ｍａｎｎｅｒ． Ｍｏｂｉｌｅ ＩＰＶ４ では、ＣＮからＭＮ宛のパケットはＨＡでインタセプトされた後、ＭＮが在圏するＦＡ（Ｆｏｒｅｉｇｎ Ａｇｅｎｔ） 宛にｅｎｃａｐｓｕｌａｔｉｏｎ してトンネリングされる。これを受けたＦＡではこのパケットをｄｅｃａｐｓｕｌａｔｉｏｎ しＭＮ宛てに転送する。このようにＭｏｂｉｌｅ ＩＰＶ４ では、ＨＡでのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理が大規模移動網にスケールさせるためにボトルネックとなる可能性がある。同様に本ｍｏｂｉｌｅ ＩＰＶ６ 改善Ｉ−Ｄ においてもＣＮからＭＮ宛てのパケットは、ＭＡＰ でｅｎｃａｐｓｕｌａｔｉｏｎされるため大規模移動網ではこの処理量が問題となると考えられる。
【０００９】
また、Ｍｏｂｉｌｅ ＩＰＶ６ ではＭＮがＣＮにｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する機能は必須機能でなく、ＩＥＴＦ用語でＭＡＹ となっており必ずしも全ての端末がｂｉｎｄｉｎｇ ｕｐｄａｔｅ機能をサポートするとは言いきれない。とするとＩＰＶ６に進化した移動網において、なおＭｏｂｉｌｅ ＩＰＶ４ と同様Ｔｒｉａｎｇｌｅ ｒｏｕｔｉｎｇとＨＡでのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理がそのまま残る可能性が懸念される。
【００１０】
一方、Ｈｏｍｅｌｅｓｓ Ｍｏｂｉｌｅ ＩＰｖ６では次のような欠点を指摘できる。本Ｉ−Ｄ でも上記Ｉ−Ｄ と同じようにＭＮとＣＮとがｂｉｎｄｉｎｇ ｕｐｄａｔｅを用いてＨｏｓｔ ｃａｃｈｅを更新するためＭＮのバッテリ消費および大規模移動網でのｂｉｎｄｉｎｇ ｕｐｄａｔｅトラフィックによる無線リソースの消費問題を有する。また、相手端末が同じＨＯＭＥＬＥＳＳの場合、例えば両者が同時に新たなドメインを跨ぎ無線リンクを失うタイミングが発生すると考えられる。この場合、最悪、両者がお互いの位置情報（新規アドレス情報）を同時に失ってしまうことになる。そうすると、このアーキテクチャでは、お互いのアドレスが変化したことを相手に通知する手段がないと考えられる。但し、この問題は相手が固定端末では発生しないと考えられる。また、移動端末がもともと認識していない端末から初めて受信する場合、相手端末はこの移動端末のアドレスを知る手段がないと考えられる。いずれの場合でもＨＡの機能サポートが必要と考えられる。
【００１１】
以上の課題をまとめると以下のようになる。
（１） ＭＮが相手端末とｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りすることによるＭＮのバッテリ消費問題
（２） ＭＮが相手端末とｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りすることによる無線リソース消費問題
（３） ＨＡ（ＭＡＰ） のＭＮ宛てのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理による大規模移動網へのスケーラビリティ問題
【００１２】
【発明の目的】
本発明では、かかる従来技術の３つの課題を解決するシステムを提供することを目的としている。
【００１３】
【課題を解決するための手段】
本発明は複数の相互に接続されたサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における移動端末管理システムにおいて、前記サブネットワークは、アクセスルータを備え、前記アクセスルータは、在圏する前記移動端末のCOAを保持管理する端末管理テーブルと、在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新テーブルと、前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求を受け付けるホームエージェント代行手段とを有する。また、前記ホームエージェント代行手段が、在圏する前記移動端末から通信相手宛に送信されるパケットを受信してその宛先アドレスを当該通信相手のCOA に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットを受信して前記移動端末に転送する手段を有する。ここで、前記端末管理テーブルは在圏する前記移動端末のNAI 又はURI とCOA の組を保持する構成を有し、前記バインディング更新テーブルは各通信相手のNAI 又はURI とCOA の組を保持する構成を有し、前記移動端末から通信相手宛に送信されるパケットはその宛先アドレスに当該通信相手のNAI 又はURI が設定される。また、前記複数のサブネットワークはそれぞれ異なるネットワークプレフィックスを持ち、前記移動端末のCOA は在圏する前記サブネットワークのネットワークプレフィックスと当該移動端末のインタフェースIDとから構成される。
【００１４】
このようなホームエージェント代行手段を各アクセスルータが備えることにより、移動端末から通信相手へのパケット送信時、パケットをｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ する必要がなくなる。
【００１５】
また前記ホームエージェント代行手段は、在圏する前記移動端末から通信相手宛に送信されるパケットの宛先アドレスを前記ＮＡＩ 又はＵＲＩ から前記ＣＯＡ に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットの宛先アドレスを前記ＣＯＡ から前記ＮＡＩ 又はＵＲＩ に書き換えて前記移動端末に転送する構成を有する。これにより、端末ユーザはパケット送信時にメールアドレスと同じ形式のアドレス（ＮＡＩ） やＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のアドレス（ＵＲＩ） を使用することができる。
【００１６】
また前記アクセスルータは、前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を受け付ける手段を備え、且つ、移動前のサブネットワークの前記アクセスルータと移動後のサブネットワークの前記アクセスルータとの間で、当該移動端末用の前記バインディング更新テーブルの受け渡し及び当該移動端末にかかるホームエージェント代行機能の移管を行う手段を備える。これにより、移動端末の移動の際にアクセスルータがホームエージェントの代わりに移動端末からの登録要求を受け付け、且つ自動的にホームエージェント代行機能を移動先のサブネットワークのアクセスルータに移管することができる。
【００１７】
また本発明における前記アクセスルータは、自サブネットワークに移動してきた前記移動端末の前記バインディング更新テーブルを受け取ったときに当該バインディング更新テーブルに記載されている全ての通信相手に対して前記移動してきた移動端末の新たなＣＯＡ を通知するバインディング更新パケットを送信すると共に、在圏する移動端末宛の前記バインディング更新パケットを他のアクセスルータから受信したときに該当する前記バインディング更新テーブルを更新する移動端末代行手段を備える。
【００１８】
このような移動端末代行手段を各アクセスルータが備えることにより、移動端末自身が通信相手にバインディング更新パケットを送信する必要がなくなる。
【００１９】
【発明の実施の形態】
［構成］
本発明の実施の形態にかかる移動網における移動端末管理システムは、次に示す手段を有する。
○アクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ、ＡＲ）
移動端末ＭＮから１ホップの関係にあるＩＰＶ６ルータがアクセスルータとなり、ＨＡの代理機能かつ移動端末ＭＮ（通信相手ＣＮ） の代理機能を持つ。すなわち、ＨＡに代わり移動端末ＭＮからの登録要求を受け付ける手段と、移動端末ＭＮ（通信相手ＣＮ）に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を保持、更新する手段を有する。かつ、移動端末ＭＮからＡＲ（Ｐｒｅｖｉｏｕｓ ＡＲと記す） に対する登録要求（ＢＵ）が移動端末ＭＮの移動先ＡＲ（Ｎｅｗ ＡＲ と記す） 経由であった場合、該Ｐｒｅｖｉｏｕｓ ＡＲ が、該移動端末ＭＮに対する登録応答に該移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を付加しＮｅｗ ＡＲへ転送する手段、および該ｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報が付加された登録応答受信をトリガにしてＮｅｗ ＡＲが、該ＭＮの代理ＨＡおよび代理ＭＮ機能を該Ｐｒｅｖｉｏｕｓ ＡＲ から受け継ぐ手段を持つ。ここで、ＨＡの代理機能をサポートする具体的手段として端末管理テーブルを、移動端末ＭＮ（ＣＮ）の代理機能をサポートする具体的手段としてｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを有する。
○移動端末ＭＮ
従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様ＣＯＡ 獲得の手段および登録要求を代理ＨＡへ行う手段を持つ。
【００２０】
［動作］
本発明の実施の形態のかかる移動網における移動端末管理システムでは、次のような動作が行われる。
（１）登録要求（代理ＨＡ機能）
移動端末ＭＮが新たなサブネットワークへ移動した場合、従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様ルータ広告から別のサブネットワークに移動したことを認識し、登録要求を移動前の代理ＨＡ（Ｐｒｅｖｉｏｕｓ ＡＲ） に対し行う。この登録要求は移動端末ＭＮから１ホップの位置にある移動先のＮｅｗ ＡＲ経由でＰｒｅｖｉｏｕｓ ＡＲ へ転送される。Ｐｒｅｖｉｏｕｓ ＡＲ は、この登録要求を受けると端末管理テーブルから該移動端末ＭＮが移動直前まで自分のエリアにいたことを確認するとともに、該移動端末ＭＮとのｓａ（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）に従い該移動端末ＭＮが不正な端末でないかどうか確認する。不正な端末でないことを認証できた場合にはＨＡに代わり登録応答をＮｅｗ ＡＲに返す。
【００２１】
この登録応答はＰｒｅｖｉｏｕｓ ＡＲ からＮｅｗ ＡＲに該移動端末ＭＮの代理ＨＡ機能が移行したことを通知するトリガとなる。この登録応答にはｐｒｅｖｉｏｕｓ ＡＲ が保持していた該移動端末ＭＮ用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルが含まれる。
【００２２】
Ｎｅｗ ＡＲはＰｒｅｖｉｏｕｓ ＡＲ からこの登録応答を受けると、該移動端末ＭＮに対し登録応答を返す。
【００２３】
（２）登録要求（代理ＭＮ機能）
次にＮｅｗ ＡＲは、該当移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照し、該当移動端末ＭＮの相手端末（ＣＮ）に対し該当移動端末ＭＮに代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する。このｂｉｎｄｉｎｇ ｕｐｄａｔｅを受けた相手端末ＣＮの最終ホップのルータ（ＡＲ）は、該当相手端末ＣＮに変わり該当相手端末ＣＮ用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを更新する。
【００２４】
（３）パケット送受信
移動端末ＭＮは、相手端末ＣＮ宛にパケット送信する場合、ＳＡ（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）＝ＣＯＡ 、ＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ） ＝ＣＮのＮＡＩ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）又はＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ） としパケットを送信することができる。該移動端末ＭＮの代理ＨＡ（アクセスルータＡＲ）は、該移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルから相手端末ＣＮの最新アドレスを知りＤＡ＝相手端末のＣＯＡ にセットしてパケットを転送する。パケットは該相手端末ＣＮの代理ＨＡ（アクセスルータＡＲ）経由で配送される。
【００２５】
【実施例】
［１］構成の説明
図１は本発明の実施例のシステム構成図を示す。図１に示すように本実施例のシステムは移動端末ＭＮ、アクセスルータＡＲ（ＡＲ１〜ＡＲｎ）、および通信相手ＣＮならびにアクセスルータＡＲ間を相互に接続するインターネット等のＩＰコアネットワークからなる。アクセスルータＡＲは移動端末ＭＮから１ホップの関係にあるＩＰ（アクセス）ルータであり、ＨＡの端末移動管理代理機能およびＭＮ（ＣＮ）の移動管理代理機能を持つ。図１の構成を３Ｇ移動網に対応させるとアクセスルータＡＲと移動端末ＭＮの関係は、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と移動端末、ｃｄｍａ２０００の場合のＰＤＳＮと移動端末の関係に該当する。またＭＷＩＦで検討が始まっているＯＰＥＮ ＬＡＮのアーキテクチャでは、ＲＮＣ もしくはＮｏｄｅ Ｂが将来ＩＰルータの機能を持つようになると考えられる。このアーキテクチャに当てはめると、アクセスルータＡＲと移動端末ＭＮの関係はＲＮＣ もしくはＮｏｄｅ Ｂと移動端末の関係に該当する。
【００２６】
図２は本実施例における移動端末ＭＮの登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）のシーケンス例を示す。図２に示すように移動網は各々異なるＮｅｔｗｏｒｋ ｐｒｅｆｉｘを持つサブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ で構成され、各サブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ には一つのアクセスルータを持つ。また移動端末は、アクセスルータを介して移動網にアクセスしネットワークサービスを受けたり他の端末と通信を行う。図２では４つのサブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ の例を示しており、各サブネットワークはＭ，Ｎ，Ｘ，Ｙ と記載したｎｅｔｗｏｒｋ ｐｒｅｆｉｘを持つものとする。また各サブネットワークはＡＲＭ，ＡＲＮ，ＡＲＸ，ＡＲＹ と記載したアクセスルータを持ち、ＣＮＤ，ＣＮＥ，ＭＮＡ，ＭＮＢ，ＭＮＣ と記載した移動端末が各サブネットワーク内に在圏している場合を示している。図２の登録要求シーケンス例は移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ移動した場合について示すものである。
【００２７】
図３は、代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータＡＲにおける端末の移動管理機能の構成例を示す。図３の（１）および（３）がアクセスルータＡＲの代理ＨＡ機能である端末の端末管理テーブルを示す。図３の（２）が、アクセスルータＡＲの端末の代理機能となるｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを示す。ここで図３の（１）は、移動端末ＭＮＡ が移動直前に在圏していたサブネットワークＳＹのアクセスルータＡＲＹ の端末管理テーブルを、図３の（２）が、移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを、図３の（３）が移動端末ＭＮＡ がサブネットワークＳＸへ移動後のアクセスルータＡＲＹ の端末管理テーブルを示している。図３の（１）および（２）に示すように、各移動端末のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルは端末管理テーブルの該当端末欄にあるポインタで関係付けられる。ここで、移動端末がサブネットワークを移動すると代理ＨＡの機能も移動先のアクセスルータＡＲ（Ｎｅｗ ＡＲ）に移動する。この場合、Ｐｒｅｖｉｏｕｓ ＡＲ からＮｅｗ ＡＲへ該当端末のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルが引き継がれる。
【００２８】
図４は図２に示すアクセスルータＡＲＮ の端末管理テーブル（図４の（１））および移動端末ＣＮＥ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す。ここで、図４の（２）および（３）は、移動端末ＣＮＥ の通信相手である移動端末ＭＮＡ がサブネットワーク移動前および移動後に対応したｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す。
【００２９】
ここで、移動端末ＭＮＡ やＣＮＥ 等のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルには、その端末のユーザが通信を行う相手毎のＮＡＩ またはＵＲＩ とＣＯＡ の組が登録される。このようなｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの初期生成方法としては、各端末ユーザが全ての通信相手のＮＡＩ またはＵＲＩ とＣＯＡ の組のリストを作成して、在圏するアクセスルータにｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの登録を依頼する方法がある。また、リスト中のＣＯＡ の部分は空白にして、通信相手のＮＡＩ またはＵＲＩ のリストだけをアクセスルータに通知することも可能である。この場合、アクセスルータに初期生成されるｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルもＣＯＡ の部分は空白となるが、通信相手が移動登録を行うと後述するようにして最新のＣＯＡ が順次に書き込まれていき、全通信相手が一度でも移動登録を行うとｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの内容が完成することになる。
【００３０】
図５の（１）は移動端末ＭＮＡ が新たなサブネットワークへ移動した場合に、今まで在圏していた代理ＨＡであるアクセスルータＡＲＹ に送信する登録要求（ＢＵ）のパケットフォーマット例、図５の（２）は移動端末ＭＮＡ からの登録要求に対する登録応答のパケットフォーマット例、図５の（３）は、移動端末ＭＮＡ の新たな代理ＨＡであるアクセスルータＡＲＸ が移動端末ＭＮＡ に代わり通信相手に送信する登録要求ＢＵのパケットフォーマット例を示す。
【００３１】
図６は、移動端末から通信相手宛てのパケット送信のシーケンス例を示す。図６では、移動端末ＭＮＡ から通信相手ＣＮＥ へパケットを送信する場合を示す。
【００３２】
図７はＨａｎｄ ｏｆｆシーケンス例を示す。図７では移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ通信中に移動した場合のｈａｎｄ ｏｆｆシーケンス例を示す。
【００３３】
図８は、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｃｃｏｕｎｔｉｎｇ）サーバとの連携例を示す。
【００３４】
［２］動作の説明
次に本実施例の動作を図を用いて説明する。
（１） 登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）：代理ＨＡ機能
図２に本実施例の登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）のシーケンス例を示す。図２の登録要求シーケンス例は移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ移動した場合について示すものである。移動端末ＭＮＡ がサブネットワークＳＹから新たサブネットワークＳＸへ移動した場合、従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様、移動先のルータ広告から別のサブネットワークに移動したことを認識する。図２ではＩＰＶ６ルータであるアクセスルータＡＲＸ がこのルータ広告を出す。移動端末ＭＮＡ は移動したことを認識すると、従来の移動端末と同様にＣＯＡ を獲得する。ＣＯＡ の獲得方法はＤＨＣＰＶ６によるＳｔａｔｅｆｕｌｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ もしくはｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ（ＲＦＣ１９７１）いずれでもよい。図２では移動端末ＭＮＡ が新たに獲得したＣＯＡ の例としてＸ：ａ と記している。ここでＸ：ａ は、１２８ ビット長のＩＰＶ６のアドレスを示しており、 ＸはサブネットワークＳＸのｎｅｔｗｏｒｋ ｐｒｅｆｉｘ、ａ は移動端末ＭＮＡ のインタフェースＩＤを示す。
【００３５】
次に移動端末ＭＮＡ は、登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を移動前の代理ＨＡ（Ｐｒｅｖｉｏｕｓ ＡＲ） であるアクセスルータＡＲＹ に対し行う。移動端末ＭＮＡ は、図５の（１）に示すように登録要求の送信元アドレス（ＩＰＶ６ヘッダ内の送信元アドレスＳＡ）として移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）を、あて先アドレス（ＩＰＶ６ ヘッダ内のあて先アドレスＤＡ） にアクセスルータＡＲＹ のアドレス（Ｙ：ｙ） をセットする。またＭｏｂｉｌｅ ＩＰＶ６ の Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ（もしくはＩＰＶ６のＲｏｕｔｉｎｇ ｅｘｔｅｎｔｉｏｎ ｈｅａｄｅｒ）を用い、登録要求の経路指定を行う。ここでは途中の経路ノードとしてアクセスルータＡＲＸ を指定するため、アクセスルータＡＲＸ のアドレス（Ｘ：ｘ） をセットする。この指定により移動端末ＭＮＡ の登録要求は、移動端末ＭＮＡから１ホップの位置にある移動先のアクセスルータＡＲＸ 経由で移動前のアクセスルータＡＲＹ へ転送される（図２の（１））。また、端末ユーザがパケット送信時にメールアドレスと同じ形式のアドレスもしくはＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）端末のユーザがＳＩＰ のアドレス（ＵＲＩ） を使用できるよう移動端末ＭＮＡ のＮＡＩ（ＲＦＣ；Ｎｅｔｗｏｒｋ ａｃｃｅｓｓ ｉｄｅｎｔｉｆｉｅｒ）もしくはＳＩＰ ＵＲＩ をＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ にセットしてもよい。ここでは移動端末ＭＮＡ のＮＡＩ としてｏｈｋｉ＠ｎｅｃ．ｃｏｍを例に挙げている。
【００３６】
アクセスルータＡＲＸ はこの登録要求を受けると、途中の経路アドレスが自分のアドレスであることから端末管理テーブルに移動端末ＭＮＡ のＮＡＩ とＣＯＡ を追加するとともに登録要求パケットをアクセスルータＡＲＹ 宛に転送する。
【００３７】
アクセスルータＡＲＹ は、この登録要求を受信すると登録要求の送信元アドレス（ＳＡ）から登録要求を行った端末の新たなＣＯＡ を、またＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ からＮＡＩ（あるいはＳＩＰ ＵＲＩ）を知る。アクセスルータＡＲＹ は、このＮＡＩ および ＣＯＡをもとに代理ＨＡの手段を実現している端末管理テーブルをサーチする。ここで、図３の（１）にアクセスルータＡＲＹ の端末管理テーブルの構成例を示す。同図に示すようにこの端末管理テーブルは、管理する各端末のＮＡＩ （あるいはＳＩＰ ＵＲＩ ）、ＣＯＡ およびｓａ （ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ； アクセスルータＡＲＹ と各端末間の認証アルゴリズムおよび認証鍵） がセットになっている。ここで図３（１）は、移動端末ＭＮＡ がサブネットワークＳＸへ移動する前の状態を示しており、移動端末ＭＮＡ のＮＡＩ であるｏｈｋｉ＠ｎｅｃ．ｃｏｍに該当するＣＯＡ は移動前のＣＯＡ ＝Ｙ：ａ となっている。アクセスＡＲＹ はこの端末管理テーブルをサーチした結果、移動端末ＭＮＡ のＣＯＡ がＹ：ａ であることから移動直前まで自分のサブネットワークＳＹに在圏していたことを確認するとともに、該移動端末ＭＮＡ とのｓａ （ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ） に従い該移動端末ＭＮＡ が不正な端末でないかどうか確認する。ここで、移動端末ＭＮＡ の登録要求には、Ｒｅｐｌａｙ ａｔｔａｃｋ 対策として例えば今までの代理ＨＡ（ＡＲＹ） からのルータ広告で得たＣｈａｌｌｅｎｇｅ 値に対するＲｅｓｐｏｎｓｅ値が挿入されており、アクセスルータＡＲＹ で移動端末ＭＮＡ が不正な端末かどうか認証できるようになっている。移動端末ＭＮＡ が不正な端末でないことを認証できた場合には移動端末ＭＮＡ のＣＯＡ を新たなＸ：ａ に書き換えるとともに、ＨＡに代わり登録応答をアクセスルータＡＲＸ 経由で移動端末ＭＮＡ に返す（図２の（２），（３））。図３の（３）の端末管理テーブルは、アクセスルータＡＲＹ が移動端末ＭＮＡ のＣＯＡ を新たなＸ：ａ に書き換えた後の状態を示す。
【００３８】
次にアクセスルータＡＲＹ は移動端末ＭＮＡ に対し登録応答を返す。図５の（２）に示すように、登録応答パケットの送信元アドレス（ＳＡ）としてアクセスルータＡＲＹ のアドレス（Ｙ：ｙ） を、送信先アドレス（ＤＡ）として移動端末ＭＮＡ のＣＯＡ （Ｘ：ａ）をセットする。また、Ｍｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ に途中経由するルータのアドレスとして移動端末ＭＮＡ の新たな代理ＨＡであるアクセスルータＡＲＸ のアドレス（Ｘ：ｘ） をセットする。これに加えアクセスルータＡＲＹ は、自身が保持していた移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報をパケットのｐａｙｌｏａｄ に書き込み送信する。
【００３９】
この登録応答パケットをアクセスルータＡＲＸ が受信すると、パケットの識別子から登録応答であること、最終あて先がアクセスルータＡＲＸ のルータ広告に反応し登録要求を出した移動端末ＭＮＡ であること、且つＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ 内のアドレスが自分のアドレスであることを認識する。これによりアクセスルータＡＲＸ は、アクセスルータＡＲＹ から移動端末ＭＮＡ の代理ＨＡ機能が移行したことを認識する。
【００４０】
アクセスルータＡＲＸ（Ｎｅｗ ＡＲ） はアクセスルータＡＲＹ（Ｐｒｅｖｉｏｕｓ ＡＲ）からこの登録応答を受けると、パケットのペイロード内に書き込まれた移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報を読み出し、先に自身の端末管理テーブルに書き込んだ移動端末ＭＮＡ のテーブル蘭にあるポインタをセットし、このポインタが示すｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルに前記読み出した移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報を書き込む。次にこの登録応答を移動端末ＭＮＡ に転送する（図２の（３））。
【００４１】
以上により移動端末ＭＮＡ の代理ＨＡ機能および移動端末ＭＮＡ の代理端末機能がアクセスルータＡＲＹ からアクセスルータＡＲＸ に移管されたことになる。
【００４２】
なお、移動端末ＭＮＡ が不正な端末である場合には、アクセスルータＡＲＹ による認証で移動端末ＭＮＡ からの登録要求ははじかれＮＡＣ が返される。アクセスルータＡＲＸ はこのＮＡＣ を受けると先に端末管理テーブルに書き込んだ移動端末ＭＮＡ のＮＡＩ およびＣＯＡ をテーブルから抹消する。
【００４３】
次に、アクセスルータにおける移動端末の代理機能について説明する。
（２）登録要求（代理ＭＮ機能）
移動端末ＭＮＡ の代理端末機能が移管されたＮｅｗ ＡＲであるアクセスルータＡＲＸ は、移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照し、移動端末ＭＮＡ の相手端末（ＣＮ）全てに対し移動端末ＭＮＡ に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する（図２の（４））。図５の（３）にアクセスルータＡＲＸ が相手端末ＣＮＤ に対し送信するｂｉｎｄｉｎｇ ｕｐｄａｔｅのパケットのアドレス例を示す。同図に示すように、パケットの送信元アドレスＳＡとして移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）、送信先アドレスＤＡとして相手端末ＣＮＤ のＣＯＡ（Ｍ：ｄ）を設定し、Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎにアクセスルータＡＲＭ のアドレス（Ｍ：ｍ） および移動端末ＭＮＡ のＮＡＩ を設定する。
【００４４】
アクセスルータＡＲＸ からのｂｉｎｄｉｎｇ ｕｐｄａｔｅを受けた各相手端末の最終ホップのアクセスルータ（ＡＲ）では、該当相手端末に代わり該当相手端末用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを更新する。即ち、ｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル中の前記パケットで通知されたＮＡＩ と同じＮＡＩ に対応するＣＯＡ に前記通知されたＣＯＡ を設定する。図４は移動端末ＭＮＡ の相手端末ＣＮＤ が在圏する代理ＨＡであるアクセスルータＡＲＭ が相手端末ＣＮＤ に代わり移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅを受け、相手端末ＣＮＤ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルにある移動端末ＭＮＡ のＣＯＡ をＹ：ａ （図４の（２））からＸ：ａ （図４の（３））に更新する例を示す。
【００４５】
次に、アクセスルータにおける移動端末の代理ＨＡ機能について説明する。
（３）パケット送信、受信
移動端末ＭＮＡ が相手端末にパケットを送信する場合の実施例を図６に示す。図６では移動端末ＭＮＡ が相手端末ＣＮＥ にパケットを送信する例を示している。移動端末ＭＮＡ はアクセスルータＡＲＸ に対し、ＳＡ＝ｏｈｋｉ＠ｎｅｃ．ｃｏｍ，ＤＡ＝ｊｉｒｏ＠ｂｉｇｌｏｂｅ．ｎｅ．ｊｐ とアドレス指定をしてパケットを送信する（図６の（１））。アクセスルータＡＲＸ は移動端末ＭＮＡ からパケットを受け、相手端末宛にパケットを転送する場合、次の処理を行う。先ず、パケットのＳＡから移動端末ＭＮＡ からのパケットで有ることを認識し、端末管理テーブルから移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）を獲得して、転送パケットのＳＡとしてセットする。次に移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照してＤＡ＝ｊｉｒｏ＠ｂｉｇｌｏｂｅ．ｎｅ．ｊｐ に該当する相手端末ＣＮＥ のＣＯＡ（Ｎ：ｅ）を転送パケットのＤＡにセットし、相手端末ＣＮＥ 宛に転送する。
【００４６】
相手端末ＣＮＥ 宛のパケットは、通常のＩＰルーティングによりＤＡのＣＯＡ におけるｎｅｔｗｏｒｋ ｐｒｅｆｉｘ Ｎを持つサブネットワークＳＮのアクセスルータＡＲＮ（相手端末ＣＮＥ の代理ＣＮ） に配送される。アクセスルータＡＲＮ はＤＡからこのパケットが端末ＣＮＥ 宛のパケットと認識し、端末管理テーブルから端末ＣＮＥ のＮＡＩ にＤＡアドレスを書き換え、端末ＣＮＥ 宛にパケットを転送する。
【００４７】
このように相手端末ＣＮＥ 宛のパケットのＤＡアドレスとして相手端末ＣＮＥ のＣＯＡ を指定できるため、アクセスルータＡＲＸ およびＡＲＮ ではパケットをｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ する必要はない。
【００４８】
（４） ｈａｎｄｏｆｆ
図７に移動端末ＭＮＡ が通信相手ＣＮＤ からパケットを受信中にサブネットワークを跨ぐ場合のハンドオフ制御の例を示す。
【００４９】
移動端末ＭＮＡ は、サブネットワークを跨ぐと、（１）項で述べた手順で移動検知とＣＯＡ 獲得を行い、アクセスルータＡＲＸ 経由でアクセスルータＡＲＹ へ登録要求を行う（図７の（１））。アクセスルータＡＲＸ は前述したように端末管理テーブルに移動端末ＭＮＡ のＮＡＩ とＣＯＡ の対を登録する。
【００５０】
アクセスルータＡＲＹ は移動端末ＭＮＡ がパケット通信中に登録要求を受け、移動端末ＭＮＡ が新たなサブネットワークに移動したことを認識すると、移動端末ＭＮＡ に対するアンカーとなり移動端末ＭＮＡ にパケットを転送し始める。この場合は、通信相手ＣＮＤ からのパケット送信が終わるか或いはタイマによる一定時間が経過するまでは、移動端末ＭＮＡ の代理ＨＡ機能はアクセスルータＡＲＸ に移行せず、アクセスルータＡＲＹ がアンカーとなり最後までパケットを転送し続ける。具体的には以下のような制御が行われる。
【００５１】
アクセスルータＡＲＹ は移動端末ＭＮＡ から登録要求を受けると、（１）項で述べた認証を行い成功すれば、相手端末ＣＮＤ へ移動端末ＭＮＡ に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する（ 図７の（２））。また端末管理テーブル中の移動端末ＭＮＡ のＣＯＡ を新ＣＯＡ に書き換え、相手端末ＣＮＤ から移動端末ＭＮＡ 宛のパケットは新ＣＯＡ のＮｅｔｗｏｒｋ ｐｒｅｆｉｘ Ｘに従ってアクセスルータＡＲＸ に転送することを決定する。アクセスルータＡＲＭ はアクセスルータＡＲＹ から移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅを受信すると、端末ＣＮＤ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル中の移動端末ＭＮＡ のＣＯＡ を書き換え、端末ＣＮＤ から移動端末ＭＮＡ 宛のパケットはアクセスルータＡＲＹ に転送すると共に、移動端末ＭＮＡ の新たなＣＯＡ へもパケットを送信し始める（図７の（３））。アクセスルータＡＲＹ では受信したパケットのＤＡ中のＮｅｔｗｏｒｋ ｐｒｅｆｉｘをＹ からＸ に書き換え、アクセスルータＡＲＸ に転送し、アクセスルータＡＲＸ は移動端末ＭＮＡ に転送する。この結果、移動端末ＭＮＡ 宛のパケットはいわゆるｂｉｃａｓｔｉｎｇ されることになりｈａｎｄｏｆｆ に伴うパケットロスを極力少なくすることが可能である。
【００５２】
通信相手ＣＮＤ から移動端末ＭＮＡ へのパケット送信が終了すると、（１）項で述べた手順により移動端末ＭＮＡ の代理ＨＡ機能および代理端末機能がアクセスルータＡＲＹ からアクセスルータＡＲＸ へ移行する。
【００５３】
（５）端末認証（セキュリティ）
本発明では従来と同様に、Ｍｏｂｉｌｅ ＩＰ とＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｃｃｏｕｎｔｉｎｇ）サーバとの連携が可能である。図８に端末認証に対する実施例を示す。図８に示すモデルで、代理ＨＡであるアクセスルータＡＲＸ は移動端末ＭＮＡ からの登録要求を受けると、ＡＡＡ サーバと連携で端末の認証を行うことができる。ここで、図８のＫＤＣ（Ｋｅｙ ｄｉｓｔｒｉｂｕｔｉｏｎ ｃｅｎｔｅｒ）は、ＡＡＡ サーバおよび移動端末ＭＮＡ に認証鍵を配送する機能をもつ。
【００５４】
【発明の効果】
以上説明したように本発明によれば以下の効果が奏される。
【００５５】
移動端末は自分の端末アドレスのＣＯＡ のみ獲得できれば、後は代理ＨＡが自分用のｂｉｎｄｉｎｇ ｕｐｄａｔｅを維持、更新してくれる。このため、待ちうけ時にｂｉｎｄｉｎｇ ｕｐｄａｔｅ更新の必要がなく従来技術のｂｉｎｄｉｎｇ ｕｐｄａｔｅ維持、更新のためのバッテリ消費問題が解決できる。
【００５６】
移動端末間のｂｉｎｄｉｎｇ ｕｐｄａｔｅはアクセスルータ同士で行われるため、ｂｉｎｄｉｎｇ ｕｐｄａｔｅは無線区間に流れることはない。
【００５７】
通信相手がアクセスルータのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルに存在する限りトンネリングの必要がなく、アクセスルータでのｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ 処理によるスケーラビリティ問題を回避できる。
【図面の簡単な説明】
【図１】本発明の実施例のシステム構成図である。
【図２】本発明における移動端末の登録要求およびｂｉｎｄｉｎｇ ｕｐｄａｔｅ送信のシーケンス例を示す図である。
【図３】代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータにおける端末管理テーブルおよびｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す図である。
【図４】代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータにおける端末管理テーブルおよびｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す図である。
【図５】移動端末から代理ＨＡ向けに出される登録要求パケットのフォーマット構成例を示す図である。
【図６】移動端末から通信相手宛のパケット送信のシーケンス例を示す図である。
【図７】本発明の実施例におけるＨａｎｄ ｏｆｆシーケンス例を示す図である。
【図８】本発明の実施例におけるＡＡＡ サーバとの連携例を示す図である。
【図９】従来技術の一例を示す図である。
【図１０】従来技術の他の例を示す図である。
【符号の説明】
ＭＮ： 移動端末（Ｍｏｂｉｌｅ Ｎｏｄｅ）
ＡＲ： アクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）
ＣＮ： 通信相手（Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ Ｎｏｄｅ）
【発明の属する技術分野】
本発明は、複数の相互に接続されたサブネットワークを備え、任意のサブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における移動端末管理システムに関する。
【０００２】
【従来の技術】
インタネットの爆発的な進展に伴い、従来音声サービスが中心であった移動網においてもデータサービスが急激に立ち上がり始めており、早晩データトラフィックが音声トラフィックを上回ることが予想されている。これに伴い移動網も音声中心のネットワークからモバイルインタネットに適したネットワークへと進化すべく３ＧＰＰやＧＰＰ２でＡＬＬ ＩＰの検討が進められている。またＩＥＴＦでもこれに呼応する形で、従来ＬＡＮ ユースのＩＰモビリティを議論していたＭＯＢＩＬＥ ＩＰ ＷＧが第三世代移動通信システムをスコープにいれ標準化を検討するようになってきた。本ＷＧでは、特に今後アドレス枯渇が懸念されているＩＰＶ４にかわるＩＰＶ６のＩＰモビリティ（Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６ ＜ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｉｐｖ６−１２．ｔｘｔ ＞）の検討が活発化してきている。従来のＭｏｂｉｌｅ ＩＰＶ６ では、ＭＮ（Ｍｏｂｉｌｅ Ｎｏｄｅ） が新たにサブネットワークへ移動した場合、ＭＮはＨＡ（Ｈｏｍｅ Ａｇｅｎｔ）に対し登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ：以下ＢＵとも記す）を行う。ＭＮは相手端末（ＣＮ）からのパケットがＨＡ経由でＭｏｂｉｌｅ ＩＰＶ４ と同様トンネリングで送信された場合には、該ＣＮがＭＮのＣＯＡ（Ｃａｒｅ ｏｆ ａｄｄｒｅｓｓ）を知らないと判断し、ＣＮに対し自分のＨｏｍｅ ａｄｄｒｅｓｓとＣＯＡ のペア情報であるｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を送付する。これ以降、ＣＮはＭＮへパケット送信する場合、パケットをＭＮ宛に直接送信できるようになる。これにより、Ｍｏｂｉｌｅ ＩＰＶ６ では、Ｍｏｂｉｌｅ ＩＰＶ４ の欠点であったトライアングルルーチングを解決するｒｏｕｔｅ ｏｐｔｉｍａｚａｔｉｏｎ機能がサポートできるようになった。
【０００３】
更にハンドオフ時のパケットロスを極力回避するためＳＭＯＯＴＨ ＨＡＮＤＯＦＦ機能がサポートされる。Ｍｏｂｉｌｅ ＩＰＶ６ は、かかるＭｏｂｉｌｅ ＩＰＶ４ からの改善策を持つ一方、ネットワークモデルは、Ｍｏｂｉｌｅ ＩＰＶ４ と同じくＨＡとＭＮとのフラットなモデルとしている。このため、ＭＮがＨＡと物理的に遠く離れたネットワークへローミングした場合等には、ＲＥＧＩＳＴＲＡＴＩＯＮ要求がＭＮとＨＡ間のＲＯＵＮＤ ＴＲＩＰ ＤＥＬＡＹだけ遅延する欠点を有したままとなっている。これを解決する目的でＨｉｅｒａｒｃｈｉｃａｌ ＭＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ＜ｄｒａｆｔ−ｉｅｔｆ−ｍｏｂｉｌｅｉｐ−ｈｍｉｐｖ６−０１．ｔｘｔ ＞というＩｎｔｅｒｎｅｔ Ｄｒａｆｔ（ 以下Ｉ−Ｄ と記す） が提案されている。図９に示すように本Ｉ−Ｄ ではネットワークモデルとして、ＭＮ−ＡＲ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）−ＭＡＰ（Ｍｏｂｉｌｉｔｙ Ａｎｃｈｏｒ Ｐｏｉｎｔ）−ＨＡからなる階層化構成を採用している。そしてＭｏｂｉｌｉｔｙ Ａｎｃｈｏｒ Ｐｏｉｎｔ（ＭＡＰ）がＨＡの代理機能をサポートすることにより、上記ＭＮの登録要求の遅延を削減することを可能にしている。
【０００４】
またこれとは別に、図１０に示すようなＨＡおよびＨｏｍｅ ａｄｄｒｅｓｓを不要にした新たなＩ−Ｄ（Ｈｏｍｅｌｅｓｓ Ｍｏｂｉｌｅ ＩＰｖ６＜ｄｒａｆｔ−ｎｉｋａｎｄｅｒ−ｍｏｂｉｌｅｉｐ−ｈｏｍｅｌｅｓｓｖ６−００．ｔｘｔ ＞） が２０００．１２．１１〜１２．１５ の期間開催されたＩＥＴＦ ＷＧ で提案されている。もともとＭｏｂｉｌｅ ＩＰＶ６ では、ＭＮとＣＮ間でやりとりされるｂｉｎｄｉｎｇ ｕｐｄａｔｅが、ＭＮとＣＮ間とで移動管理情報を共有し合うために用いられる。本Ｉ−Ｄ ではこのｂｉｎｄｉｎｇ ｕｐｄａｔｅを継承しＭＮでＨｏｓｔ Ｃａｃｈｅなる情報を保持することによりＨＡなしでも移動管理が実現できるとしている。本Ｉ−Ｄ のメリットとしてＨｏｍｅｌｅｓｓ ｓｕｐｐｏｒｔｉｎｇ Ｈｏｓｔ間同士のパケット送信では、Ｍｏｂｉｌｅ ＩＰＶ６ で用いるＲｏｕｔｉｎｇ ｈｅａｄｅｒおよびＨｏｍｅ ａｄｄｒｅｓｓ ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ が不要になりＩＰＶ６ヘッダのみでパケットを送受できることを挙げている。これにより９２バイトから４０バイトのパケット長の削減が図れるとしている。
【０００５】
【発明が解決しようとする課題】
以上のようにＭｏｂｉｌｅ ＩＰ ＷＧでは、Ｍｏｂｉｌｅ ＩＰＶ６ の改善提案が活発に行われている。しかし、現状提案されているＩ−Ｄ ではまだ以下のような課題が存在する。
【０００６】
まず、Ｈｉｅｒａｒｃｈｉｃａｌ ＭＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔでは以下のように欠点が指摘できる。本Ｉ−Ｄ の５．１ ＭＮ Ｏｐｅｒａｔｉｏｎｓ につぎのような記述がある。
Ｉｔ ｃａｎ ａｌｓｏ ｓｅｎｄ ａ ｓｉｍｉｌａｒ ＢＵ （ｉ．ｅ． ｔｈａｔ ｓｐｅｃｉｆｉｅｓ ｔｈｅ ｂｉｎｄｉｎｇ ｂｅｔｗｅｅｎ ｔｈｅ Ｈｏｍｅ Ａｄｄｒｅｓｓ ａｎｄ ｔｈｅ ＲＣｏＡ） ｔｏ ｉｔｓ ｃｕｒｒｅｎｔ ＣＮｓ．すなわち、Ｍｏｂｉｌｅ ＩＰＶ６ 同様ＭＮとＣＮ（相手が移動端末の場合はＭＮ）同士は互いにｂｉｎｄｉｎｇ ｕｐｄａｔｅをやりとりし、ｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を更新し合わないといけない。ここでｂｉｎｄｉｎｇ ｕｐｄａｔｅはエリアを跨いだ時に加え、リフレッシュのため定期的に更新する必要があるためｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りする相手端末が多い場合、ＭＮは頻繁にｂｉｎｄｉｎｇ ｕｐｄａｔｅを送受信することになる。このため、端末は待ちうけ時でもｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信するため送信モードとなる必要があり端末のバッテリ消費を早めることになる。このｂｉｎｄｉｎｇ ｕｐｄａｔｅ保持には端末のリソース（メモリ、ＣＰＵ 負荷）が必要であり、バッテリ消費に加え端末の小型化にも影響を与えることになる。
【０００７】
またｂｉｎｄｉｎｇ ｕｐｄａｔｅを移動端末間でやり取りするため、大規模移動網ではｂｉｎｄｉｎｇ ｕｐｄａｔｅトラフィックが大量に無線区間を飛び交うことになり、これによる無線リソースの消費が無視できなくなる。
【０００８】
更に以下の記述もある。
Ｔｈｅ ＭＡＰ ｗｉｌｌ ｒｅｃｅｉｖｅ ｐａｃｋｅｔｓ ａｄｄｒｅｓｓｅｄ ｔｏ ｔｈｅ ＭＮ’ｓ ＲＣＯＡ （ｆｒｏｍ ｔｈｅ ＨＡ ｏｒ ＣＮｓ）． Ｐａｃｋｅｔｓ ｗｉｌｌ ｂｅ ｔｕｎｎｅｌｌｅｄ ｆｒｏｍ ｔｈｅ ＭＡＰ ｔｏ ｔｈｅ ＭＮ’ｓ ＬＣＯＡ． Ｔｈｅ ＭＮ ｗｉｌｌ ｄｅｃａｐｓｕｌａｔｅ ｔｈｅ ｐａｃｋｅｔｓ ａｎｄ ｐｒｏｃｅｓｓ ｔｈｅ ｐａｃｋｅｔ ｉｎ ｔｈｅ ｎｏｒｍａｌ ｍａｎｎｅｒ． Ｍｏｂｉｌｅ ＩＰＶ４ では、ＣＮからＭＮ宛のパケットはＨＡでインタセプトされた後、ＭＮが在圏するＦＡ（Ｆｏｒｅｉｇｎ Ａｇｅｎｔ） 宛にｅｎｃａｐｓｕｌａｔｉｏｎ してトンネリングされる。これを受けたＦＡではこのパケットをｄｅｃａｐｓｕｌａｔｉｏｎ しＭＮ宛てに転送する。このようにＭｏｂｉｌｅ ＩＰＶ４ では、ＨＡでのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理が大規模移動網にスケールさせるためにボトルネックとなる可能性がある。同様に本ｍｏｂｉｌｅ ＩＰＶ６ 改善Ｉ−Ｄ においてもＣＮからＭＮ宛てのパケットは、ＭＡＰ でｅｎｃａｐｓｕｌａｔｉｏｎされるため大規模移動網ではこの処理量が問題となると考えられる。
【０００９】
また、Ｍｏｂｉｌｅ ＩＰＶ６ ではＭＮがＣＮにｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する機能は必須機能でなく、ＩＥＴＦ用語でＭＡＹ となっており必ずしも全ての端末がｂｉｎｄｉｎｇ ｕｐｄａｔｅ機能をサポートするとは言いきれない。とするとＩＰＶ６に進化した移動網において、なおＭｏｂｉｌｅ ＩＰＶ４ と同様Ｔｒｉａｎｇｌｅ ｒｏｕｔｉｎｇとＨＡでのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理がそのまま残る可能性が懸念される。
【００１０】
一方、Ｈｏｍｅｌｅｓｓ Ｍｏｂｉｌｅ ＩＰｖ６では次のような欠点を指摘できる。本Ｉ−Ｄ でも上記Ｉ−Ｄ と同じようにＭＮとＣＮとがｂｉｎｄｉｎｇ ｕｐｄａｔｅを用いてＨｏｓｔ ｃａｃｈｅを更新するためＭＮのバッテリ消費および大規模移動網でのｂｉｎｄｉｎｇ ｕｐｄａｔｅトラフィックによる無線リソースの消費問題を有する。また、相手端末が同じＨＯＭＥＬＥＳＳの場合、例えば両者が同時に新たなドメインを跨ぎ無線リンクを失うタイミングが発生すると考えられる。この場合、最悪、両者がお互いの位置情報（新規アドレス情報）を同時に失ってしまうことになる。そうすると、このアーキテクチャでは、お互いのアドレスが変化したことを相手に通知する手段がないと考えられる。但し、この問題は相手が固定端末では発生しないと考えられる。また、移動端末がもともと認識していない端末から初めて受信する場合、相手端末はこの移動端末のアドレスを知る手段がないと考えられる。いずれの場合でもＨＡの機能サポートが必要と考えられる。
【００１１】
以上の課題をまとめると以下のようになる。
（１） ＭＮが相手端末とｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りすることによるＭＮのバッテリ消費問題
（２） ＭＮが相手端末とｂｉｎｄｉｎｇ ｕｐｄａｔｅをやり取りすることによる無線リソース消費問題
（３） ＨＡ（ＭＡＰ） のＭＮ宛てのパケットｅｎｃａｐｓｕｌａｔｉｏｎ 処理による大規模移動網へのスケーラビリティ問題
【００１２】
【発明の目的】
本発明では、かかる従来技術の３つの課題を解決するシステムを提供することを目的としている。
【００１３】
【課題を解決するための手段】
本発明は複数の相互に接続されたサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における移動端末管理システムにおいて、前記サブネットワークは、アクセスルータを備え、前記アクセスルータは、在圏する前記移動端末のCOAを保持管理する端末管理テーブルと、在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新テーブルと、前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求を受け付けるホームエージェント代行手段とを有する。また、前記ホームエージェント代行手段が、在圏する前記移動端末から通信相手宛に送信されるパケットを受信してその宛先アドレスを当該通信相手のCOA に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットを受信して前記移動端末に転送する手段を有する。ここで、前記端末管理テーブルは在圏する前記移動端末のNAI 又はURI とCOA の組を保持する構成を有し、前記バインディング更新テーブルは各通信相手のNAI 又はURI とCOA の組を保持する構成を有し、前記移動端末から通信相手宛に送信されるパケットはその宛先アドレスに当該通信相手のNAI 又はURI が設定される。また、前記複数のサブネットワークはそれぞれ異なるネットワークプレフィックスを持ち、前記移動端末のCOA は在圏する前記サブネットワークのネットワークプレフィックスと当該移動端末のインタフェースIDとから構成される。
【００１４】
このようなホームエージェント代行手段を各アクセスルータが備えることにより、移動端末から通信相手へのパケット送信時、パケットをｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ する必要がなくなる。
【００１５】
また前記ホームエージェント代行手段は、在圏する前記移動端末から通信相手宛に送信されるパケットの宛先アドレスを前記ＮＡＩ 又はＵＲＩ から前記ＣＯＡ に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットの宛先アドレスを前記ＣＯＡ から前記ＮＡＩ 又はＵＲＩ に書き換えて前記移動端末に転送する構成を有する。これにより、端末ユーザはパケット送信時にメールアドレスと同じ形式のアドレス（ＮＡＩ） やＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のアドレス（ＵＲＩ） を使用することができる。
【００１６】
また前記アクセスルータは、前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を受け付ける手段を備え、且つ、移動前のサブネットワークの前記アクセスルータと移動後のサブネットワークの前記アクセスルータとの間で、当該移動端末用の前記バインディング更新テーブルの受け渡し及び当該移動端末にかかるホームエージェント代行機能の移管を行う手段を備える。これにより、移動端末の移動の際にアクセスルータがホームエージェントの代わりに移動端末からの登録要求を受け付け、且つ自動的にホームエージェント代行機能を移動先のサブネットワークのアクセスルータに移管することができる。
【００１７】
また本発明における前記アクセスルータは、自サブネットワークに移動してきた前記移動端末の前記バインディング更新テーブルを受け取ったときに当該バインディング更新テーブルに記載されている全ての通信相手に対して前記移動してきた移動端末の新たなＣＯＡ を通知するバインディング更新パケットを送信すると共に、在圏する移動端末宛の前記バインディング更新パケットを他のアクセスルータから受信したときに該当する前記バインディング更新テーブルを更新する移動端末代行手段を備える。
【００１８】
このような移動端末代行手段を各アクセスルータが備えることにより、移動端末自身が通信相手にバインディング更新パケットを送信する必要がなくなる。
【００１９】
【発明の実施の形態】
［構成］
本発明の実施の形態にかかる移動網における移動端末管理システムは、次に示す手段を有する。
○アクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ、ＡＲ）
移動端末ＭＮから１ホップの関係にあるＩＰＶ６ルータがアクセスルータとなり、ＨＡの代理機能かつ移動端末ＭＮ（通信相手ＣＮ） の代理機能を持つ。すなわち、ＨＡに代わり移動端末ＭＮからの登録要求を受け付ける手段と、移動端末ＭＮ（通信相手ＣＮ）に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を保持、更新する手段を有する。かつ、移動端末ＭＮからＡＲ（Ｐｒｅｖｉｏｕｓ ＡＲと記す） に対する登録要求（ＢＵ）が移動端末ＭＮの移動先ＡＲ（Ｎｅｗ ＡＲ と記す） 経由であった場合、該Ｐｒｅｖｉｏｕｓ ＡＲ が、該移動端末ＭＮに対する登録応答に該移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報を付加しＮｅｗ ＡＲへ転送する手段、および該ｂｉｎｄｉｎｇ ｕｐｄａｔｅ情報が付加された登録応答受信をトリガにしてＮｅｗ ＡＲが、該ＭＮの代理ＨＡおよび代理ＭＮ機能を該Ｐｒｅｖｉｏｕｓ ＡＲ から受け継ぐ手段を持つ。ここで、ＨＡの代理機能をサポートする具体的手段として端末管理テーブルを、移動端末ＭＮ（ＣＮ）の代理機能をサポートする具体的手段としてｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを有する。
○移動端末ＭＮ
従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様ＣＯＡ 獲得の手段および登録要求を代理ＨＡへ行う手段を持つ。
【００２０】
［動作］
本発明の実施の形態のかかる移動網における移動端末管理システムでは、次のような動作が行われる。
（１）登録要求（代理ＨＡ機能）
移動端末ＭＮが新たなサブネットワークへ移動した場合、従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様ルータ広告から別のサブネットワークに移動したことを認識し、登録要求を移動前の代理ＨＡ（Ｐｒｅｖｉｏｕｓ ＡＲ） に対し行う。この登録要求は移動端末ＭＮから１ホップの位置にある移動先のＮｅｗ ＡＲ経由でＰｒｅｖｉｏｕｓ ＡＲ へ転送される。Ｐｒｅｖｉｏｕｓ ＡＲ は、この登録要求を受けると端末管理テーブルから該移動端末ＭＮが移動直前まで自分のエリアにいたことを確認するとともに、該移動端末ＭＮとのｓａ（ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ）に従い該移動端末ＭＮが不正な端末でないかどうか確認する。不正な端末でないことを認証できた場合にはＨＡに代わり登録応答をＮｅｗ ＡＲに返す。
【００２１】
この登録応答はＰｒｅｖｉｏｕｓ ＡＲ からＮｅｗ ＡＲに該移動端末ＭＮの代理ＨＡ機能が移行したことを通知するトリガとなる。この登録応答にはｐｒｅｖｉｏｕｓ ＡＲ が保持していた該移動端末ＭＮ用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルが含まれる。
【００２２】
Ｎｅｗ ＡＲはＰｒｅｖｉｏｕｓ ＡＲ からこの登録応答を受けると、該移動端末ＭＮに対し登録応答を返す。
【００２３】
（２）登録要求（代理ＭＮ機能）
次にＮｅｗ ＡＲは、該当移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照し、該当移動端末ＭＮの相手端末（ＣＮ）に対し該当移動端末ＭＮに代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する。このｂｉｎｄｉｎｇ ｕｐｄａｔｅを受けた相手端末ＣＮの最終ホップのルータ（ＡＲ）は、該当相手端末ＣＮに変わり該当相手端末ＣＮ用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを更新する。
【００２４】
（３）パケット送受信
移動端末ＭＮは、相手端末ＣＮ宛にパケット送信する場合、ＳＡ（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）＝ＣＯＡ 、ＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ） ＝ＣＮのＮＡＩ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）又はＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ） としパケットを送信することができる。該移動端末ＭＮの代理ＨＡ（アクセスルータＡＲ）は、該移動端末ＭＮのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルから相手端末ＣＮの最新アドレスを知りＤＡ＝相手端末のＣＯＡ にセットしてパケットを転送する。パケットは該相手端末ＣＮの代理ＨＡ（アクセスルータＡＲ）経由で配送される。
【００２５】
【実施例】
［１］構成の説明
図１は本発明の実施例のシステム構成図を示す。図１に示すように本実施例のシステムは移動端末ＭＮ、アクセスルータＡＲ（ＡＲ１〜ＡＲｎ）、および通信相手ＣＮならびにアクセスルータＡＲ間を相互に接続するインターネット等のＩＰコアネットワークからなる。アクセスルータＡＲは移動端末ＭＮから１ホップの関係にあるＩＰ（アクセス）ルータであり、ＨＡの端末移動管理代理機能およびＭＮ（ＣＮ）の移動管理代理機能を持つ。図１の構成を３Ｇ移動網に対応させるとアクセスルータＡＲと移動端末ＭＮの関係は、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と移動端末、ｃｄｍａ２０００の場合のＰＤＳＮと移動端末の関係に該当する。またＭＷＩＦで検討が始まっているＯＰＥＮ ＬＡＮのアーキテクチャでは、ＲＮＣ もしくはＮｏｄｅ Ｂが将来ＩＰルータの機能を持つようになると考えられる。このアーキテクチャに当てはめると、アクセスルータＡＲと移動端末ＭＮの関係はＲＮＣ もしくはＮｏｄｅ Ｂと移動端末の関係に該当する。
【００２６】
図２は本実施例における移動端末ＭＮの登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）のシーケンス例を示す。図２に示すように移動網は各々異なるＮｅｔｗｏｒｋ ｐｒｅｆｉｘを持つサブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ で構成され、各サブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ には一つのアクセスルータを持つ。また移動端末は、アクセスルータを介して移動網にアクセスしネットワークサービスを受けたり他の端末と通信を行う。図２では４つのサブネットワークＳＭ，ＳＮ，ＳＸ，ＳＹ の例を示しており、各サブネットワークはＭ，Ｎ，Ｘ，Ｙ と記載したｎｅｔｗｏｒｋ ｐｒｅｆｉｘを持つものとする。また各サブネットワークはＡＲＭ，ＡＲＮ，ＡＲＸ，ＡＲＹ と記載したアクセスルータを持ち、ＣＮＤ，ＣＮＥ，ＭＮＡ，ＭＮＢ，ＭＮＣ と記載した移動端末が各サブネットワーク内に在圏している場合を示している。図２の登録要求シーケンス例は移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ移動した場合について示すものである。
【００２７】
図３は、代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータＡＲにおける端末の移動管理機能の構成例を示す。図３の（１）および（３）がアクセスルータＡＲの代理ＨＡ機能である端末の端末管理テーブルを示す。図３の（２）が、アクセスルータＡＲの端末の代理機能となるｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを示す。ここで図３の（１）は、移動端末ＭＮＡ が移動直前に在圏していたサブネットワークＳＹのアクセスルータＡＲＹ の端末管理テーブルを、図３の（２）が、移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを、図３の（３）が移動端末ＭＮＡ がサブネットワークＳＸへ移動後のアクセスルータＡＲＹ の端末管理テーブルを示している。図３の（１）および（２）に示すように、各移動端末のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルは端末管理テーブルの該当端末欄にあるポインタで関係付けられる。ここで、移動端末がサブネットワークを移動すると代理ＨＡの機能も移動先のアクセスルータＡＲ（Ｎｅｗ ＡＲ）に移動する。この場合、Ｐｒｅｖｉｏｕｓ ＡＲ からＮｅｗ ＡＲへ該当端末のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルが引き継がれる。
【００２８】
図４は図２に示すアクセスルータＡＲＮ の端末管理テーブル（図４の（１））および移動端末ＣＮＥ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す。ここで、図４の（２）および（３）は、移動端末ＣＮＥ の通信相手である移動端末ＭＮＡ がサブネットワーク移動前および移動後に対応したｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す。
【００２９】
ここで、移動端末ＭＮＡ やＣＮＥ 等のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルには、その端末のユーザが通信を行う相手毎のＮＡＩ またはＵＲＩ とＣＯＡ の組が登録される。このようなｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの初期生成方法としては、各端末ユーザが全ての通信相手のＮＡＩ またはＵＲＩ とＣＯＡ の組のリストを作成して、在圏するアクセスルータにｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの登録を依頼する方法がある。また、リスト中のＣＯＡ の部分は空白にして、通信相手のＮＡＩ またはＵＲＩ のリストだけをアクセスルータに通知することも可能である。この場合、アクセスルータに初期生成されるｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルもＣＯＡ の部分は空白となるが、通信相手が移動登録を行うと後述するようにして最新のＣＯＡ が順次に書き込まれていき、全通信相手が一度でも移動登録を行うとｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの内容が完成することになる。
【００３０】
図５の（１）は移動端末ＭＮＡ が新たなサブネットワークへ移動した場合に、今まで在圏していた代理ＨＡであるアクセスルータＡＲＹ に送信する登録要求（ＢＵ）のパケットフォーマット例、図５の（２）は移動端末ＭＮＡ からの登録要求に対する登録応答のパケットフォーマット例、図５の（３）は、移動端末ＭＮＡ の新たな代理ＨＡであるアクセスルータＡＲＸ が移動端末ＭＮＡ に代わり通信相手に送信する登録要求ＢＵのパケットフォーマット例を示す。
【００３１】
図６は、移動端末から通信相手宛てのパケット送信のシーケンス例を示す。図６では、移動端末ＭＮＡ から通信相手ＣＮＥ へパケットを送信する場合を示す。
【００３２】
図７はＨａｎｄ ｏｆｆシーケンス例を示す。図７では移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ通信中に移動した場合のｈａｎｄ ｏｆｆシーケンス例を示す。
【００３３】
図８は、ＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｃｃｏｕｎｔｉｎｇ）サーバとの連携例を示す。
【００３４】
［２］動作の説明
次に本実施例の動作を図を用いて説明する。
（１） 登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）：代理ＨＡ機能
図２に本実施例の登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）のシーケンス例を示す。図２の登録要求シーケンス例は移動端末ＭＮＡ がサブネットワークＳＹからサブネットワークＳＸへ移動した場合について示すものである。移動端末ＭＮＡ がサブネットワークＳＹから新たサブネットワークＳＸへ移動した場合、従来のＭｏｂｉｌｅ ＩＰＶ６ の移動端末と同様、移動先のルータ広告から別のサブネットワークに移動したことを認識する。図２ではＩＰＶ６ルータであるアクセスルータＡＲＸ がこのルータ広告を出す。移動端末ＭＮＡ は移動したことを認識すると、従来の移動端末と同様にＣＯＡ を獲得する。ＣＯＡ の獲得方法はＤＨＣＰＶ６によるＳｔａｔｅｆｕｌｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ もしくはｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ（ＲＦＣ１９７１）いずれでもよい。図２では移動端末ＭＮＡ が新たに獲得したＣＯＡ の例としてＸ：ａ と記している。ここでＸ：ａ は、１２８ ビット長のＩＰＶ６のアドレスを示しており、 ＸはサブネットワークＳＸのｎｅｔｗｏｒｋ ｐｒｅｆｉｘ、ａ は移動端末ＭＮＡ のインタフェースＩＤを示す。
【００３５】
次に移動端末ＭＮＡ は、登録要求（ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）を移動前の代理ＨＡ（Ｐｒｅｖｉｏｕｓ ＡＲ） であるアクセスルータＡＲＹ に対し行う。移動端末ＭＮＡ は、図５の（１）に示すように登録要求の送信元アドレス（ＩＰＶ６ヘッダ内の送信元アドレスＳＡ）として移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）を、あて先アドレス（ＩＰＶ６ ヘッダ内のあて先アドレスＤＡ） にアクセスルータＡＲＹ のアドレス（Ｙ：ｙ） をセットする。またＭｏｂｉｌｅ ＩＰＶ６ の Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ（もしくはＩＰＶ６のＲｏｕｔｉｎｇ ｅｘｔｅｎｔｉｏｎ ｈｅａｄｅｒ）を用い、登録要求の経路指定を行う。ここでは途中の経路ノードとしてアクセスルータＡＲＸ を指定するため、アクセスルータＡＲＸ のアドレス（Ｘ：ｘ） をセットする。この指定により移動端末ＭＮＡ の登録要求は、移動端末ＭＮＡから１ホップの位置にある移動先のアクセスルータＡＲＸ 経由で移動前のアクセスルータＡＲＹ へ転送される（図２の（１））。また、端末ユーザがパケット送信時にメールアドレスと同じ形式のアドレスもしくはＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）端末のユーザがＳＩＰ のアドレス（ＵＲＩ） を使用できるよう移動端末ＭＮＡ のＮＡＩ（ＲＦＣ；Ｎｅｔｗｏｒｋ ａｃｃｅｓｓ ｉｄｅｎｔｉｆｉｅｒ）もしくはＳＩＰ ＵＲＩ をＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ にセットしてもよい。ここでは移動端末ＭＮＡ のＮＡＩ としてｏｈｋｉ＠ｎｅｃ．ｃｏｍを例に挙げている。
【００３６】
アクセスルータＡＲＸ はこの登録要求を受けると、途中の経路アドレスが自分のアドレスであることから端末管理テーブルに移動端末ＭＮＡ のＮＡＩ とＣＯＡ を追加するとともに登録要求パケットをアクセスルータＡＲＹ 宛に転送する。
【００３７】
アクセスルータＡＲＹ は、この登録要求を受信すると登録要求の送信元アドレス（ＳＡ）から登録要求を行った端末の新たなＣＯＡ を、またＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ からＮＡＩ（あるいはＳＩＰ ＵＲＩ）を知る。アクセスルータＡＲＹ は、このＮＡＩ および ＣＯＡをもとに代理ＨＡの手段を実現している端末管理テーブルをサーチする。ここで、図３の（１）にアクセスルータＡＲＹ の端末管理テーブルの構成例を示す。同図に示すようにこの端末管理テーブルは、管理する各端末のＮＡＩ （あるいはＳＩＰ ＵＲＩ ）、ＣＯＡ およびｓａ （ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ； アクセスルータＡＲＹ と各端末間の認証アルゴリズムおよび認証鍵） がセットになっている。ここで図３（１）は、移動端末ＭＮＡ がサブネットワークＳＸへ移動する前の状態を示しており、移動端末ＭＮＡ のＮＡＩ であるｏｈｋｉ＠ｎｅｃ．ｃｏｍに該当するＣＯＡ は移動前のＣＯＡ ＝Ｙ：ａ となっている。アクセスＡＲＹ はこの端末管理テーブルをサーチした結果、移動端末ＭＮＡ のＣＯＡ がＹ：ａ であることから移動直前まで自分のサブネットワークＳＹに在圏していたことを確認するとともに、該移動端末ＭＮＡ とのｓａ （ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ） に従い該移動端末ＭＮＡ が不正な端末でないかどうか確認する。ここで、移動端末ＭＮＡ の登録要求には、Ｒｅｐｌａｙ ａｔｔａｃｋ 対策として例えば今までの代理ＨＡ（ＡＲＹ） からのルータ広告で得たＣｈａｌｌｅｎｇｅ 値に対するＲｅｓｐｏｎｓｅ値が挿入されており、アクセスルータＡＲＹ で移動端末ＭＮＡ が不正な端末かどうか認証できるようになっている。移動端末ＭＮＡ が不正な端末でないことを認証できた場合には移動端末ＭＮＡ のＣＯＡ を新たなＸ：ａ に書き換えるとともに、ＨＡに代わり登録応答をアクセスルータＡＲＸ 経由で移動端末ＭＮＡ に返す（図２の（２），（３））。図３の（３）の端末管理テーブルは、アクセスルータＡＲＹ が移動端末ＭＮＡ のＣＯＡ を新たなＸ：ａ に書き換えた後の状態を示す。
【００３８】
次にアクセスルータＡＲＹ は移動端末ＭＮＡ に対し登録応答を返す。図５の（２）に示すように、登録応答パケットの送信元アドレス（ＳＡ）としてアクセスルータＡＲＹ のアドレス（Ｙ：ｙ） を、送信先アドレス（ＤＡ）として移動端末ＭＮＡ のＣＯＡ （Ｘ：ａ）をセットする。また、Ｍｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ に途中経由するルータのアドレスとして移動端末ＭＮＡ の新たな代理ＨＡであるアクセスルータＡＲＸ のアドレス（Ｘ：ｘ） をセットする。これに加えアクセスルータＡＲＹ は、自身が保持していた移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報をパケットのｐａｙｌｏａｄ に書き込み送信する。
【００３９】
この登録応答パケットをアクセスルータＡＲＸ が受信すると、パケットの識別子から登録応答であること、最終あて先がアクセスルータＡＲＸ のルータ広告に反応し登録要求を出した移動端末ＭＮＡ であること、且つＭｏｂｉｌｅ ＩＰＶ６ Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎ ｈｅａｄｅｒ 内のアドレスが自分のアドレスであることを認識する。これによりアクセスルータＡＲＸ は、アクセスルータＡＲＹ から移動端末ＭＮＡ の代理ＨＡ機能が移行したことを認識する。
【００４０】
アクセスルータＡＲＸ（Ｎｅｗ ＡＲ） はアクセスルータＡＲＹ（Ｐｒｅｖｉｏｕｓ ＡＲ）からこの登録応答を受けると、パケットのペイロード内に書き込まれた移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報を読み出し、先に自身の端末管理テーブルに書き込んだ移動端末ＭＮＡ のテーブル蘭にあるポインタをセットし、このポインタが示すｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルに前記読み出した移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル情報を書き込む。次にこの登録応答を移動端末ＭＮＡ に転送する（図２の（３））。
【００４１】
以上により移動端末ＭＮＡ の代理ＨＡ機能および移動端末ＭＮＡ の代理端末機能がアクセスルータＡＲＹ からアクセスルータＡＲＸ に移管されたことになる。
【００４２】
なお、移動端末ＭＮＡ が不正な端末である場合には、アクセスルータＡＲＹ による認証で移動端末ＭＮＡ からの登録要求ははじかれＮＡＣ が返される。アクセスルータＡＲＸ はこのＮＡＣ を受けると先に端末管理テーブルに書き込んだ移動端末ＭＮＡ のＮＡＩ およびＣＯＡ をテーブルから抹消する。
【００４３】
次に、アクセスルータにおける移動端末の代理機能について説明する。
（２）登録要求（代理ＭＮ機能）
移動端末ＭＮＡ の代理端末機能が移管されたＮｅｗ ＡＲであるアクセスルータＡＲＸ は、移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照し、移動端末ＭＮＡ の相手端末（ＣＮ）全てに対し移動端末ＭＮＡ に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する（図２の（４））。図５の（３）にアクセスルータＡＲＸ が相手端末ＣＮＤ に対し送信するｂｉｎｄｉｎｇ ｕｐｄａｔｅのパケットのアドレス例を示す。同図に示すように、パケットの送信元アドレスＳＡとして移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）、送信先アドレスＤＡとして相手端末ＣＮＤ のＣＯＡ（Ｍ：ｄ）を設定し、Ｄｅｓｔｉｎａｔｉｏｎ ｏｐｔｉｏｎにアクセスルータＡＲＭ のアドレス（Ｍ：ｍ） および移動端末ＭＮＡ のＮＡＩ を設定する。
【００４４】
アクセスルータＡＲＸ からのｂｉｎｄｉｎｇ ｕｐｄａｔｅを受けた各相手端末の最終ホップのアクセスルータ（ＡＲ）では、該当相手端末に代わり該当相手端末用のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを更新する。即ち、ｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル中の前記パケットで通知されたＮＡＩ と同じＮＡＩ に対応するＣＯＡ に前記通知されたＣＯＡ を設定する。図４は移動端末ＭＮＡ の相手端末ＣＮＤ が在圏する代理ＨＡであるアクセスルータＡＲＭ が相手端末ＣＮＤ に代わり移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅを受け、相手端末ＣＮＤ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルにある移動端末ＭＮＡ のＣＯＡ をＹ：ａ （図４の（２））からＸ：ａ （図４の（３））に更新する例を示す。
【００４５】
次に、アクセスルータにおける移動端末の代理ＨＡ機能について説明する。
（３）パケット送信、受信
移動端末ＭＮＡ が相手端末にパケットを送信する場合の実施例を図６に示す。図６では移動端末ＭＮＡ が相手端末ＣＮＥ にパケットを送信する例を示している。移動端末ＭＮＡ はアクセスルータＡＲＸ に対し、ＳＡ＝ｏｈｋｉ＠ｎｅｃ．ｃｏｍ，ＤＡ＝ｊｉｒｏ＠ｂｉｇｌｏｂｅ．ｎｅ．ｊｐ とアドレス指定をしてパケットを送信する（図６の（１））。アクセスルータＡＲＸ は移動端末ＭＮＡ からパケットを受け、相手端末宛にパケットを転送する場合、次の処理を行う。先ず、パケットのＳＡから移動端末ＭＮＡ からのパケットで有ることを認識し、端末管理テーブルから移動端末ＭＮＡ のＣＯＡ（Ｘ：ａ）を獲得して、転送パケットのＳＡとしてセットする。次に移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルを参照してＤＡ＝ｊｉｒｏ＠ｂｉｇｌｏｂｅ．ｎｅ．ｊｐ に該当する相手端末ＣＮＥ のＣＯＡ（Ｎ：ｅ）を転送パケットのＤＡにセットし、相手端末ＣＮＥ 宛に転送する。
【００４６】
相手端末ＣＮＥ 宛のパケットは、通常のＩＰルーティングによりＤＡのＣＯＡ におけるｎｅｔｗｏｒｋ ｐｒｅｆｉｘ Ｎを持つサブネットワークＳＮのアクセスルータＡＲＮ（相手端末ＣＮＥ の代理ＣＮ） に配送される。アクセスルータＡＲＮ はＤＡからこのパケットが端末ＣＮＥ 宛のパケットと認識し、端末管理テーブルから端末ＣＮＥ のＮＡＩ にＤＡアドレスを書き換え、端末ＣＮＥ 宛にパケットを転送する。
【００４７】
このように相手端末ＣＮＥ 宛のパケットのＤＡアドレスとして相手端末ＣＮＥ のＣＯＡ を指定できるため、アクセスルータＡＲＸ およびＡＲＮ ではパケットをｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ する必要はない。
【００４８】
（４） ｈａｎｄｏｆｆ
図７に移動端末ＭＮＡ が通信相手ＣＮＤ からパケットを受信中にサブネットワークを跨ぐ場合のハンドオフ制御の例を示す。
【００４９】
移動端末ＭＮＡ は、サブネットワークを跨ぐと、（１）項で述べた手順で移動検知とＣＯＡ 獲得を行い、アクセスルータＡＲＸ 経由でアクセスルータＡＲＹ へ登録要求を行う（図７の（１））。アクセスルータＡＲＸ は前述したように端末管理テーブルに移動端末ＭＮＡ のＮＡＩ とＣＯＡ の対を登録する。
【００５０】
アクセスルータＡＲＹ は移動端末ＭＮＡ がパケット通信中に登録要求を受け、移動端末ＭＮＡ が新たなサブネットワークに移動したことを認識すると、移動端末ＭＮＡ に対するアンカーとなり移動端末ＭＮＡ にパケットを転送し始める。この場合は、通信相手ＣＮＤ からのパケット送信が終わるか或いはタイマによる一定時間が経過するまでは、移動端末ＭＮＡ の代理ＨＡ機能はアクセスルータＡＲＸ に移行せず、アクセスルータＡＲＹ がアンカーとなり最後までパケットを転送し続ける。具体的には以下のような制御が行われる。
【００５１】
アクセスルータＡＲＹ は移動端末ＭＮＡ から登録要求を受けると、（１）項で述べた認証を行い成功すれば、相手端末ＣＮＤ へ移動端末ＭＮＡ に代わりｂｉｎｄｉｎｇ ｕｐｄａｔｅを送信する（ 図７の（２））。また端末管理テーブル中の移動端末ＭＮＡ のＣＯＡ を新ＣＯＡ に書き換え、相手端末ＣＮＤ から移動端末ＭＮＡ 宛のパケットは新ＣＯＡ のＮｅｔｗｏｒｋ ｐｒｅｆｉｘ Ｘに従ってアクセスルータＡＲＸ に転送することを決定する。アクセスルータＡＲＭ はアクセスルータＡＲＹ から移動端末ＭＮＡ のｂｉｎｄｉｎｇ ｕｐｄａｔｅを受信すると、端末ＣＮＤ のｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブル中の移動端末ＭＮＡ のＣＯＡ を書き換え、端末ＣＮＤ から移動端末ＭＮＡ 宛のパケットはアクセスルータＡＲＹ に転送すると共に、移動端末ＭＮＡ の新たなＣＯＡ へもパケットを送信し始める（図７の（３））。アクセスルータＡＲＹ では受信したパケットのＤＡ中のＮｅｔｗｏｒｋ ｐｒｅｆｉｘをＹ からＸ に書き換え、アクセスルータＡＲＸ に転送し、アクセスルータＡＲＸ は移動端末ＭＮＡ に転送する。この結果、移動端末ＭＮＡ 宛のパケットはいわゆるｂｉｃａｓｔｉｎｇ されることになりｈａｎｄｏｆｆ に伴うパケットロスを極力少なくすることが可能である。
【００５２】
通信相手ＣＮＤ から移動端末ＭＮＡ へのパケット送信が終了すると、（１）項で述べた手順により移動端末ＭＮＡ の代理ＨＡ機能および代理端末機能がアクセスルータＡＲＹ からアクセスルータＡＲＸ へ移行する。
【００５３】
（５）端末認証（セキュリティ）
本発明では従来と同様に、Ｍｏｂｉｌｅ ＩＰ とＡＡＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｃｃｏｕｎｔｉｎｇ）サーバとの連携が可能である。図８に端末認証に対する実施例を示す。図８に示すモデルで、代理ＨＡであるアクセスルータＡＲＸ は移動端末ＭＮＡ からの登録要求を受けると、ＡＡＡ サーバと連携で端末の認証を行うことができる。ここで、図８のＫＤＣ（Ｋｅｙ ｄｉｓｔｒｉｂｕｔｉｏｎ ｃｅｎｔｅｒ）は、ＡＡＡ サーバおよび移動端末ＭＮＡ に認証鍵を配送する機能をもつ。
【００５４】
【発明の効果】
以上説明したように本発明によれば以下の効果が奏される。
【００５５】
移動端末は自分の端末アドレスのＣＯＡ のみ獲得できれば、後は代理ＨＡが自分用のｂｉｎｄｉｎｇ ｕｐｄａｔｅを維持、更新してくれる。このため、待ちうけ時にｂｉｎｄｉｎｇ ｕｐｄａｔｅ更新の必要がなく従来技術のｂｉｎｄｉｎｇ ｕｐｄａｔｅ維持、更新のためのバッテリ消費問題が解決できる。
【００５６】
移動端末間のｂｉｎｄｉｎｇ ｕｐｄａｔｅはアクセスルータ同士で行われるため、ｂｉｎｄｉｎｇ ｕｐｄａｔｅは無線区間に流れることはない。
【００５７】
通信相手がアクセスルータのｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルに存在する限りトンネリングの必要がなく、アクセスルータでのｅｎｃａｐｓｕｌａｔｉｏｎ，ｄｅｃａｐｓｕｌａｔｉｏｎ 処理によるスケーラビリティ問題を回避できる。
【図面の簡単な説明】
【図１】本発明の実施例のシステム構成図である。
【図２】本発明における移動端末の登録要求およびｂｉｎｄｉｎｇ ｕｐｄａｔｅ送信のシーケンス例を示す図である。
【図３】代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータにおける端末管理テーブルおよびｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す図である。
【図４】代理ＨＡおよび代理ＭＮ（もしくは代理ＣＮ）機能を有すアクセスルータにおける端末管理テーブルおよびｂｉｎｄｉｎｇ ｕｐｄａｔｅテーブルの構成例を示す図である。
【図５】移動端末から代理ＨＡ向けに出される登録要求パケットのフォーマット構成例を示す図である。
【図６】移動端末から通信相手宛のパケット送信のシーケンス例を示す図である。
【図７】本発明の実施例におけるＨａｎｄ ｏｆｆシーケンス例を示す図である。
【図８】本発明の実施例におけるＡＡＡ サーバとの連携例を示す図である。
【図９】従来技術の一例を示す図である。
【図１０】従来技術の他の例を示す図である。
【符号の説明】
ＭＮ： 移動端末（Ｍｏｂｉｌｅ Ｎｏｄｅ）
ＡＲ： アクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）
ＣＮ： 通信相手（Ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ Ｎｏｄｅ）
Claims (13)
- 複数の相互に接続されたサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における移動端末管理システムにおいて、
前記サブネットワークは、アクセスルータを備え、
前記アクセスルータは、
在圏する前記移動端末のCOAを保持管理する端末管理テーブルと、
在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新テーブルと、
前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求を受け付けるホームエージェント代行手段と、
を有することを特徴とする移動網における移動端末管理システム。 - 前記ホームエージェント代行手段が、
在圏する前記移動端末から通信相手宛に送信されるパケットを受信してその宛先アドレスを当該通信相手のCOA に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットを受信して前記移動端末に転送する手段を有することを特徴とする請求項１記載の移動網における移動端末管理システム。 - 前記端末管理テーブルは在圏する前記移動端末のNAI 又はURI とCOA の組を保持する構成を有し、
前記バインディング更新テーブルは各通信相手のNAI 又はURI とCOA の組を保持する構成を有し、
前記移動端末から通信相手宛に送信されるパケットはその宛先アドレスに当該通信相手のNAI 又はURI が設定される請求項１又は２記載の移動網における移動端末管理システム。 - 前記ホームエージェント代行手段は、在圏する前記移動端末から通信相手宛に送信されるパケットの宛先アドレスを前記NAI 又はURI から前記COA に書き換えて転送すると共に在圏する前記移動端末宛に送信されてくるパケットの宛先アドレスを前記COA から前記NAI 又はURI に書き換えて前記移動端末に転送する構成を有する請求項１乃至３の何れか１項に記載の移動網における移動端末管理システム。
- 前記アクセスルータは、移動前のサブネットワークの前記アクセスルータと移動後のサブネットワークの前記アクセスルータとの間で、当該移動端末用の前記バインディング更新テーブルの受け渡し及び当該移動端末にかかるホームエージェント代行機能の移管を行う手段を備える請求項1 乃至４の何れか１項に記載の移動網における移動端末管理システム。
- 前記アクセスルータは、自サブネットワークに移動してきた前記移動端末の前記バインディング更新テーブルを受け取ったときに当該バインディング更新テーブルに記載されている全ての通信相手に対して前記移動してきた移動端末の新たなCOA を通知するバインディング更新パケットを送信すると共に、在圏する移動端末宛の前記バインディング更新パケットを他のアクセスルータから受信したときに該当する前記バインディング更新テーブルを更新する移動端末代行手段を備える請求項５記載の移動網における移動端末管理システム。
- 前記複数のサブネットワークはそれぞれ異なるネットワークプレフィックスを持ち、
前記移動端末のCOA は在圏する前記サブネットワークのネットワークプレフィックスと当該移動端末のインタフェースIDとから構成される請求項１乃至６の何れか１項に記載の移動網における移動端末管理システム。 - 複数の相互に接続されたサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における前記サブネットワークに備えられたアクセスルータであって、
在圏する前記移動端末のCOAを保持管理する端末管理手段と、
在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新保持手段と、
を備えることを特徴とするアクセスルータ。 - アクセスルータを含み相互に接続される複数のサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網におけるアクセスルータであって、
在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新保持手段と、
前記移動端末がサブネットワーク間を移動した際に、前記移動端末の各通信相手が在圏するサブネットワークに対応するアクセスルータに対してそのアクセスルータの備えるバインディング更新保持手段を更新するための信号を送信する手段と、
を備えることを特徴とするアクセスルータ。 - アクセスルータを含み相互に接続される複数のサブネットワークを備え、任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供する移動網における前記アクセスルータであって、
在圏する前記移動端末の各通信相手のCOA を保持管理するバインディング更新保持手段と、
前記移動端末がサブネットワーク間を移動した際に、移動先のサブネットワークに対応するアクセスルータから送信される前記バインディング更新保持手段を更新するための信号に基づいて前記バインディング更新保持手段を更新する手段と、
を備えることを特徴とするアクセスルータ。 - アクセスルータを含み複数の相互に接続されたサブネットワークを備え、
任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供し、
前記アクセスルータが前記移動端末のCOAを保持管理する端末管理手段と在圏する前記移動端末の各通信相手のCOAを保持管理するバインディング更新保持手段とを備える移動網における移動端末管理方法であって、
前記アクセスルータが、前記移動端末がサブネットワーク間を移動したときに前記移動端末から出される登録要求を受け付けることを特徴とする移動端末管理方法。 - アクセスルータを含み複数の相互に接続されたサブネットワークを備え、
任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供し、
前記アクセスルータが在圏する前記移動端末の各通信相手のCOAを保持管理するバインディング更新保持手段を備える移動網における移動端末管理方法であって、
前記アクセスルータが、前記移動端末がサブネットワーク間を移動した際に、前記移動端末の各通信相手が在圏するサブネットワークに対応するアクセスルータに対してそのアクセスルータの備えるバインディング更新保持手段を更新するための信号を送信することを特徴とする移動端末管理方法。 - アクセスルータを含み複数の相互に接続されたサブネットワークを備え、
任意の前記サブネットワークに在圏する移動端末に対してパケット通信サービスを提供し、
前記アクセスルータが在圏する前記移動端末の各通信相手のCOAを保持管理するバインディング更新保持手段を備える移動網における移動端末管理方法であって、
前記アクセスルータが、前記移動端末がサブネットワーク間を移動した際に、移動先のサブネットワークに対応するアクセスルータから送信される前記バインディング更新保持手段を更新するための信号に基づいて前記バインディング更新保持手段を更新することを特徴とする移動端末管理方法。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001070120A JP3573098B2 (ja) | 2001-03-13 | 2001-03-13 | 移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 |
| CNB02806660XA CN1262090C (zh) | 2001-03-13 | 2002-03-12 | 移动网络中管理移动节点的系统 |
| CN2005101187073A CN1770742B (zh) | 2001-03-13 | 2002-03-12 | 移动网络中管理移动节点的系统 |
| US10/471,613 US7483697B2 (en) | 2001-03-13 | 2002-03-12 | System for managing mobile node in mobile network |
| PCT/JP2002/002301 WO2002073907A1 (fr) | 2001-03-13 | 2002-03-12 | Systeme de gestion de noeud mobile dans un reseau de mobiles |
| EP02702906A EP1379034A4 (en) | 2001-03-13 | 2002-03-12 | SYSTEM FOR MANAGING A MOBILE NODE IN A MOBILE NETWORK |
| HK04107869A HK1065201A1 (en) | 2001-03-13 | 2004-10-13 | System for managing mobile node in mobile network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001070120A JP3573098B2 (ja) | 2001-03-13 | 2001-03-13 | 移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002271377A JP2002271377A (ja) | 2002-09-20 |
| JP3573098B2 true JP3573098B2 (ja) | 2004-10-06 |
Family
ID=18928045
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001070120A Expired - Fee Related JP3573098B2 (ja) | 2001-03-13 | 2001-03-13 | 移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3573098B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0305673D0 (en) * | 2003-03-12 | 2003-04-16 | Orange Personal Comm Serv Ltd | Telecommunications |
| KR100513863B1 (ko) | 2003-04-29 | 2005-09-09 | 삼성전자주식회사 | 호스트의 이동성을 지원할 수 있는 무선 근거리 네트워크시스템 및 그의 동작방법 |
| KR20050101693A (ko) * | 2004-04-19 | 2005-10-25 | 삼성전자주식회사 | 이동 네트워크에서 손상된 라우팅 경로 복구 방법 |
| EP1753181A4 (en) * | 2004-05-31 | 2012-02-22 | Panasonic Corp | MOBILE TERMINAL MANAGEMENT DEVICE, MOBILE TERMINAL AND COMMUNICATION SYSTEM |
| CN101147366B (zh) | 2005-03-25 | 2015-09-16 | 日本电气株式会社 | 移动通信系统、边缘路由器和传输控制方法 |
| JP4616074B2 (ja) | 2005-05-16 | 2011-01-19 | 株式会社エヌ・ティ・ティ・ドコモ | アクセスルータ、サービス制御システム、サービス制御方法 |
| JP5102766B2 (ja) * | 2006-07-28 | 2012-12-19 | パナソニック株式会社 | 移動通信方法及びアクセスルータ |
| JP5298540B2 (ja) * | 2008-01-22 | 2013-09-25 | 富士通株式会社 | ネットワークシステム、データ送受信方法、及びデータ送受信プログラム |
| JP2015041801A (ja) * | 2013-08-20 | 2015-03-02 | 日本電信電話株式会社 | 端末認証方法および端末認証システム |
-
2001
- 2001-03-13 JP JP2001070120A patent/JP3573098B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002271377A (ja) | 2002-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7483697B2 (en) | System for managing mobile node in mobile network | |
| US8102815B2 (en) | Proxy mobility optimization | |
| US7630340B2 (en) | Handover method | |
| JP3587984B2 (ja) | 移動通信システム、パケットゲートウェイ装置、位置情報管理方法、および、位置情報通知方法 | |
| JP5118055B2 (ja) | 移動体ネットワーク上におけるインターネット・プロトコル・トンネリング | |
| JP4909357B2 (ja) | イーサネット伝送プロトコルを基礎とするデータパケットを少なくとも１つのモバイル通信ユニットと通信システムとの間において伝送する方法 | |
| JP3617952B2 (ja) | モバイルｉｐにおけるデータ転送方法およびシステム | |
| US7224695B2 (en) | Router and communication network system | |
| WO2010000174A1 (zh) | 移动节点的注册、通信、切换方法及装置 | |
| JP2013021712A (ja) | 移動管理システム、ホームエージェント及びそれらに用いる移動端末管理方法並びにそのプログラム | |
| WO2007131404A1 (fr) | Méthode et dispositif de transfert rapide | |
| WO2007128239A1 (fr) | Système d'implémentation d'ipv6 mobile et procédé d'établissement de lien utilisateur dans le système | |
| JP3573098B2 (ja) | 移動網における移動端末管理システム、アクセスルータ、移動端末管理方法 | |
| KR100915513B1 (ko) | 프락시 모바일 ＩＰｖ６에서 패킷 손실을 줄이기 위한 패킷버퍼링 장치 및 방법 | |
| JP3601464B2 (ja) | 移動網における移動端末管理システム、移動端末管理方法および端末 | |
| US20090116452A1 (en) | APPARATUS AND METHOD FOR A MOBILE NODE ROAMING IN AN IPv6 NETWORK | |
| JP2008543120A (ja) | パケット転送制御方法及びパケット転送制御装置 | |
| KR100597432B1 (ko) | 이웃탐색 프록시 기반의 아이피브이6 이동 네트워크에서의이동노드를 위한 경로최적화 방법 | |
| JP2008541516A (ja) | ＩＰｖ６通信相手ノード及び移動ＩＰｖ６ノード間の通信方法、並びに通信相手ノードプロキシーゲートウエイ | |
| WO2008017253A1 (fr) | Procédé, système et appareil d'accès à plusieurs hôtes supportant une ip mixte | |
| JP4425757B2 (ja) | モバイルネットワークシステム | |
| JP2005012620A (ja) | ネットワークシステム及びアドレス作成方法 | |
| JP3885942B2 (ja) | 移動端末のデータ通信方法 | |
| JP4351123B2 (ja) | ユーザ識別子の管理方法、モバイルｉｐエージェント及びホームエージェント | |
| Idoue et al. | Mobile IP network supporting private IP addresses utilizing regional registration and NAT function |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040608 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040621 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070709 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080709 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090709 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100709 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120709 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120709 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130709 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |