JP2002505044A

JP2002505044A - Ｓｃｐデータベースの移動

Info

Publication number: JP2002505044A
Application number: JP54834098A
Authority: JP
Inventors: レキータ，トーマス・ダブリユ; チエン，チユアン−メーイ; ワン，ケテイ・イー; トウン，ビーデイン; マオ，テイン−チユアン
Original assignee: アルカテル・ユー・エス・エイ・ソーシング、エル・ピー
Priority date: 1997-05-09
Filing date: 1998-05-04
Publication date: 2002-02-12
Also published as: WO1998051095A3; CN1260100A; BR9809276A; WO1998051095A2; US6098076A; CN1141846C

Abstract

(57)【要約】ＡＩＮサービスが、増加する需要を満足するように拡張可能な複数のＳＣＰ対を含む。この拡張は、この対の間での冗長性を維持しながらも、ＳＣＰ対間でレコードを移動することによってサービスを中断することなく発生させることが可能である。集中型ＧＴＴがＡＩＮシステム中の複数のサブシステム間に分散しているＧＴＴを維持する。加入者データベースが複数のファイルに分割されているので、対を成すメイトＳＣＰ間の同期は高速で行われ、各ファイルが独立した同期プロセスを有している。

Description

【発明の詳細な説明】ＳＣＰデータベースの移動背景技術１．技術分野本発明は一般的には電気通信に関し、より特定的には、拡張可能な冗長データベースを提供する方法と装置に関する。２．関連技術の記載無線通信は過去数年の間に急速に成長した。最も人気のある形態の無線遠隔通信の１つがセルラー電話であるが、日本で人気があるＰＨＳ（パーソナルハンディフォンシステム）などの他の技術も将来の世界に大きな影響を与えると期待されている。ＰＨＳは、電話とモデムなどのモバイルデバイスが、セルラー用セルの場合の約１５００〜５０００メートルというセル範囲に対して約１００〜５００メートルというセル範囲を現在のところ有する「基地局」を介して通信するという点でセルラー技術と異なっている。したがって、基地局の分布密度はセルラーセルより高い。しかしながら、ＰＨＳハンドセットの出力はセルラー式の場合よりかなり低く、ＰＨＳハンドセットの出力は約１０ミリワットであり、一方、セルラー電話は一般的には０．６〜１．０ワットの出力を持つ。ＰＨＳは近い将来において、より安い値段で卓越した性能を提供するものと期待されている。ＰＨＳシステム及び他の無線遠隔通信システムにおいては、１つ以上の加入者データベースが、サービスオプション（例えば音声メール）、制限事項（例えばコールブロッキング、長距離制限）、請求書の情報と状況及び現在位置（すなわち、加入者の電話と現時点でどの基地局が連絡しているか）などの各加入者のアカウントに関する情報を記憶する。このデータベース中の情報は、あらゆる電話の処理にとって必要であり、したがって、１つのコンピュータが故障してもデータへのアクセスを妨げないように、該データベースは、完全な冗長コンピュータ中に一般的には置かれている。洪水や地震又は他の自然災害などによって引き起こされる故障などの破局的な故障に対して備えるために、冗長コンピュータはしばしば数１００マイルも物理的に離される。加入者の数が増すに連れて、データサイズも増す。結局、データベースは１つのコンピュータで効率的に維持するには大きくなりすぎる。したがって、拡張可能な加入者データベースを提供する方法と装置に対する必要が発生している。発明の簡単な開示本発明による通信システムは、交換ネットワークとサービスネットワークに結合されている複数の電話デバイスを備え、これによって、前記の交換ネットワークからの加入者情報に対する要求に応答する情報を提供する。サービスネットワークは、加入者情報のデータベースを維持するデータベース機構を備え、該データベース機構は、各々がデータベースの１部分を維持する責任を負う複数のサービス制御ポイントを備えている。データは、前記交換ネットワークからの前記要求に対する応答を提供し続けながら、第１のサービス制御ポイントから第２のサービス制御ポイントに転送するようにしてもよい。本発明は先行技術にない重要な利点を提供する。サービス制御ポイントの数は、加入者データベースのサイズが増加するにつれて増加し、これによってサービスを迅速化できる。サービス制御ポイントは、この遷移期間中にサービスを停止させることなく追加できる。図面の簡単な説明本発明およびその利点をより完全に理解するため、添付の図面に関連して行われる下記の記述を参照する。第１ａ図は、容量を増加するために動的に追加される可能性があるＳＣＰ（サービス制御ポイント）のＡＩＮサービスを有する電話システムのブロック図を示している。第１ｂ図は、サービスマネージメントシステム（ＳＭＳ）と、サービス制御ポイント（ＳＣＰ）と、そのメイト（対の他方）ＳＣＰと、加入者の電話装置を含む無線通信における基地局(ＢＳ)との間の関係を示している簡易ブロック図である。第１ｃ図は、複数のＳＣｐ対に結合される様々な装置の簡易ブロック図である。第２図は、本発明によって構成されるサービス制御ポイント（ＳＣＰ）のブロック図である。第３図は、本発明によって構成されるＳＣＰのより詳細なブロック図である。第３Ａ図は、本発明によるＩＰＵ故障によるファイル分散および再分散のより詳細なブロック図である。第４図は、プラットフォームマネージャ（ＰＭ）データベースマネージャのオブジェクト図である。第５図は、アプリケーションプロセッサグループ（ＡＰＧ）データベースマネージャのオブジェクト図である。第６図は、インテリジェントプロセッサユニット（ＩＰＵ）データベースマネージャのオブジェクト図である。第７図は、ＡＰＧデータベースマネージャの初期設定プロセスの例示的なフローチャートである。第８図は、ＩＰＵデータベースマネージャの初期設定プロセスの例示的なフローチャートである。第９図は、ＰＭが、スタンバイからアクティブオペレーティングステータスに遷移するプロセスの例示的なフローチャートである。第１０図は、ＩＰＵ故障を処理するプロセスの例示的なフローチャートである。第１１図は、ファイルシステムをＩＰＵに追加するプロセスの例示的なフローチャートである。第１２図は。ファイルシステムをＩＰＵから除去するプロセスの例示的なフローチャートである。第１３図は、ロードバランス要求プロセスの例示的なフローチャートである。第１４図は、ロードバランシングプロセスの例示的なフローチャートである。第１５図は、データベース再構成プロセスの例示的なフローチャートである。第１６図は、共用メモリおよびディスク同期プロセスの例示的なフローチャートである。第１７図は、ＳＣＰ対内の対応するＳＣＰのデータベースを同期させるプロセスを示している例示的な工程系統図である。第１８図は、対応するＳＣＰデータベースの同期に使用されるＩＰＵ同期プロセスの例示的なフローチャートである。第１９図は、対応するＳＣＰデータベースの同期に使用されるＩＰＵアップデートプロセスの例示的なフローチャートである。第２０図は、集中型グローバルタイトル変換（ＣＧＴＴ）テーブルのフォーマットを示している。第２１図および第２２図は、ＣＧＴＴからグローバルタイトル変換テーブルを修正するフローチャートを示している。第２３ａ図乃至第２３ｅ図は、ＳＣＰ間の情報を移動するプロセスを示している。発明の詳細な説明本発明は、図面の第１図乃至第２３図を参照するとより理解され、同一数字が、様々な図面の同一要素に使用されている。第１ａ図は、ＰＨＳの性能を有する電話システム１０のブロック図を示している。ＰＳＴＮ（公衆交換電話回線網）１２は、電話やＰＢＸ（構内交換設備）、モデム、デジタルデバイスなどの複数のデバイス１４に結合される。そのうえ、複数のＰＨＳ基地局１６が、ＰＳＴＮ１２に接続される。ＰＨＳハンドセット（または、デジタルモデムなどのその他のデバイス）１８は、無線通信を使用する基地局１６を介して、ＰＳＴＮ１２に結合されるその他のデバイスと通信する。ＡＩＮ（高度インテリジェントネットワーク）システム２２は、ＰＳＴＮ１２に結合される１つ以上のＳＴＰ（信号転送ポイント）２４を含む。ＳＴＰ２４は、互いに結合され、かつ複数のＳＣＰ（サービス制御ポイント）対２６に結合される。それぞれのＳＣＰ対２６は、以下に詳細に記述される、２つの十分に冗長なＳＣＰ２６ａおよび２６ｂを含む。ＳＴＰ２４は、さらに、ＮＣＣ（ネットワーク制御センター）２８やＳＭＳ（サービス管理システム）３０、ＶＭＳ（音声メールシステム）３２に接続される。ＮＣＣ２８、ＳＭＳ３０およびＶＭＳ３２は、ＳＣＰ対２６に結合される。ＮＣＣ２８は、ＣＧＴＴ（集中型グローバルタイトルテーブル）３４を含む。オペレーションにおいて、ＰＨＳデバイス１８から開始される呼、またはＰＨＳデバイス１８に終結する呼は、情報のためにＡＩＮ機構構成２２を使用する。その他の情報について、ＳＣＰ２６は、それぞれの移動デバイス１８に関連付けられた現基地局に関する一時データを含む情報、音声メールオプション、コールブロッキングなどのその他のオプションに加入しているそれぞれの移動デバイス１８のための音声メール情報および請求書情報のデータベースを供給する。移動デバイス１８へ、または移動デバイス１８から発呼される場合、関連情報を決定するためにＳＣＰに対して照会が行われる。例えば、呼が、０５０−８８８−７７７７の割り当てＰＳＮ（電話システム番号）を有する第１移動デバイス１８から、０５０−８８８−６６６６の割り当てＰＳＮを有する第２移動デバイスに行われる場合、下記のトランザクションが生じる。第１に、デバイスが、それぞれのＰＳＮの特定デジットによって移動（この場合ＰＨＳ）デバイスであると識別される。この例において、「０５０」は、ＰＨＳデバイスであると識別し、「８８８」は、ＰＨＳプロバイダ（数字の組み合わせを使用することは可能であるが）であると識別する。したがって、呼を完結させるために、どの基地局１６が現在受信デバイスと関連付けられているのかを、ＰＳＴＮが決定する。第２に、発信デバイスまたは受信デバイスのいずれかに関連付けられている音声メールがある場合、この情報は、デバイス（例えば、電話機のライトが、ユーザにメールが使用可能であることを通知することを可能とするデバイス）に送信される。第３に、発信デバイスまたは受信デバイス１８が、特定の呼が発信されたり、受信されたりすることを防止する１つ以上の制限オプションに加入することが可能である。このように、発信デバイス１８が、長距離電話をかけることを制限されている場合、呼は、受信デバイスが長距離電話を要求する基地局と関連付けられていれば、完結しない（そして、発信者に通知される）。あるいは、受信デバイスが、呼を受信したくないデバイスとして発信デバイスのＰＳＮをリストすることもできる。このような場合、呼は、ブロックされる（そして、発信者に通知される）。第４に、デバイス１８の１つが、料金を滞納するか、または、サービスをす場合があり、この場合、呼は、完結されない。上述のトランザクションが、第１のＰＨＳデバイス１８から第２のＰＨＳデバイス１８への呼に関連して記述されているが、少なくとも１つのＳＣＰへの照会は、一方のパーティがＰＨＳデバイスでないとしても、呼が発信パーティかまたは受信パーティかのいずれかとして、ＰＨＳデバイスを含む所であればどこでも行われる。ＳＣＰ２６が、ＰＨＳデバイス１８に係わる呼に必要とされるので、これらのデータベースは、急速に増加する。さらに、データベースが増加するにつれて、ＳＣＰサービスが行われる速度が著しく減速されてはならない。さらに、ＳＣＰ２６のデータは、１つのＳＣＰの故障による損失から守る必要がある。第１ａ図に示される実施の形態において、ＳＣＰ２６の対は十分に冗長であり、すなわち対のそれぞれのＳＣＰ２６ａおよび２６ｂは、同一データベースを有する（下記に記述される同期手順によって解決される短期変化は受けるものとして）。それぞれのＳＣｐ対２６は、サブセットのデバイスに割り当てられる。ここに記述される好ましい実施の形態において、それぞれのＳＣＰ対２６は、ＰＨＳシステムに関連付けられたＰＳＮ内の１つ以上の範囲に割り当てられる。例えば、第１のＳＣＰ対２６は、８８８−００００から８８８−３３３３の範囲にわたるＰＳＮに割り当てられることが可能であり、また第２の対は、８８８−３３３４から８８８−７７７７の範囲にわたるＰＳＮに関連付けられることが可能である（現実の実施の形態において、それぞれのＳＣＰ対に関連付けられるＰＳＮの数は、ずっと大きい）。ＣＧＴＴ３４は、それぞれのＳＣＰ対の範囲を定義するデータベースを維持している。この情報は、必要な時にＡＩＮシステムのその他のデバイスに分散される。ＳＣＰ対２６に関連付けられたＰＳＮの範囲内に、対２６のそれぞれのＳＣＰは、冗長なデータベースを有する。しかし、効率をあげるために、それぞれのＳＣＰ２６ａおよび２６ｂは、照会のロードの半分に応答するように割り当てられる。１つの２６ａまたは２６ｂが実施不可能になる場合、他方のＳＣＰ（メイトＳＣＰ）が、故障しているＳＣＰがサービスのために回復するときまで、全ロードに応答可能である。このように、それぞれのＰＳＮについて、「プライマリ」ＳＣＰが、両ＳＣＰが実行している間、そのＰＳＮに対する照会に応答するＳＣＰとして定義される。オペレーション中、ＳＣＰ２６ａおよび２６ｂ間のデータは、同期を損失する可能性がある。例えば、デバイスが基地局の間で変化するとき、この情報（以下「一時」情報と呼ぶ）は、その対のプライマリＳＣＰに割り当てられたＳＣＰにレポートされる。同様に、ＶＭＳ３２からの音声メール情報は、所属するデバイスのために、その対のプライマリＳＣＰにレポートされる。ＳＣＰは、データベースの冗長性を維持するために、第１７図乃至第１９図に関連して記述されるように、一時情報および音声情報を交換する。第１ａ図のＡＩＮシステム２２は、複数のＳＣＰ対２６を使用する。それぞれのＳＣＰ対２６は、加入者データベースの一部分のサービスを供給する責任を負う。ＣＧＴＴは、１つ以上の範囲の電話番号に、各ＳＣＰ対を関連付けることによって、どのＳＣＰ対２６が、どの加入者のために責任を負うかを定義する。全加入者データベースよりむしろ加入者データベースの一部分をそれぞれのＳＣＰ対２６に関連付けることによって、ＳＣＰの応答時間を大幅に改善する。そのうえ、以下により完全に記述されるように、ＳＣＰ対２６は、必要な時にＡＩＮシステムに追加されることが可能である。このように、加入者データベースが増加するにつれて、ＡＩＮサービスが、第２３ａ図乃至第２３ｅ図に関連して記述されるように、ＳＣＰ対を追加し、加入者レコードを新しいＳＣＰ対に移動させることによって、迅速な応答を続けることが可能である。サービスを中止することなく、かつデータを損失することなく、新しいＳＣＰ対を追加することが成し遂げられる。ＳＣＰ２６は、専用のポイントツーポイントＸ．２５リンクを介して、ＳＭＳ３０に結合される。一対のＳＣＰ２６ａおよび２６ｂは、異なる市に、一般に、物理的に配置され、かつポイントツーポイント広域ネットワーク（ＷＡＮ）リンクまたはメディアアクセスコントロール（ＭＡＣ）ブリッジなどのいくつかの通信回線を介して互いに結合される。ＳＭＳ３０と、ＳＣＰ２６と、基地局１６との間に伝送されるいくつかの例示的なメッセージが、第１ｂ図に示されている。ポータブルハンドセット１８を使用する新しい加入者が、通信ネットワーク１０に追加されるとき、ＳＭＳ３０が、ＩＮＳＥＲＴコマンドを発行し、新しい独自の個人加入者番号または電話番号を、ＣＧＴＴ３４によって定義される適当な対のＳＣＰ２６ａおよび２６ｂの双方に追加する。無線サービスを望まない加入者は、ＳＣＰ２６ａおよび２６ｂの双方へのＤＥＬＥＴＥメッセージで、同様な方法で削除されることが可能である。ＳＭＳ３０は、さらにＵＰＤＡＴＥメッセージを発行して、新サービスを追加するなどの情報をＳＣＰ２６ａおよび２６ｂに供給する。これらのメッセージは、静的データの更新の例示である。ポータブルハンドセットが移動するとき、その位置は、１つの基地局のカバーエリアから別の基地局のカバーエリアへと変わる。基地局の番号の更新は、現在ポータブルハンドセットをカバーする基地局によってプライマリＳＣＰ１６に供給され、ポータブルハンドセットへの着信呼は、その基地局へルーティングされ得る。さらに、別のポータブルハンドセットへの発信呼は、相手先のポータブルハンドセットの位置情報についてのプライマリＳＣＰ１６への照会から始まる。データベース同期プロセスは、ＳＣＰ２６ａおよび２６ｂ間で定期的に及び／又は要求があり次第、実行され、この一時データでＳＣＰのそれぞれのコピーを更新する。第１ｃ図は、個々にＳＣＰ１、ＳＣＰ２およびＳＣＰｎとして参照されている複数のＳＣＰ対２６に結合される様々なデバイスのブロック図を示している。それぞれの対は、ＳＭＳ３０と、ＶＭＳ３２と、ＢＳ１６とに（ＳＴＰ２４を介して）結合される。ＳＭＳ３０やＶＭＳ３２、ＳＴＰ２４などのデバイスのそれぞれは、ＮＣＣ２８から更新されるグローバルタイトルテーブル（ＧＴＴ）を含む。ＧＴＴは、関連デバイスを、所定の番号によって、適当なＳＣＰ対２６に向ける。このように、例えば、ＶＭＳ３２が、番号０５０−８８８ −７７７７に関連付けられた音声メールデータを有する場合、内部ＧＴＴを参照として、ＳＣＰ対２６のどれが０５０−８８８−７７７７のデータベースを維持するかを決定する。ＶＭＳ３２は、通信セッションを、ＧＴＴの情報に基づく適当なＳＣＰ対26と開始する。以下により詳細に記述されるように、複数のＳＣＰ対の間にＳＣＰデータベースを分散する能力により、電話システムの柔軟なサイズを供給する。例えば、各々のＳＣＰ対が５百万のユーザを処理する容量を有する場合、電話システム１０の容量が５百万の顧客に近づくとき、追加のＳＣＰ対２６が下記に記述されるように追加されることが可能である。追加のＳＣＰ対は、必要とされるときに追加される。第２図は、本発明により構成されるメイトＳＣＰ２６ａに結合されるＳＣＰ２６ｂのより詳細なブロック図を供給している。それぞれのＳＣＰは、バスやローカルエリアネットワーク（ＬＡＮ）、ローカルエリアネットワークハブ５０などによって、アプリケーションプロセッサグループ（ＡＰＧ₁−ＡＰＧ_m）３８−４２の予め決められた番号に結合されるアクティブ・プラットフォームマネージャ（ＰＭ）３４と、スタンバイ・プラットフォームマネージャ３６とを含む。より大きなネットワークの安全性と故障への耐久性を供給するために、デュアルＬＡＮまたはハブが、ＰＭをＡＰＧに接続するために使用され、冗長性を供給する。それぞれのＡＰＧ３８−４２は、複数のインテリジェントプロセッサユニット（ＩＰＵ₁−ＩＰＵ_n）４４−４８を含む。１つ以上のＩＰＵは、別のＩＰＵが故障すると、オンライン状態にされるスペアまたはスタンバイＩＰＵとして構成される。ホスト５１は、ＳＴＰ２４とＳＣＰのＩＰＵとの間のインターフェースの役割をする。以下に記述されるルートテーブルは、照会を正確なＩＰＵに向ける。ルートテーブルは、ＰＭによって管理され、ホスト５１とＩＰＵとに分散される。ルートテーブルをホスト５１とＩＰＵとに分散されることによって、ＳＴＰからの照会が、迅速に、正確なＩＰＵにルーティングされることが可能となる。第３図を参照すると、プラットフォームマネージャ３４および３６の各々は、ＰＭデータベースマネージャプロセス５２と、各ＡＰＧのためのＡＰＧデータベースマネージャプロセス５４とを含むことが分かる。ＩＰＵ_1-n６０−６４の各々は、さらに、ＩＰＵデータベースマネージャプロセス６６−７０と、そこに属する共用メモリ７２−７６とを有する。共用メモリ７２−７６は、ランダムアクセスメモリ（ＲＡＭ）デバイスを含む高速メモリデバイスによって提供され、かつＩＰＵに属するすべてのプロセスにアクセスしやすい。一対のミラーリングしているメモリ記憶デバイス８０および８２は、ＩＰＵ６０−６４の各々に結合され、ＩＰＵ６０−６４が、同時にメモリ記憶デバイス８０−８２にアクセスすることができる。メモリ記憶デバイス８０および８２にマルチポートメディアを実装することによって、またはメモリデバイス８０および８２の各々にマルチイニシエータモードでＩＰＵ６０−６４を実行することによって、同時ファイルアクセスが達成される。メモリ記憶デバイス８０および８２には、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｉｓｋ）、またはその他適当な記憶メディアが提供されてもよい。マルチイニシエータモードにおいて、メモリ記憶デバイス８０および８２は、独立したバス、または小型コンピュータシステムインターフェース（ＳＣＳＩ）によって、ＩＰＵ６０−６４にそれぞれ結合される。このように構築されかつ構成されたＩＰＵ６０−６４のいずれか１つは、メモリ記憶デバイス８０−８２の双方にアクセスできる。メモリ記憶デバイス８０および８２は、予め定められたパーティションまたはファイルシステムに区分され、ここでそれらのＸは、加入者ファイルを格納するために使用される。ポータブルハンドセットの加入者データベースは、ＳＣＰ３０のＡＰＧ３８−４２のミラーリング・ディスクに格納される固定数のファイルからなり、１つのＡＰＧにつき一対のミラーリング・ディスクがある。全加入者データベースの加入者レコードのサブセットは、それぞれの加入者ファイルに割り当てられる。それぞれの加入者ファイルが、ＳＣＰの特定の対のミラーリング・ディスク内の特定ファイルシステムに格納されるように、割り当てられ、それぞれのＡＰＧは、加入者データベースの排他的なサブセットを提供する。第３図に示されるように、一対のディスクに格納されるファイルの数は、Ｙである。一対のディスクはミラーリングされており、両方が操作可能である場合、ディスクの内容はいつも同一である。所定の対のディスクの特別のファイルにアクセスするために、そのファイルを含むファイルシステムは、ＡＰＧ内のＩＰＵのディレクトリにマウントされる必要があり、そこでファイルシステムは、同時に１つのＩＰＵだけにマウントされることが可能である。ファイルシステムが、ＩＰＵにマウントされるとき、そのファイルは、ＩＰＵの共用メモリにマッピングされる。一般のオペレーション中、それぞれのファイルシステムは、特別のＩＰＵに割り当てられ、かつＩＰＵの共用メモリにマウント及びマッピングされ、そこに含まれるデータは、ＩＰＵで操作するすべてのプロセスに簡単にアクセスされる。加入者位置情報などを含む一時データの更新は、ＩＰＵの共用メモリにだけに行われるが、加入者の追加や削除、サービス修正などの静的データの更新は、ディスクに即座に書き改められるとともに、共用メモリに更新される。進行するに従って、一時データを含む、ＩＰＵの共用メモリにマッピングされた構成可能なサイズの部分は、ミラーリング・ディスクに同時に書き改められ、そこに含まれるコピーを更新する。この進行中の書き込みオペレーションの結果が、構成可能なインターバルで、マッピングされた共用メモリファイルを介して、連続的に循環することになり、余分なの入力／出力、またはＣＰＵピークを必要とすることなく、ディスクコピーを更新する。このように、考えられる断続的なサービスの遅れが、ディスクへのファイルの小部分の連続的な書き込みによって回避される。第３Ａ図を参照すると、ＡＰＧのＩＰＵへのファイル分散および再分散の例示的ブロック図が示されている。ディスク８０および８２のそれぞれが、６つのパーティション、またはファイルシステムＦＳ１−ＦＳ６を有し、例えば、それぞれのファイルシステムは、Ｆ１−Ｆ１４のファイルの２つかまたは３つのファイルセットを有する。ファイルの初期分散において、ＩＰＵ₁６０は、ＦＳ１をマウントし、共用メモリにファイルＦ１−Ｆ３をマッピングする；ＩＰＵ₂６２は、ＦＳ２をマウントし、共用メモリにファイルＦ４−Ｆ６をマッピングする；ＩＰＵ₃６３は、ＦＳ３およびＦＳ４をマウントし、共用メモリにファイルＦ７− Ｆ１０をマッピングする；ＩＰＵ₄６４は、ＦＳ５およびＦＳ６をマウントし、共用メモリにＦ１１−Ｆ１４をマッピングする。それぞれのＩＰＵは、マウントしたファイルシステムのファイルの加入者レコードのみにアクセス可能である。ＡＰＧは、全体として、それに割り当てられるすべてのファイル内のすべての加入者にサービス提供する。その後、ＩＰＵ₃６３がダウンすると、ファイルシステムＦＳ３およびＦＳ４のファイルＦ７−Ｆ１０は、残りのＩＰＵの１つ以上に再分散される。第３Ａ図に示される例において、ＦＳ３およびＦＳ４のファイルは、ＩＰＵ₁６０およびＩＰＵ₂６２に再分散され、ファイルＦ７−Ｆ１０に格納された情報を有するこれらの加入者へのサービスが、中断することなく継続する。したがって、ＩＰＵが、サービスが始まるか、またはサービスが終了するとき、ファイル分散が再構成される。さらなる例示として、２つのＡＰＧの構成、それぞれのＡＰＧのディスク毎に使用される６つのファイルシステムおよび３２の加入者ファイルが、下記に示される例示的なファイル割り当てを有する：３２の加入者情報ファイルは、それぞれのＡＰＧのミラーリング・ディスクに存在するロードの半分、すなわち１６のファイルを有するＡＰＧに均等に分散されることがわかる。それぞれのＡＰＧが３つのアクティブＩＰＵを有する場合、それぞれのＩＰＵに、共用メモリにマウントされマッピングされる２つのファイルシステムが割り当てられる。それぞれのＡＰＧが４つのＩＰＵを有する場合、２つのＩＰＵに、２つのファイルシステムが割り当てられ、残りの２つのＩＰＵに、１つのファイルシステムがそれぞれ割り当てられる。１つ以上のスペア１ＰＵは、さらに、ＩＰＵが故障するまでスタンバイモードの状態であるそれぞれのＡＰＧに含まれる。個人加入者番号（ＰＳＮ）または呼番号が使用され、そのアカウントに関する情報を格納するファイルのファイルインデックスを決定する。例えば、データベースが、３２ファイルに区分される上記のような場合、モジュロまたはＭＯＤ３２オペレーションが、個人加入者番号の選択された桁において実行され、加入者ファイルインデックスを生成する。大部分のアプリケーションに関して、個人加入者番号の最後の４または５桁が、ＭＯＤオペレーションに使用され、ファイルインデックスを生成する。３−４百万の加入者をサポートするために、加入者情報データベースは、１２８のファイルに区分される。５つのＡＰＧがシステムをサボートするために使用される場合、例示的なファイル割り当てが、下記に示されている。データベースが１２８のファイルに区分されている上記の例において、個人加入者番号の最後の４または５桁においてモジュロ１２８オペレーションが実行され、この呼番号の加入者情報が配置されるファイルのファイルインデックスを生成する。したがって、特定の加入者についての情報は、データベースに迅速に配置されることが可能である。デフォルトまたは初期ファイル割り当てが、ロードおよびトラフィック状態により修正されることを示していることは重要なことである。それぞれのＩＰＵは、受信する照会の数の統計を維持し、統計をレポートする。ファイル割り当てが、再分散され、ＩＰＵがオーバーワークされることがない。さらに一様に分散するためのロードバランシングの詳細は、下記に記述される。結果的に、ＰＭデータベースマネージャ５２が、主として、ＳＣＰ３０のＩＰＵのデータベースロードバランシングに対して責任を負い、ＡＰＧデータベースマネージャ５４が、主として、それぞれのＡＰＵのＩＰＵのデータベースロードの管理について責任を負う。ＩＰＵは、少なくとも３つのサービス状態：ＩＮ＿ＳＥＲＶＩＣＥ、ＯＳ＿ＭＩＮおよびＯＵＴ＿ＯＦ＿ＳＥＲＶＩＣＥを有する。ＰＭデータベースマネージャ５２、ＡＰＧデータベースマネージャ５４およびデータベースマネージャ６６−７０は、互いに整合して、ＯＳ＿ＭＩＮおよびＯＵＴ＿ＯＦ＿ＳＥＲＶＩＣＥＩＰＵからファイルシステムをアンマウントし、残りの１Ｎ＿ＳＥＲＶＩＣＥにファイルシステムを再分散する。ファイルは、また、ファイルシステム間を移動されて、それぞれのＩＰＵおよびＡＰＧによって運ばれるロードを均等に分散する。プロセスのオペレーティング状態の詳細は、この明細書に参照として記載されているＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＭｕｌｔｉ−ＳｉｔｅＤｉｓｔｒｉｂｕｔｅｄＯｂｊｅｃｔｍａｎａｇｅｍｅｎｔＥｎｖｉｒｏｎｍｅｎｔの表題を付けられた同時係属の米国特許出願第０８／５２６，９５３号に論じられている。第４図を参照すると、ＰＭデータベースマネージャ５２は、データベース構成を処理するデータベース構成テーブル９０とＩＰＵテーブル９２を含む。データベース構成テーブル９０が、全データベースのそれぞれのファイルシステムの情報を基本的には維持し：１．ファイルシステム名２．デフォルトＩＰＵ名３．現行ＩＰＵ名４．ＡＰＧＩＤ５．ファイルシステムのファイルの数６．ファイルシステムのファイルのマップを含む。デフォルトＩＰＵは、ファイルシステムが初めに割り当てられるＩＰＵであり、現行ＩＰＵは、データベース再構成および／またはロードバランシングによって影響されるファイルシステムを現在マウントしているＩＰＵである。ＩＰＵテーブル９２は、システムのそれぞれのＩＰＵの情報を維持し：１．ＩＰＵ名２．ＡＰＧＩＤ３．現在のＩＰＵのファイル数４．現在のＩＰＵのファイルシステム数を含む。第３のテーブルのルートテーブル９４もまた、ＰＭデータベースマネージャプロセス５２によって維持される。ルートテーブル９４は、データベースのそれぞれのファイルの情報を含む。それは、ＰＭに結合されるメッセージトランスポートネットワーク（ＭＴＮ）などのホスト（第２図を参照）にルーティング情報を供給するために使用され、ホストは、それぞれのＩＰＵのデータベースロードにより、照会を適当なＩＰＵに指示する。ルートテーブルは、：１．加入者ファイルインデックス２．ファイルが、現在、存在しているＩＰＵ名３．ＩＰＵＩＤを含む。３つのテーブルすべては、永続性であり、かつ技術上周知であるように複写される。これらのテーブルのすべての更新および複写は、ここでは詳細に記述されない別のサブシステムによって処理される。ＰＭデータベースマネージャプロセス５２は、データベースを管理するタスクを実行するいくつかのオブジェクトを含む。簡単な記述が次に続くが、これらのオブジェクトの機能のより詳細な論議は、第７図乃至第１６図を参照として下記に述べられる。第４図に示されるように、ＰＭデータベースハンドラ９６は、ＩＰＵ間の、およびルーティング情報のホストからの送信請求要求を処理するために、ロードバランシングを行う。ルートテーブルアクセス１００およびデータベース構成テーブルアクセス１０２は、ルートテーブル９４およびデータベース構成テーブル９０へのそれぞれのアクセスをコントロールするＰＭデータベースマネージャ５２に存在するオブジェクトである。ロードバランスハンドラ１０４は、ロードバランシングファイルおよびファイルシステムの処理方法を含むオブジェクトである。共用メモリアレイ１０６は、ＰＭデータベースマネージャ５２とＡＰＧデータベースマネージャ５４との間のロードバランシングと再構成とを同期させるために使用される共用メモリ７２−７６（第３図）のブール値のアレイである。第５図は、ＡＰＧデータベースマネージャ５４にＩＰＵデータベースマネージャ６６−７０およびその他のプロセスへのインターフェースを供給するＡＰＧデータベースハンドラ１１０を含み、さらに、ＩＰＵの除去および回復の際に呼び出される方法を供給するＡＰＧデータベースマネージャ５４の典型的な組成を示している。データベースルートコントロール１１２は、ＩＰＵの回復や除去、監査などの異なる状況を処理するためにファイルシステムを再割り当てする様々な処理方法を含む。データベースルートコントロール１１２は、また、ＡＰＧ自体についての情報も含む。ＩＰＵ情報テーブル１１４は、現行ＩＰＵサービス状態を含むＡＰＧ内のＩＰＵに特有の情報を維持するテーブルである。ＰＭデータベースマネージャ５２と同じく、ＡＰＧデータベースマネージャ５４は、さらに、データベース構成テーブル９０、データベース構成テーブルアクセス１１６、ルートテーブルアクセス１１６、ルートテーブル９４および共用メモリアレイ１２０を含み、それぞれのテーブルのデータへのアクセスをコントロールする。第６図を参照すると、ＩＰＵデータベースマネージャ６６は、ＡＰＧデータベースマネージャへのインターフェースおよびＩＰＵノード６０−６４（第３図）のアプリケーションプロセスを供給するＩＰＵデーベースハンドラ１３０などの若干のオブジェクトを含む。ＩＰＵデータベースマネージャ６６は、さらに、直接的に、ＩＰＵノードにファイルシステムのマウント、およびアンマウント、またデータベースファイルを共用メモリ７２（第３図）へのおよび共用メモリ７２（第３図）からのマッピング、およびアンマッピングに対しての責任を有する。プロセス６６のオブジェクト１３０は、さらに、新データベースロード情報をノードのアプリケーションプロセスに通信する。グループファイルハンドラ１３２は、定期的に、共用メモリ７２（第３図）にあるデータベースファイルをミラーリングディスク８０−８２（第３図）に同期させる責任を負う。ＩＰＵディスクマネージャオブジェクト１３４は、ＩＰＵデータベースハンドラ１３０によってインスタンス生成され、ファイルシステムのマウントおよびアンマウンとを行う責任を負う。データベースファイルマッパオブジェクト１３６は、共用メモリへ、または共用メモリからファイルをマッピング、およびアンマッピングする責任を負う。ＩＰＵノードのファイル毎に１つのデータベースファイルマッパ１３６がある。加入者データベースアクセスオブジェクト１３８は、リモートノードアクセスのプロセスをこの特定のＩＰＵによって処理されるデータベースの部分に供給する責任を負う。リモートノードは、例えば、メイトＳＣＰ２６ａ（第２図）に存在するノードを含む。分散された冗長データベースのオペレーションは、第７図乃至第１９図のフローチャートおよびブロック図によってより詳細に記述されており、以下に順番に論じられる。第２図乃至第６図は、必要なところで、特定の構成が論じられるときに、参照されている。ＡＰＧデータベースマネージャ５２は、第１に、ＳＣＰのそれぞれのＡＰＧのＡＰＧデータベースマネージャ５４のインスタンス生成する。第７図は、ブロック１６０のＡＰＧデータベースマネージャ初期設定開始の例示的なプロセスフローである。第１に、ＡＰＧデータベースハンドラオブジェクト１１０は、ブロック１６２に示されるように、インスタンス生成される。ブロック１６４において、ＡＰＧデータベースハンドラ１１０は、データベースルートコントロール１１２と、データベース構成テーブルアクセス１１６と、ＩＰＵ情報テーブル１１４のインスタンス生成する。データベースルートコントロールオブジェクト１１２は、ブロック１６６および１６８に示されるように、インスタンス生成され、ＡＰＧデータベースマネージャ５２のすべてのテーブル９０−９４を初期設定する。ＰＭがアクティブである場合、ブロック１７０で決定されるように、監査は、ブロック１７２のＡＰＧデータベースハンドラによってＩＮ＿ＳＥＲＶＩＣＥについて行われる。監査により、ブロック１７４に示されるように、この情報を有するテーブルを更新するために使用される監査されたＩＰＵのデータベースロードを生ずる。ブロック１７６および１７８に続いて、ＡＰＧデータベースマネージャ５４は、初期設定プロセスを終了する前に、ＰＭノードプロセスにそれ自体を登録する。登録の行為が、オブジェクトのインスタンスをその他のプロセスに示し、その他のプロセスが、それらと通信する。第８図は、ＩＰＵデータベースマネージャ初期設定１９０の例示的なプロセスフロー２０示している。ブロック１９２において、ＩＰＵデータベースハンドラ１３０、グループファイルハンドラ１３２および加入者データベースアクセス１３８のオブジェクトが、インスタンス生成される。共用メモリーツー−ディスク更新に使用される同期タイマが、ブロック１９４で開始される。ＩＰＵデータベースハンドラ１３０は、ブロック１９６に示されるように、ＡＰＧデータベースハンドラ１１０からのデータベースロードを共用することを要求する。応答において、ＡＰＧデータベースマネージャ５４が、ファイルシステムの情報のデータベース構成およびＩＰＵテーブル、またこの情報を有する要求するＩＰＵをルックアップし、ＩＮ＿ＳＥＲＶＩＣＥのＩＰＵのデータベースロードが、ブロック１９８および２００に示されるように、ＩＮ＿ＳＥＲＶＩＣＥに存在するＩＰＵの数およびトラフィック状態に基づき決定される。データベースロードは、ブロック２０２の要求するＩＰＵに分散される。ＩＰＵデータベースマネージャ６６は、ブロック２０６に示されるように、ＰＭノードプロセスにそれ自体を登録する。ＩＰＵデータベースマネージャ６６は、ブロック２０４に示されるように、ロードを受信する。ＩＰＵに割り当てられるデータベースの部分に属するファイルシステムは、ブロック２０８に示されるように、ＩＰＵに追加されたり、またはマウントされたりする。初期設定プロセスは、ブロック２１０で終了する。第９図は、プラットフォームマネージャ３４が、ブロック２３０で開始するスタンバイモードからアクティブモードに変化するときのＡＰＧデータベースマネージャのプロセスフローを示している。プラットフォームマネージャで操作するすべてのＡＰＧデータベースマネージャ５４は、ブロック２３２に示されるように、ＩＰＵデータベースロードの監査を実施する。それぞれのＡＰＧのデータベースルートコントロール１１２は、データベース構成テーブル９０、ルートテーブル９４およびＩＰＵテーブル９２を含むすべてのテーブルを初期設定する。ＡＰＧデータベースハンドラ１１０は、ブロック２３６および２３８に示されるように、ＡＰＧのＩＮ＿ＳＥＲＶＩＣＥのＩＰＵのリストを入手し、データベースロードについてそれぞれのＩＮ＿ＳＥＲＶＩＣＥのＩＰＵに照会する。テーブルは、ブロック２４０に示されるように、ＩＮ＿ＳＥＲＶＩＣＥのＩＰＵによって供給される情報で再構成されて、更新される。さらに、この監査情報によって、割り当てを解除されたファイルシステムが、ブロック２４２および２４４に示されるように、軽いロードのこれらのＩＮ＿ＳＥＲＶＩＣＥのＩＰＵに割り当てられ、割り当てられるロードを有しないＩＰＵが、デフォルトデータベースロードに割り当てられる。新データベースロード分散により、ＡＰＧデータベースハンドラ１１０によってホストに供給されるルートテーブル９４の新ルーティング情報となる。スタンバイからアクティブへの変化プロセスが、ブロック２４８で終了する。ＩＰＵ故障は、ブロック２５０で開始する第１０図に示されるプロセスフローによって処理される。ブロック２５２において、ＡＰＧデータベースマネージャ５４は、ＩＰＵ故障の通知をＰＭノードプロセスから受信する。タイマが、ブロック２５４に示されるように、それぞれの故障ＩＰＵにセットされる。タイマ終了前に、ＡＰＧデータベースマネージャ５４が、ＩＰＵＩＮ＿ＳＥＲＶＩＣＥ通知を受信する場合、ブロック２５６で決定されるように、なにもする必要はない。しかし、そのような通知が受信されない場合、ブロック２５８に示されるように、またＩＰＵ終了通知が受信される場合、またはタイマが終了する場合、故障ＩＰＵによって運ばれるロードが、ブロック２６０および２６２に示されるように、残りのＩＮ＿ＳＥＲＶＩＣＥＩＰＵに再割り当てされ送信される。別のＩＮ＿ＳＥＲＶＩＣＥＩＰＵが、ブロック２６４で決定されるように、故障する場合、実行がブロック２６０に進み、データベースロードが、再度、残りのＩＮ＿ＳＥＲＶＩＣＥＩＰＵに再分散される。ブロック２６４で決定されるように、別のＩＰＵが故障しない場合、データベースルートコントロール１１２は、ブロック２６６および２６８に示されるように、ルートテーブル９４から更新されたルーティング情報を抽出し、ＡＰＧデータベースハンドラが、この情報をホストに供給する。プロセスは、ブロック２７０で終了する。ファイルシステムにＩＰＵを追加するために、第１１図に示されるブロック２８０で開始する例示的なプロセスフローが使用される。ＩＰＵディスクマネージャ１３４が、ブロック２８２に示されるように、適当なＩＰＵに追加されるファイルシステムをマウントする。マウントされたファイルシステムのファイルは、ブロック２８４に示されるように、グループファイルハンドラ１３２によって共用メモリにマッピングされる。加入者データベースアクセス１３８は、ブロック２８６に示されるように、共用メモリファイルにタスク生成する。ファイルのレコードは、好ましい実施の形態のＲｅｄ−Ｂｌａｃｋツリーデータ構造のポインタをアクセスして、組織され、検索可能となるので、Ｒｅｄ−Ｂｌａｃｋツリーは、必要な場合修正され、または再組み立てされる。Ｒｅｄ−Ｂｌａｃｋツリーは、迅速な検索を促進するバランスツリーデータ構造であり、ファイルのすべてのレコードは、Ｒｅｄ−Ｂｌａｃｋツリーのノードを検索することによって配置される。モジュロオペレーションが、ファイルインデックスを生成し、適当なＲｅｄ−Ｂｌａｃｋツリー共用メモリファイルを検索することによって、特定のレコードがアクセスされることを思い出してほしい。その他のデータ構造が、本発明の範囲から逸脱することなく使用されることが明らかなことは重要なことである。以下に、加入者データベースアクセス１３８は、ブロック２９０に示されるように、新ＩＰＵファイルロードについてメッセージをすべての関係アプリケーションに送信する。このプロセスは、ブロック２９２で終了する。ファイルシステム除去は、さらに、第１２図に示されるように、かつブロック３００で開始するＩＰＵデータベースハンドラ１３０によって処理される。加入者データベースアクセス１３８は、ブロック３０２および３０４に示されるように、ファイルを共用メモリから消去し、アプリケーションを共用メモリから消去する。グループファイルハンドラ１３２は、ブロック３０６および３０８に示されるように、共用メモリセグメントの割り当てを解除し、ＩＰＵディスクマネージャ１３４が、当該ファイルシステムをアンマウントする。ファイルシステム除去プロセスは、ブロック３１０で終了する。データベースロードが、ＡＰＧのＩＰＵ間でバランスがとられ、照会トラフィックの均等分散が、成し遂げられることが注目されている。さらに、ＩＰＵが、故障するか、または操作されていない状態（ＯＳ＿ＭＩＮまたはＯＵＴ＿ＯＦ＿ＳＥＲＶＩＣＥ）の１つに入るので、データベースロードは、残りのＩＮ＿ＳＥＲＶＩＣＥＩＰＵに再構成されるか、または再分散される必要がある。ＰＭデータベースマネージャ５２とＡＰＧデータベースマネージャ５４との間のロードバランシングおよびデータベース再構成を同期させるために、共用メモリアレイ１２０がインスタンス生成され、一方は、構成アレイ、共用メモリのブールのアレイであり、他方は、ロードバランスフラグ、共用メモリに維持されるブールフラグである。特別のＡＰＧのデータベースが、１つ以上のＩＰＵの、ダウンまたはサービスへの再入により、再構成される場合、適当なＡＰＧデータベースマネージャ５４は、再構成アレイの対応するフラグをセットする。データベース再構成が完了すると、ＡＰＧデータベースマネージャ５４が、再構成アレイのフラグをリセットする。同様に、ロードバランシングが実行されている場合、ロードバランスフラグが、ＰＭデータベースマネージャ５２によってセットされる。第１３図乃至第１５図は、ロードバランシングとデータベース再構成とを同期させるプロセスを説明するフローチャートである。第１３図において、例示的なロードバランス要求プロセス３２０が示されている。ロードバランスは、専門のスクリーンインターフェースを介して専門家によって、ＰＭデータベースマネージャ５２によって、またはＡＰＧデータベースマネージャ５４によって要求される。再構成アレイは、ブロック３２２に示されるように、第１に、再構成フラグが、問題のＡＰＧのためにセットされているかどうかを見るために検査される。再構成フラグがセットされている場合、ロードバランシングが、ブロック３２４に簡単にアボートされ、その後に再試行される。ロードバランシングは重要なオペレーションでないので、そのような機構が設けられているが、ロードバランシングは再構成の完了を待つことを要求されない。ＡＰＧ用再構成フラグがセットされていない場合、ロードバランスフラグが、ブロック３２６に示されるようにセットされ、ロードバランシングが、ブロック３２８に示されるように実行される。ロードバランシングが、ブロック３４０で開始する第１４図の例示的なフローチャートに示されている。１つ以上の特定のファイルシステムを１つ以上の特定のＩＰＵに移動する要求が、ブロック３４２に示されるように、受信される。要求は、現行ロード分散およびトラフィック状態を考慮して、専門家又はＰＭ、ＡＰＧデータベースマネージャによって生成される。ブロック３４４において、データベースルートコントロール１１２は、バランスロード分散を反映するテーブルに必要な変化をさせる。新データベースロードは、ブロック３４６に示されるように、ＰＭデータベースハンドラ９６によってソースと宛先とに供給される。この時点で、ブロック３４８に示されるように、ソースおよび／または宛先ＩＰＵが故障したことが検知される場合、ロードバランシングは、ブロック３５４で簡単に終了される。そうでない場合、データベースルートコントロール９８は、ブロック３５０および３５２に示されるように、ルートテーブル９４から新ルーティング情報を抽出し、それをホストに供給する。第１５図は、ブロック３６０で開始するデータベース再構成を開始するプロセスフローを示している。データベース再構成が望まれる場合、適当な再構成フラグが、ブロック３６２に示されるように、ＡＰＧのためにセットされる。次にブロック３６４に示されるように、再試行カウンタまたはタイマ（ＲＥＴＲＹ＿ＣＮＴ）がゼロにリセットされる。実行は、再構成プロセスが進行中の場合、ロードバランシングの完了を待つループに入る。再試行カウンタが、ブロック３６８に示されるように、予め定められた上限、例えば、１８０に達したかを見るために検査される。上限に到達している場合、ＰＭノードが故障しており、そのステータスが、ＯＳ＿ＭＩＮ状態にダウングレードされる。再試行カウントが、予め定められた上限に達しなかった場合、ロードバランスフラグが、ブロック３７０に示されるように、セットされているかどうかを見るために検査される。ロードバランスフラグがセットされていない場合、実行はデータベース再構成と共に進む。そうでない場合、再試行カウンタは増加され、予め定められた時間、例えば、１秒間が、ブロック３６６のループの開始に戻る前に経過される。分散冗長データベース１０に行われるいくつかのデータ同期プロセスがある。それぞれのＩＰＵ共用メモリに格納されるデータは、２つのミラーリングディスクに同期され、それぞれのＳＣＰのデータベースの修正された一時データが、そのメイトＳＣＰに供給される。第１６図は、ＩＰＵの共用メモリ７２−７６（第３図）のデータをミラーリングディスク８０および８２に同期させる例示的なプロセスフロー３８０である。ブロック３８２において、ＩＰＵ同期タイマは、それが終了されたかどうかを決定するために検査される。第８図のブロック１９４に示されるように、このタイマが、ＩＰＵデータベースマネージャ初期設定中に初期設定されたことを思い出してほしい。同期タイマが満了されなかった場合、同期タイマが満了されるまで、予め定められたタイマの時間が、経過され、タイマが、再検査される。同期タイマの満了が、ブロック３８４に示されるように、共用メモリのファイルの一部分またはブロックをミラーリングディスクにコピーする時間を指示する。ブロック３８６に示されるように、同期タイマがリセットされ、ブロック３８２に戻る。次の同期タイマの満了時に、ファイルの次の部分がディスクにコピーされる。全ファイルがコピーされると、次のファイルがディスクにファイルされる。このように、それぞれのＩＰＵの共用メモリの全ファイルが、ディスクにコピーされる。それぞれのＩＰＵが、異なるセットのファイルシステムに割り当てられるので、ＩＰＵは、それぞれのその他のオペレーションを妨害することなくマルチ初期設定されたモードで並行にディスクに「同期」することができる。ディスクプロセスへの「同期」が、主として、加入者現行位置などの一時データを有するディスクを更新することは注目されることである。新加入者を追加したり、または削除したりするなどの静的データやサービスオプション更新、加入者プリファレンスデータなどは、同一データを共用メモリに一般には同時に書き込みながらミラーリングディスクに直接書き込まれる。第１７図は、ＳＣＰ対２６のそれぞれのＳＣＰ２６ａおよび２６ｂが、同一情報を含むためＳＣＰデータベース間の同期を示す簡素化されたブロック図を示している。この例示のために、それぞれのＳＣＰ２６ａおよび２６ｂが、３つのＡＰＧ（第２図に示されるように）を含む。３つのＡＰＧのそれぞれにおいて、ＳＣＰ毎に４つのＩＰＵがあり、総計１２のＩＰＵになる。ＳＣＰ対２６に関連付けられた加入者データベースは、１２８の個人のファイルに分割され、それぞれのＡＰＧが、４２または４３のファイルに対して責任を負う。それぞれのＡＰＧの４つのＩＰＵのそれぞれが、サービス中のＩＰＵの数およびＩＰＵ間のファイルの分割により、７−４３のファイルに対して責任を負う（上記第３図および第３Ａ図を参照）。それぞれのＩＰＵは、性能改善のために複数のＣＰＵプロセッサを含む。オペレーションにおいて、独立した同期プロセスは、それぞれのファイルＦ１ −Ｆ１２８用である。それぞれのファイルについて、ＩＰＵ同期プロセスは、どのレコードが、一時情報および／または変化した音声メールを有するかを決定し、同期されたバッファに変化されたレコードを格納する。それぞれのレコードについて、ＩＰＵ同期プロセスがそのレコードを最後に検査した時から、一時情報または音声メール情報のいずれかが変化したことを識別するために、２つのフラグが存在する。同期バッファが、一杯であるとき、またはファイルが完全に検索されたとき、ＩＰＵ同期が、同期バッファをそのメイトＳＣＰの対応するＩＰＵに送信する（ＳＣＰ２６ａは、ＳＣＰ２６ｂのメイトＳＣＰであり、ＳＣＰ２６ｂは、ＳＣＰ２６ａのメイトＳＣＰである）。さらに、それぞれのファイルについて、ＩＰＵ更新プロセスが、そのメイトＳＣＰの対応するＩＰＵから同期バッファを受信する。メイトＳＣＰから同期バッファを受信すると、ＩＰＵ更新プロセスは、関連ファイルのレコードを更新する。それぞれのＩＰＵに、２つのプロセス、ＩＰＵ同期メインおびＩＰＵ更新メインが、そのＩＰＵと関連されるファイルのＩＵ同期およびＩＰＵ更新プロセスを活動化し、管理する責任を負う。別の実施の形態において、それぞれのファイルを実行する４つの独立したプロセスがある：ＩＰＵ同期Ｖ（音声メール情報が変化したレコードのファイルを走査し、出力が音声メール同期バッファに変化したファイルを出力する）と、ＩＰＵ同期Ｔ（一時情報が変化したレコードのファイルを走査し、一時同期バッファに変化したファイルを出力する）と、ＩＰＵ更新Ｖ（音声メール同期バッファのレコードに応答するメイトＳＣＰのレコードを更新する）と、ＩＰＵ更新Ｔ（一時同期バッファのレコードに応答するメイトＳＣＰのレコードを更新する）。第１８図は、ＩＰＵ同期プロセスが、一時または音声メール情報のいずれかが変化したレコードを検索する場合のＩＰＵ同期プロセスのオペレーションを記述するフローチャートである。ブロック４２０の関連ファイルの第１レコードでスタートすると、それぞれのレコードが検査され、レコードの一時または音声メール情報のどれが決定ブロック４２２で変化したかを決定する。情報が変化した場合、レコードが、ブロック４２４で同期バッファに書き込まれる。レコートの情報がブロック４２２において変化しなかった場合、プロセスが、決定ブロック４２６でファイルの最後に到達したかどうかを、またはバッファが、決定ブロック４２８で満杯であるかどうかを見るために、検査される。これらの状態のいずれかが正しい場合、同期バッファがメイトＳＣＰのＩＰＵ更新プロセスに送信される。いずれの状態も満たされない場合、次のレコードがブロック４３２で検査される。それぞれのファイルの一時および音声メール情報の独立したＩＰＵ同期プロセスのその他の実施の形態において、決定ブロック４２２のそれぞれのプロセスが一時データ（ＩＰＵ同期Ｔの場合）または音声メールデータ（ＩＰＵ同期Ｖ）におけるいずれかの変化を検索することを除いては、第１８図の基本フローが使用される。第１９図が、ＩＰＵ更新プロセスのオペレーションを記述するフローチャートを示している。ブロック４４２において、同期バッファが、メイトＳＣＰのＩＰＵ同期プロセスから受信される。ブロック４４４、４４６、４４８および４５０において、同期バッファのそれぞれのレコードは、関連ファイルを更新するために使用される。第１８図のように、それぞれのファイルの一時および音声メール情報の独立したＩＰＵ更新プロセスの他の実施の形態の場合、それぞれのプロセスが、ブロック４４２の一時同期バッファ（ＩＰＵ更新Ｔの場合）または音声メール同期バッファ（ＩＰＵ更新Ｖの場合）にいずれかを受信することを除いては、第１９図の基本フローが使用される。第２０図は、集中型グローバルタイトル変換（ＣＧＴＴ）テーブル３４の図を示している。ＣＧＴＴテーブル３４は、ＰＳＮの範囲を、その範囲内の加入者をサポートする責任を負うＳＣＰ対２６に関係づける。ＣＧＴＴテーブル３４の情報が、そのような情報を必要とするＡＩＮシステム２２内のサブシステム、すなわちＳＣＰ２６やＳＴＰ２４、ＳＭＳ３０、ＶＭＳ３２などをサポートするために使用される。ＳＭＳは、どのＳＣＰ対２６（または複数のＳＣＰ対２６）が、加入者アカウント情報を追加や削除、修正したりする情報を送信するかを決定するために、情報を必要とする。ＳＴＰ２４は、適当なＳＣＰ対２６に照会をルーティングするために、ＣＧＴＴテーブル３４の情報を必要とする。ＶＭＳ３２は、音声メール状態の情報を適当なＳＣＰ対２６へ送信するために、ＣＧＴＴテーブル３４の情報を必要とする。最後に、ＳＣＰ２６は、電話接続にとっての他のパーティに関連付けられたＳＣＰを決定するために、ＣＧＴＴテーブル３４の情報を必要とする。第２０図を参照すると、ＣＧＴＴテーブル３４は、ｎ個のエントリ（またはレコード）３６を有し、ｎは、典型的な実施形態では１０００エントリである（または限定されることはない）。それぞれのエントリには、５つのフィールドがある。第１フィールド３８は、エントリによって定義される範囲のＰＳＮの桁数を識別する。このフィールドは、電話システムは、日本やその他の国など固定長番号を使用しない国で使用される。第２フィールドは、範囲の起点ＰＳＮを識別し、第３フィールドは、範囲の最終ＰＳＮを識別する。第４のフィールドは、第２および第３フィールドによって定義される範囲内のＰＳＮに関連付けられた第ＩＳＣＰ対を識別する。第５フィールドは、第２および第３フィールドによって定義される範囲内のＰＳＮに関連付けられた第２ＳＣＰ対２６を識別する。以下に詳細に記述されるように、情報がＳＣＰ対の間のデータの移動中に、２つのＳＣＰ対に書き込まれるとき、第２ＳＣＰ対２６が使用される。第４および第５フィールド内に、９つのサブフィールドがある。第１サブフィールドは、変換タイプを定義する。必要な場合、これが、異なるネットワークタイプを識別するために使用される。第２サブフィールドは、プロバイダ間で異なる番号計画を識別する。第３サブフィールドは、第１および第２ＳＣＰ間を共用するロードを第ＩＳＣＰに、または第ＩＳＣＰが動作しない場合、第２ＳＣＰのいずれかに、バックアッブモードを定義する。ＳＴＰが最終ＳＴＰであるか否か、プライマリＳＣＰの名称およびプライマリＳＣＰの宛先アプリケーションであるかどうかを、第４、第５および第６サブフィールドが識別する。第７、第８および第９サブフィールドが、バックアップ経路についての同一情報を識別する。オペレーション中、ＣＧＴＴテーブル３４は、様々なＳＣＰ対の間のＰＳＮの割り当てを変えるために使用される。新ＳＣＰ対を追加したり、またはＰＳＮを過負荷のＳＣＰ対から十分に利用されていないＳＣＰ対に再割り当てたりするいずれかのときに、再割り当てが行われる。ＡＩＮ内の様々なサブシステムに新ＧＴＴを分散が、２つの方法の１つを使用して実行される。第１は、サブシステムの新テーブルが、ＮＣＣに準備され、サブシステムに送信される。新ＧＴＴが、サブシステムによって受信されると、旧ＧＴＴは、新ＧＴＴと置き換えられる。ある状態において、しかし、簡単なファイルの置き換えが、サービスを妨害することなく、起こり得ることはない。この場合、ＧＴＴを編集する既存の編集プログラムが、ＣＧＴＴテーブル３４のデータに対して使用される。第１に、サブシステムのＧＴＴのコピーが、ＮＣＣによって受信される。このコピーは、ＣＧＴＴテーブル３４の現行情報と比較される。ＧＴＴとＣＧＴＴとの間の差が決定される。この差が、コマンド生成し、ＧＴＴの編集プログラムをコントロールするために使用される。新テーブルをサブシステムに送信する代わりに、コマンドが、ユーザによって変化させるために入力されるコマンドを模擬するバッチファイルとして実行されるために送信される。しかし、好ましい実施の形態においてコマンドは２つのデータベースを比較してＮＣＣによって自動的に生成され、サブシステムにダウンロードされ、ほとんど対話することなく実行される。第２１図および第２２図は、サブシステムの内部ＧＴＴの変化を行う２つの方法を示している。第２１図には、データベースの置き換え方法を記述するフローチャートを示している。ブロック４６０において、サブシステムのＧＴＴデータベースが、ＣＧＴＴ３４からの情報を使用して生成される。ブロック４６２において、サブシステムの新ＧＴＴが、ＮＣＣからサブシステムにダウンロードされる。ブロック４６４において、サブシステムによって現在使用されているＧＴＴが、新ＧＴＴと置き換えられる。第２２図は、ＣＧＴＴ３４の情報によるサブシステムの現行ＧＴＴを修正するバッチファイル方法を示している。ブロック４７０において、ＮＣＣが、サブシステムに現在使用されているＧＴＴをアップロードする。現行ＧＴＴからの情報が、ブロック４７２で、ＣＧＴＴ３４の情報と比較されて、ＣＧＴＴ３４に情報を適合させるために、もしあれば、サブシステムの現行ＧＴＴに作成されるために必要とする変化を決定する。ブロック４７４において、現行ＧＴＴを修正するためのコマンドが生成される。典型的なコマンドは、ＡＤＤ＜レコード＞、ＤＥＬＥＴＥ＜レコード＞、またはＭＯＤＩＦＹ＜レコード＞である。これらのコマンドを有するバッチファイルは、ブロック４７６で、所定サブシステムのＧＴＴ編集プログラムを実行するコンピュータにダウンロードされる。バッチファイルは、ブロック４７８で、ＧＴＴに修正を行うコンピュータによって実行される。第２３ａ図乃至第２３ｅ図は、１つのＳＣＰ対（ＳＣＰ１、ＳＣＰ１Ａおよび１Ｂを含む移動元ＳＣＰ）から第２ＳＣＰ対（ＳＣＰ２、ＳＣＰ２Ａおよび２Ｂを含む移動先ＳＣＰ）への情報の移動を示している。１つのＳＣＰ対２６から別のＳＣＰ対２６への情報の移動は、ＳＣＰ１からＳＣＰ２へのＰＳＮの範囲に対応する転送レコードを含む。この手順は、例えば、新ＳＣＰ対２６がシステムに迫加されるときまたはレコードがシフトされるときに、実行され、ＳＣＰ対２６間のロードを均等に分配する。重要なことは、情報の移動が関連するダウンタイムを持たないで、動的に行われることである。第１移動ステップが、第２３ａ図を参照して示されている。第１に、オペレータが、ＳＣＰ１からＳＣＰ２にスイッチされる特定範囲の番号のＳＭＳサービス（顧客のレコードを追加、削除および修正）を抑止する。ＳＭＳサービスは、電話デバイス間の接続に影響を及ぼさないので、このステップは電話サービスに影響を及ぼさない。特定範囲のすべての加入者レコードは、ＳＣＰ１ＡからＳＣＰ２ＡおよびＳＣＰ２Ｂへとコピーされる。移動元ＳＣＰ１Ａおよび１Ｂは、特定範囲のレコードの各々と関連付けられた転送同期ビット（転送されたレコードが修正されたことを示している）をリセットする。ＳＣＰ２Ａおよび２Ｂは、受信されたレコードの転送同期ビットと照会同期ビット（上記第１７図乃至第１９図を参照して、メイトＳＣＰ間を同期させることについて記述されている）とをリセットする。レコード情報の転送が、実行されるあいだに、移動元ＳＣＰ１は、照会（一時データ）および音声メール情報を受信し、影響を及ぼされたレコードの転送同期ビットと照会同期ビットとをセットする。ＳＣＰが一時および音声メール更新をそれらのメイト（例えば、ＳＣＰ１ＡからＳＣＰ１ＢへおよびＳＣＰ１ＢからＳＣＰ１Ａへ）に送信すると、照会同期ビットがリセットされる。レコードの転送が完了すると、監査が、ＳＣＰ１Ａと２Ａの間で、およびＳＣＰ１Ｂと２Ｂの間で行われる。相違があれば、問題が修正され、またはプロセスが、リスタートされる。第２３ｂ図は、レコードの移動の次のステップを示している。このステップにおいて、転送同期コマンドは発行される。転送同期コマンドが発行されると、ＳＣＰ１Ａは、更新をＳＣＰ２Ａに送信し、ＳＣＰ１Ｂは、更新をＳＣＰ２Ｂに送信する。更新情報を送信すると、移動元ＳＣＰ１Ａまたは１Ｂが、更新されたレコードの転送同期ビットをリセットする。更新をＳＣＰ１に送信するために、ＳＣＰ２が使用されることは可能であるが、一時または音声メール照会を受信していないので、ＳＣＰ２は、この点でメッセージをＳＣＰ１に通過させない。メイトＳＣＰ１Ａおよび１Ｂ間の同期は実行されつづける。ＳＣＰ２Ａおよび２Ｂ間の同期も実行可能とされる。転送同期コマンドが七ットされると、ＳＭＳおよびＳＣＰ（ＣＧＴＴ３４による）のグローバルＧＴＴは更新されて、ＳＣＰ１およびＳＣＰ２の特定範囲のレコードの更新を送信する。このように、ＳＭＳからの変化が双方のＳＣＰ対に影響を及ぼす。第２３ｃ図において、ＳＴＰのＧＴＴが修正されて、特定範囲のレコードのすべての照会を移動先ＳＣＰ対、ＳＣＰ２にルーティングされる。ＳＣＰ２が、一時データに関するＳＣＰ１を更新し、ＳＣＰ１が、音声メールデータに関するＳＣＰ２を更新するので、転送同期は現在両方向に生ずる。第２３ｄ図において、ＶＭＳのＧＴＴが修正されて、特定範囲のレコードのすべての音声メール照会を移動先ＳＣＰ対、ＳＣＰ２にルーティングされる。転送同期が、両方向にまだ生じている間、実際は移動元ＳＣＰ対、ＳＣＰ１が、一時または音声メール照会を受信せず、送信するための更新メッセージを有しない。ＳＣＰ２が更新をＳＣＰ１に送信すると、ＳＣＰ２は更新されたレコードの転送同期ビットをリセットする。ＶＭＳのＧＴＴが、ＳＴＰのＧＴＴと同時に修正され、音声メールおよび一時照会の両方を同時にＳＣＰ２にスイッチすることは注目すべきことである。この点で、移動先の対は、継続するサービスを実行するが、両方のＳＣＰ対は十分にレコードの特定範囲の操作可能である。ＳＣＰ２によるレコードの処理が監視され、処理が適当に続行される場合、転送同期が抑止される。そうでない場合、オペレータは、ＳＴＰに関連付けられたＧＴＴとＶＭＳとを以前の割り当てに変化することによって、移動元ＳＣＰ対への復帰が可能である。第２３ｅ図において、以前の割り当てに復帰しないと仮定すると、ＳＭＳおよびＳＣＰのＧＴＴ（ＣＧＴＴ３４による）は変化されて、特定範囲内のレコードに対して責任を負うものとして、移動先ＳＣＰ対を指定可能である。転送レコードは、ＳＣＰ１から削除されることが可能である。ここに記述されるＡＩＮシステムは、先行技術以上のかなりの利点を供給している。重要なことは、複数のＳＣＰが、照会に高速度で応答することである。加入者データベースが増加すると、追加のＳＣＰが、システムに追加される。１つのＳＣＰ対からのレコードは、サービスを中止することなく、一時または音声メール情報を損失することなく、別の対に移動されることが可能である。集中型ＧＴＴは、ＡＩＮの様々なサブシステムに関連付けられたＧＴＴを修正する効率の良いシステムを供給する。照会を修正ＳＣＰに向けるＧＴＴと照会をホスト５１から正しいＩＰＵに向けるルートテーブルとを組み合わせることにより、照会を迅速に宛先に通過させる高能率の信号通路を供給する。高速同期方法により、更新する間に最短待ち時間を有するＳＣＰ対のＳＣＰ間に冗長性を維持させる。本発明の詳細な説明は、特定の例示的な実施の形態に向けられてきたが、これらの実施の形態の様々な修正およびその他の実施の形態が、当業者により提案されるであろう。本発明は、請求の範囲内にある修正またはその他の実施の形態を含むものである。

【手続補正書】特許法第１８４条の８第１項【提出日】平成１１年５月１２日（１９９９．５．１２）【補正内容】請求の範囲１．交換ネットワークに結合された複数の電話デバイスと、前記交換ネットワークからの加入者情報に対する要求に応答する情報を提供するサービスネットワークであって、各々がデータベースの１部分を維持する責任を負う複数の制御ポイントを備える、加入者情報のデータベースを維持するデータベース機構と、前記交換ネットワークからの前記要求に対する応答を提供し続けながら、第１のサービス制御ポイントから、加入者レコードのセットを維持するように設計された第２のサービス制御ポイントに、前記加入者レコードのセットを動的に移動する機構とを備えるサービスネットワークと、前記加入者レコードのセットに関する更新と照会を、前記第２のサービス制御ポイントにルーティングする機構とを備えることを特徴とする通信システム。２．前記電話デバイスが、モバイル電話を含むことを特徴とする請求項１に記載の通信システム。３．前記電話デバイスがさらに、前記モバイル電話からの信号を受信し、前記信号を前記交換ネットワークに通信する基地局を含むことを特徴とする請求項２に記載の通信システム。４．前記動的に移動する機構が、前記第１のサービス制御ポイントが、要求に対して応答し続けている間に、所定の範囲のレコードの情報を前記第１のサービス制御ポイントから前記第２のサービス制御ポイントにコピーするステップと、前記情報がコピーされている間に、前記第１のサービス制御ポイント中の変更済みレコード内にフラグを設定するステップと、前記第１のサービス制御ポイント中のフラグ付けされたレコードに対応する前記第２のサービス制御ポイント中のレコードを更新するステップとを実行することを特徴とする請求項１に記載の通信システム。５．前記動的に移動する機構が、さらに、前記所定の範囲のレコードの前記コピーの後、前記所定の範囲のレコードに対する要求を、前記第２のサービス制御ポイントに送出するステップと、前記第２のサービス制御ポイント中の変更済みレコード内にフラグを設定するステップと、前記第２の制御ポイント中の前記フラグ付けされたレコードに対応する前記第１のサービス制御ポイント中のレコードを更新するステップとを実行することを特徴とする請求項４に記載の通信システム。６．前記動的に移動する機構が、前記第１のサービス制御ポイントから前記所定の範囲のレコードを削除するステップをさらに実行することを特徴とする請求項５に記載の通信システム。７．前記第１のサービス制御ポイントと前記第２のサービス制御ポイントの各々が、第１と第２のサブシステムを含み、各サブシステムが、前記サービス制御ポイントに関連付けられたデータベースの部分のコピーを有し、また、前記データベースの部分中のサブセットのレコードに対して主として責任を負うことを特徴とする請求項６に記載の通信システム。８．前記動的に移動する機構が、前記第１のサービス制御ポイントの前記サブシステム間で、データを同期させるステップをさらに実行することを特徴とする請求項７に記載の通信システム。９．前記動的に移動する機構が、第１のサブシステム中に格納されているデータベースの部分を、前記第２の制御ポイントの第１と第２のサブシステムにコピーすることによって同期させるステップを実行することを特徴とする請求項８に記載の通信システム。１０．交換ネットワークからの加入者情報に対する要求に対応する情報を提供する方法が、各々が、データベースの１部分を維持する責任を負う複数のサービス制御ポイント中に、加入者情報のデータベースを維持するステップと、前記交換ネットワークからの要求に対する応答を提供し続けながら、第１のサービス制御ポイントから、加入者レコードのセットを維持するように設計された第２のサービス制御ポイントに、加入者レコードのセットを動的に移動するステップと、前記加入者レコードのセットに関する更新と照会を、前記第２のサービス制御ポイントにルーティングするステップとを含むことを特徴とする方法。１１．動的に移動するステップが、前記第１のサービス制御ポイントが要求に対して応答し続けている間に、所定の範囲のレコードの情報を前記第１のサービス制御ポイントから前記第２のサービス制御ポイントにコピーするステップと、前記コピーするステップの間に、前記第１のサービス制御ポイント中の変更済みレコード中にフラグを設定するステップと、前記第１のサービス制御ポイント中のフラグ付けされたレコードに対応する前記第２のサービス制御ポイント中のレコードを更新するステップとを備えることを特徴とする請求項１０に記載の方法。１２．前記動的に移動するステップが、さらに、前記所定の範囲のレコードの前記コピーの後、前記所定の範囲のレコードに対する要求を前記第２のサービス制御ポイントに送出するステップと、前記第２のサービス制御ポイント中の変更済みレコード中にフラグを設定するステップと、前記第２の制御ポイント中の前記フラグ付けされたレコードに対応する前記第１のサービス制御ポイント中のレコードを更新するステップとを含むことを特徴とする請求項１１に記載の方法。１３．前記動的に移動するステップが、さらに、前記所定の範囲のレコードを前記第１のサービス制御ポイントから削除するステップを含むことを特徴とする請求項１２に記載の方法。１４．前記第１のサービス制御ポイントと前記第２のサービス制御ポイントの各々が、第１と第２のサブシステムを含み、各サブシステムが、前記サービス制御ポイントに関連付けられたデータベースの部分のコピーを有し、また、データベースの部分中のサブセットのレコードに対して主として責任を負うことを特徴とする請求項１３に記載の方法。１５．前記動的に移動するステップが、さらに、前記第１のサービス制御ポイントの前記サブシステム間でデータを同期させるステップを含むことを特徴とする請求項１４に記載の方法。１６．前記同期させるステップが、第１のサービス制御ポイントの第１のサブシステム中に格納されているデータベースの部分を、第２の制御ポイントの第１と第２のサブシステムにコピーするステップを含むことを特徴とする請求項１５に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｑ 7/26 7/30 (72)発明者ワン，ケテイ・イーアメリカ合衆国、テキサス・75075、プレイノウ、ハリントン・ドライブ・1509 (72)発明者トウン，ビーデインアメリカ合衆国、テキサス・75093、プレイノウ、ソルトブラン・ドライブ・4204 (72)発明者マオ，テイン−チユアンアメリカ合衆国、テキサス・75024、プレイノウ、マクカベツト・ドライブ・4421

Claims

【特許請求の範囲】１．交換ネットワークに結合された複数の電話デバイスと、前記交換ネットワークからの加入者情報に対する要求に応答する情報を提供するサービスネットワークであって、各々がデータベースの１部分を維持する責任を負う複数の制御ポイントを備える、加入者情報のデータベースを維持するデータベース機構と、前記交換ネットワークからの前記要求に対する応答を提供し続けながら、第１のサービス制御ポイントから第２のサービス制御ポイントに、データを動的に転送する機構とを備えるサービスネットワークとを備えることを特徴とする通信システム。２．前記電話デバイスが、モバイル電話を含むことを特徴とする請求項１に記載の通信システム。３．前記電話デバイスがさらに、前記モバイル電話からの信号を受信し、前記信号を前記交換ネットワークに通信する基地局を含むことを特徴とする請求項２に記載の通信システム。４．前記データを動的に転送する機構が、前記第１のサービス制御ポイントが、要求に対して応答し続けている間に、所定の範囲のレコードの情報を前記第１のサービス制御ポイントから前記第２のサービス制御ポイントにコピーするステップと、前記第１のサービス制御ポイント中の変更済みレコード内にフラグを設定するステップと、前記第１のサービス制御ポイント中のフラグ付けされたレコードに対応する前記第２のサービス制御ポイント中のレコードを更新するステップとを実行することを特徴とする請求項１に記載の通信システム。５．前記データを動的に転送する機構が、さらに、前記所定の範囲のレコードの前記コピーの後、前記所定の範囲のレコードに対する要求を、前記第２のサービス制御ポイントに送出するステップと、前記第２のサービス制御ポイント中の変更済みレコード内にフラグを設定するステップと、前記第２の制御ポイント中の前記フラグ付けされたレコードに対応する前記第１のサービス制御ポイント中のレコードを更新するステップとを実行することを特徴とする請求項４に記載の通信システム。６．前記データを動的に転送する機構が、前記第１のサービス制御ポイントから前記所定の範囲のレコードを削除するステップをさらに実行することを特徴とする請求項５に記載の通信システム。７．前記第１のサービス制御ポイントと前記第２のサービス制御ポイントの各々が、第１と第２のサブシステムを含み、各サブシステムが、前記サービス制御ポイントに関連付けられたデータベースの部分のコピーを有し、また、前記データベースの部分中のサブセットのレコードに対して主として責任を負うことを特徴とする請求項６に記載の通信システム。８．前記データを動的に転送する機構が、前記第１のサービス制御ポイントの前記サブシステム間で、データを同期させるステップをさらに実行することを特徴とする請求項７に記載の通信システム。９．前記データを動的に転送する機構が、第１のサブシステム中に格納されているデータベースの部分を、前記第２の制御ポイントの第１と第２のサブシステムにコピーすることによって同期させるステップを実行することを特徴とする請求項８に記載の通信システム。１０．交換ネットワークからの加入者情報に対する要求に対応する情報を提供する方法が、各々が、データベースの１部分を維持する責任を負う複数のサービス制御ポイント中に、加入者情報のデータベースを維持するステップと、前記交換ネットワークからの要求に対する応答を提供し続けながら、第１のサービス制御ポイントから第２のサービス制御ポイントにデータを動的に転送するステップとを含むことを特徴とする方法。１１．データを動的に転送するステップが、前記第１のサービス制御ポイントが要求に対して応答し続けている間に、所定の範囲のレコードの情報を前記第１のサービス制御ポイントから前記第２のサービス制御ポイントにコピーするステップと、前記第１のサービス制御ポイント中の変更済みレコード中にフラグを設定するステップと、前記第１のサービス制御ポイント中のフラグ付けされたレコードに対応する前記第２のサービス制御ポイント中のレコードを更新するステップとを備えることを特徴とする請求項１０に記載の方法。１２．前記データを動的に転送するステップが、さらに、前記所定の範囲のレコードの前記コピーの後、前記所定の範囲のレコードに対する要求を前記第２のサービス制御ポイントに送出するステップと、前記第２のサービス制御ポイント中の変更済みレコード中にフラグを設定するステップと、前記第２の制御ポイント中の前記フラグ付けされたレコードに対応する前記第１のサービス制御ポイント中のレコードを更新するステップとを含むことを特徴とする請求項１１に記載の方法。１３．前記データを動的に転送するステップが、さらに、前記所定の範囲のレコードを前記第１のサービス制御ポイントから削除するステップを含むことを特徴とする請求項１２に記載の方法。１４．前記第１のサービス制御ポイントと前記第２のサービス制御ポイントの各々が、第１と第２のサブシステムを含み、各サブシステムが、前記サービス制御ポイントに関連付けられたデータベースの部分のコピーを有し、また、データベースの部分中のサブセットのレコードに対して主として責任を負うことを特徴とする請求項１３に記載の方法。１５．前記データを動的に転送するステップが、さらに、前記第１のサービス制御ポイントの前記サブシステム間でデータを同期させるステップを含むことを特徴とする請求項１４に記載の方法。１６．前記同期させるステップが、第１のサービス制御ポイントの第１のサブシステム中に格納されているデータベースの部分を、第２の制御ポイントの第１と第２のサブシステムにコピーするステップを含むことを特徴とする請求項１５に記載の方法。