JP3573265B2 - パケットを無線デバイスに送信するステップ - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はインターネット及び他のパケットベースのネットワークに関し、特に、移動体デバイス（モバイルデバイス）によるパケットベースネットワークへの無線アクセス方法に関する。
【０００２】
【従来の技術】
通信ノードと移動体デバイス（モバイルデバイス）との間のインターネットを介した無線アクセスに関するサポートについては、“移動体でのＩＰサポート”という表題のインターネットエンジニアリングタスクフォース（ＩＥＴＦ）提案（Ｃ．Ｅ．Ｐｅｒｋｉｎｓ編、リクエスト・フォー・コメント（ＲＦＣ）２００２（１９９６年１０月、以降、本明細書においては“モバイルＩＰ”として指し示す））にその概要が述べられている。モバイルＩＰを用いることによって、各々のモバイルデバイスは、そのインターネットへの接続点にかかわらず、固定されたホームアドレス及び関連するホームエージェントによって常に識別される。通信ノードからモバイルデバイスへ送出されるパケットは、ホームエージェント宛に回される。移動装置がホームドメインから離れている場合には、ホームエージェントは、パケットをこの移動装置に関連する外部エージェントにトンネリング（通過）する。
【０００３】
ＩＰパケットは、ＩＰパケットヘッダとして用いることのできるパケットの４０バイトでその大きさが限られている。このＩＰヘッダは、ソースアドレスとデスティネーション（宛先）アドレスとを有する。対応するノードは、ＩＰヘッダのソースアドレスとして設定され、移動装置はＩＰヘッダデスティネーションアドレスとして設定される。限られたパケットサイズの残りの部分は、データペイロード用に用いることができる。ホームエージェントをホストするノードで、パケットを受信し、移動装置がホームドメインから離れているときには、ホームエージェントは、ＩＰパケットをインターセプトし、このＩＰパケットに添付されたＩＰヘッダデスティネーションアドレスとソースアドレスを組み込み、この組み込まれたパケットをＩＰ−ｉｎ−ＩＰトンネル形式で埋め込まれたパケットを、外部エージェントに転送する。
【０００４】
この組み込まれたパケットは、元の４０バイトのＩＰヘッダと、１０バイトの添付したＩＰヘッダソースアドレス（フォームエージェントのＩＰアドレスにより指定される）と、１０バイトの添付したＩＰヘッダデスティネーションアドレス（外部エージェントのＩＰアドレスで指定される）からなり、この限られたパケットサイズの残りの部分は、データペイロード用に利用できる。組み込まれたパケットのデータペイロード部分は、トンネリング用に組み込まれなかったパケット内のデータペイロード用に利用できるものよりも２０バイト少ない。その後、この組み込まれたパケットは、外部エージェントにトンネリングされる。
【０００５】
【発明が解決しようとする課題】
トンネリング用に用いられる、組み込まれたアドレスを含めることにより、少なくとも２つの好ましくない影響がある。第１の影響は、カプセル化するヘッダアドレスの追加は、パケットのオーバーヘッドをさらに含むために、パケットの伝送効率を減少させ、利用可能なデータペイロード部分が減少することである。第２の影響は、最大サイズのパケットが移動装置にトンネリングするために、ホームエージェントによりインターセプトされると、ホームエージェントは、インターネット制御メッセージプロトコル（ｉｎｔｅｒｎｅｔ ｃｏｎｔｒｏｌ ｍｅｓｓａｇｅ ｐｒｏｔｏｃｏｌ：ＩＣＭＰ）エラーメッセージを、対応するノードに戻し、トンネリングのヘッダの追加が、フラグメンテーション（ｆｒａｇｍｅｎｎｔａｔｉｏｎ）を必要とすることを指示する点である。その後、この対応するノードが、パケットのデータペイロードサイズを制限し、再度転送する。そのため、対応するノードからホームエージェントにパケットを転送するための、往復時間が必要とされる。この影響は、対応するノードから移動装置へ、ウェブ転送を行うために、移動装置ＩＰトンネリングスキーム（Ｍｏｂｉｌｅ ＩＰ ｔｕｎｎｅｌｉｎｇ ｓｃｈｅｍｅ）を用いるとき、特に顕著で、その結果、５００ミリ秒のさらなる遅れが発生する。これは、ウェブのページトランスファーは、転送を行うために複数の伝送制御プロトコル、トランスミッション制御コントロールプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：ＴＣＰ）のダウンロードを必要とするからである。
【０００６】
【課題を解決するための手段】
パケットの遅延と、トンネリングのオーバーヘッドは、パケットがホームエージェントから移動装置の外部エージェントに、各パケットを余分のソースアドレスとデスティネーションアドレスでもって組み込むことなく、ホームエージェントにおけるパケットのデスティネーションアドレスを置換することにより転送される。本発明の一実施例においては、外部エージェントは、移動装置と共通場所に配置される。移動装置が新たな外部エージェントを獲得したときには、移動装置は、ホームエージェントに対し、外部エージェントに対応するアドレスを通知する。
【０００７】
移動装置を有するホームエージェントが、パケットのヘッダデスティネーションアドレスとして受信したパケットは、余分のソースアドレスとデスティネーションアドレスとが組み込まれていない。パケットヘッダは、解析され、外部エージェントのアドレスが移動装置のアドレスの代わりに用いられ、パケットは、外部エージェントに転送される。この外部エージェントは、パケットを受信すると、外部エージェントのアドレスを取り除き、移動装置のアドレスをパケットヘッダアドレスとして置き換える。その後このパケットは、移動装置に転送される。
【０００８】
パケットヘッダデスティネーションアドレスを交換することにより２つの利点がある。第１の利点は、組み込むヘッダアドレスを必要とせずまた使用されることもないので、ホームエージェントから外部エージェントに転送されるパケットのパケットヘッダサイズが増えることはない。そのため、パケットの伝送効率は、移動ＩＰトンネリング用に用いられる系に比較すると改善する。第２の利点は、パケットのペイロードサイズは、ホームエージェントから外部エージェントに転送されるパケットに対しては減少しないので、ホームエージェントは、ＩＣＭＰエラーメッセージを対応するノードに戻すことはなく、そのため、データペイロードサイズが減少したパケットを再度転送する必要はない点である。
【０００９】
【発明の実施の形態】
以下、本発明は、例えばインターネットやイントラネットなどのインターネットプロトコル（ＩＰ）ベースのネットワークへの無線アクセスに関して用いられる実施例を用いて記述されるが、本明細書に記載されている実施例は例示目的のみのものであって本発明を限定するものではない。本発明は、モバイルデバイスからのあらゆるパケットベースネットワークへの無線アクセスに関して等しく適用可能である。
【００１０】
図１は、従来技術に係る、モバイルデバイスからのインターネットプロトコル（ＩＰ）ベースのネットワークへのモバイルＩＰ無線アクセスを実現するために用いられているアーキテクチャ例を示している。通信ノード１１０は、サービスプロバイダ１１２を介してインターネット１００にアクセスしているように描かれている。通信ノードは、移動体かあるいは固定かのいずれかである。モバイルデバイス１１４を用いる移動体ユーザは、基地局ＢＳ１に近接して描かれており、基地局ＢＳ１との間に設定された接続を保っている。モバイルデバイスは、無線ホストあるいはルータであって、その接続点をあるネットワークもしくはサブネットから別のものに変更することが可能である。モバイルデバイス１１４にはホームエージェント１１８が関連づけられており、ホームエージェント１１８はサービスプロバイダ１１６を介してインターネット１００にアクセスするように示されている。ホームエージェントはノードあるいはルータによってインプリメントされ、モバイルデバイスがホームから離れている場合には当該モバイルデバイス宛に伝達する目的でパケットを通過させ、当該モバイルデバイスに係る現時点での位置情報を管理している。
【００１１】
さらに図示されているのがルータであり、インターネットと複数個の基地局間でパケットをルーティングする目的で使用される。詳細に述べれば、ルータＲ１は、ルータＲ２及びＲ３に対するインターフェースとして機能している。ルータＲ２は、基地局ＢＳ１及びＢＳ２に対するインターフェースとして機能している。同様に、ルータＲ３は、基地局ＢＳ３及びＢＳ４に対するインターフェースとして機能している。モバイルＩＰの観点及び本明細書の以下の部分全てにおいては、基地局は従来技術に係る無線基地局に関連する全ての機能を含んでおり、さらに、従来技術に係るルータに関連する機能も含むものとする。この二重機能性は、ルータ及び基地局を統合するという方法、あるいは、個別のルータ及び基地局を双方の間でパケットを交換するように適切にインターフェースする方法のいずれかで実現されうる。後者の場合には、ルータ部分及び基地局部分が通常同一箇所に配置されるが、必ずもそうである必要はない。
【００１２】
モバイルＩＰによって実現されるＩＰ移動性サポートは、現在どの点からインターネットに接続されているかにかかわらず、各々のモバイルデバイスが常にそのホームアドレスによって識別されることが特徴である。常にホームから離れている場合においても、モバイルデバイスには気付アドレス（ｃａｒｅ−ｏｆ ａｄｄｒｅｓｓ）も関連付けられており、その現時点でのインターネットへの接続点に係る情報を提供する。モバイルＩＰは、気付アドレスのホームエージェントへの登録を必要とする。ホームエージェントは、モバイルデバイス宛のパケットをＩＰ−ｉｎ−ＩＰカプセル化済みパケット内で気付アドレス宛に通過させる。ＩＰ−ｉｎ−ＩＰパケットが気付アドレスに到着すると、付加されたＩＰアドレスが除去されて元のパケットデータが適切なモバイルデバイス宛に伝達される。気付アドレスは、モバイルデバイス宛に転送されたパケットの、モバイルデバイスがホームから離れて存在する場合のモバイルデバイスへのトンネリングの終端点である。
【００１３】
モバイルＩＰ方式の動作の一例として、モバイルデバイス１１４が、図１に示されているように、位置１から位置４まで順次移動するのに連れて、そのインターネットへの接続点を（ハンドオフを介して）基地局ＢＳ１からＢＳ４へ変更する場合を考える。基地局ＢＳ１の近傍にいる場合には、通信ノード１１０からモバイルデバイス１１４宛に送出されたパケットは、まずモバイルデバイスのホームエージェント１１８へ送出される。ホームエージェント１１８は各々のパケットを基地局ＢＳ１に係る対応するアドレス宛に通過させる。モバイルデバイスがハンドオフを行なって基地局ＢＳ２に接続されると、そのインターネットへの接続点は基地局ＢＳ２に対応するアドレスに変更される。この時点では、ホームエージェントはモバイルデバイス１１４宛のパケットを基地局ＢＳ２へ通過させる。このルーティング変更をインプリメントするためには、ホームエージェント１１８に対して、接続点が変更されたことを知らせる通知がなされなければならない。ホームエージェントは、この通知を受信すると、設定済みのルーティングテーブルを更新し、モバイルデバイス１１４宛のそれ以降のパケットは基地局ＢＳ２へと通過させられることになる。基地局ＢＳ３及びＢＳ４へのハンドオフも同様に取り扱われる。このような伝達方式は、三角ルーティングとして知られている。モバイルＩＰ及びホームエージェントを用いる三角ルーティング方式は、モバイルデバイスがそのインターネットへの接続点をあるＩＰサブネットから別のＩＰサブネットに変更する場合のような、マクロ的な移動性を実現するための手段としては効率的である。しかしながら、モバイルＩＰは、共通のサブネット内での、それぞれ非常に狭い地形的な領域をカバーしている無線トランシーバ間でのハンドオフのような、ミクロ的な接続性を実現するためにはあまり効率的ではない。
【００１４】
最近、モバイルＩＰプロトコルへの拡張が、“モバイルＩＰのルート最適化”という表題のインターネットエンジニアリングタスクフォース提案の草稿（Ｃ．Ｅ．Ｐｅｒｋｉｎｓ編、インターネットドラフト−ワークインプログレス（１９９７年１１月））で発表された。このルート最適化拡張は、ホームエージェント宛に転送されることなくパケットが通信ノードからモバイルデバイス宛にルーティングされるための手段を提案している。ルート最適化拡張は、通信ノード１１０がモバイルデバイス１１４に係るバインドをキャッシュし、そのバインドに示された気付アドレス宛にパケットを直接送出することによって、モバイルデバイスのホームエージェント１１８をバイパスする。この提案を用いることによって、パケットは、ハンドオフ間の中断を低減する目的で、旧基地局の外部エージェントから新基地局の外部エージェント宛に転送される。しかしながら、モバイルデバイスの気付アドレスは、モバイルデバイスが基地局間でハンドオフするたび毎に変更されてしまう。例えば、モバイルデバイス１１４が基地局ＢＳ１（旧基地局）から基地局ＢＳ２（新基地局）にハンドオフすると仮定する。ルート最適化拡張は、（サービスを提供している基地局に係る）現在の外部エージェントに対する気付アドレスをバインドするため、気付アドレスはＢＳ１からＢＳ２に変更される。このような方式は、ミクロ的な移動性を改善するが、モバイルデバイス１１４のハンドオフのたび毎に、ホームエージェント１１８及び通信ノード１１０への通知が不可避である。
【００１５】
モバイルデバイスがホームネットワーク（すなわち、モバイルデバイスのホームエージェントが位置するのと同一のネットワーク）内に存在する場合には、モバイルデバイス宛のパケットはホームエージェントによってインターセプトされる。ホームエージェントは、それらのパケットを通常のＩＰパケットとしてルーティングし、モバイルデバイスが通常接続されているローカルエリアネットワーク宛に送出する。それゆえ、モバイルＩＰは、ルート最適化拡張が用いられるか否かにかかわらず、ローカルサブネット内の移動性をサポートしない。モバイルデバイスがローカルサブネット内でその接続点を変更する場合には、その変更はリンク層修正技法によるか、あるいは、モバイルデバイス宛のパケットをそのローカルサブネットに接続されている全ての基地局宛にブロードキャストするかのいずれかによって取り扱われなければならない。リンク層を取り扱うことは受容され得ないほどの遅延やパケットロスを招く可能性があり、全基地局宛にパケットをブロードキャストすることは帯域利用の面で非効率的である。
【００１６】
ローカル移動性ドメイン
今日の広域ＩＰネットワークは、通常、それぞれ独立した主体によって管理されている複数個のサブネットに分割されており、各々の主体はそれぞれのサブネット内で独立のローカルプロトコルを用いて動作しているが、それぞれのサブネットの外部に対するインターフェースとして標準的なプロトコルを認証している。本発明は、本発明は、主体によって制御されているサブネット（例えば、インターネットにアクセスするルートルータを有し複数個の基地局に対してサービスを提供しているセルラーサービスプロバイダ）に係る自然な独立性及び自律性を、複数個のドメインを分類・規定することによって利用する。各々のドメインは、実際にはローカルサブネットである。各々のドメインは、インターネットへのアクセスを行なうルートルータを管理しており、ドメイン内の全ルータは共通のローカルプロトコルを利用する。
【００１７】
本発明は、規定されたドメイン内で共通のルートルータを有するルータを分類する際に、モバイルユーザの基地局間の移動性は、通常、ローカライズされた事象である（すなわち、大部分のハンドオフは物理的に隣接している基地局間で発生し、共通のルートルータを介してインターネットに接続されている共通のサービスプロバイダによって管理されて操作されている）という事実を利用する。
【００１８】
本発明を用いることによって、移動中のモバイルデバイスが割り当てられたホームドメイン内のある基地局から当該割り当てられたホームドメイン内の別の基地局へとハンドオフされる場合に、当該ホームドメイン内の選択されたルータが、その変更を反映する目的で純粋にローカルなレベルでの（すなわち、当該ホームドメイン内のルータのみの）特別の経路設定メッセージを用いて関連するルーティングテーブルを更新する。よって、ルータ間のメッセージング及びシグナリングは最少化される。なぜなら、更新はローカルドメインベースレベルのみでなされ、さらに、選択されたルータのみ（すなわち、ルーティングテーブルの更新が必要とされるルータのみ）に対するものであるからである。さらに、モバイルＩＰを用いる場合には、パケットがホームドメイン内に含まれる全ての基地局宛にブロードキャストされるか、あるいは単一の基地局を指示するためにリンク層アドレッシングが必要とされていたのに対して、本発明は、パケットを単一の基地局へ導くためにホームドメインルータの個別のルーティングテーブルを更新する。ＩＰ層ルーティングはエンド−ツー−エンドで用いられるため、ＩＰ層ＱｏＳメカニズムが本発明と共に用いられうる。
【００１９】
しかしながら、移動中のモバイルデバイスが割り当てられたホームドメイン内のある基地局から外部ドメインに属する別の基地局へハンドオフされる場合には、パケットはホームエージェントから当該外部ドメイン内のモバイルデバイスに対して割り当てられた気付アドレスに対して通過（トンネリング）させられる。外部ドメイン内のミクロ的な移動性は、モバイルデバイスがその外部ドメインに係る基地局を介してインターネットに接続されている期間全体を通して当該モバイルデバイス対する同一の気付アドレスを保持することによって、そのドメインに係る基地局間で実行されたハンドオフの回数にかかわらずに実現される。その代わり、ホームドメイン内で実行されるハンドオフに関連して記述されているように、その外部ドメイン内の選択されたルータのルーティングテーブルが、その変更を反映する目的で純粋にローカルなレベルでの（すなわち、当該外部ドメイン内のルータのみの）特別の経路設定メッセージを用いて更新される。よって、外部エージェントとホームエージェントの間のメッセージング及びシグナリングが最少化される。なぜなら、、更新はローカルドメインベースレベルのみでなされ、さらに、選択されたルータのみ（すなわち、ルーティングテーブルの更新が必要とされるルータのみ）に対するものであるからである。よって、外部ドメイン内の基地局間のハンドオフは、モバイルユーザのホームエージェント及び通信ノードに対しては、実質的にトランスペアレント（透過的）である。
【００２０】
図２は、本発明に従った、ハンドオフ認識無線アクセスインターネットインフラストラクチャ（ＨＡＷＡＩＩ）に関するドメインベースアーキテクチャを模式的に示した図である。ＨＡＷＡＩＩをインプリメントするために、無線ネットワークの有線アクセス部分が複数個のドメインに分割されている。各々のドメインは共通のルートルータを有しており、そのルートルータを通じてそのドメイン内の基地局に接続されたモバイルユーザ宛の全てのパケットが転送される。詳細に述べれば、図２においては、無線ネットワークの有線アクセス部分が二つのドメイン、ドメイン１及びドメイン２に分割されている。ドメイン１は、基地局ＢＳ５、ＢＳ６、あるいはＢＳ７に接続されたモバイルデバイス宛の全てのパケットがルーティングされる場合に通過するルートルータを有している。具体的には、ルータＲ４及びＲ５が、適切な基地局宛にパケットを転送する目的で用いられるドメイン１内のダウンストリームルータとして示されている。この実施例においては、ドメイン１は、モバイルデバイス１１４にサービスを提供するホームドメインを表わすサブネットを包含するものとして規定されている。ホームエージェント１５２はルートルータ１５０に組み込まれている。この実施例においては、ホームエージェント１５２がルートルータ１５０内に存在するプロセッサ及びメモリの機能を利用してルートルータ内でインプリメントされているが、ホームエージェント１５２を、パーソナルコンピュータで利用可能なもののようなプロセッサ及びメモリを用いて、個別にインプリメントしてルートルータと同一箇所に配置することも可能であることは当業者には明らかである。さらに、ホームエージェントは、ルートルータと共にインプリメントされる必要は必ずしも無い、すなわち、ホームエージェントは、ホームドメイン内の（基地局を含む）他のルータと通信することが可能なあらゆるローカルルータもしくはノードにインプリメントされることが可能である。ドメイン２は、ドメイン１に組み込まれていない基地局にサービスを提供する第二ドメインを表現するサブネット例として提示されている。それゆえ、ドメイン２は外部ドメインを代表していることになる。ドメイン２に組み込まれているのは、単一あるいは複数個の基地局に対してサービスを提供する複数個のルータである。例示目的で、ルータＲ６がドメイン２に係るルートルータとして示されており、ＢＳ８はドメイン２に属するルータを介してサービスを提供されている基地局のうちの一つとして示されている。ルータＲ６は、ドメイン２をその関連づけられたホームドメインとして有するモバイルデバイスに対するホームエージェント及びルートルータとしての機能を有するように設定されており、よって、ドメイン２は、ルートルータ１５０内にホームエージェント機能を有するモバイルデバイスに関しては外部ドメインである一方、同時に、ルータＲ６内にホームエージェント機能を有するモバイルデバイス（図示せず）に対するホームドメインでもある。それ以外のドメイン（図２には示されていない）の各々は、共通のルートルータを介してインターネット１００に接続された単一あるいは複数個の基地局に対するインターネットアクセスを実現する。
【００２１】
モバイルデバイス１１４を操作しているモバイルユーザがドメイン内で移動する場合には、そのドメインがホームドメインか外部ドメインであるかにかかわらず、モバイルデバイスのＩＰアドレスは不変である。例えば、モバイルデバイス１１４が、最初に基地局ＢＳ５からのサービスを受けていて、その後基地局ＢＳ６さらにＢＳ７へとハンドオフされた場合であっても、モバイルデバイスのＩＰアドレスは同一に保たれる。当該モバイルユーザに対するホームエージェント及び通信ノードは、当該モバイルデバイスがそのドメイン内でいずれの基地局を介して接続されている場合においても、ユーザが移動したことからはシールドされている（ユーザが移動したことの影響を受けない）。ドメイン内の新たな基地局からモバイルデバイスへのパケット伝達設定は、以下に記述されるように、特別の経路設定方式を用いることによって実現される。この方式は、ドメイン内の選択されたルータにおける選択されたホストベースのルーティングテーブルを更新する。各々のドメインがローカルサブネットとして識別されているため、それぞれのドメインの外部のバックボーンルータにおけるルーティングエントリの変更あるいは更新は不要である。この方法は、前述されたモバイルＩＰへのルート最適化拡張に関して用いられた方法とは明確に異なっている。ルート最適化拡張においては、モバイルデバイスが隣接する基地局間でハンドオフする度に、モバイルデバイスの気付アドレスが変更されるが、個々のルータ内に含まれるルーティングエントリは不変であった。
【００２２】
モバイルデバイス１１４が、その接続点を、第一ドメインに係る基地局（第一ドメインはホームドメインであるか外部ドメインであるかのいずれかである）から第二ドメインに係る基地局（第二ドメインは外部ドメインのいずれかであるがホームドメインではない。なぜなら、モバイルデバイスの接続点がホームドメイン内に含まれるあらゆる基地局である場合にはトンネリングが必要ではないからである。）に変更する場合には、パケットは新たな（第二）ドメイン内の当該モバイルデバイス宛に、パケットトンネリングのための、例えばモバイルＩＰなどの適切なプロトコルを用いて、ホームエージェントから転送される。モバイルデバイス１１４が（ドメイン１を介してインターネットに有線接続されている）基地局ＢＳ７から（ドメイン２を介してインターネットに有線接続されている）基地局ＢＳ８へとハンドオフを行なう場合には、ホームドメイン（ドメイン１）内のルートルータ１５０におけるホームエージェント１５２は、パケットのカプセル化を開始し、それらを、ドメイン２内の基地局へのハンドオフの際にモバイルデバイスが獲得した気付アドレスへと通過させる。よって、アプリケーションは、同一のＩＰアドレスを中断することなく継続使用できる。
【００２３】
モバイルユーザ宛のパケットフローの伝達に係る保証されたサービス品質（ＱｏＳ）を実現する目的で、パケットフロー経路に沿った各々のルータは各々のパケットに係る所定のレベルのＱｏＳを規定し、それに従って適切なルータリソースが予約される。この分類機能を実行する一つの方法は、各々のパケットに係るＱｏＳレベルを規定するパケットヘッダフィールドを利用することである。このような方式は、Ｔ．Ｖ．Ｌａｋｓｈｍａｎ ａｎｄ Ｄ．Ｓｔｉｌｉａｄｉｓによる“効率的な多次元レンジマッチングを利用した高速ポリシーベースパケット転送”という表題の論文（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ ＳＩＧＣＯＭＭ， １９９８）及びＶ．Ｓｒｉｎｉｖａｓａｎ， Ｇ．Ｖａｒｇｈｅｓｅ， Ｓ．Ｓｕｒｉ， ａｎｄ Ｍ．Ｗａｌｄｖｏｇｅｌによる“レベル４スイッチングのための高速スケーラブルアルゴリズム”という表題の論文（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＣＭ ＳＩＧＣＯＭＭ， １９９８）に記載されている。
【００２４】
しかしながら、ＨＡＷＡＩＩにおいてインプリメントされたローカル移動性ドメインを用いること、及び、本発明に従うことによって、通信ノードから対応するモバイルデバイス宛に送出されたパケットは、パケットのデスティネーションアドレスによって一意的に識別される。このデスティネーションアドレスは、（モバイルデバイスがホームドメイン内の基地局を介してネットワークに接続されている場合には）モバイルデバイスのホームアドレスであり、あるいは、（モバイルデバイスが外部ドメイン内に組み込まれた基地局を介してネットワークに接続されている場合には）モバイルデバイスの気付アドレスである。よって、ローカル移動性ドメインないでのフロー毎の基準に基づくパケットに対するＱｏＳを実現することが、そのサービスをモバイルＩＰ方式（この場合には、パケットがモバイルデバイスそのものではなく、サービスを提供している基地局に対応する気付アドレスに対して通過させられる）を用いて実現する場合に比較して大幅に簡略化される。
【００２５】
ＨＡＷＡＩＩローカル移動性ドメイン方式におけるモバイルデバイスユーザには、動的ホスト配置プロトコル（ＤＨＣＰ）サーバを介して動的にＩＰアドレスが割り当てられる。デバイスがドメイン内の基地局間でハンドオフされる場合には、そのデバイスに割り当てられたＩＰアドレスは不変である。それゆえ、ドメイン外のユーザは、当該モバイルユーザが移動したことを認識しない。この方式は、各々のモバイルデバイスに割り当てられた二つのＩＰアドレスを用いる、その一方はホームドメイン内におけるモバイルデバイスに割り当てられるものであり、他方はモバイルデバイスが外部ドメインに係る基地局を介して接続されている場合に割り当てられるものである。複数個のＩＰアドレスの利用はＩＰアドレスの現在の限られた利用性を悪化させるものであるが、この限られたＩＰアドレスの問題は、ＩＰバージョン６の利用が一般化すれば議論できるものになると思われる。
【００２６】
現在利用可能なＩＰアドレスを維持する最適化は、動的ホーム最適化と呼称される。動的ホーム最適化を用いる場合には、モバイルデバイスは、それが起動されるまでは、何らアドレスが割り当てられない。データクライアントとしてのモバイルデバイスは、通常、ウェブサーバあるいはメールサーバのようなサーバとのトランザクションを開始するので、固定されたＩＰアドレスは不要である。その初期起動に際して、モバイルデバイスには、その起動がなされた時点で属していたドメインに係る動的ホスト配置プロトコル（ＤＨＣＰ）サーバから“動的固定アドレス”が割り当てられる。その後、そのドメインはそのモバイルデバイスに係るホームドメインとなる。それゆえ、モバイルデバイスは、固定されたアドレスを有することがなく、また、モバイルデバイスがいずれかのドメインに固定的に登録されることもない。モバイルデバイスが、それが起動された時点でのドメイン以外のドメインにおける基地局へとその接続点を変更する場合には、その新たなドメイン内に存在するＤＨＣＰサーバによって第二のＩＰアドレスが割り当てられる。この第二アドレスはモバイルデバイスの気付アドレスとなる。モバイルデバイスの電源が切断されると、モバイルデバイスはその（起動時点のドメインにおけるＤＨＣＰサーバによって割り当てられた）動的固定アドレス及び（電源切断時点で接続されていたドメインのＤＨＣＰサーバによって割り当てられた）気付アドレスを放棄する。次回の起動の際には、モバイルデバイスにはそれが起動された時点で接続されるドメインにおける新たな動的固定アドレスが割り当てられる。
【００２７】
図３は、本発明に係る、ドメインベースＨＡＷＡＩＩ方式を、動的ホーム最適化を用いずにインプリメントする目的で、動的ホスト配置プロトコル（ＤＨＣＰ）サーバによって実行されるプロセスステップを示す流れ図例である。ステップ１７０においては、モバイルデバイスには、ホームドメイン内において用いられるホームアドレスが割り当てられる。ＤＨＣＰサーバは、ルートルータ内に存在するプロセッサ及びメモリの機能を用いてインプリメントされうるが、パーソナルコンピュータにおいて利用可能なもののような個別のプロセッサ及びメモリを用いることによってＤＨＣＰサーバを実現することが可能であることは当業者には明らかである。さらに、ＤＨＣＰサーバはルートルータに関連してインプリメントされる必要は必ずしも無い、すなわち、ＤＨＣＰサーバは、ドメイン内の（基地局を含む）他のルータと通信することが可能なあらゆるローカルルータあるいはノードにおいてインプリメントされうる。モバイルデバイスが起動される（ステップ１７２）と、モバイルデバイスがそのホームドメイン内に含まれる基地局を介して接続されているか否かが決定される（ステップ１７４）。モバイルデバイスがホームドメインを介して接続されている場合には、ステップ１７８に従って、特別の経路設定方式（後に記述される）を用いて、ホームドメイン内でのホストベースルーティングが設定される。
【００２８】
モバイルデバイスが外部ドメイン（ホームドメイン以外のドメイン）を介して接続されている場合には、ステップ１７６に従って、モバイルデバイスはその外部ドメインをサポートしているＤＨＣＰサーバから気付アドレスを獲得する。ステップ１８０においては、特別の経路設定方式を用いて、外部ドメインにおけるホストベースルーティングが設定される。気付アドレスが獲得されて経路設定方式が設定されると、モバイルデバイス宛のパケットは、ホームドメインのルートルータからモバイルデバイスの気付アドレスに通過させられる（ステップ１８２）。ステップ１８４においては、モバイルデバイスが現在のドメイン内に含まれる基地局に対してハンドオフされた場合には、（以下に記述されるハンドオフ経路設定メッセージが生成される以外は）何ら操作がなされない。しかしながら、モバイルデバイスが新たなドメインに属する基地局に対してハンドオフされる場合には、現在の気付アドレスが解放される（ステップ１８６）。この流れ図は、ここからステップ１７４の直前に戻って、モバイルデバイスのホームドメインへの接続がなされるか否かに係るチェックが実行される。この手続きは、モバイルデバイスの電源が切断されるまで、ハンドオフ毎に継続される。
【００２９】
図４は、動的ホーム最適化を用いるドメインベースＨＡＷＡＩＩ方式をインプリメントする目的で、ドメインにおける動的ホスト配置プロトコル（ＤＨＣＰ）サーバにおいて実行されるプロセスステップを例示する流れ図である。この手続きは、モバイルデバイスに対して固定ホームアドレスが割り当てられない点を除いて、図３と共に記述された手続きと同様である。前述されているように、動的固定ホームアドレスが導入される。ステップ２００において、モバイルデバイスがまず起動され、そのドメイン内でのアドレスを獲得する前に、サービス提供側基地局との間のリンクが設定される。リンクが設定された後、ドメインのＤＨＣＰサーバは、モバイルデバイスに対して固定ホームアドレスを割り当てる（ステップ２０２）。ステップ２０４においては、モバイルデバイスがそのホームドメイン内に含まれる基地局を介して接続されているか否かが決定される。動的ホーム最適化を用いる場合には、最初の起動後は、モバイルデバイスは常にそのホームドメイン内に含まれる基地局に接続されているため、特別の経路設定方式を用いてホームドメイン内でのホストベースルーティングが設定される（ステップ２０６）。ステップ２１４においては、モバイルデバイスがそのホームドメイン内に含まれる基地局に対してハンドオフされる限りは、（以下に記述されるハンドオフ経路設定メッセージの生成を除いて）何ら操作が行われない。しかしながら、モバイルデバイスが外部ドメインに属する基地局に対してハンドオフされる場合は、流れ図はステップ２０４の直前に戻って、モバイルデバイスのホームドメインへの接続に係るチェックが実行される。この際、ステップ２１６における気付アドレスの解放は行われない。なぜなら、モバイルデバイスに対しては何も割り当てられていないからである。
【００３０】
ステップ２０４で、モバイルデバイスが外部ドメインに接続されていることが決定された場合には、モバイルデバイスは、その外部ドメインをサポートしているＤＨＣＰサーバから気付アドレスを獲得する。ステップ２１０においては、特別の経路設定方式を用いて、当該外部ドメインにおけるホストベースルーティングが設定される。気付アドレスが獲得され、経路設定方式が設定されると、モバイルデバイス宛のパケットは、ホームドメインのルートルータからモバイルデバイスの気付アドレス宛に通過させられる（ステップ２１２）。ステップ２１４においては、モバイルデバイスが現在のドメインに含まれる基地局に対してハンドオフされる限りは（以下に記述されるハンドオフ経路設定メッセージを除いて）何ら操作がなされない。モバイルデバイスが新たなドメインに属する基地局に対してハンドオフされる場合には、現在の気付アドレスが解放される（ステップ２１６）。この流れ図は、ステップ２０４の直前に戻って、モバイルデバイスがそのホームドメインに接続されているか否かのチェックがなされる。この手続きは、モバイルデバイスの電源が切断されるまで、各ハンドオフに関して継続される。
【００３１】
図５は、本発明に従って、動的ホーム最適化が用いられるか否かにかかわらず、モバイルデバイスの電源が切断される際に実行されるドメインベースプロセスステップを例示する流れ図である。モバイルデバイスは、現在の基地局を介してリンクを維持している（ステップ２３０）。ステップ２３２においては、動的ホスト配置プロトコル（ＤＨＣＰ）サーバが動的ホスト最適化を利用しているか否かのチェックがなされ、利用している場合には、モバイルデバイスがそのホームドメインを介してインターネットに接続されているか否かの決定がなされる（ステップ２４０）。モバイルデバイスが、電源切断の時点で外部ドメイン内の基地局を介してインターネットに接続されている場合には、動的固定ホームアドレス及び割り当てられた気付アドレスが後の割り当て及び利用に備えて対応するＤＨＣＰサーバに返還される（ステップ２４４）。しかしながら、モバイルデバイスが、電源切断の時点でそのホームドメイン内の基地局を介してインターネットに接続されている場合には、動的固定アドレスのみが後の割り当て及び利用に備えて対応するＤＨＣＰサーバに返還される。なぜなら、そのホームドメイン内ではモバイルデバイスには気付アドレスが割り当てられないからである。
【００３２】
動的ホスト配置プロトコル（ＤＨＣＰ）サーバが動的ホスト最適化を用いない場合には、ステップ２３４において、モバイルデバイスがそのホームドメインを介してインターネットに接続されているか否かの決定がなされる。モバイルデバイスが、その電源切断の時点で、外部ドメイン内の基地局を介してインターネットに接続されている場合には、割り当てられた気付アドレスが後の割り当て及び利用に備えて対応するＤＨＣＰサーバに返還される。しかしながら、モバイルデバイスが、その電源切断の時点でホームドメイン内の基地局を介してインターネットに接続されている場合には、何ら操作がなされない。これは、動的ホーム最適化を用いない場合には、固定ホームアドレスが対応するＤＨＣＰサーバに返還されないからである。なぜなら、ホームアドレスが動的に割り当てられるのではなく、ホームＤＨＣＰサーバにおいて当該モバイルデバイスに関して固定的に登録されるからである。
【００３３】
図６は、動的ホスト配置プロトコル（ＤＨＣＰ）サーバ２７２及びホームエージェント２７０を実現しているドメインルータ２６０の実施例を示している。ドメインルータは、直前のノードからのパケットを受信する複数個の入力ポート（インターフェース）２６２及び次のホップに対してパケットを送出する出力ポート（インターフェース）２６４を有している。これらのインターフェースが双方向であることが可能であることは当業者には明らかである。すなわち、インターフェースは、入力及び出力インターフェースの双方として機能しうる。さらに、各々のルータは、プロセッサ２６６及びメモリ２６８を含んでいる。各々のルータに存在しているプロセシング及びメモリリソースにより、フォワードアルゴリズム、キューイング、シグナリング、メッセージングのインプリメント、ルータフォワードテーブルのインプリメント、及び他の標準的及び補足的ルータ機能及びサービス等のルータ機能及びサービスの実現を可能にする。図６に示されているドメインルータ２６０は、プロセッサ２６６及びメモリ２６８のリソースを用いてインプリメントされたＤＨＣＰサーバ２７２及びホームエージェント２７０を含むように示されている。通常、ＤＨＣＰサーバ及びホームエージェント２７０がインプリメントされているドメインルータ２６０はドメインルートルータであるが、前述されているように、このことは必須ではない。他のルータ（基地局含む）と通信することが可能なあらゆるローカルルータあるいはノードにホームエージェント及びＤＨＣＰサーバをインプリメントすることが可能であることは当業者には明らかである。さらに、ドメインルートルータとの適切な通信が実現される場合には、例えばパーソナルコンピュータにおいて利用可能なもののような個別のプロセッサ及びメモリを用いて、ルータそのものの外部にホームエージェント及びＤＨＣＰサーバをインプリメントすることが可能であることも当業者には明らかである。ルータ内への外部エージェントをインプリメントすることも、必要な場合には同様に可能である。
【００３４】
本発明に係るホストベースルーティングは、システムのスケーラビリティを効率的に実現することに留意されたい。例えば、ドメインのルーティングテーブル内に含まれるルーティングエントリの個数はそのドメイン内におけるアクティブ状態にあるモバイルユーザ数に依存する。通常、各無線基地局は、利用可能な無線帯域スペクトルが限定されているために、そのサポート可能なアクティブユーザ数が１００程度に限定されている。現在のルータが１万のオーダーのルータエントリをサポートすることが可能であるため、ドメインサイズはおよそ１００程度の基地局を含むように設計されている。１００個の基地局がカバーする領域はかなり広い（都市部に位置するか郊外に位置するかに依存して、半径２０ｋｍ^２から５００ｋｍ^２）ため、ユーザの移動の大部分は単一のドメイン内であり、結果として、ホームエージェント及び通信ノードに関して実質的にトランスペアレントな移動性が実現される。それゆえ、スケーラビリティは、（ｉ）現在のルータに固有の、１万のオーダーのルーティングエントリを処理することが可能であるという事実を通じて、及び、（ｉｉ）各々のドメイン内のルータによって管理されることが必要とされるルーティングエントリの最大数を制限する目的で適切なドメインサイズを用いることによって、保証される。これに対して、ドメインルータではないインターネットバックボーンルータは、サブネット（ドメイン）ベースルーティングエントリのみを管理することが必要とされる。
【００３５】
経路設定方式
前述されているように、ホストベースドメイン指向ＨＡＷＡＩＩ方法は、モバイルユーザ宛のパケット伝達管理目的で、ドメインルータを設定し、実現し、更新する三つの基本的なタイプの経路設定メッセージを利用する。第一のタイプは起動経路設定メッセージであり、モバイルデバイスによって、その起動の際に、そのドメイン内のルータパケット伝達経路をまず設定する目的で開始及び送出されるものである。起動経路設定メッセージは、この機能を、モバイルデバイスが最初に起動された時点で、（モバイルデバイスが接続されている基地局を含む）種々のルータ内にルーティングテーブルエントリを設定することによって実行する。ルートルータからモバイルデバイス宛にパケットをルーティングするために用いられるルータのみがこの起動されたモバイルデバイス宛のルーティングテーブルエントリを必要とし、それゆえ、これらのルータのみが起動経路設定メッセージの転送に関して選択される。
【００３６】
第二のタイプの経路設定メッセージは、モバイルデバイスが、接続されているドメイン内に含まれる他の基地局に対してハンドオフされる際に、開始して送出する。このハンドオフ経路設定メッセージは、モバイルデバイスによるある基地局から別の基地局へのハンドオフを反映し、かつ、そのようなハンドオフが発生した際のシームレスなパケット伝達を保証する目的で、ドメイン内の選択されたルータに係るルーティングテーブルを更新するために使用される。ハンドオフの結果として更新されたルーティングテーブルエントリを必要とするルーティングテーブルを有するドメインルータのみが、このハンドオフ経路設定メッセージを受信するように選択される。ハンドオフ及び起動経路設定メッセージは、更新メッセージに分類される。
【００３７】
第三のタイプの経路設定メッセージ、すなわちリフレッシュメッセージ、は、ソフトステートルーティングテーブルエントリをリフレッシュする目的で、（モバイルデバイスが接続されている）基地局によって開始されてルートルータ及び中間ルータ宛に送出される。このメッセージは、個々のモバイルデバイスに関して個別に送出されるか、あるいは伝達側基地局を介して接続されている複数個のモバイルデバイス宛のリフレッシュ経路設定メッセージがまとまって送出される。リフレッシュ経路設定メッセージは、ルートルータから当該メッセージを開始した基地局宛のパケット伝達に用いられる、ドメイン内の選択されたルータに係るルーティングテーブルを更新する目的で用いられる。
【００３８】
リフレッシュ経路設定メッセージは、ルータにおける“ソフトステート”を利用する本発明に係る実施例と共に用いられる。ソフトステートルータは、所定の時間期間内にリフレッシュ経路設定メッセージを周期的に受信しなければならないルータであって、受信できないとホストベースルーティングリンクが切断されるものである。ソフトステート方式は、ＨＡＷＡＩＩにおいて特に有用である。なぜなら、モバイルデバイスのユーザの移動性がそれぞれのハンドオフに対応する新たなホストベースルーティングエントリを設定する経路設定メッセージによって実現されるからである。ホストベースルーティングエントリを周期的にリフレッシュすることによって、（モバイルデバイスのハンドオフによって必要とされるもの以外の）ドメインルーティングの変更への応答も実現される。ハンドオフによるものではないサブネット変更は、リンクの切断による故障、ノードの混雑、トラフィック制御などを含む（但し、これらに限定されている訳ではない）種々の事象によって開始させられる。それゆえ、リフレッシュ経路設定メッセージは、起動あるいはハンドオフに応答して開始される経路設定メッセージとは異なり、ドメイン内の基地局に接続された各々のモバイルデバイスに係るドメインルートルータ宛に基地局から伝達される。よって、ＨＡＷＡＩＩベースドメインにおいてソフトステートルータを用いている間の、ルータあるいはリンク故障によるパケットリルーティングが容易に実現される。さらに、モバイルデバイスに係るパケット経路における単一あるいは複数個の外部エージェントを除去することで、モバイルユーザ宛のデータ伝達の信頼性が向上する。
【００３９】
ルータのソフトステートルーティングテーブルに係る周期的なリフレッシュメッセージは、基地局に接続された個々のモバイルデバイスに対応するリフレッシュメッセージの集積を可能にする、すなわち、基地局は、その無線インターフェースを介して接続されているモバイルユーザの各々に対する情報要素を含む単一のリフレッシュ経路設定メッセージを送出することが可能である。さらに、後に記述されるように、リフレッシュ経路設定メッセージは、ドメイン内の選択された数個のルータに対してのみ送出されるので、ルータソフトステートの管理に係るオーバーヘッド量が低減される。
【００４０】
リフレッシュ経路設定メッセージはアクノレッジを必要としない。むしろ、リフレッシュ経路設定メッセージの損失が、連続した数個のリフレッシュ経路設定メッセージが受信されなかった場合にドメインルータに係るルーティングテーブルエントリが期限切れになることを許容することによって、黙許されている。更新経路設定メッセージ（起動及びハンドオフ）はアクノレッジを必要とし、当該メッセージあるいはアクノレッジが受信されない場合には再送信される。それゆえ、本発明に係る経路設定方式は堅固であり、経路設定メッセージの損失に対して寛容である。
【００４１】
図７−９は、本発明に係る経路設定メッセージの三つのタイプの構造を模式的に示した図である。経路設定メッセージは、六つのフィールドからなる情報要素３００を有している。図７は、リフレッシュ経路設定メッセージの情報要素フィールドを模式的に示した図である。図８は、起動経路設定メッセージの情報要素フィールドを模式的に示した図である。図９は、ハンドオフ経路設定メッセージの情報要素フィールドを模式的に示した図である。まず、情報要素３００に含まれる個々のフィールドの記述の前に、経路設定メッセージ全体に対する補足を行なう。第一に、前述されているように、リフレッシュ経路設定メッセージは、基地局からそれに対して接続されている各々のモバイルデバイス宛に送出されるか、あるいは別の実施例においては、その基地局に接続された複数個のモバイルデバイスに対する情報要素を含む単一のリフレッシュ経路設定メッセージが、基地局からまとめて伝達される。第二に、更新経路設定メッセージとは、経路設定メッセージのうちの残存する二つのタイプ、すなわち起動経路設定メッセージ及びハンドオフ経路設定メッセージを指し示す。第三に、更新経路設定メッセージは、基地局に接続された単一のモバイルデバイスに対応する単一の情報要素３００のみを含んでいる。第四に、各経路設定メッセージは、伝達されるメッセージの真正性を確認する目的で、認証ヘッダを含む場合がある。
【００４２】
経路設定メッセージの情報要素３００は、以下のフィールドを含む：（ｉ）メッセージタイプフィールド３１０、（ｉｉ）シーケンスナンバーフィールド３１２、（ｉｉｉ）モバイルデバイスＩＰアドレスフィールド３１４、（ｉｖ）ソースＩＰアドレスフィールド３１６、（ｖ）デスティネーションＩＰアドレスフィールド３１８、及び（ｖｉ）メトリックフィールド３２０。メッセージタイプフィールド３１０は、受信側ルータに、どのタイプの経路設定メッセージが受信されつつあるかを通知する目的で用いられる。シーケンスナンバーフィールド３１２は、モバイルデバイスがハンドオフされる場合に、旧基地局とルータとの間でのパケットのルーピングを防止する目的で使用される。モバイルデバイスＩＰアドレスフィールド３１４は、受信側ルータに、ドメイン内のモバイルデバイスに対して割り当てられた現在のＩＰアドレスを通知する目的で用いられる。ソースＩＰアドレスフィールド３１６及びデスティネーションＩＰアドレスフィールド３１８は、受信側ルータに、ドメインルートルータ及び基地局に関して割り当てられた特定のＩＰアドレスを提供するために用いられる（メッセージタイプに基づいて、含まれる特定の情報は変化する）。メトリックフィールド３２０は、情報要素を処理する基地局あるいはルータからモバイルデバイスまでのホップの数を識別する。それゆえ、メトリックフィールド３２０は、モバイルデバイスから開始される経路設定メッセージに関しては０にセットされ、対応する基地局から開始されるリフレッシュ経路設定メッセージに関しては１にセットされる。情報要素を処理する各基地局あるいはルータは、順次このメトリックフィールド３２０をインクリメントする（後に記述されるように、ある種の経路設定メッセージは、このメトリックフィールド３２０をインクリメントするのではなくデクリメントする）。
【００４３】
図７には、リフレッシュ経路設定メッセージに係る情報要素フィールドが模式的に示されている。メッセージタイプフィールド３１０は、この経路設定メッセージがリフレッシュ経路設定メッセージであることを示している。シーケンスナンバーフィールド３１２の機能及びその使用法に関しては、後により詳細に記述される。ここでは、リフレッシュ経路設定メッセージに含まれるシーケンスナンバーフィールド３１２は、リフレッシュ経路設定メッセージを開始した基地局にストアされている現在のシーケンスナンバーフィールド値（１より小さくはない）にセットされることに留意されたい。モバイルデバイスＩＰアドレスフィールド３１４は、リフレッシュ経路設定メッセージを開始した基地局に接続されているモバイルデバイスに対して割り当てられたＩＰアドレスにセットされる。ソースＩＰアドレスフィールド３１６は、当該リフレッシュ経路設定メッセージを開始した基地局のＩＰアドレスにセットされる。デスティネーションＩＰアドレスフィールド３１８は、ドメインルートルータのＩＰアドレスにセットされる。メトリックフィールド３２０は、当該リフレッシュ経路設定メッセージを開始した基地局によって１にセットされ、その後に当該メッセージを受信するルータによって順次インクリメントされる。
【００４４】
図８には、起動経路設定メッセージに係る情報要素フィールドが模式的に示されている。メッセージタイプフィールド３１０は、この経路設定メッセージが更新メッセージであることを示している。シーケンスナンバーフィールド３１２の機能及びその使用法に関しては、後により詳細に記述される。ここでは、起動経路設定メッセージ内に含まれるシーケンスナンバーフィールド３１２が０にセットされることに留意されたい。モバイルデバイスＩＰアドレスフィールド３１４は、モバイルデバイスのＩＰアドレスにセットされる。ソースＩＰアドレスフィールド３１６は、当該モバイルデバイスにサービスを提供している現在の基地局のＩＰアドレスにセットされる。デスティネーションＩＰアドレスフィールド３１８は、ドメインルートルータのＩＰアドレスにセットされる。メトリックフィールド３２０は、当該起動経路設定メッセージを開始したモバイルデバイスによって０にセットされ、当該メッセージを受信する各ルータによって順次インクリメントされる。
【００４５】
図９には、ハンドオフ経路設定メッセージに係る情報要素フィールドが模式的に示されている。メッセージタイプフィールド３１０は、この経路設定メッセージが更新メッセージであることを示している。シーケンスナンバーフィールド３１２の機能及びその使用法に関しては、後により詳細に記述される。ここでは、ハンドオフ経路設定メッセージ内に含まれるシーケンスナンバーフィールド３１２が、現在ストアされているシーケンスナンバーフィールド値より１だけ大きい値にセットされること（但し、２より小さくはない）に留意されたい。モバイルデバイスＩＰアドレスフィールド３１４は、モバイルデバイスのＩＰアドレスにセットされる。ソースＩＰアドレスフィールド３１６は、モバイルデバイスのハンドオフ先の新たな基地局のＩＰアドレスにセットされる。デスティネーションＩＰアドレスフィールド３１８は、モバイルデバイスのハンドオフ元の旧基地局のＩＰアドレスにセットされる。メトリックフィールド３２０は、当該ハンドオフ経路設定メッセージを開始したモバイルデバイスによって０にセットされ、当該メッセージを受信する各々のルータによって順次インクリメントされる。
【００４６】
起動経路設定メッセージ
図１０は、起動経路設定メッセージを処理するドメインルータによって用いられる方法を示す流れ図である。モバイルデバイスは、起動されると、近接する基地局との間でリンクを確立する。リンク確立期間内、あるいはその直後に、モバイルデバイスは、ドメインルートルータ、接続されている基地局、及び基地局とルートルータとの間のパケット伝達に用いられる各中間ドメインルータ宛に伝達される経路設定メッセージを開始する。ここで記述される方法は、本発明の実施例に従ってＨＡＷＡＩＩをインプリメントしているホストベースドメイン内の各々のルータ（前述されているように、これらにはドメイン基地局も含まれる。なぜなら、基地局は、サブネット内の有線部分とのインターフェースとして機能するルータ機能を維持しているかあるいはそれらへアクセス可能であるからである。）に対して適用可能である。本明細書において記述されているメッセージ処理手続きは、前述されているように、現在のルータにおいて利用可能な処理及びメモリ機能を用いて実行される。ステップ３４０では、ドメインルータが起動経路設定メッセージを受信する。ルータはメトリックフィールドをインクリメントする（ステップ３４２）。ステップ３４４では、ルータは現在の経路設定メッセージが受信されたルータインターフェースを識別し、変数Ｉｎｔｆ１をそのインターフェースにセットする。ステップ３４６では、モバイルデバイスのＩＰアドレスをＩｎｔｆ１（ステップ３４４で識別されたルータインターフェース）にマッピングするルーティングテーブルエントリが入力される。ステップ３４８では、ルータは、ルータアドレスが現在の経路設定メッセージのデスティネーションＩＰアドレスフィールドに入力されているアドレスと一致するか否かをチェックする。一致する場合には、そのルータはドメインルートルータであり、経路設定メッセージに係るアクノレッジが設定されたルータ／インターフェース経路を介してモバイルデバイス宛に返送される（ステップ３５２）。一致しない場合には、ルータは、その経路設定メッセージのデスティネーションＩＰアドレス（すなわちドメインルートルータ）に達する目的でその経路設定メッセージを転送すべき次のホップのルータを識別する（ステップ３５０）。その後、当該ルータは、他のモバイルデバイスから開始された起動経路設定メッセージを待機する（ステップ３５４）。新たな起動経路設定メッセージが受信されると、ルータはメッセージ処理手続きをステップ３４０から再度開始する。
【００４７】
図１１は、ＨＡＷＡＩＩホストベースアーキテクチャを用いるドメイン例における起動経路設定メッセージの処理シーケンスを模式的に示した図である。ここで、“Ｉｎｔｆ”の使用は、あるノードがそれを介して他のノードに接続されているインターフェースあるいはポートを意味していることに留意されたい。ドメインルートルータ３６０は、ドメインルートルータＩｎｔｆＡを介してインターネット３６２へアクセスする。ドメインルートルータ３６０のＩｎｔｆＢは、ルータＲ７のＩｎｔｆＡに接続されている。ドメインルートルータ３６０のＩｎｔｆＣは、ルータＲ８のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＢは、基地局ＢＳ９のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＣは、基地局ＢＳ１０のＩｎｔｆＡに接続されている。ルータＲ８のＩｎｔｆＢは、基地局ＢＳ１１のＩｎｔｆＡに接続されている。ルータＲ８のＩｎｔｆＣは、基地局ＢＳ１２のＩｎｔｆＡに接続されている。
【００４８】
起動に際して基地局ＢＳ９のＩｎｔｆＢとの間でリンクを設定しようとしているモバイルデバイス１１４が示されている。起動の開始に際して、モバイルデバイスには、まず、動的ホスト配置プロトコル（ＤＨＣＰ）サーバ（図示せず）を介してＩＰアドレスが割り当てられる。ＤＨＣＰサーバがルートルータと同一地点に存在していると仮定すると、基地局ＢＳ９はＤＨＣＰサーバリレーとして機能し、ＤＨＣＰサーバとモバイルデバイスとの間でのメッセージ転送を行なう。認証が成功すると、ＤＨＣＰサーバはドメイン内で用いられるＩＰアドレスをモバイルデバイス宛に割り当て、さらに、基地局ＢＳ９とドメインルートルータ３６０のＩＰアドレスをモバイルデバイス宛に伝達する。モバイルデバイスは、その情報要素フィールドが図８に関連して記述されているように設定された起動経路設定メッセージを生成する。モバイルデバイス１１４は、その起動経路設定メッセージを、基地局ＢＳ９のＩｎｔｆＢへの第一ホップ３６４を介して送出する。
【００４９】
起動経路設定メッセージを受信すると、基地局ＢＳ９は情報要素のメトリックフィールドをインクリメントし、それ自体のルーティングテーブルにモバイルデバイス１１４宛のルーティングエントリを追加する。モバイルデバイス宛のエントリは、モバイルデバイスのＩＰアドレスとＢＳ９によって受信されたモバイルデバイス宛のパケットがルーティングされるべき関連するインターフェースという二つのフィールドよりなる。関連するインターフェースは、その起動経路設定メッセージが受信されたものと同一のインターフェース（この例では、ＢＳ９のＩｎｔｆＢという無線インターフェース）にセットされる。次に、ＢＳ９は、デスティネーションＩＰアドレスフィールドに示されたＩＰアドレスへの転送を完遂する目的で、その起動経路設定メッセージを転送すべきゲートウェイを決定するためのルーティングテーブル検索を実行する。起動経路設定メッセージにおいては、デスティネーションＩＰアドレスフィールドはドメインルートルータのＩＰアドレスにセットされている。この実施例の場合には、ＢＳ９は、適切なゲートウェイがルータＲ７であることを決定する。それゆえ、ＢＳ９はこの起動経路設定メッセージを、ＢＳ９のＩｎｔｆＡからＲ７のＩｎｔｆＢへという第二のホップ３６６へルーティングする。
【００５０】
起動経路設定メッセージを受信すると、ルータＲ７は情報要素メトリックフィールドをインクリメントし、基地局ＢＳ９と同一の様式で、モバイルデバイス１１４宛のルーティングエントリを自らのルーティングテーブルに追加する。それゆえ、ルータＲ７は、モバイルデバイスのＩＰアドレスを、起動経路設定メッセージが受信されたインターフェース（Ｒ７ ＩｎｔｆＢ）と関連づける。その後、ルータＲ７は、その起動経路設定メッセージをドメインルートルータ３６０宛に第三ホップ３６８へ、すなわちＲ７ ＩｎｔｆＡからドメインルートルータ３６０のＩｎｔｆへと転送する。起動経路設定メッセージを受信すると、ドメインルートルータ３６０は情報要素メトリックフィールドをインクリメントし、そのルーティングテーブルに前述されたものと同様にモバイルデバイス１１４宛のルーティングエントリを追加する。それゆえ、ドメインルートルータ３６０は、モバイルデバイスのＩＰアドレスを起動経路設定メッセージが受信されたインターフェース（ＩｎｔｆＢ）と関連づける。その後、ドメインルートルータ３６０は、起動経路設定メッセージによって設定されたルーティングテーブルエントリを用いて、モバイルデバイスのＩＰアドレスを経路中の各々のルータに関連づける目的で、アクノレッジ３７０をモバイルデバイス１１４宛に返送する。その後、モバイルデバイス１１４宛にインターネットを介して伝達されるパケットは、モバイルデバイスのＩＰアドレスのサブネット部分に基づいて、ドメインルートルータ３６０宛にルーティングされる。モバイルデバイスのＩＰアドレスを有してドメインルートルータ３６０に到達するパケットは、生成されたホストベースルーティングエントリを用いてモバイルデバイス１１４宛にルーティングされる。ドメイン内の、当該起動経路設定メッセージを受信していないルータ、すなわちＢＳ１１、ＢＳ１２及びＲ８は、モバイルデバイスのＩＰアドレスに対応するルーティングエントリを維持していない。それゆえ、これらのルータは、ルーティングテーブル内に対応するエントリが無いデスティネーションアドレスを有するパケットに関しては、ドメインルートルータ３６０宛のデフォールトのルーティング経路を用いる。よって、モバイルデバイス１１４に対応するデスティネーションアドレスを有するパケットが基地局ＢＳ１１において受信された場合には、それらはデフォールトでドメインルートルータ３６０宛にルーティングされる。ドメインルートルータ３６０において受信されると、モバイルデバイスのＩＰアドレスは認識され、モバイルデバイス１１４宛にパケットを転送するために用いられるエントリはドメインルートルータ３６０のルーティングテーブル内で利用可能である。
【００５１】
リフレッシュ経路設定メッセージ
図１２は、本発明に従って、ドメインルートルータがリフレッシュ経路設定メッセージを処理するために利用する方法例を示した流れ図である。前述されているように、リフレッシュ経路設定メッセージは、（各モバイルデバイスが接続された）基地局によって開始され、ソフトステートルーティングテーブルエントリをリフレッシュする目的で、ルートルータ及び中間のルータ宛に送出される。メッセージは、各々のモバイルデバイスに関して個別に送出されるか、あるいは、その基地局に対して接続された複数個のモバイルデバイスに関するリフレッシュ経路設定メッセージがまとめて送出される。ここで例示・記述される方法は、本発明の実施例に従ってＨＡＷＡＩＩをインプリメントしているホストベースドメイン内の各々のルータ（これらには、前述されているように、ドメイン内の基地局も含まれる。なぜなら、基地局は、サブネットの有線部分へのインターフェースとして働くルータ機能を維持あるいはそれへのアクセスが可能であるからである。）に対して適用可能である。ここで記述されるメッセージ処理手続きは、前述されているように、現在のルータにおいて利用可能な処理及びメモリ機能を用いて実行される。ステップ３８０では、ドメイン内のルータがリフレッシュ経路設定メッセージを受信する。当該ルータはメトリックフィールドをインクリメントする（ステップ３８２）。ステップ３８４では、当該ルータはリフレッシュ経路設定メッセージが受信されたルータインターフェースを識別し、それを変数Ｉｎｔｆ１にセットする。ステップ３８８では、モバイルデバイスのＩＰアドレスに係るエントリがルーティングテーブル内に存在するか否かをチェックする。存在しない場合には、ステップ３９０でルーティングテーブルエントリが入力され、当該エントリはモバイルデバイスのＩＰアドレスをＩｎｔｆ１（ステップ３８４で識別されたルータインターフェース）にマッピングする。モバイルデバイスのＩＰアドレスに係るルーティングテーブルエントリが存在する場合には、リフレッシュ経路設定メッセージ内のシーケンスナンバーが既存のルータシーケンスナンバーエントリと比較される（ステップ３９２）。リフレッシュ経路設定メッセージ内のシーケンスナンバーが既存のルータシーケンスナンバーエントリよりも大きい場合には、リフレッシュ経路設定メッセージがルータにおいて現時点で利用可能なものよりもより新しい情報要素フィールドを含んでいることを意味しており、ステップ３９４において、ルータにおいてストアされていた情報要素フィールドがリフレッシュ経路設定メッセージ内で送信されてきたより新しい値を反映するように更新（リフレッシュ）される。
【００５２】
ステップ３９６においては、ルータは、ルータのアドレスがリフレッシュ経路設定メッセージ内のデスティネーションＩＰアドレスフィールド内のアドレスと一致するか否かをチェックする。一致しない場合には、ルータは、リフレッシュ経路設定メッセージ内のデスティネーションＩＰアドレスに到達する目的で、当該リフレッシュ経路設定メッセージを転送すべき次のホップのルータを識別する（ステップ３９８）。しかしながら、一致する場合には、そのルータはドメインルートルータであってそのリフレッシュ経路設定メッセージをさらに転送する必要はない。さらに、ドメインルートルータによる受信に対するアクノレッジも不要である。よって、ステップ４００では、ルータは、それ自体のルーティングテーブルエントリを更新することになる新たなリフレッシュ経路設定メッセージを待機する。このようなリフレッシュ経路設定メッセージは、同一の基地局か、あるいは当該ルータをサービスを提供しているモバイルデバイス宛にパケットを転送する際に利用するドメイン内の他の基地局からかのいずれかから発せられる。新たなリフレッシュ経路設定メッセージを受信すると、この手続きはステップ３８０から再度開始される。
【００５３】
以下、本発明に係るホストベースドメインＨＡＷＡＩＩアーキテクチャにおいて用いられる三つの経路設定ハンドオフ方式が記述される。すなわち、新−旧経路設定方式、旧−新経路設定方式、及び新−旧−新経路設定方式である。起動及びリフレッシュ経路設定メッセージが、以下に記述される三つのハンドオフ方式の各々と関連して用いられる。三つの経路設定ハンドオフ方式は、ハンドオフ経路設定メッセージがどのように調整され、管理され、転送されるかという点で異なっている。本明細書において記述される三つの経路設定ハンドオフ方式は、既存のトポロジーに関する知識を何ら仮定しない。すなわち、経路設定メッセージは、ルーティング情報プロトコル（ＲＩＰ）あるいはオープン最短経路優先（ＯＳＰＦ）等の従来技術に係るルーティングプロトコルによって生成されたルーティングエントリを用いて、他のあらゆる付加情報を用いることなく、ドメイン内でルーティングされる。しかしながら、ドメインノード、リンク及びルータ混雑及び／あるいはＱｏＳ保証責任に対応するプロトコル内で本明細書に記載されている経路設定方式を適応することが可能であることは当業者には明らかである。
【００５４】
以下の、図１３から図１９を参照した記述は、本発明に係るホストベースドメインＨＡＷＡＩＩアーキテクチャにおいて用いられる前述された三つの経路設定ハンドオフ方式に係る詳細を列挙したものである。それらは、新−旧経路設定方式、旧−新経路設定方式、及び新−旧−新経路設定方式である。それぞれの名前が示しているように、それらは、モバイルデバイスの旧基地局から新基地局へのハンドオフ事象をドメインホストルータに通知して更新する、三つの相異なったメッセージ伝達手段を表している。これら三つの方式全ては、ドメインルータのルーティングテーブルにおける変更を実現するために必要とされるメッセージング及びシグナリングを、モバイルデバイスがドメイン内でその接続点を新たな基地局に変更することによってパケット伝達に用いられるインターフェースが変更された、選択されたルータのみを更新することによって限定している。それぞれの（すなわち、新−旧、旧−新、あるいは新−旧−新）経路設定方式を用いて基地局が通知される順序は、個々の基地局及びルータが論理レベルで経路設定メッセージを処理する順序を表している。経路設定メッセージが伝達される物理的な経路は、論理レベルにおいて記述されるものと異なる可能性がある。
【００５５】
以下、“クロスオーバールータ”という術語は、経路設定ハンドオフ方式を記述するために用いられる。再度図２を参照して、クロスオーバールータという術語が定義される。ドメインルートルータ１５０、ルータＲ４及びＲ５、及び基地局ＢＳ５、ＢＳ６、及びＢＳ７を含むドメイン１よりなる要素を考える。モバイルデバイス１１４が起動して、基地局ＢＳ５に接続されると仮定する。モバイルデバイス１１４はＩＰアドレスを獲得し（すなわち、ＩＰアドレスが固定的に割り当てられ）、ドメインルートルータ１５０宛の起動経路設定メッセージを開始する。ドメインルートルータ１５０は、ドメインルートルータ及び各中間ルータにおいて、そのＩＰアドレスをルータインターフェースと等値することによってルーティングテーブルエントリを追加する。それゆえ、モバイルデバイスのＩＰアドレスを有し、ドメインルートルータ１５０によって受信されるパケットは、適切なインターフェースを介してルータＲ４にルーティングされる。ルータＲ４は、パケットを受信すると、当該パケットを適切なインターフェースを介して基地局ＢＳ５にルーティングする。基地局ＢＳ５は、当該パケットをモバイルデバイス宛に送信する。ここで、モバイルデバイス１１４がその接続点をドメイン１内で基地局ＢＳ６に変更し、モバイルデバイス１１４宛のパケットが、ドメインルートルータ１５０、（新たなインターフェースを介してであるが）ルータＲ４、及び基地局ＢＳ６を介してモバイルデバイス１１４宛にルーティングされると仮定する。基地局ＢＳ５及びＢＳ６及びルータＲ４にストアされているモバイルデバイスのＩＰアドレスに係るルーティングテーブルエントリは更新が必要であるが、ドメインルートルータ１５０内のルーティングテーブルエントリに関しては何ら更新は必要ではない。これは、ドメインルートルータが、モバイルデバイス１１４宛のパケットの最終的な伝達が基地局ＢＳ５あるいはＢＳ６のいずれかを介してなされるかにかかわらず、モバイルデバイス１１４のＩＰアドレスを有するパケットを同一のインターフェースを介してルータＲ４に転送するからである。この場合のクロスオーバールータはＲ４である。なぜなら、モバイルデバイスがその接続点を基地局ＢＳ５から基地局ＢＳ６へ変更した場合に当該モバイルデバイス宛にパケットを転送するために用いるインターフェースを変更しなければならない、パケット伝達方式における最初のドメインルータであるからである。
【００５６】
以下に記述される三つの経路設定ハンドオフ方式の各々において、第一ドメイン基地局から第二ドメイン基地局へのハンドオフの間、ハンドオフの完了前及びドメインルータへに係るルーティングテーブルエントリの更新前に旧基地局によって受信されたパケットが、モバイルデバイス宛の伝送のために新たな基地局へ伝達されるように、既存のルーティングテーブルにルーティングエントリが追加される。このようにしてルーティングエントリを更新することにより、パケット損失につながるループ形成の可能性を防止する。さらに、三つの経路設定ハンドオフ方式は、全て、図９において示されて既に記述された情報要素構造を利用する（但し、後に記述されるように、旧−新経路設定方式が用いられる場合に、ソース及びデスティネーションＩＰアドレスフィールドが相互に交換されて用いられる、という例外を除く）。しかしながら、それぞれの方式は、ドメインルータが情報要素フィールド値をどのように解釈してどのようにそれに応答するか、という点で異なっている。
【００５７】
新−旧経路設定
図１３は、ドメインルータによって新−旧ハンドオフ経路設定メッセージの処理に用いられる方法例を示す流れ図である。前述されているように、ハンドオフ経路設定メッセージは、モバイルデバイスによって開始され、新たな基地局から旧基地局及び選択された中間ルータさらにクロスオーバールータを含んで送出される。このメッセージを受信する基地局あるいはルータは、発信側モバイルデバイスＩＰアドレスに対応するルーティングテーブル内のエントリを、ハンドオフ経路設定メッセージが到達したルータあるいは基地局のインターフェースへのポイントに更新する。詳細に述べれば、ハンドオフ経路設定メッセージを受信するドメインルータは、（ｉ）新基地局とクロスオーバールータとの間のハンドオフ後のパケット伝達経路に相当する各ルータ（新基地局及びクロスオーバールータを含む）及び（ｉｉ）クロスオーバールータと旧基地局との間のハンドオフの前のパケット伝達経路に相当する各ルータ（旧基地局を含む）が含まれる。本明細書において例示・記述されている方法は、本発明の実施例に従ってＨＡＷＡＩＩをインプリメントしているホストベースドメイン内の各々のルータ（これらには、前述されているように、ドメイン内の基地局も含まれる。なぜなら、基地局は、サブネットの有線部分へのインターフェースとして働くルータ機能を維持あるいはそれへのアクセスが可能であるからである。）に対して適用可能である。ここで記述されるメッセージ処理手続きは、前述されているように、現在のルータにおいて利用可能な処理及びメモリ機能を用いて実行される。ステップ４１０では、ドメインルータが、まず、ハンドオフ経路設定メッセージを受信する。ルータは、メトリックフィールドをインクリメントする（ステップ４１２）。ステップ４１４においては、ルータは経路設定メッセージが受信されたルータインターフェースを識別し、変数Ｉｎｔｆ１をそのインターフェースに設定する。ステップ４１８では、ルータはモバイルデバイスのＩＰアドレスに対する既存のエントリがルーティングテーブル内に存在するか否かをチェックする。存在しない場合には、ステップ４２０においてルーティングテーブルエントリが入力され、これはモバイルデバイスのＩＰアドレスをＩｎｔｆ１（ステップ４１４で識別されたルータインターフェース）にマッピングする。モバイルデバイスのＩＰアドレスに対する既存のエントリが存在する場合には、ステップ４２２において、ハンドオフ経路設定メッセージのシーケンスナンバーが既存のルータシーケンスナンバーエントリと比較される。ハンドオフ経路設定メッセージ中のシーケンスナンバーが既存のルータシーケンスナンバーエントリより大きい場合には、ハンドオフ経路設定メッセージがルータにストアされているものよりもより新しい情報要素を含むことを意味しており、ステップ４２４において、当該モバイルデバイスに係るルーティングテーブルエントリが更新される。
【００５８】
ステップ４２６においては、ルータは、ハンドオフ経路設定メッセージのデスティネーションアドレスフィールド中のアドレスがルータのアドレスに一致するか否かをチェックする。一致しない場合には、ルータは、当該ハンドオフ経路設定メッセージのデスティネーションＩＰアドレス（すなわち、旧基地局）に到達させる目的で、当該ハンドオフ経路設定メッセージを転送すべき次のホップのルータを識別する（ステップ４２８）。一致する場合には、当該ルータは旧基地局であって、当該ハンドオフ経路設定メッセージをさらに転送する必要はない。ステップ４３０では、ハンドオフ経路設定メッセージの受信に係るアクノレッジが新基地局宛に送出される。当該ハンドオフ経路設定メッセージを受信したルータが旧基地局であるか否かにかかわらず、当該ルータは次のハンドオフ経路設定メッセージを待機する（ステップ４３２）。新たな経路設定メッセージを受信すると、当該処理はステップ４１０から再度開始される。
【００５９】
図１４は、本発明に従ったＨＡＷＡＩＩホストベースアーキテクチャを用いるドメイン例における新−旧経路設定方式処理シーケンスを示している。“Ｉｎｔｆ”が、あるノードが次のノードに接続される際に用いられるインターフェースあるいはポートを意味していることに留意されたい。ドメインルートルータ３６０は、ドメインルートルータＩｎｔｆＡを介してインターネット３６２にアクセスする。ドメインルートルータ３６０のＩｎｔｆＢは、ルータＲ７のＩｎｔｆＡに接続されている。ドメインルートルータ３６０のＩｎｔｆＣは、ルータＲ８のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＢは、基地局ＢＳ９のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＣは、基地局ＢＳ１０のＩｎｔｆＡに接続されている。るーたＲ８のＩｎｔｆＢは、基地局ＢＳ１１のＩｎｔｆＡに接続されている。ルータＲ８のＩｎｔｆＣは、基地局ＢＳ１２のＩｎｔｆＡに接続されている。
【００６０】
モバイルデバイス１１４は、旧基地局ＢＳ９から新基地局ＢＳ１０へハンドオフする途中として示されている。モバイルデバイス１１４はハンドオフ経路設定メッセージを生成し、その情報要素フィールドは図９に関連して＾記述されているようにセットされている。その後、モバイルデバイス１１４は、ハンドオフ経路設定メッセージを第一ホップ４５０を介して基地局ＢＳ１０のＩｎｔｆＢ宛に送出する。
【００６１】
ハンドオフ経路設定メッセージを受信すると、基地局ＢＳ１０は情報要素メトリックフィールドをインクリメントし、そのルーティングテーブルにモバイルデバイス１１４宛のルーティングエントリを追加する。モバイルデバイス宛のエントリは二つのフィールド、すなわち、モバイルデバイスのＩＰアドレスとＢＳ１０がモバイルデバイス１１４宛に受信したパケットがルーティングされるべき関連するインターフェース、より構成されている。関連するインターフェースは、ハンドオフ経路設定メッセージげ受信されたインターフェースと同一のもの（この場合は、ＢＳ１０の無線インターフェースであるＩｎｔｆＢ）にセットされる。次に、ＢＳ１０は、デスティネーションＩＰアドレスフィールドへの伝達を完遂する目的で、当該ハンドオフ経路設定メッセージを転送するべきルータを決定するために、旧基地局のＩＰアドレス（ＢＳ９のＩｎｔｆＡのアドレス）に関するルーティングテーブル検索を実行する。この実施例では、ＢＳ１０は、ハンドオフ経路設定メッセージを転送すべき適切なルータがＲ７であることを決定する。このルータＲ７はクロスオーバールータである。それゆえ、ＢＳ１０はハンドオフ経路設定メッセージを、第二ホップ４５２でＢＳ１０のＩｎｔｆＡからＲ７のＩｎｔｆＣ宛にルーティングする。
【００６２】
ハンドオフ経路設定メッセージを受信すると、ルータＲ７は情報要素メトリックフィールドをインクリメントし、基地局ＢＳ１０と同様の方式で、ルーティングテーブル内のモバイルデバイス１１４に係るルーティングエントリを更新する。それゆえ、ルータＲ７は、モバイルデバイスのＩＰアドレスをハンドオフ経路設定メッセージを受信したインターフェース（Ｒ７のＩｎｔｆＣ）と関連づける。その後、ルータＲ７は、ハンドオフ経路設定メッセージを、第三ホップ４５４でＲ７のＩｎｔｆＢからＢＳ９のＩｎｔｆＡへと基地局ＢＳ９（旧基地局）宛に転送する。ハンドオフ経路設定メッセージを受信すると、基地局ＢＳ９は情報要素メトリックフィールドをインクリメントし、前述されているように、ルーティングテーブルのモバイルデバイス１１４に係るルーティングエントリを更新する。それゆえ、基地局ＢＳ９は、モバイルデバイスのＩＰアドレスをハンドオフ経路設定メッセージを受信したインターフェース（ＩｎｔｆＡ）と関連づける。よって、その後に基地局ＢＳ９にて処理される、デスティネーションアドレスフィールドにモバイルデバイスのＩＰアドレスを有するパケットは、モバイルデバイス１１４宛に伝送される目的で、基地局ＢＳ１０へとリダイレクトされる。その後、基地局ＢＳ９は、モバイルデバイスのＩＰアドレスを経路内の各ルータにおけるインターフェースと関連づける目的で、ハンドオフ経路設定メッセージによって設定されたルーティングテーブルエントリを用いて、アクノレッジ４５６をモバイルデバイス１１４宛に返送する。その後、インターネット３６２を介してモバイルデバイス１１４への伝達目的で伝送されてきたパケットは、モバイルデバイスのＩＰアドレスのサブネット部分に基づいてドメインルートルータ３６０にルーティングされ、ドメインルートルータ３６０はそのパケットをルータＲ７のＩｎｔｆＡへと転送する（なぜなら、ドメインルートルータにおけるモバイルデバイスのＩＰアドレスは、ハンドオフ経路設定メッセージによって変更されていないからである。）。その後、ルータＲ７は、モバイルデバイスのＩＰアドレスを有するパケットを、ルータＲ７のＩｎｔｆＣから、モバイルデバイスのＩＰアドレスに係る更新されたルーティングテーブルエントリによって指示されるように、基地局ＢＳ１０のＩｎｔｆＡへとルーティングする。基地局ＢＳ１０は、モバイルデバイスのＩＰアドレスを有するパケットを、基地局ＢＳ１０のＩｎｔｆＢ（ＢＳ１０の無線インターフェース）を介してモバイルデバイス１１４宛にルーティングする。以上より明らかなように、新及び旧基地局及びそれらを接続するルータのみが新−旧ハンドオフ経路設定メッセージの処理に関与していることに留意されたい。ドメイン内の他のルータは、ドメインルートルータ３６０を指し示すデフォールトエントリを有するのみであり、不変に保たれる。
【００６３】
既に紹介されているように、経路設定メッセージの情報要素にシーケンスナンバーフィールドを含めることによって、モバイルデバイスがハンドオフする際の旧基地局とルータとの間のパケットルーピングが防止される。この節では新−旧経路設定方式に関連して記述されているが、シーケンスナンバーフィールドを用いることによって、本明細書で記述されているあらゆる経路設定メッセージあるいは方式におけるルーピングが防止される。本発明に係るホストベース基地局が、ドメインルートルータに対して周期的にリフレッシュ経路設定メッセージを送信することを思い出されたい。図１４を参照して、ハンドオフ経路設定メッセージが生成されてモバイルデバイスから送出され、当該ハンドオフ経路設定メッセージが第二ホップ４５２まで完遂し、及び、ルータＲ７が当該ハンドオフ経路設定メッセージの処理を完了したところである、と仮定する。さらに、周期的リフレッシュメッセージが基地局ＢＳ９から送出されたところであると仮定する。基地局ＢＳ９には、モバイルデバイス１１４の基地局１０へのハンドオフは未だに通知されていない。なぜなら、ハンドオフ経路設定メッセージを受信していないからである。リフレッシュ経路設定メッセージがルータＲ７において処理されるところである場合には、モバイルデバイス宛のルーティングテーブルエントリは、モバイルデバイスが、ＢＳ１０における現在の接続点ではなく、依然として基地局ＢＳ９に接続されていることを表すようにリフレッシュされることになる。ハンドオフ経路設定メッセージは、第三ホップ４５４の後に基地局ＢＳ９に伝達され、ＢＳ９のルーティングテーブルが、モバイルデバイス１１４宛のパケットをルータＲ７にリダイレクトするように更新される。このシナリオにより、モバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有するパケットが、次のリフレッシュ経路設定メッセージが開始されるまでの間、基地局ＢＳ９とルータＲ７との間でループされることになる。
【００６４】
しかしながら、経路設定メッセージにシーケンスナンバーフィールドを含ませることによって、パケットルーピングは回避される。モバイルデバイスが起動する際、シーケンスナンバーフィールドは０にセットされ、モバイルデバイスが起動した直後であって隣接する基地局へハンドオフされていないことを表している。モバイルデバイスがハンドオフされるたびに、モバイルデバイスは情報要素と共に送出されるシーケンスナンバーをインクリメントする。それゆえ、リフレッシュ経路設定メッセージを開始する基地局は、ハンドオフ前の値（すなわち、その基地局に依然として接続されている間のシーケンスナンバーフィールド値に対応する値）にセットされたシーケンスナンバーフィールドを有する情報要素を送出する。新基地局へハンドオフされたモバイルデバイスは、１だけインクリメントされたシーケンスナンバーフィールド値を有するハンドオフ経路設定メッセージを開始する。それゆえ、基地局ＢＳ９から送出されたルータＲ７に到達するリフレッシュ経路設定メッセージは、モバイルデバイス１１４によって開始されたハンドオフ経路設定メッセージのシーケンスナンバーフィールド値よりも小さいシーケンスナンバーフィールド値を有することになる。ルータＲ７は、リフレッシュ経路設定メッセージがちょうど受信したハンドオフ経路設定メッセージと同じ程度に新しくはない、ということを認識し、当該モバイルデバイスに対応するルーティングテーブルエントリを変更せずにリフレッシュ経路設定メッセージを転送する。よって、パケットルーピング、及びそれがもたらす望ましくない結果、は回避される。
【００６５】
シーケンスナンバーフィールドは、起動経路設定メッセージが常に処理されることを保証する目的で、起動の際に０にセットされる。このようにすることで、モバイルデバイス１１４がそれ自体をリセットする場合（例えば、バッテリの故障の結果として）においてもパケット伝達が保証される。起動経路設定メッセージは、起動経路設定メッセージとしてのそのステータスを表示する目的で、０に等しいシーケンスナンバーフィールドを有するため、リフレッシュ経路設定メッセージは、最小１であるような値にセットされたシーケンスナンバーフィールド値を有する。さらに、モバイルデバイスによって生成されたハンドオフ経路設定メッセージに係るシーケンスナンバーフィールド値は、各ハンドオフごとに、巻き付けるように１ずつインクリメントされる。それゆえ、ハンドオフ経路設定メッセージは、２とそのフィールド値として取りうる最大シーケンス数との間の値を有するシーケンスナンバーフィールド値を有している。
【００６６】
新−旧経路設定方式の利用は、モバイルデバイスのハンドオフの前及びその間に無線デバイスがコンカレントに新基地局及び旧基地局の双方にチューニングするような、ＣＤＭＡあるいは広帯域ＣＤＭＡネットワークなどの応用例に関して特に適している。ＴＤＭＡネットワークと共に用いられる場合には、新−旧経路設定方式はパケットロスを生ずる可能性がある。なぜなら、モバイルデバイスと旧基地局との間の無線リンクが、旧基地局がモバイルデバイス宛のパケットを受信するのと同時に切断される可能性があるからである。ＣＤＭＡあるいは広帯域ＣＤＭＡネットワークと共に用いられる場合には、新−旧経路設定方式は、パケットが新基地局あるいは旧基地局のいずれかからモバイルデバイス宛に伝達されることを可能にする。
【００６７】
例えば、基地局ＢＳ９から基地局ＢＳ１０へのハンドオフが発生すると仮定する。ＴＤＭＡネットワークにおいては、ＢＳ１０がモバイルデバイスをピックアップする前に、ＢＳ９がモバイルデバイスとのリンクを切断する。このことは、ハードハンドオフとして知られている。このハンドオフに関しては、ハンドオフ経路設定メッセージが４５０、４５２、４５４、４５６の順序で流される。しかしながら、経路設定メッセージが、モバイルデバイス１１４との間の設定済みのリンクの切断前に、ＢＳ９を通じた物理的無線リンクを介して開始されると仮定する。よって、ＢＳ１０及びルータＲ７におけるルーティングテーブルエントリは更新され、モバイルデバイス１１４宛の今後のパケットは基地局ＢＳ１０へルーティングされる。それゆえ、経路設定メッセージの処理前にＲ７のインターフェースＩｎｔｆＢを介してＢＳ９宛にルーティングされたパケットは、落とされることになる。なぜなら、ＢＳ９との間のハードハンドオフがその間に発生するからである。このことは、ＣＤＭＡネットワークでは生じない。モバイルデバイスは、二つの基地局に同時にチューニングして双方からパケットを受信することが可能であるため、ＢＳ９及びＢＳ１０から送出されたパケットを受信する。
【００６８】
図１４は、クロスオーバールータＲ７が、旧基地局（ＢＳ９）と新基地局（ＢＳ１０）との間にサブネットドメインの有線部分を介して配置されている場合の新−旧通話設定方式処理シーケンスを示している。しかしながら、基地局ＢＳ９と基地局ＢＳ１０とが互いに中間ルータ無く直接有線接続されていたらどうなるであろうか？ 図１４に従ったハンドオフ経路設定メッセージの処理の後、モバイルデバイス１１４宛のパケットは、ドメインルートルータ３６０から、ルータＲ７及び旧基地局ＢＳ９を介してルーティングされ、旧基地局ＢＳ９から新基地局（ＢＳ１０）へと転送されてその後にモバイルデバイス宛に伝達される。ルーティング費用がホップ数に基づくものであると仮定すると、このようにパケットをルーティングすることは最適ルーティング経路ではない。なぜなら、ドメインルートルータ３６０からのモバイルデバイス宛のパケットは、クロスオーバールータＲ７から基地局ＢＳ１０へ直接ルーティングされるのではなく、クロスオーバールータＲ７を介してまず基地局ＢＳ９へルーティングされその後に基地局ＢＳ１０へルーティングされるからである。
【００６９】
図１５は、旧基地局が新基地局に対して、中間に配置された中継ルータを用いることなく直接有線接続されている場合の新−旧経路設定方式処理シーケンスの実施例を模式的に示した図である。それゆえ、前述されたドメイン相互接続に加えて、基地局ＢＳ９のＩｎｔｆＣが基地局ＢＳ１０のＩｎｔｆＣに接続されている。前述されているように、モバイルデバイス１１４は、旧基地局ＢＳ９から新基地局ＢＳ１０へとハンドオフするところである。モバイルデバイス１１４は、図９に関連して記述されたようにセットされた情報要素フィールドを有するハンドオフ経路設定メッセージを生成する。その後、モバイルデバイス１１４は、当該ハンドオフ経路設定メッセージを、第一ホップ４６０を介して基地局ＢＳ１０のＩｎｔｆＢへと送出する。基地局ＢＳ１０は、モバイルデバイス１１４に対応するルーティングテーブルエントリを追加あるいは更新し、メトリックフィールドをインクリメントして、当該ハンドオフ経路設定メッセージを第二ホップ４６２を介してＢＳ１０のＩｎｔｆＣからＢＳ９のＩｎｔｆＣ宛に転送する。基地局ＢＳ９は、モバイルデバイス１１４に対応するルーティングテーブルエントリを更新し、メトリックフィールドをインクリメントして、基地局ＢＳ９及びＢＳ１０内でハンドオフ経路設定メッセージによって設定されたルーティングテーブルエントリを用いて、モバイルデバイス１１４宛にアクノレッジ４６４を返送する。
【００７０】
最適ではないルーティング経路の問題は、新基地局ＢＳ１０が次のリフレッシュ経路設定メッセージを送出する際に修正される。リフレッシュ経路設定メッセージは、二つのホップでドメインルートルータ宛に送出される。第一ホップ４６６は、ルータＲ７のＩｎｔｆＣ宛のものであり、第二ホップ４６８はドメインルートルータ３６０宛のものである。ドメインルートルータには何ら必要とされるルーティング変更は無いが、ルータＲ７におけるモバイルデバイスに係るルーティングテーブルエントリをリフレッシュする目的でリフレッシュ経路設定メッセージが用いられる。リフレッシュ経路設定メッセージを処理した後、ルータＲ７はモバイルデバイスのＩＰアドレスを、リフレッシュ経路設定メッセージを受信したインターフェースであるＩｎｔｆＣと関連づける。その後、モバイルデバイス宛の全てのパケットはルータＲ７のＩｎｔｆＣを介して基地局ＢＳ１０のＩｎｔｆＡ宛にルーティングされ、ルーティング経路が最適化される。
【００７１】
図１５を参照して、基地局ＢＳ１０とルータＲ７との間のリンクでリンク故障が発生した場合のシナリオを考える。基地局ＢＳ１０から発せられる次のリフレッシュ経路設定メッセージは、基地局ＢＳ１０のＩｎｔｆＣから基地局ＢＳ９のＩｎｔｆＣ宛に、次いで基地局ＢＳ９のＩｎｔｆＡからルータＲ７のＩｎｔｆＢ宛に、さらに、ルータＲ７のＩｎｔｆＡからドメインルートルータ３６０宛にそれぞれ送出される。サブネットのルーティングプロトコルがリンク故障を検出し、自動的に代替ルートを基地局ＢＳ１０からドメインルートルータ３６０への次善のルートに係るゲートウェイとして選択するため、この新たなルーティング経路が用いられる。前述された場合と同様、リフレッシュ経路設定メッセージが、このメッセージを受信する各々のルータにおけるモバイルデバイスに係るルーティングテーブルエントリを更新し、モバイルデバイス１１４宛の新たなパケット伝達経路を設定する。
【００７２】
本発明に係る興味深い実施例は新−旧経路設定方式の変形であり、“旧−新”経路設定方式と呼称される。旧−新経路設定方式は新−旧経路設定方式と同様であるが、二つの主要な違いが存在する。第一に、ハンドオフ経路設定メッセージが、モバイルデバイスによって、新基地局宛ではなく旧基地局宛に送出される。その後、旧基地局は当該ハンドオフ経路設定メッセージを新基地局及び中間ルータを介してモバイルデバイス宛に返送し、モバイルデバイスに対応するルーティングテーブルエントリを各々のルータあるいは基地局において更新する。第二に、メトリックフィールドが、旧基地局において、新基地局に対応するルーティングテーブルエントリに係るメトリックフィールド値よりも１だけ大きい値に設定され、モバイルデバイスへ返送されるハンドオフ経路設定メッセージの各々のホップごとにデクリメントされる。
【００７３】
新−旧−新経路設定方式
図１６及び１７は、本発明に従って、新−旧−新ハンドオフ経路設定メッセージを処理するドメインルータによって用いられるプログラム例を示す流れ図である。前述されているように、ハンドオフ経路設定メッセージはモバイルデバイスによって開始されて送出され、新基地局におけるモバイルデバイスの新たな接続点を反映させる目的でドメインルータにおけるルーティングテーブルエントリを更新する。新−旧−新ハンドオフ経路設定メッセージは、まず、（図１６に示されているフェーズ１において）新基地局から旧基地局へと経路設定メッセージを転送し、（図１７に示されているフェーズ２において）旧基地局から新基地局へと経路設定メッセージを転送する。ここで例示・記述される方法は、本発明の実施例に従ってＨＡＷＡＩＩをインプリメントしているホストベースドメイン内の各々のルータ（これらには、前述されているように、ドメイン内の基地局も含まれる。なぜなら、基地局は、サブネットの有線部分へのインターフェースとして働くルータ機能を維持あるいはそれへのアクセスが可能であるからである。）に対して適用可能である。ここで記述されるメッセージ処理手続きは、前述されているように、現在のルータにおいて利用可能な処理及びメモリ機能を用いて実行される。
【００７４】
新−旧−新ハンドオフ経路設定方式は、前述された新−旧経路設定方式や旧−新経路設定方式よりも複雑である。新−旧−新ハンドオフ経路設定方式は、修正されたルーティングテーブル構造を利用する。標準的なルーティングテーブルエントリは、（前述されているように）ルーティング経路を決定するために二つのフィールドを利用し、あるＩＰアドレスを、そのＩＰアドレスをデスティネーションアドレスとして有するパケットが転送されるルータインターフェースに関連づける。ルーティングテーブル構造は、新−旧−新ハンドオフ経路設定方式をインプリメントする際には、三つのフィールドを含むように修正される。ＩＰパケットが転送されるルータインターフェースは、デスティネーションＩＰアドレスの他にパケットが受信されるルータインターフェースの関数として決定される。それゆえ、同一のデスティネーションＩＰアドレスを有するパケットを、どの着信ルータインターフェースを介してそのパケットが受信されたかに依存して、相異なったインターフェースを介してルーティングすることが可能である。従って、強化されたルーティングテーブルエントリは、（［着信Ｉｎｔｆ、ＩＰアドレス］→発信Ｉｎｔｆ）という形式を有している。しかしながら、ルータのインターフェースポートに係る転送テーブルの形式は同一のままであることも可能である。
【００７５】
図１６を参照して、ステップ４８０においては、ドメインルータが、まず、新−旧−新フェーズ１ハンドオフ経路設定メッセージを受信する。フェーズ１メッセージというステータスは、当該メッセージが、モバイルデバイスから旧基地局への経路（すなわち、メッセージ経路の新−旧脚）内のルータにおいて処理されつつあることを表している。ルータはメトリックフィールドをインクリメントする（ステップ４８２）。ステップ４８４においては、ルータがその経路設定メッセージを受信したルータインターフェースを識別し、変数Ｉｎｔｆ１をそのインターフェースに対応するようにセットする。ステップ４８６では、ルータは、その経路設定メッセージ内のデスティネーションアドレスとルータ自体のアドレスとが等しいか否かをチェックする。ルータアドレスがデスティネーションアドレスである場合には（そのルータが実際に旧基地局であることを表しており）、ステップ４８８が実行される。
【００７６】
ステップ４８８においては、フェーズ１ハンドオフ経路設定メッセージが旧基地局によって受信されると、（［＊、モバイルデバイスアドレス］→Ｉｎｔｆ１）という形態を有するルーティングテーブルエントリが生成される。この表記は、ルータ（この場合には旧基地局）に到達するパケットが、それがどの着信インターフェースを介して受信されたかにかかわらず、ステップ４８４において識別された発信インターフェース（Ｉｎｔｆ１）を介してルーティングされることを意味している。ステップ４９０では、Ｉｎｔｆ１に接続された次のホップのルータが識別され、フェーズ２経路設定メッセージのデスティネーションＩＰアドレスがモバイルデバイスのＩＰアドレスにセットされ、フェーズ２経路設定メッセージが出力される。その後、ルータは、次のフェーズ１経路設定メッセージを待機する（ステップ５０４）。
【００７７】
しかしながら、ステップ４８６において実行されたチェックの結果が、メッセージを受信したルータがそのメッセージのデスティネーションＩＰアドレスフィールドにおいて示されたルータではないことを表している場合には、ステップ４９２が実行される。ステップ４９２では、ルータは、その経路設定メッセージが転送される際に用いられるべきルータインターフェースを識別し、このインターフェースを変数Ｉｎｔｆ２で表す。この決定は、経路設定メッセージのデスティネーションアドレスフィールドに基づいており、これは旧基地局のＩＰアドレスである。ステップ４９４においては、ルータは、モバイルデバイスのＩＰアドレスに係るルーティングテーブルエントリが存在するか否かをチェックする。モバイルデバイスのＩＰアドレスに対するルーティングテーブルエントリが存在しない場合には、ステップ４９６において、モバイルデバイスのＩＰアドレスに対するルーティングテーブルエントリが生成される。このエントリは、（［＊、モバイルデバイスアドレス］→Ｉｎｔｆ１）という形式を有しており、ルータに到達した、モバイルデバイスに対応するデスティネーションＩＰアドレスを有するパケットが、どのインターフェースを介して受信されたかにかかわらず、Ｉｎｔｆ１を介してルーティングされることを意味している。その後、経路設定メッセージがＩｎｔｆ２を用いて次のホップのルータ宛に転送される。
【００７８】
ステップ４９４で、モバイルデバイスのＩＰアドレスに対応するルーティングテーブルエントリが存在すると決定された場合には、ステップ４９８が実行される。ステップ４９８においては、ハンドオフ経路設定メッセージのシーケンスナンバーがルータ内に存在するシーケンスナンバーエントリと比較される。経路設定メッセージのシーケンスナンバーがルータ内に存在するシーケンスナンバーエントリ以下である場合には、ハンドオフ経路設定メッセージはルータにおいてストアされている情報要素フィールド値と同じかより古いものであることを意味しており、その経路設定メッセージは、それ以上そのルータにおいては処理されない。その代わりにステップ５０２が実行され、その経路設定メッセージがＩｎｔｆ２を用いて次のホップのルータ宛に転送される。
【００７９】
しかしながら、ハンドオフ経路設定メッセージ中のシーケンスナンバーが既存のルータシーケンスナンバーエントリよりも大きい場合には、ハンドオフ経路設定メッセージがルータにストアされているものよりもより新しい情報要素フィールドを有していることを表しており、ステップ５００が実行される。（［Ｉｎｔｆ２、モバイルデバイスアドレス］→Ｉｎｔｆ１）という形式のルーティングテーブルエントリが追加される。このエントリは、既存のエントリを置換するのではなく、追加されることが重要である。既存のエントリは、（［〜Ｉｎｔｆ２、モバイルデバイスアドレス］→ＩｎｔｆＸ）という形式に更新される。これら二つのエントリはルーティングテーブル内に同時に存在し、以下の効果を有する。このルータにおいてＩｎｔｆ２から受信され、モバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有するパケットはＩｎｔｆ１を介して転送され、一方、このルータにおいてＩｎｔｆ２以外のインターフェースから受信され、モバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有するパケットはＩｎｔｆＸ（ステップ４９４において、存在すると決定されたエントリに係るインターフェース）を介して転送される。ステップ５０２においては、このハンドオフ経路設定メッセージが、Ｉｎｔｆ２を用いて次のホップのルータ宛に転送される。その後、ルータは次のフェーズ１メッセージの受信を待機する（ステップ５０４）。
【００８０】
図１７を参照すると、ステップ５２０においては、ドメインルータは、まず、新−旧−新フェーズ２ハンドオフ経路設定メッセージを受信する。フェーズ２メッセージというステータスは、そのメッセージが、旧基地局からモバイルデバイスへ返送される経路（すなわち、メッセージ経路の旧−新脚）内に存在するルータによって処理されつつあることを意味している。ステップ５２２では、ルータはメトリックフィールドをデクリメントする。なぜなら、フェーズ２ホップごとに１ホップ分ずつモバイルデバイスにより近くなるからである。ステップ５２４においては、ルータは当該経路設定メッセージを受信したインターフェースを識別し、変数Ｉｎｔｆ１をそのインターフェースに対応する値にセットする。ステップ５２６では、ルータは、（［Ｉｎｔｆ１、モバイルデバイスアドレス］→ＩｎｔｆＸ）という形式のルーティングテーブルエントリが存在するか否かをチェックする。すなわち、ルータプロセッサは、パケットがＩｎｔｆ１から受信されてモバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有する場合に、その受信されたパケットを規定されたインターフェース（ＩｎｔｆＸ）から転送するルーティングテーブルエントリが存在するか否かをチェックする。そのようなエントリが存在しない場合には、ステップ５３２において、どのインターフェースからその経路設定メッセージが受信されたかにかかわらず、経路設定メッセージ内に含まれるデスティネーションＩＰアドレスのみによって決定された次のホップに当該経路設定メッセージを転送する。しかしながら、ステップ５２６によって実行された検索の結果、（［Ｉｎｔｆ１、モバイルデバイスアドレス］→ＩｎｔｆＸ）という形式のエントリが存在することが明らかになった場合には、ステップ５２８が実行される。
【００８１】
ステップ５２８においては、当該ハンドオフ経路設定メッセージのシーケンスナンバーが既存のルータシーケンスナンバーエントリと比較される。当該ハンドオフ経路設定メッセージのシーケンスナンバーが既存のルータシーケンスナンバーエントリ以下である場合には、当該ハンドオフ経路設定メッセージがルータにストアされているものよりも新しくはない情報要素フィールド値を有することを意味しており、当該経路設定メッセージはそのルータにおいてさらに処理されることはない。その代わりに、ステップ５３２が実行され、当該ハンドオフ経路設定メッセージがＩｎｔｆＸを介して次のホップのルータ宛に転送される。
【００８２】
しかしながら、当該ハンドオフ経路設定メッセージのシーケンスナンバーが既存のルータシーケンスナンバーエントリより大きい場合には、当該ハンドオフ経路設定メッセージがルータにストアされているものよりもより新しい情報要素フィールドを有することを意味しており、ステップ５３０が実行される。そのルータにおけるルーティングテーブルエントリが更新され、モバイルデバイスのＩＰアドレスをデスティネーションアドレスフィールドに有する全てのエントリが、（［＊、モバイルデバイスアドレス］→ＩｎｔｆＸ）の形式に修正される。すなわち、モバイルデバイスのＩＰアドレスを有するエントリが修正され、いずれのインターフェースから受信されたかにかかわらず、モバイルデバイスのＩＰアドレスを有するそれ以降のパケットが、この時点の修正前に存在していたエントリにおいて規定されたインターフェースへ転送されるようになる。ステップ５３２においては、当該ハンドオフ経路設定メッセージがＩｎｔｆＸを介して次のホップのルータ宛に転送される。その後、どのような経路からステップ５３２に到達した場合であろうとも、ルータは次の新−旧−新フェーズ２ハンドオフ経路設定メッセージが受信されるのを待機する。受信されると、処理はステップ５２０から新たに再開される。
【００８３】
図１７は、本発明に従ったＨＡＷＡＩＩホストベースアーキテクチャを用いるドメイン例における新−旧−新経路設定方式処理シーケンスを示している。“Ｉｎｔｆ”は、あるノードが次のノードに接続される際のインターフェースあるいはポートを示している。ドメインルートルータ３６０は、ドメインルートルータのＩｎｔｆＡを介してインターネット３６２にアクセスする。ドメインルートルータ３６０のＩｎｔｆＢは、ルータＲ７のＩｎｔｆＡに接続されている。ドメインルートルータ３６０のＩｎｔｆＣは、ルータＲ８のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＢは、基地局ＢＳ９のＩｎｔｆＡに接続されている。ルータＲ７のＩｎｔｆＣは、基地局ＢＳ１０のＩｎｔｆＡに接続されている。ルータＲ８のＩｎｔｆＢは、基地局ＢＳ１１のＩｎｔｆＡに接続されている。ルータＲ８のＩｎｔｆＣは、基地局ＢＳ１２のＩｎｔｆＡに接続されている。
【００８４】
モバイルデバイス１１４は、旧基地局ＢＳ９から新基地局ＢＳ１１へのハンドオフの途中として示されている。モバイルデバイス１１４は、その情報要素フィールドが図９に関連して記述されているようにセットされた新−旧−新フェーズ１ハンドオフ経路設定メッセージを生成する。モバイルデバイス１１４は、当該ハンドオフ経路設定メッセージを第一ホップ５５０を介して基地局ＢＳ１１のＩｎｔｆＢ宛に送出する。
【００８５】
ハンドオフ経路設定メッセージを受信すると、基地局ＢＳ１１は情報要素メトリックフィールドをインクリメントし、モバイルデバイス１１４のＩＰアドレスに対応するルーティングテーブルエントリを生成する。前述されているように、モバイルデバイスに対するエントリは、着信インターフェース、モバイルデバイスのＩＰアドレス、及び関連して決定された、基地局ＢＳ１１によって受信されたモバイルデバイス１１４宛のパケットがルーティングされる発信インターフェース、という三つのフィールドを有する強化されたエントリである。当該ハンドオフ経路設定メッセージを受信する前には、基地局ＢＳ１１は、（［＊、デフォールト］→ＢＳ１１のＩｎｔｆＡ）という形式のデフォールトエントリを維持している。当該ハンドオフ経路設定メッセージの処理の後には、基地局ＢＳ１１は、（［＊、モバイルデバイスアドレス］→ＢＳ１１のＩｎｔｆＢ）という形式のエントリを生成する。すなわち、関連づけられる発信インターフェースは、当該ハンドオフ経路設定メッセージが受信されたものと同一のインターフェース（この例の場合には、無線インターフェースであるＢＳ１１のＩｎｔｆＢ）にセットされる。次に、ＢＳ１１は、デスティネーションＩＰアドレスフィールドに示されたアドレスへの伝達を完了する目的で、当該ハンドオフ経路設定メッセージを送出すべき転送先のルータを決定するために、旧基地局のＩＰアドレス（ＢＳ９アドレス）に関するルーティングテーブル検索を実行する。この例では、ＢＳ１１は、当該ハンドオフ経路設定メッセージを転送すべき適切なルータはルータＲ８であると決定する。それゆえ、ＢＳ１１は、当該ハンドオフ経路設定メッセージを第二ホップ５５２においてＢＳ１１のＩｎｔｆＡからＲ８のＩｎｔｆＢへとルーティングする。
【００８６】
ハンドオフ経路設定メッセージを受信すると、ルータＲ８は情報要素メトリックフィールドをインクリメントし、モバイルデバイス１１４に対応するルーティングテーブルエントリを生成する。当該ハンドオフ経路設定メッセージを受信して処理する前には、ルータＲ８は、（［＊、デフォールト］→Ｒ８のＩｎｔｆＡ）というデフォールトエントリを維持していた。当該ハンドオフ経路設定メッセージを処理した後には、ルータＲ８は、（［＊、モバイルデバイスアドレス］→Ｒ８のＩｎｔｆＢ）という形式のエントリを生成する。すなわち、ＩＰヘッダデスティネーションアドレスとしてモバイルデバイスのアドレスを有するパケットに関しては、どの着信インターフェースで受信されたかにかかわらず、関連する発信インターフェースとして用いられるのは当該ハンドオフ経路設定メッセージが受信されたものと同一のインターフェース（Ｒ８のＩｎｔｆＢ）である。ルータＲ８は、デスティネーションＩＰアドレスフィールドに含まれたアドレスへの伝達を完遂する目的で、当該ハンドオフ経路設定メッセージの転送先のルータを決定するために、旧基地局のＩＰアドレス（ＢＳ９のアドレス）に関するルーティングテーブル検索を実行する。この例では、ルータ８は、当該ハンドオフ経路設定メッセージを転送すべき適切なルータがドメインルートルータ３６０であることを決定する。それゆえ、ルータＲ８は、ハンドオフ経路設定メッセージを第三ホップ５５４でルータＲ８のＩｎｔｆＡからドメインルートルータのＩｎｔｆＣ宛に転送する。
【００８７】
ハンドオフ経路設定メッセージを受信すると、ドメインルートルータ３６０は情報要素メトリックフィールドをインクリメントし、モバイルデバイス１１４に対応するルーティングテーブルエントリを追加する。当該ハンドオフ経路設定メッセージを受信して処理する前には、ドメインルートルータ３６０は、基地局ＢＳ９を介したモバイルデバイス宛のパケットの伝達に係るルーティングテーブルエントリを（［＊、モバイルデバイスアドレス］→ＤＲＲのＩｎｔｆＢ）という形で維持していた。これは、それ以前の経路設定メッセージによって設定されたものである。このエントリは、パケットが受信されたインターフェースにかかわらず、モバイルデバイスのＩＰアドレスをＩＰヘッダデスティネーションアドレスとして有するパケットは、ドメインルートルータ３６０からＤＲＲのＩｎｔｆＢを介してルーティングされる、ということを規定していた。当該ハンドオフ経路設定メッセージを処理した後、ドメインルートルータ３６０は既存のルーティングテーブルエントリを（［〜ＤＲＲのＩｎｔｆＢ、モバイルデバイスアドレス］→ＤＲＲのＩｎｔｆＢ）という形式に修正し、（［ＤＲＲのＩｎｔｆＢ、モバイルデバイスアドレス］→ＤＲＲのＩｎｔｆＣ）という形式のエントリを付加する。それゆえ、モバイルデバイスをデスティネーションＩＰアドレスとして有するパケットは、その後にドメインルートルータ３６０において受信されると、どのインターフェースからそのパケットが受信されたかに依存して、二つのうちのいずれかのインターフェースを介して転送される。パケットが着信インターフェースＤＲＲのＩｎｔｆＢから受信されると、当該パケットはＤＲＲのＩｎｔｆＣを介してルータＲ８へと転送され、最終的に基地局ＢＳ１１を介して、接続されているモバイルデバイスにと転送される。しかしながら、パケットがＤＲＲのＩｎｔｆＢ以外の着信インターフェースを介して受信された場合には、そのパケットはＤＲＲのＩｎｔｆＢを介して転送される。処理の後、当該ハンドオフ経路設定メッセージは、第四ホップ５５６でＤＲＲのＩｎｔｆＢからルータＲ７のＩｎｔｆＡへと転送される。
【００８８】
ハンドオフ経路設定メッセージを受信すると、ルータＲ７は情報要素メトリックフィールドをインクリメントして、モバイルデバイス１１４のＩＰアドレスに対応するルーティングテーブルエントリを更新する。当該ハンドオフ経路設定メッセージを受信して処理する前は、ルータＲ７は、基地局ＢＳ９を介したモバイルデバイス宛のパケットの伝達に係るルーティングテーブルエントリを（［＊、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＢ）という形式で維持していた。これは、パケットが受信されたインターフェースにかかわらず、モバイルデバイスのＩＰアドレスをＩＰヘッダデスティネーションアドレスとして含むパケットは、ルータＲ７のＩｎｔｆＢを介してルータＲ７から基地局ＢＳ９宛に転送される、ということを規定していた。当該ハンドオフ経路設定メッセージを処理した後、ルータＲ７は既存のルーティングテーブルエントリを（［〜Ｒ７のＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＢ）の形に修正し、（［Ｒ７のＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＡ）の形のエントリを付加する。それゆえ、その後にルータＲ７によって受信される、モバイルデバイスをデスティネーションＩＰアドレスとして有するパケットは、どのインターフェースから受信されたかに依存して、二つのインターフェースのうちの一方を介して転送される。パケットが着信インターフェースＲ７のＩｎｔｆＢから受信された場合には、当該パケットはＲ７のＩｎｔｆＡを介してドメインルートルータ３６０宛に転送され、最終的に基地局ＢＳ１１を介して、接続されているモバイルデバイス宛に転送される。しかしながら、パケットがＲ７のＩｎｔｆＢ以外の着信インターフェースから受信される場合には、パケットはＲ７のＩｎｔｆＢを介して転送される。処理の後、当該ハンドオフ経路設定メッセージは第五ホップを介してルータＲ７のＩｎｔｆＢから基地局ＢＳ９のＩｎｔｆＡへと転送される。
【００８９】
ハンドオフ経路設定メッセージを受信すると、基地局ＢＳ９は情報要素メトリックフィールドをインクリメントして、モバイルデバイス１１４のＩＰアドレスに対応するルーティングテーブルエントリを更新する。当該ハンドオフ経路設定メッセージを受信して処理する前は、旧基地局（ＢＳ９）は、モバイルデバイス宛のパケットの伝達に係るルーティングテーブルエントリを（［＊、モバイルデバイスアドレス］→ＢＳ９のＩｎｔｆＢ）という形式で維持していた。これは、パケットが受信されたインターフェースにかかわらず、モバイルデバイスのＩＰアドレスをＩＰヘッダデスティネーションアドレスとして含むパケットは、基地局ＢＳ９からモバイルデバイス宛に発信インターフェースＢＳ９のＩｎｔｆＢを介して転送される、ということを規定していた。当該ハンドオフ経路設定メッセージの処理の後、基地局ＢＳ９は、モバイルデバイスのアドレスに対応するルーティングテーブルエントリを（［＊、モバイルデバイスアドレス］→ＢＳ９のＩｎｔｆＡ）という形に更新する。それゆえ、その後にＢＳ９において受信される、モバイルデバイスのアドレスをパケットヘッダデスティネーションＩＰアドレスとして有するパケットは、どのインターフェースを介して受信されたかにかかわらず、旧基地局からＢＳ９のＩｎｔｆＡを介して転送される（よって、当該ドメインの有線部分を介してＢＳ１１への伝達のためにパケットがリダイレクトされ、さらにＢＳ１１の無線インターフェースを介してモバイルデバイスへ伝送される）。新−旧−新ハンドオフ経路設定方式のフェーズ１部分の処理は、モバイルデバイスのＩＰアドレスに対応するよう当該ハンドオフ経路設定メッセージの情報要素フィールドのデスティネーションアドレスを変更することによって完了する。変更されたメッセージは、そのステップで、新−旧−新フェーズ２ハンドオフ経路設定メッセージと見なされる。新−旧−新フェーズ２ハンドオフ経路設定メッセージは、第六ホップ５６０を介して、ＢＳ９のＩｎｔｆＡからルータＲ７のＩｎｔｆＢへと転送される。
【００９０】
新−旧−新フェーズ２ハンドオフ経路設定メッセージを受信すると、ルータＲ７は情報要素メトリックフィールドをデクリメントし、モバイルデバイス１１４のＩＰアドレスに対応するルーティングテーブルエントリを更新する。このハンドオフ経路設定メッセージを受信して処理する前には、モバイルデバイス宛のパケットの伝達に関しては、二つのルーティングテーブルエントリが生成されて維持されていた。第一エントリは、（［〜Ｒ７のＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＢ）という形式を有し、第二エントリは（［Ｒ７のＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＡ）という形式を有していた。このハンドオフ経路設定メッセージの処理の後には、ルータＲ７はモバイルデバイスのＩＰアドレスに対応する二つの既存のエントリを（［＊、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＡ）という形式を有する単一のエントリで置換する。それゆえ、ルータＲ７は、モバイルデバイスアドレスをＩＰヘッダデスティネーションアドレスとして有する全てのパケットを、いずれのインターフェースから受信したかにかかわらず、発信インターフェースＲ７のＩｎｔｆＡを介して転送する。処理の後、当該ハンドオフ経路設定メッセージは、第七ホップ５６２でルータＲ７のＩｎｔｆＡからドメインルートルータ３６０宛に転送される。
【００９１】
新−旧−新フェーズ２ハンドオフ経路設定メッセージを受信すると、ドメインルートルータ３６０７は情報要素メトリックフィールドをデクリメントし、モバイルデバイス１１４のＩＰアドレスに対応するルーティングテーブルエントリを更新する。このハンドオフ経路設定メッセージを受信して処理する前には、モバイルデバイス宛のパケットの伝達に関しては、二つのルーティングテーブルエントリが生成されて維持されていた。第一エントリは、（［〜ＤＲＲのＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＢ）という形式を有し、第二エントリは（［ＤＲＲのＩｎｔｆＢ、モバイルデバイスアドレス］→Ｒ７のＩｎｔｆＣ）という形式を有していた。このハンドオフ経路設定メッセージの処理の後には、ドメインルートルータ３６０はモバイルデバイスのＩＰアドレスに対応する二つの既存のエントリを（［＊、モバイルデバイスアドレス］→ＤＲＲのＩｎｔｆＣ）という形式を有する単一のエントリで置換する。それゆえ、ドメインルートルータ３６０は、モバイルデバイスアドレスをＩＰヘッダデスティネーションアドレスとして有する全てのパケットを、いずれのインターフェースから受信したかにかかわらず、発信インターフェースＤＲＲのＩｎｔｆＣを介して転送する。処理の後、当該ハンドオフ経路設定メッセージは、第八ホップ５６４でドメインルートルータ３６０のインターフェースＤＲＲのＩｎｔｆＣからルータＲ８の着信インターフェースＲ８のＩｎｔｆＡ宛に転送される。
【００９２】
新−旧−新ハンドオフ経路設定メッセージを受信すると、ルータＲ８は情報要素メトリックフィールドをデクリメントする。モバイルデバイスに係るルーティングテーブルエントリは更新を必要としない。なぜなら、それは単一のものであって（パケット転送に用いられる発信インターフェースはＩＰヘッダのデスティネーションアドレスのみに依存しており、パケットが受信されるインターフェースには依存していない）、モバイルデバイス宛にルーティングされるべきパケットが受信されるインターフェースを正確に反映しているからである。当該ハンドオフ経路設定メッセージは、第九ホップ５６６でルータＲ８のＩｎｔｆＢから基地局ＢＳ１１のＩｎｔｆＡ宛に転送される。
【００９３】
新−旧−新ハンドオフ経路設定メッセージを受信すると、新基地局（ＢＳ１１）は情報要素メトリックフィールドをデクリメントする。モバイルデバイスに係るルーティングテーブルエントリは更新を必要としない。なぜなら、それは単一のものであって（パケット転送に用いられる発信インターフェースはＩＰヘッダのデスティネーションアドレスのみに依存しており、パケットが受信されるインターフェースには依存していない）、モバイルデバイス宛にルーティングされるべきパケットが受信されるインターフェースを正確に反映しているからである。当該ハンドオフ経路設定メッセージは、第十ホップ５６８で基地局ＢＳ１１のＩｎｔｆＢからモバイルデバイス宛に転送される。返送されてきたハンドオフ経路設定メッセージの受信は、ドメイン有線ルーティング更新手続きが満足に完了したことを表している。
【００９４】
新−旧−新ハンドオフ経路設定方式の使用は、ＴＤＭＡ装置を用いる場合などのように、無線デバイスが一度に一つの基地局のみにしかチューニングできないようなアプリケーションに特に適している。ＴＤＭＡネットワーク内では、ソフトハンドオフという概念が存在しない（なぜなら、モバイルデバイスが旧基地局と新基地局の双方に対してチューニングすることが無いからである。）。むしろ、ＴＤＭＡモバイルデバイスは、旧基地局に対してチューニングしており、新基地局に近づくにつれて、旧基地局との間の旧リンクを切断すると同時に新基地局との間の新リンクを設定する。新−旧方式では、旧リンクが切断されつつあり、かつ新リンクの設定前の期間にパケットが旧基地局宛に転送される可能性がある。それゆえ、新−旧方式や旧−新方式を用いると、パケットロスが発生する可能性がある。しかしながら、新−旧−新ハンドオフ経路設定方式は、旧リンクが切断されつつある間に旧基地局宛に転送されたパケットが新基地局宛に転送されることが保証される。それゆえ、ハンドオフの間のパケットロスの危険性は最小化されている。
【００９５】
図１９は、メモリ５８８内にインプリメントされたルーティングテーブル５９０を有するルータの実施例を模式的に示す図である。ルータは、前のノードからパケットを受信するための複数個の入力ポート（すなわちインターフェース）５８２及び次のホップへパケットを送出するための複数個の出力ポート（すなわちインターフェース）５８４を有している。これらのインターフェースが双方向であることも可能である。すなわち、インターフェースは、入力及び出力インターフェースの双方として機能することも可能である。さらに、ルータ５８０は、プロセッサ５８６及びメモリ５８８を有している。ルータに存在する処理及びメモリ資源のために、転送アルゴリズムのインプリメンテーション、キュー、シグナリング、メッセージング、ルーティングテーブル５９０のインプリメンテーション、さらには他の標準的及び補足的なルータ機能及びサービス等のルータ機能やサービスの実現が可能になる。図１９に示されたルータ５８０は、ルータメモリ５８８の資源を用いてインプリメントされたルーティングテーブル５９０を有している。ルーティングテーブル５９０は、ルーティングテーブル５９０に係る要素フィールドの蓄積用に割り当てられた、ルータメモリ５８８の分割された部分にストアされている複数個のルーティングエントリを有している。ルータプロセッサ５８６は、ルーティングエントリの初期値を決定し、かつ、これらの値をストアし、更新し、かつアクセスする目的でのルータメモリ５８８とのインターフェースとして機能するように用いられる。
【００９６】
前述された経路設定方式は、ルーティング情報プロトコルバージョン２（ＲＩＰｖ２）を修正して拡張することによってインプリメントされた。以下に記述されるのは、ＲＩＰｖ２を用いて新−旧経路設定方式をモデル化するために用いられた方法例である。他の経路設定方式のインプリメンテーションも同様に実行される。ノードにおける処理は以下のように行なわれる。通常のＲＩＰｖ２更新メッセージは、ＡＦ＿ＩＮＥＴというファミリーフィールド識別子を有している。本発明の一実施例においては、ルーティング更新メッセージと識別する目的でＡＦ＿ＭＯＢＩＮＥＴというファミリー識別子を有するＨＡＷＡＩＩ経路設定メッセージが用いられる。種々の経路設定メッセージのうち、リフレッシュ経路設定メッセージはＲＩＰＣＭＤ＿ＲＥＳＰＯＮＳＥというコマンドフィールドを用いてインプリメントされるが、更新経路設定メッセージはＲＩＰＣＭＤ＿ＲＥＳＰＯＮＳＥ．ＡＣＫというコマンドフィールドを用いてインプリメントされる。
【００９７】
ルーティングデーモンは、ＡＦ＿ＭＯＢＩＮＥＴというファミリー識別子を有するＲＩＰメッセージを受信すると、メトリックフィールドをインクリメントし、（モバイルデバイスのＩＰアドレス→メッセージが受信されたインターフェース）という形式のエントリを追加する。ルーティングデーモンがモバイルデバイスに対応するエントリを既に有している場合には、メッセージに係るシーケンスナンバーが０かあるいは当該モバイルデバイスに対応する既存のエントリのシーケンスナンバーよりも大きければ、当該既存のエントリが更新される。その後、ルーティングデーモンは、当該メッセージが転送されるべきインターフェースを決定する。このことは、メッセージ内のデスティネーションアドレスフィールドに対応するルーティングテーブルエントリを用いて実行される。その後、メッセージは次のホップのルータ宛に転送される。次のホップのルータに係るアドレスが現在のルータあるいは基地局のアドレスのうちの一方と同一の場合には、当該経路設定メッセージはその最終的なデスティネーションアドレスに到達していることになる。メッセージが最終的なデスティネーションアドレスに到達すると、コマンドフィールドがＲＩＰ＿ＲＥＳＰＯＮＳＥ＿ＡＣＫとセットされている場合には、更新経路設定メッセージの場合と同様に、アクノレッジ信号が生成される。その後、生成されたアクノレッジ信号はモバイルデバイス宛に転送される。ドメイン基地局に認証情報が保持されている場合には、認証情報を含むアクノレッジ信号がまず新基地局宛に送出され、その新基地局がアクノレッジ信号をモバイルデバイス宛に転送する。
【００９８】
動的ホスト配置プロトコル（ＤＨＣＰ）サーバ内でのルーティング情報プロトコル（ＲＩＰ）とモバイルＩＰ標準との統合は、以下の記述例に従って実現される。モバイルデバイスは、起動されると、最初にＤＨＣＰ＿ＤＩＳＣＯＶＥＲメッセージを起動時点で接続されている基地局宛に送出する。それゆえ、基地局はＤＨＣＰリレーとして機能し、当該ＤＨＣＰ＿ＤＩＳＣＯＶＥＲメッセージをＤＨＣＰサーバ宛に転送する。ＤＨＣＰサーバは、モバイルデバイスあての返信をＤＨＣＰ＿ＯＦＦＥＲメッセージと共に伝達する。その後、モバイルデバイスは、ＤＨＣＰ＿ＲＥＱＵＥＳＴメッセージを基地局宛に伝達し、基地局はそのメッセージをＤＨＣＰサーバ宛にリレーする。その後、ＤＨＣＰサーバは、モバイルデバイスに対して割り当てられたアドレス（’ｃｉａｄｄｒ’フィールド）、基地局のアドレス（’ｇｉａｄｄｒ’フィールド）、及びドメインルートルータのアドレス（’ｓｉａｄｄｒ’フィールド）を含むＤＨＣＰ＿ＲＥＳＰＯＮＳＥを送出する。その後、モバイルデバイスは、シーケンスナンバー０を有し、ドメインルートルータを最終的なデスティネーションアドレスとして有する更新経路設定メッセージを現在の基地局宛に送出する。このメッセージは、ドメイン内の選択されたルータにおいてルーティングエントリを設定し、そのため、ドメインルートルータに到達するパケットはモバイルデバイス宛に伝達される。モバイルデバイスが、同一ドメイン内の新たな基地局へとハンドオフする場合には、前述されているようにシーケンスナンバーを更新し、ハンドオフ後の接続性を維持する目的で、新−旧経路設定方式を用いて経路設定メッセージを送出する。モバイルデバイスが新たなドメイン内の新たな基地局へとハンドオフする場合には、モバイルデバイスは、新ドメインのＤＨＣＰサーバを介して、気付アドレスを獲得する。その後、モバイルデバイスは、以前のドメインでのホームエージェントに新たな気付アドレスを通知する。その後、パケットは、モバイルデバイスが新ドメイン内の基地局に接続されている限り、前記ホームエージェントと新気付アドレスとの間で通過させられる。モバイルデバイスの電源が切断されると、新ドメインにおいてＤＨＣＰサーバによって割り当てられたアドレス及び／あるいは元のドメインにおいてＤＨＣＰサーバから割り当てられたアドレスは再使用のために破棄される。
【００９９】
認証情報は、任意のユーザが経路設定メッセージを送出するのを許可せず、それによって他のユーザによるパケット送出を防止する目的で用いられる。本明細書において記述されているＨＡＷＡＩＩの実施例と共に考慮されてきたそれぞれの経路設定メッセージは、安全だと考えられている。なぜなら、ハンドオフ経路設定方式をインプリメントする目的で、旧基地局による協調と関与をそれぞれが必要とするからである。ユーザに係る認証情報は、モバイルデバイスが起動される際に現在の基地局内にストアされる。モバイルデバイスが新基地局へとハンドオフする場合には、旧基地局は、当該モバイルデバイスが経路設定メッセージにおいてそれ自身を認証することができる場合にのみ、経路設定メッセージを是認する。その後、認証情報は、経路設定メッセージのアクノレッジ信号上で、旧基地局から新基地局へと転送される。モバイルデバイスの起動登録の際のＩＰアドレスの割り当ても、任意のユーザがＩＰアドレスを獲得することを防ぐ目的で安全でなければならない。このことは、セルラーネットワークで用いられているように、ホームロケーション登録（ＨＬＲ）認証等の機構を用いて、あるいは、ＲＡＤＩＵＳプロトコル認証機構を用いて、実現される。
【０１００】
図２０は、モバイルデバイスのホームエージェントからモバイルデバイスの外部エージェント宛にＩＰパケットを通過させる目的で用いられるモバイルＩＰ標準方法を模式的に示す図である。通信ノード６００からモバイルデバイス６０８宛の伝達目的で発せられたパケットは、モバイルデバイス６０８のホームエージェント６０２に対するホストとして機能しているノードにまずルーティングされる。ホームエージェント６０２は、モバイルデバイス６０８のＩＰアドレスをデスティネーションアドレスとして有する全てのパケットが最初にルーティングされるべき、モバイルデバイス６０８に対する登録済みエージェントである。通信ノード６００とホームエージェント６０２との間の経路は、全体は示されていない。インターネット、プライベートイントラネット、及び／あるいは複数個のルータ及びノードが、通信ノード６００とホームエージェント６０２との間に配置されうる。ホームエージェント６０２は、モバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有するパケットを受信すると、それらのパケットをモバイルデバイスの外部エージェント６１０宛に転送する。外部エージェント６１０は、この実施例ではモバイルデバイス６０８内に位置しているように示されている。モバイルデバイス６０８は、基地局６０６との間に設定された無線接続を維持しているように図示されている。ルータ６０４が基地局６０６とホームエージェント６０２との間に配置されている。ホームエージェント６０２とモバイルデバイス６０８との間の通過経路は、全体は示されていない。インターネット、プライベートイントラネット、及び／あるいは複数個のルータ及びノードが、ホームエージェント６０２とモバイルデバイス６０８との間に配置されうる。
【０１０１】
通信ノード６００からモバイルデバイス６０８宛のＩＰパケット６１２は、まず、ホームエージェント６０２に対するホストとして機能しているノードによって受信される。ＩＰパケット６１２は、通常、そのサイズが１５００バイトに制限されている。１５００バイトのうち、４０バイトがＩＰパケットヘッダに用いられる。通信ノードはＩＰヘッダソースアドレス６１４にセットされ、モバイルデバイスはＩＰヘッダデスティネーションアドレス６１６にセットされる。全体で１４６０バイトが、データペイロード６１８用に利用可能である。ホームエージェントに対するホストとして機能しているノードによって受信された後、ホームエージェントはＩＰパケット６１２をモバイルデバイスの代わりに受け取り、ＩＰパケット６１２を付加されたＩＰヘッダデスティネーションアドレス及びソースアドレスと共にカプセル化し、カプセル化されたパケット６２０を、モバイルデバイス６０８内に位置している外部エージェント６１０宛のＩＰ−イン−ＩＰトンネルで転送する。それゆえ、カプセル化されたパケットは、通信ノードのＩＰアドレス６２６とモバイルデバイスのＩＰアドレス６２８、ホームエージェントのＩＰアドレスを示す付加された１０バイトのＩＰヘッダソースアドレス６２２、外部エージェントのＩＰアドレスを示す付加された１０バイトのＩＰヘッダデスティネーションアドレス６２４、及び、データペイロード６３０用に利用可能な全１４４０バイトから構成されている。通過させられたカプセル化済みパケット６２０が外部エージェント６１０において受信されると、外部エージェントは付加されたＩＰヘッダソース及びデスティネーションアドレス６２２、６２４を除去し、残りのパケットを処理のためにモバイルデバイス６０８宛に送出する。
【０１０２】
図２１は、モバイルデバイスのホームエージェントからモバイルデバイスの外部エージェント宛のＩＰパケットの通過に関する、本発明に従った最適化を例示した図である。通信ノード６００からモバイルデバイス６０８宛に送出されたパケットは、モバイルデバイス６０８のホームエージェントに対するホストとして機能しているノードへとルーティングされる。ホームエージェント６０２は、モバイルデバイス６０８のＩＰアドレスをデスティネーションアドレスとして有する全てのパケットが最初にルーティングされるべき、モバイルデバイス６０８に対する登録済みエージェントである。通信ノード６００とホームエージェント６０２との間の経路は、全体は示されていない。インターネット、プライベートイントラネット、及び／あるいは複数個のルータ及びノードが、通信ノード６００とホームエージェント６０２との間に配置されうる。ホームエージェント６０２は、モバイルデバイスのＩＰアドレスをデスティネーションアドレスとして有するパケットを受信すると、それらのパケットをモバイルデバイスの外部エージェント６１０宛に転送する。外部エージェント６１０は、この実施例ではモバイルデバイス６０８内に位置しているように示されている。モバイルデバイス６０８は、基地局６０６との間に設定された無線接続を維持しているように図示されている。ルータ６０４が基地局６０６とホームエージェント６０２との間に配置されている。ホームエージェント６０２とモバイルデバイス６０８との間の通過経路は、全体は示されていない。インターネット、プライベートイントラネット、及び／あるいは複数個のルータ及びノードが、ホームエージェント６０２とモバイルデバイス６０８との間に配置されうる。
【０１０３】
通信ノード６００からモバイルデバイス６０８宛のＩＰパケット６１２は、まず、ホームエージェント６０２に対するホストとして機能しているノードによって受信される。ＩＰパケット６１２は、通常、そのサイズが１５００バイトに制限されている。１５００バイトのうち、４０バイトがＩＰパケットヘッダに用いられる。通信ノードはＩＰヘッダソースアドレス６１４にセットされ、モバイルデバイスはＩＰヘッダデスティネーションアドレス６１６にセットされる。全体で１４６０バイトが、データペイロード６１８用に利用可能である。ホームエージェントに対するホストとして機能しているノードによって受信された後、ホームエージェントはＩＰパケット６１２をモバイルデバイスの代わりに受け取り、ＩＰパケット６１２を付加されたＩＰヘッダソース及びデスティネーションアドレスと共にカプセル化する代わりに、モバイルデバイスの外部エージェント６４４に対して割り当てられたアドレスをモバイルデバイスのＩＰアドレス６１６と相互交換する。ＩＰヘッダデスティネーションアドレスが相互交換されると、新たなＩＰパケット６４０が、モバイルデバイス６０８内に存在する外部エージェント６１０宛に転送される。それゆえ、新たなＩＰパケット６４０は、通信ノードのＩＰアドレス６４２、外部エージェントのＩＰアドレス６４４を含む４０バイトのＩＰヘッダ、及びデータペイロード６４６として利用可能な１４６０バイトより構成される。付加ＩＰヘッダソース及びデスティネーションアドレスを付け加える代わりにパケットのデスティネーションアドレスを交換することによって、利用可能なデータペイロード６４６サイズは減少させられることはない。すなわち、通過最適化を用いることによって、パケットをホームエージェントから外部エージェントへと通過させるために必要になるオーバーヘッドが低減される。新たなＩＰパケット６４０を受信すると、外部エージェント６１０はモバイルデバイスのＩＰアドレス６１６をモバイルデバイスの外部エージェント６４４に対して割り当てられたアドレスと相互交換し、その結果得られたパケットを処理目的でモバイルデバイス６０８宛に伝達する。
【０１０４】
図２２は、従来技術に係るモバイルＩＰパケットトンネリングに係るｔｃｐｄｕｍｐトレースを示す図である。前述されているように、モバイルデバイスが常にホームネットワークの外部に位置する場合には、パケットは、通常、対応するホームエージェントからモバイルデバイス宛に通過させられる。通信ノードがルート最適化拡張を用いる場合には、パケットはホームエージェント宛にルーティングされることなく直接モバイルデバイス宛にルーティングされる。しかしながら、通信ノードがルート最適化をインプリメントするように更新されるまでには非常に長い時間が必要と考えられている。従来技術に係る、ホームエージェントから外部エージェントへのモバイルＩＰパケットトンネリングには、モバイルデバイス宛に送出されるパケットの各々に付加ヘッダを付け加えるステップが含まれる。この付加ヘッダを含ませることにより、図２２のｔｃｐｄｕｍｐトレースの例からも明らかなように、重大なかつ望ましくない効果がもたらされる。ｔｃｐｄｕｍｐトレース中で、通信ノードはＣＨで示されており、モバイルデバイスはＭＨ、ホームエージェントはＨＡ、及び外部エージェントはＦＡでそれぞれ示されている。
【０１０５】
図２２の最初の５ステップは、通信ノードとホームエージェントとの間のトランスミッションコントロールプロトコル（ＴＣＰ）ハンドシェークを表している。この期間に、最大セグメント長（ｍｓｓ）が１４６０バイトであることが決定される。最大セグメント長は、ＩＰパケット中の、アプリケーションデータが存在するペイロード部分の大きさを反映している。１５００バイトよりなるＩＰパケットを構成している残りの４０バイトは、ソース及びデスティネーションＩＰアドレスを含むＩＰパケットヘッダとして用いられる。ステップ６では、１４６０バイトのペイロードを有する最初のパケットがフラグメンテーション禁止フラグをセットした状態（経路ＭＴＵ検索）で送出されると、ホームエージェントがインターネットコントロールメッセージプロトコル（ＩＣＭＰ）エラーメッセージを通信ノード宛に返送して、通過ヘッダの付加がフラグメンテーションを要求することを示す。ステップ７の完了の後、経路最大伝送ユニット（ＭＴＵ）として１４４０バイトがパケットペイロードに新たに割り当てられる。それゆえ、付加パケットオーバーヘッドを含めることによるパケット伝送効率の低減に加えて、通過ヘッダを利用することにより、通信ノードとホームエージェントとの間で浪費される１ラウンドトリップ分の通信の追加という望ましくなくかつ不効率な影響がある。この影響は、通信ノードからモバイルデバイス宛のウェブ（ｗｅｂ）伝送に関してモバイルＩＰトンネリング方式を用いる場合に特に認識されるものとなり、５００ミリ秒あるいはそれ以上の付加遅延が生ずる。なぜなら、各ウェブページの伝送は、それを完了するまでに複数個のＴＣＰダウンロードが必要とされるからである。
【０１０６】
図２３は、本発明に従ってトンネリング最適化を利用する場合のホームエージェントから外部エージェントへのパケット伝達に係るｔｃｐｄｕｍｐトレースを示した図である。前述されているように、トンネリング最適化はモバイルデバイス内に存在する外部エージェントを利用しており、それゆえ、モバイルデバイスの気付アドレスがモバイルデバイスの外部エージェントとのアドレスとして用いられる。よって、ホームエージェントは、ＩＰヘッダデスティネーションアドレスを、モバイルデバイスのアドレスからその気付アドレス（外部エージェントのアドレス）に相互交換する。パケットがモバイルデバイスに到達すると、外部エージェントはモバイルデバイスのＩＰアドレスを当該外部エージェントのアドレスと置換し、本来含められているフィールドを有するパケットヘッダが回復される。その後、パケットは、モバイルデバイスにおいて実行されているアプリケーションに転送される。このトンネリング最適化はアプリケーションレイヤに対して完全にトランスペアレントであり、外部エージェントがモバイルデバイス内に存在している限りは適用可能である。さらに、トンネリング最適化は、付加ヘッダというオーバーヘッドを負わない。図２３の最初の５ステップは、通信ノードとホームエージェントとの間のトランスミッションコントロールプロトコル（ＴＣＰ）ハンドシェークを表している。ここで、ＩＰパケットヘッダソースアドレスが通信ノードのものであるにもかかわらず、ステップ２及び５がホームエージェントによって生成されたものであることに留意されたい。ステップ６から８より明らかなように、パケットフラグメンテーションを必要とするというインターネットコントロールメッセージプロトコル（ＩＣＭＰ）エラーメッセージは用いられない。なぜなら、付加ヘッダが追加されることがないからである。それゆえ、トンネリング最適化を用いることは、必要とされるパケットオーバーヘッドを低減することによってパケット伝送効率に利するのみならず、通信ノードとホームエージェントとの間のＴＣＰセッションごとの１ラウンドトリップ分の通信を必要とすることによる望ましくなくかつ不効率な影響を無くしている。
【０１０７】
図２４は、ホームエージェントに対するホストとして機能しているノードにおけるトンネリング最適化をインプリメントする手続き例を示す流れ図である。ステップ７００においては、モバイルデバイス宛のパケットが対応するホームエージェントにおいて受信されると、ＩＰヘッダの正確性を確認する目的でＩＰヘッダチェックサムがまずチェックされる。ホームエージェントは、当該ホームエージェントに登録されてホームドメインから離れて存在しているモバイルデバイスに対応するモバイルデバイスアドレスのリストを維持している。このリストは、モバイルホストアウェーフロムホームリストと呼称される。ステップ７０２では、ホームエージェントが、テーブル検索によって、このパケットのＩＰヘッダデスティネーションアドレスが、モバイルホストアウェーフロムホームリスト中に関連するエントリを有しているか否かがチェックされる。エントリを有さない場合には、トンネリング最適化が破棄され、従来技術に係るＩＰ処理がパケットを転送する目的で行なわれる。しかしながら、エントリを有している場合には、ステップ７０４が実行される。ステップ７０４では、パケットのＩＰヘッダ中のＩＰリザーブドフラグメントフラグがセットされる。ＩＰリザーブドフラグメントフラグがセットされているということは、その関連するパケットがトンネリング最適化方式の適用を受けるということを意味している。この重要な情報はＩＰヘッダ内に含められ、このパケットを受信する外部エージェントに、その受信したパケットに関連してトンネリング最適化方式が用いられていることを通知する。ステップ７０６では、パケットのＩＰヘッダデスティネーションアドレスに含まれているモバイルデバイスのアドレスが、モバイルデバイスに係る気付アドレスによって置換される。この場合の気付アドレスは外部エージェントのＩＰアドレスである。なぜなら、外部エージェントがモバイルデバイス内に存在しているからである。ステップ７０８では、新たなＩＰヘッダチェックサムが計算される。新たなＩＰヘッダチェックサムの計算は、当該ＩＰヘッダにはモバイルデバイスのＩＰアドレスの代わりに外部エージェントのＩＰアドレスがＩＰヘッダデスティネーションアドレスとして含まれているため、必要となる。ステップ７１０では、ＩＰパケットが、モバイルデバイス内に存在している外部エージェント宛に転送される。
【０１０８】
図２５は、対応するモバイルデバイス内に存在する外部エージェントにおいてトンネリング最適化をインプリメントするプログラム例を示す流れ図である。ステップ７２０では、パケットが外部エージェントによって受信されると、ＩＰヘッダの正確性を確認する目的でＩＰヘッダチェックサムがまずチェックされる。ステップ７２２では、ＩＰヘッダに含まれるＩＰリザーブドフラグメントフラグがセットされているか否かを決定するためのチェックがなされる。ＩＰリザーブドフラグメントフラグがセットされていない場合には、そのパケットは当該外部エージェント宛にトンネリング最適化方式を用いて転送されてきたのではないため、そのＩＰパケットのデスティネーションアドレスを変更することなく通常のパケット処理が実行される。しかしながら、リザーブドフラグメントフラグがセットされている場合には、ホームエージェントにおいてトンネリング最適化方式がインプリメントされていたことを意味しており、この外部エージェントにおいてもトンネリング最適化方式がインプリメントされなければならない。それゆえ、ステップ７２４において、当該パケットのＩＰヘッダデスティネーションアドレスが当該外部エージェントの気付アドレスリストに含まれるエントリと比較される。モバイルデバイスが気付アドレス（外部エージェントが対応するモバイルデバイス内に存在している場合には、外部エージェントのアドレスと同一である）を有している場合には、外部エージェントは現在の気付アドレスを反映するように気付アドレスリストを更新する。気付アドレスリスト中に含まれない場合には、そのパケットは誤って受信されたものであり、破棄される（ステップ７３０）。しかしながら、そのパケットのＩＰヘッダデスティネーションアドレスが当該外部エージェントの気付アドレスリスト中のエントリと一致する場合には、ステップ７２６が実行される。ステップ７２６では、外部エージェントが、そのパケットのＩＰヘッダデスティネーションアドレスにおいて、当該外部エージェントに対応するＩＰアドレス（すなわち気付アドレス）をホームエージェントに対応するＩＰアドレスに置換する。ステップ７２８では、当該パケットに対するパケット処理がモバイルデバイスにおいて再開される。
【０１０９】
以上の説明は、本発明の一実施例に関するもので，この技術分野の当業者であれば、本発明の種々の変形例が考え得るが、それらはいずれも本発明の技術的範囲に包含される。さらに、本明細書に記述された全ての例示及び条件言語は、本発明の原理並びに本発明の発明者によって提供された概念の当業者による理解を助ける教育的な目的で原理的に表現されているものであり、それら記述された例示及び条件が本発明を何ら限定するものではないというように解釈されるべきものである。さらに、本発明の原理、側面及び実施例に係る全ての記述は、その実施例と共に、それらの構造的等価事物及び機能的等価事物の双方を包含することが企図されている。加えて、それらの等価事物には、現在公知の等価事物及び将来において開発される等価事物、すなわち、その構造にかかわらず同一の機能を実行する全ての被開発事物、の双方が含まれることが企図されている。
【０１１０】
よって、例えば、本明細書に記載されているブロック図は、本発明の原理を具体化する回路例に係る概念的な観点を表現していることを理解されたい。同様に、あらゆる流れ図、状態遷移図、擬似符号、及びそれらに類するものは、コンピュータあるいはプロセッサが明示的に図示されているいないにかかわらず、実質的にコンピュータによって読み取り可能な媒体において表現され、コンピュータあるいはプロセッサによって実行される種々のプロセスを表していることにも留意されたい。
【０１１１】
“プロセッサ”というラベルが付された機能ブロックを含む種々の図示あるいは記述された要素の機能は、専用のハードウエアあるいはソフトウエアを実行することが可能なハードウエアを適切なソフトウエアと関連させて用いることによって実現されうる。プロセッサが用いられる場合には、機能は、単一の専用プロセッサ、単一の共有プロセッサ、あるいはそのうちのいくつかが共有されている複数個の個別のプロセッサによって実現されうる。さらに、“プロセッサ”あるいは“コントローラ”という術語の明示的な使用は、ソフトウエアを実行することが可能なハードウエアを排他的に言及していると解釈されるべきではなく、デジタル信号プロセッサ（ＤＳＰ）、ソフトウエアをストアするリードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性ストレージ装置等を暗示的に含む（但し、それらに限定されるものではない）。従来技術に係る及び／あるいはカスタム品のその他のハードウエアも含められうる。同様に、図に示された全てのスイッチは概念的なものである。それらの機能は、プログラムロジックの操作を通じて、専用のロジックを通じて、プログラム制御及び専用ロジックの相互作用を通じて、あるいは手動で実行されうるものであり、選択可能な特定の技術は本明細書をより詳細に理解することによってその実施者によって選択可能である。
【０１１２】
本明細書の特許請求の範囲において、特定の機能を実行する手段として表現されているあらゆる要素は、例えば、ａ）その機能を実行する回路要素の組み合わせ、あるいは、ｂ）その機能を実行する目的でソフトウエアを実行する適切な回路と組み合わせられたファームウエア、マイクロコードあるいはその同等物を含むあらゆる形態のソフトウエア、等を含む、その機能を実行するあらゆる方策を含むものであることが企図されている。このような請求項によって規定された本発明は、記述された種々の手段によって実現される機能が、特許請求の範囲が要求するような方式で組み合わせられて構成されている、という事実に存する。よって、本発明の出願者は、それらの機能を実現する全ての手段を本明細書に記述／例示されたものと同等であると見なす。
【０１１３】
【発明の効果】
以上述べたごとく、本発明によれば、サブネット内のローカルな移動性を最小の遅延及び最小のトラフィック量で実現する、パケットベースネットワークへの無線アクセス方法が提供される。
【図面の簡単な説明】
【図１】インターネットプロトコル（ＩＰ）ベースネットワークへのモバイルデバイスからのモバイルＩＰ無線アクセスを実現するために用いられるアーキテクチャを模式的に示す図。
【図２】本発明に従ったハンドオフ認識無線アクセスインターネットインフラストラクチャ（ＨＡＷＡＩＩ）に関するドメインベースアーキテクチャを模式的に示す図。
【図３】本発明に係るＨＡＷＡＩＩドメインベースアーキテクチャを利用するドメインに関する動的ホスト配置プロトコル（ＤＨＣＰ）サーバにおいて実行されるプロセスステップを例示する流れ図。このＤＨＣＰサーバは動的ホーム最適化を利用しない。
【図４】本発明に係るＨＡＷＡＩＩドメインベースアーキテクチャを利用するドメインに関する動的ホスト配置プロトコル（ＤＨＣＰ）サーバにおいて実行されるプロセスステップを例示する流れ図。このＤＨＣＰサーバは動的ホーム最適化を利用する。
【図５】動的ホーム最適化を利用するしないにかかわらず、本発明に従って、モバイルデバイスのパワーダウンの際に実行されるドメインベースのプロセスステップを例示する流れ図。
【図６】本発明に従って動的ホスト配置プロトコル（ＤＨＣＰ）サーバ及びホームエージェントに対するホストとして機能するドメインルータの実施例を模式的に示す図。
【図７】本発明に従った、リフレッシュ経路設定メッセージに係る情報要素フィールドの構造例を示す図。
【図８】本発明に従った、パワーアップ経路設定メッセージに係る情報要素フィールドの構造例を示す図。
【図９】本発明に従った、ハンドオフ経路設定メッセージに係る情報要素フィールドの構造例を示す図。
【図１０】本発明に従って、ドメインベースＨＡＷＡＩＩアーキテクチャにおけるルータによってパワーアップ経路設定メッセージの処理のために用いられる方法例を示す流れ図。
【図１１】本発明に従った、ＨＡＷＡＩＩドメインベースアーキテクチャを利用するドメイン例におけるパワーアップ経路設定メッセージの処理シーケンスを示す図。
【図１２】本発明に従って、リフレッシュ経路設定メッセージの処理のためにドメインベースＨＡＷＡＩＩアーキテクチャサブネット内のルータによって用いられる方法例を示す流れ図。
【図１３】本発明に従って、新−旧経路設定メッセージの処理のためにドメインベースＨＡＷＡＩＩアーキテクチャサブネット内のルータによって用いられる方法例を示す流れ図。
【図１４】本発明に従った、ＨＡＷＡＩＩドメインベースアーキテクチャを利用するドメイン例における新−旧経路設定方式処理シーケンス例を示す図。
【図１５】本発明に従った、ＨＡＷＡＩＩドメインベースアーキテクチャを利用するドメイン例における新−旧経路設定方式処理シーケンス例を示す図。ここでは、新たな基地局が旧基地局に直接接続されている。
【図１６】本発明に従って新−旧−新フェーズ１ハンドオフ経路設定メッセージを処理するドメインルータによって用いられる方法例を示す流れ図。
【図１７】本発明に従って新−旧−新フェーズ２ハンドオフ経路設定メッセージを処理するドメインルータによって用いられる方法例を示す流れ図。
【図１８】本発明に従った、ドメイン例内の新−旧−新経路設定方式処理シーケンスの具体例を示す図。
【図１９】本発明に従った、ルーティングテーブルを有するドメインルータの実施例を示すブロック図。
【図２０】モバイルデバイスのホームエージェントからモバイルデバイスの外部エージェント宛にＩＰパケットをトンネルさせるために用いられる、従来技術に係るモバイルＩＰ標準方法を示す模式図。
【図２１】本発明に従ったトンネリング最適化を示すブロック図。
【図２２】従来技術に係る、パケットのモバイルＩＰトンネリングに係るＴＣＰダンプトレースを示す図。
【図２３】本発明に従ったトンネリング最適化法式を用いる、ホームエージェントから外部エージェントへのパケット伝達に係るＴＣＰダンプトレースを示す図。
【図２４】本発明に従った、ホームエージェントに対するホストとして機能しているノードにおけるトンネリング最適化を実現する手続き例を示す流れ図。
【図２５】本発明に従った、対応するモバイルデバイスと共存している外部エージェントにおけるトンネリング最適化を実現する手続き例を示す流れ図。
【符号の説明】
１００ インターネット
１１０ 通信ノード
１１２ サービスプロバイダ
１１４ モバイルデバイス
１１６ サービスプロバイダ
１１８ ホームエージェント
１５０ ドメインルートルータ
１５２ ホームエージェント
２６０ ドメインルータ
２６２ 入力ポート
２６４ 出力ポート
２６６ プロセッサ
２６８ メモリ
２７０ ホームエージェント
２７２ ＤＨＣＰサーバ
３００ 構成要素
３１０ メッセージタイプ
３１２ シーケンスナンバー
３１４ モバイルＩＰアドレス
３１６ ソースＩＰアドレス
３１８ デスティネーションＩＰアドレス
３２０ メトリックフィールド
３６０ ドメインルートルータ
３６２ インターネット
５８０ ルータ
５８２ 入力ポート
５８４ 出力ポート
５８６ プロセッサ
５８８ メモリ
５９０ ルーティングテーブル
６００ 通信ノード
６０２ ホームエージェント
６０４ ルータ
６０６ 基地局
６０８ モバイルデバイス
６１０ 外部エージェント
６１２ ＩＰパケット
６１４ ＩＰヘッダソースアドレス
６１６ ＩＰヘッダデスティネーションアドレス
６１８ データペイロード
６２０ ＩＰパケット
６２２ 付加されたＩＰヘッダソースアドレス
６２４ 付加されたＩＰヘッダデスティネーションアドレス
６２６ 元のＩＰヘッダソースアドレス
６２８ 元のＩＰヘッダデスティネーションアドレス
６４０ ＩＰパケット
６４２ ＩＰヘッダソースアドレス
６４４ ＩＰヘッダデスティネーションアドレス

Claims (5)

1. 外部エージェントを有するワイヤレスデバイスへ、パケットベースネットワークを介してパケットを分配する方法において、
   （Ａ）前記無線デバイスに対応するホームエージェントに、前記無線デバイスの外部エージェントアドレスを提供するステップ、
   前記無線デバイスは、ホームアドレスを有し、
   （Ｂ）前記ホームエージェントで、ホームアドレスをパケットのヘッダデスティネーションアドレスとして有するパケットを受信するステップ、
   （Ｃ）前記ホームアドレスを、前記パケットのパケットヘッダデスティネーションアドレスとして外部エージェントアドレスで置換するステップ、
   （Ｄ）前記ホームエージェントから、前記パケットヘッダデスティネーションアドレスに、前記パケットを転送するステップ、及び
   （Ｅ）トンネリングの最適化がパケットとして実行されるようなパケットとして、前記パケットを特定するために、ヘッダフィールドが前記パケット内に含まれるよう設定するステップであって、前記パケットヘッダは置換後実質的に同じサイズであるステップ
   を有することを特徴とする無線デバイスにパケットを分配する方法。
2. 前記外部エージェントは、前記無線デバイスと共通場所にある
   ことを特徴とする請求項１記載の方法。
3. 前記外部エージェントのアドレスは、前記無線デバイスに対応するドメインベースの気付アドレスである
   ことを特徴とする請求項２記載の方法。
4. （Ｆ）前記パケットを、前記外部エージェントで受信するステップ、
   （Ｇ）前記外部エージェントアドレスを、前記パケット用のパケットヘッダデスティネーションアドレスとして、前記ホームアドレスで置換するステップ、
   （Ｈ）前記パケットを、前記無線デバイスに転送するステップ
   をさらに有することを特徴とする請求項１記載の方法。
5. 共通場所に配置された、外部エージェントを有する無線デバイスにパケットを分配する方法において、
   （Ａ）パケットを、外部エージェントアドレスをパケットヘッダデスティネーションアドレスとして有する、外部エージェントで受信するステップ、
   （Ｂ）前記パケット内に組み込まれた、保存フラグメントフラグ（Reserved Fragment Flag ）が設定されているか否かを決定するステップ、
   （Ｃ）前記保存フラグメントフラグが設定されている場合、トンネリング最適化技術を用いて、前記パケットが処理されていることを決定するステップ、
   （Ｄ）前記パケットが、前記トンネリング最適化技術を用いて処理されている場合に、前記パケット用のパケットヘッダデスティネーションアドレスとし、前記外部エージェントアドレスを無線デバイスアドレスで置換するステップ、
   （Ｅ）前記ワイヤレスデバイスのアドレスに、前記パケットを転送するステップ、及び
   （Ｆ）トンネリングの最適化がパケットとして実行されるようなパケットとして、前記パケットを特定するために、ヘッダフィールドが前記パケット内に含まれるよう設定するステップであって、前記パケットヘッダは置換後実質的に同じサイズであるステップ
   を有することを特徴とする無線デバイスへパケットを分配する方法。

Images