JP2002185520A - 移動端末対応ルータおよびホームエージェント・ルータ - Google Patents

Abstract

(57)【要約】 【課題】 ＩＰｖ６プロトコルで動作するルータに関
し、移動端末の現在アドレス更新に要する時間を短縮し
て転送ルートの切替えを高速化すると共に、同プロトコ
ルをサポートしない端末については、毎回ホームエージ
ェントを経由しない転送ルートを提供する。 【解決手段】 相手端末ＣＮが記憶すべき移動端末ＭＮ
の現在アドレスを、該相手端末に代わって、記憶する記
憶手段１１と、移動端末ＭＮのホームアドレス宛てに送
信されたパケットを受信したとき、記憶手段１１を参照
し、現在アドレス宛てに変換してそのパケットを送信す
る転送手段１２と、を備える移動端末対応ルータ１０で
ある。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、固定端末および移
動端末のうち少なくとも移動端末をサポートするパケッ
ト通信システムを構成する移動端末対応ルータおよびホ
ームエージェント・ルータに関する。

【０００２】

【従来の技術】ＩＰネットワークにおいて、端末がネッ
トワーク上の接続位置を変えても通信を行うことを可能
とする移動端末対応のプロトコルとして、米国の標準化
団体ＩＥＴＦ（Internet Engineering Task Force ）に
おいて、Ｍｏｂｉｌｅ ＩＰ（文献〔１〕ＲＦＣ２００
２）が標準化されている（注：本明細書中にて引用する
各文献は巻末にまとめて掲記する）。

【０００３】また近年のＩＰネットワークに収容される
端末数の急増により、ＩＰアドレスの枯渇の問題が深刻
化しており、より多くのＩＰアドレスを使用することが
可能なＩＰｖ６（文献〔２〕ＲＦＣ２４６０）を使用し
たネットワークへの移行が本格化している。このため、
これまでのＩＰｖ４ネットワークにおけるＭｏｂｉｌｅ
ＩＰだけでなく、ＩＰｖ６ネットワーク上での端末の
移動をサポートするプロトコルとしてＭｏｂｉｌｅ Ｉ
Ｐｖ６（文献〔３〕）の標準化が進められており、上記
ＩＥＴＦにおいてＲＦＣ（Request For Comments）化の
ための審議が行われている。

【０００４】

【発明が解決しようとする課題】しかしながら、上記の
Ｍｏｂｉｌｅ−ＩＰｖ６では、ネットワークの構成や端
末の位置によっては、移動端末（Mobile Node ：以下、
ＭＮとも称す）が移動した際に行われる転送ルートの切
替えに時間がかかる場合がある。このような場合、移動
端末ＭＮの移動前に接続していたネットワークに他の端
末からパケットが送られるとパケット損失（ロス）が発
生し、通信品質が劣化する、という問題がある。

【０００５】また、上記の転送ルートの切替えを行うに
は、移動端末ＭＮのみならず、この移動端末ＭＮと通信
を行う相手端末（Correspondent Node：以下、ＣＮとも
称す）でもＭｏｂｉｌｅ−ＩＰｖ６のプロトコルが動作
している必要がある。したがってもしこの相手端末ＣＮ
においてＭｏｂｉｌｅ−ＩＰｖ６プロトコルをサポート
していない場合には、ＭＮへ送信すべきパケットは、通
常ＭＮが接続しているホームリンクに連係するホームエ
ージェント（Home Agent：以下、ＨＡとも称す）を経由
してＭＮへ転送される。このため、転送遅延の増大やＨ
Ａにおけるトラフィックの集中等が起こる可能性があ
る、という問題がある。なお、これらの問題は後に図を
参照して詳しく説明する。

【０００６】したがって本発明は、上記問題点に鑑み、
転送ルートの切替えに要する時間を短縮してパケット転
送ルートの切替えを高速化し、また、ＩＰｖ６プロトコ
ルをサポートしてない相手端末ＣＮから移動端末ＭＮへ
のパケット転送についてはその転送ルートを短縮化し
て、通信品質の劣化の原因となるパケット損失、転送遅
延の増大、ホームエージェントＨＡにおけるトラフィッ
クの集中等を抑制することのできる、移動端末対応ルー
タならびにホームエージェント・ルータを提供すること
を目的とするものである。

【０００７】

【課題を解決するための手段】図１は本発明に係る移動
端末対応ルータの基本構成を示す図である。本図におい
て、本発明に係る移動端末対応ルータ１０は、図示する
記憶手段１１と、転送手段１２を含んで構成される。ま
ずこの移動端末対応ルータ１０は、少なくとも移動端末
ＭＮのパケット通信をサポートするネットワークを構成
する移動端末対応ルータである。したがってこのネット
ワークは固定端末のパケット通信もサポート可能であ
る。

【０００８】ここに、記憶手段１１は、上記パケット通
信の相手端末ＣＮが記憶すべき移動端末ＭＮの現在アド
レスを、この相手端末ＣＮに代わって、記憶する。ま
た、転送手段１２は、相手端末ＣＮから移動端末ＭＮの
ホームアドレス宛てに送信されたパケットを受信したと
き、記憶手段１１を参照し、そのホームアドレス宛てを
現在アドレス宛てに変換してそのパケットを送信する。

【０００９】図２は本発明に係るホームエージェント・
ルータの基本構成を示す図である。このホームエージェ
ント・ルータ２０は、図１の移動端末対応ルータ１０と
同様に、少なくとも移動端末ＭＮの通信をサポートする
ネットワークを構成するホームエージェント・ルータで
ある。ここに、受信手段２１は、移動端末ＭＮの移動に
より現在アドレスを変更したことに伴いホームエージェ
ント・ルータに対し当該アドレスの更新を通知するため
に送信される更新通知情報を受信する。

【００１０】またアドレス更新通知手段２２は、該更新
通知情報を受信したときに、その更新後の現在アドレス
を、ネットワークを構成する他のルータに送信する。こ
のホームエージェント・ルータ２０は、通常のホームエ
ージェントとしての機能に加え、本発明に基づき、上記
の記憶手段１１に上記現在アドレスを通知する機能を併
せ持つものである。ただし、その現在アドレスを通知す
る機能はこれに限るものではない（後述）。

【００１１】かくして、ＩＰｖ６をサポートする相手端
末ＣＮが本来実行すべき、移動端末ＭＮの移動後のアド
レス更新操作を、この移動端末ＭＮにこの相手端末ＣＮ
より近くに位置する移動端末対応ルータ１０が先取りし
て行ってしまうので、前述した転送ルートの切替えに要
する時間は短縮され、したがって問題となっているパケ
ット損失は大幅に減少する。

【００１２】また、ＩＰｖ６をサポートしない相手端末
ＣＮから移動端末ＭＮに送信されるパケットは、当該移
動端末対応ルータ１０を経由してホームエージェントＨ
Ａに至り、ここでＭＮの現在アドレスに書き換えられて
送信先のＭＮに送られる、という従来の手順は不要とな
り、上記パケットはその移動端末対応ルータ１０から、
ＨＡを介さずに、直接送信先のＭＮに送られるので、問
題となっているパケットの転送遅延やＨＡでのトラフィ
ックの集中は大幅に改善される。

【００１３】

【発明の実施の形態】本発明はＩＰｖ６プロトコルに準
拠する場合のみならず、このＩＰｖ６プロトコル相当の
プロトコルに準拠する場合にも適用可能であるが、以下
の説明は主として現状のＩＰｖ６プロトコルに準拠する
場合を例にとって行う。そこでまず、本発明の実施例を
説明する前に、本発明の理解を容易にするため従来の移
動端末対応ルータ１０について説明しておく。また上記
ホームエージェント・ルータ２０に相当する従来のホー
ムエージェントＨＡについても併せて説明しておく。

【００１４】図３は従来のパケット通信システムを表す
図（その１）であり、図４は同図（その２）である。な
お、これら図３および図４は、相手端末ＣＮにおいてＭ
ｏｂｉｌｅ−ＩＰｖ６プロトコルをサポートしている場
合の例を示す。まず図３を参照すると、前提として、通
常はホームリンクであるネットワーク１に接続している
移動端末ＭＮ（ホームアドレス＝Ａ）は、ネットワーク
３に移動したものとする。すると、このネットワーク３
において新たにアドレスＢを生成する。この生成したア
ドレスＢをＣｏＡ（Care-of Address ）として、ホーム
エージェントＨＡおよび相手端末ＣＮ１に図示しないル
ートで通知する。ＨＡおよびＣＮ１は、その通知に基づ
き、Binding Cache （ＭＮのホームアドレスと、通知さ
れたＭＮのＣｏＡおよびその有効時間等を記憶する情
報：文献〔３〕で定義）を生成する。なお、ＣＮ１は上
述のとおりＭｏｂｉｌｅ−ＩＰｖ６をサポートしている
端末である。つまりBinding Update（Ｂ．Ｕ．）を受信
・処理して、Binding Cache を生成する能力を持つ端末
である。

【００１５】このような状態から、 〔１〕：ＭＮはネットワーク４へ移動したとする。 〔２〕：ＭＮはネットワーク４において、新たなＣｏＡ
としてアドレスＣを生成する。 〔３〕：ＭＮは、ＨＡおよびＣＮ１にそれぞれBinding
Update（ＣｏＡを通知するパケット：文献〔３〕で定
義）を図中のＢ．Ｕ．として送信し、ＣｏＡ（＝アドレ
スＣ）を通知する。

【００１６】〔４〕：上記〔３〕で送信されたBinding
Update（Ｂ．Ｕ．）をＣＮ１が受信するよりも前に、Ｃ
Ｎ１からＭＮ宛てに、パケットＰ１，Ｐ２，Ｐ３を送信
したものとする。このとき、パケットの宛先アドレスで
あるＣｏＡはまだＢとなったままである。 〔５〕：ＨＡおよびＣＮ１はそれぞれ、ＭＮから〔３〕
にて送信されたBinding Update（Ｂ．Ｕ．）を受信し、
Binding Cache として記憶しているＭＮのＣｏＡを、ア
ドレスＢからアドレスＣへ更新する（図中の、Ａ→Ｂ，
Ａ→Ｃ）。続いてＨＡおよびＣＮ１はそれぞれ、Bindin
g Acknowledgement （Binding Update受信の確認を通知
するためのパケット。文献〔３〕で定義）を、図示しな
いルートでＭＮへ送信する。

【００１７】次に図４を参照する。図３の〔４〕におい
てＣＮ１より送信されたパケットＰ１，Ｐ２，Ｐ３は、
ＭＮの移動前におけるネットワーク３のＣｏＡ（＝アド
レスＢ）へ送信されている。このため、移動後のＭＮに
受信されることはなく、パケット損失（ロス）となる。
しかしＣｏＡの更新後にＣＮ１から送信されるパケット
Ｐ４は、ネットワーク４へ移動後のＭＮのＣｏＡ（＝ア
ドレスＣ）へ送信され、ルータＲ１→Ｒ２→Ｒ４を経由
してＭＮにて受信される。

【００１８】ここでの例では、ＭＮとＣＮ１の間にはネ
ットワーク５，６の２つのネットワークが存在するが、
さらに多くのネットワークを経由するような場合には、
ＭＮからBinding Updateが送信されてから、ＣＮ１でこ
れを受信しＣｏＡが更新されるまでの所要時間（上記の
例では図３の〔３〕〜〔５〕）がより一層長くなること
が予想される。このような場合、図３の〔４〕で示した
ように、ＣＮ１がＭＮの移動前のＣｏＡ（＝アドレス
Ｂ）宛てに多くのパケットを転送してしまうことにな
り、より多くのパケット損失（ロス）が発生する可能性
がある。

【００１９】図５は従来の他のパケット通信システムを
表す図（その１）であり、図６は同図（その２）であ
る。なお、これら図５および図６は、相手端末ＣＮにお
いてＭｏｂｉｌｅ−ＩＰｖ６プロトコルをサポートして
いない場合の例を示す。まず図５を参照すると、前提と
して、通常はホームリンクであるネットワーク１に接続
している移動端末ＭＮ（ホームアドレス＝Ａ）は、ネッ
トワーク３に移動したものとする。すると、このネット
ワーク３において新たにアドレスＢを生成する。この生
成したアドレスＢをＣｏＡとして、ＨＡおよびＣＮ２に
通知する。この通知により、ＨＡではBinding Cache を
生成するが、ＣＮ２はＭｏｂｉｌｅ−ＩＰｖ６をサポー
トしていないためにBinding Cache が生成されていない
状態、つまり通知されたＣｏＡ（＝アドレスＢ）を記憶
していない状態にある。

【００２０】このような状態から、 〔１〕：ＭＮはネットワーク４に移動したとする。 〔２〕：ＭＮはネットワーク４において、新たなＣｏＡ
としてアドレスＣを生成する。 〔３〕：ＭＮは、ＨＡおよびＣＮ２にそれぞれBinding
Updateを図中のＢ．Ｕ．として送信し、ＣｏＡ（＝アド
レスＣ）を通知する。ただし通信の相手端末ＣＮがＭｏ
ｂｉｌｅ−ＩＰｖ６をサポートしている／いない（ＣＮ
１／ＣＮ２）に拘わらず、ＭＮはＣＮ（ＣＮ１／ＣＮ
２）へBinding Updateを送信する場合がある。

【００２１】〔４〕：ＣＮ２からＭＮのホームアドレス
（＝Ａ）宛てに送信されたパケットＰ５，Ｐ６は、ネッ
トワーク２内を転送される。ただしＭｏｂｉｌｅ−ＩＰ
ｖ６をサポートしていない相手端末は、常にＭＮのホー
ムアドレスＡ宛てにパケットを送信する。 〔５〕：〔３〕にてＨＡおよびＣＮ２はそれぞれ、ＭＮ
から送信されたBinding Update（Ｂ．Ｕ．）を受信し
て、ＨＡは、Binding Cache として記憶しているＭＮに
ついてのＣｏＡをＢからＣへ更新（図中の、Ａ→Ｂ，Ａ
→Ｃ）するが、ＣＮ２は、Ｍｏｂｉｌｅ−ＩＰｖ６プロ
トコルをサポートしていないため、受信したBinding Up
dateを処理することができない。つまりＣＮ２には、Ｍ
ＮのＣｏＡ（＝アドレスＡ）は記憶されない。

【００２２】なおＢ．Ｕ．を受信したＨＡは、図示しな
いルートでBinding Acknowledgement をＭＮへ返送す
る。次に図６を参照する。図５の〔４〕にて、ＭＮのホ
ームアドレス（＝Ａ）宛てに転送されていたパケットＰ
５，Ｐ６は、ＨＡによってインタセプト（代理応答）さ
れる。すなわちこのＨＡにて、そのパケットはＩＰ−ｉ
ｎ−ＩＰカプセル化され（図のＰ６）、ＭＮのＣｏＡ
（＝アドレスＣ）へトンネリングされる。

【００２３】ここでパケットＰ５は更新前のＣｏＡ（＝
アドレスＢ）へトンネリングされたため、ＭＮに受信さ
れることはなく、パケット損失（ロス）となる。一方パ
ケットＰ６は、更新後のＣｏＡ（＝アドレスＣ）へトン
ネリングされ、ＭＮに受信される。以降、ＣＮ２からＭ
ＮのホームアドレスＡ宛てに送信されたパケットＰ７
は、ルータＲ１→Ｒ２→ＨＡ→Ｒ４を経由してＭＮにて
受信される。つまり、Ｍｏｂｉｌｅ−ＩＰｖ６をサポー
トしていない相手端末から送信されるパケットは、受信
者であるＭＮが、そのホームリンクから外部リンクへ移
動中である場合には、必ずＨＡを経由してＭＮへ転送さ
れることになる。これはパケット転送遅延の増大やＨＡ
へのパケットトラフィックの集中等を引き起こすことに
なる。また、ＭＮとＨＡが離れている場合には、図３お
よび図４で示した場合と同様に、ＨＡにおけるＣｏＡの
更新に時間がかかることから、ＨＡから、ＭＮの移動前
のＣｏＡ（＝アドレスＢ）にパケットをトンネリングし
てしまい、パケット損失（ロス）が発生する。

【００２４】このような問題を解決するための本発明に
基づく実施例を以下に詳述する。本発明に基づく実施例
は、移動端末ＭＮのＣｏＡ（Care-of Address ）の更新
に要する時間を短縮してパケット転送ルートの切替えを
高速化するものであり、また、Ｍｏｂｉｌｅ−ＩＰｖ６
をサポートしていない相手端末ＣＮからＭＮへのパケッ
ト転送ルートを、毎回ホームエージェントＨＡを経由し
ないように、最適化するものである。これにより、通信
品質の劣化の原因となるパケット転送遅延やパケット損
失（ロス）の増大を防ぐことを可能とする。

【００２５】図７は本発明に基づく移動端末対応ルータ
１０のさらに具体的な構成を示す図である。この構成は
図１の構成にさらに登録手段１３を付加したものであ
る。この登録手段１３は、移動端末ＭＮの移動により現
在アドレスを変更したことに伴い通信の相手端末ＣＮに
対し当該アドレスの更新を通知するために送信される更
新通知情報を受信したとき、この受信をトリガとして、
記憶手段１１におけるホームアドレスと現在アドレスと
の対応関係を新たに登録するものである。

【００２６】図８は本発明に基づくホームエージェント
・ルータ２０のさらに具体的な構成を示す図である。こ
の構成は図２の構成にさらに登録手段２３を付加したも
のである。ネットワーク２は、移動端末ＭＮをこのホー
ムアドレスにおいて収容するホームエージェント・ルー
タ２０を含んでおり、登録手段２３は、移動端末ＭＮの
移動により現在アドレスを変更したことに伴いホームエ
ージェント・ルータ２０に対し当該アドレスの更新を通
知するために送信される更新通知情報を受信したときに
ホームエージェント・ルータ２０からの当該更新アドレ
スの転送をトリガとして、記憶手段１１におけるホーム
アドレスと現在アドレスとの対応関係を新たに登録する
ものである。

【００２７】図９は本発明に基づくルータ１０および２
０を含むパケット通信システムの具体例を示す図（その
１）であり、図１０は同図（その２）である。まず図９
を参照すると、本図中の１０および２０が、それぞれ本
発明に係る移動端末対応ルータ（図のＲ２）およびホー
ムエージェント・ルータ（図のＨＡ）である。以下、Ｒ
２およびＨＡと略称する。

【００２８】移動端末対応ルータＲ２は、移動端末ＭＮ
から送信されるBinding Update（Ｂ．Ｕ．）を、相手端
末ＣＮ１またはＣＮ２の代わりに受信する（本図の
〔１〕）。あるいは、ホームエージェント・ルータＨＡ
がＲ２へアドレスの更新を通知し、Ｒ２がこれを受信す
る（本図の〔２〕）。〔１〕または〔２〕により、ＭＮ
についてのＣｏＡ（現在アドレス）を記憶する（本図の
〔３〕）。

【００２９】相手端末ＣＮのうちＣＮ１は、Ｍｏｂｉｌ
ｅ−ＩＰｖ６をサポートしているが、ＭＮからのBindin
g Update（Ｂ．Ｕ．）はＲ２で受信され、ＣＮ１には到
達しない。したがって、ＣＮ１はＭＮがホームリンクの
外へ移動中であることを知ることがない。このためＭｏ
ｂｉｌｅ−ＩＰｖ６をサポートしていないＣＮ２のみな
らずＣＮ１も、ＭＮのホームアドレス（＝アドレスＡ）
宛てにパケットを送信する。

【００３０】この場合、ＭＮからＨＡおよびＣＮ（ＣＮ
１／ＣＮ２）へのBinding Update（Ｂ．Ｕ．）の送信、
およびＨＡまたはＣＮからＭＮへのBinding Acknowledg
ement の送信のためには、ＭＮとＨＡ、およびＭＮとＣ
Ｎのそれぞれの間で、認証ヘッダ（文献〔４〕ＲＦＣ２
４０２）による認証を行うための情報を持っている必要
がある。この情報は、セキュリティパラメータインデッ
クス、認証アルゴリズム、認証鍵等からなる。

【００３１】そのような認証情報が無い場合には、ＭＮ
からBinding Updateが送信されないため、本図のルータ
Ｒ２は〔１〕のBinding UpdateからＣｏＡを更新するこ
とができない。このような場合には、図の〔２〕に示す
ように、ＨＡからＲ２に対してＭＮのＣｏＡを通知する
ことが有効である。なおこのようなＨＡからＲ２へのＣ
ｏＡの通知は、Ｍｏｂｉｌｅ−ＩＰｖ６プロトコルでは
定義されていない。

【００３２】次に図１０を参照すると、本図中のＲ２
は、ＭＮのＣｏＡ（＝アドレスＣ）を記憶しているの
で、ＣＮ１またはＣＮ２から送信されたパケット（宛先
はＭＮのホームアドレスＡ）をＲ２で受信した場合に、
Ｒ２はそのパケットをＭＮのホームアドレスＡに向けて
転送するのではなく、ＭＮのＣｏＡ（＝アドレスＣ）へ
向けてダイレクトに転送することができる。

【００３３】このように本発明のルータ１０（あるい
は、ルータ１０およびルータ２０）により、ＭＮのＣｏ
Ａの更新に要する時間を短縮し、ＭＮへのパケット転送
ルートの切替えを高速化することができる。またＭｏｂ
ｉｌｅ−ＩＰｖ６をサポートしていない相手端末ＣＮ２
からＭＮへのパケット送信があったときは、その転送ル
ートを、ＨＡを毎回経由しないように、最適化する。こ
れにより、通信品質の劣化の原因となるパケット転送遅
延やパケット損失（ロス）の増大を防ぐことが可能にな
る。

【００３４】以下、図９および図１０のさらに詳細な例
を説明する。図１１は図９および図１０のシステムの第
１の詳細例を示す図（その１）であり、図１２は同図
（その２）である。まず前提として、図１１および図１
２に示されるルータ（Ｒ１，Ｒ２，Ｒ３，Ｒ４）および
端末（ＭＮ，ＣＮ１）についての詳しい説明を以下に示
す。

【００３５】＜ＭＮ＞Ｍｏｂｉｌｅ−ＩＰｖ６プロトコ
ルをサポートする移動端末である。通常はそのＭＮのホ
ームリンクであるネットワーク１に接続され、ホームア
ドレスＡを使用して通信を行う。ホームリンク（ネット
ワーク１）以外のネットワークに移動した場合は、移動
先のネットワークにおいて使用するＣｏＡ（Care-of Ad
dress）を生成する。さらにＭｏｂｉｌｅ−ＩＰｖ６プ
ロトコルにより、ＨＡ２０およびＣＮ１に対し、Bindin
g Updateを送信する。またこのＭＮは、ＨＡ２０との認
証情報であるＳＡ１と、ＣＮ１との認証情報であるＳＡ
２とをそれぞれ保持しているものとする。ＳＡ１および
２は、Security Association 1および２である。

【００３６】＜ＨＡ＞ＭＮのホームリンクであるネット
ワーク１において、Ｍｏｂｉｌｅ−ＩＰｖ６プロトコル
でのホームエージェント機能を提供するルータあるいは
サーバである。ここの例では、ＨＡ２０のアドレスをＤ
とする。またＭＮとの認証情報であるＳＡ１を保持して
いるものとする。

【００３７】ＭＮから送信されたBinding Update（Ｂ．
Ｕ．）をＨＡが受信すると、ＨＡはBinding Cache を生
成しこれを保持する。Binding Cache を生成した場合に
は、ＨＡはＭＮに対し、Binding Acknowledgement
（Ｂ．Ａ．）を返送する。このBinding Cache の有効時
間内に、ＨＡはＭＮ宛てに送信されたパケットをインタ
セプトし、ＭＮのＣｏＡ（＝アドレスＢ）へ向けてその
パケットをＩＰ−ｉｎ−ＩＰカプセル化して転送する。

【００３８】＜ＣＮ１＞ＭＮと通信を行う相手端末であ
り、Ｍｏｂｉｌｅ−ＩＰｖ６プロトコルをサポートす
る。ここの例では、ＣＮ１のアドレスをＥとする。また
ＭＮとの認証情報であるＳＡ２を保持しているものとす
る。ＭＮから送信されたBinding Updateを受信した場合
には、上記のＨＡと同様に、Binding Cache を生成し、
これを保持する。このBinding Cache の有効時間内に、
ＭＮ宛てにパケットを送信する際は、ＩＰｖ６拡張ヘッ
ダであるルーティングオプションヘッダを使用して、Ｍ
ＮのＣｏＡ（＝アドレスＢ）にダイレクトにそのパケッ
トを転送する。ただしこれはＩＰｖ６での通常の場合の
動作であり、本発明では、ルータＲ２が、ＣＮ１に代わ
って、Binding Updateの受信と、ＣｏＡ（＝アドレス
Ｂ）へのパケットの転送とを行う。

【００３９】＜Ｒ１，Ｒ３，Ｒ４＞通常のＩＰｖ６ルー
タである。 ＜Ｒ２＞通常のＩＰｖ６ルータの機能に加え、上述した
本発明の機能を有する移動端末対応ルータである。ここ
の例では、ＣＮ１と同様に、ＭＮとの認証情報であるＳ
Ａ２を保持しているものとする。

【００４０】次に図１１のシステムの動作概要を示す。 〔１〕：移動端末ＭＮは、ホームリンクであるネットワ
ーク１から、ネットワーク３へ移動したものとする。 〔２〕：ＭＮは、ネットワーク３において、ルータＲ３
がネットワーク３の内部にブロードキャストするRouter
Advertisementに含まれるネットワークプレフィクス
（どのネットワークであるかを示す固定のコード）の情
報を受信して、今自分（ＭＮ）がネットワーク１の外部
へ移動したことを認識すると共に、ＣｏＡ（ここではア
ドレスＢとする）を生成する。

【００４１】〔３〕：ＭＮは、ＨＡ２０へBinding Upda
teを送信し、ＣｏＡ（＝アドレスＢ）を現在アドレスと
して通知する。 〔４〕：ＨＡ２０は、その受信したBinding Updateに基
づき、ＭＮのホームアドレス（＝Ａ）とＣｏＡ（＝Ｂ）
等とを、Binding Cache として記憶する。そして、ＭＮ
に対して図示しないルートでBinding Acknowledgement
を返送する。

【００４２】〔５〕：ここでＣＮ１がＭＮへパケットを
送信するものとする。ＣＮ１は、ＭＮがネットワーク３
へ向かって移動中であることを未だ知らないため、パケ
ットはＭＮのホームアドレス（＝Ａ）宛てに送信され
る。このパケットはルータＲ１→Ｒ２を経由して、ＭＮ
のホームアドレス（＝Ａ）であるネットワーク１へ転送
される。このときＨＡ２０はそのパケットをインタセプ
トし、このパケットをＩＰ−ｉｎ−ＩＰカプセル化し
て、移動中のＭＮへ転送する。この時のパケットの内容
を図で示す。

【００４３】図１３は図１１中の〔５〕で転送されるパ
ケットのフォーマットを示す図である。ＣＮ１が送信し
たオリジナルのパケット（宛先アドレス＝Ａ、送信元ア
ドレス＝Ｅ）に加え、ＨＡにてもう一つのＩＰヘッダ
（宛先アドレス＝Ｂ、送信元アドレス＝Ｄ）が付加され
ている。これがＩＰ−ｉｎ−ＩＰカプセル化されたパケ
ットである。

【００４４】〔６〕：ＭＮは、ＨＡ２０からの上記ＩＰ
−ｉｎ−ＩＰカプセル化されたパケットを受信すると、
オリジナルのパケットの送信元であるＣＮ１に対してBi
nding Update（Ｂ．Ｕ．）を送信する。この時のパケッ
トの内容を図で示す。図１４は図１１中の〔６〕で転送
されるパケットのフォーマットを示す図である。

【００４５】Binding Update信号は、ＩＰｖ６ヘッダ
（宛先アドレス＝Ｅ、送信元アドレス＝Ｂ）に、Bindin
g Updateオプション（Binding Update Option ：文献
〔３〕）、Home Addressオプション（Home Address Opt
ion ：文献〔３〕）、および認証ヘッダ（Authenticati
on Header ：文献〔４〕）を付加した形のパケットとな
る。

【００４６】Binding Updateオプション、Home Address
オプションは、ＩＰｖ６拡張ヘッダ（IPv6 Extension H
eader ：文献〔２〕）の１つである宛先オプションヘッ
ダ（Destination Options Header. 文献〔２〕）として
定義されており、それぞれOption Type の値は、Bindin
g Updateオプション＝Ｃ６（１６進）、Home Addressオ
プション＝Ｃ９（１６進）である。

【００４７】以上の〔６〕までは、Ｍｏｂｉｌｅ−ＩＰ
ｖ６プロトコルに基づいた通常の動作である。 〔７〕：上記〔６〕にて、ＭＮからＣＮ１宛てに送信さ
れた図１４のBindingUpdate（Ｂ．Ｕ．）を、本発明に
係るルータ（Ｒ２）１０が受信する。Ｒ２では、受信し
たＢ．Ｕ．パケットの内容のチェックを行う。

【００４８】まず図１４に示すBinding Updateオプショ
ンが含まれていることを、Ｒ２の登録手段１３（図７）
で検出し、このパケットがＭｏｂｉｌｅ−ＩＰｖ６のBi
nding Update信号であると判断する。次に、図１４のＩ
Ｐｖ６ヘッダの宛先アドレスがＣＮ１のアドレス（＝
Ｅ）であることから、このBinding Update信号がＣＮ１
へ送信されたものであると判断する。

【００４９】さらに、ＣＮ１についての認証情報ＳＡ２
を使用して、図１４の認証ヘッダのチェックを行う。そ
して、その認証ヘッダのチェックが成功した場合には、
当該パケットに含まれる図１４のHome Addressオプショ
ンから得られる、ＭＮのホームアドレス（＝Ａ）と、Ｉ
Ｐｖ６ヘッダの送信元アドレスであるＭＮのＣｏＡ（＝
アドレスＢ）と、Binding Updateオプションに含まれる
有効時間等の情報とから、Binding Cache を生成し、こ
れをＲ２の記憶手段１１（図７）に記憶する。

【００５０】〔８〕：上記〔６〕のパケットに含まれる
Binding Updateオプションにおいて、Acknowledge ビッ
ト（いわゆるＡビット）がセットされている場合には、
Ｒ２は転送手段１２（図７）により、ＭＮへBinding Ac
knowledgement （Ｂ．Ａ．）を返送する。（もしそのAc
knowledge （Ａ）ビットがセットされていないならば、
Binding Acknowledgement を返送しなくても良い）。こ
の時のパケットの内容を図で示す。

【００５１】図１５は図１１中の〔８〕で転送されるパ
ケットのフォーマットを示す図である。Binding Acknow
ledgement （Ｂ．Ａ．）は、図１５に示すように、ＩＰ
ｖ６ヘッダ（宛先アドレス＝Ｂ、送信元アドレス＝Ｅ）
に、ルーティングヘッダ（Routing Header：文献
〔２〕）（宛先アドレス＝Ａ）、Binding Acknowledgem
ent オプション（Binding Acknowledgement Option：文
献〔３〕）および認証ヘッダを付加した形のパケットと
なる。

【００５２】Binding Acknowledgement オプションは、
ＩＰｖ６拡張ヘッダの１つである宛先オプションヘッダ
として定義されており、Option Type の値は、０７（１
６進）である。ルーティングヘッダは、宛先オプション
ヘッダと同様に、ＩＰｖ６拡張ヘッダの１つとして定義
されており、転送中のＩＰｖ６パケットの宛先アドレス
を定めるものである。

【００５３】以上述べたことを図７との関連で要約する
と、相手端末ＣＮがＩＰｖ６プロトコルをサポートする
端末ＣＮ１であるとき、図７の現在アドレスはCare-of
Address であり、また図７の更新通知情報はBinding Up
date信号である。これらをＣＮ１に代わって受信する。
このとき図７の転送手段１２は、移動端末ＭＮとの間で
定めた認証情報を保持すると共に、Binding Update信号
の送信元である移動端末ＭＮに対しこのBinding Update
信号の受信に対するBinding Acknowledgement 信号を返
送する。これらをＣＮ１に代わって実行する。

【００５４】次に前述の図１２を参照する。

〔９〕：ここでＣＮ１がＭＮ宛てのパケットを送信する
ものとする。このときＲ２は上記〔７〕にて、ＭＮから
ＣＮ１へのBinding Updateを受信し保持しているため、
ＣＮ１はＭＮがネットワーク３に移動していることを知
らない。したがってＣＮ１は通常通りＭＮのホームアド
レス（＝Ａ）を宛先としてそのパケットを送信する。

【００５５】〔１０〕：上記

〔９〕にて送信されたパケ
ットをＲ２が受信すると、Ｒ２の転送手段１２（図７）
は、宛先アドレスのチェックを行う。すなわち、記憶手
段１１（図７）を参照して、宛先アドレスであるＭＮの
ホームアドレス（＝Ａ）についてのBinding Cache が存
在し、かつ有効時間内である場合には、Ｒ２は、受信し
たそのパケットをＭＮのホームアドレス（＝Ａ）ではな
く、ＣｏＡ（＝アドレスＢ）へ転送する。Ｒ２がＭＮの
ＣｏＡ（＝アドレスＢ）へ転送するパケットの形態に
は、次の（Ｉ）および（II）がある。

【００５６】（Ｉ）ＩＰｖ6 拡張ヘッダの１つであるル
ーティングヘッダを使用する。 （II）ＩＰ−ｉｎ−ＩＰカプセル化を行う。 また、ＣＮ１が送信したパケットに認証ヘッダが含まれ
ているかどうかにより、以下の１）および２）のような
処理を行うことができる。 １）ルーティングヘッダを使用する場合 この場合の説明のために、図１２の他に、図１６〜図１
９も参照する。

【００５７】図１６は図１２中の

〔９〕で転送されるパ
ケット（第１例）のフォーマットを示す図であり、図１
７は図１２中の〔１０〕で転送されるパケット（第１
例）のフォーマットを示す図であり、図１８は図１２中
の

〔９〕で転送されるパケット（第２例）のフォーマッ
トを示す図であり、図１９は図１２中の〔１０〕で転送
されるパケット（第２例）のフォーマットを示す図であ
る。

【００５８】さらに詳しくは、図１６は認証ヘッダが無
い場合のパケット、図１８は認証ヘッダが有る場合のパ
ケット、図１７はＩＰｖ６ルーティングヘッダを用いる
場合で、かつ、認証ヘッダが無い場合のパケット、図１
９はＩＰｖ６ルーティングヘッダを用いる場合で、か
つ、認証ヘッダが有る場合のパケット、である。

【００５９】図１２および図１６〜図１９を参照する
と、 １−ａ）ＣＮ１が送信したパケットが、図１６のよう
に、認証ヘッダを含んでいない場合には、Ｒ２の転送手
段１２（図７）からＭＮのＣｏＡ（＝アドレスＢ）への
転送パケットは、図１７のようになる。図１７のパケッ
トはＩＰｖ６ヘッダ（宛先アドレス＝Ｂ、送信元アドレ
ス＝Ｅ）に、ルーティングヘッダ（宛先アドレス＝Ａ）
を付加した形のパケットとなる。

【００６０】１−ｂ）ＣＮ１が送信したパケットが、図
１８のように認証ヘッダを含んでいる場合には、Ｒ２の
転送手段１２（図７）からＭＮのＣｏＡ（＝アドレス
Ｂ）への転送パケットは、図１９のようになる。つま
り、ＩＰｖ６ヘッダ（宛先アドレス＝Ｂ、送信元アドレ
ス＝Ｅ）に、ルーティングヘッダ（宛先アドレス＝Ａ）
と認証ヘッダを付加した形のパケットとなる。

【００６１】ここでその認証ヘッダは、図１８に含まれ
ていたものをそのまま付加するのではなく、ＣＮ１とＭ
Ｎとの間の認証情報ＳＡ２を使用して、Ｒ２が再計算し
たものを付加する。この理由は次のとおりである。認証
ヘッダにおける認証データの計算には通常ＩＰパケット
の内容そのものを使用している。このため、図１８のパ
ケットの内容を使用して計算した認証データは、図１９
のようにＲ２によってパケットの内容が変更された場合
の認証データとは異なったものとなり、認証が確立しな
いから、受信端末であるＭＮにおいて、〔１０〕のパケ
ットが廃棄されてしまう。このため、図１９の変更され
たパケットの内容を用いて、Ｒ２が改めて認証データの
計算（再計算）をし直す必要がある。これが図１９にお
ける、認証ヘッダ（再計算）の意味である。

【００６２】２）ＩＰ−ｉｎ−ＩＰカプセル化を行う場
合 この場合の説明のために、図１２の他に、図２０および
図２１も参照する。図２０は図１２中の〔１０〕で転送
されるパケット（第３例）で認証ヘッダ無しのときのフ
ォーマットを示す図であり、図２１は図２０のパケット
（第３例）で認証ヘッダ有りのときのフォーマットを示
す図である。

【００６３】さらに詳しくは、図２０はＩＰ−ｉｎ−Ｉ
Ｐカプセル化を行い、かつ、認証ヘッダが無い場合のパ
ケット、図２１はＩＰ−ｉｎ−ＩＰカプセル化を行い、
かつ、認証ヘッダが有る場合のパケット、である。

【００６４】図１２ならびに図２０および図２１を参照
すると、 ２−ａ）ＣＮ１が送信したパケットが、前述した図１６
のように認証ヘッダを含んでいない場合には、Ｒ２の転
送手段１２（図７）からＭＮのＣｏＡ（＝アドレスＢ）
への転送パケットは、図２０のようになる。図２０のパ
ケットは、図１６のパケットそのものに、転送手段１２
により、新たにＩＰｖ６ヘッダ（宛先アドレス＝Ｂ、送
信元アドレス＝Ｅ）を付加した形のパケットとなる。

【００６５】２−ｂ）ＣＮ１が送信したパケットが、図
１８のように認証ヘッダを含んでいる場合には、Ｒ２の
転送手段１２から、ＭＮのＣｏＡ（＝アドレスＢ）への
転送パケットは、図２１のようになる。図２１のパケッ
トは、上記の２−ａ）の場合と同様に、図１８のパケッ
トそのものに、転送手段１２により、新たにＩＰｖ６ヘ
ッダ（宛先アドレス＝Ｂ、送信元アドレス＝Ｅ）を付加
した形のパケットとなる。この場合、上記の１−ｂ）で
行ったような認証ヘッダにおける認証データの再計算
（図１９）は不要である。Ｒ２によるパケットの内容の
変更はないからである。

【００６６】ここで、Ｒ２により新たに付加したＩＰｖ
６ヘッダの送信元アドレスを、オリジナルパケット

〔９〕の送信元であるＣＮ１のアドレス（＝Ｅ）にして
いる理由を以下に述べる。Ｍｏｂｉｌｅ−ＩＰｖ６プロ
トコルでは、ＭＮがＩＰ−ｉｎ−ＩＰカプセル化された
パケットを受信した際に、そのパケットに対していくつ
かの適合性判定を行い、適合した場合には、ＩＰ−ｉｎ
−ＩＰカプセル化されたオリジナルパケットの送信元へ
Binding Update（Ｂ．Ｕ．）を送信することが定義され
ている。通常は、まだＭＮのＣｏＡを知らないＣＮ１か
ら、ＭＮのホームアドレス（＝Ａ）へ送信されたパケッ
トをＨＡがインタセプトしてＩＰ−ｉｎ−ＩＰカプセル
化し、ＭＮに転送する。このカプセル化パケットを受信
したＭＮがＣＮへBinding Updateを送信する。これは上
記の定義に基づいた動作である。

【００６７】この定義に基づくと、図１２中の〔１０〕
のように、Ｒ２からＭＮへのパケットを転送する際、上
記の２−ａ）および２−ｂ）に示すように、ＩＰ−ｉｎ
−ＩＰカプセル化したパケットを用いると、このＩＰ−
ｉｎ−ＩＰカプセル化パケットを受信する度に、ＭＮか
らＣＮ１へのBinding Updateが送信されることになる。
そうすると、特にパケットが連続して送信されたような
場合には、Binding Updateも同様に連続して送信されて
しまう。この問題は、上記のＭＮにおけるＩＰ−ｉｎ−
ＩＰカプセル化パケットの受信の際に行われる適合性判
定において、不適合となるようなパケットに意図的にす
ることで解決できる。

【００６８】すなわち、ＭＮの適合性判定の条件の１つ
として、「オリジナルパケットのＩＰｖ６ヘッダの送信
元アドレスと、ＩＰ−ｉｎ−ＩＰカプセル化ＩＰｖ６ヘ
ッダの送信元アドレスとが異なっていること」という条
件がある（文献〔３〕10.8.Sending Binding Updates t
o Correspondent Nodes参照）。このことを逆に利用し
て、Ｒ２からＭＮへパケットを送信する際にＩＰ−ｉｎ
−ＩＰカプセル化パケットを使用する場合に、図２１に
示すように、ＩＰ−ｉｎ−ＩＰカプセル化パケットのヘ
ッダにおける送信元アドレスを、意図的にオリジナルパ
ケットの送信元アドレスと同じＣＮ１のアドレス（＝
Ｅ）にしてしまう。ＭＮにおいて適合性判定の条件を満
たさなくなるから、上記のようにBinding Updateを連続
して送信するという問題はなくなる。ただし、一番最初
のパケットだけについては、Ｒ２の登録手段１３（図
７）を起動するために、そのBinding UpdateをＲ２に送
信しなければならない。このための対策は種々考えられ
るが、その１つを図３９も参照しながら後に説明する。

【００６９】以上述べたことを図７との関連で要約する
と、転送手段１２は、相手端末ＣＮからのパケットを移
動端末ＭＮに転送するに際し、このパケット内に、ホー
ムアドレス（＝Ａ）を記述したＩＰｖ６ルーティングヘ
ッダ（図１７、図１９）を形成するようにする。また、
転送手段１２は、相手端末ＣＮからのパケットを移動端
末ＭＮに転送するに際し、現在アドレス（ＣｏＡ）を含
むＩＰｖ６ヘッダによりこのパケットをＩＰ−ｉｎ−Ｉ
Ｐカプセル化して（図２０、図２１）、転送するように
する。

【００７０】図２２は図９および図１０のシステムの第
２の詳細例を示す図である。前述の第１の詳細例（図１
１および図１２）は、本発明に係る移動端末対応ルータ
（Ｒ２）１０に重点を置いたものであるが、第２の詳細
例（図２２）は、本発明に係るホームエージェント・ル
ータ（ＨＡ）２０に重点を置く。まず前提として、図２
２に示されるホームエージェント・ルータ（ＨＡ）２０
およびＲ２と端末（ＭＮ，ＣＮ２）とについての説明を
以下に示す。

【００７１】＜ＭＮ＞第１の詳細例（図１１、図１２）
と同じ。ただし、ＭＮとＣＮ２はこれらの間の認証情報
（前述のＳＡ２相当）を保持していない。＜ＨＡ２０＞
第１の詳細例に示す通常のＭｏｂｉｌｅ−ＩＰｖ６ Ｈ
Ａ機能に加え、本発明に基づく機能を有するホームエー
ジェント・ルータである。ここの例ではＲ２との認証情
報ＳＡ３を保持しているものとする。

【００７２】＜ＣＮ２＞ＭＮと通信を行う相手端末であ
るが、Ｍｏｂｉｌｅ−ＩＰｖ６プロトコルをサポートし
ていない。ここの例では、ＣＮ２のアドレスをＦとす
る。ＭＮ宛てにパケットを送信する際は、常に宛先アド
レスをＭＮのホームアドレス（＝Ａ）として通常のパケ
ットの転送を行う。

【００７３】＜Ｒ１，Ｒ３，Ｒ４＞通常のＩＰｖ６ルー
タである。 ＜Ｒ２＞通常のＩＰｖ６ルータの機能に加え、前述した
本発明に基づく機能を有するルータである。ここの例で
は、Ｒ２のアドレスをＧとする。またＲ２は、第１の詳
細例に示したＣＮ１との認証情報ＳＡ２は保持しておら
ず、ＨＡ２０との間の認証情報ＳＡ３を保持しているも
のとする。

【００７４】次に図２２のシステムの動作概要を示す。 〔１〕〜〔４〕：第１の詳細例（図１１）の〔１〕〜
〔４〕と同じである。 〔５〕：ＣＮ２はＭＮへ向けてパケットを送信する。こ
こではＣＮ２はＭｏｂｉｌｅ−ＩＰｖ６をサポートして
いないため、そのパケットは常にＭＮのホームアドレス
（＝Ａ）宛てに送信される。

【００７５】以上の〔５〕までは、ＩＰｖ６およびＭｏ
ｂｉｌｅ−ＩＰｖ６プロトコルに基づいた通常の動作で
ある。 〔６〕：上記〔５〕にて送信されたパケットをＲ２が受
信すると、Ｒ２の登録手段１３（図１７）は、この受信
したパケットの宛先アドレス（＝Ａ）をチェックする。

【００７６】ここで宛先アドレス（＝Ａ）についてのBi
nding Cache を記憶していない場合には、Ｒ２はパケッ
トをＩＰ−ｉｎ−ＩＰカプセル化してＨＡへ転送する。
この時のパケットの内容を図で示す。図２３は図２２中
の〔６〕で転送されるパケットのフォーマットを示す図
である。

【００７７】このパケット〔６〕は、ＣＮ２が送信した
パケットに、新たにもう１つのＩＰｖ６パケットヘッダ
（宛先アドレス＝Ａ、送信元であるＲ２のアドレス＝
Ｇ）を付加した形のパケットとなる。 〔７〕：上記〔６〕にて、Ｒ２から転送されたパケット
をＨＡ２０が受信する。このＨＡでは登録手段２３（図
８）にて、その受信したパケットのチェックを行う。す
なわちＨＡはまずＩＰ−ｉｎ−ＩＰカプセル化されてい
るパケットであることを検出する。

【００７８】次に、上記〔６〕にて付加された、図２３
に示す外側のＩＰｖ６パケットヘッダの内側にあるオリ
ジナルパケット（上記〔５〕にてＣＮ２から送信された
パケット）のチェックを行い、宛先となるＭＮのホーム
アドレス（＝Ａ）を検出する。次に、ＨＡ２０は登録手
段２３にて、ＭＮについてのBinding Cache の存在およ
び有効時間をチェックする。このチェックによりＭＮに
ついてのBinding Cache が存在し、かつそれが有効時間
内であると判定された場合には、ＨＡはこのオリジナル
パケットを、ＭＮのＣｏＡ（＝アドレスＢ）宛てに再カ
プセル化して転送する。この時のパケットの内容を図で
示す。

【００７９】図２４は図２２中の〔７〕で転送されるパ
ケットのフォーマットを示す図である。ＣＮ２が送信し
たオリジナルのパケット〔５〕（宛先アドレス＝Ａ、送
信元アドレス＝Ｆ）に加え、もう１つのＩＰｖ６ヘッダ
（宛先アドレス＝Ｂ、送信元のＨＡのアドレス＝Ｄ）
が、ＨＡにより付加される。

【００８０】〔８〕：さらにＨＡ２０は、上記〔６〕に
て受信した図２３に示すパケットの外側のＩＰｖ６パケ
ットヘッダに含まれる送信元アドレス（Ｇ）をチェック
し、このＩＰ−ｉｎ−ＩＰカプセル化パケットの送信元
（＝アドレスＧ）であるＲ２に対して、アドレス更新通
知手段２２（図８）により、ＭＮのＣｏＡ（＝アドレス
Ｂ）を通知する。

【００８１】この通知はＭｏｂｉｌｅ−ＩＰｖ６プロト
コルとは独立した手順であるから、どのような手法でＣ
ｏＡをＲ２に通知しても良い。ここの例ではＭｏｂｉｌ
ｅ−ＩＰｖ６のBinding Updateを利用して通知すること
とする。この時のパケットの内容を図で示す。図２５は
図２２中の〔８〕で転送されるパケットのフォーマット
を示す図である。すなわち、ＨＡ２０からＲ２へＣｏＡ
を通知するパケットの内容を示す。

【００８２】本図に示すように、この通知パケットは、
ＩＰｖ６ヘッダ（宛先アドレス＝Ｇ、送信元アドレス＝
Ｄ）に、Binding Updateオプション、Home Addressオプ
ション、認証ヘッダ、およびＣｏＡオプションを付加し
た形のパケットとなる。Binding Updateオプション、Ho
me Addressオプション、認証ヘッダは、第１の詳細例
（図１１）の〔６〕で示したものと同様に、Ｍｏｂｉｌ
ｅ−ＩＰｖ６およびＩＰＳＥＣで定義されているもので
ある。

【００８３】上記認証ヘッダに含まれる認証データは、
ＨＡ２０とＲ２との間の認証情報ＳＡ３と本パケットの
内容とを使用して計算により算出される。またＣｏＡオ
プションは、Ｍｏｂｉｌｅ−ＩＰｖ６で定義されていな
いため、新規オプションとして定義することができる。
この新規オプションの内容を図で示す。

【００８４】図２６は図２５におけるＣｏＡオプション
のフォーマットの一例を示す図である。本図において、
ＣｏＡオプションはBinding Updateオプションと同様
に、ＩＰｖ６拡張ヘッダの１つである宛先オプションヘ
ッダとして、ＩＰｖ６ヘッダ（図２５）の宛先アドレス
で示された受信側端末（ここではルータＲ２）の登録手
段１３（図７）によって処理される。

【００８５】図２６のフォーマット例において、Option
Type （８ビット）には、このオプションがＣｏＡアド
レスであることを示す数値が入る。Option Length （８
ビット）には、本オプションの長さ（Option Type およ
びOption Length を除く）を８オクテット単位で示した
数値が入る。Care-of Address （１２８ビット）には、
通知すべきＭＮのＣｏＡ（ここではアドレスＢ）が入
る。

【００８６】

〔９〕：図２２に戻ると、上記〔８〕に
て、ＨＡ２０から送信されたＣｏＡ通知パケットをＲ２
が受信手段１３（図７）で受信する。Ｒ２では、受信し
たパケットの内容のチェックを登録手段１３（図７）に
て行う。まずBinding Updateオプションが含まれている
ことを検出すると、このパケットがＣｏＡ通知パケット
であると判断する。

【００８７】次に、ＩＰｖ６ヘッダ（図２５）の宛先ア
ドレスが自分のアドレス（＝Ｇ）であり、送信元アドレ
スがＨＡのアドレス（Ｄ）であって、このパケットがＨ
Ａから自分自身（Ｒ２）へ送信されたものであると判断
する。次に、ＨＡとの間の認証情報ＳＡ３に基づき、認
証ヘッダ（図２５）のチェックを行う。そして、この認
証ヘッダのチェックに成功した場合には、該パケットに
含まれるHome Addressオプション（図２５）から得られ
るＭＮのホームアドレス（＝Ａ）と、ＣｏＡオプション
から得られるＭＮのＣｏＡ（＝アドレスＢ）と、Bindin
g Updateオプションに含まれる有効時間等の情報を、Bi
nding Cache として、記憶手段１１（図７）に記憶す
る。

【００８８】ここではＣｏＡオプション（図２５、図２
６）が含まれるため、ＩＰｖ６ヘッダの送信元アドレス
（＝Ｄ）からＭＮのＣｏＡを得るのではなく、ＣｏＡオ
プション（＝アドレスＢ）からＣｏＡを得ることにな
る。このＣｏＡオプションに隣接する図２５の認証ヘッ
ダの計算は、送信・受信側それぞれにおいて、パケット
の送信元アドレス（Ｍｏｂｉｌｅ ＩＰｖ６メッセージ
ではHome Addressオプションに格納されたアドレス）と
その送信元との間で確立しているＳＡを使用して行う。
ＨＡからＲ２へＭＮのＣｏＡを通知する場合、通常のＭ
ｏｂｉｌｅ−ＩＰｖ６のＢ．Ｕ．メッセージフォーマッ
トに基づいたパケット、例えば〔Ｆ〕〔Ｂ〕〔Ｂ．
Ｕ．〕〔Ａ〕〔認証〕、で通知しようとしても、もとも
とＣＮ−ＭＮについてのＳＡが無いため、ＨＡは認証ヘ
ッダを計算して付与することができない。

【００８９】そこで、図２５のような形のパケットに
し、ＨＡとＲ２の間でＳＡ３を確立しておくことで、Ｈ
ＡとＲ２との間で認証ヘッダを計算し、ＨＡとＲ２にお
いて通知パケットをチェックすることが可能となる。以
上の動作により、Ｒ２においてＭＮについてのBinding
Cache が生成され、以降ＣＮ２からＭＮへ送信されるパ
ケットは、第１の詳細例（図１２）の〔１０〕と同様
に、ＨＡを経由せずに、ＣＮ２→Ｒ１→Ｒ２→Ｒ３→Ｍ
Ｎの経路で転送される。

【００９０】この第２の詳細例（図２２）では、ＣＮ２
はＭＮについての認証情報を保持していないとしている
ので、ＣＮ２からＭＮへ送信されるパケットに認証ヘッ
ダが含まれることはない。この場合、パケットは、第１
の詳細例における上記〔１０〕に示す１−ａ）または２
−ａ）の方法で転送される。もし、ＣＮ２がＭＮについ
ての認証情報を保持していると仮定すると、ＣＮ２から
ＭＮへ送信されるパケットに認証ヘッダが含まれること
になる。このように認証ヘッダが含まれる場合は、その
パケットは、第１の詳細例における上記〔１０〕に示す
１−ｂ）または２−ｂ）の方法で転送されることにな
る。

【００９１】また第１の詳細例における上記〔６〕と同
様に、ＭＮからＣＮ２へBinding Updateが送信されるこ
とになる。この場合は、第１の詳細例における上記
〔７〕〜〔１０〕と同様に、Ｒ２がＣＮ２宛てのBindin
g Updateを受信して、Ｒ２からＭＮのＣｏＡにダイレク
トにパケットを転送することになる。以上述べたことの
ポイントを図８との関連で要約すると、ホームエージェ
ント・ルータ（ＨＡ）と連係する他のルータ（Ｒ２）
が、ＩＰｖ６プロトコルをサポートする移動端末端末Ｍ
Ｎと通信可能な移動体端末対応ルータであるとき、アド
レス更新通知手段２２（図８）は、現在アドレスを示す
Care-of Address （ＣｏＡ）を、ＩＰｖ６拡張ヘッダの
１つである宛先オプション（図２５、図２６）としてそ
の移動体端末対応ルータ（Ｒ２）に通知するようにす
る。

【００９２】そしてこの移動体端末対応ルータ（Ｒ２）
に通知されるパケット〔８〕（図２２）内には認証ヘッ
ダ（図２５）を含み、この認証ヘッダ内の認証データ
は、ホームエージェント・ルータ（ＨＡ）と該移動体端
末対応ルータ（Ｒ２）との間で定めた認証情報ＳＡ３と
当該パケットの内容とを用いた計算による算出結果から
なるようにしている。

【００９３】最後に、本発明に係る移動端末対応ルータ
（Ｒ２）１０およびホームエージェント・ルータ（Ｈ
Ａ）２０の詳細例について補足説明する。図７および図
８に示すこれらのルータ（Ｒ２）１０および（ＨＡ）２
０は、実際にはソフトウェアによって実現可能である
が、これを機能ブロックで構成した場合について以下に
説明する。

【００９４】まず、説明の都合上、前述したシステムの
第１の詳細例（図１１、図１２）と第２の詳細例（図２
２）とを１つに統合して表現し直す。図２７は図１１，
１２および２２で示すシステムを１つに統合して表す図
である。本図において、ＭＮ１（ホームアドレス＝Ａ
１）は図１１、図１２のＭＮに相当し、ＭＮ２（ホーム
アドレス＝Ａ２）は、図２２のＭＮに相当する。このた
め、ホームアドレスやセキュリティ情報も再度定義し直
している。後述する説明に現れるテーブルの内容（図２
９、図３０）や、パケットおよび処理ルートは、全て図
２７に示す設定値に準じている。

【００９５】図２７において、ＭＮ１とＣＮはセキュリ
ティ情報ＳＡ１２を確立しているため、ＭＮ１は移動時
にＨＡへのＢ．Ｕ．１１以外にＣＮへのＢ．Ｕ．１２も
送信する。なおＢ．Ｕ．１２は、ＣＮの代わりにＲ２が
受信し、Ｒ２からＭＮ１へＢ．Ａ．１２を送信する。ま
た、ＭＮ２とＣＮはセキュリティ情報を確立していない
ため、ＭＮ２は移動時にＨＡへのＢ．Ｕ．２１のみ送信
する。

【００９６】さらに、ＨＡとＲ２はセキュリティ情報Ｓ
Ａ３を確立しており、ＨＡはＲ２へＭＮ２のＣｏＡ通知
であるＢ．Ｕ．３を送信する。なお、ＣＮのＳＡ１２
は、Ｒ２が代わりに持っているので、ＣＮは持たなくて
も良い。図２８は本発明に係るルータ（１０，２０）の
機能ブロックを表す図である。

【００９７】本図に示すとおり、ルータ（Ｒ２）１０も
ルータ（ＨＡ）２０も実質的に同一の機能ブロックで表
すことができる。ただし、テーブルの内容が、ルータ１
０とルータ２０とで相違する（後述）。また、パケット
の上りの処理と下りの処理は共通である。モバイルテー
ブル３１は、ＭＮのＣｏＡの記憶や最適化ルートでパケ
ットを転送するために必要な情報を格納したテーブルで
ある。なお、このテーブルの内容例は図２９および図３
０に示す。

【００９８】ルーティングテーブル３２は、通常のルー
タが持つルーティングテーブルと同様であり、パケット
のルーティング決定を行う際に参照する情報を格納した
テーブルである。なお、このテーブルの内容例は図３１
および図３２に示す。プロトコル処理部手段３３は、図
示するとおり、Ｍｏｂｉｌｅ−ＩＰｖ６処理部３３１
と、ルーティング処理部３３２と、ルーティングプロト
コル処理部３３３と、その他のプロトコル処理部３３４
と、を含んでなり、プロトコル（Ｍｏｂｉｌｅ ＩＰｖ
６，ＩＣＭＰ等）に応じてパケットの内容を理解し、こ
の理解に基づいてメッセージの処理を行う。

【００９９】パケット処理部３４は、パケット種別の判
定を行い、プロトコル処理手段３３へプロトコル処理を
引き渡す。またプロトコル処理手段３３からの指示に基
づきパケットの修正・生成、及び送信部への入力を行
う。受信部３５は、ネットワークをなす伝送路からの信
号を受信し、フレームの組み立てや、データの正常性の
チェック等を行う。

【０１００】送信部３６は、パケット処理部３４からの
送出パケットを伝送フレームに載せて上記伝送路に送出
する。図２９はルータ（Ｒ２）１０についてのモバイル
テーブルの内容の一例を示す図である。図２８のモバイ
ルテーブル３１は、ルータ（Ｒ２）１０についてはこの
ような内容を記憶する。

【０１０１】なお、ＭＮのＣｏＡは有効時間が切れると
消去される。また、実際には１つのＣＮについて複数の
ＭＮについての情報が記憶されていてもよい。モバイル
テーブル−ＭＮ情報について見ると、この情報は、ＨＡ
から通知されてキャッシュされる。そして有効時間が切
れると、ＭＮホームアドレス、ＣｏＡ、有効時間の全て
のエントリが消去される。

【０１０２】図３０はルータ（ＨＡ）２０についてのモ
バイルテーブルの内容の一例を示す図である。図２８の
モバイルテーブル３１は、ルータ（ＨＡ）２０について
はこのような内容を記憶する。モバイルテーブル−ＭＮ
情報は、ＭＮの各ＣｏＡについての有効時間が切れると
消去される。

【０１０３】図３１はルータ（Ｒ２）１０についてのル
ーティングテーブルの内容の一例を示す図である。図２
８のルーティングテーブル３２は、ルータ（Ｒ２）１０
についてはこのような内容を記憶する。図３２はルータ
（ＨＡ）２０についてのルーティングテーブルの内容の
一例を示す図である。

【０１０４】図２８のルーティングテーブルは、ルータ
（ＨＡ）２０についてはこのような内容を記憶する。図
３３はルータ（Ｒ２）としてのパケット処理部３４（図
２８）の処理を示すフローチャート（その１）であり、
図３４は同フローチャート（その２）である。

【０１０５】図３５は図３３および図３４のフローチャ
ート上における各パケット（Ｐ１〜Ｐ４）の流れを示す
図であり、図３６は図３５における各パケット（Ｐ１〜
Ｐ４）のフォーマットを示す図である。図３３について
説明を付け加えると、ステップＳ１９の「判定１」は、
前の判定で一致したＣＮアドレスについて、ＣＮ情報の
ＭＮホームアドレスと受信パケットの宛先アドレスが一
致するか否か、の判定を行う。

【０１０６】また図３５について説明を付け加えると、
ルート４１において、ＭＮ１のＣｏＡ無しのとき、受信
パケットをそのままＨＡへ送信する。そしてＨＡは、図
３９に示すパケットＰ５の処理を行う。また図３５のル
ート４２において、ＭＮ２のＣｏＡ無しのとき、受信パ
ケットをカプセル化してＨＡへ送信し、ＨＡは図３９に
示すパケットＰ６の処理を行う。

【０１０７】図３７はルータ（ＨＡ）としてのパケット
処理部３４（図２８）の処理を示すフローチャート（そ
の１）であり、図３８は同フローチャート（その２）で
ある。図３９は図３７および図３８のフローチャート上
における各パケット（Ｐ５〜Ｐ８）の流れを示す図であ
り、図４０は図３９における各パケット（Ｐ５〜Ｐ８）
のフォーマットを示す図である。

【０１０８】図３７について説明を付け加えると、ステ
ップＳ３９の「判定２」は、送信元アドレスが通知先ル
ータ情報のルータアドレスと一致するか否か、かつ、カ
プセル化ヘッダ（外側）の宛先アドレスとオリジナルヘ
ッダ（内側）の宛先アドレスとが一致するか否か、の判
定を行う。また図３９について説明を付け加えると、ル
ート４３において、ＨＡがＭＮ１のＣｏＡ宛てにカプセ
ル化して転送したパケットをＭＮ１が受信すると、ＭＮ
１はＣＮへＢ．Ｕ１２を送信する。

【０１０９】そしてルート４４においては、ＨＡは図３
５のＰ２のパケットをＭＮ２のＣｏＡへ転送するととも
に、図３５のＰ４のパケットをＲ２へ送信する。さらに
ルート４５においては、ＨＡはＭＮ１およびＭＮ２から
のＢ．Ｕ．を受信し、Ｂ．Ａ．を返信する。これは通常
の登録動作である。以上がルータ１０および２０につい
ての詳細な説明であるが、その中の２−ｂ）の終わり
に、「ＭＮにおいて適合性判定の条件を満たさなくなる
と、BindingUpdateを連続して送信するという問題はな
くなる」としている。ただし、一番最初のパケットだけ
については、登録手段１３（図１７）を起動するため
に、そのBinding UpdateをＲ２に送信する対策を講じな
ければならない。これについては図３９も参照しながら
後述する、としたので、ここで説明する。

【０１１０】ＣＮからＭＮへの１回目のパケットは、Ｒ
２にてＣｏＡが記憶されていないため、図３９のＰ５ま
たはＰ６のパケットの形でＭＮのホームアドレスへ送信
される。そしてＨＡがこのパケットを受信し、これを図
１３のようにカプセル化して、ＨＡからＭＮへ送信す
る。この時、カプセル化したパケットの外側ヘッダの送
信元アドレスはＨＡのアドレスであり、図２０や図２１
に示すパケットのように、Ｒ２がパケットをＩＰ−ｉｎ
−ＩＰカプセル化する場合と異なる。ＭＮが前述のＭＮ
１、すなわちＣＮとのセキュリティ情報を持つＭＮの場
合、ＨＡ経由のカプセル化パケットを受信した際には、
２−ｂ）で記述した適合性判定の条件を満たすため、Ｃ
ＮへＢ．Ｕ．を送信することができる。

【０１１１】以上述べた本発明の実施の態様は、以下の
付記のとおりである。 （付記１）少なくとも移動端末のパケット通信をサポー
トするネットワークを構成する移動端末対応ルータであ
って、前記パケット通信の相手端末が記憶すべき前記移
動端末の現在アドレスを、該相手端末に代わって、記憶
する記憶手段と、前記相手端末から前記移動端末のホー
ムアドレス宛てに送信されたパケットを受信したとき、
前記記憶手段を参照し、該ホームアドレス宛てを前記現
在アドレス宛てに変換して該パケットを送信する転送手
段と、を具備することを特徴とする移動端末対応ルー
タ。 （付記２）前記移動端末の移動により前記現在アドレス
を変更したことに伴い前記通信の相手端末に対し当該ア
ドレスの更新を通知するために送信される更新通知情報
を受信したとき、この受信をトリガとして、前記記憶手
段における前記ホームアドレスと前記現在アドレスとの
対応関係を新たに登録する登録手段を有することを特徴
とする付記１に記載の移動端末対応ルータ。 （付記３）前記ネットワークは、前記移動端末をこのホ
ームアドレスにおいて収容するホームエージェント・ル
ータを含み、前記移動端末の移動により前記現在アドレ
スを変更したことに伴い該ホームエージェント・ルータ
に対し当該アドレスの更新を通知するために送信される
更新通知情報を受信したときに該ホームエージェント・
ルータからの当該更新アドレスの転送をトリガとして、
前記記憶手段における前記ホームアドレスと前記現在ア
ドレスとの対応関係を新たに登録する登録手段を有する
ことを特徴とする付記１に記載の移動端末対応ルータ。 （付記４）少なくとも移動端末の通信をサポートするネ
ットワークを構成するホームエージェント・ルータであ
って、前記移動端末の移動により前記現在アドレスを変
更したことに伴い前記ホームエージェント・ルータに対
し当該アドレスの更新を通知するために送信される更新
通知情報を受信する受信手段と、該更新通知情報を受信
したときに、その更新後の前記現在アドレスを、前記ネ
ットワークを構成する他のルータに送信するアドレス更
新通知手段、を具備することを特徴とするホームエージ
ェント・ルータ。 （付記５）前記相手端末がIPv6プロトコルをサポートす
る端末であるとき、前記現在アドレスはCare-of Addres
s であり、前記更新通知情報はBinding Update信号であ
ることを特徴とする付記２に記載の移動端末対応ルー
タ。

【０１１２】（付記６）前記転送手段は、前記移動端末
との間で定めた認証情報を保持すると共に、前記Bindin
g Update信号の送信元である該移動端末に対し該Bindin
g Update信号の受信に対するBinding Acknowledgement
信号を返送することを特徴とする付記５に記載の移動端
末対応ルータ。 （付記７）前記転送手段は、前記相手端末からの前記パ
ケットを前記移動端末に転送するに際し、該パケット内
に、前記ホームアドレスを記述したIPv6ルーティングヘ
ッダを形成することを特徴とする付記５に記載の移動端
末対応ルータ。

【０１１３】（付記８）前記転送手段は、前記相手端末
からの前記パケットを前記移動端末に転送するに際し、
前記現在アドレスを含むIPv6ヘッダにより該パケットを
IP-in-IPカプセル化して転送することを特徴とする付記
５に記載の移動端末対応ルータ。 （付記９）前記他のルータが、IPv6プロトコルをサポー
トする移動端末端末と通信可能な移動体端末対応ルータ
であって、前記アドレス更新通知手段は、前記現在アド
レスを示すCare-of Address を、IPv6拡張ヘッダの１つ
である宛先オプションとして該移動体端末対応ルータに
通知することを特徴とする付記４に記載のホームエージ
ェント・ルータ。

【０１１４】（付記１０）前記移動体端末対応ルータに
通知されるパケット内には認証ヘッダを含み、該認証ヘ
ッダ内の認証データは、前記ホームエージェント・ルー
タと該移動体端末対応ルータとの間で定めた認証情報と
当該パケットの内容とを用いた計算による結果からなる
ことを特徴とする付記９に記載のホームエージェント・
ルータ。

【０１１５】また本明細書中に掲げた諸文献のＵＲＬ
は、次のとおりである。 文献〔１〕（Mobile IP ） http://www.ietf.org/rfc/
rfc2002.txt 文献〔２〕（IPv6） http://www.ietf.org/rfc/
rfc2460.txt 文献〔３〕（Mobile IPv6 ）http://www.ietf.org/inte
rnet-drafts/draft-ietf-mobileip-ipv6-12.txt 文献〔４〕（認証ヘッダ） http://www.ietf.org/rfc/
rfc2402.txt

【０１１６】

【発明の効果】以上詳しく述べたように本発明により、
移動端末ＭＮの移動に伴うＣｏＡ更新に要する時間を短
縮可能とし、パケット転送ルートの切替えが高速化され
る。またＭｏｂｉｌｅ−ＩＰｖ６をサポートしていない
相手端末ＣＮからＭＮへのパケット転送ルートを、ホー
ムエージェントＨＡを経由することなく、最適化するこ
とができる。

【０１１７】以上により、通信品質の劣化の原因となる
パケット転送遅延やパケット損失（ロス）の増大を防ぐ
ことが可能となる。

【図面の簡単な説明】

【図１】本発明に係る移動端末対応ルータの基本構成を
示す図である。

【図２】本発明に係るホームエージェント・ルータの基
本構成を示す図である。

【図３】従来のパケット通信システムを表す図（その
１）である。

【図４】従来のパケット通信システムを表す図（その
２）である。

【図５】従来の他のパケット通信システムを表す図（そ
の１）である。

【図６】従来の他のパケット通信システムを表す図（そ
の２）である。

【図７】本発明に基づく移動端末対応ルータ１０のさら
に具体的な構成を示す図である。

【図８】本発明に基づくホームエージェント・ルータ２
０のさらに具体的な構成を示す図である。

【図９】本発明に基づくルータ１０および２０を含むパ
ケット通信システムの具体例を示す図（その１）であ
る。

【図１０】本発明に基づくルータ１０および２０を含む
パケット通信システムの具体例を示す図（その２）であ
る。

【図１１】図９および図１０のシステムの第１の詳細例
を示す図（その１）である。

【図１２】図９および図１０のシステムの第１の詳細例
を示す図（その２）である。

【図１３】図１１中の〔５〕で転送されるパケットのフ
ォーマットを示す図である。

【図１４】図１１中の〔６〕で転送されるパケットのフ
ォーマットを示す図である。

【図１５】図１１中の〔８〕で転送されるパケットのフ
ォーマットを示す図である。

【図１６】図１２中の

〔９〕で転送されるパケット（第
１例）のフォーマットを示す図である。

【図１７】図１２中の〔１０〕で転送されるパケット
（第１例）のフォーマットを示す図である。

【図１８】図１２中の

〔９〕で転送されるパケット（第
２例）のフォーマットを示す図である。

【図１９】図１２中の〔１０〕で転送されるパケット
（第２例）のフォーマットを示す図である。

【図２０】図１２中の〔１０〕で転送されるパケット
（第３例）で認証ヘッダ無しのときのフォーマットを示
す図である。

【図２１】図１２中の〔１０〕で転送されるパケット
（第３例）で認証ヘッダ有りのときのフォーマットを示
す図である。

【図２２】図９および図１０のシステムの第２の詳細例
を示す図である。

【図２３】図２２中の〔６〕で転送されるパケットのフ
ォーマットを示す図である。

【図２４】図２２中の〔７〕で転送されるパケットのフ
ォーマットを示す図である。

【図２５】図２２中の〔８〕で転送されるパケットのフ
ォーマットを示す図である。

【図２６】図２５におけるＣｏＡオプションのフォーマ
ットの一例を示す図である。

【図２７】図１１，１２および２２で示すシステムを１
つに統合して表す図である。

【図２８】本発明に係るルータ（１０，２０）の機能ブ
ロックを表す図である。

【図２９】ルータ（Ｒ２）１０についてのモバイルテー
ブルの内容の一例を示す図である。

【図３０】ルータ（ＨＡ）２０についてのモバイルテー
ブルの内容の一例を示す図である。

【図３１】ルータ（Ｒ２）１０についてのルーティング
テーブルの内容の一例を示す図である。

【図３２】ルータ（ＨＡ）２０についてのルーティング
テーブルの内容の一例を示す図である。

【図３３】ルータ（Ｒ２）としてのパケット処理部３４
（図２８）の処理を示すフローチャート（その１）であ
る。

【図３４】ルータ（Ｒ２）としてのパケット処理部３４
（図２８）の処理を示すフローチャート（その２）であ
る。

【図３５】図３３および図３４のフローチャート上にお
ける各パケット（Ｐ１〜Ｐ４）の流れを示す図である。

【図３６】図３５における各パケット（Ｐ１〜Ｐ４）の
フォーマットを示す図である。

【図３７】ルータ（ＨＡ）としてのパケット処理部３４
（図２８）の処理を示すフローチャート（その１）であ
る。

【図３８】ルータ（ＨＡ）としてのパケット処理部３４
（図２８）の処理を示すフローチャート（その２）であ
る。

【図３９】図３７および図３８のフローチャート上にお
ける各パケット（Ｐ５〜Ｐ８）の流れを示す図である。

【図４０】図３９における各パケット（Ｐ５〜Ｐ８）の
フォーマットを示す図である。

【符号の説明】

１０…移動端末対応ルータ １１…記憶手段 １２…転送手段 １３…登録手段 ２０…ホームエージェント・ルータ ２１…受信手段 ２２…アドレス更新通知手段 ２３…登録手段 ３１…モバイルテーブル ３２…ルーティングテーブル ３３…プロトコル処理手段 ３４…パケット処理部 ３５…受信部 ３６…送信部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｑ 7/22 Ｈ０４Ｑ 7/04 Ａ 7/24 7/26 7/30 (72)発明者 武智 竜一 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5K030 GA01 HA06 HC09 HD03 HD07 JL01 JT09 LB05 LC01 5K033 AA02 BA01 BA02 CC01 DA05 DA19 DB19 5K067 AA13 BB21 DD17 DD27 EE02 EE16 HH21 HH22 HH23

Claims (4)

【特許請求の範囲】
1. 【請求項１】 少なくとも移動端末のパケット通信をサ
   ポートするネットワークを構成する移動端末対応ルータ
   であって、 前記パケット通信の相手端末が記憶すべき前記移動端末
   の現在アドレスを、該相手端末に代わって、記憶する記
   憶手段と、 前記相手端末から前記移動端末のホームアドレス宛てに
   送信されたパケットを受信したとき、前記記憶手段を参
   照し、該ホームアドレス宛てを前記現在アドレス宛てに
   変換して該パケットを送信する転送手段と、 を具備することを特徴とする移動端末対応ルータ。
2. 【請求項２】 前記移動端末の移動により前記現在アド
   レスを変更したことに伴い前記通信の相手端末に対し当
   該アドレスの更新を通知するために送信される更新通知
   情報を受信したとき、この受信をトリガとして、前記記
   憶手段における前記ホームアドレスと前記現在アドレス
   との対応関係を新たに登録する登録手段を有することを
   特徴とする請求項１に記載の移動端末対応ルータ。
3. 【請求項３】 前記ネットワークは、前記移動端末をこ
   のホームアドレスにおいて収容するホームエージェント
   ・ルータを含み、前記移動端末の移動により前記現在ア
   ドレスを変更したことに伴い該ホームエージェント・ル
   ータに対し当該アドレスの更新を通知するために送信さ
   れる更新通知情報を受信したときに該ホームエージェン
   ト・ルータからの当該更新アドレスの転送をトリガとし
   て、前記記憶手段における前記ホームアドレスと前記現
   在アドレスとの対応関係を新たに登録する登録手段を有
   することを特徴とする請求項１に記載の移動端末対応ル
   ータ。
4. 【請求項４】 少なくとも移動端末の通信をサポートす
   るネットワークを構成するホームエージェント・ルータ
   であって、 前記移動端末の移動により前記現在アドレスを変更した
   ことに伴い前記ホームエージェント・ルータに対し当該
   アドレスの更新を通知するために送信される更新通知情
   報を受信する受信手段と、 該更新通知情報を受信したときに、その更新後の前記現
   在アドレスを、前記ネットワークを構成する他のルータ
   に送信するアドレス更新通知手段、 を具備することを特徴とするホームエージェント・ルー
   タ。