ポイントツーポイント・プロトコル・デバイスの冗長性のためのシステムおよび方法
パケット・データ・サービング・ノード（ＰＤＳＮ）の冗長性を提供するシステムおよび方法が示される。例示的な一つの方法は、複数のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャとをアクセス・ノードに提供し、アクティブＰＤＳＮとスタンバイＰＤＳＮとの割合がＮ対１となる冗長性を確立する。モバイル・ノードと通信セッションを確立すると、それぞれのアクティブＰＤＳＮは、回復不能データのみを含む状態更新をスタンバイＰＤＳＮへ提供する。何れかのアクティブＰＤＳＮに障害が発生すると、スタンバイＰＤＳＮがアクティブＰＤＳＮとして割当てし直されて、障害のあるユニットに代わってモバイル・ノードとの通信セッションを引き継ぐ。残りのアクティブＰＤＳＮへはその割当て換えが通知され、更新状態データの送信は中断される。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、譲受人が本出願と同じである、２００２年６月１３日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＰＡＣＫＥＴ ＤＡＴＡ ＳＥＲＶＩＮＧ ＮＯＤＥ ＬＯＡＤ ＢＡＬＡＮＣＩＮＧ ＡＮＤ ＦＡＵＬＴ ＴＯＬＥＲＡＮＣＥ」と題する米国特許出願第１０／１７０９００号の一部継続出願である。
発明の分野
本発明は、モバイル・インターネット・プロトコル（「ＩＰ」）・ネットワークにおける通信に関する。より詳細には、本発明は、Ｎ対１の冗長性をもち、回復不能状態データのみ複製保存を行うパケット・データ・サービング・ノードを特に含む、ポイントツーポイント・プロトコル・デバイスの管理に関する。
【背景技術】
【０００２】
公衆パケット交換ネットワークは、モバイル・ホストなどのようなモバイル通信デバイス（モバイル・ノード）や、１つのネットワークから別のネットワークに接続点を変更するルータなどへの、およびそれらからのトラフィックを搬送するために使用されることができる。モバイルＩＰデータ・ネットワーキングの基本アーキテクチャは当技術分野で知られており、複数の刊行物の中で説明されており、それらの刊行物にはリクエスト・フォー・コメント（「ＲＦＣ」）文書ＲＦＣ２００２（１９９６年）（以降「ＲＦＣ２００２」）が含まれており、更に多くの情報については現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいてインターネット・エンジニアリング・タスク・フォース（「ＩＥＴＦ」）から入手可能である。モバイルＩＰデータ・ネットワーキング分野の当業者は、上記の文書、および実際にモバイルＩＰデータ・ネットワーキングを実施するために使用されるデバイスのことをよく知っている。
【０００３】
モバイルＩＰ通信ネットワークにおいて、モバイル・ノードは、「フォリン（foreign）・エージェント」および「ホーム（home）・エージェント」の２つのデバイスを用いて、ＩＰネットワーク上のターゲット・ホストと通信する。このタイプの通信を説明するモバイルＩＰネットワークの一例が、「Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ） Ｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ Ｈｏｍｅ Ａｇｅｎｔ ａｎｄ／ｏｒ Ｆｏｒｅｉｇｎ Ａｇｅｎｔ Ｆｕｎｃｔｉｏｎｓ Ｄｉｓｔｒｉｂｕｔｅｄ Ａｍｏｎｇ Ｍｕｌｔｉｐｌｅ Ｄｅｖｉｃｅｓ」と題する米国特許出願第０９／３５４６５９号で提示されており、同出願の全内容を参照により本明細書に組み込む。典型的には、フォリン・エージェント機能は、モバイル・ノードが訪れたネットワーク上のルータに組み込まれる。フォリン・エージェントは、モバイル・ノードがホーム・エージェントに登録されているとき、モバイル・ノードにルーティング・サービスを提供する。例えば、フォリン・エージェントは、モバイル・ノードのホーム・エージェントによってトンネリング（tunnel、トンネル化）されたデータグラムをデトンネリング（de-tunnel、トンネル化解除）し、それをモバイル・ノードへ配送する。
【０００４】
典型的には、ホーム・エージェントは、モバイル・ノードのホーム・ネットワーク上のルータに組み込まれる。ホーム・エージェントは、モバイル・ノードの現在地情報を維持する。１または複数のホーム・エージェントが複数のモバイル・ノード宛のコール（call、呼）を同時に処理する場合、ホーム・エージェントは、本質的に、仮想プライベート・ネットワーク・サービスに類似のサービスを提供する。典型的には、それぞれのモバイル・ノードは、別個のホーム・ネットワークと関連づけられ、そのホーム・ネットワークからホーム・エージェントを経由してフォリン・エージェントおよびモバイル・ノードへと到るルーティング経路は、モバイル・ノード用の仮想プライベート・ネットワークに似ている。
【０００５】
モバイルＩＰは、モバイル・ノード（モバイル・エンティティ）とフォリン・エージェントとの間のリンク・レイヤ接続性を必要とする。しかしながら、幾つかのシステムでは、モバイル・ノードからのリンク・レイヤは、フォリン・エージェントから遠い地点で終了し得る。そのようなネットワークは、一般に第３世代ワイヤレス・ネットワークと呼ばれている。図１は、典型的には第３世代ワイヤレス・ネットワークで使用されるネットワーク・アーキテクチャを例示したブロック図である。図１を参照すると、モバイル・ノード１０は、無線ネットワーク・ノード１６、パケット・データ・サービング・ノード１８、およびホーム・エージェント・ノード２４の３つのデバイスを用いて、ＩＰネットワーク３０上のターゲット・ホスト３４と通信する。モバイル・ノード１０の物理レイヤは、無線ネットワーク・ノード１６上で終端し、フォリン・エージェントの機能は、パケット・データ・サービング・ノード１８上に存在する。典型的には、無線ネットワーク・ノード１６が、モバイル・ノード１０とパケット・データ・サービング・ノード１８との間でリンク・レイヤ・プロトコル・データを中継し、パケット・データ・サービング・ノード１８が、モバイル・ノード１０へのリンク・レイヤを確立し、維持し、また、終了する。例えば、モバイル・ノード１０は、無線アクセス・ネットワーク上の通信リンクを介して、無線ネットワーク・ノード１６にリンクされることができる。
【０００６】
パケット・データ・サービング・ノード１８は、モバイル・ノード１０がホーム・エージェント２４に登録されているとき、モバイル・ノード１０にルーティング・サービスを提供する。パケット・データ・サービング・ノード１８は、トンネリングされたデータグラムをデトンネリングし、ホーム・エージェント・ノード２４からＩＰネットワーク２０を介してモバイル・ノード１０へ配送する。パケット・データ・サービング・ノード１６とホーム・エージェント２４との間で交換される通信トラフィックは、データ・トラフィックおよび制御トラフィックを含む。制御トラフィックは、登録要求または登録応答メッセージを含む。制御およびデータ・トラフィックは、パケット・データ・サービング・ノード１６を介して送られ、モバイル・ノード１０で終了する。ターゲット・ホスト３４は、ＩＰネットワーク２０および３０などのような、任意の数のネットワークによってホーム・ネットワーク２６に接続されることができ、また、ホーム・ネットワーク２６上に直接配置されることができる。代替例として、ターゲット・ホスト３４は、他のタイプのパケット交換ネットワークによってホーム・ネットワークに接続されることができる。
【０００７】
ホーム・エージェント２４は、モバイル・ノードのホーム・ネットワーク２６のルータに実装されることができる。ホーム・エージェント２４は、フォリン・エージェント・アドレス、モバイル・ノード１０のネットワーク・アクセス識別子（「ＮＡＩ：Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ」）、モバイル・ホーム・アドレス、およびホーム・エージェントとモバイル・ノード１０の間で共用される秘密鍵などのような、モバイル端末１０に関する現在地情報データを維持する。ホーム・エージェントは、ターゲット・ホスト３４からパケット・データ・サービング・ノード１８へデータをトンネリングし、同様に、逆方向のトンネリング・サービスも提供する。レイヤ２トンネリング・プロトコル（「Ｌ２ＴＰ：Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ」）トンネルなどのような、ポイントツーポイント・トンネルに関するより多くの情報は、現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて入手可能なＲＦＣ２６６１の中に見出されることができる。
【０００８】
従って、典型的には、ホーム・エージェント２４は、モバイル・ノード１０のために少なくとも２つの異なるタスクを実施する。第１に、ホーム・エージェント２４は、モバイル・ノード１０がホーム・ネットワーク２６へのアクセスを許可されているかどうかを決定するために、登録および認証のプロセスを実行する。これは、例えば、モバイル・エンティティの一意シリアル番号、ＮＡＩ、または製造番号、パスワード認証を用いてのモバイル・エンティティの識別情報（identification、アイデンティフィケーション）のチェック、そして場合によっては、モバイル・エンティティのアカウントが現在有効であり入金済かどうかのチェックを、含むことができる。ホーム・エージェントの登録および認証の機能は、リモート認証ダイアルイン・ユーザ・サービス（ＲＡＤＩＵＳ）（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ」）サーバのような認証・許可・アカウンティング（ＡＡＡ）（ａｕｔｈｅｎｔｉｃａｔｉｏｎ，ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ ａｃｃｏｕｎｔｉｎｇ）サーバなどのような第２のデバイスと連携して、または第２のデバイスの支援を受けて、実行されることができる。ＲＡＤＩＵＳサーバに関するより多くの情報は、より多くの情報を得るために現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて入手可能なＲＦＣ２１３８の中に見出されることができる。当業者に知られているように、登録プロセスは、パケット・データ・サービング・ノード１８からの登録要求メッセージの受信および処理、ならびにパケット・データ・サービング・ノード１８への登録応答メッセージの送信を含む。
【０００９】
パケット・データ・サービング・ノード１８も、モバイル・ノード１０のために４つの異なるタスクを実行する。パケット・データ・サービング・ノード１８は、モバイル・ノード１０のために登録およびセッション制御を取り扱うものであり、その制御は、ホーム・エージェント２４への登録要求メッセージの送信、およびホーム・エージェント２４から受信された登録応答メッセージの処理を含む。加えて、パケット・データ・サービング・ノード１８は、データ・パケットを、ターゲット・ホスト３４へ最終的に送信されるように、ホーム・エージェント２４へ転送するためのトンネリングについての責任を有し、また、ホーム・エージェント２４からのデータを、モバイル・ノード１０へ最終的に配送するために、デトンネリングする責任も負う。更に、パケット・データ・サービング・ノード１８は、モバイル・ノード１０のために、認証、許可、アカウンティングのサービスを提供する。パケット・データ・サービング・ノードは、ＲＡＤＩＵＳサーバなどのような認証・許可・アカウンティング・サーバと連携して、または支援を受けて、認証、許可、アカウンティングの機能を実行することができる。加えて、パケット・データ・サービング・ノード１８は、ＡＡＡサーバ、移動通信交換局（「ＭＳＣ：ｍｏｂｉｌｅ ｓｗｉｔｃｈｉｎｇ ｃｅｎｔｅｒ」）、またはホーム・エージェントへのおよびそれらからの信号／データ・インタフェースを提供するＰｉ／ＦＡインタフェースを提供することができる。
【００１０】
モバイル・ノード１０が、無線通信リンクを介して無線ネットワーク・ノード１６へコール設定指示を送信することによって、無線ネットワーク・ノード１６との通信セッションを開始するとき、無線ネットワーク・ノード１６は、パケット・データ・サービング・ノード１８への登録プロセスを開始する。典型的には、無線ネットワーク・ノード１６は、モバイル・ノード１０へサービスを提供できる複数のパケット・データ・サービング・ノードをもつように構成される。知られた従来技術では、無線ネットワーク・ノード１６は、新規の通信セッションに対して働くように構成された何れのパケット・データ・サービング・ノードのステータス情報ももたない。従って、無線ネットワーク・ノード１６は、モバイル・ノード１０についての登録プロセスを開始するとき、モバイル・ノード１０のためのパケット・データ・サービング・ノードをランダムに選択する。そのようなシステムでは、無線ネットワーク・ノードが使用可能なパケット・データ・サービング・ノードの一部はすぐに負荷過剰になり、その他のノードはほとんど使用されないということがあり得る。更に、無線ネットワーク・ノード１６からの登録要求の送信先となる複数の連続するパケット・データ・サービング・ノードが負荷過剰になった場合、そのようなパケット・データ・サービング・ノードは、無線ネットワーク・ノード１６からの登録要求を拒否する可能性がきわめて高く、従って、その結果、モバイル・ノード１０に対するサービスが遅れる。
【００１１】
モバイル・ノードからのユーザ・セッションの負荷を均衡化すること（負荷バランシング）は、重要な機能である。ユーザ・セッションの負荷バランシングに使用され得る既存の方法が幾つか存在する。典型的には、無線ネットワーク・ノードが、パケット・データ・サービング・ノードのＩＰアドレスを複数もつようにプログラムされ、無線ネットワーク・ノードは、その中の１つを、モバイル・ノードからの着信セッションに対するサービスのために選択することができる。既存の一つの方法によれば、無線ネットワーク・ノードはパケット制御機能を含むことができ、この機能は、例えばモバイル・ノードの国際電話加入者インタフェース（電話番号など）に基づいてハッシュ値を計算し、計算されたハッシュは、パケット・データ・サービング・ノードのＩＰアドレスを選択するために使用されることができる。この方式の短所は、アルゴリズムが、それぞれのパケット・データ・サービング・ノードの現在の負荷を考慮していないことである。別の代替方法によれば、パケット制御機能は、パケット・データ・サービング・ノードを選択するためにラウンド・ロビン機構を用いることができる。そのような実施形態では、パケット制御機能は、後続のそれぞれの到着（着信）セッションをリスト内の次のパケット・データ・サービング・ノードへ割り当てることができ、最後のパケット・データ・サービング・ノードに達したときには最初のパケット・データ・サービング・ノードへ戻って処理を繰り返す。ラウンド・ロビン機構は、コールを、パケット・データ・サービング・ノード間で分配するが、例えば、それぞれのパケット・データ・サービング・ノードへ送られるコール・セッションのタイプを考慮していない。
【００１２】
更に、別の方法によれば、外部フォリン・エージェント制御ノードが、例えば、パケット・データ・サービング・ノードのメモリ使用量や処理能力使用量に基づいて、パケット・データ・サービング・ノードを選択することができる。フォリン・エージェント制御ノードの機能は、「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｍａｎａｇｉｎｇ Ｆｏｒｅｉｇｎ Ａｇｅｎｔ Ｓｅｌｅｃｔｉｏｎｓ ｉｎ ａ Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｎｅｔｗｏｒｋ」と題する米国特許出願第０９／８８１６４９号に説明されており、同出願の全内容を参照により本明細書に組み込む。フォリン・エージェント制御ノードは、パケット・データ・サービング・ノードの選択時に負荷バランシング機構を提供するが、その現在のアーキテクチャには幾つかの制約が存在する。第１に、複数の冗長なフォリン・エージェント制御ノードは、現在のパケット制御機能選択アルゴリズムを仮定した場合、容易にはサポートされない。第２に、フォリン・エージェント制御ノードは、システム・アーキテクチャへ更なるコンポーネントが追加されることを必要とし、ＰＤＳＮがクラッシュした場合やその他の理由で使用不能になった場合、ユーザ・セッションをセーブすることを可能にしない。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
従って、モバイルＩＰネットワークにおいてパケット・データ・サービング・ノードやホーム・エージェントなどのようなサービング・ノードを選択するための改良されたシステムおよび方法が必要である。パケット・データ・サービング・ノード用の冗長性およびフェイルオーバ機能は、モバイル・ノードに無矛盾で無中断のサービスを提供するための重要な要素を構成する。
【課題を解決するための手段】
【００１４】
パケット・データ・サービング・ノードのフェイルオーバ機能を備える冗長性のためのシステムおよび方法は、モバイル・インターネット・プロトコル・ネットワークにおいてアクティブＰＤＳＮとスタンバイＰＤＳＮのＮ対１の関係を含み、複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャをアクセス・ノードに設けることによって達成される。Ｎ＋１個のパケット・データ・サービング・ノードから、１つのパケット・データ・サービング・ノードが、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイ（予備）として選択される。パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するための登録要求が無線ノードから受信されたとき、１つのパケット・データ・サービング・ノードが選択され、登録応答メッセージが第１のパケット・データ・サービング・ノードから無線ノードへ送信される。モバイル・ノードと選択されたパケット・データ・サービング・ノードとの間の通信セッションが確立され、回復不能状態データが、選択されたパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送信される。スタンバイ・パケット・データ・サービング・ノードは、Ｎ個のアクティブ・パケット・データ・サービング・ノードのすべてから同じように状態データを受信する。選択されたそれぞれのパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送られた回復不能状態データの更新は定期的に達成され、選択されたパケット・データ・サービング・ノードの障害時には、通信セッションは、アクティブ・パケット・データ・サービング・ノードの役割を引き継ぐスタンバイ・パケット・データ・サービング・ノードへ移され、それはＮ−１個の障害の無い（非障害）パケット・データ・サービング・ノードのすべての状態データを廃棄し、モバイル・ノードとの通信を継続しながらすべての動的状態データを回復する。
【００１５】
本発明の上記ならびにその他の態様および利点は、添付の図面を参照しながら以下の詳細な説明を読むことによって、当業者には明らかとなるであろう。
本発明の例示的な実施形態が、添付の図面を参照しながら説明される。
【発明を実施するための最良の形態】
【００１６】
図２は、モバイルＩＰネットワークにおいてモバイル・ノード用のフォリン・エージェントおよびホーム・エージェントを選択するために本発明で使用するのに適したネットワーク・システム２００の実施形態を示す機能ブロック図である。本明細書で説明される上記ならびにその他の構成およびプロセスは、例として示されるに過ぎず、代わりにその他の構成および要素（例えば、インタフェース、機能、要素の順序など）が使用されることができ、また幾つかの要素は全く省略されてもよいことを理解されたい。更に、大部分の電気通信の応用においてと同様に、本明細書で説明される多くの要素は、個別のコンポーネントとして、または他のコンポーネントとともに、任意の適切な組合せで、または任意の適切な場所に実装され得る機能エンティティであることは、当業者であれば理解されよう。
【００１７】
図２に示されるように、システム２００は、モバイル・ノード２０２と、基地局コントローラ２０４と、無線ノード２０６と、アクセス・ノード２０８および２２４と、ＩＰネットワーク２１０と、フォリン認証・許可・アカウンティング（「ＦＡＡＡ」）サーバ２１４と、ホーム認証・許可・アカウンティング（「ＨＡＡＡ」）サーバ２１６と、ターゲット・ホスト２１２とを含む。モバイル・ノード２０２は、例えば、電話、ラップトップ・コンピュータ、ファックス、または携帯情報端末（「ＰＤＡ」）などのような、任意の適切な形態をとることができる。１つのみのモバイル・ノードを図示しているが、複数のモバイル・ノードが存在できることを理解されたい。
【００１８】
モバイル・ノード２０２は、基地局（図示せず）を介して基地局コントローラ２０４に接続される。基地局コントローラ２０４は、ＣＤＭＡ無線ネットワークなどのような無線ネットワーク上に存在することができる。基地局コントローラ２０４は、無線ノード２０６に結合される。無線ノード２０６は、新規着信ユーザ通信セッションのためにＰＤＳＮを選択するパケット制御機能（「ＰＣＦ」）（ｐａｃｋｅｔ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）を含むことができる。例えば、ＰＣＦは、ＰＤＳＮの１または複数のＩＰアドレスをもつように前もってプログラムされることができる。
【００１９】
無線ノード２０６は、アクセス・ノード２０８と通信する。アクセス・ノード２０８は、モバイル・ノードへデータ・サービスを提供するマルチサービス・アクセス・プラットフォームである。例示的な実施形態によれば、アクセス・ノード２０８は、複数のＰＤＳＮを含み、そのうちの２つであるＰＤＳＮ２１８とＰＤＳＮ２２０とが図２に示されている。ＰＤＳＮ２１８および２２０は、システム・マネージャ２２２と通信する。システム・マネージャ２２２は、以下に説明される機能のなかでも特に、それぞれのＰＤＳＮからロード（負荷）／ステータス（状態）情報を受信し、モバイル・ノードへのＰＤＳＮ割当てを決定する。代替例として、以下でより詳しく説明されるように、システム・マネージャ２２２は、負荷分散型データベースをサポートする。
【００２０】
アクセス・ノード２０８は更に、複数のＨＡを含むアクセス・ノード２２４とも通信し、複数のＨＡのうちの２つであるＨＡ２２６とＨＡ２２８とが図２に示されている。ＨＡ２２６および２２８は、システム・マネージャ２３０と通信する。図２は２つのアクセス・ノードを示しており、アクセス・ノード２０８はＰＤＳＮカードを収容し、アクセス・ノード２２４はＨＡカードを収容している。しかしながら、ネットワーク・アーキテクチャは、ＰＤＳＮとＨＡとの組合せを収容する単一のアクセス・ノードを含むこともできることを理解されたい。
【００２１】
ＰＤＳＮ２１８は、モバイル・ノード２０２からのポイントツーポイント・プロトコル（「ＰＰＰ」）セッションの終端点である。ＰＤＳＮ２１８はまた、ＩＰパケットを得るためにＰＰＰパケットを集めてカプセル開放（decapsulate、カプセル化解除）を行い、その後、ＩＰパケットは、アクセス・ノード２２４上のＨＡ２２６や２２８などのようなＨＡへ送られる。アクセス・ノード２０８および２２４は更に、それぞれＦＡＡＡ２１４およびＨＡＡＡ２１６に結合される。ＦＡＡＡ２１４は、ＰＤＳＮへログ・オンするモバイル・ユーザの認証を行ったり、ユーザ固有のコンフィグレーション・オプションをＰＤＳＮに提供したり、モバイルＩＰ登録時にルーティング情報を提供したりすることができる。アクセス・ノード２０８は更にＩＰネットワーク２１０に結合され、ＩＰネットワークはターゲット・ホスト２１２に結合される。
【００２２】
ＰＤＳＮは、モバイル・ノードのホーム・ネットワークに典型的には配置されるＨＡＡＡ２１６とは直接に通信できないので、ＦＡＡＡ２１４は、ネットワーク・サービス・プロバイダのドメインにおいてＨＡＡＡ２１６のプロキシとして機能することができる。そのような実施形態では、ＦＡＡＡ２１４は、ＰＤＳＮ２１８から認証要求を受信したとき、その要求をＨＡＡＡ２１６へ送信し、ＨＡＡＡ２１６は認証応答をＦＡＡＡ２１４へ送信し、その後ＦＡＡＡ２１４はその応答をＰＤＳＮ２１８へ返送する。ＦＡＡＡ２１４とＨＡＡＡ２１６との間には、認証するメッセージをそれらの間で送信されるようにするために、共有の機密が存在する。
【００２３】
ＨＡＡＡ２１６およびアクセス・ノード２２４は、モバイル・ノード２０２のホーム・ネットワークに存在する。ＨＡＡＡ２１６は、ホーム・ネットワークにおいてモバイル・ノード登録要求を認証することができる。ＨＡＡＡ２１６はまた、コール・セッションを設定するためのコンフィグレーション・パラメータをサービングＨＡへ提供することができる。例えば、コンフィグレーション・パラメータは、セキュリティ・レベルや、差別化サービス・タイプや、リバース・トンネリング・パラメータを含むことができる。ＨＡＡＡ２１６はまた、モバイル・ノード２０２に代わるＦＡＡＡ２１４からの要求を認証することもできる。ＦＡＡＡ２１４は、要求をＨＡＡＡ２１６へ送信することができ、ＨＡＡＡ２１６は、その要求を認証し、応答をＦＡＡＡ２１４へ返送することができ、その後ＦＡＡＡ２１４は、その応答をＰＤＳＮ２１８へ転送する。
【００２４】
図３は、アクセス・ノード２０８の例示的な実施形態を示すブロック図３００である。図３に示されるアクセス・ノード２０８および２２４は、３つのシェルフ、即ち、１つの制御シェルフ３０２および２つのデータ・シェルフ３０４、３０６から成る単一のラック３５０上に構成されることができる。制御シェルフ３０２は、以下で図を参照しながらより詳しく説明される複数のカード（０〜Ｎ）から構成される。制御シェルフ３０２は、ネットワーク管理インタフェース３０８を介してネットワーク管理システムに結合されることができ、従って、システム・マネージャがそれらのシステムの必要に応じてアクセス・ノード２０８および２２４をコンフィグレーションできるようにする。制御シェルフ３０２は更に、ネットワーク３１６へのインタフェース３１０を含む。一実施形態では、ネットワーク３１６は、例えば、ＣＤＭＡネットワーク、ＰＳＴＮ／ＴＤＭまたはＡＴＭネットワーク、およびインターネットなどのようなデータ・ネットワークとすることができる。しかしながら、異なるネットワークが使用されることもできる。一実施形態では、制御シャーシ内の各カードは２つのポートを含むことができ、それらは、例えば、ネットワーク３１６との間でデータの通信を行うのに使用されることができる２つのギガビット・イーサネット（登録商標）・ポートなどのようなものである。
【００２５】
更に、図３に示されるアクセス・ノード２０８および／または２２４は、やはり以下で図を参照しながらより詳しく説明される複数のカード（０〜Ｎ）を有する２つのデータ・シェルフ３０４および３０６を含む。データ・シェルフ３０４および３０６は、ネットワーク３１６へのインタフェース３１２および３１４を含む。図３は幾つかの外部インタフェースのみを示し、シャーシ間の接続を示していないことを理解されたい。更に、本発明は３つのシャーシを含む単一のラックに限定されず、より多くのシャーシが単一のラックへ追加されることもできることを理解されたい。
【００２６】
代替例として、アクセス・ノード２０８またはアクセス・ノード２２４は、複数のラックに分散されてもよい。そのような構成では、１つの制御シェルフが、複数のラックに分散された複数のデータ・シェルフを制御することができる。図４は、アクセス・ノード２０８の分散型ネットワーク・アーキテクチャ４００を示すブロック図である。図３に示されるラック３５０に加えて、アクセス・ノード２０８は更に第２のラック４５０を含む。第２のラック４５０は、インタフェース４０８、４１０、および４１２を介してネットワーク３１６と通信し、更にインタフェース４１４、４１６、および４１８をそれぞれ介してネットワーク３１６と通信する３つのデータ・シェルフ４０２、４０４、および４０６を含む。本発明は２つのラックに限定されず、３以上のラックが使用されることもできることを理解されたい。
【００２７】
図５は、例示的な一実施形態による制御シェルフ５００を示すブロック図である。図５に示される制御シェルフ５００は１８個のカード・スロットを含んでいるが、制御シェルフはそのような構成に限定されず、幾つかのスロットは未使用のまま何もカードを装着せずにおくことができ、また、より少数のカード・スロットが使用されることもできることを、理解されたい。例示的な実施形態によれば、制御シェルフ５００のすべてのコンポーネントは、１対１の冗長性などの冗長性を示し、フェイルオーバ機能を有する。従って、制御シェルフ５００の各コンポーネントは、アクティブ・カードとスタンバイ・カードとを含むことができ、アクティブ・カードが障害を起こした場合には、スタンバイ・カードがその障害を検出してアクティブ・カードの役割を引き継ぐことができるようにされる。その実施形態は、以下でより詳しく説明される。
【００２８】
制御シェルフ５００は、２つのシェルフ・コントローラ５０２および５０４を含み、それぞれのシェルフ・コントローラは、シェルフ５００の左端のスロット内に配置される高さが半分の２つのカードの形態をとる専用ハードウェアでサポートされる。更に、制御シェルフ５００は、２つのスイッチ出口モジュール５０６および５０８と、２つのシステム・マネージャ５１０および５１２と、ＰＤＳＮ／ＨＡカードとして示された複数のアプリケーション・カード５１４〜５３６とを含む。例示的な実施形態は、ＰＤＳＮカードまたはＨＡカードのみを含む制御シェルフに限定されず、代替例として、制御シェルフ５００は、ＰＤＳＮカードとＨＡカードの組合せを含むことができることを理解されたい。更に、代替的な実施形態では、シェルフ・コントローラおよびシステム・マネージャは、システム管理機能を達成するために、単一または複数のカード上に構成されることができる。
【００２９】
例示的な実施形態では、シェルフ・コントローラ５０２は、プライマリ・シェルフ・コントローラとして構成されることができ、シェルフ・コントローラ５０４は、バックアップ・シェルフ・コントローラとして構成されることができる。それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのカード・スロットにシェルフ・コントローラを接続するのに使用されるマルチレイヤ（Ｌ２／Ｌ３）対応スイッチを含む。更に、それぞれのシェルフ・コントローラは、それぞれのスロットへの個別のバス、即ち、以下で管理バスとも呼ばれるシステム制御バスを有することができ、このバスは、単一プラットフォーム内において管理、シグナリング、およびルーティングなどのようなカード内制御通信およびカード間制御通信を提供するのに使用される。一実施形態によれば、例えば、ＰＤＳＮカードは、システム制御バスを使用して、１または複数のシステム・マネージャ・カードまたは別のＰＤＳＮカードと通信することができる。そのような実施形態では、ＰＤＳＮから送信されるデータは、システム制御バス、１または複数のシェルフ・コントローラ・カードを介して、１または複数のシステム・マネージャ・カードやＰＤＳＮカードなどのような宛先へ送られる。
【００３０】
シェルフ・コントローラ５０２および５０４は、シェルフ内ハードウェア・コンフィグレーションを管理し、ハードウェア管理を行う。例えば、シェルフ・コントローラは、シェルフ識別子およびシェルフ・シリアル番号を読み取ることができ、これらはその後、内部アドレスの割当てを容易にするために、またシステム・マネージャが特定のカード・ロケーションおよびコンフィグレーションを正確に関連づけることができるようにするために、使用されることができる。更に、シェルフ・コントローラ５０２および５０４は、シェルフ内のその他のカードおよび電源の存在検出の形態をとる物理的監視を提供する。
【００３１】
シェルフ・コントローラ５０２および５０４はまた、例えば、電源や、冷却ファンや、電源内に設けられた温度センサなどのステータスに関してポーリングを行うことができる。加えて、シェルフ・コントローラ５０２および５０４は、シェルフ５００内の電力管理に責任をもつこともでき、それは、電源から取得可能な現在の有能電力に対する個々のカードの現在の必要量を評価することによってなされる。シェルフ・コントローラ５０２および５０４は、１００Ｍｂｐｓまたはそれより高速のインタフェースなどのようなイーサネット（登録商標）・インタフェース５４２を介して、シェルフ５００内のすべてのカードと通信することができる。
【００３２】
スイッチ出口モジュール５０６および５０８は、システム・マネージャおよびＰＤＳＮ／ＨＡなどのようなスロット内のすべてのカードがギガビット・リンク上で互いに通信できるようにする、高速ポイントツーポイント・スイッチ（Ｌ２／Ｌ３）として構成されることができる。スイッチ出口モジュール５０６および５０８は、ネットワークとの間でデータの通信を行うために、スイッチ・ネットワーク・インタフェース５３８および５４０を使用する。
【００３３】
更に、制御シャーシ５００は、複数のシャーシを単一点から管理するために、シンプル・ネットワーク管理プロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのような既存または今後開発される管理プロトコルを使用できるシステム・マネージャ５１０および５１２を含む。システム・マネージャ５１０および５１２は、例えばＳＮＭＰを使用してそれぞれのカードを定期的にポーリングすることによって、システム内のすべてのカードの統計およびステータス情報を維持することができる。システム・マネージャ５１０および５１２は、それぞれインタフェース５４４および５４６を介して、それぞれのカードと通信することができる。更に、それぞれのＰＤＳＮカードまたはＨＡカードは、ネットワーク・インタフェース、即ち、図５に示されたネットワーク・インタフェース５４８〜５７０を有する。
【００３４】
図６は、例示的な一実施形態によるデータ・シェルフ６００を示すブロック図である。データ・シェルフ５００は、インタフェース６４２を介してシェルフ６００内のすべてのカードと通信するシェルフ・コントローラ６０２および６０４を含む。データ・シェルフ６００は更に、スイッチ・ネットワーク・インタフェース６３８および６４０を介して通信する２つのスイッチ出口モジュール６０６および６０８と、インタフェース６４４〜６７０を介して通信するＰＤＳＮまたはＨＡ６１０〜６３６とを含む。図５と同様に、データ・シェルフ６００は、ＰＤＳＮまたはＨＡのみを含むように限定されず、データ・シェルフ６００は、ＰＤＳＮカードとＨＡカードの組合せを含むこともできることを、理解されたい。
【００３５】
図７は、シェルフ内のピア・モジュール間のデータプレーン接続性（ｃｏｎｎｅｃｔｉｖｉｔｙ、コネクティビティ）およびシェルフ・コントローラおよびシステム・マネージャのバックプレーン接続性についてのシェルフ・アーキテクチャ７００を示すブロック図である。
【００３６】
シェルフ・アーキテクチャ７００は、３つの例示的なアプリケーション・モジュール７０２、７０４、および７０６を示している。アプリケーション・モジュール７０２〜７０６は、ネットワーク・インタフェース７１０、７１８、７２６と、作業間機能（「ＩＷＦ」）（ｉｎｔｅｒ−ｗｏｒｋｉｎｇ ｆｕｎｃｔｉｏｎ）７１２、７２０、７２８と、管理および制御インタフェース７０８、７１６、７２４と、パケット処理／転送モジュール７１４、７２２、７３０とをそれぞれ含む。アプリケーション・モジュール７０２〜７０６は、ＰＤＳＮモジュールまたはＨＡモジュールとすることができることを理解されたい。
【００３７】
ネットワーク・インタフェース７１０、７１８、および７２６は、例えば、ＰＳＴＮ、無線ネットワーク、データ・ネットワークなどのようなネットワークへのインタフェースを提供する。管理および制御インタフェース７０８、７１６、および７２４は、ＳＮＭＰネットワーク、セッション開始プロトコル（「ＳＩＰ」）（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ネットワーク、Ｈ．３２３ネットワーク、または任意の既存もしくは今後開発される信号ネットワークなどのような管理および信号ネットワークへのインタフェースを提供する。管理および制御インタフェースは、システム制御バス７３４（または管理バス）を介して、シェルフ・コントローラ・モジュール７３６および７３８と通信し、シェルフ・コントローラ・モジュールは、図５に示された制御シェルフ５００などのような制御シェルフへ管理および制御メッセージを送信する。
【００３８】
システム制御バス７３４は、単一プラットフォーム内での管理、シグナリング、およびルーティング通信などのようなカード内／カード間制御を提供する。一実施形態では、システム制御バス７３４は、スイッチド・ファースト・イーサネット（登録商標）（１００Ｍｂｐｓ）システム制御バスとして実装されることができ、
プラットフォームの管理および制御機能をサポートするための、物理的に個別で専用の組込まれたネットワークを提供する。システム制御バス７３４は、シェルフ７００の２つのシェルフ・コントローラ・モジュールのそれぞれから始まり、ピア・シェルフ・コントローラ・スロットを含むそれぞれのスロットへ到る。例えば、それぞれのシェルフ・コントローラは、１つの双方向１００ＢａｓｅＴ−ＴＸイーサネット（登録商標）・リンクを介して、シェルフ内のすべてのスイッチ出口モジュールおよびアプリケーション・モジュールに接続されることができる。加えて、２つのシェルフ・コントローラ・モジュールは、１つの双方向１００ＢａｓｅＴ−ＴＸイーサネット（登録商標）・リンクを介して接続されることができる。一実施形態では、それぞれの接続は、１００Ｍｂｐｓ １００ＢａｓｅＴ−ＴＸイーサネット（登録商標）を伝送する１対の差動トレース（ｄｉｆｆｅｒｅｎｔｉａｌ ｔｒａｃｅ）として構成されることができる。従って、そのような実施形態では、それぞれのシステム制御バス・リンクは、１対のＴＸおよび１対のＲＸファスト・イーサネット（登録商標）・リンクを含む４線インタフェースとすることができる。しかしながら、異なるタイプのリンクも使用され得ることを理解されたい。
【００３９】
図８は、例示的な一実施形態によるシステム制御バス７３４の例示的な物理的相互接続を示している。図８に示されるように、システム制御バス７３４は、２つのシェルフ・コントローラ８０６および８０８を互いに、そしてそれぞれのスイッチ出口モジュール８０２および８０４へ、ならびにＰＤＳＮカードまたはＨＡカードを収容するそれぞれのアプリケーション・スロットなどのようなそれぞれのアプリケーション・カード８１０〜８３６へ、相互接続する。
【００４０】
再び図７を参照すると、それぞれのアプリケーション・カードおよびシェルフ・コントローラは、媒体データ・バス７３２（以下でスイッチ構造とも呼ばれる）に接続される。媒体データ・バス７３２は、単一シェルフ内でＬＰパケット・トラフィックを分配する。媒体データ・バス７３２は、スター型トポロジで実装されることができ、それは、それぞれのスイッチ出口スロットから始まり、ピア・スイッチ出口スロットおよび２つのシェルフ・コントローラ・スロットを含むメイン・バックプレーンの他のすべてのスロットへ到る。一実施形態では、スイッチド・スター型バスは、それぞれの差動対が、１．２５Ｇｂｐｓ範囲、２．５Ｇｂｐｓ範囲、またはより高速／より低速の範囲などのようなＧｂｐｓ範囲で信頼性の高い送信を行えるようにする。一実施形態では、スイッチ出口スロットからのそれぞれの媒体データ・バス接続は、デュアル（ＴＸ／ＲＸ）・ポイントツーポイント差動対（即ちスポーク）として構成されることができる。そのような実施形態では、ピア・スイッチ出口スロットへは２つのスポーク、それぞれのアプリケーション・モジュール・スロットへは２つのスポーク、それぞれの半シェルフ・コントローラ・スロットへは１つのスポークが存在するように、スポークは分配されることができる。
【００４１】
例示的な一実施形態によれば、１または複数のＰＤＳＮカードは、互いにまたはシステム・マネージャ・カードと通信するために、媒体データ・バス７３２を使用することができる。そのような実施形態では、ＰＤＳＮカードへおよびＰＤＳＮカードから送られるデータは、媒体データ・バス７３２を介し、１または複数のスイッチ出口モジュールを経由して、システム・マネージャ・カードやＰＤＳＮカードなどのような目的の宛先（１または複数）へ送信される。加えて、それぞれのＰＤＳＮカードは、ＦＡＡＡサーバ２１４へ問合せを送信するため、およびＦＡＡＡサーバ２１４から許可応答を受信するために、媒体データ・バス７３２を使用することができる。許可問合せを送信するために、ＰＤＳＮカードは、許可問合せを、媒体データ・バス７３２およびスイッチ出口モジュールを介してＦＡＡＡサーバ２１４に送信することができる。それに応答して、ＰＤＳＮカードは、許可応答を、ＦＡＡＡサーバ２１４から、スイッチ出口モジュールおよび媒体データ・バスを介して、受信することができる。それぞれのＨＡカードも、ＨＡＡＡサーバ２１６へ許可情報を送信するため、およびＨＡＡＡサーバ２１６から許可情報を受信するために、また、データをシステム・マネージャ・カードおよび他のＨＡカードと通信するために、媒体データ・バス７３２を使用することができることを、理解されたい。
【００４２】
図９は、例示的な一実施形態による媒体データ・バスの物理的相互接続を示すブロック図である。図９に示されるように、スイッチ出口スロット８０２および８０４は、１００Ｍｂｐｓイーサネット（登録商標）・リンク９０２を介して相互接続される。更に、それぞれのスイッチ出口スロットは、１００Ｍｂｐｓイーサネット（登録商標）・リンク９０４〜９１０を介してそれぞれのシェルフ・コントローラ８０６および８０８へ、また、Ｇｂｐｓイーサネット（登録商標）・リンク９１２〜９２６を介してそれぞれのアプリケーション・モジュール・スロットへ、相互接続される。従って、例示的な実施形態によれば、スイッチド・ギガビット・イーサネット（登録商標）媒体データ・バスは、それぞれのシェルフ内でカード間通信をサポートする物理的に別個で専用の組込まれたネットワークを提供する。
【００４３】
例示的な一実施形態によれば、アクセス・ノードの構成は、１つの制御シェルフおよび５つのデータ・シェルフを含む６つのシェルフから成ることができ、それぞれのデータ・シェルフは、シグナリングおよび管理情報などのような制御情報を受信するために制御シェルフと通信する。図１０は、例示的な一実施形態によるシェルフ間ケーブル配線トポロジ１０００を示すブロック図である。
【００４４】
図１０は、シェルフ・コントローラ１００８および１０１０と、５つのデータ・シェルフ１０１６、１０１８、１０２０、１０２２、および１０２４とに相互接続される２つのシステム・マネージャ１０１２および１０１４を含む制御シェルフ１００２を示している。例示的な実施形態によれば、それぞれのデータ・シェルフは、２つのシェルフ・コントローラを含み、そのうちの一方はバックアップ・コントローラとして構成されることができる。具体的には、図１０に示されるように、データ・シェルフ１０１６、１０１８、１０２０、１０２２、および１０２４は、シェルフ・コントローラ１０２６および１０２８、１０３０および１０３２、１０３４および１０３６、１０３８および１０４０、１０４２および１０４４をそれぞれ含む。
【００４５】
それぞれのシェルフ・コントローラは、シェルフ内における管理通信インフラストラクチャを提供するマルチレイヤ・イーサネット（登録商標）・スイッチを含む。更に、それぞれのシェルフ・コントローラは、２つの外部接続を単一のスター型バス・インタフェースに提供して、冗長システム・マネージャのそれぞれが各シェルフ・コントローラへ接続できるようにする。制御シェルフ１００２では、シェルフ・コントローラ１００８および１０１０へのパスは、バックプレーンの制御プレーン・インタフェースを介して構成されることができる。
【００４６】
マルチシャーシ構成では、すべてのシェルフ間接続性は、物理的に制御シェルフ１００２内に配置されるシステム・マネージャ１０１２および１０１４を介して、データ・シェルフ１０１６〜１０２４内のシェルフ・コントローラ１０２６〜１０４４へとなされる。シェルフ・コントローラは、そのシェルフ内のアプリケーション・カードへの物理的接続を確立する。そのような例示的な一実施形態が、図１０で制御シェルフ１００２に関して示されており、シェルフ・コントローラ１００８および１０１０は、アプリケーション・モジュール１００４および１００６によって示される複数のアプリケーション・モジュールへ相互接続されている。
【００４７】
図１０に示されたそれぞれのシェルフ・コントローラは、２４個の１０／１００ポートおよび２ギガビット・イーサネット（登録商標）・ポートを含むＩＥＥＥ８０２．１ｐ／Ｑ対応スイッチなどのようなマルチレイヤ（Ｌ２／Ｌ３）スイッチを含む。一実施形態では、それぞれのシェルフ・コントローラは、Ｂｒｏａｄｃｏｍ社製のＢＣＭ５６００シリーズＳｔｒａｔａ Ｓｗｉｔｃｈを含むが、異なるスイッチも使用され得る。前掲の図を参照して説明されたように、それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのスロットへの物理的に別個の管理バス、即ち、システム制御バスを有する。更に、シェルフ内の２つのシェルフ・コントローラは、デュアル１０／１００Ｍｂｐｓリンクによって互いに接続される。
【００４８】
図１０に示されたシェルフ間通信アーキテクチャは、ネットワーク管理および搬送信号の目的で使用される。またスイッチ出口モジュール（図１０には示されず）は、複数のシャーシを接続するために無線システムで使用され得る２つの外部ギガビット・リンクも提供することを理解されたい。更に、図１０および前掲の図に示された例示的な実施形態によれば、制御シェルフ機能は、管理および動作の一貫性を実現するために、単一の指定されたシェルフに存在する。しかしながら、制御シェルフ機能は、複数のシェルフに分散されることもできることを理解されたい。例示的な実施形態によれば、図２に示された無線ノード２０６のＰＣＦは、新規の通信セッションをアクセス・ノード２０８の任意のＰＤＳＮへ送ることができる。システム・マネージャは、結びつけられた対として配置され、一方のシステム・マネージャ・カードは、他方のバックアップとして機能する。そのような実施形態では、プライマリ・システム・マネージャは、ＰＤＳＮから負荷情報を受信したとき、その負荷情報をそのバックアップ・パートナへ渡すことができる。従って、プライマリ・システム・マネージャがソフトウェアの障害またはハードウェアの障害を起こした場合、バックアップ・システム・マネージャは障害を検出してプライマリ・システム・マネージャの機能を引き継ぐことができる。
【００４９】
システム・マネージャは、アクセス・ノード２０８のそれぞれのシャーシのすべてのカードに関する統計情報およびステータス情報を維持する。更に、それぞれのシステム・マネージャは、システム・マネージャがサービスを提供するＰＤＳＮのＩＰアドレスをもってプログラムされることができ、それぞれのＰＤＳＮ ＩＰアドレスは、対応するＰＤＳＮの所定の特性の組へとマッピングすることができる。例えば、システム・マネージャは、セッション・タイプ、セッション・ビット・レート、またはグループ内のそれぞれのＰＤＳＮが処理できるセッション数に基づいて、ＰＤＳＮを幾つかの組にグループ化することができる。更に、アクセス・ノード２０８の通常動作中、システム・マネージャは、アクセス・ノード上でサービスを受けるそれぞれのモバイル端末およびそれぞれのＰＤＳＮ、ＨＡ用の動的データベースを構築することができる。例示的な実施形態は、スタンドアローンのブレードに構成されるＰＤＳＮおよびＨＡを開示しているが、以下で開示される通信方法は、例えば、ＰＤＳＮ機能が、インタフェース機能用、コール処理機能用、およびデータ転送機能用の別個のエレメントで提供されるような、ＰＤＳＮおよび／またはＨＡの機能が通信シャーシ内の１または複数のブレードによって提供される構成にも、等しく適用可能である。
【００５０】
一実施形態では、ＰＤＳＮプロフィールまたはＨＡプロフィールは、ＰＤＳＮ ＩＰアドレスまたはＨＡ ＩＰアドレスそれぞれを使用してプロフィールが生成されたＰＤＳＮまたはＨＡを定義することができる。更に、それぞれのプロフィールは、個々のＰＤＳＮまたはＨＡが処理するセッション・タイプ、セッション・ビット・レート、あるいはセッションの数を定めることができる。加えて、それぞれのＰＤＳＮおよびＨＡプロフィールは、個々のＰＤＳＮおよびＨＡのステータスおよび状態、ならびにそのＰＤＳＮおよびＨＡについての負荷情報を含むことができる。例えば、パラメータの中でも特に、ステータス（状態）は、ＰＤＳＮまたはＨＡがアクティブかまたは非アクティブかを定めることができ、状態は、ＰＤＳＮまたはＨＡがプライマリＰＤＳＮ／ＨＡであるかバックアップＰＤＳＮ／ＨＡであるかを定めることができる。それぞれのＰＤＳＮまたはＨＡの状態情報に加えて、プロフィールは、そのパートナとなるＰＤＳＮまたはＨＡのＩＰアドレスも定めることができる。
【００５１】
更に、例示的な実施形態によれば、それぞれのＰＤＳＮおよびＨＡは、それぞれスタンバイＰＤＳＮおよびＨＡへ、コール関連情報を定期的に送信するように構成されることができる。例えば、ＰＤＳＮプロフィールは、特定のセッションまたはそのセッション用に使用されるＰＰＰ圧縮のタイプについてＩＰｓｅｃがネゴシエートされたかどうかを定めることができる。しかしながら、セッション・タイプを定めるための異なる基準も使用され得ることを理解されたい。そのような実施形態では、システム運用者は、アクセス・ノード２０８内の異なるＰＤＳＮ用の負荷コンフィグレーションをダウンロードし、特別のセッション・タイプのユーザにより良いサービスおよび接続性を提供することができる。
【００５２】
例示的な実施形態によれば、アクセス・ノード２０８のＰＤＳＮおよびＨＡは、その使用可能性および負荷情報をシステム・マネージャへ伝えるためにハートビート機構を使用することができる。図１１は、ＨＡまたはＰＤＳＮなどのようなアプリケーション・モジュール用の例示的なブート・アップ・プロセスを示している。図１１は、ＰＤＳＮおよびＨＡを単一のＰＤＳＮ／ＨＡブロックとして示すことによって、ＰＤＳＮおよびＨＡ用のブート・アップ・プロセスを簡略化しているが、例示的な実施形態によれば、ＨＡとＰＤＳＮとは、アクセス・ノード２０８内の異なるアプリケーション・モジュールに配置されることを理解されたい。
【００５３】
ステップ１１０２で、ＰＤＳＮまたはＨＡなどのようなアプリケーション・モジュールは、電源が投入され、初期設定メッセージをシステム・マネージャへ送信することによって、プライマリ・システム・マネージャとの通信を開始する。ステップ１１０４で、システム・マネージャは、ＨＡまたはＰＤＳＮを確認する。これを行うため、システム・マネージャは、物理的ＨＡまたはＰＤＳＮリストからＨＡまたはＰＤＳＮを読み取る。確認が成功すると、ステップ１１０６で、システム・マネージャは、初期設定アクノレッジ（肯定応答）・メッセージをＨＡ／ＰＤＳＮへ送信する。
【００５４】
ステップ１１０８で、システム・マネージャは、このＨＡ／ＰＤＳＮのための役割を選択する。一実施形態では、役割の割当ては動的である。代替例として、システム・マネージャは、冗長性メカニズムが確立されるように、アクセス・ノード内のＰＤＳＮまたはＨＡなどのような各カードの役割を定める役割割当ファイルをもつように前もってプログラムされることができる。例えば、ＨＡ／ＰＤＳＮは、バックアップとして働く所定のＨＡ／ＰＤＳＮを有するプライマリＨＡ／ＰＤＳＮとして構成されることができる。更に、ＨＡ／ＰＤＳＮは、ＨＡ／ＰＤＳＮへアクティブな役割を割り当てることができる。代替例として、ＨＡ／ＰＤＳＮが別のＨＡ／ＰＤＳＮのバックアップとして割り当てられた場合、システム・マネージャは、更に、そのＨＡ／ＰＤＳＮへスタンバイとしての役割を割り当てて、所定のプライマリＨＡ／ＰＤＳＮの冗長ＨＡ／ＰＤＳＮとして動作するようにさせる。異なる冗長性メカニズムが、以下でより詳しく説明される。
【００５５】
ステップ１１１０で、システム・マネージャは、ＨＡ／ＰＤＳＮに役割割当てメッセージを送信し、ＨＡ／ＰＤＳＮは、システム・マネージャへ役割割当アクノレッジ・メッセージ１１１２を送信することによって応答する。ステップ１１１４で、システム・マネージャは、サービス中であるというマークをＨＡ／ＰＤＳＮに付け、ステップ１１１６で、システム・マネージャは、ハートビート・タイマを始動させる。一実施形態では、ハートビート・タイマは、次のハートビート・メッセージがＰＤＳＮ／ＨＡから受信されるべき時間間隔を識別することができ、システム・マネージャは、その時間間隔が経過する前に次のハートビートが受信されない場合にはＰＤＳＮ／ＨＡが使用不可能であると決定する。代替例として、システム・マネージャは、２以上のハートビートがモジュールから受信されない場合に、そのモジュールが使用不可能であると決定することができる。同様に、ハートビートがシステム・マネージャから受信されない場合、ＨＡ／ＰＤＳＮは、そのプライマリ・システム・マネージャの障害を検出し、その後のハートビートを、その時点でプライマリ・システム・マネージャとして動作している冗長システム・マネージャへ送信することができる。
【００５６】
例示的な実施形態によれば、アクセス・ノード２０８のすべてのＰＤＳＮおよびＨＡは、システム・マネージャがすべてのＰＤＳＮおよびＨＡのステータスをラック全体にわたって見渡せるように、システム・マネージャへハートビート情報１１１８を定期的に送信する。更に、代替例として、ＰＤＳＮ／ＨＡモジュールは、ＩＰマルチキャストを使用して他のＰＤＳＮ／ＨＡからコール情報を受信することもでき、そこにおいては、参加するそれぞれのＰＤＳＮ／ＨＡは、マルチキャスト・グループの一員であり、分散型情報データベースをサポートする。
【００５７】
例示的な実施形態によれば、ＰＤＳＮ／ＨＡは、管理バス（即ち、システム制御バス）を介してシステム・マネージャと通信することができる。代替例として、制御メッセージは、媒体データ・バス（即ち、スイッチ構造）を介して交換されることもできる。
【００５８】
図１２は、システム・マネージャを使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオ１２００のブロック図である。ブロック図は、モバイル・ノード（ＭＮ）と、無線ネットワーク・ノード（ＲＮＮ）と、選択されたＰＤＳＮと、ＰＤＳＮと、システム・マネージャとを含む。図示のＰＤＳＮおよびシステム・マネージャは、前掲の図を参照して詳しく説明されたアクセス・ノード２０８の部分であることを理解されたい。モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、ステップ１２０２に示されるように、トラフィック・チャネル（「ＴＣＨ」）設定を無線ネットワーク・ノードと開始する。トラフィック・チャネルを確立すると、無線ネットワーク・ノード上のパケット制御機能（ＰＣＦ）は、ＰＤＳＮへ登録要求メッセージ１２０４を送信する。一実施形態では、ＰＣＦは、アクセス・ノード２０８において１組のＰＤＳＮを用いて構成されることができ、ＰＣＦは、例えば、負荷バランス機構やラウンド・ロビン機構などの内部選択メカニズムに基づいて、ＰＤＳＮを選択することができる。
【００５９】
図１２に示された実施形態では、ＰＤＳＮは、登録要求メッセージ１２０４を受信した場合、そのセッションにサービスを提供することができない。そのＰＤＳＮが新規セッションにサービスを提供するために使用できないのには、多くの理由が含まれ得る。ＰＤＳＮは、過剰な負荷がかかるため、セッションにサービスを提供することを拒否することがある。例えば、ＰＤＳＮは、新規セッションを拒否するまでにサービスを提供できるセッションの数を識別する閾値レベルをもつように構成されることができる。代替例として、ＰＤＳＮは、その容量を監視するように構成されることができ、容量の所定の割合が使用されている場合、新規セッションへのサービス提供を拒否することができる。更に、ＰＤＳＮは、その機能コンフィグレーションが原因で新規セッションへのサービス提供を拒否することもある。例えば、ＰＤＳＮは、圧縮または暗号を使用するセッションなどのような、所定のタイプのセッションだけにサービスを提供するように構成されることができる。
【００６０】
図１２に示された実施形態では、システム・マネージャは、代替ＰＤＳＮを決定する。従って、ＰＤＳＮは、システム・マネージャにＰＤＳＮ選択要求メッセージ２１０６を送信し、ステップ１２０８で、システム・マネージャは、１組の選択規則に基づいて新しいＰＤＳＮを選択する。選択規則は、以前の選択規則の記録およびサービス規則のタイプを含むことができる。一実施形態では、システム・マネージャは、１組の規則または異なる選択規則の組合せを使用するように構成されることができる。例えば、システム・マネージャは、着信セッションに対してサービスを提供できるＰＤＳＮのサブセットを決定するために１つの選択規則を使用することができ、その後、着信セッションに対するサービスを提供できる１つのＰＤＳＮを選択するために別の規則を使用することができる。
【００６１】
先の段落で述べられたように、システム・マネージャは、新しいＰＤＳＮを決定するために以前の選択規則の記録を使用することができる。そのような実施形態では、システム・マネージャは、モバイル・ノードにおける以前のセッションにサービスを提供したＰＤＳＮを決定および選択するために、モバイル・ユーザの以前の登録記録を使用する。一実施形態では、それぞれのＰＤＳＮは、コール設定が成功したときに、モバイル・ノードの登録記録を送信するように構成されることができる。
【００６２】
ＰＤＳＮを選択すると、システム・マネージャは、ＰＤＳＮへ、選択されたＰＤＳＮのＩＰアドレスを含むＰＤＳＮ選択応答メッセージ１２１０を送信する。ＰＤＳＮは、メッセージ１２１０を受信したとき、無線ネットワーク・ノードへ、選択されたＰＤＳＮのＩＰアドレスを含むＲＰ登録応答メッセージ１２１２を送信する。ＲＰ登録応答メッセージ１２１２は、ＲＦＣ２００２に記載されたメッセージ「エラー１３６（Ｅｒｒｏｒ １３６）」の形をとることができる。しかしながら、異なるタイプのメッセージが使用されることもできる。
【００６３】
次に、無線ネットワーク・ノードは、ＲＰ登録要求メッセージ１２１４を選択されたＰＤＳＮへ送信し、選択されたＰＤＳＮは、ステップ１２１６に示されるように、着信セッションにサービスを提供するために資源を割り当てる。選択されたＰＤＳＮが着信セッションにサービスを提供することを拒否することがあり、システム・マネージャに問い合わせるプロセスが繰り返されることがあることを理解されたい。そのような実施形態では、システム・マネージャは、ＰＤＳＮ選択要求が選択されたＰＤＳＮから送信されたと判断することができ、システム・マネージャは、要求を送信したＰＤＳＮのＩＰアドレスを含むＰＤＳＮ選択応答によって応答することができる。加えて、ＰＤＳＮ選択応答メッセージは、ＰＤＳＮがセッションにサービスを提供すべきことをＰＤＳＮに通知する所定のビットまたはビット・パターンなどのである識別子を含むことができる。更に、要求を処理することを拒否したＰＤＳＮの数を示す所定のビットまたはビット・パターンが、ＰＤＳＮ選択応答メッセージ内に設定されることができることを理解されたい。そのような実施形態では、ＰＤＳＮは、所定数のＰＤＳＮがセッションにサービスを提供することを拒否したときに、要求を受け入れるように構成されることができる。サービス遅延、即ち、多数のＰＤＳＮが新規セッションを拒否することを防止する異なる実施形態も使用され得ることを理解されたい。
【００６４】
資源を割り当てると、選択されたＰＤＳＮは、ＲＰ登録応答メッセージ１２１８を送信し、１２２０で示されるように、ＲＰセッションが、無線ネットワーク・ノードと選択されたＰＤＳＮとの間で確立される。更に、例示的な実施形態によれば、新規セッションへ資源を割当てると、選択されたＰＤＳＮは、システム・マネージャへ、選択されたＰＤＳＮの新しい負荷を含む更新メッセージ１２２２を送信する。更新メッセージ１２２２は、モバイル・ノードのＮＡＩまたはＩＭＳＩを含む、確立されたコール・セッションのためのセッション情報を含むことができる。代替例として、選択されたＰＤＳＮは、システム・マネージャへ、セッション情報を含む別個のメッセージを送信することができる。先の段落に関して述べられたように、モバイル・ノードが次に登録するときに、システム・マネージャは、最後のサービス提供ＰＤＳＮを決定するためにセッション情報を使用することができる。ステップ１２２４で、モバイル・ノードは、選択されたＰＤＳＮに対するポイントツーポイント・プロトコル（「ＰＰＰ」）セッションを確立し、選択されたＰＤＳＮに登録する。
【００６５】
図１３は、分散型制御ノード方法によるＰＤＳＮ選択を示すメッセージ・シーケンス・シナリオ１３００のブロック図である。分散型制御ノード機構では、アクセス・ノード内のそれぞれのＰＤＳＮカードは、アクセス・ノード２０８のすべてのＰＤＳＮの負荷情報を提供するようにシステム・マネージャへ定期的に要求することができる。代替例として、ＰＤＳＮは、アクセス・ノード２０８のすべてのＰＤＳＮから負荷情報を受信することができる。そのような実施形態では、それぞれのＰＤＳＮは、ＩＰマルチキャスト方法またはその他の現存の又は今後開発される伝送方式を使用して、他のＰＤＳＮへ負荷情報を提供することができる。図１３は、モバイル・ノードと、パケット制御機能を有する無線ネットワーク・ノードと、選択されたＰＤＳＮと、ＰＤＳＮと、システム・マネージャとを示している。
【００６６】
モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、無線ネットワーク・ノードへ、無線ネットワーク・ノードとのトラフィック・チャネルを確立するための要求を含むメッセージ１３０２を送信する。チャネルが確立されると、無線ネットワーク・ノードは、ＰＤＳＮへＲＰ登録要求メッセージ１３０４を送信する。パケット制御機能がそのＰＤＳＮテーブルに複数のＰＤＳＮ ＩＰアドレスを保持する実施形態では、パケット制御機能は、ＰＤＳＮのＩＰアドレスを決定するために負荷バランシング機構を使用することができる。代替例として、パケット制御機能は、プライマリＰＤＳＮのＩＰアドレスとセカンダリＰＤＳＮのＩＰアドレスとを含む２つのエントリだけをそのテーブルに保持することができる。そのような実施形態では、ＰＣＦは、プライマリＰＤＳＮが着信セッションに対してサービスできなくなるまで、すべての新規コール・セッション要求をプライマリＰＤＳＮへ送信することができる。プライマリＰＤＳＮが障害を起こすか又は負荷過剰になった場合、ＰＣＦは、セカンダリＰＤＳＮのＩＰアドレスへ新規コール・セッションを送ることができる。
【００６７】
図１３に示される実施形態によれば、ＰＤＳＮは、それが着信登録要求に対するサービスを提供できないこと、または少なくとも、そのＰＤＳＮが、好ましくは別のＰＤＳＮがコールを処理すべきであると判断される所定の閾値レベルより上にあることを決定する。ＰＤＳＮは、図１２を参照して説明された複数の要因に基づいて、その決定を下すことができる。
【００６８】
無線ネットワーク・ノードが選択を行い、選択されたＰＤＳＮのＩＰアドレスへＲＰ登録要求メッセージ１３１０を送信すると、選択されたＰＤＳＮは、１３１２に示すように、資源を新規セッションに割り当てる。次に、選択されたＰＤＳＮは、ＲＰ登録応答メッセージ１３１４を送信し、ＲＰセッション１３１６が、無線ネットワーク・ノードと選択されたＰＤＳＮとの間で確立される。更に、例示的な実施形態によれば、選択されたＰＤＳＮは、１３１８に示すように、その更新された負荷情報を最初のＰＤＳＮへ送信する。図１３は、選択されたＰＤＳＮから負荷情報を受信するＰＤＳＮを１つだけ示しているが、選択されたＰＤＳＮは、そのマルチキャスト・グループ内の他のＰＤＳＮへもその負荷を送ることができることを理解されたい。更に、後でより詳しく説明されるように、選択されたＰＤＳＮは、スタンバイＰＤＳＮへ、その新規コール情報を送信することができる。システム・マネージャも同様にマルチキャスト・グループの一員となり得ることを理解されたい。代替例として、選択されたＰＤＳＮは、ハートビート・メッセージによってその新しい負荷をシステム・マネージャへ送ることができる。
【００６９】
選択されたＰＤＳＮへの登録が成功すると、ＰＰＰセッションが、モバイル・ノードと選択されたＰＤＳＮとの間で確立され、モバイルが、１３２２に示すように、選択されたＰＤＳＮに登録される。
【００７０】
例示的な一実施形態によると、ＰＤＳＮに加えて、アクセス・ノードは、システム・マネージャによって管理されるＨＡも含むことができる。図１１を参照して述べられたように、アクセス・ノード内のすべてのＨＡは、ハートビートをシステム・マネージャに送信し、その負荷情報を定期的にシステム・マネージャへ送信する。ＰＤＳＮに関して説明された実施形態と同様に、システム・マネージャは、アクセス・ノードのそれぞれのＨＡに対する負荷を含む制御ノード・データベースを保持することができる。代替例として、制御ノード・データベースは、すべてのＨＡにわたって分散されることができ、それぞれの参加するＨＡは、他のすべての参加するＨＡの負荷情報を保持することができる。そのような実施形態において、それぞれの参加するＨＡは、ＩＰマルチキャストを使用して、他のＨＡ上のその負荷を更新することができ、すべての参加するＨＡおよびシステム・マネージャは、分散型制御ノード情報データベースをサポートするマルチキャスト・グループの一員であることができる。
【００７１】
図１４は、最初のＨＡが使用不可能なときにシステム・マネージャが新しいＨＡを選択する実施形態におけるＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオ１４００のブロック図である。図１４は、モバイル・ノードと、ＰＤＳＮと、システム・マネージャと、ＨＡと、選択されたＨＡと、ＨＡＡＡとを示している。
【００７２】
モバイル・ノードは、図１２および図１３を参照して説明された方法の１つを使用してＰＤＳＮとのＰＰＰセッションを確立するとき、ＰＤＳＮへＭＩＰ登録要求メッセージ１４０２を送信する。一実施形態では、登録要求メッセージ１４０２は、モバイル・ノードによって要求されるＨＡのＩＰアドレスを指定することができる。代替例として、ＰＤＳＮは、モバイル・ノード用のＨＡのＩＰアドレスを決定するために、ＦＡＡＡサーバにコンタクトすることができる。ＰＤＳＮは、１４０４で例示されるように、その後にＨＡへ登録要求メッセージを送る。図１４に示される実施形態によれば、ＨＡは、例えば、過剰負荷もしくは過剰負荷に近い状況のために、またはモバイル・ノードによって提示された静的モバイル・ノードＩＰアドレスが現在のＨＡのＩＰアドレス・プールに属していないために、コール・セッションを処理できないことを、決定する。ＨＡは、負荷マップに関してスタンバイＨＡと通信する。異なるメッセージ方式も、代替ホーム・エージェントのＩＰアドレスを取得するのに使用され得ることを理解されたい。
【００７３】
ＨＡは、スタンバイＨＡから冗長グループ内の他のＨＡの負荷情報を受信する。アクティブＨＡは、バックアップＨＡから負荷マップを含む定期的メッセージを受信する。この負荷マップは、冗長グループ内のそれぞれのＨＡの平均負荷と、最小負荷のものから４つの小負荷のＨＡの負荷とを含む。アクティブＨＡは、代替ＨＡを選択する必要があるかどうかを決定するために、この負荷情報を使用する。アクティブＨＡの負荷が平均負荷より一定の比率だけ大きくなった場合、アクティブＨＡは、負荷マップから、４つの小負荷のＨＡのうちで最小負荷のものを選択する。その後、モバイルＩＰ登録要求１４１０は、処理のために代替のＨＡへ送られる。
【００７４】
ステップ１４１６で、選択されたＨＡは、ＭＩＰ登録要求メッセージを認証し、モバイル・ノード用にＭＢＲを生成する。更に、選択されたＨＡは、ＰＤＳＮへのＩＰトンネルのネゴシエーションおよび設定を開始する。次に、選択されたＨＡは、ＭＩＰ登録応答メッセージ１４１８をＰＤＳＮへ送信し、ＭＩＰ登録応答メッセージ１４１８のホーム・エージェント・フィールドは、その選択されたＨＡのＩＰアドレスを含む。ステップ１４２０で、ＰＤＳＮは、モバイル・ノードのために選択されたＨＡへのＩＰトンネルおよびビジタ・リスト（ＶＬ）を作成する。ＰＤＳＮは、それぞれのモバイルＩＰコール用にＶＬを作成することができ、それぞれのＶＬは、サービングＨＡのＩＰアドレスと、モバイル・ノードのＩＰアドレスと、トンネリング・パラメータと、認証情報とを含むことができる。
【００７５】
ステップ１４２２で、ＰＤＳＮは、ＭＩＰ応答メッセージをモバイル・ノードへ送る。ステップ１４２４で、選択されたＨＡは、ＭＢＲ更新メッセージ１４２４もシステム・マネージャへ送信し、その後、システム・マネージャは、ステップ１４２６に示すように、ＭＢＲを更新するとＭＢＲ更新ＡＣＫメッセージ１４２８によって応答する。ＭＩＰセッションは、ステップ１４３０に示すように確立される。更に、ステップ１４３２で、選択されたＨＡは、その現在の負荷データを含む更新メッセージをシステム・マネージャへ送信する。
【００７６】
図１５は、ＨＡが分散型情報データベース機構に参加する、ＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。そのような実施形態では、それぞれのＨＡは、例えば、そのＨＡに過剰な負荷がかかっている場合に新しいＨＡを決定するように構成されることができる。更に、そのような実施形態では、それぞれの参加するＨＡは、スタンバイＨＡから、他の参加するＨＡの負荷更新情報を定期的に受信することができる。代替例として、ＨＡは、ＩＰマルチキャストを介してそれぞれの参加するＨＡから負荷情報を受信することができる。図１４と同様に、図１５は、モバイル・ノードと、ＰＤＳＮと、システム・マネージャと、ＨＡと、選択されたＨＡと、ＨＡＡＡとを示している。
【００７７】
ＰＤＳＮに対するＰＰＰセッションを確立すると、モバイル・ノードは、ＭＩＰ登録要求メッセージ１５０２をＰＤＳＮへ送信する。一実施形態では、ＭＩＰ登録要求メッセージは、モバイル・ノードによって要求されたＨＡのＩＰアドレスを含むことができる。代替例として、ＰＤＳＮは、そのモバイル・ノード用のＨＡのＩＰアドレスを決定するために、ＦＡＡＡに問い合わせることができる。次にＰＤＳＮは、ステップ１５０４に示されるように、登録要求メッセージをＨＡへ送る。
【００７８】
ＨＡは、ＭＩＰ登録要求メッセージ１５０４を受信すると、その要求にサービスを提供できないと決定し、ステップ１５０６に示されるように、新しいＨＡを選択する。図１５に示される例示的な実施形態によれば、ＨＡは、分散型情報データベースに参加し、それによって、この方式に参加する他のＨＡの負荷情報を有する。従って、選択基準は、それぞれのＨＡの負荷に基づくことができ、その選択において、ＨＡは、例えば、最低の負荷、セッション・タイプ、コール・データ速度、またはユーザに関連するサービス・タイプを有するＨＡを選択する。ＨＡは、その後、ステップ１５０８で示されるように、ＭＩＰ登録要求を、選択されたＨＡへ送る。
【００７９】
更に、選択されたＨＡは、アクセス要求メッセージをＨＡＡＡに送信することができ、ＨＡＡＡは、アクセス承認メッセージ１５１２によって応答する。ステップ１５１４で、選択されたＨＡは、ＭＩＰ登録要求メッセージを認証し、ＭＢＲを生成し、ＰＤＳＮに対するＩＰトンネルを設定する。ステップ１５１６で、選択されたＨＡは、ＭＩＰ応答メッセージをＰＤＳＮに送信し、ＰＤＳＮはそれに応答して、１５１８に示されるように、モバイル・ノードのためのビジタ・リスト（ＶＬ）を生成し、選択されたＨＡに対するＩＰトンネルを設定する。ステップ１５２０で、ＰＤＳＮは、ＭＩＰ登録応答メッセージをモバイル・ノードへ送り、ステップ１５３２に示されるように、ＭＩＰセッションが確立される。
【００８０】
ステップ１５２２で、選択されたＨＡは、ＭＢＲ更新をシステム・マネージャへ送信し、システム・マネージャは、ステップ１５２４で、ＭＢＲを更新し、ＭＢＲ ＡＣＫメッセージ１５２６を送信する。更に、ステップ１５２８で、選択されたＨＡは、分散型データベース機構に参加するＨＡへ更新メッセージを送信し、その更新メッセージは、ＨＡの現在の更新された負荷を含む。図１５は、更新メッセージ１５２８を受信するＨＡを１つだけ示している。しかしながら、ＨＡはすべての参加するＨＡによって受信されるＩＰマルチキャストを生成できることを理解されたい。更に、更新メッセージは、スタンバイＨＡによっても受信される。ＨＡは、スタンバイＨＡ用に排他的メッセージを生成できることや、代替例として、１５３０に示されるように、スタンバイＨＡのＩＰアドレスもマルチキャスト・グループへ含まれ得ることも理解されたい。
【００８１】
負荷バランシング、および、さもなければ着信通信セッションの選択的なルーティングおよび再ルーティングに加えて、制御シェルフおよびデータ・シェルフのコンポーネントは、フェイルオーバ機能をもつ冗長性を示す。例えば、図５に示され且つそれを参照して説明された制御シェルフは、２つのシェルフ・コントローラ５０２および５０４と、２つのシステム・マネージャ５１０および５１２とを含む。そのような実施形態では、システム・マネージャ／シェルフ・コントローラの一つがアクティブのシステム・マネージャ／シェルフ・コントローラとして構成され、他の１つは冗長（スタンバイ）システム・マネージャ／シェルフ・コントローラとして構成される。従って、アクティブ・ユニットが障害を起こした場合、冗長ユニットが障害を検出し、アクティブ・ユニットの役割を引き継ぐことができる。
【００８２】
スタンバイ・システム・マネージャおよびシェルフ・コントローラは、それらのアクティブ・パートナとのハートビート動作を実行して、アクティブ・パートナが使用できないことを決定することができる。スタンバイ・エンティティは、そのハートビート・タイマがタイムアウトになるたびに、ハートビート要求メッセージを送信することができ、アクティブ・エンティティは、アクノレッジメント（肯定応答）メッセージによって応答することができる。肯定応答メッセージが受信されない場合、スタンバイ・エンティティは、そのアクティブ・エンティティが動作していないと仮定することができる。代替例として、コンフィグレーションに基づいて、アクティブ・エンティティは、ハートビートを再送信することができ、それに対する応答が受信されない場合、そのパートナが動作していないと仮定することができる。更に、例示的な一実施形態によれば、結び合わされた対の各メンバは、そのパートナのデータの完全なミラー・イメージを有する。例えば、それぞれのＰＤＳＮまたはＨＡは、それぞれのシステム・マネージャとの２つの別個の物理的リンクをもち、それにより、アクティブ・システム・マネージャおよびバックアップ・システム・マネージャは同時に同じ情報を受信する。代替例として、アクティブ・システム・マネージャは、１または複数のＰＤＳＮまたはＨＡから、更新された負荷情報を受信することができ、そして、その受信した情報を例えばシステムのデータ・バスを介してスタンバイ・システム・マネージャへ渡すことができる。
【００８３】
更に、それぞれのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）は、１対１の冗長性を提供するために、結び合わされた対として構成されることができ、１対のパートナにおけるそれぞれのＰＤＳＮは、他方のパートナのためのバックアップとして機能する。新規セッションがＰＤＳＮに到着すると、ＰＤＳＮは、そのパートナへセッションに関連するすべての状態情報を送信する。同様に、セッション状態情報は、状態が変化したときにも、パートナに渡される。従って、結び合わされた対の各メンバは、そのパートナのセッションの完全なミラー・イメージを有する。例示的な実施形態によれば、ＰＤＳＮ／ＨＡは、スイッチ出口モジュールまたは内部バスを介して通信することができる。更に、パートナＰＤＳＮ／ＨＡは、プライマリＰＤＳＮが障害を起こした場合にセッションを引き継ぐことができる。例示的な一実施形態によれば、ＰＤＳＮ／ＨＡは、同時係属中の特許出願第１０／０４１４３６号、「Ｓｍｏｏｔｈ Ｈａｎｄｏｆｆ ｖｉａ Ｓｔａｔｅ Ｅｘｃｈａｎｇｅ ｉｎ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋ」で説明されているハンドオフ方法を使用することができ、この出願の全体を参照によって本明細書に組み込むものとする。
【００８４】
複数のコンフィグレーション方式が、機能的冗長性を達成するために使用され得ることを理解されたい。例えば、上で述べられたように、２つのＰＤＳＮ／ＨＡは、プライマリおよびセカンダリ（バックアップ）のＰＤＳＮ／ＨＡとして対をなすように構成されることができ、プライマリＰＤＳＮ／ＨＡは、サービスできなくなるまで、すべてのセッションを処理する。そのような実施形態では、バックアップＰＤＳＮ／ＨＡは、プライマリＰＤＳＮ／ＨＡの障害時にその機能を引き継ぐ受動的な非アクティブなバックアップである。更に、セカンダリまたはバックアップのＰＤＳＮ／ＨＡは、内部媒体データ・バスを介してプライマリＰＤＳＮ／ＨＡで受信されるすべてのトラフィックのミラー・イメージを受信し、また、バックアップＰＤＳＮ／ＨＡは、外部にデータを伝える能力をもたない。そのような実施形態では、バックアップ・アプリケーション・モジュールの外部インタフェースでバックアップ・アプリケーション・モジュールを出ていくすべてのデータは、除去される。
【００８５】
プライマリ／バックアップ・コンフィグレーションでは、システム・マネージャは、シェルフ内のすべてのアクティブ・カードの活動ステータスを監視する。これを行うために、システム・マネージャは、インターネット・エンジニアリング・タスク・フォース（「ＩＥＴＦ」）のリクエスト・フォー・コメント（「ＲＦＣ」）１１５７に完全に説明されているシンプル・ネットワーク・マネジメント・プロトコル（「ＳＮＭＰ」）を使用することができ、この文献を参照によって本明細書に組み込むものとする。一実施形態では、ＳＮＭＰは、管理情報ベース（「ＭＩＢ」）（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）を含むＰＤＳＮ／ＨＡにポーリングを行うため使用されることができる。更に、システム・マネージャは、それぞれのカードのステータスを決定するために、コモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ（「ＣＯＲＢＡ」）（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）を基にする方法を使用することができる。ＳＮＭＰを使用して、システム・マネージャは、障害のあるＰＤＳＮ／ＨＡがＳＮＭＰポーリングに応答しない場合、ＰＤＳＮ／ＨＡの障害を検出することができる。プライマリＰＤＳＮ／ＨＡが障害を起こしたとき、システム・マネージャは、バックアップＰＤＳＮ／ＨＡへメッセージを送信し、バックアップＰＤＳＮ／ＨＡは、プライマリＰＤＳＮ／ＨＡとして動作する。更に、バックアップＰＤＳＮ／ＨＡは、引継ぎを行うと、アドレス解決プロトコル（「ＡＲＰ」）（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージを外部ルータへ送信して、データが、障害を起こしたＰＤＳＮ／ＨＡではなくバックアップＰＤＳＮ／ＨＡへ送られるようにする。また、プライマリＰＤＳＮ／ＨＡが障害を起こしたとき、バックアップＰＤＳＮ／ＨＡは、プライマリ・カードと同じ外部ＩＰアドレスを使用する。
【００８６】
冗長性のための別の例示的な実施形態によれば、２つの結び合わされたＰＤＳＮ／ＨＡがアクティブであり、通信セッションを処理することができる。そのような実施形態では、プライマリＰＤＳＮ／ＨＡは、アクティブ通信セッションのみについてデータを媒体データ・バスを介してバックアップＰＤＳＮ／ＨＡへ送信し、セッションが休止状態になった場合、バックアップＰＤＳＮ／ＨＡは、セッション情報をそのメモリから削除し、一方、プライマリＰＤＳＮ／ＨＡはなおもそれを保持し続ける。そのような実施形態では、このタイプの冗長性をサポートするためのメモリ要件は最低限に抑えられ、アクティブ・セッションだけがバックアップＰＤＳＮ／ＨＡにキャッシュされて、プライマリＰＤＳＮ／ＨＡが障害を起こした場合の速やかな切替えに備える。更に、アクティブ・カードは、バックアップされるセッションのデータ処理を省くために、アクティブ・セッションの制御データだけを送信することができる。バックアップＰＤＳＮ／ＨＡが引継ぎを行うと、バックアップ・モジュール（今はプライマリ・モジュールである）は、ＡＲＰメッセージを外部ネットワーク・エンティティへ送り、障害を起こしたカードのＩＰアドレスを、その関連ネットワーク・インタフェース、例えばＲ−ＰインタフェースやＰｉインタフェースなどに結び付ける。
【００８７】
更に、代替例としては、１対１の冗長性の代わりに、シャーシ内の１つのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）が、他のすべてのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）用のバックアップとして割り当てられ、その結果として、Ｎ対１の冗長性を生み出すことができる。Ｎ対１の冗長性の方式は、大多数の通信セッションがしばしば休止中となる通信システムでは望ましいことがある。従って、冗長とされるべきであり且つデータおよびコールの喪失を回避するためのシステムの場合、バックアップ・モジュールが、アクティブ・セッションのために必要とされる。そのような実施形態では、単一のバックアップ・モジュールによってバックアップされ得るプライマリ・モジュールの数は、Ｎ個のＰＤＳＮ／ＨＡのアクティブ・セッションをバックアップするのに必要とされるメモリ量に基づいて決定されることができる。
【００８８】
Ｎ対１の冗長性の方式では、すべてのアクティブ・モジュールは、コールの状態に影響する制御および何らかのデータ情報を１つのバックアップ・モジュールへ送信する。Ｎ個のＰＤＳＮ／ＨＡのうちの１または複数のものが障害を起こした場合、システム・マネージャは、障害モジュールについてバックアップ・モジュールへ通知し、バックアップ・モジュールは、障害モジュールに対するネットワーク・インタフェースを提供する。
【００８９】
スタンバイＰＤＳＮにおいて最小限の通信トラフィックと記憶要件とをもった望ましいＮ対１の冗長性を達成するために、回復不能状態だけがスタンバイＰＤＳＮへ転送される。Ｎ個のアクティブＰＤＳＮによってスタンバイＰＤＳＮへ転送される更新は、適用されるデータのタイプおよび送信される頻度に基づいてカテゴリに分割される。
【００９０】
本明細書で開示される実施形態のデータ・タイプには以下のものがある。
ＰＤＳＮ全体の状態およびすべてのコールに適用される「ＰＤＳＮ毎データ」。ＰＤＳＮ毎状態の例は、気付ＩＰアドレス、ＭＡＣアドレスなどを含む。
特定のＨＡおよびそのＨＡ上のすべてのコールに関連する状態を含む「ホーム・エージェント（ＨＡ）毎データ」。ＨＡ毎状態の例は、ＨＡ ＩＰアドレス、ＦＡ−ＨＡ ＳＰＩおよびキーなどを含む。
特定のコールだけに属する状態である「コール毎データ」。コール毎状態の例は、ＰＰＰ状態、モバイルＩＰ（ＭＩＰ）状態などを含む。
本明細書で開示される実施形態の更新タイプには以下のものがある。
ただ１度のみ送信されることを想定した「静的更新」。静的更新は２度以上送信されることもできるが、その想定される頻度はきわめて低い。静的更新の例は、ＳＩＰコールのホームＩＰアドレスであり得る。
ＰＤＳＮ外部の発信源からの情報受信またはＰＤＳＮ内の状態変化に応答して送信される「トリガされた更新」。トリガされた更新の例は、ＰＣＦからの休止指示、ＰＰＰアイドル・タイマのタイムアウトなどである。
非常に速やかに変化する、場合によっては、ユーザによって送信または受信されるパケット毎に変化するデータを送信する「動的更新」。
【００９１】
後で説明される実施形態の場合、Ｎ個のアクティブＰＤＳＮカードおよびスタンバイＰＤＳＮカードのそれぞれは、図１１に関して先に説明されたように、システム・マネージャによってアクティブ／スタンバイの役割を割り当てられる。システム・マネージャは、それぞれのアクティブＰＤＳＮへ、その関連づけられたスタンバイＰＤＳＮを、役割割当てプロトコルの一部として通知する。
【００９２】
ＰＤＳＮのＮ対１の冗長性を使用するシステムの例示的な実施形態が、シンプルＩＰコールに関して図１６に示されている。図面中の実施形態の場合、１つのアクティブＰＤＳＮ２１８が示されており、本明細書に示され説明される１つのアクティブＰＤＳＮの通信について把握している１つのスタンバイＰＤＳＮ２２０は、Ｎ個のアクティブＰＤＳＮのそれぞれに対して複製されている。アクティブＰＤＳＮとスタンバイＰＤＳＮとの間の通信は、先に図８に関して説明されたようなシステム制御バスを使用して、図示の実施形態において実行される。ＰＤＳＮの選択およびＲＰセッションの確立は、図１２に関して説明されるように達成される。セッションが確立されると、アクティブＰＤＳＮは、ＲＰ更新１６０２をスタンバイＰＤＳＮへ提供する。ＲＰ更新は、新しいコールＩＤおよびＲＰ状態についてのデータを含む。それぞれのコールは、アクティブＰＤＳＮに対して一意のコール識別子で識別される。ＲＰ状態に関して送信されるデータが表１に示されている。
【００９３】
【表１】
【００９４】
図１２に関して先に説明されたように、モバイル・ノードは、パスワード認証プロトコル（「ＰＡＰ」）（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）またはチャレンジ・ハンドシェイク認証プロトコル（「ＣＨＡＰ」）（Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用するリンク制御プロトコル（「ＬＣＰ」）（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を含むステップ１６０４に示すように、選択されたＰＤＳＮとのＰＰＰセッションを確立し、選択されたＰＤＳＮに登録する。アクセス要求およびアクセス応答通信１６０６は、図２に関して先に説明されたように、アクティブＰＤＳＮとＨＡＡＡ２１６またはＦＡＡＡ２１４との間で行われる。
【００９５】
ステップ１６０８においてＩＰ制御プロトコルがＰＰＰセッションでネゴシエートされると、アクティブＰＤＳＮは、ステップ１６１０において、コールＩＤ、ＰＰＰ状態、およびＡＡＡプロフィールについてスタンバイＰＤＳＮを更新する。ＰＰＰ状態はコール毎に定められ、表２で定義されるようなＬＣＰデータと、表３で定義されるようなＰＡＰ／ＣＨＡＰデータと、表４に示されるようなＩＰＣＰデータとを含む。ＰＡＰまたはＣＨＡＰ状態自体は存在しないので、必要とされるデータは、表３に示されるように、使用されるプロトコルの記録（レコード）とユーザの認証とに限定される。
【００９６】
【表２】
【００９７】
【表３】
【００９８】
【表４】
【００９９】
ＡＡＡプロフィールは、アクセス応答においてＨＡＡＡから返されるＲＡＤＩＵＳパラメータのグループを構成し、表５に示されるパラメータを含むことができるが、これらに限定されるものではない。
【０１００】
【表５】
【０１０１】
圧縮制御プロトコル（「ＣＣＰ」）（Ｃｏｍｐｒｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が、ステップ１６１２に示されるように、モバイル・ノードとアクティブＰＤＳＮとの間でネゴシエートされる場合、表６に示されるＣＣＰ状態を提供するために、別個のＰＰＰ更新１６１４が、スタンバイＰＤＳＮに対して行われる。
【０１０２】
【表６】
【０１０３】
ユーザ・データが、ステップ１６１６に示されるように送信され始めると、アカウンティング（会計）目的の使用データ記録（「ＵＤＲ」）情報は、ステップ１６１８に示されるように、スタンバイＰＤＳＮと定期的に同期させられる。例示的なＵＤＲデータが表７に示されている。
【０１０４】
【表７】
【０１０５】
図１７は、モバイルＩＰアプリケーションのためのＮ対１のＰＤＳＮ冗長性のデータ更新構造を示している。先に図１６でシンプルＩＰの場合について説明されたように、１２２０でＲＰセッションが確立された後、ステップ１７０２で、コールＩＤおよび表１で定義されるＲＰ状態が、スタンバイＰＤＳＮへ送信される。シンプルＩＰの場合と異なり、モバイルＩＰアプリケーションでは、ＰＰＰは、ステップ１７０４に示されるように、ＬＣＰとネゴシエーションを行い、認証をスキップし、その後、ＩＰＣＰを完了する。その後、ステップ１７０６で、アクティブＰＤＳＮは、コールＩＤおよびＰＰＰ状態についてスタンバイＰＤＳＮを更新する。その後、ステップ１７０８で、ＰＰＰは、コールに対するＣＣＰを確立し、１７１０で、スタンバイＰＤＳＮは、表６に示されるようなＣＣＰ状態が更新される。ステップ１７ｌ２で、アクティブＰＤＳＮは、エージェント広告をモバイル・ノードへ送信し、その後、ステップ１７１４で、スタンバイＰＤＳＮでＭＩＰ状態が更新される。モバイル・コール毎データおよびホーム・エージェント毎データについてのＭＩＰ状態が、それぞれ、表８および表９に示されている。
【０１０６】
【表８】
【０１０７】
【表９】
【０１０８】
ＭＩＰ登録は、先に図１および図２に関して説明されたように、モバイル・ノードによるＭＩＰ登録要求（「ＲＲＱ」）１７１６と、アクティブＰＤＳＮとＨＡＡＡまたはＦＡＡＡとの間でのアクセス要求およびアクセス応答の通信１７１８と、それに続いての、アクティブＰＤＳＮとホーム・エージェントとの間でのＭＩＰ ＲＲＱ１７２０およびＭＩＰ登録応答（「ＲＲＰ」）１７２２の通信とによって、実行される。アクティブＰＤＳＮによるモバイル・ノードへのＭＩＰ ＲＲＰ１７２４の送信がなされると、１７２６で、スタンバイＰＤＳＮは、表５に定義されるようなＭＩＰ状態とＡＡＡプロフィールについて再度更新される。次に１７２８で、ユーザ・データが、モバイル・ノードとアクティブＰＤＳＮとの間で送信され始め、１７３０で、定期的なＵＤＲ更新１７３０が表７に定義されるようなアカウンティング・データを伴ってスタンバイＰＤＳＮへ送られる。ＭＩＰ再登録１７３２は、ステップ１７１６、１７１８、１７２０、１７２２、および１７２４を繰り返すコールの間に定期的に行われ、その結果、ＭＩＰ状態についてのスタンバイＰＤＳＮのＭＩＰ更新１７３４がなされる。その後、ステップ１７３６に示されるように、ユーザ・データ・フローが、スタンバイＰＤＳＮに対する定期的なＵＤＲ更新１７３８を伴いながら継続する。
【０１０９】
図１８に示されるＭＰＡコールが最初にシンプルＩＰコールと同様の方式で処理される。セッション１２２０を確立すると、アクティブＰＤＳＮは、スタンバイＰＤＳＮへＲＰ更新１８０２を提供する。ＲＰ更新は、新しいコールＩＤおよび表１で示されるＲＰ状態についてのデータを含む。モバイル・ノードは、選択されたＰＤＳＮとのＰＰＰセッションを確立し、ＰＡＰまたはＣＨＡＰを使用するＬＣＰを含むステップ１８０４に示されるように、選択されたＰＤＳＮに登録する。アクセス要求およびアクセス応答通信１８０６が、先に図２に関して説明されたように、アクティブＰＤＳＮとＨＡＡＡ２１６またはＦＡＡＡ２１４との間で行われる。ステップ１８０８で、ＰＰＰセッションにおいてＩＰ制御プロトコルがネゴシエートされると、ステップ１８１０で、アクティブＰＤＳＮは、コールＩＤ、ＰＰＰ状態、およびＡＡＡプロフィールについてスタンバイＰＤＳＮを更新する。ＰＰＰ状態は、コール毎に定義され、表２に定義されたＬＣＰデータと、表３に定義されたＰＡＰ／ＣＨＡＰデータと、表４に示されたＩＰＣＰデータとを含む。やはり、ステップ１８１２に示されるように、ＣＣＰがモバイル・ノードとアクティブＰＤＳＮとの間でネゴシエートされる場合、表６に示されるようなＣＣＰ状態を提供するために、別個のＰＰＰ更新１８１４が、スタンバイＰＤＳＮに対して行われることになる。
【０１１０】
この時点で、アクティブＰＤＳＮは、ＭＩＰ ＲＲＱ１８１６およびＭＩＰ ＲＲＰ１８１８によって、ＨＡとのプロキシＭＩＰセッションを開始する。その後、アクティブＰＤＳＮは、スタンバイＰＤＳＮへＭＩＰ更新１８２０を提供し、次に、ステップ１８２２に示されるように、ドメイン・ネーム・システム（「ＤＮＳ」）アドレスを送信するために、モバイル・ノードとＩＰＣＰを再ネゴシエートする。その後、ＰＰＰ更新１８２４が、スタンバイＰＤＳＮへ提供される。先のコール・タイプと同様に、ステップ１８２６に示されるように、ユーザ・データ送信が開始すると、表７に示されるようなアカウンティング・データとともに定期的なＵＤＲ更新１８２８がスタンバイＰＤＳＮに提供される。
【０１１１】
本明細書で開示される実施形態の場合、更新は、イベントまたは運用者によって設定されるコンフィグレーション可能トリガであるＰＤＳＮ更新タイマによって制御される。更新タイマは、アカウンティング・データ（先に図１６〜図１９に関して説明されたＵＤＲ更新）がアクティブＰＤＳＮによってスタンバイＰＤＳＮへ送られる頻度を、制御する。様々なコール・タイプの実施形態について説明された更新およびスタンバイＰＤＳＮへ送信される状態更新のトリガとなるイベントが、表１０にまとめられている。
【０１１２】
【表１０】
【０１１３】
表１０に示されるように、ＲＰ接続に関連するトリガは、コールの確立後に起こされたものである場合、ＲＰ状態情報および他のＵＤＲ情報の更新を引き起こす。同様に、モバイルＩＰコールについては、ＭＩＰネゴシエーションの要素が状態更新をトリガする。ＰＰＰの確立は、コールに関連する実質的状態データについての更新をトリガする。
【０１１４】
コール終了は、更なる状態更新のトリガを提供する。アクティブＰＤＳＮからコール終了の指示を受信すると、スタンバイＰＤＳＮは、終了されたコールに関連するコール状態を削除する。コール終了は、表１１にまとめられている。
【０１１５】
【表１１】
【０１１６】
スタンバイＰＤＳＮのフェイルオーバ動作が図１９に示されている。ハートビート・プロトコル１９０２を介して、Ｎ個のアクティブＰＤＳＮの１つが障害を起こしたと判断すると、システム・マネージャは、ステップ１９０４で、その障害および障害のあるＰＤＳＮのアクティブ・ステータスの引継ぎを、スタンバイＰＤＳＮへ通知し、そして、状態更新送信を中断するために、スタンバイＰＤＳＮがアクティブ・ステータスに遷移したことを残りのＮ−１個のアクティブＰＤＳＮへ通知する。スタンバイＰＤＳＮは、ステップ１９０６で、残りのＮ−１個のアクティブＰＤＳＮ用のすべての状態情報を廃棄し、それぞれステップ１９０８と１９１０で、ＲＰインタフェースおよびＰｉインタフェースへ障害ＰＤＳＮのアドレスを伴うＡＲＰメッセージを送信する。その後、スタンバイＰＤＳＮは、ステップ１９１２で、それまでアクティブＰＤＳＮによって処理されていたモバイル・ノードとのすべての通信を引き継ぐ。フェイルオーバが起きた後、ＩＰセキュリティ（「ＩＰｓｅｃ」）状態は再び初期設定される。
【０１１７】
再初期設定は、ＲＦＣ２４０９に従って達成される。ＩＰｓｅｃポリシ・ファイルのすべての静的ＩＰｓｅｃ情報は、システム・スタートアップで同期される。動的ＩＰｓｅｃ情報は、ユーザ・プロファイル・データ（表５の事前共有機密を参照）の一部としてＨＡＡＡ／ＦＡＡＡから返されたインターネット鍵交換（「ＩＫＥ」）（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ」）鍵を含む。
【０１１８】
ＰＤＳＮ−ＰＤＳＮ（「Ｐ−Ｐ」）インタフェースにおけるスタンバイＰＤＳＮの動作は、先に説明されたシナリオに類似している。図２０は、Ｐ−ＰセッションにおけるターゲットＰＤＳＮ２００２とアンカ（anchor）ＰＤＳＮ２００４とを示す。図２１ａに示されるように、２１０２で、ターゲットＰＤＳＮとのセッションがモバイル・ノードによって確立され、２１０４で、アンカＰＤＳＮとのＰ−Ｐトンネルが確立される。ターゲットＰＤＳＮを収容するラックまたはシェルフでは、セッションが確立された後、表１２に示されるような更新データ２１０６がスタンバイＰＤＳＮに提供される。
【０１１９】
【表１２】
【０１２０】
同様に、ターゲットＰＤＳＮを収容するラックまたはシェルフ内のスタンバイＰＤＳＮに提供される更新データ２１０８が表１３に示されている。
【０１２１】
【表１３】
【０１２２】
Ｐ−ＰトンネルにおいてアンカＰＤＳＮ２００４の障害が、ハートビート通信２１１０を介してそのラックまたはシェルフ内のシステム・マネージャ２１０１によって見つけだされると、図２１ａに示されるように、スタンバイＰＤＳＮは、ステップ２１１２で、システム・マネージャによってアクティブとして割り当てられ、Ｐ−Ｐトンネルは、ターゲットＰＤＳＮ２１０４へＰ−Ｐ登録更新２１１４を送信することによって終了させる。ターゲットＰＤＳＮは、ＬＣＰコンフィグ（ＬＣＰ−ｃｏｎｆｉｇ）２１１６をモバイルへ送信して、ＰＰＰ再ネゴシエーション２１１８を強制する。同様に、Ｐ−ＰトンネルにおいてターゲットＰＤＳＮの障害が、ハートビート通信２１２０を介してそのラックまたはシェルフ内のシステム・マネージャ２１２１によって検出されると、図２１ｂに示されるように、スタンバイＰＤＳＮは、ステップ２１２２で、システム・マネージャによってアクティブとして割り当てられ、Ｐ−Ｐトンネルは、アンカＰＤＳＮへＰ−Ｐ登録解除２１２４を送信することによって終了させる。その後、障害のあるターゲットＰＤＳＮのために動作するスタンバイＰＤＳＮは、ＬＣＰコンフィグ２１２６をモバイル・ノードへ送信して、ＰＰＰ再ネゴシエーション２１２８を強制する。それぞれの場合におけるＰ−Ｐトンネルの速やかな終了は、モバイルが迅速な方法でターゲットＰＤＳＮとのＰＰＰセッションに移ることを可能にする。
【０１２３】
図２２に示されるように、障害ＰＤＳＮが復旧または置換（交替）されると、システム・マネージャは、ハートビート検出２２０２を受信し、交替したＰＤＳＮを２２０４でスタンバイＰＤＳＮとして再割り当てし、２２０６でその割当てをアクティブＰＤＳＮに通知する。その後、２２０８で、アクティブＰＤＳＮは、上で説明されたように、確立されるそれぞれの新規セッションについて更新データの送信を開始する。
【０１２４】
更に、代替例として、Ｎ対Ｍの冗長性の方式も使用されることができる。これらの代替実施形態の幾つかでは、Ｎ対１の冗長性で使用される方法が、システム・マネージャによって割り当てられるスタンバイ・ユニットが複数となるように拡張される。また、Ｎ対Ｍの冗長性は、バックアップ・セッション情報だけを保存し且つコール処理のためには使用されないようにした特別な目的のモジュールをシャーシ／シェルフに備えることによって、更に別の代替実施形態でも達成されることができる。そのような実施形態では、バックアップ・モジュールは、アクティブおよび休止中のセッションの両方をキャッシュ記憶できるだけの十分なメモリを有し、制御情報だけが、それらのモジュールにミラーリングされる。そのような実施形態では、コール・セッションを処理するすべてのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）は、例えば、セッション到来時、セッション状態変更時、またはセッション切断時に、セッション情報を冗長モジュールへ送信する。冗長モジュールは、すべてのアクティブ・アプリケーション・モジュールのために受信情報を整理することができる。アプリケーション・モジュールが障害を起こすと、システム・マネージャは、事前に割り当てられたＭ個のモジュールのリストからバックアップ・モジュールを選択することができる。システム・マネージャは、Ｍ個のモジュールの相対負荷に基づいて、バックアップ・モジュールを選択することができる。そのような実施形態では、選択されたバックアップ・モジュールは、障害モジュールのセッション情報を、その情報を保持するＭ個のモジュールの１つから転送しなければならない。例えば、すべてのコール・セッション情報を要求する代わりに、バックアップ・モジュールは、速やかな切替えのためにアクティブ・セッション情報だけを要求することができ、後にその負荷に基づいて休止中セッション情報を取得することもできる。先の段落で説明された冗長性の方式と同様に、Ｍ個のバックアップ・モジュールは、内部の媒体データ・バスを介して通信することができる。更に、選択されたバックアップ・モジュールは、障害モジュールのネットワーク・インタフェースを引き継ぐためにルータなどのような外部デバイスへＡＲＰメッセージを送信する。
【０１２５】
上で説明されたＰＤＳＮの冗長性についての実施形態は、ＰＰＰ通信ネットワークの一般的なデバイスに適用可能である。ＰＰＰは、多くの通信システムがレイヤ３プロトコルを送るのに使用するレイヤ２プロトコルである。最も一般的に使用されるレイヤ３プロトコルは、インターネット・プロトコル（ＩＰ）である。使用可能ではあるが普通は使用されないその他のプロトコルも存在する。そのようなプロトコルの１つがＩＰＸである。
【０１２６】
ＰＰＰは、様々な物理的媒体上で使用される。これらの物理的媒体に加えて、ＰＰＰは、他の上位レイヤ・プロトコルを介してトンネリングされることもできる。物理的媒体の一例は、Ｖ．３５、Ｖ．９０などの様々なモデム・プロトコルを使用するモデム・ダイヤルアップ・リンクである。ＰＰＰが転送されるトンネリング・プロトコルの一例は、レイヤ２トンネリング・プロトコル（Ｌ２ＴＰ）である。
【０１２７】
様々な物理的媒体およびトンネリング媒体上のＰＰＰが、様々な提供物（ｏｆｆｅｒｉｎｇ）におけるデバイスを接続するために産業上において広く使用されている。そのような提供物およびデバイスの例とては、ＩＰパケットを転送（トランスポート）するためにレイヤ２リンクを確立するためにＰＰＰがＰＰＰｏＥ（ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（登録商標））を介して転送されるＤＳＬや、Ｖ．３５、Ｖ．９０などのモデム・プロトコルを介してＰＰＰが転送されるＲＡＳや、先に説明された例示的な実施形態において示されたような汎用ルーティング・カプセル化（ＧＲＥ）（Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）トンネルを介してＰＰＰが転送されるＰＤＳＮや、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）・トンネルを介してＰＰＰが転送されるＧＧＳＮや、レイヤ２トンネリング・プロトコル（Ｌ２ＴＰ）・トンネルを介してＰＰＰが転送されるＬＮＳ／ＬＡＣがある。
【０１２８】
これらのデバイスのすべてにおいて、無中断サービスを提供するために冗長性の方式が重要である。どのような冗長性の方式も、スタンバイ・ユニットにバックアップされるには、これらのデバイスにおいてＰＰＰセッションを必要とする。クライアント・デバイスとアクセス・デバイスとの間のＰＰＰ手順は、上で説明されたすべてのデバイスにおけるものと同じである。従って、上で説明されたＰＤＳＮの実施形態のために具体的に定められた手順は、これらのデバイスすべてのための一般的なＰＰＰバックアップ手順として適用可能である。
【０１２９】
一般的なＰＰＰデバイスのスタンバイ・バックアップのための冗長性の方式は、ＰＰＰに関しては、少なくとも以下のモジュールのバックアップ、即ち、リンク制御プロトコル（ＬＣＰ）パラメータ、認証パラメータ、インターネット・プロトコル制御プロトコル（ＩＰＣＰ）パラメータ、および圧縮パラメータのバックアップを提供する。プライマリ・デバイスの障害時には、パラメータがバックアップされているスタンバイ・デバイスが、そのパラメータを使用してＰＰＰコンテキストを再構築し、障害を起こしたプライマリ・デバイスの役割を引き継ぐ。
【０１３０】
図２３に示されるコール・フローは、ＰＰＰセッションをバックアップするために本発明によって提供される、アクティブＰＰＰアクセス・デバイス２３０２とバックアップＰＰＰアクセス・デバイス２３０４との間の一般的な手順を示している。一般的なクライアント・デバイス２３０６は、媒体確立２３０８によってアクティブ・アクセス・デバイスとのセッションを確立する。アクティブ・アクセス・デバイスは、コンテキスト生成メッセージ２３１０を送る。バックアップ・アクセス・デバイスは、セッションについてのコンテキスト生成２３１２を行う。クライアント・デバイスとアクティブ・アクセス・デバイスとは、ＬＣＰ確立２３１４を行い、その後、アクティブ・アクセス・デバイスは、ＬＣＰ更新２３１６をバックアップ・アクセス・デバイスへ提供し、その後、バックアップ・アクセス・デバイスは、セッション用に保存されているコンテキストの更新２３１８を行う。クライアント・デバイスとアクティブ・アクセス・デバイスは、認証手順２３２０を交換し、アクティブ・アクセス・デバイスは、確認認証手順２３２４によって認証デバイス２３２２と通信する。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、認証デバイスからの確認に基づいて認証手順２３２６を交換する。次に、アクティブ・アクセス・デバイスは、認証更新２３２８をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは、それに対応してセッションについてのコンテキストの更新２３３０を行う。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、ＩＰＣＰ確立２３３２のために通信し、アクティブ・アクセス・デバイスは、ＩＰＣＰ更新２３３４をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは再びコンテキストの更新２３３６を行う。アクティブ・アクセス・デバイスとクライアント・デバイスは、圧縮プロトコル確立２３３８のために通信を行い、アクティブ・アクセス・デバイスは再びバックアップ・アクセス・デバイスの更新２３４０を行い、バックアップ・アクセス・デバイスは、コンテキストの更新２３４２を行う。その後、ユーザ・データ２３４４が、セッションの通常の進行中に、クライアント・デバイスとアクティブ・アクセス・デバイスとの間を流れる。セッションが終了すると、クライアント・デバイスとアクティブ・アクセス・デバイスは、セッション切断２３４６を行うために通信し、アクティブ・アクセス・デバイスは、終了したセッションに関連するコンテキスト削除２３４８を行うために、バックアップ・アクセス・デバイスへ更新を送信する。その後、バックアップ・アクセス・デバイスは、そのセッションについてのコンテキスト削除２３５０を行う。代替の実施形態では、ＬＣＰ、認証、およびＩＰＣＰ状態についてのコンテキスト更新は、アクティブ・アクセス・デバイスからバックアップ・アクセス・デバイスへの単一の更新として行われる。
【０１３１】
先にＰＤＳＮの実施形態に関して説明されたように、バックアップ・アクセス・デバイスは、複数のアクティブ・デバイスのバックアップとして動作することができる。ＰＰＰセッション中のいかなる時でも、アクティブ・アクセス・デバイスが障害を起こした場合には、そのアクセス・デバイス用のシステム・マネージャは、ＰＤＳＮの実施形態について先に図１９に関して説明されたように、クライアント・デバイスとの通信を引き継ぐためにバックアップ・アクセス・デバイスを作動させる。
【０１３２】
本明細書で説明されたプログラム、プロセス、方法、およびシステムは、別途指示されない限り、特定のタイプのコンピュータまたはネットワーク・システム（ハードウェアまたはソフトウェア）に関連せず、またそれらに限定されないことを理解されたい。ＩＰネットワーキングをサポートする様々なタイプの汎用または専用のコンピュータ・システムが、本明細書で説明された教示とともに使用され、また、教示に従った動作を実行することができる。本明細書で開示されたＰＤＳＮ用の実施形態は、単一の統合されたカードを提供する。しかしながら、説明されたプロセスおよび方法は、ＰＤＳＮを生成するために組み合わされる要素としてインタフェース機能、コール処理機能、およびデータ転送機能の形態をとるＰＤＳＮ機能を提供する複数のブレードを通信シャーシで使用する実施形態にも、等しく適用可能である。本明細書で説明され、特許請求される説明された冗長のための方法および通信は、統合エンティティとしてのＰＤＳＮと同様に、機能要素にも別々に適用可能である。
【０１３３】
本発明の原理が適用され得る多様な実施形態から見れば、例示された実施形態は、例であるに過ぎず、本発明の範囲を限定するものと見なすべきではないことを理解されたい。例えば、流れ図のステップは、説明されたものとは異なるシーケンスで実行されることができ、また、より多くのまたはより少ないステップを使用することができ、また、ブロック図では、より多くのまたはより少ない要素を使用することができる。好ましい実施形態の様々な要素を、ソフトウェアで実装されるものとして説明されたが、他の実施形態では、それらの要素をハードウェアまたはファームウェアとして実装することができ、また、ハードウェアまたはファームウェアとして実装した要素をソフトウェアして実装することもできる。
【０１３４】
請求項は、その趣旨で述べられない限り、説明された順序または要素に限定して読まれるべきではない。従って、添付の特許請求の範囲の範囲および精神に包含されるすべての実施形態およびその均等物は、本発明として特許請求される。
【図面の簡単な説明】
【０１３５】
【図１】図１は、従来技術によるモバイルＩＰネットワーク・アーキテクチャの例を示す機能ブロック図である。
【図２】図２は、本発明で使用するのに適したネットワーク・システムの一実施形態を示す機能ブロック図である。
【図３】図３は、本発明の一実施形態によるアクセス・ノードのブロック図である。
【図４】図４は、本発明の一実施形態によるアクセス・ノードの分散型アーキテクチャを示すブロック図である。
【図５】図５は、本発明の一実施形態によるアクセス・ノードにおける制御シェルフを示すブロック図である。
【図６】図６は、本発明の一実施形態によるアクセス・ノードにおけるデータ・シェルフを示すブロック図である。
【図７】図７は、本発明の一実施形態による、アクセス・ノードにおけるシェルフ内のピア・モジュール間のデータプレーン接続性、およびシェルフ・コントローラおよびシステム・マネージャとのバックプレーン接続性についてのシェルフ・アーキテクチャを示すブロック図である。
【図８】図８は、本発明の一実施形態によるシステム制御バスの例示的な物理的相互接続を示すブロック図である。
【図９】図９は、本発明の一実施形態による媒体データ・バスの物理的相互接続を示すブロック図である。
【図１０】図１０は、本発明の一実施形態によるシェルフ間ケーブル配線トポロジを示すブロック図である。
【図１１】図１１は、本発明の一実施形態によるＰＤＳＮ／ＨＡブート・アップ・プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１２】図１２は、本発明の一実施形態による、システム・マネージャを使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１３】図１３は、本発明の一実施形態による、分散型情報データベース機構を使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１４】図１４は、本発明の一実施形態による、システム・マネージャを使用するＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１５】図１５は、本発明の一実施形態による、分散型情報データベース機構を使用するＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１６】図１６は、シンプルＩＰコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１７】図１７は、モバイルＩＰコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１８】図１８は、ＭＰＡコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１９】図１９は、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２０】図２０は、Ｐ−Ｐトンネル・セッションのブロック図である。
【図２１ａ】図２１ａおよび図２１ｂは、アンカＰＤＳＮおよびターゲットＰＤＳＮそれぞれの障害に対しての、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２１ｂ】図２１ａおよび図２１ｂは、アンカＰＤＳＮおよびターゲットＰＤＳＮそれぞれの障害に対しての、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２２】図２２は、スタンバイＰＤＳＮとして障害ＰＤＳＮを交替および再割当てすることを示すメッセージ・シーケンス・シナリオのブロック図である。
【図２３】図２３は、バックアップのためにコール・パラメータを更新するための、アクティブＰＰＰデバイスとそのスタンバイＰＰＰデバイスとの間の総称的通信を示すメッセージ・シーケンス・シナリオのブロック図である。
【技術分野】
【０００１】
関連出願の相互参照
本出願は、譲受人が本出願と同じである、２００２年６月１３日に出願された「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＰＡＣＫＥＴ ＤＡＴＡ ＳＥＲＶＩＮＧ ＮＯＤＥ ＬＯＡＤ ＢＡＬＡＮＣＩＮＧ ＡＮＤ ＦＡＵＬＴ ＴＯＬＥＲＡＮＣＥ」と題する米国特許出願第１０／１７０９００号の一部継続出願である。
発明の分野
本発明は、モバイル・インターネット・プロトコル（「ＩＰ」）・ネットワークにおける通信に関する。より詳細には、本発明は、Ｎ対１の冗長性をもち、回復不能状態データのみ複製保存を行うパケット・データ・サービング・ノードを特に含む、ポイントツーポイント・プロトコル・デバイスの管理に関する。
【背景技術】
【０００２】
公衆パケット交換ネットワークは、モバイル・ホストなどのようなモバイル通信デバイス（モバイル・ノード）や、１つのネットワークから別のネットワークに接続点を変更するルータなどへの、およびそれらからのトラフィックを搬送するために使用されることができる。モバイルＩＰデータ・ネットワーキングの基本アーキテクチャは当技術分野で知られており、複数の刊行物の中で説明されており、それらの刊行物にはリクエスト・フォー・コメント（「ＲＦＣ」）文書ＲＦＣ２００２（１９９６年）（以降「ＲＦＣ２００２」）が含まれており、更に多くの情報については現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいてインターネット・エンジニアリング・タスク・フォース（「ＩＥＴＦ」）から入手可能である。モバイルＩＰデータ・ネットワーキング分野の当業者は、上記の文書、および実際にモバイルＩＰデータ・ネットワーキングを実施するために使用されるデバイスのことをよく知っている。
【０００３】
モバイルＩＰ通信ネットワークにおいて、モバイル・ノードは、「フォリン（foreign）・エージェント」および「ホーム（home）・エージェント」の２つのデバイスを用いて、ＩＰネットワーク上のターゲット・ホストと通信する。このタイプの通信を説明するモバイルＩＰネットワークの一例が、「Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ） Ｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ Ｈｏｍｅ Ａｇｅｎｔ ａｎｄ／ｏｒ Ｆｏｒｅｉｇｎ Ａｇｅｎｔ Ｆｕｎｃｔｉｏｎｓ Ｄｉｓｔｒｉｂｕｔｅｄ Ａｍｏｎｇ Ｍｕｌｔｉｐｌｅ Ｄｅｖｉｃｅｓ」と題する米国特許出願第０９／３５４６５９号で提示されており、同出願の全内容を参照により本明細書に組み込む。典型的には、フォリン・エージェント機能は、モバイル・ノードが訪れたネットワーク上のルータに組み込まれる。フォリン・エージェントは、モバイル・ノードがホーム・エージェントに登録されているとき、モバイル・ノードにルーティング・サービスを提供する。例えば、フォリン・エージェントは、モバイル・ノードのホーム・エージェントによってトンネリング（tunnel、トンネル化）されたデータグラムをデトンネリング（de-tunnel、トンネル化解除）し、それをモバイル・ノードへ配送する。
【０００４】
典型的には、ホーム・エージェントは、モバイル・ノードのホーム・ネットワーク上のルータに組み込まれる。ホーム・エージェントは、モバイル・ノードの現在地情報を維持する。１または複数のホーム・エージェントが複数のモバイル・ノード宛のコール（call、呼）を同時に処理する場合、ホーム・エージェントは、本質的に、仮想プライベート・ネットワーク・サービスに類似のサービスを提供する。典型的には、それぞれのモバイル・ノードは、別個のホーム・ネットワークと関連づけられ、そのホーム・ネットワークからホーム・エージェントを経由してフォリン・エージェントおよびモバイル・ノードへと到るルーティング経路は、モバイル・ノード用の仮想プライベート・ネットワークに似ている。
【０００５】
モバイルＩＰは、モバイル・ノード（モバイル・エンティティ）とフォリン・エージェントとの間のリンク・レイヤ接続性を必要とする。しかしながら、幾つかのシステムでは、モバイル・ノードからのリンク・レイヤは、フォリン・エージェントから遠い地点で終了し得る。そのようなネットワークは、一般に第３世代ワイヤレス・ネットワークと呼ばれている。図１は、典型的には第３世代ワイヤレス・ネットワークで使用されるネットワーク・アーキテクチャを例示したブロック図である。図１を参照すると、モバイル・ノード１０は、無線ネットワーク・ノード１６、パケット・データ・サービング・ノード１８、およびホーム・エージェント・ノード２４の３つのデバイスを用いて、ＩＰネットワーク３０上のターゲット・ホスト３４と通信する。モバイル・ノード１０の物理レイヤは、無線ネットワーク・ノード１６上で終端し、フォリン・エージェントの機能は、パケット・データ・サービング・ノード１８上に存在する。典型的には、無線ネットワーク・ノード１６が、モバイル・ノード１０とパケット・データ・サービング・ノード１８との間でリンク・レイヤ・プロトコル・データを中継し、パケット・データ・サービング・ノード１８が、モバイル・ノード１０へのリンク・レイヤを確立し、維持し、また、終了する。例えば、モバイル・ノード１０は、無線アクセス・ネットワーク上の通信リンクを介して、無線ネットワーク・ノード１６にリンクされることができる。
【０００６】
パケット・データ・サービング・ノード１８は、モバイル・ノード１０がホーム・エージェント２４に登録されているとき、モバイル・ノード１０にルーティング・サービスを提供する。パケット・データ・サービング・ノード１８は、トンネリングされたデータグラムをデトンネリングし、ホーム・エージェント・ノード２４からＩＰネットワーク２０を介してモバイル・ノード１０へ配送する。パケット・データ・サービング・ノード１６とホーム・エージェント２４との間で交換される通信トラフィックは、データ・トラフィックおよび制御トラフィックを含む。制御トラフィックは、登録要求または登録応答メッセージを含む。制御およびデータ・トラフィックは、パケット・データ・サービング・ノード１６を介して送られ、モバイル・ノード１０で終了する。ターゲット・ホスト３４は、ＩＰネットワーク２０および３０などのような、任意の数のネットワークによってホーム・ネットワーク２６に接続されることができ、また、ホーム・ネットワーク２６上に直接配置されることができる。代替例として、ターゲット・ホスト３４は、他のタイプのパケット交換ネットワークによってホーム・ネットワークに接続されることができる。
【０００７】
ホーム・エージェント２４は、モバイル・ノードのホーム・ネットワーク２６のルータに実装されることができる。ホーム・エージェント２４は、フォリン・エージェント・アドレス、モバイル・ノード１０のネットワーク・アクセス識別子（「ＮＡＩ：Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ」）、モバイル・ホーム・アドレス、およびホーム・エージェントとモバイル・ノード１０の間で共用される秘密鍵などのような、モバイル端末１０に関する現在地情報データを維持する。ホーム・エージェントは、ターゲット・ホスト３４からパケット・データ・サービング・ノード１８へデータをトンネリングし、同様に、逆方向のトンネリング・サービスも提供する。レイヤ２トンネリング・プロトコル（「Ｌ２ＴＰ：Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ」）トンネルなどのような、ポイントツーポイント・トンネルに関するより多くの情報は、現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて入手可能なＲＦＣ２６６１の中に見出されることができる。
【０００８】
従って、典型的には、ホーム・エージェント２４は、モバイル・ノード１０のために少なくとも２つの異なるタスクを実施する。第１に、ホーム・エージェント２４は、モバイル・ノード１０がホーム・ネットワーク２６へのアクセスを許可されているかどうかを決定するために、登録および認証のプロセスを実行する。これは、例えば、モバイル・エンティティの一意シリアル番号、ＮＡＩ、または製造番号、パスワード認証を用いてのモバイル・エンティティの識別情報（identification、アイデンティフィケーション）のチェック、そして場合によっては、モバイル・エンティティのアカウントが現在有効であり入金済かどうかのチェックを、含むことができる。ホーム・エージェントの登録および認証の機能は、リモート認証ダイアルイン・ユーザ・サービス（ＲＡＤＩＵＳ）（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ」）サーバのような認証・許可・アカウンティング（ＡＡＡ）（ａｕｔｈｅｎｔｉｃａｔｉｏｎ，ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ ａｃｃｏｕｎｔｉｎｇ）サーバなどのような第２のデバイスと連携して、または第２のデバイスの支援を受けて、実行されることができる。ＲＡＤＩＵＳサーバに関するより多くの情報は、より多くの情報を得るために現在ｗｗｗ．ｉｅｔｆ．ｏｒｇにおいて入手可能なＲＦＣ２１３８の中に見出されることができる。当業者に知られているように、登録プロセスは、パケット・データ・サービング・ノード１８からの登録要求メッセージの受信および処理、ならびにパケット・データ・サービング・ノード１８への登録応答メッセージの送信を含む。
【０００９】
パケット・データ・サービング・ノード１８も、モバイル・ノード１０のために４つの異なるタスクを実行する。パケット・データ・サービング・ノード１８は、モバイル・ノード１０のために登録およびセッション制御を取り扱うものであり、その制御は、ホーム・エージェント２４への登録要求メッセージの送信、およびホーム・エージェント２４から受信された登録応答メッセージの処理を含む。加えて、パケット・データ・サービング・ノード１８は、データ・パケットを、ターゲット・ホスト３４へ最終的に送信されるように、ホーム・エージェント２４へ転送するためのトンネリングについての責任を有し、また、ホーム・エージェント２４からのデータを、モバイル・ノード１０へ最終的に配送するために、デトンネリングする責任も負う。更に、パケット・データ・サービング・ノード１８は、モバイル・ノード１０のために、認証、許可、アカウンティングのサービスを提供する。パケット・データ・サービング・ノードは、ＲＡＤＩＵＳサーバなどのような認証・許可・アカウンティング・サーバと連携して、または支援を受けて、認証、許可、アカウンティングの機能を実行することができる。加えて、パケット・データ・サービング・ノード１８は、ＡＡＡサーバ、移動通信交換局（「ＭＳＣ：ｍｏｂｉｌｅ ｓｗｉｔｃｈｉｎｇ ｃｅｎｔｅｒ」）、またはホーム・エージェントへのおよびそれらからの信号／データ・インタフェースを提供するＰｉ／ＦＡインタフェースを提供することができる。
【００１０】
モバイル・ノード１０が、無線通信リンクを介して無線ネットワーク・ノード１６へコール設定指示を送信することによって、無線ネットワーク・ノード１６との通信セッションを開始するとき、無線ネットワーク・ノード１６は、パケット・データ・サービング・ノード１８への登録プロセスを開始する。典型的には、無線ネットワーク・ノード１６は、モバイル・ノード１０へサービスを提供できる複数のパケット・データ・サービング・ノードをもつように構成される。知られた従来技術では、無線ネットワーク・ノード１６は、新規の通信セッションに対して働くように構成された何れのパケット・データ・サービング・ノードのステータス情報ももたない。従って、無線ネットワーク・ノード１６は、モバイル・ノード１０についての登録プロセスを開始するとき、モバイル・ノード１０のためのパケット・データ・サービング・ノードをランダムに選択する。そのようなシステムでは、無線ネットワーク・ノードが使用可能なパケット・データ・サービング・ノードの一部はすぐに負荷過剰になり、その他のノードはほとんど使用されないということがあり得る。更に、無線ネットワーク・ノード１６からの登録要求の送信先となる複数の連続するパケット・データ・サービング・ノードが負荷過剰になった場合、そのようなパケット・データ・サービング・ノードは、無線ネットワーク・ノード１６からの登録要求を拒否する可能性がきわめて高く、従って、その結果、モバイル・ノード１０に対するサービスが遅れる。
【００１１】
モバイル・ノードからのユーザ・セッションの負荷を均衡化すること（負荷バランシング）は、重要な機能である。ユーザ・セッションの負荷バランシングに使用され得る既存の方法が幾つか存在する。典型的には、無線ネットワーク・ノードが、パケット・データ・サービング・ノードのＩＰアドレスを複数もつようにプログラムされ、無線ネットワーク・ノードは、その中の１つを、モバイル・ノードからの着信セッションに対するサービスのために選択することができる。既存の一つの方法によれば、無線ネットワーク・ノードはパケット制御機能を含むことができ、この機能は、例えばモバイル・ノードの国際電話加入者インタフェース（電話番号など）に基づいてハッシュ値を計算し、計算されたハッシュは、パケット・データ・サービング・ノードのＩＰアドレスを選択するために使用されることができる。この方式の短所は、アルゴリズムが、それぞれのパケット・データ・サービング・ノードの現在の負荷を考慮していないことである。別の代替方法によれば、パケット制御機能は、パケット・データ・サービング・ノードを選択するためにラウンド・ロビン機構を用いることができる。そのような実施形態では、パケット制御機能は、後続のそれぞれの到着（着信）セッションをリスト内の次のパケット・データ・サービング・ノードへ割り当てることができ、最後のパケット・データ・サービング・ノードに達したときには最初のパケット・データ・サービング・ノードへ戻って処理を繰り返す。ラウンド・ロビン機構は、コールを、パケット・データ・サービング・ノード間で分配するが、例えば、それぞれのパケット・データ・サービング・ノードへ送られるコール・セッションのタイプを考慮していない。
【００１２】
更に、別の方法によれば、外部フォリン・エージェント制御ノードが、例えば、パケット・データ・サービング・ノードのメモリ使用量や処理能力使用量に基づいて、パケット・データ・サービング・ノードを選択することができる。フォリン・エージェント制御ノードの機能は、「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｍａｎａｇｉｎｇ Ｆｏｒｅｉｇｎ Ａｇｅｎｔ Ｓｅｌｅｃｔｉｏｎｓ ｉｎ ａ Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｎｅｔｗｏｒｋ」と題する米国特許出願第０９／８８１６４９号に説明されており、同出願の全内容を参照により本明細書に組み込む。フォリン・エージェント制御ノードは、パケット・データ・サービング・ノードの選択時に負荷バランシング機構を提供するが、その現在のアーキテクチャには幾つかの制約が存在する。第１に、複数の冗長なフォリン・エージェント制御ノードは、現在のパケット制御機能選択アルゴリズムを仮定した場合、容易にはサポートされない。第２に、フォリン・エージェント制御ノードは、システム・アーキテクチャへ更なるコンポーネントが追加されることを必要とし、ＰＤＳＮがクラッシュした場合やその他の理由で使用不能になった場合、ユーザ・セッションをセーブすることを可能にしない。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
従って、モバイルＩＰネットワークにおいてパケット・データ・サービング・ノードやホーム・エージェントなどのようなサービング・ノードを選択するための改良されたシステムおよび方法が必要である。パケット・データ・サービング・ノード用の冗長性およびフェイルオーバ機能は、モバイル・ノードに無矛盾で無中断のサービスを提供するための重要な要素を構成する。
【課題を解決するための手段】
【００１４】
パケット・データ・サービング・ノードのフェイルオーバ機能を備える冗長性のためのシステムおよび方法は、モバイル・インターネット・プロトコル・ネットワークにおいてアクティブＰＤＳＮとスタンバイＰＤＳＮのＮ対１の関係を含み、複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャをアクセス・ノードに設けることによって達成される。Ｎ＋１個のパケット・データ・サービング・ノードから、１つのパケット・データ・サービング・ノードが、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイ（予備）として選択される。パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するための登録要求が無線ノードから受信されたとき、１つのパケット・データ・サービング・ノードが選択され、登録応答メッセージが第１のパケット・データ・サービング・ノードから無線ノードへ送信される。モバイル・ノードと選択されたパケット・データ・サービング・ノードとの間の通信セッションが確立され、回復不能状態データが、選択されたパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送信される。スタンバイ・パケット・データ・サービング・ノードは、Ｎ個のアクティブ・パケット・データ・サービング・ノードのすべてから同じように状態データを受信する。選択されたそれぞれのパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送られた回復不能状態データの更新は定期的に達成され、選択されたパケット・データ・サービング・ノードの障害時には、通信セッションは、アクティブ・パケット・データ・サービング・ノードの役割を引き継ぐスタンバイ・パケット・データ・サービング・ノードへ移され、それはＮ−１個の障害の無い（非障害）パケット・データ・サービング・ノードのすべての状態データを廃棄し、モバイル・ノードとの通信を継続しながらすべての動的状態データを回復する。
【００１５】
本発明の上記ならびにその他の態様および利点は、添付の図面を参照しながら以下の詳細な説明を読むことによって、当業者には明らかとなるであろう。
本発明の例示的な実施形態が、添付の図面を参照しながら説明される。
【発明を実施するための最良の形態】
【００１６】
図２は、モバイルＩＰネットワークにおいてモバイル・ノード用のフォリン・エージェントおよびホーム・エージェントを選択するために本発明で使用するのに適したネットワーク・システム２００の実施形態を示す機能ブロック図である。本明細書で説明される上記ならびにその他の構成およびプロセスは、例として示されるに過ぎず、代わりにその他の構成および要素（例えば、インタフェース、機能、要素の順序など）が使用されることができ、また幾つかの要素は全く省略されてもよいことを理解されたい。更に、大部分の電気通信の応用においてと同様に、本明細書で説明される多くの要素は、個別のコンポーネントとして、または他のコンポーネントとともに、任意の適切な組合せで、または任意の適切な場所に実装され得る機能エンティティであることは、当業者であれば理解されよう。
【００１７】
図２に示されるように、システム２００は、モバイル・ノード２０２と、基地局コントローラ２０４と、無線ノード２０６と、アクセス・ノード２０８および２２４と、ＩＰネットワーク２１０と、フォリン認証・許可・アカウンティング（「ＦＡＡＡ」）サーバ２１４と、ホーム認証・許可・アカウンティング（「ＨＡＡＡ」）サーバ２１６と、ターゲット・ホスト２１２とを含む。モバイル・ノード２０２は、例えば、電話、ラップトップ・コンピュータ、ファックス、または携帯情報端末（「ＰＤＡ」）などのような、任意の適切な形態をとることができる。１つのみのモバイル・ノードを図示しているが、複数のモバイル・ノードが存在できることを理解されたい。
【００１８】
モバイル・ノード２０２は、基地局（図示せず）を介して基地局コントローラ２０４に接続される。基地局コントローラ２０４は、ＣＤＭＡ無線ネットワークなどのような無線ネットワーク上に存在することができる。基地局コントローラ２０４は、無線ノード２０６に結合される。無線ノード２０６は、新規着信ユーザ通信セッションのためにＰＤＳＮを選択するパケット制御機能（「ＰＣＦ」）（ｐａｃｋｅｔ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）を含むことができる。例えば、ＰＣＦは、ＰＤＳＮの１または複数のＩＰアドレスをもつように前もってプログラムされることができる。
【００１９】
無線ノード２０６は、アクセス・ノード２０８と通信する。アクセス・ノード２０８は、モバイル・ノードへデータ・サービスを提供するマルチサービス・アクセス・プラットフォームである。例示的な実施形態によれば、アクセス・ノード２０８は、複数のＰＤＳＮを含み、そのうちの２つであるＰＤＳＮ２１８とＰＤＳＮ２２０とが図２に示されている。ＰＤＳＮ２１８および２２０は、システム・マネージャ２２２と通信する。システム・マネージャ２２２は、以下に説明される機能のなかでも特に、それぞれのＰＤＳＮからロード（負荷）／ステータス（状態）情報を受信し、モバイル・ノードへのＰＤＳＮ割当てを決定する。代替例として、以下でより詳しく説明されるように、システム・マネージャ２２２は、負荷分散型データベースをサポートする。
【００２０】
アクセス・ノード２０８は更に、複数のＨＡを含むアクセス・ノード２２４とも通信し、複数のＨＡのうちの２つであるＨＡ２２６とＨＡ２２８とが図２に示されている。ＨＡ２２６および２２８は、システム・マネージャ２３０と通信する。図２は２つのアクセス・ノードを示しており、アクセス・ノード２０８はＰＤＳＮカードを収容し、アクセス・ノード２２４はＨＡカードを収容している。しかしながら、ネットワーク・アーキテクチャは、ＰＤＳＮとＨＡとの組合せを収容する単一のアクセス・ノードを含むこともできることを理解されたい。
【００２１】
ＰＤＳＮ２１８は、モバイル・ノード２０２からのポイントツーポイント・プロトコル（「ＰＰＰ」）セッションの終端点である。ＰＤＳＮ２１８はまた、ＩＰパケットを得るためにＰＰＰパケットを集めてカプセル開放（decapsulate、カプセル化解除）を行い、その後、ＩＰパケットは、アクセス・ノード２２４上のＨＡ２２６や２２８などのようなＨＡへ送られる。アクセス・ノード２０８および２２４は更に、それぞれＦＡＡＡ２１４およびＨＡＡＡ２１６に結合される。ＦＡＡＡ２１４は、ＰＤＳＮへログ・オンするモバイル・ユーザの認証を行ったり、ユーザ固有のコンフィグレーション・オプションをＰＤＳＮに提供したり、モバイルＩＰ登録時にルーティング情報を提供したりすることができる。アクセス・ノード２０８は更にＩＰネットワーク２１０に結合され、ＩＰネットワークはターゲット・ホスト２１２に結合される。
【００２２】
ＰＤＳＮは、モバイル・ノードのホーム・ネットワークに典型的には配置されるＨＡＡＡ２１６とは直接に通信できないので、ＦＡＡＡ２１４は、ネットワーク・サービス・プロバイダのドメインにおいてＨＡＡＡ２１６のプロキシとして機能することができる。そのような実施形態では、ＦＡＡＡ２１４は、ＰＤＳＮ２１８から認証要求を受信したとき、その要求をＨＡＡＡ２１６へ送信し、ＨＡＡＡ２１６は認証応答をＦＡＡＡ２１４へ送信し、その後ＦＡＡＡ２１４はその応答をＰＤＳＮ２１８へ返送する。ＦＡＡＡ２１４とＨＡＡＡ２１６との間には、認証するメッセージをそれらの間で送信されるようにするために、共有の機密が存在する。
【００２３】
ＨＡＡＡ２１６およびアクセス・ノード２２４は、モバイル・ノード２０２のホーム・ネットワークに存在する。ＨＡＡＡ２１６は、ホーム・ネットワークにおいてモバイル・ノード登録要求を認証することができる。ＨＡＡＡ２１６はまた、コール・セッションを設定するためのコンフィグレーション・パラメータをサービングＨＡへ提供することができる。例えば、コンフィグレーション・パラメータは、セキュリティ・レベルや、差別化サービス・タイプや、リバース・トンネリング・パラメータを含むことができる。ＨＡＡＡ２１６はまた、モバイル・ノード２０２に代わるＦＡＡＡ２１４からの要求を認証することもできる。ＦＡＡＡ２１４は、要求をＨＡＡＡ２１６へ送信することができ、ＨＡＡＡ２１６は、その要求を認証し、応答をＦＡＡＡ２１４へ返送することができ、その後ＦＡＡＡ２１４は、その応答をＰＤＳＮ２１８へ転送する。
【００２４】
図３は、アクセス・ノード２０８の例示的な実施形態を示すブロック図３００である。図３に示されるアクセス・ノード２０８および２２４は、３つのシェルフ、即ち、１つの制御シェルフ３０２および２つのデータ・シェルフ３０４、３０６から成る単一のラック３５０上に構成されることができる。制御シェルフ３０２は、以下で図を参照しながらより詳しく説明される複数のカード（０〜Ｎ）から構成される。制御シェルフ３０２は、ネットワーク管理インタフェース３０８を介してネットワーク管理システムに結合されることができ、従って、システム・マネージャがそれらのシステムの必要に応じてアクセス・ノード２０８および２２４をコンフィグレーションできるようにする。制御シェルフ３０２は更に、ネットワーク３１６へのインタフェース３１０を含む。一実施形態では、ネットワーク３１６は、例えば、ＣＤＭＡネットワーク、ＰＳＴＮ／ＴＤＭまたはＡＴＭネットワーク、およびインターネットなどのようなデータ・ネットワークとすることができる。しかしながら、異なるネットワークが使用されることもできる。一実施形態では、制御シャーシ内の各カードは２つのポートを含むことができ、それらは、例えば、ネットワーク３１６との間でデータの通信を行うのに使用されることができる２つのギガビット・イーサネット（登録商標）・ポートなどのようなものである。
【００２５】
更に、図３に示されるアクセス・ノード２０８および／または２２４は、やはり以下で図を参照しながらより詳しく説明される複数のカード（０〜Ｎ）を有する２つのデータ・シェルフ３０４および３０６を含む。データ・シェルフ３０４および３０６は、ネットワーク３１６へのインタフェース３１２および３１４を含む。図３は幾つかの外部インタフェースのみを示し、シャーシ間の接続を示していないことを理解されたい。更に、本発明は３つのシャーシを含む単一のラックに限定されず、より多くのシャーシが単一のラックへ追加されることもできることを理解されたい。
【００２６】
代替例として、アクセス・ノード２０８またはアクセス・ノード２２４は、複数のラックに分散されてもよい。そのような構成では、１つの制御シェルフが、複数のラックに分散された複数のデータ・シェルフを制御することができる。図４は、アクセス・ノード２０８の分散型ネットワーク・アーキテクチャ４００を示すブロック図である。図３に示されるラック３５０に加えて、アクセス・ノード２０８は更に第２のラック４５０を含む。第２のラック４５０は、インタフェース４０８、４１０、および４１２を介してネットワーク３１６と通信し、更にインタフェース４１４、４１６、および４１８をそれぞれ介してネットワーク３１６と通信する３つのデータ・シェルフ４０２、４０４、および４０６を含む。本発明は２つのラックに限定されず、３以上のラックが使用されることもできることを理解されたい。
【００２７】
図５は、例示的な一実施形態による制御シェルフ５００を示すブロック図である。図５に示される制御シェルフ５００は１８個のカード・スロットを含んでいるが、制御シェルフはそのような構成に限定されず、幾つかのスロットは未使用のまま何もカードを装着せずにおくことができ、また、より少数のカード・スロットが使用されることもできることを、理解されたい。例示的な実施形態によれば、制御シェルフ５００のすべてのコンポーネントは、１対１の冗長性などの冗長性を示し、フェイルオーバ機能を有する。従って、制御シェルフ５００の各コンポーネントは、アクティブ・カードとスタンバイ・カードとを含むことができ、アクティブ・カードが障害を起こした場合には、スタンバイ・カードがその障害を検出してアクティブ・カードの役割を引き継ぐことができるようにされる。その実施形態は、以下でより詳しく説明される。
【００２８】
制御シェルフ５００は、２つのシェルフ・コントローラ５０２および５０４を含み、それぞれのシェルフ・コントローラは、シェルフ５００の左端のスロット内に配置される高さが半分の２つのカードの形態をとる専用ハードウェアでサポートされる。更に、制御シェルフ５００は、２つのスイッチ出口モジュール５０６および５０８と、２つのシステム・マネージャ５１０および５１２と、ＰＤＳＮ／ＨＡカードとして示された複数のアプリケーション・カード５１４〜５３６とを含む。例示的な実施形態は、ＰＤＳＮカードまたはＨＡカードのみを含む制御シェルフに限定されず、代替例として、制御シェルフ５００は、ＰＤＳＮカードとＨＡカードの組合せを含むことができることを理解されたい。更に、代替的な実施形態では、シェルフ・コントローラおよびシステム・マネージャは、システム管理機能を達成するために、単一または複数のカード上に構成されることができる。
【００２９】
例示的な実施形態では、シェルフ・コントローラ５０２は、プライマリ・シェルフ・コントローラとして構成されることができ、シェルフ・コントローラ５０４は、バックアップ・シェルフ・コントローラとして構成されることができる。それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのカード・スロットにシェルフ・コントローラを接続するのに使用されるマルチレイヤ（Ｌ２／Ｌ３）対応スイッチを含む。更に、それぞれのシェルフ・コントローラは、それぞれのスロットへの個別のバス、即ち、以下で管理バスとも呼ばれるシステム制御バスを有することができ、このバスは、単一プラットフォーム内において管理、シグナリング、およびルーティングなどのようなカード内制御通信およびカード間制御通信を提供するのに使用される。一実施形態によれば、例えば、ＰＤＳＮカードは、システム制御バスを使用して、１または複数のシステム・マネージャ・カードまたは別のＰＤＳＮカードと通信することができる。そのような実施形態では、ＰＤＳＮから送信されるデータは、システム制御バス、１または複数のシェルフ・コントローラ・カードを介して、１または複数のシステム・マネージャ・カードやＰＤＳＮカードなどのような宛先へ送られる。
【００３０】
シェルフ・コントローラ５０２および５０４は、シェルフ内ハードウェア・コンフィグレーションを管理し、ハードウェア管理を行う。例えば、シェルフ・コントローラは、シェルフ識別子およびシェルフ・シリアル番号を読み取ることができ、これらはその後、内部アドレスの割当てを容易にするために、またシステム・マネージャが特定のカード・ロケーションおよびコンフィグレーションを正確に関連づけることができるようにするために、使用されることができる。更に、シェルフ・コントローラ５０２および５０４は、シェルフ内のその他のカードおよび電源の存在検出の形態をとる物理的監視を提供する。
【００３１】
シェルフ・コントローラ５０２および５０４はまた、例えば、電源や、冷却ファンや、電源内に設けられた温度センサなどのステータスに関してポーリングを行うことができる。加えて、シェルフ・コントローラ５０２および５０４は、シェルフ５００内の電力管理に責任をもつこともでき、それは、電源から取得可能な現在の有能電力に対する個々のカードの現在の必要量を評価することによってなされる。シェルフ・コントローラ５０２および５０４は、１００Ｍｂｐｓまたはそれより高速のインタフェースなどのようなイーサネット（登録商標）・インタフェース５４２を介して、シェルフ５００内のすべてのカードと通信することができる。
【００３２】
スイッチ出口モジュール５０６および５０８は、システム・マネージャおよびＰＤＳＮ／ＨＡなどのようなスロット内のすべてのカードがギガビット・リンク上で互いに通信できるようにする、高速ポイントツーポイント・スイッチ（Ｌ２／Ｌ３）として構成されることができる。スイッチ出口モジュール５０６および５０８は、ネットワークとの間でデータの通信を行うために、スイッチ・ネットワーク・インタフェース５３８および５４０を使用する。
【００３３】
更に、制御シャーシ５００は、複数のシャーシを単一点から管理するために、シンプル・ネットワーク管理プロトコル（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのような既存または今後開発される管理プロトコルを使用できるシステム・マネージャ５１０および５１２を含む。システム・マネージャ５１０および５１２は、例えばＳＮＭＰを使用してそれぞれのカードを定期的にポーリングすることによって、システム内のすべてのカードの統計およびステータス情報を維持することができる。システム・マネージャ５１０および５１２は、それぞれインタフェース５４４および５４６を介して、それぞれのカードと通信することができる。更に、それぞれのＰＤＳＮカードまたはＨＡカードは、ネットワーク・インタフェース、即ち、図５に示されたネットワーク・インタフェース５４８〜５７０を有する。
【００３４】
図６は、例示的な一実施形態によるデータ・シェルフ６００を示すブロック図である。データ・シェルフ５００は、インタフェース６４２を介してシェルフ６００内のすべてのカードと通信するシェルフ・コントローラ６０２および６０４を含む。データ・シェルフ６００は更に、スイッチ・ネットワーク・インタフェース６３８および６４０を介して通信する２つのスイッチ出口モジュール６０６および６０８と、インタフェース６４４〜６７０を介して通信するＰＤＳＮまたはＨＡ６１０〜６３６とを含む。図５と同様に、データ・シェルフ６００は、ＰＤＳＮまたはＨＡのみを含むように限定されず、データ・シェルフ６００は、ＰＤＳＮカードとＨＡカードの組合せを含むこともできることを、理解されたい。
【００３５】
図７は、シェルフ内のピア・モジュール間のデータプレーン接続性（ｃｏｎｎｅｃｔｉｖｉｔｙ、コネクティビティ）およびシェルフ・コントローラおよびシステム・マネージャのバックプレーン接続性についてのシェルフ・アーキテクチャ７００を示すブロック図である。
【００３６】
シェルフ・アーキテクチャ７００は、３つの例示的なアプリケーション・モジュール７０２、７０４、および７０６を示している。アプリケーション・モジュール７０２〜７０６は、ネットワーク・インタフェース７１０、７１８、７２６と、作業間機能（「ＩＷＦ」）（ｉｎｔｅｒ−ｗｏｒｋｉｎｇ ｆｕｎｃｔｉｏｎ）７１２、７２０、７２８と、管理および制御インタフェース７０８、７１６、７２４と、パケット処理／転送モジュール７１４、７２２、７３０とをそれぞれ含む。アプリケーション・モジュール７０２〜７０６は、ＰＤＳＮモジュールまたはＨＡモジュールとすることができることを理解されたい。
【００３７】
ネットワーク・インタフェース７１０、７１８、および７２６は、例えば、ＰＳＴＮ、無線ネットワーク、データ・ネットワークなどのようなネットワークへのインタフェースを提供する。管理および制御インタフェース７０８、７１６、および７２４は、ＳＮＭＰネットワーク、セッション開始プロトコル（「ＳＩＰ」）（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ネットワーク、Ｈ．３２３ネットワーク、または任意の既存もしくは今後開発される信号ネットワークなどのような管理および信号ネットワークへのインタフェースを提供する。管理および制御インタフェースは、システム制御バス７３４（または管理バス）を介して、シェルフ・コントローラ・モジュール７３６および７３８と通信し、シェルフ・コントローラ・モジュールは、図５に示された制御シェルフ５００などのような制御シェルフへ管理および制御メッセージを送信する。
【００３８】
システム制御バス７３４は、単一プラットフォーム内での管理、シグナリング、およびルーティング通信などのようなカード内／カード間制御を提供する。一実施形態では、システム制御バス７３４は、スイッチド・ファースト・イーサネット（登録商標）（１００Ｍｂｐｓ）システム制御バスとして実装されることができ、
プラットフォームの管理および制御機能をサポートするための、物理的に個別で専用の組込まれたネットワークを提供する。システム制御バス７３４は、シェルフ７００の２つのシェルフ・コントローラ・モジュールのそれぞれから始まり、ピア・シェルフ・コントローラ・スロットを含むそれぞれのスロットへ到る。例えば、それぞれのシェルフ・コントローラは、１つの双方向１００ＢａｓｅＴ−ＴＸイーサネット（登録商標）・リンクを介して、シェルフ内のすべてのスイッチ出口モジュールおよびアプリケーション・モジュールに接続されることができる。加えて、２つのシェルフ・コントローラ・モジュールは、１つの双方向１００ＢａｓｅＴ−ＴＸイーサネット（登録商標）・リンクを介して接続されることができる。一実施形態では、それぞれの接続は、１００Ｍｂｐｓ １００ＢａｓｅＴ−ＴＸイーサネット（登録商標）を伝送する１対の差動トレース（ｄｉｆｆｅｒｅｎｔｉａｌ ｔｒａｃｅ）として構成されることができる。従って、そのような実施形態では、それぞれのシステム制御バス・リンクは、１対のＴＸおよび１対のＲＸファスト・イーサネット（登録商標）・リンクを含む４線インタフェースとすることができる。しかしながら、異なるタイプのリンクも使用され得ることを理解されたい。
【００３９】
図８は、例示的な一実施形態によるシステム制御バス７３４の例示的な物理的相互接続を示している。図８に示されるように、システム制御バス７３４は、２つのシェルフ・コントローラ８０６および８０８を互いに、そしてそれぞれのスイッチ出口モジュール８０２および８０４へ、ならびにＰＤＳＮカードまたはＨＡカードを収容するそれぞれのアプリケーション・スロットなどのようなそれぞれのアプリケーション・カード８１０〜８３６へ、相互接続する。
【００４０】
再び図７を参照すると、それぞれのアプリケーション・カードおよびシェルフ・コントローラは、媒体データ・バス７３２（以下でスイッチ構造とも呼ばれる）に接続される。媒体データ・バス７３２は、単一シェルフ内でＬＰパケット・トラフィックを分配する。媒体データ・バス７３２は、スター型トポロジで実装されることができ、それは、それぞれのスイッチ出口スロットから始まり、ピア・スイッチ出口スロットおよび２つのシェルフ・コントローラ・スロットを含むメイン・バックプレーンの他のすべてのスロットへ到る。一実施形態では、スイッチド・スター型バスは、それぞれの差動対が、１．２５Ｇｂｐｓ範囲、２．５Ｇｂｐｓ範囲、またはより高速／より低速の範囲などのようなＧｂｐｓ範囲で信頼性の高い送信を行えるようにする。一実施形態では、スイッチ出口スロットからのそれぞれの媒体データ・バス接続は、デュアル（ＴＸ／ＲＸ）・ポイントツーポイント差動対（即ちスポーク）として構成されることができる。そのような実施形態では、ピア・スイッチ出口スロットへは２つのスポーク、それぞれのアプリケーション・モジュール・スロットへは２つのスポーク、それぞれの半シェルフ・コントローラ・スロットへは１つのスポークが存在するように、スポークは分配されることができる。
【００４１】
例示的な一実施形態によれば、１または複数のＰＤＳＮカードは、互いにまたはシステム・マネージャ・カードと通信するために、媒体データ・バス７３２を使用することができる。そのような実施形態では、ＰＤＳＮカードへおよびＰＤＳＮカードから送られるデータは、媒体データ・バス７３２を介し、１または複数のスイッチ出口モジュールを経由して、システム・マネージャ・カードやＰＤＳＮカードなどのような目的の宛先（１または複数）へ送信される。加えて、それぞれのＰＤＳＮカードは、ＦＡＡＡサーバ２１４へ問合せを送信するため、およびＦＡＡＡサーバ２１４から許可応答を受信するために、媒体データ・バス７３２を使用することができる。許可問合せを送信するために、ＰＤＳＮカードは、許可問合せを、媒体データ・バス７３２およびスイッチ出口モジュールを介してＦＡＡＡサーバ２１４に送信することができる。それに応答して、ＰＤＳＮカードは、許可応答を、ＦＡＡＡサーバ２１４から、スイッチ出口モジュールおよび媒体データ・バスを介して、受信することができる。それぞれのＨＡカードも、ＨＡＡＡサーバ２１６へ許可情報を送信するため、およびＨＡＡＡサーバ２１６から許可情報を受信するために、また、データをシステム・マネージャ・カードおよび他のＨＡカードと通信するために、媒体データ・バス７３２を使用することができることを、理解されたい。
【００４２】
図９は、例示的な一実施形態による媒体データ・バスの物理的相互接続を示すブロック図である。図９に示されるように、スイッチ出口スロット８０２および８０４は、１００Ｍｂｐｓイーサネット（登録商標）・リンク９０２を介して相互接続される。更に、それぞれのスイッチ出口スロットは、１００Ｍｂｐｓイーサネット（登録商標）・リンク９０４〜９１０を介してそれぞれのシェルフ・コントローラ８０６および８０８へ、また、Ｇｂｐｓイーサネット（登録商標）・リンク９１２〜９２６を介してそれぞれのアプリケーション・モジュール・スロットへ、相互接続される。従って、例示的な実施形態によれば、スイッチド・ギガビット・イーサネット（登録商標）媒体データ・バスは、それぞれのシェルフ内でカード間通信をサポートする物理的に別個で専用の組込まれたネットワークを提供する。
【００４３】
例示的な一実施形態によれば、アクセス・ノードの構成は、１つの制御シェルフおよび５つのデータ・シェルフを含む６つのシェルフから成ることができ、それぞれのデータ・シェルフは、シグナリングおよび管理情報などのような制御情報を受信するために制御シェルフと通信する。図１０は、例示的な一実施形態によるシェルフ間ケーブル配線トポロジ１０００を示すブロック図である。
【００４４】
図１０は、シェルフ・コントローラ１００８および１０１０と、５つのデータ・シェルフ１０１６、１０１８、１０２０、１０２２、および１０２４とに相互接続される２つのシステム・マネージャ１０１２および１０１４を含む制御シェルフ１００２を示している。例示的な実施形態によれば、それぞれのデータ・シェルフは、２つのシェルフ・コントローラを含み、そのうちの一方はバックアップ・コントローラとして構成されることができる。具体的には、図１０に示されるように、データ・シェルフ１０１６、１０１８、１０２０、１０２２、および１０２４は、シェルフ・コントローラ１０２６および１０２８、１０３０および１０３２、１０３４および１０３６、１０３８および１０４０、１０４２および１０４４をそれぞれ含む。
【００４５】
それぞれのシェルフ・コントローラは、シェルフ内における管理通信インフラストラクチャを提供するマルチレイヤ・イーサネット（登録商標）・スイッチを含む。更に、それぞれのシェルフ・コントローラは、２つの外部接続を単一のスター型バス・インタフェースに提供して、冗長システム・マネージャのそれぞれが各シェルフ・コントローラへ接続できるようにする。制御シェルフ１００２では、シェルフ・コントローラ１００８および１０１０へのパスは、バックプレーンの制御プレーン・インタフェースを介して構成されることができる。
【００４６】
マルチシャーシ構成では、すべてのシェルフ間接続性は、物理的に制御シェルフ１００２内に配置されるシステム・マネージャ１０１２および１０１４を介して、データ・シェルフ１０１６〜１０２４内のシェルフ・コントローラ１０２６〜１０４４へとなされる。シェルフ・コントローラは、そのシェルフ内のアプリケーション・カードへの物理的接続を確立する。そのような例示的な一実施形態が、図１０で制御シェルフ１００２に関して示されており、シェルフ・コントローラ１００８および１０１０は、アプリケーション・モジュール１００４および１００６によって示される複数のアプリケーション・モジュールへ相互接続されている。
【００４７】
図１０に示されたそれぞれのシェルフ・コントローラは、２４個の１０／１００ポートおよび２ギガビット・イーサネット（登録商標）・ポートを含むＩＥＥＥ８０２．１ｐ／Ｑ対応スイッチなどのようなマルチレイヤ（Ｌ２／Ｌ３）スイッチを含む。一実施形態では、それぞれのシェルフ・コントローラは、Ｂｒｏａｄｃｏｍ社製のＢＣＭ５６００シリーズＳｔｒａｔａ Ｓｗｉｔｃｈを含むが、異なるスイッチも使用され得る。前掲の図を参照して説明されたように、それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのスロットへの物理的に別個の管理バス、即ち、システム制御バスを有する。更に、シェルフ内の２つのシェルフ・コントローラは、デュアル１０／１００Ｍｂｐｓリンクによって互いに接続される。
【００４８】
図１０に示されたシェルフ間通信アーキテクチャは、ネットワーク管理および搬送信号の目的で使用される。またスイッチ出口モジュール（図１０には示されず）は、複数のシャーシを接続するために無線システムで使用され得る２つの外部ギガビット・リンクも提供することを理解されたい。更に、図１０および前掲の図に示された例示的な実施形態によれば、制御シェルフ機能は、管理および動作の一貫性を実現するために、単一の指定されたシェルフに存在する。しかしながら、制御シェルフ機能は、複数のシェルフに分散されることもできることを理解されたい。例示的な実施形態によれば、図２に示された無線ノード２０６のＰＣＦは、新規の通信セッションをアクセス・ノード２０８の任意のＰＤＳＮへ送ることができる。システム・マネージャは、結びつけられた対として配置され、一方のシステム・マネージャ・カードは、他方のバックアップとして機能する。そのような実施形態では、プライマリ・システム・マネージャは、ＰＤＳＮから負荷情報を受信したとき、その負荷情報をそのバックアップ・パートナへ渡すことができる。従って、プライマリ・システム・マネージャがソフトウェアの障害またはハードウェアの障害を起こした場合、バックアップ・システム・マネージャは障害を検出してプライマリ・システム・マネージャの機能を引き継ぐことができる。
【００４９】
システム・マネージャは、アクセス・ノード２０８のそれぞれのシャーシのすべてのカードに関する統計情報およびステータス情報を維持する。更に、それぞれのシステム・マネージャは、システム・マネージャがサービスを提供するＰＤＳＮのＩＰアドレスをもってプログラムされることができ、それぞれのＰＤＳＮ ＩＰアドレスは、対応するＰＤＳＮの所定の特性の組へとマッピングすることができる。例えば、システム・マネージャは、セッション・タイプ、セッション・ビット・レート、またはグループ内のそれぞれのＰＤＳＮが処理できるセッション数に基づいて、ＰＤＳＮを幾つかの組にグループ化することができる。更に、アクセス・ノード２０８の通常動作中、システム・マネージャは、アクセス・ノード上でサービスを受けるそれぞれのモバイル端末およびそれぞれのＰＤＳＮ、ＨＡ用の動的データベースを構築することができる。例示的な実施形態は、スタンドアローンのブレードに構成されるＰＤＳＮおよびＨＡを開示しているが、以下で開示される通信方法は、例えば、ＰＤＳＮ機能が、インタフェース機能用、コール処理機能用、およびデータ転送機能用の別個のエレメントで提供されるような、ＰＤＳＮおよび／またはＨＡの機能が通信シャーシ内の１または複数のブレードによって提供される構成にも、等しく適用可能である。
【００５０】
一実施形態では、ＰＤＳＮプロフィールまたはＨＡプロフィールは、ＰＤＳＮ ＩＰアドレスまたはＨＡ ＩＰアドレスそれぞれを使用してプロフィールが生成されたＰＤＳＮまたはＨＡを定義することができる。更に、それぞれのプロフィールは、個々のＰＤＳＮまたはＨＡが処理するセッション・タイプ、セッション・ビット・レート、あるいはセッションの数を定めることができる。加えて、それぞれのＰＤＳＮおよびＨＡプロフィールは、個々のＰＤＳＮおよびＨＡのステータスおよび状態、ならびにそのＰＤＳＮおよびＨＡについての負荷情報を含むことができる。例えば、パラメータの中でも特に、ステータス（状態）は、ＰＤＳＮまたはＨＡがアクティブかまたは非アクティブかを定めることができ、状態は、ＰＤＳＮまたはＨＡがプライマリＰＤＳＮ／ＨＡであるかバックアップＰＤＳＮ／ＨＡであるかを定めることができる。それぞれのＰＤＳＮまたはＨＡの状態情報に加えて、プロフィールは、そのパートナとなるＰＤＳＮまたはＨＡのＩＰアドレスも定めることができる。
【００５１】
更に、例示的な実施形態によれば、それぞれのＰＤＳＮおよびＨＡは、それぞれスタンバイＰＤＳＮおよびＨＡへ、コール関連情報を定期的に送信するように構成されることができる。例えば、ＰＤＳＮプロフィールは、特定のセッションまたはそのセッション用に使用されるＰＰＰ圧縮のタイプについてＩＰｓｅｃがネゴシエートされたかどうかを定めることができる。しかしながら、セッション・タイプを定めるための異なる基準も使用され得ることを理解されたい。そのような実施形態では、システム運用者は、アクセス・ノード２０８内の異なるＰＤＳＮ用の負荷コンフィグレーションをダウンロードし、特別のセッション・タイプのユーザにより良いサービスおよび接続性を提供することができる。
【００５２】
例示的な実施形態によれば、アクセス・ノード２０８のＰＤＳＮおよびＨＡは、その使用可能性および負荷情報をシステム・マネージャへ伝えるためにハートビート機構を使用することができる。図１１は、ＨＡまたはＰＤＳＮなどのようなアプリケーション・モジュール用の例示的なブート・アップ・プロセスを示している。図１１は、ＰＤＳＮおよびＨＡを単一のＰＤＳＮ／ＨＡブロックとして示すことによって、ＰＤＳＮおよびＨＡ用のブート・アップ・プロセスを簡略化しているが、例示的な実施形態によれば、ＨＡとＰＤＳＮとは、アクセス・ノード２０８内の異なるアプリケーション・モジュールに配置されることを理解されたい。
【００５３】
ステップ１１０２で、ＰＤＳＮまたはＨＡなどのようなアプリケーション・モジュールは、電源が投入され、初期設定メッセージをシステム・マネージャへ送信することによって、プライマリ・システム・マネージャとの通信を開始する。ステップ１１０４で、システム・マネージャは、ＨＡまたはＰＤＳＮを確認する。これを行うため、システム・マネージャは、物理的ＨＡまたはＰＤＳＮリストからＨＡまたはＰＤＳＮを読み取る。確認が成功すると、ステップ１１０６で、システム・マネージャは、初期設定アクノレッジ（肯定応答）・メッセージをＨＡ／ＰＤＳＮへ送信する。
【００５４】
ステップ１１０８で、システム・マネージャは、このＨＡ／ＰＤＳＮのための役割を選択する。一実施形態では、役割の割当ては動的である。代替例として、システム・マネージャは、冗長性メカニズムが確立されるように、アクセス・ノード内のＰＤＳＮまたはＨＡなどのような各カードの役割を定める役割割当ファイルをもつように前もってプログラムされることができる。例えば、ＨＡ／ＰＤＳＮは、バックアップとして働く所定のＨＡ／ＰＤＳＮを有するプライマリＨＡ／ＰＤＳＮとして構成されることができる。更に、ＨＡ／ＰＤＳＮは、ＨＡ／ＰＤＳＮへアクティブな役割を割り当てることができる。代替例として、ＨＡ／ＰＤＳＮが別のＨＡ／ＰＤＳＮのバックアップとして割り当てられた場合、システム・マネージャは、更に、そのＨＡ／ＰＤＳＮへスタンバイとしての役割を割り当てて、所定のプライマリＨＡ／ＰＤＳＮの冗長ＨＡ／ＰＤＳＮとして動作するようにさせる。異なる冗長性メカニズムが、以下でより詳しく説明される。
【００５５】
ステップ１１１０で、システム・マネージャは、ＨＡ／ＰＤＳＮに役割割当てメッセージを送信し、ＨＡ／ＰＤＳＮは、システム・マネージャへ役割割当アクノレッジ・メッセージ１１１２を送信することによって応答する。ステップ１１１４で、システム・マネージャは、サービス中であるというマークをＨＡ／ＰＤＳＮに付け、ステップ１１１６で、システム・マネージャは、ハートビート・タイマを始動させる。一実施形態では、ハートビート・タイマは、次のハートビート・メッセージがＰＤＳＮ／ＨＡから受信されるべき時間間隔を識別することができ、システム・マネージャは、その時間間隔が経過する前に次のハートビートが受信されない場合にはＰＤＳＮ／ＨＡが使用不可能であると決定する。代替例として、システム・マネージャは、２以上のハートビートがモジュールから受信されない場合に、そのモジュールが使用不可能であると決定することができる。同様に、ハートビートがシステム・マネージャから受信されない場合、ＨＡ／ＰＤＳＮは、そのプライマリ・システム・マネージャの障害を検出し、その後のハートビートを、その時点でプライマリ・システム・マネージャとして動作している冗長システム・マネージャへ送信することができる。
【００５６】
例示的な実施形態によれば、アクセス・ノード２０８のすべてのＰＤＳＮおよびＨＡは、システム・マネージャがすべてのＰＤＳＮおよびＨＡのステータスをラック全体にわたって見渡せるように、システム・マネージャへハートビート情報１１１８を定期的に送信する。更に、代替例として、ＰＤＳＮ／ＨＡモジュールは、ＩＰマルチキャストを使用して他のＰＤＳＮ／ＨＡからコール情報を受信することもでき、そこにおいては、参加するそれぞれのＰＤＳＮ／ＨＡは、マルチキャスト・グループの一員であり、分散型情報データベースをサポートする。
【００５７】
例示的な実施形態によれば、ＰＤＳＮ／ＨＡは、管理バス（即ち、システム制御バス）を介してシステム・マネージャと通信することができる。代替例として、制御メッセージは、媒体データ・バス（即ち、スイッチ構造）を介して交換されることもできる。
【００５８】
図１２は、システム・マネージャを使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオ１２００のブロック図である。ブロック図は、モバイル・ノード（ＭＮ）と、無線ネットワーク・ノード（ＲＮＮ）と、選択されたＰＤＳＮと、ＰＤＳＮと、システム・マネージャとを含む。図示のＰＤＳＮおよびシステム・マネージャは、前掲の図を参照して詳しく説明されたアクセス・ノード２０８の部分であることを理解されたい。モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、ステップ１２０２に示されるように、トラフィック・チャネル（「ＴＣＨ」）設定を無線ネットワーク・ノードと開始する。トラフィック・チャネルを確立すると、無線ネットワーク・ノード上のパケット制御機能（ＰＣＦ）は、ＰＤＳＮへ登録要求メッセージ１２０４を送信する。一実施形態では、ＰＣＦは、アクセス・ノード２０８において１組のＰＤＳＮを用いて構成されることができ、ＰＣＦは、例えば、負荷バランス機構やラウンド・ロビン機構などの内部選択メカニズムに基づいて、ＰＤＳＮを選択することができる。
【００５９】
図１２に示された実施形態では、ＰＤＳＮは、登録要求メッセージ１２０４を受信した場合、そのセッションにサービスを提供することができない。そのＰＤＳＮが新規セッションにサービスを提供するために使用できないのには、多くの理由が含まれ得る。ＰＤＳＮは、過剰な負荷がかかるため、セッションにサービスを提供することを拒否することがある。例えば、ＰＤＳＮは、新規セッションを拒否するまでにサービスを提供できるセッションの数を識別する閾値レベルをもつように構成されることができる。代替例として、ＰＤＳＮは、その容量を監視するように構成されることができ、容量の所定の割合が使用されている場合、新規セッションへのサービス提供を拒否することができる。更に、ＰＤＳＮは、その機能コンフィグレーションが原因で新規セッションへのサービス提供を拒否することもある。例えば、ＰＤＳＮは、圧縮または暗号を使用するセッションなどのような、所定のタイプのセッションだけにサービスを提供するように構成されることができる。
【００６０】
図１２に示された実施形態では、システム・マネージャは、代替ＰＤＳＮを決定する。従って、ＰＤＳＮは、システム・マネージャにＰＤＳＮ選択要求メッセージ２１０６を送信し、ステップ１２０８で、システム・マネージャは、１組の選択規則に基づいて新しいＰＤＳＮを選択する。選択規則は、以前の選択規則の記録およびサービス規則のタイプを含むことができる。一実施形態では、システム・マネージャは、１組の規則または異なる選択規則の組合せを使用するように構成されることができる。例えば、システム・マネージャは、着信セッションに対してサービスを提供できるＰＤＳＮのサブセットを決定するために１つの選択規則を使用することができ、その後、着信セッションに対するサービスを提供できる１つのＰＤＳＮを選択するために別の規則を使用することができる。
【００６１】
先の段落で述べられたように、システム・マネージャは、新しいＰＤＳＮを決定するために以前の選択規則の記録を使用することができる。そのような実施形態では、システム・マネージャは、モバイル・ノードにおける以前のセッションにサービスを提供したＰＤＳＮを決定および選択するために、モバイル・ユーザの以前の登録記録を使用する。一実施形態では、それぞれのＰＤＳＮは、コール設定が成功したときに、モバイル・ノードの登録記録を送信するように構成されることができる。
【００６２】
ＰＤＳＮを選択すると、システム・マネージャは、ＰＤＳＮへ、選択されたＰＤＳＮのＩＰアドレスを含むＰＤＳＮ選択応答メッセージ１２１０を送信する。ＰＤＳＮは、メッセージ１２１０を受信したとき、無線ネットワーク・ノードへ、選択されたＰＤＳＮのＩＰアドレスを含むＲＰ登録応答メッセージ１２１２を送信する。ＲＰ登録応答メッセージ１２１２は、ＲＦＣ２００２に記載されたメッセージ「エラー１３６（Ｅｒｒｏｒ １３６）」の形をとることができる。しかしながら、異なるタイプのメッセージが使用されることもできる。
【００６３】
次に、無線ネットワーク・ノードは、ＲＰ登録要求メッセージ１２１４を選択されたＰＤＳＮへ送信し、選択されたＰＤＳＮは、ステップ１２１６に示されるように、着信セッションにサービスを提供するために資源を割り当てる。選択されたＰＤＳＮが着信セッションにサービスを提供することを拒否することがあり、システム・マネージャに問い合わせるプロセスが繰り返されることがあることを理解されたい。そのような実施形態では、システム・マネージャは、ＰＤＳＮ選択要求が選択されたＰＤＳＮから送信されたと判断することができ、システム・マネージャは、要求を送信したＰＤＳＮのＩＰアドレスを含むＰＤＳＮ選択応答によって応答することができる。加えて、ＰＤＳＮ選択応答メッセージは、ＰＤＳＮがセッションにサービスを提供すべきことをＰＤＳＮに通知する所定のビットまたはビット・パターンなどのである識別子を含むことができる。更に、要求を処理することを拒否したＰＤＳＮの数を示す所定のビットまたはビット・パターンが、ＰＤＳＮ選択応答メッセージ内に設定されることができることを理解されたい。そのような実施形態では、ＰＤＳＮは、所定数のＰＤＳＮがセッションにサービスを提供することを拒否したときに、要求を受け入れるように構成されることができる。サービス遅延、即ち、多数のＰＤＳＮが新規セッションを拒否することを防止する異なる実施形態も使用され得ることを理解されたい。
【００６４】
資源を割り当てると、選択されたＰＤＳＮは、ＲＰ登録応答メッセージ１２１８を送信し、１２２０で示されるように、ＲＰセッションが、無線ネットワーク・ノードと選択されたＰＤＳＮとの間で確立される。更に、例示的な実施形態によれば、新規セッションへ資源を割当てると、選択されたＰＤＳＮは、システム・マネージャへ、選択されたＰＤＳＮの新しい負荷を含む更新メッセージ１２２２を送信する。更新メッセージ１２２２は、モバイル・ノードのＮＡＩまたはＩＭＳＩを含む、確立されたコール・セッションのためのセッション情報を含むことができる。代替例として、選択されたＰＤＳＮは、システム・マネージャへ、セッション情報を含む別個のメッセージを送信することができる。先の段落に関して述べられたように、モバイル・ノードが次に登録するときに、システム・マネージャは、最後のサービス提供ＰＤＳＮを決定するためにセッション情報を使用することができる。ステップ１２２４で、モバイル・ノードは、選択されたＰＤＳＮに対するポイントツーポイント・プロトコル（「ＰＰＰ」）セッションを確立し、選択されたＰＤＳＮに登録する。
【００６５】
図１３は、分散型制御ノード方法によるＰＤＳＮ選択を示すメッセージ・シーケンス・シナリオ１３００のブロック図である。分散型制御ノード機構では、アクセス・ノード内のそれぞれのＰＤＳＮカードは、アクセス・ノード２０８のすべてのＰＤＳＮの負荷情報を提供するようにシステム・マネージャへ定期的に要求することができる。代替例として、ＰＤＳＮは、アクセス・ノード２０８のすべてのＰＤＳＮから負荷情報を受信することができる。そのような実施形態では、それぞれのＰＤＳＮは、ＩＰマルチキャスト方法またはその他の現存の又は今後開発される伝送方式を使用して、他のＰＤＳＮへ負荷情報を提供することができる。図１３は、モバイル・ノードと、パケット制御機能を有する無線ネットワーク・ノードと、選択されたＰＤＳＮと、ＰＤＳＮと、システム・マネージャとを示している。
【００６６】
モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、無線ネットワーク・ノードへ、無線ネットワーク・ノードとのトラフィック・チャネルを確立するための要求を含むメッセージ１３０２を送信する。チャネルが確立されると、無線ネットワーク・ノードは、ＰＤＳＮへＲＰ登録要求メッセージ１３０４を送信する。パケット制御機能がそのＰＤＳＮテーブルに複数のＰＤＳＮ ＩＰアドレスを保持する実施形態では、パケット制御機能は、ＰＤＳＮのＩＰアドレスを決定するために負荷バランシング機構を使用することができる。代替例として、パケット制御機能は、プライマリＰＤＳＮのＩＰアドレスとセカンダリＰＤＳＮのＩＰアドレスとを含む２つのエントリだけをそのテーブルに保持することができる。そのような実施形態では、ＰＣＦは、プライマリＰＤＳＮが着信セッションに対してサービスできなくなるまで、すべての新規コール・セッション要求をプライマリＰＤＳＮへ送信することができる。プライマリＰＤＳＮが障害を起こすか又は負荷過剰になった場合、ＰＣＦは、セカンダリＰＤＳＮのＩＰアドレスへ新規コール・セッションを送ることができる。
【００６７】
図１３に示される実施形態によれば、ＰＤＳＮは、それが着信登録要求に対するサービスを提供できないこと、または少なくとも、そのＰＤＳＮが、好ましくは別のＰＤＳＮがコールを処理すべきであると判断される所定の閾値レベルより上にあることを決定する。ＰＤＳＮは、図１２を参照して説明された複数の要因に基づいて、その決定を下すことができる。
【００６８】
無線ネットワーク・ノードが選択を行い、選択されたＰＤＳＮのＩＰアドレスへＲＰ登録要求メッセージ１３１０を送信すると、選択されたＰＤＳＮは、１３１２に示すように、資源を新規セッションに割り当てる。次に、選択されたＰＤＳＮは、ＲＰ登録応答メッセージ１３１４を送信し、ＲＰセッション１３１６が、無線ネットワーク・ノードと選択されたＰＤＳＮとの間で確立される。更に、例示的な実施形態によれば、選択されたＰＤＳＮは、１３１８に示すように、その更新された負荷情報を最初のＰＤＳＮへ送信する。図１３は、選択されたＰＤＳＮから負荷情報を受信するＰＤＳＮを１つだけ示しているが、選択されたＰＤＳＮは、そのマルチキャスト・グループ内の他のＰＤＳＮへもその負荷を送ることができることを理解されたい。更に、後でより詳しく説明されるように、選択されたＰＤＳＮは、スタンバイＰＤＳＮへ、その新規コール情報を送信することができる。システム・マネージャも同様にマルチキャスト・グループの一員となり得ることを理解されたい。代替例として、選択されたＰＤＳＮは、ハートビート・メッセージによってその新しい負荷をシステム・マネージャへ送ることができる。
【００６９】
選択されたＰＤＳＮへの登録が成功すると、ＰＰＰセッションが、モバイル・ノードと選択されたＰＤＳＮとの間で確立され、モバイルが、１３２２に示すように、選択されたＰＤＳＮに登録される。
【００７０】
例示的な一実施形態によると、ＰＤＳＮに加えて、アクセス・ノードは、システム・マネージャによって管理されるＨＡも含むことができる。図１１を参照して述べられたように、アクセス・ノード内のすべてのＨＡは、ハートビートをシステム・マネージャに送信し、その負荷情報を定期的にシステム・マネージャへ送信する。ＰＤＳＮに関して説明された実施形態と同様に、システム・マネージャは、アクセス・ノードのそれぞれのＨＡに対する負荷を含む制御ノード・データベースを保持することができる。代替例として、制御ノード・データベースは、すべてのＨＡにわたって分散されることができ、それぞれの参加するＨＡは、他のすべての参加するＨＡの負荷情報を保持することができる。そのような実施形態において、それぞれの参加するＨＡは、ＩＰマルチキャストを使用して、他のＨＡ上のその負荷を更新することができ、すべての参加するＨＡおよびシステム・マネージャは、分散型制御ノード情報データベースをサポートするマルチキャスト・グループの一員であることができる。
【００７１】
図１４は、最初のＨＡが使用不可能なときにシステム・マネージャが新しいＨＡを選択する実施形態におけるＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオ１４００のブロック図である。図１４は、モバイル・ノードと、ＰＤＳＮと、システム・マネージャと、ＨＡと、選択されたＨＡと、ＨＡＡＡとを示している。
【００７２】
モバイル・ノードは、図１２および図１３を参照して説明された方法の１つを使用してＰＤＳＮとのＰＰＰセッションを確立するとき、ＰＤＳＮへＭＩＰ登録要求メッセージ１４０２を送信する。一実施形態では、登録要求メッセージ１４０２は、モバイル・ノードによって要求されるＨＡのＩＰアドレスを指定することができる。代替例として、ＰＤＳＮは、モバイル・ノード用のＨＡのＩＰアドレスを決定するために、ＦＡＡＡサーバにコンタクトすることができる。ＰＤＳＮは、１４０４で例示されるように、その後にＨＡへ登録要求メッセージを送る。図１４に示される実施形態によれば、ＨＡは、例えば、過剰負荷もしくは過剰負荷に近い状況のために、またはモバイル・ノードによって提示された静的モバイル・ノードＩＰアドレスが現在のＨＡのＩＰアドレス・プールに属していないために、コール・セッションを処理できないことを、決定する。ＨＡは、負荷マップに関してスタンバイＨＡと通信する。異なるメッセージ方式も、代替ホーム・エージェントのＩＰアドレスを取得するのに使用され得ることを理解されたい。
【００７３】
ＨＡは、スタンバイＨＡから冗長グループ内の他のＨＡの負荷情報を受信する。アクティブＨＡは、バックアップＨＡから負荷マップを含む定期的メッセージを受信する。この負荷マップは、冗長グループ内のそれぞれのＨＡの平均負荷と、最小負荷のものから４つの小負荷のＨＡの負荷とを含む。アクティブＨＡは、代替ＨＡを選択する必要があるかどうかを決定するために、この負荷情報を使用する。アクティブＨＡの負荷が平均負荷より一定の比率だけ大きくなった場合、アクティブＨＡは、負荷マップから、４つの小負荷のＨＡのうちで最小負荷のものを選択する。その後、モバイルＩＰ登録要求１４１０は、処理のために代替のＨＡへ送られる。
【００７４】
ステップ１４１６で、選択されたＨＡは、ＭＩＰ登録要求メッセージを認証し、モバイル・ノード用にＭＢＲを生成する。更に、選択されたＨＡは、ＰＤＳＮへのＩＰトンネルのネゴシエーションおよび設定を開始する。次に、選択されたＨＡは、ＭＩＰ登録応答メッセージ１４１８をＰＤＳＮへ送信し、ＭＩＰ登録応答メッセージ１４１８のホーム・エージェント・フィールドは、その選択されたＨＡのＩＰアドレスを含む。ステップ１４２０で、ＰＤＳＮは、モバイル・ノードのために選択されたＨＡへのＩＰトンネルおよびビジタ・リスト（ＶＬ）を作成する。ＰＤＳＮは、それぞれのモバイルＩＰコール用にＶＬを作成することができ、それぞれのＶＬは、サービングＨＡのＩＰアドレスと、モバイル・ノードのＩＰアドレスと、トンネリング・パラメータと、認証情報とを含むことができる。
【００７５】
ステップ１４２２で、ＰＤＳＮは、ＭＩＰ応答メッセージをモバイル・ノードへ送る。ステップ１４２４で、選択されたＨＡは、ＭＢＲ更新メッセージ１４２４もシステム・マネージャへ送信し、その後、システム・マネージャは、ステップ１４２６に示すように、ＭＢＲを更新するとＭＢＲ更新ＡＣＫメッセージ１４２８によって応答する。ＭＩＰセッションは、ステップ１４３０に示すように確立される。更に、ステップ１４３２で、選択されたＨＡは、その現在の負荷データを含む更新メッセージをシステム・マネージャへ送信する。
【００７６】
図１５は、ＨＡが分散型情報データベース機構に参加する、ＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。そのような実施形態では、それぞれのＨＡは、例えば、そのＨＡに過剰な負荷がかかっている場合に新しいＨＡを決定するように構成されることができる。更に、そのような実施形態では、それぞれの参加するＨＡは、スタンバイＨＡから、他の参加するＨＡの負荷更新情報を定期的に受信することができる。代替例として、ＨＡは、ＩＰマルチキャストを介してそれぞれの参加するＨＡから負荷情報を受信することができる。図１４と同様に、図１５は、モバイル・ノードと、ＰＤＳＮと、システム・マネージャと、ＨＡと、選択されたＨＡと、ＨＡＡＡとを示している。
【００７７】
ＰＤＳＮに対するＰＰＰセッションを確立すると、モバイル・ノードは、ＭＩＰ登録要求メッセージ１５０２をＰＤＳＮへ送信する。一実施形態では、ＭＩＰ登録要求メッセージは、モバイル・ノードによって要求されたＨＡのＩＰアドレスを含むことができる。代替例として、ＰＤＳＮは、そのモバイル・ノード用のＨＡのＩＰアドレスを決定するために、ＦＡＡＡに問い合わせることができる。次にＰＤＳＮは、ステップ１５０４に示されるように、登録要求メッセージをＨＡへ送る。
【００７８】
ＨＡは、ＭＩＰ登録要求メッセージ１５０４を受信すると、その要求にサービスを提供できないと決定し、ステップ１５０６に示されるように、新しいＨＡを選択する。図１５に示される例示的な実施形態によれば、ＨＡは、分散型情報データベースに参加し、それによって、この方式に参加する他のＨＡの負荷情報を有する。従って、選択基準は、それぞれのＨＡの負荷に基づくことができ、その選択において、ＨＡは、例えば、最低の負荷、セッション・タイプ、コール・データ速度、またはユーザに関連するサービス・タイプを有するＨＡを選択する。ＨＡは、その後、ステップ１５０８で示されるように、ＭＩＰ登録要求を、選択されたＨＡへ送る。
【００７９】
更に、選択されたＨＡは、アクセス要求メッセージをＨＡＡＡに送信することができ、ＨＡＡＡは、アクセス承認メッセージ１５１２によって応答する。ステップ１５１４で、選択されたＨＡは、ＭＩＰ登録要求メッセージを認証し、ＭＢＲを生成し、ＰＤＳＮに対するＩＰトンネルを設定する。ステップ１５１６で、選択されたＨＡは、ＭＩＰ応答メッセージをＰＤＳＮに送信し、ＰＤＳＮはそれに応答して、１５１８に示されるように、モバイル・ノードのためのビジタ・リスト（ＶＬ）を生成し、選択されたＨＡに対するＩＰトンネルを設定する。ステップ１５２０で、ＰＤＳＮは、ＭＩＰ登録応答メッセージをモバイル・ノードへ送り、ステップ１５３２に示されるように、ＭＩＰセッションが確立される。
【００８０】
ステップ１５２２で、選択されたＨＡは、ＭＢＲ更新をシステム・マネージャへ送信し、システム・マネージャは、ステップ１５２４で、ＭＢＲを更新し、ＭＢＲ ＡＣＫメッセージ１５２６を送信する。更に、ステップ１５２８で、選択されたＨＡは、分散型データベース機構に参加するＨＡへ更新メッセージを送信し、その更新メッセージは、ＨＡの現在の更新された負荷を含む。図１５は、更新メッセージ１５２８を受信するＨＡを１つだけ示している。しかしながら、ＨＡはすべての参加するＨＡによって受信されるＩＰマルチキャストを生成できることを理解されたい。更に、更新メッセージは、スタンバイＨＡによっても受信される。ＨＡは、スタンバイＨＡ用に排他的メッセージを生成できることや、代替例として、１５３０に示されるように、スタンバイＨＡのＩＰアドレスもマルチキャスト・グループへ含まれ得ることも理解されたい。
【００８１】
負荷バランシング、および、さもなければ着信通信セッションの選択的なルーティングおよび再ルーティングに加えて、制御シェルフおよびデータ・シェルフのコンポーネントは、フェイルオーバ機能をもつ冗長性を示す。例えば、図５に示され且つそれを参照して説明された制御シェルフは、２つのシェルフ・コントローラ５０２および５０４と、２つのシステム・マネージャ５１０および５１２とを含む。そのような実施形態では、システム・マネージャ／シェルフ・コントローラの一つがアクティブのシステム・マネージャ／シェルフ・コントローラとして構成され、他の１つは冗長（スタンバイ）システム・マネージャ／シェルフ・コントローラとして構成される。従って、アクティブ・ユニットが障害を起こした場合、冗長ユニットが障害を検出し、アクティブ・ユニットの役割を引き継ぐことができる。
【００８２】
スタンバイ・システム・マネージャおよびシェルフ・コントローラは、それらのアクティブ・パートナとのハートビート動作を実行して、アクティブ・パートナが使用できないことを決定することができる。スタンバイ・エンティティは、そのハートビート・タイマがタイムアウトになるたびに、ハートビート要求メッセージを送信することができ、アクティブ・エンティティは、アクノレッジメント（肯定応答）メッセージによって応答することができる。肯定応答メッセージが受信されない場合、スタンバイ・エンティティは、そのアクティブ・エンティティが動作していないと仮定することができる。代替例として、コンフィグレーションに基づいて、アクティブ・エンティティは、ハートビートを再送信することができ、それに対する応答が受信されない場合、そのパートナが動作していないと仮定することができる。更に、例示的な一実施形態によれば、結び合わされた対の各メンバは、そのパートナのデータの完全なミラー・イメージを有する。例えば、それぞれのＰＤＳＮまたはＨＡは、それぞれのシステム・マネージャとの２つの別個の物理的リンクをもち、それにより、アクティブ・システム・マネージャおよびバックアップ・システム・マネージャは同時に同じ情報を受信する。代替例として、アクティブ・システム・マネージャは、１または複数のＰＤＳＮまたはＨＡから、更新された負荷情報を受信することができ、そして、その受信した情報を例えばシステムのデータ・バスを介してスタンバイ・システム・マネージャへ渡すことができる。
【００８３】
更に、それぞれのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）は、１対１の冗長性を提供するために、結び合わされた対として構成されることができ、１対のパートナにおけるそれぞれのＰＤＳＮは、他方のパートナのためのバックアップとして機能する。新規セッションがＰＤＳＮに到着すると、ＰＤＳＮは、そのパートナへセッションに関連するすべての状態情報を送信する。同様に、セッション状態情報は、状態が変化したときにも、パートナに渡される。従って、結び合わされた対の各メンバは、そのパートナのセッションの完全なミラー・イメージを有する。例示的な実施形態によれば、ＰＤＳＮ／ＨＡは、スイッチ出口モジュールまたは内部バスを介して通信することができる。更に、パートナＰＤＳＮ／ＨＡは、プライマリＰＤＳＮが障害を起こした場合にセッションを引き継ぐことができる。例示的な一実施形態によれば、ＰＤＳＮ／ＨＡは、同時係属中の特許出願第１０／０４１４３６号、「Ｓｍｏｏｔｈ Ｈａｎｄｏｆｆ ｖｉａ Ｓｔａｔｅ Ｅｘｃｈａｎｇｅ ｉｎ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋ」で説明されているハンドオフ方法を使用することができ、この出願の全体を参照によって本明細書に組み込むものとする。
【００８４】
複数のコンフィグレーション方式が、機能的冗長性を達成するために使用され得ることを理解されたい。例えば、上で述べられたように、２つのＰＤＳＮ／ＨＡは、プライマリおよびセカンダリ（バックアップ）のＰＤＳＮ／ＨＡとして対をなすように構成されることができ、プライマリＰＤＳＮ／ＨＡは、サービスできなくなるまで、すべてのセッションを処理する。そのような実施形態では、バックアップＰＤＳＮ／ＨＡは、プライマリＰＤＳＮ／ＨＡの障害時にその機能を引き継ぐ受動的な非アクティブなバックアップである。更に、セカンダリまたはバックアップのＰＤＳＮ／ＨＡは、内部媒体データ・バスを介してプライマリＰＤＳＮ／ＨＡで受信されるすべてのトラフィックのミラー・イメージを受信し、また、バックアップＰＤＳＮ／ＨＡは、外部にデータを伝える能力をもたない。そのような実施形態では、バックアップ・アプリケーション・モジュールの外部インタフェースでバックアップ・アプリケーション・モジュールを出ていくすべてのデータは、除去される。
【００８５】
プライマリ／バックアップ・コンフィグレーションでは、システム・マネージャは、シェルフ内のすべてのアクティブ・カードの活動ステータスを監視する。これを行うために、システム・マネージャは、インターネット・エンジニアリング・タスク・フォース（「ＩＥＴＦ」）のリクエスト・フォー・コメント（「ＲＦＣ」）１１５７に完全に説明されているシンプル・ネットワーク・マネジメント・プロトコル（「ＳＮＭＰ」）を使用することができ、この文献を参照によって本明細書に組み込むものとする。一実施形態では、ＳＮＭＰは、管理情報ベース（「ＭＩＢ」）（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）を含むＰＤＳＮ／ＨＡにポーリングを行うため使用されることができる。更に、システム・マネージャは、それぞれのカードのステータスを決定するために、コモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ（「ＣＯＲＢＡ」）（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）を基にする方法を使用することができる。ＳＮＭＰを使用して、システム・マネージャは、障害のあるＰＤＳＮ／ＨＡがＳＮＭＰポーリングに応答しない場合、ＰＤＳＮ／ＨＡの障害を検出することができる。プライマリＰＤＳＮ／ＨＡが障害を起こしたとき、システム・マネージャは、バックアップＰＤＳＮ／ＨＡへメッセージを送信し、バックアップＰＤＳＮ／ＨＡは、プライマリＰＤＳＮ／ＨＡとして動作する。更に、バックアップＰＤＳＮ／ＨＡは、引継ぎを行うと、アドレス解決プロトコル（「ＡＲＰ」）（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージを外部ルータへ送信して、データが、障害を起こしたＰＤＳＮ／ＨＡではなくバックアップＰＤＳＮ／ＨＡへ送られるようにする。また、プライマリＰＤＳＮ／ＨＡが障害を起こしたとき、バックアップＰＤＳＮ／ＨＡは、プライマリ・カードと同じ外部ＩＰアドレスを使用する。
【００８６】
冗長性のための別の例示的な実施形態によれば、２つの結び合わされたＰＤＳＮ／ＨＡがアクティブであり、通信セッションを処理することができる。そのような実施形態では、プライマリＰＤＳＮ／ＨＡは、アクティブ通信セッションのみについてデータを媒体データ・バスを介してバックアップＰＤＳＮ／ＨＡへ送信し、セッションが休止状態になった場合、バックアップＰＤＳＮ／ＨＡは、セッション情報をそのメモリから削除し、一方、プライマリＰＤＳＮ／ＨＡはなおもそれを保持し続ける。そのような実施形態では、このタイプの冗長性をサポートするためのメモリ要件は最低限に抑えられ、アクティブ・セッションだけがバックアップＰＤＳＮ／ＨＡにキャッシュされて、プライマリＰＤＳＮ／ＨＡが障害を起こした場合の速やかな切替えに備える。更に、アクティブ・カードは、バックアップされるセッションのデータ処理を省くために、アクティブ・セッションの制御データだけを送信することができる。バックアップＰＤＳＮ／ＨＡが引継ぎを行うと、バックアップ・モジュール（今はプライマリ・モジュールである）は、ＡＲＰメッセージを外部ネットワーク・エンティティへ送り、障害を起こしたカードのＩＰアドレスを、その関連ネットワーク・インタフェース、例えばＲ−ＰインタフェースやＰｉインタフェースなどに結び付ける。
【００８７】
更に、代替例としては、１対１の冗長性の代わりに、シャーシ内の１つのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）が、他のすべてのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）用のバックアップとして割り当てられ、その結果として、Ｎ対１の冗長性を生み出すことができる。Ｎ対１の冗長性の方式は、大多数の通信セッションがしばしば休止中となる通信システムでは望ましいことがある。従って、冗長とされるべきであり且つデータおよびコールの喪失を回避するためのシステムの場合、バックアップ・モジュールが、アクティブ・セッションのために必要とされる。そのような実施形態では、単一のバックアップ・モジュールによってバックアップされ得るプライマリ・モジュールの数は、Ｎ個のＰＤＳＮ／ＨＡのアクティブ・セッションをバックアップするのに必要とされるメモリ量に基づいて決定されることができる。
【００８８】
Ｎ対１の冗長性の方式では、すべてのアクティブ・モジュールは、コールの状態に影響する制御および何らかのデータ情報を１つのバックアップ・モジュールへ送信する。Ｎ個のＰＤＳＮ／ＨＡのうちの１または複数のものが障害を起こした場合、システム・マネージャは、障害モジュールについてバックアップ・モジュールへ通知し、バックアップ・モジュールは、障害モジュールに対するネットワーク・インタフェースを提供する。
【００８９】
スタンバイＰＤＳＮにおいて最小限の通信トラフィックと記憶要件とをもった望ましいＮ対１の冗長性を達成するために、回復不能状態だけがスタンバイＰＤＳＮへ転送される。Ｎ個のアクティブＰＤＳＮによってスタンバイＰＤＳＮへ転送される更新は、適用されるデータのタイプおよび送信される頻度に基づいてカテゴリに分割される。
【００９０】
本明細書で開示される実施形態のデータ・タイプには以下のものがある。
ＰＤＳＮ全体の状態およびすべてのコールに適用される「ＰＤＳＮ毎データ」。ＰＤＳＮ毎状態の例は、気付ＩＰアドレス、ＭＡＣアドレスなどを含む。
特定のＨＡおよびそのＨＡ上のすべてのコールに関連する状態を含む「ホーム・エージェント（ＨＡ）毎データ」。ＨＡ毎状態の例は、ＨＡ ＩＰアドレス、ＦＡ−ＨＡ ＳＰＩおよびキーなどを含む。
特定のコールだけに属する状態である「コール毎データ」。コール毎状態の例は、ＰＰＰ状態、モバイルＩＰ（ＭＩＰ）状態などを含む。
本明細書で開示される実施形態の更新タイプには以下のものがある。
ただ１度のみ送信されることを想定した「静的更新」。静的更新は２度以上送信されることもできるが、その想定される頻度はきわめて低い。静的更新の例は、ＳＩＰコールのホームＩＰアドレスであり得る。
ＰＤＳＮ外部の発信源からの情報受信またはＰＤＳＮ内の状態変化に応答して送信される「トリガされた更新」。トリガされた更新の例は、ＰＣＦからの休止指示、ＰＰＰアイドル・タイマのタイムアウトなどである。
非常に速やかに変化する、場合によっては、ユーザによって送信または受信されるパケット毎に変化するデータを送信する「動的更新」。
【００９１】
後で説明される実施形態の場合、Ｎ個のアクティブＰＤＳＮカードおよびスタンバイＰＤＳＮカードのそれぞれは、図１１に関して先に説明されたように、システム・マネージャによってアクティブ／スタンバイの役割を割り当てられる。システム・マネージャは、それぞれのアクティブＰＤＳＮへ、その関連づけられたスタンバイＰＤＳＮを、役割割当てプロトコルの一部として通知する。
【００９２】
ＰＤＳＮのＮ対１の冗長性を使用するシステムの例示的な実施形態が、シンプルＩＰコールに関して図１６に示されている。図面中の実施形態の場合、１つのアクティブＰＤＳＮ２１８が示されており、本明細書に示され説明される１つのアクティブＰＤＳＮの通信について把握している１つのスタンバイＰＤＳＮ２２０は、Ｎ個のアクティブＰＤＳＮのそれぞれに対して複製されている。アクティブＰＤＳＮとスタンバイＰＤＳＮとの間の通信は、先に図８に関して説明されたようなシステム制御バスを使用して、図示の実施形態において実行される。ＰＤＳＮの選択およびＲＰセッションの確立は、図１２に関して説明されるように達成される。セッションが確立されると、アクティブＰＤＳＮは、ＲＰ更新１６０２をスタンバイＰＤＳＮへ提供する。ＲＰ更新は、新しいコールＩＤおよびＲＰ状態についてのデータを含む。それぞれのコールは、アクティブＰＤＳＮに対して一意のコール識別子で識別される。ＲＰ状態に関して送信されるデータが表１に示されている。
【００９３】
【表１】
【００９４】
図１２に関して先に説明されたように、モバイル・ノードは、パスワード認証プロトコル（「ＰＡＰ」）（Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）またはチャレンジ・ハンドシェイク認証プロトコル（「ＣＨＡＰ」）（Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を使用するリンク制御プロトコル（「ＬＣＰ」）（Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を含むステップ１６０４に示すように、選択されたＰＤＳＮとのＰＰＰセッションを確立し、選択されたＰＤＳＮに登録する。アクセス要求およびアクセス応答通信１６０６は、図２に関して先に説明されたように、アクティブＰＤＳＮとＨＡＡＡ２１６またはＦＡＡＡ２１４との間で行われる。
【００９５】
ステップ１６０８においてＩＰ制御プロトコルがＰＰＰセッションでネゴシエートされると、アクティブＰＤＳＮは、ステップ１６１０において、コールＩＤ、ＰＰＰ状態、およびＡＡＡプロフィールについてスタンバイＰＤＳＮを更新する。ＰＰＰ状態はコール毎に定められ、表２で定義されるようなＬＣＰデータと、表３で定義されるようなＰＡＰ／ＣＨＡＰデータと、表４に示されるようなＩＰＣＰデータとを含む。ＰＡＰまたはＣＨＡＰ状態自体は存在しないので、必要とされるデータは、表３に示されるように、使用されるプロトコルの記録（レコード）とユーザの認証とに限定される。
【００９６】
【表２】
【００９７】
【表３】
【００９８】
【表４】
【００９９】
ＡＡＡプロフィールは、アクセス応答においてＨＡＡＡから返されるＲＡＤＩＵＳパラメータのグループを構成し、表５に示されるパラメータを含むことができるが、これらに限定されるものではない。
【０１００】
【表５】
【０１０１】
圧縮制御プロトコル（「ＣＣＰ」）（Ｃｏｍｐｒｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が、ステップ１６１２に示されるように、モバイル・ノードとアクティブＰＤＳＮとの間でネゴシエートされる場合、表６に示されるＣＣＰ状態を提供するために、別個のＰＰＰ更新１６１４が、スタンバイＰＤＳＮに対して行われる。
【０１０２】
【表６】
【０１０３】
ユーザ・データが、ステップ１６１６に示されるように送信され始めると、アカウンティング（会計）目的の使用データ記録（「ＵＤＲ」）情報は、ステップ１６１８に示されるように、スタンバイＰＤＳＮと定期的に同期させられる。例示的なＵＤＲデータが表７に示されている。
【０１０４】
【表７】
【０１０５】
図１７は、モバイルＩＰアプリケーションのためのＮ対１のＰＤＳＮ冗長性のデータ更新構造を示している。先に図１６でシンプルＩＰの場合について説明されたように、１２２０でＲＰセッションが確立された後、ステップ１７０２で、コールＩＤおよび表１で定義されるＲＰ状態が、スタンバイＰＤＳＮへ送信される。シンプルＩＰの場合と異なり、モバイルＩＰアプリケーションでは、ＰＰＰは、ステップ１７０４に示されるように、ＬＣＰとネゴシエーションを行い、認証をスキップし、その後、ＩＰＣＰを完了する。その後、ステップ１７０６で、アクティブＰＤＳＮは、コールＩＤおよびＰＰＰ状態についてスタンバイＰＤＳＮを更新する。その後、ステップ１７０８で、ＰＰＰは、コールに対するＣＣＰを確立し、１７１０で、スタンバイＰＤＳＮは、表６に示されるようなＣＣＰ状態が更新される。ステップ１７ｌ２で、アクティブＰＤＳＮは、エージェント広告をモバイル・ノードへ送信し、その後、ステップ１７１４で、スタンバイＰＤＳＮでＭＩＰ状態が更新される。モバイル・コール毎データおよびホーム・エージェント毎データについてのＭＩＰ状態が、それぞれ、表８および表９に示されている。
【０１０６】
【表８】
【０１０７】
【表９】
【０１０８】
ＭＩＰ登録は、先に図１および図２に関して説明されたように、モバイル・ノードによるＭＩＰ登録要求（「ＲＲＱ」）１７１６と、アクティブＰＤＳＮとＨＡＡＡまたはＦＡＡＡとの間でのアクセス要求およびアクセス応答の通信１７１８と、それに続いての、アクティブＰＤＳＮとホーム・エージェントとの間でのＭＩＰ ＲＲＱ１７２０およびＭＩＰ登録応答（「ＲＲＰ」）１７２２の通信とによって、実行される。アクティブＰＤＳＮによるモバイル・ノードへのＭＩＰ ＲＲＰ１７２４の送信がなされると、１７２６で、スタンバイＰＤＳＮは、表５に定義されるようなＭＩＰ状態とＡＡＡプロフィールについて再度更新される。次に１７２８で、ユーザ・データが、モバイル・ノードとアクティブＰＤＳＮとの間で送信され始め、１７３０で、定期的なＵＤＲ更新１７３０が表７に定義されるようなアカウンティング・データを伴ってスタンバイＰＤＳＮへ送られる。ＭＩＰ再登録１７３２は、ステップ１７１６、１７１８、１７２０、１７２２、および１７２４を繰り返すコールの間に定期的に行われ、その結果、ＭＩＰ状態についてのスタンバイＰＤＳＮのＭＩＰ更新１７３４がなされる。その後、ステップ１７３６に示されるように、ユーザ・データ・フローが、スタンバイＰＤＳＮに対する定期的なＵＤＲ更新１７３８を伴いながら継続する。
【０１０９】
図１８に示されるＭＰＡコールが最初にシンプルＩＰコールと同様の方式で処理される。セッション１２２０を確立すると、アクティブＰＤＳＮは、スタンバイＰＤＳＮへＲＰ更新１８０２を提供する。ＲＰ更新は、新しいコールＩＤおよび表１で示されるＲＰ状態についてのデータを含む。モバイル・ノードは、選択されたＰＤＳＮとのＰＰＰセッションを確立し、ＰＡＰまたはＣＨＡＰを使用するＬＣＰを含むステップ１８０４に示されるように、選択されたＰＤＳＮに登録する。アクセス要求およびアクセス応答通信１８０６が、先に図２に関して説明されたように、アクティブＰＤＳＮとＨＡＡＡ２１６またはＦＡＡＡ２１４との間で行われる。ステップ１８０８で、ＰＰＰセッションにおいてＩＰ制御プロトコルがネゴシエートされると、ステップ１８１０で、アクティブＰＤＳＮは、コールＩＤ、ＰＰＰ状態、およびＡＡＡプロフィールについてスタンバイＰＤＳＮを更新する。ＰＰＰ状態は、コール毎に定義され、表２に定義されたＬＣＰデータと、表３に定義されたＰＡＰ／ＣＨＡＰデータと、表４に示されたＩＰＣＰデータとを含む。やはり、ステップ１８１２に示されるように、ＣＣＰがモバイル・ノードとアクティブＰＤＳＮとの間でネゴシエートされる場合、表６に示されるようなＣＣＰ状態を提供するために、別個のＰＰＰ更新１８１４が、スタンバイＰＤＳＮに対して行われることになる。
【０１１０】
この時点で、アクティブＰＤＳＮは、ＭＩＰ ＲＲＱ１８１６およびＭＩＰ ＲＲＰ１８１８によって、ＨＡとのプロキシＭＩＰセッションを開始する。その後、アクティブＰＤＳＮは、スタンバイＰＤＳＮへＭＩＰ更新１８２０を提供し、次に、ステップ１８２２に示されるように、ドメイン・ネーム・システム（「ＤＮＳ」）アドレスを送信するために、モバイル・ノードとＩＰＣＰを再ネゴシエートする。その後、ＰＰＰ更新１８２４が、スタンバイＰＤＳＮへ提供される。先のコール・タイプと同様に、ステップ１８２６に示されるように、ユーザ・データ送信が開始すると、表７に示されるようなアカウンティング・データとともに定期的なＵＤＲ更新１８２８がスタンバイＰＤＳＮに提供される。
【０１１１】
本明細書で開示される実施形態の場合、更新は、イベントまたは運用者によって設定されるコンフィグレーション可能トリガであるＰＤＳＮ更新タイマによって制御される。更新タイマは、アカウンティング・データ（先に図１６〜図１９に関して説明されたＵＤＲ更新）がアクティブＰＤＳＮによってスタンバイＰＤＳＮへ送られる頻度を、制御する。様々なコール・タイプの実施形態について説明された更新およびスタンバイＰＤＳＮへ送信される状態更新のトリガとなるイベントが、表１０にまとめられている。
【０１１２】
【表１０】
【０１１３】
表１０に示されるように、ＲＰ接続に関連するトリガは、コールの確立後に起こされたものである場合、ＲＰ状態情報および他のＵＤＲ情報の更新を引き起こす。同様に、モバイルＩＰコールについては、ＭＩＰネゴシエーションの要素が状態更新をトリガする。ＰＰＰの確立は、コールに関連する実質的状態データについての更新をトリガする。
【０１１４】
コール終了は、更なる状態更新のトリガを提供する。アクティブＰＤＳＮからコール終了の指示を受信すると、スタンバイＰＤＳＮは、終了されたコールに関連するコール状態を削除する。コール終了は、表１１にまとめられている。
【０１１５】
【表１１】
【０１１６】
スタンバイＰＤＳＮのフェイルオーバ動作が図１９に示されている。ハートビート・プロトコル１９０２を介して、Ｎ個のアクティブＰＤＳＮの１つが障害を起こしたと判断すると、システム・マネージャは、ステップ１９０４で、その障害および障害のあるＰＤＳＮのアクティブ・ステータスの引継ぎを、スタンバイＰＤＳＮへ通知し、そして、状態更新送信を中断するために、スタンバイＰＤＳＮがアクティブ・ステータスに遷移したことを残りのＮ−１個のアクティブＰＤＳＮへ通知する。スタンバイＰＤＳＮは、ステップ１９０６で、残りのＮ−１個のアクティブＰＤＳＮ用のすべての状態情報を廃棄し、それぞれステップ１９０８と１９１０で、ＲＰインタフェースおよびＰｉインタフェースへ障害ＰＤＳＮのアドレスを伴うＡＲＰメッセージを送信する。その後、スタンバイＰＤＳＮは、ステップ１９１２で、それまでアクティブＰＤＳＮによって処理されていたモバイル・ノードとのすべての通信を引き継ぐ。フェイルオーバが起きた後、ＩＰセキュリティ（「ＩＰｓｅｃ」）状態は再び初期設定される。
【０１１７】
再初期設定は、ＲＦＣ２４０９に従って達成される。ＩＰｓｅｃポリシ・ファイルのすべての静的ＩＰｓｅｃ情報は、システム・スタートアップで同期される。動的ＩＰｓｅｃ情報は、ユーザ・プロファイル・データ（表５の事前共有機密を参照）の一部としてＨＡＡＡ／ＦＡＡＡから返されたインターネット鍵交換（「ＩＫＥ」）（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ」）鍵を含む。
【０１１８】
ＰＤＳＮ−ＰＤＳＮ（「Ｐ−Ｐ」）インタフェースにおけるスタンバイＰＤＳＮの動作は、先に説明されたシナリオに類似している。図２０は、Ｐ−ＰセッションにおけるターゲットＰＤＳＮ２００２とアンカ（anchor）ＰＤＳＮ２００４とを示す。図２１ａに示されるように、２１０２で、ターゲットＰＤＳＮとのセッションがモバイル・ノードによって確立され、２１０４で、アンカＰＤＳＮとのＰ−Ｐトンネルが確立される。ターゲットＰＤＳＮを収容するラックまたはシェルフでは、セッションが確立された後、表１２に示されるような更新データ２１０６がスタンバイＰＤＳＮに提供される。
【０１１９】
【表１２】
【０１２０】
同様に、ターゲットＰＤＳＮを収容するラックまたはシェルフ内のスタンバイＰＤＳＮに提供される更新データ２１０８が表１３に示されている。
【０１２１】
【表１３】
【０１２２】
Ｐ−ＰトンネルにおいてアンカＰＤＳＮ２００４の障害が、ハートビート通信２１１０を介してそのラックまたはシェルフ内のシステム・マネージャ２１０１によって見つけだされると、図２１ａに示されるように、スタンバイＰＤＳＮは、ステップ２１１２で、システム・マネージャによってアクティブとして割り当てられ、Ｐ−Ｐトンネルは、ターゲットＰＤＳＮ２１０４へＰ−Ｐ登録更新２１１４を送信することによって終了させる。ターゲットＰＤＳＮは、ＬＣＰコンフィグ（ＬＣＰ−ｃｏｎｆｉｇ）２１１６をモバイルへ送信して、ＰＰＰ再ネゴシエーション２１１８を強制する。同様に、Ｐ−ＰトンネルにおいてターゲットＰＤＳＮの障害が、ハートビート通信２１２０を介してそのラックまたはシェルフ内のシステム・マネージャ２１２１によって検出されると、図２１ｂに示されるように、スタンバイＰＤＳＮは、ステップ２１２２で、システム・マネージャによってアクティブとして割り当てられ、Ｐ−Ｐトンネルは、アンカＰＤＳＮへＰ−Ｐ登録解除２１２４を送信することによって終了させる。その後、障害のあるターゲットＰＤＳＮのために動作するスタンバイＰＤＳＮは、ＬＣＰコンフィグ２１２６をモバイル・ノードへ送信して、ＰＰＰ再ネゴシエーション２１２８を強制する。それぞれの場合におけるＰ−Ｐトンネルの速やかな終了は、モバイルが迅速な方法でターゲットＰＤＳＮとのＰＰＰセッションに移ることを可能にする。
【０１２３】
図２２に示されるように、障害ＰＤＳＮが復旧または置換（交替）されると、システム・マネージャは、ハートビート検出２２０２を受信し、交替したＰＤＳＮを２２０４でスタンバイＰＤＳＮとして再割り当てし、２２０６でその割当てをアクティブＰＤＳＮに通知する。その後、２２０８で、アクティブＰＤＳＮは、上で説明されたように、確立されるそれぞれの新規セッションについて更新データの送信を開始する。
【０１２４】
更に、代替例として、Ｎ対Ｍの冗長性の方式も使用されることができる。これらの代替実施形態の幾つかでは、Ｎ対１の冗長性で使用される方法が、システム・マネージャによって割り当てられるスタンバイ・ユニットが複数となるように拡張される。また、Ｎ対Ｍの冗長性は、バックアップ・セッション情報だけを保存し且つコール処理のためには使用されないようにした特別な目的のモジュールをシャーシ／シェルフに備えることによって、更に別の代替実施形態でも達成されることができる。そのような実施形態では、バックアップ・モジュールは、アクティブおよび休止中のセッションの両方をキャッシュ記憶できるだけの十分なメモリを有し、制御情報だけが、それらのモジュールにミラーリングされる。そのような実施形態では、コール・セッションを処理するすべてのアプリケーション・モジュール（ＰＤＳＮ／ＨＡ）は、例えば、セッション到来時、セッション状態変更時、またはセッション切断時に、セッション情報を冗長モジュールへ送信する。冗長モジュールは、すべてのアクティブ・アプリケーション・モジュールのために受信情報を整理することができる。アプリケーション・モジュールが障害を起こすと、システム・マネージャは、事前に割り当てられたＭ個のモジュールのリストからバックアップ・モジュールを選択することができる。システム・マネージャは、Ｍ個のモジュールの相対負荷に基づいて、バックアップ・モジュールを選択することができる。そのような実施形態では、選択されたバックアップ・モジュールは、障害モジュールのセッション情報を、その情報を保持するＭ個のモジュールの１つから転送しなければならない。例えば、すべてのコール・セッション情報を要求する代わりに、バックアップ・モジュールは、速やかな切替えのためにアクティブ・セッション情報だけを要求することができ、後にその負荷に基づいて休止中セッション情報を取得することもできる。先の段落で説明された冗長性の方式と同様に、Ｍ個のバックアップ・モジュールは、内部の媒体データ・バスを介して通信することができる。更に、選択されたバックアップ・モジュールは、障害モジュールのネットワーク・インタフェースを引き継ぐためにルータなどのような外部デバイスへＡＲＰメッセージを送信する。
【０１２５】
上で説明されたＰＤＳＮの冗長性についての実施形態は、ＰＰＰ通信ネットワークの一般的なデバイスに適用可能である。ＰＰＰは、多くの通信システムがレイヤ３プロトコルを送るのに使用するレイヤ２プロトコルである。最も一般的に使用されるレイヤ３プロトコルは、インターネット・プロトコル（ＩＰ）である。使用可能ではあるが普通は使用されないその他のプロトコルも存在する。そのようなプロトコルの１つがＩＰＸである。
【０１２６】
ＰＰＰは、様々な物理的媒体上で使用される。これらの物理的媒体に加えて、ＰＰＰは、他の上位レイヤ・プロトコルを介してトンネリングされることもできる。物理的媒体の一例は、Ｖ．３５、Ｖ．９０などの様々なモデム・プロトコルを使用するモデム・ダイヤルアップ・リンクである。ＰＰＰが転送されるトンネリング・プロトコルの一例は、レイヤ２トンネリング・プロトコル（Ｌ２ＴＰ）である。
【０１２７】
様々な物理的媒体およびトンネリング媒体上のＰＰＰが、様々な提供物（ｏｆｆｅｒｉｎｇ）におけるデバイスを接続するために産業上において広く使用されている。そのような提供物およびデバイスの例とては、ＩＰパケットを転送（トランスポート）するためにレイヤ２リンクを確立するためにＰＰＰがＰＰＰｏＥ（ＰＰＰ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（登録商標））を介して転送されるＤＳＬや、Ｖ．３５、Ｖ．９０などのモデム・プロトコルを介してＰＰＰが転送されるＲＡＳや、先に説明された例示的な実施形態において示されたような汎用ルーティング・カプセル化（ＧＲＥ）（Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）トンネルを介してＰＰＰが転送されるＰＤＳＮや、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）・トンネルを介してＰＰＰが転送されるＧＧＳＮや、レイヤ２トンネリング・プロトコル（Ｌ２ＴＰ）・トンネルを介してＰＰＰが転送されるＬＮＳ／ＬＡＣがある。
【０１２８】
これらのデバイスのすべてにおいて、無中断サービスを提供するために冗長性の方式が重要である。どのような冗長性の方式も、スタンバイ・ユニットにバックアップされるには、これらのデバイスにおいてＰＰＰセッションを必要とする。クライアント・デバイスとアクセス・デバイスとの間のＰＰＰ手順は、上で説明されたすべてのデバイスにおけるものと同じである。従って、上で説明されたＰＤＳＮの実施形態のために具体的に定められた手順は、これらのデバイスすべてのための一般的なＰＰＰバックアップ手順として適用可能である。
【０１２９】
一般的なＰＰＰデバイスのスタンバイ・バックアップのための冗長性の方式は、ＰＰＰに関しては、少なくとも以下のモジュールのバックアップ、即ち、リンク制御プロトコル（ＬＣＰ）パラメータ、認証パラメータ、インターネット・プロトコル制御プロトコル（ＩＰＣＰ）パラメータ、および圧縮パラメータのバックアップを提供する。プライマリ・デバイスの障害時には、パラメータがバックアップされているスタンバイ・デバイスが、そのパラメータを使用してＰＰＰコンテキストを再構築し、障害を起こしたプライマリ・デバイスの役割を引き継ぐ。
【０１３０】
図２３に示されるコール・フローは、ＰＰＰセッションをバックアップするために本発明によって提供される、アクティブＰＰＰアクセス・デバイス２３０２とバックアップＰＰＰアクセス・デバイス２３０４との間の一般的な手順を示している。一般的なクライアント・デバイス２３０６は、媒体確立２３０８によってアクティブ・アクセス・デバイスとのセッションを確立する。アクティブ・アクセス・デバイスは、コンテキスト生成メッセージ２３１０を送る。バックアップ・アクセス・デバイスは、セッションについてのコンテキスト生成２３１２を行う。クライアント・デバイスとアクティブ・アクセス・デバイスとは、ＬＣＰ確立２３１４を行い、その後、アクティブ・アクセス・デバイスは、ＬＣＰ更新２３１６をバックアップ・アクセス・デバイスへ提供し、その後、バックアップ・アクセス・デバイスは、セッション用に保存されているコンテキストの更新２３１８を行う。クライアント・デバイスとアクティブ・アクセス・デバイスは、認証手順２３２０を交換し、アクティブ・アクセス・デバイスは、確認認証手順２３２４によって認証デバイス２３２２と通信する。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、認証デバイスからの確認に基づいて認証手順２３２６を交換する。次に、アクティブ・アクセス・デバイスは、認証更新２３２８をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは、それに対応してセッションについてのコンテキストの更新２３３０を行う。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、ＩＰＣＰ確立２３３２のために通信し、アクティブ・アクセス・デバイスは、ＩＰＣＰ更新２３３４をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは再びコンテキストの更新２３３６を行う。アクティブ・アクセス・デバイスとクライアント・デバイスは、圧縮プロトコル確立２３３８のために通信を行い、アクティブ・アクセス・デバイスは再びバックアップ・アクセス・デバイスの更新２３４０を行い、バックアップ・アクセス・デバイスは、コンテキストの更新２３４２を行う。その後、ユーザ・データ２３４４が、セッションの通常の進行中に、クライアント・デバイスとアクティブ・アクセス・デバイスとの間を流れる。セッションが終了すると、クライアント・デバイスとアクティブ・アクセス・デバイスは、セッション切断２３４６を行うために通信し、アクティブ・アクセス・デバイスは、終了したセッションに関連するコンテキスト削除２３４８を行うために、バックアップ・アクセス・デバイスへ更新を送信する。その後、バックアップ・アクセス・デバイスは、そのセッションについてのコンテキスト削除２３５０を行う。代替の実施形態では、ＬＣＰ、認証、およびＩＰＣＰ状態についてのコンテキスト更新は、アクティブ・アクセス・デバイスからバックアップ・アクセス・デバイスへの単一の更新として行われる。
【０１３１】
先にＰＤＳＮの実施形態に関して説明されたように、バックアップ・アクセス・デバイスは、複数のアクティブ・デバイスのバックアップとして動作することができる。ＰＰＰセッション中のいかなる時でも、アクティブ・アクセス・デバイスが障害を起こした場合には、そのアクセス・デバイス用のシステム・マネージャは、ＰＤＳＮの実施形態について先に図１９に関して説明されたように、クライアント・デバイスとの通信を引き継ぐためにバックアップ・アクセス・デバイスを作動させる。
【０１３２】
本明細書で説明されたプログラム、プロセス、方法、およびシステムは、別途指示されない限り、特定のタイプのコンピュータまたはネットワーク・システム（ハードウェアまたはソフトウェア）に関連せず、またそれらに限定されないことを理解されたい。ＩＰネットワーキングをサポートする様々なタイプの汎用または専用のコンピュータ・システムが、本明細書で説明された教示とともに使用され、また、教示に従った動作を実行することができる。本明細書で開示されたＰＤＳＮ用の実施形態は、単一の統合されたカードを提供する。しかしながら、説明されたプロセスおよび方法は、ＰＤＳＮを生成するために組み合わされる要素としてインタフェース機能、コール処理機能、およびデータ転送機能の形態をとるＰＤＳＮ機能を提供する複数のブレードを通信シャーシで使用する実施形態にも、等しく適用可能である。本明細書で説明され、特許請求される説明された冗長のための方法および通信は、統合エンティティとしてのＰＤＳＮと同様に、機能要素にも別々に適用可能である。
【０１３３】
本発明の原理が適用され得る多様な実施形態から見れば、例示された実施形態は、例であるに過ぎず、本発明の範囲を限定するものと見なすべきではないことを理解されたい。例えば、流れ図のステップは、説明されたものとは異なるシーケンスで実行されることができ、また、より多くのまたはより少ないステップを使用することができ、また、ブロック図では、より多くのまたはより少ない要素を使用することができる。好ましい実施形態の様々な要素を、ソフトウェアで実装されるものとして説明されたが、他の実施形態では、それらの要素をハードウェアまたはファームウェアとして実装することができ、また、ハードウェアまたはファームウェアとして実装した要素をソフトウェアして実装することもできる。
【０１３４】
請求項は、その趣旨で述べられない限り、説明された順序または要素に限定して読まれるべきではない。従って、添付の特許請求の範囲の範囲および精神に包含されるすべての実施形態およびその均等物は、本発明として特許請求される。
【図面の簡単な説明】
【０１３５】
【図１】図１は、従来技術によるモバイルＩＰネットワーク・アーキテクチャの例を示す機能ブロック図である。
【図２】図２は、本発明で使用するのに適したネットワーク・システムの一実施形態を示す機能ブロック図である。
【図３】図３は、本発明の一実施形態によるアクセス・ノードのブロック図である。
【図４】図４は、本発明の一実施形態によるアクセス・ノードの分散型アーキテクチャを示すブロック図である。
【図５】図５は、本発明の一実施形態によるアクセス・ノードにおける制御シェルフを示すブロック図である。
【図６】図６は、本発明の一実施形態によるアクセス・ノードにおけるデータ・シェルフを示すブロック図である。
【図７】図７は、本発明の一実施形態による、アクセス・ノードにおけるシェルフ内のピア・モジュール間のデータプレーン接続性、およびシェルフ・コントローラおよびシステム・マネージャとのバックプレーン接続性についてのシェルフ・アーキテクチャを示すブロック図である。
【図８】図８は、本発明の一実施形態によるシステム制御バスの例示的な物理的相互接続を示すブロック図である。
【図９】図９は、本発明の一実施形態による媒体データ・バスの物理的相互接続を示すブロック図である。
【図１０】図１０は、本発明の一実施形態によるシェルフ間ケーブル配線トポロジを示すブロック図である。
【図１１】図１１は、本発明の一実施形態によるＰＤＳＮ／ＨＡブート・アップ・プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１２】図１２は、本発明の一実施形態による、システム・マネージャを使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１３】図１３は、本発明の一実施形態による、分散型情報データベース機構を使用するＰＤＳＮ選択方法を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１４】図１４は、本発明の一実施形態による、システム・マネージャを使用するＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１５】図１５は、本発明の一実施形態による、分散型情報データベース機構を使用するＨＡ登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。
【図１６】図１６は、シンプルＩＰコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１７】図１７は、モバイルＩＰコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１８】図１８は、ＭＰＡコールについてのスタンバイＰＤＳＮ更新を示すメッセージ・シーケンス・シナリオのブロック図である。
【図１９】図１９は、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２０】図２０は、Ｐ−Ｐトンネル・セッションのブロック図である。
【図２１ａ】図２１ａおよび図２１ｂは、アンカＰＤＳＮおよびターゲットＰＤＳＮそれぞれの障害に対しての、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２１ｂ】図２１ａおよび図２１ｂは、アンカＰＤＳＮおよびターゲットＰＤＳＮそれぞれの障害に対しての、アクティブＰＤＳＮからスタンバイＰＤＳＮへのフェイルオーバ転送のメッセージ・シーケンス・シナリオのブロック図である。
【図２２】図２２は、スタンバイＰＤＳＮとして障害ＰＤＳＮを交替および再割当てすることを示すメッセージ・シーケンス・シナリオのブロック図である。
【図２３】図２３は、バックアップのためにコール・パラメータを更新するための、アクティブＰＰＰデバイスとそのスタンバイＰＰＰデバイスとの間の総称的通信を示すメッセージ・シーケンス・シナリオのブロック図である。
【特許請求の範囲】
【請求項１】
インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
１つのパケット・データ・サービング・ノードを、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから、登録要求を受信するステップと、
アクティブ・パケット・データ・サービング・ノードを選択するステップと、
選択された前記パケット・データ・サービング・ノード（ＰＤＳＮ）から前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記選択されたＰＤＳＮとの間で通信セッションを確立するステップと、
前記選択されたＰＤＳＮから前記スタンバイＰＤＳＮへ状態を送信するステップと、
前記スタンバイＰＤＳＮに対して前記選択されたＰＤＳＮから状態を定期的に更新するステップと、
前記選択されたＰＤＳＮに障害が発生した時に前記スタンバイＰＤＳＮへ前記通信セッションを移すステップと
を備える方法。
【請求項２】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、それぞれのアクティブＰＤＳＮは、選択された際に、前記スタンバイＰＤＳＮへ回復不能状態データを送信し、前記スタンバイＰＤＳＮに対して回復不能状態データを定期的に更新する、方法。
【請求項３】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記状態を送信するステップは、無線ネットワーク−パケット・データ・サービング・ノード（ＲＰ）・インタフェース状態についてのデータを送信するステップを含む、方法。
【請求項４】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記選択されたＰＤＳＮと前記モバイル・ノードとの間でＩＰ制御プロトコル（ＩＰＣＰ）・ネゴシエーションを完了するステップを更に含み、前記定期的に更新するステップは、
ポイントツーポイント・プロトコル（ＰＰＰ）状態を送信するステップと、
認証・許可・アカウンティング（ＡＡＡ）プロフィールを送信するステップと
を含む、
方法。
【請求項５】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、圧縮制御プロトコル（ＣＣＰ）状態を送信するステップを更に含む、方法。
【請求項６】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記ＰＰＰ状態を送信するステップは、
リンク制御プロトコル（ＬＣＰ）状態を送信するステップと、
認証プロトコル状態を送信するステップと、
ＩＰＣＰ状態を送信するステップと
を含む、
方法。
【請求項７】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルＩＰアプリケーションであり、前記ＰＰＰ状態を送信するステップは、
リンク制御プロトコル（ＬＣＰ）状態を送信するステップと、
ＩＰＣＰ状態を送信するステップと
を含む、
方法。
【請求項８】
請求項６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはＭＰＡアプリケーションであり、
前記選択されたＰＤＳＮとホーム・エージェントとの間でプロキシＭＩＰセッションを開始するステップと、
ドメイン・ネーム・システム・アドレスを送信するために前記モバイル・ノードとＩＰＣＰを再ネゴシエートするステップと
を更に含み、
前記定期的に更新するステップは、
前記プロキシ・セッションを開始した後にＭＩＰ状態を送信するステップと、
前記ＩＰＣＰを再ネゴシエートした後に前記ＰＰＰ状態を送信するステップと
を含む、
方法。
【請求項９】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、使用デート記録（ＵＤＲ）情報を同期させるステップを更に含む、方法。
【請求項１０】
請求項９に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記ＵＤＲ情報を同期させるステップは更新タイマによってトリガされる、方法。
【請求項１１】
請求項７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記選択されたＰＤＳＮから前記モバイル・ノードへエージェント広告を送信するステップと、
前記スタンバイＰＤＳＮの前記ＭＩＰ状態を更新するステップと、
前記モバイル・ノードからＭＩＰ登録要求（ＲＲＱ）を送信するステップと、
前記選択されたＰＤＳＮとホーム認証・許可・アカウンティング・サーバ（ＨＡＡＡ）との間でアクセス要求およびアクセス応答の通信を完了させるステップと、
前記選択されたＰＤＳＮからホーム・エージェントへＭＩＰ ＲＲＱを送信するステップと、
前記選択されたＰＤＳＮで前記ホーム・エージェントからのＭＩＰ登録応答（ＲＲＰ）を受信するステップと、
前記選択されたＰＤＳＮから前記モバイル・ノードへ前記ＭＩＰ ＲＲＰを送信するステップと、
前記ＭＩＰ状態について前記スタンバイＰＤＳＮを更新するステップと
を更に含む方法。
【請求項１２】
請求項１１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
コールを行っている間に定期的にＭＩＰ再登録を行うステップと、
前記ＭＩＰ状態について前記スタンバイＰＤＳＮを更新するステップと
を更に含む方法。
【請求項１３】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、複数の事前定義された更新トリガのうちの何れかのものによりトリガされる、方法。
【請求項１４】
インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
１つのパケット・データ・サービング・ノードを、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから登録要求を受信するステップと、
第１のパケット・データ・サービング・ノードから前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記パケット・データ・サービング・ノードとの間で通信セッションを確立するステップと、
更新トリガの所定の組に属する何れかの更新トリガに応答して、前記選択されたパケット・データ・サービング・ノードから前記スタンバイのパケット・データ・サービング・ノードへ、選択された回復不能のコール情報データを送信するステップと
を備える方法。
【請求項１５】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガは無線ネットワークＰＤＳＮ（ＲＰ）インタフェース・トリガであり、前記コール情報データはＲＰインタフェース状態を含む、方法。
【請求項１６】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガはポイントツーポイント・プロトコルの完了であり、前記コール情報データはリンク制御プロトコル（ＬＣＰ）状態および認証状態を含む、方法。
【請求項１７】
請求項１６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング（ＡＡＡ）・ユーザ・プロフィール・データを更に含む、方法。
【請求項１８】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルＩＰ（ＭＩＰ）・アプリケーションであり、前記トリガはＭＩＰ登録イベントであり、前記コール情報データはＭＩＰ状態を含む、方法。
【請求項１９】
請求項１８に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング（ＡＡＡ）・ユーザ・プロフィール・データを更に含む、方法。
【請求項２０】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記トリガはＰＤＳＮ更新タイマの期間満了であり、前記コール情報データはユーザ・データを含む、方法。
【請求項２１】
請求項２０に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データはＲＰ状態を更に含む、方法。
【請求項２２】
請求項２０に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはＭＩＰアプリケーションであり、前記コール情報データはＭＩＰ状態を更に含む、方法。
【請求項２３】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コールの更新トリガはコール終了トリガを含む、方法。
【請求項２４】
請求項２３に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、終了トリガを受信したときに、終了されたコールに関して前記スタンバイＰＤＳＮにおけるコール状態情報を削除する追加ステップを含む、方法。
【請求項２５】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記通信セッションを移すステップが、
前記選択されたＰＤＳＮの障害を検出するステップと、
障害を起こした前記選択されたＰＤＳＮ以外のすべてのＰＤＳＮに関する前記スタンバイＰＤＳＮ内のコール情報を削除するステップと、
前記スタンバイＰＤＳＮを使用して前記モバイル・ノードとの通信を引き継ぐステップと
を含む、
方法。
【請求項２６】
請求項２５に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記障害を検出するステップは、
前記システム・マネージャによって、前記選択されたＰＤＳＮからハートビート信号を受信するステップと、
前記ハートビート信号の消失を検出するステップと、
障害を起こした前記選択されたＰＤＳＮのアドレス情報とともにアクティブ・ステータスを前記スタンバイＰＤＳＮへ通知するステップと、
前記スタンバイＰＤＳＮへアクティブ・ステータスを再割当てしたことを前記残りのアクティブＰＤＳＮへ通知するステップと
を含む、
方法。
【請求項２７】
請求項２５に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、ＰＤＳＮ−ＰＤＳＮ（Ｐ−Ｐ）トンネルが確立され、前記通信を引き継ぐステップは、前記モバイル・ノードによる新規のＰＰＰネゴシエーションを強制するステップを含む、方法。
【請求項２８】
請求項２７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記ＰＤＳＮは前記Ｐ−ＰトンネルにおけるアンカＰＤＳＮであり、前記新規のＰＰＰネゴシエーションを強制するステップは、
ターゲットＰＤＳＮへＰ−Ｐ登録更新を送信するステップと、
前記ターゲットＰＤＳＮから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと
を含む、
方法。
【請求項２９】
請求項２７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記ＰＤＳＮは、前記Ｐ−ＰトンネルにおけるターゲットＰＤＳＮであり、前記新規のＰＰＰネゴシエーションを強制するステップは、
前記スタンバイＰＤＳＮから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと、
新しいＰ−Ｐトンネルを確立するためにＰＰＰを再びネゴシエートするステップと
を含む、
方法。
【請求項３０】
請求項２６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記システム・マネージャによって交替ＰＤＳＮのためのハートビート信号を検出するステップと、
スタンバイＰＤＳＮとして前記交替ＰＤＳＮを割り当てるステップと、
前記アクティブＰＤＳＮに、スタンバイＰＤＳＮの割当てを通知するステップと、
新規のコールセッションが確立される毎に前記アクティブＰＤＳＮから前記スタンバイＰＤＳＮへ状態更新を送信するステップと
を更に含む方法。
【請求項３１】
インターネット・プロトコル・ネットワークにおけるポイントツーポイント・プロトコル通信エレメントの冗長性のための方法であって、
複数のＮ＋１個のエレメントと少なくとも１つのシステム・マネージャとを備える通信ノードを提供するステップと、
１つのエレメントを、残りのＮ個のアクティブエレメントのためのスタンバイとして選択するステップと、
選択された前記エレメントを用いてＰＰＰクライアントとの通信セッションを確立するステップと、
前記選択されたエレメントから前記スタンバイのエレメントへ状態を送信するステップと、
前記選択されたエレメントから前記スタンバイのエレメントに対して状態を定期的に更新するステップと、
前記選択されたエレメントに障害が発生した時に、前記通信セッションを前記スタンバイ・エレメントへ移すステップと
を備える方法。
【請求項１】
インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
１つのパケット・データ・サービング・ノードを、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから、登録要求を受信するステップと、
アクティブ・パケット・データ・サービング・ノードを選択するステップと、
選択された前記パケット・データ・サービング・ノード（ＰＤＳＮ）から前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記選択されたＰＤＳＮとの間で通信セッションを確立するステップと、
前記選択されたＰＤＳＮから前記スタンバイＰＤＳＮへ状態を送信するステップと、
前記スタンバイＰＤＳＮに対して前記選択されたＰＤＳＮから状態を定期的に更新するステップと、
前記選択されたＰＤＳＮに障害が発生した時に前記スタンバイＰＤＳＮへ前記通信セッションを移すステップと
を備える方法。
【請求項２】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、それぞれのアクティブＰＤＳＮは、選択された際に、前記スタンバイＰＤＳＮへ回復不能状態データを送信し、前記スタンバイＰＤＳＮに対して回復不能状態データを定期的に更新する、方法。
【請求項３】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記状態を送信するステップは、無線ネットワーク−パケット・データ・サービング・ノード（ＲＰ）・インタフェース状態についてのデータを送信するステップを含む、方法。
【請求項４】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記選択されたＰＤＳＮと前記モバイル・ノードとの間でＩＰ制御プロトコル（ＩＰＣＰ）・ネゴシエーションを完了するステップを更に含み、前記定期的に更新するステップは、
ポイントツーポイント・プロトコル（ＰＰＰ）状態を送信するステップと、
認証・許可・アカウンティング（ＡＡＡ）プロフィールを送信するステップと
を含む、
方法。
【請求項５】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、圧縮制御プロトコル（ＣＣＰ）状態を送信するステップを更に含む、方法。
【請求項６】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記ＰＰＰ状態を送信するステップは、
リンク制御プロトコル（ＬＣＰ）状態を送信するステップと、
認証プロトコル状態を送信するステップと、
ＩＰＣＰ状態を送信するステップと
を含む、
方法。
【請求項７】
請求項４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルＩＰアプリケーションであり、前記ＰＰＰ状態を送信するステップは、
リンク制御プロトコル（ＬＣＰ）状態を送信するステップと、
ＩＰＣＰ状態を送信するステップと
を含む、
方法。
【請求項８】
請求項６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはＭＰＡアプリケーションであり、
前記選択されたＰＤＳＮとホーム・エージェントとの間でプロキシＭＩＰセッションを開始するステップと、
ドメイン・ネーム・システム・アドレスを送信するために前記モバイル・ノードとＩＰＣＰを再ネゴシエートするステップと
を更に含み、
前記定期的に更新するステップは、
前記プロキシ・セッションを開始した後にＭＩＰ状態を送信するステップと、
前記ＩＰＣＰを再ネゴシエートした後に前記ＰＰＰ状態を送信するステップと
を含む、
方法。
【請求項９】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、使用デート記録（ＵＤＲ）情報を同期させるステップを更に含む、方法。
【請求項１０】
請求項９に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記ＵＤＲ情報を同期させるステップは更新タイマによってトリガされる、方法。
【請求項１１】
請求項７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記選択されたＰＤＳＮから前記モバイル・ノードへエージェント広告を送信するステップと、
前記スタンバイＰＤＳＮの前記ＭＩＰ状態を更新するステップと、
前記モバイル・ノードからＭＩＰ登録要求（ＲＲＱ）を送信するステップと、
前記選択されたＰＤＳＮとホーム認証・許可・アカウンティング・サーバ（ＨＡＡＡ）との間でアクセス要求およびアクセス応答の通信を完了させるステップと、
前記選択されたＰＤＳＮからホーム・エージェントへＭＩＰ ＲＲＱを送信するステップと、
前記選択されたＰＤＳＮで前記ホーム・エージェントからのＭＩＰ登録応答（ＲＲＰ）を受信するステップと、
前記選択されたＰＤＳＮから前記モバイル・ノードへ前記ＭＩＰ ＲＲＰを送信するステップと、
前記ＭＩＰ状態について前記スタンバイＰＤＳＮを更新するステップと
を更に含む方法。
【請求項１２】
請求項１１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
コールを行っている間に定期的にＭＩＰ再登録を行うステップと、
前記ＭＩＰ状態について前記スタンバイＰＤＳＮを更新するステップと
を更に含む方法。
【請求項１３】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、複数の事前定義された更新トリガのうちの何れかのものによりトリガされる、方法。
【請求項１４】
インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のＮ＋１個のパケット・データ・サービング・ノードと少なくとも１つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
１つのパケット・データ・サービング・ノードを、残りのＮ個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから登録要求を受信するステップと、
第１のパケット・データ・サービング・ノードから前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記パケット・データ・サービング・ノードとの間で通信セッションを確立するステップと、
更新トリガの所定の組に属する何れかの更新トリガに応答して、前記選択されたパケット・データ・サービング・ノードから前記スタンバイのパケット・データ・サービング・ノードへ、選択された回復不能のコール情報データを送信するステップと
を備える方法。
【請求項１５】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガは無線ネットワークＰＤＳＮ（ＲＰ）インタフェース・トリガであり、前記コール情報データはＲＰインタフェース状態を含む、方法。
【請求項１６】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガはポイントツーポイント・プロトコルの完了であり、前記コール情報データはリンク制御プロトコル（ＬＣＰ）状態および認証状態を含む、方法。
【請求項１７】
請求項１６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング（ＡＡＡ）・ユーザ・プロフィール・データを更に含む、方法。
【請求項１８】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルＩＰ（ＭＩＰ）・アプリケーションであり、前記トリガはＭＩＰ登録イベントであり、前記コール情報データはＭＩＰ状態を含む、方法。
【請求項１９】
請求項１８に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング（ＡＡＡ）・ユーザ・プロフィール・データを更に含む、方法。
【請求項２０】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記トリガはＰＤＳＮ更新タイマの期間満了であり、前記コール情報データはユーザ・データを含む、方法。
【請求項２１】
請求項２０に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データはＲＰ状態を更に含む、方法。
【請求項２２】
請求項２０に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはＭＩＰアプリケーションであり、前記コール情報データはＭＩＰ状態を更に含む、方法。
【請求項２３】
請求項１４に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コールの更新トリガはコール終了トリガを含む、方法。
【請求項２４】
請求項２３に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、終了トリガを受信したときに、終了されたコールに関して前記スタンバイＰＤＳＮにおけるコール状態情報を削除する追加ステップを含む、方法。
【請求項２５】
請求項１に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記通信セッションを移すステップが、
前記選択されたＰＤＳＮの障害を検出するステップと、
障害を起こした前記選択されたＰＤＳＮ以外のすべてのＰＤＳＮに関する前記スタンバイＰＤＳＮ内のコール情報を削除するステップと、
前記スタンバイＰＤＳＮを使用して前記モバイル・ノードとの通信を引き継ぐステップと
を含む、
方法。
【請求項２６】
請求項２５に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記障害を検出するステップは、
前記システム・マネージャによって、前記選択されたＰＤＳＮからハートビート信号を受信するステップと、
前記ハートビート信号の消失を検出するステップと、
障害を起こした前記選択されたＰＤＳＮのアドレス情報とともにアクティブ・ステータスを前記スタンバイＰＤＳＮへ通知するステップと、
前記スタンバイＰＤＳＮへアクティブ・ステータスを再割当てしたことを前記残りのアクティブＰＤＳＮへ通知するステップと
を含む、
方法。
【請求項２７】
請求項２５に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、ＰＤＳＮ−ＰＤＳＮ（Ｐ−Ｐ）トンネルが確立され、前記通信を引き継ぐステップは、前記モバイル・ノードによる新規のＰＰＰネゴシエーションを強制するステップを含む、方法。
【請求項２８】
請求項２７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記ＰＤＳＮは前記Ｐ−ＰトンネルにおけるアンカＰＤＳＮであり、前記新規のＰＰＰネゴシエーションを強制するステップは、
ターゲットＰＤＳＮへＰ−Ｐ登録更新を送信するステップと、
前記ターゲットＰＤＳＮから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと
を含む、
方法。
【請求項２９】
請求項２７に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記ＰＤＳＮは、前記Ｐ−ＰトンネルにおけるターゲットＰＤＳＮであり、前記新規のＰＰＰネゴシエーションを強制するステップは、
前記スタンバイＰＤＳＮから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと、
新しいＰ−Ｐトンネルを確立するためにＰＰＰを再びネゴシエートするステップと
を含む、
方法。
【請求項３０】
請求項２６に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記システム・マネージャによって交替ＰＤＳＮのためのハートビート信号を検出するステップと、
スタンバイＰＤＳＮとして前記交替ＰＤＳＮを割り当てるステップと、
前記アクティブＰＤＳＮに、スタンバイＰＤＳＮの割当てを通知するステップと、
新規のコールセッションが確立される毎に前記アクティブＰＤＳＮから前記スタンバイＰＤＳＮへ状態更新を送信するステップと
を更に含む方法。
【請求項３１】
インターネット・プロトコル・ネットワークにおけるポイントツーポイント・プロトコル通信エレメントの冗長性のための方法であって、
複数のＮ＋１個のエレメントと少なくとも１つのシステム・マネージャとを備える通信ノードを提供するステップと、
１つのエレメントを、残りのＮ個のアクティブエレメントのためのスタンバイとして選択するステップと、
選択された前記エレメントを用いてＰＰＰクライアントとの通信セッションを確立するステップと、
前記選択されたエレメントから前記スタンバイのエレメントへ状態を送信するステップと、
前記選択されたエレメントから前記スタンバイのエレメントに対して状態を定期的に更新するステップと、
前記選択されたエレメントに障害が発生した時に、前記通信セッションを前記スタンバイ・エレメントへ移すステップと
を備える方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１ａ】
【図２１ｂ】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１ａ】
【図２１ｂ】
【図２２】
【図２３】
【公表番号】特表２００７−５１０３３２（Ｐ２００７−５１０３３２Ａ）
【公表日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願番号】特願２００６−５３６７９９（Ｐ２００６−５３６７９９）
【出願日】平成１６年１０月２２日（２００４．１０．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３４９４１
【国際公開番号】ＷＯ２００５／０４３８２１
【国際公開日】平成１７年５月１２日（２００５．５．１２）
【出願人】（５０５１４３１１２）ユーティースターコム・インコーポレーテッド (7)
【Ｆターム（参考）】
【公表日】平成１９年４月１９日（２００７．４．１９）
【国際特許分類】
【出願日】平成１６年１０月２２日（２００４．１０．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０３４９４１
【国際公開番号】ＷＯ２００５／０４３８２１
【国際公開日】平成１７年５月１２日（２００５．５．１２）
【出願人】（５０５１４３１１２）ユーティースターコム・インコーポレーテッド (7)
【Ｆターム（参考）】
[ Back to top ]