Multiprocessor system, monitoring system, method of taking out queue from multiprocessor system, and process for table recovery at multiprocessor system
Abstract
[Subject] in a multiprocessor system, at the time of a fault occurrence when two or more processors have accessed the shared memory, The multiprocessor system which has the pliability by the buffer which was able to assign the reliability and the big work capacity of prevention of the call loss at the time of recovery, the simplification of recovery processing, restorative improvement in the speed, and a system is offered. [Solution means] In a multiprocessor system, a shared memory, The cue management information table 7 holding the cue management information which consists of two or more information elements which pinpoint the size of resource administration cue and the position of cue holding the call information about the communication call gained by each processor, The memo record part (update history recording region) 8 which records the update history which consists of two or more update condition elements written in the cue management information of the cue management information table 7 is prepared and constituted. [Selection figure] Fig. 8
Term
Term ended
Projected expiry passed 9 January 2023, 3.7 years ago.
- Priority and filed
- Published
- Projected expiry
- Today
5 claims: 4 independent, 1 dependent
- 1In a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible to the plurality of processors, the shared memory holds a resource management queue for holding call information about the communication call acquired by each processor. A queue management information table that holds queue management information consisting of a plurality of information elements that specify the size of the queue and the position of the queue, and an update history consisting of a plurality of update information elements that are written in the queue management information of the queue management information table. A multiprocessor system characterized by providing an update history recording area for recording. 通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおいて、該共有メモリが、各プロセッサによって獲得された該通信呼に関する呼情報を保持するリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルと、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域とを設けたことを特徴とする、マルチプロセッサシステム。
- 3In a monitoring system that monitors the communication status between a communication device and an opposite communication device that communicates with the communication device, a status monitoring table that holds the above communication status including the resource status of shared memory that can be accessed by a plurality of processors. And, the communication status recording area for recording the communication status held in the status monitoring table and the local failure occurrence part in the status monitoring table are recovered based on the communication status held in the communication status recording area. A monitoring system characterized in that a recovery unit is provided and an initialization for initializing a local failure-occurring portion of the communication status of the status monitoring table is provided. 通信装置と、該通信装置と通信する対向通信装置との間における通信状態を監視する監視システムにおいて、複数のプロセッサがアクセスしうる共有メモリのリソース状態を含む上記の通信状態を保持する状態監視テーブルと、該状態監視テーブルに保持された通信状態を記録する通信状態記録領域と、該通信状態記録領域に保持された通信状態に基づいて該状態監視テーブルのうちの局所的な障害発生部分をリカバリする復旧部と、該状態監視テーブルの通信状態のうちの局所的な障害発生部分を初期化する初期化とのうちの少なくとも一方を実施する選択とを設けたことを特徴とする、監視システム。
- 4A queue retrieval method in a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, and resource management acquired by one of the plurality of processors. A reference step that refers to a queue management information table that holds queue management information consisting of a plurality of information elements that specify the size of a queue and the position of the queue, and one of the processors manages the queue of the queue management information table. A recording step of recording an update history composed of a plurality of update information elements to be written in information in an update history recording area, and a write step of writing the update history to the queue management information table by any of the processors. A method of queuing in a multiprocessor system, characterized by. 通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるキュー取り出し方法であって、該複数のプロセッサのうちのいずれかのプロセッサが、獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルを参照する参照ステップと、該いずれかのプロセッサが、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を、更新履歴記録領域に記録する記録ステップと、該いずれかのプロセッサが、該更新履歴を該キュー管理情報テーブルに書き込む書き込みステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるキュー取り出し方法。
- 5A table recovery processing method in a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, and resource management acquired by one of the plurality of processors. The queue management information of the queue management information table that holds queue management information consisting of a plurality of information elements that specify the size of the queue and the position of the queue, and a plurality of update information to be written to the queue management information of the queue management information table. A determination step for determining the necessity of recovery processing based on the update history information in the update history recording area for recording an update history composed of elements, and an update history when it is determined in the determination step that recovery is necessary. A table recovery processing method in a multiprocessor system, which comprises a recovery step for recovering the queue management information based on the information. 通信呼を処理する複数のプロセッサと該複数のプロセッサがアクセスしうる共有メモリとを有するマルチプロセッサシステムにおけるテーブルリカバリ処理方法であって、該複数のプロセッサのうちのいずれかのプロセッサが獲得したリソース管理キューの大きさと該キューの位置とを特定する複数の情報要素からなるキュー管理情報を保持するキュー管理情報テーブルの該キュー管理情報と、該キュー管理情報テーブルのキュー管理情報に書き込む複数の更新情報要素からなる更新履歴を記録する更新履歴記録領域の該更新履歴情報とに基づいてリカバリ処理の要否を判定する判定ステップと、該判定ステップにてリカバリ必要と判定された場合に、該更新履歴情報に基づいて該キュー管理情報をリカバリするリカバリステップとをそなえたことを特徴とする、マルチプロセッサシステムにおけるテーブルリカバリ処理方法。
Independent claims4
378 paragraphs in 1 section, as filed
【0001】
[Technical field to which the invention belongs]
The present invention relates to, for example, a load-distributed multiprocessor system, a multiprocessor system, a monitoring system, which is suitable for recovery processing of a queue allocated to a shared memory accessed by a plurality of processors performing a large amount of signal processing. The present invention relates to a queue retrieval method in a multiprocessor system and a table recovery processing method in a multiprocessor system.
【0002】
[Conventional technology]
Various communication devices in W-CDMA (Wideband-Code Division Multiple Access) mobile communication systems perform transmission / reception processing of a large amount of data. (P1) Example of mobile communication system Base station control device (BTS: Base Transmitting Station: hereinafter referred to as BTS unless otherwise specified) and a base station control device (BTS) provided between a public network or the Internet. RNC: Radio Network Controller: Hereinafter referred to as RNC unless otherwise specified) receives a large amount of moving image data, etc. from the public network, and transfers the moving image data, etc. to one or more BTSs. To do. In addition, RNC transmits information data transmitted from a plurality of BTSs to the public network. That is, RNC requires a large amount of call processing (CP) and a large amount of arithmetic processing.
【0003】
(P2) Load Distributor For this purpose, the RNC constitutes a multiprocessor system including a plurality of processors that perform signal processing and a shared memory that is shared by these multiple processors and holds data necessary for call processing. However, the load required for call processing is distributed (distributed).
【0004】
Various multiprocessor systems that perform this load distribution processing have been conventionally proposed (see, for example, Patent Document 1). The RNC queue management method (queue management method or queue management information method) manages resources for each device (or each device). For example, one resource is allocated to one BTS.
【0005】
(P3) Resource Here, unless otherwise specified, the resource means a physical memory area or a memory area that holds one call information such as identification information of a communication partner. The shared memory is provided in a communication device accessed (read / written) by a plurality of processors, and a bidirectional queue is used.
【0006】
(P4) A queue queue generally has information data and another queue address to which the queue itself connects. Here, the bidirectional queue means, for example, the queue address immediately before the queue itself (hereinafter, the previous queue address) and the queue address immediately after the queue itself, as shown in resources A to C shown in FIG. 21 (a). (Hereinafter, the next queue address). As a result, the processor can search for the desired queue by referring to each "next queue address" of the resources A to C shown in FIG. 21 (a). In addition, the processor can refer to the "previous queue address" stored in the "next queue address" of resource C and search each queue in order from the opposite direction. In this respect, the bidirectional queue has each queue "next". It differs from a one-way queue that has only a "queue address".
【0007】
Then, the processor inserts various call information into the queue, and another processor refers to the call information of this queue, whereby the call information is shared with each other through the queue. This queue is constantly managed by the queue management information table while each processor processes call information. (P5) Load-Distributed Multiprocessor System As an example of the load-distributed multiprocessor, the shared memory in the RNC system will be described with reference to FIGS. 19 and 20.
【0008】
FIG. 19 is a block diagram of a load-distributed multiprocessor system. The load distribution device 200 shown in FIG. 19 is provided in the RNC, for example, for performing call processing, and is a load distribution control unit (control unit) 201, processors A to D, shared memory 203, and an interprocessor communication device 204. It is configured with and. Here, the control unit 201 receives the information data and the control data from the exchange 102 and the BTS 198a to 198b, and distributes the load required for the call processing or the communication processing to the processors A to D. Further, the processors A to D all perform call processing between the BTS 198a and the BTS 198a to 198b. Then, the total load of the load generated inside the RNC and the load for the call processing from the external device such as the exchange 102 is distributed and processed by these processors A to D. Therefore, each processor A to D handles not only the load for the specific BTS 198a but also the load for the other BTS 198b. That is, the entire load is distributed and allocated so that the loads of the processors A to D are averaged.
【0009】
Further, the shared memory 203 secures a resource for each of the BTS 198a to 198b, and generates a queue in this resource for holding call information such as the address or telephone number of the mobile phone of the communication partner (opposite communication device). There is. Each call information is assigned an ID (Identification) so that it can communicate with each other via a wired line.
【0010】
The inter-processor communication device 204 is for the processors A to D to send and receive signals to and from each other. (P6) Explanation of resource acquisition by software FIG. 20 is a diagram showing a sequence for explaining resource acquisition from the shared memory 203. The exchange 102 transmits a call control signal 1 for the terminal 1 to the control unit 201 (step H1), and when the control unit 201 receives the call control signal 1, the load among the processors A to D is loaded. For example, processor A is selected and interrupted to processor A (step H2), and this call control signal 1 is notified. Upon receiving this notification, processor A acquires a resource in the shared memory 203 (see FIG. 19) (step H3), and when it acquires the resource, transmits to that effect to the exchange 102 (call control signal 1'[. Message displayed as Terminal 1].
【0011】
On the other hand, the exchange 102 transmits the call control signal 2 for the terminal 1 after the above call control signal 1 is transmitted (step H4), and when the control unit 201 receives the call control signal 2, the call control signal 2 is transmitted. Distribute the task for 2 to processor B (step H5) and notify processor B (step H6). Here, when the processor B can acquire the resource from the shared memory 203, the processor B transmits an acknowledgment (answer signal) as a call control signal 2'to the exchange 102 (step H7). As a result, the load of each processor A to D is distributed.
【0012】
(P7) Queue management function The queue management function is realized by the software section (hereinafter referred to as software) of each processor A to D. When the control unit 201 assigns the queue management function to the processor A, the processor A performs exclusive processing (locking) and acquires the resource allocated to the queue in the shared memory 203. The other processors B to D wait while the exclusive processing is being performed.
【0013】
As an example of queue management, when processor A acquires a queue, it writes the queue size information (queue range and queue position) to a specific area of shared memory 203. Then, when the processing by the processor A is completed and another processor B needs to access the shared memory 203, the processor B refers to the size information written by the processor A.
【0014】
A memory control state monitoring device that constantly monitors the operating state / used state of the shared buffer area is disclosed in, for example, Patent Document 2. (P8) Example of Shared Memory 203 FIG. 21 (b) is a diagram showing an example of allocation of the shared memory 203 after a failure occurs. The information held in the queue management information table 205 is the number of queue management (total number of queues), the next queue address, the previous queue address, and the like.
【0015】
For example, in the shared memory 203 shown in FIG. 21 (a), since three queues 91a to 91c are connected, the number of queue management is held as 3, and the next queue address is the first queue address of the queue 91a ( The queued first queue address) is held at the beginning of the queue management information table 205. Note that there is no queue before the queue 91a even if there is a queue management information table 205, so there is no value for the previous queue address.
【0016】
All of the processors A to D can access the information such as the number of queue management written in the queue management information table 205, and can easily acquire the information such as the size of the resource occupying each call. Further, as a master processor, a processor that receives a specific signal from a processor (not shown) of another device receives a voice packet via the control unit 201 with respect to a processor A to D having a small load. I try to sort them out. In other words, the queue management information table 205 functions as a "queue terminal".
【0017】
(P9) Explanation of Queue Extraction and Queue Insertion Operations Figures 23 (a) to 23 (f) are all diagrams for explaining queue retrieval or queue insertion, and the three-stage areas shown in these are the diagrams. , The queue management information table 205 is provided, and the number of queue management, the first queue address, and the last queue address in the information area required for queue management are written in the first to third rows. Figures 23 (a) to 23 (f) also accept this policy.
【0018】
FIG. 23 (a) is a diagram showing a main part of the queue management information table 205 immediately after initialization, and 0 (no recording) is recorded in the entire area. When one queue (the queue with the number 1) is inserted, the number of managed areas, the first queue address, and the last queue address shown in FIG. 23 (b) are 1, 1, 1, respectively. What is shown in FIG. 23 (c) is a diagram showing each area when one more queue (queue of number 2) is inserted in the state shown in FIG. 23 (b). That is, the total number of queues is two, and the number of managed queues, the first queue address, and the last queue address are 2 (queues with numbers 1 and 2) and 1 and 2, respectively.
【0019】
What is shown in FIG. 23 (d) is a diagram showing each area when one more queue (queue of number 3) is inserted in the state shown in FIG. 23 (c). Therefore, the number of managed items, the first queue address, and the last queue address are 3 (queues with numbers 1 to 3), 1, and 3, respectively. In this way, each time a queue is inserted, its history is saved.
【0020】
Next, the main parts of the queue management information table 205 when the queue is fetched or deleted will be described with reference to FIGS. 23 (e) and 23 (f). The queue deletion is recorded in the queue management information table 205 and the call is retained, for example, when the telephone call ends. FIG. 23 (e) shows the state after the queue number 2 is taken out from the state shown in FIG. 23 (d). The number of managed items is 2, the first queue address is 1, and the last queue address is queue 3. There is up to.
【0021】
FIG. 23 (f) shows the case where the queue 2 is inserted again from the state shown in FIG. 23 (e). As a result, the number of managed items is 3, the first queue address is 1, and the last queue address is 2. (P10) Example of Queue Operation In order to operate the queue, processors A to D, for example, the number of queues managed in the queue management information table 205 shown in FIG. 21 (a), the next queue address, and the previous queue when the queue is released. Each of the address and the first queue address needs to be updated.
【0022】
On the other hand, if the processors A to D for queue operation fail, the recovery process is not easy. When a failure occurs in the queue operation, for example, processor A, and there is a difference between the actual number of queue management and the number of queue management written to the queue, for example, as shown in Fig. 21 (b), or the next queue. If there is a difference between the address and the previous next queue address, it is possible that the program will not run properly. Therefore, in order to operate the program normally, the other processors B to D that have detected the failure perform the recovery processing operation.
【0023】
FIG. 22 is a diagram showing an example of the recovery processing operation of the shared memory 203. In the recovery processing operation shown in FIG. 22, processors A to D search for the address of the shared memory 203, trace the queue from both directions of the first queue 91a and the last queue (end queue) 91b, and of the two-way queue. Count and compare the number. If the number of these queues does not match, the queue address after being written to the queue management information table 205 and the previous queue address are not consecutive, and the queue is missing or the queue management information table 205 is destroyed. Is assumed. In this case, each processor A to D performs a recovery process to recover the queue.
【0024】
In this way, the load-distributed multiprocessors A to D provided in the RNC and the shared memory 203 perform queue management and recovery processing. By the way, when a large number of calls are input to the RNC, the resources for holding the queue management information may become saturated and the system may stop functioning. Therefore, the RNC needs to monitor the state of the memory area of the shared memory 203, and this state monitoring is realized by the state monitoring system. The condition monitoring system will be described below.
【0025】
This status monitoring system is a memory monitoring system that monitors the resource allocation status of the shared memory 203, and monitors or manages the resource status of a device, device, or terminal in the mobile communication system using a status monitoring table. This condition monitoring system is configured to include a management and recovery unit. Here, in the management, the status monitoring table divides the memory resource into pages of a predetermined size, manages whether or not each page is updated, holds the information in the management data file, and also stores the updated page data. Is stored in the update data file. Further, the recovery unit recovers the table data in the memory based on the information of the management data file and the update data file at the time of failure recovery.
【0026】
According to this condition monitoring system, in particular, regarding resources, buffers, etc., the status between the device-device or the device-terminal corresponding to the failed part of the status monitoring table (that is, the local failure occurrence status). Can be grasped.
【0027】
[Patent Document 1]
Japanese Unexamined Patent Publication No. 2001-167075 [Patent Document 2]
Japanese Unexamined Patent Publication No. 9-91172 [0028]
[Problems to be Solved by the Invention]
However, the system using the above queue management information table 205 or the status monitoring table has the problems shown in the following (Q1) to (Q4). (Q1) Invitation of recovery processing error If a failure occurs during dequeue (retrieving a specific queue), enqueue (inserting a queue), or status update of a resource in shared memory 203, the queue management in which the failure occurred Information table 205 may be corrupted, leading to system processing errors. For example, when a control signal is directly input from the exchange 102 via the control unit 201, the response cannot be made and the host device disconnects the call.
【0029】
In addition, the method of managing using the status monitoring table may also destroy the data held in the status monitoring table if a failure occurs during table access, which may lead to a system processing error. (Q2) Processing performance due to call loss during recovery If the signal amount (call amount, etc.) is large, the time for processors A to D to access the shared memory 203 becomes long, which may become a bottleneck. In this case, in order to shorten the processing time, the load for call processing becomes large. Moreover, it is more efficient to operate the recovery process only when necessary than to perform the recovery process all the time.
【0030】
In addition, the above method of comparing the number of queues requires a long time for searching (recovery time) because the processor follows the queues from both directions, and other processors access the shared memory 203. The amount of time that cannot be done increases, and therefore the processing performance due to call loss is affected. (Q3) System reliability Since the recovery process after a failure affects call loss, etc., it is necessary to design the program so that it is fast and absolutely reliable without causing abnormal operation of the program. It doesn't become. This increases the complexity of the system.
【0031】
In addition, when recovering the destruction of the queue management information table 205, the recovery process also induces a double failure by another processor (exclusive resource acquisition fails), and the system is unreliable. In particular, reliability is an important factor because the reliability of mobile communication systems in recent years is high. As a method of improving the stability of the system, a redundant configuration in which an active system and a backup system are provided is well known. For example, each RNC84a to 84b has several working CP boards and one spare CP board, and when the working CP board cannot be used for failure, maintenance or inspection, the working system The physical communication path between the CP board and the external device is cut from the active CP board and connected to the spare CP board. However, there is a problem that switching using the active system and the backup system has time.
【0032】
In addition, the system must ensure reliable billing and operation of devices or terminals downstream of the RNC. Therefore, when a failure occurs while the processor is accessing the shared memory 203, it is necessary to release the occupancy of the shared memory 203 so that another processor (another user) can access it. (Q4) Simplification The expansion of the system scale leads to an increase in the amount of programs. The reliability and flexibility of each system depends on the scale of the system to be developed. When the conventional technology is used, the processing is complicated, and reliability (program amount) and flexibility (required storage capacity) are bottlenecks.
【0033】
The present invention was devised in view of such problems, avoids system processing errors, eliminates processing performance due to call loss during recovery, and causes other processors in the event of a failure while accessing shared memory by the processor. Queue retrieval methods and methods in multiprocessor systems, surveillance systems, multiprocessor systems, which are accessible and have the flexibility of processing simplification, reliability with abundant program capacity, and allocation of relatively large working memory capacity. An object of the present invention is to provide a table recovery processing method in a multiprocessor system.
【0034】
[Means for solving problems]
Therefore, the multiprocessor system of the present invention relates to a communication call in which the shared memory is acquired by each processor in a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible to the plurality of processors. Resource management that holds call information A queue management information table that holds queue management information consisting of multiple information elements that specify the size of the queue and the location of the queue, and multiple update information that is written to the queue management information in the queue management information table. It is characterized in that an update history recording area for recording an update history composed of elements is provided (claim 1).
【0035】
In addition, when one of the processors fails to access the queue management information, the queue management information held in the queue management information table and the updates recorded in the update history recording area. It is configured with a determination unit that determines the necessity of recovery processing based on the history information, and a recovery unit that recovers the queue management information based on the update history information when the determination unit determines that recovery is necessary. It may be (Claim 2).
【0036】
Further, the monitoring system of the present invention includes the resource state of the shared memory that can be accessed by a plurality of processors in the monitoring system that monitors the communication state between the communication device and the opposite communication device that communicates with the communication device. A status monitoring table that holds the communication status, a communication status recording area that records the communication status held in the status monitoring table, and a local status monitoring table based on the communication status held in the communication status recording area. The feature is that a recovery unit that recovers the failure-occurring part and an initialization unit that initializes the local failure-occurring part of the communication status of the status monitoring table are provided. (Claim 3).
【0037】
The queue retrieval method in the multi-processor system of the present invention is a queue retrieval method in a multi-processor system having a plurality of processors for processing communication calls and a shared memory accessible by the plurality of processors, and is a queue retrieval method for a plurality of processors. A reference step in which one of the processors refers to a queue management information table that holds queue management information consisting of multiple information elements that identify the size and location of the resource management queue acquired, and each processor It has a recording step of recording an update history consisting of a plurality of update information elements to be written in the queue management information of the queue management information table in the update history recording area, and a write step of each processor writing the update history to the queue management information table. It is characterized in that (claim 4).
【0038】
Further, the table recovery processing method in the multiprocessor system of the present invention is a table recovery processing method in a multiprocessor system having a plurality of processors for processing communication calls and a shared memory accessible to the plurality of processors, and is a plurality of table recovery processing methods. Resource management acquired by one of the processors Queue management information in the queue management information table that holds queue management information consisting of multiple information elements that specify the size of the queue and the location of the queue, and the queue management information table The determination step of determining the necessity of recovery processing based on the update history information of the update history recording area for recording the update history consisting of a plurality of update information elements to be written in the queue management information of, and the determination step of determining that recovery is necessary. When this is done, it is characterized by having a recovery step for recovering the queue management information based on the update history information (claim 5).
【0039】
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. (A) Explanatory drawing of the first embodiment of the present invention FIG. 1 is a configuration diagram of a mobile communication system according to the first embodiment of the present invention. The mobile communication system 100 shown in FIG. 1 is a system using a CDMA system, and has low-capacity data such as telephone, text data, and voice, and large-capacity data such as still images and moving images (hereinafter, low-capacity). Data and large-capacity data are referred to as information data), and are transmitted and received at high speed.
【0040】
Hereinafter, each device of the mobile communication system 100 will be described with reference to FIGS. 1 to 3, and the load distribution device will be described with reference to FIG. (1) Mobile communication system 100 The mobile communication system 100 shown in FIG. 1 includes various mobile devices (MS: Mobile Station, hereinafter referred to as MS) 10a, 10b, 10c and, for example, 48 BTS (MS) used by the user. Communication with wireless base stations) 83a to 83c, RNCs (wireless network controllers) 84a to 84b, core networks (CN: Core Network) 101, public switched telephone networks (PSTN) 85a, and the Internet 85b. It is configured with the other party terminal (other party terminal) 11a and 11b.
【0041】
(1-1) Core network 101, public network 85a, and Internet 85b The core network 101 is a network switch and a packet switch that are connected to each other and exchange information data (switch), and location registration data of MS10a to 10c. It has an HLR (Home Location Register) 101a that holds a packet, an MMS (Mobile Multimedia Switching System) 101b that switches packets, and a GMMS (Gateway Mobile Multimedia Switching System) 101c that has a gateway function. The public network 85a is a subscriber line network that transmits voice data, fax data, etc., and the Internet 85b is a network that transfers packets.
【0042】
Thereby, for example, the radio signal transmitted by the MS10a is demodulated by the BTS83a and then terminated by the RNC84a, and the information data contained in the radio signal is transmitted to the public network 85a or the Internet via the core network 101. It is transmitted to 85b. The information data transmitted by the remote terminal 11a is transferred to the RNC84a via the public network 85a, the Internet 85b, and the core network 101, respectively, based on the location registration data of the HLR101a, and is modulated into a radio signal by the BTS83a. Sent to MS10a.
【0043】
The mobile communication system 100 can also use the cdma2000 system or the W-CDMA system. (1-2) RNC (base station controller) 84a to 84b The RNC84a to 84b controls a plurality of BTS83a to 83c, and multiplexes a plurality of channel data between each BTS83a to 83c and the core network 101. It sends and receives, and requires high-speed and large-capacity data processing capability.
【0044】
Each of the RNCs 84a to 84b has a function of transferring information data between the BTS 83a to 83c and the core network 101, and a control function of transmitting and receiving a control signal for call connection processing or maintenance operation for each of the BTS 83a to 83c. It also has functions such as channel allocation, handover execution, and incoming / outgoing connection. As a result, the information data from the public network 85a or the Internet 85b is transferred to any of the plurality of BTS 83a to 83c depending on the destination, and the information data from the plurality of BTS 83a to 83c is transferred to the public network 85a or the public network 85a or Transferred to Internet 85b.
【0045】
These RNC84a to 84b, the plurality of BTS83a to 83c, and the plurality of MS10a to 10c all transmit and receive control signals and data signals using a wireless protocol, and function as a radio access network (RAN). ing. On the other hand, RNC84a to 84b and the core network 101 send and receive information data by wire.
【0046】
(1-3) Multiprocessor System of the Present Invention This multiprocessor system is applied to the load distribution device provided in RNC84a to 84b. The information data transferred by RNC84a to 84b is fast and has a large capacity, and also processes information data from both a plurality of BTS83a to 83c and the core network 101, so that the load on each of the RNC84a to 84b is extremely high. large. Therefore, a load distribution function is provided in each RNC84a to 84b so that the entire load of information data is distributed.
【0047】
The multiprocessor system of the present invention can also be applied to a device unit such as a call, MS10a to 10c, network terminal, computer or BTS83a to 83c. (1-4) MS10a, etc. MS10a ~ 10c wirelessly communicates information data with BTS83a ~ 83c and control data related to communication and control, and is a mobile phone 10a, a video playback device 10b, and a television. Telephone 10c etc.
【0048】
As shown in FIG. 2, for example, the mobile phone 10a outputs and receives information data in which signals from the voice receiving unit (SPK) 86a, the voice transmitting unit (MIC) 86g, and the voice transmitting unit 86g are encoded. Modulation / demodulation that modulates the information data from the baseband processing unit 86b that inputs the signal-decoded data to the voice receiver 86a or the display (not shown) and the baseband processing unit 86b into a radio signal and democratizes the received radio signal. A key information holding unit 86e that has a unit (TRX) 86c and a transmission / reception amplifier (T / R AMP) 86d that amplifies the radio signal from the modulation / demodulation unit 86c and amplifies the received signal, and also holds the identification information of the terminal. And a mobile device control unit (control unit) 86f that controls MS10a to 10c.
【0049】
The description of the video playback device 10b and the videophone 10c will be omitted because their wireless transmission / reception units are equivalent to the modulation / demodulation unit 86c of the mobile phone 10a. Moreover, it will be described below using MS (mobile phone) 10a. (1-5) The other party terminals 11a and 11b (see Fig. 1) Both the other party terminals 11a and 11b talk to the MS10a or send and receive information data, for example, a fixed telephone, a mobile phone or a personal computer (see Fig. 1). (PC) etc.
【0050】
(1-6) BTS83a to 83c FIG. 2 is a functional block diagram of the mobile communication system 100 according to the first embodiment of the present invention, and those having the same reference numerals as those described above in FIG. 2 have the same functions. The 48 BTS 83a to 83c all transmit and receive wireless data to and from MS10a, and also transmit and receive wired data to and from RNC84a to 84b. , The modulation / demodulation unit 86c that modifies and demolishes radio signals, the baseband processing unit 86b that processes baseband signals, and the highway-in control unit (HW-CNT) 87a that controls data transmission / reception between RNC84a to 84b and BTS83a to 83c. And the baseband control unit (control unit) 87b that monitors and controls the inside of BTS83a to 83c.
【0051】
Further, the base station control unit 87b can be configured by providing a shared memory equivalent to the shared memory 3 of the RNC84a (not shown). Both BTS83b and 83c have the same configuration as BTS83a, and duplicate description will be omitted. The BTS number of 48 is an example and is not limited to this value.
【0052】
(2) Configuration of RNC84a to 84b RNC84a to 84b is a line interface that terminates the line between the load distribution device (CONT) 1 that has a control function and load distribution function for call processing and BTS83a to 83c. (LIF: Line InterFace) 85a, ATM switch (Asynchronous Transfer Mode Switch) 85b that switches packets from BTS83a to 83c and switch 102 based on its destination or a predetermined path, and the line between the switch 102 are terminated. It is configured with an output interface 85c to be used and a terminal (SU) 85d for terminating control signals such as call processing.
【0053】
Further, the terminal 85d has a mobile device opposed signal termination (MSU), an external device opposed signal termination (ESU), and an OPS opposed signal termination (OSU), and receives signals from the MS10a and the switch 102. It is designed to be input to the load distribution device 1. (3) Load Distributor (Multiprocessor System) 1 FIG. 3 is a schematic block diagram of RNC84a to 84b according to the first embodiment of the present invention. Those shown in FIG. 3 having the same code as the above-mentioned code have the same function.
【0054】
(3-1) Load Distributor 1 The functions of Load Distributor 1 are communication, call connection, and maintenance operation between external devices such as BTS83a to 83c and switch 102 (see Fig. 1) and each module of RNC84a to 84b itself. It is the transmission and reception of control signals for these purposes and the load distribution for these processes. The load distribution device 1 includes an interprocessor communication device (bus controller: BCONT [Bus Controller]) 5, a call processing unit (CP: Call Processing) 2a to 2e, a shared memory (CM: Common Memory) 3, and the like. It is composed of a hard disk drive (HDD) 4, a debugger (DB: Debugger) 5f, and a bus 5e for communication.
【0055】
(3-2) Call processing units 2a to 2e The functions of each call processing unit 2a to 2e are radio channel allocation, call information processing related to incoming calls, conversion processing between global addresses and local addresses, and main control. A processor 22a, a ROM (Read Only Memory) 23, and a RAM (Random Access Memory) 24 are provided on a board (CP board or CP card).
【0056】
FIG. 4 is a diagram showing a main part of the load distribution device 1 according to the first embodiment of the present invention. The load distribution device 1 shown in FIG. 4 is a load distribution control that distributes communication calls from a plurality of processors 22a to 22e that process communication calls and an external device such as an exchange 102 according to the load of the processors 22a to 22e. It has a unit (distributed control unit) 9 and a shared memory 3 that can be accessed by processors 22a to 22e. Then, the shared memory 3 holds the queue management information table (see Fig. 5 etc.) 7 that holds the queue management information for the resource management queue that holds the call information related to the communication call, and the update history of the queue management information in the queue management information table. A memo recording unit (update history recording area, see Fig. 8) 8 is provided to record the information.
【0057】
The function of the call processing unit 2a is exhibited by software in which the processor 22a, ROM23, and RAM24 cooperate with each other. Similarly, each function of the call processing units 2b to 2e is also provided with each processor 22b to 22e on each CP board, and ROM23 and RAM24 are exhibited in cooperation with each other. Then, by the cooperation of the call processing units 2a to 2e, the total load for the call processing of the 48 BTS83a to 83c is distributed.
【0058】
(3-3) Interprocessor Communication Device 5 The interprocessor communication device 5 has a control function for each processor 22a to 22e to transmit and receive signals to and from each other. The load distribution device 1 uses, for example, the processor 22a of the processors 22a to 22e as the master processor, and receives specific signals from the other processors 22b to 22e. In other words, the other processors 22b to 22e all use the interprocessor communication device 5 to send and receive signals to and from the master processor 22a.
【0059】
(3-4) Load distribution control unit (distributed control unit) 9 The distribution control unit 9 receives information data and control data from the exchange 102 and BTS83a to 83c, and applies the processing load of the communication call to each call processing unit 2a. It is distributed over ~ 2e. Further, this load distribution function is exhibited by, for example, the master processor 22a. It should be noted that other processors 22b to 22e can also realize the load distribution function.
【0060】
(3-5) Shared memory 3 The information held in the shared memory 3 is information that needs to be inherited by a plurality of processors 22a to 22e, or information that must not be lost. For example, if a failure occurs when the MS10a and the other party terminal 11a are in a call state such as "Hello" or "Yes Yes", the call state between the two is maintained. Therefore, the call information indicating this call state is maintained. Must be taken over by other processors 22a-22e.
【0061】
Then, each processor is assigned a task according to the load to process the call in order to distribute the load. FIG. 5 is a diagram schematically showing an area of the shared memory 3 according to the first embodiment of the present invention. The shared memory 3 shown in FIG. 5 is shared and accessed by each processor 22a to 22e, and holds a queue management information table 7, resources (queues) 6a to 6c, 6q, and data other than these. The table area 6d and the memo recording unit 8 are provided.
【0062】
Each of the resources 6a to 6c is a memory area acquired to hold call information A to C related to a plurality of calls, and a plurality of queues A to C are generated in this memory area. Resource 6q is also a memory area acquired to hold call information D related to a plurality of calls, and a queue D is generated. Since each of RNC84a to 84b receives a large number of calls, one resource is allocated to one device in order to efficiently manage a large number of calls. That is, the shared memory 3 allocates resources for each of the BTS 83a to 83c by the resource allocation function generally possessed.
【0063】
For example, in the shared memory 203 shown in FIG. 21 (a), resources A to C corresponding to three BTS 83a to 83c are allocated, and a plurality of received calls are inserted into queues A to C, respectively. In addition, it is fetched (dequeue). Therefore, since the number of inserted queues A to C is different and the range of the queue area is different, the queue management information table 7 holds the queue management information about the queue that manages the resource that holds the call information. is there.
【0064】
(3-6) Queue management information table 7 The queue management information table 7 is a plurality of information elements that specify the size of the queue and the position of the queue that manage the resources that hold the call information acquired by each processor 22a to 22e. Holds queue management information consisting of. This information element is, for example, the number of queue management (total number of queues), the first queue address, the front queue address, and the back queue address, and may also include the last queue address.
【0065】
This enables efficient queue management by using each information element. Further, the queue management information table 7 holds queue management information including at least the number of queue management and the start queue address for the queue that manages the resource that holds the call information acquired by each processor 22a to 22e. This is because each queue can be identified according to these two types of elements.
【0066】
(3-7) Memo recording unit 8 Next, the memo recording unit 8 (see FIG. 8) records the update history of the queue management information in the queue management information table 7. That is, the memo recording unit 8 records a plurality of update information elements (for example, the number of queue management, the first queue address, the previous queue address, and the second queue address) to be written in the queue management information of the queue management information table 7. The memo recording unit 8 secures, for example, three memo recording units (memo recording units) 1, 2, and 3 to record the number of queue management and the like. For example, memo records 1 and 2 can temporarily write the number of queues managed and the first queue address, respectively, and memo records 1, 2 and 3 can write the number of the queue to be fetched, the previous queue address, and the next, respectively. You can also write the queue address temporarily. That is, the memo recording unit 8 records the update information element to be written in the queue management number and the start queue address held in the queue management information table 7.
【0067】
Then, when each call processing unit 2a to 2e (see FIG. 4) receives a control signal from the distributed control unit 9, they acquire a physical resource from the shared memory 3, generate a queue in the acquired resource, and generate the queue. Information about the queues that have been created is centrally stored in the queue management information table 7. As a result, each of the processors 22a to 22e refers to the queue and performs signal processing while updating the queue. Further, for example, when the call processing unit 2a is overloaded, other call processing units 2b to 2e process data.
【0068】
(3-8) Clock unit 88, etc. The RNC (see Fig. 3) is the clock unit (CLK) 88 that generates the reference timing, the trunk card DHT (Diversity Handover Trunk card) 89a that performs diversity handover processing, and the wireless line. It also has a Mac Multiplexer M-MUX (Mac Multiplexer) 89b, BWC that handles multiplexing for the MAC (Media Access Control) layer.
【0069】
In addition, HDD4a (see Fig. 3) holds the information acquired about the firmware. The debugger 5f writes and reads the shared memory 3, and this writing and reading is possible by outputting a signal for writing and reading to the bus 5e. (3-9) Example of mounting The load distribution device 1 is provided on the board (backboard) of the back portion of the device rack of RNC84a to 84b.
【0070】
FIG. 6 is a schematic view of the load distribution device according to the first embodiment of the present invention as viewed from above. The load distribution device 1 shown in FIG. 6 has the functions of the interprocessor communication device 5, the call processing units 2a to 2e, the debugger 5f, the shared memory 3, the clock unit 88, and the power supply unit 88a on the flat backboard 82. The substrate to be held is inserted vertically. That is, each function is realized for each board, which reduces the burden of maintenance and the like, and can flexibly respond to changes in system specifications. The shaded area shown in FIG. 6 represents the upper surface of the backboard 82.
【0071】
Each board is assigned an ID (Identification) so that it can communicate with each other via a signal transmission line. As a result, the processors can communicate with each other via the shared memory 3. In an example of this mutual communication, each processor 22a to 22e acquires an ID included in the data output to the bus 5e, and compares the acquired ID with an ID stored in a register (not shown) in advance. , It is determined whether or not to use the data.
【0072】
In addition, each board is removable, and the number of CP boards can be increased or decreased according to the processing capacity of the call processing units 2a to 2e. The load distribution device 1 is provided with a total of 6 CP boards, including 5 current CP boards and 1 spare CP board, and can support 48 BTS 83a to 83c. A spare CP board (not shown) is provided in case one of the five CP boards fails.
【0073】
RNC84a to 84b can use a redundant configuration including a plurality of active system (active: ACT) CP boards and a standby system (standby: STBY) CP board. Here, the spare CP board is provided for failure or maintenance of the active CP board, and when any of the active CP boards fails, the physical communication path connected to the external device is changed. , It is cut from the failed CP board and connected to the spare CP board. This constitutes a load-distributed multiprocessor system.
【0074】
Furthermore, resources corresponding to each of the 48 BTS83a to 83c are secured in the shared memory 3 of the CM board, and the CP boards of the BTS83a to 83c are created by the cooperation of the processors 22a to 22e and the shared memory 3. When the load is overloaded, another CP board for BTS83a to 83c processes the data of BTS83a to 83c.
【0075】
In this way, the load distribution device 1 can process an extremely large amount of call processing data, and can recognize the call to be processed from the large number of calls and process them appropriately, whereby data multiplexing and data separation can be performed. It will be possible. (3-10) Recovery processing When processors 22a to 22e for queue operation fail, the difference between the actual number of queue management and the number of queue management written to the queue, or the next queue address and the previous next queue address There is a difference with.
【0076】
Each of the processors 22a to 22e has a detection function for detecting the occurrence of a failure, and in the present embodiment, the failure detection function of the master processor 22a is operated. Specifically, the master processor 22a triggers recovery processing by an external interrupt from the hardware, and for example, using software by the master processor 22a, both states of the queue management information table 7 and the memo recording unit 8. To compare.
【0077】
Then, the master processor 22a that has detected the failure performs recovery processing so that the program can be executed normally. This recovery processing function is realized by, for example, the call processing unit 2a and the shared memory 3, but can also be realized by other call processing units 2b to 2e (software by the processors 22b to 22e) and the shared memory 3.
【0078】
(3-11) Judgment unit (judgment means) 25a and recovery unit (recovery means) 25b Both the judgment unit 25a and the recovery unit 25b must be provided in each call processing unit 2a to 2e. This is a processor 22a to 22e as hardware that can normally perform recovery processing even if a failure occurs when any of the processors 22a to 22e accesses the shared memory 3, and a call processing unit as software. This is because 2a to 2e are secured.
【0079】
FIG. 7 is a schematic block diagram of the determination unit and the restoration unit according to the first embodiment of the present invention, and the determination unit 25a and the restoration unit 25b shown in FIG. 7 are both call processing units 2a to 2e. It is provided in. Here, the determination unit 25a records the queue management information held in the queue management information table and a memo when any of the processors 22a to 22e fails when accessing the queue management information. The necessity of recovery processing is determined based on the update history information recorded in Part 8.
【0080】
The call processing unit 2a and the shared memory 3 cooperate with each other to exert the functions of the determination unit 25a and the recovery unit 25b. Further, the recovery unit 25b recovers the queue management information based on the update history information when the determination unit 25a determines that the recovery process is necessary. The acquisition and release of shared memory 3 resources are always queue-managed, and processor 22a has accessed the information elements (number of queues managed, first queue address, previous queue address, second queue address) required for queue management. When a failure occurs, the determination unit 25a determines whether or not the queue management information table 7 of the shared memory 3 has been destroyed based on the contents of the memo recording unit 8. If the queue management information table 7 is destroyed, the determination unit 25a causes the recovery unit 25b to perform a complete recovery process, and if the queue management information table 7 is not destroyed, the determination unit 25a causes the recovery unit 25b to perform a complete recovery process. Do not perform recovery processing.
【0081】
In this way, since each of the processors 22a to 22e recovers the information by referring to the queue management information of the shared memory 3 based on the memo recording, the queue management information table 7 can be recovered in an extremely short time or instantly. (4) Operation Description With the above configuration, the recovery processing method of the queue management information table 7 of the shared memory 3 of the present invention will be described in detail.
【0082】
When the load distribution device 1 receives the control signal, the load distribution device 1 distributes the load to the processors 22a to 22e and manages the resources of the shared memory 3 by the queue. When each processor 22a to 22e accesses the queue management information table 7, the contents to be written to the queue management information table 7 are first temporarily written to the memo recording unit 8 of the shared memory 3, and the written contents are saved. To do.
【0083】
Here, when data is held across a plurality of queues A to D, when operating, for example, queue C among the plurality of queues A to D, each processor 22a to 22e is accessing the queue C. Occasionally, if any of the processors 22a to 22e fails, a recovery process is performed to recover from the failure.
【0084】
Here, in each of the RNC84a to 84b, two load distribution devices 1 may be provided, and in this way, after the occurrence of a failure is detected, first, the active processor and the spare processor are provided. And are processed to change each other. A failure occurs while each processor 22a to 22e is accessing the queue management information table 7 in the shared memory 3, and after recovery, the number of queue management or the start queue address in the queue management information table 7 does not match the substance. It may have occurred. In this case, the queue management information table 7 is recovered based on the memo information recorded at the time of access.
【0085】
Hereinafter, a method of retrieving the first queue and a recovery processing method will be described. The queue retrieval method in the multiprocessor system of the present invention is in a multiprocessor system (for example, load distribution device 1) having a processor 22a to 22e for processing a communication call and a shared memory 3 accessible to the processors 22a to 22e. ..
【0086】
First, queue management that holds queue management information consisting of a plurality of information elements that specify the size of the resource management queue acquired by any of the processors 22a to 22e (for example, the processor 22a itself) and the position of the queue. Browse the information table (reference step). That is, the number of queue management, the first queue address, the front queue address, and the back queue address are referred to.
【0087】
Next, each processor 22a to 22e records the update history including the plurality of update information elements to be written in the queue management information of the queue management information table 7 in the memo recording unit (update history recording area) 8 (recording step). That is, the number of queue management to be updated, the first queue address, the front queue address, and the rear queue address are recorded in the memo recording unit 8.
【0088】
Then, each processor 22a to 22e writes the update history to the queue management information table 7 (write step). The queue removal method will be described in more detail. In the above reference, each processor 22a to 22e refers to the number of queue management, the number of queue management among the number of queue management, the first queue address, the front queue address, and the rear queue address, and the first queue address as information elements.
【0089】
Next, in the recording, each processor 22a to 22e records the updated queue management number (first update value) or the updated first queue address (second update value) as the update information element. Then, upon the writing, each processor 22a to 22e writes the updated queue management number or the updated head queue address to the queue management information table 7.
【0090】
The queue retrieval method will be specifically described below. (5) How to take out the first queue. Refer to Fig. 8 and Fig. 9 to explain how to delete the first queue (resource). Here, steps J1 to J5 shown in FIG. 8 correspond to steps J1 to J5 shown in FIG.
【0091】
FIG. 8 is a diagram for explaining a head queue extraction method according to the first embodiment of the present invention. In FIG. 8, the memo recording unit 8, the queue management information table 7, and the queues A to D are displayed, and the upper half of the page is the memo recording unit 8 and the queue management information before the queue is taken out. Represents the state of table 7 and queues. The lower half represents their state after queuing. The direction from top to bottom represents the passage of time. Here, before the queue is taken out, the queues A to D are generated, and the first queue A is taken out from the queues A to D. The queue management information table 7 holds the start queue address and the total number of queues forming the queue columns A to D.
【0092】
FIG. 9 is a flowchart for explaining the head queue retrieval process according to the first embodiment of the present invention. This first queue retrieval process will be described using the processor 22a as an example. The processing for the processors 22b to 22e is also the same as the processing for the processors 22a. (J1) Processor 22a retrieves the queue (resource) queued at the beginning. When the processor 22a retrieves the first queue, it refers to the queue A by referring to the first queue address from the queue management information table 7.
【0093】
(J2) The processor 22a sets the next queue address of the queue (resource) queued at the beginning of memo recording 2. The next queue address B of the queue (resource) queued at the beginning is taken out and set to memo recording 2. (J3) The processor 22a holds the queue management number (total number) in the memo record 1, and sets the memo record 1 to 3 which is obtained by subtracting 1 from the queue management number 4 in the queue management information table 7.
【0094】
If a failure occurs while the processor 22a is rewriting the memo records 1 and 2 in step J2 or step J3 (step J6a), recovery is not performed (step J6b). (J4) The processor 22a rewrites the start queue address of the queue management information table 7 from the queue A to the address of the queue B.
【0095】
(J5) The processor 22a subtracts 1 from the queue management number of the queue management information table 7 by taking out the queue A and sets it to 3. If a failure occurs while the processor 22a is rewriting the queue management information table 7 in step J4 or step J5 (step J7a), the determination unit 25a determines that recovery processing is necessary, and records memo 1 Rewrite, 2 (step J7b).
【0096】
This simplifies the recovery process and realizes high-speed recovery. (6) Recovery Processing Method The table recovery processing method in the multiprocessor system of the present invention is in a multiprocessor system having a plurality of processors 22a to 22e for processing communication calls and a shared memory 3 accessible to the processors 22a to 22e. It is a thing.
【0097】
First, among the processors 22a to 22e, for example, the processor 22a identifies the size of the resource management queue acquired by itself and the position of the queue (number of queue management, first queue address, front queue address, and rear queue address). Queue management information that holds queue management information consisting of information elements, and update information elements such as the number of updated queue management to be written to the queue management information in queue management information table 7 (number of queue management, start queue address) The necessity of recovery processing is determined based on the update history information of the memo recording unit 8 that records the update history consisting of the front queue address and the rear queue address (determination step).
【0098】
Then, when any of the above processors determines that recovery is necessary in the above determination, the queue management information is restored based on the update history information (recovery step). This allows multiple processors 22a-22e to work together, making the system more resilient to failures.
【0099】
Next, the table recovery processing method will be described in more detail. In determining the necessity of recovery processing, one of the plurality of processors 22a to 22e determines the number of queue managements or the first queue address of the queue management information held in the queue management information table 7, and the memo recording unit 8. Judgment is necessary based on the number of queues managed or the match / mismatch with the start queue address.
【0100】
Further, upon recovery, one of the processors rewrites the queue management number or the head queue address of the memo recording unit 8 to the queue management number or the head queue address of the queue management information table 7 based on the necessity. In this way, recovery processing after a failure can be performed quickly. Next, a recovery processing method when a failure occurs while fetching the first queue will be described with reference to FIG.
【0101】
FIG. 10 is a flowchart for explaining the recovery process for taking out the head queue according to the first embodiment of the present invention. Each of the processors 22a to 22e can carry out the recovery process described below, the processor 22a will be described, and the detailed description of the processors 22b to 22e will be omitted. Here, reference numerals 1 to 6 shown in FIG. 10 correspond to the following (6-1) to (6-6), respectively.
【0102】
(6-1) The determination unit 25a determines whether the start queue address of the memo record 2 and the start queue address of the queue management information table 7 match. (6-2) If the judgment results do not match, the judgment unit 25a goes through the "mismatch" route, rewrites the memo record 2, and then a failure occurs before rewriting the information in the queue management information table 7. It is in a state of not being done. Therefore, the memo recording is ignored and the recovery process is not executed.
【0103】
(6-3) If the judgment results match, the judgment unit 25a rewrites the memo record 1 if they match, and indicates the rewritten state when the information in the queue management information table 7 is normal. There is. (6-4) The determination unit 25a determines whether the number of queues managed in the memo record 1 and the number of queues managed in the queue management information table 7 match.
【0104】
(6-5) If the determination results do not match, the determination unit 25a rewrites the memo record 1, and when a part of the queue management information table 7 is normal, it is in a state of not being rewritten. Therefore, it is recovered by referring to the memo record 1 and rewriting the number of queue management in the queue management information table 7 to 3. (6-6) If the determination results match, the determination unit 25a is in a state where the queue management information table 7 and the first queue have been fetched normally when they are normal. Therefore, recovery is unnecessary.
【0105】
(6-7) If the judgment result of the judgment unit 25a in (6-1) above is "mismatch", a failure occurs before writing the queue management information table 7 through the route marked "mismatch". Therefore, the determination unit 25a determines that it is not damaged and does not perform recovery processing. (6-8) If the determination unit 25a determines in (6-4) above that the queue management numbers do not match, it passes through the NO route and the start queue address of the queue management information table 7 has been rewritten. Determine that a failure has occurred.
【0106】
(6-9) The determination unit 25a performs a recovery process that replaces the number of queue managements for memo recording with the number of queue managements in the management number queue management information table 7. The operation of fetching the first queue of the processors 22b to 22e is the same as the operation of the processors 22a. In this way, in this recovery processing method, the acquisition and release of the resources of the shared memory 3 are queue-managed, and the information areas such as the number of queue managements required for this queue management, the first queue address, the front queue address, and the rear queue address. Is saved as a memo recording unit 8 before it is accessed. As a result, the recovery process can be performed in a single time and at high speed. Therefore, the induction of double disability is avoided.
【0107】
Then, regarding the queue management information table 7, it is possible to perform a process as if only by recording a memo, and it is possible to recover using the minimum data required for the recovery process, and the system can be simplified. (7) How to take out a queue located between a plurality of queues With reference to FIGS. 11 and 12, queue C queued between queues A to D (hereinafter, intermediate queue C in FIGS. 11 and 12). A method of taking out and deleting (referred to as) will be described. The processor 22a will be described, and duplicate description of the processors 22b to 22e having the same functions as the processor 22a will be omitted. The symbols K1 to K6 shown in FIGS. 11 and 12 correspond to each other.
【0108】
FIG. 11 is a diagram for explaining a method of taking out the intermediate queue C according to the first embodiment of the present invention, and the queue management information table 7 holds the address of the head queue A. FIG. 12 is a flowchart for explaining the process of taking out the intermediate queue C according to the first embodiment of the present invention.
【0109】
(K1) Processor 22a takes out queue C on the way. (K2) The processor 22a acquires the address of the first queue A in the queue management information table 7, and sequentially traces the queue from the first queue A to the queue D to refer to the intermediate queue C and record a memo. Queue C is set to 1 on the way. (K3) The processor 22a writes the address of the previous queue B of the intermediate queue C to the memo record 2 and takes out the intermediate queue C. Therefore, since the next queue of the queue B is changed from the intermediate queue C to the queue D, the processor 22a sets the address of the previous queue B of the intermediate queue C to the address (B) in the memo recording 3.
【0110】
(K4) Since the queue D is changed by taking out the intermediate queue C, the processor 22a sets the next queue address (D) of the intermediate queue C in the memo recording unit 3. If a failure occurs while the processor 22a is rewriting the queue management information table 7 in each of steps K2, K3, and K4 (step K7a), the determination unit 25a determines that recovery processing is unnecessary (step K7b). ).
【0111】
(K5) The processor 22a rewrites the address of the next queue D of the queue B from C to D in the memo recording unit 3. (K6) Processor 22a rewrites the previous queue address of queue D from C to B. If a failure occurs while the processor 22a is rewriting the queue management information table 7 in step K5 or step K6 (step K8a), the determination unit 25a determines that recovery processing is necessary, and the recovery unit 25b Rewrites the contents of memo records 1 to 3 into the queue management information table 7 (step K8b).
【0112】
The operation of taking out the queue C in the middle of the processors 22b to 22e is the same as the operation of the processors 22a. (8) Recovery processing method Refer to Fig. 13 to explain the recovery processing method when a failure occurs while retrieving queue C on the way.
【0113】
FIG. 13 is a flowchart for explaining the recovery process for taking out the intermediate queue according to the first embodiment of the present invention. The determination unit 25a described below is the same as the operation of the processor 22a. Reference numerals 1 to 7 shown in FIG. 13 correspond to (8-1) to (8-7) shown below, respectively. (8-1) The determination unit 25a derives the intermediate queue C from the information of the memo record 1, determines the match / "mismatch" between the previous queue address of the intermediate queue C and the previous queue address of the memo record 2, and also determines The determination unit 25a determines a match / mismatch between the next queue address and the next queue address of the memo recording unit 3.
【0114】
(8-2) When the judgment results do not match Since the dequeue has already been performed, the previous queue address of the memo recording 2 and the previous queue address of the intermediate queue C do not match, and the next address of the memo recording unit 3 Does not match the next queue address of queue C on the way. In this case, the recovery is not performed through the NO route.
【0115】
(8-3) When the determination results match The determination unit 25a determines whether or not the address of the queue C in the middle of memo recording 1 and the address of the next queue of the queue B are the same through the YES route. To do. (8-4) If the judgment results do not match, the NO route is passed, recovery is not performed, and the process ends.
【0116】
(8-5) When the determination results match In the determination in (8-3) above, the determination unit 25a determines whether the intermediate queue C address of memo recording 1 and the previous queue address of queue D are the same. Is determined. (8-6) When the judgment results do not match The judgment unit 25a has not completed the retrieval yet, passes through the NO route, and the intermediate queue C is set to the next queue address of the queue B. As a result, the recovery process is executed.
【0117】
(8-7) When the judgment results match Since the retrieval process is not executed and the dequeue process is not performed through the YES route, the recovery process is not necessary. (9) Comparison between the conventional table recovery processing method and this table recovery processing method.
【0118】
Regarding the queue management information table 7 when a failure occurs, the conventional table recovery processing method is that each processor 22a to 22e is bidirectional between the intermediate queue connected to the first queue and the intermediate queue connected to the final queue. The queue management information table 7 was recovered based on the success or failure of the count value by tracing the number of connected queues from and counting the number of queues in both directions. Therefore, the processors 22a to 22e took a lot of time to recognize the occurrence of the failure.
【0119】
On the other hand, according to this table recovery processing method, each processor 22a to 22e manages the acquisition and release of the resource of the shared memory 3 in a queue, and the processors 22a to 22e are required for queue management. If a failure occurs when accessing the information area, the recovery unit recovers the information by referring to the queue management information in the shared memory 3 based on the memo record, so that the queue management information table 7 can be displayed in a very short time or instantly. Can be recovered.
【0120】
(10) How to insert the queue The method of inserting the queue D will be described with reference to FIGS. 14 to 16. FIG. 14 is a diagram for explaining a method of inserting a cue according to the first embodiment of the present invention, and shows a method of inserting and connecting a cue D into three cues A to C. The queue management information table 7 holds the start queue address and the total number of connected queues.
【0121】
The enqueue method will be described, for example, when the processor 22a is used, but the operation of taking out the first queue of the processors 22b to 22e is the same as the operation of the processor 22a. FIG. 15 is a flowchart for explaining the enqueue process according to the first embodiment of the present invention.
【0122】
(10-1) Creation of queue D Since the processor 22a becomes the final queue, the next queue address of queue D holds the final (END) (step L1). (10-2) Processor 22a holds the address of queue C in memo recording 2 (step L2).
【0123】
(10-3) The processor 22a sets the address of the queue D to be enqueued in the memo recording unit 3 (step L3). (10-4) The processor 22a holds the number of queue management (total number) in the memo record 1. Here, 1 is added (+1) by connecting a queue from the number of queues managed in the queue management information table 7 to memo record 1, and 4 is set (step L4).
【0124】
(10-5) The processor 22a rewrites the next queue address of queue C, searches the queue C to be changed by tracing the queue from the first queue address in the queue management information table 7, and sets the next queue address from the last (END). Rewrite to D (step L5). (10-6) Rewrite the queue management number in the queue management information table 7 The queue management number in the queue management information table 7 is set to 4 by connecting the queue D (step L6).
【0125】
In steps L2 to L4, if a failure occurs while the processor 22a is rewriting the memo records 1 and 2 (step L6a), recovery is not performed (step L6b). Further, in step L5 or step L6, if a failure occurs while the processor 22a is rewriting the queue management information table 7 (step L7a), the determination unit 25a determines that recovery processing is necessary, and records a memo 1 Rewrite, 2 (step L7b).
【0126】
(11) Enqueue Recovery Processing Method FIG. 16 is a flowchart for explaining the enqueue recovery processing according to the first embodiment of the present invention. The recovery processing method when a failure occurs during enqueue will be described. Reference numerals 1 to 6 shown in FIG. 16 correspond to (11-1) to (11-6) shown below, respectively.
【0127】
(11-1) The determination unit 25a determines whether the next queue address of the queue C of the memo recording unit 2 and the next queue address of the queue C of the memo recording unit 3 match. (11-2) When the determination results do not match The determination unit 25a passes through the NO route, determines that the queue C is not damaged, and does not perform recovery processing. That is, since a failure occurred before writing the next queue address of queue C, the queue is not damaged. Therefore, it is determined that recovery processing is unnecessary, and the processing ends.
【0128】
(11-3) When the judgment results match In this case, the judgment unit 25a passes through the YES route, and corresponds to the state in which the next queue address information of the memo recording unit 3 and the queue C is rewritten when it is normal. .. (11-4) The determination unit 25a determines whether or not the number of queue management in the memo record 1 and the number of queue management in the queue management information table 7 match.
【0129】
(11-5) When the judgment results do not match In this case, after the next queue address of queue C is rewritten, the judgment unit 25a is in a state where a failure occurs and the queue management information table 7 is not rewritten. Equivalent to. Therefore, the determination unit 25a passes through the NO route, refers to the memo record 1, and performs the recovery process of rewriting the number of queue management in the queue management information table 7 to 4.
【0130】
(11-6) When the judgment results match In this case, since the rewriting of the queue management information table 7 and the queue C has been completed normally, the judgment unit 25a passes through the YES route and the recovery process is not required. The process ends. In this way, the enqueue recovery process is performed.
【0131】
Further, in this way, it is possible to realize a highly reliable system that operates at high speed due to the simplified processing method. (B) Description of the Second Embodiment of the Present Invention In the shared memory 3, when the queue representing the call that ended the call is deleted, the vacant resource (memory area or buffer area) is released, and the released resource is different. Is acquired by the call processing units 2a to 2e (or processors 22a to 22e) that process the call of. Therefore, the size of the resource of the shared memory 3 is not fixed and fluctuates for each of the call processing units 2a to 2e.
【0132】
Here, if a failure occurs when the call processing units 2a to 2e delete a queue that is no longer needed due to the end of the call, the queue management information table 7 is destroyed, and this destruction is one of the resources of the shared memory 3. It causes the part to remain occupied, and also causes a decrease in the resources allocated to each processor 22a to 22e. Therefore, the mobile communication system in the second embodiment uses a state monitoring table to determine the resource status or communication status of each communication device (opposite communication device) such as MS10a, BTS83a to 83c or RNC84a to 84b in the mobile communication system. Distributed monitoring or distributed management.
【0133】
FIG. 17 is a configuration diagram of a mobile communication system according to a second embodiment of the present invention. The mobile communication system 100a shown in FIG. 17 uses a CDMA system, and has an RNC (communication device) 84p, a plurality of BTS (opposite communication devices) 83p communicating with the RNC 84p, and an MS (mobile device). It is configured with 10p. Here, the MS10p is provided with a control unit 86p having a shared memory 29 that can be accessed by a plurality of processors 22a to 22e, and the BTS83p is provided with a mobile device control unit 87p having a shared memory 29. Further, the RNC84p is provided with a distributed control unit 1a having a shared memory 29. All of these MS10p, BTS83p, and RNC84p allocate the status monitoring table to the shared memory 29. It should be noted that, among those shown in FIG. 17, those having the same reference numerals as those described above represent the same ones.
【0134】
The status monitoring table holds the above communication status including the resource status of the shared memory 3 that can be accessed by the plurality of processors 22a to 22e. In this status monitoring table, the queue address and the usage status of the storage area corresponding to the queue address are stored in association with each other in the shared memory 29. FIG. 18 is a diagram schematically showing an area of the shared memory 29 according to the second embodiment of the present invention. The shared memory 29 shown in FIG. 18 has a status monitoring table 30 that holds the communication status including the resource status, communication status holding units 31a to 31c that hold the communication status of a plurality of BTS 83a to 83c, and a status monitoring table 30. It has a memo recording unit (communication status recording area or memo recording area) 32 for recording the communication status held in the table. Further, the memo recording unit 32 has a memo recording (memo recording area) 32a to 32c.
【0135】
As a result, the processors 22a to 22e provided in each communication device, ROM23 and RAM24 (see FIG. 4) cooperate with each other to function as call processing units 2a to 2e. Then, the resource status monitoring units (not shown) of these call processing units 2a to 2e monitor the resource status acquired in the shared memory 29. This makes it possible to check, for example, the operating state of software having a call processing function for each of the call processing units 2a to 2e.
【0136】
In addition, when each call processing unit 2a to 2e recognizes an abnormality in the resource status, the shared memory 29 is restored using the status monitoring table, and the management unit and the recovery unit (not shown) are provided. It is composed of. Here, the management unit divides the resource of the shared memory 29 into pages of a predetermined size, manages whether or not each page is updated, holds the information in the management data file, and also keeps the updated page data. Is stored in the update data file.
【0137】
Further, the recovery unit recovers the data held in the shared memory 29 based on the information of the management data file and the update data file at the time of failure recovery. Then, for example, when the call processing unit 2a and the shared memory 29 shown in FIG. 17 cooperate with each other, each function of the management unit and the recovery unit is exhibited. With respect to the resource, this management unit can grasp the situation between the device-device or the device-terminal (that is, the local failure occurrence situation) corresponding to the failure occurrence part in the status monitoring table.
【0138】
Further, the condition monitoring table 30 is connected to the recovery unit 33, the initialization unit 34, and the selection unit 35, respectively, and is referred to by the recovery unit 33, the initialization unit 34, and the selection unit 35. There is. Here, the recovery unit 33 recovers a local failure-occurring portion of the condition monitoring table 30 based on the communication state held in the memo recording unit 32. In addition, the initialization unit 34 initializes the local failure occurrence portion of the plurality of communication states 1 to N held by the condition monitoring table 30. Further, the selection unit 35 implements one of the recovery unit 33 and the initialization unit 34.
【0139】
Therefore, the condition monitoring table 30 is necessary as a recovery processing method that initializes the table contents and invalidates the information in the recovery processing after a failure, instead of holding all the information in the management data file. Two local recovery processes are possible: a recovery process that notes only the information and resets its state. As a result, the status of the resource of the device, device or MS10a such as BTS83p (see FIG. 17) is monitored or managed by using the status monitoring table 30. Specifically, in the mobile communication system 100a, when the remote terminal 11a is talking to the MS10a, the call between the remote terminal 11a and the MS10a is the public network 85a, the core network 101, the exchange 102, the RNC84a to 84b and It is connected via BTS83a ~ 83c. In the state where this call is connected, each network or various communication devices mutually manages and monitors the ID and the like of the communication partner device.
【0140】
Further, as a result, the operator of the monitoring system 100a or the failure occurrence part of the management system 100a does not have to bear the burden of constantly checking the queue of the shared memory 29 of the RNC84p. Therefore, it takes time and man-hours to elucidate, and the occurrence of a failure can be detected relatively early. With such a configuration, when a failure occurs, the communication status is invalidated by recovering the status monitoring table 30 (first recovery) based on the memo record and initializing the recovered status monitoring table 30. Recovery (second recovery) is selectively performed.
【0141】
As a result, it is not necessary to manage the entire mobile communication system 100a, and the failure that has occurred between the local communication devices can be recovered by referring to the condition monitoring table 30. In this way, when managing various communication devices using the condition monitoring table 30, the table is not destroyed even if a failure occurs during table access by the processors 22a to 22e. In addition, abnormal operation of the program due to the occurrence of a failure and the introduction of system processing errors are both avoided.
【0142】
The condition monitoring system in the second embodiment can also be applied to a system using a multiprocessor system, an electronic device, or the like, and can be applied to various units such as a terminal, a call, a base station, or a computer. An example of applying this monitoring system to the mobile communication system 100 (see FIG. 2) will be described. The monitoring system can be used not only for mobile communication but also for other purposes.
【0143】
(C) Others The present invention is not limited to the above-described embodiments and modifications thereof, and can be variously modified and implemented without departing from the spirit of the present invention. (D) Appendix (Appendix 1) In a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, the shared memory is a resource for holding call information related to the communication call. A multiprocessor system characterized in that a queue management information table for holding queue management information about a management queue and an update history recording area for recording the update history of the queue management information in the queue management information table are provided.
【0144】
(Appendix 2) In a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, the shared memory holds call information related to the communication call acquired by each processor. From a queue management information table that holds queue management information consisting of a plurality of information elements that specify the size of the resource management queue and the position of the queue, and a plurality of update information elements that are written to the queue management information of the queue management information table. A multiprocessor system characterized by providing an update history recording area for recording the update history.
【0145】
(Appendix 3) In a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, the shared memory holds call information related to the communication call acquired by each processor. Write to the queue management information table that holds queue management information including at least the number of queue management and the start queue address for the resource management queue to be used, and the number of queue management and the start queue address held in the queue management information table. A multiprocessor system characterized in that an update history recording area for recording an update history composed of a plurality of update information elements is provided.
【0146】
(Appendix 4) When one of the plurality of processors fails when accessing the queue management information, the queue management information held in the queue management information table and the update history record are recorded. A determination unit that determines the necessity of recovery processing based on the update history information recorded in the area, and recovers the queue management information based on the update history information when the determination unit determines that recovery is necessary. The multiprocessor system according to any one of Appendix 1 to Appendix 3, characterized in that it is configured to include a recovery unit.
【0147】
(Appendix 5) A queue management information table that holds queue management information for a plurality of processors that process communication calls, shared memory that can be accessed by the plurality of processors, and a resource management queue that holds call information related to the communication call. A multiprocessor system comprising the above, wherein the shared memory is provided with an update history recording area for recording the update history of the queue management information of the queue management information table.
【0148】
(Appendix 6) In a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, each processor holds a queue for a resource management queue for holding call information related to the communication call. A multiprocessor system characterized by sharing a queue management information table that holds management information and an update history recording area that records an update history of queue management information in the queue management information table.
【0149】
(Appendix 7) In a multiprocessor system having a plurality of processors for processing information data and a shared memory accessible by the plurality of processors, the shared memory holds various information related to the information data in a resource management queue. A multi-processor system characterized in that a queue management information table for holding queue management information and an update history recording area for recording update history of queue management information in the queue management information table are provided.
【0150】
(Appendix 8) A plurality of processors that process a communication call and a memory having a queue management information table that holds queue management information about a resource management queue that the plurality of processors access and hold call information related to the communication call. A multiprocessor system, wherein each processor shares an update history recording area provided in the memory and records an update history of queue management information in the queue management information table.
【0151】
(Appendix 9) In a multiprocessor system having a plurality of processors that process call information related to communication and a shared memory that the plurality of processors can access and hold the call information, the shared memory is a call related to the communication call. It is characterized in that a queue management information table that holds queue management information about a resource management queue that holds information and an update history recording area that records the update history of the queue management information of the queue management information table are provided. Multi-processor system.
【0152】
(Appendix 10) Queue management information about a resource management queue that includes a plurality of processors that process communication calls and shared memory that can be accessed by the plurality of processors, and the shared memory holds call information related to the communication call. A multiprocessor system characterized in that a queue management information table for holding the above and an update history recording area for recording the update history of the queue management information of the queue management information table are provided.
【0153】
(Appendix 11) In a monitoring system that monitors a communication state between a communication device and an opposite communication device that communicates with the communication device, a state monitoring table that holds the communication state and communication held in the state monitoring table. Communication between the communication status recording area that records the status, the recovery unit that recovers the local failure occurrence part of the status monitoring table based on the communication status held in the communication status recording area, and the status monitoring table. A monitoring system characterized in that it is provided with an initialization unit that initializes a local failure occurrence part of the state and a selection unit that executes at least one of the initialization units.
【0154】
(Appendix 12) A plurality of processors that process communication calls, a distributed control unit that distributes communication calls from external devices according to the load of the plurality of processors, and a shared memory that can be accessed by the plurality of processors are provided. , The shared memory records the queue management information table that holds the queue management information for the resource management queue that holds the call information related to the communication call, and the update history record that records the update history of the queue management information of the queue management information table. A load distribution device characterized by providing an area.
【0155】
(Appendix 13) A queue retrieval method in a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, which is acquired by any one of the plurality of processors. A reference step that refers to a queue management information table that holds queue management information consisting of a plurality of information elements that specify the size of the resource management queue and the location of the queue, and each processor uses the queue of the queue management information table. A recording step of recording an update history composed of a plurality of update information elements to be written in management information in an update history recording area, and a writing step of each processor writing the update history to the queue management information table. A featured method of queuing in a multiprocessor system.
【0156】
(Appendix 14) In the reference step, each processor refers to at least one of the queue management number and the start queue address as the plurality of information elements, and in the recording step, each processor updates the queue. As an information element, at least one of the first update value of the queue management number and the second update value of the first queue address is recorded, and in the write step, each processor causes the first update value and the second update value. The queue retrieval method according to Appendix 13, wherein at least one of the second update value is written to the queue management information table.
【0157】
(Appendix 15) A table recovery processing method in a multiprocessor system having a plurality of processors for processing communication calls and a shared memory accessible by the plurality of processors, wherein one of the plurality of processors is used. Write to the queue management information of the queue management information table that holds the queue management information consisting of a plurality of information elements that specify the size of the acquired resource management queue and the position of the queue, and the queue management information of the queue management information table. A determination step for determining the necessity of recovery processing based on the update history information in the update history recording area for recording an update history composed of a plurality of update information elements, and a determination step for determining that recovery is necessary in the determination step. , A table recovery processing method in a multiprocessor system, comprising a recovery step for recovering the queue management information based on the update history information.
【0158】
(Appendix 16) In the determination step, each processor manages the first queue management number or the first first queue address as a plurality of information elements of the queue management information, and the second queue management as the plurality of update information elements. The necessity is determined based on the number or the match / mismatch with the second head queue address, and the recovery step is performed by each processor based on the necessity, the second queue management number or the second head. The table recovery processing method according to Appendix 15, wherein the queue address is rewritten to the first queue management number or the first first queue address.
【0159】
[Effect of the invention]
As described in detail above, the multiprocessor system (claims 1 and 2), the monitoring system (claim 3), the queue retrieval method in the multiprocessor system (claim 4), and the table recovery process in the multiprocessor system of the present invention. According to the method (claim 5), the following effects or advantages can be obtained.
【0160】
(1) According to the multiprocessor system of the present invention, in a multiprocessor system having a plurality of processors for processing a communication call and a shared memory accessible by the plurality of processors, the shared memory holds call information related to the communication call. Since a queue management information table that holds queue management information about the resource management queue to be used and an update history recording area that records the update history of the queue management information in the queue management information table are provided, processing is simplified and high speed is provided. A highly reliable multiprocessor system that operates on is realized.
【0161】
(2) According to the multiprocessor system of the present invention, the shared memory is composed of a plurality of information elements that specify the size and position of the resource management queue that holds the call information regarding the communication call acquired by each processor. Since the queue management information table that holds the queue management information and the update history recording area that records the update history consisting of multiple update information elements to be written in the queue management information of the queue management information table are provided, the queue management information table can be used. If the legitimacy is not established due to a failure, it can be recovered automatically, quickly, and completely (claim 1).
【0162】
(3) According to the multi-processor system of the present invention, queue management information including at least the number of queue management and the start queue address for the resource management queue in which the shared memory holds call information regarding the communication call acquired by each processor. Since the queue management information table that holds the queue management information table and the update history recording area that records the update history consisting of a plurality of update information elements to be written to the queue management number and the start queue address held in the queue management information table are provided. Regarding the processing performance during memo recording and recovery, the queues enqueued in the queue management information table are searched from both the first queue and the last queue, and the search time is long and the search time is variable depending on the number of queues. In contrast to the method, since the number of queues managed in the queue management information table or the head queue address information is retained in the memo record, it is not necessary to search for whether the queue connection is normal or abnormal, and memo recording is minimal. Since the presence or absence of recovery processing can be determined using the area, the shared memory can be effectively used.
【0163】
(4) When each processor fails to access the queue management information, the queue management information held in the queue management information table and the update history information recorded in the update history recording area are used as the basis for each processor. A determination unit that determines the necessity of recovery processing and a recovery unit that recovers queue management information based on update history information when the determination unit determines that recovery is necessary may be provided. Then, when the number of received signals increases and the search time is required to the maximum for the system reliability, the recovery process is performed while the double failure or the exclusive acquisition failure by other processors is induced. Can be performed in a single time and can be performed at high speed, so that the induction of double failure is avoided (claim 2).
【0164】
(5) According to the multiprocessor system of the present invention, in a multiprocessor system having a plurality of processors, a shared memory, and a queue management information table, the shared memory provides an update history recording area, so that the system processes. You can avoid the error. (6) According to the multiprocessor system of the present invention, in a multiprocessor system having a plurality of processors, a shared memory, and a queue management information table, each processor shares the queue management information table and the update history recording area. , Eliminates processing performance due to call loss during recovery and allows other processors to access when a failure occurs while accessing shared memory by the processor.
【0165】
(7) According to the multi-processor system of the present invention, in a multi-processor system having a plurality of processors for processing information data and a shared memory accessible by the plurality of processors, the shared memory holds various information related to the information data. Since a queue management information table that holds queue management information about the resource management queue to be used and an update history recording area that records the update history of the queue management information in the queue management information table are provided, information data other than communication calls can be obtained. However, it is possible to obtain flexibility by simplifying the process, reliability using abundant program capacity, and allocating a relatively large working memory capacity.
【0166】
(8) According to the multiprocessor system of the present invention, a plurality of processors and a memory having a queue management information table are provided, and each processor shares an update history recording area. Recovery processing is possible simply by writing information in the memo record. (9) According to the multiprocessor system of the present invention, there are a plurality of processors that process call information related to communication and a shared memory that can be accessed by the plurality of processors and hold the call information, and the shared memory is a queue management information table. And the update history recording area is provided, so that the recovery process can be simplified.
【0167】
(10) According to the multiprocessor system of the present invention, since a plurality of processors and a shared memory are provided and the shared memory provides a queue management information table and an update history recording area, the recovery process can be performed in a single time. It becomes possible at high speed. (11) According to the multiprocessor system of the present invention, in a monitoring system that monitors the communication status between a communication device and an opposite communication device that communicates with the communication device, a status monitoring table that holds the communication status and status monitoring. A communication status recording area that records the communication status held in the table, a recovery unit that recovers the local failure occurrence part of the status monitoring table based on the communication status held in the communication status recording area, and status monitoring. Since an initialization unit that initializes the local failure occurrence part of the communication state of the table and a selection unit that executes at least one of them are provided, a local recovery processing method becomes possible and the amount of memory is increased. It has a fail-safe effect that reduces, speeds up, and does not cause system down (claim 3).
【0168】
(12) According to the load distribution device of the present invention, a plurality of processors for processing a communication call, a distributed control unit for distributing a communication call from an external device according to the load of the plurality of processors, and a plurality of processors access the load distribution device. The shared memory records the update history of the queue management information table that holds the queue management information for the resource management queue that holds the call information related to the communication call, and the queue management information table that holds the queue management information. Since the update history recording area is provided, the induction of double failure is avoided.
【0169】
(13) According to the queue retrieval method in the multiprocessor system of the present invention, a queue consisting of a plurality of information elements that specifies the size of the resource management queue acquired by any of the plurality of processors and the position of the queue. A reference step for referencing the queue management information table that holds management information, and a recording step for recording an update history consisting of a plurality of update information elements that each processor writes in the queue management information of the queue management information table in the update history recording area. And since each processor has a write step to write the update history to the queue management information table, recovery processing can be performed only by recording a memo in the queue management information table, and with the minimum data required for recovery. Recovery is possible and the system can be simplified (claim 4).
【0170】
(14) In the reference step, each processor refers to at least one of the queue management number and the start queue address as a plurality of information elements, and in the recording step, each processor manages the queue as an update information element. The first update value of the number and the second update value of the first queue address are recorded, and in the write step, each processor queues at least one of the first update value and the second update value. You may write to the management information table, which reduces the burden of maintenance and the like, and allows you to flexibly respond to changes in system specifications.
【0171】
(15) According to the table recovery processing method in the multiprocessor system of the present invention, it is composed of a plurality of information elements that specify the size of the resource management queue acquired by any of the plurality of processors and the position of the queue. Based on the queue management information of the queue management information table that holds the queue management information and the update history information of the update history recording area that records the update history consisting of multiple update information elements to be written to the queue management information of the queue management information table. Since it has a judgment step for determining the necessity of recovery processing and a recovery step for recovering queue management information based on update history information when it is determined in the judgment step that recovery is necessary, local recovery is provided. It enables processing methods, reduces the amount of memory, is fast, and has a fail-safe effect that does not cause a system down.
【0172】
(16) In the determination step, each processor performs the first queue management number or the first queue management number as a plurality of information elements of the queue management information and the second queue management number or the second head as a plurality of update information elements. The necessity is determined based on the match / mismatch with the queue address, and in the recovery step, each processor determines the number of second queue management or the second first queue address based on the necessity, and the number of management of the first queue or the first queue. 1 Since it is rewritten to the first queue address, it is not necessary to manage the entire system, and it is possible to recover from a failure between local communication devices of a mobile communication system.
【0173】
In addition, when status monitoring is managed using a table, or when a failure occurs during table access, the table is not destroyed and system processing errors are avoided.
[Simple explanation of drawings]
FIG. 1 is a configuration diagram of a mobile communication system according to the first embodiment of the present invention.
FIG. 2 is a functional block diagram of a mobile communication system according to the first embodiment of the present invention.
FIG. 3 is a schematic block diagram of a base station control device according to the first embodiment of the present invention.
FIG. 4 is a diagram showing a main part of a load distribution device according to a first embodiment of the present invention.
FIG. 5 is a diagram schematically showing an area of a shared memory according to the first embodiment of the present invention.
FIG. 6 is a schematic view of a load distribution device according to a first embodiment of the present invention as viewed from above.
FIG. 7 is a diagram for explaining a recovery process according to the first embodiment of the present invention.
FIG. 8 is a diagram for explaining a head queue retrieval process according to the first embodiment of the present invention.
FIG. 9 is a flowchart for explaining a head queue retrieval process according to the first embodiment of the present invention.
FIG. 10 is a flowchart for explaining a recovery process for taking out the head queue according to the first embodiment of the present invention.
FIG. 11 is a diagram for explaining a method of taking out an intermediate cue according to the first embodiment of the present invention.
FIG. 12 is a flowchart for explaining a process of taking out an intermediate queue according to the first embodiment of the present invention.
FIG. 13 is a flowchart for explaining a recovery process for taking out an intermediate queue according to the first embodiment of the present invention.
FIG. 14 is a diagram for explaining an enqueue method according to the first embodiment of the present invention.
FIG. 15 is a flowchart for explaining an enqueue process according to the first embodiment of the present invention.
FIG. 16 is a flowchart for explaining an enqueue recovery process according to the first embodiment of the present invention.
FIG. 17 is a configuration diagram of a mobile communication system according to a second embodiment of the present invention.
FIG. 18 is a diagram schematically showing an area of a shared memory according to a second embodiment of the present invention.
FIG. 19 is a block diagram of a load-distributed multiprocessor system.
FIG. 20 is a diagram showing a sequence for explaining resource acquisition from shared memory.
FIG. 21 (a) is a diagram showing an example of allocating shared memory before a failure occurs, and FIG. 21 (b) is a diagram showing an example of allocating shared memory after a failure occurs.
FIG. 22 is a diagram showing an example of a shared memory recovery processing operation.
[Fig. 23] (a) to (f) are diagrams for explaining dequeue or enqueue.
[Explanation of symbols]
1 Load distribution device 2a ~ 2e Call processing unit 3,29 Shared memory 4 Hard disk drive 5 Interprocessor communication device 5e Bus 5f Debugger 6a ~ 6c, 6q Resource (queue) 6d Table area 8,32 Memo recording unit (update history recording area) 9,1a Distributed control unit 10a, 10p Mobile phone 10b Video playback device 10c Video phone 11a, 11b Communication partner terminal (other terminal) 22a ~ 22e Processor 23 ROM24 RAM25a Judgment unit 25b Recovery unit 32a ~ 32c Memo recording 33 Recovery unit 34 Initial Processor 35 Selection 82 Backboard 83a ~ 83c, 83p BTS (wireless base station) 84a ~ 84b, 84p RNC (wireless network controller) 85a Line interface 85b ATM switch 85c Output interface 85d Termination 86a Voice receiver 86g Voice transmission Speaker 86b Baseband processing unit 86c Modulation / demodulation unit 86d Transmission / reception amplifier 86e Key information holding unit 86f, 86p Mobile device control unit 87a Highway-in control unit 87b, 87p Base station control unit 88 Clock unit 88a Power supply unit 89a DHT89b M-MUX100,100a Mobile communication system
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US11936609B2 | Cited by | United States of America | Applicant |
| US9992608B2 | Cited by | United States of America | Applicant |
| US11882242B2 | Cited by | United States of America | Applicant |
| US11765275B2 | Cited by | United States of America | Applicant |
| US9621733B2 | Cited by | United States of America | Applicant |
| US11843722B2 | Cited by | United States of America | Applicant |
| US10637938B2 | Cited by | United States of America | Applicant |
| US10122763B2 | Cited by | United States of America | Applicant |
| US11489961B2 | Cited by | United States of America | Applicant |
| US11240381B2 | Cited by | United States of America | Applicant |
| US10212275B2 | Cited by | United States of America | Applicant |
| US10757546B2 | Cited by | United States of America | Applicant |
| US10554825B2 | Cited by | United States of America | Applicant |
| US10257674B2 | Cited by | United States of America | Applicant |
| US11171865B2 | Cited by | United States of America | Applicant |
| US10165015B2 | Cited by | United States of America | Applicant |
| US10853854B2 | Cited by | United States of America | Applicant |
| US10747717B2 | Cited by | United States of America | Applicant |
| US11088984B2 | Cited by | United States of America | Applicant |
| US10051011B2 | Cited by | United States of America | Applicant |
| US9907010B2 | Cited by | United States of America | Applicant |
| US11621911B2 | Cited by | United States of America | Applicant |
| US9807244B2 | Cited by | United States of America | Applicant |
| US9959151B2 | Cited by | United States of America | Applicant |
| US10063713B2 | Cited by | United States of America | Applicant |
| US10291782B2 | Cited by | United States of America | Applicant |
| US11165853B2 | Cited by | United States of America | Applicant |
| US10708437B2 | Cited by | United States of America | Applicant |
| US10200458B2 | Cited by | United States of America | Applicant |
| US10440192B2 | Cited by | United States of America | Applicant |
| US10560495B2 | Cited by | United States of America | Applicant |
| US10893079B2 | Cited by | United States of America | Applicant |
| US11265367B2 | Cited by | United States of America | Applicant |
| US11544752B2 | Cited by | United States of America | Applicant |
| US11005998B2 | Cited by | United States of America | Applicant |
| US11283843B2 | Cited by | United States of America | Applicant |
| US11341092B2 | Cited by | United States of America | Applicant |
| US10694042B2 | Cited by | United States of America | Applicant |
| US10904389B2 | Cited by | United States of America | Applicant |
| US10560516B2 | Cited by | United States of America | Applicant |
| US11019159B2 | Cited by | United States of America | Applicant |
| US9628624B2 | Cited by | United States of America | Applicant |
| US9948788B2 | Cited by | United States of America | Applicant |
| US10686694B2 | Cited by | United States of America | Applicant |
| US11706349B2 | Cited by | United States of America | Applicant |
| US10455094B2 | Cited by | United States of America | Applicant |
| US11637933B2 | Cited by | United States of America | Applicant |
| US11831810B2 | Cited by | United States of America | Applicant |
| US11032325B2 | Cited by | United States of America | Applicant |
| US10469670B2 | Cited by | United States of America | Applicant |
| JP2011199412A | Cited by | Japan | Examiner |
| US11093305B2 | Cited by | United States of America | Applicant |
| US11272325B2 | Cited by | United States of America | Applicant |
| US9654647B2 | Cited by | United States of America | Applicant |
| US10659349B2 | Cited by | United States of America | Applicant |
| US9853872B2 | Cited by | United States of America | Applicant |
| US11611663B2 | Cited by | United States of America | Applicant |
| US10708317B2 | Cited by | United States of America | Applicant |
| US10063461B2 | Cited by | United States of America | Applicant |
| US10033617B2 | Cited by | United States of America | Applicant |
| US11330108B2 | Cited by | United States of America | Applicant |
| US10819757B2 | Cited by | United States of America | Applicant |
| US11882139B2 | Cited by | United States of America | Applicant |
| US10986142B2 | Cited by | United States of America | Applicant |
| US11595792B2 | Cited by | United States of America | Applicant |
| US10182147B2 | Cited by | United States of America | Applicant |
| US10439907B2 | Cited by | United States of America | Applicant |
| US11831415B2 | Cited by | United States of America | Applicant |
| US10686936B2 | Cited by | United States of America | Applicant |
| US11394673B2 | Cited by | United States of America | Applicant |
| US11755530B2 | Cited by | United States of America | Applicant |
| US11379275B2 | Cited by | United States of America | Applicant |
| US9906651B2 | Cited by | United States of America | Applicant |
| US11722602B2 | Cited by | United States of America | Applicant |
| US11246013B2 | Cited by | United States of America | Applicant |
| US10757200B2 | Cited by | United States of America | Applicant |
| US10230772B2 | Cited by | United States of America | Applicant |
| US11637876B2 | Cited by | United States of America | Applicant |
| US9774687B2 | Cited by | United States of America | Applicant |
| US9858279B2 | Cited by | United States of America | Applicant |
| US9967224B2 | Cited by | United States of America | Applicant |
| US11665285B2 | Cited by | United States of America | Applicant |
| US10057734B2 | Cited by | United States of America | Applicant |
| US11546471B2 | Cited by | United States of America | Applicant |
| US10116733B2 | Cited by | United States of America | Applicant |
| US9614972B2 | Cited by | United States of America | Applicant |
| US10187530B2 | Cited by | United States of America | Applicant |
| US9882942B2 | Cited by | United States of America | Applicant |
| US11063972B2 | Cited by | United States of America | Applicant |
| US10467064B2 | Cited by | United States of America | Applicant |
| US11444985B2 | Cited by | United States of America | Applicant |
| US11539601B2 | Cited by | United States of America | Applicant |
| US11632471B2 | Cited by | United States of America | Applicant |
| US11076054B2 | Cited by | United States of America | Applicant |
| US10873892B2 | Cited by | United States of America | Applicant |
| US10841421B2 | Cited by | United States of America | Applicant |
| US9894212B2 | Cited by | United States of America | Applicant |
| US10893078B2 | Cited by | United States of America | Applicant |
| US11622022B2 | Cited by | United States of America | Applicant |
| US11032330B2 | Cited by | United States of America | Applicant |
2 priority claims, no other members on record
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2003003662 | Japan | A | |
| JP20030003662 | – | – | – |
5 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalA02 | A02 | |
| Written amendmentA521 | A521 | |
| Notification of reasons for refusalA131 | A131 | |
| Report on retrievalA977 | A977 | |
| Written request for application examinationA621 | A621 |
Numbers
- Publication
- 2004220118
- Publication, DOCDB
- 2004220118
- Publication, EPODOC
- JP2004220118
- Application
- 3662
- Application, DOCDB
- 2003003662
- Application, EPODOC
- JP20030003662
Titles3
- English
- MULTIPROCESSOR SYSTEM, MONITORING SYSTEM, METHOD OF TAKING OUT QUEUE FROM MULTIPROCESSOR SYSTEM, AND PROCESS FOR TABLE RECOVERY AT MULTIPROCESSOR SYSTEM
- Japanese
- マルチプロセッサシステム,監視システム,マルチプロセッサシステムにおけるキュー取り出し方法およびマルチプロセッサシステムにおけるテーブルリカバリ処理方法
- English
- Queue retrieval method in multiprocessor system, monitoring system, multiprocessor system and table recovery processing method in multiprocessor system
Classification
- IPC, 7
- G06F12 02
- G06F9 48
- G06F11 00
- G06F15 167
- G06F15 177
- H04B7 26
- H04Q3 545