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