JP2005522967A - 無線通信システム要素間に互換性を与えるための方法および装置 - Google Patents

Abstract

モバイルインターネットプロトコル通信を支援する通信システムにおいて、システム要素間に互換性がないことを解決するために方法および装置。この方法は、同じプロトコルの異なるバージョンまたは異なるプロトコル、あるいはこの両者をもつシステム要素間に、順方向および逆方向の両者の互換性を与える。１つの実施形態では、方法は、システム要素間の呼登録拡張数を適合させる。

Description

本発明は、概ね、無線通信システムに関し、とくに、パケットデータサービスのハンドオフのための方法および装置に関する。

モバイルインターネットプロトコル（Internet Protocol, IP）は、ノードが、１つのＩＰサブネットから別のＩＰサブネットへ、一方のイーサネット（登録商標）セグメントから別のイーサネットセグメントへ、およびイーサネットセグメントから無線ＬＡＮへ移動できるようにするためのものである。その目的は、移動ノード（Mobile Node, MN）のＩＰアドレスが、所与の移動において同じままにすることである。ノードが、異なるＩＰサブネットの接続点間を移動しない限り、リンク層移動機構（すなわち、リンク層のハンドオフ）の方が、モバイルＩＰよりも、収束はより迅速であり、オーバヘッドはより小さい。異なるプロトコルと、このようなプロトコルの種々の改訂との間に互換性を与えることに問題がある。とくに、新しいプロトコルを採用すると、前改訂とプロトコルとが一致しないことがある。

したがって、異なる無線通信とデータ転送プロトコルとの間に互換性が必要である。とくに、モバイルＩＰプロトコルのための逆方向および順方向の互換性のあるインターフェイスが必要である。

ここでは、“例示的”という用語は、“例、実例、または例示としての役割を果たす”ことを意味するためにのみ使用されている。ここに“例示的”として記載されている実施形態、実行、または応用は、必ずしも、他の実施形態、実行、または応用よりも好ましい、または効果的であると解釈されるとは限らない。図面には、実施形態の種々の態様が提示されているが、とくに指示されていないならば、図面は、必ずしもある縮尺にする必要はない。

次に続く記述では、最初に、移動ノードとデータを通信するためのモバイルＩＰを実行するネットワークを提示することによって、例示的な実施形態を展開する。その後で、スペクトラム拡散無線通信システムを記載する。次に、無線通信システムにおいて実行されるモバイルＩＰネットワークを示す。移動ノードをホームエージェントに登録し、ＩＰデータを移動ノードと送受信できるようにするメッセージを示す。最後に、ホームエージェントにおいて資源を再使用する方法を記載する。

本明細書全体に、例示的な実施形態が例として与えられているが、本発明の技術的範囲から逸脱しないならば、別の実施形態は、種々の態様を採用してもよいことに注意すべきである。とくに、種々の実施形態は、データ処理システム、無線通信システム、モバイルＩＰネットワーク、および資源を効率的に使用し、管理することが求められる他のシステムに応用可能である。

例示的な実施形態は、スペクトラム拡散無線通信システムを採用している。無線通信システムは、音声、データ、等のような種々のタイプの通信を供給するように広く展開されている。これらのシステムは、符号分割多元接続（Code Division-Multiple Access, CDMA）、時分割多元接続（Time Division Multiple Access, TDMA）、または他の変調技術に基づく。ＣＤＭＡシステムは、他のタイプのシステムよりも、システム容量が増加したことを含めて、ある特定の長所を備えている。

システムは、次に示すような１つ以上の標準規格を支援するように設計されている。標準規格には、例えば、“TIA/EIA-95 Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System”(ここでは、IS-95標準規格と呼ばれる)；“第三世代パートナーシッププロジェクト（3rd Generation Partnership Project）”（ここでは、３ＧＰＰと呼ばれる）という名称の協会によって提案され、かつ文献番号第3G TS 25.211号、第3G TS 25.212号、第3G TS 25.213号、第3G TS 25.214号、第3G TS 25.302号を含む１組の文献に具現されている標準規格（ここでは、W-CDMA標準規格と呼ばれる）；“第三世代パートナーシッププロジェクト ２（3rd Generation Partnership Project 2）”（ここでは、3GPP2と呼ばれる）という名称の協会によって提案された標準規格；およびここではcdma2000標準規格と呼ばれ、正式には、IS-2000 MCと呼ばれるTR-45.5がある。上述で引用した標準規格は、ここでは、参考として取り上げていることは明らかである。

各標準規格は、とくに、基地局から移動局へ、および移動局から基地局へ伝送されるデータの処理を定めている。例示的な実施形態として、以下に続く記述では、CDMA2000標準規格のプロトコルに準拠するスペクトラム拡散通信システムについて検討する。他の実施形態は、別の標準規格を採用してもよい。

図１には、１つの実施形態にしたがう通信システム100が示されている。通信システム100は、無線部分およびインターネットプロトコル（ＩＰ）部分の両者を含む。システム100の種々の要素を記載するのに使用した用語は、ここに記載されているモバイルＩＰの理解を容易にするためのものである。移動ノード（ＭＮ）のホームネットワーク102は、ホームエージェント（Home Agent, HA）104と、ホームエージェントの認証、管理、および会計（Home Agent Authentication, Administration, and Accounting, HAAA）装置106とを含む。認証は、例えば、暗号技術を使用することによって、メッセージの発信者を識別する確認処理であることに注意すべきである。

ホームネットワーク102は、ＩＰホスト108と通信する。既に記載したように、ＭＮ116は、外部システム110に移動する。外部システム110は、パケットデータサービスノード（Packet Data Service Node, PDSN）112および外部エージェント（Foreign Agent, FA）114を含む。

ＭＮ116のようなＭＮは、一方から他方のネットワークまたはサブネットワークへの接続点を変更するホストまたはルータである。ＭＮは、そのＩＰアドレスを変更することなく、その位置を変更でき、接続点へのリンク層接続が使用可能であると仮定すると、他のインターネットノードと、任意の位置において、その（不変の）ＩＰアドレスを使用して、通信を続けることができる。

ＨＡは、ＭＮホームネットワーク上のルータであり、ＭＮがホームから離れたときに、ＭＮへ伝送するためのデータグラムをトンネルを通し、ＭＮの現在の位置情報を維持する。ＦＡは、ＭＮが訪問するネットワーク上のルータであり、ＭＮを登録する一方で、ＭＮへルーティングサービスを供給する。ＦＡは、ＭＮのホームエージェントがトンネルを通したＭＮへのデータグラムをトンネルを通さなかったり、伝送したりする。ＭＮによって送られたデータグラムについて、ＦＡは、登録したＭＮのためのデフォルトのルータとしての役割を果たす。

ＭＮ116は、ホームネットワーク102上の長期間のＩＰアドレスを与えられる。このホームアドレス、すなわちＭＮのＩＰアドレスは、静止ホストへ与えられる“永久”ＩＰアドレスと同じやり方で管理される。ＭＮ116は、ホームネットワーク102から離れると、ＭＮの現在の接続点を反映する“気付アドレス”と関係付けられる。気付アドレスは、トンネルの終端部のＩＰアドレスである。ＭＮ116は、ＭＮ116から送られたＩＰデータグラムのソースアドレスとして、ホームアドレスを使用する。

ホームネットワーク102のようなホームネットワークは、恐らくはバーチャルのネットワークであって、ＭＮのホームアドレスに整合させたネットワークプレフィックスを有する。標準のＩＰルーティング機構は、ＭＮのホームアドレスに宛てられたデータグラムを、移動ノードのホームネットワークへ伝送することに注意すべきである。外部ネットワークは、ホームネットワーク以外のネットワークである。これらの条件はＭＮごとであることに注意すべきである。

ホームから離れているとき、モバイルＩＰは、プロトコルのトンネリングを使用して、ホームネットワークとその現在の位置との間にルータを介在させることにより、ＭＮのホームアドレスを隠す。トンネルは、ＭＮの気付アドレスにおいて終端する。気付アドレスは、従来のＩＰルーティングによって伝送できるデータグラムのアドレスでなければならない。気付アドレスにおいて、元のデータグラムをトンネルから取去って、ＭＮへ伝送する。

トンネルは、カプセル化されたデータグラムが通る経路である。モデルとして、データグラムは、カプセル化される一方で、認識可能なデカプセル化エージェントへルート設定され、デカプセル化され、最終的な宛先へ正しく伝送される。
ＭＮ116へのデータグラムは、経路ａ上でＩＰホスト108からホームネットワーク102へ供給される。データグラムは、標準ＩＰルーティング技術を使用して送られる。データグラムは、ＨＡ104によって受信され、インターセプトされ、気付アドレスへトンネルを通される。ＨＡ104は、トンネルを通されたデータグラムを、経路ｃを経由して、外部ネットワーク110へ送る。ＦＡ114は、ＭＮ116へ伝送するためのデータグラムをトンネルを通さなくする。ＦＡ114は、データグラムを、経路ｅを経由して、ＭＮ116へ送る。

ＭＮ116からのデータグラムは、外部ネットワーク110と通信する一方で、標準ＩＰルーティング技術によって、外部ネットワーク110からＩＰホスト108へ送られる。ＭＮ116は、動作を分かり易くするために、外部ネットワーク110の外に示されているが、外部ネットワーク110によってサービスされる地理的領域または仮想領域において動作することに注意すべきである。

既に記載したように、システム100の動作は、RFC 2002（“IP Mobility Support”、C. Perkins監修、1996年10月）およびRFC 3220（“IP Mobility Support for IPv4”、C. Perkins監修、2002年1月）によって指定された動作にしたがう。これらの文献の両者は、Internet Engineering Task Force(IETF)によって公布されている。

RFC 3220には、種々の相違が示され、したがって、所与のシステム間の潜在的な不一致と、所与のシステムの種々の改訂間の互換性の問題とが生じた。これらの相違は、とくに、無線通信とモバイルＩＰとに関係する互換性の問題の例として示されるが、この記載に関係して、種々の他の相違および互換性がないものについて検討する。

元の仕様
RFC 2002に特定されているように、モバイルＩＰ登録は、ＭＮが現在の到達可能情報をＨＡへ通信するための順応性のある機構を与える。これは、ＭＮが、外部ネットワークを訪れたときに、順方向サービスを要求し；ＨＡに現在の気付アドレスを知らせ；期限が切れるか、またはホームへ戻って再登録するか、あるいはこの両者のために、登録を更新する方法である。登録メッセージの情報をＭＮ、（オプションで）ＦＡ、およびＨＡ間で交換する。登録は、ＨＡにおいて移動バインディングを生成または変更し、特定の寿命の間、ＭＮのホームアドレスと、ＭＮの現在の気付アドレスとを対応付ける。

登録手続きによって、いくつかの他の（オプションの）能力を得ることができ、移動ノードが多数の同期登録を維持できると、各データグラムのコピーを、各アクティブな気付アドレスへトンネルを通し、特定の気付アドレスを再登録し、一方で他の移動バインディングを保持し、ＭＮがこの情報を用いて構成されないときは、ＨＡのアドレスを発見する。モバイルＩＰは、２つの異なる登録手続きを定めている。一方は、ＦＡを中断して、ＭＮのＨＡへ登録する手続きであり、他方は、ＭＮのＨＡに直接に登録する手続きである。次の規則は、個々の環境において、これらの２つの登録手続きのいずれを使用するかを決める。移動ノードがＦＡの気付アドレスを登録しているときは、ＭＮは、そのＦＡを経由して登録しなければならない。ＭＮが、同じ位置の気付アドレスを使用し、かつＭＮがこの気付アドレスを使用しているリンク上で、ＦＡからエージェント広告を受信するとき、受信したエージェント広告メッセージ内に‘Ｒ’ビットが設定されている場合は、そのＦＡ（または、このリンク上の別のＦＡ）を経由して登録すべきである。さもなければ、ＭＮが、同じ位置の気付アドレスを使用しているときは、ＭＮは、そのＨＡに直接に登録しなければならない。ＭＮが、そのホームネットワークへ戻っていて、ＨＡに登録（登録解除）しているときは、ＭＮは、そのＨＡに直接に登録しなければならない。両者の登録手続きは、登録要求（Registration ReQuest, RRQ）メッセージと登録応答（Registration RePly, RRP）メッセージとの交換を含む。ＦＡを経由して登録するときは、登録手続きには、次の４つのメッセージが必要である。
ａ）ＭＮは、ＲＲＱを予定のＦＡへ送り、登録処理を開始する。
ｂ）ＦＡは、ＲＲＱを処理し、それをＨＡへ中継する。
ｃ）ＨＡは、要求、すなわちＲＲＱを承認または否認するためのＲＲＰをＦＡへ送る。
ｄ）ＦＡは、ＲＲＰを処理し、それをＭＮへ中継して、その要求の処置についてＭＮに知らせる。

その代りに、ＭＮがＨＡに直接に登録するときは、登録手続きは、次の２つのメッセージのみが必要である。
ａ）移動ノードは、登録要求をホームエージェントへ送る。
ｂ）ホームエージェントは、登録応答を移動ノードへ送って、要求を承認または否認する。

登録メッセージは、ユーザデータグラムプロトコル（User Datagram Protocol, UDP）を使用する。ゼロ以外のＵＤＰのチェックサムを、ヘッダに含めるべきであり、受信者はそれを検査しなければならない。
各ＭＮ、ＦＡ、およびＨＡは、セキュリティパラメータ指標（Security Parameter Index, SPI）およびＩＰアドレスによって示される移動エンティティの移動セキュリティアソシエーションを支援できなければならない。ＭＮの場合は、これは、そのホームアドレスでなければならない。ＭＮとＨＡとの間の登録メッセージは、移動ノード−ホーム認証拡張（Mobile Node-Home Authentication Extension, MN-HA Authentication Extension）で認証されなければならない。ＭＮ−ＨＡ認証拡張は、ＦＡ専用の拡張を除いて、全非認証拡張の直後に続き、ＦＡ専用の拡張は、ＭＮが認証を計算した後で、メッセージに加えられる。

ＭＮは、ＲＲＱメッセージを使用して、ＨＡに登録するので、ＨＡは、（例えば、新しい寿命について）そのＭＮの移動バインディングを生成または変更することができる。ＲＲＱ要求は、ＭＮが登録しているＦＡが、ＨＡへ中継するか、またはＭＮが同じ位置の気付アドレスを登録している場合は、ＨＡに直接に送られる。

ＲＲＱの既定部分の後には、拡張の１つ以上が続く。ＭＮ−ＨＡ認証拡張は、全ＲＲＱ要求内に含まれていなければならない。移動エージェントは、ＲＲＱメッセージを送ったＭＮへ、ＲＲＰメッセージを返す。ＭＮがＦＡからサービスを要求しているときは、このＦＡは、ＨＡからＲＲＰを受信し、その後で、それをＭＮへ中継する。ＲＲＰメッセージは、ＨＡによって承認された寿命について、ＲＲＱ要求の状態に関してＭＮに知らせるための必要コードを含む。必要コードは、元のＲＲＱ要求よりも小さい。

全てのＲＲＱ要求およびＲＲＰ応答内には、１つのみのＭＮ−ＨＡ認証拡張が存在しなければならず、その結果、インターネットにおける遠隔転送の無制御の伝搬により生じる問題を解消する。拡張の位置は、認証されたデータの最後を示す。さらに加えて、ＦＡによって使用される非認証拡張、ＭＮ−ＦＡ認証拡張、および／またはＭＮ−ＡＡＡ認証拡張のような追加の拡張が支援される。ＭＮは、モバイルＩＰ登録中にＰＤＳＮおよびＦＡへのＲＲＱメッセージ内に、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含む必要があることに注意すべきである。ＭＮ−ＡＡＡ認証拡張は、RFC 3012に特定されている。IS-835-Aとして識別される標準規格のような、IS-95以前のいくつかの標準規格および標準規格バージョンには要件があることに注意すべきである。これは、移動局が両方の認証拡張を送ることも許している。IS-835-A標準規格バージョンは、IS-835-B標準規格バージョンよりも制限的であり、移動局は両方の認証拡張を送らなければならない。さらに加えて、ＰＤＳＮおよびＦＡは、ＨＡへ送られるＲＲＱメッセージ内に両方の拡張を含まなければならない。

改訂された仕様
RFC 2002の仕様とは対照的に、RFC 3220は、ＰＤＳＮおよびＦＡが、１つのみの認証拡張、とくにＭＮ−ＨＡ認証拡張を送ることを指定している。各ＭＮ、ＦＡ、およびＨＡは、ＳＰＩおよびＩＰアドレスによって示されている移動エンティティの移動セキュリティアソシエーションを支援できなければならない。ＭＮの場合に、これは、そのホームアドレスでなければならない。ＭＮとＨＡとの間の登録メッセージは、ＭＮ−ＨＡ認証拡張のような、“認証許可拡張”で認証されなければならない。この拡張は、第１の認証拡張でなければならず、移動ノードが認証を計算した後で、他の外部エージェント専用の拡張をメッセージに加えてもよい。

認証許可拡張は、登録メッセージの最終の受信において（登録）メッセージをを受領できるようにする認証である。認証許可拡張は、ＳＰＩを含まなければならない。RFC 3220に使用されているように、認証許可拡張は、ホームエージェントが認証要求メッセージを受領できるようにする認証拡張を指す。追加のプロトコルを使用して、ＭＮは、ＨＡが受領できる、ネットワーク内の別の認証エンティティによって、ＨＡに、登録の認証を与えることができる。

ＭＮは、ＲＲＱメッセージを使用してＨＡに登録し、ＨＡは、（例えば、新しい寿命について）そのＭＮの移動バインディングを生成または登録することができる。ＲＲＱは、ＭＮが登録しているＦＡを中継して、ＨＡへ送られるか、またはＭＮが、同じ位置の気付アドレスに登録している場合は、ＨＡに直接に送られる。

１つのみの認証許可拡張は、全ＲＲＱ内、およびＨＡによって生成された全てのＲＲＰ内にも存在していなければならない。ＭＮ−ＨＡ認証拡張は、登録メッセージの認証許可である。この要件は、インターネットにおける遠隔転送の無制御の伝搬によって生じる問題を解消するためのものである。拡張の位置は、認証されるデータの最後を示す。

RFC 3220に特定されているように、ＨＡは、認証拡張、すなわち認証許可拡張を２つ以上受信すると、ＭＮの登録要求を否認し、ＲＲＰを指定されたエラーコードと共に、ＦＡ／ＰＤＳＮを経由して、ＭＮへ送る。１つの実施形態において、エラーコードは、１３１として識別され、ＭＮが認証に失敗したことを示す。

現在の解決案
元の仕様、すなわち、RFC 2002との後方互換性を維持するために、3GPP2のTSG-Pは、次の方法を支援する。最初の登録において、ＭＳは、ＭＮ−ＨＡおよびＭＮ−ＡＡＡ認証拡張を含む。前のバージョンとの後方互換性を支援するために、認証許可拡張を取去ることができるかどうかを示す3GPP2の“認証許可拡張”属性をホームＡＡＡ（ＲＡＤＩＵＳ）サーバからＰＤＳＮへ加える。

ＰＤＳＮは、次に示すように、認証拡張を処理する。ＰＤＳＮは、ホームＡＡＡ（ＲＡＤＩＵＳ）サーバから、3GPP2の“認証許可拡張”属性を受信すると、ＭＮ−ＨＡの認証拡張の後の認証を取去らない。属性は、IS-835-Bの最近のバロット解決バージョンに記載されていることに注意すべきである。属性は、別途記載する。さらに加えて、ＲＡＤＩＵＳサーバは、ＲＡＤＩＵＳプロトコルを使用するＡＡＡサーバであることに注意すべきである。このシナリオは、図２に示されている。ＰＤＳＮが属性を受信しないときは、モバイルＩＰのRFC 3220によって指定されているように、ＲＲＱをＨＡへ送る前に、ＡＡＡインフラストラクチャによって移動ノードの認証を完了した後で、ＲＲＱから、ＭＮ−ＡＡＡ認証拡張を取去る。

図２は、システム100内の処理を示し、水平軸上に、システム要素を表わし、垂直軸上に、時間を表わしている。時間ｔ１において、ＭＮ116は、ＲＲＱ（１）として識別されるＲＲＱを送る。ＲＲＱ（１）は、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含む。ＰＤＳＮ112またはＦＡ114、あるいはこの両者は、ＲＲＱ（１）を受信し、応答して、時間ｔ２において、アクセス要求メッセージをＨＡＡＡ106へ送る。時間ｔ３において、ＨＡＡＡ106はアクセス受領メッセージで応答する。アクセス受領メッセージは認証許可拡張を含む。時間ｔ４において、ＰＤＳＮ112またはＦＡ114、あるいはこの両者は、ＲＲＱ（２）として識別されるＲＲＱをＨＡ104へ送る。時間ｔ５において、ＨＡ104は、ＲＲＰ（１）として識別されるＲＲＰメッセージで応答する。時間ｔ６において、ＰＤＳＮ112またはＦＡ114、あるいはこの両者は、ＲＲＰ（２）として識別されるＲＲＰメッセージで応答する。

図３は、決定処理のための処理120を示す。決定ダイヤモンド122において、認証許可拡張属性を受信すると、処理は、続いてステップ126へ進み、追加の拡張を処理する。属性が受信されないときは、処理は、続いてステップ124へ進み、追加の拡張を取去る。両方の処理経路は、続いてステップ128の登録処理へ進む。

図２および３の解決案は、システム要素の能力によって、他の問題を提示する。次の表には、種々のシナリオが記載されている。システム要素に関して、一般に、IS-835-AはRFC 2002に準拠し、IS-835-BはRFC 3220に準拠することを意図されている。これらの標準規格およびバージョンは、システム構成の例として与えられていることに注意すべきである。別の実施形態は、種々の標準規格、バージョン、システムの構成要素、および構成の何れかを含んでもよい。

一般に、ＨＡおよびＨＡＡＡは、同じ搬送波領域内にあり、ＨＡＡＡは、ＨＡのバージョンを知っているか、またはアクセスする。したがって、後方互換性および前方互換性の両者において、ＨＡＡＡが“認証許可拡張”属性を送る代わりに、ＨＡのバージョンを、ＦＡ／ＰＤＳＮに示すことができるのが望ましい。さらに加えて、ＨＡＡＡが、ＨＡのバージョンを知らないとき、またはＦＡ／ＰＤＳＮがこの新しい属性を受信しないときは、両者の認証拡張は、ＦＡ／ＰＤＳＮからＨＡへ送られる。

図４は、ＨＡのバージョン情報を供給するシナリオを示している。垂直軸に、時間を表わし、水平軸に、システム要素を表わしている。最初の登録において、ＭＳは、時間ｔ１において、ＲＲＱ（１）として識別されるＲＲＱメッセージ内にＭＮ−ＨＡおよびＭＮ−ＡＡＡの認証拡張を含めて、ＦＡまたはＰＤＳＮ、あるいはこの両者へ送る。時間ｔ２において、ＦＡまたはＰＤＳＮ、あるいはこの両者は、ＨＡＡＡへアクセス要求を送る。時間ｔ３において、前のバージョンとの後方互換性を支援するために、ＨＡＡＡは、ＦＡまたはＰＤＳＮ、あるいはこの両者にアクセスすることによって、アクセス要求に応答する。アクセス要求は、ＨＡバージョンを識別する。１つの実施形態において、ＨＡＡＡは、3GPP2の“ＨＡバージョン識別”属性にしたがうバージョン識別子を送る。属性情報は、RFC 2002またはRFC 3220に関係するＨＡのバージョンを示す。別途記載される属性情報を参照してください。１つの実施形態では、RFC2002のＨＡは、IS-835-Aに相当し、RFC3220のＨＡはIS-835-Bに相当する。

リリースＢの（すなわち、RFC 3220を支援する）ＰＤＳＮは、図５のフローチャートに示されているように、認証拡張を処理する。処理200は、決定ダイヤモンド202から始まり、上述の属性のような、ＨＡバージョン識別をＨＡＡＡから受信したかどうかを判断する。バージョン識別は、図４に示されているアクセス受領メッセージに含まれている。ＨＡバージョン識別を受信すると、処理は、続いて決定ダイヤモンド204へ進む。バージョン識別が受信されないときは、処理は、続いてステップ212へ進み、ＭＮからのＲＲＱメッセージ内に含まれている追加の拡張を保持する。決定ダイヤモンド204から、バージョン識別が、ＨＡがRFC 3220バージョン（バージョン２）を支援している、すなわち、ＨＡがRFC 3220に準拠していることを示すと、ステップ206において、ＰＤＳＮは、ＭＮ−ＡＡＡ認証拡張のような追加の拡張を取去る。ＭＮがＲＲＱをＨＡへ送るときは、モバイルＩＰのRFC 3220によって指定されているように、ＲＲＱをＨＡへ送る前に、ＡＡＡインフラストラクチャによってＭＮの認証を完了した後で、追加の拡張をＲＲＱから取去ることに注意すべきである。ＰＤＳＮがＲＲＱメッセージをＨＡへ送るときは、モバイルＩＰのRFC 3220によって特定されているように、ＡＡＡインフラストラクチャによってＭＮの認証を完了した後で、追加の拡張をＲＲＱメッセージから取去ることに注意すべきである。

決定ダイヤモンド204へ戻って、ＰＤＳＮが、ＨＡがRFC 2002（バージョン１）に準拠していることを示すバージョン識別（例えば、3GPP2の“ＨＡバージョン識別”）属性を、ＨＡＡＡサーバから受信すると、ＭＮ−ＨＡ認証拡張の後で、ステップ208において、追加の拡張を保持する。同様に、ＰＤＳＮが、ＨＡのバージョンが分かっていないことを示すバージョン識別（例えば、3GPP2の“ＨＡバージョン識別”）属性を、ＨＡＡＡサーバから受信すると、ステップ208において、ＭＮ−ＨＡの認証拡張後の任意の拡張を保持する。

“認証−許可拡張”に加えて、またはその代わりに、“ＨＡバージョン識別”属性のようなバージョン識別を使用して、前方互換性を得て、将来のＨＡバージョンを現在のＨＡバージョンと区別する。例えば、将来のＦＡおよびＨＡは、モバイルＩＰ登録取消[draft-ietf-mobileip-reg-revok-02.txt]を支援する。“ＨＡバージョン識別”属性によって、取消しに対応するＦＡは、取消しを支援しないＨＡへ、取消しメッセージを送るのを避ける。

図４および５に示されている方法は、ＦＡおよび／またはＰＤＳＮと、ＨＡＡＡとが、RFC 3220のような新しいバージョン（バージョン２）を支援し、一方で、ＨＡが、RFC 2002のような前のバージョン（バージョン１）を支援するときの解決案を与える。しかしながら、ＦＡまたはＰＤＳＮ、あるいはこの両者が新しいバージョン（バージョン２）を支援し、ＨＡＡＡが古いバージョン（バージョン１）を支援し、かつＨＡが新しいバージョン（バージョン２）を支援するときは、問題は解消されない。この構成において、ＨＡＡＡは、新しい属性、すなわちバージョン識別を支援せず、したがってＦＡまたはＰＤＳＮ、あるいはこの両者は、両方の拡張をＨＡへ送る。この問題、並びにハードウエアおよびソフトウエアの改訂が異なっている構成によって生じる他の問題を避けるために、他の実施形態を提示する。

図６は、１つの実施形態を示し、次に詳細に記載する。
ａ）ＭＳは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＦＡ／ＰＤＳＮへ送る。
ｂ）ＦＡ／ＰＤＳＮは、アクセス要求メッセージをＨＡＡＡへ送る。
ｃ）ＨＡＡＡは、アクセス受領で応答する。この例では、ＨＡＡＡは、RFC 2002を支援しているので、新しい属性“ＨＡバージョン指標”をどのように処理するかを知らない。
ｄ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＨＡへ送る。
ｅ）ＨＡは、RFC 3220に準拠しているので、ＲＲＰを、ＭＮが認証に失敗したことを示すエラーコード１３１のようなエラーコードと共に、ＦＡ／ＰＤＳＮへ送る。
ｆ）ＦＡ／ＰＤＳＮは、ＲＲＰを見て、エラーコード１３１を検出し、ＭＮ−ＨＡ認証拡張のみを含む別のＲＲＱを、ＨＡへ送る。
ｇ）ＨＡは、ＲＲＰをＦＡ／ＰＤＳＮへ送る。
ｈ）ＦＡ／ＰＤＳＮは、ＲＲＰをＭＳへ送る。

この実施形態では、ＦＡは、エラーコードと共にＲＲＱを受信すると、ＭＮ−ＡＡＡ認証拡張が削除されたＲＲＱを再送する。しかしながら、ＭＮは、ＲＲＱを１回のみ送ればよく、エアーリソースが節約される。
図７は、別の実施形態を示し、次に詳細に記載する。
ａ）ＭＮは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＦＡ／ＰＤＳＮへ送る。
ｂ）ＦＡ／ＰＤＳＮは、アクセス要求をＨＡＡＡへ送る。
ｃ）ＨＡＡＡは、アクセス受領メッセージで応答する。この例では、ＨＡＡＡは、RFC 2002を支援しているので、新しい属性“ＨＡバージョン指標”を支援しない。
ｄ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＨＡへ送る。
ｅ）ＨＡは、RFC 3320を支援しているので、ＲＲＰは、１つの拡張のみを許可することを示す値に設定された新しいエラーコードと共に送られる。ＲＲＰは、ＦＡ／ＰＤＳＮへ送られる。
ｆ）ＦＡ／ＰＤＳＮは、新しいエラーコードを受信すると、ＭＮ−ＨＡ認証拡張のみを含む別のＲＲＱをＨＡへ送る。
ｇ）ＨＡは、ＲＲＰをＦＡ／ＰＤＳＮへ送る。
ｈ）ＦＡ／ＰＤＳＮは、ＲＲＰをＭＳへ送る。

新しいエラーコードを支援するＨＡおよびＦＡは、RFC 3220に準拠していないことに注意すべきである。RFC 3220へ変更すると、このような実施形態が可能になる。しかしながら、ＭＮは、ＲＲＱを１回のみ送ればよく、エアーリソースが節約されることになる。

図８は、さらに別の実施形態を示し、次に詳細に記載する。ＭＮは、登録を再び試みるのに、認証に失敗したことを知る必要がある。
ａ）ＭＳは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＦＡ／ＰＤＳＮへ送る。
ｂ）ＦＡ／ＰＤＳＮは、アクセス要求をＨＡＡＡへ送る。
ｃ）ＨＡＡＡは、アクセス受領で応答する。この例では、ＨＡＡＡは、IS-835-Aに準拠しているので、新しい属性“ＨＡバージョン指標”を支援しない。
ｄ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＨＡへ送る。
ｅ）ＨＡは、RFC 3220に準拠しているので、ＲＲＰを、（移動ノードが認証に失敗したことを示す）１３１に設定されたエラーコードと共に、ＦＡ／ＰＤＳＮへ送る。
ｆ）ＦＡ／ＰＤＳＮは、エラーコードと共にＲＲＰをＭＳへ送り、対応するＭＳに関する認証失敗情報を記憶する。
ｇ）ＭＳは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＦＡ／ＰＤＳＮへ再送する。
ｈ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張のみを含むＲＲＱを、ＨＡへ送る。
ｉ）ＨＡは、ＲＲＰでＦＡ／ＰＤＳＮに応答する。
ｊ）ＦＡ／ＰＤＳＮは、ＲＲＰをＭＳへ送る。

ここでは、ＭＮは、ＲＲＱを再送すると、登録待ち時間が増すことになる。さらに加えて、図８の方法は、ＦＡの実行に複雑さを加え、ＭＮの失敗した認証の履歴を記録する。これは、ＭＮの実行にも若干の複雑さを加え、ＭＮは、エラーコード１３１のようなエラーコードと共にＲＲＰを受信すると、ＲＲＱを再送する。ＦＡおよびＨＡの動作は、RFC 3220の要件に準拠していることにも注意すべきである。

図９は、さらに別の実施形態を示し、次に詳細に記載する。
ａ）ＭＳは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＦＡ／ＰＤＳＮへ送る。
ｂ）ＦＡ／ＰＤＳＮは、アクセス要求をＨＡＡＡへ送る。
ｃ）ＨＡＡＡは、アクセス受領で応答する。この例では、ＨＡＡＡは、RFC 2002を支援しているので、新しい属性“ＨＡバージョン指標”を支援しない。
ｄ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張およびＭＮ−ＡＡＡ認証拡張の両者を含むＲＲＱを、ＨＡへ送る。
ｅ）ＨＡは、RFC 3320に準拠しているので、ＭＮが認証に失敗したことを示すエラーコード１３１のような、設定されたエラーコードと共にＲＲＰを、ＦＡ／ＰＤＳＮへ送る。
ｆ）ＦＡ／ＰＤＳＮは、エラーコードを含むＲＲＰをＭＳへ送る。
ｇ）ＭＳは、ＭＮ−ＨＡの認証拡張のみを含むＲＲＱを、ＦＡ／ＰＤＳＮへ再送する。
ｈ）ＦＡ／ＰＤＳＮは、ＭＮ−ＨＡ認証拡張のみを含むＲＲＱを、ＨＡへ送る。
ｉ）ＨＡは、ＲＲＰでＦＡ／ＰＤＳＮに応答する。
ｊ）ＦＡ／ＰＤＳＮは、ＲＲＰをＭＮへ送る。

この実施形態では、ＭＮは、ＲＲＱを再送すると、登録待ち時間が増す。さらに加えて、この実施形態には複雑さが加わって、ＭＮが、ＲＲＰをエラーコードと共に受信すると、ＭＮ−ＡＡＡ認証拡張を含まないＲＲＱを再送する。ＭＮは、RFC 3220に違反しないが、無線標準規格に違反することがある。ＦＡおよびＨＡの動作も、RFC 3220に準拠している。

認証許可拡張
認証許可拡張属性は、ＲＲＱメッセージをＨＡへ中継する前に、ＦＡの必要動作を示すことに注意すべきである。これは、ＲＡＤＩＵＳアクセス受領メッセージにオプションで現れる。この属性は、標準規格の前のバージョンとの後方互換性を支援する。この属性は、次のリリースにおいて不要になるものである。互換性の問題がないときは、この属性は不要である。

ＨＡバージョン指標
ＨＡのバージョンを示す。これは、ＲＡＤＩＵＳアクセス受領メッセージにオプションで示される。この属性は、この標準規格の前のバージョンとの後方互換性を支援する。互換性の問題がないときは、この属性は不要である。
以上の記述および実施形態は、登録拡張に関して、システム要素間に互換性がないことを示しているが、別の実施形態は、それ以外に互換性がないことを示してもよい。したがって、上述の実施形態は例としての役割を果たすが、本発明は、システム要素が、異なるプロトコルか、または同じプロトコルの異なるバージョンか、あるいはこの両者を支援するといった多数の状況に適用される。例えば、種々の互換性のないものを解決するのに、バージョン識別を使用してもよい。同様に、種々の実施形態は、多数のシステム要素間に互換性がないことを解決する役割を共用してもよい。

当業者には、情報および信号が、種々の異なる技術および技能を使用して表現されることが分かるであろう。例えば、上述で全体的に参照したデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁粒、光の界または粒子、あるいはその組み合わせによって表現される。

当業者には、ここに開示されている実施形態に関係して記載された種々の例示的な論理ブロック、モジュール、回路、およびアルゴリズムのステップが、電子ハードウエア、コンピュータソフトウエア、またはこの両者の組合せとして実行されることも分かるであろう。ハードウエアとソフトウエアとのこの互換性を明らかに示すために、種々の例示的な構成要素、ブロック、モジュール、回路、およびステップを、上述で全体的に機能に関して概ね記載した。このような機能が、ハードウエアとして実行されるか、またはソフトウエアとして実行されるかは、全体的なシステムに課された個々の応用および設計の制約に依存する。熟練した技能をもつ者は、各個々の応用ごとに種々のやり方で上述の機能を実行するが、このような実行の決定は、本発明の技術的範囲から逸脱すると解釈すべきではない。

ここに開示されている実施形態に関係して記載された種々の例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、ディジタル信号プロセッサ（digital signal processor, DSP）、特定用途向け集積回路（application specific integrated circuit, ASIC）、フィールドプログラマブルゲートアレイ（field programmable gate array, FPGA）または他のプログラマブル論理装置、ディスクリートなゲートまたはトランジスタ論理、ディスクリートなハードウエア構成要素、あるいはここに記載されている機能を実行するように設計された組合せで構成または実行される。汎用プロセッサは、マイクロプロセッサであってもよいが、その代わりに、プロセッサは、従来のプロセッサ、制御装置、マイクロ制御装置、または状態機械であってもよい。プロセッサは、計算機の組合せ、例えば、１つのＤＳＰと１つのマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、１つ以上のマイクロプロセッサと１つのＤＳＰのコアとの組み合わせ、または他のこのような構成としても実行される。

ここに開示されている実施形態に関係して記載された方法またはアルゴリズムのステップは、ハードウエアにおいて、プロセッサによって実行されるソフトウエアモジュールにおいて、または２つの組み合わせにおいて直接に具体化される。ソフトウエアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能ディスク、ＣＤ−ＲＯＭ、またはこの技術において知られている記憶媒体の他の形態の中にあってもよい。例示的な記憶媒体は、プロセッサに接続され、プロセッサは、記憶媒体から情報を読み出し、かつ記憶媒体へ情報を書き込んでもよい。その代りに、記憶媒体は、プロセッサと一体構成であってもよい。プロセッサおよび記憶媒体は、ＡＳＩＣの中にあってもよい。ＡＳＩＣは、ユーザ端末の中にあってもよい。その代りに、プロセッサおよび記憶媒体は、ディスクリートな構成要素として、ユーザ端末の中にあってもよい。

開示された実施形態についてのこれまでの記述は、当業者が本発明を作成または使用できるようにするために与えられている。当業者には、これらの実施形態に対する種々の変更は容易に明らかであり、ここに定められている一般的な原理は、本発明の意図および技術的範囲から逸脱しないならば、他の実施形態に適用してもよい。したがって、本発明は、ここに示された実施形態に制限されることを意図されず、ここに開示されている原理および新規な特徴に一致する最も幅広い範囲にしたがうことを意図されている。

モバイルＩＰを支援する通信システムのブロック図。 認証許可拡張を使用する通信システムにおける呼登録を示すタイミング図。 認証許可拡張を使用する呼登録処理のフローチャート。 バージョン識別メッセージを使用する通信システムにおける呼登録を示すタイミング図。 バージョン識別メッセージを支援する呼登録処理のフローチャート。 種々の呼登録処理を示すタイミング図。 種々の呼登録処理を示すタイミング図。 種々の呼登録処理を示すタイミング図。 種々の呼登録処理を示すタイミング図。

符号の説明

100・・・通信システム、102・・・ホームネットワーク、110・・・外部システム、ａ,ｂ,ｃ,ｄ,ｅ,ｆ・・・経路、120,200・・・処理、

Claims (20)

1. モバイルインターネットプロトコル通信を支援する通信システムにおける呼登録方法であって、
   ホームエージェントの能力を識別するホームエージェントのバージョン指標を受信することと、
   バージョン指標に応答して、多数の登録拡張が、ホームエージェントの能力にしたがうかどうかを判断することとを含む方法。
2. 多数の登録拡張をもつ登録要求メッセージを送ることをさらに含む請求項１記載の方法。
3. バージョン指標をホーム認証、管理、および会計装置から受信する請求項２記載の方法。
4. 最初の登録要求メッセージを移動ノードから受信する請求項２記載の方法。
5. 最初の登録要求メッセージが多数の登録拡張を含み、登録要求メッセージが１つの登録拡張を含む請求項３記載の方法。
6. バージョン指標が属性である請求項１記載の方法。
7. モバイルインターネットプロトコル通信を支援する通信システムにおける呼登録のための装置であって、
   ホームエージェントの能力を識別するホームエージェントのためのバージョン指標を受信するための手段と、
   バージョン指標に応答して、多数の登録拡張が、ホームエージェントの能力にしたがうかどうかを判断するための手段とを含む装置。
8. モバイルインターネットプロトコル通信を支援する通信システムにおける呼登録のための方法であって、
   登録要求メッセージをホームエージェントへ送ることと、
   ホームエージェントからエラーメッセージを受信することと、
   登録要求メッセージから追加の登録拡張を取去って、低減された登録要求メッセージを形成することと、
   低減された登録要求メッセージを送ることとを含む方法。
9. エラーメッセージが、移動ノードの認証に失敗したことを示す請求項８記載の方法。
10. エラーメッセージが、所定数の登録拡張が許可されることを示す請求項８記載の方法。
11. エラーメッセージが、登録応答メッセージ内に含まれている請求項８記載の方法。
12. モバイルインターネットプロトコル通信を支援する通信システムにおける呼登録のための方法であって、
    移動ノードから登録要求メッセージを受信することと、
    登録要求メッセージをホームエージェントへ送ることと、
    認証に失敗したことを示すエラーメッセージを、ホームエージェントから受信することと、
    エラーメッセージを移動ノードへ送ることと、
    移動ノードから第２の登録要求メッセージを受信することと、
    第２の登録要求メッセージをホームエージェントへ再送することとを含む方法。
13. 第２の登録要求メッセージが、登録要求メッセージと同じである請求項１２記載の方法。
14. 第２の登録要求メッセージが、登録要求メッセージと異なる請求項１２記載の方法。
15. 移動ノードが、登録要求メッセージから追加の登録拡張を取去り、第２の登録要求メッセージを生成する請求項１２記載の方法。
16. モバイルインターネットプロトコル通信を支援する通信システムにおける呼登録のための方法であって、
    ２つのシステム要素間に互換性がないと判断することと、
    ２つのシステム要素間で登録メッセージを適合させて、互換性を達成することと、
    適合された登録メッセージを送ることとを含む方法。
17. 互換性がないことが、許可された数の登録拡張である請求項１６記載の方法。
18. ２つのシステム要素の各々が、異なるプロトコルバージョンを支援する請求項１７記載の方法。
19. モバイルインターネットプロトコル通信を支援する通信システムにおける装置であって、
    ２つのシステム要素間に互換性がないことを判断するための手段と、
    ２つのシステム要素間で登録メッセージを適合させて、互換性を達成するための手段と、
    適合された登録メッセージを送るための手段とを含む装置。
20. モバイルインターネットプロトコル通信を支援する通信システムにおけるシステム要素であって、
    コンピュータ読み出し可能命令を記憶するためのメモリ記憶装置と、
    コンピュータ読み出し可能命令に応答して、
    ２つのシステム要素間に互換性がないと判断し、
    ２つのシステム要素間で登録メッセージを適合させて、互換性を達成し、
    適合された登録メッセージを送るようにされている処理装置とを含むシステム要素。

Images