(57)【要約】【課題】マルチプロセッサシステムにおいて、複数のプロセッサが共有メモリにアクセスしているときの障害発生時に、リカバリ時の呼損の防止，リカバリ処理の簡素化，復旧の高速化，システムの信頼性および大きな作業容量を割り当てられたバッファによる柔軟性を有するマルチプロセッサシステムを提供する。【解決手段】マルチプロセッサシステムにおいて、共有メモリが、各プロセッサによって獲得された通信呼に関する呼情報を保持するリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブル７と、キュー管理情報テーブル７のキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録するメモ記録部（更新履歴記録領域）８とを設けて構成する。【選択図】  図８
2004220118.tif 000002
【特許請求の範囲】
【請求項１】
通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
各プロセッサによって獲得された該通信呼に関する呼情報を保持するリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【請求項２】
該複数のプロセッサのうちのいずれかのプロセッサが、該キュー管理情報へのアクセス時に障害が発生したときに、該キュー管理情報テーブルに保持されたキュー管理情報と、該更新履歴記録領域に記録された更新履歴情報とに基づいて、リカバリ処理の要否を判定する判定部と、
該判定部がリカバリ必要と判定した場合に、該更新履歴情報に基づいて該キュー管理情報をリカバリする復旧部とをそなえて構成されたことを特徴とする、請求項１記載のマルチプロセッサシステム。
【請求項３】
通信装置と、該通信装置と通信する対向通信装置との間における通信状態を監視する監視システムにおいて、
複数のプロセッサがアクセスしうる共有メモリのリソース状態を含む上記の通信状態を保持する状態監視テーブルと、
該状態監視テーブルに保持された通信状態を記録する通信状態記録領域と、
該通信状態記録領域に保持された通信状態に基づいて該状態監視テーブルのうちの局所的な障害発生部分をリカバリする復旧部と、該状態監視テーブルの通信状態のうちの局所的な障害発生部分を初期化する初期化とのうちの少なくとも一方を実施する選択とを設けたことを特徴とする、監視システム。
【請求項４】
通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるキュー取り出し方法であって、
該複数のプロセッサのうちのいずれかのプロセッサが、獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する参照ステップと、
該いずれかのプロセッサが、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、更新履歴記録領域に記録する記録ステップと、
該いずれかのプロセッサが、該更新履歴を該キュー管理情報テーブルに書き込む書き込みステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるキュー取り出し方法。
【請求項５】
通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるテーブルリカバリ処理方法であって、
該複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルの該キュー管理情報と、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域の該更新履歴情報とに基づいてリカバリ処理の要否を判定する判定ステップと、
該判定ステップにてリカバリ必要と判定された場合に、該更新履歴情報に基づいて該キュー管理情報をリカバリするリカバリステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるテーブルリカバリ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば負荷分散型のマルチプロセッサシステムに関し、多量の信号処理を行なう複数のプロセッサによってアクセスされる共有メモリに割り当てられたキューのリカバリ処理に用いて好適な、マルチプロセッサシステム，監視システム，マルチプロセッサシステムにおけるキュー取り出し方法およびマルチプロセッサシステムにおけるテーブルリカバリ処理方法に関する。
【０００２】
【従来の技術】
Ｗ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ；符号分割多元接続）方式の移動通信システムにおける各種の通信装置は、大量のデータの送受信処理を行なっている。
（Ｐ１）移動通信システムの一例
複数の無線基地局装置（ＢＴＳ：Ｂａｓｅ  Ｔｒａｎｓｍｉｔｔｉｎｇ  Ｓｔａｔｉｏｎ：以下、特に断らない限り、ＢＴＳと称する。）と公衆網又はインターネットとの間に設けられた基地局制御装置（ＲＮＣ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ：以下、特に断らない限り、ＲＮＣと称する。）は、公衆網から大容量の動画像データ等を受信し、かつその動画像データ等を１又は複数のＢＴＳに対して転送する。また、ＲＮＣは、複数のＢＴＳから送信された情報データを公衆網に送信する。すなわち、ＲＮＣは、多量の呼処理（Ｃａｌｌ  Ｐｒｏｃｅｓｓｉｎｇ：ＣＰ）と大量の演算処理とが必要である。
【０００３】
（Ｐ２）負荷分散装置
このため、ＲＮＣは、信号処理を行なう複数のプロセッサと、これらの複数のプロセッサが共有して呼処理に必要なデータを保持する共有メモリとをそなえたマルチプロセッサシステムを構成し、呼処理に必要な負荷を分散させている（振り分けている）。
【０００４】
この負荷分散処理を行うマルチプロセッサシステムは、従来から種々提案されている（例えば特許文献１参照）。
ＲＮＣのキュー管理方法（キュー管理方式又はキュー管理情報方式）は、各装置（又は各機器）ごとにリソースを管理している。例えば、１台のＢＴＳに対して一つのリソースを割り当てるのである。
【０００５】
（Ｐ３）リソース
ここで、リソースとは、特に断らない限り、物理的なメモリ領域、又は通信相手の識別情報等の一つの呼情報を保持するメモリ領域を意味する。そして、共有メモリは、複数のプロセッサによってアクセス（読み書き）される通信装置に設けられ、両方向キューが用いられている。
【０００６】
（Ｐ４）キュー
キューは、一般に、情報データと、そのキュー自身が接続する別のキューアドレスとを有する。ここで、両方向キューとは、例えば、図２１（ａ）に示すリソースＡ〜Ｃのように、そのキュー自身の直前のキューアドレス（以下、前キューアドレス）と、そのキュー自身の直後のキューアドレス（以下、次キューアドレス）とを有する。これにより、プロセッサは、図２１（ａ）に示すリソースＡ〜Ｃの各「次キューアドレス」を参照して、所望のキューを検索できる。また、プロセッサは、リソースＣの「次キューアドレス」に格納されている「前キューアドレス」を参照し、順に各キューを逆方向から検索でき、この点で、両方向キューは、各キューが「次キューアドレス」だけを有する片方向キューと異なる。
【０００７】
そして、プロセッサは、キューに各種の呼情報を挿入し、また、他のプロセッサが、このキューの呼情報を参照し、これにより、キューを介して呼情報が、プロセッサ相互に共有される。このキューは、各プロセッサが呼情報を処理している間は、キュー管理情報テーブルにより常時管理されている。
（Ｐ５）負荷分散型のマルチプロセッサシステム
負荷分散型のマルチプロセッサの一例として、図１９，図２０を参照してＲＮＣシステムにおける共有メモリについて説明する。
【０００８】
図１９は負荷分散型のマルチプロセッサシステムのブロック図である。この図１９に示す負荷分散装置２００は、ＲＮＣに設けられ、例えば呼処理を行なうものであって、負荷分散制御部（制御部）２０１とプロセッサＡ〜Ｄと共有メモリ２０３とプロセッサ間通信装置２０４とをそなえて構成されている。
ここで、制御部２０１は、交換機１０２およびＢＴＳ１９８ａ〜１９８ｂからの情報データおよび制御データを受信し、呼処理又は通信処理に要する負荷を各プロセッサＡ〜Ｄに振り分けるものである。また、プロセッサＡ〜Ｄは、いずれも、ＢＴＳ１９８ａ〜１９８ｂとの間における呼処理を行なうものである。そして、ＲＮＣ内部において生じた負荷と、交換機１０２等の外部装置からの呼処理についての負荷との全負荷が、これらのプロセッサＡ〜Ｄによって分散処理される。従って、各プロセッサＡ〜Ｄは、特定のＢＴＳ１９８ａについての負荷のみを処理せずに、他のＢＴＳ１９８ｂについての負荷をも処理する。すなわち、プロセッサＡ〜Ｄの各負荷が平均されるように、全負荷が分散して割り当てられるのである。
【０００９】
また、共有メモリ２０３は、ＢＴＳ１９８ａ〜１９８ｂのそれぞれについてのリソースを確保し、このリソースに、通信相手（対向通信装置）の携帯電話のアドレス又は電話番号等の呼情報を保持するキューを生成している。呼情報はそれぞれＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：識別子）を割り当てられ、有線回線を介して相互に通信できるようになっている。
【００１０】
プロセッサ間通信装置２０４は、各プロセッサＡ〜Ｄが相互に信号を送受信するためのものである。
（Ｐ６）ソフトウェアによるリソース獲得の説明
図２０は共有メモリ２０３からのリソース獲得を説明するためのシーケンスを示す図である。交換機１０２は、制御部２０１に対して、端末１についての呼制御信号１を送信し（ステップＨ１）、制御部２０１は、この呼制御信号１を受信すると、各プロセッサＡ〜Ｄのうちの負荷が小さい例えばプロセッサＡを選択しプロセッサＡに対して割り込みし（ステップＨ２）、この呼制御信号１を通知する。プロセッサＡは、この通知を受信すると、共有メモリ２０３（図１９参照）にリソースを獲得し（ステップＨ３）、リソースを獲得すると、その旨を交換機１０２に対して送信する（呼制御信号１′［端末１］と表示されたメッセージ）。
【００１１】
一方、交換機１０２は、端末１についての呼制御信号２を、上記の呼制御信号１の送信後に送信し（ステップＨ４）、制御部２０１は、この呼制御信号２を受信すると、その呼制御信号２についてのタスクをプロセッサＢに分散し（ステップＨ５）、プロセッサＢに通知する（ステップＨ６）。ここで、プロセッサＢが共有メモリ２０３からリソースを獲得できた場合、プロセッサＢは、交換機１０２に呼制御信号２′としてアック（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：応答信号）を送信する（ステップＨ７）。これにより、各プロセッサＡ〜Ｄの負荷が分散される。
【００１２】
（Ｐ７）キュー管理機能
キュー管理機能は、各プロセッサＡ〜Ｄのソフトウェア部（以下、ソフトウェアと称する。）により実現される。制御部２０１が、キュー管理機能をプロセッサＡに割り当てると、プロセッサＡは、排他処理（ロック）を行ない、共有メモリ２０３のうちのキューに割り当てられていたリソースを獲得する。排他処理されている間は、他のプロセッサＢ〜Ｄは待機する。
【００１３】
キュー管理の一例として、プロセッサＡが、キューを獲得した場合、そのキューの大きさ情報（キューの範囲およびキューの位置）を共有メモリ２０３の特定領域に書き込む。そして、プロセッサＡによる処理が終了し、他のプロセッサＢが共有メモリ２０３にアクセスが必要なときに、プロセッサＢがプロセッサＡにより書かれた大きさ情報を参照する。
【００１４】
なお、共有バッファ領域の動作状態／使用状態を常時監視するメモリ制御状態監視装置は、例えば特許文献２に開示されている。
（Ｐ８）共有メモリ２０３の一例
図２１（ｂ）は障害発生後の共有メモリ２０３の割り当て例を示す図である。キュー管理情報テーブル２０５に保持される情報は、キュー管理数（全キュー数），次キューアドレス，前キューアドレス等である。
【００１５】
例えば、図２１（ａ）に示す共有メモリ２０３は、キュー９１ａ〜９１ｃの３個が接続されているので、キュー管理数は３と保持され、また、次キューアドレスはキュー９１ａの先頭キューアドレス（キュー管理情報テーブル２０５の先頭にキューイングされている先頭キューアドレス）が保持される。なお、キュー９１ａの前には、キュー管理情報テーブル２０５はあってもキューはないので、前キューアドレスの値はない。
【００１６】
プロセッサＡ〜Ｄは、いずれも、このキュー管理情報テーブル２０５に書き込まれたキュー管理数等の情報にアクセスでき、各呼を占有しているリソースの大きさ等の情報を容易に取得できる。また、マスタプロセッサとして他の装置のプロセッサ（図示省略）からの特定信号を受信するものは、制御部２０１を介して受信した音声パケットをプロセッサＡ〜Ｄのうちの負荷が小さいものに対して、振り分けるようにしている。換言すれば、キュー管理情報テーブル２０５は、「キューのターミナル」として機能している。
【００１７】
（Ｐ９）キュー取り出しおよびキュー挿入の動作説明
図２３（ａ）〜図２３（ｆ）は、いずれも、キュー取り出し、又はキュー挿入を説明するための図であり、これらに示す３段の領域は、キュー管理情報テーブル２０５に設けられたものであって、１〜３段目は、キュー管理に必要な情報エリアのうちのキュー管理数，先頭キューアドレスおよび最終キューアドレスが書き込まれている。図２３（ａ）〜図２３（ｆ）も、この方針を受け入れている。
【００１８】
図２３（ａ）に示すものは、初期化直後のキュー管理情報テーブル２０５の要部を示す図であって、全領域は０（記録なし）が記録される。そして、一つのキュー（番号１のキュー）が挿入されると、図２３（ｂ）に示す各領域の管理数，先頭キューアドレス，最終キューアドレスは、それぞれ、１，１，１である。
図２３（ｃ）に示すものは、図２３（ｂ）に示す状態において、さらに１個のキュー（番号２のキュー）が挿入された場合の各領域を示す図である。すなわち、全キュー数が２個のキューであり、管理数，先頭キューアドレス，最終キューアドレスは、それぞれ、２（番号１，２のキュー），１，２である。
【００１９】
図２３（ｄ）に示すものは、図２３（ｃ）に示す状態において、さらに１個のキュー（番号３のキュー）が挿入された場合の各領域を示す図である。従って、管理数，先頭キューアドレス，最終キューアドレスは、それぞれ、３（番号１〜３のキュー），１，３である。
このように、キューを挿入する毎に、その履歴が保存される。
【００２０】
次に、キューの取り出し又はキューの削除のときのキュー管理情報テーブル２０５の要部を図２３（ｅ），図２３（ｆ）を参照して説明する。キュー削除は、例えば、電話の通話が終了したときに、キュー管理情報テーブル２０５に記録されてその通話が保持される。
図２３（ｅ）は、図２３（ｄ）に示す状態から、キュー番号２を取り出した後のものを示しており、管理数は２，先頭キューアドレスは１，最終キューアドレスは、キュー３のままである。
【００２１】
図２３（ｆ）は図２３（ｅ）に示す状態から、再度、キュー２を挿入した場合におけるものである。これにより、管理数は３、先頭キューアドレスは１であり、また、最終キューアドレスは２である。
（Ｐ１０）キュー操作の一例
キューを操作するためには、プロセッサＡ〜Ｄは、キューの開放時に、例えば図２１（ａ）に示すキュー管理情報テーブル２０５のキュー管理数，次キューアドレス、前キューアドレスおよび先頭キューアドレスのそれぞれを更新する必要がある。
【００２２】
これに対して、キュー操作するためのプロセッサＡ〜Ｄに障害が発生した場合は、リカバリ処理が容易ではない。キュー操作している例えばプロセッサＡに障害が発生し、例えば図２１（ｂ）に示すように、現実のキュー管理数とキューに書き込まれたキュー管理数との相違が発生する場合、又は次キューアドレスと前の次キューアドレスとの相違が発生する場合は、プログラムが正常に実行されないことが起こり得る。このため、プログラムを正常に動作させるために、障害を検出した他のプロセッサＢ〜Ｄは、リカバリ処理動作を行なう。
【００２３】
図２２は共有メモリ２０３のリカバリ処理動作の一例を示す図である。この図２２に示すリカバリ処理動作は、プロセッサＡ〜Ｄが、共有メモリ２０３のアドレスを検索し、先頭キュー９１ａと最終キュー（末尾キュー）９１ｂとの双方向からキューを辿り、双方向のキューの個数をカウントして比較する。これらのキューの個数が不一致の場合は、キュー管理情報テーブル２０５に書き込まれた後キューアドレスと前キューアドレスとが連続していないので、キューの欠落又はキュー管理情報テーブル２０５に破壊が生じたことが想定される。この場合、各プロセッサＡ〜Ｄは、リカバリ処理を行なってキューをリカバリさせている。
【００２４】
このように、ＲＮＣに設けられた負荷分散型のマルチプロセッサＡ〜Ｄと、共有メモリ２０３とにより、キュー管理およびリカバリ処理が行なわれる。
ところで、大量の呼がＲＮＣに入力されると、キュー管理情報を保持するためのリソースが飽和し、システムの機能が停止する可能性がある。このため、ＲＮＣは、共有メモリ２０３のメモリ領域の状態を監視する必要があり、この状態監視は、状態監視システムによって実現される。以下、状態監視システムについて説明する。
【００２５】
この状態監視システムは、共有メモリ２０３のリソース割り当て状態を監視するメモリ監視システムであり、移動通信システムにおける装置，機器又は端末のリソース状態を、状態監視テーブルを用いて監視又は管理する。
この状態監視システムは、管理と復旧部とをそなえて構成されている。ここで、管理は、状態監視テーブルはメモリのリソースを所定のサイズのページに分割し各ページの更新の有無を管理して管理データファイルにその情報を保持し、また、更新されたページのデータを更新データファイルに保持するものである。さらに、復旧部は、障害リカバリ時に、管理データファイルおよび更新データファイルの情報に基づいて、メモリのテーブルデータをリカバリするものである。
【００２６】
この状態監視システムによれば、特に、リソース又はバッファ等に関し、状態監視テーブルのうちの障害が発生した部分に対応する装置−装置又は装置−端末間の状況（すなわち、局所的な障害発生状況）を把握することができる。
【００２７】
【特許文献１】
特開２００１−１６７０７５号公報
【特許文献２】
特開平９−９１１７２号公報
【００２８】
【発明が解決しようとする課題】
しかしながら、上記のキュー管理情報テーブル２０５又は状態監視テーブルを用いたシステムは、次の（Ｑ１）〜（Ｑ４）に示す課題がある。
（Ｑ１）リカバリ処理エラーの招来
共有メモリ２０３にあるリソースをデキュー（特定のキューを取り出すこと），エンキュー（キューを挿入すること）又は状態更新中に障害が発生した場合、障害が発生したキュー管理情報テーブル２０５が破壊されシステムの処理エラーを招来する可能性がある。例えば、制御部２０１を介して、交換機１０２から直接、制御信号が入力されたときに、その応答ができず、上位装置は呼を切断する。
【００２９】
また、状態監視テーブルを用いて管理する方法も、テーブルアクセス時に障害が発生した場合は、状態監視テーブルに保持されたデータを破壊する可能性があり、システムの処理エラーを招く可能性がある。
（Ｑ２）リカバリ時の呼損による処理性能
信号量（呼量等）が多い場合は、プロセッサＡ〜Ｄが共有メモリ２０３をアクセスする時間が長くなりボトルネックとなる可能性がある。この場合、処理時間を  短縮するためには、呼処理のための負荷が多大となる。また、リカバリ処理は、常時行なうよりも、必要時のみ動作するほうが効率的である。
【００３０】
また、上記のキューの個数を比較する方法は、プロセッサが、双方向からキューを辿っていくため、検索のための長い時間（リカバリの時間）を要し、他のプロセッサが共有メモリ２０３をアクセスできない時間が増大し、従って、呼損による処理性能に影響を与える。
（Ｑ３）システム信頼度
障害発生後のリカバリ処理は、呼損等に影響があるので、プログラムの非正常な動作を起こさずに、高速で絶対的な信頼性のあるような設計をしなければならない。このため、システムの複雑さが高まる。
【００３１】
また、キュー管理情報テーブル２０５の破壊をリカバリするときは、リカバリ処理は、他のプロセッサによる二重障害（排他的なリソース獲得が失敗すること。）も誘発し、システムの信頼度に欠ける。特に、近年の移動通信システムへの信頼度は高いので、信頼性は重要な要素である。
システムの安定化を向上させる方法として、現用系と予備系とを設ける冗長構成がよく知られている。例えば、各ＲＮＣ８４ａ〜８４ｂは、数枚の現用系のＣＰ基板と、１枚の予備系のＣＰ基板とをそなえ、現用系のＣＰ基板が、故障，保守又は検査で使用できないときは、現用系のＣＰ基板と外部装置との間の物理的な通信パスを、その現用系のＣＰ基板から切断して、予備系のＣＰ基板に接続する。ところが、この現用系および予備系を用いた切り替えは、時間を有するという課題がある。
【００３２】
さらに、システムは、確実な課金と、ＲＮＣの下流側の装置又は端末の動作とを保証しなければならない。従って、プロセッサが共有メモリ２０３にアクセス中に障害が発生したときに、他のプロセッサ（他のユーザ）がアクセスできるように、共有メモリ２０３の占有を開放させる必要である。
（Ｑ４）簡素化
システム規模の拡大は、プログラム量の増大を招く。システムの信頼性および柔軟性は、それぞれ、開発するシステム規模に左右される。従来技術を用いた場合は、処理が複雑であり、また、信頼性（プログラム量）および柔軟性（必要な記憶容量）がネックであった。
【００３３】
本発明は、このような課題に鑑み創案されたもので、システムの処理エラーを回避し、リカバリ時の呼損による処理性能をなくし、プロセッサによる共有メモリのアクセス中の障害発生時において他のプロセッサがアクセスでき、そして、処理の簡素化，豊富なプログラム容量を用いた信頼性および比較的大きな作業メモリ容量の割り当てによる柔軟性を有する、マルチプロセッサシステム，監視システム，マルチプロセッサシステムにおけるキュー取り出し方法およびマルチプロセッサシステムにおけるテーブルリカバリ処理方法を提供することを目的とする。
【００３４】
【課題を解決するための手段】
このため、本発明のマルチプロセッサシステムは、通信呼を処理する複数のプロセッサと複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、共有メモリが、各プロセッサによって獲得された通信呼に関する呼情報を保持するリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けたことを特徴としている（請求項１）。
【００３５】
また、複数のプロセッサのうちのいずれかのプロセッサが、キュー管理情報へのアクセス時に障害が発生したときに、キュー管理情報テーブルに保持されたキュー管理情報と、更新履歴記録領域に記録された更新履歴情報とに基づいて、リカバリ処理の要否を判定する判定部と、判定部がリカバリ必要と判定した場合に、更新履歴情報に基づいてキュー管理情報をリカバリする復旧部とをそなえて構成されてもよい（請求項２）。
【００３６】
さらに、本発明の監視システムは、通信装置と、通信装置と通信する対向通信装置との間における通信状態を監視する監視システムにおいて、複数のプロセッサがアクセスしうる共有メモリのリソース状態を含む上記の通信状態を保持する状態監視テーブルと、状態監視テーブルに保持された通信状態を記録する通信状態記録領域と、通信状態記録領域に保持された通信状態に基づいて状態監視テーブルのうちの局所的な障害発生部分をリカバリする復旧部と、状態監視テーブルの通信状態のうちの局所的な障害発生部分を初期化する初期化部とのうちの少なくとも一方を実施する選択とを設けたことを特徴としている（請求項３）。
【００３７】
そして、本発明のマルチプロセッサシステムにおけるキュー取り出し方法は、通信呼を処理する複数のプロセッサと複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるキュー取り出し方法であって、複数のプロセッサのうちのいずれかのプロセッサが、獲得したリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する参照ステップと、各プロセッサが、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、更新履歴記録領域に記録する記録ステップと、各プロセッサが、更新履歴をキュー管理情報テーブルに書き込む書き込みステップとをそなえたことを特徴としている（請求項４）。
【００３８】
また、本発明のマルチプロセッサシステムにおけるテーブルリカバリ処理方法は、通信呼を処理する複数のプロセッサと複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるテーブルリカバリ処理方法であって、複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルのキュー管理情報と、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域の更新履歴情報とに基づいてリカバリ処理の要否を判定する判定ステップと、判定ステップにてリカバリ必要と判定された場合に、更新履歴情報に基づいてキュー管理情報をリカバリするリカバリステップとをそなえたことを特徴としている（請求項５）。
【００３９】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
（Ａ）本発明の第１実施形態の説明
図１は本発明の第１実施形態に係る移動通信システムの構成図である。この図１に示す移動通信システム１００は、ＣＤＭＡ方式を用いたシステムであって、電話，テキストデータおよび音声等の低容量のデータと、静止画および動画等の大容量のデータ（以下、低容量データおよび大容量データを情報データと称する。）を混在させ、かつ高速に送受信するものである。
【００４０】
以下、移動通信システム１００の各装置について図１〜図３を参照して説明し、図４を参照して負荷分散装置について説明する。
（１）移動通信システム１００
図１に示す移動通信システム１００は、ユーザが利用する各種の移動機（ＭＳ：Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ，以下、ＭＳと称する。）１０ａ，１０ｂ，１０ｃと、例えば４８のＢＴＳ（無線基地局）８３ａ〜８３ｃと、ＲＮＣ（無線ネットワーク制御装置）８４ａ〜８４ｂと、コアネットワーク（ＣＮ：Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）１０１と、公衆網（ＰＳＴＮ：Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋｓ）８５ａと、インターネット８５ｂと、通信相手端末（相手端末）１１ａ，１１ｂとをそなえて構成されている。
【００４１】
（１−１）コアネットワーク１０１，公衆網８５ａおよびインターネット８５ｂ
コアネットワーク１０１は、回線交換機およびパケット交換機が相互に接続され情報データを交換（スイッチ）するものであって、ＭＳ１０ａ〜１０ｃの位置登録データを保持するＨＬＲ（Ｈｏｍｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）１０１ａと、パケットをスイッチするＭＭＳ（Ｍｏｂｉｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｗｉｔｃｈｉｎｇ  Ｓｙｓｔｅｍ）１０１ｂおよびゲートウェイ機能を有するＧＭＭＳ（Ｇａｔｅｗａｙ  Ｍｏｂｉｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｗｉｔｃｈｉｎｇ  Ｓｙｓｔｅｍ）１０１ｃからなる交換機１０２を有する。公衆網８５ａは音声データ，ＦＡＸデータ等を伝送する加入者回線ネットワークであり、インターネット８５ｂはパケットを転送するネットワークである。
【００４２】
これにより、例えば、ＭＳ１０ａが送信した無線信号は、ＢＴＳ８３ａにて復調されてからＲＮＣ８４ａにて終端され、そして、その無線信号に含まれる情報データは、コアネットワーク１０１を介して、公衆網８５ａ又はインターネット８５ｂに伝送される。また、相手端末１１ａが送信した情報データは、公衆網８５ａ，インターネット８５ｂおよびコアネットワーク１０１をそれぞれ介し、ＨＬＲ１０１ａの位置登録データに基づいて、ＲＮＣ８４ａに転送され、ＢＴＳ８３ａにて無線信号に変調されて、ＭＳ１０ａに送信される。
【００４３】
なお、移動通信システム１００は、ｃｄｍａ２０００方式又はＷ−ＣＤＭＡ方式を用いることもできる。
（１−２）ＲＮＣ（基地局制御装置）８４ａ〜８４ｂ
ＲＮＣ８４ａ〜８４ｂは、複数のＢＴＳ８３ａ〜８３ｃを制御し、また、各ＢＴＳ８３ａ〜８３ｃとコアネットワーク１０１との間において複数のチャネルデータを多重して送受信するものであって、高速かつ大容量のデータ処理能力を要する。
【００４４】
各ＲＮＣ８４ａ〜８４ｂは、いずれも、ＢＴＳ８３ａ〜８３ｃとコアネットワーク１０１との間における情報データの転送機能と、各ＢＴＳ８３ａ〜８３ｃのそれぞれについて呼接続処理又は保守操作のための制御信号を送受信する制御機能と、チャネル割り当て，ハンドオーバ実施および発着信接続等の各機能を有する。これにより、公衆網８５ａ又はインターネット８５ｂからの情報データは、宛先に応じて複数のＢＴＳ８３ａ〜８３ｃのいずれかに対して転送され、また、複数のＢＴＳ８３ａ〜８３ｃからの情報データは、公衆網８５ａ又はインターネット８５ｂに対して転送される。
【００４５】
これらのＲＮＣ８４ａ〜８４ｂと複数のＢＴＳ８３ａ〜８３ｃと複数のＭＳ１０ａ〜１０ｃとは、いずれも、無線プロトコルを用いて制御信号およびデータ信号を送受信し、無線アクセスネットワーク（ＲＡＮ：Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）として機能している。この一方、ＲＮＣ８４ａ〜８４ｂとコアネットワーク１０１とは、有線により情報データを送受信している。
【００４６】
（１−３）本発明のマルチプロセッサシステム
本マルチプロセッサシステムは、ＲＮＣ８４ａ〜８４ｂに設けられた負荷分散装置に適用されている。ＲＮＣ８４ａ〜８４ｂが転送する情報データは、高速かつ大容量であり、また、複数のＢＴＳ８３ａ〜８３ｃおよびコアネットワーク１０１の双方からの情報データを処理するので、ＲＮＣ８４ａ〜８４ｂの各々についての負荷は、きわめて大きい。このため、負荷分散機能が各ＲＮＣ８４ａ〜８４ｂに設けられ、情報データについての全負荷が分散処理されるようになっている。
【００４７】
なお、本発明のマルチプロセッサシステムは、呼，ＭＳ１０ａ〜１０ｃ，ネットワーク端末，計算機又はＢＴＳ８３ａ〜８３ｃ等の装置単位に適用することもできる。
（１−４）ＭＳ１０ａ等
ＭＳ１０ａ〜１０ｃは、ＢＴＳ８３ａ〜８３ｃとの間において、情報データと、通信，制御に関する制御データとを無線通信するものであって、携帯電話１０ａ，ビデオ再生装置１０ｂ，テレビ電話１０ｃ等である。
【００４８】
携帯電話１０ａは、例えば図２に示すように、音声受話部（ＳＰＫ）８６ａ，音声送話部（ＭＩＣ）８６ｇと、音声送話部８６ｇからの信号を符号化した情報データを出力するとともに受信信号をデコードしたデータを音声受話部８６ａ又はディスプレイ（図示省略）に入力するベースバンド処理部８６ｂと、ベースバンド処理部８６ｂからの情報データを無線信号に変調するとともに受信した無線信号を復調する変復調部（ＴＲＸ）８６ｃと、変復調部８６ｃからの無線信号を増幅するとともに受信信号を増幅する送受信アンプ（Ｔ／Ｒ  ＡＭＰ）８６ｄとをそなえ、また、端末の識別情報を保持するキー情報保持部８６ｅと、ＭＳ１０ａ〜１０ｃを制御する移動機制御部（制御部）８６ｆとをそなえて構成されている。
【００４９】
なお、ビデオ再生装置１０ｂ，テレビ電話１０ｃについては、これらの無線送受信部が、携帯電話１０ａの変復調部８６ｃ等と同等なのでその説明を省略する。また、以下、ＭＳ（携帯電話）１０ａを用いて説明する。
（１−５）相手端末１１ａ，１１ｂ（図１参照）
相手端末１１ａ，１１ｂは、ともに、ＭＳ１０ａと通話し、又は情報データを送受信するものであって、例えば固定電話機，携帯電話又はパーソナルコンピュータ（パソコン）等である。
【００５０】
（１−６）ＢＴＳ８３ａ〜８３ｃ
図２は本発明の第１実施形態に係る移動通信システム１００の機能ブロック図であり、この図２において上述した符号と同一符号を有するものは同一機能を有する。
４８のＢＴＳ８３ａ〜８３ｃは、いずれも、ＭＳ１０ａと無線データを送受信するとともに、ＲＮＣ８４ａ〜８４ｂと有線データを送受信するものであって、無線信号を高パワー増幅し受信信号をローノイズ増幅する送受信アンプ８６ｄと、無線信号を変復調する変復調部８６ｃと、ベースバンド信号を処理するベースバンド処理部８６ｂと、ＲＮＣ８４ａ〜８４ｂとＢＴＳ８３ａ〜８３ｃとの間におけるデータ送受信を制御するハイウェイイン制御部（ＨＷ−ＣＮＴ）８７ａと、ＢＴＳ８３ａ〜８３ｃの内部の監視および制御をする基地局制御部（制御部）８７ｂとをそなえて構成されている。
【００５１】
また、基地局制御部８７ｂは、ＲＮＣ８４ａが有する共有メモリ３と同等の共有メモリを設けて構成することもできる（図示省略）。
なお、ＢＴＳ８３ｂ，８３ｃは、いずれも、ＢＴＳ８３ａと同一構成であり、重複した説明を省略する。ＢＴＳ数４８は、一例であり、この値に限定されるものではない。
【００５２】
（２）ＲＮＣ８４ａ〜８４ｂの構成
ＲＮＣ８４ａ〜８４ｂは、呼処理（Ｃａｌｌ  Ｐｒｏｃｅｓｓｉｎｇ）についての制御機能と負荷分散機能とを有する負荷分散装置（ＣＯＮＴ）１と、ＢＴＳ８３ａ〜８３ｃとの回線を終端するラインインターフェース（ＬＩＦ：Ｌｉｎｅ  ＩｎｔｅｒＦａｃｅ）８５ａと、ＢＴＳ８３ａ〜８３ｃおよび交換機１０２からのパケットをその宛先又は予め決定されたパスに基づいてスイッチングするＡＴＭスイッチ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ  Ｓｗｉｔｃｈ）８５ｂと、交換機１０２との回線を終端する出力インターフェース８５ｃと、呼処理等の制御信号を終端する終端部（ＳＵ）８５ｄとをそなえて構成されている。
【００５３】
また、終端部８５ｄは、移動機対向信号終端部（ＭＳＵ）と、外部装置対向信号終端部（ＥＳＵ）と、ＯＰＳ対向信号終端部（ＯＳＵ）とを有し、ＭＳ１０ａ，交換機１０２からの信号を負荷分散装置１に対して入力するようになっている。
（３）負荷分散装置（マルチプロセッサシステム）１
図３は本発明の第１実施形態に係るＲＮＣ８４ａ〜８４ｂの概略的なブロック図である。この図３に示すもので上述した符号と同一符号を有するものは同一機能を有する。
【００５４】
（３−１）負荷分散装置１
負荷分散装置１の機能は、ＢＴＳ８３ａ〜８３ｃおよび交換機１０２（図１参照）等の外部装置とＲＮＣ８４ａ〜８４ｂ自身の各モジュールとの通信，呼接続，保守操作のための制御信号の送受信およびこれらの処理についての負荷分散である。この負荷分散装置１は、プロセッサ間通信装置（バス制御部：ＢＣＯＮＴ［Ｂｕｓ  Ｃｏｎｔｒｏｌｌｅｒ］）５と、呼処理部（ＣＰ：Ｃａｌｌ  Ｐｒｏｃｅｓｓｉｎｇ）２ａ〜２ｅと、共有メモリ（ＣＭ：Ｃｏｍｍｏｎ  Ｍｅｍｏｒｙ）３と、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）４と、デバッガ（ＤＢ：Ｄｅｂｕｇｇｅｒ）５ｆと、通信用のバス５ｅとをそなえて構成されている。
【００５５】
（３−２）呼処理部２ａ〜２ｅ
各呼処理部２ａ〜２ｅの機能は、無線チャネルの割り当て，着信呼に関する呼情報処理，グローバルアドレスとローカルアドレスとの変換処理および主制御であって、基板（ＣＰ基板又はＣＰカード）上に、プロセッサ２２ａと、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２３と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２４とが設けられている。
【００５６】
図４は本発明の第１実施形態に係る負荷分散装置１の要部を示す図である。この図４に示す負荷分散装置１は、通信呼を処理する複数のプロセッサ２２ａ〜２２ｅと、例えば交換機１０２等の外部装置からの通信呼をプロセッサ２２ａ〜２２ｅの負荷に応じて分散する負荷分散制御部（分散制御部）９と、プロセッサ２２ａ〜２２ｅがアクセスしうる共有メモリ３とをそなえている。そして、共有メモリ３が、通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブル（図５等参照）７と、キュー管理情報テーブルのキュー管理情報の更新履歴を記録するメモ記録部（更新履歴記録領域，図８参照）８とを設けている。
【００５７】
なお、呼処理部２ａの機能は、プロセッサ２２ａとＲＯＭ２３とＲＡＭ２４とが協働するソフトウェアにより発揮される。また、呼処理部２ｂ〜２ｅの各機能も同様に、各ＣＰ基板上に、各プロセッサ２２ｂ〜２２ｅが設けられ、ＲＯＭ２３，ＲＡＭ２４が協働して発揮される。そして、呼処理部２ａ〜２ｅが協働することにより、４８のＢＴＳ８３ａ〜８３ｃの呼処理についての全負荷が分散される。
【００５８】
（３−３）プロセッサ間通信装置５
プロセッサ間通信装置５は、各プロセッサ２２ａ〜２２ｅが相互に信号を送受信するための制御機能を有する。負荷分散装置１は、プロセッサ２２ａ〜２２ｅのうちの例えばプロセッサ２２ａを、マスタプロセッサとし、他のプロセッサ２２ｂ〜２２ｅからの特定信号を受信するようにしている。換言すれば、他のプロセッサ２２ｂ〜２２ｅは、いずれも、マスタプロセッサ２２ａと信号を送受信するために、プロセッサ間通信装置５を利用しているのである。
【００５９】
（３−４）負荷分散制御部（分散制御部）９
分散制御部９は、交換機１０２およびＢＴＳ８３ａ〜８３ｃからの情報データおよび制御データを受信し、通信呼の処理の負荷を各呼処理部２ａ〜２ｅに分散するものである。また、この負荷分散機能は、例えばマスタプロセッサ２２ａにより発揮される。なお、他のプロセッサ２２ｂ〜２２ｅが負荷分散機能を実現することもできる。
【００６０】
（３−５）共有メモリ３
共有メモリ３に保持される情報は、複数のプロセッサ２２ａ〜２２ｅが相互に引き継ぎすることが必要な情報、又は消失してはならない情報である。例えば、ＭＳ１０ａと相手端末１１ａとが、「もしもし」，「はいはい」等の通話状態になった場合に障害が発生すると、両者間の通話状態は維持されているので、この通話状態を表す呼情報は、他のプロセッサ２２ａ〜２２ｅに引き継がれなければならない。
【００６１】
そして、各プロセッサは、負荷を分散させるために、負荷に応じたタスクを割り当てられて呼を処理する。
図５は本発明の第１実施形態に係る共有メモリ３の領域を模式的に示す図である。この図５に示す共有メモリ３は、各プロセッサ２２ａ〜２２ｅが共有してアクセスするものであって、キュー管理情報テーブル７と、リソース（キュー）６ａ〜６ｃ，６ｑと、これら以外のデータを保持するテーブル領域６ｄと、メモ記録部８とをそなえて構成されている。
【００６２】
リソース６ａ〜６ｃは、それぞれ、複数の呼に関する呼情報Ａ〜Ｃを保持するために獲得されたメモリ領域であり、このメモリ領域に複数のキューＡ〜Ｃが生成されている。リソース６ｑも、複数の呼に関する呼情報Ｄを保持するために獲得されたメモリ領域であり、キューＤが生成されている。ＲＮＣ８４ａ〜８４ｂは、それぞれ、大量の呼を入力されるので、大量の呼を効率的に管理するために、一装置について一リソースを割り当てるようにしている。すなわち、共有メモリ３は、一般的に有するリソース割り当て機能によりＢＴＳ８３ａ〜８３ｃのそれぞれについてリソース割り当てを行なう。
【００６３】
例えば図２１（ａ）に示す共有メモリ２０３は、３台のＢＴＳ８３ａ〜８３ｃに対応するリソースＡ〜Ｃが割り当てられており、受信された複数の呼は、それぞれ、キューＡ〜Ｃに挿入され、また、取り出し処理される（デキュー）。従って、各キューＡ〜Ｃは、挿入された数が異なり、キュー領域の範囲が異なるので、キュー管理情報テーブル７は、呼情報を保持するリソースを管理するキューについてのキュー管理情報を保持するのである。
【００６４】
（３−６）キュー管理情報テーブル７
キュー管理情報テーブル７は、各プロセッサ２２ａ〜２２ｅによって獲得された呼情報を保持するリソースを管理するキューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持する。この情報要素とは、例えば、キュー管理数（全キュー数），先頭キューアドレス，前キューアドレスおよび後キューアドレスであり、また、最終キューアドレスをも含めることがある。
【００６５】
これにより、各情報要素を用いることによって、効率的にキュー管理が可能となる。また、キュー管理情報テーブル７は、各プロセッサ２２ａ〜２２ｅによって獲得された呼情報を保持するリソースを管理するキューについての少なくともキュー管理数と先頭キューアドレスとを含むキュー管理情報を保持する。この２種類の要素によれば、各キューを特定できるからである。
【００６６】
（３−７）メモ記録部８
次に、メモ記録部８（図８参照）は、キュー管理情報テーブル７のキュー管理情報の更新履歴を記録するものである。すなわち、メモ記録部８は、キュー管理情報テーブル７のキュー管理情報に書き込む複数の更新情報要素（例えば、キュー管理数，先頭キューアドレス，前キューアドレス，後キューアドレス）を記録する。メモ記録部８は、例えば３個のメモ記録（メモ記録部）１，２，３を確保してキュー管理数等を記録している。例えば、メモ記録１，２は、それぞれキュー管理数，先頭キューアドレスを一時的に書き込むこともでき、また、メモ記録１，２，３は、それぞれ、取り出しするキューの番号，前キューアドレス，次キューアドレスを一時的に書き込むこともできる。すなわち、メモ記録部８は、キュー管理情報テーブル７に保持されたキュー管理数と先頭キューアドレスとに書き込む更新情報要素を記録する。
【００６７】
そして、各呼処理部２ａ〜２ｅ（図４参照）は、分散制御部９から制御信号を受信すると、共有メモリ３から物理的なリソースを獲得し、獲得したリソースにキューを生成し、その生成したキューに関する情報は、キュー管理情報テーブル７に集中的に保持される。
これにより、各プロセッサ２２ａ〜２２ｅは、キューを参照し、キューを更新しながら信号処理を行なう。また、例えば呼処理部２ａが過負荷のときに、他の呼処理部２ｂ〜２ｅがデータ処理をする。
【００６８】
（３−８）クロック部８８等
なお、ＲＮＣ（図３参照）は、基準タイミングを生成するクロック部（ＣＬＫ）８８，ダイバーシチハンドオーバ処理を行なうトランクカードＤＨＴ（Ｄｉｖｅｒｓｉｔｙ  Ｈａｎｄｏｖｅｒ  Ｔｒｕｎｋ  ｃａｒｄ）８９ａ，無線回線のＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤについて多重分離を処理するマック多重分離カードＭ−ＭＵＸ（Ｍａｃ  Ｍｕｌｔｉｐｌｅｘｅｒ）８９ｂ，ＢＷＣをも有する。
【００６９】
また、ＨＤＤ４ａ（図３参照）は、ファームウェアについて取得された情報を保持するものである。デバッガ５ｆは、共有メモリ３の書き込みおよび読み出しを行なうものであって、書き込みおよび読み出しのための信号をバス５ｅに出力することによりこの書き込みおよび読み出しが可能となる。
（３−９）実装の一例
負荷分散装置１は、ＲＮＣ８４ａ〜８４ｂの装置架の背面部分の基板（バックボード）に設けられている。
【００７０】
図６は本発明の第１実施形態に係る負荷分散装置を上方から見た模式図である。この図６に示す負荷分散装置１は、平面的なバックボード８２に、プロセッサ間通信装置５，呼処理部２ａ〜２ｅ，デバッガ５ｆ，共有メモリ３，クロック部８８および給電部８８ａの各機能を有する基板が、垂直に差し込まれるようになっている。すなわち、各機能が基板ごとに実現されており、これにより、保守等の負担が軽減され、システム仕様の変更に対して柔軟に対応できる。なお、図６に示す陰影がある部分は、バックボード８２の上面を表している。
【００７１】
各基板はそれぞれＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：識別子）を割り当てられ、信号伝送路を介して相互に通信できるようになっている。これにより、共有メモリ３を介してプロセッサ相互間が通信可能となる。
この相互通信の一例は、各プロセッサ２２ａ〜２２ｅが、バス５ｅに出力されたデータに含まれるＩＤを取得し、この取得したＩＤと予めレジスタ（図示省略）等に格納されたＩＤとを比較し、そのデータを用いるか否かを判別するのである。
【００７２】
また、各基板は、脱着可能になっており、呼処理部２ａ〜２ｅの処理能力に応じて、ＣＰ基板の数を増減できる。負荷分散装置１は、５枚の現用のＣＰ基板と１枚の予備用のＣＰ基板との全部で６枚のＣＰ基板が設けられ、４８のＢＴＳ８３ａ〜８３ｃに対応可能となっている。５枚のＣＰ基板の１枚が故障した場合にそなえて、予備用のＣＰ基板（図示省略）が設けられている。
【００７３】
ＲＮＣ８４ａ〜８４ｂは、複数の現用系（アクティブ：ＡＣＴ）のＣＰ基板と、予備系（スタンバイ：ＳＴＢＹ）のＣＰ基板とをそなえた冗長構成を用いることができる。ここで、予備系のＣＰ基板は、現用系のＣＰ基板の故障又は保守のために設けられており、いずれかの現用系ＣＰ基板が故障すると、外部装置と接続された物理的な通信パスは、故障したＣＰ基板から切断されて、予備系のＣＰ基板に接続されるようになっている。これにより、負荷分散型マルチプロセッサシステムが構成される。
【００７４】
さらに、４８のＢＴＳ８３ａ〜８３ｃのそれぞれに対応するリソースが、ＣＭ基板の共有メモリ３に確保され、また、プロセッサ２２ａ〜２２ｅと共有メモリ３とが協働することにより、ＢＴＳ８３ａ〜８３ｃのＣＰ基板が過負荷のときに、他のＢＴＳ８３ａ〜８３ｃ用のＣＰ基板がＢＴＳ８３ａ〜８３ｃのデータ処理を行なう。
【００７５】
このように、負荷分散装置１は、きわめて多量の呼処理データを処理でき、かつ処理対象となる呼を、多量の呼の中から認識し適切に処理でき、これにより、データ多重およびデータ分離が可能となる。
（３−１０）リカバリ処理
キュー操作するためのプロセッサ２２ａ〜２２ｅに障害が発生すると、現実のキュー管理数とキューに書き込まれたキュー管理数との相違、又は次キューアドレスと以前の次キューアドレスとの相違が生じる。
【００７６】
各プロセッサ２２ａ〜２２ｅは、障害発生を検出する検出機能を有し、本実施形態においては、マスタプロセッサ２２ａの障害検出機能が動作するようにしている。具体的には、マスタプロセッサ２２ａは、ハードウェアからの外部割り込みによって、リカバリ処理の契機とし、また、例えばマスタプロセッサ２２ａによるソフトウェアを用いて、キュー管理情報テーブル７とメモ記録部８との両状態を比較する。
【００７７】
そして、障害を検出したマスタプロセッサ２２ａは、プログラムが正常に実行されるように、リカバリ処理を行なう。このリカバリ処理機能は、例えば呼処理部２ａおよび共有メモリ３により実現されるが、他の呼処理部２ｂ〜２ｅ（プロセッサ２２ｂ〜２２ｅによるソフトウェア）および共有メモリ３により実現することもできる。
【００７８】
（３−１１）判定部（判定手段）２５ａおよび復旧部（復旧手段）２５ｂ
判定部２５ａと復旧部２５ｂとは、いずれも、各呼処理部２ａ〜２ｅに設けなければならない。これは、プロセッサ２２ａ〜２２ｅのいずれかが、共有メモリ３にアクセスしたときに障害が発生しても、正常に復旧処理を行なえるハードウェアとしてのプロセッサ２２ａ〜２２ｅと、ソフトウェアとしての呼処理部２ａ〜２ｅとが確保されるためである。
【００７９】
図７は本発明の第１実施形態に係る判定部および復旧部の概略的なブロック図であり、この図７に示す判定部２５ａおよび復旧部２５ｂは、いずれも、各呼処理部２ａ〜２ｅに設けられている。
ここで、判定部２５ａは、プロセッサ２２ａ〜２２ｅのうちのいずれかのプロセッサが、キュー管理情報へのアクセス時に障害が発生したときに、キュー管理情報テーブルに保持されたキュー管理情報と、メモ記録部８に記録された更新履歴情報とに基づいて、リカバリ処理の要否を判定するものである。
【００８０】
呼処理部２ａおよび共有メモリ３は、協働することにより、判定部２５ａと、復旧部２５ｂとの各機能を発揮している。
また、復旧部２５ｂは、判定部２５ａがリカバリ処理を必要と判定した場合に、更新履歴情報に基づいてキュー管理情報をリカバリするものである。
共有メモリ３のリソースの獲得および解放は、常時、キュー管理されており、プロセッサ２２ａが、キュー管理に必要な情報要素（キュー管理数，先頭キューアドレス，前キューアドレス，後キューアドレス）をアクセスしたときに障害が発生すると、判定部２５ａは、メモ記録部８の内容に基づいて、共有メモリ３のキュー管理情報テーブル７が破壊されたか否かを判定する。判定部２５ａは、キュー管理情報テーブル７が破壊されていた場合は復旧部２５ｂに対して完全リカバリ処理を実施させ、また、キュー管理情報テーブル７が破壊されていない場合は復旧部２５ｂに対してリカバリ処理を行なわせない。
【００８１】
このように、各プロセッサ２２ａ〜２２ｅは、メモ記録に基づいて共有メモリ３のキュー管理情報を参照して情報をリカバリするので、きわめて短時間あるいは瞬時にキュー管理情報テーブル７をリカバリできる。
（４）動作説明
上述の構成により、本発明の共有メモリ３のキュー管理情報テーブル７のリカバリ処理方法について詳述する。
【００８２】
負荷分散装置１は、制御信号を受信すると、負荷を各プロセッサ２２ａ〜２２ｅに振り分けて、共有メモリ３のリソースをキューにより管理する。各プロセッサ２２ａ〜２２ｅは、キュー管理情報テーブル７をアクセスするときに、キュー管理情報テーブル７に書き込む内容を、まず、共有メモリ３のメモ記録部８に一時的に書き込み、この書き込みした内容を保存する。
【００８３】
ここで、複数のキューＡ〜Ｄにわたってデータが保持されている場合において、複数のキューＡ〜Ｄのうちの例えばキューＣを操作する場合、各プロセッサ２２ａ〜２２ｅがそのキューＣにアクセスしているときに、プロセッサ２２ａ〜２２ｅのうちのいずれかのプロセッサに障害が発生すると、その障害をリカバリするリカバリ処理が行なわれる。
【００８４】
ここで、ＲＮＣ８４ａ〜８４ｂは、いずれも、負荷分散装置１を２枚設けてもよく、このようにすれば、障害発生が検出された後は、まず、現用系のプロセッサと、予備用のプロセッサとを、相互に変更する処理が行なわれる。
共有メモリ３にあるキュー管理情報テーブル７を各プロセッサ２２ａ〜２２ｅがアクセスしている最中に障害が発生し、リカバリ後はキュー管理情報テーブル７のキュー管理数又は先頭キューアドレスと実体に不一致が発生している場合がある。この場合、アクセス時に記録しておいたメモ情報に基づいてキュー管理情報テーブル７をリカバリさせるのである。
【００８５】
以下、先頭キューを取り出す方法と、リカバリ処理方法とについて説明する。本発明のマルチプロセッサシステムにおけるキュー取り出し方法は、通信呼を処理するプロセッサ２２ａ〜２２ｅとプロセッサ２２ａ〜２２ｅがアクセスしうる共有メモリ３とを有するマルチプロセッサシステム（例えば負荷分散装置１）におけるものである。
【００８６】
まず、各プロセッサ２２ａ〜２２ｅのうちのいずれかのプロセッサ（例えばプロセッサ２２ａ自身）が獲得したリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する（参照ステップ）。すなわち、キュー管理数，先頭キューアドレス，前キューアドレスおよび後キューアドレスが参照される。
【００８７】
次に、各プロセッサ２２ａ〜２２ｅは、キュー管理情報テーブル７のキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、メモ記録部（更新履歴記録領域）８に記録する（記録ステップ）。すなわち、更新されるキュー管理数，先頭キューアドレス，前キューアドレス，後キューアドレスがメモ記録部８に記録される。
【００８８】
そして、各プロセッサ２２ａ〜２２ｅは、更新履歴をキュー管理情報テーブル７に書き込むのである（書き込みステップ）。
キュー取り出し方法についてさらに詳述する。
各プロセッサ２２ａ〜２２ｅは、前記参照に当たり、キュー管理数，先頭キューアドレス，前キューアドレスおよび後キューアドレスのうちのキュー管理数と先頭キューアドレスとを情報要素として参照する。
【００８９】
次に、前記記録に当たり、各プロセッサ２２ａ〜２２ｅは、更新したキュー管理数（第１更新値）、又は更新した先頭キューアドレス（第２更新値）を更新情報要素として記録する。
そして、前記書き込みに当たり、各プロセッサ２２ａ〜２２ｅは、更新したキュー管理数、又は更新した先頭キューアドレスをキュー管理情報テーブル７に書き込む。
【００９０】
以下に、キュー取り出し方法を具体的に説明する。
（５）先頭キューを取り出す方法。
図８，図９を参照して先頭キュー（リソース）を削除する方法について説明する。ここで、図８に示すステップＪ１〜Ｊ５は、図９に示すステップＪ１〜Ｊ５に対応させている。
【００９１】
図８は本発明の第１実施形態に係る先頭キュー取り出し方法を説明するための図である。この図８には、メモ記録部８と、キュー管理情報テーブル７と、キューＡ〜Ｄとが表示されており、また、紙面の上半分はキュー取り出し前における、メモ記録部８，キュー管理情報テーブル７およびキューの状態を表す。下半分はキュー取り出し後におけるそれらの状態を表す。なお、上から下への方向は時間経過を表す。ここで、キュー取り出し前は、キューＡ〜Ｄが生成されており、また、キューＡ〜Ｄから先頭キューＡを取り出すようにしている。キュー管理情報テーブル７には先頭キューアドレスと、キュー列Ａ〜Ｄを形成している全キュー個数が保持されている。
【００９２】
図９は本発明の第１実施形態に係る先頭キュー取り出し処理を説明するためのフローチャートである。プロセッサ２２ａを一例とし、この先頭キュー取り出し処理を説明する。なお、プロセッサ２２ｂ〜２２ｅについての処理も、プロセッサ２２ａの処理と同一である。
（Ｊ１）プロセッサ２２ａは、先頭にキューイングされているキュー（リソース）を取り出す。プロセッサ２２ａが、先頭キューを取り出す場合、キュー管理情報テーブル７より先頭キューアドレスを参照することによりキューＡを参照する。
【００９３】
（Ｊ２）プロセッサ２２ａは、メモ記録２に先頭にキューイングされているキュー（リソース）の次キューアドレスを設定する。先頭にキューイングされているキュー（リソース）の次キューアドレスＢを取り出し、メモ記録２に設定する。
（Ｊ３）プロセッサ２２ａは、メモ記録１にキュー管理数（全個数）を保持し、メモ記録１にキュー管理情報テーブル７にあるキュー管理数４から１を減算した３を設定する。
【００９４】
なお、ステップＪ２又はステップＪ３において、プロセッサ２２ａが、メモ記録１，２を書き換えているときに、障害が発生した場合（ステップＪ６ａ）、リカバリは行なわれない（ステップＪ６ｂ）。
（Ｊ４）プロセッサ２２ａは、キュー管理情報テーブル７の先頭キューアドレスをキューＡからキューＢのアドレスに書き換える。
【００９５】
（Ｊ５）プロセッサ２２ａは、キュー管理情報テーブル７のキュー管理数について、キューＡを取り出したことにより１を減算して３に設定する。
なお、ステップＪ４又はステップＪ５において、プロセッサ２２ａが、キュー管理情報テーブル７を書き換えているときに障害が発生した場合（ステップＪ７ａ）、判定部２５ａは、リカバリ処理を必要と判定し、メモ記録１，２を書き換える（ステップＪ７ｂ）。
【００９６】
これにより、リカバリ処理が簡素化され、かつ高速リカバリが実現する。
（６）リカバリ処理方法
本発明のマルチプロセッサシステムにおけるテーブルリカバリ処理方法は、通信呼を処理する複数のプロセッサ２２ａ〜２２ｅと、プロセッサ２２ａ〜２２ｅがアクセスしうる共有メモリ３とを有するマルチプロセッサシステムにおけるものである。
【００９７】
まず、プロセッサ２２ａ〜２２ｅのうちの例えばプロセッサ２２ａは、自分自身が獲得したリソース管理キューの大きさとキューの位置とを特定する（キュー管理数，先頭キューアドレス，前キューアドレスおよび後キューアドレス）の情報要素からなるキュー管理情報を保持するキュー管理情報テーブル７のキュー管理情報と、キュー管理情報テーブル７のキュー管理情報に書き込む更新したキュー管理数等の更新情報要素（キュー管理数，先頭キューアドレス，前キューアドレスおよび後キューアドレス）からなる更新履歴を記録するメモ記録部８の更新履歴情報とに基づいて復旧処理の要否を判定する（判定ステップ）。
【００９８】
そして、前記のいずれかのプロセッサは、前記判定にて復旧要と判定された場合に、更新履歴情報に基づいてキュー管理情報を復旧するのである（復旧ステップ）。
これにより、複数のプロセッサ２２ａ〜２２ｅが協働するので、システムは障害に対して強固になる。
【００９９】
次に、テーブルリカバリ処理方法についてさらに詳述する。
復旧処理の要否の判定に当たり、複数のプロセッサ２２ａ〜２２ｅのうちのいずれかのプロセッサは、キュー管理情報テーブル７に保持されたキュー管理情報のキュー管理数又は先頭キューアドレスと、メモ記録部８のキュー管理数又は先頭キューアドレスとの一致／不一致に基づいて要否を判定する。
【０１００】
また、復旧に当たり、いずれかのプロセッサは、その要否に基づいて、メモ記録部８のキュー管理数又は先頭キューアドレスを、キュー管理情報テーブル７のキュー管理数又は先頭キューアドレスに書き換える。
このように、障害発生後のリカバリ処理が迅速に行なえる。
次に、図１０を参照して先頭キューの取り出し中に障害が発生した場合のリカバリ処理方法について説明する。
【０１０１】
図１０は本発明の第１実施形態に係る先頭キュー取り出しのリカバリ処理を説明するためのフローチャートである。プロセッサ２２ａ〜２２ｅは、いずれも、以下に説明するリカバリ処理を実施でき、プロセッサ２２ａについて説明し、プロセッサ２２ｂ〜２２ｅについての詳細な説明を省略する。ここで、図１０に示す符号１〜６は、それぞれ、以下の（６−１）〜（６−６）に対応する。
【０１０２】
（６−１）判定部２５ａは、メモ記録２の先頭キューアドレスとキュー管理情報テーブル７の先頭キューアドレスとが一致しているか判定する。
（６−２）判定部２５ａは、判定結果が一致していない場合は、「不一致」ルートを通り、メモ記録２を書き換え後、キュー管理情報テーブル７の情報を書き換える前に障害が発生したため一致していない状態である。従って、メモ記録を無視してリカバリ処理は実行されない。
【０１０３】
（６−３）判定部２５ａは、判定結果が一致している場合、一致している場合はメモ記録１を書き換え、およびキュー管理情報テーブル７の情報が正常時、書き換えられた状態を示している。
（６−４）判定部２５ａは、メモ記録１のキュー管理数とキュー管理情報テーブル７のキュー管理数が一致しているか判定する。
【０１０４】
（６−５）判定結果が一致してない場合、判定部２５ａは、メモ記録１を書き換え、およびキュー管理情報テーブル７の一部が正常時、書き換えられていない状態である。従って、メモ記録１を参照し、キュー管理情報テーブル７のキュー管理数を３に書き換えることによりリカバリさせる。
（６−６）判定結果が一致している場合、判定部２５ａは、キュー管理情報テーブル７および先頭キューが正常時、取り出し終了した状態である。従って、リカバリは不要となる。
【０１０５】
（６−７）前記（６−１）にて判定部２５ａの判定結果が「不一致」の場合は、「不一致」と付されたルートを通り、キュー管理情報テーブル７を書き込む前に障害が発生しているため、判定部２５ａは破損していないと判定し、リカバリ処理は行なわない。
（６−８）前記（６−４）にて判定部２５ａは、キュー管理数が一致しないと判定した場合は、ＮＯルートを通り、キュー管理情報テーブル７の先頭キューアドレスが書き換え済みであり、障害が発生していると判定する。
【０１０６】
（６−９）判定部２５ａは、メモ記録のキュー管理数を管理数キュー管理情報テーブル７のキュー管理数に置換するリカバリ処理を行なう。
なお、プロセッサ２２ｂ〜２２ｅの先頭キュー取り出し動作も、プロセッサ２２ａの動作と同様である。
このように、本リカバリ処理方法は、共有メモリ３のリソースの獲得，開放が、キュー管理され、このキュー管理に必要なキュー管理数，先頭キューアドレス，前キューアドレスおよび後キューアドレス等の情報領域がアクセスされる前にメモ記録部８として保存される。これにより、リカバリ処理が単一時間でかつ高速に可能となる。従って、二重障害の誘発が回避される。
【０１０７】
そして、キュー管理情報テーブル７に関し、あたかもメモを記録するだけでよい処理が可能となり、リカバリ処理に要する必要最小のデータを用いてリカバリが可能となり、システムの簡素化が図れる。
（７）複数のキュー間に位置するキューの取り出し方法
図１１，図１２を参照して、キューＡ〜Ｄの間にキューイングされているキューＣ（以下、図１１，図１２において途中キューＣと称する。）を取り出して削除する方法について説明する。なお、プロセッサ２２ａについて説明し、このプロセッサ２２ａと同一機能を有するプロセッサ２２ｂ〜２２ｅについての重複説明を省略する。これらの図１１，図１２に示す符号Ｋ１〜Ｋ６は相互に対応している。
【０１０８】
図１１は本発明の第１実施形態に係る途中キューＣの取り出し方法を説明するための図であり、キュー管理情報テーブル７は先頭キューＡのアドレスを保持している。
図１２は本発明の第１実施形態に係る途中キューＣの取り出し処理を説明するためのフローチャートである。
【０１０９】
（Ｋ１）プロセッサ２２ａは、途中キューＣを取り出す。
（Ｋ２）プロセッサ２２ａは、キュー管理情報テーブル７にある先頭キューＡのアドレスを取得し、先頭キューＡからキューＤの方向に、順次、キューを辿ることにより、途中キューＣを参照し、メモ記録１に途中キューＣが設定される。
（Ｋ３）プロセッサ２２ａは、メモ記録２に途中キューＣの前キューＢのアドレスを書き込み、途中キューＣを取り出す。このため、キューＢの次キューは、途中キューＣからキューＤに変更されるので、プロセッサ２２ａは、メモ記録３に、途中キューＣの前キューＢのアドレスをアドレス（Ｂ）に設定する。
【０１１０】
（Ｋ４）途中キューＣの取り出しにより、キューＤが変更となるので、プロセッサ２２ａは、メモ記録部３に途中キューＣの次キューアドレス（Ｄ）を設定する。
ステップＫ２，Ｋ３，Ｋ４のそれぞれにおいて、プロセッサ２２ａが、キュー管理情報テーブル７を書き換えているときに障害が発生した場合（ステップＫ７ａ）、判定部２５ａは、リカバリ処理を不要と判定する（ステップＫ７ｂ）。
【０１１１】
（Ｋ５）プロセッサ２２ａは、メモ記録部３にキューＢの次キューＤのアドレスをＣからＤに書き換える。
（Ｋ６）プロセッサ２２ａは、キューＤの前キューアドレスをＣからＢに書き換える。
なお、ステップＫ５又はステップＫ６において、プロセッサ２２ａが、キュー管理情報テーブル７を書き換えているときに障害が発生した場合（ステップＫ８ａ）、判定部２５ａは、リカバリ処理を必要と判定し、復旧部２５ｂは、メモ記録１〜３の内容をキュー管理情報テーブル７に書き換える（ステップＫ８ｂ）。
【０１１２】
なお、プロセッサ２２ｂ〜２２ｅの途中キューＣの取り出し動作も、プロセッサ２２ａの動作と同様である。
（８）リカバリ処理方法
図１３を参照して途中キューＣの取り出し中に障害が発生した場合のリカバリ処理方法について説明する。
【０１１３】
図１３は本発明の第１実施形態に係る途中キュー取り出しのリカバリ処理を説明するためのフローチャートである。以下に説明する判定部２５ａは、プロセッサ２２ａの動作と同様である。この図１３に示す符号１〜７は、それぞれ、以下に示す（８−１）〜（８−７）に対応する。
（８−１）判定部２５ａは、メモ記録１の情報から途中キューＣを導き出し、途中キューＣの前キューアドレスとメモ記録２の前キューアドレスとの一致／「不一致」を判定し、また、判定部２５ａは、次キューアドレスとメモ記録部３の次キューアドレスとの一致／不一致を判定する。
【０１１４】
（８−２）判定結果が一致していない場合
既にデキューされているため、メモ記録２の前キューアドレスと途中キューＣの前キューアドレスとは一致せず、また、メモ記録部３の次アドレスと途中キューＣの次キューアドレスとは一致しない。この場合、ＮＯルートを通り、リカバリは行なわれない。
【０１１５】
（８−３）判定結果が一致している場合
判定部２５ａは、ＹＥＳルートを通り、メモ記録１の途中キューＣのアドレスと、キューＢの次キューアドレスとが同一であるか否かを判定する。
（８−４）判定結果が一致していない場合
ＮＯルートを通り、リカバリは行なわれずに、処理は終了する。
【０１１６】
（８−５）判定結果が一致している場合
前記（８−３）における判定において、判定部２５ａは、メモ記録１の途中キューＣアドレスとキューＤの前キューアドレスとが同一であるか否かを判定する。
（８−６）判定結果が一致していない場合
判定部２５ａが、取り出しが未だ完了していない場合であり、ＮＯルートを通り、キューＢの次キューアドレスに途中キューＣが設定される。これにより、リカバリ処理が実行される。
【０１１７】
（８−７）判定結果が一致している場合
取り出し処理は実行されていない場合であり、ＹＥＳルートを通り、デキュー処理は行なわれていないので、リカバリ処理は不要である。
（９）従来のテーブルリカバリ処理方法と本テーブルリカバリ処理方法との比較。
【０１１８】
障害発生時のキュー管理情報テーブル７について、従来のテーブルリカバリ処理方法は、各プロセッサ２２ａ〜２２ｅが、先頭キューに接続されている途中キューと、最終キューに接続されている途中キューとの双方向から複数接続されたキューを辿っていき、双方向のキューの個数をカウントし、そのカウント値の成否に基づいてキュー管理情報テーブル７をリカバリさせていた。従って、プロセッサ２２ａ〜２２ｅは、障害発生を認識するために多くの時間を要した。
【０１１９】
これに対して、本テーブルリカバリ処理方法によれば、各プロセッサ２２ａ〜２２ｅは、共有メモリ３のリソースの獲得，開放をキュー管理しており、また、プロセッサ２２ａ〜２２ｅが、キュー管理に必要な情報領域にアクセスしたときに障害が発生すると、復旧部が、メモ記録に基づいて共有メモリ３のキュー管理情報を参照して情報をリカバリするので、きわめて短時間あるいは瞬時にキュー管理情報テーブル７をリカバリできる。
【０１２０】
（１０）キューの挿入方法
図１４〜図１６を参照してキューＤを挿入する方法ついて説明する。
図１４は本発明の第１実施形態に係るキューを挿入する方法を説明するための図であり、３個のキューＡ〜Ｃに、キューＤを挿入して接続する方法について示されている。キュー管理情報テーブル７には先頭キューアドレスとキューに接続している全個数が保持されている。
【０１２１】
なお、エンキュー方法は、例えばプロセッサ２２ａが用いる場合について説明するが、プロセッサ２２ｂ〜２２ｅの先頭キュー取り出し動作も、プロセッサ２２ａの動作と同様である。
図１５は本発明の第１実施形態に係るエンキュー処理を説明するためのフローチャートである。
【０１２２】
（１０−１）キューＤの作成
プロセッサ２２ａは、最終のキューになるためキューＤの次キューアドレスは最終（ＥＮＤ）を保持する（ステップＬ１）。
（１０−２）プロセッサ２２ａは、メモ記録２にキューＣのアドレスを保持する（ステップＬ２）。
【０１２３】
（１０−３）プロセッサ２２ａは、メモ記録部３にエンキューするキューＤのアドレスを設定する（ステップＬ３）。
（１０−４）プロセッサ２２ａは、メモ記録１にキュー管理数（全個数）を保持する。ここで、メモ記録１にキュー管理情報テーブル７にあるキュー管理数からキューを接続することにより１を加算して（＋１して）４を設定する（ステップＬ４）。
【０１２４】
（１０−５）プロセッサ２２ａは、キューＣの次キューアドレスを書き換え
キュー管理情報テーブル７にある先頭キューアドレスからキューを辿ることにより変更するキューＣを検索し、次キューアドレスを最終（ＥＮＤ）からＤに書き換える（ステップＬ５）。
（１０−６）キュー管理情報テーブル７のキュー管理数を書き換えキュー管理情報テーブル７のキュー管理数はキューＤを接続することにより、プロセッサ２２ａは、４に設定する（ステップＬ６）。
【０１２５】
なお、ステップＬ２〜ステップＬ４において、プロセッサ２２ａが、メモ記録１，２を書き換えているときに、障害が発生した場合（ステップＬ６ａ）、リカバリは行なわれない（ステップＬ６ｂ）。
また、ステップＬ５又はステップＬ６において、プロセッサ２２ａが、キュー管理情報テーブル７を書き換えているときに障害が発生した場合（ステップＬ７ａ）、判定部２５ａは、リカバリ処理を必要と判定し、メモ記録１，２を書き換える（ステップＬ７ｂ）。
【０１２６】
（１１）エンキューのリカバリ処理方法
図１６は本発明の第１実施形態に係るエンキューのリカバリ処理を説明するためのフローチャートである。エンキュー中に障害が発生した場合のリカバリ処理方法について説明する。この図１６に示す符号１〜６は、それぞれ、以下に示す（１１−１）〜（１１−６）に対応する。
【０１２７】
（１１−１）判定部２５ａは、メモ記録２のキューＣの次キューアドレスと、メモ記録部３のキューＣの次キューアドレスとが一致しているかを判定する。
（１１−２）判定結果が一致していない場合
判定部２５ａは、ＮＯルートを通り、キューＣは破損していないと判定され、リカバリ処理行なわれない。すなわち、キューＣの次キューアドレスを書き込む前に障害が発生したので、キューは破損しておらず、従って、リカバリ処理は不要と判定され、処理が終了する。
【０１２８】
（１１−３）判定結果が一致している場合
この場合は、判定部２５ａは、ＹＥＳルートを通り、メモ記録部３とキューＣの次キューアドレス情報が正常時、書き換えられた状態に相当する。
（１１−４）判定部２５ａは、メモ記録１のキュー管理数とキュー管理情報テーブル７のキュー管理数とが一致しているか否かを判定する。
【０１２９】
（１１−５）判定結果が一致していない場合
この場合は、判定部２５ａは、キューＣの次キューアドレスが書き換えられた後、障害が発生しキュー管理情報テーブル７が書き換えられていない状態に相当する。従って、判定部２５ａは、ＮＯルートを通り、メモ記録１を参照し、キュー管理情報テーブル７のキュー管理数を４に書き換えるリカバリ処理を行なう。
【０１３０】
（１１−６）判定結果が一致している場合
この場合は、キュー管理情報テーブル７およびキューＣの書き換えが正常に終了した状態なので、判定部２５ａは、ＹＥＳルートを通り、リカバリ処理は不要として処理が終了する。
このように、エンキューのリカバリ処理が行なわれる。
【０１３１】
また、このように、簡素化された処理方法のため高速で動作し、かつ信頼性の高いシステムの実現を可能にする。
（Ｂ）本発明の第２実施形態の説明
共有メモリ３において、通話終了した呼を表すキューが削除されると、空いたリソース（メモリ領域又はバッファ領域）は解放され、解放したリソースは、別の呼を処理する呼処理部２ａ〜２ｅ（又はプロセッサ２２ａ〜２２ｅ）によって獲得される。このため、共有メモリ３のリソースの大きさは、呼処理部２ａ〜２ｅごとに固定されず変動している。
【０１３２】
ここで、呼処理部２ａ〜２ｅが、呼の終了により不要になったキューを削除するときに障害が発生すると、キュー管理情報テーブル７が破壊され、この破壊は、共有メモリ３のリソースの一部が占有されたままの状態を引き起こし、また、各プロセッサ２２ａ〜２２ｅに割り当てられるリソースの減少を招く。
このため、第２実施形態における移動通信システムは、移動通信システムにおけるＭＳ１０ａ，ＢＴＳ８３ａ〜８３ｃ又はＲＮＣ８４ａ〜８４ｂ等の各通信装置（対向通信装置）のリソース状態又は通信状態を、状態監視テーブルを用いて分散監視又は分散管理している。
【０１３３】
図１７は本発明の第２実施形態に係る移動通信システムの構成図である。この図１７に示す移動通信システム１００ａは、ＣＤＭＡ方式を用いたものであって、ＲＮＣ（通信装置）８４ｐと、このＲＮＣ８４ｐと通信する複数のＢＴＳ（対向通信装置）８３ｐと、ＭＳ（移動機）１０ｐとをそなえて構成されている。
ここで、ＭＳ１０ｐは、複数のプロセッサ２２ａ〜２２ｅがアクセスしうる共有メモリ２９を有する制御部８６ｐを設けたものであり、ＢＴＳ８３ｐは、共有メモリ２９を有する移動機制御部８７ｐを設けたものであり、さらに、ＲＮＣ８４ｐは、共有メモリ２９を有する分散制御部１ａを設けている。そして、これらのＭＳ１０ｐ、ＢＴＳ８３ｐおよびＲＮＣ８４ｐは、いずれも、共有メモリ２９に状態監視テーブルを割り当てるようにしている。なお、この図１７に示すもので、上述したものと同一符号を有するものは同一のものを表す。
【０１３４】
状態監視テーブルは、複数のプロセッサ２２ａ〜２２ｅがアクセスしうる共有メモリ３のリソース状態を含む上記の通信状態を保持するものである。この状態監視テーブルは、共有メモリ２９について、キューアドレスと、このキューアドレスに対応する記憶領域の使用状態とを対応付けて格納している。
図１８は本発明の第２実施形態に係る共有メモリ２９の領域を模式的に示す図である。この図１８に示す共有メモリ２９は、リソース状態を含む通信状態を保持する状態監視テーブル３０と、複数のＢＴＳ８３ａ〜８３ｃの通信状態が保持された通信状態保持部３１ａ〜３１ｃと、状態監視テーブル３０に保持された通信状態を記録するメモ記録部（通信状態記録領域又はメモ記録領域）３２とを有する。また、メモ記録部３２は、メモ記録（メモ記録領域）３２ａ〜３２ｃを有する。
【０１３５】
これにより、各通信機器に設けられたプロセッサ２２ａ〜２２ｅと、ＲＯＭ２３およびＲＡＭ２４（図４参照）とが協働して呼処理部２ａ〜２ｅとして機能する。そして、これらの呼処理部２ａ〜２ｅのリソース状態監視部（図示省略）が、共有メモリ２９に獲得されたリソース状態を監視する。これにより、各呼処理部２ａ〜２ｅについて、例えば呼処理機能を有するソフトウェアの動作状態のチェックが可能となる。
【０１３６】
また、各呼処理部２ａ〜２ｅが、リソース状態の異常を認識すると、状態監視テーブルを用いて共有メモリ２９を復旧するようにもなっており、管理部と復旧部（図示省略）とをそなえて構成されている。
ここで、管理部は、共有メモリ２９のリソースを所定のサイズのページに分割し各ページの更新の有無を管理して、管理データファイルにその情報を保持し、また、更新されたページのデータを更新データファイルに保持するものである。
【０１３７】
さらに、復旧部は、障害リカバリ時に、管理データファイルおよび更新データファイルの情報に基づいて、共有メモリ２９の保持するデータをリカバリするものである。そして、例えば図１７に示す呼処理部２ａおよび共有メモリ２９が協働することにより、管理部と復旧部との各機能が発揮される。
この管理部により、リソースに関し、状態監視テーブルのうちの障害発生部分に対応する装置−装置又は装置−端末間の状況（すなわち、局所的な障害発生状況）を把握することができる。
【０１３８】
また、状態監視テーブル３０は、リカバリ部３３と、初期化部３４と、選択部３５とのそれぞれに接続され、これらリカバリ部３３，初期化部３４，選択部３５によって参照されるようになっている。
ここで、リカバリ部３３は、メモ記録部３２に保持された通信状態に基づいて状態監視テーブル３０のうちの局所的な障害発生部分をリカバリするものである。また、初期化部３４は、状態監視テーブル３０の保持する複数の通信状態１〜Ｎのうちの局所的な障害発生部分を初期化するものである。さらに、選択部３５は、リカバリ部３３および初期化部３４との一方を実施するものである。
【０１３９】
従って、状態監視テーブル３０は、障害発生後のリカバリ処理において、管理データファイルにその情報全てを保持しておくのではなく、テーブル内容を初期化して情報を無効にするリカバリ処理方法と、必要な情報のみをメモしその状態を再設定するリカバリ処理方法との二つの局所的なリカバリ処理が可能となる。これにより、ＢＴＳ８３ｐ（図１７参照）のような装置，機器又はＭＳ１０ａが有するリソースの状態は、状態監視テーブル３０を用いて監視又は管理される。具体的には、移動通信システム１００ａにおいて、相手端末１１ａが、ＭＳ１０ａと通話している場合は、相手端末１１ａおよびＭＳ１０ａ間の呼は、公衆網８５ａ，コアネットワーク１０１，交換機１０２，ＲＮＣ８４ａ〜８４ｂおよびＢＴＳ８３ａ〜８３ｃを介して接続されている。この呼が接続されている状態においては、各網又は各種の通信装置が相互に通信相手装置のＩＤ等を管理および監視している。
【０１４０】
また、これにより、監視システム１００ａの運営者又は管理システム１００ａの障害発生部は、ＲＮＣ８４ｐの共有メモリ２９のキューを常時、確認する負担が不要となる。従って、解明に時間と工数とを要し、また、障害発生を比較的早期に発見可能となる。
このような構成により、障害が発生したときに、メモ記録に基づいて状態監視テーブル３０のリカバリ（第１のリカバリ）と、そのリカバリされる状態監視テーブル３０の初期化により通信状態を無効とするリカバリ（第２のリカバリ）とが選択的に実施される。
【０１４１】
これにより、移動通信システム１００ａの全体を管理する必要がなくなり、局所的な通信装置間において発生した障害を、状態監視テーブル３０を参照することにより、リカバリ処理が可能となるのである。
このように、状態監視テーブル３０を用いて、各種の通信装置を管理する場合において、プロセッサ２２ａ〜２２ｅによるテーブルアクセス時に障害が発生したときでもそのテーブルは破壊されない。また、障害発生によるプログラムの非正常な動作とシステムの処理エラーの招来とがいずれも回避される。
【０１４２】
なお、第２実施形態における状態監視システムは、マルチプロセッサシステムを用いたシステムおよび電子機器等に適用することもでき、端末，呼，基地局又は計算機等種々な単位に適用可能である。
この監視システムは、移動通信システム１００（図２参照）に適用した例を説明する。なお、監視システムは、移動通信のみならず、他の用途に用いることもできる。
【０１４３】
（Ｃ）その他
本発明は上述した実施態様およびその変形例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、種々変形して実施することができる。
（Ｄ）付記
（付記１）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１４４】
（付記２）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
各プロセッサによって獲得された該通信呼に関する呼情報を保持するリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１４５】
（付記３）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
各プロセッサによって獲得された該通信呼に関する呼情報を保持するリソース管理キューについての少なくともキュー管理数と先頭キューアドレスとを含むキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルに保持された該キュー管理数と該先頭キューアドレスとに書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１４６】
（付記４）  該複数のプロセッサのうちのいずれかのプロセッサが、該キュー管理情報へのアクセス時に障害が発生したときに、該キュー管理情報テーブルに保持されたキュー管理情報と、該更新履歴記録領域に記録された更新履歴情報とに基づいて、リカバリ処理の要否を判定する判定部と、
該判定部がリカバリ必要と判定した場合に、該更新履歴情報に基づいて該キュー管理情報をリカバリする復旧部とをそなえて構成されたことを特徴とする、付記１〜付記３のいずれか一に記載のマルチプロセッサシステム。
【０１４７】
（付記５）  通信呼を処理する複数のプロセッサと、該複数のプロセッサがアクセスしうる共有メモリと、該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１４８】
（付記６）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
各プロセッサが、
該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを共有することを特徴とする、マルチプロセッサシステム。
【０１４９】
（付記７）  情報データを処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
該情報データに関する各種情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１５０】
（付記８）  通信呼を処理する複数のプロセッサと、
該複数のプロセッサがアクセスし該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルを有するメモリとをそなえ、
各プロセッサが、
該メモリに設けられ該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域を共有することを特徴とする、マルチプロセッサシステム。
【０１５１】
（付記９）  通信に関する呼情報を処理する複数のプロセッサと該複数のプロセッサがアクセスし該呼情報を保持しうる共有メモリとを有するマルチプロセッサシステムにおいて、
該共有メモリが、
該該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１５２】
（付記１０）  通信呼を処理する複数のプロセッサと、
該複数のプロセッサがアクセスしうる共有メモリとをそなえ、
該共有メモリが、
該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
【０１５３】
（付記１１）  通信装置と、該通信装置と通信する対向通信装置との間における通信状態を監視する監視システムにおいて、
該通信状態を保持する状態監視テーブルと、
該状態監視テーブルに保持された通信状態を記録する通信状態記録領域と、
該通信状態記録領域に保持された通信状態に基づいて該状態監視テーブルのうちの局所的な障害発生部分をリカバリする復旧部と、
該状態監視テーブルの通信状態のうちの局所的な障害発生部分を初期化する初期化部とのうちの少なくとも一方を実施する選択部とを設けたことを特徴とする、監視システム。
【０１５４】
（付記１２）  通信呼を処理する複数のプロセッサと、
外部装置からの通信呼を該複数のプロセッサの負荷に応じて分散する分散制御部と、
該複数のプロセッサがアクセスしうる共有メモリとをそなえ、
該共有メモリが、
該通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、
該キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、負荷分散装置。
【０１５５】
（付記１３）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるキュー取り出し方法であって、
該複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する参照ステップと、
該各プロセッサが、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、更新履歴記録領域に記録する記録ステップと、
該各プロセッサが、該更新履歴を該キュー管理情報テーブルに書き込む書き込みステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるキュー取り出し方法。
【０１５６】
（付記１４）  該参照ステップは、該各プロセッサが、該複数の情報要素として、キュー管理数と先頭キューアドレスとのうちの少なくとも一方を参照し、
該記録ステップは、該各プロセッサが、該更新情報要素として、該キュー管理数の第１更新値と該先頭キューアドレスの第２更新値とのうちの少なくとも一方を記録し、
該書き込みステップは、該各プロセッサが、該第１更新値と該第２更新値とのうちの少なくとも一方を該キュー管理情報テーブルに書き込むことを特徴とする、付記１３記載のキュー取り出し方法。
【０１５７】
（付記１５）  通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるテーブルリカバリ処理方法であって、
該複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルの該キュー管理情報と、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域の該更新履歴情報とに基づいてリカバリ処理の要否を判定する判定ステップと、
該判定ステップにてリカバリ必要と判定された場合に、該更新履歴情報に基づいて該キュー管理情報をリカバリするリカバリステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるテーブルリカバリ処理方法。
【０１５８】
（付記１６）  該判定ステップは、該各プロセッサが、該キュー管理情報の複数の情報要素としての第１キュー管理数又は第１先頭キューアドレスと、該複数の更新情報要素としての第２キュー管理数又は第２先頭キューアドレスとの一致／不一致に基づいて該要否を判定し、
該リカバリステップは、該各プロセッサが、該要否に基づいて、該第２キュー管理数又は該第２先頭キューアドレスを、該第１キュー管理数又は該第１先頭キューアドレスに書き換えることを特徴とする、付記１５記載のテーブルリカバリ処理方法。
【０１５９】
【発明の効果】
以上、詳述したように、本発明のマルチプロセッサシステム（請求項１，２），監視システム（請求項３），マルチプロセッサシステムにおけるキュー取り出し方法（請求項４）およびマルチプロセッサシステムにおけるテーブルリカバリ処理方法（請求項５）によれば、以下のような効果ないし利点が得られる。
【０１６０】
（１）本発明のマルチプロセッサシステムによれば、通信呼を処理する複数のプロセッサと複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、共有メモリが、通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けているので、処理が簡素化されて高速で動作し、かつ信頼性の高いマルチプロセッサシステムが実現する。
【０１６１】
（２）本発明のマルチプロセッサシステムによれば、共有メモリが、各プロセッサによって獲得された通信呼に関する呼情報を保持するリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けているので、キュー管理情報テーブルが障害により正当性が成立しない場合に自動的にかつ高速、完全に復旧できる（請求項１）。
【０１６２】
（３）本発明のマルチプロセッサシステムによれば、共有メモリが、各プロセッサによって獲得された通信呼に関する呼情報を保持するリソース管理キューについての少なくともキュー管理数と先頭キューアドレスとを含むキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルに保持されたキュー管理数と先頭キューアドレスとに書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けているので、メモ記録、リカバリ時の処理性能について、キュー管理情報テーブルにエンキューされているキューを先頭キューと最終キューとの両方から検索してキュー数により検索時間に時間を要しかつ検索時間が可変な従来方法に対して、メモ記録にキュー管理情報テーブルのキュー管理数、又は先頭キューアドレス情報を保持するので、キューの接続が正常か異常かの検索時間を不要とし、また、メモ記録は最小限の領域を用いてリカバリ処理の有無を判定できるので、共有メモリの有効利用が図れる。
【０１６３】
（４）各プロセッサが、キュー管理情報へのアクセス時に障害が発生したときに、キュー管理情報テーブルに保持されたキュー管理情報と、更新履歴記録領域に記録された更新履歴情報とに基づいて、リカバリ処理の要否を判定する判定部と、判定部がリカバリ必要と判定した場合に、更新履歴情報に基づいてキュー管理情報をリカバリする復旧部とをそなえて構成されてもよく、このようにすれば、システム信頼度について受信信号数が増大しかつ検索時間が最大限に要している場合において、他のプロセッサによる二重障害又は排他獲得失敗を誘発していたのに対して、リカバリ処理が単一時間で実施でき、かつ高速実施が可能なので二重障害の誘発が回避される（請求項２）。
【０１６４】
（５）本発明のマルチプロセッサシステムによれば、複数のプロセッサと共有メモリとキュー管理情報テーブルとを有するマルチプロセッサシステムにおいて、共有メモリが、更新履歴記録領域とを設けているので、システムの処理エラーを回避できる。
（６）本発明のマルチプロセッサシステムによれば、複数のプロセッサと共有メモリとキュー管理情報テーブルとを有するマルチプロセッサシステムにおいて、各プロセッサが、キュー管理情報テーブルと更新履歴記録領域とを共有するので、リカバリ時の呼損による処理性能をなくしプロセッサによる共有メモリのアクセス中の障害発生時において他のプロセッサがアクセスできる。
【０１６５】
（７）本発明のマルチプロセッサシステムによれば、情報データを処理する複数のプロセッサと複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、共有メモリが、情報データに関する各種情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けているので、通信呼以外の情報データについても、処理の簡素化，豊富なプログラム容量を用いた信頼性および比較的大きな作業メモリ容量の割り当てによる柔軟性を得ることができる。
【０１６６】
（８）本発明のマルチプロセッサシステムによれば、複数のプロセッサと、キュー管理情報テーブルを有するメモリとをそなえ、各プロセッサが、更新履歴記録領域を共有するので、簡素化についてキュー管理情報テーブルについてメモ記録に情報を書き込むだけでリカバリ処理が可能となる。
（９）本発明のマルチプロセッサシステムによれば、通信に関する呼情報を処理する複数のプロセッサと複数のプロセッサがアクセスし呼情報を保持しうる共有メモリとを有し、共有メモリがキュー管理情報テーブルと更新履歴記録領域とを設けているので、やはり、リカバリ処理が簡素化できる。
【０１６７】
（１０）本発明のマルチプロセッサシステムによれば、複数のプロセッサと共有メモリとをそなえ、共有メモリがキュー管理情報テーブルと更新履歴記録領域とを設けているので、リカバリ処理は単一時間でかつ高速に可能となる。
（１１）本発明のマルチプロセッサシステムによれば、通信装置と、通信装置と通信する対向通信装置との間における通信状態を監視する監視システムにおいて、通信状態を保持する状態監視テーブルと、状態監視テーブルに保持された通信状態を記録する通信状態記録領域と、通信状態記録領域に保持された通信状態に基づいて状態監視テーブルのうちの局所的な障害発生部分をリカバリする復旧部と、状態監視テーブルの通信状態のうちの局所的な障害発生部分を初期化する初期化部とのうちの少なくとも一方を実施する選択部とを設けているので、局所的なリカバリ処理方法が可能となりメモリ量の削減、高速、かつシステムダウンを引起さないフェールセーフな作用がある（請求項３）。
【０１６８】
（１２）本発明の負荷分散装置によれば、通信呼を処理する複数のプロセッサと、外部装置からの通信呼を複数のプロセッサの負荷に応じて分散する分散制御部と、複数のプロセッサがアクセスしうる共有メモリとをそなえ、共有メモリが、通信呼に関する呼情報を保持するリソース管理キューについてのキュー管理情報を保持するキュー管理情報テーブルと、キュー管理情報テーブルのキュー管理情報の更新履歴を記録する更新履歴記録領域とを設けているので、二重障害の誘発が回避される。
【０１６９】
（１３）本発明のマルチプロセッサシステムにおけるキュー取り出し方法によれば、複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する参照ステップと、各プロセッサが、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、更新履歴記録領域に記録する記録ステップと、各プロセッサが、更新履歴をキュー管理情報テーブルに書き込む書き込みステップとをそなえているので、キュー管理情報テーブルへのメモ記録だけでリカバリ処理が可能となり、また、リカバリに要する必要最小のデータでリカバリが可能となり、システムの簡素化が図れる（請求項４）。
【０１７０】
（１４）前記参照ステップは、各プロセッサが、複数の情報要素として、キュー管理数と先頭キューアドレスとのうちの少なくとも一方を参照し、記録ステップは、各プロセッサが、更新情報要素として、キュー管理数の第１更新値と先頭キューアドレスの第２更新値とのうちの少なくとも一方を記録し、書き込みステップは、各プロセッサが、第１更新値と第２更新値とのうちの少なくとも一方をキュー管理情報テーブルに書き込みしてもよく、このようにすれば、保守等の負担が軽減され、システム仕様の変更に対して柔軟に対応できる。
【０１７１】
（１５）本発明のマルチプロセッサシステムにおけるテーブルリカバリ処理方法によれば、複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさとキューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルのキュー管理情報と、キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域の更新履歴情報とに基づいてリカバリ処理の要否を判定する判定ステップと、判定ステップにてリカバリ必要と判定された場合に、更新履歴情報に基づいてキュー管理情報をリカバリするリカバリステップとをそなえているので、局所的なリカバリ処理方法が可能となりメモリ量の削減、高速、かつシステムダウンを引起さないフェールセーフな作用がある。
【０１７２】
（１６）判定ステップは、各プロセッサが、キュー管理情報の複数の情報要素としての第１キュー管理数又は第１先頭キューアドレスと、複数の更新情報要素としての第２キュー管理数又は第２先頭キューアドレスとの一致／不一致に基づいて要否を判定し、リカバリステップは、各プロセッサが、要否に基づいて、第２キュー管理数又は第２先頭キューアドレスを、第１キュー管理数又は第１先頭キューアドレスに書き換えるので、システム全体を管理する必要がなくなり、移動通信システムの局所的な通信装置間における障害のリカバリ処理が可能となる。
【０１７３】
また、状態監視をテーブルを用いて管理する場合、又はテーブルアクセス時に障害が発生した場合においてもそのテーブルは破壊されず、システム処理エラーが回避される。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係る移動通信システムの構成図である。
【図２】本発明の第１実施形態に係る移動通信システムの機能ブロック図である。
【図３】本発明の第１実施形態に係る基地局制御装置の概略的なブロック図である。
【図４】本発明の第１実施形態に係る負荷分散装置の要部を示す図である。
【図５】本発明の第１実施形態に係る共有メモリの領域を模式的に示す図である。
【図６】本発明の第１実施形態に係る負荷分散装置を上方から見た模式図である。
【図７】本発明の第１実施形態に係るリカバリ処理を説明するための図である。
【図８】本発明の第１実施形態に係る先頭キュー取り出し処理を説明するための図である。
【図９】本発明の第１実施形態に係る先頭キュー取り出し処理を説明するためのフローチャートである。
【図１０】本発明の第１実施形態に係る先頭キュー取り出しのリカバリ処理を説明するためのフローチャートである。
【図１１】本発明の第１実施形態に係る途中キューの取り出し方法を説明するための図である。
【図１２】本発明の第１実施形態に係る途中キューの取り出し処理を説明するためのフローチャートである。
【図１３】本発明の第１実施形態に係る途中キュー取り出しのリカバリ処理を説明するためのフローチャートである。
【図１４】本発明の第１実施形態に係るエンキュー方法を説明するための図である。
【図１５】本発明の第１実施形態に係るエンキュー処理を説明するためのフローチャートである。
【図１６】本発明の第１実施形態に係るエンキューのリカバリ処理を説明するためのフローチャートである。
【図１７】本発明の第２実施形態に係る移動通信システムの構成図である。
【図１８】本発明の第２実施形態に係る共有メモリの領域を模式的に示す図である。
【図１９】負荷分散型のマルチプロセッサシステムのブロック図である。
【図２０】共有メモリからのリソース獲得を説明するためのシーケンスを示す図である。
【図２１】（ａ）は障害発生前の共有メモリの割り当て例を示す図であり、（ｂ）は障害発生後の共有メモリの割り当て例を示す図である。
【図２２】共有メモリのリカバリ処理動作の一例を示す図である。
【図２３】（ａ）〜（ｆ）はいずれもデキュー又はエンキューを説明するための図である。
【符号の説明】
１  負荷分散装置
２ａ〜２ｅ  呼処理部
３，２９  共有メモリ
４  ハードディスクドライブ
５  プロセッサ間通信装置
５ｅ  バス
５ｆ  デバッガ
６ａ〜６ｃ，６ｑ  リソース（キュー）
６ｄ  テーブル領域
８，３２  メモ記録部（更新履歴記録領域）
９，１ａ  分散制御部
１０ａ，１０ｐ  携帯電話
１０ｂ  ビデオ再生装置
１０ｃ  テレビ電話
１１ａ，１１ｂ  通信相手端末（相手端末）
２２ａ〜２２ｅ  プロセッサ
２３  ＲＯＭ
２４  ＲＡＭ
２５ａ  判定部
２５ｂ  復旧部
３２ａ〜３２ｃ  メモ記録
３３  リカバリ部
３４  初期化部
３５  選択部
８２  バックボード
８３ａ〜８３ｃ，８３ｐ  ＢＴＳ（無線基地局）
８４ａ〜８４ｂ，８４ｐ  ＲＮＣ（無線ネットワーク制御装置）
８５ａ  ラインインターフェース
８５ｂ  ＡＴＭスイッチ
８５ｃ  出力インターフェース
８５ｄ  終端部
８６ａ  音声受話部
８６ｇ  音声送話部
８６ｂ  ベースバンド処理部
８６ｃ  変復調部
８６ｄ  送受信アンプ
８６ｅ  キー情報保持部
８６ｆ，８６ｐ  移動機制御部
８７ａ  ハイウェイイン制御部
８７ｂ，８７ｐ  基地局制御部
８８  クロック部
８８ａ  給電部
８９ａ  ＤＨＴ
８９ｂ  Ｍ−ＭＵＸ
１００，１００ａ  移動通信システム
【図１】
2004220118.tif 000003
【図２】
2004220118.tif 000004
【図３】
2004220118.tif 000005
【図４】
2004220118.tif 000006
【図５】
2004220118.tif 000007
【図６】
2004220118.tif 000008
【図７】
2004220118.tif 000009
【図８】
2004220118.tif 000010
【図９】
2004220118.tif 000011
【図１０】
2004220118.tif 000012
【図１１】
2004220118.tif 000013
【図１２】
2004220118.tif 000014
【図１３】
2004220118.tif 000015
【図１４】
2004220118.tif 000016
【図１５】
2004220118.tif 000017
【図１６】
2004220118.tif 000018
【図１７】
2004220118.tif 000019
【図１８】
2004220118.tif 000020
【図１９】
2004220118.tif 000021
【図２０】
2004220118.tif 000022
【図２１】
2004220118.tif 000023
【図２２】
2004220118.tif 000024
【図２３】
2004220118.tif 000025