JP3974652B2 - 通信システムにおけるノードのためのハードウェアおよびデータ冗長アーキテクチャ - Google Patents
通信システムにおけるノードのためのハードウェアおよびデータ冗長アーキテクチャ Download PDFInfo
- Publication number
- JP3974652B2 JP3974652B2 JP52158996A JP52158996A JP3974652B2 JP 3974652 B2 JP3974652 B2 JP 3974652B2 JP 52158996 A JP52158996 A JP 52158996A JP 52158996 A JP52158996 A JP 52158996A JP 3974652 B2 JP3974652 B2 JP 3974652B2
- Authority
- JP
- Japan
- Prior art keywords
- database platform
- platform
- master
- service request
- slave
- 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.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Description
発明の背景
発明の技術分野
本発明は通信システムに関し、より詳細には通信システムにおける個々のノードに対しハードウェアおよびデータ冗長性の双方を提供するためのアーキテクチャに関する。本発明はデータベース、例えば移動電話ネットワークのホームまたはビジターロケーションレジスタを利用するシステムノードのためのかかる冗長性を提供することに特に利用できる。
関連技術の説明
移動電話ネットワークの移動交換センターは複数のデータベースを含み、これらデータベースは移動電話ネットワーク内での電話接続の確立中に交換センターから質問を受ける。これらデータベースはホームロケーションレジスタおよびビジターロケーションレジスタを含み、これらレジスタは加入者に関連したスタティック（すなわち変化しない）データおよびダイナミック（すなわち変化する）データの双方をデータベースフォーマットで記憶するためのプラットフォームを含む。
レジスタに記憶されるスタティックデータは、例えば移動交換センターと相互接続された交換機を協働させるための識別子のリストと、各加入者によって使用できる（話中転送のような）サービスの識別と、（固定されたＣ番号のような）かかるサービスに関連したパラメータとを含む。データの上記例のみならず他のタイプのスタティックデータもデータベースに入力され、これらデータはレジスタのアドミニストレータにしかこれを変更できない。他方、ダイナミックデータは、例えば（可変Ｃ番号のような）加入者が定義したサービスデータと、（移動交換センターおよび基地局の双方に対する）移動局ロケーションデータと、（移動局オン／オフステータスのような）移動局アクティビティデータとを含む。このデータを他のタイプのダイナミックデータと同じようにデータベースに入力し、これらデータは常時、加入者によって、移動局によって、またはネットワークによって、加入者にトランスペアレントな態様で変更できる。
ホームロケーションレジスタは移動電話ネットワーク内での電話の接続を確立するのに必要なデータを含むので、ホームロケーションレジスタのためのプラットフォームの故障は電話の発呼を受信したり、または発信する能力をかなりの数の加入者から奪うことになる。プラットフォームだけでなく、そこに記憶されているスタティックデータおよびダイナミックデータも電話の接続の確立に重要であることを思い出すことも、更に重要である。従って、ハードウェアの見地のみならず、記憶されているスタティックデータおよびダイナミックデータの無欠性を維持することにも関連してホームロケーションレジスタプラットフォームの故障を処理できるシステムが望まれている。かかるシステムは冗長性が必要とされるデータベースシステムまたは通信システムノードに用途がある。
発明の概要
個々のノードによる冗長なデータ取り扱い通信のための方法と共に、データ通信システムにおける個々のノードへハードウェアおよびデータ冗長性を与えるためのアーキテクチャが提供される。この方法は更にノードの故障後に正確なデータを回復することも配慮するものである。このアーキテクチャは構造を変えながら多数のプラットフォームを提供しつつ、データ通信の各ノードにおいて多数のプラットフォームを利用するものである。
本発明の一実施例によれば、多数のプラットフォームがマスターとスレーブの関係になるように対にされ、ネットワークに接続される。多数のプラットフォームの存在がネットワークにとってトランスペアレントとなるようにする信号ルータを介し、双方のプラットフォームに対し通信できるよう、すべてのネットワークユーザーが冗長に接続される。マスタープラットフォームにはデータ通信を取り扱うための（すなわちデータ通信を処理し、応答するための）基本的な役割が与えられる。従って、すべてのデータ通信信号は信号ルータによりマスタープラットフォームにルーチング（経路指定）される。スレーブプラットフォームは処理時にマスタープラットフォーム内に記憶されているデータの変更を生じさせるような通信信号と共に、マスタープラットフォームによりこのマスタープラットフォームにコピーされる。かかるスレーブプラットフォームへの通信信号のコピーにより、データ通信システム全体のデータの無欠性（インティグリィティ）が維持され、故障の場合にマスタープラットフォームからの処理作業を引き継ぐのに必要な情報がスレーブプラットフォームに与えられる。マスタープラットフォームの故障が発生し、この故障が検出されると、信号ルータは取り扱いのためにマスタープラットフォームへではなく、スレーブプラットフォームへデータ通信信号を自動的かつトランスペアレントにルーチングする。
本発明の別の実施例では、含まれる多数のプラットフォームのうちの各１つに全ユーザーのうちの一部のみに対する役割しか割り当てられない。従って、多数のプラットフォームは全ユーザー負荷に対する処理負荷の役割を分担する。しかしながらこれと同時に、すべてのネットワークユーザーは信号ルータを介してプラットフォームの各々への通信のために冗長的に接続される。処理時にプラットフォームに記憶されていたデータの変更を生じさせるようなデータ通信信号はプラットフォーム間でコピーされる。プラットフォーム間でのかかる通信信号のコピーによりデータ通信システムでのデータの無欠性が維持され、プラットフォームに故障が生じた場合に別のプラットフォームからの処理作業を引き継ぐのに必要な情報へ各プラットフォームがアクセスする機会が与えられる。プラットフォームに故障が発生し、これが検出されると、信号ルータはその代わりに取り扱いのために残りの機能的プラットフォームのうちの１つへデータ通信信号を自動的かつトランスペアレントにルーチングする。
本発明のシステムおよび方法は、移動電話システムの移動交換センターに維持されたロケーションレジスタ（ホームまたはビジター）を含むデータベースに対しハードウェアおよびデータの冗長性を提供する際に特に有効である。以下、この特定のアプリケーションに関連して本発明の好ましい実施例について説明する。しかしながら、本発明のシステムおよび方法はハードウェアおよびデータの双方に関する冗長性が必要とされるか、または有効なデータ通信システムにおけるノードおよび／またはデータベースシステムに適用可能であるので、本明細書に記載した冗長なホームロケーションレジスタに関連させた本発明の説明は、本発明の範囲を限定するものではなく、むしろ本発明を説明するためのものであることが理解できよう。
【図面の簡単な説明】
添付図面に関連させて次の詳細な説明を参照すれば、本発明の方法および装置についてより完全に理解できよう。
図１は、ホームロケーションレジスタを含む従来の移動交換センターのブロック図である。
図２は、マスター／スレーブ構造で提供される冗長性ホームロケーションレジスタプラットフォームを含む本発明の第１実施例のブロック図である。
図３は、図２のシステムにおいて、受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図４は、図２のシステムにおいて、マスターホームロケーションレジスタプラットフォームの故障およびその後受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図５Ａおよび５Ｂは、図２のシステムにおける、故障したホームロケーションレジスタプラットフォームにおける加入者データを回復するための２つの方法の処理工程を示すフローチャートである。
図６は、負荷分担構造で提供される冗長ホームロケーションレジスタプラットフォームを含む、本発明の第２実施例のブロック図である。
図７は、図６のシステムにおいて、受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図８は、図６のシステムにおいて、ホームロケーションレジスタプラットフォームの故障およびその後受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図９Ａおよび９Ｂは、図６のシステムにおける、故障したホームロケーションレジスタプラットフォームにおける加入者データを回復するための２つの方法の処理工程を示すフローチャートである。
図１０は、３つ以上の冗長ホームロケーションレジスタプラットフォームをリンクするための負荷分担構造のブロック図である。
実施例の詳細な説明
次に図１を参照する。ここには交換機１２と移動電話サブシステム１４とを備えた従来の移動交換センター１０のブロック図が示されている。移動電話サブシステム１４は移動電話システムの加入者に関連したスタティック（すなわち変化しない）データと、ダイナミック（すなわち変化する）データの双方を記憶するための複数のデータベース１６を含む。これらデータベースはホームロケーションレジスタ１８とビジターロケーションレジスタ２０を備え、これらレジスタは移動電話ネットワーク内および基地局２６を介した加入者の移動局２４への電話接続の確立中に、センターによる質問を受ける。交換機１２は更に公衆交換電話ネットワーク２２に接続されており、ホームロケーションレジスタ１８およびビジターロケーションレジスタ２０は電話システムのコンポーネントからのサービスリクエストメッセージも処理する。サービスリクエストメッセージに一般に応答する例としては、登録−通知、登録−キャンセルおよびサービス−プロフィル−リクエストが挙げられる。
データベース１６に記憶されるスタティックデータとしては、例えば移動交換センター１０と相互接続される協働する交換機のための識別子のリスト、各加入者によって使用できる（話中転送のような）サービスの識別および（固定されたＣ番号のような）かかるサービスに関連したパラメータがある。このデータのみならず当業者に知られている他のタイプのスタティックデータもデータベース１６に入力され、これらデータは移動交換センター１０内に設けられているデータベースアドミニストレータ２８によってしかこれを変更できない。他方、ダイナミックデータとしては、例えば（可変Ｃ番号のような）加入者が定義したサービスデータと、（移動交換センター１０および基地局２６の双方に対する）移動局２４ロケーションデータと、（移動局オン／オフステータスのような）移動局アクティビティデータとがある。このデータのみならず当業者に知られている他のタイプのダイナミックデータもデータベース１６に入力され、これらデータは常時加入者によって、移動局２４によって、またはネットワークによって、加入者にトランスペアレントな（すなわち加入者の知識または参加のためのアクションを必要としないで）態様で変更できる。
移動電話サブシステム１４は認証センター３０を更に含む。この認証センターは加入者が別の加入者のアイデンティティーを誤認するのを防止する認証パラメータおよび必要なときに送信される情報を暗号化するための暗号化パラメータを提供する。従来の移動交換センター１０またはそのコンポーネント部分の機能的動作および構成を更に詳細に説明することは不要であると考える。その理由は、かかる情報は当業者には周知であるからである。
次に、図２を参照する。この図には移動交換センターが冗長ホームロケーションレジスタ（ＨＬＲ）プラットフォーム１８’を含み、このプラットフォームがマスターホームロケーションプラットフォーム３２とスレーブホームロケーションプラットフォーム３４とを含む、本発明の第１実施例のブロック図が示されている。これらホームロケーションレジスタプラットフォーム３２および３４はアラーム４２と、一対の信号転送ポイント（ＳＴＰ）３８および４０を介した移動交換センターのネットワーク３６を備えたインターフェースとを含む。信号転送ポイント３８および４０は多数のホームロケーションレジスタプラットフォーム３２および３４の存在をネットワーク３６に対しトランスペアレントにするものであると認識すべきである。「トランスペアレント」なる用語は、多数のホームロケーションレジスタプラットフォーム３２または３４が存在していること、またはそのうちのどのプラットフォームがネットワークサービスリクエストメッセージに応答しているかを、ネットワーク３６が知らないということを意味している。
ネットワーク３６は通信リンク４４を介して第１信号転送ポイント３８に接続され、通信リンク４６を介して第２信号転送ポイント４０に接続されている。第１信号転送ポイント３８と第２信号ポイント４０との間には別の通信リンク４８が設けられている。マスターホームロケーションレジスタプラットフォーム３２は通信リンク５０を介して第１信号転送ポイント３８に接続され、通信リンク５２を介して第２信号転送ポイント４０に接続されている。同様に、スレーブホームロケーションレジスタプラットフォーム３４は通信リンク５４を介して第１信号転送ポイント３８に接続されており、通信リンク５６を介して第２信号転送ポイント４０に接続されている。マスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４は更にインターフェース６０および一対の通信リンク６２および６４を介してホームロケーションレジスタアドミニストレータ５８に接続されている。インターフェース６０はマスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４の双方へのアドミニストレータ５８の同時通信アクセスを容易にするものである。図２に示された通信リンクは単一リンクとして示されているが、必要に応じ多数のパラレルリンクを含むことができる。
マスターホームロケーションレジスタプラットフォーム３２にはネットワーク通信サービスリクエストメッセージを取り扱う（すなわちこれを処理し、応答する）ための基本的な役割が与えられている。本明細書で後により詳細に説明するように、システムが運用されている際にはすべてのサービスリクエストメッセージは信号転送ポイント３８および４０によりマスターホームロケーションレジスタプラットフォーム３２にルーチングされる。スレーブホームロケーションレジスタプラットフォーム３４は対応するメッセージを備えた信号転送ポイント３８または４０を使用するマスターホームロケーションレジスタプラットフォーム３２によってコピーされ、ダイナミックデータの無欠性を維持し、プラットフォームの故障時にマスタープラットフォームからの引き継ぎに必要な情報へスレーブプラットフォームがアクセスする機会を与える。
次に、図２および３を参照する。ここで、図３は図２のシステムにおいてマスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４により受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。各サービスリクエストメッセージはメッセージを取り扱うように指定されたホームロケーションレジスタプラットフォーム３２または３４を識別するダイレクトポイントコードを含む。図２のマスター／スレーブ構造では、マスタープラットフォームがネットワーク３６にサービスしない（すなわちプラットフォームに故障がある場合）と判断されない限り、マスターホームロケーションレジスタプラットフォーム３２がすべてのメッセージを取り扱うことが好ましい。従って、ステップ６６ではマスターホームロケーションレジスタプラットフォーム３２がすべてのネットワークサービスリクエストメッセージをサービスするように指定することにより、ネットワークアドミニストレータ５８がホームロケーションレジスタプラットフォーム３２および３４の構造を決定する。
ネットワーク３６からのメッセージの受信に応答して信号転送ポイント３８および４０は次に、別のルーティングパスを介したマスターホームロケーションレジスタプラットフォーム３２だけへルーチングする（ステップ６８）。例えば第１信号転送ポイント３８がリンク４４を通してメッセージを受信すると、まず通信リンク５０を通るようメッセージをルーチングする。これができない場合、第１信号転送ポイント３８は通信リンク５２を通してマスターホームロケーションレジスタプラットフォーム３２へ伝送するため、リンク４８を通して第２信号転送ポイント４０へメッセージを通過させる。リンク４８を通して受信されたメッセージを搬送するために第２信号転送ポイント４０（リンク５２またはリンク４８および５０）からマスターホームロケーションレジスタプラットフォーム３２へ同様に２つの経路が提供される。従って、マスターホームロケーションレジスタプラットフォーム３２へメッセージを搬送するのに信号転送ポイント３８および４０から冗長／別の（ｒｅｄｕｎｄａｎｔ／ａｌｔｅｒｎａｔｅ）通信経路が与えられる。このようなデータリンク冗長性により別のメッセージパスが提供される。ネットワーク３６が運用中のマスターホームロケーションレジスタプラットフォーム３２にアクセスするのを阻害するような潜在的な通信リンクの故障に関する問題を解決する。
メッセージを受信すると、マスターホームロケーションレジスタプラットフォーム３２は処理のための適当なアプリケーションにメッセージを送る（ステップ７０）。このアプリケーションはメッセージを処理し、適当なレスポンスを発生する（ステップ７２）。次にこのレスポンスはマスターホームロケーションレジスタプラットフォーム３２により信号転送ポイント３８または４０を介しネットワーク３６へ戻すように送られる（ステップ７４）。
マスターホームロケーションレジスタプラットフォーム３２は受信したメッセージをスレーブホームロケーションレジスタプラットフォーム３４にも送るべきかを更に判断する（ステップ７６）。この判断はアプリケーション内のメッセージの処理の結果、記憶されたダイナミックデータが変更されるかどうかに基づいて行われる。記憶されたダイナミックデータの変更が生じる場合、マスターホームロケーションレジスタプラットフォーム３２はメッセージをコピー（ステップ７８）し、スレーブホームロケーションレジスタプラットフォーム３４へのルーティングインストラクションに従い、信号転送ポイント３８または４０を通してコピーしたメッセージを戻す（ステップ８０）。次にスレーブホームロケーションレジスタプラットフォーム３４はメッセージを適当なアプリケーションへ送ること（ステップ８２）によりマスターレジスタプラットフォームと同じように応答し、その結果、内部に記憶されたダイナミックデータの変更と応答の発生が生じる（ステップ８３）。しかしながらこの場合、スレーブホームロケーションレジスタプラットフォーム３４はアドミニストレータ５８によってネットワークリクエストをサービスするようには指定されないので、スレーブプラットフォームによって発生された応答は無視され（ステップ８４）、ネットワーク３６へは送られない。
上記工程に従って受信されたメッセージが処理された後に双方のホームロケーションレジスタプラットフォーム３２および３４は記憶された同一のダイナミックデータを含む。その後、マスターホームロケーションレジスタプラットフォーム３２が故障した場合、スレーブホームロケーションレジスタプラットフォーム３４はネットワークサービスリクエストへの応答をトランスペアレントに引き継ぐのに必要なダイナミックデータのすべてを保有する。
次に、図２および４を参照すると、図４は、マスターホームロケーションレジスタプラットフォーム３２の故障を取り扱い、その後受信されたサービスリクエストのスレーブホームロケーションレジスタプラットフォーム３４による取り扱いを行うための処理工程を示すフローチャートである。アドミニストレータ５８または信号転送ポイント３８および４０のいずれかまたは双方により、マスターホームロケーションレジスタプラットフォーム３２の故障が検出された（ステップ８６）後、アドミニストレータはスレーブホームロケーションレジスタプラットフォーム３４がすべてのネットワークリクエストをサービスするように指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ８８）。
ネットワーク３６からのメッセージの受信に応答し、信号転送ポイント３８および４０はメッセージをスレーブホームロケーションレジスタプラットフォーム３２へ自動的かつトランスペアレントにルーチングする（ステップ９０）。これに関連し、「トランスペアレントに」なる用語は、ネットワーク３６が多数のホームロケーションレジスタプラットフォーム３２または３４が存在していること、またはそのうちのどのプラットフォームがメッセージに応答しているかについては知らないことを再び意味している。メッセージを受信するとスレーブホームロケーションレジスタプラットフォーム３４はメッセージを適当なアプリケーションへ送る（ステップ９２）。次にアプリケーションは応答を発生し（ステップ９４）、この応答は信号転送ポイント３８および４０を介してネットワーク３６へ戻されるように送られる（ステップ９６）。
マスターホームロケーションレジスタプラットフォーム３２が故障した後に信号転送ポイント３８および４０による受信されたメッセージの取り扱いに関し、第１信号転送ポイント３８がリンク４４を通してメッセージを受信した場合、このポイントはまずこのメッセージを通信リンク５４を通るようにルーチングするように試みる。これに失敗すると信号転送ポイント３８は通信リンク５６を通してスレーブホームロケーションレジスタプラットフォーム３４へ伝送するよう、リンク４８を介し第２信号転送ポイント４０へメッセージを送る。リンク４６を通して受信されたメッセージを搬送するように第２の信号転送ポイント４０からスレーブホームロケーションレジスタプラットフォーム３４へ同様に２つの経路が提供される（リンク５６またはリンク４８および５４）。従って、マスタープラットフォームの故障後にスレーブホームロケーションレジスタプラットフォーム３４へメッセージを搬送するために信号転送ポイント３８および４０から冗長／別の通信経路が提供される。このデータリンク冗長性は別のメッセージ経路を提供し、ネットワーク３６が運用中のスレーブホームロケーションレジスタプラットフォーム３４へァクセスするのを阻害する潜在的な通信リンクの故障に関する問題を解決する。
（マスタープラットフォームの故障の後であって）アドミニストレータ５８がシステムを再構成する機会を持つ前にメッセージをネットワーク３６から受信し、信号転送ポイント３８および４０によりこれらメッセージをスレーブホームロケーションレジスタプラットフォーム３４へ自動的に伝送することが可能である。この場合、スレーブプラットフォームはまだネットワークサービスリクエストを取り扱うように指定されていないので、受信の際にメッセージはスレーブホームロケーションレジスタプラットフォーム３４によって廃棄される。これら廃棄されるメッセージはネットワーク３６によって再送信しなければならない。ホームロケーションレジスタからの応答をネットワークが受信することなくメッセージに対して指定されたタイムアウトが終了した時に一般に廃棄されたメッセージの発見が通常行われる。
次に図２および５Ａを参照する。図５Ａは図２のシステムにおける故障したマスターホームロケーションレジスタプラットフォーム３２内に正確で最新の加入者データを回復するための方法の処理ステップを示すフローチャートである。マスターホームロケーションレジスタプラットフォーム３２内で更新される加入者データは、スレーブホームロケーションレジスタプラットフォーム３４によりサービスリクエストの仮の取り扱いにより影響されたダイナミックデータを基本的に含む。
まず信号転送ポイント３８および４０からのマスターホームロケーションレジスタプラットフォーム３２の接続が外される（ステップ９８）。次に、最終バックアップおよび加入者データダンプがマスターホームロケーションレジスタプラットフォーム３２に再ロードされる（ステップ１００）。次に、スレーブプラットフォームの最後の加入者データダンプをマスタープラットフォームにロードし、スレーブプラットフォームのダイナミックデータをダンプし、ダンプされたデータをマスタープラットフォームにロードすることによりスレーブホームロケーションレジスタプラットフォーム３４からマスターホームロケーションレジスタプラットフォーム３２にダイナミックデータを転送する（ステップ１０２）。次に、アドミニストレータ５８はすべてのネットワークリクエストメッセージをサービスすることにマスターホームロケーションレジスタプラットフォーム３２を再び指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ１０４）。マスターホームロケーションレジスタプラットフォーム３２が信号転送ポイント３８および４０に再接続されると回復が終了する（ステップ１０６）。好ましくはネットワークサービスリクエストのプラットフォームの取り扱いの開始前にマスターホームロケーションレジスタプラットフォーム３２は「アンリライアブル−ローマー−データ−ダイレクティブ」を伝搬し、正確な移動局２４のロケーションを獲得し、これを記憶する。プラットフォームが再び即座に故障した場合には、この時にマスターホームロケーションレジスタプラットフォーム３２からのデータダンプを行ってもよい。
図５Ｂには故障したマスターホームロケーションレジスタプラットフォーム３２の加入者データを回復するための別の方法が示されている。この方法は特にマスタープラットフォーム３２の回復が完了する前にスレーブホームロケーションレジスタプラットフォーム３４が故障した場合の取り扱い状況に適用できる。この方法によれば、故障したマスターホームロケーションレジスタプラットフォーム３２をスレーブホームロケーションレジスタプラットフォーム３４が引き継ぐと、中間期間中のネットワークサービスリクエストの処理により変更されたスレーブプラットフォーム内のすべてのダイナミックデータが新データとしてマークされる（フラグが付けられる）（ステップ１０８）。マスターホームロケーションレジスタプラットフォーム３２がオンライン状態に戻されると、マスタープラットフォームに最終バックアップおよび加入者データダンプが再ロードされる（ステップ１１０）。ダイナミックデータの回復前にスレーブプラットフォーム３４が故障した場合、マスタープラットフォーム３２はできるかぎりサービスリクエストメッセージを取り扱う（ステップ１１２）。スレーブプラットフォーム３４がオンライン状態に戻されるとスレーブプラットフォームのマークされたダイナミックデータをダンプし、マークされたデータをマスタープラットフォームにロードすることによりスレーブホームロケーションレジスタプラットフォーム３４からマスタープラットフォームレジスタプラットフォーム３２にマークされたダイナミックデータだけが転送される（ステップ１１４）。アドミニストレータ５８はマスターホームロケーションレジスタプラットフォーム３２がネットワークリクエストをサービスするように指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ１１６）。マスターホームロケーションレジスタプラットフォーム３２が信号転送ポイント３８および４０に再接続され（ステップ１１８）、ネットワークサービスリクエストの取り扱いを開始すると回復が終了する。
マスターホームロケーションレジスタプラットフォーム３２が作動中のスレーブホームロケーションレジスタプラットフォーム３４の故障は、重大な問題とはならない。その理由は、中断を生じることなくサービスリクエストメッセージの処理が続くからである。しかしながらマスターホームロケーションレジスタプラットフォーム３２はバックアップ無しに作動する。スレーブプラットフォームがオンライン状態に戻る際にマスターホームロケーションレジスタプラットフォーム３２からのスレーブホームロケーションレジスタプラットフォーム３４の加入者データの回復を取り扱うのに、図５Ａおよび５Ｂの方法も使用される。
次に図６を参照する。ここには移動交換センターが冗長ホームロケーションレジスタプラットフォーム１８”を含み、このプラットフォームが、後により詳細に説明するような負荷分担構造の第１ホームロケーションレジスタプラットフォーム３２’と第２ホームロケーションレジスタプラットフォーム３４’を含む、本発明の第２実施例のブロック図が示されている。図６では図１のシステム内に示されたものと同一または類似する部品には同じ参照番号が付けられている。ホームロケーションレジスタプラットフォーム３２’および３４’はアラーム４２を含み、一対の信号転送ポイント３８および４０を介して移動交換センターのネットワーク３６とインターフェースするようになっている。従って、信号転送ポイントがプラットフォーム３２’または３４’の指定された一方のみから常時サービスを受けている場合でも、すべての加入者は信号転送ポイント３８および４０を介して双方のプラットフォームに接続される。これに関連し、信号転送ポイント３８および４０は多数のホームロケーションレジスタプラットフォーム３２’および３４’が存在することをネットワーク３６に対しトランスペアレントな状態とする。ここで「トランスペアレント」なる用語はネットワークが多数のホームロケーションレジスタプラットフォーム３２’または３４’が存在していること、またはそのうちのどちらのプラットフォームがネットワークサービスリクエストメッセージに応答しているかを知らないことを意味している。
ネットワーク３６は通信リンク４４を介して第１信号転送ポイント（ＳＴＰ１）３８に接続され、通信リンク４６を介して第２信号転送ポイント（ＳＴＰ２）４０に接続される。第１信号転送ポイント３８と第２信号転送ポイント４０との間には別の通信リンク４８が設けられる。第１ホームロケーションレジスタプラットフォーム３２’は通信リンク５０を介して第１信号転送ポイント３８に接続され、通信リンク５２を介して第２信号転送ポイント４０に接続される。同様に、第２ホームロケーションレジスタプラットフォーム３４’は通信リンク５４を介して第１信号転送ポイント３８に接続され、通信リンク５６を介して第２信号転送ポイント４０に接続される。更に第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’はインターフェース６０および一対の通信リンク６２および６４を介してホームロケーションレジスタアドミニストレータ５８に接続されている。インターフェース６０はホームロケーションレジスタプラットフォーム３２’および３４’の双方へのアドミニストレータ５８の同時の通信アクセスを容易にするものである。一対の通信リンク１２０および１２２が第１ホームロケーションレジスタプラットフォーム３２’と第２ホームロケーションレジスタプラットフォーム３４’とを接続している。図６に示された通信リンクは単一リンクとして示されているが、この通信リンクは必要に応じて多数のリンクを含んでいてもよい。
第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’の各々には移動電話ネットワークによってサービスを受ける全加入者の一部（「自己の加入者」と一般に称される）のみのためのネットワーク通信サービスリクエストの取り扱い（すなわちそれらの処理および応答）をする役割が与えられている。これに関連し、本実施例における各ホームロケーションレジスタプラットフォームに割り当てられる自己の加入者の数を、故障したプラットフォームのオウン加入者のための処理の役割を果たすのに、プラットフォームのプロセッサが必要とされる場合の、プラットフォームプロセッサの負荷容量の約半分に限定できることに留意すべきである。このように負荷を制限することにより別のプラットフォームが故障した場合に１つのプラットフォームが過負荷となるのを防止することができる。
後により詳細に説明するように、本システムが運用されている際にはすべてのサービスリクエストはリクエストを処理するように指定された第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’の適当な一方へ、信号転送ポイント３８および４０によってルーチングされる。従って、多数のホームロケーションレジスタプラットフォームはネットワークサービスリクエストの加入者の全負荷に対する処理負荷の役割を分担する。ホームロケーションレジスタプラットフォーム３２’および３４’は更に互いに対応するメッセージをコピーし、ダイナミックデータの無欠性を維持し、プラットフォームの故障が生じた場合、別のプラットフォームから引き継ぐのに必要な情報へ各プラットフォームがアクセスする。
次に図６および７を参照する。ここで図７は、図６のシステムにおけるホームロケーションレジスタプラットフォーム３２’および３４’による受信されたサービスリクエストを取り扱うための処理工程を示すフローチャートである。各サービスリクエストメッセージはメッセージの取り扱いに割り当てられたホームロケーションレジスタプラットフォーム３２’または３４’を識別するダイレクトポイントコードを含む。図６の負荷分担構造では、指定されたプラットフォームがネットワーク３６をサービスしていない（すなわちプラットフォームの故障がある）と判断されない限り、ホームロケーションレジスタプラットフォーム３２’または３４’は自己の加入者のすべてのメッセージおよび／またはダイレクトポイントコードによって指定されたメッセージを処理する。従って、ステップ１２４ではネットワークアドミニストレータ５８は、各ホームロケーションレジスタプラットフォームがオウン加入者のネットワークサービスリクエストメッセージしかサービスしないように指定することにより、ホームロケーションレジスタプラットフォーム３２’および３４’を負荷分担構造となるように構成する。
ネットワーク３６からのメッセージの受信に応答して信号転送ポイント３８および４０はメッセージのダイレクトポイントコードによって指定されたホームロケーションレジスタプラットフォーム３２’または３４’へメッセージをルーチングする（ステップ１２６）。例えば第１ホームロケーションレジスタプラットフォーム３２’を指定するダイレクトポイントコードを有する、リンク４４を通して受信されたサービスリクエストに対しては、第１信号転送ポイント３８は、まず通信リンク５０を通してメッセージをルーチングすることを試みる。これに失敗した場合、第１信号転送ポイント３８は通信リンク５２を通して第１ホームロケーションレジスタプラットフォーム３２’へ伝送するよう、リンク４８を介して第２信号転送ポイント４０へメッセージを送る。ダイレクトポイントコードが第２ホームロケーションレジスタプラットフォーム３４’を指定した場合、メッセージはまずリンク５４を通るようにルーチングされる。これに失敗した場合、次にリンク４８および５６を通るようにルーチングされる。リンク４６を通して受信されたメッセージに対しては、その後、同様なルーチング方法がとられる。図示するように、ネットワーク３６から受信されたメッセージを帆走するのに、信号転送ポイント３８および４０の各々から各ホームロケーションレジスタプラットフォーム３２’または３４’へそれぞれ２つの別の経路が設けられている。このようなデータリンクの冗長性により別個のデータ経路が提供され、このような対策がとられない場合、作動中のホームロケーションレジスタプラットフォーム３２’または３４’へのアクセスを不能にするような潜在的な通信リンクの故障に関する問題が解決される。
指定されたホームロケーションレジスタプラットフォーム３２’または３４’はメッセージを受信すると、このメッセージを適当なアプリケーションへ送る（ステップ１２８）。アプリケーションはメッセージを処理し、適当な応答を発生する（ステップ１３０）。この応答はホームロケーションレジスタプラットフォームにより信号転送ポイント３８および４０を介してネットワーク３６へ戻される（ステップ１３２）。
指定されたホームロケーションレジスタプラットフォーム３２’または３４’は受信したメッセージを他のホームロケーションレジスタプラットフォームにも送るべきかどうかを更に判断する（ステップ１３４）。この判断はアプリケーションにおけるメッセージの処理の結果、記憶されたダイナミックデータに変更が生じるかどうかに基づいて行われる。記憶されたダイナミックデータにおける変更が生じる場合、指定されたホームロケーションレジスタプラットフォーム３２’または３４’はメッセージをコピーし（ステップ１３６）、通信リンク１２０または１２２を通して他のホームロケーションレジスタプラットフォームにコピーされたメッセージを送る（ステップ１３８）。次に他のホームロケーションレジスタプラットフォーム３２’または３４’はアプリケーション内でメッセージを処理し（ステップ１４０）、ダイナミックデータを更新し（ステップ１４２）、通信リンク１２０または１２２を通して指定されたホームロケーションレジスタプラットフォームに送られるアクノーリッジメントによりメッセージの受信を確認する（ステップ１４４）ことにより、メッセージに応答する。
上記ステップに従い、受信したメッセージを処理した後に、ホームロケーションレジスタプラットフォーム３２’および３４’の双方は同じ記憶されたダイナミックデータを含む。その後、ホームロケーションレジスタプラットフォームの一方が故障した場合、他方のプラットフォームは故障したプラットフォームのためのダイレクトポイントコードによって指定されたネットワークサービスリクエストへの応答をトランスペアレントに引き継ぐのに必要なダイナミックデータのすべてを処理する。
次に、図６および８を参照する。ここで、図８はホームロケーションレジスタプラットフォーム３２’または３４’の一方の故障を処理し、その後、受信されたサービスリクエストの他方のホームロケーションレジスタプラットフォームによる処理のための処理ステップを示すフローチャートである。アドミニストレータ５８および信号転送ポイント３８および４０の一方または双方により、ホームロケーションレジスタプラットフォーム３２’または３４’の一方の故障が検出（ステップ１４６）された後に、故障したプラットフォームのためのダイレクトポイントコードによって指定された入進するすべてのサービスリクエストメッセージは、信号転送ポイント３８および４０によりサービスのための他の（バックアップ）プラットフォームへ自動的かつトランスペアレントにルーチングし直される（ステップ１４８）。これに関連し、「トランスペアレント」なる用語は再びネットワーク３６が多数のホームロケーションレジスタプラットフォーム３２’および３４’が存在していること、またはいずれのプラットフォームがメッセージに応答しているかを知らないことを意味している。他方のホームロケーションレジスタプラットフォーム３２’または３４’はメッセージを受信すると、このメッセージを適当なアプリケーションへ送る（ステップ１５０）。アプリケーションは次に応答を発生し（ステップ１５２）、この応答は信号転送ポイント３８および４０を介してネットワーク３６へ送り戻される（ステップ１５４）。
プラットフォームの故障後の信号転送ポイント３８および４０による受信されたメッセージの取り扱いに関し、例えば第１信号転送ポイント３８が故障した第１ホームロケーションレジスタプラットフォーム３２’に対して指定されたメッセージを受信した場合、第１信号転送ポイント３８は、まず通信リンク５４を通してメッセージをルーチングしようと試みる。これに失敗すると、第１信号転送ポイント３８は通信リンク５６を通して第２ホームロケーションレジスタプラットフォーム３４’へ伝送するよう、リンク４８を介して第２信号転送ポイント４０へメッセージを送る。第２信号転送ポイント４０によって受信されたメッセージおよび／または第２ホームロケーションレジスタプラットフォーム３４’に対して指定されたメッセージに対し、同様なルーチング方法が続けられる。利用可能なデータリンクにおけるこのような冗長性により、別のデータ経路が提供され、冗長性が無い場合、作動中のホームロケーションレジスタプラットフォーム３２’または３４’へのアクセスを不可能とするような潜在的な通信リンクの故障に関する問題が解決される。
プラットフォームが故障する前にネットワーク３６によりメッセージを送るが指定されたプラットフォームが故障するまでにこれらメッセージを受信または取り扱うことができないことがある。この場合、メッセージはプラットフォームにより処理されず、応答も発生しない。応答を得るにはこれらメッセージはネットワーク３６によって再送信しなければならない。ホームロケーションレジスタからの応答をネットワークが受信することなくメッセージの指定されたタイムアウトが終了した際に、一般に再送信の必要があるかどうかの判断がされる。
次に図６および９Ａを参照する。ここで図９Ａは、図６のシステムにおける故障したホームロケーションレジスタプラットフォーム３２’または３４’における、正確で、かつ最新の加入者データを回復するための方法の処理ステップを示すフローチャートである。この方法は、バックアップとして作動する間の他方のホームロケーションレジスタプラットフォームによるサービスリクエストの中間処理により影響されるダイナミックデータに関するプラットフォームを送信するため、ホームロケーションレジスタプラットフォーム３２’または３４’の一方が故障してから比較的短い期間の後に有利に使用される。
まず、故障したホームロケーションレジスタプラットフォーム３２’または３４’は信号転送ポイント３８および４０から、更に他方のプラットフォームから切り離される（ステップ１５６）。次に、この故障したホームロケーションレジスタプラットフォーム３２’または３４’には最後のバックアップが再ロードされる（ステップ１５８）。次に、ホームロケーションレジスタプラットフォーム３２’と３４’とは互いに接続される（ステップ１６０）。次にバックアップ用ホームロケーションレジスタプラットフォームは最終のデータバックアップの開始後、変更されたすべての加入者データを故障したホームロケーションレジスタプラットフォームへ送信する。この場合、故障したプラットフォームの自己の加入者のデータに優先権が与えられる（ステップ１６２）。先に故障し、更新されたホームロケーションレジスタプラットフォーム３２’または３４’が信号転送ポイント３８および４０に再接続されると回復が終了する（ステップ１６４）。プラットフォームが再び即座に故障した場合には、この時にネットワークサービスリクエストの取り扱い開始前にホームロケーションレジスタプラットフォームからのデータダンプを行うことができる。
図９Ｂには、故障したホームロケーションレジスタプラットフォーム３２’または３４’の加入者データを回復するための別の方法が示されている。この方法は、ホームロケーションレジスタプラットフォーム３２’または３４’の一方が比較的長時間故障した後に使用すると有利である。その理由は、かかる更新を行うにはバックアップとして作動する他方のホームロケーションレジスタプラットフォームのデータベースのほとんどすべてを一般に転送するからである。故障したホームロケーションレジスタプラットフォーム３２’または３４’は、まず信号転送ポイント３８および４０から、かつ他方のプラットフォームから切り離される（ステップ１６６）。次に、故障したホームロケーションレジスタプラットフォーム３２’または３４’には、その最終バックアップが再ロードされる（ステップ１６８）。次に、故障したホームロケーションレジスタプラットフォームに他方のホームロケーションレジスタプラットフォームの加入者データがダンプされ、ロードされる（ステップ１７０）。ホームロケーションレジスタプラットフォーム３２’と３４’とは互いに接続され（ステップ１７２）、他方のホームロケーションレジスタプラットフォームが最終バックアップの開始後に変更されたすべてのダイナミックデータを故障したホームロケーションレジスタプラットフォームへ送信し、この場合、故障したプラットフォームの自己の加入者のデータに優先権が与えられる（ステップ１７４）。先に故障し、更新されたホームロケーションレジスタプラットフォーム３２’または３４’が信号転送ポイント３８および４０に再接続されると、回復が終了する（ステップ１７６）。サービスリクエスメッセージの取り扱いに先立ち、先に故障し、現在は回復したホームロケーションレジスタプラットフォームからのデータダンプを行うこともできる。
次に、図１０を参照する。ここには負荷分担関係となるように構成された３つ以上の冗長ホームロケーションレジスタプラットフォーム３２’、３３’および３４’をリンクするための、本発明の第２実施例の別の構成のブロック図が示されている。この図１０では、図６のシステムに示されたものと同一または同様な部品には同じ参照番号が付けられている。負荷分担構造となっている多数のホームロケーションレジスタプラットフォームでは、全体の加入者の負荷の一部（この構成における約３分の１）しか処理しないように、各プラットフォームを割り当てることができる。追加される各ホームロケーションレジスタプラットフォームには付加的な信号転送ポイント３９’も含まれる。このように増設されたホームロケーションレジスタプラットフォームの間の通信を容易とするために、リンク１２０’、１２１’および１２２’を含む円形の通信リンクが提供される。ホームロケーションプラットフォームの作動および回復は、図６のシステムのための図７〜９Ｂに示されたホームロケーションプラットフォームと同じように行われる。
本発明の方法および装置の好ましい実施例を添付図面に示し、これまでの詳細な説明に説明したが、本発明はこれら実施例のみに限定されるものではなく、次の請求の範囲に記載の本発明の要旨から逸脱することなく、ハードウェアおよびデータの双方の冗長性を必要とするビジターロケーションレジスタまたは他のタイプのデータベースシステムと共に使用することを含む、多数の再配置、変更および置換が可能であることが理解できよう。特に、本発明の方法および装置はハードウェアおよびデータの双方に関する冗長性が必要とされるか、または有効である、データ通信システムおよび／またはデータベースシステムにおけるノードに適用可能である。従って、冗長なホームロケーションレジスタに関連させた本発明のこれまでの説明は、本発明の範囲を限定するものではなく、本発明を説明するものである。
発明の技術分野
本発明は通信システムに関し、より詳細には通信システムにおける個々のノードに対しハードウェアおよびデータ冗長性の双方を提供するためのアーキテクチャに関する。本発明はデータベース、例えば移動電話ネットワークのホームまたはビジターロケーションレジスタを利用するシステムノードのためのかかる冗長性を提供することに特に利用できる。
関連技術の説明
移動電話ネットワークの移動交換センターは複数のデータベースを含み、これらデータベースは移動電話ネットワーク内での電話接続の確立中に交換センターから質問を受ける。これらデータベースはホームロケーションレジスタおよびビジターロケーションレジスタを含み、これらレジスタは加入者に関連したスタティック（すなわち変化しない）データおよびダイナミック（すなわち変化する）データの双方をデータベースフォーマットで記憶するためのプラットフォームを含む。
レジスタに記憶されるスタティックデータは、例えば移動交換センターと相互接続された交換機を協働させるための識別子のリストと、各加入者によって使用できる（話中転送のような）サービスの識別と、（固定されたＣ番号のような）かかるサービスに関連したパラメータとを含む。データの上記例のみならず他のタイプのスタティックデータもデータベースに入力され、これらデータはレジスタのアドミニストレータにしかこれを変更できない。他方、ダイナミックデータは、例えば（可変Ｃ番号のような）加入者が定義したサービスデータと、（移動交換センターおよび基地局の双方に対する）移動局ロケーションデータと、（移動局オン／オフステータスのような）移動局アクティビティデータとを含む。このデータを他のタイプのダイナミックデータと同じようにデータベースに入力し、これらデータは常時、加入者によって、移動局によって、またはネットワークによって、加入者にトランスペアレントな態様で変更できる。
ホームロケーションレジスタは移動電話ネットワーク内での電話の接続を確立するのに必要なデータを含むので、ホームロケーションレジスタのためのプラットフォームの故障は電話の発呼を受信したり、または発信する能力をかなりの数の加入者から奪うことになる。プラットフォームだけでなく、そこに記憶されているスタティックデータおよびダイナミックデータも電話の接続の確立に重要であることを思い出すことも、更に重要である。従って、ハードウェアの見地のみならず、記憶されているスタティックデータおよびダイナミックデータの無欠性を維持することにも関連してホームロケーションレジスタプラットフォームの故障を処理できるシステムが望まれている。かかるシステムは冗長性が必要とされるデータベースシステムまたは通信システムノードに用途がある。
発明の概要
個々のノードによる冗長なデータ取り扱い通信のための方法と共に、データ通信システムにおける個々のノードへハードウェアおよびデータ冗長性を与えるためのアーキテクチャが提供される。この方法は更にノードの故障後に正確なデータを回復することも配慮するものである。このアーキテクチャは構造を変えながら多数のプラットフォームを提供しつつ、データ通信の各ノードにおいて多数のプラットフォームを利用するものである。
本発明の一実施例によれば、多数のプラットフォームがマスターとスレーブの関係になるように対にされ、ネットワークに接続される。多数のプラットフォームの存在がネットワークにとってトランスペアレントとなるようにする信号ルータを介し、双方のプラットフォームに対し通信できるよう、すべてのネットワークユーザーが冗長に接続される。マスタープラットフォームにはデータ通信を取り扱うための（すなわちデータ通信を処理し、応答するための）基本的な役割が与えられる。従って、すべてのデータ通信信号は信号ルータによりマスタープラットフォームにルーチング（経路指定）される。スレーブプラットフォームは処理時にマスタープラットフォーム内に記憶されているデータの変更を生じさせるような通信信号と共に、マスタープラットフォームによりこのマスタープラットフォームにコピーされる。かかるスレーブプラットフォームへの通信信号のコピーにより、データ通信システム全体のデータの無欠性（インティグリィティ）が維持され、故障の場合にマスタープラットフォームからの処理作業を引き継ぐのに必要な情報がスレーブプラットフォームに与えられる。マスタープラットフォームの故障が発生し、この故障が検出されると、信号ルータは取り扱いのためにマスタープラットフォームへではなく、スレーブプラットフォームへデータ通信信号を自動的かつトランスペアレントにルーチングする。
本発明の別の実施例では、含まれる多数のプラットフォームのうちの各１つに全ユーザーのうちの一部のみに対する役割しか割り当てられない。従って、多数のプラットフォームは全ユーザー負荷に対する処理負荷の役割を分担する。しかしながらこれと同時に、すべてのネットワークユーザーは信号ルータを介してプラットフォームの各々への通信のために冗長的に接続される。処理時にプラットフォームに記憶されていたデータの変更を生じさせるようなデータ通信信号はプラットフォーム間でコピーされる。プラットフォーム間でのかかる通信信号のコピーによりデータ通信システムでのデータの無欠性が維持され、プラットフォームに故障が生じた場合に別のプラットフォームからの処理作業を引き継ぐのに必要な情報へ各プラットフォームがアクセスする機会が与えられる。プラットフォームに故障が発生し、これが検出されると、信号ルータはその代わりに取り扱いのために残りの機能的プラットフォームのうちの１つへデータ通信信号を自動的かつトランスペアレントにルーチングする。
本発明のシステムおよび方法は、移動電話システムの移動交換センターに維持されたロケーションレジスタ（ホームまたはビジター）を含むデータベースに対しハードウェアおよびデータの冗長性を提供する際に特に有効である。以下、この特定のアプリケーションに関連して本発明の好ましい実施例について説明する。しかしながら、本発明のシステムおよび方法はハードウェアおよびデータの双方に関する冗長性が必要とされるか、または有効なデータ通信システムにおけるノードおよび／またはデータベースシステムに適用可能であるので、本明細書に記載した冗長なホームロケーションレジスタに関連させた本発明の説明は、本発明の範囲を限定するものではなく、むしろ本発明を説明するためのものであることが理解できよう。
【図面の簡単な説明】
添付図面に関連させて次の詳細な説明を参照すれば、本発明の方法および装置についてより完全に理解できよう。
図１は、ホームロケーションレジスタを含む従来の移動交換センターのブロック図である。
図２は、マスター／スレーブ構造で提供される冗長性ホームロケーションレジスタプラットフォームを含む本発明の第１実施例のブロック図である。
図３は、図２のシステムにおいて、受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図４は、図２のシステムにおいて、マスターホームロケーションレジスタプラットフォームの故障およびその後受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図５Ａおよび５Ｂは、図２のシステムにおける、故障したホームロケーションレジスタプラットフォームにおける加入者データを回復するための２つの方法の処理工程を示すフローチャートである。
図６は、負荷分担構造で提供される冗長ホームロケーションレジスタプラットフォームを含む、本発明の第２実施例のブロック図である。
図７は、図６のシステムにおいて、受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図８は、図６のシステムにおいて、ホームロケーションレジスタプラットフォームの故障およびその後受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。
図９Ａおよび９Ｂは、図６のシステムにおける、故障したホームロケーションレジスタプラットフォームにおける加入者データを回復するための２つの方法の処理工程を示すフローチャートである。
図１０は、３つ以上の冗長ホームロケーションレジスタプラットフォームをリンクするための負荷分担構造のブロック図である。
実施例の詳細な説明
次に図１を参照する。ここには交換機１２と移動電話サブシステム１４とを備えた従来の移動交換センター１０のブロック図が示されている。移動電話サブシステム１４は移動電話システムの加入者に関連したスタティック（すなわち変化しない）データと、ダイナミック（すなわち変化する）データの双方を記憶するための複数のデータベース１６を含む。これらデータベースはホームロケーションレジスタ１８とビジターロケーションレジスタ２０を備え、これらレジスタは移動電話ネットワーク内および基地局２６を介した加入者の移動局２４への電話接続の確立中に、センターによる質問を受ける。交換機１２は更に公衆交換電話ネットワーク２２に接続されており、ホームロケーションレジスタ１８およびビジターロケーションレジスタ２０は電話システムのコンポーネントからのサービスリクエストメッセージも処理する。サービスリクエストメッセージに一般に応答する例としては、登録−通知、登録−キャンセルおよびサービス−プロフィル−リクエストが挙げられる。
データベース１６に記憶されるスタティックデータとしては、例えば移動交換センター１０と相互接続される協働する交換機のための識別子のリスト、各加入者によって使用できる（話中転送のような）サービスの識別および（固定されたＣ番号のような）かかるサービスに関連したパラメータがある。このデータのみならず当業者に知られている他のタイプのスタティックデータもデータベース１６に入力され、これらデータは移動交換センター１０内に設けられているデータベースアドミニストレータ２８によってしかこれを変更できない。他方、ダイナミックデータとしては、例えば（可変Ｃ番号のような）加入者が定義したサービスデータと、（移動交換センター１０および基地局２６の双方に対する）移動局２４ロケーションデータと、（移動局オン／オフステータスのような）移動局アクティビティデータとがある。このデータのみならず当業者に知られている他のタイプのダイナミックデータもデータベース１６に入力され、これらデータは常時加入者によって、移動局２４によって、またはネットワークによって、加入者にトランスペアレントな（すなわち加入者の知識または参加のためのアクションを必要としないで）態様で変更できる。
移動電話サブシステム１４は認証センター３０を更に含む。この認証センターは加入者が別の加入者のアイデンティティーを誤認するのを防止する認証パラメータおよび必要なときに送信される情報を暗号化するための暗号化パラメータを提供する。従来の移動交換センター１０またはそのコンポーネント部分の機能的動作および構成を更に詳細に説明することは不要であると考える。その理由は、かかる情報は当業者には周知であるからである。
次に、図２を参照する。この図には移動交換センターが冗長ホームロケーションレジスタ（ＨＬＲ）プラットフォーム１８’を含み、このプラットフォームがマスターホームロケーションプラットフォーム３２とスレーブホームロケーションプラットフォーム３４とを含む、本発明の第１実施例のブロック図が示されている。これらホームロケーションレジスタプラットフォーム３２および３４はアラーム４２と、一対の信号転送ポイント（ＳＴＰ）３８および４０を介した移動交換センターのネットワーク３６を備えたインターフェースとを含む。信号転送ポイント３８および４０は多数のホームロケーションレジスタプラットフォーム３２および３４の存在をネットワーク３６に対しトランスペアレントにするものであると認識すべきである。「トランスペアレント」なる用語は、多数のホームロケーションレジスタプラットフォーム３２または３４が存在していること、またはそのうちのどのプラットフォームがネットワークサービスリクエストメッセージに応答しているかを、ネットワーク３６が知らないということを意味している。
ネットワーク３６は通信リンク４４を介して第１信号転送ポイント３８に接続され、通信リンク４６を介して第２信号転送ポイント４０に接続されている。第１信号転送ポイント３８と第２信号ポイント４０との間には別の通信リンク４８が設けられている。マスターホームロケーションレジスタプラットフォーム３２は通信リンク５０を介して第１信号転送ポイント３８に接続され、通信リンク５２を介して第２信号転送ポイント４０に接続されている。同様に、スレーブホームロケーションレジスタプラットフォーム３４は通信リンク５４を介して第１信号転送ポイント３８に接続されており、通信リンク５６を介して第２信号転送ポイント４０に接続されている。マスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４は更にインターフェース６０および一対の通信リンク６２および６４を介してホームロケーションレジスタアドミニストレータ５８に接続されている。インターフェース６０はマスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４の双方へのアドミニストレータ５８の同時通信アクセスを容易にするものである。図２に示された通信リンクは単一リンクとして示されているが、必要に応じ多数のパラレルリンクを含むことができる。
マスターホームロケーションレジスタプラットフォーム３２にはネットワーク通信サービスリクエストメッセージを取り扱う（すなわちこれを処理し、応答する）ための基本的な役割が与えられている。本明細書で後により詳細に説明するように、システムが運用されている際にはすべてのサービスリクエストメッセージは信号転送ポイント３８および４０によりマスターホームロケーションレジスタプラットフォーム３２にルーチングされる。スレーブホームロケーションレジスタプラットフォーム３４は対応するメッセージを備えた信号転送ポイント３８または４０を使用するマスターホームロケーションレジスタプラットフォーム３２によってコピーされ、ダイナミックデータの無欠性を維持し、プラットフォームの故障時にマスタープラットフォームからの引き継ぎに必要な情報へスレーブプラットフォームがアクセスする機会を与える。
次に、図２および３を参照する。ここで、図３は図２のシステムにおいてマスターホームロケーションレジスタプラットフォーム３２およびスレーブホームロケーションレジスタプラットフォーム３４により受信したサービスリクエストメッセージを取り扱うための処理工程を示すフローチャートである。各サービスリクエストメッセージはメッセージを取り扱うように指定されたホームロケーションレジスタプラットフォーム３２または３４を識別するダイレクトポイントコードを含む。図２のマスター／スレーブ構造では、マスタープラットフォームがネットワーク３６にサービスしない（すなわちプラットフォームに故障がある場合）と判断されない限り、マスターホームロケーションレジスタプラットフォーム３２がすべてのメッセージを取り扱うことが好ましい。従って、ステップ６６ではマスターホームロケーションレジスタプラットフォーム３２がすべてのネットワークサービスリクエストメッセージをサービスするように指定することにより、ネットワークアドミニストレータ５８がホームロケーションレジスタプラットフォーム３２および３４の構造を決定する。
ネットワーク３６からのメッセージの受信に応答して信号転送ポイント３８および４０は次に、別のルーティングパスを介したマスターホームロケーションレジスタプラットフォーム３２だけへルーチングする（ステップ６８）。例えば第１信号転送ポイント３８がリンク４４を通してメッセージを受信すると、まず通信リンク５０を通るようメッセージをルーチングする。これができない場合、第１信号転送ポイント３８は通信リンク５２を通してマスターホームロケーションレジスタプラットフォーム３２へ伝送するため、リンク４８を通して第２信号転送ポイント４０へメッセージを通過させる。リンク４８を通して受信されたメッセージを搬送するために第２信号転送ポイント４０（リンク５２またはリンク４８および５０）からマスターホームロケーションレジスタプラットフォーム３２へ同様に２つの経路が提供される。従って、マスターホームロケーションレジスタプラットフォーム３２へメッセージを搬送するのに信号転送ポイント３８および４０から冗長／別の（ｒｅｄｕｎｄａｎｔ／ａｌｔｅｒｎａｔｅ）通信経路が与えられる。このようなデータリンク冗長性により別のメッセージパスが提供される。ネットワーク３６が運用中のマスターホームロケーションレジスタプラットフォーム３２にアクセスするのを阻害するような潜在的な通信リンクの故障に関する問題を解決する。
メッセージを受信すると、マスターホームロケーションレジスタプラットフォーム３２は処理のための適当なアプリケーションにメッセージを送る（ステップ７０）。このアプリケーションはメッセージを処理し、適当なレスポンスを発生する（ステップ７２）。次にこのレスポンスはマスターホームロケーションレジスタプラットフォーム３２により信号転送ポイント３８または４０を介しネットワーク３６へ戻すように送られる（ステップ７４）。
マスターホームロケーションレジスタプラットフォーム３２は受信したメッセージをスレーブホームロケーションレジスタプラットフォーム３４にも送るべきかを更に判断する（ステップ７６）。この判断はアプリケーション内のメッセージの処理の結果、記憶されたダイナミックデータが変更されるかどうかに基づいて行われる。記憶されたダイナミックデータの変更が生じる場合、マスターホームロケーションレジスタプラットフォーム３２はメッセージをコピー（ステップ７８）し、スレーブホームロケーションレジスタプラットフォーム３４へのルーティングインストラクションに従い、信号転送ポイント３８または４０を通してコピーしたメッセージを戻す（ステップ８０）。次にスレーブホームロケーションレジスタプラットフォーム３４はメッセージを適当なアプリケーションへ送ること（ステップ８２）によりマスターレジスタプラットフォームと同じように応答し、その結果、内部に記憶されたダイナミックデータの変更と応答の発生が生じる（ステップ８３）。しかしながらこの場合、スレーブホームロケーションレジスタプラットフォーム３４はアドミニストレータ５８によってネットワークリクエストをサービスするようには指定されないので、スレーブプラットフォームによって発生された応答は無視され（ステップ８４）、ネットワーク３６へは送られない。
上記工程に従って受信されたメッセージが処理された後に双方のホームロケーションレジスタプラットフォーム３２および３４は記憶された同一のダイナミックデータを含む。その後、マスターホームロケーションレジスタプラットフォーム３２が故障した場合、スレーブホームロケーションレジスタプラットフォーム３４はネットワークサービスリクエストへの応答をトランスペアレントに引き継ぐのに必要なダイナミックデータのすべてを保有する。
次に、図２および４を参照すると、図４は、マスターホームロケーションレジスタプラットフォーム３２の故障を取り扱い、その後受信されたサービスリクエストのスレーブホームロケーションレジスタプラットフォーム３４による取り扱いを行うための処理工程を示すフローチャートである。アドミニストレータ５８または信号転送ポイント３８および４０のいずれかまたは双方により、マスターホームロケーションレジスタプラットフォーム３２の故障が検出された（ステップ８６）後、アドミニストレータはスレーブホームロケーションレジスタプラットフォーム３４がすべてのネットワークリクエストをサービスするように指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ８８）。
ネットワーク３６からのメッセージの受信に応答し、信号転送ポイント３８および４０はメッセージをスレーブホームロケーションレジスタプラットフォーム３２へ自動的かつトランスペアレントにルーチングする（ステップ９０）。これに関連し、「トランスペアレントに」なる用語は、ネットワーク３６が多数のホームロケーションレジスタプラットフォーム３２または３４が存在していること、またはそのうちのどのプラットフォームがメッセージに応答しているかについては知らないことを再び意味している。メッセージを受信するとスレーブホームロケーションレジスタプラットフォーム３４はメッセージを適当なアプリケーションへ送る（ステップ９２）。次にアプリケーションは応答を発生し（ステップ９４）、この応答は信号転送ポイント３８および４０を介してネットワーク３６へ戻されるように送られる（ステップ９６）。
マスターホームロケーションレジスタプラットフォーム３２が故障した後に信号転送ポイント３８および４０による受信されたメッセージの取り扱いに関し、第１信号転送ポイント３８がリンク４４を通してメッセージを受信した場合、このポイントはまずこのメッセージを通信リンク５４を通るようにルーチングするように試みる。これに失敗すると信号転送ポイント３８は通信リンク５６を通してスレーブホームロケーションレジスタプラットフォーム３４へ伝送するよう、リンク４８を介し第２信号転送ポイント４０へメッセージを送る。リンク４６を通して受信されたメッセージを搬送するように第２の信号転送ポイント４０からスレーブホームロケーションレジスタプラットフォーム３４へ同様に２つの経路が提供される（リンク５６またはリンク４８および５４）。従って、マスタープラットフォームの故障後にスレーブホームロケーションレジスタプラットフォーム３４へメッセージを搬送するために信号転送ポイント３８および４０から冗長／別の通信経路が提供される。このデータリンク冗長性は別のメッセージ経路を提供し、ネットワーク３６が運用中のスレーブホームロケーションレジスタプラットフォーム３４へァクセスするのを阻害する潜在的な通信リンクの故障に関する問題を解決する。
（マスタープラットフォームの故障の後であって）アドミニストレータ５８がシステムを再構成する機会を持つ前にメッセージをネットワーク３６から受信し、信号転送ポイント３８および４０によりこれらメッセージをスレーブホームロケーションレジスタプラットフォーム３４へ自動的に伝送することが可能である。この場合、スレーブプラットフォームはまだネットワークサービスリクエストを取り扱うように指定されていないので、受信の際にメッセージはスレーブホームロケーションレジスタプラットフォーム３４によって廃棄される。これら廃棄されるメッセージはネットワーク３６によって再送信しなければならない。ホームロケーションレジスタからの応答をネットワークが受信することなくメッセージに対して指定されたタイムアウトが終了した時に一般に廃棄されたメッセージの発見が通常行われる。
次に図２および５Ａを参照する。図５Ａは図２のシステムにおける故障したマスターホームロケーションレジスタプラットフォーム３２内に正確で最新の加入者データを回復するための方法の処理ステップを示すフローチャートである。マスターホームロケーションレジスタプラットフォーム３２内で更新される加入者データは、スレーブホームロケーションレジスタプラットフォーム３４によりサービスリクエストの仮の取り扱いにより影響されたダイナミックデータを基本的に含む。
まず信号転送ポイント３８および４０からのマスターホームロケーションレジスタプラットフォーム３２の接続が外される（ステップ９８）。次に、最終バックアップおよび加入者データダンプがマスターホームロケーションレジスタプラットフォーム３２に再ロードされる（ステップ１００）。次に、スレーブプラットフォームの最後の加入者データダンプをマスタープラットフォームにロードし、スレーブプラットフォームのダイナミックデータをダンプし、ダンプされたデータをマスタープラットフォームにロードすることによりスレーブホームロケーションレジスタプラットフォーム３４からマスターホームロケーションレジスタプラットフォーム３２にダイナミックデータを転送する（ステップ１０２）。次に、アドミニストレータ５８はすべてのネットワークリクエストメッセージをサービスすることにマスターホームロケーションレジスタプラットフォーム３２を再び指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ１０４）。マスターホームロケーションレジスタプラットフォーム３２が信号転送ポイント３８および４０に再接続されると回復が終了する（ステップ１０６）。好ましくはネットワークサービスリクエストのプラットフォームの取り扱いの開始前にマスターホームロケーションレジスタプラットフォーム３２は「アンリライアブル−ローマー−データ−ダイレクティブ」を伝搬し、正確な移動局２４のロケーションを獲得し、これを記憶する。プラットフォームが再び即座に故障した場合には、この時にマスターホームロケーションレジスタプラットフォーム３２からのデータダンプを行ってもよい。
図５Ｂには故障したマスターホームロケーションレジスタプラットフォーム３２の加入者データを回復するための別の方法が示されている。この方法は特にマスタープラットフォーム３２の回復が完了する前にスレーブホームロケーションレジスタプラットフォーム３４が故障した場合の取り扱い状況に適用できる。この方法によれば、故障したマスターホームロケーションレジスタプラットフォーム３２をスレーブホームロケーションレジスタプラットフォーム３４が引き継ぐと、中間期間中のネットワークサービスリクエストの処理により変更されたスレーブプラットフォーム内のすべてのダイナミックデータが新データとしてマークされる（フラグが付けられる）（ステップ１０８）。マスターホームロケーションレジスタプラットフォーム３２がオンライン状態に戻されると、マスタープラットフォームに最終バックアップおよび加入者データダンプが再ロードされる（ステップ１１０）。ダイナミックデータの回復前にスレーブプラットフォーム３４が故障した場合、マスタープラットフォーム３２はできるかぎりサービスリクエストメッセージを取り扱う（ステップ１１２）。スレーブプラットフォーム３４がオンライン状態に戻されるとスレーブプラットフォームのマークされたダイナミックデータをダンプし、マークされたデータをマスタープラットフォームにロードすることによりスレーブホームロケーションレジスタプラットフォーム３４からマスタープラットフォームレジスタプラットフォーム３２にマークされたダイナミックデータだけが転送される（ステップ１１４）。アドミニストレータ５８はマスターホームロケーションレジスタプラットフォーム３２がネットワークリクエストをサービスするように指定することにより、ホームロケーションレジスタプラットフォーム３２および３４を再構成する（ステップ１１６）。マスターホームロケーションレジスタプラットフォーム３２が信号転送ポイント３８および４０に再接続され（ステップ１１８）、ネットワークサービスリクエストの取り扱いを開始すると回復が終了する。
マスターホームロケーションレジスタプラットフォーム３２が作動中のスレーブホームロケーションレジスタプラットフォーム３４の故障は、重大な問題とはならない。その理由は、中断を生じることなくサービスリクエストメッセージの処理が続くからである。しかしながらマスターホームロケーションレジスタプラットフォーム３２はバックアップ無しに作動する。スレーブプラットフォームがオンライン状態に戻る際にマスターホームロケーションレジスタプラットフォーム３２からのスレーブホームロケーションレジスタプラットフォーム３４の加入者データの回復を取り扱うのに、図５Ａおよび５Ｂの方法も使用される。
次に図６を参照する。ここには移動交換センターが冗長ホームロケーションレジスタプラットフォーム１８”を含み、このプラットフォームが、後により詳細に説明するような負荷分担構造の第１ホームロケーションレジスタプラットフォーム３２’と第２ホームロケーションレジスタプラットフォーム３４’を含む、本発明の第２実施例のブロック図が示されている。図６では図１のシステム内に示されたものと同一または類似する部品には同じ参照番号が付けられている。ホームロケーションレジスタプラットフォーム３２’および３４’はアラーム４２を含み、一対の信号転送ポイント３８および４０を介して移動交換センターのネットワーク３６とインターフェースするようになっている。従って、信号転送ポイントがプラットフォーム３２’または３４’の指定された一方のみから常時サービスを受けている場合でも、すべての加入者は信号転送ポイント３８および４０を介して双方のプラットフォームに接続される。これに関連し、信号転送ポイント３８および４０は多数のホームロケーションレジスタプラットフォーム３２’および３４’が存在することをネットワーク３６に対しトランスペアレントな状態とする。ここで「トランスペアレント」なる用語はネットワークが多数のホームロケーションレジスタプラットフォーム３２’または３４’が存在していること、またはそのうちのどちらのプラットフォームがネットワークサービスリクエストメッセージに応答しているかを知らないことを意味している。
ネットワーク３６は通信リンク４４を介して第１信号転送ポイント（ＳＴＰ１）３８に接続され、通信リンク４６を介して第２信号転送ポイント（ＳＴＰ２）４０に接続される。第１信号転送ポイント３８と第２信号転送ポイント４０との間には別の通信リンク４８が設けられる。第１ホームロケーションレジスタプラットフォーム３２’は通信リンク５０を介して第１信号転送ポイント３８に接続され、通信リンク５２を介して第２信号転送ポイント４０に接続される。同様に、第２ホームロケーションレジスタプラットフォーム３４’は通信リンク５４を介して第１信号転送ポイント３８に接続され、通信リンク５６を介して第２信号転送ポイント４０に接続される。更に第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’はインターフェース６０および一対の通信リンク６２および６４を介してホームロケーションレジスタアドミニストレータ５８に接続されている。インターフェース６０はホームロケーションレジスタプラットフォーム３２’および３４’の双方へのアドミニストレータ５８の同時の通信アクセスを容易にするものである。一対の通信リンク１２０および１２２が第１ホームロケーションレジスタプラットフォーム３２’と第２ホームロケーションレジスタプラットフォーム３４’とを接続している。図６に示された通信リンクは単一リンクとして示されているが、この通信リンクは必要に応じて多数のリンクを含んでいてもよい。
第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’の各々には移動電話ネットワークによってサービスを受ける全加入者の一部（「自己の加入者」と一般に称される）のみのためのネットワーク通信サービスリクエストの取り扱い（すなわちそれらの処理および応答）をする役割が与えられている。これに関連し、本実施例における各ホームロケーションレジスタプラットフォームに割り当てられる自己の加入者の数を、故障したプラットフォームのオウン加入者のための処理の役割を果たすのに、プラットフォームのプロセッサが必要とされる場合の、プラットフォームプロセッサの負荷容量の約半分に限定できることに留意すべきである。このように負荷を制限することにより別のプラットフォームが故障した場合に１つのプラットフォームが過負荷となるのを防止することができる。
後により詳細に説明するように、本システムが運用されている際にはすべてのサービスリクエストはリクエストを処理するように指定された第１ホームロケーションレジスタプラットフォーム３２’および第２ホームロケーションレジスタプラットフォーム３４’の適当な一方へ、信号転送ポイント３８および４０によってルーチングされる。従って、多数のホームロケーションレジスタプラットフォームはネットワークサービスリクエストの加入者の全負荷に対する処理負荷の役割を分担する。ホームロケーションレジスタプラットフォーム３２’および３４’は更に互いに対応するメッセージをコピーし、ダイナミックデータの無欠性を維持し、プラットフォームの故障が生じた場合、別のプラットフォームから引き継ぐのに必要な情報へ各プラットフォームがアクセスする。
次に図６および７を参照する。ここで図７は、図６のシステムにおけるホームロケーションレジスタプラットフォーム３２’および３４’による受信されたサービスリクエストを取り扱うための処理工程を示すフローチャートである。各サービスリクエストメッセージはメッセージの取り扱いに割り当てられたホームロケーションレジスタプラットフォーム３２’または３４’を識別するダイレクトポイントコードを含む。図６の負荷分担構造では、指定されたプラットフォームがネットワーク３６をサービスしていない（すなわちプラットフォームの故障がある）と判断されない限り、ホームロケーションレジスタプラットフォーム３２’または３４’は自己の加入者のすべてのメッセージおよび／またはダイレクトポイントコードによって指定されたメッセージを処理する。従って、ステップ１２４ではネットワークアドミニストレータ５８は、各ホームロケーションレジスタプラットフォームがオウン加入者のネットワークサービスリクエストメッセージしかサービスしないように指定することにより、ホームロケーションレジスタプラットフォーム３２’および３４’を負荷分担構造となるように構成する。
ネットワーク３６からのメッセージの受信に応答して信号転送ポイント３８および４０はメッセージのダイレクトポイントコードによって指定されたホームロケーションレジスタプラットフォーム３２’または３４’へメッセージをルーチングする（ステップ１２６）。例えば第１ホームロケーションレジスタプラットフォーム３２’を指定するダイレクトポイントコードを有する、リンク４４を通して受信されたサービスリクエストに対しては、第１信号転送ポイント３８は、まず通信リンク５０を通してメッセージをルーチングすることを試みる。これに失敗した場合、第１信号転送ポイント３８は通信リンク５２を通して第１ホームロケーションレジスタプラットフォーム３２’へ伝送するよう、リンク４８を介して第２信号転送ポイント４０へメッセージを送る。ダイレクトポイントコードが第２ホームロケーションレジスタプラットフォーム３４’を指定した場合、メッセージはまずリンク５４を通るようにルーチングされる。これに失敗した場合、次にリンク４８および５６を通るようにルーチングされる。リンク４６を通して受信されたメッセージに対しては、その後、同様なルーチング方法がとられる。図示するように、ネットワーク３６から受信されたメッセージを帆走するのに、信号転送ポイント３８および４０の各々から各ホームロケーションレジスタプラットフォーム３２’または３４’へそれぞれ２つの別の経路が設けられている。このようなデータリンクの冗長性により別個のデータ経路が提供され、このような対策がとられない場合、作動中のホームロケーションレジスタプラットフォーム３２’または３４’へのアクセスを不能にするような潜在的な通信リンクの故障に関する問題が解決される。
指定されたホームロケーションレジスタプラットフォーム３２’または３４’はメッセージを受信すると、このメッセージを適当なアプリケーションへ送る（ステップ１２８）。アプリケーションはメッセージを処理し、適当な応答を発生する（ステップ１３０）。この応答はホームロケーションレジスタプラットフォームにより信号転送ポイント３８および４０を介してネットワーク３６へ戻される（ステップ１３２）。
指定されたホームロケーションレジスタプラットフォーム３２’または３４’は受信したメッセージを他のホームロケーションレジスタプラットフォームにも送るべきかどうかを更に判断する（ステップ１３４）。この判断はアプリケーションにおけるメッセージの処理の結果、記憶されたダイナミックデータに変更が生じるかどうかに基づいて行われる。記憶されたダイナミックデータにおける変更が生じる場合、指定されたホームロケーションレジスタプラットフォーム３２’または３４’はメッセージをコピーし（ステップ１３６）、通信リンク１２０または１２２を通して他のホームロケーションレジスタプラットフォームにコピーされたメッセージを送る（ステップ１３８）。次に他のホームロケーションレジスタプラットフォーム３２’または３４’はアプリケーション内でメッセージを処理し（ステップ１４０）、ダイナミックデータを更新し（ステップ１４２）、通信リンク１２０または１２２を通して指定されたホームロケーションレジスタプラットフォームに送られるアクノーリッジメントによりメッセージの受信を確認する（ステップ１４４）ことにより、メッセージに応答する。
上記ステップに従い、受信したメッセージを処理した後に、ホームロケーションレジスタプラットフォーム３２’および３４’の双方は同じ記憶されたダイナミックデータを含む。その後、ホームロケーションレジスタプラットフォームの一方が故障した場合、他方のプラットフォームは故障したプラットフォームのためのダイレクトポイントコードによって指定されたネットワークサービスリクエストへの応答をトランスペアレントに引き継ぐのに必要なダイナミックデータのすべてを処理する。
次に、図６および８を参照する。ここで、図８はホームロケーションレジスタプラットフォーム３２’または３４’の一方の故障を処理し、その後、受信されたサービスリクエストの他方のホームロケーションレジスタプラットフォームによる処理のための処理ステップを示すフローチャートである。アドミニストレータ５８および信号転送ポイント３８および４０の一方または双方により、ホームロケーションレジスタプラットフォーム３２’または３４’の一方の故障が検出（ステップ１４６）された後に、故障したプラットフォームのためのダイレクトポイントコードによって指定された入進するすべてのサービスリクエストメッセージは、信号転送ポイント３８および４０によりサービスのための他の（バックアップ）プラットフォームへ自動的かつトランスペアレントにルーチングし直される（ステップ１４８）。これに関連し、「トランスペアレント」なる用語は再びネットワーク３６が多数のホームロケーションレジスタプラットフォーム３２’および３４’が存在していること、またはいずれのプラットフォームがメッセージに応答しているかを知らないことを意味している。他方のホームロケーションレジスタプラットフォーム３２’または３４’はメッセージを受信すると、このメッセージを適当なアプリケーションへ送る（ステップ１５０）。アプリケーションは次に応答を発生し（ステップ１５２）、この応答は信号転送ポイント３８および４０を介してネットワーク３６へ送り戻される（ステップ１５４）。
プラットフォームの故障後の信号転送ポイント３８および４０による受信されたメッセージの取り扱いに関し、例えば第１信号転送ポイント３８が故障した第１ホームロケーションレジスタプラットフォーム３２’に対して指定されたメッセージを受信した場合、第１信号転送ポイント３８は、まず通信リンク５４を通してメッセージをルーチングしようと試みる。これに失敗すると、第１信号転送ポイント３８は通信リンク５６を通して第２ホームロケーションレジスタプラットフォーム３４’へ伝送するよう、リンク４８を介して第２信号転送ポイント４０へメッセージを送る。第２信号転送ポイント４０によって受信されたメッセージおよび／または第２ホームロケーションレジスタプラットフォーム３４’に対して指定されたメッセージに対し、同様なルーチング方法が続けられる。利用可能なデータリンクにおけるこのような冗長性により、別のデータ経路が提供され、冗長性が無い場合、作動中のホームロケーションレジスタプラットフォーム３２’または３４’へのアクセスを不可能とするような潜在的な通信リンクの故障に関する問題が解決される。
プラットフォームが故障する前にネットワーク３６によりメッセージを送るが指定されたプラットフォームが故障するまでにこれらメッセージを受信または取り扱うことができないことがある。この場合、メッセージはプラットフォームにより処理されず、応答も発生しない。応答を得るにはこれらメッセージはネットワーク３６によって再送信しなければならない。ホームロケーションレジスタからの応答をネットワークが受信することなくメッセージの指定されたタイムアウトが終了した際に、一般に再送信の必要があるかどうかの判断がされる。
次に図６および９Ａを参照する。ここで図９Ａは、図６のシステムにおける故障したホームロケーションレジスタプラットフォーム３２’または３４’における、正確で、かつ最新の加入者データを回復するための方法の処理ステップを示すフローチャートである。この方法は、バックアップとして作動する間の他方のホームロケーションレジスタプラットフォームによるサービスリクエストの中間処理により影響されるダイナミックデータに関するプラットフォームを送信するため、ホームロケーションレジスタプラットフォーム３２’または３４’の一方が故障してから比較的短い期間の後に有利に使用される。
まず、故障したホームロケーションレジスタプラットフォーム３２’または３４’は信号転送ポイント３８および４０から、更に他方のプラットフォームから切り離される（ステップ１５６）。次に、この故障したホームロケーションレジスタプラットフォーム３２’または３４’には最後のバックアップが再ロードされる（ステップ１５８）。次に、ホームロケーションレジスタプラットフォーム３２’と３４’とは互いに接続される（ステップ１６０）。次にバックアップ用ホームロケーションレジスタプラットフォームは最終のデータバックアップの開始後、変更されたすべての加入者データを故障したホームロケーションレジスタプラットフォームへ送信する。この場合、故障したプラットフォームの自己の加入者のデータに優先権が与えられる（ステップ１６２）。先に故障し、更新されたホームロケーションレジスタプラットフォーム３２’または３４’が信号転送ポイント３８および４０に再接続されると回復が終了する（ステップ１６４）。プラットフォームが再び即座に故障した場合には、この時にネットワークサービスリクエストの取り扱い開始前にホームロケーションレジスタプラットフォームからのデータダンプを行うことができる。
図９Ｂには、故障したホームロケーションレジスタプラットフォーム３２’または３４’の加入者データを回復するための別の方法が示されている。この方法は、ホームロケーションレジスタプラットフォーム３２’または３４’の一方が比較的長時間故障した後に使用すると有利である。その理由は、かかる更新を行うにはバックアップとして作動する他方のホームロケーションレジスタプラットフォームのデータベースのほとんどすべてを一般に転送するからである。故障したホームロケーションレジスタプラットフォーム３２’または３４’は、まず信号転送ポイント３８および４０から、かつ他方のプラットフォームから切り離される（ステップ１６６）。次に、故障したホームロケーションレジスタプラットフォーム３２’または３４’には、その最終バックアップが再ロードされる（ステップ１６８）。次に、故障したホームロケーションレジスタプラットフォームに他方のホームロケーションレジスタプラットフォームの加入者データがダンプされ、ロードされる（ステップ１７０）。ホームロケーションレジスタプラットフォーム３２’と３４’とは互いに接続され（ステップ１７２）、他方のホームロケーションレジスタプラットフォームが最終バックアップの開始後に変更されたすべてのダイナミックデータを故障したホームロケーションレジスタプラットフォームへ送信し、この場合、故障したプラットフォームの自己の加入者のデータに優先権が与えられる（ステップ１７４）。先に故障し、更新されたホームロケーションレジスタプラットフォーム３２’または３４’が信号転送ポイント３８および４０に再接続されると、回復が終了する（ステップ１７６）。サービスリクエスメッセージの取り扱いに先立ち、先に故障し、現在は回復したホームロケーションレジスタプラットフォームからのデータダンプを行うこともできる。
次に、図１０を参照する。ここには負荷分担関係となるように構成された３つ以上の冗長ホームロケーションレジスタプラットフォーム３２’、３３’および３４’をリンクするための、本発明の第２実施例の別の構成のブロック図が示されている。この図１０では、図６のシステムに示されたものと同一または同様な部品には同じ参照番号が付けられている。負荷分担構造となっている多数のホームロケーションレジスタプラットフォームでは、全体の加入者の負荷の一部（この構成における約３分の１）しか処理しないように、各プラットフォームを割り当てることができる。追加される各ホームロケーションレジスタプラットフォームには付加的な信号転送ポイント３９’も含まれる。このように増設されたホームロケーションレジスタプラットフォームの間の通信を容易とするために、リンク１２０’、１２１’および１２２’を含む円形の通信リンクが提供される。ホームロケーションプラットフォームの作動および回復は、図６のシステムのための図７〜９Ｂに示されたホームロケーションプラットフォームと同じように行われる。
本発明の方法および装置の好ましい実施例を添付図面に示し、これまでの詳細な説明に説明したが、本発明はこれら実施例のみに限定されるものではなく、次の請求の範囲に記載の本発明の要旨から逸脱することなく、ハードウェアおよびデータの双方の冗長性を必要とするビジターロケーションレジスタまたは他のタイプのデータベースシステムと共に使用することを含む、多数の再配置、変更および置換が可能であることが理解できよう。特に、本発明の方法および装置はハードウェアおよびデータの双方に関する冗長性が必要とされるか、または有効である、データ通信システムおよび／またはデータベースシステムにおけるノードに適用可能である。従って、冗長なホームロケーションレジスタに関連させた本発明のこれまでの説明は、本発明の範囲を限定するものではなく、本発明を説明するものである。
Claims (16)
- マスターデータベースプラットフォーム（３２）と，
マスターデータベースプラットフォーム（３２）に対して冗長バックアップであるスレーブデータベースプラットフォーム（３４）と，
処理と応答の発生のため，マスターデータベースプラットフォーム（３２）にルーチングされたすべてのサービスリクエストメッセージを受信する手段とを含むデータベースシステムにおいて，
前記ルーチングされたサービスリクエストメッセージの少なくとも１つに対し，該少なくとも１つのルーチングされたサービスリクエストメッセージが，マスターデータベースプラットフォーム（３２）によって処理された時，マスターデータベースプラットフォーム（３２）に記憶されたデータに変更を生じさせるかどうか決定する手段と，
変更が生じるとの決定に応答し，前記少なくとも１つのルーチングされたサービスリクエストメッセージを，スレーブデータベースプラットフォームで処理しかつマスターデータベースプラットフォーム（３２）に記憶されたデータに合わせてスレーブデータベースプラットフォーム（３４）に記憶されたデータを変更するため，スレーブデータベースプラットフォーム（３４）にも送る手段
とを含むことを特徴としたデータベースシステム。 - マスターおよびスレーブデータベースプラットフォームは，移動電話通信システムのための移動交換センター内に冗長マスターおよびスレーブロケーションレジスタを含む請求項１に記載のデータベースシステム。
- マスターおよびスレーブロケーションレジスタはホームロケーションレジスタである請求項２に記載のデータベースシステム。
- マスターデータベースプラットフォーム（３２）の故障をモニタする手段と，
そのような故障に応答し，その後に続くサービスリクエストメッセージの処理と該サービスリクエストメッセージへの応答の発生とスレーブデータベースプラットフォーム（３４）内に記憶されたデータの変更のため，前記その後に続く全てのサービスリクエストメッセージを自動的にスレーブデータベースプラットフォーム（３４）にルーチングする手段
とを更に含む請求項１に記載のデータベースシステム。 - マスターデータベースプラットフォーム（３２）がオンライン状態に戻る時，マスターデータベースプラットフォーム（３２）内のダイナミックデータを回復するためにスレーブデータベースプラットフォーム（３４）からマスターデータベースプラットフォーム（３２）にデータを転送する手段と，
全てのサービスリクエストメッセージをマスターデータベースプラットフォーム（３２）に再びルーチングするためシステム動作を再構成する手段
とを更に含む請求項４に記載のデータベースシステム。 - マスターデータベースプラットフォーム（３２）の故障後に続くサービスリクエストメッセージの処理においてスレーブデータベースプラットフォーム（３４）により変更された全てのデータにフラグを付ける手段と，
マスターデータベースプラットフォーム（３２）がオンライン状態に戻る時，マスターデータベースプラットフォーム（３２）内のダイナミックデータを回復するためにスレーブデータベースプラットフォーム（３４）からマスターデータベースプラットフォーム（３２）にフラグの付いたデータを転送する手段と，
全てのサービスリクエストメッセージをマスターデータベースプラットフォーム（３２）に再びルーチングするためシステム動作を再構成する手段
とを更に含む請求項４に記載のデータベースシステム。 - 各サービスリクエストメッセージが，登録−通知メッセージ，登録−キャンセルメッセージ，サービス−プロフィル−リクエストメッセージから成るメッセージのグループから選択されたサービスリクエストメッセージを含む請求項１に記載のデータベースシステム。
- 前記データベースシステムにおいて，前記全てのサービスリクエストメッセージがマスターデータベースプラットフォーム（３２）へのルーチングのための第１の宛先を有し，
該データベースシステムは更に，
スレーブデータベースプラットフォーム（３４）にルーチングされた第２の宛先コードを有する全てのサービスリクエストメッセージを受信する手段と，
前記第２の宛先コードを有するルーチングされたサービスリクエストメッセージの少なくとも１つが，スレーブデータベースプラットフォームにより処理された時，スレーブデータベースプラットフォーム（３４）に記憶されたデータに変更を生じさせるかどうかを決定する手段と，
変更が生じるとの決定に応答し，前記第２の宛先コードを有する少なくとも１つのルーチングされたサービスリクエストメッセージを，マスターデータベースプラットフォームで処理しかつスレーブデータベースプラットフォーム（３４）に記憶されたデータに合わせてマスターデータベースプラットフォーム（３２）に記憶されたデータを変更するために，マスターデータベースプラットフォーム（３２）にも送る手段
とを含む請求項１に記載のデータベースシステム。 - マスターデータベースプラットフォーム（３２）とマスターデータベースプラットフォーム（３２）に対して冗長バックアップであるスレーブデータベースプラットフォーム（３４）とを含むデータベースシステムにおけるサービスリクエストメッセージの冗長処理方法であって，該方法は，
処理し，応答を発生するためにマスターデータベースプラットフォーム（３２）に全てのサービスリクエストメッセージをルーチングするステップ（６８）と，
前記ルーチングされたサービスリクエストメッセージの少なくとも１つに対し，該少なくとも１つのルーチングされたサービスリクエストメッセージが，マスターデータベースプラットフォーム（３２）によって処理された時，マスターデータベースプラットフォーム（３２）に記憶されたデータに変更を生じさせるかどうか決定するステップ（７６，１３４）と，
変更が生じるとの決定に応答し，前記少なくとも１つのルーチングされたサービスリクエストメッセージを，スレーブデータベースプラットフォームで処理しかつマスターデータベースプラットフォーム（３２）に記憶されたデータに合わせてスレーブデータベースプラットフォーム（３４）に記憶されたデータを変更するため，スレーブデータベースプラットフォーム（３４）にも送るステップ（８０）
とを含むことを特徴とする冗長処理方法。 - マスターおよびスレーブデータベースプラットフォームは，移動電話通信システムのための移動交換センター内に冗長マスターおよびスレーブロケーションレジスタを含む請求項９に記載の冗長処理方法。
- マスターおよびスレーブロケーションレジスタはホームロケーションレジスタである請求項１０に記載の冗長処理方法。
- マスターデータベースプラットフォーム（３２）の故障をモニタするステップ（８６）と，
そのような故障に応答し，その後に続くサービスリクエストメッセージの処理と該サービスリクエストメッセージへの応答の発生とスレーブデータベースプラットフォーム（３４）内に記憶されたデータの変更のため，前記その後に続く全てのサービスリクエストメッセージを自動的にスレーブデータベースプラットフォーム（３４）にルーチングするステップ（９０）
とを更に含む請求項９に記載の冗長処理方法。 - マスターデータベースプラットフォーム（３２）がオンライン状態に戻るのを待つステップと，
マスターデータベースプラットフォーム（３２）内のダイナミックデータを回復するためにスレーブデータベースプラットフォーム（３４）からマスターデータベースプラットフォーム（３２）にデータを転送するステップ（１０２）と，
全てのサービスリクエストメッセージをマスターデータベースプラットフォーム（３２）に再びルーチングするためシステム動作を再構成するステップ（１０４）
とを更に含む請求項１２に記載の冗長処理方法。 - マスターデータベースプラットフォーム（３２）の故障後に続くサービスリクエストメッセージの処理においてスレーブデータベースプラットフォーム（３４）により変更された全てのデータにフラグを付けるステップ（１０８）と，
マスターデータベースプラットフォーム（３２）がオンライン状態に戻るのを待つステップと，
マスターデータベースプラットフォーム（３２）内のダイナミックデータを回復するためにスレーブデータベースプラットフォーム（３４）からマスターデータベースプラットフォーム（３２）にフラグの付いたデータを転送するステップ（１１４）と，
全てのサービスリクエストメッセージをマスターデータベースプラットフォーム（３２）に再びルーチングするためシステム動作を再構成するステップ（１１６）
とを更に含む請求項１２に記載の冗長処理方法。 - 各サービスリクエストメッセージが，登録−通知メッセージ，登録−キャンセルメッセージ，サービス−プロフィル−リクエストメッセージから成るメッセージのグループから選択されたサービスリクエストメッセージを含む請求項９に記載の冗長処理方法。
- 前記冗長処理方法において，前記全てのサービスリクエストメッセージがマスターデータベースプラットフォーム（３２）へのルーチングのための第１の宛先を有し，
該方法は更に，
第２の宛先コードを有する全てのサービスリクエストメッセージをスレーブデータベースプラットフォーム（３４）にルーチングするステップと，
前記第２の宛先コードを有するルーチングされたサービスリクエストメッセージの少なくとも１つが，スレーブデータベースプラットフォームにより処理された時，スレーブデータベースプラットフォーム（３４）に記憶されたデータに変更を生じさせるかどうかを決定するステップと，
変更が生じるとの決定に応答し，前記第２の宛先コードを有する少なくとも１つのルーチングされたサービスリクエストメッセージを，マスターデータベースプラットフォームで処理しかつスレーブデータベースプラットフォーム（３４）に記憶されたデータに合わせてマスターデータベースプラットフォーム（３２）に記憶されたデータを変更するために，マスターデータベースプラットフォーム（３２）にも送るステップ
とを含む請求項９に記載の冗長処理方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US372,074 | 1995-01-12 | ||
| US08/372,074 US5623532A (en) | 1995-01-12 | 1995-01-12 | Hardware and data redundant architecture for nodes in a communications system |
| PCT/SE1995/001510 WO1996021981A2 (en) | 1995-01-12 | 1995-12-14 | A hardware and data reduntant architecture for nodes in a communications system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10512122A JPH10512122A (ja) | 1998-11-17 |
| JP3974652B2 true JP3974652B2 (ja) | 2007-09-12 |
Family
ID=23466609
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP52158996A Expired - Lifetime JP3974652B2 (ja) | 1995-01-12 | 1995-12-14 | 通信システムにおけるノードのためのハードウェアおよびデータ冗長アーキテクチャ |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US5623532A (ja) |
| EP (1) | EP0804842B1 (ja) |
| JP (1) | JP3974652B2 (ja) |
| AU (1) | AU4460796A (ja) |
| CA (1) | CA2209900A1 (ja) |
| DE (1) | DE69534851T2 (ja) |
| FI (1) | FI972958A (ja) |
| WO (1) | WO1996021981A2 (ja) |
Families Citing this family (110)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5867787A (en) * | 1995-07-31 | 1999-02-02 | Northern Telecom Limited | Overload control for an integrated MSC/HLR switch |
| US5920615A (en) * | 1995-10-19 | 1999-07-06 | British Telecommunications Public Limited Company | Telecommunications switch |
| US5884043A (en) * | 1995-12-21 | 1999-03-16 | Cisco Technology, Inc. | Conversion technique for routing frames in a source route bridge network |
| US5953662A (en) * | 1996-04-30 | 1999-09-14 | Ericsson, Inc. | Dual home location registers in a mobile radio system |
| KR100209464B1 (ko) * | 1996-11-30 | 1999-07-15 | 김영환 | 디지탈 이동통신 시스템의 동적 과부하 제어 장치 및 그 방법 |
| US6064875A (en) * | 1997-01-31 | 2000-05-16 | Usa Telecommunications Services, Inc. | Wireless communications system and method of operation for reducing fraud |
| US6052736A (en) * | 1997-03-31 | 2000-04-18 | International Business Machines Corp. | Adaptive message routing in a multiple network environment with a master router |
| CA2293710C (en) * | 1997-06-20 | 2008-08-12 | British Telecommunications Public Limited Company | Location dependent service for mobile telephones |
| USH1897H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Merged operations and maintenance center and method for operation |
| USH1804H (en) * | 1997-09-26 | 1999-09-07 | Browning; Mark D. | Span interface module for a telecommunications switching platform |
| USH1918H (en) * | 1997-09-26 | 2000-11-07 | Dsc/Celcore, Inc. | Integrated authentication center and method for authentication in a wireless telecommunications network |
| USH1882H (en) * | 1997-09-26 | 2000-10-03 | Asthana; Sarvesh | System and method for transferring data to redundant components |
| USH1898H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Signaling data processing |
| USH1836H (en) * | 1997-09-26 | 2000-02-01 | Fletcher; Anthony G. | Integrated telecommunications system |
| USH1837H (en) * | 1997-09-26 | 2000-02-01 | Fletcher; Anthony G. | Generic telecommunications system and associated call processing architecture |
| USH1881H (en) * | 1998-02-19 | 2000-10-03 | Dsc/Celcore, Inc. | System and method for forming circuit connections within a telecommunications switching platform |
| USH1895H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Application provider and method for communication |
| USH1859H (en) * | 1997-09-26 | 2000-09-05 | Dsc/Celcore, Inc. | System and method for controlling redundant components |
| USH1884H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | System and method for transferring echo cancellation data |
| USH1921H (en) * | 1997-09-26 | 2000-11-07 | Dsc/Celcore, Inc. | Generic wireless telecommunications system |
| USH1894H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Flexible telecommunications system architecture |
| USH1896H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Network management system server and method for operation |
| USH1917H (en) * | 1997-09-26 | 2000-11-07 | Dsc/Celcore, Inc. | Signal-processing module for a telecommunications switching platform |
| USH1802H (en) * | 1997-09-26 | 1999-09-07 | Dsc/Celcore, Inc. | System and method for automatically provisioning a telecommunications switch |
| USH1814H (en) * | 1997-09-26 | 1999-11-02 | Browning; Mark David | Telephony-support module for a telecommunications switching platform |
| USH1801H (en) * | 1997-09-26 | 1999-09-07 | Dsc/Celcore, Inc. | Switching module for a telecommunications switching platform |
| US6115463A (en) * | 1997-11-21 | 2000-09-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Migration of subscriber data between home location registers of a telecommunications system |
| US6094660A (en) * | 1997-11-21 | 2000-07-25 | Telefonaktiebolaget Lm Ericsson | Customer administrative system management of redundant database network elements in a telecommunications system |
| US6208856B1 (en) | 1997-12-08 | 2001-03-27 | Telefonaktiebolaget L M Ericsson | Method for maintaining service nodes in a telecommunications network |
| US6138017A (en) * | 1997-12-08 | 2000-10-24 | Nortel Networks Limited | Cellular communications system |
| USH1853H (en) * | 1998-02-19 | 2000-06-06 | Dsc/Celcore, Inc. | Universal client engine for a client-server environment |
| JP2978878B1 (ja) * | 1998-05-18 | 1999-11-15 | 日本電気通信システム株式会社 | ホーム位置レジスタの制御装置、方法及びプログラムを記録した記録媒体 |
| DE19836347C2 (de) | 1998-08-11 | 2001-11-15 | Ericsson Telefon Ab L M | Fehlertolerantes Computersystem |
| AU1421700A (en) * | 1998-10-22 | 2000-05-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic hlr redundancy in a radio telecommunications network |
| US6674727B1 (en) | 1998-11-30 | 2004-01-06 | Cisco Technology, Inc. | Distributed ring protocol and database |
| US6563832B1 (en) | 1998-11-30 | 2003-05-13 | Cisco Technology, Inc. | Token ring bridge distributed in a switched fabric |
| US6657951B1 (en) | 1998-11-30 | 2003-12-02 | Cisco Technology, Inc. | Backup CRF VLAN |
| US6704318B1 (en) | 1998-11-30 | 2004-03-09 | Cisco Technology, Inc. | Switched token ring over ISL (TR-ISL) network |
| US6088328A (en) * | 1998-12-29 | 2000-07-11 | Nortel Networks Corporation | System and method for restoring failed communication services |
| WO2000048363A1 (en) * | 1999-02-10 | 2000-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Utilization of gratuitous address resolution protocol for mobility support |
| US6690644B1 (en) | 1999-02-17 | 2004-02-10 | Zhone Technologies, Inc. | Mechanism for 1:1, 1+1, and UPSR path-switched protection switching |
| US6850518B1 (en) | 1999-03-04 | 2005-02-01 | Cisco Technology, Inc. | DLSw RIF passthru technique for providing end-to-end source route information to end stations of a data link switching network |
| US7013139B1 (en) * | 1999-04-02 | 2006-03-14 | Nortel Networks Limited | HLR data migration |
| KR100309444B1 (ko) * | 1999-06-17 | 2001-11-01 | 서평원 | 방문 가입자 위치 등록기의 일부 프로세서 장애시 호 착신방법 |
| US6714541B1 (en) | 1999-08-10 | 2004-03-30 | Cisco Technology, Inc. | Method and apparatus for encoding bridging/switching information within a routing information filed in a token ring environment |
| US6735441B1 (en) | 1999-11-16 | 2004-05-11 | Tekelec | Methods and systems for providing mobile telecommunications network services in a routing node |
| US6308067B1 (en) | 1999-11-30 | 2001-10-23 | At&T Corp. | Wireless communications system and method of operation for reducing fraud |
| KR100310240B1 (ko) * | 1999-12-01 | 2001-10-17 | 박종섭 | Ｃｄｍａ 시스템내 홈위치 등록기 장애 발생시의 이동가입자 재위치 등록방법 |
| US6836477B1 (en) | 1999-12-23 | 2004-12-28 | Tekelec | Methods and systems for routing messages in a communications network |
| US6662017B2 (en) * | 1999-12-23 | 2003-12-09 | Tekelec | Methods and systems for routing messages associated with ported subscribers in a mobile communications network |
| US7092505B2 (en) * | 1999-12-23 | 2006-08-15 | Tekelec | Methods and systems for universal, automatic service selection in a telecommunications signaling network |
| KR20010060451A (ko) * | 1999-12-27 | 2001-07-07 | 김진찬 | 이동 통신망의 착신 단말 위치 검출 방법 |
| US6535991B1 (en) * | 2000-01-12 | 2003-03-18 | Worldcom, Inc. | Method and apparatus for providing reliable communications in an intelligent network |
| KR100354990B1 (ko) * | 2000-01-26 | 2002-10-05 | 주식회사 하이닉스반도체 | Ｈｌｒ의 과부하 발생시 ｏｍｐ의 명령어 전송 제어 장치및 방법 |
| GB0002972D0 (en) * | 2000-02-09 | 2000-03-29 | Orange Personal Comm Serv Ltd | Data handling system |
| US6728419B1 (en) * | 2000-02-17 | 2004-04-27 | Xerox Corporation | Multi-tasking multi-threaded image processing system and method for image capture devices |
| US6513092B1 (en) | 2000-04-18 | 2003-01-28 | Nec Eluminant Technologies, Inc. | 1:N protection switching architecture for common processing units |
| GB2363548A (en) * | 2000-06-15 | 2001-12-19 | Int Computers Ltd | Computer systems, in particular virtual private networks |
| US8019587B1 (en) * | 2000-09-06 | 2011-09-13 | Ciscotechnology, Inc. | Software upgrade of redundant network components |
| KR100366434B1 (ko) * | 2001-12-21 | 2002-12-31 | 정의종 | 독립된 가입자 위치정보를 이용한 이동통신시스템 및이동통신방법 |
| CN1180569C (zh) * | 2001-12-24 | 2004-12-15 | 华为技术有限公司 | 一种设置备份归属位置寄存器的方法 |
| KR100723570B1 (ko) * | 2001-12-27 | 2007-05-31 | 엘지노텔 주식회사 | 가상 홈 네트워크의 네트워크 인터페이스 이중화 장치 및그 방법 |
| US7836252B2 (en) * | 2002-08-29 | 2010-11-16 | Micron Technology, Inc. | System and method for optimizing interconnections of memory devices in a multichip module |
| JP4111793B2 (ja) * | 2002-09-26 | 2008-07-02 | 富士通株式会社 | 中継システム |
| US7848767B2 (en) | 2002-10-15 | 2010-12-07 | Tekelec | Methods and systems for migrating between application layer mobile signaling protocols |
| US7082308B1 (en) * | 2002-12-18 | 2006-07-25 | Nortel Networks Limited | HLR mated-pair auto cutover |
| US7039402B1 (en) * | 2003-08-05 | 2006-05-02 | Nortel Networks Limited | Disaster recovery for very large GSM/UMTS HLR databases |
| ATE403302T1 (de) * | 2003-08-13 | 2008-08-15 | Koninkl Philips Electronics Nv | Kommunikationsnetzwerk |
| CN100388805C (zh) * | 2003-11-10 | 2008-05-14 | 华为技术有限公司 | 一种归属位置寄存器的数据容灾方法 |
| JP2005269068A (ja) * | 2004-03-17 | 2005-09-29 | Fujitsu Ltd | ホームエージェント二重化方法及びその装置 |
| US7844745B1 (en) * | 2004-08-19 | 2010-11-30 | Nortel Networks Limited | Alternate home subscriber server (HSS) node to receive a request if a first HSS node cannot handle said request |
| CN100344202C (zh) * | 2004-09-10 | 2007-10-17 | 华为技术有限公司 | 智能网***中实现业务处理单元备份的方法及装置 |
| US7889716B2 (en) * | 2005-12-01 | 2011-02-15 | Tekelec | Methods, systems, and computer program products for using an E.164 number (ENUM) database for message service message routing resolution among 2G and subsequent generation network systems |
| BRPI0707819A2 (pt) * | 2006-02-15 | 2011-05-10 | Tekelec Us | mÉtodo, sistemas e produÇço de programa de computador para seletivamente processar ou redirecionar mensagens de parte de controle de conexço de sinalizaÇço ( sccp ) |
| US7596615B2 (en) * | 2006-02-22 | 2009-09-29 | Microsoft Corporation | Multi-server automated redundant service configuration |
| US20070234345A1 (en) * | 2006-02-22 | 2007-10-04 | Microsoft Corporation | Integrated multi-server installation |
| US7853945B2 (en) * | 2006-02-22 | 2010-12-14 | Michael Kramer | Integrated computer server imaging |
| US8224322B2 (en) * | 2006-06-12 | 2012-07-17 | Lemko Corporation | Roaming mobile subscriber registration in a distributed mobile architecture |
| US8634829B2 (en) * | 2006-06-30 | 2014-01-21 | Nokia Corporation | System and method for IMSI list based VLR resilience |
| US7787445B2 (en) | 2006-07-20 | 2010-08-31 | Tekelec | Methods, systems, and computer program products for routing and processing ENUM queries |
| US8254551B2 (en) * | 2006-12-07 | 2012-08-28 | Tekelec, Inc. | Methods, systems, and computer program products for providing quality of service using E.164 number mapping (ENUM) data in a communications network |
| FR2912862B1 (fr) * | 2007-02-15 | 2009-08-21 | Bouygues Telecom Sa | Continuite de services par l'utilisation d'un hlr secours |
| US7996541B2 (en) * | 2007-06-15 | 2011-08-09 | Tekelec | Methods, systems, and computer program products for identifying a serving home subscriber server (HSS) in a communications network |
| US8538000B2 (en) * | 2007-08-10 | 2013-09-17 | Tekelec, Inc. | Methods, systems, and computer program products for performing message deposit transaction screening |
| JP4583433B2 (ja) * | 2007-12-10 | 2010-11-17 | 富士通株式会社 | 中継システム |
| EP2258128B1 (en) * | 2008-03-07 | 2017-01-11 | Tekelec Global, Inc. | Methods, systems, and computer readable media for routing a message service message through a communications network |
| US7877625B2 (en) | 2008-04-16 | 2011-01-25 | Invensys Systems, Inc. | Efficient architecture for interfacing redundant devices to a distributed control system |
| US8046420B2 (en) | 2008-04-23 | 2011-10-25 | Lemko Corporation | System and method to control wireless communications |
| US8340667B2 (en) | 2008-06-26 | 2012-12-25 | Lemko Corporation | System and method to control wireless communications |
| US8706105B2 (en) | 2008-06-27 | 2014-04-22 | Lemko Corporation | Fault tolerant distributed mobile architecture |
| US8107409B2 (en) | 2008-07-11 | 2012-01-31 | Lemko Corporation | OAMP for distributed mobile architecture |
| US7855988B2 (en) | 2008-07-14 | 2010-12-21 | Lemko Corporation | System, method, and device for routing calls using a distributed mobile architecture |
| WO2010060087A2 (en) | 2008-11-24 | 2010-05-27 | Tekelec | Systems, methods, and computer readable media for location-sensitive called-party number translation in a telecommunications network |
| US9021014B2 (en) * | 2009-03-25 | 2015-04-28 | Tekelec, Inc. | Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy |
| WO2010132436A2 (en) * | 2009-05-11 | 2010-11-18 | Tekelec | Methods, systems, and computer readable media for providing scalable number portability (np) home location register (hlr) |
| WO2011035050A2 (en) * | 2009-09-16 | 2011-03-24 | Tekelec | Methods, systems, and computer readable media for providing foreign routing address information to a telecommunications network gateway |
| EP2489161B1 (en) | 2009-10-16 | 2019-06-12 | Tekelec, Inc. | Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring and/or firewall functionality |
| US9313759B2 (en) | 2009-10-16 | 2016-04-12 | Tekelec, Inc. | Methods, systems, and computer readable media for providing triggerless equipment identity register (EIR) service in a diameter network |
| US8750126B2 (en) * | 2009-10-16 | 2014-06-10 | Tekelec, Inc. | Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information |
| WO2011106690A2 (en) | 2010-02-25 | 2011-09-01 | Tekelelec | Systems, methods, and computer readable media for using a signaling message routing node to provide backup subscriber information management service |
| FR2956940B1 (fr) * | 2010-02-26 | 2013-10-04 | Eads Defence & Security Sys | Procede de gestion d'une cellule d'un reseau de radiotelecommunication |
| US8644355B2 (en) | 2010-12-23 | 2014-02-04 | Tekelec, Inc. | Methods, systems, and computer readable media for modifying a diameter signaling message directed to a charging function node |
| CN103460648B (zh) | 2011-01-21 | 2017-04-19 | 泰克莱克股份有限公司 | 用于在Diameter信令路由器(DSR)内屏蔽Diameter消息的方法和*** |
| WO2012129171A2 (en) | 2011-03-18 | 2012-09-27 | Tekelec, Inc. | Methods, systems, and computer readable media for configurable diameter address resolution |
| US9100796B2 (en) | 2011-12-15 | 2015-08-04 | Tekelec, Inc. | Methods, systems, and computer readable media for seamless roaming between diameter and non-diameter networks |
| US8855654B2 (en) | 2013-01-28 | 2014-10-07 | Tekelec Global, Inc. | Methods, systems, and computer readable media for tracking and communicating long term evolution (LTE) handset communication capability |
| US9143942B2 (en) | 2013-03-14 | 2015-09-22 | Tekelec Global, Inc. | Methods, systems, and computer readable media for providing a multi-network equipment identity register |
| US9635526B2 (en) | 2013-03-15 | 2017-04-25 | Tekelec, Inc. | Methods, systems, and computer readable media for utilizing a diameter proxy agent to communicate short message service (SMS) messages |
| ES2915700T3 (es) * | 2013-05-22 | 2022-06-24 | Vivo Mobile Communication Co Ltd | Rastreo de fallos en un sistema de telecomunicaciones |
| US10117127B2 (en) | 2015-07-08 | 2018-10-30 | Oracle International Corporation | Methods, systems, and computer readable media for communicating radio access network congestion status information for large numbers of users |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5307481A (en) * | 1990-02-28 | 1994-04-26 | Hitachi, Ltd. | Highly reliable online system |
| US5289179A (en) * | 1991-11-27 | 1994-02-22 | At&T Bell Laboratories | Maintaining stable virtual circuit data connections with spare protocol handler |
| US5278890A (en) * | 1991-11-27 | 1994-01-11 | At&T Bell Laboratories | Paging arrangements in a cellular mobile switching system |
| US5526507A (en) * | 1992-01-06 | 1996-06-11 | Hill; Andrew J. W. | Computer memory array control for accessing different memory banks simullaneously |
| SE501088C2 (sv) * | 1993-03-31 | 1994-11-07 | Ericsson Telefon Ab L M | Återupprättande av en hemmadatabas i mobilradiosystem |
| US5406504A (en) * | 1993-06-30 | 1995-04-11 | Digital Equipment | Multiprocessor cache examiner and coherency checker |
| JP2708386B2 (ja) * | 1994-03-18 | 1998-02-04 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 同時更新及び複写手順を通して重複データベースを回復させる方法及び装置 |
| US5555430A (en) * | 1994-05-31 | 1996-09-10 | Advanced Micro Devices | Interrupt control architecture for symmetrical multiprocessing system |
-
1995
- 1995-01-12 US US08/372,074 patent/US5623532A/en not_active Expired - Lifetime
- 1995-12-14 AU AU44607/96A patent/AU4460796A/en not_active Abandoned
- 1995-12-14 DE DE69534851T patent/DE69534851T2/de not_active Expired - Lifetime
- 1995-12-14 WO PCT/SE1995/001510 patent/WO1996021981A2/en active IP Right Grant
- 1995-12-14 EP EP95943315A patent/EP0804842B1/en not_active Expired - Lifetime
- 1995-12-14 JP JP52158996A patent/JP3974652B2/ja not_active Expired - Lifetime
- 1995-12-14 CA CA002209900A patent/CA2209900A1/en not_active Abandoned
-
1997
- 1997-07-11 FI FI972958A patent/FI972958A/fi unknown
Also Published As
| Publication number | Publication date |
|---|---|
| AU4460796A (en) | 1996-07-31 |
| FI972958A (fi) | 1997-09-12 |
| MX9705122A (es) | 1997-10-31 |
| EP0804842B1 (en) | 2006-03-08 |
| DE69534851T2 (de) | 2006-11-30 |
| WO1996021981A2 (en) | 1996-07-18 |
| EP0804842A2 (en) | 1997-11-05 |
| FI972958A0 (fi) | 1997-07-11 |
| WO1996021981A3 (en) | 1996-09-12 |
| JPH10512122A (ja) | 1998-11-17 |
| US5623532A (en) | 1997-04-22 |
| CA2209900A1 (en) | 1996-07-18 |
| DE69534851D1 (de) | 2006-05-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3974652B2 (ja) | 通信システムにおけるノードのためのハードウェアおよびデータ冗長アーキテクチャ | |
| EP0964563B1 (en) | Redundant call processing | |
| US6920320B2 (en) | Method and apparatus for stable call preservation | |
| US20140064130A1 (en) | Geographic redundancy for call servers in a cellular system based on a bearer-independent core network | |
| JPH0670363A (ja) | 信号送信方法 | |
| EP1044579B1 (en) | Database updating in a mobile communication system | |
| CN100574486C (zh) | 通信网络中双归属组网的***及其方法 | |
| US7013139B1 (en) | HLR data migration | |
| AU772655B2 (en) | Method and apparatus for providing reliable communications in an intelligent network | |
| US8559940B1 (en) | Redundancy mechanisms in a push-to-talk realtime cellular network | |
| US7130907B2 (en) | Wireless mobility services platform with package-based database structure | |
| EP1391131B1 (en) | Data element information management in a network environment | |
| JPH1168790A (ja) | Ｌａｎエミュレーションサーバ二重化方式 | |
| MXPA97005122A (en) | Redundant architecture of hardware and paranod data in a communication system | |
| JP3000932B2 (ja) | 通信ネットワークの迂回ルート管理方法と装置 | |
| KR20020052778A (ko) | 백업 홈위치등록기의 메모리 백업 운용방법 | |
| US6320844B1 (en) | Distributed restoration | |
| JPH10150469A (ja) | フレームリレー・バックアップ・システム及びバックアップ方法 | |
| JPH1013464A (ja) | パケット交換システムにおける通信制御方法 | |
| JPH05336166A (ja) | 通信無中断形ファイル更新方法 | |
| JPH11252105A (ja) | 加入者回線切替方法 | |
| JPH03101540A (ja) | ポイント・ツウ・ポイント通信方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051220 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060317 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060614 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061107 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070605 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070615 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100622 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100622 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110622 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120622 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130622 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |