[go: up one dir, main page]

JP2003018192A - 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるゲートノード，エッジノード及び移動端末並びにパケット網におけるハンドオーバ方法及びルーティングノード - Google Patents

階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるゲートノード，エッジノード及び移動端末並びにパケット網におけるハンドオーバ方法及びルーティングノード

Info

Publication number
JP2003018192A
JP2003018192A JP2001174698A JP2001174698A JP2003018192A JP 2003018192 A JP2003018192 A JP 2003018192A JP 2001174698 A JP2001174698 A JP 2001174698A JP 2001174698 A JP2001174698 A JP 2001174698A JP 2003018192 A JP2003018192 A JP 2003018192A
Authority
JP
Japan
Prior art keywords
packet
node
cache
mobile terminal
information
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.)
Granted
Application number
JP2001174698A
Other languages
English (en)
Other versions
JP4340400B2 (ja
Inventor
Hideaki Ono
英明 小野
Keiichi Nakatsugawa
恵一 中津川
Tsugio Kato
次雄 加藤
Kazuyuki Oka
和之 岡
Ryuichi Takechi
竜一 武智
Akiko Tamai
明子 玉井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2001174698A priority Critical patent/JP4340400B2/ja
Priority to EP20060013365 priority patent/EP1718024A1/en
Priority to EP20010122678 priority patent/EP1263182B1/en
Priority to US09/967,447 priority patent/US20030026241A1/en
Priority to DE60137025T priority patent/DE60137025D1/de
Publication of JP2003018192A publication Critical patent/JP2003018192A/ja
Application granted granted Critical
Publication of JP4340400B2 publication Critical patent/JP4340400B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/20—Communication route or path selection, e.g. power-based or shortest path routing based on geographic position or location
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0027—Control or signalling for completing the hand-off for data sessions of end-to-end connection for a plurality of data sessions of end-to-end connections, e.g. multi-call or multi-bearer end-to-end data connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 【課題】 パケット通信システムにおいて、ハンドオー
バの高速対応とパケット転送ルートに制限の無いルート
最適化とを実現する。 【解決手段】 ゲートノード２１ｂが、自己が管理する
移動端末３ａの現在位置情報をキャッシュ情報として移
動端末３ａ宛のパケットを自己宛にルーティングしてく
るエッジノード（以下、通信中エッジノードという）
（ＥＮ“３”）に通知し（９３）、その通信中エッジノ
ード（ＥＮ“３”）が、通知されたキャッシュ情報に基
づき上記ゲートノード２１ｂに代わって移動端末３宛の
パケットの在圏エッジノード（ＥＮ“４”）に対するル
ーティングを実施する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、階層化パケット網
におけるパケット転送方法並びに階層化パケット通信シ
ステム並びに同システムに使用されるゲートノード，エ
ッジノード及び移動端末並びにパケット網におけるハン
ドオーバ方法並びにルーティングノードに関し、特に、
MIPv6（Mobile Internet Protocol version 6）等に準
拠したパケット網に用いて好適な技術に関する。
【０００２】
【従来の技術】近年、IETF（Internet Engineering Tas
k Force）において、インターネットプロトコル（Ｉ
Ｐ）上で携帯電話等の移動端末（以下、単に「端末」と
もいう）の位置を管理する方式として、「MIPv6」が提
案されている。図６３に「MIPv6」に準拠したパケット
通信システムの一例を示す。この図６３に示すシステム
では、ルータ網（パケット網）１１０を運営するＩＳＰ
（Internet Service Provider）等（以下、単に「プロ
バイダ」という）が管理するホームエージェント（HA：
Home Agent）ノード１００において、そのプロバイダが
提供するパケット転送サービスの契約加入者の移動端末
（これを「ホーム端末」あるいは「契約端末」という）
５００の現在位置が管理される。
【０００３】同様に、ＨＡノード１００（ルータ網１１
０）のプロバイダとは異なるプロバイダが管理するＨＡ
ノード〔ＨＡノード１００側からみれば外部（foreig
n）網２１０のＨＡノード〕２００では、ルータ網２１
０についての契約端末の現在位置が管理される。なお、
３００，４００はルータ網１１０，２１０間を結ぶ中継
ルータ網を表す。
【０００４】ここで、具体的に、上記の契約端末５００
の現在位置管理は、契約端末５００が契約ルータ網（ホ
ーム網）１１０に存在している場合、その現在位置から
アクセスしうる最寄りのアクセスノード（在圏ノード；
無線基地局としての機能を有するパケットのラストホッ
プルータ）１１１から広告（報知）される情報〔ルータ
広告（ＲＡ：Router Advertisment）メッセージ〕に含
まれるアクセスノード１１１のＩＰアドレスを基にCOA
（Care of Address）と呼ばれる、現在自己がどのノー
ドの在圏ゾーンに位置しているか（つまり、端末５００
の接続先ノード）を表す情報を作成し、これをＨＡノー
ド１００に通知することで実施される。
【０００５】一方、契約端末５００がその移動により非
契約ルータ網（移動先網）２１０に存在している場合
（いわゆる「ローミング」中の場合）には、契約端末５
００は、移動先網２１０の最寄りのアクセスノード２１
１から受信されるＲＡに含まれるアクセスノード２１１
のＩＰアドレスを基にCOAを作成して、これをホーム網
１１０のＨＡノード１００にルータ網２１０，３００，
４００を介して通知することになる。
【０００６】つまり、契約端末５００は、その移動によ
って受信するＲＡに含まれるＩＰアドレスが変化して最
寄りのアクセスノード１１１又は２１１が変わる度に、
新たなCOAを作成してホーム網１１０のＨＡノード１０
０に対して現在位置の更新登録を実施するのである。こ
れにより、ＨＡノード１００は、契約端末５００が非契
約ルータ網２１０に位置する場合（「ローミング」中の
場合）であっても、逐次、更新登録されている現在位置
宛に契約端末５００宛のパケットをカプセル化（契約端
末５００宛のパケットにCOAを宛先アドレスとするヘッ
ダを付加）して転送することで、契約端末５００宛のパ
ケットを正しく契約端末５００に届けることができ、正
常な移動通信が実現される。
【０００７】なお、ルータ網２１０についての契約端末
によるＨＡノード２００に対する位置登録手順も上記と
同様である。しかしながら、このような位置登録手順で
は、端末はその移動により最寄りのアクセスノードが変
わる度に常にＨＡノード１００又は２００に位置登録を
行なわなければならないため、現在位置とＨＡノード１
００（又は２００）との距離に応じたパケット転送遅延
が生じ、高速ハンドオーバには不向きである。また、ア
クセスノード２１１（又は１１１）からＨＡノード１０
０（又は２００）までのルータ網２１０，３００，４０
０，１１０のトラフィック量の増大にもつながる。
【０００８】なお、上記のシステムにおいてローミング
中の契約端末（以下、ローミング端末という）５００と
相手端末６００（移動端末でもよいし固定端末でもよ
い）との通信が開始された後は、例えば図６４に示すよ
うに、ローミング端末５００が、ＨＡノード１００に対
する位置登録と同様に、相手端末６００に現在のCOAを
通知する（破線矢印７００参照）ことで、「ルート最適
化」を図ることができる。つまり、相手端末６００は、
現在のCOAをローミング端末５００から直接受信するこ
とで、ＨＡノード１００を経由せずにそのCOA宛に直接
パケットを送信することができるようになるのである
（実線矢印８００参照）。
【０００９】ただし、この場合も、ローミング端末５０
０が移動して最寄りのアクセスノード２１１が変わった
ときには、その都度、新しいCOAを相手端末６００に通
知する必要があるため、相手端末６００との距離に応じ
たパケット転送遅延によってハンドオーバ品質が左右さ
れることになり、やはり高速ハンドオーバには向かな
い。
【００１０】このように、図６３に示すような通常の
「MIPv6」網（パケット通信システム）では、ローミン
グ先のルータ網２１０でローミング端末５００が移動す
ると、その移動の度（正確には、最寄りのアクセスノー
ドが変わる度）に、ＨＡノード１００への位置登録が発
生し、ハンドオーバ時の通信品質劣化を生じるが、これ
を緩和するために、近年、ルータ網を階層化して階層内
の移動時にはＨＡノードへの位置登録を不要とする方式
〔階層化（Hierarchical）MIPv6〕も提案されている。
【００１１】図６５に階層化Mobile-IPv6（以下、「HMI
Pv6」と表記する）に準拠したパケット通信システムの
一例を示す。この図６５において、９００が移動端末５
００へのゲート機能を提供するゲートノード（ＭＡ；Mo
bility Agent）であり、この図６５に示すように、それ
ぞれが１台以上のアクセスノードを収容することによ
り、ルータ網１１０又は２１０のＭＡ９００単位での階
層化が図られている。
【００１２】そして、例えば、ルータ網１１０をホーム
網とする契約端末５００がホーム網１１０からローミン
グ先のルータ網２１０へ移動（ローミングイン）すると
（矢印９０３参照）、その端末５００は、最寄りのＭＡ
９００からルータ広告（ＲＡ）メッセージ（以下、単に
「ルータ広告」ともいう）を受けて、そのＭＡ９００配
下で使用するローカルなＩＰアドレス（「PCOA」と呼ば
れる）と、ＨＡノード１００からＭＡ９００まで到達可
能なＩＰアドレス（「VCOA」と呼ばれる）の２つのアド
レスを作成する。
【００１３】その後、端末５００は、「VCOA」をＨＡノ
ード１００に通知して現在位置の位置登録を行なう（矢
印９０４参照）とともに、「PCOA」をＭＡ９００に通知
してＭＡ９００にも位置登録を行なう（矢印９０５参
照）。以降、端末５００は、同一ＭＡ９００の配下での
移動の場合（矢印９０１参照）には、ＭＡ９００にのみ
位置登録を行ない（矢印９０６参照）、ＨＡノード１０
０への位置登録は行なわず、ＭＡ９００が異なる地域へ
移動した場合（矢印９０２参照）には、再度、移動先の
ＭＡ９００とＨＡノード１００の両方に位置登録を行な
う（矢印９０７，９０８参照）。なお、端末５００は、
ホーム網１１０内に位置する場合にも、ＭＡをまたぐ移
動が生じると、その都度、移動先のＭＡ９００とＨＡノ
ード１００の双方に位置登録を行なう。
【００１４】つまり、「HMIPv6」準拠のパケット通信シ
ステム（以下、階層化パケット通信システムという）で
は、同一ＭＡ９００内の移動であれば、端末５００は自
己の現在位置の登録先（ＭＡ９００）を切り替えないの
である。したがって、図６３及び図６４により前述した
通常のシステムよりも、高速なハンドオーバを実現でき
る。
【００１５】なお、この階層化パケット通信システムに
おいても、前述したような「ルート最適化」を行なう場
合には、図６６に示すように、ローミング端末５００
が、相手端末６００との通信開始後、相手端末６００に
現在の「VCOA」を通知すればよい（破線矢印９０９参
照）。つまり、相手端末６００から最初に端末５００宛
に送信されたパケットが、一旦、ＨＡノード１００で受
信され（矢印９１０参照）、ＨＡノード１００にて「VC
OA」（ＭＡアドレス）でカプセル化されてＭＡ９００へ
ルーティングされ、そのＭＡ９００にて「PCOA」（移動
先アドレス）でカプセル化されて該当アクセスノード２
１１へルーティングされることにより、相手端末６００
とローミング端末５００との通信が開始されるが、その
後は、ローミング端末５００が、相手端末６００に「VC
OA」（ＭＡ９００まで到達可能なアドレス）を通知する
ことにより、相手端末６００は、その「VCOA」宛にパケ
ットを送信することが可能となり、当該パケットはＭＡ
９００まで到達できる。
【００１６】ただし、この場合も、ローミング端末５０
０の移動によりＭＡ９００が変わる（「VCOA」が変わ
る）場合には、その都度、新しい「VCOA」を相手端末６
００に再通知する必要がある。なお、「ルート最適化」
前の相手端末６００からローミング端末５００までのパ
ケット転送ルートの一例を図６７に、「ルート最適化」
後の相手端末６００からローミング端末５００までのパ
ケット転送ルートの一例を図６８にそれぞれ示す。な
お、これらの図６７，図６８において、符号１１０ａ，
１１０ｂ（２１０ａ，２１０ｂ）はそれぞれＭＡ９００
が管轄する階層化網を表し、これらの階層化網１１０
ａ，１１０ｂ（２１０ａ，２１０ｂ）によってホーム網
１１０（移動先網２１０）が形成されていることを示し
ている。
【００１７】そして、これらの図６７，図６８から分か
るように、階層化パケット通信システムでは、ＨＡノー
ド１００に「VCOA」を通知することで、常に、端末５０
０が位置登録（「PCOA」の通知）を行なっているＭＡ９
００までのルートが最短距離となるよう最適化される
（換言すれば、階層化パケット通信システムにおける
「ルート最適化」では、必然的に、最低１台のＭＡ９０
０を経由することになる）。
【００１８】ところで、従来の「Mobile-IP」網におけ
るハンドオーバ方法には、「スムースハンドオーバ」と
呼ばれるものがある。これは、例えば図６９に模式的に
示すように、ＨＡ１００（２００）に「COA1」が登録さ
れている状態で、端末５００が移動して接続先ルータが
「Ｒ１」から「Ｒ２」に変わることにより新しい「COA
2」を作成したときに、ＨＡ１００（２００）ではな
く、移動直前の接続先ルータ「Ｒ２」に対して、新しい
「COA2」宛にパケットを転送するよう要求（「COA2」を
登録）する（これをスムースハンドオフ指示という；矢
印９１２参照）ことで実現される。
【００１９】即ち、この図６９において、「スムースハ
ンドオフ指示」を受けた（端末５００により「COA2」が
登録された）ルータ「Ｒ１」は、ＨＡ１００（２００）
にて「COA1」宛にカプセル化されて転送されてくる、相
手端末（ＣＮ；Corresponding Node）６００が端末５０
０のホームアドレス宛に送信したパケットを受信すると
（矢印９１０，９１１参照）、その受信パケットをさら
に「COA2」宛にカプセル化して転送するのである。
【００２０】これにより、端末５００が通信中に旧ルー
ト（ルータ「Ｒ１」）へ到着したパケットは「スムース
ハンドオフ指示」によって新しい「COA2」へと転送され
ることになり（矢印９１３参照）、端末５００は相手端
末６００との通信を円滑に継続することが可能になる。
なお、ＨＡ１００（２００）のCOAが更新された後は、
ＨＡ１００（２００）において最新のCOA宛への受信パ
ケットのカプセル化が行なわれて、ＨＡ１００（２０
０）から新しい接続先ルータ「Ｒ２」経由で端末５００
にパケットが到着することとなる。
【００２１】
【発明が解決しようとする課題】しかしながら、図６５
〜図６８により上述した階層化パケット通信システムで
は、ハンドオーバ時間は短縮されるが、通常のパケット
通信システムでは実現できていたルート最適化が、必ず
現在使用中（位置登録を行なっている）ＭＡ９００を経
由しなければならないというルート上の制限が生じるた
めに実現できなくなっている。換言すれば、階層化パケ
ット通信システムにおいては、「ルート最適化」がＭＡ
９００までしか行なわれないのである。このため、特定
のＭＡ９００にパケットが集中して到着することにな
り、ＭＡ９００の処理負荷も高くなってしまう。
【００２２】また、階層化パケット通信システムにおい
ても、端末５００がＭＡ９００をまたいで移動する場合
には、ホーム網１１０のＨＡノード１００に位置登録を
行なう必要があるため、通常の（非階層化）パケット通
信システムと同様に、ハンドオーバに時間がかかり、高
速ハンドオーバには向かない。さらに、上述したハンド
オーバ手法では、どの種別のパケットに対しても同じ動
作をする。一般に、パケットは、どのような上位アプリ
ケーションデータを運ぶかによって、それぞれネットワ
ークに対して要求する特性が異なる。例えば、音声パケ
ットであれば、高品質を保つために遅延を少なく押さえ
なければならないが、多少のパケットロスは許容でき
る。これに対し、データパケットの場合は、パケットロ
スが上位アプリケーションデータの再送処理を引き起こ
し通信品質に大きな影響を与えることになるが、転送遅
延については多少生じても許容できる。
【００２３】このように、パケット種別（例えば、音声
パケットやデータパケット等）によってネットワークに
要求される条件が異なるにもかかわらず、これまでハン
ドオーバの仕組みはネットワークで１つの手法が固定的
に適用されることが一般的であり、条件の異なるハンド
オーバが同一ネットワークにおいて適用されることはな
かった。その結果、音声向け、あるいは、データ通信向
けのどちらかにチューニングしたハンドオーバ手法しか
採用できないこととなり、双方の要求を柔軟に満たすこ
とができなかった。
【００２４】本発明は、このような課題に鑑み創案され
たもので、階層化パケット通信システムにおいて、ハン
ドオーバの高速対応とパケット転送ルートに制限の無い
ルート最適化とを可能にすることを目的とする。また、
本発明は、受信パケット種別に応じてハンドオーバ手法
を変更できるようにして、受信パケット種別に最適なハ
ンドオーバを実現できるようにすることも目的とする。
【００２５】
【課題を解決するための手段】上記の目的を達成するた
めに、本発明の階層化パケット網におけるパケット転送
方法（請求項１）は、移動端末と通信してパケットの送
受を行ないうる複数のエッジノードと、該移動端末の現
在位置情報を管理し当該現在位置情報に基づいて該移動
端末宛のパケットを該移動端末がその現在位置から通信
可能なエッジノード（以下、在圏エッジノードという）
へルーティングしうるゲートノードとをそなえて成る階
層化パケット網において、(1)ゲートノードが、自己が
管理する移動端末の現在位置情報をキャッシュ情報とし
て上記移動端末宛のパケットを自己宛にルーティングし
てくるエッジノード（以下、通信中エッジノードとい
う）に通知し、(2)その通信中エッジノードが、通知さ
れたキャッシュ情報に基づき上記ゲートノードに代わっ
て上記移動端末宛のパケットの在圏エッジノードに対す
るルーティングを実施することを特徴としている。
【００２６】ここで、上記のエッジノードは、それぞ
れ、少なくとも自己を収容するゲートノードの識別情報
（以下、ゲートノード識別情報という）と階層化パケッ
ト網の識別情報（以下、網識別情報という）とを含む報
知情報を該移動端末に送信し、移動端末は、その報知情
報に含まれるゲートノード識別情報が自己の移動に伴っ
て変化しても網識別情報が変化していなければ、自己の
現在位置情報の登録先を、同じゲートノードに維持する
ようにしてもよい（請求項２）。
【００２７】次に、本発明の階層化パケット通信システ
ム（請求項３）は、移動端末，ゲートノード，エッジノ
ードがそれぞれ下記の手段をそなえていることを特徴と
している。 ・移動端末 (1)在圏エッジノードの識別情報に基づく位置情報を自
己の現在位置情報として特定のゲートノードに通知して
登録する現在位置登録手段 ・ゲートノード (2)上記の移動端末の現在位置登録手段によって通知さ
れる現在位置情報を管理する端末位置管理手段 (3)この端末位置管理手段で管理されている現在位置情
報をキャッシュ情報として通信中エッジノードに通知す
るキャッシュ情報通知手段 ・エッジノード (4)上記のゲートノードのキャッシュ情報通知手段によ
り通知されたキャッシュ情報を保持するキャッシュ手段 (5)このキャッシュ手段に保持されているキャッシュ情
報に基づき上記のゲートノードに代わって移動端末宛の
パケットの在圏エッジノードに対するルーティングを実
施するルーティング手段 また、本発明の階層化パケット通信システムに使用され
るゲートノード（請求項４）は、(1)移動端末からその
現在位置情報として通知されてくる、在圏エッジノード
の識別情報に基づく位置情報を管理する端末位置管理手
段と、(2)この端末位置管理手段で管理されている現在
位置情報をキャッシュ情報として通信中エッジノードに
通知するキャッシュ情報通知手段とをそなえていること
を特徴としている。
【００２８】さらに、本発明の階層化パケット通信シス
テムに使用されるエッジノード（請求項５）は、(1)ゲ
ートノードで管理されている、在圏エッジノードの識別
情報に基づく位置情報をキャッシュ情報として受けて保
持するキャッシュ手段と、(2)このキャッシュ手段に保
持されているキャッシュ情報に基づき上記のゲートノー
ドに代わって移動端末宛のパケットの在圏エッジノード
に対するルーティングを実施するルーティング手段とを
そなえていることを特徴としている。
【００２９】また、本発明の階層化パケット通信システ
ムに使用される移動端末（請求項６）は、(1)少なくと
も在圏エッジノードを収容する特定のゲートノードの識
別情報（以下、ゲートノード識別情報という）と階層化
パケット網の識別情報（以下、網識別情報という）とを
含む報知情報を、在圏エッジノードから受信する報知情
報受信手段と、(2)この報知情報受信手段で受信された
報知情報に含まれるゲートノード識別情報が自己の移動
に伴って変化しても上記の網識別情報が変化していなけ
れば、自己の現在位置情報の登録先を、同じゲートノー
ドに維持する現在位置登録手段とをそなえていることを
特徴としている。
【００３０】次に、本発明のパケット網におけるハンド
オーバ方法（請求項７）は、特定のルーティングノード
（以下、特定ノードという）において移動端末の移動に
伴う複数の端末位置情報を管理しておき、その特定ノー
ドが、移動端末宛の受信パケットの種別（以下、パケッ
ト種別という）を識別し、識別したパケット種別に応じ
て上記複数の端末位置情報のいずれかを選択し、選択し
た端末位置情報に基づいて受信パケットをルーティング
することを特徴としている。
【００３１】ここで、上記の特定ノードは、上記複数の
端末位置情報として、移動端末の現在の位置情報と、そ
の移動端末の通信開始時の位置情報とを管理しておき、
上述のごとく識別したパケット種別がパケットロスを許
容する特性をもつパケット種別であると、移動端末の現
在の位置情報を選択する一方、識別したパケット種別が
パケット転送遅延を許容する特性をもつパケット種別で
あると、移動端末の通信開始時の位置情報を選択しても
よい（請求項８）。
【００３２】また、本発明のパケット網におけるハンド
オーバ方法（請求項９）は、階層化パケット網におい
て、ゲートノードが、自己が管理する移動端末の現在の
位置情報をキャッシュ情報としてその移動端末宛のパケ
ットを自己宛にルーティングしてくるルーティングノー
ド（以下、通信中ノードという）に通知し、その通信中
ノードは、上記の移動端末の通信開始時の位置情報を管
理しておき、その移動端末宛の受信パケットの種別（以
下、パケット種別という）を識別し、識別したパケット
種別がパケットロスを許容する特性をもつパケット種別
であると、ゲートノードから通知されたキャッシュ情報
に基づきそのゲートノードに代わって受信パケットを在
圏ノードへルーティングすることを特徴としている。
【００３３】さらに、本発明のルーティングノード（請
求項１０）は、移動端末の移動に伴う複数の端末位置情
報を管理する端末位置管理手段と、その移動端末宛の受
信パケットの種別（以下、パケット種別という）を識別
するパケット種別識別手段と、このパケット種別識別手
段で識別したパケット種別に応じて上記の端末位置管理
手段で管理されている複数の端末位置情報のいずれかを
選択する選択手段と、この選択手段によって選択された
端末位置情報に基づいて受信パケットをルーティングす
るルーティング手段とをそなえたことを特徴としてい
る。
【００３４】
【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を説明する。 (A)第１実施形態の説明 (A1)システム構成の概要説明 図１は本発明の第１実施形態としての階層化パケット通
信システムの構成を示すブロック図で、この図１に示す
階層化パケット通信システムは、「MIPv6」に準拠した
システムであって、それぞれ異なるキャリア（ＩＳＰ等
の通信事業者）が提供するパケット網（キャリア網とも
いう）１，２を有しており、キャリア網１（２）は、少
なくとも１台のＶＨＡ（Virtual Home Agent）ノード１
０（２０）と、キャリア網１（２）を構成するサブキャ
リア（サブパケット）網１ａ，１ｂ（２ａ，２ｂ）毎に
少なくとも１台ずつ設けられたＴＨＡ（Temporary Home
Agent）ノード１１ａ，１１ｂ（２１ａ，２１ｂ）と、
階層化網１ａ，１ｂ（２ａ，２ｂ）を形成する複数のエ
ッジノード（ＥＮ）１２とをそなえて構成されている。
なお、「キャリア網」はいわゆる「ドメイン」として識
別される。また、以下の説明において、本発明が適用さ
れるキャリア網を「Ｍ３対応網」あるいは「M3v6（Mult
i-Media Mobile Network based on IPv6）ネットワー
ク」と称することがある。
【００３５】ここで、ＶＨＡノード１０（２０）は、自
キャリア網（ホーム網）１（２）内に存在する契約加入
者の移動端末（ＭＮ：Mobile Node）３（以下、「ホー
ム端末３」もしくは単に「端末３」という場合がある）
の現在位置情報〔COA（VCOA，PCOA）〕を結合（バイン
ディング）キャッシュ（Binding Cache）と呼ばれる情
報の一部として管理するとともに、到着（受信）した端
末３宛のパケットが示す宛先アドレス（ＤＡ）に対応す
る「COA」を本「キャッシュ」において検索し、該当「C
OA」でカプセル化して転送（ルーティング）するための
ものである。
【００３６】なお、上記の「VCOA」／「PCOA」は、後述
するように、ＴＨＡアドレス／ＥＮアドレスのネットワ
ークプレフィックス部分（上位６４ビット）と端末３の
インタフェースＩＤとを組み合わせることにより作成さ
れる。従って、「VCOA」は該当ＴＨＡ１１ａ，１１ｂ
（２１ａ，２１ｂ）まで到達できるアドレスを表し、
「PCOA」は該当ＥＮ１２まで到達できるアドレスを表し
ていることになる。
【００３７】また、上記の「キャッシュ」は、ホーム端
末３からの位置登録により「MIPv6」ベースで作成・更
新される〔「キャッシュ」の内容については、図４
（Ａ）により後述する〕。この位置登録は、ホーム端末
３とホーム網１（２）のＶＨＡ１０（２０）との間で、
後述するホーム位置登録メッセージ（パケット）及びホ
ーム位置登録応答メッセージ（パケット）を送受するこ
とで実施される。
【００３８】そして、本ＶＨＡノード１０（２０）（以
下、単に「ＶＨＡ１０（２０）」と表記する場合があ
る）は、本実施形態に特有の機能として、次のような機
能も有している。 (1)ＥＮ１２から「結合キャッシュ」（以下、「キャッ
シュ情報」、又は、単に「キャッシュ」ともいう）の通
知要求〔キャッシュ要求（Binding Request-M3）メッセ
ージ（パケット）〕を受けると、該当「キャッシュ情
報」を要求元のＥＮ１２へキャッシュ通知メッセージ
（パケット）により通知（提供）する機能。
【００３９】(2)そのＥＮ１２のＩＰアドレス（ＥＮア
ドレス；識別情報）を「通信中ＥＮアドレス」として
「キャッシュ情報」とともに管理する機能。 (3)上記の位置登録に応じて「キャッシュ」を更新する
機能。 (4)「キャッシュ」の更新に応じて通信中ＥＮ１２に通
知した「キャッシュ」を更新するための機能。なお、こ
の機能は、通信中ＥＮ１２との間で位置（キャッシュ）
更新メッセージ（パケット）及び位置（キャッシュ）更
新応答メッセージ（パケット）の送受を実施することで
実現される。
【００４０】次に、上記のＴＨＡノード１１ａ，１１ｂ
（２１ａ，２１ｂ）（以下、説明の便宜上、単に「ＴＨ
Ａ１１（２１）」と表記することがある）は、それぞ
れ、自キャリア網１（２）とは異なる他のキャリア網２
（１）をホーム網とする移動端末３（これをローミング
端末という）３〕の現在位置情報〔COA(PCOA)〕を、上
記と同様のキャッシュ情報の一部として一時的に管理
し、到着（受信）した端末３宛のパケットが示す宛先ア
ドレス（ＤＡ）に対応する「PCOA」を本「キャッシュ」
において検索し、該当「PCOA」でカプセル化して転送
（ルーティング）する機能（代理ＨＡ機能）を有するも
のである。
【００４１】なお、このＴＨＡ１１（２１）における
「キャッシュ」は、ローミング端末３からの位置登録
（「PCOA」の登録）により「MIPv6」ベースで逐次更新
される。この位置登録は、ローミング端末３と、そのロ
ーミング端末３の現在位置から通信可能な最寄りのＥＮ
（これを在圏ＥＮという）１２を収容するＴＨＡ１１
（２１）との間で、在圏位置登録メッセージ（パケッ
ト）及び在圏位置登録応答メッセージ（パケット）を送
受することで実施される。
【００４２】したがって、本ＴＨＡ１１（２１）は、上
述したＶＨＡ１０（２０）と同様に、パケットが到着す
ると、自己が管理する「キャッシュ」を検索してその宛
先情報が示す宛先端末〔ローミング端末〕３の「PCOA」
を検索し、その「PCOA」で到着パケットをカプセル化し
て転送（ルーティング）する機能を有するほか、次のよ
うな機能も有している。
【００４３】(1)ＥＮ１２からのキャッシュ要求メッセ
ージに対して「キャッシュ」をキャッシュ通知メッセー
ジによりそのＥＮ１２へ通知（提供）する機能。 (2)「キャッシュ」を通知したＥＮ１２のＩＰアドレス
を「通信中ＥＮアドレス」として「キャッシュ」ととも
に管理する機能。 (3)上記の位置登録に応じて「キャッシュ」を更新する
機能。
【００４４】(4)「キャッシュ」の更新に応じて通信中
ＥＮ１２に通知した「キャッシュ」を更新するための機
能。なお、この機能は、ＶＨＡ１０（２０）と同様に、
通信中ＥＮ１２との間で位置（キャッシュ）更新メッセ
ージ及び位置（キャッシュ）更新応答メッセージの送受
を実施することで実現される。次に、上記のＥＮ１２
は、それぞれ、自己の通信エリアに存在する端末（在圏
端末；ホーム端末，ローミング端末の双方を含む）３と
無線通信することにより、上位のＶＨＡ１０（２０）や
ＴＨＡ１１（２１）からルーティングされてくる在圏端
末３宛のパケットを最終的にその端末３に転送するラス
トホップルータとしての機能を有するもので、本実施形
態では、次のような機能も有している。
【００４５】(1)ＶＨＡ１０（２０）又はＴＨＡ１１
（２１）で管理されている「キャッシュ」の通知を受け
て保持する機能。 (2)パケット到着時に、「キャッシュ」を検索し、キャ
ッシュヒットすればその情報（PCOA）で到着パケットの
カプセル化を行なって転送する機能。 (3)上記の検索によりキャッシュヒットしなかった場合
に、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）にキャ
ッシュ要求メッセージ（パケット）を発行する機能。
【００４６】(4)上記のキャッシュ要求メッセージに対
する応答としてのキャッシュ通知メッセージ（パケッ
ト）により「キャッシュ」の提供を受けたＶＨＡ１０
（２０）又はＴＨＡ１１（２１）のＩＰアドレス〔ＶＨ
Ａ／ＴＨＡアドレス（ゲートノード識別情報）〕を「キ
ャッシュ」とともに管理する機能〔図４（Ｂ）により後
述〕。なお、このＶＨＡ／ＴＨＡアドレスは、下記(8)
に示すように、ＶＨＡ１０（２０）又はＴＨＡ１１（２
１）で管理（保持）されている「キャッシュ」（通信中
ＥＮアドレス）の削除要求〔キャッシュ削除要求メッセ
ージ（パケット）〕発行時の宛先として使用される。
【００４７】(5)「キャッシュ情報」の中に含まれる
「ライフタイム（Lifetime）」を処理（一定周期毎にデ
クリメント）する機能（タイマ処理）。なお、「ライフ
タイム」が“０”になると「キャッシュ情報」の有効期
限が切れたことになる。 (6)「キャッシュ情報」の有効期限が切れると、その
「キャッシュ情報」を削除する機能。
【００４８】(7)パケット到着時に、「ライフタイム」
を更新（延長）する機能。この機能により、通信継続中
に「キャッシュ情報」の有効期限が切れることはない
（つまり、通信継続中は削除されずに維持される）。 (8)通信終了時（ライフタイム満了時）に、「キャッシ
ュ情報」の転送元のＶＨＡ１０（２０）又はＴＨＡ１１
（２１）で保持されている前記「通信中ＥＮアドレス」
のキャッシュ削除要求メッセージを発行する機能。
【００４９】(9)ルータ広告（RA：Router Advertise）
メッセージ（以下、単に「ルータ広告」という）を在圏
端末３に向けて定期的に、あるいは、在圏端末３からの
要求を受けたときに送信する機能。ただし、本実施形態
の「ルータ広告」には、ＥＮアドレスと、ＴＨＡアドレ
スと、キャリア網１（２）のアドレス（Ｍ３ネットワー
クアドレス；網識別情報）とが含まれる。ＴＨＡアドレ
スは、「HMIPv6」におけるＭＡアドレスと同等の情報で
ある。
【００５０】なお、上記の「Ｍ３ネットワークアドレ
ス」は、端末３が、現在位置するキャリア網がホーム網
１（２）なのか、他のキャリア網２（１）（つまり、ロ
ーミング中）なのかを判別したり、その有無によって現
在位置する網が「Ｍ３対応網」なのか、非「Ｍ３対応
網」なのかを判別したりするために使用される。そし
て、端末３は、在圏ＥＮ１２と通信してパケットの送受
を行なえるモバイルＩＰ端末で、本実施形態では、ホー
ム網１（２）内に位置するときには、ＶＨＡ１０（２
０）に対してホーム位置登録メッセージによりCOA（「P
COA」）を登録し、「Ｍ３対応網」である他網２（１）
にローミングインするときには、ローミング先のＴＨＡ
２１ａ又は２１ｂ（１１ａ又は１１ｂ）と、ホーム網１
（２）のＶＨＡ１０（２０）との双方にCOAを登録する
ようになっている。
【００５１】この場合、端末３は、ＴＨＡ２１ａ又は２
１ｂ（１１ａ又は１１ｂ）には「PCOA」を登録し、ＶＨ
Ａ１０（２０）には「VCOA」を登録する。また、本端末
３は、上記の「ルータ広告」に含まれるアドレス情報に
よってローミング先の網種別を識別することができるの
で、その網種別に応じて位置登録先を変えることができ
る。
【００５２】即ち、例えば、「ルータ広告」にＭ３ネッ
トワークアドレスが含まれずＭＡアドレスが含まれてい
る場合はその網が通常の「HMIPv6」網であるので、ロー
ミング先のＭＡに「PCOA」を、ホーム網１（２）のＶＨ
Ａ１０（２０）に「VCOA」をそれぞれ登録する。また、
「ルータ広告」にＭ３ネットワークもＭＡアドレスも含
まれていない場合は、その網は通常の「MIPv6」網であ
るので、端末３は、ＶＨＡ１０（２０）にのみ「VCOA」
を登録する。つまり、本実施形態の端末３は、「MIPv
6」，「HMIPv6」，「M3v6」のどのネットワークにも対
応できるようになっているのである。
【００５３】(A2)各種メッセージの詳細説明 さて、次に、本実施形態のシステムにおいて使用される
上記の各種メッセージについて整理すると、次表１に示
すようになる。
【００５４】
【表１】
【００５５】以下、これらのメッセージの詳細について
説明する。なお、以下では、これらのメッセージを「モ
バイルメッセージ」と総称する。これらの「モバイルメ
ッセージ」は、「MIPv6」準拠の制御メッセージを拡張
したもので、基本的には、いずれも、図７に示すような
「MIPv6」に準拠したパケット（以下、「MIPv6」パケッ
トともいう）のフォーマットを有している。
【００５６】即ち、「MIPv6」パケットは、標準ヘッダ
７１，オプションヘッダ７２及び認証ヘッダ７３から成
るＩＰヘッダ７０とＩＰペイロード８０とから成るが、
「モバイルメッセージ」は、これらのうちＩＰペイロー
ド８０を除く部分で構成される。そして、上記のＩＰヘ
ッダ７０（特に、オプションヘッダ７２）の設定内容に
よって上記の各メッセージ（パケット）が表示（識別）
されるのである。
【００５７】なお、標準ヘッダ７１には、図８に示すよ
うに、「バージョン情報」（４ビット），「トラフィッ
ククラス」（８ビット），「フローラベル」（２０ビッ
ト），「ペイロード長」（１６ビット），「ネクストヘ
ッダ」（８ビット），「ホップ制限数」（８ビット），
「送信元アドレス（ＳＡ：Source Address）」（１２８
ビット），「宛先アドレス（ＤＡ：Destination Addres
s）」（１２８ビット）が格納される各フィールド７１
１〜７１８が用意されている。
【００５８】以下、上記の各モバイルメッセージのパケ
ットフォーマットについて説明する。 (1)ホーム位置登録／位置登録応答メッセージ 図９にホーム位置登録メッセージのパケットフォーマッ
ト（ただし、ＩＰヘッダ７０に相当する部分）を示す。
この図９から分かるように、ホーム端末３のホーム網１
（２）への位置登録〔ＶＨＡ１０（２０）に対する位置
登録〕には、「MIPv6」のオプションヘッダ７２の宛先
オプションとして定義されている結合更新（Binding Up
date）オプション及びホームアドレス（Home Address）
オプションを使用する。次表２に結合更新オプション
（位置登録）パラメータを、次表３にホームアドレスオ
プションパラメータをそれぞれ示す。
【００５９】
【表２】
【００６０】
【表３】
【００６１】そして、図９に示すように、ホーム位置登
録メッセージの場合は、ＳＡフィールド７１７に端末３
のCO A（MN-COA）が格納され、ＤＡフィールド７１８に
ＶＨＡ１０（２０）のアドレス（ＶＨＡアドレス）が格
納される。これにより、ＶＨＡ１０（２０）にホーム位
置登録メッセージが到着し、「ＳＡフィールド」に格納
されているCOAが「キャッシュ情報」に登録されて端末
３の位置登録（更新）が行なわれることになる。なお、
本メッセージが「結合更新メッセージ」であることは、
オプションタイプ（Option Type）フィールド７２３に
表示（ここでは、“１９８”）される。
【００６２】これに対し、上記のホーム位置登録メッセ
ージを受けたＶＨＡ１０（２０）から端末３へのホーム
位置登録応答には、図１０に示すパケットフォーマット
を用いる。即ち、ホーム位置登録応答には、「MIPv6」
の宛先オプションとして定義されている結合応答（Bind
ing Acknowledgement）オプションを使用する。次表４
にこの場合の結合応答オプションパラメータを示す。
【００６３】
【表４】
【００６４】そして、図１０に示すように、ホーム位置
登録応答メッセージの場合は、ＳＡフィールド７１７に
発信ノード〔この場合はＶＨＡ１０（２０）〕のアドレ
スが格納され、ＤＡフィールド７１８にMN-COA〔受信パ
ケット（つまり、上記のホーム位置登録メッセージ）の
ＳＡ〕が格納されることにより、ＶＨＡ１０（２０）位
置登録を行なった端末３宛に本メッセージが発行（返
信）されて、位置登録完了の旨が通知されることにな
る。
【００６５】なお、ホーム位置登録メッセージを受けた
ＶＨＡ１１（２１）が位置登録応答メッセージを発行す
べきか否かは結合更新オプションのＡ（Acknowledgemen
t）ビットフィールド７２７に表示される（表２に示す
ように、“１”で要を表す）。また、図９及び図１０に
おいて、ＩＰヘッダ長やヘッダ拡張長等のLengthフィー
ルドの取り扱いは、次表５のとおりである。
【００６６】
【表５】
【００６７】（２）在圏位置登録／位置登録応答メッセ
ージ 次に、在圏網１ａ，１ｂ（２ａ，２ｂ）への位置登録
〔ＴＨＡ１１（２１）に対する位置登録〕には、図１１
に示すパケットフォーマットを使用する。即ち、「HMIP
v6」の宛先オプション７２として定義されている結合更
新（Binding Update）オプションと同等の登録オプショ
ン（Registration）及びホームアドレスオプション（表
３参照）を使用する。次表６に登録オプションパラメー
タを示し、次表７，８にそれぞれ表６中に示す前ＭＡア
ドレスサブオプション（previous mobility agent addr
ess sub-option）パラメータ，ホームエージェントアド
レスサブオプション（home agent address Sub-Optio
n）パラメータを示す。
【００６８】
【表６】
【００６９】
【表７】
【００７０】
【表８】
【００７１】そして、図１１に示すように、本在圏位置
登録（Registration）メッセージの場合も、基本的に、
上述したホーム位置登録メッセージと同様に、ＳＡフィ
ールド７１７に端末３のCOA（MN-COA）が格納され、Ｄ
Ａフィールド７１８にＴＨＡ１１（２１）のアドレス
（ＴＨＡアドレス）が格納されることにより、ＴＨＡ１
１（２１）に本在圏位置登録メッセージが到着し、ＳＡ
フィールド７１７に格納されているCOAがＴＨＡ１１
（２１）の「キャッシュ情報」に登録されて端末３の位
置登録（更新）が行なわれることになる。
【００７２】なお、本メッセージが「Registration」メ
ッセージであることは、オプションタイプフィールド７
２３に表示（ここでは、“９”）される。また、前ＭＡ
アドレスサブオプションの前ＭＡアドレスフィールド７
２１には、端末３が移動する前に位置登録を行なってい
たＴＨＡ１１（２１）のアドレスが格納され、ＴＨＡ１
１（２１）は、この前ＭＡアドレスフィールド７２１に
設定されているアドレスを参照することで、在圏端末３
がどのＴＨＡ１１（２１）の在圏ゾーンから移動してき
たかを認識できることになる。
【００７３】なお、図１１においても、ＩＰヘッダ長や
ヘッダ拡張長等のLengthフィールドの取り扱いは、前記
の表５のとおりである。これに対し、ＴＨＡ１１（２
１）から端末３への位置登録応答には、前記の結合応答
オプション（表４参照）を使用する。つまり、図１０に
示すものと同様のパケットフォーマットを使用する。そ
して、ＳＡフィールド７１７に発信ノード〔この場合
は、ＴＨＡ１１（２１）〕のアドレスが格納され、ＤＡ
フィールド７１８にMN-COA（受信パケットのＳＡフィー
ルド７１７に設定されていたアドレス）が格納されるこ
とにより、ＴＨＡ１１（２１）に対して位置登録を行な
った端末３宛に本メッセージが発行（返信）されて、位
置登録完了の旨が通知されることになる。
【００７４】（３）位置（キャッシュ）更新／応答メッ
セージ 次に、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）から
ＥＮ１２への位置更新（キャッシュ更新）には、図１２
に示すパケットフォーマット（ＩＰヘッダ７０に相当す
る部分）を使用する。即ち、結合更新オプション及びホ
ームアドレスオプション（前記の表３参照）を使用す
る。ただし、更新対象の端末３のCOAは、結合更新オプ
ションの代替COAサブオプション（Alternate Care of A
ddress Sub-Option）によって通知する。次表９に結合
更新オプション（位置更新）パラメータ例を、次表１０
に代替COAサブオプションパラメータ例を示す。
【００７５】
【表９】
【００７６】
【表１０】
【００７７】なお、本位置更新メッセージは、上述した
端末３からＶＨＡ１０（２０）又はＴＨＡ１１（２１）
への位置登録によりＶＨＡ１０（２０）又はＴＨＡ１１
（２１）の「キャッシュ情報」が更新されることに伴っ
て通信中のＥＮ１２にその更新を反映させる必要がある
ときに発行されるメッセージである。このため、図１２
に示すように、本位置更新メッセージの場合は、ＳＡフ
ィールド７１７にＶＨＡ１０（２０）又はＴＨＡ１１
（２１）のアドレスが格納されるとともに、ＤＡフィー
ルド７１８にＥＮ１２のアドレス（通信中ＥＮアドレ
ス）が格納され、且つ、代替COAフィールド７２２に位
置更新対象の端末３のCOA（MN-COA）が格納される。
【００７８】これにより、「キャッシュ情報」の更新が
必要な通信中ＥＮ１２に更新情報（MN-COA）が提供され
て、通信中ＥＮ１２の「キャッシュ情報」が更新され、
通信中ＥＮ１２は、端末３に対するパケットルーティン
グを正常に継続することが可能になる。なお、本メッセ
ージが「位置更新メッセージ」であることは、代替COA
フィールド７２２の有無によって識別できる。
【００７９】一方、通信中ＥＮ１２は、上記の位置更新
メッセージに対する応答（位置更新応答メッセージ）を
発行元のＶＨＡ１０（２０）又はＴＨＡ１１（２１）に
返信するが、このときの位置更新応答には、図１３に示
すパケットフォーマット（ＩＰヘッダ７０に相当する部
分）を使用する。即ち、本メッセージの場合も、結合応
答オプション（パラメータについては前記の表４参照）
を使用する。
【００８０】そして、この図１３に示すように、本位置
更新応答メッセージの場合は、ＳＡフィールド７１７に
発信ノード（ＥＮ１２）のアドレスが格納され、ＤＡフ
ィールド７１８に上記の受信パケット（位置更新メッセ
ージ）のＳＡフィールド７１７に設定されていたアドレ
ス〔つまり、位置更新メッセージの発信元のＶＨＡ１０
（２０）又はＴＨＡ１１（２１）のアドレス〕が格納さ
れることにより、そのＶＨＡ１０（２０）又はＴＨＡ１
１（２１）宛に本メッセージが発行（返信）されて、位
置更新完了の旨が通知されることになる。
【００８１】なお、この場合も、本位置更新メッセージ
を受けたＥＮ１２がそれに対する応答メッセージを発行
すべきか否かは結合更新オプションのＡ（Acknowledgem
ent）ビット（表２参照）に表示される（“１”で要を
表す）。また、図１２及び図１３においても、ＩＰヘッ
ダ長やヘッダ拡張長等のLengthフィールドの取り扱い
は、前記の表５に準ずる。
【００８２】（４）キャッシュ要求／通知メッセージ 次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１
（２１）へのキャッシュ要求（後述するキャッシュ検索
によりキャッシュヒットしなかった場合に発行される）
には、また、図１４に示すパケットフォーマット（ＩＰ
ヘッダ７０に相当する部分）を使用する。即ち、「MIPv
6」の宛先オプションとして新規に定義した結合要求〔B
inding Reauest for M3 (BR-M3)〕オプションを使用す
る。
【００８３】なお、このキャッシュ要求は、ＥＮ１２が
ＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレス
を既知である場合には、ＶＨＡ１０（２０）又はＴＨＡ
１１（２１）をＤＡとして本メッセージを発行する。こ
のとき、どのアドレスに対する「キャッシュ」を要求し
ているかを示すためにホームアドレスオプションを使用
する。
【００８４】また、別の例として、ＤＡに「キャッシ
ュ」を要求したいアドレスを直接指定する方法もある。
この場合、「キャッシュ」をもっているエージェント
〔ＶＨＡ１０（２０）／ＴＨＡ１１（２１）〕は、BR-M
3メッセージであることを宛先オプションから判断し、
ＤＡから「キャッシュ」を要求するアドレスを知るよう
に定義することも可能である。
【００８５】次表１１にBR-M3オプションパラメータ例
を、次表１２に表１１中に示す固有ＩＤサブオプション
（Unique Identifier Sub-Option）パラメータ例を、次
表１３にホームアドレスオプション（キャッシュ要求）
パラメータ例をそれぞれ示す。
【００８６】
【表１１】
【００８７】
【表１２】
【００８８】
【表１３】
【００８９】そして、図１４に示すように、本キャッシ
ュ要求メッセージの場合は、BR-M3オプションのオプシ
ョンタイプフィールド７２３に、本メッセージがBR-M3
メッセージであることを表す値（例えば、“１６”）が
格納され、ＳＡフィールド７１７にＥＮ１２のアドレス
が格納され、ＤＡフィールド７１８にキャッシュを知り
たい端末３のアドレス、又は、その端末３に対応するエ
ージェント〔ＶＨＡ１０（２０）又はＴＨＡ１１（２
１）〕のアドレスが格納される。また、ＤＡフィールド
７１８に後者のアドレスを格納する場合には、ホームア
ドレスフィールド７２４に、キャッシュを要求したいノ
ードのホームアドレスが格納される。
【００９０】これに対し、ＥＮ１２へのキャッシュ通知
には、図１５に示すパケットフォーマットを使用する。
即ち、結合更新オプション及びホームアドレスオプショ
ンを使用する。次表１４に、この場合の結合更新（Bind
ing Update）オプションパラメータ例を、次表１５及び
次表１６に表１４中に示す固有ＩＤサブオプション（Un
ique Identifier Sub-Option）パラメータ例及び代替CO
Aサブオプション（Alternate Care of Address Sub-Opt
ion）パラメータ例を示す。なお、代替COAサブオプショ
ンは、キャッシュエントリを特定するために使用され
る。また、ホームアドレスオプションパラメータは前記
の表３と同様である。
【００９１】
【表１４】
【００９２】
【表１５】
【００９３】
【表１６】
【００９４】そして、図１５に示すように、キャッシュ
通知の場合は、ＳＡフィールド７１７に上記のキャッシ
ュ要求を受けたＶＨＡ１０（２０）又はＴＨＡ１１（２
１）のアドレスが格納され、ＤＡフィールド７１８にキ
ャッシュ通知対象の通信中ＥＮ１２のアドレスが格納さ
れる。また、代替COAサブオプションの代替COAフィール
ド７２２には端末３のCOAが格納される。
【００９５】これにより、本キャッシュ通知は、目的の
通信中ＥＮ１２に到着し、そのＥＮ１２では、代替COA
に格納されている端末３のCOAを自己のキャッシュとし
て保持することになる。なお、本メッセージが、「キャ
ッシュ通知メッセージ」であることは、結合更新オプシ
ョンにより識別でき、代替COAサブオプションを使用し
ていれば（オプションタイプフィールド７２３ａが代替
COAの存在を表示していれば）、ＳＡ以外をCOAとして使
うことが分かる。従って、「キャッシュ」を作る際、検
索キーについてはホームアドレスオプションフィールド
７２４に設定された値を用い、COAについては代替COAフ
ィールド７２２に設定された値（MN-COA）を用いること
になる。
【００９６】（５）キャッシュ削除要求／応答メッセー
ジ 次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１
（２１）へのキャッシュ削除要求には、図１６に示すパ
ケットフォーマットを使用する。即ち、前記の結合更新
オプションを使用する。また、キャッシュ削除対象の端
末３のアドレスを通知するためにホームアドレスオプシ
ョン（そのパラメータについては前記の表３参照）を使
用する。次表１７にこの場合の結合更新オプション（キ
ャッシュ削除要求）パラメータ例を示す。
【００９７】
【表１７】
【００９８】そして、図１６に示すように、本キャッシ
ュ削除要求メッセージの場合は、ＳＡフィールド７１７
にＥＮ１２のアドレスが格納され、ＤＡフィールド７１
８にＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアド
レスが格納される。また、ホームアドレスフィールド７
２４に、ＥＮ１２においてキャッシュを削除した端末３
のホームアドレス（ＶＨＡ１０（２０）又はＴＨＡ１１
（２１）での削除対象キャッシュを特定する検索キーと
して用いられる）が格納される。
【００９９】なお、本メッセージが「キャッシュ削除要
求メッセージ」であることは、上記の表１７及びこの図
１６に示すように、リザーブ（reserved）ビットフィー
ルド７２８に“１(0x01)”、ライフタイム（Lifetime）
フィールド７２９に“０”が設定されることによって表
示される。これにより、通信中ＥＮ１２が非通信中とな
り、該当キャッシュが削除されることに伴って、その削
除したキャッシュの通知元であるＶＨＡ１０（２０）又
はＴＨＡ１１（２１）に対して本キャッシュ削除要求メ
ッセージが発行され、そのＶＨＡ１０（２０）又はＴＨ
Ａ１１（２１）において、もはや保持しておく必要の無
い情報が適切に削除されることになる。
【０１００】なお、本キャッシュ削除要求メッセージを
受けたＶＨＡ１０（２０）又はＴＨＡ１１（２１）は、
キャッシュ削除要求応答メッセージをＥＮ１２に対して
返信するが、このキャッシュ削除要求応答メッセージに
は、前記の結合応答オプション（パラメータについては
前記の表４参照）を使用する。即ち、本メッセージに
は、図１０に示すものと同様のパケットフォーマットを
使用する。
【０１０１】そして、ＳＡフィールド７１７に受信パケ
ット（キャッシュ削除要求メッセージ）のＤＡフィール
ド７１８に設定されていたアドレス〔つまり、ＶＨＡ１
０（２０）又はＴＨＡ１１（２１）のアドレス〕が格納
され、ＤＡフィールド７１８に受信パケットのＳＡフィ
ールド７１７に設定されていたアドレス（つまり、キャ
ッシュ削除要求を発行した通信中ＥＮ１２のアドレス）
が格納されることにより、通信中ＥＮ１２に対してキャ
ッシュ削除を行なった旨が返信されて通知されることに
なる。
【０１０２】(A3)システムの構成要素の詳細説明 次に、以下では、上記のＶＨＡ１０（２０），ＴＨＡ１
１（２１），ＥＮ１２及び端末（ＭＮ）３を実現するた
めのそれぞれの構成について詳述する。なお、以下で
は、説明の便宜上、ＶＨＡ１０（２０），ＴＨＡ１１
（２１），ＥＮ１２及びＭＮ３は、それぞれ、単にＶＨ
Ａ，ＴＨＡ，ＥＮ，ＭＮと符号を略して表記する場合が
ある。また、これらを特に区別しない場合には、単に
「ノード」と総称する場合もある。
【０１０３】(A3.1)ＶＨＡ，ＴＨＡ，ＥＮの詳細説明 図２は上記のＶＨＡ１０（２０），ＴＨＡ１１（２１）
及びＥＮ１２の要部の詳細構成を示すブロック図で、こ
の図２に示すように、本実施形態において、ＶＨＡ１０
（２０），ＴＨＡ１１（２１）及びＥＮ１２は、それぞ
れ、共通の構成を有しており、例えば、入力処理部４
１，パケット種別識別部４２，バインディングキャッシ
ュ検索部４３，結合（バインディング）キャッシュ（Bi
nding Cache）テーブル４４，カプセル化処理部４５，
ルータ処理部４６（ルーティングテーブル４６ａ，出方
路決定部４６ｂ），出力処理部４８，タイマ処理部４９
及び制御メッセージ処理部５０をそなえて構成されてい
る。なお、この図２において、符号４３１はトラフィッ
ク種別識別部を表し、符号４３４はブリッジ部を表す
が、これらの各部の機能についてはそれぞれ第２実施形
態にて後述する。
【０１０４】ここで、入力処理部４１は、到着（受信）
パケットのＩＰレイヤ以下の処理を行なうためのもの
で、例えば、イーサネット（登録商標）であれば自ノー
ド宛のＭＡＣ（Media Access Control）アドレスが付与
されたパケットを取り込んで、そのパケットのフレーム
自体の正常性をチェックする処理を行なう機能を装備す
るものである。
【０１０５】また、パケット種別識別部４２は、この入
力処理部４１で受信された正常なパケットの種別〔主
に、制御メッセージ，マルチキャストパケット，これら
以外のパケット等〕を、そのヘッダ部分（具体的には、
ＤＡフィールド７１８）を参照して識別するためのもの
で、ここでは、上述した各種制御メッセージやマルチキ
ャストパケットは制御メッセージ処理部５０へ、それ以
外のパケットはバインディングキャッシュ検索部４３へ
それぞれ引き渡されるようになっている。
【０１０６】次に、図２に示す結合キャッシュテーブル
（以下、単に「キャッシュテーブル」ともいう）４４
は、基本的に、「MIPv6」ベースで作成される「キャッ
シュ」を端末３のホームアドレス（ＭＮホームアドレ
ス）別にテーブル形式のデータとして保持するもので、
例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによ
って構成される。ただし、このキャッシュテーブル４４
は、ＶＨＡ／ＴＨＡにおけるものと、ＥＮにおけるもの
とで保持内容が若干異なる。
【０１０７】即ち、ＶＨＡ／ＴＨＡのキャッシュテーブ
ル４４には、例えば図４（Ａ）に示すように、“COA”
（128ビット），“Lifetime”（32ビット），“Home re
gistration flag”（1ビット），“router flag”（1ビ
ット），“prefix length”（7ビット），“Sequence N
umber”（16ビット），“Rec ent Usage Information”
（1ビット），“last BR time”（128ビット）等のキャ
ッシュデータ６１ａとともに、ここでは、複数（本例で
は、最大１６台分）の「通信中ＥＮアドレス」（128ビ
ット×16）データ（拡張データ）６１ｂが保持される。
【０１０８】これは、１台の端末３に対して、複数（最
大１６台）のＥＮへ「キャッシュ」をコピーできること
を意味する。つまり、ＶＨＡ／ＴＨＡに代わってルーテ
ィングを行なえるＥＮを複数台設定することができ、Ｖ
ＨＡ／ＴＨＡの処理負荷をＥＮに分散して大幅に削減す
ることができることを意味する。さて、これに対し、Ｅ
Ｎ１２のキャッシュテーブル４４には、図４（Ｂ）に示
すように、ＶＨＡ又はＴＨＡから通知される上記のキャ
ッシュデータ６１ａとともに、「ＶＨＡ／ＴＨＡアドレ
ス」（128ビット）データ（拡張データ）６２ｂが保持
される。なお、後述するように、上記のキャッシュテー
ブル４４は、モバイルメッセージ処理部５２によって作
成（登録）され、そのエントリのうち“Lifetime”の更
新（減算）がタイマ処理部４９によって行なわれるよう
になっている。
【０１０９】つまり、ＶＨＡ／ＴＨＡにおけるキャッシ
ュテーブル４４，タイマ処理部４９及びモバイルメッセ
ージ処理部５２から成る部分は、端末３（後述する現在
位置登録手段）によって通知され登録されるCOA（現在
位置情報）を管理する端末位置管理手段としての機能を
果たしていることになり、ＶＨＡ／ＴＨＡのキャッシュ
テーブル４４は、通信中ＥＮ１２のＥＮアドレス（識別
情報）を保持するノード識別情報保持手段としての機能
も果たすことになる。
【０１１０】これに対し、ＥＮ側のキャッシュテーブル
４４は、後述するキャッシュ情報通知手段として機能す
るＶＨＡ／ＴＨＡ／他ＥＮの結合更新メッセージ作成部
５２４（図３にて後述）によって作成・発行されるキャ
ッシュ通知メッセージにより通知される「キャッシュ」
を保持するキャッシュ手段としての機能を果たすことに
なる。
【０１１１】そして、バインディングキャッシュ検索部
（以下、単に「キャッシュ検索部」ともいう）４３は、
入力パケットのＩＰヘッダ７０に含まれるＭＮ３のホー
ムアドレス（128ビット）を検索キーとして、上記のキ
ャッシュテーブル４４（データ６１ａ又は６２ａ）を検
索して現在のＭＮ３の位置情報（COA）等を取得するた
めのものである。
【０１１２】また、カプセル化処理部４５は、このキャ
ッシュ検索部４３のキャッシュ検索により得られたCOA
等の情報に基づいて受信パケットをカプセル化するもの
であり、ルータ処理部４６において、出方路決定部４６
ｂは、カプセル化されたパケット（これをトンネルパケ
ットという）に付加されたCOAを検索キーとしてルーテ
ィングテーブル４６ａに保持されているルーティング情
報を検索して、そのCOAに応じた出方路（出力インタフ
ェース）や下位レイヤでの宛先アドレス等を決定するも
のである。
【０１１３】つまり、このルータ処理部４６は、ＥＮに
おいては、キャッシュ手段としての上記キャッシュテー
ブル４４に保持されているキャッシュ情報（以下、キャ
ッシュエントリともいう）に基づきＶＨＡ／ＴＨＡ（ゲ
ートノード）に代わって端末３宛のパケットの在圏ＥＮ
へのルーティングを実施するルーティング手段として機
能するのである。
【０１１４】さらに、出力処理部４８は、決定した出力
ポートへ受信パケットを出力して次ホップ先へ転送する
もので、例えば、イーサネットの場合にはイーサネット
フレームに必要なフレームチェックシーケンス符号を付
けて、パケット（フレーム）送出を行なうようになって
いる。これにより、受信パケットはＶＨＡ１０（２０）
から所望のＴＨＡ１１（２１）（「VCOA」の場合）ま
で、あるいは、ＴＨＡ１１（２１）から所望のＥＮ１２
まで（「PCOA」の場合）正しく転送されることになる。
【０１１５】さらに、タイマ処理部４９は、上述したキ
ャッシュテーブル４４における「キャッシュ」のうちデ
ータ６１ａに含まれる“Lifetime”を前述したように更
新する機能、即ち、入力処理部４１でパケットが受信さ
れない間は“Lifetime”をデクリメントし、パケットが
受信されている間は“Lifetime”が切れない（“０”に
ならない）ように更新する機能を有するとともに、“Li
fetime”が切れたときに、該当「キャッシュ情報」を削
除する機能を有するものである。
【０１１６】次に、制御メッセージ処理部５０は、パケ
ット種別識別部４２で制御メッセージであると識別され
て入力される制御メッセージに応じた処理を実施するた
めのもので、本実施形態では、例えば図２中に示すよう
に、メッセージ種別判定部５１，モバイルメッセージ処
理部５２，ルーティングメッセージ処理部５３及びルー
タ広告（RA：Router Advertise）メッセージ処理部５４
をそなえて構成されている。ただし、このルータ広告メ
ッセージ処理部５４は、ＥＮ１２に固有の機能で、ＶＨ
Ａ１０（２０）やＴＨＡ１１（２１）には実装されてい
なくてもよい。
【０１１７】ここで、上記のメッセージ種別判定部５１
は、受信制御メッセージの種別を判定（識別）するため
のもので、ここでは、上述したモバイルメッセージとそ
れ以外のルーティングメッセージとを判別して、モバイ
ルメッセージについてはモバイルメッセージ処理部５２
へ、ルーティングメッセージについてはルーティングメ
ッセージ処理部５３へ振り分けられるようになってい
る。
【０１１８】また、モバイルメッセージ処理部５２は、
受信したモバイルメッセージの種別を判定してその種別
に応じた処理を実施するためのもので、本実施形態で
は、そのメッセージ種別として、前述したように、主
に、結合更新（Binding Update）オプションを使用し
た結合更新メッセージ（ホーム／在圏位置登録メッセー
ジ，キャッシュ更新メッセージ，キャッシュ削除要求メ
ッセージ），結合応答（Binding Ack）オプションを
使用した結合応答メッセージ（ホーム／在圏位置登録応
答メッセージ，キャッシュ通知メッセージ，キャッシュ
削除応答メッセージ，キャッシュ更新応答メッセー
ジ），結合要求（Binding Request-M3）メッセージが
ある。
【０１１９】このため、本モバイルメッセージ処理部５
２は、例えば図３に示すように、結合更新（Binding Up
date）メッセージ処理部５２Ｃ，結合応答（Binding Ac
knowledge）メッセージ処理部５２Ｄ及び結合要求（Bin
ding Request-M3）メッセージ処理部５２Ｅを有して構
成されている。ここで、上記の結合更新メッセージ処理
部５２Ｃは、上記のメッセージ種別判定部５１から入力
される結合更新メッセージに応じた処理を行なうための
もので、本実施形態では、例えば、結合キャッシュ（Bi
nding Cache）テーブルアクセス部５２１，結合更新（B
inding Update）メッセージ解析部５２２，結合応答（B
inding Acknowledge）メッセージ作成部５２３，結合更
新（Binding Update）メッセージ作成部５２４をそなえ
ている。ただし、結合更新メッセージ作成部５２４の機
能は、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）にの
み実装され、ＥＮ１２には無い。
【０１２０】ここで、上記の結合キャッシュテーブルア
クセス部５２１（以下、単に「テーブルアクセス部５２
１」と表記する）は、上述したキャッシュテーブル４４
に対してＭＮホームアドレスを検索キーとしてアクセス
しその保持内容（キャッシュ）を更新・削除することが
できるものであり、結合更新メッセージ解析部５２２
は、メッセージ種別判定部５１から入力される結合更新
メッセージの内容を解析するためのものである。
【０１２１】そして、ＶＨＡ／ＴＨＡの場合は、この結
合更新メッセージ解析部５２２での解析結果により、受
信した結合更新メッセージが端末３からのホーム／在圏
位置登録メッセージであれば、テーブルアクセス部５２
１によって、そのメッセージによって通知されるCOA
が、同じメッセージに設定されているＭＮホームアドレ
スで特定されるキャッシュテーブル４４の記憶領域（メ
モリアドレス）に書き込まれて位置登録が行なわれ、そ
れに伴って、結合更新メッセージ作成部５２４によっ
て、通信中ＥＮ１２に対するキャッシュ更新メッセージ
が作成・発行されることになる。
【０１２２】つまり、この結合更新メッセージ作成部５
２４は、端末３の移動に伴って現在位置通知手段として
機能する位置登録メッセージ作成部３４３（図６にて後
述）により端末３から新たに通知されてくる現在位置情
報（COA）に基づいて、通信中ＥＮ１２の「キャッシ
ュ」を更新するキャッシュ情報更新手段としての機能を
果たすのである。これにより、通信中ＥＮ１２のルータ
処理部４６は、更新後の「キャッシュ」に基づいて端末
３宛のパケットをＴＨＡ／ＶＨＡに代わって新たな移動
先（在圏ＥＮ１２）へ正しくルーティングすることが可
能となる。
【０１２３】また、受信した結合更新メッセージが通信
中ＥＮ１２からのキャッシュ削除要求メッセージであれ
ば、テーブルアクセス部５２１によって、そのメッセー
ジに設定されているＭＮホームアドレスを検索キーとし
て、該当「キャッシュ」（「通信中ＥＮアドレス」デー
タ６１ｂ）が削除されるとともに、結合応答メッセージ
作成部５２３によって、上記通信中ＥＮ１２宛のキャッ
シュ削除応答メッセージが作成・発行されることにな
る。
【０１２４】つまり、テーブルアクセス部５２１は、Ｅ
Ｎ１２の結合更新メッセージ作成部５２７によって作成
・発行されたキャッシュ削除要求メッセージを受ける
と、自ノード（ＶＨＡ／ＴＨＡ）のキャッシュテーブル
４４に保持している「通信中ＥＮアドレス」データ６２
ｂを削除するノード識別情報削除手段としての機能を果
たすのである。
【０１２５】これに対し、ＥＮ１２の場合は、上記の結
合更新メッセージ解析部５２２での解析結果により、受
信した結合更新メッセージがＶＨＡ１０（２０）又はＴ
ＨＡ１１（２１）からのキャッシュ更新メッセージであ
れば、テーブルアクセス部５２１によって、そのメッセ
ージによって通知されるCOAが、同じメッセージに設定
されているＭＮホームアドレスで特定されるキャッシュ
テーブル４４の記憶領域に書き込まれて、ＶＨＡ／ＴＨ
Ａで管理されているキャッシュとの同期がとられ、それ
に伴って、結合応答メッセージ作成部５２３によって、
ＶＨＡ／ＴＨＡ宛のキャッシュ更新応答メッセージが作
成・発行されることになる。
【０１２６】さて、次に、図３に示す結合応答メッセー
ジ処理部５２Ｄは、メッセージ種別判定部５１から入力
される結合応答メッセージについての受信処理を行なう
もので、そのメッセージ内容を解析して必要に応じて内
部パラメータの変更等を行なうようになっている。ま
た、結合要求メッセージ処理部５２Ｅは、メッセージ種
別判定部５１から入力される結合要求メッセージに応じ
た処理を行なうためのもので、このために、本実施形態
では、結合キャッシュ（Binding Cache）テーブルアク
セス部５２５，結合要求（Binding Request-M3）メッセ
ージ解析部５２６，結合更新（Binding Update）メッセ
ージ作成部５２７及び結合要求（Binding Request-M3）
メッセージ作成部５２８をさらにそなえている。
【０１２７】ここで、結合キャッシュテーブルアクセス
部５２５（以下、単に「テーブルアクセス部５２５」と
表記する）は、結合更新メッセージ処理部５２Ｃにおけ
るものと同様に、キャッシュテーブル４４に対してＭＮ
ホームアドレスを検索キーとしてアクセスしその保持内
容（キャッシュ）を更新することができるものであり、
結合要求メッセージ解析部５２６は、メッセージ種別判
定部５１から入力される結合要求メッセージ〔キャッシ
ュ要求（BR-M3）メッセージ〕の内容を解析するための
ものである。
【０１２８】そして、この結合要求メッセージ解析部５
２６での解析結果により、そのメッセージに設定されて
いるＭＮホームアドレスを検索キーとして、テーブルア
クセス部５２５が、キャッシュテーブル４４を検索し
て、該当キャッシュを取得し、これに伴って、結合応答
メッセージ作成部５２７が、そのキャッシュを要求元の
ノード（ＶＨＡ／ＴＨＡ／ＥＮ）に通知するキャッシュ
通知メッセージを作成・発行することになる。
【０１２９】つまり、この結合応答メッセージ作成部５
２７は、端末３宛のパケットを自己宛にルーティングし
てくるＥＮ（通信中ＥＮ）１２からキャッシュ要求（BR
-M3）メッセージを受けた場合に、キャッシュテーブル
４４で管理（保持）されているキャッシュ（COA等）を
その通信中ＥＮ１２に通知するキャッシュ情報通知手段
としての機能を果たすのである。
【０１３０】なお、この結合更新メッセージ作成部５２
７は、ＥＮ１２においては、前述したタイマ処理部４９
（図２参照）によって“Lifetime”の切れた「キャッシ
ュ」が削除された場合に、キャッシュ通知を発行したＶ
ＨＡ／ＴＨＡ／ＥＮに対して該当する「キャッシュ」
（「通信中ＥＮアドレス」データ６２ｂ）の削除を要求
するキャッシュ削除要求メッセージを発行する機能も有
する。
【０１３１】つまり、この結合更新メッセージ作成部５
２７は、ＥＮ１２の通信が終了して「キャッシュ」の有
効期限が切れると、その「キャッシュ」の「通信中ＥＮ
アドレス」データ６２ｂの削除をキャッシュ通知元のノ
ード（ＶＨＡ／ＴＨＡ／ＥＮ）に要求するノード識別情
報削除要求手段としての機能を果たすのである。また、
結合要求メッセージ作成部（キャッシュ情報要求手段）
５２８は、前記のキャッシュ検索部４３による検索の結
果、必要な「キャッシュ」がキャッシュテーブル４４に
保持されていないことが分かった場合に、ＶＨＡ／ＴＨ
Ａ／他ＥＮ宛の結合要求メッセージ（キャッシュ要求メ
ッセージ）を作成・発行するものである。
【０１３２】そして、メッセージ送信部５２Ｆは、上記
の結合応答メッセージ作成部５２３，結合更新メッセー
ジ作成部５２４，５２７及び結合要求メッセージ作成部
５２７で作成された各種メッセージをルータ処理部４６
（出力方路決定部４６ｂ；図２参照）へ送信するもの
で、これにより、各種メッセージがそれぞれ所望の出力
インタフェースを通じて次ホップ先ノードへ転送される
ことになる。
【０１３３】さて、次に、図２において、ルーティング
メッセージ処理部５３は、メッセージ種別判定部５１か
らモバイルメッセージ以外の制御メッセージであると判
定されて入力されてくるＲＩＰ（Routing Information
Protocol）等のルーティングメッセージについての処理
（例えば、網構成の変更等に伴うルーティング情報の更
新等）を実施するためのものであり、ＥＮ１２に固有の
ルータ広告メッセージ処理部５４は、在圏端末３に対す
るルータ広告を発行するためのものであるが、本実施形
態では、前述したように、ＥＮアドレスと、ＴＨＡアド
レスと、Ｍ３ネットワークアドレスとを含む「ルータ広
告」が作成・発行されるようになっている。
【０１３４】即ち、本ルータ広告メッセージ処理部５４
は、例えば図１７に示すように、ＳＡフィールド７１７
にＥＮアドレス（ルータ広告送信ノードのリンクローカ
ルアドレス）、モビリティオプション（Type:100）とし
て定義されるＭＡアドレスフィールド７２５にＴＨＡア
ドレス〔ローカルリンクにある（換言すると、ＥＮ１２
が収容されている）ＴＨＡ１１（２１）のアドレス〕、
モビリティオプション（Type:101）として定義されるＭ
３ネットワークアドレスフィールド７２６にＭ３ネット
ワークアドレスをそれぞれ格納した「ルータ広告」を作
成・発行するようになっている。
【０１３５】なお、「リンクローカルアドレス」とは、
ルータ広告送信ノード配下のリンクでしか使えないアド
レスを意味し、「ルータ広告」以外の用途にも使用され
る。 (A3.2)端末（ＭＮ）３の詳細構成説明 次に、以下では、端末３の詳細構成について説明する。
図５は上記の端末３の詳細構成を示すブロック図で、こ
の図５に示すように、本実施形態の端末３は、入力処理
部３１，ＩＰレイヤ処理部３２，パケット種別判定部３
３，モバイルメッセージ処理部３４，ルーティングメッ
セージ処理部３５，アプリケーション３６，ルーティン
グテーブル３７，出力方路決定部３８及び出力処理部３
９をそなえて構成されている。
【０１３６】ここで、上記の入力処理部３１は、最寄り
の（ローカルリンクの）ＥＮ１２からパケットを受信す
るものであり、ＩＰレイヤ処理部３２は、この入力処理
部３１から入力されるパケットについてデカプセル処理
（ただし、パケットがカプセル化されている場合のみ）
やルーティングヘッダ処理などの各種ＩＰレイヤ処理を
施すためのものである。
【０１３７】また、パケット種別判定部３３は、上記Ｉ
Ｐレイヤ処理後の受信パケットの種別（モバイルメッセ
ージ，ルーティングメッセージ等）を判定するもので、
モバイルメッセージ（この場合は、主に「ルータ広告」
やホーム／在圏位置登録応答メッセージ等）はモバイル
メッセージ処理部３４へ、ルーティングメッセージはル
ーティングメッセージ処理部３５へ、これら以外のパケ
ット（ユーザパケット等）はアプリケーション部３６へ
それぞれ振り分けられるようになっている。
【０１３８】さらに、ルーティングメッセージ処理部３
５は、モバイルメッセージ以外の制御メッセージ（ルー
ティングメッセージ）を処理するためのものであり、ア
プリケーション部３６は、制御メッセージ以外のパケッ
ト（ユーザパケット等）についての受信処理を担うもの
であり、モバイルメッセージ処理部３４は、ＥＮ１２か
ら報知されている「ルータ広告」の受信に伴う位置登録
処理やホーム／在圏位置登録応答メッセージ等について
の処理を担うものである。
【０１３９】このため、本モバイルメッセージ処理部３
４は、その要部に着目すると、例えば図６に示すよう
に、メッセージ受信部３４Ａ，メッセージ種別判断部３
４Ｂ，ルータ広告メッセージ処理部３４Ｃ，モバイルＩ
Ｐメッセージ処理部３４Ｄ及びメッセージ送信部３４Ｅ
をそなえており、ルータ広告メッセージ処理部３４Ｃ
は、さらに、情報格納レジスタ３４１，ルータ広告解析
部３４２，位置登録（Registration）メッセージ作成部
３４３及び結合更新（Binding Update）メッセージ作成
部３４４をそなえて構成されている。
【０１４０】ここで、上記のメッセージ受信部３４Ａ
は、パケット種別判定部３３から振り分けられてくるモ
バイルメッセージを受信するものであり、メッセージ種
別判断部３４Ｂは、受信モバイルメッセージが、「ルー
タ広告」及びそれ以外のモバイルＩＰメッセージのいず
れであるかを判断するもので、この場合、「ルータ広
告」はルータ広告メッセージ処理部３４Ｃへ、それ以外
のモバイルＩＰメッセージはモバイルＩＰメッセージ処
理部３４Ｄへそれぞれ転送されるようになっている。
【０１４１】そして、ルータ広告メッセージ処理部３４
Ｃにおいて、情報格納レジスタ３４１は、受信「ルータ
広告」に含まれる前記のＥＮアドレス，ＴＨＡアドレス
及びＭ３ネットワークアドレス（以下、「アドレス情
報」と総称することがある）を保持するためのものであ
り、ルータ広告解析部３４２は、上記のメッセージ種別
判断部３４Ｂから転送されてくる「ルータ広告」の内容
を解析するもので、このルータ広告解析部３４２におい
て、上記のＥＮアドレス，ＴＨＡアドレス及びＭ３ネッ
トワークアドレスが抽出されて、上記情報格納レジスタ
３４に格納されるようになっている。
【０１４２】ただし、このルータ広告解析部３４２は、
情報格納レジスタ３４に保持されている過去のアドレス
情報と、最新の受信「ルータ広告」に含まれるアドレス
情報とを比較する機能も有しており、本実施形態では、
その比較により、端末３の移動に伴ってＥＮアドレスが
変化していてもＭ３ネットワークアドレスが変化してい
なければＴＨＡアドレスを更新しないようになってい
る。
【０１４３】これにより、「HMIPv6」では、位置登録メ
ッセージ作成部３４３が、ＥＮアドレスの変化を契機
に、新しいＴＨＡアドレスをもつＴＨＡ１１（２１）宛
に在圏位置登録メッセージを作成・発行するのだが、Ｍ
３ネットワークアドレスに変化が無い限り、位置登録メ
ッセージ作成部３４３は、元のＴＨＡアドレスをもつＴ
ＨＡ１１（２１）宛の在圏位置登録メッセージを作成・
発行することになる。
【０１４４】つまり、上記のメッセージ受信部３４Ａ
は、在圏ＥＮ１２から報知される「ルータ広告」（報知
情報）を受信する報知情報受信手段としての機能を果た
し、ルータ広告解析部３４２は、このメッセージ受信部
３４Ａで受信された「ルータ広告」に含まれるＴＨＡア
ドレス（ゲートノード識別情報）が変化したか否かを監
視するゲートノード識別情報監視手段と、「ルータ広
告」に含まれるＭ３ネットワークアドレス（網識別情
報）が変化したか否かを監視する網識別情報監視手段と
しての機能を果たし、さらに、上記の位置登録メッセー
ジ作成部３４３は、上記のゲートノード識別情報監視手
段でＴＨＡアドレスの変化が検知されても網識別情報監
視手段でＭ３ネットワークアドレスの変化が検知されて
いなければ、同じＴＨＡに自己の現在位置情報（COA）
を通知する現在位置通知手段としての機能を果たすので
ある。
【０１４５】そして、これらの各手段をそなえることに
より、本実施形態のモバイルメッセージ処理部３４は、
在圏ＥＮ１２のＥＮアドレスに基づくCOA（「PCOA」）
をＶＨＡ／ＴＨＡに通知して登録する現在位置登録手段
としての機能を有していることになる。ただし、上記の
処理は端末３がローミング中の場合であって、非ローミ
ング中（つまり、ホーム網１（２）を移動している場
合）には、ＥＮアドレスの変化が検出される毎に、結合
更新メッセージ作成部３４４によって、ＶＨＡ１０（２
０）宛のホーム位置登録メッセージが作成・発行され、
ＶＨＡ１０（２０）に対して位置登録（「PCOA」の登
録）が行なわれる。つまり、端末３がホーム網１（２）
に存在する場合は、ＴＨＡ１１（２１）は使用されない
ようになっているのである。
【０１４６】このときの端末３がホーム網３内に位置し
ているか否かの判断は、ホーム網３のＭ３ネットワーク
アドレスをデフォルトアドレス（これを「Ｍ３ホームネ
ットワークアドレス」という）として情報格納レジスタ
３４１に予め格納しておき、「ルータ広告」に含まれる
Ｍ３ネットワークアドレスとの比較により行なうように
すればよい。なお、「ルータ広告」にＭ３ネットワーク
アドレスが含まれていない場合は、その網が非「Ｍ３対
応網」である（つまり、ＴＨＡが用意されていない）こ
とを意味する。
【０１４７】この場合、端末３は、既存の「MIPv6」準
拠の位置登録処理を行なうことになる。即ち、ローミン
グ先の網が非階層化網であれば、端末３は、その移動に
伴って「ルータ広告」に含まれるＥＮアドレスが変化す
る度に、自己のホーム網１（２）のＶＨＡに対して位置
登録を行ない、階層化網であれば、ＥＮアドレスが変化
する度に、ローカルリンクのＭＡに対して位置登録を行
なうことになる。なお、この場合のＶＨＡあるいはＭＡ
に対する位置登録メッセージの作成機能は、位置登録メ
ッセージ作成部３４３及び結合更新メッセージ作成部３
４４が兼用してもよいし、専用のものを別個に用意して
もよい。
【０１４８】さて次に、図６に示すモバイルＩＰメッセ
ージ処理部３４Ｄは、上述した「ルータ広告」以外のメ
ッセージ（Binding RequestやBinding Ackメッセージ
等）についての処理を担うもので、例えば、上記のホー
ム／在圏位置登録メッセージに対する応答（ホーム／在
圏位置登録応答メッセージ）等の受信処理が行なわれる
ようになっている。そして、メッセージ送信部３４Ｅ
は、上記のホーム／在圏位置登録メッセージ等を図５に
示す出力方路決定部３８へ送信するものである。なお、
これらは、モバイルＩＰ端末には標準で備わる機能であ
る。
【０１４９】次に、図５において、ルーティングテーブ
ル３７は、端末３がパケットを送信する上で必要なルー
ティング情報を保持するためのもので、このルーティン
グ情報は、上記のルーティングメッセージ処理部３５で
の受信ルーティングメッセージに応じて適宜更新される
ようになっている。なお、このルーティングテーブル３
７も、例えば、ＲＡＭやレジスタ等の所要の記憶デバイ
スによって実現される。
【０１５０】また、出力方路決定部３８は、上述したモ
バイルメッセージ処理部３４，ルーティング処理部３５
及びアプリケーション部３６から入力されるパケットの
出力先（インタフェース）を、その宛先情報（ＤＡ）と
ルーティングテーブル２７のルーティング情報とに基づ
いて決定するものであり、出力処理部３９は、この出力
方路決定部３８での決定に従って、パケットを所望の出
力インタフェースに出力するためのものである。
【０１５１】(A4)動作説明 次に、上述のごとく構成された本実施形態のパケット通
信システムの動作について詳述する。 (A4.1)端末３の動作（位置登録処理）説明 まず始めに、端末３の動作（位置登録処理）について、
図１８及び図２２を用いて説明する。なお、図１８に示
すように、ここでは、説明の便宜上、「MIPv6」のアド
レス表記を「“ネットワークアドレス”．“インタフェ
ースＩＤ”」とすることにして、端末３のホーム網１の
アドレス（Ｍ３ネットワークアドレス）を「100.50」、
ローミング先のパケット網２のＭ３ネットワークアドレ
ス）を「200.50」、ＴＨＡ１１ａ，１１ｂ，２１ａ，２
１ｂのアドレスをそれぞれ順に「10.2」，「20.2」，
「30.2」，「40.2」、ＥＮ１２（ＥＮ“１”〜“４”）
のアドレスをそれぞれ順に「1.1」，「2.1」，「3.
1」，「4.1」と仮定する。また、端末３のインタフェー
スＩＤを“３”と仮定する（従って、この場合、Ｍ３ホ
ームネットワークアドレスは「100.3」となる）。勿
論、実際のアドレス表記はこれらの表記とは異なる（例
えば、「aaaa.b.c.d」等の長い表記になる）。以上の点
は後述する図３０においても同様である。
【０１５２】さて、図１８において、まず端末３が、Ｅ
Ｎ“１”の在圏ゾーン内で移動（矢印４参照）したとす
る。このとき、端末３では、ルータ広告解析部３４２
（図６参照）が、図２２に示すように、ＥＮ“１”から
受信される「ルータ広告」のＥＮアドレス（1.1），Ｔ
ＨＡアドレス（10.2），Ｍ３ネットワークアドレス（10
0.50）を抽出し（ステップＡ１）、まず、受信したＥＮ
アドレスと情報格納レジスタ３４１に保持されているＥ
Ｎアドレスとを比較して、一致しているか否かを判定す
る（ステップＡ２）。
【０１５３】この場合、端末３は、同一ＥＮ“１”から
「ルータ広告」を受信しているので、ＥＮアドレス（1.
1）に変化は無い。従って、ルータ広告解析部３４１
は、抽出したＥＮアドレス（1.1），ＴＨＡアドレス（1
0.2），Ｍ３ネットワークアドレス（100.50）をそのま
ま情報格納レジスタ３４１に格納することになる（ステ
ップＡ２のＹｅｓルートからステップＡ５）。
【０１５４】その後、さらに、端末３が移動して、異な
るＥＮ“２”の在圏ゾーン内へ移動したとする（矢印５
参照）。すると、端末３では、受信した「ルータ広告」
に含まれるＥＮアドレスが「1.1」→「2.1」に変化する
ので、ルータ広告解析部３４２が、今度はその「ルータ
広告」に含まれるＭ３ネットワークアドレスと情報格納
レジスタ３４１に保持されているＭ３ホームネットワー
クアドレスとを比較して、それぞれが一致しているか否
かをチェックする（ステップＡ２のＮｏルートからステ
ップＡ３）。
【０１５５】この場合、図１８中に示すように、ＥＮア
ドレス及びＴＨＡアドレスは変化しているが、Ｍ３ネッ
トワークアドレスは変化しておらず、しかも、Ｍ３ホー
ムネットワークアドレスも変化していないので、ルータ
広告解析部３４２は、端末３の移動がホーム網１内の移
動であると認識し、結合更新メッセージ作成部３４４に
対してホーム位置登録メッセージの作成を依頼する。
【０１５６】これにより、結合更新メッセージ作成部３
４４は、図９に示すＳＡフィールド７１７に「PCOA」を
設定するとともにＤＡフィールド７１８にＶＨＡ１０の
アドレスを設定したホーム位置登録メッセージを作成・
発行（ステップＡ３のＹｅｓルートからステップＡ４）
して、ＶＨＡ１０に対する位置登録を実施し（図１８の
矢印５ａ参照）、「ルータ広告」により受信したＥＮア
ドレス（2.1），ＴＨＡアドレス（20.2），Ｍ３ネット
ワークアドレス（100.50）を情報格納レジスタ３４１に
格納する（ステップＡ５）。
【０１５７】なお、ＶＨＡ１０のアドレスは、端末３毎
に予め設定されている。また、「PCOA」は、前述したよ
うに、ＥＮ“２”が発行する「ルータ広告」に含まれる
ＥＮアドレスから作成される。即ち、ＥＮアドレスのネ
ットワークプレフィックス部分（本例では、「2.1」の
うちの“２”の部分）と、自己のインタフェースＩＤ
（＝“３”）とを組み合わせて「PCOA」を作成する。従
って、この場合、端末３は、「PCOA」＝“2.3”を作成
し、これがＶＨＡ１０に通知されることになる。
【０１５８】このように、本実施形態の端末３は、自己
のホーム網１（２）内に位置している間は、ＴＨＡには
位置登録は行なわず、常に、ＶＨＡに対して「PCOA」の
登録を行なう。さて、その後、さらに端末３が移動し、
図１８中に矢印６で示すように、パケット網２のＥＮ
“３”の在圏ゾーンへ移動（ローミングイン）したとす
る。すると、この場合は、端末３で受信される「ルータ
広告」に含まれるＥＮアドレスが「2.1」→「3.1」に変
化するとともに、Ｍ３ネットワークアドレスもＭ３ホー
ムネットワークアドレス（100.3）と異なるアドレス（2
00.50）に変化するので、ルータ広告解析部３４２は、
今度はその「ルータ広告」に含まれるＭ３ネットワーク
アドレスと情報格納レジスタ３４１に保持されているＭ
３ネットワークアドレスとを比較して、それぞれが一致
しているか否かをチェックする（ステップＡ２のＮｏル
ートからステップＡ３及びステップＡ３のＮｏルートか
らステップＡ６）。
【０１５９】今、「ルータ広告」に含まれるＭ３ネット
ワークアドレスは元の「100.50」から「200.50」に変化
しているので、ルータ広告解析部３４２は、端末３がパ
ケット網１，２をまたいで移動（ローミングイン）した
と認識し、位置登録メッセージ作成部３４３に対して在
圏位置登録メッセージの作成を依頼するとともに、結合
更新メッセージ作成部３４４に対してホーム位置登録メ
ッセージの作成を依頼する。
【０１６０】これにより、結合更新メッセージ作成部３
４４は、図９に示すＳＡフィールド７１７に「VCOA」を
設定するとともにＤＡフィールド７１８にＶＨＡ１０の
アドレスを設定したホーム位置登録メッセージを作成・
発行して、ＶＨＡ１０に対する位置登録を実施する（図
１８の矢印６ａ参照）。なお、このときの「VCOA」は、
ＴＨＡアドレス（30.2）のネットワークプレフィックス
部分（“３０”）と、端末３のインタフェースＩＤ（＝
“３”）との組み合わせにより作成されるから、「30.
3」となる。
【０１６１】一方、位置登録メッセージ作成部３４３
は、図１１に示すＳＡフィールド７１７に「PCOA」（3.
3）を設定するとともにＤＡフィールド７１８にＴＨＡ
アドレス（30.2）を設定した在圏位置登録メッセージを
作成・発行して、ＴＨＡ２１ａに対する位置登録を実施
する（図１８の矢印６ｂ参照）。つまり、端末３は、パ
ケット網１，２をまたぐ移動（ローミングイン）を行な
うと、ホーム網１のＶＨＡ１０とローミング先の最寄り
のＥＮ１２を収容するＴＨＡ２１ａとのそれぞれに対し
て位置登録を行なうのである（以上、ステップＡ６のＮ
ｏルートからステップＡ７）。
【０１６２】なお、ルータ広告解析部３４２は、上記の
各メッセージの作成依頼後、この場合も、「ルータ広
告」から抽出したＥＮアドレス（3.1），ＴＨＡアドレ
ス（30.2），Ｍ３ネットワークアドレス（200.50）をそ
れぞれ情報格納レジスタ３４１に格納（保持しているア
ドレス情報を更新）する（ステップＡ５）。さて、次
に、端末３がローミング先のパケット網２内においてさ
らに移動し、異なるＥＮ“４”の在圏ゾーンに移動した
とする。すると、この場合は、端末３で受信される「ル
ータ広告」に含まれるＥＮアドレスが「3.1」→「4.1」
に変化するが、Ｍ３ネットワークアドレスはＭ３ホーム
ネットワークアドレス（100.3）と異なる「200.50」の
ままであるので（ステップＡ２及びＡ３でＮｏと判定さ
れ、且つ、ステップＡ６でＹｅｓと判定されるので）、
ルータ広告解析部３４２は、位置登録メッセージ作成部
３４３に対して在圏位置登録メッセージの作成を依頼す
る。
【０１６３】これにより、位置登録メッセージ作成部３
４３は、図１１に示すＳＡフィールド７１７に「PCOA」
（4.3）を設定するとともにＤＡフィールド７１８に情
報格納レジスタ３４１に保持されている元のＴＨＡアド
レス（30.2）を設定した在圏位置登録メッセージを作成
・発行して、同じＴＨＡ２１ａに対する位置登録を実施
する（ステップＡ８；図１８の矢印７ａ参照）。そし
て、ルータ広告解析部３４２は、「ルータ広告」により
受信したＥＮアドレス（4.1），ＴＨＡアドレス（40.
2），Ｍ３ネットワークアドレス（200.50）をそれぞれ
情報格納レジスタ３４１に格納（保持しているアドレス
情報を更新）する（ステップＡ５）。
【０１６４】つまり、本実施形態の端末３は、既存の
「HMIPv6」準拠のシステムであれば「ルータ広告」に含
まれるＥＮアドレスが変化しているので同じ「ルータ広
告」に含まれるＴＨＡアドレス（40.2）をもつＴＨＡ２
１ｂに対して位置登録を行なう（位置登録先のＴＨＡを
切り替える）ところであるが、ＥＮアドレスに変化があ
っても、Ｍ３ネットワークアドレスに変化がないと、最
初に位置登録を行なったＴＨＡ２１ａに対して位置登録
を行ない、その移動に関わらず、同じＴＨＡ２１ａを位
置登録先として使い続けるのである。
【０１６５】これは、ローミング中に端末３がホーム網
１のＶＨＡ１０へ位置登録を行なうのはパケット網２へ
ローミングインしたときだけで良いということを意味す
る。従って、既存の「HMIPv6」準拠のシステムのよう
に、ＭＡが切り替わる度にホーム網１のＶＨＡ１０へ位
置登録する必要がないので、端末３のローミング中のハ
ンドオーバ時間が大幅に短縮されることになる。
【０１６６】(A4.2)ＶＨＡ／ＴＨＡの動作説明 さて次に、以下では、ＶＨＡ／ＴＨＡ側の動作につい
て、図２３及び図２４を用いて説明する。まず、図２３
に示すように、ＶＨＡ／ＴＨＡでは、パケットを受信す
ると、入力処理部４１においてその正常性がチェックさ
れたのち（ステップＢ１）、パケット種別識別部４２に
おいて、ＤＡフィールド７１８に設定されている宛先ア
ドレスが抽出される（ステップＢ２）。そして、パケッ
ト種別識別部４２は、抽出したアドレスの先頭が“０ｘ
ＦＦ”であるか否かをチェックし（ステップＢ３）、
“０ｘＦＦ”であればその受信パケットはマルチキャス
トパケットであるので、制御メッセージ処理部５０へ転
送する（ステップＢ３のＹｅｓルートからステップＢ
４）。
【０１６７】一方、抽出した宛先アドレスが“０ｘＦ
Ｆ”以外の値であれば、パケット種別識別部４２は、次
に、宛先アドレスのプレフィックス部分（上位６４ビッ
ト）が自ＶＨＡ／ＴＨＡアドレスのプレフィックス部分
と一致するか否かをチェックし（ステップＢ３のＮｏル
ートからステップＢ５）、一致していなければ、その受
信パケットは他ドメイン向けパケットであるので、その
ままルータ処理部４６ａへ転送する（ステップＢ５のＮ
ｏルートからステップＢ６）。
【０１６８】これに対し、宛先アドレスのプレフィック
ス部分が自ＶＨＡ／ＴＨＡアドレスのプレフィックス部
分と一致した場合は、パケット種別識別部４２は、次
に、宛先アドレス（下位６４ビット）が自ＶＨＡ／ＴＨ
Ａアドレスと一致するか否かをチェックし（ステップＢ
５のＹｅｓルートからステップＢ７）、一致すれば、そ
の受信パケットは自ＶＨＡ／ＴＨＡ宛のパケット（つま
り、制御メッセージ）であるので、制御メッセージ処理
部５０へ転送する（ステップＢ７のＹｅｓルートからス
テップＢ８）。
【０１６９】一方、宛先アドレス（下位６４ビット）が
自ＶＨＡ／ＴＨＡアドレスと一致しない場合は、パケッ
ト種別識別部４２は、次に、受信パケットの宛先オプシ
ョンを参照してそのパケットがキャッシュ要求（BR-M
3）メッセージ（Option Type=16）であるか否かをチェ
ックする（ステップＢ７のＮｏルートからステップＢ
９）。
【０１７０】その結果、受信パケットがBR-M3メッセー
ジである場合は、パケット種別識別部４２は、その受信
パケットを制御メッセージ処理部５０へ転送し（ステッ
プＢ１０のＹｅｓルートからステップＢ１１）、BR-M3
メッセージでなければ、キャッシュ検索部４３に受信パ
ケットを転送する。キャッシュ検索部４３は、このよう
に転送されてきたパケットのＤＡフィールド７１８に設
定されている宛先アドレスを検索キーとして、キャッシ
ュテーブル４４を検索する（ステップＢ１０のＮｏルー
トからステップＢ１２）。
【０１７１】この検索の結果、該当宛先アドレス（CO
A）がキャッシュテーブル４４に登録されていなけれ
ば、キャッシュ検索部４３は、宛先が見つからないの
で、ソフトウェア（図示省略）にパケットを引き渡し、
当該ソフトウェアは、例えばICMP（Internet Control M
essage Protocol）に従ってパケットの送信元に対して
宛先が見つからない旨のエラーメッセージを発行する
（ステップＢ１３のＮｏルートからステップＢ１４）。
【０１７２】これに対し、受信パケットの宛先アドレス
がキャッシュテーブル４４に登録されていれば（キャッ
シュヒットすれば）、キャッシュ検索部４３は、受信パ
ケットをカプセル化処理部４５に転送し、カプセル化処
理部４５は、キャッシュヒットしたCOAをＤＡ，受信パ
ケット（オリジナルパケット）のＳＡフィールド７１７
に設定されていたアドレスをＳＡとするヘッダをオリジ
ナルパケットに付加してカプセル化する（ステップＢ１
３のＹｅｓルートからステップＢ１５）。
【０１７３】そして、カプセル化されたパケット（トン
ネルパケット）は、ルータ処理部４６へ出力され、ルー
タ処理部４６では、図２９に示すように、出力方路決定
部４６ｂが、そのトンネルパケットのＤＡを抽出し（ス
テップＧ１）、そのＤＡを検索キーとしてルーティング
テーブル４６ａのルーティング情報を検索する（ステッ
プＧ２）ことにより、ＤＡに応じた出力インタフェース
を決定し（ステップＧ３）、出力処理部４８へ送信する
（ステップＧ４）。これにより、トンネルパケットは、
決定した出力インタフェースを通じてそのＤＡに応じた
次ホップ先ノード（ＥＮ／ＭＮ）へ送信されることにな
る（ステップＢ１６）。
【０１７４】次に、制御メッセージ処理部５０での処理
について、図２４に示すフローチャートを参照しながら
詳述する。まず、制御メッセージ処理部５０では、上記
のステップＢ４やＢ８，Ｂ１１によりパケット種別識別
部４２から転送されてくる制御メッセージの種別をメッ
セージ種別判定部５１にて判定する。即ち、メッセージ
種別判定部５１は、受信した制御メッセージのメッセー
ジ種別（宛先オプション）を抽出し（ステップＣ１）、
そのメッセージ種別が結合更新メッセージ，結合応答メ
ッセージ，結合要求メッセージのいずれであるかをチェ
ックする（ステップＣ２〜Ｃ４）。
【０１７５】その結果、受信制御メッセージがモバイル
メッセージ以外のメッセージ（ルーティングメッセージ
等）であれば（ステップＣ２〜Ｃ４でいずれもＮｏと判
定された場合）、メッセージ種別判定部５１は、そのメ
ッセージをルーティングメッセージ処理部５３へ転送
し、ルーティングメッセージ処理部５３においてそのメ
ッセージ内容に応じた処理が実施される（ステップＣ２
４）。
【０１７６】これに対し、受信制御メッセージが、例え
ば、結合更新メッセージ（Option Type=198）であるこ
とが分かると、メッセージ種別判定部５１は、そのメッ
セージを結合更新メッセージ処理部５２Ｃ（結合更新メ
ッセージ解析部５２２）へ転送する。結合更新メッセー
ジ解析部５２２は、受信した結合更新メッセージのリザ
ーブビットが“１”になっているか（つまり、受信した
結合更新メッセージがキャッシュ削除要求メッセージ
か）否かをチェックし（ステップＣ２のＹｅｓルートか
らステップＣ５）、リザーブビットが“０”になってい
れば、キャッシュ削除要求メッセージ以外の結合更新メ
ッセージ（つまり、ホーム／在圏位置登録メッセージ）
であるので、さらに、その結合更新メッセージに対する
ステータス判定（フォーマットの正常性確認等）を行な
う（ステップＣ５のＮｏルートからステップＣ６）。
【０１７７】その結果、受信した結合更新メッセージが
正常であれば、結合更新メッセージ解析部５２２は、テ
ーブルアクセス部５２１に指示を与えてキャッシュテー
ブル４４を更新させる。即ち、この場合、受信した結合
更新メッセージはホーム／在圏位置登録メッセージであ
るので、テーブルアクセス部５２１は、そのＳＡフィー
ルド７１７に設定されているCOA（VCOA/PCOA）を、ホー
ムアドレスフィールド７２４に設定されているＭＮホー
ムアドレスを検索キーとして特定されるキャッシュテー
ブル４４の記憶領域に書き込んで該当「キャッシュ」
〔データ６１ａ；図４（Ａ）参照〕を更新する（ステッ
プＣ６のＹｅｓルートからステップＣ７）。
【０１７８】そして、結合更新メッセージ解析部５２２
は、受信した上記の結合更新メッセージのＡビットが
“１”が設定されている、つまり、そのメッセージに対
して応答が必要か否かをチェックし（ステップＣ８）、
Ａビットが“１”に設定されていれば（ステップＣ８で
Ｙｅｓであれば）、結合応答メッセージ作成部５２３に
対して、上記の結合更新メッセージに対する結合応答メ
ッセージ（ホーム／在圏位置登録応答メッセージ）の作
成を依頼し、これを受けて、結合応答メッセージ作成部
５２３が、端末３宛のホーム／在圏位置登録応答メッセ
ージを作成する（ステップＣ９）。
【０１７９】作成されたメッセージは、メッセージ送信
部５２Ｆを通じてルータ処理部４６（出力方路決定部４
６ｂ）へ転送され（ステップＣ１０）、これにより、ホ
ーム／在圏位置登録応答メッセージの発行元の端末３へ
本メッセージが通知されることになる。つまり、図１８
及び図２２により上述したように、端末３からその移動
に伴って発行されるホーム／在圏位置登録メッセージ
は、ＶＨＡ／ＴＨＡにおいて、図２３により上述したス
テップＢ１，Ｂ２、ステップＢ３のＮｏルート、ステッ
プＢ５のＮｏルート，ステップＢ７のＹｅｓルート、図
２４により上述したステップＣ１、ステップＣ２のＹｅ
ｓルート、ステップＣ５のＮｏルート、ステップＣ６の
ＹｅｓルートからステップＣ７、ステップＣ８のＹｅｓ
ルートからステップＣ９，Ｃ１０及びステップＣ１１の
Ｎｏルートを通るアルゴリズムによって処理されるので
ある。
【０１８０】さて、次に、結合更新メッセージ解析部５
２２は、上記のステップＣ７において更新を行なった
「キャッシュ」（データ６１ａ）に対応する通信中ＥＮ
アドレスデータ６２ｂ〔図４（Ａ）参照〕が存在するか
否かをチェックし（ステップＣ１１）、存在しなけれ
ば、自己（ＶＨＡ／ＴＨＡ）の「キャッシュ」を受けて
自己の代わりに通信を行なっている通信中ＥＮ１２は存
在せず、ＥＮ１２に対するキャッシュ更新要求は行なわ
なくて良いので、そのまま処理を終了する（ステップＣ
１１のＮｏルート）。
【０１８１】これに対し、通信中ＥＮアドレスデータ６
１ｂが１つでも存在すれば、結合更新メッセージ解析部
５２２は、受信した結合更新メッセージのＳＡフィール
ドに設定されていたCOA（VCOA/PCOA）と更新前の「キャ
ッシュ」のCOAとが一致するか否か（つまり、COAが変化
したか否か）をさらにチェックする（ステップＣ１１の
ＹｅｓルートからステップＣ１２）。
【０１８２】その結果、COAが変化していなければ（ス
テップＣ１２でＹｅｓであれば）、通信中ＥＮ１２のも
つ「キャッシュ」を更新する必要はないので、結合更新
メッセージ解析部５２２は、そのまま処理を終える（ス
テップＣ１２のＹｅｓルート）が、COAが変化していれ
ば（ステップＣ１２でＮｏであれば）、更新の必要があ
るので、結合更新メッセージ作成部５２４に対して通信
中ＥＮ１２宛の結合更新メッセージ（キャッシュ更新要
求メッセージ）の作成を依頼する。
【０１８３】これを受けて、結合更新メッセージ作成部
５２４は、上記の通信中ＥＮアドレスをＤＡフィールド
７１８としてもつキャッシュ更新要求メッセージを作成
・発行する（ステップＣ１３）。つまり、ＶＨＡ／ＴＨ
Ａは、「通信中ＥＮアドレス」をキャッシュテーブル４
４に保持しておき、端末３の移動に伴ってその端末３か
ら新たな現在位置情報（COA）の通知を受けると、その
新たな現在位置情報に基づいて、「通信中ＥＮアドレ
ス」によって識別される通信中ＥＮに対してその「キャ
ッシュ」の更新を実施するのである。
【０１８４】これにより、ＶＨＡ／ＴＨＡは、「キャッ
シュ」を更新すべきＥＮを誤ることなく正確に所望のＥ
Ｎの「キャッシュ」を更新することができる。また、端
末３の移動（位置登録）に伴って新たな現在位置情報
（COA）がＶＨＡ／ＴＨＡに通知されることによりＶＨ
Ａ／ＴＨＡ側の「キャッシュ」が更新される都度、その
更新が通信中ＥＮ１２側の「キャッシュ」に反映され
て、相互の同期がとられることになる。
【０１８５】従って、通信中ＥＮは、更新後の「キャッ
シュ」に基づいて端末３宛のパケットルーティングを行
なうことにより、引き続きＶＨＡ／ＴＨＡに代わって新
たな在圏ＥＮ（端末３の移動先ＥＮ）へのパケットルー
ティングを行なうことが可能であり、常に、端末３宛の
パケットを端末３の移動先へ正しく届けることができ
る。
【０１８６】ところで、上記のステップＣ５において、
受信した結合更新メッセージのリザーブビットが“１”
になっていた場合は、そのメッセージはキャッシュ削除
要求メッセージ（図１６参照）を意味するので、結合更
新メッセージ解析部５２２は、さらに、その受信メッセ
ージのライフタイムが“０”に設定されているか否かを
チェックする（ステップＣ５のＹｅｓルートからステッ
プＣ１４）。
【０１８７】その結果、ライフタイムが“０”に設定さ
れていれば、結合更新メッセージ解析部５２２は、その
キャッシュ削除要求メッセージのホームアドレスフィー
ルド７２４に設定されているＭＮホームアドレスをテー
ブルアクセス部５２１に通知して該当「キャッシュ」
（「通信中ＥＮアドレス」データ６２ｂ）の削除を依頼
する。
【０１８８】これにより、テーブルアクセス部５２１
は、通知されたＭＮアドレスキーにして、キャッシュテ
ーブル４４を検索して該当「通信中ＥＮアドレス」デー
タ６２ｂを削除する（ステップＣ１４のＹｅｓルートか
らステップＣ１５）。なお、上記のライフタイムが
“０”以外の値に設定されている場合は、このテーブル
アクセス部５２１によるキャッシュ削除処理は実施され
ない（ステップＣ１４のＮｏルート）。
【０１８９】次いで、結合更新メッセージ解析部５２２
は、上記の受信メッセージのＡビットが“１”になって
いるかをチェックし（ステップＣ１６）、“１”になっ
ていなければ、自ＶＨＡ／ＴＨＡでその受信メッセージ
に対する応答メッセージを発行する必要が無いので、そ
のまま処理を終える（ステップＣ１６のＮｏルート）。
【０１９０】一方、Ａビットが“１”になっていれば、
自ＶＨＡ／ＴＨＡで応答メッセージを発行する必要があ
るので、結合更新メッセージ解析部５２２は、結合応答
メッセージ作成部５２３に対して結合応答メッセージ
（キャッシュ削除要求応答メッセージ）の作成を依頼
し、結合応答メッセージ作成部５２３は、受信メッセー
ジのＳＡをＤＡとするキャッシュ削除要求応答メッセー
ジを作成する（ステップＣ１６のＹｅｓルートからステ
ップＣ１７）。
【０１９１】これにより、作成されたキャッシュ削除要
求応答メッセージは、メッセージ送信部５２Ｆを通じ
て、ルータ処理部４６（出力方路決定部４６ｂ）へ転送
され、出力方路決定部４６ｂにおいてそのメッセージの
出力インタフェースが決定されて、決定した出力インタ
フェースを通じて次ホップ先ノードへルーティングされ
る（ステップＣ１８）。
【０１９２】さて、以上は結合更新メッセージを受信し
た場合の処理（ＶＨＡ／ＴＨＡの動作）であるが、結合
応答メッセージ，結合要求（BR-M3）メッセージを受信
した場合の処理は次のようになる。即ち、メッセージ種
別判定部５１において、受信メッセージが結合応答メッ
セージ（Option Type＝７）であると判断されると、そ
のメッセージは結合応答メッセージ処理部５２Ｄに転送
され、結合応答メッセージ処理部５２Ｄにて処理される
（ステップＣ３のＹｅｓルートからステップＣ１９）。
なお、この場合、ＶＨＡ／ＴＨＡが受信しうる結合応答
メッセージは、キャッシュ更新応答メッセージ（図１３
参照）である。
【０１９３】これに対し、メッセージ種別判定部５１に
おいて、受信メッセージがBR-M3メッセージであると判
断された場合は、そのBR-M3メッセージは結合要求メッ
セージ処理部５２Ｅ（結合要求メッセージ解析部５２
６）に転送される。すると、結合要求メッセージ解析部
５２６は、受信したBR-M3メッセージの内容を解析し、
ホームアドレスフィールド７２４に設定されているＭＮ
ホームアドレスを抽出してテーブルアクセス部５２５に
そのＭＮホームアドレスを通知する。
【０１９４】これにより、テーブルアクセス部５２５
は、通知されたＭＮホームアドレスをキーにしてキャッ
シュテーブル４４を検索して、該当「キャッシュ」〔受
信BR-M3メッセージのＳＡと同一のキャッシュデータ（C
OA）〕が存在するかをチェックする（ステップＣ４のＹ
ｅｓルートからステップＣ２５）。その結果、キャッシ
ュテーブル４４に該当「キャッシュ」が存在しなけれ
ば、テーブルアクセス部５２５は、そのまま処理を終え
る（ステップＣ２５のＮｏルート）一方、「キャッシ
ュ」が存在すれば、「キャッシュ」に登録されているCO
Aを保持しておき、さらに、BR-M3メッセージのＳＡと同
じ「通信中ＥＮアドレス」が該当するキャッシュエント
リに存在するか否かを検索する（ステップＣ２５のＹｅ
ｓルートからステップＣ２０）。
【０１９５】この検索の結果、BR-M3メッセージのＳＡ
と同じ「通信中ＥＮアドレス」が存在すれば、テーブル
アクセス部５２５は、その「通信中ＥＮアドレス」と保
持しておいたCOAとを読み出し（ステップＣ２６）、結
合要求メッセージ解析部５２６へ渡す。これにより、結
合要求メッセージ解析部５２６は、受け取った情報（CO
A，「通信中ＥＮアドレス」）を結合更新メッセージ作
成部５２７に転送して結合更新メッセージ（キャッシュ
通知メッセージ）の作成を依頼する（ステップＣ２１の
ＹｅｓルートからステップＣ２３）。なお、上記のステ
ップＣ２０において、「通信中ＥＮアドレス」が未登録
であれば、その時点で、BR-M3メッセージのＳＡを「通
信中ＥＮアドレス」として新規登録する。
【０１９６】一方、「キャッシュ」が存在しない場合
（ステップＣ２１でＮｏの場合）、結合要求メッセージ
解析部５２６は、受信メッセージのＳＡをキャッシュし
て（ステップＣ２２）、結合更新メッセージの作成を結
合更新メッセージ作成部５２７に依頼する（ステップＣ
２３）。 (A4.3)ＥＮの動作説明 次に、本実施形態のＥＮの動作について、図２５〜図２
９を参照しながら詳述する。
【０１９７】まず、ＥＮでは、図２５に示すように、パ
ケットを受信すると、その受信パケットの正常性が入力
処理部４１にてチェックされたのち（ステップＤ１）、
パケット種別識別部４２において、そのＤＡが抽出され
て（ステップＤ２）、そのＤＡの先頭が“０ｘＦＦ”に
なっている（つまり、マルチキャストパケットを表示し
ている）か否かがチェックされる（ステップＤ３）。
【０１９８】その結果、受信パケットがマルチキャスト
パケットであれば、パケット種別識別部４２は、そのパ
ケットを制御メッセージ処理部５０へ転送する（ステッ
プＤ３のＹｅｓルートからステップＤ３′）が、マルチ
キャストパケットでなければ、次に、抽出したＤＡのプ
レフィックス部分（上位６４ビット）と自己のＥＮアド
レスのプレフィックス部分とを比較して一致しているか
否かをチェックする（ステップＤ３のＮｏルートからス
テップＤ４）。
【０１９９】この比較の結果、上記の各プレフィックス
部分が互いに一致していれば、パケット種別識別部４２
は、自ＥＮが所属する自ドメイン向けのパケットである
と認識して、さらに、そのＤＡと自己のＥＮアドレスの
下位６４ビット同士を比較して一致するか否かをチェッ
クし（ステップＤ５）、一致していれば、その受信パケ
ットは自ＥＮ宛の制御メッセージであるので、その受信
パケットを制御メッセージ処理部５０へ転送し（ステッ
プＤ５のＹｅｓルートからステップＤ６′）、一致して
いなければ、次に、受信パケットがBR-M3メッセージで
あるか否かをチェックする（ステップＤ５のＮｏルート
からステップＤ６）。
【０２００】その結果、受信パケットがBR-M3メッセー
ジであれば、パケット種別識別部４２は、ソフトウェア
（図示省略）へ受信パケットを引き渡し、これにより、
当該ソフトウェアは、ＤＡを受信パケットのＳＡ，ＳＡ
を自ＥＮアドレスとする結合更新メッセージ（キャッシ
ュ通知メッセージ）を作成する（ステップＤ７のＹｅｓ
ルートからステップＤ８）。
【０２０１】ただし、このとき作成されるキャッシュ通
知メッセージは、上記のBR-M3メッセージを発行したＥ
Ｎ１２がその後にパケットを受信する度に「キャッシ
ュ」が無いことを理由に何度もBR-M3メッセージを発行
してしまうことを防止することを目的としており、この
キャッシュ通知メッセージを受けた送信元ＥＮ１２で
は、そのメッセージに基づいてダミーの「キャッシュ」
（以下、「ダミーキャッシュ」という）を作成すること
になる。この「ダミーキャッシュ」は、例えば、検索キ
ーと登録データとを同一の値に設定しておくことで、通
常のキャッシュエントリとは区別する。もしくは、特定
のビットを使って識別できるようにしてもよい。
【０２０２】一方、受信パケットがBR-M3メッセージで
なければ、その受信パケットは端末３宛のパケットであ
るので、パケット種別識別部４２は、受信パケットをキ
ャッシュ検索部４３へ転送し、キャッシュ検索部４３
は、その受信パケットのＤＡを検索キーとしてキャッシ
ュテーブル４４を検索する（ステップＤ７のＮｏルート
からステップＤ９）。
【０２０３】その結果、該当「キャッシュ」がキャッシ
ュテーブル４４に登録されていなければ、キャッシュ検
索部４３は、受信パケットをそのまま（カプセル化処理
部４５でカプセル化せずに）ルータ処理部４６へ転送す
る（ステップＤ１０のＮｏルートからステップＤ１
１）。これに対し、該当「キャッシュ」がキャッシュテ
ーブル４４に登録されていれば、キャッシュ検索部４３
は、受信パケットのＤＡと検索により得られた「キャッ
シュ」のCOAとを比較して両者が一致するか否かをチェ
ックし（ステップＤ１０のＹｅｓルートからステップＤ
１２）、両者が一致しなければ、端末３が既に他のＥＮ
の在圏ゾーンへ移動しており、上記の「キャッシュ」が
新たに作成されている状態を意味するので、受信パケッ
トをカプセル化処理部４５へ転送する。
【０２０４】カプセル化処理部４５は、受信パケット
に、ＤＡを上記のキャッシュ検索により得られたCOA，
ＳＡを自ＥＮアドレスとするヘッダを付加して受信パケ
ットをカプセル化する（ステップＤ１２のＮｏルートか
らステップＤ１３）。これにより、端末３宛のパケット
は端末３の移動先の新たなＥＮへ正しく転送されること
になる。なお、受信パケットのＤＡと検索により得られ
た「キャッシュ」のＤＡ（COA）とが一致すれば、それ
はダミーキャッシュを意味しており、受信パケットはカ
プセル化されない（ステップＤ１２のＹｅｓルート）。
【０２０５】そして、キャッシュ検索部４３は、上記の
「キャッシュ」に含まれるライフタイムが切れない
（“０”にならないように）更新（リフレッシュ）する
（ステップＤ１４）。なお、このとき更新する値は予め
ＥＮ毎に設定されており、キャッシュ検索部４３は、そ
の設定値にライフタイムを設定することになる。ただ
し、リフレッシュ後のライフタイムが現在のライフタイ
ムよりも小さくなるような場合には、現在のライフタイ
ムに維持する。
【０２０６】また、ルータ処理部４６では、出力方路決
定部４６ｂにおいて、受信パケット（トンネルパケット
又はカプセル化されなかった受信パケット）のＤＡを検
索キーとしてルーティングテーブル４６ａを検索して、
その受信パケットの出力インタフェースを決定し（ステ
ップＤ１５）、出力処理部４８へ送信する（図２９に示
すステップＧ１〜Ｇ４）。これにより、受信パケットは
そのＤＡに応じた出力インタフェースを通じて次ホップ
先ノードへルーティングされる。
【０２０７】ところで、上記のステップＤ４において、
受信パケットのＤＡのプレフィックス部分と自ＥＮアド
レスのプレフィックス部分とが一致しなかった場合（つ
まり、受信パケットが他ドメイン向けのパケットである
場合）、パケット種別識別部４２は、図２６に示すよう
に、さらに、その受信パケットがBR-M3メッセージであ
るか否かをチェックする（ステップＤ１６）。
【０２０８】その結果、受信パケットがBR-M3メッセー
ジでれば、そのメッセージは他ドメイン向けのBR-M3メ
ッセージであることが分かるので、キャッシュ検索部４
３が、そのBR-M3メッセージのＤＡを検索キーにしてル
ーティングテーブル４６ａを検索し（ステップＤ１７の
ＹｅｓルートからステップＤ１８）、出力インタフェー
スが「Ｍ３対応網」以外へのインタフェースであるか否
かをチェックする（ステップＤ１９）。
【０２０９】その結果、出力インタフェースが「Ｍ３対
応網」以外へのインタフェースである場合、つまり、BR
-M3メッセージを受けても対応できない網へのインタフ
ェースである場合、キャッシュ検索部４３は、ソフトウ
ェアへパケットを引き渡し、当該ソフトウェアによって
受信パケットのＳＡをＤＡ，ＳＡを自ＥＮアドレスとす
る結合更新メッセージ（キャッシュ通知メッセージ）を
作成させる（ステップＤ１９のＹｅｓルートからステッ
プＤ２０）。
【０２１０】これにより、この場合も、受信したBR-M3
メッセージの発行元ＥＮに対してキャッシュ通知メッセ
ージが送信されて、当該発行元ＥＮにおいて、「ダミー
キャッシュ」が作成されることになる。つまり、この処
理を行なうＥＮ１２は、「Ｍ３対応網」以外の網とのゲ
ートウェイ機能を提供するゲートノードでもあることを
意味する。
【０２１１】一方、出力インタフェースが「Ｍ３対応
網」へのインタフェースである場合は、次ホップ先ノー
ドが「Ｍ３対応網」対応のノード（ＥＮ）であり、自Ｅ
Ｎ１２が「Ｍ３対応網」内の中継ノードとしての役割を
果たすことを意味するので、キャッシュ検索部４３は、
受信パケットをルータ処理部４６へ転送する（ステップ
Ｄ１９のＮｏルートからステップＤ２１）。
【０２１２】なお、上記のステップＤ１７において、受
信パケットがBR-M3メッセージでなかった場合、パケッ
ト種別識別部４２は、その受信パケットをキャッシュ検
索部４３へ転送し、キャッシュ検索部４３は、その受信
パケットのＤＡを検索キーとしてキャッシュテーブル４
４を検索する（ステップＤ１７のＮｏルートからステッ
プＤ２２）。
【０２１３】その結果、該当「キャッシュ」が登録され
ていれば、受信パケットは他ドメインの端末３向けのパ
ケットを意味するので、図２５により上述したステップ
Ｄ１２以降の処理が実施されて、ルータ処理部４６にお
いてその出力インタフェースが決定されて、決定した出
力インタフェースを通じて次ホップ先ノードへルーティ
ングされる（ステップＤ２３のＹｅｓルートから図２５
に示すステップＤ１２〜Ｄ１５）。
【０２１４】一方、該当「キャッシュ」が登録されてい
なければ、キャッシュ検索部４３は、この場合も、受信
パケットのＤＡを検索キーとしてルーティングテーブル
４６ａを検索し（ステップＤ２３のＮｏルートからステ
ップＤ２４）、その受信パケットの出力インタフェース
が「Ｍ３対応網」以外へのインタフェースであるか否か
をチェックする（ステップＤ２５）。
【０２１５】この結果、出力インタフェースが「Ｍ３対
応網」へのインタフェースであれば（ステップＤ２５で
Ｎｏと判定されれば）、キャッシュ検索部４３は、モバ
イルメッセージ処理部５２における結合要求メッセージ
処理部５２Ｅの結合要求メッセージ作成部５２８（図３
参照）へBR-M3メッセージの作成を依頼する（ステップ
Ｄ２７）。このようにして、通信中ＥＮは、端末３宛の
パケットをＶＨＡ／ＴＨＡへルーティングする際に「キ
ャッシュ」が無いと、そのＶＨＡ／ＴＨＡへ「キャッシ
ュ」を要求するのである。なお、出力インタフェースが
非「Ｍ３対応網」へのものである場合（ステップＤ２５
でＹｅｓの場合）、キャッシュ検索部４３は、ルータ処
理部４６へ受信パケットを引き渡す（ステップＤ２
６）。
【０２１６】この要求を受けた結合要求メッセージ作成
部５２８は、受信パケットのＤＡをＤＡ，ＳＡを自ＥＮ
アドレスとするBR-M3メッセージを作成し、メッセージ
送信部５２Ｆを通じてルータ処理部４６へ転送する（ス
テップＤ２７，Ｄ２８）。これにより、ＶＨＡ／ＴＨＡ
／ＥＮに対してキャッシュ要求が行なわれ、必要な「キ
ャッシュ」がそのＶＨＡ／ＴＨＡ／ＥＮからキャッシュ
通知メッセージにより通知されてくることになる。
【０２１７】なお、この例は、各ＥＮがＶＨＡ／ＴＨＡ
アドレスを知らないことを前提として場合であるため、
BR-M3メッセージを作成するときのＤＡには、ＥＮが受
信したパケットのＤＡを設定しているが、予めＥＮがＶ
ＨＡ／ＴＨＡアドレスを知っている場合は、そのアドレ
スをＤＡに設定すればよい。ところで、ＥＮ１２のタイ
マ処理部４９では、上記のメッセージ処理やルーティン
グ処理等とは独立して、図２８に示すタイマ処理が行な
われている。即ち、タイマ処理部４９は、キャッシュテ
ーブル４４のアドレスを例えば昇順あるいは降順に順次
指定して（ステップＦ１）、該当「キャッシュ」のライ
フタイムを順番に取得し（ステップＦ２）、そのライフ
タイムを１減算した上で（ステップＦ３）、ライフタイ
ムが“０”になったか否かをチェックする（ステップＦ
４）。
【０２１８】その結果、ライフタイムが“０”になって
いれば、その「キャッシュ」の有効期限が切れたことに
なるので、タイマ処理部４９は、モバイルメッセージ処
理部５２の結合更新メッセージ作成部５２７（図３参
照）に対して結合更新メッセージ（キャッシュ削除要求
メッセージ）の作成を依頼する。これにより、結合更新
メッセージ作成部５２７は、有効期限の切れた上記「キ
ャッシュ」に対応するＶＨＡ／ＴＨＡアドレスデータ６
２ｂ〔図４（Ｂ）参照〕をＤＡとし、自ＥＮアドレスを
ＳＡとするとともに、宛先オプションのリザーブビット
を“１”，ライフタイムを“０”とするＶＨＡ／ＴＨＡ
宛のキャッシュ削除要求メッセージを作成しルータ処理
部４６へ転送する（ステップＦ４のＹｅｓルートからス
テップＦ５）。
【０２１９】つまり、通信中ＥＮは、通信が終了して
「キャッシュ」の有効期限が終了すると、ＶＨＡ／ＴＨ
Ａに対してそのＶＨＡ／ＴＨＡで管理されている「通信
中ＥＮアドレス」の削除要求を行なうのである。これに
より、上記キャッシュ削除要求メッセージを受けたＶＨ
Ａ／ＴＨＡ（キャッシュ通知を行なったＶＨＡ／ＴＨ
Ａ）では、キャッシュテーブル４４で保持されている該
当「通信中ＥＮアドレス」を削除する。
【０２２０】その後、ＥＮ側のタイマ処理部４９は、キ
ャッシュテーブル４４からライフタイムの切れた「キャ
ッシュ」を削除する（ステップＦ６）。このようにし
て、ライフタイムの切れた「キャッシュ」はＶＨＡ／Ｔ
ＨＡ／ＥＮにおいて順次削除されてゆくことになる。従
って、不要な情報がいつまでもキャッシュテーブル４４
で保持されることがなく、キャッシュテーブル４４に必
要な記憶容量を最小限に抑制することができる。
【０２２１】さて次に、本ＥＮ１２の制御メッセージ処
理部５０での処理について、図２７を参照しながら説明
する。即ち、制御メッセージ処理部５０では、メッセー
ジ種別判定部５１が、受信パケット（メッセージ）の宛
先オプションのオプションタイプを参照することにより
その受信メッセージの種別を判定する（ステップＥ
１）。即ち、受信メッセージが結合更新メッセージ，結
合応答メッセージ，BR-M3メッセージのいずれであるか
を判定する（ステップＥ２，Ｅ３，Ｅ４）。
【０２２２】その結果、受信メッセージが、例えば、結
合更新メッセージ（キャッシュ通知メッセージ）であれ
ば（ステップＥ２でＹｅｓと判定されれば）、メッセー
ジ種別判定部５１は、そのメッセージを結合更新メッセ
ージ処理部５２Ｃの結合更新メッセージ解析部５２２へ
転送する。なお、ＥＮ１２が受信しうる結合更新メッセ
ージとしては、キャッシュ通知メッセージ，位置（キャ
ッシュ）更新メッセージがある（前記の表１参照）。
【０２２３】従って、結合更新メッセージ解析部５２２
は、受信メッセージの正常性をチェックしたのち（ステ
ップＥ５）、正常であれば、テーブルアクセス部５２１
によって、そのメッセージ（キャッシュ通知メッセージ
／キャッシュ更新メッセージ）により通知されたキャッ
シュデータ６１ａを、そのメッセージに含まれるＭＮホ
ームアドレスをキーにしてキャッシュテーブル４４の該
当記憶領域に書き込んで、キャッシュテーブル４４の内
容を登録／更新する（ステップＥ６）。
【０２２４】そして、結合更新メッセージ解析部５２２
は、上記の受信メッセージのＡビットが“１”になって
いるか否かをチェックし（ステップＥ７）、“１”にな
っていれば（ステップＥ７でＹｅｓなら）、そのメッセ
ージに対する応答メッセージ（キャッシュ更新応答メッ
セージ）が要求されていることを意味するので、結合応
答メッセージ作成部５２３に対してキャッシュ更新応答
メッセージの作成を依頼する。
【０２２５】これにより、結合応答メッセージ作成部５
２３は、受信メッセージのＳＡをＤＡ，自ＥＮアドレス
をＳＡとするＶＨＡ／ＴＨＡ宛のキャッシュ更新応答メ
ッセージを作成する（ステップＥ８）。このキャッシュ
更新応答メッセージは、メッセージ送信部５２Ｆを通じ
てルータ処理部４６へ転送され、ルータ処理部４６（出
力方路決定部４６ｂ）において出力インタフェースが決
定されて、そのＤＡに応じた次ホップ先ノードへルーテ
ィングされる（ステップＥ９，図２９のステップＧ１〜
Ｇ４）。
【０２２６】なお、受信メッセージのＡビットが“１”
になっていない場合は、その受信メッセージに対する応
答メッセージは要求されていないことを意味するので、
結合更新メッセージ解析部５２２は、テーブルアクセス
部５２１による受信「キャッシュ」の書き込みの後、キ
ャッシュ更新応答メッセージの作成は依頼せずに、その
まま処理を終える（ステップＥ７のＮｏルート）。
【０２２７】これに対し、上記のメッセージ種別判定の
結果、受信メッセージが結合応答メッセージであれば
（ステップＥ２でＮｏと判定され、ステップＥ３でＹｅ
ｓと判定されれば）、メッセージ種別判定部５１は、そ
のメッセージを結合応答メッセージ処理部５２Ｄへ転送
し、これにより、結合応答メッセージ処理部５２Ｄにお
いて、そのメッセージ内容に応じた処理が実施される
（ステップＥ３のＹｅｓルートからステップＥ１０）。
なお、ＥＮ１２が受信しうる結合応答メッセージとして
は、自ＥＮ１２が発行したキャッシュ削除要求メッセー
ジに対する応答（キャッシュ削除応答メッセージ）があ
る（表１参照）。
【０２２８】次に、上記のメッセージ種別判定の結果、
受信メッセージがBR-M3メッセージであれば（ステップ
Ｅ２及びＥ３でいずれもＮｏと判定され、ステップＥ４
でＹｅｓと判定されれば）、メッセージ種別判定部５１
は、そのメッセージを結合要求メッセージ解析部５２６
へ転送する。すると、結合要求メッセージ解析部５２６
は、そのメッセージに含まれるＭＮホームアドレスをテ
ーブルアクセス部５２５に通知し、テーブルアクセス部
５２５は、そのＭＮホームアドレスを検索キーとしてキ
ャッシュテーブル４４を検索する。
【０２２９】その結果、キャッシュヒットすれば、結合
更新メッセージ作成部５２７によって、その「キャッシ
ュ」をキャッシュ要求元のノードへ通知するためのキャ
ッシュ通知メッセージが作成されて（ステップＥ１
１）、これがメッセージ送信部５２Ｆを通じてルータ処
理部４６へ転送される。なお、上記のメッセージ種別判
定の結果、受信メッセージが、結合更新メッセージ，結
合応答メッセージ，BR-M3メッセージのいずれでもなか
った場合（ステップＥ２〜Ｅ４においていずれもＮｏと
判定された場合）、メッセージ種別判定部５１は、受信
メッセージをルーティングメッセージ処理部５３へ転送
し、ルーティングメッセージ処理部５３においてそのメ
ッセージ内容に応じた処理が実施される（ステップＥ１
２）。
【０２３０】以上のようなＶＨＡ／ＴＨＡ／ＥＮ／ＭＮ
の個々の動作により、本実施形態のシステムでは、ホー
ム網１（２）のホーム端末３に対しては、ＶＨＡがその
現在位置情報（COA）を管理し、ＥＮがホーム網１
（２）のＶＨＡに端末３の現在位置情報（COA）の問い
合わせを行ない、COAが判明した後はＥＮがＶＨＡの代
わりにCOA宛にパケットをカプセル化して転送し、他網
２（１）からローミングしてきた端末３に対しては、Ｔ
ＨＡがその現在位置情報（COA）を管理し、ＥＮがホー
ム１（２）のＴＨＡに端末３の現在位置情報（COA）の
問い合わせを行ない、COAが判明した後はＥＮがＴＨＡ
の代わりにCOA宛にパケットをカプセル化して転送する
ことが可能となる。
【０２３１】(A4.4)ローミング中の端末３との通信時の
動作説明 さて、次に、以下では、上述したＶＨＡ／ＴＨＡ／ＥＮ
／ＭＮの個々の動作を前提として、図１８により前述し
たように端末３がローミング先のパケット網２のＥＮ
“４”の在圏ゾーンに位置しているときに、例えば図１
９に示すように、ホーム網１のＥＮ“１”の在圏ゾーン
に位置する別の端末３（以下、説明の便宜上、ローミン
グ中の端末３を端末３ａ、ホーム網１に存在する別の端
末３を端末３ｂと表記する）がローミング中の端末３ａ
と通信を行なう場合の動作について考える。
【０２３２】従って、この場合、端末３ａは、ローミン
グ先のＴＨＡ２１ｂに「PCOA」を、ホーム網１のＶＨＡ
１０には「VCOA」を登録していることになる。まず、端
末３ｂは、端末３ａの現在の移動先アドレス（COA）を
知らないため、ホームアドレス（ＭＮホームアドレス）
宛にパケット（ユーザパケット）を送信することにな
る。このホームアドレス宛のパケットが、最寄りのＥＮ
“１”で受信されると、ＥＮ“１”では、図２５により
上述したステップＤ３及びＤ４にてＮｏと判定され、図
２６により上述したステップＤ１７，Ｄ２３及びＤ２５
にていずれもＮｏと判定されることになる。
【０２３３】従って、ＥＮ“１”は、受信ユーザパケッ
トをＶＨＡ１０へ向けて転送するとともに、受信パケッ
トのＤＡ（ＭＮホームアドレス）をＤＡ、つまり、ＶＨ
Ａ１０宛のBR-M3メッセージを発行してＶＨＡ１０に対
して「キャッシュ」を要求する。ＶＨＡ１０では、受信
したユーザパケットを「VCOA」宛にカプセル化して転送
するとともに、BR-M3メッセージに対する応答としてＥ
Ｎ“１”宛のキャッシュ通知メッセージを発行する（図
１９中に示す点線矢印９１参照）。
【０２３４】これらの各処理は、ユーザパケットについ
ては図２３により上述したステップＢ３のＮｏルート，
ステップＢ５のＹｅｓルート，ステップＢ７のＮｏルー
ト，ステップＢ１０のＮｏルート及びステップＢ１３の
Ｙｅｓルートを通る各処理に相当し、BR-M3メッセージ
については図２３により上述したステップＢ３のＮｏル
ート，ステップＢ５のＹｅｓルート，ステップＢ７のＹ
ｅｓルート，図２４により上述したステップＣ２のＮｏ
ルート，ステップＣ３のＮｏルート，ステップＣ４のＹ
ｅｓルート，ステップＣ２１のＹｅｓルートを通る各処
理に相当する。
【０２３５】これにより、ユーザパケットは例えば図１
９に示すようにＥＮ“２”へルーティングされ、ＥＮ
“１”では、ＶＨＡ１０からのキャッシュ通知メッセー
ジにより通知された「キャッシュ」をキャッシュテーブ
ル４４に登録する。その結果、ＥＮ“１”は、図１９中
に太実線矢印９２で示すように、以降、ＶＨＡ１０に代
わって端末３ａ宛のユーザパケットを「VCOA」でカプセ
ル化してＶＨＡ１０を経由させることなく転送すること
（ルート最適化）が可能となる。
【０２３６】次に、ＥＮ“２”は、上述のごとくＶＨＡ
１０にて「PCOA」でカプセル化されたユーザパケットを
ＥＮ“３”へ転送し、ＥＮ“３”は、そのユーザパケッ
トをＴＨＡ２１ｂへ向けてルーティングするとともに、
ＴＨＡ２１ｂ宛のBR-M3メッセージを発行してＴＨＡ２
１ｂに対して「キャッシュ」を要求することになる。な
お、このときのＥＮ“２”での処理は、図２５により前
述したステップＤ３のＮｏルート，ステップＤ４のＮｏ
ルート，図２６により前述したステップＤ１７のＮｏル
ート，ステップＤ２３のＹｅｓルート及び図２５により
前述したステップＤ１２のＹｅｓルートを通る各処理に
相当し、ＥＮ“３”での処理は、図２５により前述した
ステップＤ３のＮｏルート，ステップＤ４のＮｏルー
ト，図２６により前述したステップＤ１７のＮｏルート
及びステップＤ２３のＮｏルートを通る各処理に相当す
る。
【０２３７】これにより、ＴＨＡ２１ｂは、受信したユ
ーザパケットを「PCOA」でカプセル化してＥＮ“４”に
向けてルーティングするとともに、BR-M3メッセージに
対する応答としてＥＮ“３”宛のキャッシュ通知メッセ
ージを発行する（図１９中に示す点線矢印９３参照）。
このときの各処理も、ユーザパケットについては図２３
により上述したステップＢ３のＮｏルート，ステップＢ
５のＹｅｓルート，ステップＢ７のＮｏルート，ステッ
プＢ１０のＮｏルート及びステップＢ１３のＹｅｓルー
トを通る各処理に相当し、BR-M3メッセージについては
図２３により上述したステップＢ３のＮｏルート，ステ
ップＢ５のＹｅｓルート，ステップＢ７のＹｅｓルー
ト，図２４により上述したステップＣ２のＮｏルート，
ステップＣ３のＮｏルート，ステップＣ４のＹｅｓルー
ト，ステップＣ２１のＹｅｓルートを通る各処理に相当
する。
【０２３８】これにより、ユーザパケットは図１９に示
すようにＥＮ“４”経由でローミング中の端末３ａへ正
しく転送され、ＥＮ“３”では、ＴＨＡ２１ｂからのキ
ャッシュ通知メッセージにより通知された「キャッシ
ュ」をキャッシュテーブル４４に登録する。その結果、
ＥＮ“３”も、図１９中に太実線矢印９４で示すよう
に、以降、ＴＨＡ２１ｂに代わって端末３ａ宛のユーザ
パケットを「PCOA」でカプセル化してＴＨＡ２１ｂを経
由させることなく転送すること（ルート最適化）が可能
となる。
【０２３９】つまり、端末３ｂから送信されたユーザパ
ケットは、最終的に、図２０に示すような経路を辿って
ローミング中の端末３ａに届くことになる。従って、パ
ケットの転送遅延が最小限に抑制されるとともに、ＶＨ
Ａ／ＴＨＡの処理負荷がＥＮに分散されることになって
大幅に軽減されることになる。特に、この場合は、従来
のように、パケット転送ルートがＴＨＡを経由するルー
トに制限されず、ＴＨＡにパケットが集中することがな
いので、その効果は極めて大きい。
【０２４０】なお、上記のＥＮ“４”での処理は、図２
５により前述したステップＤ３のＮｏルート，ステップ
Ｄ４のＮｏルート，ステップＤ７のＮｏルート，ステッ
プＤ１２のＹｅｓルートを通る各処理に相当する。さ
て、次に、図２０に示すように、端末３ａと端末３ｂと
が通信を行なっている状態で、例えば図２１に示すよう
に、ＴＨＡ２１ｂとは異なるＴＨＡ２１ａが収容するＥ
Ｎ“５”の在圏ゾーンへ移動した場合を考える。
【０２４１】この場合、端末３ａは、その移動によっ
て、ＥＮ“５”から「ルータ広告」を受信するようにな
る。すると、端末３ａは、その「ルータ広告」に含まれ
ているＥＮアドレスがそれまでに受信していたものと異
なるために、位置が変わったことを認識する。また、Ｔ
ＨＡアドレスについては、この例では、これまでと異な
るアドレスを受信することとなる。
【０２４２】しかし、この場合は、ローミング先のパケ
ット網２内の移動であるため、Ｍ３ネットワークアドレ
スはそれまでに受信していたものと同一である。従っ
て、端末３ａは、図１８及び図２２を用いて前述したよ
うに、最初のＴＨＡアドレスのＴＨＡ２１ｂへ位置登録
を行なうことになり、位置登録先のＴＨＡを切り替える
ことはしない。
【０２４３】ただし、ＴＨＡは切り替えないが、ＥＮア
ドレスは変わっているので、「PCOA」は新しくなる。こ
のため、端末３ａは、この新しい「PCOA」を元のＴＨＡ
２１ｂに通知することになる（図２１中の点線矢印９５
参照）。なお、以上の端末３ａでの処理は、図２２によ
り前述したステップＡ２のＮｏルート，ステップＡ３の
Ｎｏルート，ステップＡ６のＹｅｓルートを通る各処理
に相当する。
【０２４４】一方、上記の新しい「PCOA」を受けたＴＨ
Ａ２１ｂは、自己がもつキャッシュテーブル４４に登録
されている該当「キャッシュ」を更新するとともに、更
新した「キャッシュ」に対応する通信中ＥＮアドレスデ
ータ６２ｂをＤＡとするキャッシュ更新メッセージを発
行して、通信中ＥＮ“３”に通知する（図２１中の点線
矢印９６参照）。
【０２４５】なお、以上の処理は、図２４により前述し
たステップＣ２のＹｅｓルート，ステップＣ５のＮｏル
ート，ステップＣ６のＹｅｓルート，ステップＣ８のＹ
ｅｓルート，ステップＣ１１のＹｅｓルート及びステッ
プＣ１２のＮｏルートを通る各処理に相当する。これに
より、ＥＮ“３”の「キャッシュ」がＴＨＡ２１ｂから
通知された「キャッシュ」に書き換えられる（図２７の
ステップＥ６参照）。その結果、以降に到着した端末３
ａ宛のパケットをＥＮ“３”が受信したときには、新し
い「PCOA」でカプセル化（図２５のステップＤ１３参
照）して送信することになり、端末３ａ最新の移動先に
正しく届けることができる。
【０２４６】なお、上述した実施形態では、パケット網
１をホーム網とする端末３ａがパケット網２へローミン
グする場合について説明したが、勿論、パケット網２を
ホーム網とする端末３がパケット網１へローミングする
場合も、上記と同様である。以上のように、本実施形態
によれば、ＥＮがＶＨＡ／ＴＨＡで管理している「キャ
ッシュ」を受けてその「キャッシュ」に基づきそのＶＨ
Ａ／ＴＨＡに代わって端末３宛のパケットルーティング
を行なうので、端末３宛のパケットを、ＶＨＡ／ＴＨＡ
を経由せずに、直接、在圏ＥＮに転送できることにな
り、高速ハンドオーバとパケット転送ルートに制限の無
いルート最適化とが可能になる。
【０２４７】特に、本実施形態の場合は、通信中ＥＮア
ドレスをキャッシュテーブル４４において複数分保持で
きるようにしておくことで、１台の端末３に対して複数
の通信中ＥＮにＶＨＡ／ＴＨＡによるルーティングを代
替させるよう設定することができるので、従来のように
特定のＶＨＡ／ＴＨＡにパケットが集中するようなこと
がなく、ＶＨＡ／ＴＨＡの処理負荷をＥＮに分散させて
その負荷を大幅に軽減することが可能である。
【０２４８】また、ローミング中の端末３は、在圏ＥＮ
からの「ルータ広告」に含まれるＴＨＡアドレスが自己
の移動に伴って変化してもＭ３ネットワークアドレスが
変化していなければ、自身が同じローミング先の網２
（１）内に位置していると認識して、「COA（「PCO
A」）の通知（登録）先を、同じＴＨＡに維持すること
ができるので、従来のように移動に伴って位置登録先Ｔ
ＨＡの切り替えが頻繁に発生することも防止でき、高速
ハンドオーバ性をさらに向上することができる。
【０２４９】さらに、端末３による位置登録先ＴＨＡが
端末３の移動に関わらず上述のごとく同じＴＨＡに維持
される場合であっても、端末３のＴＨＡに対する現在位
置の更新登録に応じて必要な「キャッシュ」が通信中Ｅ
Ｎに逐次提供されて相互の同期がとられるので、通信中
ＥＮは、パケット転送ルートを、ＴＨＡを経由しない新
たな在圏ＥＮに到るルートに適切且つ迅速に変更するこ
とが可能である。従って、ＴＨＡの処理負荷をさらに抑
制しながら高速ハンドオーバを実現することができる。
【０２５０】また、端末３宛のパケットを受信したＥＮ
は、「キャッシュ」が無い場合にＶＨＡ／ＴＨＡへ必要
な「キャッシュ」を要求するので、どのＥＮも、ＶＨＡ
／ＴＨＡによるパケットルーティングを代替することが
でき、ＶＨＡ／ＴＨＡのパケットルーティングを代替す
るＥＮが１箇所に固定されず、特定のＥＮにパケットが
集中してその負荷が増大することも無い。従って、この
場合、ＥＮとＶＨＡ／ＴＨＡとの双方の負荷を軽減でき
ることになる。
【０２５１】さらに、このとき、ＶＨＡ／ＴＨＡは、
「キャッシュ」の要求を受けたＥＮのみにキャッシュ情
報を提供するので、不要な「キャッシュ」の転送を防止
することができ、網内のトラフィック量の増大を抑制す
ることも可能である。また、ＶＨＡ／ＴＨＡは、キャッ
シュテーブル４４に保持する「通信中ＥＮアドレス」に
よって、「キャッシュ」を更新／削除すべきＥＮを把握
しておくので、新しいCOAの通知を受けた場合の該当通
信中ＥＮの「キャッシュ」を誤ることなく更新できる。
従って、パケットルーティングの信頼性、つまり、通信
品質を向上することができる。
【０２５２】さらに、通信中ＥＮでは、端末３宛のパケ
ットを受信する毎に、上記の「キャッシュ」のライフタ
イム（有効期限）をリフレッシュするので、通信中に
「キャッシュ」の有効期限が切れて正常な通信を維持で
きなくなることを回避することができ、さらに、パケッ
トルーティングの信頼性、つまり、通信品質を向上する
ことができる。
【０２５３】また、通信中ＥＮは、通信が終了して上記
の「キャッシュ」の有効期限が切れると、当該「キャッ
シュ」を削除するとともに、その「キャッシュ」を受け
たＶＨＡ／ＴＨＡに対して該当「キャッシュ」の「通信
中ＥＮアドレス」の削除を要求し、この要求を受けたＶ
ＨＡ／ＴＨＡが、自己のキャッシュテーブル４４で保持
している該当「通信中ＥＮアドレス」を削除するので、
ＥＮ及びＶＨＡ／ＴＨＡにおいて不要な情報をいつまで
も保持しておくことがなく、それぞれに必要なメモリ容
量などを削減して、その小型化を図ることができる。
【０２５４】(B)変形例の説明 上述した実施形態では、ローミング先において端末３が
移動してＥＮアドレス及びＴＨＡアドレスに変化があっ
ても、原則として、Ｍ３ネットワークアドレスに変化が
無い限り、それらの変化を無視して、最初に位置登録を
行なったＴＨＡに対してのみ位置登録を行なっている
が、或る特定の条件（付加的条件）を満足した場合に
は、位置登録先のＴＨＡの切り替えを行なうようにする
ことも可能である。なお、「ＴＨＡの切り替え」とは、
受信した「ルータ広告」に含まれるＴＨＡアドレス，Ｅ
Ｎアドレスから新しく「VCOA」，「PCOA」を作成し、Ｖ
ＨＡにはホーム位置登録メッセージにより「VCOA」を、
ＴＨＡには在圏位置登録メッセージにより「PCOA」を送
信して各COAを登録することを意味する。
【０２５５】以下では、その例について詳述する。ただ
し、以下の例では、例えば、図３０に示すように端末３
がM3v6ネットワーク１からローミング先の他網（M3v6他
ネットワーク）２へ移動してゆく状況を想定する。な
お、この図３０において、端末３のホーム網１のアドレ
ス（Ｍ３ネットワークアドレス）は、「100.50」、ロー
ミング先のパケット網２のＭ３ネットワークアドレスは
「200.50」、ＴＨＡ１１ａ，１１ｂ，２１ａ，２１ｂの
アドレスは、それぞれ順に、「10.1」，「20.1」，「3
0.1」，「40.1」、ＥＮ１２（ＥＮ“１”，“２”，
“５”〜“８”）のアドレスは、それぞれ順に、「1.
1」，「2.1」，「5.1」，「6.1」，「7.1」，「8.1」と
仮定し、端末３のインタフェースＩＤは“３”と仮定す
る。
【０２５６】従って、図３０中に示すように、ＥＮ１２
から端末３が受信する「ルータ広告」に含まれるＥＮア
ドレスは、その移動に伴って、「1.1」→「1.1」→「2.
1」→「5.1」→「6.1」→「7.1」→「8.1」と遷移して
ゆき、同じく、ＴＨＡアドレスは「10.1」→「10.1」→
「20.1」→「30.1」→「30.1」→「40.1」→「40.1」と
遷移してゆく。
【０２５７】また、Ｍ３ネットワークアドレスは、「10
0.50」→「100.50」→「100.50」→「200.50」→「200.5
0」→「200.50」→「200.50」→「200.50」と遷移して
ゆく。そして、このような移動に伴って、端末３で作成
する「PCOA」は、「1.3」→「1.3」→「2.3」→「5.3」
→「6.3」→「7.3」→「8.3」と遷移してゆき、「VCO
A」は、「10.3」→「10.3」→「30.3」→「30.3」→「4
0.3」→「40.3」と遷移してゆくことになる。
【０２５８】(B1)第１変形例（一定時間経過毎にＴＨＡ
の切り替え判断を行なう場合） かかる状況を前提として、本第１変形例の端末３では、
例えば図３１に示すように、パケット網２へローミング
インした後、一定周期Ｔ毎に、ＴＨＡアドレスが変化し
ているか否かを判断する。そして、一定周期Ｔ経過時に
ＴＨＡアドレスが変化していれば、端末３は、そのとき
に初めて、位置登録先のＴＨＡをＴＨＡ２１ａからＴＨ
Ａ２１ｂに切り替える。
【０２５９】即ち、この例では、端末３は、ＴＨＡアド
レスが変化した時点Ｔ１では、ＴＨＡの切り替えは行な
わず、一定周期Ｔ経過時点Ｔ２において、初めて、その
時のＥＮアドレス（＝「7.1」のプレフィックス部分
（“７”）と自己のインタフェースＩＤ（＝“３”）と
の組み合わせにより、「PCOA」＝「7.3」を作成し、こ
の「PCOA」をＴＨＡ２１ａではなくＴＨＡ２１ｂへ通知
する（点線矢印９６参照）とともに、その時のＴＨＡア
ドレス（＝「40.1」）のプレフィックス部分（“４
０”）と自己のインタフェースＩＤ（＝“３”）との組
み合わせにより、「VCOA」＝「40.3」を作成して、この
「VCOA」をホーム網１のＶＨＡ１０へ通知するのである
（点線矢印９７参照）。
【０２６０】このような動作は、例えば端末３のルータ
広告メッセージ処理部３４Ｃの基本アルゴリズム（図２
２に示すステップＡ１〜Ａ８）に、図３２に示すＴＨＡ
アドレスチェックアルゴリズム（ステップＡ９〜Ａ１
３）及び図３３に示すフラグ設定アルゴリズム（ステッ
プＡ１４〜Ａ１８）を付加することで実現できる。即
ち、この場合、図３３に示すように、端末３では、現時
刻情報（nowtime）を読み出し（ステップＡ１４）、前
回ＴＨＡアドレスチェック時刻情報（oldtime）を読み
出し（ステップＡ１５）、これらの時刻情報の差分（no
wtime−oldtime）が周期Ｔよりも大きいか否かをチェッ
クする（ステップＡ１６）。
【０２６１】そして、上記の各時刻情報の差分が時間情
報（周期）Ｔよりも大きければ、一定周期Ｔが経過した
ことになるので、ＴＨＡアドレスフラグチェックフラグ
を“on”とし（ステップＡ１６のＹｅｓルートからステ
ップＡ１７）、前回ＴＨＡアドレスチェック時刻情報
（oldtime）を現時刻情報（nowtime）に更新して処理を
終える（ステップＡ１８）。なお、上記の各時刻情報の
差分が時間情報Ｔ以下であるときは、そのまま処理は終
了する（ステップＡ１６のＮｏルート）。
【０２６２】以上の処理（一定周期カウントアルゴリズ
ム）を端末３は繰り返し実行することにより、一定周期
Ｔ経過毎にＴＨＡアドレスチェックフラグを“on”に設
定することになる。なお、上記の時刻情報（nowtime，o
ldtime），時間情報Ｔ，ＴＨＡアドレスチェックフラグ
は、それぞれ、情報格納レジスタ３４１に格納されるよ
うにすればよい。
【０２６３】かかる状態で、端末３（ルータ広告メッセ
ージ処理部３４Ｃ）は、元のＴＨＡ２１ａ宛の在圏位置
登録メッセージを発行してＴＨＡ２１ａへ位置登録を行
なうと（ステップＡ８）、続いて、ＴＨＡアドレスチェ
ックフラグが“on”になっているか否かをチェックし
（ステップＡ９）、ＴＨＡアドレスチェックフラグが
“off”になっていれば、その時点でＴＨＡアドレスが
変化していても、現ＴＨＡアドレスは元のＴＨＡアドレ
スとし（ステップＡ９のＮｏルートからステップＡ１
３）、ＴＨＡアドレスチェックフラグを“off”に解除
する（ステップＡ１２）。
【０２６４】これに対し、ＴＨＡアドレスチェックフラ
グが“on”になっていれば、次に、ルータ広告処理部３
４Ｃは、「ルータ広告」に含まれるＴＨＡアドレスのプ
レフィックス部分が元のＴＨＡアドレス（例えば、情報
格納レジスタ３４１に格納される）のプレフィックス部
分と一致するか否かをチェックし（ステップＡ９のＹｅ
ｓルートからステップＡ１０）、一致していれば、ＴＨ
Ａアドレスに変化が無いので、この場合も、現ＴＨＡア
ドレスは元のＴＨＡアドレスとし（ステップＡ１０のＹ
ｅｓルートからステップＡ１３）、ＴＨＡアドレスチェ
ックフラグを“off”に解除する（ステップＡ１２）。
【０２６５】一方、上記の各プレフィックス部分が一致
していなければ、ＴＨＡアドレスが変化しているので、
端末３（ルータ広告メッセージ処理部３４Ｃ）は、上述
のごとく「PCOA」を新しいＴＨＡアドレスをもつＴＨＡ
２１ｂへ在圏位置登録メッセージにより通知するととも
に、「VCOA」をホーム網１のＶＨＡ１０へホーム位置登
録メッセージにより通知して（ステップＡ１０のＮｏル
ートからステップＡ１１）、ＴＨＡアドレスチェックフ
ラグを“off”に解除する（ステップＡ１２）。
【０２６６】つまり、本変形例では、ゲートノード識別
情報監視手段としての機能を果たすルータ広告解析部３
４２が、上記のフラグ設定アルゴリズム（ステップＡ１
４〜Ａ１８）およびＴＨＡアドレスチェックアルゴリズ
ム（ステップＡ９〜Ａ１３）を実行することにより、所
定の付加的条件下においてＴＨＡアドレスが変化したか
否かを検知する条件付監視手段として構成されているこ
とになる。
【０２６７】そして、この場合、現在位置通知手段とし
ての機能を果たす位置登録メッセージ作成部３４３が、
上記ルータ広告解析部３４２にて上記の付加的条件下に
おけるＴＨＡアドレスの変化が検知されると、Ｍ３ネッ
トワークアドレスに変化が無い場合であっても、変化後
のＴＨＡアドレスによって識別される新たなＴＨＡに自
己の現在位置情報（PCOA）を通知する条件付通知手段と
しての機能を有していることになる。
【０２６８】このように、本第１変形例の場合は、一定
周期Ｔ経過時にＴＨＡアドレスが変化しているという一
定の条件を満足すると、位置登録先ＴＨＡの切り替えを
行なうので、例えば、位置登録先ＴＨＡを維持すること
により、端末３とＴＨＡとの距離が長距離になってしま
った場合などにおいて、最寄りのＴＨＡが変化する毎に
位置登録を行なう場合よりもその登録頻度を削減しなが
ら、位置登録先ＴＨＡの最適化、つまり、ハンドオーバ
時間の最適化を有効に図ることができる。
【０２６９】(B2)第２変形例（非通信中にＴＨＡの切り
替え判断を行なう場合） 次に、上述したＴＨＡの切り替え判断を、端末３の非通
信中に行なう場合について説明する。即ち、例えば図３
４に示すように、「ルータ広告」に含まれるＴＨＡアド
レスが「30.1」から「40.1」に変わった時点Ｔ３では、
端末３は、まだ通信中であるため、ＴＨＡの切り替えを
行なわない。その後、非通信中となった後（時点Ｔ４の
後）で、「ルータ広告」を受信すると、上記の例と同様
にして端末３はＴＨＡの切り替えを実行する（ＴＨＡ２
１ｂに「PCOA」を通知し、ＶＨＡ１０に「VCOA」を通知
する）。
【０２７０】このような動作は、上記のＴＨＡアドレス
フラグチェックを“on”にする契機だけが異なっている
ため、図３３に示すフラグ設定アルゴリズムに代えて、
例えば図３５に示すように、通信中でないときにのみ
（ステップＡ１９でＮｏと判定された場合にのみ）、Ｔ
ＨＡアドレスチェックフラグを“on”にする（ステップ
Ａ２０）フラグ設定アルゴリズムを用いれば実現でき
る。なお、この図３５に示すアルゴリズムは、図３２に
示すＴＨＡアドレスチェックアルゴリズムとは独立に、
（例えば周期的に）起動される。
【０２７１】このように、本第２変形例の場合は、位置
登録先ＴＨＡの切り替えが必ず端末３の非通信中である
ときに実施されるので、通信中の切り替え発生による通
信品質の劣化は生じない。従って、通信品質の劣化を防
止しながら、ハンドオーバ時間の最適化を図ることがで
きる。 (B3)第３変形例（非通信中にＴＨＡの切り替え判断を行
なう場合） 次に、上記のＴＨＡの切り替え判断を、トラフィック量
が所定のしきい値以下であるときに行なう場合について
説明する。
【０２７２】即ち、例えば図３６に示すように、端末３
において、その通信トラフィック量を監視しておき、Ｔ
ＨＡアドレスが変化してもその時のトラフィック量がし
きい値を超えていれば、ＴＨＡの切り替え判断は行なわ
ず（時点Ｔ５参照）、トラフィック量が所定のしきい値
以下になって、初めてＴＨＡの切り替え判断を行なう
（時点Ｔ６参照）。
【０２７３】このような端末３の動作は、図３３に示す
フラグ設定アルゴリズムに代えて、例えば図３７に示す
ように、監視したトラフィック量（例えば、情報格納レ
ジスタ３４１に格納すればよい）を読み出し（ステップ
Ａ２１）、そのトラフィック量がしきい値以下であると
きにのみ（ステップＡ２２でＹｅｓと判定された場合に
のみ）、ＴＨＡアドレスチェックフラグを“on”にする
（ステップＡ２３）フラグ設定アルゴリズムを用いれば
実現できる。なお、この図３７に示すアルゴリズムも、
図３２に示すアルゴリズムとは独立に、（例えば周期的
に）起動される。
【０２７４】このように、本第３変形例の場合は、位置
登録先ＴＨＡの切り替えが、必ず通信トラフィック量が
所定値以下であるときに実施されるので、通信への影響
（通信帯域の圧迫等）を最小限に抑制しながら、ハンド
オーバ時間の最適化を図ることができる。 (B4)第４変形例（通信中トラフィックのタイプによって
ＴＨＡの切り替え判断を行なう場合） 次に、上記のＴＨＡの切り替え判断を、通信中トラフィ
ックのタイプ（種別）によって行なう場合について説明
する。
【０２７５】即ち、例えば図３８に示すように、端末３
が“http”，“VOIP”の２種のトラフィックタイプの通
信を行なっており、“http”トラフィックが存在する間
は、ＴＨＡアドレスに変化があっても、ＴＨＡの切り替
え判断は行なわず（時点Ｔ７参照）、その後に、“htt
p”トラフィックが無くなり、“VOIP”トラフィックの
みとなったときに、初めて、「ルータ広告」受信時のＴ
ＨＡの切り替え判断を行なう（時点Ｔ８参照）。
【０２７６】このような端末３の動作は、図３３に示す
フラグ設定アルゴリズムに代えて、例えば図３９に示す
ように、トラフィック種別を監視して情報格納レジスタ
３４１等にその種別情報を格納するようにしておき、そ
の種別情報を読み出し（ステップＡ２４）、現在有効な
トラフィック種別が“VOIP”のみのとき（ステップＡ２
５でＹｅｓと判定された場合）に、ＴＨＡアドレスチェ
ックフラグを“on”にする（ステップＡ２６）フラグ設
定アルゴリズムを用いれば実現できる。
【０２７７】なお、“VOIP”トラフィックであるか否か
の判断は、受信パケットの「トラフィッククラス」フィ
ールド７１２（図８参照）に設定されている値を参照す
ることで行なわれる。また、この図３９に示すアルゴリ
ズムも、図３２に示すＴＨＡアドレスチェックアルゴリ
ズムとは独立に、（例えば周期的に）起動される。この
ように、本第４変形例の場合は、通信中のデータトラフ
ィックタイプが“VOIP”という多少のパケットロスであ
れば許容できるデータトラフィックタイプであるときに
のみ、位置登録先ＴＨＡの切り替えが実施されるので、
位置登録先ＴＨＡの切り替えを行なっても許容範囲内で
の通信品質劣化で済み、ハンドオーバ時間は最適化する
ことができる。
【０２７８】なお、“VOIP”以外にも、ハンドオーバに
より多少の通信品質劣化が許容されるトラフィックタイ
プがあれば、そのタイプの通信のみが行なわれている間
に、位置登録先ＴＨＡの切り替えを行なうことも、勿
論、可能であり、同様の作用効果が得られる。 (B5)第５変形例（端末３のアプリケーションが動作して
いないときにＴＨＡの切り替え判断を行なう場合） 次に、上記のＴＨＡの切り替え判断を、端末３のアプリ
ケーションが動作していないときに行なう場合について
説明する。
【０２７９】即ち、例えば図４０に示すように、端末３
において、アプリケーションの動作数を監視しておき、
動作中のアプリケーション数が“０”以外のときには、
ＴＨＡアドレスに変化があってもＴＨＡの切り替え判断
は行なわず（時点Ｔ９参照）、動作中のアプリケーショ
ン数が“０”となっているときに初めて、「ルータ広
告」受信時のＴＨＡの切り替え判断を行なう（時点Ｔ１
０参照）。
【０２８０】このような端末３の動作は、図３３に示す
アルゴリズムに代えて、例えば図４１に示すように、監
視したアプリケーション動作数情報を読み出し（ステッ
プＡ２７）、現在動作中のアプリケーション数が“０”
であるとき（ステップＡ２８でＹｅｓと判定された場
合）にのみ、ＴＨＡアドレスチェックフラグを“on”に
する（ステップＡ２９）フラグ設定アルゴリズムを用い
れば実現できる。なお、この図４１に示すアルゴリズム
も、図３２に示すＴＨＡアドレスチェックアルゴリズム
とは独立に、（例えば周期的に）起動される。
【０２８１】このように、本第５変形例では、通信に使
用するアプリケーションの使用状態を監視し、上記の付
加的条件としてアプリケーションが未使用であるときに
のみ、つまり、端末３自体の処理能力に余裕があるとき
に実施されるので、位置登録先ＴＨＡの切り替えが行な
われるので、やはり、通信中の通信品質劣化を最小限に
抑制しながら、ハンドオーバ時間の最適化を図ることが
できる。
【０２８２】上記の(B1)第１変形例〜(B5)第５変形例に
より上述した各条件は適宜組み合わせて設定してもよ
い。即ち、上記の一定周期，非通信中，通信トラフィッ
ク量，データトラフィックタイプ，アプリケーションの
使用状態の各条件のうち、任意の条件の組み合わせによ
って特定される時期（組み合わせ条件下）においてＴＨ
Ａアドレスが変化している場合にのみ、位置登録先ＴＨ
Ａの切り替えを実施するようにしてもよい。
【０２８３】例えば、一定周期Ｔ経過時に端末が非通信
中であるときや、特定のデータトラフィックタイプの通
信中にそのトラフィック量が所定値以下であるとき等に
おいてのみ、位置登録先ＴＨＡの切り替えを実施するよ
うにすることが可能である。いずれの場合も、より有効
にハンドオーバによる通信品質の劣化を抑制することが
可能になる。
【０２８４】(C)その他 なお、上述した実施形態では、ＥＮが「キャッシュ」を
要求する相手（ＶＨＡ／ＴＨＡ）のアドレスを知らない
場合を想定したものであるが、例えばアドレスの割り当
てが正確に階層化されているような場合には、ＥＮが、
受信パケットのアドレス領域の上位数桁と、ある特定の
インタフェースＩＤとを組み合わせて宛先アドレスを決
定する方法も考えられる。
【０２８５】また、別の方法として、ＶＨＡ／ＴＨＡの
アドレスをＥＮが予め知っている場合には、そのアドレ
スをBR-M3メッセージのアドレスとして送信しても良
い。 (D)第２実施形態の説明 図４２は本発明の第２実施形態に係るパケット網の構成
を示すブロック図で、この図４２に示すパケット網１′
は、「MIPv6」に準拠する網で、複数のノード（ルーテ
ィングノード）から成り、そのうちの特定ノードが移動
端末（ＭＮ；Mobile Node）３′の位置管理機能を有す
るホームエージェントノード（ＨＡ）１０′として構成
されるとともに、他のノードがルータ（Ｒ）１３′（こ
の図４２では、「Ｒ１」〜「Ｒ５」の５台を図示してい
る）として構成されている。
【０２８６】そして、この場合も、ＭＮ３′は、最寄り
のルータ（在圏ノード）１３′から受信されるルータ広
告（ＲＡ）に含まれる当該ルータ１３′のＩＰアドレス
に基づく現在位置情報（ＣＯＡ）を作成してＨＡ１０に
通知することにより、逐次、ＨＡ１０′に対して位置登
録を行なうようになっており、これにより、ＨＡ１０′
は、常に、ＭＮ３′宛の受信パケットをＭＮ３′の現在
位置に対応する在圏ノード１３′へ正しくルーティング
（ハンドオーバ）することができ、ＭＮ移動中の正常な
モバイルＩＰ通信（音声，データ通信を含む）を可能に
している。なお、この図４２には図示していないが、ル
ータ１３′に接続してＭＮ３′と通信しうる相手端末に
は、他のＭＮ３′だけでなく固定端末も含まれる。
【０２８７】具体的に、上記のＨＡ１０′は、ＭＮ３′
から上記のＣＯＡの通知（位置登録）を受けることによ
り、そのＭＮ３′のＣＯＡを結合（バインディング）キ
ャッシュ（Binding Cache）と呼ばれる情報の一部とし
て管理するとともに、到着（受信）したＭＮ３′宛のパ
ケットが示す宛先アドレス（ＤＡ）に対応する「ＣＯ
Ａ」を本「キャッシュ」において検索し、該当「ＣＯ
Ａ」でカプセル化して転送（ルーティング）する機能を
有するものである。
【０２８８】また、各ルータ１３′は、それぞれ、在圏
ゾーンに位置するＭＮ３′と無線回線にて通信すること
により、そのＭＮ３′との間でパケットの送受を行なえ
るもので、受信パケットに付与されている宛先アドレス
（ＤＡ）に基づいてその受信パケットを次ホップ先（他
ルータ１３′もしくはＭＮ３′）へルーティングする機
能を有している。なお、以下では、ＨＡ１０′及びＭＮ
３′を、第１実施形態と同様に、それぞれ、ＨＡ及びＭ
Ｎと符号を省略して表記する場合がある。
【０２８９】そして、上記のＨＡ１０′及びルータ１
３′は、それぞれ、その要部に着目すると、例えば図４
３に示すように、入力処理部４１，パケット種別識別部
４２Ａ，結合（バインディング）キャッシュ（Binding
Cache）検索部４３Ａ，結合（バインディング）キャッ
シュ（Binding Cache）テーブル４４Ａ，カプセル化処
理部４５，ルータ処理部４６（ルーティングテーブル４
６ａ，出方路決定部４６ｂ），出力処理部４８，タイマ
処理部４９Ａ及び制御メッセージ処理部５０Ａをそなえ
て構成されている。
【０２９０】ここで、上記の入力処理部４１は、図２に
示すものと同様に、到着（受信）パケットのＩＰレイヤ
以下の処理を行なうためのもので、例えば、イーサネッ
トであれば自ノード宛のＭＡＣ（Media Access Contro
l）アドレスが付与されたパケットを取り込んで、その
パケットのフレーム自体の正常性をチェックする処理を
行なう機能を装備するものである。
【０２９１】また、パケット種別識別部４２Ａは、この
入力処理部４１で受信された正常なパケットの種別（主
に、自ノード宛のメッセージか他ノード宛のメッセージ
か）を、その宛先アドレス（ＤＡ）を参照して識別する
ためのもので、ここでは、自ノード宛のメッセージ（パ
ケット）であれば制御メッセージ処理部５０Ａへ、他ノ
ード宛のメッセージであれば、バインディングキャッシ
ュ検索部４３Ａへそれぞれ転送されるようになってい
る。
【０２９２】さらに、図４３において、結合（バインデ
ィング）キャッシュテーブル（以下、単に「キャッシュ
テーブル」という）４４Ａは、本実施形態においても、
基本的に、「MIPv6」ベースで作成される「キャッシ
ュ」をＭＮ３′のホームアドレス（ＭＮホームアドレ
ス）別にテーブル形式のデータとして保持するもので、
例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによ
って構成される。
【０２９３】ここで、このキャッシュテーブル４４Ａに
は、この場合も、基本的に、“COA”（128ビット），
“lifetime”（32ビット），“Home registration fla
g”（1ビット），“router flag”（1ビット），“pref
ix length”（7ビット），“Sequence Number”（16ビ
ット），“Recent Usage Information”（1ビット），
“last BR time”（128ビット）等のキャッシュデータ
が保持されるが、ＨＡにおいては、例えば図４４（Ｂ）
に示すように、ＭＮホームアドレス毎に、「現在のＣＯ
Ａ」とその有効期限を表す“lifetime1”に加えて、Ｍ
Ｎの「通信開始時（過去）のＣＯＡ」とその有効期限を
表す“lifetime2”も保持されるようになっている。
【０２９４】つまり、本実施形態のキャッシュテーブル
４４Ａは、ＭＮの移動に伴う複数のＣＯＡ（「現在のＣ
ＯＡ」及び「通信開始時のＣＯＡ」）を保持する位置情
報保持部４４Ａ−１としての機能と、少なくとも「通信
開始時のＣＯＡ」の有効期限に関する情報（“lifetime
2”）を記憶する有効期限情報記憶部４４Ａ−２として
の機能とを果たしていることになる。
【０２９５】ここで、例えば、図４４（Ａ）に模式的に
示すように、ＨＡの通信エリア（在圏ゾーン）１００′
に存在するＭＮが、ルータ「Ｒ１」の在圏ゾーン１３′
−２，ルータ「Ｒ２」の在圏ゾーン１３′−１の順に移
動する場合（点線矢印９７参照）を想定する。なお、各
ノードのＩＰアドレスを、第１実施形態での表記法と同
様に、ｘ（ネットワークＩＤ）．ｙ（ＭＮのインタフェ
ースＩＤ）と表記することにして、ＨＡのネットワーク
ＩＤを“１４４”、ルータ「Ｒ２」のネットワークＩＤ
を“２１１”、ルータ「Ｒ１」のネットワークＩＤを
“１１２”とすると、ＨＡのアドレスは“144.y”、ル
ータ「Ｒ２」のアドレスは“211.y”、ルータ「Ｒ１」
のアドレスは“112.y”と表される。
【０２９６】そして、ＭＮのインタフェースＩＤ（ＭＮ
に固有の識別子）を“５０”とすると、ＭＮは、ルータ
「Ｒ１」の在圏ゾーン１３′−２に移動してルータ「Ｒ
１」に接続したときに、ＣＯＡ＝“112.50”を作成して
ＨＡに通知（位置登録）する。なお、この時点では、キ
ャッシュテーブル４４Ａに「通信開始時のＣＯＡ」は登
録されない。
【０２９７】その後、ＭＮがルータ「Ｒ１」に接続した
状態で通信を開始すると（つまり、ＨＡでＭＮ宛のパケ
ットが受信されると）、ＨＡは、受信パケットの「トラ
フィック種別」を判断し、受信パケットがデータパケッ
トであればそのときの「現在のＣＯＡ」及び“lifetime
1”をコピーして、「通信開始時のＣＯＡ」及び“lifet
ime2”としてキャッシュテーブル４４Ａに登録する。
【０２９８】かかる状態で、ＭＮがさらに移動し、ルー
タ「Ｒ２」に接続すると、ＭＮは新しいＣＯＡ＝“211.
50”を作成してＨＡに通知し、ＨＡでは「現在のＣＯ
Ａ」＝「現在のＣＯＡ」を“112.50”から“211.50”に
書き換える。なお、この際、「通信開始時のＣＯＡ」は
変更されない（“112.50”のままである）。ここまでの
状態で、ＨＡのキャッシュテーブル４４Ａには、図４４
（Ｂ）に示す登録内容をもつことになる。つまり、ＨＡ
のキャッシュテーブル４４Ａには、図４（Ｂ）に示すよ
うに、「現在のＣＯＡ」として“211.50”が保持され、
「通信開始時のＣＯＡ」として“112.50”が保持される
ことになる。
【０２９９】なお、上記の“lifetime1”及び“lifetim
e2”は、いずれも、対応するＣＯＡ宛のパケットを受信
しない間、定期的に減算され、最終的にその値が“０”
になると（つまり、有効期限が切れると）、対応するＣ
ＯＡ（キャッシュ）が削除される。ただし、対応するＣ
ＯＡ宛のパケットを受信している間は、そのＣＯＡを維
持する必要があるので、パケット受信毎に“lifetime
2”は“０”にならないよう予め決められた初期値等に
リフレッシュ（更新）される。“lifetime1”の更新契
機は、第１実施形態と同様である。これらの有効期限の
更新はタイマ処理部４９Ａによって実施される。
【０３００】次に、バインディングキャッシュ検索部
（以下、単に「キャッシュ検索部」ともいう）４３Ａ
は、入力パケットのＩＰヘッダ７０（図７参照）に含ま
れる宛先アドレスを検索キーとして、上記のキャッシュ
テーブル４４Ａを検索してカプセル化処理部４５でのカ
プセル化に必要な情報（ＣＯＡ等）を取得することがで
きるものである。
【０３０１】ただし、本実施形態のＨＡにおけるキャッ
シュ検索部４３Ａは、主として、次のような各機能を兼
ね備えている。 受信パケットの種別（例えば、トラフィック種別）を
識別するトラフィック（パケット）種別識別部４３１と
しての機能 「現在のＣＯＡ」及び“lifetime2”をそれぞれコピ
ーして、「通信開始時のＣＯＡ」及び“lifetime2”と
してキャッシュテーブル４４Ａに登録しうるコピー登録
部４３２としての機能 このトラフィック種別識別部４３１による識別結果
（受信パケットのトラフィック種別）に応じて、キャッ
シュテーブル４４Ａにおける上記の「現在のＣＯＡ」及
び「通信開始時のＣＯＡ」のいずれか一方を、カプセル
化処理部４５でのカプセル化に使用するＣＯＡとして選
択するＣＯＡ選択部（選択手段）４３３としての機能 ここで、上記の「トラフィック種別」の例としては、
或る程度のパケットロスが許容される特性をもつ音声パ
ケット〔例えば、ＶＯＩＰ（Voice Over Internet Prot
ocol）パケット〕や或る程度のパケット転送遅延が許
容される特性をもつデータパケット〔例えば、ｈｔｔｐ
（hyper text transfer protocol）データパケットやｆ
ｔｐ(file transfer protocol)データパケット等〕があ
り、これらはＩＰヘッダ７０（標準ヘッダ７１；図７参
照）に含まれるtos（タイプ・オブ・サービス）フィー
ルド〔「トラフィッククラス」フィールド７１２（図８
参照）〕の値をそれぞれについて定義しておくことで識
別することが可能である。なお、このように、「トラフ
ィック種別」の識別にtos値を用いるのが、最も簡便な
手法であり、ＨＡの小型化も期待できる。
【０３０２】具体的には、例えば、音声パケットは図４
５に示すようなフォーマットを有しており、ｆｔｐデー
タパケットは図４６に示すようなフォーマットを有して
いるが、これらの図４５及び図４６において、「トラフ
ィッククラス」フィールド７１２に、それぞれ音声パケ
ット及びｆｔｐデータパケットを表す値を設定しておけ
ば、これらのパケットの「トラフィック種別」（以下、
「パケット種別」ともいう）をトラフィック種別識別部
４３１において識別できることになる。
【０３０３】つまり、この場合のトラフィック種別識別
部４３１は、受信パケットの「トラフィック種別」が少
なくともパケットロスを許容する特性をもつトラフィッ
ク種別及びパケット転送転送遅延を許容する特性をもつ
トラフィック種別のいずれであるかを識別するパケット
ロス／転送遅延特性識別部として機能することになる。
【０３０４】なお、上記の「トラフィッククラス」フィ
ールド７１２の値（tos値）は、例えば、ＭＮと網管理
者との間で予め取り決めを交わしておき、ＭＮがパケッ
トを生成するときにその取り決めに従ってＭＮ側で設定
してもよいし、予め網管理者と取り決めを交わしてお
き、パケットが流入してくる網１′の入口（エッジルー
タ）にポリシー制御機能を導入し、そのルータにおい
て、全受信パケットにつき、送信元アドレス（ＳＡ），
宛先アドレス（ＤＡ），使用プロトコル，送信（発信）
元ポート番号，宛先ポート番号をチェックして「トラフ
ィック種別」を識別し、tos値をその識別結果に応じた
適切な値（トラフィック識別情報）に書き換えた（設定
した）上で網１′内（ＨＡ宛）にパケットを転送（ルー
ティング）するようにしてもよい。
【０３０５】後者の場合には、ＭＮにおいて送信パケッ
トのtos値を独自にセットする必要が無く、ＨＡは、受
信パケットに上記エッジルータにて設定し直されたtos
値に基づいて「トラフィック種別」の識別が可能となる
ので、ＭＮの処理能力に余裕をもたせることが可能であ
る。なお、エッジルータでの「トラフィック種別」の識
別結果は、勿論、パケットの「トラフィッククラス」フ
ィールド７１２以外の部分に設定するようにしてもよ
い。
【０３０６】また、図４５及び図４６において、上記の
「送信元アドレス（ＳＡ）」はＳＡフィールド７１７に
表示され、「宛先アドレス（ＤＡ）」はＤＡフィールド
７１８に表示され、「使用プロトコル」は「ネクストヘ
ッダ」フィールド（プロトコルフィールド）７１５に表
示〔例えば、ＴＣＰ（Transmission Control Protoco
l）なら“６”，ＵＤＰ（User Datagram Protocol）な
ら“１７”等〕される。
【０３０７】同様に、「送信元ポート番号」はＴＣＰヘ
ッダ７４又はＵＤＰヘッダ７６の発信元ポート番号フィ
ールド７６１に表示され、「宛先ポート番号」は同じく
ＴＣＰヘッダ７４又はＵＤＰヘッダ７６の宛先ポート番
号フィールド７６２に表示される。なお、このように網
１′の入口（エッジルータ）にポリシー制御機能を導入
しない場合は、例えば、ＶＯＩＰを使用する音声パケッ
トは、通常、ＩＰの上位レイヤにＲＴＰ（Real-time Tr
ansport Protocol）を用いるので、ＲＴＰヘッダ７７
（図４５参照）を検出することにより、受信パケットが
音声パケットであることを識別できる。
【０３０８】ここで、ＲＴＰの音声符号化の種別は、ペ
イロードタイプフィールド７７１に表示され、図４５に
は、音声パケットの一例として、ペイロード８０（２４
バイト）に格納される音声データの音声符号化にG.723
（dual rate speech corder for multimedia communica
tions transmittimg at 5.3 and 6.3kbit/s）（ペイロ
ードタイプ＝４）を用いた場合のパケットフォーマット
を示している。
【０３０９】また、受信パケットの「トラフィック種
別」は、ＭＮ側で使用するアプリケーションによって使
用ポート番号が異なる場合には、上記のポート番号フィ
ールド７６１，７６２に表示されている値から識別する
こともできる。さらに、上記のプロトコルフィールド７
１５には、上位アプリケーションの種別が表示されてい
るので、その値により受信パケットの「トラフィック種
別」を識別することもでき、また、音声パケット等のリ
アルタイムトラフィックには通常パケット長が短いとい
う特徴があるので、パケット長（「ペイロード長」フィ
ールド７１４）の値から「トラフィック種別」を識別す
ることも可能である。
【０３１０】さらに、「IPv4」のパケットであれば、そ
のヘッダに含まれる識別子（Identification）フィール
ドの値を「トラフィック種別」の識別に使用することも
可能である。そして、ＨＡにおけるキャッシュ検索部４
３Ａは、相手（宛先）ＭＮの現在位置を知らないために
ＭＮホームアドレスを宛先アドレス（ＤＡ）として送信
されたパケットの当該ＭＮホームアドレスを検索キーと
して上記のキャッシュテーブル４４Ａを検索し、カプセ
ル化処理部４５でのカプセル化に用いるＣＯＡとして、
上述したごとくトラフィック種別識別部４３１によって
識別される「トラフィック種別」に応じてＣＯＡ選択部
４３３が「現在のＣＯＡ」及び「通信開始時のＣＯＡ」
のいずれかを選択的に取得することになる。
【０３１１】即ち、本実施形態のＣＯＡ選択部４３３
は、例えば、受信パケットが或る程度のパケットロスを
許容する特性をもつ音声（ＶＯＩＰ）パケットである場
合、キャッシュ検索部４３Ａは、キャッシュテーブル４
４Ａを検索して、受信パケットのＭＮホームアドレスに
対応する「現在のＣＯＡ」を選択する一方、受信パケッ
トが或る程度のパケット転送遅延を許容する特性をもつ
データパケットである場合は、ＭＮホームアドレスに対
応する「通信開始時のＣＯＡ」（ただし、登録されてい
れば）を選択する端末位置情報選択部として機能するよ
うになっているのである。
【０３１２】次に、カプセル化処理部４５は、ＣＯＡ選
択部４３３で選択されたＣＯＡを用いてキャッシュ検索
部４３Ａから転送されてくる受信パケットをカプセル化
するものであり、ルータ処理部４６（ルーティングテー
ブル４６ａ，出力方路決定部４６ｂ），出力処理部４８
は、図２により前述したものとそれぞれ同様の機能を有
するもので、出方路決定部４６ｂが、ルーティングテー
ブル４６ａを検索して、出力すべき物理インタフェース
や下位レイヤでの宛先アドレス等を決定し、出力処理部
４８が、例えば、イーサネットの場合にはイーサネット
フレームに必要なフレームチェックシーケンス符号を付
けて、パケット（フレーム）送出を行なうようになって
いる。
【０３１３】従って、本実施形態のカプセル化処理部４
５では、ＣＯＡ選択部４３３で選択されたＣＯＡを用い
てキャッシュ検索部４３Ａから転送されてくる受信パケ
ットをカプセル化することになり、ルータ処理部４６で
は、出方路決定部４６ｂが、このようにカプセル化され
たパケット（トンネルパケット）のヘッダ（カプセルヘ
ッダ）の宛先情報（「現在のＣＯＡ」又は「通信開始時
のＣＯＡ」）に基づいてルーティングテーブル４６ａの
ルーティング情報を検索して当該トンネルパケットの出
力インタフェースを決定して、決定した出力インタフェ
ースへ当該トンネルパケットを出力することになる。
【０３１４】つまり、本実施形態のルータ処理部４６
は、ＣＯＡ選択部４３３で選択されたＣＯＡに基づいて
受信パケットをルーティングするルーティング手段とし
て機能することになる。これにより、音声パケットにつ
いては、例えば図４７に模式的に示すように、ＭＮから
結合更新（Binding Update）メッセージにより登録（点
線矢印２３ａ参照）される「現在のＣＯＡ」、つまり、
ＭＮの最新のＣＯＡ（ＣＯＡ２＝211.50）でカプセル化
されてルーティングされることになるので、ＭＮが現在
接続しているルータ「Ｒ２」までのパケット転送ルート
が最適化されて（実践矢印２２，２３参照）パケット転
送遅延が最小となる。
【０３１５】一方、データパケットの場合は、「通信開
始時のＣＯＡ」（ＣＯＡ１＝112.50）でカプセル化され
てルーティングされることになるので、例えば図４８に
模式的に示すように、ＭＮが通信継続中は通信開始時に
接続していたルータ（以下、旧ルータという）「Ｒ１」
に対して「スムースハンドオフ指示」を発行して旧ルー
タ「Ｒ１」に「現在のＣＯＡ」（ＣＯＡ２＝211.50）を
登録する（点線矢印２４参照）ことにより旧ルータ「Ｒ
１」からのパスを現在接続しているルータ「Ｒ２」まで
伸ばしておく（実線矢印２６参照）ことで、ＨＡから旧
ルータ「Ｒ１」までのパケット転送ルートは維持される
（実線矢印２５参照）ことになり、ＨＡでパケット転送
先をルータ「Ｒ１」から「Ｒ２」に切り替える場合（図
４７の場合）に比して、パケットロスを最小限に抑制す
ることが可能となる。
【０３１６】このように、本実施形態のＨＡは、受信パ
ケットの「トラフィック種別」に応じて、受信パケット
のカプセル化に用いるＣＯＡを使い分けることにより、
ＭＮに対するハンドオーバの仕組み（方法）を変える
（切り替える）ことができるようになっているのであ
る。なお、以下では、上記の各ハンドオーバ方法のう
ち、前者（ＶＯＩＰパケットについてのハンドオーバ方
法）を第１のハンドオーバ方法、後者（データパケット
についてのハンドオーバ方法）を第２のハンドオーバ方
法ということがある。
【０３１７】次に、図４３において、タイマ処理部４９
Ａは、上述したキャッシュテーブル４４Ａにおける“li
fetime1”，“lifetime2”を更新する機能、即ち、入力
処理部４１でＭＮホームアドレスを宛先アドレス（Ｄ
Ａ）とするパケットが受信されない間は“Lifetime1”,
“lifetime2”をそれぞれデクリメントし、パケットが
受信されている間は“Lifetime1”,“lifetime2”が切
れない（“０”にならない）ように更新（リフレッシ
ュ）する有効期限リフレッシュ部４９１としての機能を
有するとともに、“Lifetime1”,“lifetime2”が切れ
たときに、該当ＣＯＡを削除するＣＯＡ（端末位置情
報）削除部４９２としての機能を有するものである。
【０３１８】また、制御メッセージ処理部５０Ａは、パ
ケット種別識別部４２Ａにおいて自ノード宛のメッセー
ジであると識別された(制御)メッセージを受けて、その
メッセージを処理するためのものである。このため、本
制御メッセージ処理部５０Ａには、図４３中に示すよう
に、メッセージ種別判定部５１Ａ，モバイルメッセージ
処理部５２Ａ，ルーティングメッセージ処理部５３及び
ルータ広告メッセージ（ＲＡ）処理部５４が設けられて
いる。
【０３１９】ここで、上記のメッセージ種別判定部５１
Ａは、受信制御メッセージの種別を判定（識別）するた
めのもので、モバイルメッセージ（結合更新／応答メッ
セージ）とそれ以外のルーティングメッセージとを判別
して、モバイルメッセージについてはモバイルメッセー
ジ処理部５２Ａへ、ルーティングメッセージについては
ルーティングメッセージ処理部５３へそれぞれ振り分け
られるようになっている。
【０３２０】また、モバイルメッセージ処理部５２Ａ
は、受信したモバイルメッセージの種別を判定（解析）
してそのメッセージ内容に応じた処理（キャッシュテー
ブル４４Ａへの情報登録や削除）を行なうためのもの
で、本実施形態では、そのメッセージ種別として、主
に、前記の結合更新（Binding Update）オプションを
用いた結合更新（Binding Update）メッセージ〔位置登
録メッセージ（スムースハンドオフ指示メッセー
ジ）〕，前記の結合応答（Binding Acknowledgemen
t）オプションを用いた結合応答（Binding Acknowledge
ment）メッセージ（位置登録応答メッセージ）等があ
る。ただし、前者のメッセージはＭＮからＨＡ（旧ル
ータ１３′）宛に送信されるメッセージであり、後者
のメッセージは、ＨＡ（旧ルータ１３′）から位置登録
メッセージ送信元のＭＮ宛に送信されるメッセージであ
る。
【０３２１】そして、具体的に、このモバイルメッセー
ジ処理部５２Ａは、ＭＮからの位置登録メッセージ（ス
ムースハンドオフ指示メッセージ）を受信すると、その
メッセージに含まれるＣＯＡを「現在（最新）のＣＯ
Ａ」として前記のキャッシュテーブル４４Ａの該当領域
（ＭＮホームアドレスに対応する領域）に登録（更新）
するようになっている。
【０３２２】ただし、ＨＡにおけるモバイルメッセージ
処理部５２Ａは、受信パケットがデータパケットである
場合に、「通信開始時のＣＯＡ」がキャッシュテーブル
４４Ａに未だ登録されていない場合には、その時の「現
在のＣＯＡ」及び“lifetime1”をコピーして「通信開
始時のＣＯＡ」及び“lifetime 2”として登録すること
ができるようにもなっている。
【０３２３】つまり、図４３において、キャッシュテー
ブル４４Ａ，タイマ処理部４９Ａ及びモバイルメッセー
ジ処理部５２Ａから成る部分は、ＭＮの移動に伴う複数
のＣＯＡ（端末位置情報）を管理する端末位置管理手段
として機能するのである。なお、図４３に示すルーティ
ング処理部５３及びＲＡ処理部５４は、それぞれ、図２
により前述したものと同様のものであり、ＲＩＰ（Rout
ing InformationProtocol）等のルーティングメッセー
ジについての処理（例えば、網構成の変更等に伴うルー
ティング情報の更新等）がルーティングメッセージ処理
部５３によって実施され、在圏ＭＮに対するルータ広告
がルータ広告メッセージ処理部５４によって発行される
ようになっている。
【０３２４】以下、上述のごとく構成された本第２実施
形態のパケット網１′におけるハンドオーバ方法（ＨＡ
の動作）について詳述する。ただし、以下では、説明の
便宜上、受信パケットの「トラフィック種別」の識別
に、前記のtos値を用いることを前提とする（例えば、t
os=0で音声（ＶＯＩＰ）パケット、tos=1でデータパケ
ットを表すものとする）。
【０３２５】まず、ＨＡでは、図５０に示すように、パ
ケットが入力処理部４１において受信されると（ステッ
プＨ１）、その受信パケットの正常性がチェックされた
のち、パケット種別識別部４２Ａにおいて受信パケット
が制御メッセージであるか否かが判定される（ステップ
Ｈ２,Ｈ３）。その結果、受信パケットが制御メッセー
ジであれば、その制御メッセージは、制御メッセージ処
理部５０Ａのメッセージ種別判定部５１Ａに転送され、
メッセージ種別判定部５１Ａにおいて、さらに、その制
御メッセージがモバイルメッセージ（結合更新／応答メ
ッセージ）であるか否かが判定される（ステップＨ３の
ＹｅｓルートからステップＨ４，Ｈ５）。
【０３２６】この結果、受信制御メッセージがモバイル
メッセージであれば、そのモバイルメッセージはモバイ
ルメッセージ処理部５２Ａへ転送され、モバイルメッセ
ージ処理部５２Ａは、受信モバイルメッセージが結合更
新メッセージ（つまり、位置登録メッセージ）であれ
ば、そのメッセージに含まれるＣＯＡがＭＮの「現在の
ＣＯＡ」としてキャッシュテーブル４４Ａの該当領域に
登録する（ステップＨ５のＹｅｓルートからステップＨ
７）。なお、受信モバイルメッセージが結合応答メッセ
ージであった場合、モバイルメッセージ処理部５２Ａ
は、そのメッセージ内容を解析して必要に応じて内部パ
ラメータの変更等を行なう。
【０３２７】ところで、パケット種別識別部４２Ａにお
いて、受信パケットが制御メッセージでないと判定され
た場合（ステップＨ３でＮｏと判定された場合）、その
受信パケットはキャッシュ検索部４３Ａに転送され、図
５１に示すように、キャッシュ検索部４３Ａは、受信パ
ケットの宛先アドレス（ＭＮホームアドレス）を検索キ
ーとしてキャッシュテーブル４４Ａを検索し、ＭＮホー
ムアドレスに対応するＣＯＡ（「現在のＣＯＡ」及び
「通信開始時のＣＯＡ」）を取得する（ステップＨ
８）。
【０３２８】さらに、キャッシュ検索部４３Ａ（トラフ
ィック種別識別部４３１）は、パケット種別識別部４２
Ａから転送されてきたパケットのtos値をチェックする
ことにより、そのパケット種別（音声パケットかデータ
パケットか）を識別（判定）する（ステップＨ９,Ｈ１
０）。この結果、tos値が“０”で受信パケットが音声
（ＶＯＩＰ）パケットであった場合（ステップＨ１０で
Ｙｅｓの場合）、キャッシュ検索部４３Ａは、ＣＯＡ選
択部４３３によって、カプセル化に使用するＣＯＡとし
て上記のステップＨ８で取得したＣＯＡのうち「現在の
ＣＯＡ」を選択する（ステップＨ１１）。
【０３２９】これに対し、tos値が“１”で受信パケッ
トが（ｆｔｐ）データパケットであった場合（ステップ
Ｈ１０でＮｏの場合）、キャッシュ検索部４３Ａは、上
記のステップＨ８で取得したＣＯＡに「通信開始時のＣ
ＯＡ」が含まれている（つまり、キャッシュテーブル４
４Ａに「通信開始時のＣＯＡ」が既に登録されている）
か否かをチェックする（ステップＨ１２）。
【０３３０】その結果、未だ「通信開始時のＣＯＡ」が
登録されていなければ（ステップＨ１２でＮｏであれ
ば）、上記受信パケットがＭＮ宛の第１パケットであ
る、即ち、この時点が「通信開始時」であることを意味
するので、キャッシュ検索部４３Ａは、ＣＯＡ選択部４
３３によって、上記第１パケットのカプセル化に使用す
るＣＯＡとしてこの時点では「現在のＣＯＡ」を選択し
たのち（ステップＨ１３）、コピー登録部４３２によっ
て、その「現在のＣＯＡ」及び“lifetime1”をコピー
して「通信開始時のＣＯＡ」及び“lifetime2”として
キャッシュテーブル４４Ａの該当領域に登録する（ステ
ップＨ１４）。
【０３３１】以降は、キャッシュテーブル４４Ａに「通
信開始時のＣＯＡ」が登録されているので、同じＭＮ宛
の受信パケット（第２パケット以降）については、カプ
セル化に使用するＣＯＡとして、「通信開始時のＣＯ
Ａ」が選択されることになる（ステップＨ１２のＹｅｓ
ルートからステップＨ１５）。なお、この際、通信中に
「通信開始時のＣＯＡ」が有効期限切れになり削除され
てしまわぬように、“lifetime2”がタイマ処理部４９
Ａ（有効期限リフレッシュ部４９１）によってリフレッ
シュされる（ステップＨ１６）。
【０３３２】さて、上述のごとくステップＨ１１,Ｈ１
３又はＨ１５においてキャッシュ検索部４３Ａ（ＣＯＡ
選択部４３３）によって選択された「現在のＣＯＡ」又
は「通信開始時のＣＯＡ」は、受信パケットとともにカ
プセル化処理部４５へ転送され、カプセル化処理部４５
は、そのＣＯＡで受信パケットをカプセル化してルータ
処理部４６へ転送する（ステップＨ１７）。
【０３３３】これにより、カプセル化されたパケット
（トンネルパケット）は、出方路決定部４６ｂにおい
て、ルーティングテーブル４６ａのルーティング情報に
基づいてその出力インタフェースが決定されたのち、出
力処理部４８を通じて決定した出力インタフェースへ送
信される（ステップＨ１８）。即ち、ＶＯＩＰパケット
は「現在のＣＯＡ」に該当するルータ（ＭＮが現在接続
しているルータ）１３′へ向けてルーティングされ、デ
ータパケット（第２パケット以降）は「通信開始時のＣ
ＯＡ」に該当する旧ルータ１３′へルーティングされる
ことになる。
【０３３４】以上のようなＨＡでの動作を前提とするこ
とにより、例えば図４９（Ａ）に示すように、ＭＮが相
手端末ＣＮ（Corresponding Node）とルータ「Ｒ３」,
ＨＡ,ルータ「Ｒ１」経由で音声通話している（このと
き、ＨＡは音声パケットを「現在のＣＯＡ」（112.50）
宛にカプセル化して転送している）状態（実線矢印２
２,２３′参照）で、ＭＮが通信を継続しながらルータ
「Ｒ２」の在圏ゾーンへ移動したとすると（矢印２７参
照）、ＨＡはＭＮから登録された最新のＣＯＡ（211.5
0）で相手端末ＣＮからの音声パケットをカプセル化し
て転送する（第１のハンドオーバ方法を実行する）こと
になる（実線矢印２３参照）。
【０３３５】一方、例えば図４９（Ｂ）に示すように、
ＭＮが相手端末ＣＮ（Corresponding Node）とルータ
「Ｒ３」,ＨＡ,ルータ「Ｒ１」経由でデータ通信してい
る（このとき、ＨＡはデータパケットを「現在のＣＯ
Ａ」（112.50）宛にカプセル化して転送している）状態
（実線矢印２２参照）で、ＭＮがデータ通信を継続しな
がらルータ「Ｒ２」の在圏ゾーンへ移動したとすると
（矢印２８参照）、ＨＡは「通信開始時のＣＯＡ」（11
2.50）で相手端末ＣＮからのデータパケットを引き続き
カプセル化して転送する（第２のハンドオーバ方法を実
行する）ことになる（実線矢印２５参照）。
【０３３６】この場合、ＭＮがルータ「Ｒ２」の在圏ゾ
ーンに移動した時点で、ＭＮの「スムースハンドオフ指
示」により旧ルータ「Ｒ１」に「現在のＣＯＡ」（211.
50）が登録される（点線矢印２４参照）ので、旧ルータ
「Ｒ１」は、ＨＡから「通信開始時のＣＯＡ」（112.5
0）宛に送られてきたパケットを「スムースハンドオフ
指示」により登録されたＣＯＡ（211.50）で再カプセル
化（スムースハンドオフ）して、ＭＮが現在接続してい
るルータ「Ｒ２」へ転送する（実線矢印２６参照）。
【０３３７】なお、「スムースハンドオフ指示」を受け
ることによりスムースハンドオフを実行するルータ（ノ
ード）１３′のことを「アンカーポイント」という。こ
の「アンカーポイント」は、ＭＮの通信が一旦終了した
場合は解除され（「スムースハンドオフ指示」によりＭ
Ｎから登録されたＣＯＡが削除され）、次にＭＮが通信
を開始して「スムースハンドオフ指示」を新たに発行し
たルータ１３′が新たな「アンカーポイント」となる。
【０３３８】以上のように、本実施形態によれば、ＨＡ
において、ＭＮの移動に伴う複数のＣＯＡ（現在のＣＯ
Ａ及び通信開始時のＣＯＡ）を管理しておき、ＭＮ宛の
パケット種別を識別し、識別したパケット種別に応じて
上記のＣＯＡのいずれかを選択（つまり、カプセル化ヘ
ッダの宛先を変更）して、そのＣＯＡに基づいて受信パ
ケットをルーティングすることにより、受信パケットの
種別に応じてハンドオーバ方法を切り替えることができ
るので、ユーザが要求する複数種類の通信サービス品質
（ＱｏＳ：Quality of Service）を満足する通信を柔軟
に実現でき、常にユーザの要求に最適なハンドオーバ方
法を提供してＱｏＳを大幅に向上させることが可能であ
る。
【０３３９】特に、本実施形態では、ＨＡにおいて、受
信パケットが音声パケットであればＭＮの「現在のＣＯ
Ａ」を選択することにより、パケット転送遅延を最小限
に抑制したハンドオーバを実施することができ、受信パ
ケットがデータパケットであれば、ＭＮの「通信開始時
のＣＯＡ」を選択することにより、パケットロスを最小
限に抑制したハンドオーバを実施することができるの
で、ＭＮのユーザが利用する音声通話サービス，データ
通信サービス等に応じた最適なハンドオーバ方法を提供
することができるのである。
【０３４０】また、本実施形態のＨＡでは、「通信開始
時のＣＯＡ」の“lifetime2”を記憶しておき、ＭＮ宛
の受信パケットを受信する毎にその“lifetime2”をタ
イマ処理部４９（有効期限リフレッシュ部４９１）がリ
フレッシュするので、データパケット通信継続中に「通
信開始時のＣＯＡ」が無効になることを防止することが
でき、当該データパケット通信の信頼性も向上してい
る。
【０３４１】さらに、上記のタイマ処理部４９は、「通
信開始時のＣＯＡ」の“lifetime2”が切れると、その
「通信開始時のＣＯＡ」を位置情報削除部４９２が削除
するので、「通信開始時のＣＡＯ」の記憶に必要な記憶
容量を最小限に抑制して、ＨＡの小型化にも大きく寄与
している。また、本実施形態のＭＮは、データパケット
を受信している間、通信開始時に接続していたルータ１
３′（アンカーポイント）に対して「スムースハンドオ
フ指示」を発行するので、「スムースハンドオフ指示」
を受けたルータ１３′からＭＮが現在接続しているルー
タ１３′まで通信パス（パケット転送ルート）を伸ばし
ておくことができ、ハンドオーバに伴うパケットロスを
最小限に抑制することが可能である。
【０３４２】(D1)第２実施形態の第１変形例の説明 さて、上述した第２実施形態では、「通信開始時のＣＯ
Ａ」をパケットの宛先（ＭＮホームアドレス）毎でしか
管理していないので、同一宛先のデータパケットに対し
ては、全て、同一の転送ルートとなるようにＨＡにてカ
プセル化が行なわれることになる。
【０３４３】このため、例えば、ＭＮ宛にある発信者が
既にデータパケットの送信を行なっている状態で、別の
発信者がＭＮ宛にデータパケットを新たに送信しはじめ
ると、ＭＮが別のルータ１３′の在圏ゾーンに移動した
場合でも、そのデータパケットは、既存の発信者が送信
したデータパケットのカプセル化に使用したものと同じ
「通信開始時のＣＯＡ」でカプセル化されてしまい、既
存の発信者が送信したデータパケットのパケット転送ル
ート（スムースハンドオフによるルート）と全く同じル
ートで転送されるという非効率な事態が生じる。
【０３４４】そこで、本変形例では、宛先（ＭＮホーム
アドレス）毎に加えて、受信パケットの発信元（送信元
アドレス：ＳＡ）毎にも「通信開始時のＣＯＡ」を管理
することにより、発信元毎にデータパケットのパケット
転送ルートを変えられるようにして、発信者毎に、常に
最短のアンカーポイント〔スムースハンドオフによるパ
ケット転送を行なうルータ（ノード）〕をとることがで
きるようにする。
【０３４５】これは、例えば図５２（Ｂ）に示すよう
に、キャッシュテーブル４４Ａを、ＭＮホームアドレス
毎に「現在のＣＯＡ」,その有効期限を示す“lifetime
1”及びＭＮホームアドレスを一意に表すＩＤの組が登
録・管理されるキャッシュテーブル４４１（Biding Cac
he1）と、上記ＩＤと受信パケットの送信元アドレス
（ＳＡ）との組み合わせ毎に「通信開始時のＣＯＡ」及
びその有効期限を示す“lifetime2”の組が登録・管理
されるキャッシュテーブル４４２（Binding Cache 2）
とにより構成することで実現できる。
【０３４６】そして、本変形例においても、図４４
（Ａ）と同様に、ＨＡのネットワークＩＤを“１４
４”、ルータ「Ｒ２」のネットワークＩＤを“２１
１”、ルータ「Ｒ１」のネットワークＩＤを“１１２”
とすると、ＨＡのアドレスは“144.y”、ルータ「Ｒ
２」のアドレスは“211.y”、ルータ「Ｒ１」のアドレ
スは“112.y”と表され、ＭＮのインタフェースＩＤを
“５０”とすると、ＭＮは、ルータ「Ｒ１」の在圏ゾー
ン１３′−２に位置する時はＣＯＡ＝“112.50”、ルー
タ「Ｒ２」の在圏ゾーン１３′−１に位置する時はＣＯ
Ａ＝“211.50”を作成して、それぞれ、ＨＡに通知（位
置登録）することになる。
【０３４７】従って、仮に、ＭＮがルータ「Ｒ１」の在
圏ゾーン１３′−２に位置する時にそのルータ「Ｒ１」
に接続して、ルータ「Ｒ３」に接続している相手端末
「ＣＮ１」（仮に、送信元アドレス＝70.21とする）と
データ通信を開始したとすると、ＨＡのキャッシュテー
ブル４４２には、図５２（Ｂ）に示すように、相手端末
「ＣＮ１」との「通信開始時のＣＯＡ」として“112.5
0”が登録されることになる。
【０３４８】また、その後に、ＭＮがルータ「Ｒ２」の
在圏ゾーン１３′−１に位置する時に、そのルータ「Ｒ
２」に接続して、ルータ「Ｒ４」に接続している別の相
手端末「ＣＮ２」（仮に、送信元アドレス＝80.30とす
る）とデータ通信を開始したとすると、ＨＡのキャッシ
ュテーブル４４２には、別の相手端末「ＣＮ２」との
「通信開始時のＣＯＡ」として“211.50”が登録される
ことになる。なお、“lifetime1”及び“lifetime2”の
機能は、上述した第２実施形態で説明したものと同様で
ある。
【０３４９】そして、この場合のＨＡは、図５４及び図
５５に示すフローチャートに従って動作することによ
り、発信者（「ＣＮ１」，「ＣＮ２」）毎に、常に最短
のアンカーポイントをとるようにデータパケットの転送
（ルーティング）を実施することができる。即ち、図５
４に示すように、図５０により前述したステップＨ７に
おいて、キャッシュテーブル４４１（Binding Cache1）
に「現在のＣＯＡ」を登録し（ステップＨ７′）、図５
５に示すように、図５１により前述したステップＨ８に
おいて、キャッシュ検索部４３Ａが、ＭＮホームアドレ
ス及びＩＤをキーにして各キャッシュテーブル４４１，
４４２を検索して、ＭＮホームアドレス及びＩＤに対応
する「現在のＣＯＡ」及び送信元アドレス毎の「通信開
始時のＣＯＡ」を取得する（ステップＨ８ａ，Ｈ８ｂ）
ようにするのである。なお、他の処理は図５０及び図５
１に示す処理と同様である。
【０３５０】これにより、音声パケットについての転送
ルート（ハンドオーバ）は、図５３（Ａ）に模式的に示
すように、発信者の数に関わらず、発信者（「ＣＮ
１」，「ＣＮ２」）毎に図４９（Ａ）に示すものと同一
になるが、データパケットの場合は、図５３（Ｂ）に模
式的に示すようなる。即ち、ＭＮがルータ「Ｒ１」に接
続している時に相手端末「ＣＮ１」（ＳＡ＝70.21）が
データパケットの送信を開始し、その後に、ＭＮがルー
タ「Ｒ２」側へ移動し（矢印２８参照）、別の相手端末
「ＣＮ２」がＭＮ宛データパケットの送信を開始した場
合、相手端末「ＣＮ１」の送信したデータパケットは、
ＭＮが移動しても、ＨＡで「通信開始時のＣＯＡ（112.
50）」によりカプセル化されるので、図４９（Ｂ）の場
合と同様に、相手端末「ＣＮ１」ルータ「Ｒ４」→ＨＡ
→ルータ「Ｒ１」（スムースハンドオフ）→ルータ「Ｒ
２」→ＭＮという経路を辿ってＭＮに到達することにな
る（矢印２２，２５，２６参照）。
【０３５１】一方、別の相手端末「ＣＮ」が送信したデ
ータパケットは、ＭＮがルータ「Ｒ２」側に移動した後
に送信されたので、ＨＡにおいて「通信開始時のＣＯＡ
（211.50）」宛にカプセルされることになり、ルータ
「Ｒ１」は経由せずにルータ「Ｒ２」経由でＭＮに到達
することになる（矢印２９ａ〜２９ｄ参照）。このよう
に、本変形例では、ＨＡにおいて、「通信開始時のＣＯ
Ａ」を、宛先アドレス（ＤＡ）及び送信元アドレス（Ｓ
Ａ）の異なる受信パケットのそれぞれについて管理する
ことにより、パケットの発信者（相手端末「ＣＮ１」，
「ＣＮ２」）毎に最適なアンカーポイント（パケット転
送ルート）を設定することができるので、ＭＮに対する
通信サービス品質をより一層向上することができる。
【０３５２】なお、本変形例では、ＩＤを用いてＭＮホ
ームアドレスと送信元アドレスの対応付け（キャッシュ
テーブル４４１と４４２の対応付け）を行なっている
が、ＩＤの代わりにＭＮホームアドレスにより各テーブ
ル４４１，４４２の対応付けを行なってもよいし、ＭＮ
ホームアドレスによりこれらの各テーブル４４１，４４
２を単一のテーブルにまとめるようにしてもよい。
【０３５３】(D2)第２実施形態の第２変形例の説明 さて、上述した受信パケットの「トラフィック種別」に
応じたハンドオーバ方法の切り替えは、第１実施形態に
て前述したシステム（即ち、ＥＮがＶＨＡ／ＴＨＡから
「キャッシュ」を受けて、その「キャッシュ」に基づい
てＥＮがＶＨＡ／ＴＨＡに代わってＭＮ宛パケットのル
ーティングを実施するシステム）に適用することもでき
る。
【０３５４】即ち、この場合は、例えば図５６に示すよ
うに、図４により前述したＶＨＡ／ＴＨＡにおける「キ
ャッシュ」（キャッシュデータ６１ａ及び通信中ＥＮア
ドレスデータ６１ｂ）に、さらに、上述した「通信開始
時のＣＯＡ」をアンカーＣＯＡデータ６１ｃとして記録
・管理するためのデータ領域を付加するとともに、キャ
ッシュ検索部４３に、第２実施形態のキャッシュ検索部
４３Ａと同等の機能をもたせる。
【０３５５】なお、ＶＨＡ／ＴＨＡにおいて、「現在の
ＣＯＡ」はキャッシュデータ６１ａに含まれているＣＯ
Ａである。また、上記のアンカーＣＯＡデータ６１ｃ
は、通信中ＥＮアドレスデータ６１ｂとは特に関連はな
く、キャッシュデータ６１ａ及び通信中ＥＮアドレスデ
ータ６１ｂとは別個に設けてもよい。つまり、ＶＨＡ／
ＴＨＡは、少なくとも、図４４（Ｂ）、もしくは、図５
２（Ｂ）により前述したキャッシュテーブル４４Ａ（４
４１，４４２）を有していればよい。
【０３５６】一方、ＥＮには、図２に示すキャッシュ検
索部４３に、前記のトラフィック種別識別部４３１及び
コピー登録部４３２としての機能と、識別した「トラフ
ィック種別」がＶＯＩＰパケットである場合にはその受
信パケットを第１実施形態と同様にカプセル化すべくカ
プセル化処理部４５へ転送する一方、データパケットで
ある場合には受信パケットをカプセル化せずにルータ処
理部４６（出方路決定部４６ｂ）へブリッジする（図５
７に示すステップＨ１０のＮｏルート参照）ブリッジ部
４３４としての機能とをもたせる。
【０３５７】なお、その他の動作は図５１及び図５２に
より前述したルータ１３′の動作と同様である。ただ
し、勿論、第１実施形態におけるＥＮと同様の動作が前
提である。これにより、例えば図５８（Ａ）に模式的に
示すように、ＥＮでは、第１実施形態にて前述したよう
にＶＨＡ／ＴＨＡから「キャッシュ」の通知を受けた後
〔図５８（Ａ）及び図５８（Ｂ）の点線矢印８１参
照〕、相手端末ＣＮからの受信したパケットの「トラフ
ィック種別」がＶＯＩＰパケットであれば、常に、カプ
セル化処理部４５が「現在のＣＯＡ」を用いて第１実施
形態と同様のカプセル化を実行することにより、ルータ
処理部４６がＶＨＡ／ＴＨＡに代わってその受信パケッ
トの在圏ＥＮへのルーティング（ルート最適化）を実行
する（図５７に示すステップＨ１０のＹｅｓルートから
ステップＨ１８）。
【０３５８】この結果、相手端末ＣＮが送信したＶＯＩ
Ｐパケットは、第１のハンドオーバ方法により、ＶＨＡ
／ＴＨＡを経由することなく、常に、最適ルートで在圏
ＥＮへルーティングされることになる〔図５８（Ａ）に
示す点線矢印８２参照〕ので、上述した第２実施形態に
比して、パケット転送遅延がさらに削減されて、ハンド
オーバ時の音声通話品質を高品質に維持することができ
る。
【０３５９】一方、受信パケットの「トラフィック種
別」がデータパケットであれば、キャッシュ検索部４３
（ブリッジ部４３４）がその受信パケットをカプセル化
せずにそのままルータ処理部４６へブリッジすることに
より、当該受信パケットをルータ処理部４６がＶＨＡ／
ＴＨＡ（ゲートノード）へルーティングすることになる
〔ステップＨ１０のＮｏルートからステップＨ１７，Ｈ
１８；図５８（Ｂ）に示す実線矢印８３参照〕。
【０３６０】ＶＨＡ／ＴＨＡでは、第２実施形態と同様
に、受信パケットがデータパケットであることを識別し
てその受信パケットを「通信開始時のＣＯＡ」〔図５８
（Ｂ）ではＣＯＡ１〕でカプセル化することにより、そ
の受信パケットをＭＮが通信を開始した時のＥＮ（アン
カーポイント）へルーティングする〔図５８（Ｂ）に示
す実線矢印８４参照〕。
【０３６１】そして、アンカーポイントであるＥＮで
は、上述した第２実施形態と同様に、ＭＮからの「スム
ースハンドオフ指示」により登録されているＭＮの「現
在のＣＯＡ」〔図５８（Ｂ）ではＣＯＡ２〕でＭＮ宛の
受信パケットを再カプセル化してスムースハンドオフを
実行する。これにより、ＭＮ宛のパケットは、第２のハ
ンドオーバ方法によって、図５８（Ｂ）中に示す点線矢
印８５で示すルートでＭＮに届けられることになる。
【０３６２】以上のように、本変形例では、第１実施形
態にて前述したシステムにおけるＥＮ（通信中ＥＮ）に
おいて、受信パケットがパケットロスを許容するパケッ
ト（例えば、音声パケット）である場合にのみ、ＶＨＡ
／ＴＨＡから通知（コピー）された「キャッシュ」
（「現在のＣＯＡ」）でその受信パケットをカプセル化
することにより、ＶＨＡ／ＴＨＡに代わって本ＥＮが受
信パケットを在圏ＥＮへルーティングするので、ＶＯＩ
Ｐパケットについてのハンドオーバ時には常にルート最
適化が行なわれることになる。従って、上述した第２実
施形態に比して、パケット転送遅延がさらに削減され
て、ハンドオーバ時の音声通話品質を高品質に維持する
ことができる。
【０３６３】一方、受信パケットがデータパケットであ
る場合は、ＶＨＡ／ＴＨＡから通知された「キャッシ
ュ」での受信パケットのカプセル化は行なわずに、ＶＨ
Ａ／ＴＨＡへそのままルーティングすることにより、前
述した第２実施形態と同様にして、アンカーポイントで
のスムースハンドオフによるハンドオーバが実現される
ので、データパケット通信継続中のハンドオーバ時のパ
ケットロスを最小限に抑制することができる。
【０３６４】(D3)第２実施形態の第３変形例の説明 次に、以下では、上述した第２実施形態の第３変形例と
して、加入者が契約したサービスに従ってハンドオーバ
方法を切り替える場合について、図５９（Ａ）及び図５
９（Ｂ）を参照しながら説明する。即ち、この場合、Ｍ
Ｎのユーザ（加入者）は、予め契約等により、ハンドオ
ーバ方法の切り替えサービス（ハンドオーバ条件）につ
いての情報、例えば、tos値=“０”，“１”のときは
「現在のＣＯＡ」、tos値=“２”，“３”のときは「通
信開始時のＣＯＡ」をそれぞれ使用する旨の情報をキャ
リア（網運用者）等に通知しておく。
【０３６５】キャリアは、このハンドオーバ条件に関す
る情報（以下、「ハンドオーバ条件データ」、もしく
は、単に「ハンドオーバ条件」という）を加入者（ＭＮ
ホームアドレス）毎に、例えば図５９（Ａ）に示す、Ｍ
Ｎの加入者についてのサービス契約状況，課金状況等を
加入者データとして管理するサーバ〔例えば、ＡＡＡ
（Authentication, Authorization and Accounting）サ
ーバ等；以下、加入者データサーバという〕１４に登録
しておく。
【０３６６】そして、ＨＡは、キャッシュテーブル４４
Ａの作成時等に、この加入者データサーバ１４から上記
のハンドオーバ条件データをダウンロードし、例えば図
５９（Ｂ）に示すように、キャッシュテーブル４４Ａと
ともに、そのダウンロードデータ（ハンドオーバ条件デ
ータ）４４Ｂ（この例では、ＭＮホームアドレス＝144.
50をもつＭＮの加入者のハンドオーバ条件）を保持す
る。
【０３６７】これにより、ＨＡでは、パケット受信時
に、キャッシュ検索部４３Ａが、このハンドオーバ条件
データ４４Ｂに基づいて「現在のＣＯＡ」，「通信開始
時のＣＯＡ」のいずれを使って受信パケットをカプセル
化すべきかを判断する、つまり、加入者毎にハンドオー
バの方法を設定することが可能となる。即ち、この例で
は、ＭＮ宛の受信パケットのtos値が“０”又は“１”
であれば、図４７及び図４９（Ａ）により前述した第１
のハンドオーバ方法がＨＡにより実行され、ＭＮ宛の受
信パケットのtos値が“２”又は“３”であれば、図４
８及び図４９（Ｂ）により前述し第２のハンドオーバ方
法がＨＡにより実行されることになる。
【０３６８】なお、上記のハンドオーバ条件は、加入者
との契約条件によって適宜に設定・変更することができ
る。例えば図６０に示すように「常に現在のＣＯＡを使
う」という条件を設定することで、ＭＮ（ＭＮホームア
ドレス）宛のパケットについてはその「トラフィック種
別」に関わらず常に前述したＶＯＩＰパケットについて
のハンドオーバ方法のみが適用される（つまり、通常の
MobileIP機能のみを加入者に提供する）ようにしてもよ
いし、逆に、「常に通信開始時のＣＯＡを使う」という
条件を設定することで、ＭＮ宛のパケットについてはそ
の「トラフィック種別」に関わらず常に前述したデータ
パケットについてのハンドオーバ方法が適用されるよう
にしてもよい。
【０３６９】以上のように、本変形例では、ＨＡがＭＮ
のユーザについてのハンドオーバ条件データを含む加入
者データを管理する加入者データサーバ１４から取得
し、取得したハンドオーバ条件データに基づいて「現在
のＣＯＡ」，「通信開始時のＣＯＡ」の選択を制御する
ことができるので、ＭＮのユーザ毎にハンドオーバ条件
を設定することが可能になり、よりきめ細かいハンドオ
ーバ方法の変更が可能になる。
【０３７０】(D4)第２実施形態の第４変形例の説明 さて、上述した第２実施形態及びその各変形例では、通
常の（非階層化）Mobile-IPに準拠したパケット網、も
しくは、第１実施形態におけるＭ３網に、パケット種別
に応じたハンドオーバ方法の切り替えを適用した場合に
ついて説明したが、勿論、通常の階層化Mobile-IP網に
適用することも可能である。
【０３７１】即ち、図６１及び図６２に模式的に示すよ
うに、パケット網を階層化するノード（ＨＡ及び／又は
ＭＡ）において、「通信開始時のＣＯＡ」を記憶してお
き、受信パケットの「トラフィック種別」に応じて、前
記と同様に、「現在（最新）のＣＯＡ」及び「通信開始
時のＣＯＡ」のいずれかを使用してカプセル化すること
で、適用が可能である。
【０３７２】ここで、通常の階層化Mobile-IP網におけ
るＭＮには、前述したように２種類のアドレス〔パケッ
トが階層化ノード（ＭＡ）まで到達できるためのアドレ
ス（VCOA）およびパケットがＭＡからＭＮまで到達でき
るためのアドレス（PCOA）〕が割り当てられ、ＨＡの
「結合キャッシュ（BindingCache）」に登録されるのは
「VCOA」であり、階層化ノード（ＭＡ）をまたいだハン
ドオーバの時に、ＨＡに登録された「VCOA」の更新が行
なわれる。
【０３７３】従って、通常の階層化Mobile-IP網におけ
るＨＡに前述したハンドオーバ方法の切り替えを適用す
る場合には、「BindingCache」として、「現在のＶＣＯ
Ａ」と「通信開始時のＶＣＯＡ」とを保持することにな
る。例えば図６１では、ＭＮが階層化ノード「ＭＡ１」
が管轄する基地局ノード（ルーティングノード）「ＢＳ
２」に接続して相手端末ＣＮとの通信を開始し（VCOA=V
COA1，PCOA=PCOA2）、その後、通信を継続しながら別の
階層化ノード「ＭＡ２」が管轄する基地局ノード「ＢＳ
３」の在圏ゾーンへ移動した場合（VCOA=VCOA2，PCOA=P
COA3）を示しており、この場合、ＨＡでは、「現在のＣ
ＯＡ」として“VCOA2”を保持し、「通信開始時のＣＯ
Ａ」として“VCOA1”を保持することになる。
【０３７４】これにより、ＨＡでは、例えば、受信パケ
ットがＶＯＩＰパケットであればその受信パケットを
「現在のＶＣＯＡ（＝VCOA2）」でカプセル化し、デー
タパケットであれば「通信開始時のＶＣＯＡ（＝VCOA
1）」でカプセルすることで、階層化ノード（ＭＡ１，
ＭＡ２）をまたぐハンドオーバを行なう際に、パケット
種別に応じたハンドオーバ方法（パケット転送ルート）
の切り替えが可能となる（ＶＯＩＰパケットの場合は図
６１に矢印８６〜８８に示すパケット転送ルート、デー
タパケットの場合は図６１に示す矢印８６，８９，９０
に示すパケット転送ルートとなる）。
【０３７５】一方、階層化ノード（ＭＡ）に、同様のハ
ンドオーバ方法の切り替えを適用するには、ＭＡの「Bi
ndingCache」として登録されるのが、「VCOA」をキーと
した「PCOA」であり、ＭＮの基地局ノードをまたぐ移動
によりＭＮから新たな「PCOA」が登録（更新）されるた
め、ＭＡの「BindingCache」として、「現在のＰＣＯ
Ａ」と「通信開始時のＰＣＯＡ」とを保持すればよいこ
とになる。
【０３７６】例えば図６２では、ＭＮが基地局ノード
「ＢＳ３」に接続して相手端末ＣＮとの通信を開始し
（VCOA=VCOA2，PCOA=PCOA3）、その後、通信を継続しな
がら別の基地局ノード「ＢＳ４」の在圏ゾーンへ移動し
た場合（VCOA=VCOA2，PCOA=PCOA4）を示しており、この
場合、ＨＡでは、「現在のＣＯＡ」として“PCOA4”を
保持し、「通信開始時のＣＯＡ」として“PCOA3”を保
持することになる。
【０３７７】これにより、ＭＡでは、例えば、受信パケ
ットがＶＯＩＰパケットであればその受信パケットを
「現在のＰＣＯＡ（＝PCOA4）」でカプセル化し、デー
タパケットであれば「通信開始時のＰＣＯＡ（＝PCOA
3）」でカプセルすることで、基地局ノード（ＢＳ３，
ＢＳ４）をまたぐハンドオーバを行なう際に、パケット
種別に応じたハンドオーバ方法（パケット転送ルート）
の切り替えが可能となる（ＶＯＩＰパケットの場合は図
６２に矢印８６，８６′，８７′に示すパケット転送ル
ート、データパケットの場合は図６２に示す矢印８６，
８６′，８８′に示すパケット転送ルートとなる）。
【０３７８】このようにして、本変形例では、通常の階
層化Mobile-IP網におけるＨＡ及びＭＡのいずれにおい
ても、受信パケットの「トラフィック種別」（通信サー
ビス）に応じた最適なハンドオーバ方法の切り替えを実
現することができるので、通常の階層化Mobile-IP網に
おいても、第２実施形態と同様に、ユーザが要求する複
数種類のＱｏＳを満足する通信を柔軟に実現でき、常に
ユーザの要求に最適なハンドオーバ方法を提供してＱｏ
Ｓを大幅に向上させることが可能である。
【０３７９】(E)その他 なお、上述した第２実施形態における「トラフィック種
別」の識別は、「IPv6」のＩＰヘッダ７０に含まれる
「ホップ制限数」（Hop Limit）フィールド７１６（図
４５及び図４６等参照）〔「IPv4」ではＴＴＬ（Time T
o Live）フィールドに相当する〕に設定されている値
（ノード通過毎に減算される）を使用することもでき
る。
【０３８０】即ち、ノード到着時に、「ホップ制限数」
フィールド７１６（又は、ＴＴＬフィールド）の値が
“０”となったパケットはその時点で廃棄されるので、
例えば、「ホップ制限数」フィールド７１６（又は、Ｔ
ＴＬフィールド）の値が所定値以下のパケットについて
は、できるだけ廃棄されないよう、すなわち、以降の通
過ノード数が少なくなるようにハンドオーバ方法を変更
するのである。これにより、最適ルートでのパケット転
送が可能になる。
【０３８１】また、上述した第２実施形態では、パケッ
トロスを許容する特性をもつ「トラフィック種別」のパ
ケットとして音声（ＶＯＩＰ）パケット、パケット転送
遅延を許容する「トラフィック種別」のパケットとして
（ｆｔｐ）データパケットを例にしたが、勿論、それぞ
れの特性を満足するパケットであれば他の種別のパケッ
トであってもよい。
【０３８２】そして、本発明は、上述した各実施形態及
びその変形例に限定されるものではなく、本発明の趣旨
を逸脱しない範囲で種々変形して実施することができ
る。 (F)付記 （付記１） 移動端末と通信してパケットの送受を行な
いうる複数のエッジノードと、該移動端末の現在位置情
報を管理し当該現在位置情報に基づいて該移動端末宛の
パケットを該移動端末がその現在位置から通信可能なエ
ッジノード（以下、在圏エッジノードという）へルーテ
ィングしうるゲートノードとをそなえて成る階層化パケ
ット網において、該特定のゲートノードが、自己が管理
する該移動端末の現在位置情報をキャッシュ情報として
該移動端末宛のパケットを自己宛にルーティングしてく
るエッジノード（以下、通信中エッジノードという）に
通知し、当該通信中エッジノードが、該キャッシュ情報
に基づき該ゲートノードに代わって該移動端末宛のパケ
ットの該在圏エッジノードに対するルーティングを実施
することを特徴とする、階層化パケット網におけるパケ
ット転送方法。
【０３８３】（付記２） 該エッジノードが、それぞ
れ、少なくとも自己を収容するゲートノードの識別情報
（以下、ゲートノード識別情報という）と該階層化パケ
ット網の識別情報（以下、網識別情報という）とを含む
報知情報を該移動端末に送信し、該移動端末は、該報知
情報に含まれる該ゲートノード識別情報が自己の移動に
伴って変化しても該網識別情報が変化していなければ、
自己の現在位置情報の登録先を、該ゲートノードに維持
することを特徴とする、付記１記載の階層化パケット網
におけるパケット転送方法。
【０３８４】（付記３） 該ゲートノードは、該移動端
末からその移動に伴って通知される新たな現在位置情報
に基づいて該通信中エッジノードの該キャッシュ情報を
更新し、当該通信中エッジノードは、更新後のキャッシ
ュ情報に基づいて該移動端末宛のパケットを該ゲートノ
ードに代わって新たな在圏エッジノードへルーティング
することを特徴とする、付記２記載の階層化パケット網
におけるパケット転送方法。
【０３８５】（付記４） 該通信中エッジノードは、該
移動端末宛のパケットを該特定のゲートノードへルーテ
ィングする際に該キャッシュ情報が無いと、該特定のゲ
ートノードへ該キャッシュ情報を要求することを特徴と
する、付記１記載の階層化パケット網におけるパケット
転送方法。 （付記５） 該ゲートノードは、該キャッシュ情報の要
求を受けた場合に、要求元の該通信中エッジノードに該
キャッシュ情報を通知することを特徴とする、付記４記
載の階層化パケット網におけるパケット転送方法。
【０３８６】（付記６） 該ゲートノードは、該通信中
エッジノードの識別情報を保持しておき、該移動端末の
移動に伴って該移動端末から新たな現在位置情報の通知
を受けると、当該新たな現在位置情報に基づいて、該通
信中エッジノードの識別情報によって識別される該通信
中エッジノードに対して該キャッシュ情報の更新を実施
することを特徴とする、付記３記載の階層化パケット網
におけるパケット転送方法。
【０３８７】（付記７） 該通信中エッジノードは、該
移動端末宛のパケットを受信する毎に、該キャッシュ情
報の有効期限をリフレッシュすることを特徴とする、付
記１〜６のいずれか１項に記載の階層化パケット網にお
けるパケット転送方法。 （付記８） 該通信中エッジノードは、通信が終了して
該キャッシュ情報の有効期限が終了すると、該ゲートノ
ードに対して当該ゲートノードで管理されている該通信
中エッジノードの識別情報の削除要求を行ない、該削除
要求を受けたゲートノードは、該通信中エッジノードの
識別情報を削除することを特徴とする、請求項４記載の
階層化パケット網におけるパケット転送方法。
【０３８８】（付記９） 該移動端末は、該報知情報に
含まれる該網識別情報が変化していない場合であって
も、所定の付加的条件下において該ゲートノード識別情
報が変化していれば、自己の現在位置情報の登録先を変
化後のゲートノード識別情報によって識別されるゲート
ノードに変更することを特徴とする、付記２記載の階層
化パケット網におけるパケット転送方法。
【０３８９】（付記１０） 該移動端末は、一定周期経
過毎に該報知情報に含まれる該ゲートノード識別情報が
変化しているか否かを監視し、該付加的条件として該一
定周期経過時に該ゲートノード識別情報が変化していれ
ば、上記のゲートノードの変更を実施することを特徴と
する、付記９記載の階層化パケット網におけるパケット
転送方法。
【０３９０】（付記１１） 該移動端末は、該付加的条
件として自己の非通信中に該ゲートノード識別情報が変
化していれば、上記のゲートノードの変更を実施するこ
とを特徴とする、付記９記載の階層化パケット網におけ
るパケット転送方法。 （付記１２） 該移動端末は、自己の通信トラフィック
量を監視し、該付加的条件として当該通信トラフィック
量が所定値以下であるときに該ゲートノード識別情報が
変化していれば、上記のゲートノードの変更を実施する
ことを特徴とする、付記１１記載の階層化パケット網に
おけるパケット転送方法。
【０３９１】（付記１３） 該移動端末は、通信中のデ
ータトラフィックタイプを識別し、該付加的条件として
識別したデータトラフィックタイプが特定のデータトラ
フィックタイプであるときに該ゲートノード識別情報が
変化していれば、上記のゲートノードの変更を実施する
ことを特徴とする、付記９記載の階層化パケット網にお
けるパケット転送方法。
【０３９２】（付記１４） 該移動端末は、通信に使用
するアプリケーションの使用状態を監視し、該付加的条
件として該アプリケーションが未使用であるときに該ゲ
ートノード識別情報が変化していれば、上記のゲートノ
ードの変更を実施することを特徴とする、付記９記載の
階層化パケット網におけるパケット転送方法。 （付記１５） 該移動端末は、一定周期が経過したと
き、非通信中であるとき、通信トラフィック量が所定値
以下であるとき、通信中のデータトラフィックタイプが
特定のデータトラフィックタイプであるとき、通信に使
用するアプリケーションが未使用であるときの任意の付
加的条件の組み合わせによって特定される組み合わせ条
件下において該ゲートノード識別情報が変化していれ
ば、上記のゲートノードの変更を実施することを特徴と
する、付記９記載の階層化パケット網におけるパケット
転送方法。
【０３９３】（付記１６） 移動端末と通信してパケッ
トの送受を行ないうる複数のエッジノードと、該移動端
末の現在位置情報を管理し当該現在位置情報に基づいて
該移動端末宛のパケットを該移動端末がその現在位置か
ら通信可能なエッジノード（以下、在圏エッジノードと
いう）へルーティングしうるゲートノードとをそなえて
成る階層化パケット通信システムにおいて、該移動端末
が、該在圏エッジノードの識別情報に基づく位置情報を
該現在位置情報として特定のゲートノードに通知して登
録する現在位置登録手段をそなえるとともに、該ゲート
ノードが、該移動端末の該現在位置登録手段によって通
知される該現在位置情報を管理する端末位置管理手段
と、該端末位置管理手段で管理されている該現在位置情
報をキャッシュ情報として該移動端末宛のパケットを自
己宛にルーティングしてくるエッジノード（以下、通信
中エッジノードという）に通知するキャッシュ情報通知
手段とをそなえ、且つ、該エッジノードが、該ゲートノ
ードの該キャッシュ情報通知手段により通知されたキャ
ッシュ情報を保持するキャッシュ手段と、該キャッシュ
手段に保持されている該キャッシュ情報に基づき該ゲー
トノードに代わって該移動端末宛のパケットの該在圏エ
ッジノードに対するルーティングを実施するルーティン
グ手段とをそなえて構成されていることを特徴とする、
階層化パケット通信システム。
【０３９４】（付記１７） 該エッジノードが、それぞ
れ、少なくとも自己を収容するゲートノードの識別情報
（以下、ゲートノード識別情報という）と該階層化パケ
ット網の識別情報（以下、網識別情報という）とを含む
報知情報を該移動端末に送信する報知情報送信手段をそ
なえるとともに、該移動端末の該現在位置登録手段が、
該報知情報を受信する報知情報受信手段と、該報知情報
受信手段で受信された報知情報に含まれる該ゲートノー
ド識別情報が変化したか否かを監視するゲートノード識
別情報監視手段と、該報知情報に含まれる該網識別情報
が変化したか否かを監視する網識別情報監視手段と、該
ゲートノード識別情報監視手段で該ゲートノード識別情
報の変化が検知されても該網識別情報監視手段において
該網識別情報の変化が検知されていなければ、該ゲート
ノードに自己の現在位置情報を通知する現在位置通知手
段とをそなえて構成されていることを特徴とする、付記
１６記載の階層化パケット通信システム。
【０３９５】（付記１８） 該ゲートノードが、該移動
端末の移動に伴って該現在位置通知手段により該移動端
末から新たに通知されてくる現在位置情報に基づいて、
該通信中エッジノードのキャッシュ情報を更新するキャ
ッシュ情報更新手段をそなえるとともに、該エッジノー
ドの該ルーティング手段が、該キャッシュ情報更新手段
による更新後のキャッシュ情報に基づいて該移動端末宛
のパケットを該ゲートノードに代わって新たな在圏エッ
ジノードへルーティングするように構成されたことを特
徴とする、付記１７記載の階層化パケット通信システ
ム。
【０３９６】（付記１９） 該エッジノードが、該移動
端末宛のパケットを該ゲートノードへルーティングする
際に該キャッシュ手段に該キャッシュ情報が無いと、該
ゲートノードへ該キャッシュ情報を要求するキャッシュ
情報要求手段をそなえていることを特徴とする、付記１
６記載の階層化パケット通信システム。
【０３９７】（付記２０） 該ゲートノードの該キャッ
シュ情報通知手段が、該エッジノードの該キャッシュ情
報要求手段による該キャッシュ情報の要求を受けた場合
に、当該要求元のエッジノードに該キャッシュ情報を通
知するように構成されたことを特徴とする、付記１９記
載の階層化パケット通信システム。 （付記２１） 該ゲートノードが、該通信中エッジノー
ドの識別情報を保持するノード識別情報保持手段をそな
えるとともに、該キャッシュ情報更新手段が、上記の新
たな現在位置情報の通知を受けると、該ノード識別情報
保持手段に保持された識別情報によって識別されるエッ
ジノードに対して該キャッシュ情報の更新を実施するよ
うに構成されたことを特徴とする、付記１８記載の階層
化パケット通信システム。
【０３９８】（付記２２） 該ノード識別情報保持手段
が、複数の通信中エッジノードの識別情報を保持しうる
ように構成されたことを特徴とする、付記２１記載の階
層化パケット通信システム。 （付記２３） 該エッジノードが、該移動端末宛のパケ
ットを受信する毎に、該キャッシュ情報保持手段に保持
された該キャッシュ情報の有効期限をリフレッシュする
リフレッシュ手段をそなえていることを特徴とする、付
記１６〜２２のいずれか１項に記載の階層化パケット通
信システム。
【０３９９】（付記２４） 該通信中エッジノードが、
通信が終了して該キャッシュ情報の有効期限が終了する
と、該ゲートノードに対して自己の識別情報の削除を要
求するノード識別情報削除要求手段をそなえるととも
に、該ゲートノードが、該エッジノードの該ノード識別
情報削除要求手段による該削除要求を受けると、該ノー
ド識別情報保持手段に保持している該通信中エッジノー
ドの識別情報を削除するノード識別情報削除手段をそな
えていることを特徴とする、付記２１又は付記２２に記
載の階層化パケット通信システム。
【０４００】（付記２５） 該移動端末の該ゲートノー
ド識別情報監視手段が、所定の付加的条件下において該
ゲートノード識別情報が変化したか否かを検知する条件
付監視手段として構成されるとともに、該現在位置通知
手段が、該条件付監視手段にて該付加的条件下において
該ゲートノード識別情報の変化が検知されると、該網識
別情報監視手段にて該網識別情報に変化が無い場合であ
っても、変化後のゲートノード識別情報によって識別さ
れる新たなゲートノードに自己の現在位置情報を通知す
る条件付通知手段をそなえていることを特徴とする、付
記１７記載の階層化パケット通信システム。
【０４０１】（付記２６） 移動端末と通信してパケッ
トの送受を行ないうる複数のエッジノードと、該移動端
末の現在位置情報を管理し当該現在位置情報に基づいて
該移動端末宛のパケットを該移動端末がその現在位置か
ら通信可能なエッジノード（以下、在圏エッジノードと
いう）へルーティングしうるゲートノードとをそなえて
成る階層化パケット通信システムに使用される該ゲート
ノードであって、該移動端末から当該移動端末の現在位
置情報として通知されてくる、該在圏エッジノードの識
別情報に基づく位置情報を管理する端末位置管理手段
と、該端末位置管理手段で管理されている該現在位置情
報をキャッシュ情報として該移動端末宛のパケットをル
ーティングしてくるエッジノードに通知するキャッシュ
情報通知手段とをそなえたことを特徴とする、階層化パ
ケット通信システムに使用されるゲートノード。
【０４０２】（付記２７） 移動端末と通信してパケッ
トの送受を行ないうる複数のエッジノードと、該移動端
末の現在位置情報を管理し当該現在位置情報に基づいて
該移動端末宛のパケットを該移動端末がその現在位置か
ら通信可能なエッジノード（以下、在圏エッジノードと
いう）へルーティングしうるゲートノードとをそなえて
成る階層化パケット通信システムに使用される該エッジ
ノードであって、該ゲートノードで管理されている、該
在圏エッジノードの識別情報に基づく位置情報をキャッ
シュ情報として受けて保持するキャッシュ手段と、該キ
ャッシュ手段に保持されている該キャッシュ情報に基づ
き該ゲートノードに代わって該移動端末宛のパケットの
該在圏エッジノードに対するルーティングを実施するル
ーティング手段とをそなえて構成されていることを特徴
とする、階層化パケット通信システムに使用されるエッ
ジノード。
【０４０３】（付記２８） 移動端末と通信してパケッ
トの送受を行ないうる複数のエッジノードと、該移動端
末の現在位置情報を管理し当該現在位置情報に基づいて
該移動端末宛のパケットを該移動端末がその現在位置か
ら通信可能なエッジノード（以下、在圏エッジノードと
いう）へルーティングしうるゲートノードとをそなえて
成る階層化パケット通信システムに使用される該移動端
末であって、少なくとも該在圏エッジノードを収容する
特定のゲートノードの識別情報（以下、ゲートノード識
別情報という）と該階層化パケット網の識別情報（以
下、網識別情報という）とを含む報知情報を、該在圏エ
ッジノードから受信する報知情報受信手段と、該報知情
報受信手段で受信された報知情報に含まれる該ゲートノ
ード識別情報が自己の移動に伴って変化しても該網識別
情報が変化していなければ、自己の現在位置情報の登録
先を、特定のゲートノードに維持する現在位置登録手段
とをそなえたことを特徴とする、階層化パケット通信シ
ステムに使用される移動端末。
【０４０４】（付記２９） 移動端末と複数のルーティ
ングノードとをそなえて成るパケット網において該移動
端末の移動に伴って当該移動端末へのパケット転送ルー
トを変更するハンドオーバ方法であって、特定のルーテ
ィングノード（以下、特定ノードという）において該移
動端末の移動に伴う複数の端末位置情報を管理してお
き、該特定ノードが、該移動端末宛の受信パケットの種
別（以下、パケット種別という）を識別し、識別したパ
ケット種別に応じて該複数の端末位置情報のいずれかを
選択し、選択した端末位置情報に基づいて該受信パケッ
トをルーティングすることを特徴とする、パケット網に
おけるハンドオーバ方法。
【０４０５】（付記３０） 該特定ノードが、該複数の
端末位置情報として、該移動端末の現在の位置情報と、
該移動端末の通信開始時の位置情報とを管理しておき、
識別した該パケット種別がパケットロスを許容する特性
をもつパケット種別であると、該端末位置情報として該
移動端末の現在の位置情報を選択する一方、識別した該
パケット種別がパケット転送遅延を許容する特性をもつ
パケット種別であると、該端末位置情報として該移動端
末の通信開始時の位置情報を選択することを特徴とす
る、付記２９記載のパケット網におけるハンドオーバ方
法。
【０４０６】（付記３１） 該特定ノードが、該通信開
始時の位置情報の有効期限に関する情報を記憶してお
き、該受信パケットを受信する毎に該有効期限に関する
情報をリフレッシュすることを特徴とする、付記３０記
載のパケット網におけるハンドオーバ方法。 （付記３２） 該特定ノードが、該有効期限が切れると
該通信開始時の位置情報を削除することを特徴とする、
付記３１記載のパケット網におけるハンドオーバ方法。
【０４０７】（付記３３） 該移動端末は、該特定ノー
ドでの該受信パケットのルーティングによりパケット転
送遅延を許容する特性をもつパケット種別のパケットを
受信している間、該通信開始時に接続していたルーティ
ングノードに対してスムースハンドオフ指示を発行する
ことを特徴とする、付記３０記載のパケット網における
ハンドオーバ方法。
【０４０８】（付記３４） 該特定ノードが、該通信開
始時の位置情報を、少なくとも送信元アドレスの異なる
複数の受信パケットのそれぞれについて管理することを
特徴とする、付記３０記載のパケット網におけるハンド
オーバ方法。 （付記３５） 該特定ノードが、該受信パケットのヘッ
ダに含まれるタイプ・オブ・サービスフィールドに設定
されている値に基づいて該パケット種別の判定を行なう
ことを特徴とする、付記２９記載のパケット網における
ハンドオーバ方法。
【０４０９】（付記３６） 該パケット網へ流入してく
る該移動端末宛のパケットを受信するルーティングノー
ドが、該パケットのパケット種別に応じた情報をパケッ
ト種別識別情報として該パケットに設定して該特定ノー
ドへのルーティングを実施し、該特定ノードが、該パケ
ットに設定されている該パケット種別識別情報に基づい
て該パケット種別の識別を行なうことを特徴とする、付
記２９記載のパケット網におけるハンドオーバ方法。
【０４１０】（付記３７） 該特定ノードが、該移動端
末のユーザについてのハンドオーバ条件情報を含む加入
者データを管理する加入者データ管理ノードから取得
し、該ハンドオーバ条件情報に基づいて該端末位置情報
の選択を制御することを特徴とする、付記２９記載のパ
ケット網におけるハンドオーバ方法。
【０４１１】（付記３８） 該特定ノードが、該パケッ
ト網をホーム網とする該移動端末の位置情報を管理する
ホームエージェントノードであることを特徴とする、付
記２９記載のパケット網におけるハンドオーバ方法。 （付記３９） 該特定ノードが、該パケット網を階層化
するためのゲートノードであることを特徴とする、付記
２９記載のパケット網におけるハンドオーバ方法。
【０４１２】（付記４０） 移動端末と通信してパケッ
トの送受を行ないうる複数のルーティングノードと、該
移動端末の現在位置情報を管理し当該現在位置情報に基
づいて該移動端末宛のパケットを該移動端末がその現在
位置から通信可能なルーティングノード（以下、在圏ノ
ードという）へルーティングしうるゲートノードとをそ
なえて成る階層化パケット網において、該ゲートノード
が、自己が管理する該移動端末の現在の位置情報をキャ
ッシュ情報として該移動端末宛のパケットを自己宛にル
ーティングしてくるルーティングノード（以下、通信中
ノードという）に通知し、当該通信中ノードは、該移動
端末宛の受信パケットの種別（以下、パケット種別とい
う）を識別し、該識別の結果、該受信パケットがパケッ
トロスを許容する特性をもつパケット種別であると、該
ゲートノードから通知されたキャッシュ情報に基づき該
ゲートノードに代わって該受信パケットを該在圏ノード
へルーティングすることを特徴とする、パケット網にお
けるハンドオーバ方法。
【０４１３】（付記４１）該通信中ノードが、上記のパ
ケット種別の識別の結果、該受信パケットがパケット転
送遅延を許容する特性をもつパケット種別であると、該
受信パケットを該ゲートノードへルーティングすること
を特徴とする、付記４０記載のパケット網におけるハン
ドオーバ方法。 （付記４２） 移動端末と複数のルーティングノードと
をそなえて成るパケット網を構成し該移動端末の移動に
伴って当該移動端末へのパケット転送ルートを変更しう
るルーティングノードであって、該移動端末の移動に伴
う複数の端末位置情報を管理する端末位置管理手段と、
該移動端末宛の受信パケットの種別（以下、パケット種
別という）を識別するパケット種別識別手段と、該パケ
ット種別識別手段で識別したパケット種別に応じて該端
末位置管理手段で管理されている該複数の端末位置情報
のいずれかを選択する選択手段と、該選択手段によって
選択された端末位置情報に基づいて該受信パケットをル
ーティングするルーティング手段とをそなえたことを特
徴とする、ルーティングノード。
【０４１４】（付記４３） 該端末位置管理手段が、該
複数の端末位置情報として、該移動端末の現在の位置情
報と、該移動端末の通信開始時の位置情報とを保持する
位置情報保持部をそなえるとともに、該パケット種別識
別手段が、該受信パケットの該パケット種別が少なくと
もパケットロスを許容する特性をもつパケット種別及び
パケット転送遅延を許容する特性をもつパケット種別の
いずれであるかを識別するパケットロス／転送遅延特性
識別部として構成され、且つ、該選択手段が、該パケッ
トロス／転送遅延特性識別部にて識別された該パケット
種別がパケットロスを許容する特性をもつパケット種別
であると、該端末位置情報として該移動端末の現在の位
置情報を該位置情報保持部において選択する一方、該パ
ケットロス／転送遅延特性識別部にて識別された該パケ
ット種別がパケット転送遅延を許容する特性をもつパケ
ット種別であると、該端末位置情報として該移動端末の
通信開始時の位置情報を該位置情報保持部において選択
する端末位置情報選択部として構成されていることを特
徴とする、付記４２記載のルーティングノード。
【０４１５】（付記４４） 該端末位置管理手段が、該
通信開始時の位置情報の有効期限に関する情報を記憶す
る有効期限情報記憶部と、該受信パケットを受信する毎
に該有効期限に関する情報をリフレッシュする有効期限
リフレッシュ部とをそなていることを特徴とする、付記
４３記載のルーティングノード。
【０４１６】（付記４５） 該端末位置管理手段が、該
有効期限が切れると該通信開始時の位置情報を削除する
位置情報削除部をさらにそなえていることを特徴とす
る、付記４４記載のルーティングノード。 （付記４６） 該端末位置管理手段の該位置情報保持部
が、該通信開始時の位置情報を、少なくとも送信元アド
レスの異なる複数の受信パケットのそれぞれについて保
持するように構成されていることを特徴とする、付記４
３記載のルーティングノード。
【０４１７】（付記４７） 移動端末と通信してパケッ
トの送受を行ないうる複数のルーティングノードと、該
移動端末の現在位置情報を管理し当該現在位置情報に基
づいて該移動端末宛のパケットを該移動端末がその現在
位置から通信可能なルーティングノード（以下、在圏ノ
ードという）へルーティングしうるゲートノードとをそ
なえて成る階層化パケット網に使用される該ルーティン
グノードであって、該ゲートノードにおいて管理されて
いる該移動端末の現在の位置情報をキャッシュ情報とし
て該ゲートノードから受けて保持するキャッシュ手段
と、該移動端末宛の受信パケットの種別（以下、パケッ
ト種別という）を識別するパケット種別識別手段と、該
パケット種別識別手段による識別の結果、該パケット種
別がパケットロスを許容する特性をもつパケット種別で
あると、該キャッシュ手段における該キャッシュ情報に
基づき該ゲートノードに代わって該受信パケットを該在
圏エッジノードへルーティングするルーティング手段と
をそなえたことを特徴とする、ルーティングノード。
【０４１８】（付記４８） 該ルーティング手段が、該
トラフィック識別手段による識別の結果、該パケット種
別がパケット転送遅延を許容する特性をもつパケット種
別であると、該受信パケットを該ゲートノードへルーテ
ィングするように構成されていることを特徴とする、付
記４７記載のルーティングノード。
【０４１９】
【発明の効果】以上詳述したように、本発明によれば、
次のような利点が得られる。 (1)エッジノードがゲートノードで管理されている移動
端末の現在位置情報（キャッシュ情報）を受けてその情
報に基づきそのゲートノードに代わって移動端末宛のパ
ケットのルーティングを行なうので、移動端末宛のパケ
ットを、ゲートノードを経由せずに、直接、在圏エッジ
ノードに転送できることになり、高速ハンドオーバとパ
ケット転送ルートに制限の無いルート最適化とが可能に
なる。特に、この場合は、特定のゲートノードにパケッ
トが集中するようなこともないので、ゲートノードの処
理負荷をエッジノードに分散させてその負荷を軽減する
ことが可能である。
【０４２０】(2)移動端末は、在圏エッジノードからの
報知情報に含まれるゲートノード識別情報が自己の移動
に伴って変化しても網識別情報が変化していなければ、
自身が同じ階層化パケット網内に位置していると認識し
て、自己の現在位置情報の通知先を、特定のゲートノー
ドに維持することができるので、従来のように移動に伴
って位置登録先のゲートノードの切り替えが頻繁に発生
することも防止でき、高速ハンドオーバ性をさらに向上
することができる。
【０４２１】(3)移動端末による位置登録先のゲートノ
ードが移動端末の移動に関わらず上述のごとく同じゲー
トノードに維持される場合であっても、移動端末のゲー
トノードに対する現在位置の更新登録に応じて必要なキ
ャッシュ情報が通信中エッジノードに逐次提供されて相
互の同期がとられるので、通信中エッジノードは、パケ
ット転送ルートを、ゲートノードを経由しない新たな在
圏エッジノードに到るルートに適切且つ迅速に変更する
ことが可能である。従って、ゲートノードの処理負荷を
さらに抑制しながら高速ハンドオーバを実現することが
できる。
【０４２２】(4)なお、移動端末宛のパケットを受信し
たエッジノードは、上記のキャッシュ情報が無ければゲ
ートノードへ必要なキャッシュ情報を要求することがで
きるので、どのエッジノードも、ゲートノードによるパ
ケットルーティングを代替することができ、特定のエッ
ジノードに負荷が集中することは無い。つまり、この場
合、エッジノードとゲートノードとの双方の負荷を軽減
できることになる。
【０４２３】(5)このとき、ゲートノードは、上記のキ
ャッシュ情報の要求を受けた場合に、要求元のエッジノ
ードにキャッシュ情報を提供するので、不要なキャッシ
ュ情報の転送を防止することができ、網内のトラフィッ
ク量の増大を抑制することができる。 (6)また、上記のゲートノードは、上記の通信中エッジ
ノードの識別情報を保持しておくようにしてもよく、こ
のようにすれば、上記キャッシュ情報を更新すべきノー
ドを把握しておくことができるので、移動端末の現在位
置情報の通知を受けた場合の該当通信中エッジノードの
キャッシュ情報の更新を誤ることなく実施することが可
能である。従って、パケットルーティングの信頼性、つ
まり、通信品質を向上することができる。
【０４２４】(7)さらに、ゲートノードにおいて、上記
の通信中エッジノードの識別情報を複数分保持できるよ
うにしておくことで、１台の移動端末に対して複数の通
信中エッジノードにゲートノードによるルーティングを
代替させるよう設定することができるので、ゲートノー
ドの処理負荷を大幅に削減することができる。 (8)また、上記の通信中エッジノードは、上記の移動端
末宛のパケットを受信する毎に、上記のキャッシュ情報
の有効期限をリフレッシュすることもでき、これによ
り、通信中にキャッシュ情報の有効期限が切れて正常な
通信を維持できなくなることを回避することができる。
従って、さらに、パケットルーティングの信頼性、つま
り、通信品質を向上することができる。
【０４２５】(9)さらに、上記の通信中エッジノード
は、通信が終了して上記のキャッシュ情報の有効期限が
終了すると、そのキャッシュ情報を受けたゲートノード
に対し自己（通信中エッジノード）の識別情報の削除を
要求し、この要求を受けたゲートノードは、保持してい
る該当ノード識別 情報を削除することができる。これ
により、エッジノード及びゲートノードにおいて不要な
情報をいつまでも保持しておくことがなく、必要なメモ
リ容量などを削減して、その小型化を図ることができ
る。
【０４２６】(10)なお、移動端末は、同じ網内の移動で
は原則として位置登録先（使用）ゲートノードを変更し
ないが、一定の（付加的）条件を満足すると、位置登録
先のゲートノードを変更するようにしてもよい。これに
より、例えば、移動端末の移動に伴ってゲートノードと
の距離が長距離になってしまった場合などにおいて、位
置登録先のゲートノードを最寄りのゲートノードに変更
できるので、ハンドオーバの高速性を向上できる。
【０４２７】(11)例えば、移動端末は、一定周期経過毎
に上記の報知情報に含まれるゲートノード識別情報が変
化しているか否かを監視し、その一定周期経過時に該ゲ
ートノード識別情報が変化していれば、上記のゲートノ
ードの変更を実施する。このようにすれば、移動端末の
移動に伴って最寄りのゲートノードが変化する毎に位置
登録を行なう場合よりもその位置登録頻度を削減しなが
ら、位置登録先のゲートノードの最適化、つまり、ハン
ドオーバ時間の最適化を図ることができる。
【０４２８】(12)また、移動端末は、上記の付加的条件
として自己の非通信中にゲートノード識別情報が変化し
た場合に上記のゲートノードの変更を実施することもで
き、この場合、ゲートノードの切り替えは、必ず移動端
末の非通信中であるときに実施されるので、通信中の位
置登録先ゲートノード変更による通信品質の劣化は生じ
ない。従って、ハンドオーバによる通信品質の劣化を防
止しながら、ハンドオーバ時間の最適化を図ることがで
きる。
【０４２９】(13)さらに、移動端末は、自己の通信トラ
フィック量を監視し、上記の付加的条件として通信トラ
フィック量が所定値以下であるときに上記の報知情報に
含まれるゲートノード識別情報が変化している場合に、
上記のゲートノードの変更を実施することもできる。こ
の場合、ゲートノードの変更は必ず通信トラフィック量
が所定値以下であるときに実施されるので、通信への影
響（通信帯域の圧迫等）を最小限に抑制しながら、ハン
ドオーバ時間の最適化を図ることができる。
【０４３０】(14)また、移動端末は、上記の付加的条件
として通信中のデータトラフィックタイプが特定のデー
タトラフィックタイプであるときにゲートノード識別情
報が変化している場合に、上記のゲートノードの変更を
実施することもできる。例えば、データトラフィックタ
イプによっては多少の通信品質劣化が許容されるものが
あるので、端末がそのタイプの通信を行なっている場合
には、ゲートノードの切り替えを行なっても許容範囲内
での通信品質劣化で済み、ハンドオーバ時間は最適化す
ることができる。
【０４３１】(15)さらに、移動端末は、通信に使用する
アプリケーションの使用状態を監視し、上記の付加的条
件としてそのアプリケーションが未使用であるときにゲ
ートノード識別情報が変化している場合に、上記のゲー
トノードの変更を実施することもできる。この場合、ゲ
ートノードの変更は、必ず端末のアプリケーションが未
使用であるとき、つまり、端末自体の処理能力に余裕が
あるときに実施されるので、やはり、通信中の通信品質
劣化を最小限に抑制しながら、ハンドオーバ時間の最適
化を図ることができる。
【０４３２】(16)また、特定ノードにおいて、移動端末
の移動に伴う複数の位置情報を管理しておき、移動端末
宛の受信パケットの種別（パケット種別）に応じてこれ
らの位置情報のいずれかを選択して、その選択位置情報
に基づいて受信パケットをルーティングすることによ
り、受信パケットの種別に応じてハンドオーバ方法を変
更することができるので、複数種類の通信サービスに応
じた最適な通信品質を柔軟に提供でき、移動端末に対す
る通信サービス品質を大幅に向上させることができる。
【０４３３】（17）ここで、例えば、上記の特定ノード
では、受信パケットがパケットロスを許容するパケット
（例えば、音声パケット）であれば、移動端末の現在の
位置情報を選択することにより、パケット転送遅延を最
小限に抑制したハンドオーバを実施することができ、受
信パケットがパケットロスを許容するパケット（例え
ば、データパケット）であれば、移動端末の通信開始時
の位置情報を選択することにより、パケットロスを最小
限に抑制したハンドオーバを実施することができるの
で、移動端末のユーザが利用する音声通話サービス，デ
ータ通信サービス等に応じた最適なハンドオーバ方法を
提供することができる。
【０４３４】（18）なお、上記の特定ノードでは、上記
の通信開始時の位置情報の有効期限に関する情報を記憶
しておき、移動端末宛の受信パケットを受信する毎にそ
の有効期限に関する情報をリフレッシュすることもで
き、このようにすれば、パケットロスを許容する通信継
続中に通信開始時の位置情報が無効になることを防止す
ることができるので、当該通信の信頼性を向上すること
ができる。
【０４３５】（19）また、上記特定ノードでは、上記の
有効期限が切れると上記の通信開始時の位置情報を削除
することもでき、このようにすれば、通信開始時の位置
情報の記憶に必要な記憶容量を最小限に抑制して、特定
ノードの小型化を図ることができる。 （20）さらに、上記の移動端末は、パケット転送遅延を
許容するパケット（例えば、データパケット）を受信し
ている間、通信開始時に接続していたルーティングノー
ド（これを、アンカーポイントという）に対してスムー
スハンドオフ指示を発行するのが好ましく、このように
すれば、スムースハンドオフ指示を受けたルーティング
ノードから移動端末が現在接続しているルーティングノ
ードまで通信パス（パケット転送ルート）を伸ばしてお
くことができるので、ハンドオーバに伴うパケットロス
を最小限に抑制することができる。
【０４３６】（21）また、上記の特定ノードでは、上記
の通信開始時の位置情報を、少なくとも送信元アドレス
の異なる複数の受信パケットのそれぞれについて管理す
るようにしてもよく、このようにすれば、受信パケット
の送信元アドレス（つまり、パケットの発信者）毎に、
最適なアンカーポイントを設定することができるので、
さらに、移動端末に対する通信サービス品質をより一層
向上することができる。
【０４３７】（22）なお、上記の特定ノードでのパケッ
ト種別の識別は、受信パケットのヘッダに含まれるタイ
プ・オブ・サービスフィールド（tos）に設定されてい
る値に基づいて行なうようにしてもよく、このようにす
れば、極めて簡便にパケット種別の識別を実現すること
ができ、ひいては、特定ノードの小型化を図ることも可
能となる。
【０４３８】（23）ここで、パケット網へ流入してくる
移動端末宛のパケットを受信するルーティングノードに
おいて、そのパケットの種別に応じた情報をパケット種
別識別情報としてそのパケットに設定するようにすれ
ば、上記特定ノードでは、受信パケットに設定されてい
る上記パケット種別識別情報に基づいて上記のパケット
種別の識別を実施することができるので、移動端末側に
おいてパケット種別識別のための情報を送信パケットに
独自に設定する必要が無い。
【０４３９】（24）また、上記の特定ノードは、移動端
末のユーザについてのハンドオーバ条件情報を含む加入
者データを管理する加入者データを加入者データ管理ノ
ードから取得し、取得したハンドオーバ条件情報に基づ
いて上記の端末位置情報の選択を制御することもできる
ので、移動端末のユーザ毎にハンドオーバ条件を設定す
ることが可能になり、よりきめ細かいハンドオーバ方法
の変更が可能になる。
【０４４０】（25）なお、上記の特定ノードは、上記の
パケット網をホーム網とする移動端末の位置情報を管理
するホームエージェントノードであってもよいし、上記
のパケット網を階層化するためのゲートノード（階層化
ノード）であってもよく、いずれの場合であっても、パ
ケット種別（通信サービス）に応じた最適なハンドオー
バ方法の切り替えを実現することができる。
【０４４１】（26）また、エッジノード（通信中ノー
ド）がゲートノードからキャッシュ情報を受けることに
より当該ゲートノードに代わって移動端末宛の受信パケ
ットの在圏ノードへのルーティングを行なう階層化パケ
ット網においても、前記通信中ノードにおいて、受信パ
ケットがパケットロスを許容するパケット（例えば、音
声パケット）である場合に、上記キャッシュ情報に基づ
きゲートノードに代わってその受信パケットを在圏ノー
ドへルーティングするようにすれば、音声パケット等に
ついてのハンドオーバ時にはルート最適化が行なわれる
ことになるので、パケット転送遅延がさらに削減され
て、ハンドオーバ時の通信品質を高品質に維持すること
ができる。
【０４４２】（27）なお、上記の通信中ノードは、受信
パケットがパケット転送遅延を許容するパケット（例え
ば、データパケット）については、ゲートノードへルー
ティングすることにより、アンカーポイントでのスムー
スハンドオフによるハンドオーバを実現することがで
き、ハンドオーバ時のパケットロスを最小限に抑制する
ことができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態としての階層化パケット
通信システムの構成を示すブロック図である。
【図２】図１に示すＶＨＡ／ＴＨＡ／ＥＮの構成を示す
ブロック図である。
【図３】図２に示すモバイルメッセージ処理部の詳細構
成を示すブロック図である。
【図４】（Ａ）は図１に示すＶＨＡ／ＴＨＡにおける結
合キャッシュテーブルの情報内容例、（Ｂ）は図１に示
すＥＮにおける結合キャッシュテーブルの情報内容例を
示す図である。
【図５】図１に示す移動端末（ＭＮ）の構成を示すブロ
ック図である。
【図６】図５に示すＭＮのモバイルメッセージ処理部の
詳細構成を示すブロック図である。
【図７】「HMIPv6」準拠のパケットフォーマットを示す
図である。
【図８】図７に示す標準ヘッダのフォーマットを示す図
である。
【図９】第１実施形態に係るホーム位置登録メッセージ
のパケットフォーマットを示す図である。
【図１０】第１実施形態に係るホーム位置登録応答メッ
セージのパケットフォーマットを示す図である。
【図１１】第１実施形態に係る在圏位置登録メッセージ
のパケットフォーマットを示す図である。
【図１２】第１実施形態に係る位置（キャッシュ）更新
メッセージのパケットフォーマットを示す図である。
【図１３】第１実施形態に係る位置（キャッシュ）更新
応答メッセージのパケットフォーマットを示す図であ
る。
【図１４】第１実施形態に係るキャッシュ要求メッセー
ジのパケットフォーマットを示す図である。
【図１５】第１実施形態に係るキャッシュ通知メッセー
ジのパケットフォーアットを示す図である。
【図１６】第１実施形態に係るキャッシュ削除要求メッ
セージのパケットフォーマットを示す図である。
【図１７】第１実施形態に係るルータ広告メッセージの
パケットフォーマットを示す図である。
【図１８】図１に示す階層化パケット通信システムの動
作（位置登録処理）を説明するための図である。
【図１９】図１に示す階層化パケット通信システムの動
作（ホーム端末−ローミング端末間通信）を説明するた
めの図である。
【図２０】図１９に示す階層化パケット通信システムに
おけるルート最適化後のパケット転送経路を説明するた
めの図である。
【図２１】図１９に示すローミング端末がさらに移動し
たときの動作を説明するための図である。
【図２２】図１に示すＥＮの動作を説明するためのフロ
ーチャートである。
【図２３】図１に示すＶＨＡ／ＴＨＡの動作を説明する
ためのフローチャートである。
【図２４】図２に示すＶＨＡ／ＴＨＡにおける制御メッ
セージ処理部の動作を説明するためのフローチャートで
ある。
【図２５】図１に示すＥＮの動作を説明するためのフロ
ーチャートである。
【図２６】図１に示すＥＮの動作を説明するためのフロ
ーチャートである。
【図２７】図５及び図６に示すモバイルメッセージ処理
部の動作を説明するためのフローチャートである。
【図２８】図２に示すＶＨＡ／ＴＨＡ／ＥＮにおけるタ
イマ処理部の動作を説明するためのフローチャートであ
る。
【図２９】図２に示すＶＨＡ／ＴＨＡ／ＥＮにおけるル
ータ処理部の動作を説明するための図である。
【図３０】第１実施形態の変形例（位置登録先ＴＨＡ切
り替え動作）を説明するための図である。
【図３１】第１実施形態の第１変形例に係る位置登録先
ＴＨＡ切り替え動作を説明するためのタイムチャートで
ある。
【図３２】図３１に示すＴＨＡ切り替え動作を実現する
図６に示すルータ広告メッセージ処理部の動作アルゴリ
ズム（ＴＨＡアドレスチェックアルゴリズム）を示す図
である。
【図３３】図３１に示すＴＨＡ切り替え動作を実現する
図６に示すルータ広告メッセージ処理部の動作アルゴリ
ズム（フラグ設定アルゴリズム）を示す図である。
【図３４】第１実施形態の第２変形例に係る位置登録先
ＴＨＡ切り替え動作を説明するためのタイムチャートで
ある。
【図３５】第１実施形態の第２変形例に係るフラグ設定
アルゴリズムを示す図である。
【図３６】第１実施形態の第３変形例に係る位置登録先
ＴＨＡ切り替え動作を説明するためのタイムチャートで
ある。
【図３７】第１実施形態の第３変形例に係るフラグ設定
アルゴリズムを示す図である。
【図３８】第１実施形態の第４変形例に係る位置登録先
ＴＨＡ切り替え動作を説明するためのタイムチャートで
ある。
【図３９】第１実施形態の第４変形例に係るフラグ設定
アルゴリズムを示す図である。
【図４０】第１実施形態の第５変形例に係る位置登録先
ＴＨＡ切り替え動作を説明するためのタイムチャートで
ある。
【図４１】第１実施形態の第５変形例に係るフラグ設定
アルゴリズムを示す図である。
【図４２】本発明の第２実施形態に係るパケット網の構
成を示すブロック図である。
【図４３】図４２に示すＨＡ及びルータの構成を示すブ
ロック図である。
【図４４】（Ａ）は図４２に示すパケット網におけるＭ
Ｎアドレス例を説明するための図、（Ｂ）は（Ａ）に示
すＭＮアドレスを基にした図４３に示すバインディング
キャッシュテーブルの登録内容例を示す図である。
【図４５】第２実施形態に係る音声（ＶＯＩＰ）パケッ
トのフォーマット例を示す図である。
【図４６】第２実施形態に係るｆｔｐデータパケットの
フォーマット例を示す図である。
【図４７】図４２に示すパケット網におけるハンドオー
バ方法（音声パケットの場合）を説明するための図であ
る。
【図４８】図４２に示すパケット網におけるハンドオー
バ方法（データパケットの場合）を説明するための図で
ある。
【図４９】（Ａ）は図４７に示すハンドオーバ方法（音
声パケットの場合）によるパケット転送ルートを説明す
るための図、（Ｂ）は図４８に示すハンドオーバ方法
（データパケットの場合）によるパケット転送ルートを
説明するための図である。
【図５０】図４２及び図４３に示すＨＡの動作を説明す
るためのフローチャートである。
【図５１】図４２及び図４３に示すＨＡの動作を説明す
るためのフローチャートである。
【図５２】（Ａ）及び（Ｂ）は第２実施形態の第１変形
例に係るバインディングキャッシュテーブルの構成及び
その登録内容例を説明するための図である。
【図５３】（Ａ）及び（Ｂ）はいずれも第２実施形態の
第１変形例に係るハンドオーバ方法によるパケット転送
ルートを説明するための図で、（Ａ）は音声パケットに
ついてのパケット転送ルート、（Ｂ）はデータパケット
についてのパケット転送ルートをそれぞれ説明するため
の図である。
【図５４】第２実施形態の第１変形例に係るＨＡの動作
を説明するためのフローチャートである。
【図５５】第２実施形態の第１変形例に係るＨＡの動作
を説明するためのフローチャートである。
【図５６】第２実施形態の第２変形例に係るバインディ
ングキャッシュテーブルの登録内容例を説明するための
図である。
【図５７】第２実施形態の第２変形例に係るエッジノー
ドの動作を説明するためのフローチャートである。
【図５８】（Ａ）及び（Ｂ）はいずれも第２実施形態の
第２変形例に係るハンドオーバ方法によるパケット転送
ルートを説明するための図で、（Ａ）は音声パケットに
ついてのパケット転送ルート、（Ｂ）はデータパケット
についてのパケット転送ルートをそれぞれ説明するため
の図である。
【図５９】（Ａ）及び（Ｂ）は第２実施形態の第３変形
例に係るバインディングキャッシュテーブルの構成及び
その登録内容例を説明するための図である。
【図６０】第２実施形態の第３変形例に係るバインディ
ングキャッシュテーブルの他の登録内容例を示す図であ
る。
【図６１】第２実施形態の第４変形例に係るハンドオー
バ方法（ＨＡによるハンドオーバ）を説明すべく階層化
Mobile-IP網の一例を示すブロック図である。
【図６２】第２実施形態の第４変形例に係るハンドオー
バ方法（ＭＡによるハンドオーバ）を説明すべく階層化
Mobile-IP網の一例を示すブロック図である。
【図６３】「MIPv6」に準拠したパケット通信システム
の一例を示す図である。
【図６４】図６３に示すシステムにおける「ルート最適
化」を説明する図である。
【図６５】階層化Mobile-IPv6（HMIPv6）に準拠したパ
ケット通信システムの一例を示す図である。
【図６６】図６５に示すシステムにおける「ルート最適
化」を説明する図である。
【図６７】図６５に示すシステムにおける「ルート最適
化」前のパケット転送ルートの一例を示す図である。
【図６８】図６５に示すシステムにおける「ルート最適
化」後のパケット転送ルートの一例を示す図である。
【図６９】従来のスムースハンドオフを説明するための
図である。
【符号の説明】
１，１′，２ パケット網（キャリア網） １ａ，１ｂ，２ａ，２ｂ サブキャリア（サブパケッ
ト）網 ３ 移動端末（ＭＮ） １０，２０ ＶＨＡノード １０′ ホームエージェント（ＨＡ）ノード（ルーティ
ングノード） １１ａ，１１ｂ，２１ａ，２１ｂ ＴＨＡノード １２ エッジノード（ＥＮ） １３′ ルータ（ルーティングノード） １３′−１，１３′−２，１００′ 通信エリア（在圏
ゾーン） ３１ 入力処理部 ３２ ＩＰレイヤ処理部 ３３ パケット種別判定部 ３４ モバイルメッセージ処理部（現在位置登録手段） ３４Ａ メッセージ受信部（報知情報受信手段） ３４Ｂ メッセージ種別判断部 ３４Ｃ ルータ広告メッセージ処理部 ３４Ｄ モバイルＩＰメッセージ処理部 ３４Ｅ メッセージ送信部 ３５ ルーティングメッセージ処理部 ３６ アプリケーション ３７ ルーティングテーブル ３８ 出力方路決定部 ３９ 出力処理部 ４１ 入力処理部 ４２，４２Ａ パケット種別識別部 ４３，４３Ａ バインディングキャッシュ検索部 ４４ 結合（バインディング）キャッシュテーブル（端
末位置管理手段，キャッシュ手段，ノード識別情報保持
手段） ４４Ａ 結合（バインディング）キャッシュテーブル
（端末位置管理手段） ４４Ａ−１ 位置情報保持部 ４４Ａ−２ 有効期限情報記憶部 ４４Ｂ ハンドオーバ条件データ ４５ カプセル化処理部 ４６ ルータ処理部（ルーティング手段） ４６ａ ルーティングテーブル ４６ｂ 出方路決定部 ４８ 出力処理部 ４９，４９Ａ タイマ処理部 ５０ 制御メッセージ処理部 ５１，５１Ａ メッセージ種別判定部 ５２，５２Ａ モバイルメッセージ処理部 ５２Ｃ 結合更新（Binding Update）メッセージ処理部 ５２Ｄ 結合応答（Binding Acknowledge）メッセージ
処理部 ５２Ｅ 結合要求（Binding Request-M3）メッセージ処
理部 ５３ ルーティングメッセージ処理部 ５４ ルータ広告メッセージ処理部 ６１ａ キャッシュデータ ６１ｂ 「通信中ＥＮアドレス」データ（拡張データ） ６２ｂ 「ＶＨＡ／ＴＨＡアドレス」データ（拡張デー
タ） ６１ｃ アンカーＣＯＡデータ ７０ ＩＰヘッダ ７１ 標準ヘッダ ７２ オプションヘッダ ７３ 認証ヘッダ ７４ ＴＣＰ（Transmission Control Protocol）ヘッ
ダ ７６ ＵＤＰ（User Datagram Protocol）ヘッダ ７７ ＲＴＰ（Real-time Transport Protocol）ヘッダ ８０ ＩＰペイロード ３４１ 情報格納レジスタ ３４２ ルータ広告解析部〔ゲートノード識別情報監視
手段（条件付監視手段），網識別情報監視手段〕 ３４３ 位置登録（Registration）メッセージ作成部
〔現在位置通知手段（条件付通知手段）〕 ３４４ 結合更新（Binding Update）メッセージ作成部 ４３１ トラフィック種別識別部 ４３２ コピー登録部 ４３３ ＣＯＡ選択部（選択手段，端末位置情報選択
部） ４４１ キャッシュテーブル（Biding Cache1） ４４２ キャッシュテーブル（Biding Cache2） ４９１ 有効期限リフレッシュ部 ４９２ ＣＯＡ削除部 ５２１ 結合キャッシュ（Binding Cache）テーブルア
クセス部（ノード識別情報削除手段） ５２２ 結合更新（Binding Update）メッセージ解析部 ５２３ 結合応答（Binding Acknowledge）メッセージ
作成部 ５２４ 結合更新（Binding Update）メッセージ作成部
（キャッシュ情報通知手段，キャッシュ情報更新手段） ５２７ 結合更新（Binding Update）メッセージ作成部
（ノード識別情報削除要求手段） ５２５ 結合キャッシュ（Binding Cache）テーブルア
クセス部 ５２６ 結合要求（Binding Request-M3）メッセージ解
析部 ５２８ 結合要求（Binding Request-M3）メッセージ作
成部（キャッシュ情報要求手段） ７１１ 「バージョン情報」フィールド ７１２ 「トラフィッククラス」フィールド ７１３ 「フローラベル」フィールド ７１４ 「ペイロード長」フィールド ７１５ 「ネクストヘッダ」フィールド ７１６ 「ホップ制限数」フィールド ７１７ 「送信元アドレス（ＳＡ：Source Address）」
フィールド ７１８ 「宛先アドレス（ＤＡ：Destination Addres
s）」フィールド ７２３，７２３ａ オプションタイプ（Option Type）
フィールド ７２４ ホームアドレスフィールド ７２５ ＭＡアドレスフィールド ７２６ Ｍ３ネットワークアドレスフィールド ７２７ Ａ（Acknowledgement）ビットフィールド ７２８ リザーブ（reserved）ビットフィールド ７２９ ライフタイム（Lifetime）フィールド ７６１ 発信元ポート番号フィールド ７６２ 宛先ポート番号フィールド ７７１ ペイロードタイプフィールド
───────────────────────────────────────────────────── フロントページの続き (72)発明者 加藤 次雄 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 岡 和之 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 武智 竜一 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 玉井 明子 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5K030 GA11 HA08 HC01 HC09 HD03 HD05 JL01 JL07 JT01 JT03 JT09 KA01 KA05 KA13 LB05 (54)【発明の名称】 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システ ムに使用されるゲートノード，エッジノード及び移動端末並びにパケット網におけるハンドオー バ方法及びルーティングノード

Claims (10)

    【特許請求の範囲】
  1. 【請求項１】 移動端末と通信してパケットの送受を行
    ないうる複数のエッジノードと、該移動端末の現在位置
    情報を管理し当該現在位置情報に基づいて該移動端末宛
    のパケットを該移動端末がその現在位置から通信可能な
    エッジノード（以下、在圏エッジノードという）へルー
    ティングしうるゲートノードとをそなえて成る階層化パ
    ケット網において、 該ゲートノードが、自己が管理する該移動端末の現在位
    置情報をキャッシュ情報として該移動端末宛のパケット
    を自己宛にルーティングしてくるエッジノード（以下、
    通信中エッジノードという）に通知し、 当該通信中エッジノードが、該キャッシュ情報に基づき
    該ゲートノードに代わって該移動端末宛のパケットの該
    在圏エッジノードに対するルーティングを実施すること
    を特徴とする、階層化パケット網におけるパケット転送
    方法。
  2. 【請求項２】 該エッジノードが、それぞれ、少なくと
    も自己を収容するゲートノードの識別情報（以下、ゲー
    トノード識別情報という）と該階層化パケット網の識別
    情報（以下、網識別情報という）とを含む報知情報を該
    移動端末に送信し、 該移動端末は、該報知情報に含まれる該ゲートノード識
    別情報が自己の移動に伴って変化しても該網識別情報が
    変化していなければ、自己の現在位置情報の登録先を、
    該ゲートノードに維持することを特徴とする、請求項１
    記載の階層化パケット網におけるパケット転送方法。
  3. 【請求項３】 移動端末と通信してパケットの送受を行
    ないうる複数のエッジノードと、該移動端末の現在位置
    情報を管理し当該現在位置情報に基づいて該移動端末宛
    のパケットを該移動端末がその現在位置から通信可能な
    エッジノード（以下、在圏エッジノードという）へルー
    ティングしうるゲートノードとをそなえて成る階層化パ
    ケット通信システムにおいて、 該移動端末が、 該在圏エッジノードの識別情報に基づく位置情報を該現
    在位置情報として特定のゲートノードに通知して登録す
    る現在位置登録手段をそなえるとともに、 該ゲートノードが、 該移動端末の該現在位置登録手段によって通知される該
    現在位置情報を管理する端末位置管理手段と、 該端末位置管理手段で管理されている該現在位置情報を
    キャッシュ情報として該移動端末宛のパケットを自己宛
    にルーティングしてくるエッジノード（以下、通信中エ
    ッジノードという）に通知するキャッシュ情報通知手段
    とをそなえ、且つ、 該エッジノードが、 該ゲートノードの該キャッシュ情報通知手段により通知
    されたキャッシュ情報を保持するキャッシュ手段と、 該キャッシュ手段に保持されている該キャッシュ情報に
    基づき該ゲートノードに代わって該移動端末宛のパケッ
    トの該在圏エッジノードに対するルーティングを実施す
    るルーティング手段とをそなえて構成されていることを
    特徴とする、階層化パケット通信システム。
  4. 【請求項４】 移動端末と通信してパケットの送受を行
    ないうる複数のエッジノードと、該移動端末の現在位置
    情報を管理し当該現在位置情報に基づいて該移動端末宛
    のパケットを該移動端末がその現在位置から通信可能な
    エッジノード（以下、在圏エッジノードという）へルー
    ティングしうるゲートノードとをそなえて成る階層化パ
    ケット通信システムに使用される該ゲートノードであっ
    て、 該移動端末から当該移動端末の現在位置情報として通知
    されてくる、該在圏エッジノードの識別情報に基づく位
    置情報を管理する端末位置管理手段と、 該端末位置管理手段で管理されている該現在位置情報を
    キャッシュ情報として該移動端末宛のパケットをルーテ
    ィングしてくるエッジノードに通知するキャッシュ情報
    通知手段とをそなえたことを特徴とする、階層化パケッ
    ト通信システムに使用されるゲートノード。
  5. 【請求項５】 移動端末と通信してパケットの送受を行
    ないうる複数のエッジノードと、該移動端末の現在位置
    情報を管理し当該現在位置情報に基づいて該移動端末宛
    のパケットを該移動端末がその現在位置から通信可能な
    エッジノード（以下、在圏エッジノードという）へルー
    ティングしうるゲートノードとをそなえて成る階層化パ
    ケット通信システムに使用される該エッジノードであっ
    て、 該ゲートノードで管理されている、該在圏エッジノード
    の識別情報に基づく位置情報をキャッシュ情報として受
    けて保持するキャッシュ手段と、 該キャッシュ手段に保持されている該キャッシュ情報に
    基づき該ゲートノードに代わって該移動端末宛のパケッ
    トの該在圏エッジノードに対するルーティングを実施す
    るルーティング手段とをそなえて構成されていることを
    特徴とする、階層化パケット通信システムに使用される
    エッジノード。
  6. 【請求項６】 移動端末と通信してパケットの送受を行
    ないうる複数のエッジノードと、該移動端末の現在位置
    情報を管理し当該現在位置情報に基づいて該移動端末宛
    のパケットを該移動端末がその現在位置から通信可能な
    エッジノード（以下、在圏エッジノードという）へルー
    ティングしうるゲートノードとをそなえて成る階層化パ
    ケット通信システムに使用される該移動端末であって、 少なくとも該在圏エッジノードを収容するゲートノード
    の識別情報（以下、ゲートノード識別情報という）と該
    階層化パケット網の識別情報（以下、網識別情報とい
    う）とを含む報知情報を、該在圏エッジノードから受信
    する報知情報受信手段と、 該報知情報受信手段で受信された報知情報に含まれる該
    ゲートノード識別情報が自己の移動に伴って変化しても
    該網識別情報が変化していなければ、自己の現在位置情
    報の登録先を、該ゲートノードに維持する現在位置登録
    手段とをそなえたことを特徴とする、階層化パケット通
    信システムに使用される移動端末。
  7. 【請求項７】 移動端末と複数のルーティングノードと
    をそなえて成るパケット網において該移動端末の移動に
    伴って当該移動端末へのパケット転送ルートを変更する
    ハンドオーバ方法であって、 特定のルーティングノード（以下、特定ノードという）
    において該移動端末の移動に伴う複数の端末位置情報を
    管理しておき、 該特定ノードが、 該移動端末宛の受信パケットの種別（以下、パケット種
    別という）を識別し、 識別したパケット種別に応じて該複数の端末位置情報の
    いずれかを選択し、 選択した端末位置情報に基づいて該受信パケットをルー
    ティングすることを特徴とする、パケット網におけるハ
    ンドオーバ方法。
  8. 【請求項８】 該特定ノードが、 該複数の端末位置情報として、該移動端末の現在の位置
    情報と、該移動端末の通信開始時の位置情報とを管理し
    ておき、 識別した該パケット種別がパケットロスを許容する特性
    をもつパケット種別であると、該端末位置情報として該
    移動端末の現在の位置情報を選択する一方、識別した該
    パケット種別がパケット転送遅延を許容する特性をもつ
    パケット種別であると、該端末位置情報として該移動端
    末の通信開始時の位置情報を選択することを特徴とす
    る、請求項７記載のパケット網におけるハンドオーバ方
    法。
  9. 【請求項９】 移動端末と通信してパケットの送受を行
    ないうる複数のルーティングノードと、該移動端末の現
    在位置情報を管理し当該現在位置情報に基づいて該移動
    端末宛のパケットを該移動端末がその現在位置から通信
    可能なルーティングノード（以下、在圏ノードという）
    へルーティングしうるゲートノードとをそなえて成る階
    層化パケット網において、 該ゲートノードが、自己が管理する該移動端末の現在の
    位置情報をキャッシュ情報として該移動端末宛のパケッ
    トを自己宛にルーティングしてくるルーティングノード
    （以下、通信中ノードという）に通知し、 当該通信中ノードは、 該移動端末の通信開始時の位置情報を管理しておき、 該移動端末宛の受信パケットの種別（以下、パケット種
    別という）を識別し、 該識別の結果、該受信パケットがパケットロスを許容す
    る特性をもつパケット種別であると、該ゲートノードか
    ら通知されたキャッシュ情報に基づき該ゲートノードに
    代わって該受信パケットを該在圏ノードへルーティング
    し、 該識別の結果、該受信パケットがパケット転送遅延を許
    容する特性をもつパケット種別であると、該通信開始時
    の位置情報に基づいて該受信パケットを該ゲートノード
    へルーティングすることを特徴とする、パケット網にお
    けるハンドオーバ方法。
  10. 【請求項１０】 移動端末と複数のルーティングノード
    とをそなえて成るパケット網を構成し該移動端末の移動
    に伴って当該移動端末へのパケット転送ルートを変更し
    うるルーティングノードであって、 該移動端末の移動に伴う複数の端末位置情報を管理する
    端末位置管理手段と、 該移動端末宛の受信パケットの種別（以下、パケット種
    別という）を識別するパケット種別識別手段と、 該パケット種別識別手段で識別したパケット種別に応じ
    て該端末位置管理手段で管理されている該複数の端末位
    置情報のいずれかを選択する選択手段と、 該選択手段によって選択された端末位置情報に基づいて
    該受信パケットをルーティングするルーティング手段と
    をそなえたことを特徴とする、ルーティングノード。
JP2001174698A 2001-04-27 2001-06-08 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 Expired - Fee Related JP4340400B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2001174698A JP4340400B2 (ja) 2001-04-27 2001-06-08 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法
EP20060013365 EP1718024A1 (en) 2001-04-27 2001-09-28 Handover method and routing node for a packet network
EP20010122678 EP1263182B1 (en) 2001-04-27 2001-09-28 Packet routing in a hierarchical packet communication system
US09/967,447 US20030026241A1 (en) 2001-04-27 2001-09-28 Packet transfer method for hierarchical packet network, hierarchical packet communication system, and gate node, edge node and mobile terminal for use with hierarchical packet communication system, as well as handover method and routing node for packet network
DE60137025T DE60137025D1 (de) 2001-04-27 2001-09-28 Paket-Leitweglenkung in einem hierarchischen Paketübertragungssystem

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2001133330 2001-04-27
JP2001-133330 2001-04-27
JP2001174698A JP4340400B2 (ja) 2001-04-27 2001-06-08 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法

Publications (2)

Publication Number Publication Date
JP2003018192A true JP2003018192A (ja) 2003-01-17
JP4340400B2 JP4340400B2 (ja) 2009-10-07

Family

ID=26614533

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001174698A Expired - Fee Related JP4340400B2 (ja) 2001-04-27 2001-06-08 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法

Country Status (4)

Country Link
US (1) US20030026241A1 (ja)
EP (2) EP1263182B1 (ja)
JP (1) JP4340400B2 (ja)
DE (1) DE60137025D1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004056054A1 (ja) * 2002-12-17 2004-07-01 Fujitsu Limited 負荷分散方法及びその装置
WO2005069557A1 (ja) * 2004-01-14 2005-07-28 Matsushita Electric Industrial Co., Ltd. モバイルルータ装置およびホームエージェント装置
US7298720B2 (en) 2003-03-03 2007-11-20 Hitachi, Ltd. Packet communication system, communication network, and method for selecting IP address in mobile node
WO2008013218A1 (en) * 2006-07-28 2008-01-31 Panasonic Corporation Mobile communication method and access router
WO2008059963A1 (en) * 2006-11-16 2008-05-22 Ntt Docomo, Inc. Communication control device and communication control method
JP2009272743A (ja) * 2008-05-01 2009-11-19 Fujitsu Ltd 無線ｌａｎシステムのアクセスポイント
US7657653B2 (en) 2002-12-17 2010-02-02 Fujitsu Limited Load decentralization method and apparatus thereof

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100414921B1 (ko) * 2001-12-29 2004-01-13 삼성전자주식회사 올 아이피 망에서의 핸드오프 방법
JP3984053B2 (ja) * 2002-01-09 2007-09-26 富士通株式会社 ホームエージェント
JP3878491B2 (ja) * 2002-01-30 2007-02-07 株式会社エヌ・ティ・ティ・ドコモ ルーチング経路変更契機の検出方法、端末、及び、ルータ
WO2004028053A1 (en) * 2002-09-18 2004-04-01 Flarion Technologies, Inc. Methods and apparatus for using a care of address option
US7756073B2 (en) * 2002-09-20 2010-07-13 Franck Le Method for updating a routing entry
JP3907568B2 (ja) * 2002-10-02 2007-04-18 キヤノン株式会社 認証装置
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8233392B2 (en) * 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7630305B2 (en) * 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
JP4120607B2 (ja) * 2003-04-03 2008-07-16 松下電器産業株式会社 ルータ装置および通信方法
KR100533667B1 (ko) * 2003-04-15 2005-12-05 삼성전자주식회사 효율적인 홈 네트워크 관리 시스템 및 방법
GB2403097A (en) * 2003-06-16 2004-12-22 Orange Personal Comm Serv Ltd Communicating internet packets having care-of-address as destination address to a mobile node
JP4353010B2 (ja) * 2003-07-15 2009-10-28 パナソニック株式会社 ホームエージェント、モバイルルータおよび、それらによる移動体通信方法
US8432800B2 (en) * 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US8238241B2 (en) 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US8050199B2 (en) * 2003-09-30 2011-11-01 Avaya Inc. Endpoint registration with local back-off in a call processing system
US7978716B2 (en) * 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
KR20050058935A (ko) * 2003-12-13 2005-06-17 삼성전자주식회사 바인딩 관리 장치, 바인딩 관리 방법, 그 방법을 수행하는프로그램이 기록된 컴퓨터 판독가능한 기록매체
US20180206166A1 (en) * 2004-01-06 2018-07-19 Vasu Networks Corporation Mobile telephone wifi/cellular seamless roaming switching controller
CN1961537B (zh) * 2004-01-07 2011-10-12 松下电器产业株式会社 通信系统、移动终端和接入路由器
WO2005067228A1 (ja) * 2004-01-07 2005-07-21 Matsushita Electric Industrial Co., Ltd. 通信システム及び移動端末並びにアクセスルータ
US20050288062A1 (en) * 2004-06-23 2005-12-29 Hammerschmidt Joachim S Method and apparatus for selecting a transmission mode based upon packet size in a multiple antenna communication system
US8739274B2 (en) * 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US7808906B2 (en) * 2004-07-23 2010-10-05 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
EP1771979B1 (en) 2004-07-23 2011-11-23 Citrix Systems, Inc. A method and systems for securing remote access to private networks
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US9197857B2 (en) * 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US7633879B2 (en) * 2004-12-13 2009-12-15 Cisco Technology, Inc. Method and apparatus for discovering the incoming media path for an internet protocol media session
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8700695B2 (en) * 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8954595B2 (en) * 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8077632B2 (en) * 2005-01-20 2011-12-13 Citrix Systems, Inc. Automatic LAN/WAN port detection
US7581005B2 (en) 2005-01-20 2009-08-25 Citrix Systems, Inc. Systems and methods for preserving transport layer protocol options
CN102123178B (zh) 2005-01-24 2014-04-09 茨特里克斯系统公司 在网络中对动态产生的对象执行缓存的系统和方法
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
US7826362B2 (en) * 2005-03-30 2010-11-02 Cisco Technology, Inc. Upstream data rate estimation
US8369329B2 (en) * 2005-05-16 2013-02-05 Rockstar Consortium Us Lp Dynamic hierarchical address resource management architecture, method and apparatus
KR100653527B1 (ko) * 2005-05-30 2006-12-05 주식회사 팬택앤큐리텔 인터넷 프로토콜 주소 운용 방법
WO2006129858A1 (en) * 2005-05-31 2006-12-07 Matsushita Electric Industrial Co., Ltd. Method and apparatus for controlling packet forwarding
WO2007001951A2 (en) 2005-06-21 2007-01-04 Motorola, Inc. System and method for providing a distributed virtual mobility agent
WO2007001949A2 (en) 2005-06-21 2007-01-04 Motorola, Inc. Address resolution protocol-based wireless access point
DE112006001618B4 (de) * 2005-06-21 2015-12-24 Motorola Mobility, Inc. ( N.D. Ges. D. Staates Delaware ) Verfahren und Vorrichtung zum Verringern der Latenz während Änderungen einer drahtlosen Konnektivität
GB2440886B (en) 2005-06-21 2009-11-04 Motorola Inc Method and apparatus to facilitate communications using surrogate and care of internet protocol addresses
WO2007001950A1 (en) 2005-06-21 2007-01-04 Motorola, Inc. System and method for paging and location update in a network
DE112006001447B4 (de) 2005-06-21 2013-03-07 Motorola Mobility, Inc. ( N.D. Ges. D. Staates Delaware ) Verfahren, Vorrichtung und System zum Einrichten eines direkten Leitweges zwischen Agenten eines Senderknotens und eines Empfängerknotens
WO2007001954A1 (en) 2005-06-21 2007-01-04 Motorola, Inc. Method and apparatus to facilitate mobile station communications using internet protocol-based communications
US7921184B2 (en) * 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
US8301839B2 (en) * 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7773571B1 (en) * 2006-02-03 2010-08-10 Nortel Networks Limited Transfer of policy and charging rules during MIP handover
WO2007119635A1 (ja) * 2006-03-27 2007-10-25 Nec Corporation フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム
CN101119393A (zh) * 2006-08-02 2008-02-06 华为技术有限公司 更新分类器的方法、系统及移动节点
JP4769669B2 (ja) * 2006-09-07 2011-09-07 富士通株式会社 モバイルｉｐに準拠する移動通信システム、ホームエージェント、モバイルノード及び方法
KR100998687B1 (ko) * 2006-09-13 2010-12-10 각고호우징 게이오기주크 방송 콘텐츠 전송장치 및 방송 콘텐츠 전송방법
JP2010507301A (ja) * 2006-10-20 2010-03-04 パナソニック株式会社 ネットワーク・ベース及びホスト・ベースの混合モビリティ管理における方法
US7664857B2 (en) 2007-01-26 2010-02-16 Citrix Systems, Inc. Systems and methods of using an IP ID field for automatic WAN/LAN detection
US8023419B2 (en) 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
US7936695B2 (en) 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US7835406B2 (en) 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US8897211B2 (en) * 2007-06-29 2014-11-25 Alcatel Lucent System and methods for providing service-specific support for multimedia traffic in wireless networks
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
KR101504763B1 (ko) * 2007-08-07 2015-03-23 삼성전자주식회사 근거리 네트워크에서 물품 정보를 제공하는 시스템 및 방법
EP2225662A4 (en) * 2007-11-21 2011-06-22 Nortel Networks Ltd METHOD OF ENSURING THE CONTINUITY OF TUNNEL COMMUNICATIONS FOR MOBILE NUTS HAVING SEVERAL TEMPORARY ADDRESSES
US7835377B2 (en) * 2008-11-12 2010-11-16 Telefonaktiebolaget L M Ericsson (Publ) Session continuity for support of simultaneous terminal accesses
EP2497023B1 (en) * 2009-11-02 2015-02-25 Hewlett Packard Development Company, L.P. Multiprocessing computing with distributed embedded switching
US8301982B2 (en) * 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
US8875220B2 (en) * 2010-07-01 2014-10-28 Raytheom Company Proxy-based network access protection
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US8743889B2 (en) * 2010-07-06 2014-06-03 Nicira, Inc. Method and apparatus for using a network information base to control a plurality of shared network infrastructure switching elements
US9854055B2 (en) * 2011-02-28 2017-12-26 Nokia Technologies Oy Method and apparatus for providing proxy-based content discovery and delivery
US9392469B2 (en) * 2011-06-03 2016-07-12 Qualcomm Incorporated Systems and methods for receiver based clear channel assessment
US8989029B2 (en) 2011-06-10 2015-03-24 Comcast Cable Communications, Llc Quality of service in packet networks
WO2015028088A1 (en) * 2013-08-30 2015-03-05 Nec Europe Ltd. Method for operating a distributed computing system and a distributed computing system
US9936009B2 (en) * 2014-05-22 2018-04-03 Qualcomm Incorporated Systems and methods of operating a device of a data path group network
US10257083B2 (en) * 2014-08-29 2019-04-09 Cisco Technology, Inc. Flow cache based mechanism of packet redirection in multiple border routers for application awareness
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
CN115297047B (zh) * 2022-09-26 2023-02-28 安徽华云安科技有限公司 组网方法、电子设备及计算机可读存储介质
CN115970292B (zh) * 2022-12-30 2025-07-25 北京字跳网络技术有限公司 游戏实体处理方法、装置、可读介质及电子设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6208625B1 (en) * 1997-06-12 2001-03-27 Motorola, Inc. Method and apparatus for increasing call-handling capacity using a multi-tier satellite network
US6160804A (en) * 1998-11-13 2000-12-12 Lucent Technologies Inc. Mobility management for a multimedia mobile network
US6763007B1 (en) * 1998-12-11 2004-07-13 Lucent Technologies Inc. Two phase local mobility scheme for wireless access to packet based networks
US6578085B1 (en) * 1999-01-27 2003-06-10 Nortel Networks Limited System and method for route optimization in a wireless internet protocol network
JP4035803B2 (ja) * 1999-02-19 2008-01-23 富士通株式会社 移動パケット通信システム
WO2001006732A1 (en) * 1999-07-19 2001-01-25 British Telecommunications Public Limited Company Routing in a packet switching network with mobile terminals
US6603972B1 (en) * 1999-08-26 2003-08-05 Lucent Technologies Inc. Apparatus, method and system for voice communication hand-off in a mobile packet data network environment
US6748233B1 (en) * 1999-10-28 2004-06-08 Telcordia Technologies, Inc. System and method for energy-efficient transmission power control, routing and transmission scheduling in wireless communication networks
JP3450776B2 (ja) * 1999-12-28 2003-09-29 株式会社エヌ・ティ・ティ・ドコモ 移動無線パケット通信システムにおける移動端末機の位置管理方法及びその移動無線パケット通信システム
WO2001076188A2 (en) * 2000-03-31 2001-10-11 British Telecommunications Public Limited Company Mobile data routing
US6999436B2 (en) * 2001-04-16 2006-02-14 Nokia Corporation Method and apparatus for efficient routing of mobile node packets

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657653B2 (en) 2002-12-17 2010-02-02 Fujitsu Limited Load decentralization method and apparatus thereof
WO2004056054A1 (ja) * 2002-12-17 2004-07-01 Fujitsu Limited 負荷分散方法及びその装置
US7298720B2 (en) 2003-03-03 2007-11-20 Hitachi, Ltd. Packet communication system, communication network, and method for selecting IP address in mobile node
WO2005069557A1 (ja) * 2004-01-14 2005-07-28 Matsushita Electric Industrial Co., Ltd. モバイルルータ装置およびホームエージェント装置
US7756061B2 (en) 2004-01-14 2010-07-13 Panasonic Corporation Mobile router device and home agent device
WO2008013218A1 (en) * 2006-07-28 2008-01-31 Panasonic Corporation Mobile communication method and access router
US8155085B2 (en) 2006-07-28 2012-04-10 Panasonic Corporation Mobile communication method and access router
JP5102766B2 (ja) * 2006-07-28 2012-12-19 パナソニック株式会社 移動通信方法及びアクセスルータ
WO2008059963A1 (en) * 2006-11-16 2008-05-22 Ntt Docomo, Inc. Communication control device and communication control method
CN101536580B (zh) * 2006-11-16 2012-02-22 株式会社Ntt都科摩 通信控制装置和通信控制方法
JP4995202B2 (ja) * 2006-11-16 2012-08-08 株式会社エヌ・ティ・ティ・ドコモ 通信制御装置及び通信制御方法
US8542651B2 (en) 2006-11-16 2013-09-24 Ntt Docomo, Inc. Communication control device and communication control method
JP2009272743A (ja) * 2008-05-01 2009-11-19 Fujitsu Ltd 無線ｌａｎシステムのアクセスポイント
US8576814B2 (en) 2008-05-01 2013-11-05 Fujitsu Limited Access point used in wireless LAN system

Also Published As

Publication number Publication date
US20030026241A1 (en) 2003-02-06
EP1263182B1 (en) 2008-12-17
EP1718024A1 (en) 2006-11-02
JP4340400B2 (ja) 2009-10-07
EP1263182A2 (en) 2002-12-04
DE60137025D1 (de) 2009-01-29
EP1263182A3 (en) 2005-12-07

Similar Documents

Publication Publication Date Title
JP2003018192A (ja) 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるゲートノード，エッジノード及び移動端末並びにパケット網におけるハンドオーバ方法及びルーティングノード
EP1030491B1 (en) System and method for route optimization in a wireless internet protocol network
JP3568852B2 (ja) 有線サブネットにアクセスする無線デバイス用にパケット経路設定アドレスを割り当てる方法及び装置
JP3573265B2 (ja) パケットを無線デバイスに送信するステップ
EP1011243B1 (en) Single phase local mobility scheme for wireless access to packet-based networks
CA2287786C (en) Wireless access to packet-based networks
US6763007B1 (en) Two phase local mobility scheme for wireless access to packet based networks
EP1260113B1 (en) Hierarchical mobility management for wireless networks
EP1206098B1 (en) Home agent and IP packet transferring method
EP1598992B1 (en) Mobile terminal management system, mobile terminal and program
JP4754735B2 (ja) 第３世代の移動通信システムのルーティング最適化方法
JP2000253068A (ja) インターネットプロトコルｉｐパケットを移動体ノードに宛てる方法および移動体ｉｐ環境
JP2004015143A (ja) 移動通信システムにおけるハンドオーバ方法、および移動通信システムにおいて使用されるルータ装置
CN103458389B (zh) 移动节点注册方法、互通方法、切换方法和网元
KR100554167B1 (ko) 계층적 이동 아이피에서의 핸드오버방법
Wang et al. Integrated Mobile IP and SIP approach for advanced location management
CN101854664B (zh) 一种在嵌套移动网络中数据转发的优化方法
JP2004282473A (ja) 移動ネットワークおよびその通信方法
Sun et al. Mobile IP applicability: When do we really need it?
WO2000041418A1 (en) Routing data in an ip-based communication system
JP2005026941A (ja) モバイルｉｐネットワークシステム及び位置登録方法
EP1445915B1 (en) System and method for route optimization in a wireless internet protocol network
Neumann Prototypical Implementation and Experimental Testbed Setup of a QoS-Enabled Mobility Concept Based on HMIPv6
Boban An Overview of Macro-Mobility Management in Next Generation All-IP Baesd Wireless Network Infrastructures
Safa et al. Improving Location Management in Mobile IPv4 Networks.

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061113

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20081107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090414

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090519

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: 20090609

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090706

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: 20120710

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120710

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130710

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees