JP2010541302A - 移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 - Google Patents
移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 Download PDFInfo
- Publication number
- JP2010541302A JP2010541302A JP2010512444A JP2010512444A JP2010541302A JP 2010541302 A JP2010541302 A JP 2010541302A JP 2010512444 A JP2010512444 A JP 2010512444A JP 2010512444 A JP2010512444 A JP 2010512444A JP 2010541302 A JP2010541302 A JP 2010541302A
- Authority
- JP
- Japan
- Prior art keywords
- map
- vmn
- aro
- rcoa
- node
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 135
- 238000004891 communication Methods 0.000 title claims description 25
- 230000008569 process Effects 0.000 claims description 41
- 230000011664 signaling Effects 0.000 claims description 30
- 238000005457 optimization Methods 0.000 abstract description 20
- 230000027455 binding Effects 0.000 description 57
- 238000009739 binding Methods 0.000 description 57
- 230000007246 mechanism Effects 0.000 description 29
- 238000012545 processing Methods 0.000 description 29
- 238000011144 upstream manufacturing Methods 0.000 description 13
- 230000000694 effects Effects 0.000 description 12
- 230000008859 change Effects 0.000 description 10
- 238000012360 testing method Methods 0.000 description 10
- 230000008901 benefit Effects 0.000 description 7
- 230000005641 tunneling Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 5
- 230000004044 response Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005538 encapsulation Methods 0.000 description 3
- 238000009448 modified atmosphere packaging Methods 0.000 description 3
- 235000019837 monoammonium phosphate Nutrition 0.000 description 3
- 239000002699 waste material Substances 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 230000001627 detrimental effect Effects 0.000 description 2
- 238000013467 fragmentation Methods 0.000 description 2
- 238000006062 fragmentation reaction Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- PAZZVPKITDJCPV-UHFFFAOYSA-N 10HSA Natural products CCCCCCCCC(O)CCCCCCCCC(O)=O PAZZVPKITDJCPV-UHFFFAOYSA-N 0.000 description 1
- 101100263503 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) vma-10 gene Proteins 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- 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/082—Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
-
- 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
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
- H04W80/045—Network layer protocols, e.g. mobile IP [Internet Protocol] involving different protocol versions, e.g. MIPv4 and MIPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/005—Moving wireless networks
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【解決手段】 本発明は、アクセス・ルータ・オプション・プロトコルや階層モビリティ管理プロトコルなどのエンド・ツー・エンド経路最適化プロトコルが移動ホストや移動ルータに実装される異種プロトコルシナリオにおいて発生するルーティングの準最適性問題を克服するため、3つの方法を提供する。第1の方法は、訪問移動ノード又は移動ルータがアクセス・ルータ・オプション・ベースの経路最適化を他のノードと行いたい場合、そのローカル気付アドレスをその気付アドレスとして使用する。第2の方法は、訪問移動ノードや移動ルータが他のノードと階層モビリティ管理を行うことを決定する場合、そのリージョナル気付アドレスをその気付アドレスとして使用する。第3の方法は、アーキテクチャ内にレガシー・モビリティ・アンカー・ポイントが存在する場合、移動ルータはそのルータ通知内において、モビリティ・アンカー・ポイント・オプションを送信しない。
Description
本発明は、パケット交換データ通信ネットワークにおける電気通信分野に関し、特に、エンド・ツー・エンド型経路最適化プロトコル及び階層化モビリティ管理プロトコルが実装された、単一のモビリティ・アンカー・ポイントが存在するシステムにて動作する移動ノードに最適経路を提供することに関する。
今日、多くのデバイスは、インターネット・プロトコル・バージョン6(IPv6)を用いて相互に通信を行っている。モバイル機器のモビリティ・サポートを提供するために、インターネット技術調査会(IETF)は、「IPv6でのモビリティ・サポート(MIPv6)」[非特許文献1]を作成した。[非特許文献1]におけるモビリティ・サポートは、ホーム・エージェント(HA)と呼ばれるホーム・ネットワークにおけるエンティティの導入により行われる。移動ノード(MN)は、バインディング・アップデート(BU)と呼ばれるメッセージにより、ホーム・エージェントに、外部リンク内でMNが入手する自身の気付アドレスを登録する。これにより、ホーム・エージェントは、ホーム・リンク内で入手した長期アドレスであるホーム・アドレスと、移動ノードの気付アドレス間でバインディングを生成できる。ホーム・エージェントは、移動ノードのホーム・アドレス(HoA)宛てのメッセージを受信し、パケットのカプセル化(すなわち、1つのパケットを新しいパケットのペイロードにすることであり、パケット・トンネリングとも呼ばれる)により、移動ノードの気付アドレスにパケットを転送する。また、MIPv6は、通信相手ノード(CN)との通信の際の経路最適化(RO)方法を定める。このROメカニズムにより、MNとCNがホーム・エージェントを経由せずにMNの気付アドレスにより相互に通信を行うことができるよう、MNはCNにおいてその気付アドレスの有効な登録を行うことができる。CNでは、MNによって開始されるリターン・ルータビリティ(RR)テストにより、MNの気付アドレスの有効な登録が行われる。このリターン・ルータビリティ・テストにより、CNは、MNの気付アドレスとMNのホーム・アドレスとが結び付けられているという証明を得ることができる。上記ROメカニズムは任意のものであり、CNがROメカニズムをサポートする何らかの機能性を有する場合にのみその利点が発揮されることとなる。
MIPv6の問題点の一つとして、MNは、ネットワーク接続におけるたった一つの変更に対し、一つ又は複数のホーム・エージェント及び一つ又は複数の通信相手ノードを更新しなければならないということが挙げられる。これにより、高速で移動しているMNのためにネットワークへ投入されるシグナリング負荷が増大する。また、ネットワーク接続における一つ一つの変更がRR及びBUメッセージの送信を伴うため、ネットワーク接続における変更ごとのCNとの平均ハンドオフ確立時間は長くなる。そのため、フロー又は接続に関連するセッション中は、かなりの時間がハンドオフの確立に割り当てられ、それによりジッターやパケット・ロスが生じることとなる。上記ジッターは、ボイス・オーバーIP(VoIP)、マルチメディア、ビデオ・ストリーミングなどのアプリケーションに弊害をもたらすものであり、また、上記パケット・ロスは、重要なテキスト情報を運ぶフローに弊害をもたらすものである。さらに、パケット・ロスは、伝送制御プロトコル(TCP)を情報重要データ・アプリケーションに利用する場合、TCPスループットを低下させる。
そのようなMIPv6の問題に対処するため、IETFは、[非特許文献2]に開示されている階層化モビリティ管理プロトコル・バージョン6(HMIPv6)と呼ばれるプロトコルの標準化を行った。HMIPv6は、二種類の気付アドレスと、モビリティ・アンカー・ポイント(MAP)と呼ばれる新しいノードとを用いる。その基本原理としては、MNは、それが接続されている新しいネットワークにおいて、二つの気付アドレスを取得する。その二つの気付アドレスの内の一方は、ローカル気付アドレス(LCoA)と呼ばれ、MNが直接接続されているネットワークから入手したアドレスである。また、その他方のアドレスは、リージョナル気付アドレス(RCoA)と呼ばれ、MAPのネットワーク・プレフィックスから得られる。RCoAは、MNがCN及びHAと通信する際に気付アドレスとして用いるアドレスである。MAPは好ましくはルーティング階層の上位に置かれる固定ルータであるので、このRCoAは頻繁に変更されることはない。MAP情報が入手可能なネットワーク・セグメント内でMNがローミングする限り、リージョナル気付アドレスが変更されることはない。このプロトコルでは、ネットワーク接続におけるすべての変更についてのハンドオフ確立処理には、主に、LCoAが登録されているMAPが用いられる。MNがMAP外へ移動し、それによりRCoAが変更される時にのみ、MAP、CN、HAに対して更新又はハンドオフ確立が同時に行われる。従って、ネットワーク接続における変更ごとのネットワークへのシグナリング負荷は、平均して、MIPv6に比べてかなり低い。さらに、ネットワーク接続におけるすべての変更についてのハンドオフ確立時間は、平均して短い。これは、大抵の場合、ハンドオフが、ローミングMNにごく接近したところに位置するMAPでの単純なLCoA登録だけで済まされるためである。このため、前述のジッターやパケット・ロスなどの問題はここではずっと少ない。このプロトコルは、フローに省電力化を必要とするノード、及び、厳しいQoSパラメータを求めるフローを運ぶノードに使用される、広く認められた標準プロトコルである。
無線デバイスがますます普及する中、複数のノードからなるネットワーク全体がその接続点を変えるネットワークモビリティ、すなわちNEMOのような 新しいタイプのモビリティ技術が出現することが予見される。IETFは、[非特許文献3]に開示されている基本的なネットワーク・モビリティ・サポートに対する解決法を開発した。この場合、移動ルータ(MR)は、BUをホーム・エージェントに送信する際、移動ネットワーク内のノードが使用しているネットワーク・プレフィックスを指定するよう規定されている。これらは、BU内に挿入するネットワーク・プレフィックス・オプションと呼ばれる特別なオプションにより指定される。これらにより、ホーム・エージェントは、ホーム・エージェントが、これらのプレフィックスと共に宛て先に送信された任意のパケットを移動ルータの気付アドレスへトンネルするように、プレフィックス・ベースのルーティング・テーブルを作成できる。
MNがNEMOに深くネストされると、二種類の問題が発生する。一つ目の問題としては、多重カプセル化のオーバーヘッドや、データ・パケットの準最適ルーティングが挙げられる。これは、ネスト状態のNEMOにおける、ネスト状態のトンネリングによるものである。多重カプセル化は、パケット・サイズの増大に起因するデータ・パケットの遅延を引き起こし、さらに、パケット・フラグメンテーションを招くこともある。さらに、パケット・フラグメンテーションは、データ・パケット・ロスを引き起こすこともある。準最適ルーティングは、データ・パケットの遅延、ネットワーク負荷の増大、HAの処理負荷増大につながる。
二つ目の問題としては、深くネストされたMNに対するレイヤ3ハンドオフ確立の大幅な遅延や、RR及びBUストリームのシグナリング・オーバーヘッドに起因してネットワークへ投入される高いシグナリング負荷が挙げられる。これは、MNが深くネストされ、ネットワーク接続に変更があったため、新しい気付アドレスがCN又はHAにて更新する必要がある場合、このような登録には、ハンドオフ登録に関与するパケットが多重にカプセル化され、大幅な遅延が発生するからである。前述のように、ハンドオフ遅延時間の増加は、高速で移動するMNによって運ばれるフローの全セッション又は接続時間に大きく関係し、それによりジッターやパケット・ロスが生じることとなる。さらにまた、一定期間内でのMNによる過度のハンドオフ確立シグナリングは、ネットワーク内で運ばれるその他のフローにも影響を及ぼすことになる。
一つ目の問題を解決するため、関連技術分野における、いわゆるネスト状態のトンネルの最適化に関して様々な提案がなされている。具体的には、[非特許文献4]には、アクセス・ルータ・オプション(ARO)と呼ばれる解決法が開示されている。送信者(すなわち、移動ルータ又は移動ホスト)は、このアクセス・ルータ・オプションと呼ばれる新しいオプションを使って、受信者(例えば、ホーム・エージェント又は通信相手ノード)に、該送信者が接続されているアクセス・ルータの一次グローバルアドレスを知らせる。移動ノードは、アクセス・ルータ・オプションと共にバインディング・アップデート・メッセージを送信後、送信するデータ・パケットに「直接転送要求」シグナルと呼ばれる特別なシグナルを挿入できる。このシグナルにより、上流の移動ルータは自身のバインディング・アップデートを宛先アドレスに送信する。この処理は、最上流の移動アクセス・ルータに達するまで繰り返される。上流のすべての移動アクセス・ルータがバインディング・アップデートを宛先に送信することで、宛先では、移動ノードが接続されている移動ルータの連鎖を形成できる。これは、拡張タイプ2ルーティングヘッダ(RH2)の作成に利用できるため、宛先ノードがパケットを移動ノードに送り返したい場合、ルーティング・ヘッダを有するパケットを埋め込むことができ、パケットが移動アクセス・ルータの連鎖を介して移動ノードへ直接転送される。この方法は、エンド・ツー・エンド型経路最適化を、セキュリティーを犠牲にせずに実現するのに適した方法であると考えられる。
二つ目の問題を解決し、一つ目の問題を部分的に解決するため、[非特許文献5]には、ネスト状態のトンネリングやレイヤ3(L3)ハンドオフ確立の遅延などの問題へ対処する設計が開示されている。この方法では、ハンドオフ効率及びシグナリング・オーバーヘッドの改善、MAP環境においてネストされたMNのエンド・ツー・エンド型経路最適化の適切な実行を図る。この方法において、すべてのMN(本稿では移動ホストとする)は、HMIPv6で規定された通りに動作する。MNは、ローカル・ネットワーク接続におけるそれぞれの変更については、そのLCoAをMAPにて更新し、RCoA又はMAPドメインにおけるそれぞれの変更については、そのCNとHAに対してRCoAを更新する。この方法では、MRは、MNに対し、HMIPv6プロトコルで規定された通りに動作するが、若干の変更も伴うものとする。MRは、ルータ・モードで動作する場合、そのルータ通知(RA)におけるMAPオプションを通知し、それに接続されているMNへとMAPサービスを拡大する。さらに、MAPがMNのLCoAに到達する最適経路をトレースするのを助けるため、MRは、純粋なHMIPv6タイプの登録の代わりに、MAPにてプレフィックス・スコープ・バインディング・アップデート(PSBU)を行う。MNがいくつかのMRの配下に深くネストされているとすると、MAPのバインディング・キャッシュは、MNのLCoAとRCoAのほかに上流のMRのLCoA、RCoA、MRのプレフィックスも有することとなる。MAPが、MNの上流のMRに関連するすべてのLCoAの位置を特定するのに、このプレフィックスをいかに利用可能であるかは当業者には公知である。このようなトレースが可能であるのは、MN又はMRのLCoAがそのアクセス・ルータのプレフィックスから得られているからである。
MNに関連するRCoAのMAPにデータ・パケットが到着すると、MAPは、まず、このRCoAの位置を特定し、その後、バインディング・キャッシュ・エントリ(BCE)からそのRCoAに関連する対応LCoAを見つけ出す。続いて、MAPは、このMNのLCoAに一致するプレフィックスを検索する。これにより、MAPは、MNの直結する移動アクセス・ルータの位置パラメータを見つけ、上流のすべてのMRのLCoAが得られるまで上記処理を繰り返すことができる。そのようにMAPにてトレースが繰り返し行われると、上流のすべてのMRのLCoAから成るトンネルにルーティング・ヘッダを挿入することで、データ・パケットがMNにトンネルされる。HMIPv6と同様、パケットをCNへ送信する場合、MNは、まず、MAPへと続くトンネルにパケットをカプセル化する。MNの上流のすべてのMRは、MAPにバインディングを有するので、MAPへと続く別々のトンネルにさらにパケットをカプセル化する。この方法によって最終的に得られる効果としては、受信データ・パケットには、拡張ルーティング・ヘッダを有するMAPからのトンネルが単一となるということである。送信データ・パケットには、無線ドメインにおいてMN/MRからMAPへ多重カプセル化が行われる。このプロトコルは、主に、NEMOに深くネストされたMNに対するハンドオフやシグナリングの向上を図るものであることを理解することが重要である。この方法を[非特許文献4]に開示されているようなARO方式と比較する場合、ARO方式は、より優れたエンド・ツー・エンドROを実現することを理解することが重要である。これは、AROでは、無線ドメインには逆方向にトンネルが存在しないのに対し、[非特許文献5]の無線ドメインには複数のトンネルが存在するためである。また、AROでは、順方向にトンネルが存在しない。
上記から予見し得るのは、データ・フロー、端子、ネットワークの目的を達成するためには、今後、複数の異なるタイプのプロトコルをシステムに実装する必要がある可能性があるということである。データ・フローについて言えば、その主な目的は、遅延、ジッター、パケット・ロスを軽減することである。ネットワークにより認識されるQoSに関する主な目的は、ネットワーク負荷、もっと正確には、ネットワークへのシグナリング負荷を軽減することである。MNに関する目的は、省電力化である。従って、これらのすべての目的を一つの目標として組み合わせるためには、複数のプロトコルをシステムに実装する必要がある可能性が非常に高い。MNは、今後、異なるQoSニーズを持つ異なるタイプのフローをサポートすることが必要になるかもしれない。例えば、MNは、厳しいエンド・ツー・エンドROを必要とするいくつかのフローと、それほど厳しいエンド・ツー・エンドROを必要としないいくつかのフローとを運ぶ必要が生じる可能性ある。それほど厳しいエンド・ツー・エンドROを必要としないフローについては、MNは、ネットワークに投入されるシグナリング負荷の向上を考慮し、頻繁に行われるバインディング・アップデートを軽減し省電力化を図ることが必要になるかもしれない。このように、MN、MR、いくつかの主要なルータ、CNには、今後、異なるタイプの複数のプロトコルを実装する必要があるということが予見し得る。
今後出現し得るシナリオとしては、ARO及びHMIPv6プロトコルの両方が一つのMN/MRに実装され、これらのノードが異なる種類のMAPが存在するグローバル通信ネットワークにおいてローミングするというシナリオがある。上記MAPは、[非特許文献2]に開示されているようなレガシーHMIPv6タイプのMAPであってもよいし、[特許文献3]に説明されているようないくつかのRO機能を有するMAPであってもよい。次に、このようなシナリオにおいて、MN及びMRがそれらに実装されているARO及びHMIPv6プロトコルに関連する標準メカニズムに従って動作する場合のシステム内でのシグナリング及びデータ・パケット・ルーティングについて分析する。図1では、このシナリオについてさらに詳しく説明する。
ネットワーク・アーキテクチャ内に一つのモビリティ・アンカー・ポイントMAP40が存在するシステムを図1に示す。このMAPは、レガシーHMIPv6タイプのMAP、ARO対応MAPなどのRO機能を有するMAP、プレフィックスを委譲しプレフィックス・スコープ・バインディング・アップデートを処理するMAP、若しくは、プレフィックスは委譲しないが、適切な検証によりPSBUを処理するMAPであってもよい。このシナリオでは、MAPに関連するRO処理機能の詳細に注目せずに、レガシーMAPやRO機能を有するMAPにおける、ルーティングの準最適性問題やその他の問題について分析する。
訪問移動ノード(VMN)10は、NEMO101内に位置し、無線リンクを介してMR20に接続されている。MR20は、NEMO102内に位置し、無線リンクを介してMR21に接続されている。MR21は、無線アクセスネットワーク103内に位置し、無線リンクを介してAR30に接続されている。AR30は、固定アクセスネットワーク104内に位置し、有線リンクを介してMAP40に接続されている。MAP40は、有線リンクにより固定アクセスネットワークを介してグローバル通信ネットワーク100(インターネット)に接続されている。MR20とMR21のホーム・エージェントは、それぞれ、HA51、HA50である。VMN10のホーム・エージェントは、明確には図示されていない。VMN10は、グローバル通信ネットワーク100に接続されているCN60と、データ通信セッションを行っている。
このシナリオでの問題点を明らかにするために、まず、レガシーHMIPv6タイプのMAPを考察する。このようなシナリオでは、VMN10やMR20は、受信するルータ通知内のAROオプションとMAPオプションの両方を入手する。MR21はMAPオプションのみを入手する。VMNとMRは、そのような異なる種類の処理オプションを入手可能である場合、いずれかのオプション又はオプションの組み合わせを選択できる。ここでは、このシナリオで生じる特定の事例を用いて問題を明らかにするが、同様の問題がこのシナリオの他の事例でも生じることは当業者であれば容易に理解し得ることである。VMN10がAROオプションとMAPオプションの両方を処理し、MR20がAROオプションのみを処理し、MR21がMAPオプションのみを処理するものとする。本シナリオのこのような事例では、MR21は、MAPオプションを処理して、RCoAとLCoAを入手し、MAP40にてローカル・バインディング登録を行う。このことは、図1のMAP40のバインディング・キャッシュ(BC)71に詳しく例示されている。問題点を明らかにするために、まずレガシーMAPを考察する。そこで、MAPではROトレース・パラメータを許容又は利用するための方法が得られないことから、BC71の第3列は空欄になっている。MR20は、AROオプションを処理するだけなので、MAP40では一切登録を行わない。VMN10は、AROオプションとMAPオプションとを処理した後、RCoAとLCoAを設定する。VMN10は、次に、AROオプションを用いてMAPでのローカル登録を試みる。上記AROオプション内の値は、RCoAに関連するLCoAを最適にトレースするのに有用であり得る値であればよい。MAPは、レガシータイプのMAPなので、AROオプションを理解せず、そのオプションを無視し、そのBC71内で通常のHMIPv6登録を行う。このVMN10によってMAP40で行われた登録をBC71の第2行に示す。VMN10は、MAP40にて適切に登録を行った後、そのホーム・エージェントにて登録を行うが、経路最適化を達成するためにCN60とAROメカニズムを実行することが可能である。VMN10がCNとAROを実行するのは、VMNが初めにMAPオプションを処理し、その後AROオプションを処理するためである。また、VMN10は、初めにMAPオプションを処理し、その後AROオプションを処理するので、CN60とAROを実行する際、RCoAをそのCoAとして利用する。CN60にて上記AROバインディングが行われると、BC70の第1行目に示すようなエントリが表示される。BC70は、CN60でのバインディング・キャッシュである。CN60は、RH2にMR20のHoAを含む確認応答(ACK)を送信する。MR20は、ACKを受信すると、CN60がそのHoAとのバインディングを有していないことを知り、CN60にてAROメカニズムを開始する。CN60にて良好にAROメカニズムが行われると、MR20のパラメータを有する第2行目のエントリがBC70に表示される。MR20は、AROオプションのみを処理するので、CN60との通信にはそのCoAとしてLCoAのみを使用することを理解することが重要である。それに続いて、CN60は、再度、RH2にMR21のHoAを含むACKを送信する。MR21は、このパケットを受信すると、そのRCoAを用いてCN60でARO登録を行う。MR21がRCoAを用いてARO登録を行うのは、MR21は、MAPオプションを処理することでRCoAを設定したが、AROスタックによりMR20に送信されたACKを処理するためである。この登録をBC70の第3エントリで示す。CN60がBC70を使ってデータ・パケット80をVMN10に送信する場合、そのデータ・パケットは深刻な経路の準最適性問題に直面する。
CN60からのデータ・パケット80は、宛先アドレスとしてMR21のRCoAを有する。ルーティング・ヘッダ2には、MR20のLCoA、VMN10のRCoA、VMN10のHoAが含まれる。このパケット80は、まず、パス110を介して送信される。パケットは、最初にMAP40に受信される。MAP40には、MR21のRCoAの登録がされているため、このパケットをMR21のLCoAへのトンネルにカプセル化する。このトンネルは明確には図示されていない。トンネルされたパケットは、再度パス110を介して、MR21に到達する。MR21は、デカプセル化を行った後、宛先アドレスをMR20のLCoAへ変更する。MR21は、パケット80に付加されたRH2から、この次の宛先アドレスを入手する。こうして、パケットは110を介してMR20に到達する。MR20は、宛先をVMN10のRCoAに再度変更する。MR20にはVMN10のRCoAに最適に到達するための登録がされていないため、パケットはMR20のホーム・エージェントHA51を介してトンネルされる。このパケットは、パス111を移動し、再びMR21にてMAP40及びMR21のホーム・エージェントHA50を介してさらにトンネルされる。この多重カプセル化されたパケットは、MAP40にてデカプセル化され、HA50でも再びデカプセル化され、最後にHA51にてデカプセル化され、最終的にはMAP40に受信される。ここで留意すべき重要な点は、これらすべての手順がパス111により明らかにされているということである。このことは、図1が複雑になるのを抑えるため明確には図示されていないが、当業者にとってはこれらのルーティング処理はごく単純な処理である。MAP40は、このパケット80を受け取ると、VMN10のRCoAへの登録がないことを認識する。このパケットは112を介してMR20のホーム・エージェント、すなわちHA51へと移動する。そこでパケット80はMR20のLCoAへさらにカプセル化される。このパケットは、その後、パス113を移動してMR21のホーム・エージェントであるHA50に到達する。ここで、パケットはMR21のRCoAへさらにカプセル化される。こうして、多重カプセル化されたパケットはパス114を移動しMAP40に到達する。ここで、パケットはMR21のLCoAへさらにカプセル化され、その後パス115を移動する。このパケットをデカプセル化しMR21にデカプセル化され、MR20のLCoAへ到達する。そこでパケットは再びデカプセル化され、VMN10のLCoAに到達する。パケットは再度VMN10にてデカプセル化され、最終的にはVMN10に消費される。
Johnson,D.B.、Perkins,C.E.及びArkko,J.、"Mobility Support In Ipv6" Internet Enginereing Task Force Requests For Comments 3775 June 2004
Soliman,H.他、"Hierarachical Mobile IPv6 Mobility Management (HMIPv6)" Internet Engineering Task Force (IETF) Requests For Comments(RFC)4140、August 2005
Devarapalli,V.他、"NEMO Basic Support Protocol" Internet Engineering Task Force Requests For Comments 3775 Junuary 2004
C.Ng、J.Hirano、"Secured Nested Tunnels Optomization with Router Access Option"IETF Internet Draft:draft−ng−nemo−access−router−option−01.txt、July 12, 2004
Ohnishi,H.、Sakitani,K.、Takagi,Y.、"HMIP based Route Optimization Method in Mobile Network"IETFInternet Draft:draft−ohnishi−nemo−ro−hmip−00.txt、October 2003
上記パケットルーティング処理の詳細な説明から、問題は多種多様にわたることが明らかである。それらの問題を以下にさらに詳しく見てみる。一つ目の重大な問題としては、VMN10は、両方のタイプのオプションを取得しMAP40がレガシータイプのMAPであることを知らないので、MAP40に対してAROバインディングを行うが、それはMAP40(レガシーMAP)には認識されない。これにより、VMN10のアクセスネットワークにおける帯域幅が浪費され、VMN10の消費電力が増大する。二つ目の問題としては、CN60のバインディング・キャッシュ70が、MAP40とMRの間のピンポンタイプのルーティング問題を引き起こす。例えば、CN60からのデータ・パケット80の最終目的地は、VMN10のHoAであるが、ここに到達するには異種のアドレス(MR21のRCoA、MR20のLCoA、VMN10のRCoA)を介してパケットを送信しなければならない。この文脈における「異種」とは、RCoA及びLCoAのエントリが混在している状態を意味する。最終目的地に至るまでにこれらの各エントリに到達しなければならない。そのため、データ・パケットが異なる種類のアドレスを含む場合、RCoAに関連するLCoAに到達後、若しくは、直接LCoAに到達後、RCoAである可能性があるRH内の次のエントリに到達しなければならない場合もある。MRはある特定のRCoAへの経路を有していないので、このパケットは、適切なルーティングを行うため、MAPに到達する必要がある。これがピンポン・ルーティングであり、パス110、111、115に示されている。さらに、VMN10へのデフォルト・パス上の移動ルータはどんな種類のオプションでも処理することが可能であり、従ってVMN10の上流MRはMAPでは登録を行わないこともあるので、上記シナリオではこのピンポン・ルーティングが深刻である。このため、MAPドメインにおいてMRからMAP40に到達するには、MRがAROオプションのみを処理した場合、上流MRはそのホーム・エージェントを介してパケットをトンネルしなければならない場合がある。これらすべてのことは、CN60からのデータ・パケット80に異なる種類の気付アドレスが存在することに直接付随するルーティングの準最適性を示している。
次に、このシナリオでの三つ目の問題を検証する。この問題は、MAPにて最適にRCoAをトレースすることに関連する。このシナリオでは、MAP40は、レガシーMAPであるので、最適にRCoAに到達するのに必要なLCoAをトレースするためのROメカニズムを持っていない。上記LCoAには、RCoAに直接関連するLCoAと、上記RCoAに到達するために通過する必要のある上流MRのLCoAとが含まれる。この問題をさらに詳しく説明するため、BC71を考察する。例えば、RCoAをトレースできるトレース機構が存在しない。レガシーMAPシナリオでは、第3列が空欄となっているものとする。この場合、RCoAに関連するLCoAに最適に到達するためのトレース機構がないことから、パケットは、固定インフラにおける、ホーム・エージェント間でトンネルされ受信されなければならない。これにより、固定インフラ内でピンボール・ルーティングが生じる。これは図1中にパス113により示されている。このルーティングパスの準最適性に加えて、上述のパケットパスについての詳しい説明から、パケットは多重カプセル化処理される必要があることが明らかである。これにより平均パケット・サイズが増大し、それが四つ目の問題を引き起こす一因となる。また、パケット80はシステム内の多数のルータによりデカプセル化されることも示唆した。これが処理遅延やルータにおける処理負担を引き起こし、五つ目の問題となる。これらすべての不具合が示すものは、AROやHMIPv6などの異種プロトコルが動作し、一つのMAPがレガシータイプである場合におけるシステムの非効率性である。
次に、図1のMAP40があるRO機能を有する場合のシナリオを考える。MAP40がレガシーMAPではなく(あるRO機能を有し)、ノードがMAP40にてARO登録を実行する場合、前述と同様の問題が生じるが、ルーティングの準最適性の度合いは小さい。そのように準最適性が軽減される理由としては、MAP40は、そのRO機能により、MAPにて適切な登録が行われている場合、いくつかのRCoAへ最適に到達するのに必要なLCoAをトレースできるからである。すでに説明したインフラに関連したピンボール・ルーティング問題の発生はRO対応のMAPの場合では確率的に低い。しかしながら、VMNやVMNのデフォルト・モバイル・アクセス・ルータは異なる複数種類の処理オプション(AROオプション、MAPオプション)を利用可能であるため、すべての登録がMAPにていつでも行われているわけではない。これはいくつかのノードがAROオプションしか処理しない場合に発生する。そのため、これら異種の処理オプションに起因して、RO対応のMAPはピンボール・ルーティング問題を完全には解消できない可能性がある。MAP40がAROに対応し、MNがAROオプションに組み込まれている適当なトレース・パラメータを用いて適切なMAP登録を行う場合、AROオプションは受諾される。一方、MAP40がプレフィックス・デレゲーション・ベースの、又は、PSBUベースのROメカニズムを有する場合、MAP40はVMN/MRからのBUにあるAROオプションを受諾しない。しかしながら、PSBUにより与えられるプレフィックスは、ある程度ROを実行するには十分なものである。プレフィックス対応のROのMAP40のシナリオでは、VMN/MRで作成されたBU内のAROオプションは無駄になる。
上記問題解析から次のことが理解できる。すなわち、ARO及びHMIPv6の異種シナリオにおいてMAPがレガシーMAPである場合、たとえVMNやVMNのすべての上流MRがMAPオプションを処理しMAPにて登録を行ったとしても、MAPには利用できるROメカニズムがないため、CNとのネスト状態のNEMOの経路最適化には全く適さない。従って、そのようなシナリオにはMAPを使用しないメカニズムが好ましい。ARO及びHMIPv6の異種シナリオにおいて、MAPがRO対応である場合、そのメカニズムによってCNでの異種アドレスの形成及びMAPでの対象とするRCoAに対するトレースの欠落が防止される限り、MAPを経路最適化処理に利用することが可能である。さらに、RO対応のMAPシナリオにおいても、ノードがCNと完全なエンド・ツー・エンドAROタイプのROを実行したい場合がある。このようなことは、従来技術の問題解析にも示したように、ノードがMAPオプションの後にAROオプションを処理する場合には不可能である。ノードは、それらの2つのオプションを上記の順で処理する場合、結局RCoAを用いてAROを実行することになり、完全なARO効果を得ることができなくなる。従って、MAPドメインにおいて、MAPを伴わずしてCNとの完全なエンド・ツー・エンドAROタイプのROを達成するためのメカニズムが必要である。
そこで、本発明は、上記先行技術の不具合や欠点を克服する、若しくは、大幅に改善することを目的とする。具体的には、本発明は、ARO及びHMIPv6の異種シナリオにおいて、アーキテクチャにMAPが一つしか存在しない場合における、2つの目的を有する。第1の目的は、ARO及びHMIPv6の異種シナリオにおいて、CNとの経路の最適化を達成するためのメカニズムを提供することにある。ここで、ARO及びHMIPv6の異種シナリオでは、VMNとMRはいずれもARO及びHMIPv6プロトコルを実装し、階層における一つのMAPはRO機能を有する、若しくは、RO機能を有しない。第2の目的は、優れたRO機能がVMNのフローに必要な場合にAROタイプのROを実現できるようにして、CNとの経路の最適化を可能とすることにある。
上記目的を達成するため、本発明は、以下のシステム、方法及び装置を提供する。
本発明は、VMN、MR、MAP、HA、CNを含む通信ノードのシステムを提供し、VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのMAPが存在し、そのMAPにはRO機能が実装され、HAにはAROプロトコルが実装されているものとする。このようなシステムにおいて、任意の第1ノードは、該任意の第1ノードに処理されたオプションに関係なく、任意の第2ノードとAROを実行したい場合、そのLCoAを気付アドレスとして使用するものとする。
本発明は、上記システムにおける任意の第1ノードはVMNであり、そのLCoAをCoAとして用いてそのCNの内の一つ又は複数とAROを行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはMRであり、そのLCoAを気付アドレスとして用いてVMNのCN若しくは他のMRのCNとAROを行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはVMNであり、そのLCoAをCoAとして用いてその一つ又は複数のHAとAROを行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはMRであり、そのLCoAをCoAとして用いてその一つ又は複数のHAとAROを行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意のノードはMRであり、そのLCoAをCoAとして用いてその一つ又は複数のCNとAROを行う上記システムにおいて採用される方法を提供する。
本発明は、VMN、MR、MAP、HA、CNを含む通信ノードのシステムを提供し、VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのMAPが存在し、そのMAPにはRO機能が実装され、HAにはAROプロトコルが実装されているものとする。このようなシステムにおいて、任意の第1ノードは、該任意の第1ノードが処理中のオプションに関係なく、任意の第2ノードとHMIPv6を実行したい場合、そのRCoAを気付アドレスとして使用するものとする。
本発明は、上記システムにおける任意の第1ノードはVMNであり、そのRCoAを用いてそのCNの内の一つ又は複数とHMIPv6を行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはVMNであり、そのRCoAを用いてその一つ又は複数のHAとHMIPv6を行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはMRであり、そのRCoAを用いてそのCNの内の一つ又は複数とHMIPv6を行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはMRであり、そのRCoAを用いてその一つ又は複数のHAとHMIPv6を行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはVMNであり、そのRCoAをローカルホームアドレスとして、及び、そのLCoAを気付アドレスとして使用して、MAPにてROベースのローカル登録を行う上記システムにおいて採用される方法を提供する。
本発明は、上記システムにおける任意の第1ノードはMRであり、そのRCoAをローカルホームアドレスとして、そのLCoAを気付アドレスとして使用して、MAPにてROベースのローカル登録を行う上記システムにおいて採用される方法を提供する。
本発明は、MRがMAPオプションを処理しておらず、それに直接接続されたVMN又はMRがMAPにてもうすでにROベースのローカル登録を行っている場合、MRはMAPオプションを処理してRCoAを取得し、MAPにてROベースのローカル登録を行う上記システムにおいて採用される方法を提供する。
上記方法に記載されているRO登録は、前述のRCoAに到達するのに必要なLCoAが最適な方法で取得できるよう、MAPにてROパラメータを用いてRCoAをホーム・アドレスとして登録する方法である。
本発明は、VMN、MR、MAP、HA、CNを含む通信ノードのシステムを提供し、VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装しているものとする。また、このシステムでは、ドメイン・アーキテクチャ内に一つのMAPが存在し、このMAPがレガシーHMIPv6タイプのものであり、HAにはAROプロトコルが実装されているものとする。このようなシステムにおいて、MRは、MAPがレガシータイプであることを知っている場合、そのRA内のMAPオプションを送信しないということを決定する。
本発明は、MRがMAPタイプの識別に、RAに付加された新しいMAPオプションを利用する上記システムにおいて採用される方法を提供する。
上記方法に記載されているタイプ情報は、MAPに関連するROスキームのタイプに関する情報であってもよいし、レガシーMAPに関する情報であってもよい。
本発明は、MRがMAPタイプの識別に、RAに付加された新しいオプションを利用する上記システムにおいて採用される方法を提供する。
上記方法に記載されているタイプ情報は、MAPに関連するROスキームのタイプに関する情報であってもよいし、レガシーMAPに関する情報であってもよい。
本発明は、MRがMAPタイプの識別に、明示的シグナリングを利用する上記システムにおいて採用される方法を提供する。
上記方法における明示的シグナリングは、AROオプション内のアドレスはMRのローカル気付アドレスであるMAPにて行われるAROタイプのBUであってもよい。
上記方法における明示的シグナリングは、プレフィックス・デレゲーション要求タイプのメッセージであってもよい。
上記システムでMAPオプションを送信しないと決定したMRは、そのLCoAを用いて、それに直接接続されているVMNの若しくはMRのHA又はCNとAROを実行してもよい。
上記システムでMAPオプションを送信しないと決定したMRは、そのRCoAを用いて、それに直接接続されているVMNの若しくはMRのHA又はCNとAROを実行してもよい。
本発明は、上記システム及び方法に記載したようなシステムにおけるVMNと関連する装置を提供する。
本発明は、上記システム及び方法に記載したようなシステムにおけるMRと関連する装置を提供する。
本発明は、AROやHMIPv6の混在する環境下でも有用なメカニズムを提供できるという利点を有する。
本発明では、ARO及びHMIPv6の統合シナリオにおいて経路最適化を達成するための3つの方法を提示する。そのシナリオでは、VMN及びMRにAROプロトコル及びHMIPv6プロトコルが実装され、ホーム・エージェントにAROプロトコルが実装され、CNにAROが実装される。アーキテクチャ内の一つのMAPはレガシータイプのMAP若しくはRO対応MAPであってもよい。第1の方法としては、処理されるオプション(ARO、MAP若しくはAROとMAP)に関係なく、VMN/MRは、自身のCN、HA又は他のノードのCNとAROを実行したい場合、VMN/MRがそのフローに対して最大のARO効果を得ることができるメカニズムを利用する。第2の方法としては、ここでもまた、処理されるオプション(ARO、MAP若しくはAROとMAP)に関係なく、VMN/MRが一つ又は複数のCNとHMIPv6を実行したい場合、若しくは、MRに直接接続されたVMN/MRがCNとHMIPv6を実行したい場合、VMN/MRは、効率的な所在管理と共に経路最適化を実現できる第2の方法を採用する。第3の方法としては、アーキテクチャにレガシーMAPが存在する場合、MRは、VMNとMRとがCN又はHAとの間に最適な経路を持つことができるよう決定を下す。
第1の好適な実施形態では、上記第1の方法が開示されている。この方法は本発明の2つの目的を達成するためである。一つは、RO対応MAP環境下においてROを実現することであり、もう一つは、ノードが厳しい遅延要件を有するフローにおいて完全なAROタイプのエンド・ツー・エンドROを実行させることができるようにすることである。この方法において、VMN/MRは、自身のCN、HA又は他のノードのCNとAROを実行したい場合、VMN/MRがそのフローにおいて最大のARO効果を得ることができるよう、自身のローカル気付アドレスを気付アドレスとして使用する。
これについて図2を用いて詳しく説明する。図2では、VMN210はMR220に直接接続され、MR220はMR221に直接接続され、MR221はAR230に直接接続される。つまり、図2では深いネスト状態のシナリオを示す。AR230はMAP240に直接接続される。このMAP240は、RO対応のものとする。HA250、HA251、HA252は、それぞれ、MR221、MR220、VMN210のホーム・エージェントである。VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装しているものとする。また、VMN210はARO対応のCN260とデータ通信セッションを行っているものとする。
MR221は、AR230からMAPオプションを含むRA261を受信する。この場合、HMIPv6スタックがトリガーされ、MR221とMAP240はローカル登録を行う。このことがメッセージ262に示されている。上記登録が終了すると、MAP240はBC263に示すようなエントリを得る。MAP240はRO対応であるので、MR221はその登録の際にROパラメータを与える。このROパラメータはプレフィックスであってもよいし、AROアドレスであってもよい。続いて、MR221は、自身のホーム・エージェント、すなわち、HA250にて登録を行う。このBU及びバインディング確認応答(BA)手順は、メッセージ264、265に示される。上記登録後、HA250は267に示すようなバインディング・キャッシュを得る。MR221はMAPオプションのみを処理するので、HA250での登録はHMIPv6タイプの登録と同様になるが、BC267にはMR221のモバイル・ネットワーク・プレフィックス(MNP)も含まれることになる。このプレフィックスはHA250によりMR221へ委譲される。
上記HA250での登録に続き、MR221はRA268を送信する。このRAにはAROオプションとMAPオプションの両方が含まれる。このAROオプションにはMR221のホーム・アドレスが含まれており、さらにMR221のRCoAも含まれていてもよい。MAPオプションにはMAP240のアドレスが含まれる。MR220は、これらのオプションを受信すると、このシナリオでは、AROオプションのみを処理することを決定するものとする。この場合、気付アドレスが一つだけ、すなわち、LCoAが設定されることとなる。MR220は、その後、そのホーム・エージェント、すなわち、HA251にBUを送信する。MR220はAROオプションを含むBUを作成する。このMR220により送信されたBUは、メッセージ269に示される。このメッセージ269はMR221のホーム・エージェントとMAP240へトンネルされる。この二重カプセル化されたメッセージが270に示される。そのようなトンネリングが行われた後、MAP240にてメッセージがデカプセル化され、単一レベルにトンネルされたメッセージ271がHA250へ送信される。HA250では、BUメッセージがさらにデカプセル化され、デカプセル化されたメッセージ272がHA251へ送信される。HA251にて良好に登録が行われると、BC273はAROパラメータとMNPパラメータを入手する。MR220のLCoAがBC273に登録されることが分かる。良好に登録が行われると、HA251はMR220にBAを送信する。このBAにはMR221のHoAが宛先アドレスとして含まれる。こうしてHA251により送信されたBAメッセージ、すなわち、274は、まず、HA250に受信される。その後、このメッセージは、図2のメッセージ275に示されるように、MR221のRCoAへトンネルされる。このトンネルされたメッセージ275はさらにMAP240により受信される。MAP240はMR221のRCoAに関連するLCoAを有する。こうして、MAP240はこのメッセージをトンネルする。このトンネルされたメッセージは276に示される。MR221は、このメッセージ276を受け取ると、トンネルを2回デカプセル化し、宛先アドレスをMR220のLCoAへと変更し、パケットをさらにルーティングする。こうしてルーティングされたBAメッセージ277は最終的にMR220に到達する。MR221は、MR221のHoAに送信されたACKを受信すると、HA251とのAROメカニズムを開始する。このことがメッセージ278に示される。メッセージ278に関連するシグナリング及びルーティングパスの詳細は明示されていないが、当業者であれば容易に想到し得ることである。上記ARO登録が完了すると、HA251のバインディング・キャッシュがBC279に示されているようになる。通常動作時、MR221は、MAPオプションを処理してRCoAを設定すると、CN260にだけそのRCoAを公開する。しかしながら、本発明の第1の方法を取り上げた本実施形態では、MR221がCN(自身の若しくは他のノードのCN)とAROを行う場合、そのLCoAを気付アドレスとして使用する。こうして、BC279には、そのようなローカル気付アドレスのエントリが含まれることとなる。
上記登録が完了すると、MR220は場合によってRA280を送信する。このRA280にもAROオプションとMAPオプションとが含まれる。VMN210は、AROオプション、MAPオプション、若しくは、AROオプションとMAPオプションの両方を処理する。VMNは、MAPオプションとAROオプションの両方を処理する場合、結局そのCNとRCoAベースのAROを実行することになるということが従来技術の問題解析にも見られた。本実施形態に概説された方法の主要なポイントは、VMNにCNとRCoAベースのAROを実行させないようにすることである。
VMN210は、上記方法を利用する場合、そのホーム・エージェントへの登録がまだであれば、まずは登録を行う。ここで理解すべき重要な点は、VMN210がさらにMAP240に登録を行い、いくつかのフローにおいてRCoAを利用できるということである。しかしながら、VMN210がCNとAROを行いたいということであれば、この方法に従うべきである。
HA252へのBUメッセージが281に示される。このメッセージは、MR220のホーム・エージェント、すなわち、HA251を介してトンネルされる。MR220は、HA251とAROを行ったので、NEMO−FWDオプションをこのメッセージに挿入する。MR221は、このトンネルされたメッセージ282を処理する場合、HA251とのAROバインディングを有するため、送信元アドレスをそのLCoAに変更し、さらにメッセージ282をルーティングする。このBUメッセージ282はHA251にてデカプセル化され、そのデカプセル化されたBUメッセージ284が最終的にHA252に到達する。HA252でのバインディング・キャッシュは、BC283に示される。
ここで理解すべき重要な点は、VMN210がすでにMAPオプションのみを処理し、HA252にて適切な登録を行っている場合、VMNは再度そのような登録を行う必要がないということである。本実施形態では、登録が行われておらず、LCoAを用いてARO登録を行うことを決定するものとする。そのような登録が行われた後、HA252はMR220のHoAへACKを送信する。このメッセージは285に示される。このメッセージはHA251に到達し、MR220のLCoAへトンネルされる。このトンネルされたメッセージ286の宛先アドレスは、MR221のLCoAとなる。MR221はBA286を受信し、宛先アドレスをMR220のLCoAへと変更し、BAメッセージをさらにルーティングする。このメッセージ286はMR220に送信され、そこで完全にデカプセル化される。このデカプセル化されたメッセージ287は最終的にVMN210に到達する。その後、MR220はHA252とAROを行う。このAROシグナリングメッセージは288に示され、HA252にて作成されたBCは289に示される。ここでも、MR220は、AROオプションのみを処理するので、HA252とAROを行う際は単にそのLCoAを登録するだけであることが分かる。続いて、MR221はHA252とAROを行い、それがメッセージ290に示される。HA252でのバインディング・キャッシュはBC291に示される。ここでも、前に述べたように、MR221はMAPオプションのみを処理したが、そのAROスタックがトリガーされると、MR221はCN(HA252)でのARO登録の際、LCoAを用いる。BC291にはHA252から最適にVMN210をトレースするための関連するすべてのパラメータが含まれることは当業者であれば理解し得ることである。
次に、VMN210はCN260とAROを行い、メッセージ292にそれを示す。そして、CN260でのバインディング・キャッシュはBC293に示される。RCoAを処理したか否かに関係なく、VMN210がLCoAだけを用いて、CNとAROを行うことが分かる。VMN210はRCoAにより他のCNと通信を行うことが可能である。このことは次の実施形態でさらに詳しく説明する。VMN210とCN260間でARO登録が良好に行われると、MR220はCN260とAROを行う。MR220は再び自身のLCoAだけを用いてCN260とAROを行い、このARO登録がメッセージ294に示される。このMR220によるAROは、VMN210のデータ・パケットに含まれるNEMO−FWDオプション又は、CN260から送信されたACKによりトリガーされている。MR220がCN260にてAROを行うと、CN260でのバインディング・キャッシュはBC295のようになる。その後、MR221はCN260とAROを行い、このARO確立メッセージが296に示される。そのように登録が良好に行われた後、CN260でのバインディング・キャッシュはBC297のようになる。BC297から、CN260はVMN210に最適に到達するのに必要なすべてのLCoAをトレースすることが可能であることが分かる。これに続いて、VMN210とCN260は298に示すような双方向データ通信を行うことができる。この通信パス及び構造は純粋なAROタイプである。このように、VMN/MRは、複数種類のオプションを処理するが、CNとのAROの際にはLCoAを使用することで完全なROを達成し、従来技術の解析にも示したようなルーティングの準最適性を解消する。また、このメカニズムにより、すでに処理されたものがMAPオプションのみであったとしても、任意のVMNは厳しい遅延要件を有するフローに対して完全なAROを実行することを決定できる。このため、レイヤ3はアプリケーションから送られるフローに関するいくつかの要件を必要とする。これは、ソケットを実装する際にフラグを付加するなど、様々な方法で行うことができる。
本発明の別の好適な実施形態では、本発明の第2の方法を説明する。第2の方法では、VMN/MRがAROオプションとMAPオプションの両方を処理可能な状況を取り扱う。しかしながら、VMN/MRは、所在管理効率に関係するROのためにCNとHMIPv6を行いたい場合、そのCoAとしてRCoAを用いてMAPと通常のHMIPv6登録を行い、CNとのバインディングを登録する際にはそのRCoAを用いる。MAPへのRO関連のローカルBUのタイプは、MAPのRO機能によって決まる。従来技術のシナリオでは、VMNが両オプションを処理する場合、VMNは結局RCoAを用いてCNとAROを実行することになり、それにより前述のすべての問題が引き起こされる。第2の方法ではまた、MRはAROオプションのみを処理するが、それに直接接続されているVMN又はMRがMAPオプションを処理しMAPに接続されている場合に、MAPオプションを処理して適切なMAP登録を行う場合も取り扱う。この第2の方法の目的は、VMNとMRがAROオプションとMAPオプションの両方を処理する場合にも、フローに対してRCoAベースのROを行うことである。RCoAベースのROは、より少ないジッターが要求されるフローや、電力が制限されたVMNや、ネットワークシグナリング負荷を軽減することが好ましい場合に有用である。
この方法は、図3に示すようなシグナリング及びデータ・パケット・ルーティング処理を検討することでさらに詳しく説明する。VMN310はMR320に直接接続され、MR320はMR321に直接接続され、MR321はAR330に直接接続され、AR330はMAP340に直接接続される。MAP340はRO対応のものとする。また、HA350、HA351、HA352は、それぞれ、MR321、MR320、VMN310のホーム・エージェントである。VMN310はARO対応のCN360とデータ通信セッションを行っているものとする。
MR321は、RA361とMAPオプションを受信し、その後、MAP340にてローカルBUを行う。これをメッセージ362に示す。続いて、MR321はホーム・エージェントHA350に対しBU登録を行う。これらの登録を図3のメッセージ364、365に示す。HA350は、その後、BC367に示すようなバインディング・キャッシュを得る。適切な登録を行った後、MR321はAROオプションとMAPオプションの両方を含むRA368を送信する。このシナリオでは、MR320はAROオプションのみを処理するものとする。このような場合、MRはLCoAを用いてAROオプションを含むBUメッセージ369をホーム・エージェントHA351に送信する。このメッセージは、メッセージ370に示されるように、MR321により二重にカプセル化される。この場合も先と同様に、MAP340はこのメッセージをデカプセル化し、デカプセル化されたメッセージ371はHA350に送られる。HA350はそのメッセージをさらにデカプセル化し、メッセージをHA351へルーティングする。このHA350を介してルーティングされたBUメッセージを372に示す。
HA351でこの登録が行われると、バインディング・キャッシュはBC373に示されているようになる。この登録ではMR320のLCoAを気付アドレスとして用いることに留意する。前述の実施形態でも述べたように、HA351からのACKは様々なパスを通り及びトンネリングをされる。このことは図3のメッセージ374、375、376、377に示される。MR321は、HA351からMR321のHoA宛てのACKを受信すると、HA351とAROを行う。これをメッセージ378に示す。MR321は、前述の実施形態に開示された発明の方法に従ってAROのBU登録を行うものとする。すなわち、MR321は、MR320のホーム・エージェントとAROを行う場合、LCoAを用いてAROを行う。上記ARO登録が行われた後の、HA351でのバインディング・キャッシュはBC379に示される。そこでのエントリはMR320に最適に到達するのに十分であることが分かる。そのような登録が完了すると、MR320は両オプションを含むRA380を送信する。VMN310がCN360とRCoAベースのROを行うことを決定したと仮定すると、VMN310はRCoAだけを用いてHMIPv6スタックを起動する。この場合でも同様に、MAP340にてROパラメータを有する適切なローカルBUを登録する必要がある。このローカルBUメッセージを381に示す。MR320はMAP340とのバインディングを持たないため、そのホーム・エージェント、すなわちHA351を介してパケットをトンネルすることが可能である。これを図3のトンネルされたメッセージ382として示す。
MR320は、このNEMO−FWDオプションを含むメッセージ382を受信すると、HA351とのAROバインディングをもうすでに実行しているので、単に送信元アドレスをLCoAへ変更し、パケットをさらにルーティングする。ローカル登録メッセージはHA351にてデカプセル化され、MAP340へと送られる。このデカプセル化されたメッセージを383に示す。この登録がMAP340により受諾されると、バインディング・キャッシュはBC384に示されているようになる。ここで理解すべき重要な点は、MAP340での登録は標準のHMIPv6におけるものとは異なる。ここでは、ローカルBUは、RCoAに到達するのに必要な上流MRのLCoAを入手できるよう、ROパラメータを含む必要がある。MAP340はVMN310に応答を送る。このACKメッセージを385に示す。このメッセージはVMN310のLCoAへ送信され、MR320のホーム・エージェントに到達する。そこでメッセージ386としてMR321を介してMR320のLCoAへとトンネルされる。このメッセージ386は最終的にMR320にてデカプセル化され、MAP340からのBAメッセージ387はVMN310に到達する。MR320は、メッセージ386をデカプセル化する時、メッセージがホーム・エージェントから来ていることを認識するので、パケットの送信元アドレスでは登録を行わない。さらに、MR320は、デカプセル化されたパケットの送信元アドレスがMAPアドレスであるかどうかを調べる。MAPアドレスである場合、MR320はMAPオプションを処理し(次にRAを受信する、若しくは、記憶されたMAPオプション値を使用する時)、MAP340にて登録を行う。この登録は図3の388、389に示される。MR320はMAP340にてROパラメータを組み込んだローカルBUを行う。この登録後のMAP340でのバインディング・キャッシュはBC390に示される。
その後、VMN310は、MIPv6方法により、CN360にてそのHoAをRCoAに結合する。ここで理解すべき重要な点は、この時、VMN310はAROオプションを処理したかもしれないが、他のフローに対するROにそれを利用しているかもしれないということである。MIPv6方法によりCN360にてそのようなHoA−RCoAバインディング登録を行う前に、VMN310はそのホーム・エージェントHA352に登録する必要がある。この登録は図3には明示されていない。VMN310はHA352に登録する際RCoAを用いることができる。若しくは、VMN310は、すでにAROオプションを処理している場合、LCoAを用いてHA352にてARO登録を行っていた可能性もある。これらは図3には明示されていない。HA352では登録タイプ(RCoAベースのMIPv6登録又はLCoAベースのARO登録)に関係なく、VMN310はRCoAを用いることができ、MIPv6方法によりCN360にてHoA−RCoAバインディングを行うことができる。
MIPv6方法によるCN360でのHoA−RCoAバインディング登録はメッセージ391に示される。そのような登録後のCN360でのBCは392に示される。次に、VMN310はCN360にデータ・パケットを送信する。VMN310は、MIPv6方法によりCN360にてHoA−RCoAバインディング登録を行ったので、そのパケットを、MAP340を介してトンネルする。VMN310は、MAP340にてAROタイプのローカル登録を行った場合、NEMO−FWDオプションを外部トンネルヘッダに組み込む。このCN360へトンネルされたデータは393に示される。このメッセージ393はMAP340にてデカプセル化され、内部メッセージ394がCN360へ送信される。CN360は、データ・パケットをVMN310へ送信する場合、そのパケットをVMN310のRCoAへ送信する。このメッセージ395はMAP340に受信される。MAPはBC390を使ってVMN310のRCoAへ到達するのに必要なすべてのLCoAを見つけ出し、パケットを宛先アドレス及びRH2に存在するすべてのLCoAと共にトンネルにカプセル化する。このカプセル化されたメッセージ396は最終的にVMN310に到達する。MAP340では、BC390に示されるROパラメータがAROパラメータである場合、トレース機構がVMN310のRCoAに関連するROパラメータと、BC390のRCoAの列エントリとの間で一致するものを見つけ出す。VMN310のRCoAに関連するROパラメータがプレフィックスである場合、このプレフィックスと一致するプレフィックスをBC390のLCoAの列エントリから検索する。このMAP340でのROトレース機構により、一回のトレースループ後、MR321のLCoA、MR320のLCoA、VMN310のLCoAが得られる。
前述の実施形態に記載された方法をさらに理解するため、本実施形態では、前述の方法を実施するVMNの動作について説明する。VMNプロトコルスタックのレイヤ3には、インターネット・プロトコル・バージョン6(IPv6)ルーティング・モジュール、MIPv6ルーティング・モジュール、MIPv6から導出されたAROルーティング・モジュール、同様にMIPv6から導出されたHMIPv6ルーティング・モジュールが含まれるものとする。上記HMIPv6モジュールは、通常のHMIPv6モジュールよりも多くの機能を有する。上記追加機能は、MAPのタイプに関連するROパラメータによりMAPにてローカルBUを行うための方法であることが好ましい。さらに、VMNは、レイヤ3にて図2、図3に概略的に示される機能を組み込んだ新しい処理モジュールを有するものとする。その処理モジュールは、その状態によって、ARO、HMIPv6、標準IPv6などの異なるルーティング・モジュールを起動する。この新しい処理モジュールは図4を用いてさらに詳しく説明する。VMNがCN、HA又はMAPと通信するために適切なルーティング・プロトコルを選択できるよう、図4のフローチャートに示されるような処理のインスタンスが一定の間隔をおいて作成される。
図4において、VMNの新しい処理モジュールに関連する第1ステップは、VMNがCN若しくは一つ又は複数のホーム・エージェントとAROを行いたいか否かを判断するステップ400である。AROを実行するか否かは完全にVMN次第である。フローにおけるより良いROのために実行してもよい。VMNが実行すると決定した場合、ステップ401がトリガーされる。ステップ401では、VMNがそのLCoAをCoAとして使用し、CN若しくは一つ又は複数のホーム・エージェントとAROバインディングを行う方法が示される。ステップ400にてVMNがAROを実行すると決定した場合、ステップ402がトリガーされる。このステップでは、VMNがMIPv6方法によりCNにてHoA−RCoAバインディング登録を行いたいか否かについてクエリーを行う。ステップ402でyesと判定された場合、ステップ403が実行される。ステップ403では、VMNがRCoAを使ってMAPにてRO登録を行い、MIPv6方法によりCNにてHoA−RCoAバインディング登録を行う方法の概要が示されている。ステップ403を行うために、処理の制御が前述のHMIPv6スタックに切り替えられる。ステップ402でnoと判定された場合、処理はステップ404へ進む。ステップ404では、VMNが一つ又は複数のHAにてRCoAを用いて登録を行いたいか否か、かつ、MAPにてROベースのHMIPv6登録を行いたいか否かを判定する。ステップ404でyesと判定された場合、処理モジュール406が起動される。このモジュールは、VMNがRCoAを用いてMAPにてHMIPv6関連のRO登録を行い、一つ又は複数のHAにてMIPv6登録を行う機能を持つ。一方、ステップ404でnoと判定された場合、処理は、ステップ405に示すように、モジュールMIPv6又はIPv6モジュールに移行する。
ここで理解すべき重要な点として、制御は、ステップ401を実行する時はAROスタックへ移り、ステップ403、406を実行する時は、MAPにてROベースの登録を行うためのサポートコードを有するHMIPv6スタックへ移る。そしてまた、ステップ405を実行する時は、制御はIPv6又はMIPv6へと移る。
本発明の別の好適な実施形態では、MRの動作を説明し、図5のフローチャートによりさらに詳しく説明する。本実施形態では、RO対応MAPシナリオ及びレガシーMAPシナリオにおけるMRの動作を説明する。本実施形態では、図2、図3に示された方法に加えて、レガシーMAPシナリオにおいてVMN/MRが一つ又は複数のCN若しくはHAとROを実行できるよう適切な判断をMRが下す本発明の第3の方法の概要を示す。上記第3の方法では、MRは、MAPがRO機能を持たないレガシータイプのMAPであることを知っている場合、RA内のMAPオプションを送信しない。
MRのプロトコル・アーキテクチャのレイヤ3は、AROルーティング・モジュール、HMIPv6ルーティング・モジュール、NEMO基本ルーティング・モジュール、IPv6ルーティング・モジュール、MIPv6ルーティング・モジュール、新しい処理モジュールから構成される。上記HMIPv6ルーティング・モジュールは標準のHMIPv6ルーティング・モジュールとは少し異なる。主な違いは、MAPでのローカルBUにROパラメータが付加されていることである。また、MRは、RO対応MAPシナリオにおいて、RA内のMAPオプションを通知する。これは通常のHMIPv6動作では行われない。MAPでのRO登録は、ROタイプのMAPに沿って行われるものとする。すなわち、HMIPv6ルーティング・モジュールは、MAPのROスキームタイプに応じて、MAPと様々なタイプのROを実行することが可能であるものとする。
次に、図5を参照して、上記新しい処理モジュールに関連する工程を説明する。まず、ステップ500を実行してMAPがレガシーMAPであるか否かを判断し、レガシーMAPでない場合、MAPがどんなタイプのROスキーム(ARO対応タイプ、プレフィックス・デレゲーションタイプなど)を有するかが判定される。この判断を行うには、受信したRAに付加された新しいタイプのMAPオプションを使う方法、受信したRAに付加された新しいオプションを使う方法、MRからMAPへのテスト信号を使う方法など、様々な方法がある。例えば、MRは、新しいMAPオプション、又は、MAPのタイプ(レガシー、MAPのROタイプ)を通知するRAに付加された新しいオプションを受信すると、MAPのタイプを知り適宜行動する。この方法の利点としては、MRが明示的シグナリングを行う必要がなく、電力を浪費しないで済む。一方、この方法の問題点は、固定ルータがこれらの特別なオプションを把握し、RAで再送しなければならないことである。これにはシステムに大幅な変更を加える必要があり、スケーラビリティに問題が生じる。MRは、外部シグナリングによりMAPタイプをテストする場合、MAPに対しAROタイプのBUテスト、又はプレフィックス・デレゲーション要求テストを利用する。こうして、双方向の要求・応答シグナリングによって、システムにはさらにシグナリングが投入されることになる。MAPがシグナリングのタイプを把握した場合のみMAPからの応答が発生するということは容易に理解し得ることである。例えば、AROタイプのBUがレガシーMAPにて行われた場合、MAPからは何の応答も送信されない。また、明示的テストシグナリングが行われる第2の方法では、MRの電力は同様に浪費される。さらに、正確なMAPタイプを知るため異なるタイプのテストシグナリングが行われることもあり、それによりシグナリング負荷がさらに増大し、MRの電力がさらに浪費されることとなる。この第2の方法の利点は、固定ルータに変更を加える必要がないということである。AROタイプのBUテストが行われると、AROオプションが受信されなかった場合、AROオプションにはMRの気付アドレスが含まれる。そのようなアドレスが使われるのは、MRが最上位移動ルータになった場合、AROオプションが受信されないからである。ここで理解すべき重要な点は、MAPがレガシーMAPであるか否かを把握することに加えて、MRがMAPにてROに関連するローカル登録を適切に行うことができるよう、MAPが使用しているROスキームのタイプを知ることも重要である。
ステップ500でyesと判定された場合、前述したような従来技術の問題を解消するためステップ501が実行される。このステップでは、MRは、MAPがレガシーMAPであることを知っているため、RAにおけるMAPオプションの通知を停止することを決定する。MRがレガシーMAPシナリオにてそのような決断を下すのは、MAPにはROトレース機構が組み込まれておらず、ネスト状態のNEMOのARO及びHMIPv6シナリオに対するサービスを提供するのに全く役に立たないためである。そのため、MN(VMN/MR)がネストされている限りMAPはROに利用することができない。ステップ501が完了すると、制御はステップ502へ移動できる、若しくは、MRはステップ502乃至512を行わずに、標準のARO及びHMIPv6動作を行うことができる。図5にはステップ501の後のステップが明示されていないのはこのためである。これについては、以下の他の実施形態にてさらに詳しく説明する。
ステップ500でnoと判定された場合、ステップ502が実行される。このステップでは、MRに直接接続されたVMN/MRがAROを使って自身のCNと通信しているか否かが判定される判定処理が行われる。ステップ502でyesと判定された場合、MRで処理されたオプションのタイプに関係なく、ステップ503が実行される。ステップ503では、MRがLCoAを使って、それに直接接続されたVMN/MRのCNとAROを確立する。ステップ502でnoと判定された場合、ステップ504で示されるようなテストをさらに実施する。これにより、MRが一つ又は複数のHA若しくはCNとAROを行いたいか否かが判定される。ステップ504でyesと判定された場合、再度ステップ503が実行される。ステップ504でnoと判定された場合、ステップ505が実行される。このステップでは、このMRに直接接続されたVMN/MRがMAPと通信しているか否かが判定される。ステップ505でyesと判定された場合、ステップ506が実行される。ここではMRがMAPオプションを処理したか否かが判定される。ステップ506でnoと判定された場合、ステップ507が実行される。ステップ507では、MAPオプションが処理され、MRがMAPにて適切なROベースの登録を行う。ステップ506でyesと判定された場合は何も行われない。ステップ505でnoと判定された場合、ステップ508が実行される。ここでは、MRが、MNとして、MIPv6方法により自身のCNにてHoA−RCoAバインディング登録を行いたいか否かがテストされる。ステップ508でyesと判定された場合、ステップ510が実行される。ステップ510では、MAPオプションが処理されたか否かが判定される。ステップ510でnoと判定された場合、ステップ511が実行される。ステップ511は、MRがMAPオプションを処理し、MAPにて適切なRO登録を行い、MIPv6方法により一つ又は複数のCNにてHoA−RCoAバインディング登録を行う手順に関する。ステップ510でyesと判定された場合、ステップ512が実行される。ステップ512では、MRがMIPv6方法により一つ又は複数のCNにてHoA−RCoAバインディング登録を適切に確立する。ステップ508でnoと判定された場合、ステップ509が実行され、標準NEMO基本、MIPv6又はIPv6動作が行われる。
本発明のさらに別の好適な実施形態では、VMN/MRがAROオプション、MAPオプション、若しくはAROオプションとMAPオプションの両方を処理できるRO対応MAPシナリオにおける主要な発明の効果を十分に理解するため、VMNとCNとの間で確定される最終的なデータパスを説明する。上記解決法の効果は、図6に示すネットワーク図により説明する。
図6では、VMN610がMR620に接続され、MR620がMR621に接続され、MR621がAR630に接続され、AR630がMAP640に接続され、MAP640がグローバル通信ネットワーク600に接続されている。VMN610は、CN650とCN651の2つのCNと同時に通信しているものとする。図6では、MAP640でのバインディング・キャッシュはBC662で示され、CN650でのバインディング・キャッシュはBC660で示され、CN651でのバインディング・キャッシュはBC661で示される。さらに、VMN610は、CN650とAROタイプのROを行うことを決定し、MIPv6方法によりCN651にてHoA−RCoAバインディング登録を行うことを決定するものとする。本発明に係る方法を採用することにより、VMN610が処理するオプションに関係なく、CN650とAROを行うことが決定したなら、LCoAを用いてAROを確立する。また、MR620とMR621もまた、LCoAを使ってCN650とのAROを確立する。そのため、図6からも分かるように、BC660には、VMN610に最適に到達するのに必要なすべてのLCoAが含まれる。また、この解決法によれば、従来技術に記載されていたようなバインディング・キャッシュに関連する異種アドレス問題が解消される。VMN610がCN650とAROを実行する場合の最適ルートパスを図6の670に示す。パスはトンネリングを伴わずに完全に最適化されていることが分かる。
VMN610がRCoAを用いてCN651と所在管理ベースのROを確立することを決定した場合、VMN610はRCoAを用いてMAP640にて適切にROベースのローカルBU登録を行い、MIPv6方法によりCN651にてHoA−RCoAベースのバインディング登録を行う。MIPv6方法によるCN651でのHoA−RCoAバインディング登録をBC661で示す。BC662の第3行には、VMN610により作成されたエントリが表示される。ここでも同様に、本発明の方法を採用することにより、MR621とMR620は、処理したオプションに関係なく、MAP640にて適切なRO登録を行う。BC662にはVMN610のRCoAを正確にトレースするのに必要なすべてのパラメータが含まれることは当業者であれば理解し得ることである。従って、VMN610とCN651は所在管理効率ベースのROを互いに実行できる。このメッセージを671に示す。VMN610からCN651へのデータ・パケットは、VMN610とMAP640間のトンネルにカプセル化される。移動ルータMR620、MR621は、パケットが逆方向に送信された場合にパケットを、パス671を介してルーティングする際、単に送信元アドレスをLCoAに変更する。順方向では、CN651からのパケットはMAP640に受信され、トンネルにカプセル化される。MAP640はVMN610のRCoAに到達するためのエントリを検索する。BC662には、VMN610のRCoAに到達するためのすべてのエントリが含まれていることが分かる。MAP640でのROメカニズムはどんなタイプのもの(ARO、PSBUを伴うプレフィックス・デレゲーション、検証を伴うPSBUなど)であってもよい。
図6に示す解決法の効果から、VMN610はそのフローやアプリケーションで使用したいROスキームのタイプを選択し、選択したROスキームに対して適当なCoAを選択することが可能であることがはっきりと見て取れる。VMN610は、CN650とAROを行う際、MIPv6方法によりHAにてHoA−RCoAバインディング登録を行うことができるということを理解することも重要である。さらに、VMN610は、MIPv6方法によりCN651にてHoA−RCoAバインディング登録を行う際、HAとAROタイプの登録を行ってもよい。
本発明のさらに別の好適な実施形態では、レガシーMAPシナリオにおける主要な発明の効果を十分に理解するため、VMNとCNとの間で確定される最終的なデータパスを説明する。上記解決法の効果は、図7に示すネットワーク図により説明する。
図7では、VMN710がMR720に接続され、MR720がMR721に接続され、MR721がAR730に接続され、AR730がMAP740に接続され、MAP740がグローバル通信ネットワーク700に接続されている。VMN710は2つのCNと同時に通信しているものとする。上述の通信相手ノードは、CN750、CN751である。さらに、図7では、MAP740、CN750、CN751でのバインディング・キャッシュは、それぞれ、BC762、BC760、BC761で示される。
このシステムでは、MR721は、MAP740がHMIPv6レガシータイプのMAPであることを確認し、RAのMAPオプションを通知しないものとする。そのため、VMN710とMR720はAROオプションのみを有し、それらのネットワーク内にMAPが存在することに気付かない。このような環境下では、VMN710はCNとの通信の際AROオプションのみを処理する。
まず、VMN710とCN750間のデータ通信を詳しく見てみる。VMN710はCN750とAROを行う。同様に、MR720は、CN750から適当なACKを取得した場合、若しくは、NEMO−FWDオプションを見つけた場合、CN750とAROを行う。MR720は処理するオプションとしてAROオプションしか有していないので、前述の実施形態で概説され図5にて説明された新しい処理部は実行されない。MR721は、CN750とAROを確立する場合、単にRCoAを用いてAROを確立できる。MRは、RAのMAPオプションの送信を停止する場合、標準メカニズムを使用できる。若しくは、図5に概説した新しい処理部を使用する決定をできることが前述の実施形態にも説明されている。この事例に限って言えば、MR721は図5に概説した新しい処理部を実行しないが、その代わり、標準のAROプロトコル及びHMIPv6プロトコルを利用するものとする。これはパス770に示される。BC760のエントリは、CN750のエントリである。MR721のRCoA、MR720のLCoA、VMN710のLCoAに到達することで、VMN710のHoAに到達できる。CN750がVMN710へデータ・パケットを送信する場合、宛先アドレスがMR721のRCoAに設定され、RHにはMR720のLCoA、VMN710のLCoA、VMN710のHoAが含まれる。そのようなパケットがCN750にて作成された場合、データパスは770に示すようになる。MAP740とMR721との間には、一つのトンネルが存在する。パス770は、一つのトンネルを有する最適ルートパスである。このパスの利点としては、RCoAがCN750に与えられたものでありLCoAほど頻繁には変更されないことから、MR721からのAROタイプの再帰的シグナリングが軽減されるということである。
次に、VMN710とCN751間のデータ通信パス771を詳しく見てみる。ここでも同様に、VMN710とMR720は処理するオプションとしてAROオプションしか有していないことが分かる。VMN710がCN751とのAROバインディングを開始する場合、VMN710とMR721間の登録は純粋なAROタイプである。このような場合、MR721は、図5に示す新しい処理モジュール、又は通常のメカニズムを利用できる。データパス771では、MR721は、CN751とAROを行う際、新しい処理アルゴリズムとLCoAとを使用するものとする。その結果、CN751でのバインディング・キャッシュが、すべてのLCoAエントリを表示するBC761に示される。BC761から、VMN710とCN751が互いに通信する際に完全なARO効果が得られることが分かる。パス771にはトンネリングが生じない。その点では、パス771はパス770よりも大きな利点を有する。しかしながら、この場合、AROシグナリングが若干高くなる。これは、すべてのLCoA登録がBC761に存在し、高いモビリティ環境下では、LCoAは頻繁に変更され、一定期間内でCN751にてより多くのARO登録が行われるからである。
以上、本発明を最も実用的で好適と思われる実施形態で説明したが、当業者であれば、本発明の要旨及び範囲から逸脱することなく、設計の詳細及びパラメータに種々の変更がなし得ることを理解できるであろう。例えば、本発明は、ネスト状態の移動ネットワークにおいて使用される経路最適化メカニズムとしてAROスキームを採用している。本発明は、何らかの方法で移動ルータのアドレスを利用して経路最適化を達成するものなど、他の経路最適化メカニズムにも適用可能であることは当業者により理解されるであろう。また、本発明は、ローカル・モビリティ管理プロトコルとして、HMIPv6を採用している。本発明は、その他のローカル・モビリティ管理プロトコルにも適用可能であることは当業者により理解されるであろう。
本発明は、AROやHMIPv6が混在する環境下でも有用な機構を提供できるという利点を有し、パケット交換通信の分野に適用可能である。
Claims (31)
- VMN、MR、MAP、HA、CNを含む通信ノードのシステムであって、
VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装し、
ドメイン・アーキテクチャ内に一つのMAPが存在し、そのMAPにはRO機能が実装され、HAにはAROプロトコルが実装され、
任意の第1ノードは、該任意の第1ノードが処理したオプションに関係なく、任意の第2ノードとAROを実行したい場合、そのLCoAを気付アドレスとして使用するシステム。 - 前記任意の第1ノードはVMNであり、そのLCoAをCoAとして用いてそのCNの内の一つ又は複数とAROを行う請求項1に記載のシステム。
- 任意の第1ノードはMRであり、そのLCoAを気付アドレスとして用いてVMNのCN若しくは他のMRのCNとAROを行う請求項1に記載のシステム。
- 任意の第1ノードはVMNであり、そのLCoAをCoAとして用いてその一つ又は複数のHAとAROを行う請求項1に記載のシステム。
- 任意の第1ノードはMRであり、そのLCoAをCoAとして用いてその一つ又は複数のHAとAROを行う請求項1に記載のシステム。
- 任意のノードはMRであり、そのLCoAをCoAとして用いてその一つ又は複数のCNとAROを行う請求項1に記載のシステム。
- VMN、MR、MAP、HA、CNを含む通信ノードのシステムであって、
VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装し、
ドメイン・アーキテクチャ内に一つのMAPが存在し、そのMAPにはRO機能が実装され、HAにはAROプロトコルが実装され、
任意の第1ノードは、前記任意の第1ノードが処理中のオプションに関係なく、任意の第2ノードとHMIPv6を実行したい場合、そのRCoAを気付アドレスとして使用するシステム。 - 前記任意の第1ノードはVMNであり、そのRCoAを用いてそのCNの内の一つ又は複数とHMIPv6を行う請求項7に記載のシステム。
- 前記任意の第1ノードはVMNであり、そのRCoAを用いてその一つ又は複数のHAとHMIPv6を行う請求項7に記載のシステム。
- 前記任意の第1ノードはMRであり、そのRCoAを用いてそのCNの内の一つ又は複数とHMIPv6を行う請求項7に記載のシステム。
- 前記任意の第1ノードはMRであり、そのRCoAを用いてその一つ又は複数のHAとHMIPv6を行う請求項7に記載のシステム。
- 前記任意の第1ノードはVMNであり、そのRCoAをローカルホームアドレスとして、及び、そのLCoAを気付アドレスとして使用して、MAPにてROベースのローカル登録を行う請求項7に記載のシステム。
- 前記任意の第1ノードはMRであり、そのRCoAをローカルホームアドレスとして、及び、そのLCoAを気付アドレスとして使用して、MAPにてROベースのローカル登録を行う請求項7に記載のシステム。
- MRがMAPオプションを処理しておらず、それに直接接続されたVMN又はMRがMAPにてもうすでにROベースのローカル登録を行っている場合、MRは前記MAPオプションを処理してRCoAを取得し、前記MAPにてROベースのローカル登録を行う請求項7に記載のシステムにおいて採用される方法。
- 前記RCoAに到達するのに必要なLCoAが最適な方法で取得できるよう、MAPにてROパラメータを用いてそのRCoAをホーム・アドレスとして登録する請求項14に記載の方法。
- VMN、MR、MAP、HA、CNを含む通信ノードのシステムであって、
VMN及びMRは、AROプロトコル及びHMIPv6プロトコルを実装し、
ドメイン・アーキテクチャ内に一つのMAPが存在し、このMAPがレガシーHMIPv6タイプのものであり、HAにはAROプロトコルが実装され、
MRは、MAPがレガシータイプであると知っている場合、そのRA内のMAPオプションを送信しないと決定するシステム。 - MRがMAPタイプの識別にRAに付加された新しいMAPオプションを利用する請求項16に記載のシステム。
- MAPのタイプに関する情報は、MAPに関連するROスキームのタイプに関する情報、又は、レガシーMAPに関する情報である請求項17に記載のシステム。
- MRがMAPタイプの識別に、RAに付加された新しいオプションを利用する請求項16に記載のシステム。
- MAPのタイプに関する情報は、MAPに関連するROスキームのタイプに関する情報、又は、レガシーMAPに関する情報である請求項19に記載のシステム。
- MRがMAPタイプの識別に、明示的シグナリングを利用する請求項16に記載のシステム。
- 前記明示的シグナリングは、AROオプション内のアドレスはMRのローカル気付アドレスであるMAPにて行われるAROタイプのBUである請求項21に記載のシステム。
- 前記明示的シグナリングは、プレフィックス・デレゲーション要求タイプのメッセージである請求項21に記載のシステム。
- MAPオプションを送信しないと決定したMRは、そのLCoAを用いて、それに直接接続されているVMNの若しくはMRのHA又はCNとAROを実行する請求項16に記載のシステム。
- MAPオプションを送信しないと決定したMRは、そのRCoAを用いて、それに直接接続されているVMNの若しくはMRのHA又はCNとAROを実行する請求項16に記載のシステム。
- 請求項1に記載のシステムにおけるVMNと関連する装置。
- 請求項7に記載のシステムにおけるVMNと関連する装置。
- 請求項16に記載のシステムにおけるVMNと関連する装置。
- 請求項1に記載のシステムにおけるMRと関連する装置。
- 請求項7に記載のシステムにおけるMRと関連する装置。
- 請求項16に記載のシステムにおけるMRと関連する装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007254765 | 2007-09-28 | ||
PCT/JP2008/002630 WO2009041022A2 (en) | 2007-09-28 | 2008-09-24 | System, method and apparatus for route-optimized communication for a mobile node nested in a mobile network |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2010541302A true JP2010541302A (ja) | 2010-12-24 |
JP2010541302A5 JP2010541302A5 (ja) | 2011-11-17 |
Family
ID=40512001
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010512444A Withdrawn JP2010541302A (ja) | 2007-09-28 | 2008-09-24 | 移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20100202385A1 (ja) |
JP (1) | JP2010541302A (ja) |
WO (1) | WO2009041022A2 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8503416B2 (en) * | 2010-12-15 | 2013-08-06 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for efficient homeless MPLS micro-mobility |
CN105122854B (zh) * | 2014-01-24 | 2019-09-13 | 华为技术有限公司 | 一种控制路由优化的方法、装置及*** |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3946153B2 (ja) * | 2003-02-26 | 2007-07-18 | 株式会社エヌ・ティ・ティ・ドコモ | 通信システム、移動端末、転送装置 |
US20060185013A1 (en) * | 2003-06-18 | 2006-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and apparatus to support hierarchical mobile ip services |
-
2008
- 2008-09-24 JP JP2010512444A patent/JP2010541302A/ja not_active Withdrawn
- 2008-09-24 WO PCT/JP2008/002630 patent/WO2009041022A2/en active Application Filing
- 2008-09-24 US US12/679,664 patent/US20100202385A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
WO2009041022A2 (en) | 2009-04-02 |
US20100202385A1 (en) | 2010-08-12 |
WO2009041022A3 (en) | 2009-07-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7366147B2 (en) | Methods and apparatus for tunneling between different addressing domains | |
US8553689B2 (en) | Home agent acting as a proxy for a Mobile Node | |
US8279807B2 (en) | Communication control method, network node, and mobile terminal | |
US20030193952A1 (en) | Mobile node handoff methods and apparatus | |
JP3917623B2 (ja) | 次世代インターネットにおける地域アンカーポイントを使用する移動ノードの移動性を支援するシステム及び方法 | |
US20040148428A1 (en) | Methods and apparatus for supporting an internet protocol (IP) version independent mobility management system | |
US20090034499A1 (en) | Method and apparatus for route optimisation in nested mobile-networks | |
US8873507B2 (en) | Distributed local mobility anchors for achieving optimized mobility routing | |
JP2003526297A (ja) | 無線ネットワークのための階層移動性管理 | |
US20100296443A1 (en) | System, method and apparatus for route-optimized communication for a mobile node nested in a mobile network | |
KR100780260B1 (ko) | 모바일 네트워크에서 강인한 로컬 이동성 관리를 위한방법 및 장치 | |
US8824353B2 (en) | Mobility route optimization in a network having distributed local mobility anchors | |
US8649352B2 (en) | Packet forwarding methods for use in handoffs | |
US8842607B2 (en) | Mobility management system and method | |
JP2008543120A (ja) | パケット転送制御方法及びパケット転送制御装置 | |
KR100597432B1 (ko) | 이웃탐색 프록시 기반의 아이피브이6 이동 네트워크에서의이동노드를 위한 경로최적화 방법 | |
JP2010541302A (ja) | 移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 | |
KR100927940B1 (ko) | 이동 네트워크에서 smr을 이용한 위치 등록 방법 및 패킷 전달 방법 | |
JP2010541304A (ja) | 移動ネットワークにネストされた移動ノードが最適経路通信を行うためのシステム、方法及び装置 | |
KR100700526B1 (ko) | 무선 네트워크에서의 핸드오버 방법 | |
WO2004036786A1 (en) | Mobile node handoff methods and apparatus | |
Sornlertlamvanich et al. | Route optimization in nested mobile networks using binding update for top-level MR | |
KR101441499B1 (ko) | 이종의 모바일 아이피 도메인 간 경로 최적화 방법 | |
Safa et al. | Improving Location Management in Mobile IPv4 Networks. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110915 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110915 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20120405 |