JP2007510332A - ポイントツーポイント・プロトコル・デバイスの冗長性のためのシステムおよび方法 - Google Patents
ポイントツーポイント・プロトコル・デバイスの冗長性のためのシステムおよび方法 Download PDFInfo
- Publication number
- JP2007510332A JP2007510332A JP2006536799A JP2006536799A JP2007510332A JP 2007510332 A JP2007510332 A JP 2007510332A JP 2006536799 A JP2006536799 A JP 2006536799A JP 2006536799 A JP2006536799 A JP 2006536799A JP 2007510332 A JP2007510332 A JP 2007510332A
- Authority
- JP
- Japan
- Prior art keywords
- pdsn
- packet data
- data serving
- node
- serving node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/08—Mobility data transfer
- H04W8/12—Mobility data transfer between location registers or mobility servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/17—Selecting a data network PoA [Point of Attachment]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
パケット・データ・サービング・ノード(PDSN)の冗長性を提供するシステムおよび方法が示される。例示的な一つの方法は、複数のパケット・データ・サービング・ノードと少なくとも1つのシステム・マネージャとをアクセス・ノードに提供し、アクティブPDSNとスタンバイPDSNとの割合がN対1となる冗長性を確立する。モバイル・ノードと通信セッションを確立すると、それぞれのアクティブPDSNは、回復不能データのみを含む状態更新をスタンバイPDSNへ提供する。何れかのアクティブPDSNに障害が発生すると、スタンバイPDSNがアクティブPDSNとして割当てし直されて、障害のあるユニットに代わってモバイル・ノードとの通信セッションを引き継ぐ。残りのアクティブPDSNへはその割当て換えが通知され、更新状態データの送信は中断される。
Description
関連出願の相互参照
本出願は、譲受人が本出願と同じである、2002年6月13日に出願された「SYSTEM AND METHOD FOR PACKET DATA SERVING NODE LOAD BALANCING AND FAULT TOLERANCE」と題する米国特許出願第10/170900号の一部継続出願である。
発明の分野
本発明は、モバイル・インターネット・プロトコル(「IP」)・ネットワークにおける通信に関する。より詳細には、本発明は、N対1の冗長性をもち、回復不能状態データのみ複製保存を行うパケット・データ・サービング・ノードを特に含む、ポイントツーポイント・プロトコル・デバイスの管理に関する。
本出願は、譲受人が本出願と同じである、2002年6月13日に出願された「SYSTEM AND METHOD FOR PACKET DATA SERVING NODE LOAD BALANCING AND FAULT TOLERANCE」と題する米国特許出願第10/170900号の一部継続出願である。
発明の分野
本発明は、モバイル・インターネット・プロトコル(「IP」)・ネットワークにおける通信に関する。より詳細には、本発明は、N対1の冗長性をもち、回復不能状態データのみ複製保存を行うパケット・データ・サービング・ノードを特に含む、ポイントツーポイント・プロトコル・デバイスの管理に関する。
公衆パケット交換ネットワークは、モバイル・ホストなどのようなモバイル通信デバイス(モバイル・ノード)や、1つのネットワークから別のネットワークに接続点を変更するルータなどへの、およびそれらからのトラフィックを搬送するために使用されることができる。モバイルIPデータ・ネットワーキングの基本アーキテクチャは当技術分野で知られており、複数の刊行物の中で説明されており、それらの刊行物にはリクエスト・フォー・コメント(「RFC」)文書RFC2002(1996年)(以降「RFC2002」)が含まれており、更に多くの情報については現在www.ietf.orgにおいてインターネット・エンジニアリング・タスク・フォース(「IETF」)から入手可能である。モバイルIPデータ・ネットワーキング分野の当業者は、上記の文書、および実際にモバイルIPデータ・ネットワーキングを実施するために使用されるデバイスのことをよく知っている。
モバイルIP通信ネットワークにおいて、モバイル・ノードは、「フォリン(foreign)・エージェント」および「ホーム(home)・エージェント」の2つのデバイスを用いて、IPネットワーク上のターゲット・ホストと通信する。このタイプの通信を説明するモバイルIPネットワークの一例が、「Mobile Internet Protocol(IP) Networking with Home Agent and/or Foreign Agent Functions Distributed Among Multiple Devices」と題する米国特許出願第09/354659号で提示されており、同出願の全内容を参照により本明細書に組み込む。典型的には、フォリン・エージェント機能は、モバイル・ノードが訪れたネットワーク上のルータに組み込まれる。フォリン・エージェントは、モバイル・ノードがホーム・エージェントに登録されているとき、モバイル・ノードにルーティング・サービスを提供する。例えば、フォリン・エージェントは、モバイル・ノードのホーム・エージェントによってトンネリング(tunnel、トンネル化)されたデータグラムをデトンネリング(de-tunnel、トンネル化解除)し、それをモバイル・ノードへ配送する。
典型的には、ホーム・エージェントは、モバイル・ノードのホーム・ネットワーク上のルータに組み込まれる。ホーム・エージェントは、モバイル・ノードの現在地情報を維持する。1または複数のホーム・エージェントが複数のモバイル・ノード宛のコール(call、呼)を同時に処理する場合、ホーム・エージェントは、本質的に、仮想プライベート・ネットワーク・サービスに類似のサービスを提供する。典型的には、それぞれのモバイル・ノードは、別個のホーム・ネットワークと関連づけられ、そのホーム・ネットワークからホーム・エージェントを経由してフォリン・エージェントおよびモバイル・ノードへと到るルーティング経路は、モバイル・ノード用の仮想プライベート・ネットワークに似ている。
モバイルIPは、モバイル・ノード(モバイル・エンティティ)とフォリン・エージェントとの間のリンク・レイヤ接続性を必要とする。しかしながら、幾つかのシステムでは、モバイル・ノードからのリンク・レイヤは、フォリン・エージェントから遠い地点で終了し得る。そのようなネットワークは、一般に第3世代ワイヤレス・ネットワークと呼ばれている。図1は、典型的には第3世代ワイヤレス・ネットワークで使用されるネットワーク・アーキテクチャを例示したブロック図である。図1を参照すると、モバイル・ノード10は、無線ネットワーク・ノード16、パケット・データ・サービング・ノード18、およびホーム・エージェント・ノード24の3つのデバイスを用いて、IPネットワーク30上のターゲット・ホスト34と通信する。モバイル・ノード10の物理レイヤは、無線ネットワーク・ノード16上で終端し、フォリン・エージェントの機能は、パケット・データ・サービング・ノード18上に存在する。典型的には、無線ネットワーク・ノード16が、モバイル・ノード10とパケット・データ・サービング・ノード18との間でリンク・レイヤ・プロトコル・データを中継し、パケット・データ・サービング・ノード18が、モバイル・ノード10へのリンク・レイヤを確立し、維持し、また、終了する。例えば、モバイル・ノード10は、無線アクセス・ネットワーク上の通信リンクを介して、無線ネットワーク・ノード16にリンクされることができる。
パケット・データ・サービング・ノード18は、モバイル・ノード10がホーム・エージェント24に登録されているとき、モバイル・ノード10にルーティング・サービスを提供する。パケット・データ・サービング・ノード18は、トンネリングされたデータグラムをデトンネリングし、ホーム・エージェント・ノード24からIPネットワーク20を介してモバイル・ノード10へ配送する。パケット・データ・サービング・ノード16とホーム・エージェント24との間で交換される通信トラフィックは、データ・トラフィックおよび制御トラフィックを含む。制御トラフィックは、登録要求または登録応答メッセージを含む。制御およびデータ・トラフィックは、パケット・データ・サービング・ノード16を介して送られ、モバイル・ノード10で終了する。ターゲット・ホスト34は、IPネットワーク20および30などのような、任意の数のネットワークによってホーム・ネットワーク26に接続されることができ、また、ホーム・ネットワーク26上に直接配置されることができる。代替例として、ターゲット・ホスト34は、他のタイプのパケット交換ネットワークによってホーム・ネットワークに接続されることができる。
ホーム・エージェント24は、モバイル・ノードのホーム・ネットワーク26のルータに実装されることができる。ホーム・エージェント24は、フォリン・エージェント・アドレス、モバイル・ノード10のネットワーク・アクセス識別子(「NAI:Network Access Identifier」)、モバイル・ホーム・アドレス、およびホーム・エージェントとモバイル・ノード10の間で共用される秘密鍵などのような、モバイル端末10に関する現在地情報データを維持する。ホーム・エージェントは、ターゲット・ホスト34からパケット・データ・サービング・ノード18へデータをトンネリングし、同様に、逆方向のトンネリング・サービスも提供する。レイヤ2トンネリング・プロトコル(「L2TP:Layer 2 Tunneling Protocol」)トンネルなどのような、ポイントツーポイント・トンネルに関するより多くの情報は、現在www.ietf.orgにおいて入手可能なRFC2661の中に見出されることができる。
従って、典型的には、ホーム・エージェント24は、モバイル・ノード10のために少なくとも2つの異なるタスクを実施する。第1に、ホーム・エージェント24は、モバイル・ノード10がホーム・ネットワーク26へのアクセスを許可されているかどうかを決定するために、登録および認証のプロセスを実行する。これは、例えば、モバイル・エンティティの一意シリアル番号、NAI、または製造番号、パスワード認証を用いてのモバイル・エンティティの識別情報(identification、アイデンティフィケーション)のチェック、そして場合によっては、モバイル・エンティティのアカウントが現在有効であり入金済かどうかのチェックを、含むことができる。ホーム・エージェントの登録および認証の機能は、リモート認証ダイアルイン・ユーザ・サービス(RADIUS)(Remote Authentication Dial−In User Service」)サーバのような認証・許可・アカウンティング(AAA)(authentication,authorization and accounting)サーバなどのような第2のデバイスと連携して、または第2のデバイスの支援を受けて、実行されることができる。RADIUSサーバに関するより多くの情報は、より多くの情報を得るために現在www.ietf.orgにおいて入手可能なRFC2138の中に見出されることができる。当業者に知られているように、登録プロセスは、パケット・データ・サービング・ノード18からの登録要求メッセージの受信および処理、ならびにパケット・データ・サービング・ノード18への登録応答メッセージの送信を含む。
パケット・データ・サービング・ノード18も、モバイル・ノード10のために4つの異なるタスクを実行する。パケット・データ・サービング・ノード18は、モバイル・ノード10のために登録およびセッション制御を取り扱うものであり、その制御は、ホーム・エージェント24への登録要求メッセージの送信、およびホーム・エージェント24から受信された登録応答メッセージの処理を含む。加えて、パケット・データ・サービング・ノード18は、データ・パケットを、ターゲット・ホスト34へ最終的に送信されるように、ホーム・エージェント24へ転送するためのトンネリングについての責任を有し、また、ホーム・エージェント24からのデータを、モバイル・ノード10へ最終的に配送するために、デトンネリングする責任も負う。更に、パケット・データ・サービング・ノード18は、モバイル・ノード10のために、認証、許可、アカウンティングのサービスを提供する。パケット・データ・サービング・ノードは、RADIUSサーバなどのような認証・許可・アカウンティング・サーバと連携して、または支援を受けて、認証、許可、アカウンティングの機能を実行することができる。加えて、パケット・データ・サービング・ノード18は、AAAサーバ、移動通信交換局(「MSC:mobile switching center」)、またはホーム・エージェントへのおよびそれらからの信号/データ・インタフェースを提供するPi/FAインタフェースを提供することができる。
モバイル・ノード10が、無線通信リンクを介して無線ネットワーク・ノード16へコール設定指示を送信することによって、無線ネットワーク・ノード16との通信セッションを開始するとき、無線ネットワーク・ノード16は、パケット・データ・サービング・ノード18への登録プロセスを開始する。典型的には、無線ネットワーク・ノード16は、モバイル・ノード10へサービスを提供できる複数のパケット・データ・サービング・ノードをもつように構成される。知られた従来技術では、無線ネットワーク・ノード16は、新規の通信セッションに対して働くように構成された何れのパケット・データ・サービング・ノードのステータス情報ももたない。従って、無線ネットワーク・ノード16は、モバイル・ノード10についての登録プロセスを開始するとき、モバイル・ノード10のためのパケット・データ・サービング・ノードをランダムに選択する。そのようなシステムでは、無線ネットワーク・ノードが使用可能なパケット・データ・サービング・ノードの一部はすぐに負荷過剰になり、その他のノードはほとんど使用されないということがあり得る。更に、無線ネットワーク・ノード16からの登録要求の送信先となる複数の連続するパケット・データ・サービング・ノードが負荷過剰になった場合、そのようなパケット・データ・サービング・ノードは、無線ネットワーク・ノード16からの登録要求を拒否する可能性がきわめて高く、従って、その結果、モバイル・ノード10に対するサービスが遅れる。
モバイル・ノードからのユーザ・セッションの負荷を均衡化すること(負荷バランシング)は、重要な機能である。ユーザ・セッションの負荷バランシングに使用され得る既存の方法が幾つか存在する。典型的には、無線ネットワーク・ノードが、パケット・データ・サービング・ノードのIPアドレスを複数もつようにプログラムされ、無線ネットワーク・ノードは、その中の1つを、モバイル・ノードからの着信セッションに対するサービスのために選択することができる。既存の一つの方法によれば、無線ネットワーク・ノードはパケット制御機能を含むことができ、この機能は、例えばモバイル・ノードの国際電話加入者インタフェース(電話番号など)に基づいてハッシュ値を計算し、計算されたハッシュは、パケット・データ・サービング・ノードのIPアドレスを選択するために使用されることができる。この方式の短所は、アルゴリズムが、それぞれのパケット・データ・サービング・ノードの現在の負荷を考慮していないことである。別の代替方法によれば、パケット制御機能は、パケット・データ・サービング・ノードを選択するためにラウンド・ロビン機構を用いることができる。そのような実施形態では、パケット制御機能は、後続のそれぞれの到着(着信)セッションをリスト内の次のパケット・データ・サービング・ノードへ割り当てることができ、最後のパケット・データ・サービング・ノードに達したときには最初のパケット・データ・サービング・ノードへ戻って処理を繰り返す。ラウンド・ロビン機構は、コールを、パケット・データ・サービング・ノード間で分配するが、例えば、それぞれのパケット・データ・サービング・ノードへ送られるコール・セッションのタイプを考慮していない。
更に、別の方法によれば、外部フォリン・エージェント制御ノードが、例えば、パケット・データ・サービング・ノードのメモリ使用量や処理能力使用量に基づいて、パケット・データ・サービング・ノードを選択することができる。フォリン・エージェント制御ノードの機能は、「System and Method for Managing Foreign Agent Selections in a Mobile Internet Protocol Network」と題する米国特許出願第09/881649号に説明されており、同出願の全内容を参照により本明細書に組み込む。フォリン・エージェント制御ノードは、パケット・データ・サービング・ノードの選択時に負荷バランシング機構を提供するが、その現在のアーキテクチャには幾つかの制約が存在する。第1に、複数の冗長なフォリン・エージェント制御ノードは、現在のパケット制御機能選択アルゴリズムを仮定した場合、容易にはサポートされない。第2に、フォリン・エージェント制御ノードは、システム・アーキテクチャへ更なるコンポーネントが追加されることを必要とし、PDSNがクラッシュした場合やその他の理由で使用不能になった場合、ユーザ・セッションをセーブすることを可能にしない。
従って、モバイルIPネットワークにおいてパケット・データ・サービング・ノードやホーム・エージェントなどのようなサービング・ノードを選択するための改良されたシステムおよび方法が必要である。パケット・データ・サービング・ノード用の冗長性およびフェイルオーバ機能は、モバイル・ノードに無矛盾で無中断のサービスを提供するための重要な要素を構成する。
パケット・データ・サービング・ノードのフェイルオーバ機能を備える冗長性のためのシステムおよび方法は、モバイル・インターネット・プロトコル・ネットワークにおいてアクティブPDSNとスタンバイPDSNのN対1の関係を含み、複数のN+1個のパケット・データ・サービング・ノードと少なくとも1つのシステム・マネージャをアクセス・ノードに設けることによって達成される。N+1個のパケット・データ・サービング・ノードから、1つのパケット・データ・サービング・ノードが、残りのN個のアクティブ・パケット・データ・サービング・ノード用のスタンバイ(予備)として選択される。パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するための登録要求が無線ノードから受信されたとき、1つのパケット・データ・サービング・ノードが選択され、登録応答メッセージが第1のパケット・データ・サービング・ノードから無線ノードへ送信される。モバイル・ノードと選択されたパケット・データ・サービング・ノードとの間の通信セッションが確立され、回復不能状態データが、選択されたパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送信される。スタンバイ・パケット・データ・サービング・ノードは、N個のアクティブ・パケット・データ・サービング・ノードのすべてから同じように状態データを受信する。選択されたそれぞれのパケット・データ・サービング・ノードからスタンバイ・パケット・データ・サービング・ノードへ送られた回復不能状態データの更新は定期的に達成され、選択されたパケット・データ・サービング・ノードの障害時には、通信セッションは、アクティブ・パケット・データ・サービング・ノードの役割を引き継ぐスタンバイ・パケット・データ・サービング・ノードへ移され、それはN−1個の障害の無い(非障害)パケット・データ・サービング・ノードのすべての状態データを廃棄し、モバイル・ノードとの通信を継続しながらすべての動的状態データを回復する。
本発明の上記ならびにその他の態様および利点は、添付の図面を参照しながら以下の詳細な説明を読むことによって、当業者には明らかとなるであろう。
本発明の例示的な実施形態が、添付の図面を参照しながら説明される。
本発明の例示的な実施形態が、添付の図面を参照しながら説明される。
図2は、モバイルIPネットワークにおいてモバイル・ノード用のフォリン・エージェントおよびホーム・エージェントを選択するために本発明で使用するのに適したネットワーク・システム200の実施形態を示す機能ブロック図である。本明細書で説明される上記ならびにその他の構成およびプロセスは、例として示されるに過ぎず、代わりにその他の構成および要素(例えば、インタフェース、機能、要素の順序など)が使用されることができ、また幾つかの要素は全く省略されてもよいことを理解されたい。更に、大部分の電気通信の応用においてと同様に、本明細書で説明される多くの要素は、個別のコンポーネントとして、または他のコンポーネントとともに、任意の適切な組合せで、または任意の適切な場所に実装され得る機能エンティティであることは、当業者であれば理解されよう。
図2に示されるように、システム200は、モバイル・ノード202と、基地局コントローラ204と、無線ノード206と、アクセス・ノード208および224と、IPネットワーク210と、フォリン認証・許可・アカウンティング(「FAAA」)サーバ214と、ホーム認証・許可・アカウンティング(「HAAA」)サーバ216と、ターゲット・ホスト212とを含む。モバイル・ノード202は、例えば、電話、ラップトップ・コンピュータ、ファックス、または携帯情報端末(「PDA」)などのような、任意の適切な形態をとることができる。1つのみのモバイル・ノードを図示しているが、複数のモバイル・ノードが存在できることを理解されたい。
モバイル・ノード202は、基地局(図示せず)を介して基地局コントローラ204に接続される。基地局コントローラ204は、CDMA無線ネットワークなどのような無線ネットワーク上に存在することができる。基地局コントローラ204は、無線ノード206に結合される。無線ノード206は、新規着信ユーザ通信セッションのためにPDSNを選択するパケット制御機能(「PCF」)(packet control function)を含むことができる。例えば、PCFは、PDSNの1または複数のIPアドレスをもつように前もってプログラムされることができる。
無線ノード206は、アクセス・ノード208と通信する。アクセス・ノード208は、モバイル・ノードへデータ・サービスを提供するマルチサービス・アクセス・プラットフォームである。例示的な実施形態によれば、アクセス・ノード208は、複数のPDSNを含み、そのうちの2つであるPDSN218とPDSN220とが図2に示されている。PDSN218および220は、システム・マネージャ222と通信する。システム・マネージャ222は、以下に説明される機能のなかでも特に、それぞれのPDSNからロード(負荷)/ステータス(状態)情報を受信し、モバイル・ノードへのPDSN割当てを決定する。代替例として、以下でより詳しく説明されるように、システム・マネージャ222は、負荷分散型データベースをサポートする。
アクセス・ノード208は更に、複数のHAを含むアクセス・ノード224とも通信し、複数のHAのうちの2つであるHA226とHA228とが図2に示されている。HA226および228は、システム・マネージャ230と通信する。図2は2つのアクセス・ノードを示しており、アクセス・ノード208はPDSNカードを収容し、アクセス・ノード224はHAカードを収容している。しかしながら、ネットワーク・アーキテクチャは、PDSNとHAとの組合せを収容する単一のアクセス・ノードを含むこともできることを理解されたい。
PDSN218は、モバイル・ノード202からのポイントツーポイント・プロトコル(「PPP」)セッションの終端点である。PDSN218はまた、IPパケットを得るためにPPPパケットを集めてカプセル開放(decapsulate、カプセル化解除)を行い、その後、IPパケットは、アクセス・ノード224上のHA226や228などのようなHAへ送られる。アクセス・ノード208および224は更に、それぞれFAAA214およびHAAA216に結合される。FAAA214は、PDSNへログ・オンするモバイル・ユーザの認証を行ったり、ユーザ固有のコンフィグレーション・オプションをPDSNに提供したり、モバイルIP登録時にルーティング情報を提供したりすることができる。アクセス・ノード208は更にIPネットワーク210に結合され、IPネットワークはターゲット・ホスト212に結合される。
PDSNは、モバイル・ノードのホーム・ネットワークに典型的には配置されるHAAA216とは直接に通信できないので、FAAA214は、ネットワーク・サービス・プロバイダのドメインにおいてHAAA216のプロキシとして機能することができる。そのような実施形態では、FAAA214は、PDSN218から認証要求を受信したとき、その要求をHAAA216へ送信し、HAAA216は認証応答をFAAA214へ送信し、その後FAAA214はその応答をPDSN218へ返送する。FAAA214とHAAA216との間には、認証するメッセージをそれらの間で送信されるようにするために、共有の機密が存在する。
HAAA216およびアクセス・ノード224は、モバイル・ノード202のホーム・ネットワークに存在する。HAAA216は、ホーム・ネットワークにおいてモバイル・ノード登録要求を認証することができる。HAAA216はまた、コール・セッションを設定するためのコンフィグレーション・パラメータをサービングHAへ提供することができる。例えば、コンフィグレーション・パラメータは、セキュリティ・レベルや、差別化サービス・タイプや、リバース・トンネリング・パラメータを含むことができる。HAAA216はまた、モバイル・ノード202に代わるFAAA214からの要求を認証することもできる。FAAA214は、要求をHAAA216へ送信することができ、HAAA216は、その要求を認証し、応答をFAAA214へ返送することができ、その後FAAA214は、その応答をPDSN218へ転送する。
図3は、アクセス・ノード208の例示的な実施形態を示すブロック図300である。図3に示されるアクセス・ノード208および224は、3つのシェルフ、即ち、1つの制御シェルフ302および2つのデータ・シェルフ304、306から成る単一のラック350上に構成されることができる。制御シェルフ302は、以下で図を参照しながらより詳しく説明される複数のカード(0〜N)から構成される。制御シェルフ302は、ネットワーク管理インタフェース308を介してネットワーク管理システムに結合されることができ、従って、システム・マネージャがそれらのシステムの必要に応じてアクセス・ノード208および224をコンフィグレーションできるようにする。制御シェルフ302は更に、ネットワーク316へのインタフェース310を含む。一実施形態では、ネットワーク316は、例えば、CDMAネットワーク、PSTN/TDMまたはATMネットワーク、およびインターネットなどのようなデータ・ネットワークとすることができる。しかしながら、異なるネットワークが使用されることもできる。一実施形態では、制御シャーシ内の各カードは2つのポートを含むことができ、それらは、例えば、ネットワーク316との間でデータの通信を行うのに使用されることができる2つのギガビット・イーサネット(登録商標)・ポートなどのようなものである。
更に、図3に示されるアクセス・ノード208および/または224は、やはり以下で図を参照しながらより詳しく説明される複数のカード(0〜N)を有する2つのデータ・シェルフ304および306を含む。データ・シェルフ304および306は、ネットワーク316へのインタフェース312および314を含む。図3は幾つかの外部インタフェースのみを示し、シャーシ間の接続を示していないことを理解されたい。更に、本発明は3つのシャーシを含む単一のラックに限定されず、より多くのシャーシが単一のラックへ追加されることもできることを理解されたい。
代替例として、アクセス・ノード208またはアクセス・ノード224は、複数のラックに分散されてもよい。そのような構成では、1つの制御シェルフが、複数のラックに分散された複数のデータ・シェルフを制御することができる。図4は、アクセス・ノード208の分散型ネットワーク・アーキテクチャ400を示すブロック図である。図3に示されるラック350に加えて、アクセス・ノード208は更に第2のラック450を含む。第2のラック450は、インタフェース408、410、および412を介してネットワーク316と通信し、更にインタフェース414、416、および418をそれぞれ介してネットワーク316と通信する3つのデータ・シェルフ402、404、および406を含む。本発明は2つのラックに限定されず、3以上のラックが使用されることもできることを理解されたい。
図5は、例示的な一実施形態による制御シェルフ500を示すブロック図である。図5に示される制御シェルフ500は18個のカード・スロットを含んでいるが、制御シェルフはそのような構成に限定されず、幾つかのスロットは未使用のまま何もカードを装着せずにおくことができ、また、より少数のカード・スロットが使用されることもできることを、理解されたい。例示的な実施形態によれば、制御シェルフ500のすべてのコンポーネントは、1対1の冗長性などの冗長性を示し、フェイルオーバ機能を有する。従って、制御シェルフ500の各コンポーネントは、アクティブ・カードとスタンバイ・カードとを含むことができ、アクティブ・カードが障害を起こした場合には、スタンバイ・カードがその障害を検出してアクティブ・カードの役割を引き継ぐことができるようにされる。その実施形態は、以下でより詳しく説明される。
制御シェルフ500は、2つのシェルフ・コントローラ502および504を含み、それぞれのシェルフ・コントローラは、シェルフ500の左端のスロット内に配置される高さが半分の2つのカードの形態をとる専用ハードウェアでサポートされる。更に、制御シェルフ500は、2つのスイッチ出口モジュール506および508と、2つのシステム・マネージャ510および512と、PDSN/HAカードとして示された複数のアプリケーション・カード514〜536とを含む。例示的な実施形態は、PDSNカードまたはHAカードのみを含む制御シェルフに限定されず、代替例として、制御シェルフ500は、PDSNカードとHAカードの組合せを含むことができることを理解されたい。更に、代替的な実施形態では、シェルフ・コントローラおよびシステム・マネージャは、システム管理機能を達成するために、単一または複数のカード上に構成されることができる。
例示的な実施形態では、シェルフ・コントローラ502は、プライマリ・シェルフ・コントローラとして構成されることができ、シェルフ・コントローラ504は、バックアップ・シェルフ・コントローラとして構成されることができる。それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのカード・スロットにシェルフ・コントローラを接続するのに使用されるマルチレイヤ(L2/L3)対応スイッチを含む。更に、それぞれのシェルフ・コントローラは、それぞれのスロットへの個別のバス、即ち、以下で管理バスとも呼ばれるシステム制御バスを有することができ、このバスは、単一プラットフォーム内において管理、シグナリング、およびルーティングなどのようなカード内制御通信およびカード間制御通信を提供するのに使用される。一実施形態によれば、例えば、PDSNカードは、システム制御バスを使用して、1または複数のシステム・マネージャ・カードまたは別のPDSNカードと通信することができる。そのような実施形態では、PDSNから送信されるデータは、システム制御バス、1または複数のシェルフ・コントローラ・カードを介して、1または複数のシステム・マネージャ・カードやPDSNカードなどのような宛先へ送られる。
シェルフ・コントローラ502および504は、シェルフ内ハードウェア・コンフィグレーションを管理し、ハードウェア管理を行う。例えば、シェルフ・コントローラは、シェルフ識別子およびシェルフ・シリアル番号を読み取ることができ、これらはその後、内部アドレスの割当てを容易にするために、またシステム・マネージャが特定のカード・ロケーションおよびコンフィグレーションを正確に関連づけることができるようにするために、使用されることができる。更に、シェルフ・コントローラ502および504は、シェルフ内のその他のカードおよび電源の存在検出の形態をとる物理的監視を提供する。
シェルフ・コントローラ502および504はまた、例えば、電源や、冷却ファンや、電源内に設けられた温度センサなどのステータスに関してポーリングを行うことができる。加えて、シェルフ・コントローラ502および504は、シェルフ500内の電力管理に責任をもつこともでき、それは、電源から取得可能な現在の有能電力に対する個々のカードの現在の必要量を評価することによってなされる。シェルフ・コントローラ502および504は、100Mbpsまたはそれより高速のインタフェースなどのようなイーサネット(登録商標)・インタフェース542を介して、シェルフ500内のすべてのカードと通信することができる。
スイッチ出口モジュール506および508は、システム・マネージャおよびPDSN/HAなどのようなスロット内のすべてのカードがギガビット・リンク上で互いに通信できるようにする、高速ポイントツーポイント・スイッチ(L2/L3)として構成されることができる。スイッチ出口モジュール506および508は、ネットワークとの間でデータの通信を行うために、スイッチ・ネットワーク・インタフェース538および540を使用する。
更に、制御シャーシ500は、複数のシャーシを単一点から管理するために、シンプル・ネットワーク管理プロトコル(Simple Network Management Protocol)などのような既存または今後開発される管理プロトコルを使用できるシステム・マネージャ510および512を含む。システム・マネージャ510および512は、例えばSNMPを使用してそれぞれのカードを定期的にポーリングすることによって、システム内のすべてのカードの統計およびステータス情報を維持することができる。システム・マネージャ510および512は、それぞれインタフェース544および546を介して、それぞれのカードと通信することができる。更に、それぞれのPDSNカードまたはHAカードは、ネットワーク・インタフェース、即ち、図5に示されたネットワーク・インタフェース548〜570を有する。
図6は、例示的な一実施形態によるデータ・シェルフ600を示すブロック図である。データ・シェルフ500は、インタフェース642を介してシェルフ600内のすべてのカードと通信するシェルフ・コントローラ602および604を含む。データ・シェルフ600は更に、スイッチ・ネットワーク・インタフェース638および640を介して通信する2つのスイッチ出口モジュール606および608と、インタフェース644〜670を介して通信するPDSNまたはHA610〜636とを含む。図5と同様に、データ・シェルフ600は、PDSNまたはHAのみを含むように限定されず、データ・シェルフ600は、PDSNカードとHAカードの組合せを含むこともできることを、理解されたい。
図7は、シェルフ内のピア・モジュール間のデータプレーン接続性(connectivity、コネクティビティ)およびシェルフ・コントローラおよびシステム・マネージャのバックプレーン接続性についてのシェルフ・アーキテクチャ700を示すブロック図である。
シェルフ・アーキテクチャ700は、3つの例示的なアプリケーション・モジュール702、704、および706を示している。アプリケーション・モジュール702〜706は、ネットワーク・インタフェース710、718、726と、作業間機能(「IWF」)(inter−working function)712、720、728と、管理および制御インタフェース708、716、724と、パケット処理/転送モジュール714、722、730とをそれぞれ含む。アプリケーション・モジュール702〜706は、PDSNモジュールまたはHAモジュールとすることができることを理解されたい。
ネットワーク・インタフェース710、718、および726は、例えば、PSTN、無線ネットワーク、データ・ネットワークなどのようなネットワークへのインタフェースを提供する。管理および制御インタフェース708、716、および724は、SNMPネットワーク、セッション開始プロトコル(「SIP」)(Session Initiation Protocol)ネットワーク、H.323ネットワーク、または任意の既存もしくは今後開発される信号ネットワークなどのような管理および信号ネットワークへのインタフェースを提供する。管理および制御インタフェースは、システム制御バス734(または管理バス)を介して、シェルフ・コントローラ・モジュール736および738と通信し、シェルフ・コントローラ・モジュールは、図5に示された制御シェルフ500などのような制御シェルフへ管理および制御メッセージを送信する。
システム制御バス734は、単一プラットフォーム内での管理、シグナリング、およびルーティング通信などのようなカード内/カード間制御を提供する。一実施形態では、システム制御バス734は、スイッチド・ファースト・イーサネット(登録商標)(100Mbps)システム制御バスとして実装されることができ、
プラットフォームの管理および制御機能をサポートするための、物理的に個別で専用の組込まれたネットワークを提供する。システム制御バス734は、シェルフ700の2つのシェルフ・コントローラ・モジュールのそれぞれから始まり、ピア・シェルフ・コントローラ・スロットを含むそれぞれのスロットへ到る。例えば、それぞれのシェルフ・コントローラは、1つの双方向100BaseT−TXイーサネット(登録商標)・リンクを介して、シェルフ内のすべてのスイッチ出口モジュールおよびアプリケーション・モジュールに接続されることができる。加えて、2つのシェルフ・コントローラ・モジュールは、1つの双方向100BaseT−TXイーサネット(登録商標)・リンクを介して接続されることができる。一実施形態では、それぞれの接続は、100Mbps 100BaseT−TXイーサネット(登録商標)を伝送する1対の差動トレース(differential trace)として構成されることができる。従って、そのような実施形態では、それぞれのシステム制御バス・リンクは、1対のTXおよび1対のRXファスト・イーサネット(登録商標)・リンクを含む4線インタフェースとすることができる。しかしながら、異なるタイプのリンクも使用され得ることを理解されたい。
プラットフォームの管理および制御機能をサポートするための、物理的に個別で専用の組込まれたネットワークを提供する。システム制御バス734は、シェルフ700の2つのシェルフ・コントローラ・モジュールのそれぞれから始まり、ピア・シェルフ・コントローラ・スロットを含むそれぞれのスロットへ到る。例えば、それぞれのシェルフ・コントローラは、1つの双方向100BaseT−TXイーサネット(登録商標)・リンクを介して、シェルフ内のすべてのスイッチ出口モジュールおよびアプリケーション・モジュールに接続されることができる。加えて、2つのシェルフ・コントローラ・モジュールは、1つの双方向100BaseT−TXイーサネット(登録商標)・リンクを介して接続されることができる。一実施形態では、それぞれの接続は、100Mbps 100BaseT−TXイーサネット(登録商標)を伝送する1対の差動トレース(differential trace)として構成されることができる。従って、そのような実施形態では、それぞれのシステム制御バス・リンクは、1対のTXおよび1対のRXファスト・イーサネット(登録商標)・リンクを含む4線インタフェースとすることができる。しかしながら、異なるタイプのリンクも使用され得ることを理解されたい。
図8は、例示的な一実施形態によるシステム制御バス734の例示的な物理的相互接続を示している。図8に示されるように、システム制御バス734は、2つのシェルフ・コントローラ806および808を互いに、そしてそれぞれのスイッチ出口モジュール802および804へ、ならびにPDSNカードまたはHAカードを収容するそれぞれのアプリケーション・スロットなどのようなそれぞれのアプリケーション・カード810〜836へ、相互接続する。
再び図7を参照すると、それぞれのアプリケーション・カードおよびシェルフ・コントローラは、媒体データ・バス732(以下でスイッチ構造とも呼ばれる)に接続される。媒体データ・バス732は、単一シェルフ内でLPパケット・トラフィックを分配する。媒体データ・バス732は、スター型トポロジで実装されることができ、それは、それぞれのスイッチ出口スロットから始まり、ピア・スイッチ出口スロットおよび2つのシェルフ・コントローラ・スロットを含むメイン・バックプレーンの他のすべてのスロットへ到る。一実施形態では、スイッチド・スター型バスは、それぞれの差動対が、1.25Gbps範囲、2.5Gbps範囲、またはより高速/より低速の範囲などのようなGbps範囲で信頼性の高い送信を行えるようにする。一実施形態では、スイッチ出口スロットからのそれぞれの媒体データ・バス接続は、デュアル(TX/RX)・ポイントツーポイント差動対(即ちスポーク)として構成されることができる。そのような実施形態では、ピア・スイッチ出口スロットへは2つのスポーク、それぞれのアプリケーション・モジュール・スロットへは2つのスポーク、それぞれの半シェルフ・コントローラ・スロットへは1つのスポークが存在するように、スポークは分配されることができる。
例示的な一実施形態によれば、1または複数のPDSNカードは、互いにまたはシステム・マネージャ・カードと通信するために、媒体データ・バス732を使用することができる。そのような実施形態では、PDSNカードへおよびPDSNカードから送られるデータは、媒体データ・バス732を介し、1または複数のスイッチ出口モジュールを経由して、システム・マネージャ・カードやPDSNカードなどのような目的の宛先(1または複数)へ送信される。加えて、それぞれのPDSNカードは、FAAAサーバ214へ問合せを送信するため、およびFAAAサーバ214から許可応答を受信するために、媒体データ・バス732を使用することができる。許可問合せを送信するために、PDSNカードは、許可問合せを、媒体データ・バス732およびスイッチ出口モジュールを介してFAAAサーバ214に送信することができる。それに応答して、PDSNカードは、許可応答を、FAAAサーバ214から、スイッチ出口モジュールおよび媒体データ・バスを介して、受信することができる。それぞれのHAカードも、HAAAサーバ216へ許可情報を送信するため、およびHAAAサーバ216から許可情報を受信するために、また、データをシステム・マネージャ・カードおよび他のHAカードと通信するために、媒体データ・バス732を使用することができることを、理解されたい。
図9は、例示的な一実施形態による媒体データ・バスの物理的相互接続を示すブロック図である。図9に示されるように、スイッチ出口スロット802および804は、100Mbpsイーサネット(登録商標)・リンク902を介して相互接続される。更に、それぞれのスイッチ出口スロットは、100Mbpsイーサネット(登録商標)・リンク904〜910を介してそれぞれのシェルフ・コントローラ806および808へ、また、Gbpsイーサネット(登録商標)・リンク912〜926を介してそれぞれのアプリケーション・モジュール・スロットへ、相互接続される。従って、例示的な実施形態によれば、スイッチド・ギガビット・イーサネット(登録商標)媒体データ・バスは、それぞれのシェルフ内でカード間通信をサポートする物理的に別個で専用の組込まれたネットワークを提供する。
例示的な一実施形態によれば、アクセス・ノードの構成は、1つの制御シェルフおよび5つのデータ・シェルフを含む6つのシェルフから成ることができ、それぞれのデータ・シェルフは、シグナリングおよび管理情報などのような制御情報を受信するために制御シェルフと通信する。図10は、例示的な一実施形態によるシェルフ間ケーブル配線トポロジ1000を示すブロック図である。
図10は、シェルフ・コントローラ1008および1010と、5つのデータ・シェルフ1016、1018、1020、1022、および1024とに相互接続される2つのシステム・マネージャ1012および1014を含む制御シェルフ1002を示している。例示的な実施形態によれば、それぞれのデータ・シェルフは、2つのシェルフ・コントローラを含み、そのうちの一方はバックアップ・コントローラとして構成されることができる。具体的には、図10に示されるように、データ・シェルフ1016、1018、1020、1022、および1024は、シェルフ・コントローラ1026および1028、1030および1032、1034および1036、1038および1040、1042および1044をそれぞれ含む。
それぞれのシェルフ・コントローラは、シェルフ内における管理通信インフラストラクチャを提供するマルチレイヤ・イーサネット(登録商標)・スイッチを含む。更に、それぞれのシェルフ・コントローラは、2つの外部接続を単一のスター型バス・インタフェースに提供して、冗長システム・マネージャのそれぞれが各シェルフ・コントローラへ接続できるようにする。制御シェルフ1002では、シェルフ・コントローラ1008および1010へのパスは、バックプレーンの制御プレーン・インタフェースを介して構成されることができる。
マルチシャーシ構成では、すべてのシェルフ間接続性は、物理的に制御シェルフ1002内に配置されるシステム・マネージャ1012および1014を介して、データ・シェルフ1016〜1024内のシェルフ・コントローラ1026〜1044へとなされる。シェルフ・コントローラは、そのシェルフ内のアプリケーション・カードへの物理的接続を確立する。そのような例示的な一実施形態が、図10で制御シェルフ1002に関して示されており、シェルフ・コントローラ1008および1010は、アプリケーション・モジュール1004および1006によって示される複数のアプリケーション・モジュールへ相互接続されている。
図10に示されたそれぞれのシェルフ・コントローラは、24個の10/100ポートおよび2ギガビット・イーサネット(登録商標)・ポートを含むIEEE802.1p/Q対応スイッチなどのようなマルチレイヤ(L2/L3)スイッチを含む。一実施形態では、それぞれのシェルフ・コントローラは、Broadcom社製のBCM5600シリーズStrata Switchを含むが、異なるスイッチも使用され得る。前掲の図を参照して説明されたように、それぞれのシェルフ・コントローラは、シェルフ内のそれぞれのスロットへの物理的に別個の管理バス、即ち、システム制御バスを有する。更に、シェルフ内の2つのシェルフ・コントローラは、デュアル10/100Mbpsリンクによって互いに接続される。
図10に示されたシェルフ間通信アーキテクチャは、ネットワーク管理および搬送信号の目的で使用される。またスイッチ出口モジュール(図10には示されず)は、複数のシャーシを接続するために無線システムで使用され得る2つの外部ギガビット・リンクも提供することを理解されたい。更に、図10および前掲の図に示された例示的な実施形態によれば、制御シェルフ機能は、管理および動作の一貫性を実現するために、単一の指定されたシェルフに存在する。しかしながら、制御シェルフ機能は、複数のシェルフに分散されることもできることを理解されたい。例示的な実施形態によれば、図2に示された無線ノード206のPCFは、新規の通信セッションをアクセス・ノード208の任意のPDSNへ送ることができる。システム・マネージャは、結びつけられた対として配置され、一方のシステム・マネージャ・カードは、他方のバックアップとして機能する。そのような実施形態では、プライマリ・システム・マネージャは、PDSNから負荷情報を受信したとき、その負荷情報をそのバックアップ・パートナへ渡すことができる。従って、プライマリ・システム・マネージャがソフトウェアの障害またはハードウェアの障害を起こした場合、バックアップ・システム・マネージャは障害を検出してプライマリ・システム・マネージャの機能を引き継ぐことができる。
システム・マネージャは、アクセス・ノード208のそれぞれのシャーシのすべてのカードに関する統計情報およびステータス情報を維持する。更に、それぞれのシステム・マネージャは、システム・マネージャがサービスを提供するPDSNのIPアドレスをもってプログラムされることができ、それぞれのPDSN IPアドレスは、対応するPDSNの所定の特性の組へとマッピングすることができる。例えば、システム・マネージャは、セッション・タイプ、セッション・ビット・レート、またはグループ内のそれぞれのPDSNが処理できるセッション数に基づいて、PDSNを幾つかの組にグループ化することができる。更に、アクセス・ノード208の通常動作中、システム・マネージャは、アクセス・ノード上でサービスを受けるそれぞれのモバイル端末およびそれぞれのPDSN、HA用の動的データベースを構築することができる。例示的な実施形態は、スタンドアローンのブレードに構成されるPDSNおよびHAを開示しているが、以下で開示される通信方法は、例えば、PDSN機能が、インタフェース機能用、コール処理機能用、およびデータ転送機能用の別個のエレメントで提供されるような、PDSNおよび/またはHAの機能が通信シャーシ内の1または複数のブレードによって提供される構成にも、等しく適用可能である。
一実施形態では、PDSNプロフィールまたはHAプロフィールは、PDSN IPアドレスまたはHA IPアドレスそれぞれを使用してプロフィールが生成されたPDSNまたはHAを定義することができる。更に、それぞれのプロフィールは、個々のPDSNまたはHAが処理するセッション・タイプ、セッション・ビット・レート、あるいはセッションの数を定めることができる。加えて、それぞれのPDSNおよびHAプロフィールは、個々のPDSNおよびHAのステータスおよび状態、ならびにそのPDSNおよびHAについての負荷情報を含むことができる。例えば、パラメータの中でも特に、ステータス(状態)は、PDSNまたはHAがアクティブかまたは非アクティブかを定めることができ、状態は、PDSNまたはHAがプライマリPDSN/HAであるかバックアップPDSN/HAであるかを定めることができる。それぞれのPDSNまたはHAの状態情報に加えて、プロフィールは、そのパートナとなるPDSNまたはHAのIPアドレスも定めることができる。
更に、例示的な実施形態によれば、それぞれのPDSNおよびHAは、それぞれスタンバイPDSNおよびHAへ、コール関連情報を定期的に送信するように構成されることができる。例えば、PDSNプロフィールは、特定のセッションまたはそのセッション用に使用されるPPP圧縮のタイプについてIPsecがネゴシエートされたかどうかを定めることができる。しかしながら、セッション・タイプを定めるための異なる基準も使用され得ることを理解されたい。そのような実施形態では、システム運用者は、アクセス・ノード208内の異なるPDSN用の負荷コンフィグレーションをダウンロードし、特別のセッション・タイプのユーザにより良いサービスおよび接続性を提供することができる。
例示的な実施形態によれば、アクセス・ノード208のPDSNおよびHAは、その使用可能性および負荷情報をシステム・マネージャへ伝えるためにハートビート機構を使用することができる。図11は、HAまたはPDSNなどのようなアプリケーション・モジュール用の例示的なブート・アップ・プロセスを示している。図11は、PDSNおよびHAを単一のPDSN/HAブロックとして示すことによって、PDSNおよびHA用のブート・アップ・プロセスを簡略化しているが、例示的な実施形態によれば、HAとPDSNとは、アクセス・ノード208内の異なるアプリケーション・モジュールに配置されることを理解されたい。
ステップ1102で、PDSNまたはHAなどのようなアプリケーション・モジュールは、電源が投入され、初期設定メッセージをシステム・マネージャへ送信することによって、プライマリ・システム・マネージャとの通信を開始する。ステップ1104で、システム・マネージャは、HAまたはPDSNを確認する。これを行うため、システム・マネージャは、物理的HAまたはPDSNリストからHAまたはPDSNを読み取る。確認が成功すると、ステップ1106で、システム・マネージャは、初期設定アクノレッジ(肯定応答)・メッセージをHA/PDSNへ送信する。
ステップ1108で、システム・マネージャは、このHA/PDSNのための役割を選択する。一実施形態では、役割の割当ては動的である。代替例として、システム・マネージャは、冗長性メカニズムが確立されるように、アクセス・ノード内のPDSNまたはHAなどのような各カードの役割を定める役割割当ファイルをもつように前もってプログラムされることができる。例えば、HA/PDSNは、バックアップとして働く所定のHA/PDSNを有するプライマリHA/PDSNとして構成されることができる。更に、HA/PDSNは、HA/PDSNへアクティブな役割を割り当てることができる。代替例として、HA/PDSNが別のHA/PDSNのバックアップとして割り当てられた場合、システム・マネージャは、更に、そのHA/PDSNへスタンバイとしての役割を割り当てて、所定のプライマリHA/PDSNの冗長HA/PDSNとして動作するようにさせる。異なる冗長性メカニズムが、以下でより詳しく説明される。
ステップ1110で、システム・マネージャは、HA/PDSNに役割割当てメッセージを送信し、HA/PDSNは、システム・マネージャへ役割割当アクノレッジ・メッセージ1112を送信することによって応答する。ステップ1114で、システム・マネージャは、サービス中であるというマークをHA/PDSNに付け、ステップ1116で、システム・マネージャは、ハートビート・タイマを始動させる。一実施形態では、ハートビート・タイマは、次のハートビート・メッセージがPDSN/HAから受信されるべき時間間隔を識別することができ、システム・マネージャは、その時間間隔が経過する前に次のハートビートが受信されない場合にはPDSN/HAが使用不可能であると決定する。代替例として、システム・マネージャは、2以上のハートビートがモジュールから受信されない場合に、そのモジュールが使用不可能であると決定することができる。同様に、ハートビートがシステム・マネージャから受信されない場合、HA/PDSNは、そのプライマリ・システム・マネージャの障害を検出し、その後のハートビートを、その時点でプライマリ・システム・マネージャとして動作している冗長システム・マネージャへ送信することができる。
例示的な実施形態によれば、アクセス・ノード208のすべてのPDSNおよびHAは、システム・マネージャがすべてのPDSNおよびHAのステータスをラック全体にわたって見渡せるように、システム・マネージャへハートビート情報1118を定期的に送信する。更に、代替例として、PDSN/HAモジュールは、IPマルチキャストを使用して他のPDSN/HAからコール情報を受信することもでき、そこにおいては、参加するそれぞれのPDSN/HAは、マルチキャスト・グループの一員であり、分散型情報データベースをサポートする。
例示的な実施形態によれば、PDSN/HAは、管理バス(即ち、システム制御バス)を介してシステム・マネージャと通信することができる。代替例として、制御メッセージは、媒体データ・バス(即ち、スイッチ構造)を介して交換されることもできる。
図12は、システム・マネージャを使用するPDSN選択方法を示すメッセージ・シーケンス・シナリオ1200のブロック図である。ブロック図は、モバイル・ノード(MN)と、無線ネットワーク・ノード(RNN)と、選択されたPDSNと、PDSNと、システム・マネージャとを含む。図示のPDSNおよびシステム・マネージャは、前掲の図を参照して詳しく説明されたアクセス・ノード208の部分であることを理解されたい。モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、ステップ1202に示されるように、トラフィック・チャネル(「TCH」)設定を無線ネットワーク・ノードと開始する。トラフィック・チャネルを確立すると、無線ネットワーク・ノード上のパケット制御機能(PCF)は、PDSNへ登録要求メッセージ1204を送信する。一実施形態では、PCFは、アクセス・ノード208において1組のPDSNを用いて構成されることができ、PCFは、例えば、負荷バランス機構やラウンド・ロビン機構などの内部選択メカニズムに基づいて、PDSNを選択することができる。
図12に示された実施形態では、PDSNは、登録要求メッセージ1204を受信した場合、そのセッションにサービスを提供することができない。そのPDSNが新規セッションにサービスを提供するために使用できないのには、多くの理由が含まれ得る。PDSNは、過剰な負荷がかかるため、セッションにサービスを提供することを拒否することがある。例えば、PDSNは、新規セッションを拒否するまでにサービスを提供できるセッションの数を識別する閾値レベルをもつように構成されることができる。代替例として、PDSNは、その容量を監視するように構成されることができ、容量の所定の割合が使用されている場合、新規セッションへのサービス提供を拒否することができる。更に、PDSNは、その機能コンフィグレーションが原因で新規セッションへのサービス提供を拒否することもある。例えば、PDSNは、圧縮または暗号を使用するセッションなどのような、所定のタイプのセッションだけにサービスを提供するように構成されることができる。
図12に示された実施形態では、システム・マネージャは、代替PDSNを決定する。従って、PDSNは、システム・マネージャにPDSN選択要求メッセージ2106を送信し、ステップ1208で、システム・マネージャは、1組の選択規則に基づいて新しいPDSNを選択する。選択規則は、以前の選択規則の記録およびサービス規則のタイプを含むことができる。一実施形態では、システム・マネージャは、1組の規則または異なる選択規則の組合せを使用するように構成されることができる。例えば、システム・マネージャは、着信セッションに対してサービスを提供できるPDSNのサブセットを決定するために1つの選択規則を使用することができ、その後、着信セッションに対するサービスを提供できる1つのPDSNを選択するために別の規則を使用することができる。
先の段落で述べられたように、システム・マネージャは、新しいPDSNを決定するために以前の選択規則の記録を使用することができる。そのような実施形態では、システム・マネージャは、モバイル・ノードにおける以前のセッションにサービスを提供したPDSNを決定および選択するために、モバイル・ユーザの以前の登録記録を使用する。一実施形態では、それぞれのPDSNは、コール設定が成功したときに、モバイル・ノードの登録記録を送信するように構成されることができる。
PDSNを選択すると、システム・マネージャは、PDSNへ、選択されたPDSNのIPアドレスを含むPDSN選択応答メッセージ1210を送信する。PDSNは、メッセージ1210を受信したとき、無線ネットワーク・ノードへ、選択されたPDSNのIPアドレスを含むRP登録応答メッセージ1212を送信する。RP登録応答メッセージ1212は、RFC2002に記載されたメッセージ「エラー136(Error 136)」の形をとることができる。しかしながら、異なるタイプのメッセージが使用されることもできる。
次に、無線ネットワーク・ノードは、RP登録要求メッセージ1214を選択されたPDSNへ送信し、選択されたPDSNは、ステップ1216に示されるように、着信セッションにサービスを提供するために資源を割り当てる。選択されたPDSNが着信セッションにサービスを提供することを拒否することがあり、システム・マネージャに問い合わせるプロセスが繰り返されることがあることを理解されたい。そのような実施形態では、システム・マネージャは、PDSN選択要求が選択されたPDSNから送信されたと判断することができ、システム・マネージャは、要求を送信したPDSNのIPアドレスを含むPDSN選択応答によって応答することができる。加えて、PDSN選択応答メッセージは、PDSNがセッションにサービスを提供すべきことをPDSNに通知する所定のビットまたはビット・パターンなどのである識別子を含むことができる。更に、要求を処理することを拒否したPDSNの数を示す所定のビットまたはビット・パターンが、PDSN選択応答メッセージ内に設定されることができることを理解されたい。そのような実施形態では、PDSNは、所定数のPDSNがセッションにサービスを提供することを拒否したときに、要求を受け入れるように構成されることができる。サービス遅延、即ち、多数のPDSNが新規セッションを拒否することを防止する異なる実施形態も使用され得ることを理解されたい。
資源を割り当てると、選択されたPDSNは、RP登録応答メッセージ1218を送信し、1220で示されるように、RPセッションが、無線ネットワーク・ノードと選択されたPDSNとの間で確立される。更に、例示的な実施形態によれば、新規セッションへ資源を割当てると、選択されたPDSNは、システム・マネージャへ、選択されたPDSNの新しい負荷を含む更新メッセージ1222を送信する。更新メッセージ1222は、モバイル・ノードのNAIまたはIMSIを含む、確立されたコール・セッションのためのセッション情報を含むことができる。代替例として、選択されたPDSNは、システム・マネージャへ、セッション情報を含む別個のメッセージを送信することができる。先の段落に関して述べられたように、モバイル・ノードが次に登録するときに、システム・マネージャは、最後のサービス提供PDSNを決定するためにセッション情報を使用することができる。ステップ1224で、モバイル・ノードは、選択されたPDSNに対するポイントツーポイント・プロトコル(「PPP」)セッションを確立し、選択されたPDSNに登録する。
図13は、分散型制御ノード方法によるPDSN選択を示すメッセージ・シーケンス・シナリオ1300のブロック図である。分散型制御ノード機構では、アクセス・ノード内のそれぞれのPDSNカードは、アクセス・ノード208のすべてのPDSNの負荷情報を提供するようにシステム・マネージャへ定期的に要求することができる。代替例として、PDSNは、アクセス・ノード208のすべてのPDSNから負荷情報を受信することができる。そのような実施形態では、それぞれのPDSNは、IPマルチキャスト方法またはその他の現存の又は今後開発される伝送方式を使用して、他のPDSNへ負荷情報を提供することができる。図13は、モバイル・ノードと、パケット制御機能を有する無線ネットワーク・ノードと、選択されたPDSNと、PDSNと、システム・マネージャとを示している。
モバイル・ノードは、無線ネットワーク・ノードのサービス・エリアに入ったとき、無線ネットワーク・ノードへ、無線ネットワーク・ノードとのトラフィック・チャネルを確立するための要求を含むメッセージ1302を送信する。チャネルが確立されると、無線ネットワーク・ノードは、PDSNへRP登録要求メッセージ1304を送信する。パケット制御機能がそのPDSNテーブルに複数のPDSN IPアドレスを保持する実施形態では、パケット制御機能は、PDSNのIPアドレスを決定するために負荷バランシング機構を使用することができる。代替例として、パケット制御機能は、プライマリPDSNのIPアドレスとセカンダリPDSNのIPアドレスとを含む2つのエントリだけをそのテーブルに保持することができる。そのような実施形態では、PCFは、プライマリPDSNが着信セッションに対してサービスできなくなるまで、すべての新規コール・セッション要求をプライマリPDSNへ送信することができる。プライマリPDSNが障害を起こすか又は負荷過剰になった場合、PCFは、セカンダリPDSNのIPアドレスへ新規コール・セッションを送ることができる。
図13に示される実施形態によれば、PDSNは、それが着信登録要求に対するサービスを提供できないこと、または少なくとも、そのPDSNが、好ましくは別のPDSNがコールを処理すべきであると判断される所定の閾値レベルより上にあることを決定する。PDSNは、図12を参照して説明された複数の要因に基づいて、その決定を下すことができる。
無線ネットワーク・ノードが選択を行い、選択されたPDSNのIPアドレスへRP登録要求メッセージ1310を送信すると、選択されたPDSNは、1312に示すように、資源を新規セッションに割り当てる。次に、選択されたPDSNは、RP登録応答メッセージ1314を送信し、RPセッション1316が、無線ネットワーク・ノードと選択されたPDSNとの間で確立される。更に、例示的な実施形態によれば、選択されたPDSNは、1318に示すように、その更新された負荷情報を最初のPDSNへ送信する。図13は、選択されたPDSNから負荷情報を受信するPDSNを1つだけ示しているが、選択されたPDSNは、そのマルチキャスト・グループ内の他のPDSNへもその負荷を送ることができることを理解されたい。更に、後でより詳しく説明されるように、選択されたPDSNは、スタンバイPDSNへ、その新規コール情報を送信することができる。システム・マネージャも同様にマルチキャスト・グループの一員となり得ることを理解されたい。代替例として、選択されたPDSNは、ハートビート・メッセージによってその新しい負荷をシステム・マネージャへ送ることができる。
選択されたPDSNへの登録が成功すると、PPPセッションが、モバイル・ノードと選択されたPDSNとの間で確立され、モバイルが、1322に示すように、選択されたPDSNに登録される。
例示的な一実施形態によると、PDSNに加えて、アクセス・ノードは、システム・マネージャによって管理されるHAも含むことができる。図11を参照して述べられたように、アクセス・ノード内のすべてのHAは、ハートビートをシステム・マネージャに送信し、その負荷情報を定期的にシステム・マネージャへ送信する。PDSNに関して説明された実施形態と同様に、システム・マネージャは、アクセス・ノードのそれぞれのHAに対する負荷を含む制御ノード・データベースを保持することができる。代替例として、制御ノード・データベースは、すべてのHAにわたって分散されることができ、それぞれの参加するHAは、他のすべての参加するHAの負荷情報を保持することができる。そのような実施形態において、それぞれの参加するHAは、IPマルチキャストを使用して、他のHA上のその負荷を更新することができ、すべての参加するHAおよびシステム・マネージャは、分散型制御ノード情報データベースをサポートするマルチキャスト・グループの一員であることができる。
図14は、最初のHAが使用不可能なときにシステム・マネージャが新しいHAを選択する実施形態におけるHA登録プロセスを示すメッセージ・シーケンス・シナリオ1400のブロック図である。図14は、モバイル・ノードと、PDSNと、システム・マネージャと、HAと、選択されたHAと、HAAAとを示している。
モバイル・ノードは、図12および図13を参照して説明された方法の1つを使用してPDSNとのPPPセッションを確立するとき、PDSNへMIP登録要求メッセージ1402を送信する。一実施形態では、登録要求メッセージ1402は、モバイル・ノードによって要求されるHAのIPアドレスを指定することができる。代替例として、PDSNは、モバイル・ノード用のHAのIPアドレスを決定するために、FAAAサーバにコンタクトすることができる。PDSNは、1404で例示されるように、その後にHAへ登録要求メッセージを送る。図14に示される実施形態によれば、HAは、例えば、過剰負荷もしくは過剰負荷に近い状況のために、またはモバイル・ノードによって提示された静的モバイル・ノードIPアドレスが現在のHAのIPアドレス・プールに属していないために、コール・セッションを処理できないことを、決定する。HAは、負荷マップに関してスタンバイHAと通信する。異なるメッセージ方式も、代替ホーム・エージェントのIPアドレスを取得するのに使用され得ることを理解されたい。
HAは、スタンバイHAから冗長グループ内の他のHAの負荷情報を受信する。アクティブHAは、バックアップHAから負荷マップを含む定期的メッセージを受信する。この負荷マップは、冗長グループ内のそれぞれのHAの平均負荷と、最小負荷のものから4つの小負荷のHAの負荷とを含む。アクティブHAは、代替HAを選択する必要があるかどうかを決定するために、この負荷情報を使用する。アクティブHAの負荷が平均負荷より一定の比率だけ大きくなった場合、アクティブHAは、負荷マップから、4つの小負荷のHAのうちで最小負荷のものを選択する。その後、モバイルIP登録要求1410は、処理のために代替のHAへ送られる。
ステップ1416で、選択されたHAは、MIP登録要求メッセージを認証し、モバイル・ノード用にMBRを生成する。更に、選択されたHAは、PDSNへのIPトンネルのネゴシエーションおよび設定を開始する。次に、選択されたHAは、MIP登録応答メッセージ1418をPDSNへ送信し、MIP登録応答メッセージ1418のホーム・エージェント・フィールドは、その選択されたHAのIPアドレスを含む。ステップ1420で、PDSNは、モバイル・ノードのために選択されたHAへのIPトンネルおよびビジタ・リスト(VL)を作成する。PDSNは、それぞれのモバイルIPコール用にVLを作成することができ、それぞれのVLは、サービングHAのIPアドレスと、モバイル・ノードのIPアドレスと、トンネリング・パラメータと、認証情報とを含むことができる。
ステップ1422で、PDSNは、MIP応答メッセージをモバイル・ノードへ送る。ステップ1424で、選択されたHAは、MBR更新メッセージ1424もシステム・マネージャへ送信し、その後、システム・マネージャは、ステップ1426に示すように、MBRを更新するとMBR更新ACKメッセージ1428によって応答する。MIPセッションは、ステップ1430に示すように確立される。更に、ステップ1432で、選択されたHAは、その現在の負荷データを含む更新メッセージをシステム・マネージャへ送信する。
図15は、HAが分散型情報データベース機構に参加する、HA登録プロセスを示すメッセージ・シーケンス・シナリオのブロック図である。そのような実施形態では、それぞれのHAは、例えば、そのHAに過剰な負荷がかかっている場合に新しいHAを決定するように構成されることができる。更に、そのような実施形態では、それぞれの参加するHAは、スタンバイHAから、他の参加するHAの負荷更新情報を定期的に受信することができる。代替例として、HAは、IPマルチキャストを介してそれぞれの参加するHAから負荷情報を受信することができる。図14と同様に、図15は、モバイル・ノードと、PDSNと、システム・マネージャと、HAと、選択されたHAと、HAAAとを示している。
PDSNに対するPPPセッションを確立すると、モバイル・ノードは、MIP登録要求メッセージ1502をPDSNへ送信する。一実施形態では、MIP登録要求メッセージは、モバイル・ノードによって要求されたHAのIPアドレスを含むことができる。代替例として、PDSNは、そのモバイル・ノード用のHAのIPアドレスを決定するために、FAAAに問い合わせることができる。次にPDSNは、ステップ1504に示されるように、登録要求メッセージをHAへ送る。
HAは、MIP登録要求メッセージ1504を受信すると、その要求にサービスを提供できないと決定し、ステップ1506に示されるように、新しいHAを選択する。図15に示される例示的な実施形態によれば、HAは、分散型情報データベースに参加し、それによって、この方式に参加する他のHAの負荷情報を有する。従って、選択基準は、それぞれのHAの負荷に基づくことができ、その選択において、HAは、例えば、最低の負荷、セッション・タイプ、コール・データ速度、またはユーザに関連するサービス・タイプを有するHAを選択する。HAは、その後、ステップ1508で示されるように、MIP登録要求を、選択されたHAへ送る。
更に、選択されたHAは、アクセス要求メッセージをHAAAに送信することができ、HAAAは、アクセス承認メッセージ1512によって応答する。ステップ1514で、選択されたHAは、MIP登録要求メッセージを認証し、MBRを生成し、PDSNに対するIPトンネルを設定する。ステップ1516で、選択されたHAは、MIP応答メッセージをPDSNに送信し、PDSNはそれに応答して、1518に示されるように、モバイル・ノードのためのビジタ・リスト(VL)を生成し、選択されたHAに対するIPトンネルを設定する。ステップ1520で、PDSNは、MIP登録応答メッセージをモバイル・ノードへ送り、ステップ1532に示されるように、MIPセッションが確立される。
ステップ1522で、選択されたHAは、MBR更新をシステム・マネージャへ送信し、システム・マネージャは、ステップ1524で、MBRを更新し、MBR ACKメッセージ1526を送信する。更に、ステップ1528で、選択されたHAは、分散型データベース機構に参加するHAへ更新メッセージを送信し、その更新メッセージは、HAの現在の更新された負荷を含む。図15は、更新メッセージ1528を受信するHAを1つだけ示している。しかしながら、HAはすべての参加するHAによって受信されるIPマルチキャストを生成できることを理解されたい。更に、更新メッセージは、スタンバイHAによっても受信される。HAは、スタンバイHA用に排他的メッセージを生成できることや、代替例として、1530に示されるように、スタンバイHAのIPアドレスもマルチキャスト・グループへ含まれ得ることも理解されたい。
負荷バランシング、および、さもなければ着信通信セッションの選択的なルーティングおよび再ルーティングに加えて、制御シェルフおよびデータ・シェルフのコンポーネントは、フェイルオーバ機能をもつ冗長性を示す。例えば、図5に示され且つそれを参照して説明された制御シェルフは、2つのシェルフ・コントローラ502および504と、2つのシステム・マネージャ510および512とを含む。そのような実施形態では、システム・マネージャ/シェルフ・コントローラの一つがアクティブのシステム・マネージャ/シェルフ・コントローラとして構成され、他の1つは冗長(スタンバイ)システム・マネージャ/シェルフ・コントローラとして構成される。従って、アクティブ・ユニットが障害を起こした場合、冗長ユニットが障害を検出し、アクティブ・ユニットの役割を引き継ぐことができる。
スタンバイ・システム・マネージャおよびシェルフ・コントローラは、それらのアクティブ・パートナとのハートビート動作を実行して、アクティブ・パートナが使用できないことを決定することができる。スタンバイ・エンティティは、そのハートビート・タイマがタイムアウトになるたびに、ハートビート要求メッセージを送信することができ、アクティブ・エンティティは、アクノレッジメント(肯定応答)メッセージによって応答することができる。肯定応答メッセージが受信されない場合、スタンバイ・エンティティは、そのアクティブ・エンティティが動作していないと仮定することができる。代替例として、コンフィグレーションに基づいて、アクティブ・エンティティは、ハートビートを再送信することができ、それに対する応答が受信されない場合、そのパートナが動作していないと仮定することができる。更に、例示的な一実施形態によれば、結び合わされた対の各メンバは、そのパートナのデータの完全なミラー・イメージを有する。例えば、それぞれのPDSNまたはHAは、それぞれのシステム・マネージャとの2つの別個の物理的リンクをもち、それにより、アクティブ・システム・マネージャおよびバックアップ・システム・マネージャは同時に同じ情報を受信する。代替例として、アクティブ・システム・マネージャは、1または複数のPDSNまたはHAから、更新された負荷情報を受信することができ、そして、その受信した情報を例えばシステムのデータ・バスを介してスタンバイ・システム・マネージャへ渡すことができる。
更に、それぞれのアプリケーション・モジュール(PDSN/HA)は、1対1の冗長性を提供するために、結び合わされた対として構成されることができ、1対のパートナにおけるそれぞれのPDSNは、他方のパートナのためのバックアップとして機能する。新規セッションがPDSNに到着すると、PDSNは、そのパートナへセッションに関連するすべての状態情報を送信する。同様に、セッション状態情報は、状態が変化したときにも、パートナに渡される。従って、結び合わされた対の各メンバは、そのパートナのセッションの完全なミラー・イメージを有する。例示的な実施形態によれば、PDSN/HAは、スイッチ出口モジュールまたは内部バスを介して通信することができる。更に、パートナPDSN/HAは、プライマリPDSNが障害を起こした場合にセッションを引き継ぐことができる。例示的な一実施形態によれば、PDSN/HAは、同時係属中の特許出願第10/041436号、「Smooth Handoff via State Exchange in Wireless Network」で説明されているハンドオフ方法を使用することができ、この出願の全体を参照によって本明細書に組み込むものとする。
複数のコンフィグレーション方式が、機能的冗長性を達成するために使用され得ることを理解されたい。例えば、上で述べられたように、2つのPDSN/HAは、プライマリおよびセカンダリ(バックアップ)のPDSN/HAとして対をなすように構成されることができ、プライマリPDSN/HAは、サービスできなくなるまで、すべてのセッションを処理する。そのような実施形態では、バックアップPDSN/HAは、プライマリPDSN/HAの障害時にその機能を引き継ぐ受動的な非アクティブなバックアップである。更に、セカンダリまたはバックアップのPDSN/HAは、内部媒体データ・バスを介してプライマリPDSN/HAで受信されるすべてのトラフィックのミラー・イメージを受信し、また、バックアップPDSN/HAは、外部にデータを伝える能力をもたない。そのような実施形態では、バックアップ・アプリケーション・モジュールの外部インタフェースでバックアップ・アプリケーション・モジュールを出ていくすべてのデータは、除去される。
プライマリ/バックアップ・コンフィグレーションでは、システム・マネージャは、シェルフ内のすべてのアクティブ・カードの活動ステータスを監視する。これを行うために、システム・マネージャは、インターネット・エンジニアリング・タスク・フォース(「IETF」)のリクエスト・フォー・コメント(「RFC」)1157に完全に説明されているシンプル・ネットワーク・マネジメント・プロトコル(「SNMP」)を使用することができ、この文献を参照によって本明細書に組み込むものとする。一実施形態では、SNMPは、管理情報ベース(「MIB」)(Management Information Base)を含むPDSN/HAにポーリングを行うため使用されることができる。更に、システム・マネージャは、それぞれのカードのステータスを決定するために、コモン・オブジェクト・リクエスト・ブローカ・アーキテクチャ(「CORBA」)(Common Object Request Broker Architecture)を基にする方法を使用することができる。SNMPを使用して、システム・マネージャは、障害のあるPDSN/HAがSNMPポーリングに応答しない場合、PDSN/HAの障害を検出することができる。プライマリPDSN/HAが障害を起こしたとき、システム・マネージャは、バックアップPDSN/HAへメッセージを送信し、バックアップPDSN/HAは、プライマリPDSN/HAとして動作する。更に、バックアップPDSN/HAは、引継ぎを行うと、アドレス解決プロトコル(「ARP」)(Address Resolution Protocol)メッセージを外部ルータへ送信して、データが、障害を起こしたPDSN/HAではなくバックアップPDSN/HAへ送られるようにする。また、プライマリPDSN/HAが障害を起こしたとき、バックアップPDSN/HAは、プライマリ・カードと同じ外部IPアドレスを使用する。
冗長性のための別の例示的な実施形態によれば、2つの結び合わされたPDSN/HAがアクティブであり、通信セッションを処理することができる。そのような実施形態では、プライマリPDSN/HAは、アクティブ通信セッションのみについてデータを媒体データ・バスを介してバックアップPDSN/HAへ送信し、セッションが休止状態になった場合、バックアップPDSN/HAは、セッション情報をそのメモリから削除し、一方、プライマリPDSN/HAはなおもそれを保持し続ける。そのような実施形態では、このタイプの冗長性をサポートするためのメモリ要件は最低限に抑えられ、アクティブ・セッションだけがバックアップPDSN/HAにキャッシュされて、プライマリPDSN/HAが障害を起こした場合の速やかな切替えに備える。更に、アクティブ・カードは、バックアップされるセッションのデータ処理を省くために、アクティブ・セッションの制御データだけを送信することができる。バックアップPDSN/HAが引継ぎを行うと、バックアップ・モジュール(今はプライマリ・モジュールである)は、ARPメッセージを外部ネットワーク・エンティティへ送り、障害を起こしたカードのIPアドレスを、その関連ネットワーク・インタフェース、例えばR−PインタフェースやPiインタフェースなどに結び付ける。
更に、代替例としては、1対1の冗長性の代わりに、シャーシ内の1つのアプリケーション・モジュール(PDSN/HA)が、他のすべてのアプリケーション・モジュール(PDSN/HA)用のバックアップとして割り当てられ、その結果として、N対1の冗長性を生み出すことができる。N対1の冗長性の方式は、大多数の通信セッションがしばしば休止中となる通信システムでは望ましいことがある。従って、冗長とされるべきであり且つデータおよびコールの喪失を回避するためのシステムの場合、バックアップ・モジュールが、アクティブ・セッションのために必要とされる。そのような実施形態では、単一のバックアップ・モジュールによってバックアップされ得るプライマリ・モジュールの数は、N個のPDSN/HAのアクティブ・セッションをバックアップするのに必要とされるメモリ量に基づいて決定されることができる。
N対1の冗長性の方式では、すべてのアクティブ・モジュールは、コールの状態に影響する制御および何らかのデータ情報を1つのバックアップ・モジュールへ送信する。N個のPDSN/HAのうちの1または複数のものが障害を起こした場合、システム・マネージャは、障害モジュールについてバックアップ・モジュールへ通知し、バックアップ・モジュールは、障害モジュールに対するネットワーク・インタフェースを提供する。
スタンバイPDSNにおいて最小限の通信トラフィックと記憶要件とをもった望ましいN対1の冗長性を達成するために、回復不能状態だけがスタンバイPDSNへ転送される。N個のアクティブPDSNによってスタンバイPDSNへ転送される更新は、適用されるデータのタイプおよび送信される頻度に基づいてカテゴリに分割される。
本明細書で開示される実施形態のデータ・タイプには以下のものがある。
PDSN全体の状態およびすべてのコールに適用される「PDSN毎データ」。PDSN毎状態の例は、気付IPアドレス、MACアドレスなどを含む。
特定のHAおよびそのHA上のすべてのコールに関連する状態を含む「ホーム・エージェント(HA)毎データ」。HA毎状態の例は、HA IPアドレス、FA−HA SPIおよびキーなどを含む。
特定のコールだけに属する状態である「コール毎データ」。コール毎状態の例は、PPP状態、モバイルIP(MIP)状態などを含む。
本明細書で開示される実施形態の更新タイプには以下のものがある。
ただ1度のみ送信されることを想定した「静的更新」。静的更新は2度以上送信されることもできるが、その想定される頻度はきわめて低い。静的更新の例は、SIPコールのホームIPアドレスであり得る。
PDSN外部の発信源からの情報受信またはPDSN内の状態変化に応答して送信される「トリガされた更新」。トリガされた更新の例は、PCFからの休止指示、PPPアイドル・タイマのタイムアウトなどである。
非常に速やかに変化する、場合によっては、ユーザによって送信または受信されるパケット毎に変化するデータを送信する「動的更新」。
PDSN全体の状態およびすべてのコールに適用される「PDSN毎データ」。PDSN毎状態の例は、気付IPアドレス、MACアドレスなどを含む。
特定のHAおよびそのHA上のすべてのコールに関連する状態を含む「ホーム・エージェント(HA)毎データ」。HA毎状態の例は、HA IPアドレス、FA−HA SPIおよびキーなどを含む。
特定のコールだけに属する状態である「コール毎データ」。コール毎状態の例は、PPP状態、モバイルIP(MIP)状態などを含む。
本明細書で開示される実施形態の更新タイプには以下のものがある。
ただ1度のみ送信されることを想定した「静的更新」。静的更新は2度以上送信されることもできるが、その想定される頻度はきわめて低い。静的更新の例は、SIPコールのホームIPアドレスであり得る。
PDSN外部の発信源からの情報受信またはPDSN内の状態変化に応答して送信される「トリガされた更新」。トリガされた更新の例は、PCFからの休止指示、PPPアイドル・タイマのタイムアウトなどである。
非常に速やかに変化する、場合によっては、ユーザによって送信または受信されるパケット毎に変化するデータを送信する「動的更新」。
後で説明される実施形態の場合、N個のアクティブPDSNカードおよびスタンバイPDSNカードのそれぞれは、図11に関して先に説明されたように、システム・マネージャによってアクティブ/スタンバイの役割を割り当てられる。システム・マネージャは、それぞれのアクティブPDSNへ、その関連づけられたスタンバイPDSNを、役割割当てプロトコルの一部として通知する。
PDSNのN対1の冗長性を使用するシステムの例示的な実施形態が、シンプルIPコールに関して図16に示されている。図面中の実施形態の場合、1つのアクティブPDSN218が示されており、本明細書に示され説明される1つのアクティブPDSNの通信について把握している1つのスタンバイPDSN220は、N個のアクティブPDSNのそれぞれに対して複製されている。アクティブPDSNとスタンバイPDSNとの間の通信は、先に図8に関して説明されたようなシステム制御バスを使用して、図示の実施形態において実行される。PDSNの選択およびRPセッションの確立は、図12に関して説明されるように達成される。セッションが確立されると、アクティブPDSNは、RP更新1602をスタンバイPDSNへ提供する。RP更新は、新しいコールIDおよびRP状態についてのデータを含む。それぞれのコールは、アクティブPDSNに対して一意のコール識別子で識別される。RP状態に関して送信されるデータが表1に示されている。
図12に関して先に説明されたように、モバイル・ノードは、パスワード認証プロトコル(「PAP」)(Password Authentication Protocol)またはチャレンジ・ハンドシェイク認証プロトコル(「CHAP」)(Challenge Handshake Authentication Protocol)を使用するリンク制御プロトコル(「LCP」)(Link Control Protocol)を含むステップ1604に示すように、選択されたPDSNとのPPPセッションを確立し、選択されたPDSNに登録する。アクセス要求およびアクセス応答通信1606は、図2に関して先に説明されたように、アクティブPDSNとHAAA216またはFAAA214との間で行われる。
ステップ1608においてIP制御プロトコルがPPPセッションでネゴシエートされると、アクティブPDSNは、ステップ1610において、コールID、PPP状態、およびAAAプロフィールについてスタンバイPDSNを更新する。PPP状態はコール毎に定められ、表2で定義されるようなLCPデータと、表3で定義されるようなPAP/CHAPデータと、表4に示されるようなIPCPデータとを含む。PAPまたはCHAP状態自体は存在しないので、必要とされるデータは、表3に示されるように、使用されるプロトコルの記録(レコード)とユーザの認証とに限定される。
AAAプロフィールは、アクセス応答においてHAAAから返されるRADIUSパラメータのグループを構成し、表5に示されるパラメータを含むことができるが、これらに限定されるものではない。
圧縮制御プロトコル(「CCP」)(Compression Control Protocol)が、ステップ1612に示されるように、モバイル・ノードとアクティブPDSNとの間でネゴシエートされる場合、表6に示されるCCP状態を提供するために、別個のPPP更新1614が、スタンバイPDSNに対して行われる。
ユーザ・データが、ステップ1616に示されるように送信され始めると、アカウンティング(会計)目的の使用データ記録(「UDR」)情報は、ステップ1618に示されるように、スタンバイPDSNと定期的に同期させられる。例示的なUDRデータが表7に示されている。
図17は、モバイルIPアプリケーションのためのN対1のPDSN冗長性のデータ更新構造を示している。先に図16でシンプルIPの場合について説明されたように、1220でRPセッションが確立された後、ステップ1702で、コールIDおよび表1で定義されるRP状態が、スタンバイPDSNへ送信される。シンプルIPの場合と異なり、モバイルIPアプリケーションでは、PPPは、ステップ1704に示されるように、LCPとネゴシエーションを行い、認証をスキップし、その後、IPCPを完了する。その後、ステップ1706で、アクティブPDSNは、コールIDおよびPPP状態についてスタンバイPDSNを更新する。その後、ステップ1708で、PPPは、コールに対するCCPを確立し、1710で、スタンバイPDSNは、表6に示されるようなCCP状態が更新される。ステップ17l2で、アクティブPDSNは、エージェント広告をモバイル・ノードへ送信し、その後、ステップ1714で、スタンバイPDSNでMIP状態が更新される。モバイル・コール毎データおよびホーム・エージェント毎データについてのMIP状態が、それぞれ、表8および表9に示されている。
MIP登録は、先に図1および図2に関して説明されたように、モバイル・ノードによるMIP登録要求(「RRQ」)1716と、アクティブPDSNとHAAAまたはFAAAとの間でのアクセス要求およびアクセス応答の通信1718と、それに続いての、アクティブPDSNとホーム・エージェントとの間でのMIP RRQ1720およびMIP登録応答(「RRP」)1722の通信とによって、実行される。アクティブPDSNによるモバイル・ノードへのMIP RRP1724の送信がなされると、1726で、スタンバイPDSNは、表5に定義されるようなMIP状態とAAAプロフィールについて再度更新される。次に1728で、ユーザ・データが、モバイル・ノードとアクティブPDSNとの間で送信され始め、1730で、定期的なUDR更新1730が表7に定義されるようなアカウンティング・データを伴ってスタンバイPDSNへ送られる。MIP再登録1732は、ステップ1716、1718、1720、1722、および1724を繰り返すコールの間に定期的に行われ、その結果、MIP状態についてのスタンバイPDSNのMIP更新1734がなされる。その後、ステップ1736に示されるように、ユーザ・データ・フローが、スタンバイPDSNに対する定期的なUDR更新1738を伴いながら継続する。
図18に示されるMPAコールが最初にシンプルIPコールと同様の方式で処理される。セッション1220を確立すると、アクティブPDSNは、スタンバイPDSNへRP更新1802を提供する。RP更新は、新しいコールIDおよび表1で示されるRP状態についてのデータを含む。モバイル・ノードは、選択されたPDSNとのPPPセッションを確立し、PAPまたはCHAPを使用するLCPを含むステップ1804に示されるように、選択されたPDSNに登録する。アクセス要求およびアクセス応答通信1806が、先に図2に関して説明されたように、アクティブPDSNとHAAA216またはFAAA214との間で行われる。ステップ1808で、PPPセッションにおいてIP制御プロトコルがネゴシエートされると、ステップ1810で、アクティブPDSNは、コールID、PPP状態、およびAAAプロフィールについてスタンバイPDSNを更新する。PPP状態は、コール毎に定義され、表2に定義されたLCPデータと、表3に定義されたPAP/CHAPデータと、表4に示されたIPCPデータとを含む。やはり、ステップ1812に示されるように、CCPがモバイル・ノードとアクティブPDSNとの間でネゴシエートされる場合、表6に示されるようなCCP状態を提供するために、別個のPPP更新1814が、スタンバイPDSNに対して行われることになる。
この時点で、アクティブPDSNは、MIP RRQ1816およびMIP RRP1818によって、HAとのプロキシMIPセッションを開始する。その後、アクティブPDSNは、スタンバイPDSNへMIP更新1820を提供し、次に、ステップ1822に示されるように、ドメイン・ネーム・システム(「DNS」)アドレスを送信するために、モバイル・ノードとIPCPを再ネゴシエートする。その後、PPP更新1824が、スタンバイPDSNへ提供される。先のコール・タイプと同様に、ステップ1826に示されるように、ユーザ・データ送信が開始すると、表7に示されるようなアカウンティング・データとともに定期的なUDR更新1828がスタンバイPDSNに提供される。
本明細書で開示される実施形態の場合、更新は、イベントまたは運用者によって設定されるコンフィグレーション可能トリガであるPDSN更新タイマによって制御される。更新タイマは、アカウンティング・データ(先に図16〜図19に関して説明されたUDR更新)がアクティブPDSNによってスタンバイPDSNへ送られる頻度を、制御する。様々なコール・タイプの実施形態について説明された更新およびスタンバイPDSNへ送信される状態更新のトリガとなるイベントが、表10にまとめられている。
表10に示されるように、RP接続に関連するトリガは、コールの確立後に起こされたものである場合、RP状態情報および他のUDR情報の更新を引き起こす。同様に、モバイルIPコールについては、MIPネゴシエーションの要素が状態更新をトリガする。PPPの確立は、コールに関連する実質的状態データについての更新をトリガする。
コール終了は、更なる状態更新のトリガを提供する。アクティブPDSNからコール終了の指示を受信すると、スタンバイPDSNは、終了されたコールに関連するコール状態を削除する。コール終了は、表11にまとめられている。
スタンバイPDSNのフェイルオーバ動作が図19に示されている。ハートビート・プロトコル1902を介して、N個のアクティブPDSNの1つが障害を起こしたと判断すると、システム・マネージャは、ステップ1904で、その障害および障害のあるPDSNのアクティブ・ステータスの引継ぎを、スタンバイPDSNへ通知し、そして、状態更新送信を中断するために、スタンバイPDSNがアクティブ・ステータスに遷移したことを残りのN−1個のアクティブPDSNへ通知する。スタンバイPDSNは、ステップ1906で、残りのN−1個のアクティブPDSN用のすべての状態情報を廃棄し、それぞれステップ1908と1910で、RPインタフェースおよびPiインタフェースへ障害PDSNのアドレスを伴うARPメッセージを送信する。その後、スタンバイPDSNは、ステップ1912で、それまでアクティブPDSNによって処理されていたモバイル・ノードとのすべての通信を引き継ぐ。フェイルオーバが起きた後、IPセキュリティ(「IPsec」)状態は再び初期設定される。
再初期設定は、RFC2409に従って達成される。IPsecポリシ・ファイルのすべての静的IPsec情報は、システム・スタートアップで同期される。動的IPsec情報は、ユーザ・プロファイル・データ(表5の事前共有機密を参照)の一部としてHAAA/FAAAから返されたインターネット鍵交換(「IKE」)(Internet Key Exchange」)鍵を含む。
PDSN−PDSN(「P−P」)インタフェースにおけるスタンバイPDSNの動作は、先に説明されたシナリオに類似している。図20は、P−PセッションにおけるターゲットPDSN2002とアンカ(anchor)PDSN2004とを示す。図21aに示されるように、2102で、ターゲットPDSNとのセッションがモバイル・ノードによって確立され、2104で、アンカPDSNとのP−Pトンネルが確立される。ターゲットPDSNを収容するラックまたはシェルフでは、セッションが確立された後、表12に示されるような更新データ2106がスタンバイPDSNに提供される。
同様に、ターゲットPDSNを収容するラックまたはシェルフ内のスタンバイPDSNに提供される更新データ2108が表13に示されている。
P−PトンネルにおいてアンカPDSN2004の障害が、ハートビート通信2110を介してそのラックまたはシェルフ内のシステム・マネージャ2101によって見つけだされると、図21aに示されるように、スタンバイPDSNは、ステップ2112で、システム・マネージャによってアクティブとして割り当てられ、P−Pトンネルは、ターゲットPDSN2104へP−P登録更新2114を送信することによって終了させる。ターゲットPDSNは、LCPコンフィグ(LCP−config)2116をモバイルへ送信して、PPP再ネゴシエーション2118を強制する。同様に、P−PトンネルにおいてターゲットPDSNの障害が、ハートビート通信2120を介してそのラックまたはシェルフ内のシステム・マネージャ2121によって検出されると、図21bに示されるように、スタンバイPDSNは、ステップ2122で、システム・マネージャによってアクティブとして割り当てられ、P−Pトンネルは、アンカPDSNへP−P登録解除2124を送信することによって終了させる。その後、障害のあるターゲットPDSNのために動作するスタンバイPDSNは、LCPコンフィグ2126をモバイル・ノードへ送信して、PPP再ネゴシエーション2128を強制する。それぞれの場合におけるP−Pトンネルの速やかな終了は、モバイルが迅速な方法でターゲットPDSNとのPPPセッションに移ることを可能にする。
図22に示されるように、障害PDSNが復旧または置換(交替)されると、システム・マネージャは、ハートビート検出2202を受信し、交替したPDSNを2204でスタンバイPDSNとして再割り当てし、2206でその割当てをアクティブPDSNに通知する。その後、2208で、アクティブPDSNは、上で説明されたように、確立されるそれぞれの新規セッションについて更新データの送信を開始する。
更に、代替例として、N対Mの冗長性の方式も使用されることができる。これらの代替実施形態の幾つかでは、N対1の冗長性で使用される方法が、システム・マネージャによって割り当てられるスタンバイ・ユニットが複数となるように拡張される。また、N対Mの冗長性は、バックアップ・セッション情報だけを保存し且つコール処理のためには使用されないようにした特別な目的のモジュールをシャーシ/シェルフに備えることによって、更に別の代替実施形態でも達成されることができる。そのような実施形態では、バックアップ・モジュールは、アクティブおよび休止中のセッションの両方をキャッシュ記憶できるだけの十分なメモリを有し、制御情報だけが、それらのモジュールにミラーリングされる。そのような実施形態では、コール・セッションを処理するすべてのアプリケーション・モジュール(PDSN/HA)は、例えば、セッション到来時、セッション状態変更時、またはセッション切断時に、セッション情報を冗長モジュールへ送信する。冗長モジュールは、すべてのアクティブ・アプリケーション・モジュールのために受信情報を整理することができる。アプリケーション・モジュールが障害を起こすと、システム・マネージャは、事前に割り当てられたM個のモジュールのリストからバックアップ・モジュールを選択することができる。システム・マネージャは、M個のモジュールの相対負荷に基づいて、バックアップ・モジュールを選択することができる。そのような実施形態では、選択されたバックアップ・モジュールは、障害モジュールのセッション情報を、その情報を保持するM個のモジュールの1つから転送しなければならない。例えば、すべてのコール・セッション情報を要求する代わりに、バックアップ・モジュールは、速やかな切替えのためにアクティブ・セッション情報だけを要求することができ、後にその負荷に基づいて休止中セッション情報を取得することもできる。先の段落で説明された冗長性の方式と同様に、M個のバックアップ・モジュールは、内部の媒体データ・バスを介して通信することができる。更に、選択されたバックアップ・モジュールは、障害モジュールのネットワーク・インタフェースを引き継ぐためにルータなどのような外部デバイスへARPメッセージを送信する。
上で説明されたPDSNの冗長性についての実施形態は、PPP通信ネットワークの一般的なデバイスに適用可能である。PPPは、多くの通信システムがレイヤ3プロトコルを送るのに使用するレイヤ2プロトコルである。最も一般的に使用されるレイヤ3プロトコルは、インターネット・プロトコル(IP)である。使用可能ではあるが普通は使用されないその他のプロトコルも存在する。そのようなプロトコルの1つがIPXである。
PPPは、様々な物理的媒体上で使用される。これらの物理的媒体に加えて、PPPは、他の上位レイヤ・プロトコルを介してトンネリングされることもできる。物理的媒体の一例は、V.35、V.90などの様々なモデム・プロトコルを使用するモデム・ダイヤルアップ・リンクである。PPPが転送されるトンネリング・プロトコルの一例は、レイヤ2トンネリング・プロトコル(L2TP)である。
様々な物理的媒体およびトンネリング媒体上のPPPが、様々な提供物(offering)におけるデバイスを接続するために産業上において広く使用されている。そのような提供物およびデバイスの例とては、IPパケットを転送(トランスポート)するためにレイヤ2リンクを確立するためにPPPがPPPoE(PPP over Ethernet(登録商標))を介して転送されるDSLや、V.35、V.90などのモデム・プロトコルを介してPPPが転送されるRASや、先に説明された例示的な実施形態において示されたような汎用ルーティング・カプセル化(GRE)(Generic Routing Encapsulation)トンネルを介してPPPが転送されるPDSNや、GPRSトンネリング・プロトコル(GTP)・トンネルを介してPPPが転送されるGGSNや、レイヤ2トンネリング・プロトコル(L2TP)・トンネルを介してPPPが転送されるLNS/LACがある。
これらのデバイスのすべてにおいて、無中断サービスを提供するために冗長性の方式が重要である。どのような冗長性の方式も、スタンバイ・ユニットにバックアップされるには、これらのデバイスにおいてPPPセッションを必要とする。クライアント・デバイスとアクセス・デバイスとの間のPPP手順は、上で説明されたすべてのデバイスにおけるものと同じである。従って、上で説明されたPDSNの実施形態のために具体的に定められた手順は、これらのデバイスすべてのための一般的なPPPバックアップ手順として適用可能である。
一般的なPPPデバイスのスタンバイ・バックアップのための冗長性の方式は、PPPに関しては、少なくとも以下のモジュールのバックアップ、即ち、リンク制御プロトコル(LCP)パラメータ、認証パラメータ、インターネット・プロトコル制御プロトコル(IPCP)パラメータ、および圧縮パラメータのバックアップを提供する。プライマリ・デバイスの障害時には、パラメータがバックアップされているスタンバイ・デバイスが、そのパラメータを使用してPPPコンテキストを再構築し、障害を起こしたプライマリ・デバイスの役割を引き継ぐ。
図23に示されるコール・フローは、PPPセッションをバックアップするために本発明によって提供される、アクティブPPPアクセス・デバイス2302とバックアップPPPアクセス・デバイス2304との間の一般的な手順を示している。一般的なクライアント・デバイス2306は、媒体確立2308によってアクティブ・アクセス・デバイスとのセッションを確立する。アクティブ・アクセス・デバイスは、コンテキスト生成メッセージ2310を送る。バックアップ・アクセス・デバイスは、セッションについてのコンテキスト生成2312を行う。クライアント・デバイスとアクティブ・アクセス・デバイスとは、LCP確立2314を行い、その後、アクティブ・アクセス・デバイスは、LCP更新2316をバックアップ・アクセス・デバイスへ提供し、その後、バックアップ・アクセス・デバイスは、セッション用に保存されているコンテキストの更新2318を行う。クライアント・デバイスとアクティブ・アクセス・デバイスは、認証手順2320を交換し、アクティブ・アクセス・デバイスは、確認認証手順2324によって認証デバイス2322と通信する。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、認証デバイスからの確認に基づいて認証手順2326を交換する。次に、アクティブ・アクセス・デバイスは、認証更新2328をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは、それに対応してセッションについてのコンテキストの更新2330を行う。次に、アクティブ・アクセス・デバイスとクライアント・デバイスは、IPCP確立2332のために通信し、アクティブ・アクセス・デバイスは、IPCP更新2334をバックアップ・アクセス・デバイスへ提供し、バックアップ・アクセス・デバイスは再びコンテキストの更新2336を行う。アクティブ・アクセス・デバイスとクライアント・デバイスは、圧縮プロトコル確立2338のために通信を行い、アクティブ・アクセス・デバイスは再びバックアップ・アクセス・デバイスの更新2340を行い、バックアップ・アクセス・デバイスは、コンテキストの更新2342を行う。その後、ユーザ・データ2344が、セッションの通常の進行中に、クライアント・デバイスとアクティブ・アクセス・デバイスとの間を流れる。セッションが終了すると、クライアント・デバイスとアクティブ・アクセス・デバイスは、セッション切断2346を行うために通信し、アクティブ・アクセス・デバイスは、終了したセッションに関連するコンテキスト削除2348を行うために、バックアップ・アクセス・デバイスへ更新を送信する。その後、バックアップ・アクセス・デバイスは、そのセッションについてのコンテキスト削除2350を行う。代替の実施形態では、LCP、認証、およびIPCP状態についてのコンテキスト更新は、アクティブ・アクセス・デバイスからバックアップ・アクセス・デバイスへの単一の更新として行われる。
先にPDSNの実施形態に関して説明されたように、バックアップ・アクセス・デバイスは、複数のアクティブ・デバイスのバックアップとして動作することができる。PPPセッション中のいかなる時でも、アクティブ・アクセス・デバイスが障害を起こした場合には、そのアクセス・デバイス用のシステム・マネージャは、PDSNの実施形態について先に図19に関して説明されたように、クライアント・デバイスとの通信を引き継ぐためにバックアップ・アクセス・デバイスを作動させる。
本明細書で説明されたプログラム、プロセス、方法、およびシステムは、別途指示されない限り、特定のタイプのコンピュータまたはネットワーク・システム(ハードウェアまたはソフトウェア)に関連せず、またそれらに限定されないことを理解されたい。IPネットワーキングをサポートする様々なタイプの汎用または専用のコンピュータ・システムが、本明細書で説明された教示とともに使用され、また、教示に従った動作を実行することができる。本明細書で開示されたPDSN用の実施形態は、単一の統合されたカードを提供する。しかしながら、説明されたプロセスおよび方法は、PDSNを生成するために組み合わされる要素としてインタフェース機能、コール処理機能、およびデータ転送機能の形態をとるPDSN機能を提供する複数のブレードを通信シャーシで使用する実施形態にも、等しく適用可能である。本明細書で説明され、特許請求される説明された冗長のための方法および通信は、統合エンティティとしてのPDSNと同様に、機能要素にも別々に適用可能である。
本発明の原理が適用され得る多様な実施形態から見れば、例示された実施形態は、例であるに過ぎず、本発明の範囲を限定するものと見なすべきではないことを理解されたい。例えば、流れ図のステップは、説明されたものとは異なるシーケンスで実行されることができ、また、より多くのまたはより少ないステップを使用することができ、また、ブロック図では、より多くのまたはより少ない要素を使用することができる。好ましい実施形態の様々な要素を、ソフトウェアで実装されるものとして説明されたが、他の実施形態では、それらの要素をハードウェアまたはファームウェアとして実装することができ、また、ハードウェアまたはファームウェアとして実装した要素をソフトウェアして実装することもできる。
請求項は、その趣旨で述べられない限り、説明された順序または要素に限定して読まれるべきではない。従って、添付の特許請求の範囲の範囲および精神に包含されるすべての実施形態およびその均等物は、本発明として特許請求される。
Claims (31)
- インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のN+1個のパケット・データ・サービング・ノードと少なくとも1つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
1つのパケット・データ・サービング・ノードを、残りのN個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから、登録要求を受信するステップと、
アクティブ・パケット・データ・サービング・ノードを選択するステップと、
選択された前記パケット・データ・サービング・ノード(PDSN)から前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記選択されたPDSNとの間で通信セッションを確立するステップと、
前記選択されたPDSNから前記スタンバイPDSNへ状態を送信するステップと、
前記スタンバイPDSNに対して前記選択されたPDSNから状態を定期的に更新するステップと、
前記選択されたPDSNに障害が発生した時に前記スタンバイPDSNへ前記通信セッションを移すステップと
を備える方法。 - 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、それぞれのアクティブPDSNは、選択された際に、前記スタンバイPDSNへ回復不能状態データを送信し、前記スタンバイPDSNに対して回復不能状態データを定期的に更新する、方法。
- 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記状態を送信するステップは、無線ネットワーク−パケット・データ・サービング・ノード(RP)・インタフェース状態についてのデータを送信するステップを含む、方法。
- 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記選択されたPDSNと前記モバイル・ノードとの間でIP制御プロトコル(IPCP)・ネゴシエーションを完了するステップを更に含み、前記定期的に更新するステップは、
ポイントツーポイント・プロトコル(PPP)状態を送信するステップと、
認証・許可・アカウンティング(AAA)プロフィールを送信するステップと
を含む、
方法。 - 請求項4に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、圧縮制御プロトコル(CCP)状態を送信するステップを更に含む、方法。
- 請求項4に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記PPP状態を送信するステップは、
リンク制御プロトコル(LCP)状態を送信するステップと、
認証プロトコル状態を送信するステップと、
IPCP状態を送信するステップと
を含む、
方法。 - 請求項4に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルIPアプリケーションであり、前記PPP状態を送信するステップは、
リンク制御プロトコル(LCP)状態を送信するステップと、
IPCP状態を送信するステップと
を含む、
方法。 - 請求項6に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはMPAアプリケーションであり、
前記選択されたPDSNとホーム・エージェントとの間でプロキシMIPセッションを開始するステップと、
ドメイン・ネーム・システム・アドレスを送信するために前記モバイル・ノードとIPCPを再ネゴシエートするステップと
を更に含み、
前記定期的に更新するステップは、
前記プロキシ・セッションを開始した後にMIP状態を送信するステップと、
前記IPCPを再ネゴシエートした後に前記PPP状態を送信するステップと
を含む、
方法。 - 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、使用デート記録(UDR)情報を同期させるステップを更に含む、方法。
- 請求項9に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記UDR情報を同期させるステップは更新タイマによってトリガされる、方法。
- 請求項7に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記選択されたPDSNから前記モバイル・ノードへエージェント広告を送信するステップと、
前記スタンバイPDSNの前記MIP状態を更新するステップと、
前記モバイル・ノードからMIP登録要求(RRQ)を送信するステップと、
前記選択されたPDSNとホーム認証・許可・アカウンティング・サーバ(HAAA)との間でアクセス要求およびアクセス応答の通信を完了させるステップと、
前記選択されたPDSNからホーム・エージェントへMIP RRQを送信するステップと、
前記選択されたPDSNで前記ホーム・エージェントからのMIP登録応答(RRP)を受信するステップと、
前記選択されたPDSNから前記モバイル・ノードへ前記MIP RRPを送信するステップと、
前記MIP状態について前記スタンバイPDSNを更新するステップと
を更に含む方法。 - 請求項11に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
コールを行っている間に定期的にMIP再登録を行うステップと、
前記MIP状態について前記スタンバイPDSNを更新するステップと
を更に含む方法。 - 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記定期的に更新するステップは、複数の事前定義された更新トリガのうちの何れかのものによりトリガされる、方法。
- インターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
複数のN+1個のパケット・データ・サービング・ノードと少なくとも1つのシステム・マネージャとを備えるアクセス・ノードを提供するステップと、
1つのパケット・データ・サービング・ノードを、残りのN個のアクティブ・パケット・データ・サービング・ノード用のスタンバイとして選択するステップと、
パケット・データ・サービング・ノードとモバイル・ノードとの間で通信セッションを確立するために、無線ノードから登録要求を受信するステップと、
第1のパケット・データ・サービング・ノードから前記無線ノードへ登録応答メッセージを送信するステップと、
前記モバイル・ノードと前記パケット・データ・サービング・ノードとの間で通信セッションを確立するステップと、
更新トリガの所定の組に属する何れかの更新トリガに応答して、前記選択されたパケット・データ・サービング・ノードから前記スタンバイのパケット・データ・サービング・ノードへ、選択された回復不能のコール情報データを送信するステップと
を備える方法。 - 請求項14に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガは無線ネットワークPDSN(RP)インタフェース・トリガであり、前記コール情報データはRPインタフェース状態を含む、方法。
- 請求項14に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記更新トリガはポイントツーポイント・プロトコルの完了であり、前記コール情報データはリンク制御プロトコル(LCP)状態および認証状態を含む、方法。
- 請求項16に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング(AAA)・ユーザ・プロフィール・データを更に含む、方法。
- 請求項14に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはモバイルIP(MIP)・アプリケーションであり、前記トリガはMIP登録イベントであり、前記コール情報データはMIP状態を含む、方法。
- 請求項18に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データは、認証・許可・アカウンティング(AAA)・ユーザ・プロフィール・データを更に含む、方法。
- 請求項14に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記トリガはPDSN更新タイマの期間満了であり、前記コール情報データはユーザ・データを含む、方法。
- 請求項20に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コール情報データはRP状態を更に含む、方法。
- 請求項20に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記モバイル・ノードはMIPアプリケーションであり、前記コール情報データはMIP状態を更に含む、方法。
- 請求項14に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記コールの更新トリガはコール終了トリガを含む、方法。
- 請求項23に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、終了トリガを受信したときに、終了されたコールに関して前記スタンバイPDSNにおけるコール状態情報を削除する追加ステップを含む、方法。
- 請求項1に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記通信セッションを移すステップが、
前記選択されたPDSNの障害を検出するステップと、
障害を起こした前記選択されたPDSN以外のすべてのPDSNに関する前記スタンバイPDSN内のコール情報を削除するステップと、
前記スタンバイPDSNを使用して前記モバイル・ノードとの通信を引き継ぐステップと
を含む、
方法。 - 請求項25に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、前記障害を検出するステップは、
前記システム・マネージャによって、前記選択されたPDSNからハートビート信号を受信するステップと、
前記ハートビート信号の消失を検出するステップと、
障害を起こした前記選択されたPDSNのアドレス情報とともにアクティブ・ステータスを前記スタンバイPDSNへ通知するステップと、
前記スタンバイPDSNへアクティブ・ステータスを再割当てしたことを前記残りのアクティブPDSNへ通知するステップと
を含む、
方法。 - 請求項25に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、PDSN−PDSN(P−P)トンネルが確立され、前記通信を引き継ぐステップは、前記モバイル・ノードによる新規のPPPネゴシエーションを強制するステップを含む、方法。
- 請求項27に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記PDSNは前記P−PトンネルにおけるアンカPDSNであり、前記新規のPPPネゴシエーションを強制するステップは、
ターゲットPDSNへP−P登録更新を送信するステップと、
前記ターゲットPDSNから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと
を含む、
方法。 - 請求項27に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、障害を起こした前記PDSNは、前記P−PトンネルにおけるターゲットPDSNであり、前記新規のPPPネゴシエーションを強制するステップは、
前記スタンバイPDSNから前記モバイル・ノードへ、再ネゴシエーションを要求するメッセージを送信するステップと、
新しいP−Pトンネルを確立するためにPPPを再びネゴシエートするステップと
を含む、
方法。 - 請求項26に記載のインターネット・プロトコル・ネットワークにおけるパケット・データ・サービング・ノードの冗長性のための方法であって、
前記システム・マネージャによって交替PDSNのためのハートビート信号を検出するステップと、
スタンバイPDSNとして前記交替PDSNを割り当てるステップと、
前記アクティブPDSNに、スタンバイPDSNの割当てを通知するステップと、
新規のコールセッションが確立される毎に前記アクティブPDSNから前記スタンバイPDSNへ状態更新を送信するステップと
を更に含む方法。 - インターネット・プロトコル・ネットワークにおけるポイントツーポイント・プロトコル通信エレメントの冗長性のための方法であって、
複数のN+1個のエレメントと少なくとも1つのシステム・マネージャとを備える通信ノードを提供するステップと、
1つのエレメントを、残りのN個のアクティブエレメントのためのスタンバイとして選択するステップと、
選択された前記エレメントを用いてPPPクライアントとの通信セッションを確立するステップと、
前記選択されたエレメントから前記スタンバイのエレメントへ状態を送信するステップと、
前記選択されたエレメントから前記スタンバイのエレメントに対して状態を定期的に更新するステップと、
前記選択されたエレメントに障害が発生した時に、前記通信セッションを前記スタンバイ・エレメントへ移すステップと
を備える方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/693,294 US7082130B2 (en) | 2002-06-13 | 2003-10-24 | System and method for point-to-point protocol device redundancey |
PCT/US2004/034941 WO2005043821A1 (en) | 2003-10-24 | 2004-10-22 | System and method for point-to-point protocol device redundancy |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007510332A true JP2007510332A (ja) | 2007-04-19 |
Family
ID=34549920
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006536799A Pending JP2007510332A (ja) | 2003-10-24 | 2004-10-22 | ポイントツーポイント・プロトコル・デバイスの冗長性のためのシステムおよび方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US7082130B2 (ja) |
EP (1) | EP1678876A1 (ja) |
JP (1) | JP2007510332A (ja) |
CN (1) | CN1886936A (ja) |
WO (1) | WO2005043821A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009139306A1 (ja) * | 2008-05-15 | 2009-11-19 | 日本電気株式会社 | 通信システム及び冗長構成管理方法 |
KR101538872B1 (ko) * | 2010-11-22 | 2015-07-22 | 모토로라 모빌리티 엘엘씨 | 주변기기 인증 |
JP2016516368A (ja) * | 2013-03-20 | 2016-06-02 | アルカテル−ルーセント | 不均質仮想シャーシにおけるソフトウェア冗長性 |
Families Citing this family (83)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2003069851A1 (en) * | 2002-02-13 | 2003-08-21 | Nokia Corporation | System and method for a communication network |
US7466680B2 (en) * | 2002-10-11 | 2008-12-16 | Spyder Navigations L.L.C. | Transport efficiency optimization for Mobile IPv6 |
US7079521B2 (en) * | 2002-11-18 | 2006-07-18 | Cisco Technology, Inc. | Method and system for voice calls in a wireless local area network (WLAN) |
US7133386B2 (en) * | 2002-11-18 | 2006-11-07 | Cisco Technology, Inc. | Method and system for service portability across disjoint wireless networks |
US8949380B2 (en) * | 2003-09-29 | 2015-02-03 | Eqapez Foundation, L.L.C. | Method and system for distributing images to client systems |
KR100567319B1 (ko) * | 2003-11-05 | 2006-04-04 | 한국전자통신연구원 | 패킷정합장치간 핸드오프 수행 방법 |
ATE460792T1 (de) | 2004-04-05 | 2010-03-15 | Alcatel Lucent | Verfahren zur verwaltung von kommunikationsgeräten in einem zugangsnetz und eine zugangseinrichtung |
WO2005101760A1 (ja) * | 2004-04-15 | 2005-10-27 | Nec Corporation | クラスタシステム及びクラスタメンバ並びにプログラム |
KR20050101693A (ko) * | 2004-04-19 | 2005-10-25 | 삼성전자주식회사 | 이동 네트워크에서 손상된 라우팅 경로 복구 방법 |
US20060004697A1 (en) * | 2004-06-09 | 2006-01-05 | Lipsky Scott E | Method and system for restricting the display of images |
JP2006019934A (ja) * | 2004-06-30 | 2006-01-19 | Kddi Corp | パケット交換網の呼設定方法 |
DE102004036259B3 (de) * | 2004-07-26 | 2005-12-08 | Siemens Ag | Netzwerkmanagement mit Peer-to-Peer-Protokoll |
KR100785292B1 (ko) * | 2004-08-25 | 2007-12-12 | 삼성전자주식회사 | 이동 통신 시스템 및 그 패킷 처리 방법 |
US8098571B2 (en) * | 2004-10-28 | 2012-01-17 | Alcatel Lucent | Stack manager protocol with automatic set up mechanism |
US20060104214A1 (en) * | 2004-11-18 | 2006-05-18 | Borella Michael S | System and method for automated provisioning of wireless access gateways |
US20060168241A1 (en) * | 2004-11-24 | 2006-07-27 | Puthiyandyil Sanil K | Redundant L2TP end points |
US20060114923A1 (en) * | 2004-11-29 | 2006-06-01 | Overgaard Mark D | Disaggregated star platform management bus architecture system |
DE602004031438D1 (de) * | 2004-12-06 | 2011-03-31 | Alcatel Lucent | Fernverwaltungsverfahren, ein dazugehörender Autokonfigurierungsserver, ein dazugehörender weiterer Autokonfigurierungsserver, ein dazugehörendes Wegeleit-Gateway und eine dazugehörende Vorrichtung |
US20060133333A1 (en) * | 2004-12-21 | 2006-06-22 | Utstarcom, Inc. | Method and apparatus to increase session capacity |
US8006091B2 (en) * | 2005-01-10 | 2011-08-23 | Cisco Technology, Inc. | Method and apparatus to provide failover capability of cached secure sessions |
US20060171299A1 (en) * | 2005-01-28 | 2006-08-03 | Skubisz Michael A | Maintaining life line packet-switched telephony services |
US7688804B2 (en) * | 2005-02-08 | 2010-03-30 | Aspect Software, Inc. | Method of providing fault tolerance in a SIP based contact handling environment |
US7773552B2 (en) * | 2005-03-09 | 2010-08-10 | Yokogawa Electric Corporation | Mobile communication system and mobile communication method |
US7600214B2 (en) * | 2005-04-18 | 2009-10-06 | Broadcom Corporation | Use of metadata for seamless updates |
US7664493B1 (en) | 2005-06-03 | 2010-02-16 | At&T Intellectual Property I, L.P. | Redundancy mechanisms in a push-to-talk realtime cellular network |
JP4592511B2 (ja) * | 2005-06-22 | 2010-12-01 | 沖電気工業株式会社 | Ipネットワークサーバのバックアップシステム |
US7496057B2 (en) * | 2005-08-10 | 2009-02-24 | Cisco Technology, Inc. | Methods and apparatus for optimizations in 3GPP2 networks using mobile IPv6 |
US7558849B2 (en) * | 2005-08-10 | 2009-07-07 | Intel Corporation | Hardware management module |
US20070041327A1 (en) * | 2005-08-16 | 2007-02-22 | Cisco Technology, Inc. | Multicast heartbeat signaling |
US9264455B2 (en) * | 2005-11-15 | 2016-02-16 | Alcatel Lucent | Clustering call servers to provide protection against call server failure |
US8565070B2 (en) * | 2005-11-23 | 2013-10-22 | Cisco Technology, Inc. | System and method for active geographic redundancy |
US8437305B2 (en) * | 2005-11-23 | 2013-05-07 | Cisco Technology, Inc. | Method for providing home agent geographic redundancy |
US8223687B2 (en) | 2005-11-23 | 2012-07-17 | Cisco Technology, Inc. | Method for providing home agent geographic redundancy via a service redundancy protocol |
US7756010B2 (en) * | 2005-12-21 | 2010-07-13 | Cisco Technology, Inc. | Method and system for preventing data packet loss in a redundant PDSN environment |
CN1878404B (zh) * | 2006-03-27 | 2010-05-12 | 华为技术有限公司 | 一种A-Flex架构下负载重新分配处理方法 |
DE102006014594A1 (de) * | 2006-03-29 | 2007-10-04 | Siemens Ag | Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherten Verbindung |
JP5107339B2 (ja) * | 2006-03-31 | 2012-12-26 | シスコ テクノロジー インコーポレーテッド | アクティブ地理的冗長性のためのシステムおよび方法 |
US8213934B2 (en) * | 2006-04-14 | 2012-07-03 | Qualcomm Incorporated | Automatic selection of a home agent |
JP4992308B2 (ja) | 2006-06-14 | 2012-08-08 | 日本電気株式会社 | 通信システム、動作制御方法、位置管理サーバ及びプログラム |
US20080040463A1 (en) * | 2006-08-08 | 2008-02-14 | International Business Machines Corporation | Communication System for Multiple Chassis Computer Systems |
US8315162B2 (en) | 2006-08-24 | 2012-11-20 | Research In Motion Limited | System and method for determining that a maximum number of IP sessions have been established |
US8687586B2 (en) * | 2006-10-13 | 2014-04-01 | Blackberry Limited | System and method for managing IP sessions based on how many IP sessions are supported |
US20080089303A1 (en) * | 2006-10-13 | 2008-04-17 | Jeff Wirtanen | System and method for deactivating IP sessions of lower priority |
EP1912386B1 (en) * | 2006-10-13 | 2013-07-31 | Research In Motion Limited | System and method for managing IP sessions based on how many IP sessions are supported |
WO2008053798A1 (fr) * | 2006-10-30 | 2008-05-08 | Panasonic Corporation | Procédé de mise à jour de liaison, terminal mobile, agent local et système de mise à jour de liaison |
US8023439B2 (en) * | 2006-11-20 | 2011-09-20 | Airvana Network Solutions, Inc. | Multicast flow distribution |
JP5059872B2 (ja) * | 2006-12-28 | 2012-10-31 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | モバイルipプロキシ |
US8611946B2 (en) * | 2007-01-25 | 2013-12-17 | Blackberry Limited | Methods and systems for configuring multi-mode mobile stations |
US8824420B2 (en) * | 2007-03-22 | 2014-09-02 | Mitsubishi Electric Research Laboratories, Inc. | Method and system for generating antenna selection signals in OFDM tranceivers with fewer RF chains than antennas in MIMO wireless networks |
US8266466B2 (en) * | 2007-05-21 | 2012-09-11 | Cisco Technology, Inc. | Globally synchronized timestamp value counter |
US20090106831A1 (en) * | 2007-10-18 | 2009-04-23 | Yingzhe Wu | IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO |
CN101426004A (zh) * | 2007-10-29 | 2009-05-06 | 华为技术有限公司 | 三层会话的接入方法、系统及设备 |
EP2091204A1 (en) | 2008-02-18 | 2009-08-19 | Panasonic Corporation | Home agent discovery upon changing the mobility management scheme |
US8300640B2 (en) * | 2008-04-18 | 2012-10-30 | Arris Group, Inc. | Multi-service PHY box |
US8059557B1 (en) | 2008-07-14 | 2011-11-15 | Sprint Spectrum L.P. | Method and system for access gateway selection |
US8578005B1 (en) | 2008-08-13 | 2013-11-05 | Sprint Spectrum L.P. | Systems and methods for providing update notifications to mobile devices using mobile-IP extensions |
US8018956B1 (en) | 2008-10-15 | 2011-09-13 | Cisco Technology, Inc. | System and method for providing recovery and resynchronization for a tunneling protocol |
US8264956B2 (en) * | 2009-02-27 | 2012-09-11 | Cisco Technology, Inc. | Service redundancy in wireless networks |
US8554178B1 (en) | 2009-07-22 | 2013-10-08 | Sprint Spectrum L.P. | Methods and systems for efficient deployment of communication filters |
JP5573188B2 (ja) * | 2010-01-20 | 2014-08-20 | 富士通株式会社 | 通信システム、及び制御方法 |
US8499336B2 (en) | 2010-11-23 | 2013-07-30 | Cisco Technology, Inc. | Session redundancy among a server cluster |
CN102137487B (zh) * | 2010-12-31 | 2013-11-06 | 华为技术有限公司 | 一种选择服务网关实体的方法及设备 |
JP5759024B2 (ja) * | 2011-03-18 | 2015-08-05 | アルカテル−ルーセント | 地理的冗長ゲートウェイでセッションを復元するシステムおよび方法 |
JP5692362B2 (ja) | 2011-03-31 | 2015-04-01 | 富士通株式会社 | ゲートウェイ装置、及びゲートウェイ選択方法 |
US20130003653A1 (en) * | 2011-06-30 | 2013-01-03 | Alcatel-Lucent Usa Inc. | Method And Apparatus For Facilitating Home Network Access |
US8693314B1 (en) * | 2011-08-25 | 2014-04-08 | Adtran, Inc. | Systems and methods for protecting bonding groups |
CN103001987B (zh) * | 2011-09-16 | 2016-05-25 | 中国移动通信集团公司 | 一种数据处理方法和数据处理节点 |
US20140307762A1 (en) * | 2011-10-27 | 2014-10-16 | Center For Development Of Telematics (C-Dot) | Communication system for managing leased line network and a method thereof |
GB2509465A (en) * | 2011-10-27 | 2014-07-02 | Ct For Dev Of Telematics C Dot | A communication system for managing leased line network with wireless fallback |
KR20130064906A (ko) | 2011-12-09 | 2013-06-19 | 삼성전자주식회사 | 통신 시스템에서의 부하 균등화를 위한 방법 및 장치 |
US9713194B2 (en) * | 2011-12-28 | 2017-07-18 | United States Cellular Corporation | System and method for data network reassignment |
US9363313B2 (en) * | 2012-06-11 | 2016-06-07 | Cisco Technology, Inc. | Reducing virtual IP-address (VIP) failure detection time |
WO2014019185A1 (zh) * | 2012-08-02 | 2014-02-06 | 华为技术有限公司 | 一种控制和转发解耦下协议处理方法及控制面设备、转发面设备 |
ES2444277B1 (es) * | 2012-08-22 | 2015-06-16 | Vodafone España, S.A.U. | Sistema y método de manejo de fallos en una red de acceso radio |
US9426837B2 (en) * | 2012-09-07 | 2016-08-23 | Qualcomm Incorporated | Systems, apparatus and methods for association in multi-hop networks |
US9301276B2 (en) | 2012-09-07 | 2016-03-29 | Qualcomm Incorporated | Systems, apparatus, and methods for association in multi-hop networks |
CN102891766B (zh) * | 2012-09-25 | 2015-04-22 | 汉柏科技有限公司 | 一种ipsec状态恢复方法 |
CN105900483A (zh) | 2014-01-03 | 2016-08-24 | 高通股份有限公司 | 用于避免基于简单ip网络的pdsn间切换之后的数据丢失的装置和方法 |
US10416630B2 (en) * | 2017-03-07 | 2019-09-17 | Uop Llc | System and method for industrial process automation controller farm with flexible redundancy schema and dynamic resource management through machine learning |
KR102499380B1 (ko) * | 2018-01-26 | 2023-02-13 | 삼성전자주식회사 | 무선 통신 시스템에서의 세션 관리 방법, 장치 및 시스템 |
US10739745B1 (en) * | 2019-03-27 | 2020-08-11 | Rockwell Automation Technologies, Inc. | Modular backplane for an industrial controller |
CN112698991B (zh) * | 2021-01-20 | 2022-02-22 | 北京锐马视讯科技有限公司 | 基于1比1心跳的双机热备系统和方法 |
CN114844774B (zh) * | 2022-04-24 | 2023-07-14 | 重庆长安汽车股份有限公司 | 一种车载以太环网的冗余通信系统、方法及存储介质 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6795705B1 (en) * | 2000-10-31 | 2004-09-21 | Utstarcom, Inc. | Hot standby protocol for wireless devices |
US6708031B2 (en) * | 2000-12-05 | 2004-03-16 | Nokia Corporation | Session or handoff methods in wireless networks |
US8160020B2 (en) * | 2001-06-25 | 2012-04-17 | Airvana Network Solutions, Inc. | Radio network control |
US6985464B2 (en) * | 2001-07-30 | 2006-01-10 | Starent Networks Corporation | Managing packet data interconnections in mobile communications |
US6987764B2 (en) * | 2001-11-05 | 2006-01-17 | Qualcomm, Incorporated | Method and apparatus for selecting a packet data serving node for multi-cast/broadcast services |
US6822952B2 (en) * | 2001-11-26 | 2004-11-23 | Qualcomm Incorporated | Maintaining packet data connectivity in a wireless communications network |
AU2003247428A1 (en) * | 2002-05-28 | 2003-12-12 | Zte San Diego, Inc. | Interworking mechanism between cdma2000 and wlan |
US7295511B2 (en) * | 2002-06-13 | 2007-11-13 | Utstarcom, Inc. | System and method for packet data serving node load balancing and fault tolerance |
-
2003
- 2003-10-24 US US10/693,294 patent/US7082130B2/en not_active Expired - Fee Related
-
2004
- 2004-10-22 WO PCT/US2004/034941 patent/WO2005043821A1/en active Application Filing
- 2004-10-22 EP EP04796008A patent/EP1678876A1/en not_active Withdrawn
- 2004-10-22 CN CNA2004800353987A patent/CN1886936A/zh active Pending
- 2004-10-22 JP JP2006536799A patent/JP2007510332A/ja active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009139306A1 (ja) * | 2008-05-15 | 2009-11-19 | 日本電気株式会社 | 通信システム及び冗長構成管理方法 |
JP2009278436A (ja) * | 2008-05-15 | 2009-11-26 | Nec Corp | 通信システム及び冗長構成管理方法 |
KR101538872B1 (ko) * | 2010-11-22 | 2015-07-22 | 모토로라 모빌리티 엘엘씨 | 주변기기 인증 |
JP2016516368A (ja) * | 2013-03-20 | 2016-06-02 | アルカテル−ルーセント | 不均質仮想シャーシにおけるソフトウェア冗長性 |
Also Published As
Publication number | Publication date |
---|---|
WO2005043821A1 (en) | 2005-05-12 |
US20040095881A1 (en) | 2004-05-20 |
CN1886936A (zh) | 2006-12-27 |
EP1678876A1 (en) | 2006-07-12 |
US7082130B2 (en) | 2006-07-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7082130B2 (en) | System and method for point-to-point protocol device redundancey | |
JP3987530B2 (ja) | パケットデータ提供ノードの負荷平衡および耐障害性のためのシステムおよび方法 | |
JP3754398B2 (ja) | モバイルインターネットプロトコルネットワークにおける外部エージェント選択を管理するためのシステムおよび方法 | |
US6956846B2 (en) | System and method for foreign agent control node redundancy in a mobile internet protocol network | |
US7212537B2 (en) | Apparatus and method for recovering communication sessions in a wireless network gateway | |
US8195187B2 (en) | Radio network control | |
US7346684B2 (en) | System and method for control of packet data serving node selection in a mobile internet protocol network | |
US7426213B2 (en) | Mobile internet protocol (IP) networking with home agent and/or foreign agent functions distributed among multiple devices | |
US9019935B2 (en) | Radio network control | |
US6061728A (en) | Arrangement for controlling network proxy device traffic on a transparently-bridged local area network using a master proxy device | |
US20040214576A1 (en) | Wireless network communication system and method | |
WO2004017172A2 (en) | System and method for home agent load balancing | |
JP2009532948A (ja) | アクティブ地理的冗長性のためのシステムおよび方法 | |
WO2006091411A2 (en) | Method and system for load balancing in network platform | |
WO2007112683A1 (en) | Method,apparatus and system for call recovery | |
US20060104214A1 (en) | System and method for automated provisioning of wireless access gateways | |
JP4495049B2 (ja) | パケット通信サービスシステム、パケット通信サービス方法、エッジ側ゲートウェイ装置、およびセンタ側ゲートウェイ装置 |