JP4340400B2 - 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 - Google Patents
階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 Download PDFInfo
- Publication number
- JP4340400B2 JP4340400B2 JP2001174698A JP2001174698A JP4340400B2 JP 4340400 B2 JP4340400 B2 JP 4340400B2 JP 2001174698 A JP2001174698 A JP 2001174698A JP 2001174698 A JP2001174698 A JP 2001174698A JP 4340400 B2 JP4340400 B2 JP 4340400B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- node
- cache
- information
- mobile terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000004891 communication Methods 0.000 title claims description 299
- 238000012546 transfer Methods 0.000 title claims description 116
- 238000000034 method Methods 0.000 title claims description 114
- 230000008859 change Effects 0.000 claims description 48
- 238000012545 processing Methods 0.000 description 250
- 230000004044 response Effects 0.000 description 94
- 230000006870 function Effects 0.000 description 74
- 101150029673 vha-10 gene Proteins 0.000 description 72
- 238000010586 diagram Methods 0.000 description 56
- 238000012217 deletion Methods 0.000 description 48
- 230000037430 deletion Effects 0.000 description 48
- 238000012986 modification Methods 0.000 description 48
- 230000004048 modification Effects 0.000 description 48
- 238000004458 analytical method Methods 0.000 description 43
- 238000005538 encapsulation Methods 0.000 description 30
- 230000005540 biological transmission Effects 0.000 description 24
- 238000005457 optimization Methods 0.000 description 22
- 238000012544 monitoring process Methods 0.000 description 21
- 230000008569 process Effects 0.000 description 21
- 238000007726 management method Methods 0.000 description 18
- 239000003795 chemical substances by application Substances 0.000 description 11
- 101150114166 coa2 gene Proteins 0.000 description 9
- 239000007787 solid Substances 0.000 description 9
- 230000015556 catabolic process Effects 0.000 description 5
- 238000006731 degradation reaction Methods 0.000 description 5
- 102100030978 Cytochrome c oxidase assembly factor 1 homolog Human genes 0.000 description 4
- 101000919635 Homo sapiens Cytochrome c oxidase assembly factor 1 homolog Proteins 0.000 description 4
- 239000000284 extract Substances 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000006866 deterioration Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 239000000969 carrier Substances 0.000 description 2
- 239000012141 concentrate Substances 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 239000002775 capsule Substances 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 101150082540 vha-11 gene Proteins 0.000 description 1
Images
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
-
- 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)
Description
【０００１】
【発明の属する技術分野】
本発明は、階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法に関し、特に、MIPv6（Mobile Internet Protocol version 6）等に準拠したパケット網に用いて好適な技術に関する。
【０００２】
【従来の技術】
近年、IETF（Internet Engineering Task Force）において、インターネットプロトコル（ＩＰ）上で携帯電話等の移動端末（以下、単に「端末」ともいう）の位置を管理する方式として、「MIPv6」が提案されている。
図６３に「MIPv6」に準拠したパケット通信システムの一例を示す。この図６３に示すシステムでは、ルータ網（パケット網）１１０を運営するＩＳＰ（Internet Service Provider）等（以下、単に「プロバイダ」という）が管理するホームエージェント（HA：Home Agent）ノード１００において、そのプロバイダが提供するパケット転送サービスの契約加入者の移動端末（これを「ホーム端末」あるいは「契約端末」という）５００の現在位置が管理される。
【０００３】
同様に、ＨＡノード１００（ルータ網１１０）のプロバイダとは異なるプロバイダが管理するＨＡノード〔ＨＡノード１００側からみれば外部（foreign）網２１０のＨＡノード〕２００では、ルータ網２１０についての契約端末の現在位置が管理される。なお、３００，４００はルータ網１１０，２１０間を結ぶ中継ルータ網を表す。
【０００４】
ここで、具体的に、上記の契約端末５００の現在位置管理は、契約端末５００が契約ルータ網（ホーム網）１１０に存在している場合、その現在位置からアクセスしうる最寄りのアクセスノード（在圏ノード；無線基地局としての機能を有するパケットのラストホップルータ）１１１から広告（報知）される情報〔ルータ広告（ＲＡ：Router Advertisment）メッセージ〕に含まれるアクセスノード１１１のＩＰアドレスを基にCOA（Care of Address）と呼ばれる、現在自己がどのノードの在圏ゾーンに位置しているか（つまり、端末５００の接続先ノード）を表す情報を作成し、これをＨＡノード１００に通知することで実施される。
【０００５】
一方、契約端末５００がその移動により非契約ルータ網（移動先網）２１０に存在している場合（いわゆる「ローミング」中の場合）には、契約端末５００は、移動先網２１０の最寄りのアクセスノード２１１から受信されるＲＡに含まれるアクセスノード２１１のＩＰアドレスを基にCOAを作成して、これをホーム網１１０のＨＡノード１００にルータ網２１０，３００，４００を介して通知することになる。
【０００６】
つまり、契約端末５００は、その移動によって受信するＲＡに含まれるＩＰアドレスが変化して最寄りのアクセスノード１１１又は２１１が変わる度に、新たなCOAを作成してホーム網１１０のＨＡノード１００に対して現在位置の更新登録を実施するのである。
これにより、ＨＡノード１００は、契約端末５００が非契約ルータ網２１０に位置する場合（「ローミング」中の場合）であっても、逐次、更新登録されている現在位置宛に契約端末５００宛のパケットをカプセル化（契約端末５００宛のパケットにCOAを宛先アドレスとするヘッダを付加）して転送することで、契約端末５００宛のパケットを正しく契約端末５００に届けることができ、正常な移動通信が実現される。
【０００７】
なお、ルータ網２１０についての契約端末によるＨＡノード２００に対する位置登録手順も上記と同様である。
しかしながら、このような位置登録手順では、端末はその移動により最寄りのアクセスノードが変わる度に常にＨＡノード１００又は２００に位置登録を行なわなければならないため、現在位置とＨＡノード１００（又は２００）との距離に応じたパケット転送遅延が生じ、高速ハンドオーバには不向きである。また、アクセスノード２１１（又は１１１）からＨＡノード１００（又は２００）までのルータ網２１０，３００，４００，１１０のトラフィック量の増大にもつながる。
【０００８】
なお、上記のシステムにおいてローミング中の契約端末（以下、ローミング端末という）５００と相手端末６００（移動端末でもよいし固定端末でもよい）との通信が開始された後は、例えば図６４に示すように、ローミング端末５００が、ＨＡノード１００に対する位置登録と同様に、相手端末６００に現在のCOAを通知する（破線矢印７００参照）ことで、「ルート最適化」を図ることができる。つまり、相手端末６００は、現在のCOAをローミング端末５００から直接受信することで、ＨＡノード１００を経由せずにそのCOA宛に直接パケットを送信することができるようになるのである（実線矢印８００参照）。
【０００９】
ただし、この場合も、ローミング端末５００が移動して最寄りのアクセスノード２１１が変わったときには、その都度、新しいCOAを相手端末６００に通知する必要があるため、相手端末６００との距離に応じたパケット転送遅延によってハンドオーバ品質が左右されることになり、やはり高速ハンドオーバには向かない。
【００１０】
このように、図６３に示すような通常の「MIPv6」網（パケット通信システム）では、ローミング先のルータ網２１０でローミング端末５００が移動すると、その移動の度（正確には、最寄りのアクセスノードが変わる度）に、ＨＡノード１００への位置登録が発生し、ハンドオーバ時の通信品質劣化を生じるが、これを緩和するために、近年、ルータ網を階層化して階層内の移動時にはＨＡノードへの位置登録を不要とする方式〔階層化（Hierarchical）MIPv6〕も提案されている。
【００１１】
図６５に階層化Mobile-IPv6（以下、「HMIPv6」と表記する）に準拠したパケット通信システムの一例を示す。この図６５において、９００が移動端末５００へのゲート機能を提供するゲートノード（ＭＡ；Mobility Agent）であり、この図６５に示すように、それぞれが１台以上のアクセスノードを収容することにより、ルータ網１１０又は２１０のＭＡ９００単位での階層化が図られている。
【００１２】
そして、例えば、ルータ網１１０をホーム網とする契約端末５００がホーム網１１０からローミング先のルータ網２１０へ移動（ローミングイン）すると（矢印９０３参照）、その端末５００は、最寄りのＭＡ９００からルータ広告（ＲＡ）メッセージ（以下、単に「ルータ広告」ともいう）を受けて、そのＭＡ９００配下で使用するローカルなＩＰアドレス（「PCOA」と呼ばれる）と、ＨＡノード１００からＭＡ９００まで到達可能なＩＰアドレス（「VCOA」と呼ばれる）の２つのアドレスを作成する。
【００１３】
その後、端末５００は、「VCOA」をＨＡノード１００に通知して現在位置の位置登録を行なう（矢印９０４参照）とともに、「PCOA」をＭＡ９００に通知してＭＡ９００にも位置登録を行なう（矢印９０５参照）。以降、端末５００は、同一ＭＡ９００の配下での移動の場合（矢印９０１参照）には、ＭＡ９００にのみ位置登録を行ない（矢印９０６参照）、ＨＡノード１００への位置登録は行なわず、ＭＡ９００が異なる地域へ移動した場合（矢印９０２参照）には、再度、移動先のＭＡ９００とＨＡノード１００の両方に位置登録を行なう（矢印９０７，９０８参照）。なお、端末５００は、ホーム網１１０内に位置する場合にも、ＭＡをまたぐ移動が生じると、その都度、移動先のＭＡ９００とＨＡノード１００の双方に位置登録を行なう。
【００１４】
つまり、「HMIPv6」準拠のパケット通信システム（以下、階層化パケット通信システムという）では、同一ＭＡ９００内の移動であれば、端末５００は自己の現在位置の登録先（ＭＡ９００）を切り替えないのである。したがって、図６３及び図６４により前述した通常のシステムよりも、高速なハンドオーバを実現できる。
【００１５】
なお、この階層化パケット通信システムにおいても、前述したような「ルート最適化」を行なう場合には、図６６に示すように、ローミング端末５００が、相手端末６００との通信開始後、相手端末６００に現在の「VCOA」を通知すればよい（破線矢印９０９参照）。
つまり、相手端末６００から最初に端末５００宛に送信されたパケットが、一旦、ＨＡノード１００で受信され（矢印９１０参照）、ＨＡノード１００にて「VCOA」（ＭＡアドレス）でカプセル化されてＭＡ９００へルーティングされ、そのＭＡ９００にて「PCOA」（移動先アドレス）でカプセル化されて該当アクセスノード２１１へルーティングされることにより、相手端末６００とローミング端末５００との通信が開始されるが、その後は、ローミング端末５００が、相手端末６００に「VCOA」（ＭＡ９００まで到達可能なアドレス）を通知することにより、相手端末６００は、その「VCOA」宛にパケットを送信することが可能となり、当該パケットはＭＡ９００まで到達できる。
【００１６】
ただし、この場合も、ローミング端末５００の移動によりＭＡ９００が変わる（「VCOA」が変わる）場合には、その都度、新しい「VCOA」を相手端末６００に再通知する必要がある。なお、「ルート最適化」前の相手端末６００からローミング端末５００までのパケット転送ルートの一例を図６７に、「ルート最適化」後の相手端末６００からローミング端末５００までのパケット転送ルートの一例を図６８にそれぞれ示す。なお、これらの図６７，図６８において、符号１１０ａ，１１０ｂ（２１０ａ，２１０ｂ）はそれぞれＭＡ９００が管轄する階層化網を表し、これらの階層化網１１０ａ，１１０ｂ（２１０ａ，２１０ｂ）によってホーム網１１０（移動先網２１０）が形成されていることを示している。
【００１７】
そして、これらの図６７，図６８から分かるように、階層化パケット通信システムでは、ＨＡノード１００に「VCOA」を通知することで、常に、端末５００が位置登録（「PCOA」の通知）を行なっているＭＡ９００までのルートが最短距離となるよう最適化される（換言すれば、階層化パケット通信システムにおける「ルート最適化」では、必然的に、最低１台のＭＡ９００を経由することになる）。
【００１８】
ところで、従来の「Mobile-IP」網におけるハンドオーバ方法には、「スムースハンドオーバ」と呼ばれるものがある。これは、例えば図６９に模式的に示すように、ＨＡ１００（２００）に「COA1」が登録されている状態で、端末５００が移動して接続先ルータが「Ｒ１」から「Ｒ２」に変わることにより新しい「COA2」を作成したときに、ＨＡ１００（２００）ではなく、移動直前の接続先ルータ「Ｒ２」に対して、新しい「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（Multi-Media Mobile Network based on IPv6）ネットワーク」と称することがある。
【００３５】
ここで、ＶＨＡノード１０（２０）は、自キャリア網（ホーム網）１（２）内に存在する契約加入者の移動端末（ＭＮ：Mobile Node）３（以下、「ホーム端末３」もしくは単に「端末３」という場合がある）の現在位置情報〔COA（VCOA，PCOA）〕を結合（バインディング）キャッシュ（Binding Cache）と呼ばれる情報の一部として管理するとともに、到着（受信）した端末３宛のパケットが示す宛先アドレス（ＤＡ）に対応する「COA」を本「キャッシュ」において検索し、該当「COA」でカプセル化して転送（ルーティング）するためのものである。
【００３６】
なお、上記の「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（「PCOA」）を登録し、「Ｍ３対応網」である他網２（１）にローミングインするときには、ローミング先のＴＨＡ２１ａ又は２１ｂ（１１ａ又は１１ｂ）と、ホーム網１（２）のＶＨＡ１０（２０）との双方にCOAを登録するようになっている。
【００５１】
この場合、端末３は、ＴＨＡ２１ａ又は２１ｂ（１１ａ又は１１ｂ）には「PCOA」を登録し、ＶＨＡ１０（２０）には「VCOA」を登録する。また、本端末３は、上記の「ルータ広告」に含まれるアドレス情報によってローミング先の網種別を識別することができるので、その網種別に応じて位置登録先を変えることができる。
【００５２】
即ち、例えば、「ルータ広告」にＭ３ネットワークアドレスが含まれずＭＡアドレスが含まれている場合はその網が通常の「HMIPv6」網であるので、ローミング先のＭＡに「PCOA」を、ホーム網１（２）のＶＨＡ１０（２０）に「VCOA」をそれぞれ登録する。また、「ルータ広告」にＭ３ネットワークもＭＡアドレスも含まれていない場合は、その網は通常の「MIPv6」網であるので、端末３は、ＶＨＡ１０（２０）にのみ「VCOA」を登録する。つまり、本実施形態の端末３は、「MIPv6」，「HMIPv6」，「M3v6」のどのネットワークにも対応できるようになっているのである。
【００５３】
(A2)各種メッセージの詳細説明
さて、次に、本実施形態のシステムにおいて使用される上記の各種メッセージについて整理すると、次表１に示すようになる。
【００５４】
【表１】
【００５５】
以下、これらのメッセージの詳細について説明する。なお、以下では、これらのメッセージを「モバイルメッセージ」と総称する。これらの「モバイルメッセージ」は、「MIPv6」準拠の制御メッセージを拡張したもので、基本的には、いずれも、図７に示すような「MIPv6」に準拠したパケット（以下、「MIPv6」パケットともいう）のフォーマットを有している。
【００５６】
即ち、「MIPv6」パケットは、標準ヘッダ７１，オプションヘッダ７２及び認証ヘッダ７３から成るＩＰヘッダ７０とＩＰペイロード８０とから成るが、「モバイルメッセージ」は、これらのうちＩＰペイロード８０を除く部分で構成される。そして、上記のＩＰヘッダ７０（特に、オプションヘッダ７２）の設定内容によって上記の各メッセージ（パケット）が表示（識別）されるのである。
【００５７】
なお、標準ヘッダ７１には、図８に示すように、「バージョン情報」（４ビット），「トラフィッククラス」（８ビット），「フローラベル」（２０ビット），「ペイロード長」（１６ビット），「ネクストヘッダ」（８ビット），「ホップ制限数」（８ビット），「送信元アドレス（ＳＡ：Source Address）」（１２８ビット），「宛先アドレス（ＤＡ：Destination Address）」（１２８ビット）が格納される各フィールド７１１〜７１８が用意されている。
【００５８】
以下、上記の各モバイルメッセージのパケットフォーマットについて説明する。
(1)ホーム位置登録／位置登録応答メッセージ
図９にホーム位置登録メッセージのパケットフォーマット（ただし、ＩＰヘッダ７０に相当する部分）を示す。この図９から分かるように、ホーム端末３のホーム網１（２）への位置登録〔ＶＨＡ１０（２０）に対する位置登録〕には、「MIPv6」のオプションヘッダ７２の宛先オプションとして定義されている結合更新（Binding Update）オプション及びホームアドレス（Home Address）オプションを使用する。次表２に結合更新オプション（位置登録）パラメータを、次表３にホームアドレスオプションパラメータをそれぞれ示す。
【００５９】
【表２】
【００６０】
【表３】
【００６１】
そして、図９に示すように、ホーム位置登録メッセージの場合は、ＳＡフィールド７１７に端末３のCO A（MN-COA）が格納され、ＤＡフィールド７１８にＶＨＡ１０（２０）のアドレス（ＶＨＡアドレス）が格納される。これにより、ＶＨＡ１０（２０）にホーム位置登録メッセージが到着し、「ＳＡフィールド」に格納されているCOAが「キャッシュ情報」に登録されて端末３の位置登録（更新）が行なわれることになる。なお、本メッセージが「結合更新メッセージ」であることは、オプションタイプ（Option Type）フィールド７２３に表示（ここでは、“１９８”）される。
【００６２】
これに対し、上記のホーム位置登録メッセージを受けたＶＨＡ１０（２０）から端末３へのホーム位置登録応答には、図１０に示すパケットフォーマットを用いる。即ち、ホーム位置登録応答には、「MIPv6」の宛先オプションとして定義されている結合応答（Binding Acknowledgement）オプションを使用する。次表４にこの場合の結合応答オプションパラメータを示す。
【００６３】
【表４】
【００６４】
そして、図１０に示すように、ホーム位置登録応答メッセージの場合は、ＳＡフィールド７１７に発信ノード〔この場合はＶＨＡ１０（２０）〕のアドレスが格納され、ＤＡフィールド７１８にMN-COA〔受信パケット（つまり、上記のホーム位置登録メッセージ）のＳＡ〕が格納されることにより、ＶＨＡ１０（２０）位置登録を行なった端末３宛に本メッセージが発行（返信）されて、位置登録完了の旨が通知されることになる。
【００６５】
なお、ホーム位置登録メッセージを受けたＶＨＡ１１（２１）が位置登録応答メッセージを発行すべきか否かは結合更新オプションのＡ（Acknowledgement）ビットフィールド７２７に表示される（表２に示すように、“１”で要を表す）。また、図９及び図１０において、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、次表５のとおりである。
【００６６】
【表５】
【００６７】
（２）在圏位置登録／位置登録応答メッセージ
次に、在圏網１ａ，１ｂ（２ａ，２ｂ）への位置登録〔ＴＨＡ１１（２１）に対する位置登録〕には、図１１に示すパケットフォーマットを使用する。即ち、「HMIPv6」の宛先オプション７２として定義されている結合更新（Binding Update）オプションと同等の登録オプション（Registration）及びホームアドレスオプション（表３参照）を使用する。次表６に登録オプションパラメータを示し、次表７，８にそれぞれ表６中に示す前ＭＡアドレスサブオプション（previous mobility agent address sub-option）パラメータ，ホームエージェントアドレスサブオプション（home agent address Sub-Option）パラメータを示す。
【００６８】
【表６】
【００６９】
【表７】
【００７０】
【表８】
【００７１】
そして、図１１に示すように、本在圏位置登録（Registration）メッセージの場合も、基本的に、上述したホーム位置登録メッセージと同様に、ＳＡフィールド７１７に端末３のCOA（MN-COA）が格納され、ＤＡフィールド７１８にＴＨＡ１１（２１）のアドレス（ＴＨＡアドレス）が格納されることにより、ＴＨＡ１１（２１）に本在圏位置登録メッセージが到着し、ＳＡフィールド７１７に格納されているCOAがＴＨＡ１１（２１）の「キャッシュ情報」に登録されて端末３の位置登録（更新）が行なわれることになる。
【００７２】
なお、本メッセージが「Registration」メッセージであることは、オプションタイプフィールド７２３に表示（ここでは、“９”）される。また、前ＭＡアドレスサブオプションの前ＭＡアドレスフィールド７２１には、端末３が移動する前に位置登録を行なっていたＴＨＡ１１（２１）のアドレスが格納され、ＴＨＡ１１（２１）は、この前ＭＡアドレスフィールド７２１に設定されているアドレスを参照することで、在圏端末３がどのＴＨＡ１１（２１）の在圏ゾーンから移動してきたかを認識できることになる。
【００７３】
なお、図１１においても、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、前記の表５のとおりである。
これに対し、ＴＨＡ１１（２１）から端末３への位置登録応答には、前記の結合応答オプション（表４参照）を使用する。つまり、図１０に示すものと同様のパケットフォーマットを使用する。そして、ＳＡフィールド７１７に発信ノード〔この場合は、ＴＨＡ１１（２１）〕のアドレスが格納され、ＤＡフィールド７１８にMN-COA（受信パケットのＳＡフィールド７１７に設定されていたアドレス）が格納されることにより、ＴＨＡ１１（２１）に対して位置登録を行なった端末３宛に本メッセージが発行（返信）されて、位置登録完了の旨が通知されることになる。
【００７４】
（３）位置（キャッシュ）更新／応答メッセージ
次に、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）からＥＮ１２への位置更新（キャッシュ更新）には、図１２に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、結合更新オプション及びホームアドレスオプション（前記の表３参照）を使用する。ただし、更新対象の端末３のCOAは、結合更新オプションの代替COAサブオプション（Alternate Care of Address Sub-Option）によって通知する。次表９に結合更新オプション（位置更新）パラメータ例を、次表１０に代替COAサブオプションパラメータ例を示す。
【００７５】
【表９】
【００７６】
【表１０】
【００７７】
なお、本位置更新メッセージは、上述した端末３からＶＨＡ１０（２０）又はＴＨＡ１１（２１）への位置登録によりＶＨＡ１０（２０）又はＴＨＡ１１（２１）の「キャッシュ情報」が更新されることに伴って通信中のＥＮ１２にその更新を反映させる必要があるときに発行されるメッセージである。
このため、図１２に示すように、本位置更新メッセージの場合は、ＳＡフィールド７１７にＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納されるとともに、ＤＡフィールド７１８にＥＮ１２のアドレス（通信中ＥＮアドレス）が格納され、且つ、代替COAフィールド７２２に位置更新対象の端末３のCOA（MN-COA）が格納される。
【００７８】
これにより、「キャッシュ情報」の更新が必要な通信中ＥＮ１２に更新情報（MN-COA）が提供されて、通信中ＥＮ１２の「キャッシュ情報」が更新され、通信中ＥＮ１２は、端末３に対するパケットルーティングを正常に継続することが可能になる。なお、本メッセージが「位置更新メッセージ」であることは、代替COAフィールド７２２の有無によって識別できる。
【００７９】
一方、通信中ＥＮ１２は、上記の位置更新メッセージに対する応答（位置更新応答メッセージ）を発行元のＶＨＡ１０（２０）又はＴＨＡ１１（２１）に返信するが、このときの位置更新応答には、図１３に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、本メッセージの場合も、結合応答オプション（パラメータについては前記の表４参照）を使用する。
【００８０】
そして、この図１３に示すように、本位置更新応答メッセージの場合は、ＳＡフィールド７１７に発信ノード（ＥＮ１２）のアドレスが格納され、ＤＡフィールド７１８に上記の受信パケット（位置更新メッセージ）のＳＡフィールド７１７に設定されていたアドレス〔つまり、位置更新メッセージの発信元のＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレス〕が格納されることにより、そのＶＨＡ１０（２０）又はＴＨＡ１１（２１）宛に本メッセージが発行（返信）されて、位置更新完了の旨が通知されることになる。
【００８１】
なお、この場合も、本位置更新メッセージを受けたＥＮ１２がそれに対する応答メッセージを発行すべきか否かは結合更新オプションのＡ（Acknowledgement）ビット（表２参照）に表示される（“１”で要を表す）。また、図１２及び図１３においても、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、前記の表５に準ずる。
【００８２】
（４）キャッシュ要求／通知メッセージ
次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１（２１）へのキャッシュ要求（後述するキャッシュ検索によりキャッシュヒットしなかった場合に発行される）には、また、図１４に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、「MIPv6」の宛先オプションとして新規に定義した結合要求〔Binding Reauest for M3 (BR-M3)〕オプションを使用する。
【００８３】
なお、このキャッシュ要求は、ＥＮ１２がＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスを既知である場合には、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）をＤＡとして本メッセージを発行する。このとき、どのアドレスに対する「キャッシュ」を要求しているかを示すためにホームアドレスオプションを使用する。
【００８４】
また、別の例として、ＤＡに「キャッシュ」を要求したいアドレスを直接指定する方法もある。この場合、「キャッシュ」をもっているエージェント〔ＶＨＡ１０（２０）／ＴＨＡ１１（２１）〕は、BR-M3メッセージであることを宛先オプションから判断し、ＤＡから「キャッシュ」を要求するアドレスを知るように定義することも可能である。
【００８５】
次表１１にBR-M3オプションパラメータ例を、次表１２に表１１中に示す固有ＩＤサブオプション（Unique Identifier Sub-Option）パラメータ例を、次表１３にホームアドレスオプション（キャッシュ要求）パラメータ例をそれぞれ示す。
【００８６】
【表１１】
【００８７】
【表１２】
【００８８】
【表１３】
【００８９】
そして、図１４に示すように、本キャッシュ要求メッセージの場合は、BR-M3オプションのオプションタイプフィールド７２３に、本メッセージがBR-M3メッセージであることを表す値（例えば、“１６”）が格納され、ＳＡフィールド７１７にＥＮ１２のアドレスが格納され、ＤＡフィールド７１８にキャッシュを知りたい端末３のアドレス、又は、その端末３に対応するエージェント〔ＶＨＡ１０（２０）又はＴＨＡ１１（２１）〕のアドレスが格納される。また、ＤＡフィールド７１８に後者のアドレスを格納する場合には、ホームアドレスフィールド７２４に、キャッシュを要求したいノードのホームアドレスが格納される。
【００９０】
これに対し、ＥＮ１２へのキャッシュ通知には、図１５に示すパケットフォーマットを使用する。即ち、結合更新オプション及びホームアドレスオプションを使用する。次表１４に、この場合の結合更新（Binding Update）オプションパラメータ例を、次表１５及び次表１６に表１４中に示す固有ＩＤサブオプション（Unique Identifier Sub-Option）パラメータ例及び代替COAサブオプション（Alternate Care of Address Sub-Option）パラメータ例を示す。なお、代替COAサブオプションは、キャッシュエントリを特定するために使用される。また、ホームアドレスオプションパラメータは前記の表３と同様である。
【００９１】
【表１４】
【００９２】
【表１５】
【００９３】
【表１６】
【００９４】
そして、図１５に示すように、キャッシュ通知の場合は、ＳＡフィールド７１７に上記のキャッシュ要求を受けたＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納され、ＤＡフィールド７１８にキャッシュ通知対象の通信中ＥＮ１２のアドレスが格納される。また、代替COAサブオプションの代替COAフィールド７２２には端末３のCOAが格納される。
【００９５】
これにより、本キャッシュ通知は、目的の通信中ＥＮ１２に到着し、そのＥＮ１２では、代替COAに格納されている端末３のCOAを自己のキャッシュとして保持することになる。なお、本メッセージが、「キャッシュ通知メッセージ」であることは、結合更新オプションにより識別でき、代替COAサブオプションを使用していれば（オプションタイプフィールド７２３ａが代替COAの存在を表示していれば）、ＳＡ以外をCOAとして使うことが分かる。従って、「キャッシュ」を作る際、検索キーについてはホームアドレスオプションフィールド７２４に設定された値を用い、COAについては代替COAフィールド７２２に設定された値（MN-COA）を用いることになる。
【００９６】
（５）キャッシュ削除要求／応答メッセージ
次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１（２１）へのキャッシュ削除要求には、図１６に示すパケットフォーマットを使用する。即ち、前記の結合更新オプションを使用する。また、キャッシュ削除対象の端末３のアドレスを通知するためにホームアドレスオプション（そのパラメータについては前記の表３参照）を使用する。次表１７にこの場合の結合更新オプション（キャッシュ削除要求）パラメータ例を示す。
【００９７】
【表１７】
【００９８】
そして、図１６に示すように、本キャッシュ削除要求メッセージの場合は、ＳＡフィールド７１７にＥＮ１２のアドレスが格納され、ＤＡフィールド７１８にＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納される。また、ホームアドレスフィールド７２４に、ＥＮ１２においてキャッシュを削除した端末３のホームアドレス（ＶＨＡ１０（２０）又はＴＨＡ１１（２１）での削除対象キャッシュを特定する検索キーとして用いられる）が格納される。
【００９９】
なお、本メッセージが「キャッシュ削除要求メッセージ」であることは、上記の表１７及びこの図１６に示すように、リザーブ（reserved）ビットフィールド７２８に“１(0x01)”、ライフタイム（Lifetime）フィールド７２９に“０”が設定されることによって表示される。
これにより、通信中ＥＮ１２が非通信中となり、該当キャッシュが削除されることに伴って、その削除したキャッシュの通知元であるＶＨＡ１０（２０）又はＴＨＡ１１（２１）に対して本キャッシュ削除要求メッセージが発行され、そのＶＨＡ１０（２０）又はＴＨＡ１１（２１）において、もはや保持しておく必要の無い情報が適切に削除されることになる。
【０１００】
なお、本キャッシュ削除要求メッセージを受けたＶＨＡ１０（２０）又はＴＨＡ１１（２１）は、キャッシュ削除要求応答メッセージをＥＮ１２に対して返信するが、このキャッシュ削除要求応答メッセージには、前記の結合応答オプション（パラメータについては前記の表４参照）を使用する。即ち、本メッセージには、図１０に示すものと同様のパケットフォーマットを使用する。
【０１０１】
そして、ＳＡフィールド７１７に受信パケット（キャッシュ削除要求メッセージ）のＤＡフィールド７１８に設定されていたアドレス〔つまり、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレス〕が格納され、ＤＡフィールド７１８に受信パケットのＳＡフィールド７１７に設定されていたアドレス（つまり、キャッシュ削除要求を発行した通信中ＥＮ１２のアドレス）が格納されることにより、通信中ＥＮ１２に対してキャッシュ削除を行なった旨が返信されて通知されることになる。
【０１０２】
(A3)システムの構成要素の詳細説明
次に、以下では、上記のＶＨＡ１０（２０），ＴＨＡ１１（２１），ＥＮ１２及び端末（ＭＮ）３を実現するためのそれぞれの構成について詳述する。なお、以下では、説明の便宜上、ＶＨＡ１０（２０），ＴＨＡ１１（２１），ＥＮ１２及びＭＮ３は、それぞれ、単にＶＨＡ，ＴＨＡ，ＥＮ，ＭＮと符号を略して表記する場合がある。また、これらを特に区別しない場合には、単に「ノード」と総称する場合もある。
【０１０３】
(A3.1)ＶＨＡ，ＴＨＡ，ＥＮの詳細説明
図２は上記のＶＨＡ１０（２０），ＴＨＡ１１（２１）及びＥＮ１２の要部の詳細構成を示すブロック図で、この図２に示すように、本実施形態において、ＶＨＡ１０（２０），ＴＨＡ１１（２１）及びＥＮ１２は、それぞれ、共通の構成を有しており、例えば、入力処理部４１，パケット種別識別部４２，バインディングキャッシュ検索部４３，結合（バインディング）キャッシュ（Binding Cache）テーブル４４，カプセル化処理部４５，ルータ処理部４６（ルーティングテーブル４６ａ，出方路決定部４６ｂ），出力処理部４８，タイマ処理部４９及び制御メッセージ処理部５０をそなえて構成されている。なお、この図２において、符号４３１はトラフィック種別識別部を表し、符号４３４はブリッジ部を表すが、これらの各部の機能についてはそれぞれ第２実施形態にて後述する。
【０１０４】
ここで、入力処理部４１は、到着（受信）パケットのＩＰレイヤ以下の処理を行なうためのもので、例えば、イーサネットであれば自ノード宛のＭＡＣ（Media Access Control）アドレスが付与されたパケットを取り込んで、そのパケットのフレーム自体の正常性をチェックする処理を行なう機能を装備するものである。
【０１０５】
また、パケット種別識別部４２は、この入力処理部４１で受信された正常なパケットの種別〔主に、制御メッセージ，マルチキャストパケット，これら以外のパケット等〕を、そのヘッダ部分（具体的には、ＤＡフィールド７１８）を参照して識別するためのもので、ここでは、上述した各種制御メッセージやマルチキャストパケットは制御メッセージ処理部５０へ、それ以外のパケットはバインディングキャッシュ検索部４３へそれぞれ引き渡されるようになっている。
【０１０６】
次に、図２に示す結合キャッシュテーブル（以下、単に「キャッシュテーブル」ともいう）４４は、基本的に、「MIPv6」ベースで作成される「キャッシュ」を端末３のホームアドレス（ＭＮホームアドレス）別にテーブル形式のデータとして保持するもので、例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによって構成される。ただし、このキャッシュテーブル４４は、ＶＨＡ／ＴＨＡにおけるものと、ＥＮにおけるものとで保持内容が若干異なる。
【０１０７】
即ち、ＶＨＡ／ＴＨＡのキャッシュテーブル４４には、例えば図４（Ａ）に示すように、“COA”（128ビット），“Lifetime”（32ビット），“Home registration flag”（1ビット），“router flag”（1ビット），“prefix length”（7ビット），“Sequence Number”（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”が切れない（“０”にならない）ように更新する機能を有するとともに、“Lifetime”が切れたときに、該当「キャッシュ情報」を削除する機能を有するものである。
【０１１６】
次に、制御メッセージ処理部５０は、パケット種別識別部４２で制御メッセージであると識別されて入力される制御メッセージに応じた処理を実施するためのもので、本実施形態では、例えば図２中に示すように、メッセージ種別判定部５１，モバイルメッセージ処理部５２，ルーティングメッセージ処理部５３及びルータ広告（RA：Router Advertise）メッセージ処理部５４をそなえて構成されている。ただし、このルータ広告メッセージ処理部５４は、ＥＮ１２に固有の機能で、ＶＨＡ１０（２０）やＴＨＡ１１（２１）には実装されていなくてもよい。
【０１１７】
ここで、上記のメッセージ種別判定部５１は、受信制御メッセージの種別を判定（識別）するためのもので、ここでは、上述したモバイルメッセージとそれ以外のルーティングメッセージとを判別して、モバイルメッセージについてはモバイルメッセージ処理部５２へ、ルーティングメッセージについてはルーティングメッセージ処理部５３へ振り分けられるようになっている。
【０１１８】
また、モバイルメッセージ処理部５２は、受信したモバイルメッセージの種別を判定してその種別に応じた処理を実施するためのもので、本実施形態では、そのメッセージ種別として、前述したように、主に、▲１▼結合更新（Binding Update）オプションを使用した結合更新メッセージ（ホーム／在圏位置登録メッセージ，キャッシュ更新メッセージ，キャッシュ削除要求メッセージ），▲２▼結合応答（Binding Ack）オプションを使用した結合応答メッセージ（ホーム／在圏位置登録応答メッセージ，キャッシュ通知メッセージ，キャッシュ削除応答メッセージ，キャッシュ更新応答メッセージ），▲３▼結合要求（Binding Request-M3）メッセージがある。
【０１１９】
このため、本モバイルメッセージ処理部５２は、例えば図３に示すように、結合更新（Binding Update）メッセージ処理部５２Ｃ，結合応答（Binding Acknowledge）メッセージ処理部５２Ｄ及び結合要求（Binding Request-M3）メッセージ処理部５２Ｅを有して構成されている。
ここで、上記の結合更新メッセージ処理部５２Ｃは、上記のメッセージ種別判定部５１から入力される結合更新メッセージに応じた処理を行なうためのもので、本実施形態では、例えば、結合キャッシュ（Binding Cache）テーブルアクセス部５２１，結合更新（Binding Update）メッセージ解析部５２２，結合応答（Binding 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），Ｍ３ネットワークアドレス（100.50）を抽出し（ステップＡ１）、まず、受信したＥＮアドレスと情報格納レジスタ３４１に保持されているＥＮアドレスとを比較して、一致しているか否かを判定する（ステップＡ２）。
【０１５３】
この場合、端末３は、同一ＥＮ“１”から「ルータ広告」を受信しているので、ＥＮアドレス（1.1）に変化は無い。従って、ルータ広告解析部３４１は、抽出したＥＮアドレス（1.1），ＴＨＡアドレス（10.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）と異なるアドレス（200.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-M3）メッセージ（Option Type=16）であるか否かをチェックする（ステップＢ７のＮｏルートからステップＢ９）。
【０１７０】
その結果、受信パケットがBR-M3メッセージである場合は、パケット種別識別部４２は、その受信パケットを制御メッセージ処理部５０へ転送し（ステップＢ１０のＹｅｓルートからステップＢ１１）、BR-M3メッセージでなければ、キャッシュ検索部４３に受信パケットを転送する。キャッシュ検索部４３は、このように転送されてきたパケットのＤＡフィールド７１８に設定されている宛先アドレスを検索キーとして、キャッシュテーブル４４を検索する（ステップＢ１０のＮｏルートからステップＢ１２）。
【０１７１】
この検索の結果、該当宛先アドレス（COA）がキャッシュテーブル４４に登録されていなければ、キャッシュ検索部４３は、宛先が見つからないので、ソフトウェア（図示省略）にパケットを引き渡し、当該ソフトウェアは、例えばICMP（Internet Control Message 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メッセージのＳＡと同一のキャッシュデータ（COA）〕が存在するかをチェックする（ステップＣ４のＹｅｓルートからステップＣ２５）。
その結果、キャッシュテーブル４４に該当「キャッシュ」が存在しなければ、テーブルアクセス部５２５は、そのまま処理を終える（ステップＣ２５のＮｏルート）一方、「キャッシュ」が存在すれば、「キャッシュ」に登録されているCOAを保持しておき、さらに、BR-M3メッセージのＳＡと同じ「通信中ＥＮアドレス」が該当するキャッシュエントリに存在するか否かを検索する（ステップＣ２５のＹｅｓルートからステップＣ２０）。
【０１９５】
この検索の結果、BR-M3メッセージのＳＡと同じ「通信中ＥＮアドレス」が存在すれば、テーブルアクセス部５２５は、その「通信中ＥＮアドレス」と保持しておいたCOAとを読み出し（ステップＣ２６）、結合要求メッセージ解析部５２６へ渡す。これにより、結合要求メッセージ解析部５２６は、受け取った情報（COA，「通信中ＥＮアドレス」）を結合更新メッセージ作成部５２７に転送して結合更新メッセージ（キャッシュ通知メッセージ）の作成を依頼する（ステップＣ２１のＹｅｓルートからステップＣ２３）。なお、上記のステップＣ２０において、「通信中ＥＮアドレス」が未登録であれば、その時点で、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（「PCOA」）の通知（登録）先を、同じＴＨＡに維持することができるので、従来のように移動に伴って位置登録先ＴＨＡの切り替えが頻繁に発生することも防止でき、高速ハンドオーバ性をさらに向上することができる。
【０２４９】
さらに、端末３による位置登録先ＴＨＡが端末３の移動に関わらず上述のごとく同じＴＨＡに維持される場合であっても、端末３のＴＨＡに対する現在位置の更新登録に応じて必要な「キャッシュ」が通信中ＥＮに逐次提供されて相互の同期がとられるので、通信中ＥＮは、パケット転送ルートを、ＴＨＡを経由しない新たな在圏ＥＮに到るルートに適切且つ迅速に変更することが可能である。従って、ＴＨＡの処理負荷をさらに抑制しながら高速ハンドオーバを実現することができる。
【０２５０】
また、端末３宛のパケットを受信したＥＮは、「キャッシュ」が無い場合にＶＨＡ／ＴＨＡへ必要な「キャッシュ」を要求するので、どのＥＮも、ＶＨＡ／ＴＨＡによるパケットルーティングを代替することができ、ＶＨＡ／ＴＨＡのパケットルーティングを代替するＥＮが１箇所に固定されず、特定のＥＮにパケットが集中してその負荷が増大することも無い。従って、この場合、ＥＮとＶＨＡ／ＴＨＡとの双方の負荷を軽減できることになる。
【０２５１】
さらに、このとき、ＶＨＡ／ＴＨＡは、「キャッシュ」の要求を受けたＥＮのみにキャッシュ情報を提供するので、不要な「キャッシュ」の転送を防止することができ、網内のトラフィック量の増大を抑制することも可能である。また、ＶＨＡ／ＴＨＡは、キャッシュテーブル４４に保持する「通信中ＥＮアドレス」によって、「キャッシュ」を更新／削除すべきＥＮを把握しておくので、新しいCOAの通知を受けた場合の該当通信中ＥＮの「キャッシュ」を誤ることなく更新できる。従って、パケットルーティングの信頼性、つまり、通信品質を向上することができる。
【０２５２】
さらに、通信中ＥＮでは、端末３宛のパケットを受信する毎に、上記の「キャッシュ」のライフタイム（有効期限）をリフレッシュするので、通信中に「キャッシュ」の有効期限が切れて正常な通信を維持できなくなることを回避することができ、さらに、パケットルーティングの信頼性、つまり、通信品質を向上することができる。
【０２５３】
また、通信中ＥＮは、通信が終了して上記の「キャッシュ」の有効期限が切れると、当該「キャッシュ」を削除するとともに、その「キャッシュ」を受けたＶＨＡ／ＴＨＡに対して該当「キャッシュ」の「通信中ＥＮアドレス」の削除を要求し、この要求を受けたＶＨＡ／ＴＨＡが、自己のキャッシュテーブル４４で保持している該当「通信中ＥＮアドレス」を削除するので、ＥＮ及びＶＨＡ／ＴＨＡにおいて不要な情報をいつまでも保持しておくことがなく、それぞれに必要なメモリ容量などを削減して、その小型化を図ることができる。
【０２５４】
(B)変形例の説明
上述した実施形態では、ローミング先において端末３が移動してＥＮアドレス及びＴＨＡアドレスに変化があっても、原則として、Ｍ３ネットワークアドレスに変化が無い限り、それらの変化を無視して、最初に位置登録を行なったＴＨＡに対してのみ位置登録を行なっているが、或る特定の条件（付加的条件）を満足した場合には、位置登録先のＴＨＡの切り替えを行なうようにすることも可能である。なお、「ＴＨＡの切り替え」とは、受信した「ルータ広告」に含まれるＴＨＡアドレス，ＥＮアドレスから新しく「VCOA」，「PCOA」を作成し、ＶＨＡにはホーム位置登録メッセージにより「VCOA」を、ＴＨＡには在圏位置登録メッセージにより「PCOA」を送信して各COAを登録することを意味する。
【０２５５】
以下では、その例について詳述する。ただし、以下の例では、例えば、図３０に示すように端末３がM3v6ネットワーク１からローミング先の他網（M3v6他ネットワーク）２へ移動してゆく状況を想定する。なお、この図３０において、端末３のホーム網１のアドレス（Ｍ３ネットワークアドレス）は、「100.50」、ローミング先のパケット網２のＭ３ネットワークアドレスは「200.50」、ＴＨＡ１１ａ，１１ｂ，２１ａ，２１ｂのアドレスは、それぞれ順に、「10.1」，「20.1」，「30.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」と遷移してゆく。
【０２５７】
また、Ｍ３ネットワークアドレスは、「100.50」→「100.50」→「100.50」→「200.50」→「200.50」→「200.50」→「200.50」→「200.50」と遷移してゆく。そして、このような移動に伴って、端末３で作成する「PCOA」は、「1.3」→「1.3」→「2.3」→「5.3」→「6.3」→「7.3」→「8.3」と遷移してゆき、「VCOA」は、「10.3」→「10.3」→「30.3」→「30.3」→「40.3」→「40.3」と遷移してゆくことになる。
【０２５８】
(B1)第１変形例（一定時間経過毎にＴＨＡの切り替え判断を行なう場合）
かかる状況を前提として、本第１変形例の端末３では、例えば図３１に示すように、パケット網２へローミングインした後、一定周期Ｔ毎に、ＴＨＡアドレスが変化しているか否かを判断する。そして、一定周期Ｔ経過時にＴＨＡアドレスが変化していれば、端末３は、そのときに初めて、位置登録先のＴＨＡをＴＨＡ２１ａからＴＨＡ２１ｂに切り替える。
【０２５９】
即ち、この例では、端末３は、ＴＨＡアドレスが変化した時点Ｔ１では、ＴＨＡの切り替えは行なわず、一定周期Ｔ経過時点Ｔ２において、初めて、その時のＥＮアドレス（＝「7.1」のプレフィックス部分（“７”）と自己のインタフェースＩＤ（＝“３”）との組み合わせにより、「PCOA」＝「7.3」を作成し、この「PCOA」をＴＨＡ２１ａではなくＴＨＡ２１ｂへ通知する（点線矢印９６参照）とともに、その時のＴＨＡアドレス（＝「40.1」）のプレフィックス部分（“４０”）と自己のインタフェースＩＤ（＝“３”）との組み合わせにより、「VCOA」＝「40.3」を作成して、この「VCOA」をホーム網１のＶＨＡ１０へ通知するのである（点線矢印９７参照）。
【０２６０】
このような動作は、例えば端末３のルータ広告メッセージ処理部３４Ｃの基本アルゴリズム（図２２に示すステップＡ１〜Ａ８）に、図３２に示すＴＨＡアドレスチェックアルゴリズム（ステップＡ９〜Ａ１３）及び図３３に示すフラグ設定アルゴリズム（ステップＡ１４〜Ａ１８）を付加することで実現できる。
即ち、この場合、図３３に示すように、端末３では、現時刻情報（nowtime）を読み出し（ステップＡ１４）、前回ＴＨＡアドレスチェック時刻情報（oldtime）を読み出し（ステップＡ１５）、これらの時刻情報の差分（nowtime−oldtime）が周期Ｔよりも大きいか否かをチェックする（ステップＡ１６）。
【０２６１】
そして、上記の各時刻情報の差分が時間情報（周期）Ｔよりも大きければ、一定周期Ｔが経過したことになるので、ＴＨＡアドレスフラグチェックフラグを“on”とし（ステップＡ１６のＹｅｓルートからステップＡ１７）、前回ＴＨＡアドレスチェック時刻情報（oldtime）を現時刻情報（nowtime）に更新して処理を終える（ステップＡ１８）。なお、上記の各時刻情報の差分が時間情報Ｔ以下であるときは、そのまま処理は終了する（ステップＡ１６のＮｏルート）。
【０２６２】
以上の処理（一定周期カウントアルゴリズム）を端末３は繰り返し実行することにより、一定周期Ｔ経過毎にＴＨＡアドレスチェックフラグを“on”に設定することになる。なお、上記の時刻情報（nowtime，oldtime），時間情報Ｔ，ＴＨＡアドレスチェックフラグは、それぞれ、情報格納レジスタ３４１に格納されるようにすればよい。
【０２６３】
かかる状態で、端末３（ルータ広告メッセージ処理部３４Ｃ）は、元のＴＨＡ２１ａ宛の在圏位置登録メッセージを発行してＴＨＡ２１ａへ位置登録を行なうと（ステップＡ８）、続いて、ＴＨＡアドレスチェックフラグが“on”になっているか否かをチェックし（ステップＡ９）、ＴＨＡアドレスチェックフラグが“off”になっていれば、その時点でＴＨＡアドレスが変化していても、現ＴＨＡアドレスは元のＴＨＡアドレスとし（ステップＡ９のＮｏルートからステップＡ１３）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６４】
これに対し、ＴＨＡアドレスチェックフラグが“on”になっていれば、次に、ルータ広告処理部３４Ｃは、「ルータ広告」に含まれるＴＨＡアドレスのプレフィックス部分が元のＴＨＡアドレス（例えば、情報格納レジスタ３４１に格納される）のプレフィックス部分と一致するか否かをチェックし（ステップＡ９のＹｅｓルートからステップＡ１０）、一致していれば、ＴＨＡアドレスに変化が無いので、この場合も、現ＴＨＡアドレスは元のＴＨＡアドレスとし（ステップＡ１０のＹｅｓルートからステップＡ１３）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６５】
一方、上記の各プレフィックス部分が一致していなければ、ＴＨＡアドレスが変化しているので、端末３（ルータ広告メッセージ処理部３４Ｃ）は、上述のごとく「PCOA」を新しいＴＨＡアドレスをもつＴＨＡ２１ｂへ在圏位置登録メッセージにより通知するとともに、「VCOA」をホーム網１のＶＨＡ１０へホーム位置登録メッセージにより通知して（ステップＡ１０のＮｏルートからステップＡ１１）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６６】
つまり、本変形例では、ゲートノード識別情報監視手段としての機能を果たすルータ広告解析部３４２が、上記のフラグ設定アルゴリズム（ステップＡ１４〜Ａ１８）およびＴＨＡアドレスチェックアルゴリズム（ステップＡ９〜Ａ１３）を実行することにより、所定の付加的条件下においてＴＨＡアドレスが変化したか否かを検知する条件付監視手段として構成されていることになる。
【０２６７】
そして、この場合、現在位置通知手段としての機能を果たす位置登録メッセージ作成部３４３が、上記ルータ広告解析部３４２にて上記の付加的条件下におけるＴＨＡアドレスの変化が検知されると、Ｍ３ネットワークアドレスに変化が無い場合であっても、変化後のＴＨＡアドレスによって識別される新たなＴＨＡに自己の現在位置情報（PCOA）を通知する条件付通知手段としての機能を有していることになる。
【０２６８】
このように、本第１変形例の場合は、一定周期Ｔ経過時にＴＨＡアドレスが変化しているという一定の条件を満足すると、位置登録先ＴＨＡの切り替えを行なうので、例えば、位置登録先ＴＨＡを維持することにより、端末３とＴＨＡとの距離が長距離になってしまった場合などにおいて、最寄りのＴＨＡが変化する毎に位置登録を行なう場合よりもその登録頻度を削減しながら、位置登録先ＴＨＡの最適化、つまり、ハンドオーバ時間の最適化を有効に図ることができる。
【０２６９】
(B2)第２変形例（非通信中にＴＨＡの切り替え判断を行なう場合）
次に、上述したＴＨＡの切り替え判断を、端末３の非通信中に行なう場合について説明する。
即ち、例えば図３４に示すように、「ルータ広告」に含まれるＴＨＡアドレスが「30.1」から「40.1」に変わった時点Ｔ３では、端末３は、まだ通信中であるため、ＴＨＡの切り替えを行なわない。その後、非通信中となった後（時点Ｔ４の後）で、「ルータ広告」を受信すると、上記の例と同様にして端末３はＴＨＡの切り替えを実行する（ＴＨＡ２１ｂに「PCOA」を通知し、ＶＨＡ１０に「VCOA」を通知する）。
【０２７０】
このような動作は、上記のＴＨＡアドレスフラグチェックを“on”にする契機だけが異なっているため、図３３に示すフラグ設定アルゴリズムに代えて、例えば図３５に示すように、通信中でないときにのみ（ステップＡ１９でＮｏと判定された場合にのみ）、ＴＨＡアドレスチェックフラグを“on”にする（ステップＡ２０）フラグ設定アルゴリズムを用いれば実現できる。なお、この図３５に示すアルゴリズムは、図３２に示すＴＨＡアドレスチェックアルゴリズムとは独立に、（例えば周期的に）起動される。
【０２７１】
このように、本第２変形例の場合は、位置登録先ＴＨＡの切り替えが必ず端末３の非通信中であるときに実施されるので、通信中の切り替え発生による通信品質の劣化は生じない。従って、通信品質の劣化を防止しながら、ハンドオーバ時間の最適化を図ることができる。
(B3)第３変形例（非通信中にＴＨＡの切り替え判断を行なう場合）
次に、上記のＴＨＡの切り替え判断を、トラフィック量が所定のしきい値以下であるときに行なう場合について説明する。
【０２７２】
即ち、例えば図３６に示すように、端末３において、その通信トラフィック量を監視しておき、ＴＨＡアドレスが変化してもその時のトラフィック量がしきい値を超えていれば、ＴＨＡの切り替え判断は行なわず（時点Ｔ５参照）、トラフィック量が所定のしきい値以下になって、初めてＴＨＡの切り替え判断を行なう（時点Ｔ６参照）。
【０２７３】
このような端末３の動作は、図３３に示すフラグ設定アルゴリズムに代えて、例えば図３７に示すように、監視したトラフィック量（例えば、情報格納レジスタ３４１に格納すればよい）を読み出し（ステップＡ２１）、そのトラフィック量がしきい値以下であるときにのみ（ステップＡ２２でＹｅｓと判定された場合にのみ）、ＴＨＡアドレスチェックフラグを“on”にする（ステップＡ２３）フラグ設定アルゴリズムを用いれば実現できる。なお、この図３７に示すアルゴリズムも、図３２に示すアルゴリズムとは独立に、（例えば周期的に）起動される。
【０２７４】
このように、本第３変形例の場合は、位置登録先ＴＨＡの切り替えが、必ず通信トラフィック量が所定値以下であるときに実施されるので、通信への影響（通信帯域の圧迫等）を最小限に抑制しながら、ハンドオーバ時間の最適化を図ることができる。
(B4)第４変形例（通信中トラフィックのタイプによってＴＨＡの切り替え判断を行なう場合）
次に、上記のＴＨＡの切り替え判断を、通信中トラフィックのタイプ（種別）によって行なう場合について説明する。
【０２７５】
即ち、例えば図３８に示すように、端末３が“http”，“VOIP”の２種のトラフィックタイプの通信を行なっており、“http”トラフィックが存在する間は、ＴＨＡアドレスに変化があっても、ＴＨＡの切り替え判断は行なわず（時点Ｔ７参照）、その後に、“http”トラフィックが無くなり、“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 Control）アドレスが付与されたパケットを取り込んで、そのパケットのフレーム自体の正常性をチェックする処理を行なう機能を装備するものである。
【０２９１】
また、パケット種別識別部４２Ａは、この入力処理部４１で受信された正常なパケットの種別（主に、自ノード宛のメッセージか他ノード宛のメッセージか）を、その宛先アドレス（ＤＡ）を参照して識別するためのもので、ここでは、自ノード宛のメッセージ（パケット）であれば制御メッセージ処理部５０Ａへ、他ノード宛のメッセージであれば、バインディングキャッシュ検索部４３Ａへそれぞれ転送されるようになっている。
【０２９２】
さらに、図４３において、結合（バインディング）キャッシュテーブル（以下、単に「キャッシュテーブル」という）４４Ａは、本実施形態においても、基本的に、「MIPv6」ベースで作成される「キャッシュ」をＭＮ３′のホームアドレス（ＭＮホームアドレス）別にテーブル形式のデータとして保持するもので、例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによって構成される。
【０２９３】
ここで、このキャッシュテーブル４４Ａには、この場合も、基本的に、“COA”（128ビット），“lifetime”（32ビット），“Home registration flag”（1ビット），“router flag”（1ビット），“prefix length”（7ビット），“Sequence Number”（16ビット），“Recent Usage Information”（1ビット），“last BR time”（128ビット）等のキャッシュデータが保持されるが、ＨＡにおいては、例えば図４４（Ｂ）に示すように、ＭＮホームアドレス毎に、「現在のＣＯＡ」とその有効期限を表す“lifetime1”に加えて、ＭＮの「通信開始時（過去）のＣＯＡ」とその有効期限を表す“lifetime2”も保持されるようになっている。
【０２９４】
つまり、本実施形態のキャッシュテーブル４４Ａは、ＭＮの移動に伴う複数のＣＯＡ（「現在のＣＯＡ」及び「通信開始時のＣＯＡ」）を保持する位置情報保持部４４Ａ−１としての機能と、少なくとも「通信開始時のＣＯＡ」の有効期限に関する情報（“lifetime2”）を記憶する有効期限情報記憶部４４Ａ−２としての機能とを果たしていることになる。
【０２９５】
ここで、例えば、図４４（Ａ）に模式的に示すように、ＨＡの通信エリア（在圏ゾーン）１００′に存在するＭＮが、ルータ「Ｒ１」の在圏ゾーン１３′−２，ルータ「Ｒ２」の在圏ゾーン１３′−１の順に移動する場合（点線矢印９７参照）を想定する。なお、各ノードのＩＰアドレスを、第１実施形態での表記法と同様に、ｘ（ネットワークＩＤ）．ｙ（ＭＮのインタフェースＩＤ）と表記することにして、ＨＡのネットワークＩＤを“１４４”、ルータ「Ｒ２」のネットワークＩＤを“２１１”、ルータ「Ｒ１」のネットワークＩＤを“１１２”とすると、ＨＡのアドレスは“144.y”、ルータ「Ｒ２」のアドレスは“211.y”、ルータ「Ｒ１」のアドレスは“112.y”と表される。
【０２９６】
そして、ＭＮのインタフェースＩＤ（ＭＮに固有の識別子）を“５０”とすると、ＭＮは、ルータ「Ｒ１」の在圏ゾーン１３′−２に移動してルータ「Ｒ１」に接続したときに、ＣＯＡ＝“112.50”を作成してＨＡに通知（位置登録）する。なお、この時点では、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」は登録されない。
【０２９７】
その後、ＭＮがルータ「Ｒ１」に接続した状態で通信を開始すると（つまり、ＨＡでＭＮ宛のパケットが受信されると）、ＨＡは、受信パケットの「トラフィック種別」を判断し、受信パケットがデータパケットであればそのときの「現在のＣＯＡ」及び“lifetime1”をコピーして、「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａに登録する。
【０２９８】
かかる状態で、ＭＮがさらに移動し、ルータ「Ｒ２」に接続すると、ＭＮは新しいＣＯＡ＝“211.50”を作成してＨＡに通知し、ＨＡでは「現在のＣＯＡ」＝「現在のＣＯＡ」を“112.50”から“211.50”に書き換える。なお、この際、「通信開始時のＣＯＡ」は変更されない（“112.50”のままである）。
ここまでの状態で、ＨＡのキャッシュテーブル４４Ａには、図４４（Ｂ）に示す登録内容をもつことになる。つまり、ＨＡのキャッシュテーブル４４Ａには、図４（Ｂ）に示すように、「現在のＣＯＡ」として“211.50”が保持され、「通信開始時のＣＯＡ」として“112.50”が保持されることになる。
【０２９９】
なお、上記の“lifetime1”及び“lifetime2”は、いずれも、対応するＣＯＡ宛のパケットを受信しない間、定期的に減算され、最終的にその値が“０”になると（つまり、有効期限が切れると）、対応するＣＯＡ（キャッシュ）が削除される。ただし、対応するＣＯＡ宛のパケットを受信している間は、そのＣＯＡを維持する必要があるので、パケット受信毎に“lifetime2”は“０”にならないよう予め決められた初期値等にリフレッシュ（更新）される。“lifetime1”の更新契機は、第１実施形態と同様である。これらの有効期限の更新はタイマ処理部４９Ａによって実施される。
【０３００】
次に、バインディングキャッシュ検索部（以下、単に「キャッシュ検索部」ともいう）４３Ａは、入力パケットのＩＰヘッダ７０（図７参照）に含まれる宛先アドレスを検索キーとして、上記のキャッシュテーブル４４Ａを検索してカプセル化処理部４５でのカプセル化に必要な情報（ＣＯＡ等）を取得することができるものである。
【０３０１】
ただし、本実施形態のＨＡにおけるキャッシュ検索部４３Ａは、主として、次のような各機能を兼ね備えている。
▲１▼受信パケットの種別（例えば、トラフィック種別）を識別するトラフィック（パケット）種別識別部４３１としての機能
▲２▼「現在のＣＯＡ」及び“lifetime2”をそれぞれコピーして、「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａに登録しうるコピー登録部４３２としての機能
▲３▼このトラフィック種別識別部４３１による識別結果（受信パケットのトラフィック種別）に応じて、キャッシュテーブル４４Ａにおける上記の「現在のＣＯＡ」及び「通信開始時のＣＯＡ」のいずれか一方を、カプセル化処理部４５でのカプセル化に使用するＣＯＡとして選択するＣＯＡ選択部（選択手段）４３３としての機能
ここで、上記の「トラフィック種別」の例としては、▲１▼或る程度のパケットロスが許容される特性をもつ音声パケット〔例えば、ＶＯＩＰ（Voice Over Internet Protocol）パケット〕や▲２▼或る程度のパケット転送遅延が許容される特性をもつデータパケット〔例えば、ｈｔｔｐ（hyper text transfer protocol）データパケットやｆｔｐ(file transfer protocol)データパケット等〕があり、これらはＩＰヘッダ７０（標準ヘッダ７１；図７参照）に含まれるtos（タイプ・オブ・サービス）フィールド〔「トラフィッククラス」フィールド７１２（図８参照）〕の値をそれぞれについて定義しておくことで識別することが可能である。なお、このように、「トラフィック種別」の識別にtos値を用いるのが、最も簡便な手法であり、ＨＡの小型化も期待できる。
【０３０２】
具体的には、例えば、音声パケットは図４５に示すようなフォーマットを有しており、ｆｔｐデータパケットは図４６に示すようなフォーマットを有しているが、これらの図４５及び図４６において、「トラフィッククラス」フィールド７１２に、それぞれ音声パケット及びｆｔｐデータパケットを表す値を設定しておけば、これらのパケットの「トラフィック種別」（以下、「パケット種別」ともいう）をトラフィック種別識別部４３１において識別できることになる。
【０３０３】
つまり、この場合のトラフィック種別識別部４３１は、受信パケットの「トラフィック種別」が少なくともパケットロスを許容する特性をもつトラフィック種別及びパケット転送転送遅延を許容する特性をもつトラフィック種別のいずれであるかを識別するパケットロス／転送遅延特性識別部として機能することになる。
【０３０４】
なお、上記の「トラフィッククラス」フィールド７１２の値（tos値）は、例えば、ＭＮと網管理者との間で予め取り決めを交わしておき、ＭＮがパケットを生成するときにその取り決めに従ってＭＮ側で設定してもよいし、予め網管理者と取り決めを交わしておき、パケットが流入してくる網１′の入口（エッジルータ）にポリシー制御機能を導入し、そのルータにおいて、全受信パケットにつき、送信元アドレス（ＳＡ），宛先アドレス（ＤＡ），使用プロトコル，送信（発信）元ポート番号，宛先ポート番号をチェックして「トラフィック種別」を識別し、tos値をその識別結果に応じた適切な値（トラフィック識別情報）に書き換えた（設定した）上で網１′内（ＨＡ宛）にパケットを転送（ルーティング）するようにしてもよい。
【０３０５】
後者の場合には、ＭＮにおいて送信パケットのtos値を独自にセットする必要が無く、ＨＡは、受信パケットに上記エッジルータにて設定し直されたtos値に基づいて「トラフィック種別」の識別が可能となるので、ＭＮの処理能力に余裕をもたせることが可能である。なお、エッジルータでの「トラフィック種別」の識別結果は、勿論、パケットの「トラフィッククラス」フィールド７１２以外の部分に設定するようにしてもよい。
【０３０６】
また、図４５及び図４６において、上記の「送信元アドレス（ＳＡ）」はＳＡフィールド７１７に表示され、「宛先アドレス（ＤＡ）」はＤＡフィールド７１８に表示され、「使用プロトコル」は「ネクストヘッダ」フィールド（プロトコルフィールド）７１５に表示〔例えば、ＴＣＰ（Transmission Control Protocol）なら“６”，ＵＤＰ（User Datagram Protocol）なら“１７”等〕される。
【０３０７】
同様に、「送信元ポート番号」はＴＣＰヘッダ７４又はＵＤＰヘッダ７６の発信元ポート番号フィールド７６１に表示され、「宛先ポート番号」は同じくＴＣＰヘッダ７４又はＵＤＰヘッダ７６の宛先ポート番号フィールド７６２に表示される。
なお、このように網１′の入口（エッジルータ）にポリシー制御機能を導入しない場合は、例えば、ＶＯＩＰを使用する音声パケットは、通常、ＩＰの上位レイヤにＲＴＰ（Real-time Transport Protocol）を用いるので、ＲＴＰヘッダ７７（図４５参照）を検出することにより、受信パケットが音声パケットであることを識別できる。
【０３０８】
ここで、ＲＴＰの音声符号化の種別は、ペイロードタイプフィールド７７１に表示され、図４５には、音声パケットの一例として、ペイロード８０（２４バイト）に格納される音声データの音声符号化にG.723（dual rate speech corder for multimedia communications transmittimg at 5.3 and 6.3kbit/s）（ペイロードタイプ＝４）を用いた場合のパケットフォーマットを示している。
【０３０９】
また、受信パケットの「トラフィック種別」は、ＭＮ側で使用するアプリケーションによって使用ポート番号が異なる場合には、上記のポート番号フィールド７６１，７６２に表示されている値から識別することもできる。
さらに、上記のプロトコルフィールド７１５には、上位アプリケーションの種別が表示されているので、その値により受信パケットの「トラフィック種別」を識別することもでき、また、音声パケット等のリアルタイムトラフィックには通常パケット長が短いという特徴があるので、パケット長（「ペイロード長」フィールド７１４）の値から「トラフィック種別」を識別することも可能である。
【０３１０】
さらに、「IPv4」のパケットであれば、そのヘッダに含まれる識別子（Identification）フィールドの値を「トラフィック種別」の識別に使用することも可能である。
そして、ＨＡにおけるキャッシュ検索部４３Ａは、相手（宛先）ＭＮの現在位置を知らないためにＭＮホームアドレスを宛先アドレス（ＤＡ）として送信されたパケットの当該ＭＮホームアドレスを検索キーとして上記のキャッシュテーブル４４Ａを検索し、カプセル化処理部４５でのカプセル化に用いるＣＯＡとして、上述したごとくトラフィック種別識別部４３１によって識別される「トラフィック種別」に応じてＣＯＡ選択部４３３が「現在のＣＯＡ」及び「通信開始時のＣＯＡ」のいずれかを選択的に取得することになる。
【０３１１】
即ち、本実施形態のＣＯＡ選択部４３３は、例えば、受信パケットが或る程度のパケットロスを許容する特性をもつ音声（ＶＯＩＰ）パケットである場合、キャッシュ検索部４３Ａは、キャッシュテーブル４４Ａを検索して、受信パケットのＭＮホームアドレスに対応する「現在のＣＯＡ」を選択する一方、受信パケットが或る程度のパケット転送遅延を許容する特性をもつデータパケットである場合は、ＭＮホームアドレスに対応する「通信開始時のＣＯＡ」（ただし、登録されていれば）を選択する端末位置情報選択部として機能するようになっているのである。
【０３１２】
次に、カプセル化処理部４５は、ＣＯＡ選択部４３３で選択されたＣＯＡを用いてキャッシュ検索部４３Ａから転送されてくる受信パケットをカプセル化するものであり、ルータ処理部４６（ルーティングテーブル４６ａ，出力方路決定部４６ｂ），出力処理部４８は、図２により前述したものとそれぞれ同様の機能を有するもので、出方路決定部４６ｂが、ルーティングテーブル４６ａを検索して、出力すべき物理インタフェースや下位レイヤでの宛先アドレス等を決定し、出力処理部４８が、例えば、イーサネットの場合にはイーサネットフレームに必要なフレームチェックシーケンス符号を付けて、パケット（フレーム）送出を行なうようになっている。
【０３１３】
従って、本実施形態のカプセル化処理部４５では、ＣＯＡ選択部４３３で選択されたＣＯＡを用いてキャッシュ検索部４３Ａから転送されてくる受信パケットをカプセル化することになり、ルータ処理部４６では、出方路決定部４６ｂが、このようにカプセル化されたパケット（トンネルパケット）のヘッダ（カプセルヘッダ）の宛先情報（「現在のＣＯＡ」又は「通信開始時のＣＯＡ」）に基づいてルーティングテーブル４６ａのルーティング情報を検索して当該トンネルパケットの出力インタフェースを決定して、決定した出力インタフェースへ当該トンネルパケットを出力することになる。
【０３１４】
つまり、本実施形態のルータ処理部４６は、ＣＯＡ選択部４３３で選択されたＣＯＡに基づいて受信パケットをルーティングするルーティング手段として機能することになる。
これにより、音声パケットについては、例えば図４７に模式的に示すように、ＭＮから結合更新（Binding Update）メッセージにより登録（点線矢印２３ａ参照）される「現在のＣＯＡ」、つまり、ＭＮの最新のＣＯＡ（ＣＯＡ２＝211.50）でカプセル化されてルーティングされることになるので、ＭＮが現在接続しているルータ「Ｒ２」までのパケット転送ルートが最適化されて（実践矢印２２，２３参照）パケット転送遅延が最小となる。
【０３１５】
一方、データパケットの場合は、「通信開始時のＣＯＡ」（ＣＯＡ１＝112.50）でカプセル化されてルーティングされることになるので、例えば図４８に模式的に示すように、ＭＮが通信継続中は通信開始時に接続していたルータ（以下、旧ルータという）「Ｒ１」に対して「スムースハンドオフ指示」を発行して旧ルータ「Ｒ１」に「現在のＣＯＡ」（ＣＯＡ２＝211.50）を登録する（点線矢印２４参照）ことにより旧ルータ「Ｒ１」からのパスを現在接続しているルータ「Ｒ２」まで伸ばしておく（実線矢印２６参照）ことで、ＨＡから旧ルータ「Ｒ１」までのパケット転送ルートは維持される（実線矢印２５参照）ことになり、ＨＡでパケット転送先をルータ「Ｒ１」から「Ｒ２」に切り替える場合（図４７の場合）に比して、パケットロスを最小限に抑制することが可能となる。
【０３１６】
このように、本実施形態のＨＡは、受信パケットの「トラフィック種別」に応じて、受信パケットのカプセル化に用いるＣＯＡを使い分けることにより、ＭＮに対するハンドオーバの仕組み（方法）を変える（切り替える）ことができるようになっているのである。なお、以下では、上記の各ハンドオーバ方法のうち、前者（ＶＯＩＰパケットについてのハンドオーバ方法）を第１のハンドオーバ方法、後者（データパケットについてのハンドオーバ方法）を第２のハンドオーバ方法ということがある。
【０３１７】
次に、図４３において、タイマ処理部４９Ａは、上述したキャッシュテーブル４４Ａにおける“lifetime1”，“lifetime2”を更新する機能、即ち、入力処理部４１でＭＮホームアドレスを宛先アドレス（ＤＡ）とするパケットが受信されない間は“Lifetime1”,“lifetime2”をそれぞれデクリメントし、パケットが受信されている間は“Lifetime1”,“lifetime2”が切れない（“０”にならない）ように更新（リフレッシュ）する有効期限リフレッシュ部４９１としての機能を有するとともに、“Lifetime1”,“lifetime2”が切れたときに、該当ＣＯＡを削除するＣＯＡ（端末位置情報）削除部４９２としての機能を有するものである。
【０３１８】
また、制御メッセージ処理部５０Ａは、パケット種別識別部４２Ａにおいて自ノード宛のメッセージであると識別された(制御)メッセージを受けて、そのメッセージを処理するためのものである。このため、本制御メッセージ処理部５０Ａには、図４３中に示すように、メッセージ種別判定部５１Ａ，モバイルメッセージ処理部５２Ａ，ルーティングメッセージ処理部５３及びルータ広告メッセージ（ＲＡ）処理部５４が設けられている。
【０３１９】
ここで、上記のメッセージ種別判定部５１Ａは、受信制御メッセージの種別を判定（識別）するためのもので、モバイルメッセージ（結合更新／応答メッセージ）とそれ以外のルーティングメッセージとを判別して、モバイルメッセージについてはモバイルメッセージ処理部５２Ａへ、ルーティングメッセージについてはルーティングメッセージ処理部５３へそれぞれ振り分けられるようになっている。
【０３２０】
また、モバイルメッセージ処理部５２Ａは、受信したモバイルメッセージの種別を判定（解析）してそのメッセージ内容に応じた処理（キャッシュテーブル４４Ａへの情報登録や削除）を行なうためのもので、本実施形態では、そのメッセージ種別として、主に、▲１▼前記の結合更新（Binding Update）オプションを用いた結合更新（Binding Update）メッセージ〔位置登録メッセージ（スムースハンドオフ指示メッセージ）〕，▲２▼前記の結合応答（Binding Acknowledgement）オプションを用いた結合応答（Binding Acknowledgement）メッセージ（位置登録応答メッセージ）等がある。ただし、前者▲１▼のメッセージはＭＮからＨＡ（旧ルータ１３′）宛に送信されるメッセージであり、後者▲２▼のメッセージは、ＨＡ（旧ルータ１３′）から位置登録メッセージ送信元のＭＮ宛に送信されるメッセージである。
【０３２１】
そして、具体的に、このモバイルメッセージ処理部５２Ａは、ＭＮからの位置登録メッセージ（スムースハンドオフ指示メッセージ）を受信すると、そのメッセージに含まれるＣＯＡを「現在（最新）のＣＯＡ」として前記のキャッシュテーブル４４Ａの該当領域（ＭＮホームアドレスに対応する領域）に登録（更新）するようになっている。
【０３２２】
ただし、ＨＡにおけるモバイルメッセージ処理部５２Ａは、受信パケットがデータパケットである場合に、「通信開始時のＣＯＡ」がキャッシュテーブル４４Ａに未だ登録されていない場合には、その時の「現在のＣＯＡ」及び“lifetime 1”をコピーして「通信開始時のＣＯＡ」及び“lifetime 2”として登録することができるようにもなっている。
【０３２３】
つまり、図４３において、キャッシュテーブル４４Ａ，タイマ処理部４９Ａ及びモバイルメッセージ処理部５２Ａから成る部分は、ＭＮの移動に伴う複数のＣＯＡ（端末位置情報）を管理する端末位置管理手段として機能するのである。
なお、図４３に示すルーティング処理部５３及びＲＡ処理部５４は、それぞれ、図２により前述したものと同様のものであり、ＲＩＰ（Routing Information Protocol）等のルーティングメッセージについての処理（例えば、網構成の変更等に伴うルーティング情報の更新等）がルーティングメッセージ処理部５３によって実施され、在圏ＭＮに対するルータ広告がルータ広告メッセージ処理部５４によって発行されるようになっている。
【０３２４】
以下、上述のごとく構成された本第２実施形態のパケット網１′におけるハンドオーバ方法（ＨＡの動作）について詳述する。ただし、以下では、説明の便宜上、受信パケットの「トラフィック種別」の識別に、前記のtos値を用いることを前提とする（例えば、tos=0で音声（ＶＯＩＰ）パケット、tos=1でデータパケットを表すものとする）。
【０３２５】
まず、ＨＡでは、図５０に示すように、パケットが入力処理部４１において受信されると（ステップＨ１）、その受信パケットの正常性がチェックされたのち、パケット種別識別部４２Ａにおいて受信パケットが制御メッセージであるか否かが判定される（ステップＨ２,Ｈ３）。
その結果、受信パケットが制御メッセージであれば、その制御メッセージは、制御メッセージ処理部５０Ａのメッセージ種別判定部５１Ａに転送され、メッセージ種別判定部５１Ａにおいて、さらに、その制御メッセージがモバイルメッセージ（結合更新／応答メッセージ）であるか否かが判定される（ステップＨ３のＹｅｓルートからステップＨ４，Ｈ５）。
【０３２６】
この結果、受信制御メッセージがモバイルメッセージであれば、そのモバイルメッセージはモバイルメッセージ処理部５２Ａへ転送され、モバイルメッセージ処理部５２Ａは、受信モバイルメッセージが結合更新メッセージ（つまり、位置登録メッセージ）であれば、そのメッセージに含まれるＣＯＡがＭＮの「現在のＣＯＡ」としてキャッシュテーブル４４Ａの該当領域に登録する（ステップＨ５のＹｅｓルートからステップＨ７）。なお、受信モバイルメッセージが結合応答メッセージであった場合、モバイルメッセージ処理部５２Ａは、そのメッセージ内容を解析して必要に応じて内部パラメータの変更等を行なう。
【０３２７】
ところで、パケット種別識別部４２Ａにおいて、受信パケットが制御メッセージでないと判定された場合（ステップＨ３でＮｏと判定された場合）、その受信パケットはキャッシュ検索部４３Ａに転送され、図５１に示すように、キャッシュ検索部４３Ａは、受信パケットの宛先アドレス（ＭＮホームアドレス）を検索キーとしてキャッシュテーブル４４Ａを検索し、ＭＮホームアドレスに対応するＣＯＡ（「現在のＣＯＡ」及び「通信開始時のＣＯＡ」）を取得する（ステップＨ８）。
【０３２８】
さらに、キャッシュ検索部４３Ａ（トラフィック種別識別部４３１）は、パケット種別識別部４２Ａから転送されてきたパケットのtos値をチェックすることにより、そのパケット種別（音声パケットかデータパケットか）を識別（判定）する（ステップＨ９,Ｈ１０）。
この結果、tos値が“０”で受信パケットが音声（ＶＯＩＰ）パケットであった場合（ステップＨ１０でＹｅｓの場合）、キャッシュ検索部４３Ａは、ＣＯＡ選択部４３３によって、カプセル化に使用するＣＯＡとして上記のステップＨ８で取得したＣＯＡのうち「現在のＣＯＡ」を選択する（ステップＨ１１）。
【０３２９】
これに対し、tos値が“１”で受信パケットが（ｆｔｐ）データパケットであった場合（ステップＨ１０でＮｏの場合）、キャッシュ検索部４３Ａは、上記のステップＨ８で取得したＣＯＡに「通信開始時のＣＯＡ」が含まれている（つまり、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」が既に登録されている）か否かをチェックする（ステップＨ１２）。
【０３３０】
その結果、未だ「通信開始時のＣＯＡ」が登録されていなければ（ステップＨ１２でＮｏであれば）、上記受信パケットがＭＮ宛の第１パケットである、即ち、この時点が「通信開始時」であることを意味するので、キャッシュ検索部４３Ａは、ＣＯＡ選択部４３３によって、上記第１パケットのカプセル化に使用するＣＯＡとしてこの時点では「現在のＣＯＡ」を選択したのち（ステップＨ１３）、コピー登録部４３２によって、その「現在のＣＯＡ」及び“lifetime1”をコピーして「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａの該当領域に登録する（ステップＨ１４）。
【０３３１】
以降は、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」が登録されているので、同じＭＮ宛の受信パケット（第２パケット以降）については、カプセル化に使用するＣＯＡとして、「通信開始時のＣＯＡ」が選択されることになる（ステップＨ１２のＹｅｓルートからステップＨ１５）。なお、この際、通信中に「通信開始時のＣＯＡ」が有効期限切れになり削除されてしまわぬように、“lifetime2”がタイマ処理部４９Ａ（有効期限リフレッシュ部４９１）によってリフレッシュされる（ステップＨ１６）。
【０３３２】
さて、上述のごとくステップＨ１１,Ｈ１３又はＨ１５においてキャッシュ検索部４３Ａ（ＣＯＡ選択部４３３）によって選択された「現在のＣＯＡ」又は「通信開始時のＣＯＡ」は、受信パケットとともにカプセル化処理部４５へ転送され、カプセル化処理部４５は、そのＣＯＡで受信パケットをカプセル化してルータ処理部４６へ転送する（ステップＨ１７）。
【０３３３】
これにより、カプセル化されたパケット（トンネルパケット）は、出方路決定部４６ｂにおいて、ルーティングテーブル４６ａのルーティング情報に基づいてその出力インタフェースが決定されたのち、出力処理部４８を通じて決定した出力インタフェースへ送信される（ステップＨ１８）。即ち、ＶＯＩＰパケットは「現在のＣＯＡ」に該当するルータ（ＭＮが現在接続しているルータ）１３′へ向けてルーティングされ、データパケット（第２パケット以降）は「通信開始時のＣＯＡ」に該当する旧ルータ１３′へルーティングされることになる。
【０３３４】
以上のようなＨＡでの動作を前提とすることにより、例えば図４９（Ａ）に示すように、ＭＮが相手端末ＣＮ（Corresponding Node）とルータ「Ｒ３」,ＨＡ,ルータ「Ｒ１」経由で音声通話している（このとき、ＨＡは音声パケットを「現在のＣＯＡ」（112.50）宛にカプセル化して転送している）状態（実線矢印２２,２３′参照）で、ＭＮが通信を継続しながらルータ「Ｒ２」の在圏ゾーンへ移動したとすると（矢印２７参照）、ＨＡはＭＮから登録された最新のＣＯＡ（211.50）で相手端末ＣＮからの音声パケットをカプセル化して転送する（第１のハンドオーバ方法を実行する）ことになる（実線矢印２３参照）。
【０３３５】
一方、例えば図４９（Ｂ）に示すように、ＭＮが相手端末ＣＮ（Corresponding Node）とルータ「Ｒ３」,ＨＡ,ルータ「Ｒ１」経由でデータ通信している（このとき、ＨＡはデータパケットを「現在のＣＯＡ」（112.50）宛にカプセル化して転送している）状態（実線矢印２２参照）で、ＭＮがデータ通信を継続しながらルータ「Ｒ２」の在圏ゾーンへ移動したとすると（矢印２８参照）、ＨＡは「通信開始時のＣＯＡ」（112.50）で相手端末ＣＮからのデータパケットを引き続きカプセル化して転送する（第２のハンドオーバ方法を実行する）ことになる（実線矢印２５参照）。
【０３３６】
この場合、ＭＮがルータ「Ｒ２」の在圏ゾーンに移動した時点で、ＭＮの「スムースハンドオフ指示」により旧ルータ「Ｒ１」に「現在のＣＯＡ」（211.50）が登録される（点線矢印２４参照）ので、旧ルータ「Ｒ１」は、ＨＡから「通信開始時のＣＯＡ」（112.50）宛に送られてきたパケットを「スムースハンドオフ指示」により登録されたＣＯＡ（211.50）で再カプセル化（スムースハンドオフ）して、ＭＮが現在接続しているルータ「Ｒ２」へ転送する（実線矢印２６参照）。
【０３３７】
なお、「スムースハンドオフ指示」を受けることによりスムースハンドオフを実行するルータ（ノード）１３′のことを「アンカーポイント」という。この「アンカーポイント」は、ＭＮの通信が一旦終了した場合は解除され（「スムースハンドオフ指示」によりＭＮから登録されたＣＯＡが削除され）、次にＭＮが通信を開始して「スムースハンドオフ指示」を新たに発行したルータ１３′が新たな「アンカーポイント」となる。
【０３３８】
以上のように、本実施形態によれば、ＨＡにおいて、ＭＮの移動に伴う複数のＣＯＡ（現在のＣＯＡ及び通信開始時のＣＯＡ）を管理しておき、ＭＮ宛のパケット種別を識別し、識別したパケット種別に応じて上記のＣＯＡのいずれかを選択（つまり、カプセル化ヘッダの宛先を変更）して、そのＣＯＡに基づいて受信パケットをルーティングすることにより、受信パケットの種別に応じてハンドオーバ方法を切り替えることができるので、ユーザが要求する複数種類の通信サービス品質（ＱｏＳ：Quality of Service）を満足する通信を柔軟に実現でき、常にユーザの要求に最適なハンドオーバ方法を提供してＱｏＳを大幅に向上させることが可能である。
【０３３９】
特に、本実施形態では、ＨＡにおいて、受信パケットが音声パケットであればＭＮの「現在のＣＯＡ」を選択することにより、パケット転送遅延を最小限に抑制したハンドオーバを実施することができ、受信パケットがデータパケットであれば、ＭＮの「通信開始時のＣＯＡ」を選択することにより、パケットロスを最小限に抑制したハンドオーバを実施することができるので、ＭＮのユーザが利用する音声通話サービス，データ通信サービス等に応じた最適なハンドオーバ方法を提供することができるのである。
【０３４０】
また、本実施形態のＨＡでは、「通信開始時のＣＯＡ」の“lifetime2”を記憶しておき、ＭＮ宛の受信パケットを受信する毎にその“lifetime2”をタイマ処理部４９（有効期限リフレッシュ部４９１）がリフレッシュするので、データパケット通信継続中に「通信開始時のＣＯＡ」が無効になることを防止することができ、当該データパケット通信の信頼性も向上している。
【０３４１】
さらに、上記のタイマ処理部４９は、「通信開始時のＣＯＡ」の“lifetime2”が切れると、その「通信開始時のＣＯＡ」を位置情報削除部４９２が削除するので、「通信開始時のＣＡＯ」の記憶に必要な記憶容量を最小限に抑制して、ＨＡの小型化にも大きく寄与している。
また、本実施形態のＭＮは、データパケットを受信している間、通信開始時に接続していたルータ１３′（アンカーポイント）に対して「スムースハンドオフ指示」を発行するので、「スムースハンドオフ指示」を受けたルータ１３′からＭＮが現在接続しているルータ１３′まで通信パス（パケット転送ルート）を伸ばしておくことができ、ハンドオーバに伴うパケットロスを最小限に抑制することが可能である。
【０３４２】
(D1)第２実施形態の第１変形例の説明
さて、上述した第２実施形態では、「通信開始時のＣＯＡ」をパケットの宛先（ＭＮホームアドレス）毎でしか管理していないので、同一宛先のデータパケットに対しては、全て、同一の転送ルートとなるようにＨＡにてカプセル化が行なわれることになる。
【０３４３】
このため、例えば、ＭＮ宛にある発信者が既にデータパケットの送信を行なっている状態で、別の発信者がＭＮ宛にデータパケットを新たに送信しはじめると、ＭＮが別のルータ１３′の在圏ゾーンに移動した場合でも、そのデータパケットは、既存の発信者が送信したデータパケットのカプセル化に使用したものと同じ「通信開始時のＣＯＡ」でカプセル化されてしまい、既存の発信者が送信したデータパケットのパケット転送ルート（スムースハンドオフによるルート）と全く同じルートで転送されるという非効率な事態が生じる。
【０３４４】
そこで、本変形例では、宛先（ＭＮホームアドレス）毎に加えて、受信パケットの発信元（送信元アドレス：ＳＡ）毎にも「通信開始時のＣＯＡ」を管理することにより、発信元毎にデータパケットのパケット転送ルートを変えられるようにして、発信者毎に、常に最短のアンカーポイント〔スムースハンドオフによるパケット転送を行なうルータ（ノード）〕をとることができるようにする。
【０３４５】
これは、例えば図５２（Ｂ）に示すように、キャッシュテーブル４４Ａを、
ＭＮホームアドレス毎に「現在のＣＯＡ」,その有効期限を示す“lifetime1”及びＭＮホームアドレスを一意に表すＩＤの組が登録・管理されるキャッシュテーブル４４１（Biding Cache1）と、上記ＩＤと受信パケットの送信元アドレス（ＳＡ）との組み合わせ毎に「通信開始時のＣＯＡ」及びその有効期限を示す“lifetime2”の組が登録・管理されるキャッシュテーブル４４２（Binding Cache 2）とにより構成することで実現できる。
【０３４６】
そして、本変形例においても、図４４（Ａ）と同様に、ＨＡのネットワークＩＤを“１４４”、ルータ「Ｒ２」のネットワークＩＤを“２１１”、ルータ「Ｒ１」のネットワークＩＤを“１１２”とすると、ＨＡのアドレスは“144.y”、ルータ「Ｒ２」のアドレスは“211.y”、ルータ「Ｒ１」のアドレスは“112.y”と表され、ＭＮのインタフェースＩＤを“５０”とすると、ＭＮは、ルータ「Ｒ１」の在圏ゾーン１３′−２に位置する時はＣＯＡ＝“112.50”、ルータ「Ｒ２」の在圏ゾーン１３′−１に位置する時はＣＯＡ＝“211.50”を作成して、それぞれ、ＨＡに通知（位置登録）することになる。
【０３４７】
従って、仮に、ＭＮがルータ「Ｒ１」の在圏ゾーン１３′−２に位置する時にそのルータ「Ｒ１」に接続して、ルータ「Ｒ３」に接続している相手端末「ＣＮ１」（仮に、送信元アドレス＝70.21とする）とデータ通信を開始したとすると、ＨＡのキャッシュテーブル４４２には、図５２（Ｂ）に示すように、相手端末「ＣＮ１」との「通信開始時のＣＯＡ」として“112.50”が登録されることになる。
【０３４８】
また、その後に、ＭＮがルータ「Ｒ２」の在圏ゾーン１３′−１に位置する時に、そのルータ「Ｒ２」に接続して、ルータ「Ｒ４」に接続している別の相手端末「ＣＮ２」（仮に、送信元アドレス＝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=VCOA1，PCOA=PCOA2）、その後、通信を継続しながら別の階層化ノード「ＭＡ２」が管轄する基地局ノード「ＢＳ３」の在圏ゾーンへ移動した場合（VCOA=VCOA2，PCOA=PCOA3）を示しており、この場合、ＨＡでは、「現在のＣＯＡ」として“VCOA2”を保持し、「通信開始時のＣＯＡ」として“VCOA1”を保持することになる。
【０３７４】
これにより、ＨＡでは、例えば、受信パケットがＶＯＩＰパケットであればその受信パケットを「現在のＶＣＯＡ（＝VCOA2）」でカプセル化し、データパケットであれば「通信開始時のＶＣＯＡ（＝VCOA1）」でカプセルすることで、階層化ノード（ＭＡ１，ＭＡ２）をまたぐハンドオーバを行なう際に、パケット種別に応じたハンドオーバ方法（パケット転送ルート）の切り替えが可能となる（ＶＯＩＰパケットの場合は図６１に矢印８６〜８８に示すパケット転送ルート、データパケットの場合は図６１に示す矢印８６，８９，９０に示すパケット転送ルートとなる）。
【０３７５】
一方、階層化ノード（ＭＡ）に、同様のハンドオーバ方法の切り替えを適用するには、ＭＡの「BindingCache」として登録されるのが、「VCOA」をキーとした「PCOA」であり、ＭＮの基地局ノードをまたぐ移動によりＭＮから新たな「PCOA」が登録（更新）されるため、ＭＡの「BindingCache」として、「現在のＰＣＯＡ」と「通信開始時のＰＣＯＡ」とを保持すればよいことになる。
【０３７６】
例えば図６２では、ＭＮが基地局ノード「ＢＳ３」に接続して相手端末ＣＮとの通信を開始し（VCOA=VCOA2，PCOA=PCOA3）、その後、通信を継続しながら別の基地局ノード「ＢＳ４」の在圏ゾーンへ移動した場合（VCOA=VCOA2，PCOA=PCOA4）を示しており、この場合、ＨＡでは、「現在のＣＯＡ」として“PCOA4”を保持し、「通信開始時のＣＯＡ」として“PCOA3”を保持することになる。
【０３７７】
これにより、ＭＡでは、例えば、受信パケットがＶＯＩＰパケットであればその受信パケットを「現在のＰＣＯＡ（＝PCOA4）」でカプセル化し、データパケットであれば「通信開始時のＰＣＯＡ（＝PCOA3）」でカプセルすることで、基地局ノード（ＢＳ３，ＢＳ４）をまたぐハンドオーバを行なう際に、パケット種別に応じたハンドオーバ方法（パケット転送ルート）の切り替えが可能となる（ＶＯＩＰパケットの場合は図６２に矢印８６，８６′，８７′に示すパケット転送ルート、データパケットの場合は図６２に示す矢印８６，８６′，８８′に示すパケット転送ルートとなる）。
【０３７８】
このようにして、本変形例では、通常の階層化Mobile-IP網におけるＨＡ及びＭＡのいずれにおいても、受信パケットの「トラフィック種別」（通信サービス）に応じた最適なハンドオーバ方法の切り替えを実現することができるので、通常の階層化Mobile-IP網においても、第２実施形態と同様に、ユーザが要求する複数種類のＱｏＳを満足する通信を柔軟に実現でき、常にユーザの要求に最適なハンドオーバ方法を提供してＱｏＳを大幅に向上させることが可能である。
【０３７９】
(E)その他
なお、上述した第２実施形態における「トラフィック種別」の識別は、「IPv6」のＩＰヘッダ７０に含まれる「ホップ制限数」（Hop Limit）フィールド７１６（図４５及び図４６等参照）〔「IPv4」ではＴＴＬ（Time To 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 Address）」フィールド
７２３，７２３ａ オプションタイプ（Option Type）フィールド
７２４ ホームアドレスフィールド
７２５ ＭＡアドレスフィールド
７２６ Ｍ３ネットワークアドレスフィールド
７２７ Ａ（Acknowledgement）ビットフィールド
７２８ リザーブ（reserved）ビットフィールド
７２９ ライフタイム（Lifetime）フィールド
７６１ 発信元ポート番号フィールド
７６２ 宛先ポート番号フィールド
７７１ ペイロードタイプフィールド
【発明の属する技術分野】
本発明は、階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法に関し、特に、MIPv6（Mobile Internet Protocol version 6）等に準拠したパケット網に用いて好適な技術に関する。
【０００２】
【従来の技術】
近年、IETF（Internet Engineering Task Force）において、インターネットプロトコル（ＩＰ）上で携帯電話等の移動端末（以下、単に「端末」ともいう）の位置を管理する方式として、「MIPv6」が提案されている。
図６３に「MIPv6」に準拠したパケット通信システムの一例を示す。この図６３に示すシステムでは、ルータ網（パケット網）１１０を運営するＩＳＰ（Internet Service Provider）等（以下、単に「プロバイダ」という）が管理するホームエージェント（HA：Home Agent）ノード１００において、そのプロバイダが提供するパケット転送サービスの契約加入者の移動端末（これを「ホーム端末」あるいは「契約端末」という）５００の現在位置が管理される。
【０００３】
同様に、ＨＡノード１００（ルータ網１１０）のプロバイダとは異なるプロバイダが管理するＨＡノード〔ＨＡノード１００側からみれば外部（foreign）網２１０のＨＡノード〕２００では、ルータ網２１０についての契約端末の現在位置が管理される。なお、３００，４００はルータ網１１０，２１０間を結ぶ中継ルータ網を表す。
【０００４】
ここで、具体的に、上記の契約端末５００の現在位置管理は、契約端末５００が契約ルータ網（ホーム網）１１０に存在している場合、その現在位置からアクセスしうる最寄りのアクセスノード（在圏ノード；無線基地局としての機能を有するパケットのラストホップルータ）１１１から広告（報知）される情報〔ルータ広告（ＲＡ：Router Advertisment）メッセージ〕に含まれるアクセスノード１１１のＩＰアドレスを基にCOA（Care of Address）と呼ばれる、現在自己がどのノードの在圏ゾーンに位置しているか（つまり、端末５００の接続先ノード）を表す情報を作成し、これをＨＡノード１００に通知することで実施される。
【０００５】
一方、契約端末５００がその移動により非契約ルータ網（移動先網）２１０に存在している場合（いわゆる「ローミング」中の場合）には、契約端末５００は、移動先網２１０の最寄りのアクセスノード２１１から受信されるＲＡに含まれるアクセスノード２１１のＩＰアドレスを基にCOAを作成して、これをホーム網１１０のＨＡノード１００にルータ網２１０，３００，４００を介して通知することになる。
【０００６】
つまり、契約端末５００は、その移動によって受信するＲＡに含まれるＩＰアドレスが変化して最寄りのアクセスノード１１１又は２１１が変わる度に、新たなCOAを作成してホーム網１１０のＨＡノード１００に対して現在位置の更新登録を実施するのである。
これにより、ＨＡノード１００は、契約端末５００が非契約ルータ網２１０に位置する場合（「ローミング」中の場合）であっても、逐次、更新登録されている現在位置宛に契約端末５００宛のパケットをカプセル化（契約端末５００宛のパケットにCOAを宛先アドレスとするヘッダを付加）して転送することで、契約端末５００宛のパケットを正しく契約端末５００に届けることができ、正常な移動通信が実現される。
【０００７】
なお、ルータ網２１０についての契約端末によるＨＡノード２００に対する位置登録手順も上記と同様である。
しかしながら、このような位置登録手順では、端末はその移動により最寄りのアクセスノードが変わる度に常にＨＡノード１００又は２００に位置登録を行なわなければならないため、現在位置とＨＡノード１００（又は２００）との距離に応じたパケット転送遅延が生じ、高速ハンドオーバには不向きである。また、アクセスノード２１１（又は１１１）からＨＡノード１００（又は２００）までのルータ網２１０，３００，４００，１１０のトラフィック量の増大にもつながる。
【０００８】
なお、上記のシステムにおいてローミング中の契約端末（以下、ローミング端末という）５００と相手端末６００（移動端末でもよいし固定端末でもよい）との通信が開始された後は、例えば図６４に示すように、ローミング端末５００が、ＨＡノード１００に対する位置登録と同様に、相手端末６００に現在のCOAを通知する（破線矢印７００参照）ことで、「ルート最適化」を図ることができる。つまり、相手端末６００は、現在のCOAをローミング端末５００から直接受信することで、ＨＡノード１００を経由せずにそのCOA宛に直接パケットを送信することができるようになるのである（実線矢印８００参照）。
【０００９】
ただし、この場合も、ローミング端末５００が移動して最寄りのアクセスノード２１１が変わったときには、その都度、新しいCOAを相手端末６００に通知する必要があるため、相手端末６００との距離に応じたパケット転送遅延によってハンドオーバ品質が左右されることになり、やはり高速ハンドオーバには向かない。
【００１０】
このように、図６３に示すような通常の「MIPv6」網（パケット通信システム）では、ローミング先のルータ網２１０でローミング端末５００が移動すると、その移動の度（正確には、最寄りのアクセスノードが変わる度）に、ＨＡノード１００への位置登録が発生し、ハンドオーバ時の通信品質劣化を生じるが、これを緩和するために、近年、ルータ網を階層化して階層内の移動時にはＨＡノードへの位置登録を不要とする方式〔階層化（Hierarchical）MIPv6〕も提案されている。
【００１１】
図６５に階層化Mobile-IPv6（以下、「HMIPv6」と表記する）に準拠したパケット通信システムの一例を示す。この図６５において、９００が移動端末５００へのゲート機能を提供するゲートノード（ＭＡ；Mobility Agent）であり、この図６５に示すように、それぞれが１台以上のアクセスノードを収容することにより、ルータ網１１０又は２１０のＭＡ９００単位での階層化が図られている。
【００１２】
そして、例えば、ルータ網１１０をホーム網とする契約端末５００がホーム網１１０からローミング先のルータ網２１０へ移動（ローミングイン）すると（矢印９０３参照）、その端末５００は、最寄りのＭＡ９００からルータ広告（ＲＡ）メッセージ（以下、単に「ルータ広告」ともいう）を受けて、そのＭＡ９００配下で使用するローカルなＩＰアドレス（「PCOA」と呼ばれる）と、ＨＡノード１００からＭＡ９００まで到達可能なＩＰアドレス（「VCOA」と呼ばれる）の２つのアドレスを作成する。
【００１３】
その後、端末５００は、「VCOA」をＨＡノード１００に通知して現在位置の位置登録を行なう（矢印９０４参照）とともに、「PCOA」をＭＡ９００に通知してＭＡ９００にも位置登録を行なう（矢印９０５参照）。以降、端末５００は、同一ＭＡ９００の配下での移動の場合（矢印９０１参照）には、ＭＡ９００にのみ位置登録を行ない（矢印９０６参照）、ＨＡノード１００への位置登録は行なわず、ＭＡ９００が異なる地域へ移動した場合（矢印９０２参照）には、再度、移動先のＭＡ９００とＨＡノード１００の両方に位置登録を行なう（矢印９０７，９０８参照）。なお、端末５００は、ホーム網１１０内に位置する場合にも、ＭＡをまたぐ移動が生じると、その都度、移動先のＭＡ９００とＨＡノード１００の双方に位置登録を行なう。
【００１４】
つまり、「HMIPv6」準拠のパケット通信システム（以下、階層化パケット通信システムという）では、同一ＭＡ９００内の移動であれば、端末５００は自己の現在位置の登録先（ＭＡ９００）を切り替えないのである。したがって、図６３及び図６４により前述した通常のシステムよりも、高速なハンドオーバを実現できる。
【００１５】
なお、この階層化パケット通信システムにおいても、前述したような「ルート最適化」を行なう場合には、図６６に示すように、ローミング端末５００が、相手端末６００との通信開始後、相手端末６００に現在の「VCOA」を通知すればよい（破線矢印９０９参照）。
つまり、相手端末６００から最初に端末５００宛に送信されたパケットが、一旦、ＨＡノード１００で受信され（矢印９１０参照）、ＨＡノード１００にて「VCOA」（ＭＡアドレス）でカプセル化されてＭＡ９００へルーティングされ、そのＭＡ９００にて「PCOA」（移動先アドレス）でカプセル化されて該当アクセスノード２１１へルーティングされることにより、相手端末６００とローミング端末５００との通信が開始されるが、その後は、ローミング端末５００が、相手端末６００に「VCOA」（ＭＡ９００まで到達可能なアドレス）を通知することにより、相手端末６００は、その「VCOA」宛にパケットを送信することが可能となり、当該パケットはＭＡ９００まで到達できる。
【００１６】
ただし、この場合も、ローミング端末５００の移動によりＭＡ９００が変わる（「VCOA」が変わる）場合には、その都度、新しい「VCOA」を相手端末６００に再通知する必要がある。なお、「ルート最適化」前の相手端末６００からローミング端末５００までのパケット転送ルートの一例を図６７に、「ルート最適化」後の相手端末６００からローミング端末５００までのパケット転送ルートの一例を図６８にそれぞれ示す。なお、これらの図６７，図６８において、符号１１０ａ，１１０ｂ（２１０ａ，２１０ｂ）はそれぞれＭＡ９００が管轄する階層化網を表し、これらの階層化網１１０ａ，１１０ｂ（２１０ａ，２１０ｂ）によってホーム網１１０（移動先網２１０）が形成されていることを示している。
【００１７】
そして、これらの図６７，図６８から分かるように、階層化パケット通信システムでは、ＨＡノード１００に「VCOA」を通知することで、常に、端末５００が位置登録（「PCOA」の通知）を行なっているＭＡ９００までのルートが最短距離となるよう最適化される（換言すれば、階層化パケット通信システムにおける「ルート最適化」では、必然的に、最低１台のＭＡ９００を経由することになる）。
【００１８】
ところで、従来の「Mobile-IP」網におけるハンドオーバ方法には、「スムースハンドオーバ」と呼ばれるものがある。これは、例えば図６９に模式的に示すように、ＨＡ１００（２００）に「COA1」が登録されている状態で、端末５００が移動して接続先ルータが「Ｒ１」から「Ｒ２」に変わることにより新しい「COA2」を作成したときに、ＨＡ１００（２００）ではなく、移動直前の接続先ルータ「Ｒ２」に対して、新しい「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（Multi-Media Mobile Network based on IPv6）ネットワーク」と称することがある。
【００３５】
ここで、ＶＨＡノード１０（２０）は、自キャリア網（ホーム網）１（２）内に存在する契約加入者の移動端末（ＭＮ：Mobile Node）３（以下、「ホーム端末３」もしくは単に「端末３」という場合がある）の現在位置情報〔COA（VCOA，PCOA）〕を結合（バインディング）キャッシュ（Binding Cache）と呼ばれる情報の一部として管理するとともに、到着（受信）した端末３宛のパケットが示す宛先アドレス（ＤＡ）に対応する「COA」を本「キャッシュ」において検索し、該当「COA」でカプセル化して転送（ルーティング）するためのものである。
【００３６】
なお、上記の「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（「PCOA」）を登録し、「Ｍ３対応網」である他網２（１）にローミングインするときには、ローミング先のＴＨＡ２１ａ又は２１ｂ（１１ａ又は１１ｂ）と、ホーム網１（２）のＶＨＡ１０（２０）との双方にCOAを登録するようになっている。
【００５１】
この場合、端末３は、ＴＨＡ２１ａ又は２１ｂ（１１ａ又は１１ｂ）には「PCOA」を登録し、ＶＨＡ１０（２０）には「VCOA」を登録する。また、本端末３は、上記の「ルータ広告」に含まれるアドレス情報によってローミング先の網種別を識別することができるので、その網種別に応じて位置登録先を変えることができる。
【００５２】
即ち、例えば、「ルータ広告」にＭ３ネットワークアドレスが含まれずＭＡアドレスが含まれている場合はその網が通常の「HMIPv6」網であるので、ローミング先のＭＡに「PCOA」を、ホーム網１（２）のＶＨＡ１０（２０）に「VCOA」をそれぞれ登録する。また、「ルータ広告」にＭ３ネットワークもＭＡアドレスも含まれていない場合は、その網は通常の「MIPv6」網であるので、端末３は、ＶＨＡ１０（２０）にのみ「VCOA」を登録する。つまり、本実施形態の端末３は、「MIPv6」，「HMIPv6」，「M3v6」のどのネットワークにも対応できるようになっているのである。
【００５３】
(A2)各種メッセージの詳細説明
さて、次に、本実施形態のシステムにおいて使用される上記の各種メッセージについて整理すると、次表１に示すようになる。
【００５４】
【表１】
以下、これらのメッセージの詳細について説明する。なお、以下では、これらのメッセージを「モバイルメッセージ」と総称する。これらの「モバイルメッセージ」は、「MIPv6」準拠の制御メッセージを拡張したもので、基本的には、いずれも、図７に示すような「MIPv6」に準拠したパケット（以下、「MIPv6」パケットともいう）のフォーマットを有している。
【００５６】
即ち、「MIPv6」パケットは、標準ヘッダ７１，オプションヘッダ７２及び認証ヘッダ７３から成るＩＰヘッダ７０とＩＰペイロード８０とから成るが、「モバイルメッセージ」は、これらのうちＩＰペイロード８０を除く部分で構成される。そして、上記のＩＰヘッダ７０（特に、オプションヘッダ７２）の設定内容によって上記の各メッセージ（パケット）が表示（識別）されるのである。
【００５７】
なお、標準ヘッダ７１には、図８に示すように、「バージョン情報」（４ビット），「トラフィッククラス」（８ビット），「フローラベル」（２０ビット），「ペイロード長」（１６ビット），「ネクストヘッダ」（８ビット），「ホップ制限数」（８ビット），「送信元アドレス（ＳＡ：Source Address）」（１２８ビット），「宛先アドレス（ＤＡ：Destination Address）」（１２８ビット）が格納される各フィールド７１１〜７１８が用意されている。
【００５８】
以下、上記の各モバイルメッセージのパケットフォーマットについて説明する。
(1)ホーム位置登録／位置登録応答メッセージ
図９にホーム位置登録メッセージのパケットフォーマット（ただし、ＩＰヘッダ７０に相当する部分）を示す。この図９から分かるように、ホーム端末３のホーム網１（２）への位置登録〔ＶＨＡ１０（２０）に対する位置登録〕には、「MIPv6」のオプションヘッダ７２の宛先オプションとして定義されている結合更新（Binding Update）オプション及びホームアドレス（Home Address）オプションを使用する。次表２に結合更新オプション（位置登録）パラメータを、次表３にホームアドレスオプションパラメータをそれぞれ示す。
【００５９】
【表２】
【表３】
そして、図９に示すように、ホーム位置登録メッセージの場合は、ＳＡフィールド７１７に端末３のCO A（MN-COA）が格納され、ＤＡフィールド７１８にＶＨＡ１０（２０）のアドレス（ＶＨＡアドレス）が格納される。これにより、ＶＨＡ１０（２０）にホーム位置登録メッセージが到着し、「ＳＡフィールド」に格納されているCOAが「キャッシュ情報」に登録されて端末３の位置登録（更新）が行なわれることになる。なお、本メッセージが「結合更新メッセージ」であることは、オプションタイプ（Option Type）フィールド７２３に表示（ここでは、“１９８”）される。
【００６２】
これに対し、上記のホーム位置登録メッセージを受けたＶＨＡ１０（２０）から端末３へのホーム位置登録応答には、図１０に示すパケットフォーマットを用いる。即ち、ホーム位置登録応答には、「MIPv6」の宛先オプションとして定義されている結合応答（Binding Acknowledgement）オプションを使用する。次表４にこの場合の結合応答オプションパラメータを示す。
【００６３】
【表４】
そして、図１０に示すように、ホーム位置登録応答メッセージの場合は、ＳＡフィールド７１７に発信ノード〔この場合はＶＨＡ１０（２０）〕のアドレスが格納され、ＤＡフィールド７１８にMN-COA〔受信パケット（つまり、上記のホーム位置登録メッセージ）のＳＡ〕が格納されることにより、ＶＨＡ１０（２０）位置登録を行なった端末３宛に本メッセージが発行（返信）されて、位置登録完了の旨が通知されることになる。
【００６５】
なお、ホーム位置登録メッセージを受けたＶＨＡ１１（２１）が位置登録応答メッセージを発行すべきか否かは結合更新オプションのＡ（Acknowledgement）ビットフィールド７２７に表示される（表２に示すように、“１”で要を表す）。また、図９及び図１０において、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、次表５のとおりである。
【００６６】
【表５】
（２）在圏位置登録／位置登録応答メッセージ
次に、在圏網１ａ，１ｂ（２ａ，２ｂ）への位置登録〔ＴＨＡ１１（２１）に対する位置登録〕には、図１１に示すパケットフォーマットを使用する。即ち、「HMIPv6」の宛先オプション７２として定義されている結合更新（Binding Update）オプションと同等の登録オプション（Registration）及びホームアドレスオプション（表３参照）を使用する。次表６に登録オプションパラメータを示し、次表７，８にそれぞれ表６中に示す前ＭＡアドレスサブオプション（previous mobility agent address sub-option）パラメータ，ホームエージェントアドレスサブオプション（home agent address Sub-Option）パラメータを示す。
【００６８】
【表６】
【表７】
【表８】
そして、図１１に示すように、本在圏位置登録（Registration）メッセージの場合も、基本的に、上述したホーム位置登録メッセージと同様に、ＳＡフィールド７１７に端末３のCOA（MN-COA）が格納され、ＤＡフィールド７１８にＴＨＡ１１（２１）のアドレス（ＴＨＡアドレス）が格納されることにより、ＴＨＡ１１（２１）に本在圏位置登録メッセージが到着し、ＳＡフィールド７１７に格納されているCOAがＴＨＡ１１（２１）の「キャッシュ情報」に登録されて端末３の位置登録（更新）が行なわれることになる。
【００７２】
なお、本メッセージが「Registration」メッセージであることは、オプションタイプフィールド７２３に表示（ここでは、“９”）される。また、前ＭＡアドレスサブオプションの前ＭＡアドレスフィールド７２１には、端末３が移動する前に位置登録を行なっていたＴＨＡ１１（２１）のアドレスが格納され、ＴＨＡ１１（２１）は、この前ＭＡアドレスフィールド７２１に設定されているアドレスを参照することで、在圏端末３がどのＴＨＡ１１（２１）の在圏ゾーンから移動してきたかを認識できることになる。
【００７３】
なお、図１１においても、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、前記の表５のとおりである。
これに対し、ＴＨＡ１１（２１）から端末３への位置登録応答には、前記の結合応答オプション（表４参照）を使用する。つまり、図１０に示すものと同様のパケットフォーマットを使用する。そして、ＳＡフィールド７１７に発信ノード〔この場合は、ＴＨＡ１１（２１）〕のアドレスが格納され、ＤＡフィールド７１８にMN-COA（受信パケットのＳＡフィールド７１７に設定されていたアドレス）が格納されることにより、ＴＨＡ１１（２１）に対して位置登録を行なった端末３宛に本メッセージが発行（返信）されて、位置登録完了の旨が通知されることになる。
【００７４】
（３）位置（キャッシュ）更新／応答メッセージ
次に、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）からＥＮ１２への位置更新（キャッシュ更新）には、図１２に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、結合更新オプション及びホームアドレスオプション（前記の表３参照）を使用する。ただし、更新対象の端末３のCOAは、結合更新オプションの代替COAサブオプション（Alternate Care of Address Sub-Option）によって通知する。次表９に結合更新オプション（位置更新）パラメータ例を、次表１０に代替COAサブオプションパラメータ例を示す。
【００７５】
【表９】
【表１０】
なお、本位置更新メッセージは、上述した端末３からＶＨＡ１０（２０）又はＴＨＡ１１（２１）への位置登録によりＶＨＡ１０（２０）又はＴＨＡ１１（２１）の「キャッシュ情報」が更新されることに伴って通信中のＥＮ１２にその更新を反映させる必要があるときに発行されるメッセージである。
このため、図１２に示すように、本位置更新メッセージの場合は、ＳＡフィールド７１７にＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納されるとともに、ＤＡフィールド７１８にＥＮ１２のアドレス（通信中ＥＮアドレス）が格納され、且つ、代替COAフィールド７２２に位置更新対象の端末３のCOA（MN-COA）が格納される。
【００７８】
これにより、「キャッシュ情報」の更新が必要な通信中ＥＮ１２に更新情報（MN-COA）が提供されて、通信中ＥＮ１２の「キャッシュ情報」が更新され、通信中ＥＮ１２は、端末３に対するパケットルーティングを正常に継続することが可能になる。なお、本メッセージが「位置更新メッセージ」であることは、代替COAフィールド７２２の有無によって識別できる。
【００７９】
一方、通信中ＥＮ１２は、上記の位置更新メッセージに対する応答（位置更新応答メッセージ）を発行元のＶＨＡ１０（２０）又はＴＨＡ１１（２１）に返信するが、このときの位置更新応答には、図１３に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、本メッセージの場合も、結合応答オプション（パラメータについては前記の表４参照）を使用する。
【００８０】
そして、この図１３に示すように、本位置更新応答メッセージの場合は、ＳＡフィールド７１７に発信ノード（ＥＮ１２）のアドレスが格納され、ＤＡフィールド７１８に上記の受信パケット（位置更新メッセージ）のＳＡフィールド７１７に設定されていたアドレス〔つまり、位置更新メッセージの発信元のＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレス〕が格納されることにより、そのＶＨＡ１０（２０）又はＴＨＡ１１（２１）宛に本メッセージが発行（返信）されて、位置更新完了の旨が通知されることになる。
【００８１】
なお、この場合も、本位置更新メッセージを受けたＥＮ１２がそれに対する応答メッセージを発行すべきか否かは結合更新オプションのＡ（Acknowledgement）ビット（表２参照）に表示される（“１”で要を表す）。また、図１２及び図１３においても、ＩＰヘッダ長やヘッダ拡張長等のLengthフィールドの取り扱いは、前記の表５に準ずる。
【００８２】
（４）キャッシュ要求／通知メッセージ
次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１（２１）へのキャッシュ要求（後述するキャッシュ検索によりキャッシュヒットしなかった場合に発行される）には、また、図１４に示すパケットフォーマット（ＩＰヘッダ７０に相当する部分）を使用する。即ち、「MIPv6」の宛先オプションとして新規に定義した結合要求〔Binding Reauest for M3 (BR-M3)〕オプションを使用する。
【００８３】
なお、このキャッシュ要求は、ＥＮ１２がＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスを既知である場合には、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）をＤＡとして本メッセージを発行する。このとき、どのアドレスに対する「キャッシュ」を要求しているかを示すためにホームアドレスオプションを使用する。
【００８４】
また、別の例として、ＤＡに「キャッシュ」を要求したいアドレスを直接指定する方法もある。この場合、「キャッシュ」をもっているエージェント〔ＶＨＡ１０（２０）／ＴＨＡ１１（２１）〕は、BR-M3メッセージであることを宛先オプションから判断し、ＤＡから「キャッシュ」を要求するアドレスを知るように定義することも可能である。
【００８５】
次表１１にBR-M3オプションパラメータ例を、次表１２に表１１中に示す固有ＩＤサブオプション（Unique Identifier Sub-Option）パラメータ例を、次表１３にホームアドレスオプション（キャッシュ要求）パラメータ例をそれぞれ示す。
【００８６】
【表１１】
【表１２】
【表１３】
そして、図１４に示すように、本キャッシュ要求メッセージの場合は、BR-M3オプションのオプションタイプフィールド７２３に、本メッセージがBR-M3メッセージであることを表す値（例えば、“１６”）が格納され、ＳＡフィールド７１７にＥＮ１２のアドレスが格納され、ＤＡフィールド７１８にキャッシュを知りたい端末３のアドレス、又は、その端末３に対応するエージェント〔ＶＨＡ１０（２０）又はＴＨＡ１１（２１）〕のアドレスが格納される。また、ＤＡフィールド７１８に後者のアドレスを格納する場合には、ホームアドレスフィールド７２４に、キャッシュを要求したいノードのホームアドレスが格納される。
【００９０】
これに対し、ＥＮ１２へのキャッシュ通知には、図１５に示すパケットフォーマットを使用する。即ち、結合更新オプション及びホームアドレスオプションを使用する。次表１４に、この場合の結合更新（Binding Update）オプションパラメータ例を、次表１５及び次表１６に表１４中に示す固有ＩＤサブオプション（Unique Identifier Sub-Option）パラメータ例及び代替COAサブオプション（Alternate Care of Address Sub-Option）パラメータ例を示す。なお、代替COAサブオプションは、キャッシュエントリを特定するために使用される。また、ホームアドレスオプションパラメータは前記の表３と同様である。
【００９１】
【表１４】
【表１５】
【表１６】
そして、図１５に示すように、キャッシュ通知の場合は、ＳＡフィールド７１７に上記のキャッシュ要求を受けたＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納され、ＤＡフィールド７１８にキャッシュ通知対象の通信中ＥＮ１２のアドレスが格納される。また、代替COAサブオプションの代替COAフィールド７２２には端末３のCOAが格納される。
【００９５】
これにより、本キャッシュ通知は、目的の通信中ＥＮ１２に到着し、そのＥＮ１２では、代替COAに格納されている端末３のCOAを自己のキャッシュとして保持することになる。なお、本メッセージが、「キャッシュ通知メッセージ」であることは、結合更新オプションにより識別でき、代替COAサブオプションを使用していれば（オプションタイプフィールド７２３ａが代替COAの存在を表示していれば）、ＳＡ以外をCOAとして使うことが分かる。従って、「キャッシュ」を作る際、検索キーについてはホームアドレスオプションフィールド７２４に設定された値を用い、COAについては代替COAフィールド７２２に設定された値（MN-COA）を用いることになる。
【００９６】
（５）キャッシュ削除要求／応答メッセージ
次に、ＥＮ１２からＶＨＡ１０（２０）又はＴＨＡ１１（２１）へのキャッシュ削除要求には、図１６に示すパケットフォーマットを使用する。即ち、前記の結合更新オプションを使用する。また、キャッシュ削除対象の端末３のアドレスを通知するためにホームアドレスオプション（そのパラメータについては前記の表３参照）を使用する。次表１７にこの場合の結合更新オプション（キャッシュ削除要求）パラメータ例を示す。
【００９７】
【表１７】
そして、図１６に示すように、本キャッシュ削除要求メッセージの場合は、ＳＡフィールド７１７にＥＮ１２のアドレスが格納され、ＤＡフィールド７１８にＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレスが格納される。また、ホームアドレスフィールド７２４に、ＥＮ１２においてキャッシュを削除した端末３のホームアドレス（ＶＨＡ１０（２０）又はＴＨＡ１１（２１）での削除対象キャッシュを特定する検索キーとして用いられる）が格納される。
【００９９】
なお、本メッセージが「キャッシュ削除要求メッセージ」であることは、上記の表１７及びこの図１６に示すように、リザーブ（reserved）ビットフィールド７２８に“１(0x01)”、ライフタイム（Lifetime）フィールド７２９に“０”が設定されることによって表示される。
これにより、通信中ＥＮ１２が非通信中となり、該当キャッシュが削除されることに伴って、その削除したキャッシュの通知元であるＶＨＡ１０（２０）又はＴＨＡ１１（２１）に対して本キャッシュ削除要求メッセージが発行され、そのＶＨＡ１０（２０）又はＴＨＡ１１（２１）において、もはや保持しておく必要の無い情報が適切に削除されることになる。
【０１００】
なお、本キャッシュ削除要求メッセージを受けたＶＨＡ１０（２０）又はＴＨＡ１１（２１）は、キャッシュ削除要求応答メッセージをＥＮ１２に対して返信するが、このキャッシュ削除要求応答メッセージには、前記の結合応答オプション（パラメータについては前記の表４参照）を使用する。即ち、本メッセージには、図１０に示すものと同様のパケットフォーマットを使用する。
【０１０１】
そして、ＳＡフィールド７１７に受信パケット（キャッシュ削除要求メッセージ）のＤＡフィールド７１８に設定されていたアドレス〔つまり、ＶＨＡ１０（２０）又はＴＨＡ１１（２１）のアドレス〕が格納され、ＤＡフィールド７１８に受信パケットのＳＡフィールド７１７に設定されていたアドレス（つまり、キャッシュ削除要求を発行した通信中ＥＮ１２のアドレス）が格納されることにより、通信中ＥＮ１２に対してキャッシュ削除を行なった旨が返信されて通知されることになる。
【０１０２】
(A3)システムの構成要素の詳細説明
次に、以下では、上記のＶＨＡ１０（２０），ＴＨＡ１１（２１），ＥＮ１２及び端末（ＭＮ）３を実現するためのそれぞれの構成について詳述する。なお、以下では、説明の便宜上、ＶＨＡ１０（２０），ＴＨＡ１１（２１），ＥＮ１２及びＭＮ３は、それぞれ、単にＶＨＡ，ＴＨＡ，ＥＮ，ＭＮと符号を略して表記する場合がある。また、これらを特に区別しない場合には、単に「ノード」と総称する場合もある。
【０１０３】
(A3.1)ＶＨＡ，ＴＨＡ，ＥＮの詳細説明
図２は上記のＶＨＡ１０（２０），ＴＨＡ１１（２１）及びＥＮ１２の要部の詳細構成を示すブロック図で、この図２に示すように、本実施形態において、ＶＨＡ１０（２０），ＴＨＡ１１（２１）及びＥＮ１２は、それぞれ、共通の構成を有しており、例えば、入力処理部４１，パケット種別識別部４２，バインディングキャッシュ検索部４３，結合（バインディング）キャッシュ（Binding Cache）テーブル４４，カプセル化処理部４５，ルータ処理部４６（ルーティングテーブル４６ａ，出方路決定部４６ｂ），出力処理部４８，タイマ処理部４９及び制御メッセージ処理部５０をそなえて構成されている。なお、この図２において、符号４３１はトラフィック種別識別部を表し、符号４３４はブリッジ部を表すが、これらの各部の機能についてはそれぞれ第２実施形態にて後述する。
【０１０４】
ここで、入力処理部４１は、到着（受信）パケットのＩＰレイヤ以下の処理を行なうためのもので、例えば、イーサネットであれば自ノード宛のＭＡＣ（Media Access Control）アドレスが付与されたパケットを取り込んで、そのパケットのフレーム自体の正常性をチェックする処理を行なう機能を装備するものである。
【０１０５】
また、パケット種別識別部４２は、この入力処理部４１で受信された正常なパケットの種別〔主に、制御メッセージ，マルチキャストパケット，これら以外のパケット等〕を、そのヘッダ部分（具体的には、ＤＡフィールド７１８）を参照して識別するためのもので、ここでは、上述した各種制御メッセージやマルチキャストパケットは制御メッセージ処理部５０へ、それ以外のパケットはバインディングキャッシュ検索部４３へそれぞれ引き渡されるようになっている。
【０１０６】
次に、図２に示す結合キャッシュテーブル（以下、単に「キャッシュテーブル」ともいう）４４は、基本的に、「MIPv6」ベースで作成される「キャッシュ」を端末３のホームアドレス（ＭＮホームアドレス）別にテーブル形式のデータとして保持するもので、例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによって構成される。ただし、このキャッシュテーブル４４は、ＶＨＡ／ＴＨＡにおけるものと、ＥＮにおけるものとで保持内容が若干異なる。
【０１０７】
即ち、ＶＨＡ／ＴＨＡのキャッシュテーブル４４には、例えば図４（Ａ）に示すように、“COA”（128ビット），“Lifetime”（32ビット），“Home registration flag”（1ビット），“router flag”（1ビット），“prefix length”（7ビット），“Sequence Number”（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”が切れない（“０”にならない）ように更新する機能を有するとともに、“Lifetime”が切れたときに、該当「キャッシュ情報」を削除する機能を有するものである。
【０１１６】
次に、制御メッセージ処理部５０は、パケット種別識別部４２で制御メッセージであると識別されて入力される制御メッセージに応じた処理を実施するためのもので、本実施形態では、例えば図２中に示すように、メッセージ種別判定部５１，モバイルメッセージ処理部５２，ルーティングメッセージ処理部５３及びルータ広告（RA：Router Advertise）メッセージ処理部５４をそなえて構成されている。ただし、このルータ広告メッセージ処理部５４は、ＥＮ１２に固有の機能で、ＶＨＡ１０（２０）やＴＨＡ１１（２１）には実装されていなくてもよい。
【０１１７】
ここで、上記のメッセージ種別判定部５１は、受信制御メッセージの種別を判定（識別）するためのもので、ここでは、上述したモバイルメッセージとそれ以外のルーティングメッセージとを判別して、モバイルメッセージについてはモバイルメッセージ処理部５２へ、ルーティングメッセージについてはルーティングメッセージ処理部５３へ振り分けられるようになっている。
【０１１８】
また、モバイルメッセージ処理部５２は、受信したモバイルメッセージの種別を判定してその種別に応じた処理を実施するためのもので、本実施形態では、そのメッセージ種別として、前述したように、主に、▲１▼結合更新（Binding Update）オプションを使用した結合更新メッセージ（ホーム／在圏位置登録メッセージ，キャッシュ更新メッセージ，キャッシュ削除要求メッセージ），▲２▼結合応答（Binding Ack）オプションを使用した結合応答メッセージ（ホーム／在圏位置登録応答メッセージ，キャッシュ通知メッセージ，キャッシュ削除応答メッセージ，キャッシュ更新応答メッセージ），▲３▼結合要求（Binding Request-M3）メッセージがある。
【０１１９】
このため、本モバイルメッセージ処理部５２は、例えば図３に示すように、結合更新（Binding Update）メッセージ処理部５２Ｃ，結合応答（Binding Acknowledge）メッセージ処理部５２Ｄ及び結合要求（Binding Request-M3）メッセージ処理部５２Ｅを有して構成されている。
ここで、上記の結合更新メッセージ処理部５２Ｃは、上記のメッセージ種別判定部５１から入力される結合更新メッセージに応じた処理を行なうためのもので、本実施形態では、例えば、結合キャッシュ（Binding Cache）テーブルアクセス部５２１，結合更新（Binding Update）メッセージ解析部５２２，結合応答（Binding 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），Ｍ３ネットワークアドレス（100.50）を抽出し（ステップＡ１）、まず、受信したＥＮアドレスと情報格納レジスタ３４１に保持されているＥＮアドレスとを比較して、一致しているか否かを判定する（ステップＡ２）。
【０１５３】
この場合、端末３は、同一ＥＮ“１”から「ルータ広告」を受信しているので、ＥＮアドレス（1.1）に変化は無い。従って、ルータ広告解析部３４１は、抽出したＥＮアドレス（1.1），ＴＨＡアドレス（10.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）と異なるアドレス（200.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-M3）メッセージ（Option Type=16）であるか否かをチェックする（ステップＢ７のＮｏルートからステップＢ９）。
【０１７０】
その結果、受信パケットがBR-M3メッセージである場合は、パケット種別識別部４２は、その受信パケットを制御メッセージ処理部５０へ転送し（ステップＢ１０のＹｅｓルートからステップＢ１１）、BR-M3メッセージでなければ、キャッシュ検索部４３に受信パケットを転送する。キャッシュ検索部４３は、このように転送されてきたパケットのＤＡフィールド７１８に設定されている宛先アドレスを検索キーとして、キャッシュテーブル４４を検索する（ステップＢ１０のＮｏルートからステップＢ１２）。
【０１７１】
この検索の結果、該当宛先アドレス（COA）がキャッシュテーブル４４に登録されていなければ、キャッシュ検索部４３は、宛先が見つからないので、ソフトウェア（図示省略）にパケットを引き渡し、当該ソフトウェアは、例えばICMP（Internet Control Message 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メッセージのＳＡと同一のキャッシュデータ（COA）〕が存在するかをチェックする（ステップＣ４のＹｅｓルートからステップＣ２５）。
その結果、キャッシュテーブル４４に該当「キャッシュ」が存在しなければ、テーブルアクセス部５２５は、そのまま処理を終える（ステップＣ２５のＮｏルート）一方、「キャッシュ」が存在すれば、「キャッシュ」に登録されているCOAを保持しておき、さらに、BR-M3メッセージのＳＡと同じ「通信中ＥＮアドレス」が該当するキャッシュエントリに存在するか否かを検索する（ステップＣ２５のＹｅｓルートからステップＣ２０）。
【０１９５】
この検索の結果、BR-M3メッセージのＳＡと同じ「通信中ＥＮアドレス」が存在すれば、テーブルアクセス部５２５は、その「通信中ＥＮアドレス」と保持しておいたCOAとを読み出し（ステップＣ２６）、結合要求メッセージ解析部５２６へ渡す。これにより、結合要求メッセージ解析部５２６は、受け取った情報（COA，「通信中ＥＮアドレス」）を結合更新メッセージ作成部５２７に転送して結合更新メッセージ（キャッシュ通知メッセージ）の作成を依頼する（ステップＣ２１のＹｅｓルートからステップＣ２３）。なお、上記のステップＣ２０において、「通信中ＥＮアドレス」が未登録であれば、その時点で、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（「PCOA」）の通知（登録）先を、同じＴＨＡに維持することができるので、従来のように移動に伴って位置登録先ＴＨＡの切り替えが頻繁に発生することも防止でき、高速ハンドオーバ性をさらに向上することができる。
【０２４９】
さらに、端末３による位置登録先ＴＨＡが端末３の移動に関わらず上述のごとく同じＴＨＡに維持される場合であっても、端末３のＴＨＡに対する現在位置の更新登録に応じて必要な「キャッシュ」が通信中ＥＮに逐次提供されて相互の同期がとられるので、通信中ＥＮは、パケット転送ルートを、ＴＨＡを経由しない新たな在圏ＥＮに到るルートに適切且つ迅速に変更することが可能である。従って、ＴＨＡの処理負荷をさらに抑制しながら高速ハンドオーバを実現することができる。
【０２５０】
また、端末３宛のパケットを受信したＥＮは、「キャッシュ」が無い場合にＶＨＡ／ＴＨＡへ必要な「キャッシュ」を要求するので、どのＥＮも、ＶＨＡ／ＴＨＡによるパケットルーティングを代替することができ、ＶＨＡ／ＴＨＡのパケットルーティングを代替するＥＮが１箇所に固定されず、特定のＥＮにパケットが集中してその負荷が増大することも無い。従って、この場合、ＥＮとＶＨＡ／ＴＨＡとの双方の負荷を軽減できることになる。
【０２５１】
さらに、このとき、ＶＨＡ／ＴＨＡは、「キャッシュ」の要求を受けたＥＮのみにキャッシュ情報を提供するので、不要な「キャッシュ」の転送を防止することができ、網内のトラフィック量の増大を抑制することも可能である。また、ＶＨＡ／ＴＨＡは、キャッシュテーブル４４に保持する「通信中ＥＮアドレス」によって、「キャッシュ」を更新／削除すべきＥＮを把握しておくので、新しいCOAの通知を受けた場合の該当通信中ＥＮの「キャッシュ」を誤ることなく更新できる。従って、パケットルーティングの信頼性、つまり、通信品質を向上することができる。
【０２５２】
さらに、通信中ＥＮでは、端末３宛のパケットを受信する毎に、上記の「キャッシュ」のライフタイム（有効期限）をリフレッシュするので、通信中に「キャッシュ」の有効期限が切れて正常な通信を維持できなくなることを回避することができ、さらに、パケットルーティングの信頼性、つまり、通信品質を向上することができる。
【０２５３】
また、通信中ＥＮは、通信が終了して上記の「キャッシュ」の有効期限が切れると、当該「キャッシュ」を削除するとともに、その「キャッシュ」を受けたＶＨＡ／ＴＨＡに対して該当「キャッシュ」の「通信中ＥＮアドレス」の削除を要求し、この要求を受けたＶＨＡ／ＴＨＡが、自己のキャッシュテーブル４４で保持している該当「通信中ＥＮアドレス」を削除するので、ＥＮ及びＶＨＡ／ＴＨＡにおいて不要な情報をいつまでも保持しておくことがなく、それぞれに必要なメモリ容量などを削減して、その小型化を図ることができる。
【０２５４】
(B)変形例の説明
上述した実施形態では、ローミング先において端末３が移動してＥＮアドレス及びＴＨＡアドレスに変化があっても、原則として、Ｍ３ネットワークアドレスに変化が無い限り、それらの変化を無視して、最初に位置登録を行なったＴＨＡに対してのみ位置登録を行なっているが、或る特定の条件（付加的条件）を満足した場合には、位置登録先のＴＨＡの切り替えを行なうようにすることも可能である。なお、「ＴＨＡの切り替え」とは、受信した「ルータ広告」に含まれるＴＨＡアドレス，ＥＮアドレスから新しく「VCOA」，「PCOA」を作成し、ＶＨＡにはホーム位置登録メッセージにより「VCOA」を、ＴＨＡには在圏位置登録メッセージにより「PCOA」を送信して各COAを登録することを意味する。
【０２５５】
以下では、その例について詳述する。ただし、以下の例では、例えば、図３０に示すように端末３がM3v6ネットワーク１からローミング先の他網（M3v6他ネットワーク）２へ移動してゆく状況を想定する。なお、この図３０において、端末３のホーム網１のアドレス（Ｍ３ネットワークアドレス）は、「100.50」、ローミング先のパケット網２のＭ３ネットワークアドレスは「200.50」、ＴＨＡ１１ａ，１１ｂ，２１ａ，２１ｂのアドレスは、それぞれ順に、「10.1」，「20.1」，「30.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」と遷移してゆく。
【０２５７】
また、Ｍ３ネットワークアドレスは、「100.50」→「100.50」→「100.50」→「200.50」→「200.50」→「200.50」→「200.50」→「200.50」と遷移してゆく。そして、このような移動に伴って、端末３で作成する「PCOA」は、「1.3」→「1.3」→「2.3」→「5.3」→「6.3」→「7.3」→「8.3」と遷移してゆき、「VCOA」は、「10.3」→「10.3」→「30.3」→「30.3」→「40.3」→「40.3」と遷移してゆくことになる。
【０２５８】
(B1)第１変形例（一定時間経過毎にＴＨＡの切り替え判断を行なう場合）
かかる状況を前提として、本第１変形例の端末３では、例えば図３１に示すように、パケット網２へローミングインした後、一定周期Ｔ毎に、ＴＨＡアドレスが変化しているか否かを判断する。そして、一定周期Ｔ経過時にＴＨＡアドレスが変化していれば、端末３は、そのときに初めて、位置登録先のＴＨＡをＴＨＡ２１ａからＴＨＡ２１ｂに切り替える。
【０２５９】
即ち、この例では、端末３は、ＴＨＡアドレスが変化した時点Ｔ１では、ＴＨＡの切り替えは行なわず、一定周期Ｔ経過時点Ｔ２において、初めて、その時のＥＮアドレス（＝「7.1」のプレフィックス部分（“７”）と自己のインタフェースＩＤ（＝“３”）との組み合わせにより、「PCOA」＝「7.3」を作成し、この「PCOA」をＴＨＡ２１ａではなくＴＨＡ２１ｂへ通知する（点線矢印９６参照）とともに、その時のＴＨＡアドレス（＝「40.1」）のプレフィックス部分（“４０”）と自己のインタフェースＩＤ（＝“３”）との組み合わせにより、「VCOA」＝「40.3」を作成して、この「VCOA」をホーム網１のＶＨＡ１０へ通知するのである（点線矢印９７参照）。
【０２６０】
このような動作は、例えば端末３のルータ広告メッセージ処理部３４Ｃの基本アルゴリズム（図２２に示すステップＡ１〜Ａ８）に、図３２に示すＴＨＡアドレスチェックアルゴリズム（ステップＡ９〜Ａ１３）及び図３３に示すフラグ設定アルゴリズム（ステップＡ１４〜Ａ１８）を付加することで実現できる。
即ち、この場合、図３３に示すように、端末３では、現時刻情報（nowtime）を読み出し（ステップＡ１４）、前回ＴＨＡアドレスチェック時刻情報（oldtime）を読み出し（ステップＡ１５）、これらの時刻情報の差分（nowtime−oldtime）が周期Ｔよりも大きいか否かをチェックする（ステップＡ１６）。
【０２６１】
そして、上記の各時刻情報の差分が時間情報（周期）Ｔよりも大きければ、一定周期Ｔが経過したことになるので、ＴＨＡアドレスフラグチェックフラグを“on”とし（ステップＡ１６のＹｅｓルートからステップＡ１７）、前回ＴＨＡアドレスチェック時刻情報（oldtime）を現時刻情報（nowtime）に更新して処理を終える（ステップＡ１８）。なお、上記の各時刻情報の差分が時間情報Ｔ以下であるときは、そのまま処理は終了する（ステップＡ１６のＮｏルート）。
【０２６２】
以上の処理（一定周期カウントアルゴリズム）を端末３は繰り返し実行することにより、一定周期Ｔ経過毎にＴＨＡアドレスチェックフラグを“on”に設定することになる。なお、上記の時刻情報（nowtime，oldtime），時間情報Ｔ，ＴＨＡアドレスチェックフラグは、それぞれ、情報格納レジスタ３４１に格納されるようにすればよい。
【０２６３】
かかる状態で、端末３（ルータ広告メッセージ処理部３４Ｃ）は、元のＴＨＡ２１ａ宛の在圏位置登録メッセージを発行してＴＨＡ２１ａへ位置登録を行なうと（ステップＡ８）、続いて、ＴＨＡアドレスチェックフラグが“on”になっているか否かをチェックし（ステップＡ９）、ＴＨＡアドレスチェックフラグが“off”になっていれば、その時点でＴＨＡアドレスが変化していても、現ＴＨＡアドレスは元のＴＨＡアドレスとし（ステップＡ９のＮｏルートからステップＡ１３）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６４】
これに対し、ＴＨＡアドレスチェックフラグが“on”になっていれば、次に、ルータ広告処理部３４Ｃは、「ルータ広告」に含まれるＴＨＡアドレスのプレフィックス部分が元のＴＨＡアドレス（例えば、情報格納レジスタ３４１に格納される）のプレフィックス部分と一致するか否かをチェックし（ステップＡ９のＹｅｓルートからステップＡ１０）、一致していれば、ＴＨＡアドレスに変化が無いので、この場合も、現ＴＨＡアドレスは元のＴＨＡアドレスとし（ステップＡ１０のＹｅｓルートからステップＡ１３）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６５】
一方、上記の各プレフィックス部分が一致していなければ、ＴＨＡアドレスが変化しているので、端末３（ルータ広告メッセージ処理部３４Ｃ）は、上述のごとく「PCOA」を新しいＴＨＡアドレスをもつＴＨＡ２１ｂへ在圏位置登録メッセージにより通知するとともに、「VCOA」をホーム網１のＶＨＡ１０へホーム位置登録メッセージにより通知して（ステップＡ１０のＮｏルートからステップＡ１１）、ＴＨＡアドレスチェックフラグを“off”に解除する（ステップＡ１２）。
【０２６６】
つまり、本変形例では、ゲートノード識別情報監視手段としての機能を果たすルータ広告解析部３４２が、上記のフラグ設定アルゴリズム（ステップＡ１４〜Ａ１８）およびＴＨＡアドレスチェックアルゴリズム（ステップＡ９〜Ａ１３）を実行することにより、所定の付加的条件下においてＴＨＡアドレスが変化したか否かを検知する条件付監視手段として構成されていることになる。
【０２６７】
そして、この場合、現在位置通知手段としての機能を果たす位置登録メッセージ作成部３４３が、上記ルータ広告解析部３４２にて上記の付加的条件下におけるＴＨＡアドレスの変化が検知されると、Ｍ３ネットワークアドレスに変化が無い場合であっても、変化後のＴＨＡアドレスによって識別される新たなＴＨＡに自己の現在位置情報（PCOA）を通知する条件付通知手段としての機能を有していることになる。
【０２６８】
このように、本第１変形例の場合は、一定周期Ｔ経過時にＴＨＡアドレスが変化しているという一定の条件を満足すると、位置登録先ＴＨＡの切り替えを行なうので、例えば、位置登録先ＴＨＡを維持することにより、端末３とＴＨＡとの距離が長距離になってしまった場合などにおいて、最寄りのＴＨＡが変化する毎に位置登録を行なう場合よりもその登録頻度を削減しながら、位置登録先ＴＨＡの最適化、つまり、ハンドオーバ時間の最適化を有効に図ることができる。
【０２６９】
(B2)第２変形例（非通信中にＴＨＡの切り替え判断を行なう場合）
次に、上述したＴＨＡの切り替え判断を、端末３の非通信中に行なう場合について説明する。
即ち、例えば図３４に示すように、「ルータ広告」に含まれるＴＨＡアドレスが「30.1」から「40.1」に変わった時点Ｔ３では、端末３は、まだ通信中であるため、ＴＨＡの切り替えを行なわない。その後、非通信中となった後（時点Ｔ４の後）で、「ルータ広告」を受信すると、上記の例と同様にして端末３はＴＨＡの切り替えを実行する（ＴＨＡ２１ｂに「PCOA」を通知し、ＶＨＡ１０に「VCOA」を通知する）。
【０２７０】
このような動作は、上記のＴＨＡアドレスフラグチェックを“on”にする契機だけが異なっているため、図３３に示すフラグ設定アルゴリズムに代えて、例えば図３５に示すように、通信中でないときにのみ（ステップＡ１９でＮｏと判定された場合にのみ）、ＴＨＡアドレスチェックフラグを“on”にする（ステップＡ２０）フラグ設定アルゴリズムを用いれば実現できる。なお、この図３５に示すアルゴリズムは、図３２に示すＴＨＡアドレスチェックアルゴリズムとは独立に、（例えば周期的に）起動される。
【０２７１】
このように、本第２変形例の場合は、位置登録先ＴＨＡの切り替えが必ず端末３の非通信中であるときに実施されるので、通信中の切り替え発生による通信品質の劣化は生じない。従って、通信品質の劣化を防止しながら、ハンドオーバ時間の最適化を図ることができる。
(B3)第３変形例（非通信中にＴＨＡの切り替え判断を行なう場合）
次に、上記のＴＨＡの切り替え判断を、トラフィック量が所定のしきい値以下であるときに行なう場合について説明する。
【０２７２】
即ち、例えば図３６に示すように、端末３において、その通信トラフィック量を監視しておき、ＴＨＡアドレスが変化してもその時のトラフィック量がしきい値を超えていれば、ＴＨＡの切り替え判断は行なわず（時点Ｔ５参照）、トラフィック量が所定のしきい値以下になって、初めてＴＨＡの切り替え判断を行なう（時点Ｔ６参照）。
【０２７３】
このような端末３の動作は、図３３に示すフラグ設定アルゴリズムに代えて、例えば図３７に示すように、監視したトラフィック量（例えば、情報格納レジスタ３４１に格納すればよい）を読み出し（ステップＡ２１）、そのトラフィック量がしきい値以下であるときにのみ（ステップＡ２２でＹｅｓと判定された場合にのみ）、ＴＨＡアドレスチェックフラグを“on”にする（ステップＡ２３）フラグ設定アルゴリズムを用いれば実現できる。なお、この図３７に示すアルゴリズムも、図３２に示すアルゴリズムとは独立に、（例えば周期的に）起動される。
【０２７４】
このように、本第３変形例の場合は、位置登録先ＴＨＡの切り替えが、必ず通信トラフィック量が所定値以下であるときに実施されるので、通信への影響（通信帯域の圧迫等）を最小限に抑制しながら、ハンドオーバ時間の最適化を図ることができる。
(B4)第４変形例（通信中トラフィックのタイプによってＴＨＡの切り替え判断を行なう場合）
次に、上記のＴＨＡの切り替え判断を、通信中トラフィックのタイプ（種別）によって行なう場合について説明する。
【０２７５】
即ち、例えば図３８に示すように、端末３が“http”，“VOIP”の２種のトラフィックタイプの通信を行なっており、“http”トラフィックが存在する間は、ＴＨＡアドレスに変化があっても、ＴＨＡの切り替え判断は行なわず（時点Ｔ７参照）、その後に、“http”トラフィックが無くなり、“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 Control）アドレスが付与されたパケットを取り込んで、そのパケットのフレーム自体の正常性をチェックする処理を行なう機能を装備するものである。
【０２９１】
また、パケット種別識別部４２Ａは、この入力処理部４１で受信された正常なパケットの種別（主に、自ノード宛のメッセージか他ノード宛のメッセージか）を、その宛先アドレス（ＤＡ）を参照して識別するためのもので、ここでは、自ノード宛のメッセージ（パケット）であれば制御メッセージ処理部５０Ａへ、他ノード宛のメッセージであれば、バインディングキャッシュ検索部４３Ａへそれぞれ転送されるようになっている。
【０２９２】
さらに、図４３において、結合（バインディング）キャッシュテーブル（以下、単に「キャッシュテーブル」という）４４Ａは、本実施形態においても、基本的に、「MIPv6」ベースで作成される「キャッシュ」をＭＮ３′のホームアドレス（ＭＮホームアドレス）別にテーブル形式のデータとして保持するもので、例えば、ＲＡＭやレジスタ等の所要の記憶デバイスによって構成される。
【０２９３】
ここで、このキャッシュテーブル４４Ａには、この場合も、基本的に、“COA”（128ビット），“lifetime”（32ビット），“Home registration flag”（1ビット），“router flag”（1ビット），“prefix length”（7ビット），“Sequence Number”（16ビット），“Recent Usage Information”（1ビット），“last BR time”（128ビット）等のキャッシュデータが保持されるが、ＨＡにおいては、例えば図４４（Ｂ）に示すように、ＭＮホームアドレス毎に、「現在のＣＯＡ」とその有効期限を表す“lifetime1”に加えて、ＭＮの「通信開始時（過去）のＣＯＡ」とその有効期限を表す“lifetime2”も保持されるようになっている。
【０２９４】
つまり、本実施形態のキャッシュテーブル４４Ａは、ＭＮの移動に伴う複数のＣＯＡ（「現在のＣＯＡ」及び「通信開始時のＣＯＡ」）を保持する位置情報保持部４４Ａ−１としての機能と、少なくとも「通信開始時のＣＯＡ」の有効期限に関する情報（“lifetime2”）を記憶する有効期限情報記憶部４４Ａ−２としての機能とを果たしていることになる。
【０２９５】
ここで、例えば、図４４（Ａ）に模式的に示すように、ＨＡの通信エリア（在圏ゾーン）１００′に存在するＭＮが、ルータ「Ｒ１」の在圏ゾーン１３′−２，ルータ「Ｒ２」の在圏ゾーン１３′−１の順に移動する場合（点線矢印９７参照）を想定する。なお、各ノードのＩＰアドレスを、第１実施形態での表記法と同様に、ｘ（ネットワークＩＤ）．ｙ（ＭＮのインタフェースＩＤ）と表記することにして、ＨＡのネットワークＩＤを“１４４”、ルータ「Ｒ２」のネットワークＩＤを“２１１”、ルータ「Ｒ１」のネットワークＩＤを“１１２”とすると、ＨＡのアドレスは“144.y”、ルータ「Ｒ２」のアドレスは“211.y”、ルータ「Ｒ１」のアドレスは“112.y”と表される。
【０２９６】
そして、ＭＮのインタフェースＩＤ（ＭＮに固有の識別子）を“５０”とすると、ＭＮは、ルータ「Ｒ１」の在圏ゾーン１３′−２に移動してルータ「Ｒ１」に接続したときに、ＣＯＡ＝“112.50”を作成してＨＡに通知（位置登録）する。なお、この時点では、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」は登録されない。
【０２９７】
その後、ＭＮがルータ「Ｒ１」に接続した状態で通信を開始すると（つまり、ＨＡでＭＮ宛のパケットが受信されると）、ＨＡは、受信パケットの「トラフィック種別」を判断し、受信パケットがデータパケットであればそのときの「現在のＣＯＡ」及び“lifetime1”をコピーして、「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａに登録する。
【０２９８】
かかる状態で、ＭＮがさらに移動し、ルータ「Ｒ２」に接続すると、ＭＮは新しいＣＯＡ＝“211.50”を作成してＨＡに通知し、ＨＡでは「現在のＣＯＡ」＝「現在のＣＯＡ」を“112.50”から“211.50”に書き換える。なお、この際、「通信開始時のＣＯＡ」は変更されない（“112.50”のままである）。
ここまでの状態で、ＨＡのキャッシュテーブル４４Ａには、図４４（Ｂ）に示す登録内容をもつことになる。つまり、ＨＡのキャッシュテーブル４４Ａには、図４（Ｂ）に示すように、「現在のＣＯＡ」として“211.50”が保持され、「通信開始時のＣＯＡ」として“112.50”が保持されることになる。
【０２９９】
なお、上記の“lifetime1”及び“lifetime2”は、いずれも、対応するＣＯＡ宛のパケットを受信しない間、定期的に減算され、最終的にその値が“０”になると（つまり、有効期限が切れると）、対応するＣＯＡ（キャッシュ）が削除される。ただし、対応するＣＯＡ宛のパケットを受信している間は、そのＣＯＡを維持する必要があるので、パケット受信毎に“lifetime2”は“０”にならないよう予め決められた初期値等にリフレッシュ（更新）される。“lifetime1”の更新契機は、第１実施形態と同様である。これらの有効期限の更新はタイマ処理部４９Ａによって実施される。
【０３００】
次に、バインディングキャッシュ検索部（以下、単に「キャッシュ検索部」ともいう）４３Ａは、入力パケットのＩＰヘッダ７０（図７参照）に含まれる宛先アドレスを検索キーとして、上記のキャッシュテーブル４４Ａを検索してカプセル化処理部４５でのカプセル化に必要な情報（ＣＯＡ等）を取得することができるものである。
【０３０１】
ただし、本実施形態のＨＡにおけるキャッシュ検索部４３Ａは、主として、次のような各機能を兼ね備えている。
▲１▼受信パケットの種別（例えば、トラフィック種別）を識別するトラフィック（パケット）種別識別部４３１としての機能
▲２▼「現在のＣＯＡ」及び“lifetime2”をそれぞれコピーして、「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａに登録しうるコピー登録部４３２としての機能
▲３▼このトラフィック種別識別部４３１による識別結果（受信パケットのトラフィック種別）に応じて、キャッシュテーブル４４Ａにおける上記の「現在のＣＯＡ」及び「通信開始時のＣＯＡ」のいずれか一方を、カプセル化処理部４５でのカプセル化に使用するＣＯＡとして選択するＣＯＡ選択部（選択手段）４３３としての機能
ここで、上記の「トラフィック種別」の例としては、▲１▼或る程度のパケットロスが許容される特性をもつ音声パケット〔例えば、ＶＯＩＰ（Voice Over Internet Protocol）パケット〕や▲２▼或る程度のパケット転送遅延が許容される特性をもつデータパケット〔例えば、ｈｔｔｐ（hyper text transfer protocol）データパケットやｆｔｐ(file transfer protocol)データパケット等〕があり、これらはＩＰヘッダ７０（標準ヘッダ７１；図７参照）に含まれるtos（タイプ・オブ・サービス）フィールド〔「トラフィッククラス」フィールド７１２（図８参照）〕の値をそれぞれについて定義しておくことで識別することが可能である。なお、このように、「トラフィック種別」の識別にtos値を用いるのが、最も簡便な手法であり、ＨＡの小型化も期待できる。
【０３０２】
具体的には、例えば、音声パケットは図４５に示すようなフォーマットを有しており、ｆｔｐデータパケットは図４６に示すようなフォーマットを有しているが、これらの図４５及び図４６において、「トラフィッククラス」フィールド７１２に、それぞれ音声パケット及びｆｔｐデータパケットを表す値を設定しておけば、これらのパケットの「トラフィック種別」（以下、「パケット種別」ともいう）をトラフィック種別識別部４３１において識別できることになる。
【０３０３】
つまり、この場合のトラフィック種別識別部４３１は、受信パケットの「トラフィック種別」が少なくともパケットロスを許容する特性をもつトラフィック種別及びパケット転送転送遅延を許容する特性をもつトラフィック種別のいずれであるかを識別するパケットロス／転送遅延特性識別部として機能することになる。
【０３０４】
なお、上記の「トラフィッククラス」フィールド７１２の値（tos値）は、例えば、ＭＮと網管理者との間で予め取り決めを交わしておき、ＭＮがパケットを生成するときにその取り決めに従ってＭＮ側で設定してもよいし、予め網管理者と取り決めを交わしておき、パケットが流入してくる網１′の入口（エッジルータ）にポリシー制御機能を導入し、そのルータにおいて、全受信パケットにつき、送信元アドレス（ＳＡ），宛先アドレス（ＤＡ），使用プロトコル，送信（発信）元ポート番号，宛先ポート番号をチェックして「トラフィック種別」を識別し、tos値をその識別結果に応じた適切な値（トラフィック識別情報）に書き換えた（設定した）上で網１′内（ＨＡ宛）にパケットを転送（ルーティング）するようにしてもよい。
【０３０５】
後者の場合には、ＭＮにおいて送信パケットのtos値を独自にセットする必要が無く、ＨＡは、受信パケットに上記エッジルータにて設定し直されたtos値に基づいて「トラフィック種別」の識別が可能となるので、ＭＮの処理能力に余裕をもたせることが可能である。なお、エッジルータでの「トラフィック種別」の識別結果は、勿論、パケットの「トラフィッククラス」フィールド７１２以外の部分に設定するようにしてもよい。
【０３０６】
また、図４５及び図４６において、上記の「送信元アドレス（ＳＡ）」はＳＡフィールド７１７に表示され、「宛先アドレス（ＤＡ）」はＤＡフィールド７１８に表示され、「使用プロトコル」は「ネクストヘッダ」フィールド（プロトコルフィールド）７１５に表示〔例えば、ＴＣＰ（Transmission Control Protocol）なら“６”，ＵＤＰ（User Datagram Protocol）なら“１７”等〕される。
【０３０７】
同様に、「送信元ポート番号」はＴＣＰヘッダ７４又はＵＤＰヘッダ７６の発信元ポート番号フィールド７６１に表示され、「宛先ポート番号」は同じくＴＣＰヘッダ７４又はＵＤＰヘッダ７６の宛先ポート番号フィールド７６２に表示される。
なお、このように網１′の入口（エッジルータ）にポリシー制御機能を導入しない場合は、例えば、ＶＯＩＰを使用する音声パケットは、通常、ＩＰの上位レイヤにＲＴＰ（Real-time Transport Protocol）を用いるので、ＲＴＰヘッダ７７（図４５参照）を検出することにより、受信パケットが音声パケットであることを識別できる。
【０３０８】
ここで、ＲＴＰの音声符号化の種別は、ペイロードタイプフィールド７７１に表示され、図４５には、音声パケットの一例として、ペイロード８０（２４バイト）に格納される音声データの音声符号化にG.723（dual rate speech corder for multimedia communications transmittimg at 5.3 and 6.3kbit/s）（ペイロードタイプ＝４）を用いた場合のパケットフォーマットを示している。
【０３０９】
また、受信パケットの「トラフィック種別」は、ＭＮ側で使用するアプリケーションによって使用ポート番号が異なる場合には、上記のポート番号フィールド７６１，７６２に表示されている値から識別することもできる。
さらに、上記のプロトコルフィールド７１５には、上位アプリケーションの種別が表示されているので、その値により受信パケットの「トラフィック種別」を識別することもでき、また、音声パケット等のリアルタイムトラフィックには通常パケット長が短いという特徴があるので、パケット長（「ペイロード長」フィールド７１４）の値から「トラフィック種別」を識別することも可能である。
【０３１０】
さらに、「IPv4」のパケットであれば、そのヘッダに含まれる識別子（Identification）フィールドの値を「トラフィック種別」の識別に使用することも可能である。
そして、ＨＡにおけるキャッシュ検索部４３Ａは、相手（宛先）ＭＮの現在位置を知らないためにＭＮホームアドレスを宛先アドレス（ＤＡ）として送信されたパケットの当該ＭＮホームアドレスを検索キーとして上記のキャッシュテーブル４４Ａを検索し、カプセル化処理部４５でのカプセル化に用いるＣＯＡとして、上述したごとくトラフィック種別識別部４３１によって識別される「トラフィック種別」に応じてＣＯＡ選択部４３３が「現在のＣＯＡ」及び「通信開始時のＣＯＡ」のいずれかを選択的に取得することになる。
【０３１１】
即ち、本実施形態のＣＯＡ選択部４３３は、例えば、受信パケットが或る程度のパケットロスを許容する特性をもつ音声（ＶＯＩＰ）パケットである場合、キャッシュ検索部４３Ａは、キャッシュテーブル４４Ａを検索して、受信パケットのＭＮホームアドレスに対応する「現在のＣＯＡ」を選択する一方、受信パケットが或る程度のパケット転送遅延を許容する特性をもつデータパケットである場合は、ＭＮホームアドレスに対応する「通信開始時のＣＯＡ」（ただし、登録されていれば）を選択する端末位置情報選択部として機能するようになっているのである。
【０３１２】
次に、カプセル化処理部４５は、ＣＯＡ選択部４３３で選択されたＣＯＡを用いてキャッシュ検索部４３Ａから転送されてくる受信パケットをカプセル化するものであり、ルータ処理部４６（ルーティングテーブル４６ａ，出力方路決定部４６ｂ），出力処理部４８は、図２により前述したものとそれぞれ同様の機能を有するもので、出方路決定部４６ｂが、ルーティングテーブル４６ａを検索して、出力すべき物理インタフェースや下位レイヤでの宛先アドレス等を決定し、出力処理部４８が、例えば、イーサネットの場合にはイーサネットフレームに必要なフレームチェックシーケンス符号を付けて、パケット（フレーム）送出を行なうようになっている。
【０３１３】
従って、本実施形態のカプセル化処理部４５では、ＣＯＡ選択部４３３で選択されたＣＯＡを用いてキャッシュ検索部４３Ａから転送されてくる受信パケットをカプセル化することになり、ルータ処理部４６では、出方路決定部４６ｂが、このようにカプセル化されたパケット（トンネルパケット）のヘッダ（カプセルヘッダ）の宛先情報（「現在のＣＯＡ」又は「通信開始時のＣＯＡ」）に基づいてルーティングテーブル４６ａのルーティング情報を検索して当該トンネルパケットの出力インタフェースを決定して、決定した出力インタフェースへ当該トンネルパケットを出力することになる。
【０３１４】
つまり、本実施形態のルータ処理部４６は、ＣＯＡ選択部４３３で選択されたＣＯＡに基づいて受信パケットをルーティングするルーティング手段として機能することになる。
これにより、音声パケットについては、例えば図４７に模式的に示すように、ＭＮから結合更新（Binding Update）メッセージにより登録（点線矢印２３ａ参照）される「現在のＣＯＡ」、つまり、ＭＮの最新のＣＯＡ（ＣＯＡ２＝211.50）でカプセル化されてルーティングされることになるので、ＭＮが現在接続しているルータ「Ｒ２」までのパケット転送ルートが最適化されて（実践矢印２２，２３参照）パケット転送遅延が最小となる。
【０３１５】
一方、データパケットの場合は、「通信開始時のＣＯＡ」（ＣＯＡ１＝112.50）でカプセル化されてルーティングされることになるので、例えば図４８に模式的に示すように、ＭＮが通信継続中は通信開始時に接続していたルータ（以下、旧ルータという）「Ｒ１」に対して「スムースハンドオフ指示」を発行して旧ルータ「Ｒ１」に「現在のＣＯＡ」（ＣＯＡ２＝211.50）を登録する（点線矢印２４参照）ことにより旧ルータ「Ｒ１」からのパスを現在接続しているルータ「Ｒ２」まで伸ばしておく（実線矢印２６参照）ことで、ＨＡから旧ルータ「Ｒ１」までのパケット転送ルートは維持される（実線矢印２５参照）ことになり、ＨＡでパケット転送先をルータ「Ｒ１」から「Ｒ２」に切り替える場合（図４７の場合）に比して、パケットロスを最小限に抑制することが可能となる。
【０３１６】
このように、本実施形態のＨＡは、受信パケットの「トラフィック種別」に応じて、受信パケットのカプセル化に用いるＣＯＡを使い分けることにより、ＭＮに対するハンドオーバの仕組み（方法）を変える（切り替える）ことができるようになっているのである。なお、以下では、上記の各ハンドオーバ方法のうち、前者（ＶＯＩＰパケットについてのハンドオーバ方法）を第１のハンドオーバ方法、後者（データパケットについてのハンドオーバ方法）を第２のハンドオーバ方法ということがある。
【０３１７】
次に、図４３において、タイマ処理部４９Ａは、上述したキャッシュテーブル４４Ａにおける“lifetime1”，“lifetime2”を更新する機能、即ち、入力処理部４１でＭＮホームアドレスを宛先アドレス（ＤＡ）とするパケットが受信されない間は“Lifetime1”,“lifetime2”をそれぞれデクリメントし、パケットが受信されている間は“Lifetime1”,“lifetime2”が切れない（“０”にならない）ように更新（リフレッシュ）する有効期限リフレッシュ部４９１としての機能を有するとともに、“Lifetime1”,“lifetime2”が切れたときに、該当ＣＯＡを削除するＣＯＡ（端末位置情報）削除部４９２としての機能を有するものである。
【０３１８】
また、制御メッセージ処理部５０Ａは、パケット種別識別部４２Ａにおいて自ノード宛のメッセージであると識別された(制御)メッセージを受けて、そのメッセージを処理するためのものである。このため、本制御メッセージ処理部５０Ａには、図４３中に示すように、メッセージ種別判定部５１Ａ，モバイルメッセージ処理部５２Ａ，ルーティングメッセージ処理部５３及びルータ広告メッセージ（ＲＡ）処理部５４が設けられている。
【０３１９】
ここで、上記のメッセージ種別判定部５１Ａは、受信制御メッセージの種別を判定（識別）するためのもので、モバイルメッセージ（結合更新／応答メッセージ）とそれ以外のルーティングメッセージとを判別して、モバイルメッセージについてはモバイルメッセージ処理部５２Ａへ、ルーティングメッセージについてはルーティングメッセージ処理部５３へそれぞれ振り分けられるようになっている。
【０３２０】
また、モバイルメッセージ処理部５２Ａは、受信したモバイルメッセージの種別を判定（解析）してそのメッセージ内容に応じた処理（キャッシュテーブル４４Ａへの情報登録や削除）を行なうためのもので、本実施形態では、そのメッセージ種別として、主に、▲１▼前記の結合更新（Binding Update）オプションを用いた結合更新（Binding Update）メッセージ〔位置登録メッセージ（スムースハンドオフ指示メッセージ）〕，▲２▼前記の結合応答（Binding Acknowledgement）オプションを用いた結合応答（Binding Acknowledgement）メッセージ（位置登録応答メッセージ）等がある。ただし、前者▲１▼のメッセージはＭＮからＨＡ（旧ルータ１３′）宛に送信されるメッセージであり、後者▲２▼のメッセージは、ＨＡ（旧ルータ１３′）から位置登録メッセージ送信元のＭＮ宛に送信されるメッセージである。
【０３２１】
そして、具体的に、このモバイルメッセージ処理部５２Ａは、ＭＮからの位置登録メッセージ（スムースハンドオフ指示メッセージ）を受信すると、そのメッセージに含まれるＣＯＡを「現在（最新）のＣＯＡ」として前記のキャッシュテーブル４４Ａの該当領域（ＭＮホームアドレスに対応する領域）に登録（更新）するようになっている。
【０３２２】
ただし、ＨＡにおけるモバイルメッセージ処理部５２Ａは、受信パケットがデータパケットである場合に、「通信開始時のＣＯＡ」がキャッシュテーブル４４Ａに未だ登録されていない場合には、その時の「現在のＣＯＡ」及び“lifetime 1”をコピーして「通信開始時のＣＯＡ」及び“lifetime 2”として登録することができるようにもなっている。
【０３２３】
つまり、図４３において、キャッシュテーブル４４Ａ，タイマ処理部４９Ａ及びモバイルメッセージ処理部５２Ａから成る部分は、ＭＮの移動に伴う複数のＣＯＡ（端末位置情報）を管理する端末位置管理手段として機能するのである。
なお、図４３に示すルーティング処理部５３及びＲＡ処理部５４は、それぞれ、図２により前述したものと同様のものであり、ＲＩＰ（Routing Information Protocol）等のルーティングメッセージについての処理（例えば、網構成の変更等に伴うルーティング情報の更新等）がルーティングメッセージ処理部５３によって実施され、在圏ＭＮに対するルータ広告がルータ広告メッセージ処理部５４によって発行されるようになっている。
【０３２４】
以下、上述のごとく構成された本第２実施形態のパケット網１′におけるハンドオーバ方法（ＨＡの動作）について詳述する。ただし、以下では、説明の便宜上、受信パケットの「トラフィック種別」の識別に、前記のtos値を用いることを前提とする（例えば、tos=0で音声（ＶＯＩＰ）パケット、tos=1でデータパケットを表すものとする）。
【０３２５】
まず、ＨＡでは、図５０に示すように、パケットが入力処理部４１において受信されると（ステップＨ１）、その受信パケットの正常性がチェックされたのち、パケット種別識別部４２Ａにおいて受信パケットが制御メッセージであるか否かが判定される（ステップＨ２,Ｈ３）。
その結果、受信パケットが制御メッセージであれば、その制御メッセージは、制御メッセージ処理部５０Ａのメッセージ種別判定部５１Ａに転送され、メッセージ種別判定部５１Ａにおいて、さらに、その制御メッセージがモバイルメッセージ（結合更新／応答メッセージ）であるか否かが判定される（ステップＨ３のＹｅｓルートからステップＨ４，Ｈ５）。
【０３２６】
この結果、受信制御メッセージがモバイルメッセージであれば、そのモバイルメッセージはモバイルメッセージ処理部５２Ａへ転送され、モバイルメッセージ処理部５２Ａは、受信モバイルメッセージが結合更新メッセージ（つまり、位置登録メッセージ）であれば、そのメッセージに含まれるＣＯＡがＭＮの「現在のＣＯＡ」としてキャッシュテーブル４４Ａの該当領域に登録する（ステップＨ５のＹｅｓルートからステップＨ７）。なお、受信モバイルメッセージが結合応答メッセージであった場合、モバイルメッセージ処理部５２Ａは、そのメッセージ内容を解析して必要に応じて内部パラメータの変更等を行なう。
【０３２７】
ところで、パケット種別識別部４２Ａにおいて、受信パケットが制御メッセージでないと判定された場合（ステップＨ３でＮｏと判定された場合）、その受信パケットはキャッシュ検索部４３Ａに転送され、図５１に示すように、キャッシュ検索部４３Ａは、受信パケットの宛先アドレス（ＭＮホームアドレス）を検索キーとしてキャッシュテーブル４４Ａを検索し、ＭＮホームアドレスに対応するＣＯＡ（「現在のＣＯＡ」及び「通信開始時のＣＯＡ」）を取得する（ステップＨ８）。
【０３２８】
さらに、キャッシュ検索部４３Ａ（トラフィック種別識別部４３１）は、パケット種別識別部４２Ａから転送されてきたパケットのtos値をチェックすることにより、そのパケット種別（音声パケットかデータパケットか）を識別（判定）する（ステップＨ９,Ｈ１０）。
この結果、tos値が“０”で受信パケットが音声（ＶＯＩＰ）パケットであった場合（ステップＨ１０でＹｅｓの場合）、キャッシュ検索部４３Ａは、ＣＯＡ選択部４３３によって、カプセル化に使用するＣＯＡとして上記のステップＨ８で取得したＣＯＡのうち「現在のＣＯＡ」を選択する（ステップＨ１１）。
【０３２９】
これに対し、tos値が“１”で受信パケットが（ｆｔｐ）データパケットであった場合（ステップＨ１０でＮｏの場合）、キャッシュ検索部４３Ａは、上記のステップＨ８で取得したＣＯＡに「通信開始時のＣＯＡ」が含まれている（つまり、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」が既に登録されている）か否かをチェックする（ステップＨ１２）。
【０３３０】
その結果、未だ「通信開始時のＣＯＡ」が登録されていなければ（ステップＨ１２でＮｏであれば）、上記受信パケットがＭＮ宛の第１パケットである、即ち、この時点が「通信開始時」であることを意味するので、キャッシュ検索部４３Ａは、ＣＯＡ選択部４３３によって、上記第１パケットのカプセル化に使用するＣＯＡとしてこの時点では「現在のＣＯＡ」を選択したのち（ステップＨ１３）、コピー登録部４３２によって、その「現在のＣＯＡ」及び“lifetime1”をコピーして「通信開始時のＣＯＡ」及び“lifetime2”としてキャッシュテーブル４４Ａの該当領域に登録する（ステップＨ１４）。
【０３３１】
以降は、キャッシュテーブル４４Ａに「通信開始時のＣＯＡ」が登録されているので、同じＭＮ宛の受信パケット（第２パケット以降）については、カプセル化に使用するＣＯＡとして、「通信開始時のＣＯＡ」が選択されることになる（ステップＨ１２のＹｅｓルートからステップＨ１５）。なお、この際、通信中に「通信開始時のＣＯＡ」が有効期限切れになり削除されてしまわぬように、“lifetime2”がタイマ処理部４９Ａ（有効期限リフレッシュ部４９１）によってリフレッシュされる（ステップＨ１６）。
【０３３２】
さて、上述のごとくステップＨ１１,Ｈ１３又はＨ１５においてキャッシュ検索部４３Ａ（ＣＯＡ選択部４３３）によって選択された「現在のＣＯＡ」又は「通信開始時のＣＯＡ」は、受信パケットとともにカプセル化処理部４５へ転送され、カプセル化処理部４５は、そのＣＯＡで受信パケットをカプセル化してルータ処理部４６へ転送する（ステップＨ１７）。
【０３３３】
これにより、カプセル化されたパケット（トンネルパケット）は、出方路決定部４６ｂにおいて、ルーティングテーブル４６ａのルーティング情報に基づいてその出力インタフェースが決定されたのち、出力処理部４８を通じて決定した出力インタフェースへ送信される（ステップＨ１８）。即ち、ＶＯＩＰパケットは「現在のＣＯＡ」に該当するルータ（ＭＮが現在接続しているルータ）１３′へ向けてルーティングされ、データパケット（第２パケット以降）は「通信開始時のＣＯＡ」に該当する旧ルータ１３′へルーティングされることになる。
【０３３４】
以上のようなＨＡでの動作を前提とすることにより、例えば図４９（Ａ）に示すように、ＭＮが相手端末ＣＮ（Corresponding Node）とルータ「Ｒ３」,ＨＡ,ルータ「Ｒ１」経由で音声通話している（このとき、ＨＡは音声パケットを「現在のＣＯＡ」（112.50）宛にカプセル化して転送している）状態（実線矢印２２,２３′参照）で、ＭＮが通信を継続しながらルータ「Ｒ２」の在圏ゾーンへ移動したとすると（矢印２７参照）、ＨＡはＭＮから登録された最新のＣＯＡ（211.50）で相手端末ＣＮからの音声パケットをカプセル化して転送する（第１のハンドオーバ方法を実行する）ことになる（実線矢印２３参照）。
【０３３５】
一方、例えば図４９（Ｂ）に示すように、ＭＮが相手端末ＣＮ（Corresponding Node）とルータ「Ｒ３」,ＨＡ,ルータ「Ｒ１」経由でデータ通信している（このとき、ＨＡはデータパケットを「現在のＣＯＡ」（112.50）宛にカプセル化して転送している）状態（実線矢印２２参照）で、ＭＮがデータ通信を継続しながらルータ「Ｒ２」の在圏ゾーンへ移動したとすると（矢印２８参照）、ＨＡは「通信開始時のＣＯＡ」（112.50）で相手端末ＣＮからのデータパケットを引き続きカプセル化して転送する（第２のハンドオーバ方法を実行する）ことになる（実線矢印２５参照）。
【０３３６】
この場合、ＭＮがルータ「Ｒ２」の在圏ゾーンに移動した時点で、ＭＮの「スムースハンドオフ指示」により旧ルータ「Ｒ１」に「現在のＣＯＡ」（211.50）が登録される（点線矢印２４参照）ので、旧ルータ「Ｒ１」は、ＨＡから「通信開始時のＣＯＡ」（112.50）宛に送られてきたパケットを「スムースハンドオフ指示」により登録されたＣＯＡ（211.50）で再カプセル化（スムースハンドオフ）して、ＭＮが現在接続しているルータ「Ｒ２」へ転送する（実線矢印２６参照）。
【０３３７】
なお、「スムースハンドオフ指示」を受けることによりスムースハンドオフを実行するルータ（ノード）１３′のことを「アンカーポイント」という。この「アンカーポイント」は、ＭＮの通信が一旦終了した場合は解除され（「スムースハンドオフ指示」によりＭＮから登録されたＣＯＡが削除され）、次にＭＮが通信を開始して「スムースハンドオフ指示」を新たに発行したルータ１３′が新たな「アンカーポイント」となる。
【０３３８】
以上のように、本実施形態によれば、ＨＡにおいて、ＭＮの移動に伴う複数のＣＯＡ（現在のＣＯＡ及び通信開始時のＣＯＡ）を管理しておき、ＭＮ宛のパケット種別を識別し、識別したパケット種別に応じて上記のＣＯＡのいずれかを選択（つまり、カプセル化ヘッダの宛先を変更）して、そのＣＯＡに基づいて受信パケットをルーティングすることにより、受信パケットの種別に応じてハンドオーバ方法を切り替えることができるので、ユーザが要求する複数種類の通信サービス品質（ＱｏＳ：Quality of Service）を満足する通信を柔軟に実現でき、常にユーザの要求に最適なハンドオーバ方法を提供してＱｏＳを大幅に向上させることが可能である。
【０３３９】
特に、本実施形態では、ＨＡにおいて、受信パケットが音声パケットであればＭＮの「現在のＣＯＡ」を選択することにより、パケット転送遅延を最小限に抑制したハンドオーバを実施することができ、受信パケットがデータパケットであれば、ＭＮの「通信開始時のＣＯＡ」を選択することにより、パケットロスを最小限に抑制したハンドオーバを実施することができるので、ＭＮのユーザが利用する音声通話サービス，データ通信サービス等に応じた最適なハンドオーバ方法を提供することができるのである。
【０３４０】
また、本実施形態のＨＡでは、「通信開始時のＣＯＡ」の“lifetime2”を記憶しておき、ＭＮ宛の受信パケットを受信する毎にその“lifetime2”をタイマ処理部４９（有効期限リフレッシュ部４９１）がリフレッシュするので、データパケット通信継続中に「通信開始時のＣＯＡ」が無効になることを防止することができ、当該データパケット通信の信頼性も向上している。
【０３４１】
さらに、上記のタイマ処理部４９は、「通信開始時のＣＯＡ」の“lifetime2”が切れると、その「通信開始時のＣＯＡ」を位置情報削除部４９２が削除するので、「通信開始時のＣＡＯ」の記憶に必要な記憶容量を最小限に抑制して、ＨＡの小型化にも大きく寄与している。
また、本実施形態のＭＮは、データパケットを受信している間、通信開始時に接続していたルータ１３′（アンカーポイント）に対して「スムースハンドオフ指示」を発行するので、「スムースハンドオフ指示」を受けたルータ１３′からＭＮが現在接続しているルータ１３′まで通信パス（パケット転送ルート）を伸ばしておくことができ、ハンドオーバに伴うパケットロスを最小限に抑制することが可能である。
【０３４２】
(D1)第２実施形態の第１変形例の説明
さて、上述した第２実施形態では、「通信開始時のＣＯＡ」をパケットの宛先（ＭＮホームアドレス）毎でしか管理していないので、同一宛先のデータパケットに対しては、全て、同一の転送ルートとなるようにＨＡにてカプセル化が行なわれることになる。
【０３４３】
このため、例えば、ＭＮ宛にある発信者が既にデータパケットの送信を行なっている状態で、別の発信者がＭＮ宛にデータパケットを新たに送信しはじめると、ＭＮが別のルータ１３′の在圏ゾーンに移動した場合でも、そのデータパケットは、既存の発信者が送信したデータパケットのカプセル化に使用したものと同じ「通信開始時のＣＯＡ」でカプセル化されてしまい、既存の発信者が送信したデータパケットのパケット転送ルート（スムースハンドオフによるルート）と全く同じルートで転送されるという非効率な事態が生じる。
【０３４４】
そこで、本変形例では、宛先（ＭＮホームアドレス）毎に加えて、受信パケットの発信元（送信元アドレス：ＳＡ）毎にも「通信開始時のＣＯＡ」を管理することにより、発信元毎にデータパケットのパケット転送ルートを変えられるようにして、発信者毎に、常に最短のアンカーポイント〔スムースハンドオフによるパケット転送を行なうルータ（ノード）〕をとることができるようにする。
【０３４５】
これは、例えば図５２（Ｂ）に示すように、キャッシュテーブル４４Ａを、
ＭＮホームアドレス毎に「現在のＣＯＡ」,その有効期限を示す“lifetime1”及びＭＮホームアドレスを一意に表すＩＤの組が登録・管理されるキャッシュテーブル４４１（Biding Cache1）と、上記ＩＤと受信パケットの送信元アドレス（ＳＡ）との組み合わせ毎に「通信開始時のＣＯＡ」及びその有効期限を示す“lifetime2”の組が登録・管理されるキャッシュテーブル４４２（Binding Cache 2）とにより構成することで実現できる。
【０３４６】
そして、本変形例においても、図４４（Ａ）と同様に、ＨＡのネットワークＩＤを“１４４”、ルータ「Ｒ２」のネットワークＩＤを“２１１”、ルータ「Ｒ１」のネットワークＩＤを“１１２”とすると、ＨＡのアドレスは“144.y”、ルータ「Ｒ２」のアドレスは“211.y”、ルータ「Ｒ１」のアドレスは“112.y”と表され、ＭＮのインタフェースＩＤを“５０”とすると、ＭＮは、ルータ「Ｒ１」の在圏ゾーン１３′−２に位置する時はＣＯＡ＝“112.50”、ルータ「Ｒ２」の在圏ゾーン１３′−１に位置する時はＣＯＡ＝“211.50”を作成して、それぞれ、ＨＡに通知（位置登録）することになる。
【０３４７】
従って、仮に、ＭＮがルータ「Ｒ１」の在圏ゾーン１３′−２に位置する時にそのルータ「Ｒ１」に接続して、ルータ「Ｒ３」に接続している相手端末「ＣＮ１」（仮に、送信元アドレス＝70.21とする）とデータ通信を開始したとすると、ＨＡのキャッシュテーブル４４２には、図５２（Ｂ）に示すように、相手端末「ＣＮ１」との「通信開始時のＣＯＡ」として“112.50”が登録されることになる。
【０３４８】
また、その後に、ＭＮがルータ「Ｒ２」の在圏ゾーン１３′−１に位置する時に、そのルータ「Ｒ２」に接続して、ルータ「Ｒ４」に接続している別の相手端末「ＣＮ２」（仮に、送信元アドレス＝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=VCOA1，PCOA=PCOA2）、その後、通信を継続しながら別の階層化ノード「ＭＡ２」が管轄する基地局ノード「ＢＳ３」の在圏ゾーンへ移動した場合（VCOA=VCOA2，PCOA=PCOA3）を示しており、この場合、ＨＡでは、「現在のＣＯＡ」として“VCOA2”を保持し、「通信開始時のＣＯＡ」として“VCOA1”を保持することになる。
【０３７４】
これにより、ＨＡでは、例えば、受信パケットがＶＯＩＰパケットであればその受信パケットを「現在のＶＣＯＡ（＝VCOA2）」でカプセル化し、データパケットであれば「通信開始時のＶＣＯＡ（＝VCOA1）」でカプセルすることで、階層化ノード（ＭＡ１，ＭＡ２）をまたぐハンドオーバを行なう際に、パケット種別に応じたハンドオーバ方法（パケット転送ルート）の切り替えが可能となる（ＶＯＩＰパケットの場合は図６１に矢印８６〜８８に示すパケット転送ルート、データパケットの場合は図６１に示す矢印８６，８９，９０に示すパケット転送ルートとなる）。
【０３７５】
一方、階層化ノード（ＭＡ）に、同様のハンドオーバ方法の切り替えを適用するには、ＭＡの「BindingCache」として登録されるのが、「VCOA」をキーとした「PCOA」であり、ＭＮの基地局ノードをまたぐ移動によりＭＮから新たな「PCOA」が登録（更新）されるため、ＭＡの「BindingCache」として、「現在のＰＣＯＡ」と「通信開始時のＰＣＯＡ」とを保持すればよいことになる。
【０３７６】
例えば図６２では、ＭＮが基地局ノード「ＢＳ３」に接続して相手端末ＣＮとの通信を開始し（VCOA=VCOA2，PCOA=PCOA3）、その後、通信を継続しながら別の基地局ノード「ＢＳ４」の在圏ゾーンへ移動した場合（VCOA=VCOA2，PCOA=PCOA4）を示しており、この場合、ＨＡでは、「現在のＣＯＡ」として“PCOA4”を保持し、「通信開始時のＣＯＡ」として“PCOA3”を保持することになる。
【０３７７】
これにより、ＭＡでは、例えば、受信パケットがＶＯＩＰパケットであればその受信パケットを「現在のＰＣＯＡ（＝PCOA4）」でカプセル化し、データパケットであれば「通信開始時のＰＣＯＡ（＝PCOA3）」でカプセルすることで、基地局ノード（ＢＳ３，ＢＳ４）をまたぐハンドオーバを行なう際に、パケット種別に応じたハンドオーバ方法（パケット転送ルート）の切り替えが可能となる（ＶＯＩＰパケットの場合は図６２に矢印８６，８６′，８７′に示すパケット転送ルート、データパケットの場合は図６２に示す矢印８６，８６′，８８′に示すパケット転送ルートとなる）。
【０３７８】
このようにして、本変形例では、通常の階層化Mobile-IP網におけるＨＡ及びＭＡのいずれにおいても、受信パケットの「トラフィック種別」（通信サービス）に応じた最適なハンドオーバ方法の切り替えを実現することができるので、通常の階層化Mobile-IP網においても、第２実施形態と同様に、ユーザが要求する複数種類のＱｏＳを満足する通信を柔軟に実現でき、常にユーザの要求に最適なハンドオーバ方法を提供してＱｏＳを大幅に向上させることが可能である。
【０３７９】
(E)その他
なお、上述した第２実施形態における「トラフィック種別」の識別は、「IPv6」のＩＰヘッダ７０に含まれる「ホップ制限数」（Hop Limit）フィールド７１６（図４５及び図４６等参照）〔「IPv4」ではＴＴＬ（Time To 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 Address）」フィールド
７２３，７２３ａ オプションタイプ（Option Type）フィールド
７２４ ホームアドレスフィールド
７２５ ＭＡアドレスフィールド
７２６ Ｍ３ネットワークアドレスフィールド
７２７ Ａ（Acknowledgement）ビットフィールド
７２８ リザーブ（reserved）ビットフィールド
７２９ ライフタイム（Lifetime）フィールド
７６１ 発信元ポート番号フィールド
７６２ 宛先ポート番号フィールド
７７１ ペイロードタイプフィールド
Claims (5)
- 移動端末と通信してパケットの送受を行ないうる複数のエッジノードと、該移動端末の現在位置情報を管理し当該現在位置情報に基づいて該移動端末宛のパケットを該移動端末がその現在位置から通信可能なエッジノード（以下、在圏エッジノードという）へルーティングしうるゲートノードとをそなえて成る階層化パケット網において、
該ゲートノードが、自己が管理する該移動端末の現在位置情報をキャッシュ情報として該移動端末宛のパケットを自己宛にルーティングしてくるエッジノード（以下、通信中エッジノードという）に通知し、
当該通信中エッジノードが、該キャッシュ情報に基づき該ゲートノードに代わって該移動端末宛のパケットの該在圏エッジノードに対するルーティングを実施し、
該エッジノードが、それぞれ、少なくとも自己を収容するゲートノードの識別情報（以下、ゲートノード識別情報という）と該階層化パケット網の識別情報（以下、網識別情報という）とを含む報知情報を該移動端末に送信し、
該移動端末は、該報知情報に含まれる該ゲートノード識別情報が自己の移動に伴って変化しても該網識別情報が変化していなければ、自己の現在位置情報の登録先を、前記自己の移動前の該ゲートノードに維持することを特徴とする、階層化パケット網におけるパケット転送方法。 - 移動端末と通信してパケットの送受を行ないうる複数のエッジノードと、該移動端末の現在位置情報を管理し当該現在位置情報に基づいて該移動端末宛のパケットを該移動端末がその現在位置から通信可能なエッジノード（以下、在圏エッジノードという）へルーティングしうるゲートノードとをそなえて成る階層化パケット通信システムにおいて、
該移動端末が、
該在圏エッジノードの識別情報に基づく位置情報を該現在位置情報として特定のゲートノードに通知して登録する現在位置登録手段をそなえるとともに、
該ゲートノードが、
該移動端末の該現在位置登録手段によって通知される該現在位置情報を管理する端末位置管理手段と、
該端末位置管理手段で管理されている該現在位置情報をキャッシュ情報として該移動端末宛のパケットを自己宛にルーティングしてくるエッジノード（以下、通信中エッジノードという）に通知するキャッシュ情報通知手段とをそなえ、且つ、
該エッジノードが、
該ゲートノードの該キャッシュ情報通知手段により通知されたキャッシュ情報を保持するキャッシュ手段と、
該キャッシュ手段に保持されている該キャッシュ情報に基づき該ゲートノードに代わって該移動端末宛のパケットの該在圏エッジノードに対するルーティングを実施するルーティング手段とをそなえて構成され、
該エッジノードが、それぞれ、少なくとも自己を収容するゲートノードの識別情報（以下、ゲートノード識別情報という）と該階層化パケット網の識別情報（以下、網識別情報という）とを含む報知情報を該移動端末に送信し、
該移動端末は、該報知情報に含まれる該ゲートノード識別情報が自己の移動に伴って変化しても該網識別情報が変化していなければ、自己の現在位置情報の登録先を、前記自己の移動前の該ゲートノードに維持することを特徴とする、階層化パケット通信システム。 - 移動端末と通信してパケットの送受を行ないうる複数のエッジノードと、該移動端末の現在位置情報を管理し当該現在位置情報に基づいて該移動端末宛のパケットを該移動端末がその現在位置から通信可能なエッジノード（以下、在圏エッジノードという）へルーティングしうるゲートノードとをそなえて成る階層化パケット通信システムに使用される該エッジノードであって、
該ゲートノードで管理されている、該在圏エッジノードの識別情報に基づく位置情報をキャッシュ情報として受けて保持するキャッシュ手段と、
該キャッシュ手段に保持されている該キャッシュ情報に基づき該ゲートノードに代わって該移動端末宛のパケットの該在圏エッジノードに対するルーティングを実施するルーティング手段とをそなえて構成され、
該エッジノードが、それぞれ、少なくとも自己を収容するゲートノードの識別情報（以下、ゲートノード識別情報という）と該階層化パケット網の識別情報（以下、網識別情報という）とを含む報知情報を該移動端末に送信し、
該移動端末は、該報知情報に含まれる該ゲートノード識別情報が自己の移動に伴って変化しても該網識別情報が変化していなければ、自己の現在位置情報の登録先を、前記自己の移動前の該ゲートノードに維持することを特徴とする、階層化パケット通信システムに使用されるエッジノード。 - 移動端末と通信してパケットの送受を行ないうる複数のエッジノードと、該移動端末の現在位置情報を管理し当該現在位置情報に基づいて該移動端末宛のパケットを該移動端末がその現在位置から通信可能なエッジノード（以下、在圏エッジノードという）へルーティングしうるゲートノードとをそなえて成る階層化パケット網における階層化パケット通信システムに使用される該移動端末であって、
少なくとも該在圏エッジノードを収容するゲートノードの識別情報（以下、ゲートノード識別情報という）と該階層化パケット網の識別情報（以下、網識別情報という）とを含む報知情報を、該在圏エッジノードから受信する報知情報受信手段と、
該報知情報受信手段で受信された報知情報に含まれる該ゲートノード識別情報が自己の移動に伴って変化しても該網識別情報が変化していなければ、自己の現在位置情報の登録先を、前記自己の移動前の該ゲートノードに維持する現在位置登録手段とをそなえたことを特徴とする、階層化パケット通信システムに使用される移動端末。 - 移動端末と通信してパケットの送受を行ないうる複数のルーティングノードと、該移動端末の現在位置情報を管理し当該現在位置情報に基づいて該移動端末宛のパケットを該移動端末がその現在位置から通信可能なルーティングノード（以下、在圏ノードという）へルーティングしうるゲートノードとをそなえて成る階層化パケット網において、
該ゲートノードが、自己が管理する該移動端末の現在の位置情報をキャッシュ情報として該移動端末宛のパケットを自己宛にルーティングしてくるルーティングノード（以下、通信中ノードという）に通知し、
当該通信中ノードは、
該移動端末の通信開始時の位置情報を管理しておき、
該移動端末宛の受信パケットの種別（以下、パケット種別という）を識別し、
該識別の結果、該受信パケットがパケットロスを許容する特性をもつパケット種別であると、該ゲートノードから通知されたキャッシュ情報に基づき該ゲートノードに代わって該受信パケットを該在圏ノードへルーティングし、
該識別の結果、該受信パケットがパケット転送遅延を許容する特性をもつパケット種別であると、該通信開始時の位置情報に基づいて該受信パケットを該ゲートノードへルーティングし、
該ルーティングノードが、それぞれ、少なくとも自己を収容するゲートノードの識別情報（以下、ゲートノード識別情報という）と該階層化パケット網の識別情報（以下、網識別情報という）とを含む報知情報を該移動端末に送信し、
該移動端末は、該報知情報に含まれる該ゲートノード識別情報が自己の移動に伴って変化しても該網識別情報が変化していなければ、自己の現在位置情報の登録先を、前記自己の移動前の該ゲートノードに維持することを特徴とする、階層化パケット網におけるパケット転送方法。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001174698A JP4340400B2 (ja) | 2001-04-27 | 2001-06-08 | 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 |
| EP20010122678 EP1263182B1 (en) | 2001-04-27 | 2001-09-28 | Packet routing in a hierarchical packet communication system |
| DE60137025T DE60137025D1 (de) | 2001-04-27 | 2001-09-28 | Paket-Leitweglenkung in einem hierarchischen Paketübertragungssystem |
| EP20060013365 EP1718024A1 (en) | 2001-04-27 | 2001-09-28 | Handover method and routing node for a packet network |
| 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 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001-133330 | 2001-04-27 | ||
| JP2001133330 | 2001-04-27 | ||
| JP2001174698A JP4340400B2 (ja) | 2001-04-27 | 2001-06-08 | 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003018192A JP2003018192A (ja) | 2003-01-17 |
| JP4340400B2 true 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) | EP1718024A1 (ja) |
| JP (1) | JP4340400B2 (ja) |
| DE (1) | DE60137025D1 (ja) |
Families Citing this family (90)
| 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 | 株式会社エヌ・ティ・ティ・ドコモ | ルーチング経路変更契機の検出方法、端末、及び、ルータ |
| US7436804B2 (en) * | 2002-09-18 | 2008-10-14 | Qualcomm Incorporated | 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 |
| US7630305B2 (en) * | 2003-07-29 | 2009-12-08 | Orbital Data Corporation | TCP selective acknowledgements for communicating delivered and missed data packets |
| US8270423B2 (en) | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| JP3993874B2 (ja) * | 2002-12-17 | 2007-10-17 | 富士通株式会社 | 負荷分散方法及びその装置 |
| US7657653B2 (en) | 2002-12-17 | 2010-02-02 | Fujitsu Limited | Load decentralization method and apparatus thereof |
| JP4088540B2 (ja) | 2003-03-03 | 2008-05-21 | 株式会社日立製作所 | パケット通信システム、通信ネットワーク、およびモバイルノードにおけるｉｐアドレス選択方法 |
| 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 |
| BRPI0506734A (pt) * | 2004-01-07 | 2007-05-15 | Matsushita Electric Ind Co Ltd | sistema de comunicação, terminal móvel, e, roteador de acesso |
| EP1703680A1 (en) * | 2004-01-07 | 2006-09-20 | Matsushita Electric Industrial Co., Ltd. | Communication system, mobile terminal and access router |
| JP3979390B2 (ja) * | 2004-01-14 | 2007-09-19 | 松下電器産業株式会社 | モバイルルータ装置およびホームエージェント装置 |
| 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 |
| 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 |
| US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private network |
| US8739274B2 (en) * | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
| AU2005266945A1 (en) * | 2004-07-23 | 2006-02-02 | Citrix Systems, Inc. | A method and systems for securing remote access to private networks |
| US8046830B2 (en) * | 2004-07-23 | 2011-10-25 | Citrix Systems, Inc. | Systems and methods for network disruption shielding techniques |
| US9197857B2 (en) * | 2004-09-24 | 2015-11-24 | Cisco Technology, Inc. | IP-based stream splicing with content-specific splice points |
| US8966551B2 (en) | 2007-11-01 | 2015-02-24 | Cisco Technology, Inc. | Locating points of interest using references to media frames within a packet flow |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| EP1842354B1 (en) | 2005-01-24 | 2014-11-05 | Citrix Systems, Inc. | Systems and methods for performing caching of dynamically generated objects in a 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 | 주식회사 팬택앤큐리텔 | 인터넷 프로토콜 주소 운용 방법 |
| JP2008543120A (ja) * | 2005-05-31 | 2008-11-27 | 松下電器産業株式会社 | パケット転送制御方法及びパケット転送制御装置 |
| US9344934B2 (en) | 2005-06-21 | 2016-05-17 | Google Technology Holdings LLC | Method and apparatus for reducing latency during wireless connectivity changes |
| US8144687B2 (en) | 2005-06-21 | 2012-03-27 | Motorola Mobility, Inc. | Method, apparatus and system for establishing a direct route between agents of a sender node and a receiver node |
| WO2007001948A2 (en) | 2005-06-21 | 2007-01-04 | Motorola, Inc. | Method and apparatus to facilitate communications using surrogate and care-of internet protocol addresses |
| GB2440703B (en) | 2005-06-21 | 2009-11-11 | Motorola Inc | System and method for paging and location update in a network |
| WO2007001954A1 (en) | 2005-06-21 | 2007-01-04 | Motorola, Inc. | Method and apparatus to facilitate mobile station communications using internet protocol-based communications |
| CN101204099B (zh) | 2005-06-21 | 2011-09-07 | 摩托罗拉移动公司 | 基于地址解析协议的无线接入点 |
| WO2007001951A2 (en) | 2005-06-21 | 2007-01-04 | Motorola, Inc. | System and method for providing a distributed virtual mobility agent |
| 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 |
| 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 |
| US7773571B1 (en) * | 2006-02-03 | 2010-08-10 | Nortel Networks Limited | Transfer of policy and charging rules during MIP handover |
| JPWO2007119635A1 (ja) * | 2006-03-27 | 2009-08-27 | 日本電気株式会社 | フレーム転送経路確認方法、ノード、そのプログラム及びフレーム転送経路確認システム |
| WO2008013218A1 (fr) * | 2006-07-28 | 2008-01-31 | Panasonic Corporation | Procédé de communication mobile et routeur d'accès |
| 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 | パナソニック株式会社 | ネットワーク・ベース及びホスト・ベースの混合モビリティ管理における方法 |
| CN101536580B (zh) * | 2006-11-16 | 2012-02-22 | 株式会社Ntt都科摩 | 通信控制装置和通信控制方法 |
| 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 |
| US7936695B2 (en) * | 2007-05-14 | 2011-05-03 | Cisco Technology, Inc. | Tunneling reports for real-time internet protocol media streams |
| US8023419B2 (en) | 2007-05-14 | 2011-09-20 | Cisco Technology, Inc. | Remote monitoring of 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 | 삼성전자주식회사 | 근거리 네트워크에서 물품 정보를 제공하는 시스템 및 방법 |
| WO2009067227A1 (en) * | 2007-11-21 | 2009-05-28 | Nortel Networks Limited | Support for continuity of tunnel communications for mobile nodes having multiple care of addressing |
| JP5181811B2 (ja) | 2008-05-01 | 2013-04-10 | 富士通株式会社 | アクセスポイント、アクセスポイントの従属先決定方法、及び無線通信システム |
| 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 |
| US8717895B2 (en) | 2010-07-06 | 2014-05-06 | Nicira, Inc. | Network virtualization apparatus and method with a table mapping engine |
| US9680750B2 (en) | 2010-07-06 | 2017-06-13 | Nicira, Inc. | Use of tunnels to hide network addresses |
| 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 | 安徽华云安科技有限公司 | 组网方法、电子设备及计算机可读存储介质 |
Family Cites Families (11)
| 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 | 富士通株式会社 | 移動パケット通信システム |
| ATE305695T1 (de) | 1999-07-19 | 2005-10-15 | British Telecomm | Routing in einem paketvermittlungsnetz mit mobilendstationen |
| 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 | 株式会社エヌ・ティ・ティ・ドコモ | 移動無線パケット通信システムにおける移動端末機の位置管理方法及びその移動無線パケット通信システム |
| US20030021275A1 (en) * | 2000-03-31 | 2003-01-30 | Mohammed Shabeer | Mobile data routing |
| US6999436B2 (en) * | 2001-04-16 | 2006-02-14 | Nokia Corporation | Method and apparatus for efficient routing of mobile node packets |
-
2001
- 2001-06-08 JP JP2001174698A patent/JP4340400B2/ja not_active Expired - Fee Related
- 2001-09-28 EP EP20060013365 patent/EP1718024A1/en not_active Withdrawn
- 2001-09-28 US US09/967,447 patent/US20030026241A1/en not_active Abandoned
- 2001-09-28 EP EP20010122678 patent/EP1263182B1/en not_active Expired - Lifetime
- 2001-09-28 DE DE60137025T patent/DE60137025D1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US20030026241A1 (en) | 2003-02-06 |
| EP1263182B1 (en) | 2008-12-17 |
| EP1263182A2 (en) | 2002-12-04 |
| DE60137025D1 (de) | 2009-01-29 |
| EP1718024A1 (en) | 2006-11-02 |
| JP2003018192A (ja) | 2003-01-17 |
| EP1263182A3 (en) | 2005-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4340400B2 (ja) | 階層化パケット網におけるパケット転送方法並びに階層化パケット通信システム並びに同システムに使用されるエッジノード及び移動端末並びに階層化パケット網におけるパケット転送方法 | |
| EP1011241B1 (en) | Wireless access to packet-based networks | |
| EP1009134B1 (en) | Packet tunneling optimization to wireless devices accessing packet-based wired networks | |
| JP3568852B2 (ja) | 有線サブネットにアクセスする無線デバイス用にパケット経路設定アドレスを割り当てる方法及び装置 | |
| EP1009141B1 (en) | Two phase local mobility scheme for wireless access to packet-based networks | |
| EP1011243B1 (en) | Single phase local mobility scheme for wireless access to packet-based networks | |
| US7623499B2 (en) | Mobile terminal management system, mobile terminal, agent, and program | |
| JP4462042B2 (ja) | ルータ選択方法、ホームエージェント装置、移動ルータ、および移動ネットワークシステム | |
| US6925075B2 (en) | Method and system for inter-operability between mobile IP and RSVP during route optimization | |
| EP1206098B1 (en) | Home agent and IP packet transferring method | |
| US20010012777A1 (en) | Mobile communications system and method thereof | |
| JP4546858B2 (ja) | モバイル通信におけるＱｏＳ設定方法及びＱｏＳ設定システム並びに該システムに用いる移動端末装置、ホームエージェント、サーバ装置 | |
| JP4088540B2 (ja) | パケット通信システム、通信ネットワーク、およびモバイルノードにおけるｉｐアドレス選択方法 | |
| US20100296443A1 (en) | System, method and apparatus for route-optimized communication for a mobile node nested in a mobile network | |
| WO2013007133A1 (zh) | 报文转发路径管理方法、系统及网元 | |
| JP2008541516A (ja) | ＩＰｖ６通信相手ノード及び移動ＩＰｖ６ノード間の通信方法、並びに通信相手ノードプロキシーゲートウエイ | |
| Sun et al. | Mobile IP applicability: When do we really need it? | |
| Mah-Rukh | Internet Mobility using SIP and MIP | |
| US8194627B1 (en) | Apparatus and method for communication with a mobile communications device in an IP network | |
| WO2009116276A1 (ja) | 通信方法、通信システム、通信ノード、移動通信装置、移動管理装置及び中継ノード |
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 |