KR20050015308A - An apparatus and method for detecting hard-ware alarm with in case of hard-ware alarm device fault state in mobile communication system - Google Patents

Abstract

PURPOSE: A system and a method for sensing occurrence of a hardware trouble when abnormality occurs at a hardware alarm board in a mobile communication system are provided to correctly check a trouble of a current system, and to reduce trouble occurrence of an overall system by receiving response messages from each board. CONSTITUTION: The method comprises several steps. A BTS(Base Station Transceiver System) trouble process block checks a state of a BALA(BTS Alarm Assembly) which senses a hardware trouble of each function board(510). In a case that there occurs a hardware trouble at the BALA, the BTS trouble process block sends a response request message to all the processor boards in a BTS system(540). The BTS trouble process block checks whether there exists a message corresponding to the response request message from each function board(550). If there exists a response message from a function board, the BTS trouble process block releases a trouble alarm for the function board(560). The BTS trouble process block checks whether the function board has a duplex structure with an active state board and a waiting state board(570). In a case that the function board has a duplex board, the BTS trouble process block check a hardware trouble state of the waiting state board(580). The BTS trouble process block checks a hardware trouble change state of the waiting state board(590), and checks whether the waiting state board is in an installation state from a separation state(600). If so, the BTS trouble process block releases an existing alarm for the waiting state board(610), otherwise, generates a separation alarm for the waiting state board(620).

Description

Device and method for detecting hardware failure in case of hardware alarm board failure in mobile communication system {AN APPARATUS AND METHOD FOR DETECTING HARD-WARE ALARM WITH IN CASE OF HARD-WARE ALARM DEVICE FAULT STATE IN MOBILE COMMUNICATION SYSTEM}

The present invention relates to a mobile communication system, and provides an apparatus and method for detecting a failure of hardware of a plurality of functional boards in a system to be managed when a failure processing software block occurs.

1 is a diagram illustrating fault handling software blocks for processing an alarm in accordance with the prior art.

Referring to FIG. 1, a failure processing software block is generally referred to as a radio network controller (RNC) failure processing block 20 and a base station transceiver subsystem (hereinafter referred to as a BTS). A failure processing block 30 is provided to collect fault alarms occurring in a plurality of RNC systems and a plurality of BTS systems, and thus, a radio failure management block (Utran Radio Management, hereinafter referred to as 'URM'), which is a higher failure handling block. It has a high / lower structure to transmit to the processing block 10.

The URM failure processing block 10 is a block belonging to the URM system and comprehensively manages the states of the processors, links devices, call resources, and the like throughout the radio access network system and outputs the result. The RNC failure processing block 20 is a block belonging to a plurality of RNC systems and is executed in a main processor (RNC switch control processor, hereinafter referred to as 'RCP') of the RNC system. The RNC failure processing block 20 collects failure alarms generated in the RNC systems and reports the failure alarms to the URM failure processing block 10. In addition, the BTS failure processing block 30 is a block belonging to a plurality of BTS systems and is executed in a main processor (BTS Control Processor) of the BTS system. The BTS failure processing block 30 collects failure alarms generated in the BTS systems and reports the failure alarm block 10 to the URM failure processing block 10.

 In this case, the URM failure processing block 10 refers to a user interface (GUI) for managing fault alarms and status information of each system transmitted from a plurality of RNC systems and BTS systems. The fault alarms are output in the form of a message window or graphically.

In this regard, the RNC 20 includes a hardware-hardware alarm collection assembly (hereinafter referred to as HACA) 24 to detect hardware failure of each board 24 in the RNC system. . Here, the hardware failure refers to a state in which the board is detached from the system or a power supply failure occurs. Accordingly, the HACA 24 detects a failure alarm condition of the boards constituting the RNC system, for example, LRIA, and informs the RNC failure processing block 22 of this. Accordingly, the RNC failure processing block 22 periodically checks the HACA 24 to check the hardware failure state of each board 24 in the RNC system.

In addition, the BTS 30 also includes a hardware alarm board (BTS Alarm Assembly, hereinafter referred to as "BALA") to detect the hardware failure of each board in the BTS system. That is, the BALA 34 detects the presence or absence of hernias of each board constituting the BTS system, or detects whether the power supply of each board is normal. Accordingly, the BTS failure processing block 32 periodically checks the BALA 34 to identify a hardware failure state of each board in the BTS system.

The process of identifying the hardware failure through the BTS failure processing block 32 through the BALA 34 will be described in more detail with reference to FIG. 2 below.

2 is a diagram illustrating a process of transmitting an alarm state of a corresponding board to a failure processing software block through a failure alarm board according to the related art.

Referring to FIG. 2, the BCP 132 is a main processor that controls a plurality of functional boards of a BTS system, and includes a BTS failure processing block 32 for checking hardware failure states of each board included in the BTS system. . The BAP 134 is an alarm board that detects a hardware failure of a plurality of functional boards provided in the BTS system. The BAP 134 detects hardware signals (ON / OFF) transmitted from the plurality of functional boards and transmits them to the BCP 132.

For example, suppose a board that provides operation time information to a plurality of functional boards provided in the BTS system is A, and the power supply of the A board 136 is suddenly stopped or dismounted. In this case, the BAP 134 detects a hardware off signal from the A board 136. Accordingly, the BAP 132 converts the hardware off signal of the A board 136 into a software signal through a protocol and transmits it to the BCP 132.

Accordingly, the BCP 132 receives a software signal corresponding to the A board 136 transmitted from the BAP 134 and determines a hardware failure of the A board 136.

However, when the BAP 134 hernias, the BCP 132 has a problem that does not recognize the hardware failure of each functional board. That is, if the LRIA 26 is hernia after the BAP 134 is hernia, the BCP 132 has a problem that the LRIA 26 does not detect hernia.

That is, the BCP 132 checks the hardware failure in the system to be managed depending on the BAP 134, and when the BAP 134 is herniad, detects a failure newly occurring with respect to other functional boards. Unexpected problem occurs.

Accordingly, the present invention provides an apparatus and method for receiving hardware failure information from each functional board as well as hardware failure information received by the BCP 132 from the BAP 134.

SUMMARY OF THE INVENTION An object of the present invention is to provide an apparatus and method for transmitting a software signal to a plurality of functional boards in order to detect a hardware failure of a plurality of functional boards.

Another object of the present invention is to provide an apparatus and method for transmitting a software signal for detecting the presence of a hardware failure to functional boards in which an error processing software block is activated and functional boards in a standby state in a mobile communication system.

The present invention according to the first aspect for achieving the above object is a plurality of functional boards and the alarm board for detecting a hardware failure of the plurality of functional boards, and receives the failure information of any functional board from the alarm board In a mobile communication system having a fault handling software block for collecting and processing a corresponding fault alarm, the fault handling software block detects hardware fault information of the plurality of functional boards. Receiving a hardware failure information of the alarm board through a protocol from a board, and if the hardware failure occurs in the alarm board through the hardware failure information of the alarm board, a response request message to the plurality of functional boards Transmit and transmit protocols from the plurality of functional boards It is characterized by consisting of the process of receiving hardware failure information of the board.

The present invention according to the second aspect for achieving the above object is a plurality of functional boards and the alarm board for detecting hardware failure of the plurality of functional boards, and receives the failure information of any functional board from the alarm board In a mobile communication system having a fault handling software block for collecting and processing the fault alarm, the fault handling software block receives hardware fault information of the plurality of functional boards, the hardware from the plurality of functional boards. Receives a failure signal and checks whether there is a hardware failure of the notification board which transmits to the failure processing software block through a protocol, and sends a response request message to the plurality of functional boards when a hardware failure occurs in the alarm board. Through a protocol from the plurality of functional boards It characterized by comprising a failure handling software block that receives a hardware failure information of the board.

Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.

DETAILED DESCRIPTION In the following detailed description, one representative embodiment of the present invention is set forth in order to achieve the above technical problem. And other embodiments that can be presented with the present invention are replaced by the description in the configuration of the present invention.

The mobile communication system to be described in the present invention includes a plurality of functional boards to perform a specific function, and the plurality of functional boards are provided with a plurality of application blocks to implement a specific function to operate a corresponding function. At this time, each functional board receives a control signal applied from the central processing unit of the upper system and controls the operation of the plurality of application blocks through the central control unit provided therein. In this case, the upper system may control a plurality of functional boards and status information, or each of the functional boards may be referred to as inter-processor communication data (“IPC data”) for controlling the application blocks and status information. Send / receive).

Here, the IPC data is a kind of control signal, which is information for satisfying various characteristics and requirements of each application block and for stabilizing the system.

In this regard, the present invention provides an IPC data including hardware failure information from each function board other than the alarm board when a failure occurs in an alarm board that detects a hardware failure for disengagement and power supply of respective function boards in a system to be managed. An apparatus and method for transmitting / receiving a message are provided.

In addition, the present invention collects the hardware failure information of each functional board by collecting the failure information transmitted from the activation board and the standby board of each functional board as well as IPC data transmitted from the alarm board for detecting the failure alarm of each functional board. It is to provide a method and apparatus for collecting more efficiently.

In this regard, the fault processing software block proposed by the present invention will be described.

3 is a diagram of fault handling software blocks for processing an alarm in accordance with the present invention.

Referring to FIG. 3, the higher error handling software block (Utran Radio Management, hereinafter referred to as 'URM error processing block'), 212 is a radio network controller (hereinafter referred to as 'RNC') error processing block. And a base station transceiver subsystem (hereinafter, referred to as a BTS) fault handling block 230 to collect fault alarms occurring in a plurality of RNC systems and a plurality of BTS systems.

The URM failure processing block 212 is a block belonging to the URM system and comprehensively manages the states of the processors, links devices, call resources, and the like throughout the radio access network system and outputs the result. That is, the URM failure processing block 110 refers to a user interface (GUI) for managing failure alarms and status information of each system transmitted from a plurality of RNC systems and BTS systems. The fault alarms are output in the form of a message window or graphically.

The RNC failure processing block 222 is a block for managing failure alarms of a plurality of RNC systems and is provided in the RCP of the RNC system. The HACA 224 detects a hardware failure such as an unmounted / mounted state of each functional board in the RNC system and a power supply failure state and transmits the hardware failure to the RNC failure processing block 222. That is, the RNC failure processing block 222 periodically checks IPC data transmitted from the HACA 224 to identify hardware failures of respective functional boards existing in the RNC system. In addition, the RNC failure processing block 222 detects hardware failure of each board by directly receiving IPC data transmitted from the activated LRIA 226 and the standby LRIA 237. Accordingly, the RNC failure processing block 222 checks the IPC data transmitted from the activated LRIA 226 and the standby LARI when the HACA 224 is dismounted, so that the RNC failure processing block 222 has reliability for hardware failures. do.

 The BTS failure processing block 232 is a block for managing failure alarms of a plurality of BTS systems and is provided in the BCP of the BTS system. The BALA 234 detects a hardware failure such as an unloading / mounting state of each functional board in the BTS system and a power supply failure state and transmits it to the BTS failure processing block 232. The BTS failure processing block 232 periodically checks IPC data transmitted from the BALA 226 to identify hardware failures of respective functional boards in the BTS system. In addition, by directly receiving IPC data from the active LRIA 236 and the standby LRIA 237 to detect the hardware failure of the respective boards. Therefore, the BTS failure processing block 232 checks the IPC data transmitted from the activated LRIA 236 and the standby LRIA 237 when the BALA 234 is dismounted, and the hardware failure caused by the BTS failure processing block 232. It has reliability. This will be described in more detail in Beam 4 below. In the following, the BTS system will be described by way of example for ease of explanation. However, it is obvious that this also applies to the RNC system.

4 is a state diagram illustrating a process of transmitting an alarm state of a corresponding board to a failure processing software block according to the present invention.

Referring to FIG. 4, the BCP 332 is a main processor that controls each board included in the BTS system. The BCP 332 includes a failure processing software block to collect failure states of respective functional boards in the BTS system and transmit them to the failure processing block 212 of the upper network. The BAP 334 is an alarm board that detects a hardware failure of a plurality of functional boards provided in the BTS system. The BAP 334 transfers IPC data related to the functional board to the BCP 332 through a protocol when a hardware failure occurs on the functional board. For example, suppose that the power supply to the A board 336 that provides operation time information to the plurality of functional boards provided in the BTS system is suddenly interrupted or dismounted. At this time, the BAP 134 detects a hardware OFF signal from the A board 336 and transmits the hardware OFF signal to the BCP 332 through a protocol, which is a software signal X ( 338). That is, the BCP 332 checks the first IPC data transmitted from the BAP 334 to grasp the hardware failure alarm of the function board.

At this time, when a hardware failure occurs in the BAP 334, the BCP 332 transmits a response request message for determining whether to remove or mount the corresponding activation board 336. At this time, when the second IPC data 340 corresponding to the response request message is received from the plurality of activation boards 336 through a protocol, the BCP 332 checks the second IPC data 340 to check the corresponding function. The hardware failure alarm of the board is identified.

In addition, when there is no second IPC data 340 corresponding to the response message from the activation board 336, the BCP 332 checks the state 337 of the standby board of each corresponding function board. The third IPC data 342 transmitted from the standby state board 337 through the protocol is checked to identify a hardware failure alarm of the corresponding function board 337.

In other words, the BCP 332 periodically checks the BAP 334 to receive a hardware failure state of each functional board in the BTS system through the protocol X 338. In this case, when the BAP 334 is hernia detached and it is no longer possible to check the failure states of the respective function boards, the IPC data 340 is received from the corresponding function board (A board 336) to check the failure state. At this time, the IPC data 342 is received from the B board 337 in the standby state of the A board 336 in the activated state in order to ensure the reliability of the IPC data. In this case, the standby B board 337 is a board that performs the same operation as the activation state A board 336 and is replaced when a failure of the activation state A board 336 occurs and performs the corresponding operation.

Accordingly, the BCP 332 that receives IPC data from each of the activated A board 336 and the B board 337 in the standby state collects hardware failure alarms of the BTS system so as to collect higher failure processing blocks 212. The alarm will be handled by passing it on.

That is, when a hardware failure of the BAP 334 for detecting a hardware failure occurs, the BCP 332 checks the IPC data transmitted from the respective function boards and delivers the failure alarm of the corresponding system to the upper failure processing block. It has the effect of processing more efficiently.

The operation of the BCP 332 will be described in more detail with reference to FIG. 5 below.

5 is a flowchart illustrating a process of processing an alarm of a board in a fault handling soft air block according to the present invention.

Referring to FIG. 5, in step 510, the BTS failure processing block 232 checks the state of the BALA 234 that detects hardware failure of each functional board of the system 230 to be managed. In this case, the failure processing software block 232 confirms whether a hardware failure occurs in the BALA 234 through a protocol. In this case, if a hardware failure occurs in the BALA 234 in step 520, for example, in a hernia state, the process proceeds to step 540 and transmits a response request message to all the processor boards in the BTS system 230. This is to check the presence of hardware failure states of the functional boards in the BTS system 230. On the other hand, if the BALA 234 is mounted in step 520, the process proceeds to step 530. In step 530, the BTS failure processing block 232 confirms hardware failure information of each function board transmitted through the protocol from the BALA 234, and processes the failure alarm of the function board according to each failure information. do.

In step 550, the BTS failure processing block 232 confirms whether a message corresponding to the response request message exists from the function board in the BTS system 230. If there is a response message from the function board 236 that was previously recognized as a hernia state in step 550, the BTS failure processing block 232 may indicate a failure alarm of the function board 236 that was recognized as the hernia state in step 560. Release it. This is a new alarm that occurs after the hardware failure of the BALA 234 is not recognized as a hardware failure. This is because the mounting state of the functioning board 236 normally operated is recognized as a hernia state. On the other hand, if the response message is not received from the activation board in the hermetic state in step 550, the process proceeds to step 570 to perform a corresponding function.

In step 570, the BTS failure processing block 232 checks whether the functional board 232 recognized as the hernia state is a board having a redundant structure. In step 580, if the board is a redundant board including an active board 236 and a standby board 237, in step 580, the hardware failure state of the standby board 237 is checked to determine the functional board 236. Ensure the reliability of hardware failure information).

That is, in step 590, the BTS failure processing block 232 checks the hardware failure change state of the standby status board 237. In step 600, it is checked whether the standby state board 237 is changed from the hernia state to the mounted state. In this case, if the board 237 in the standby state is changed from the hernia state to the mounted state, the process proceeds to step 600.

In step 600, the BTS failure processing block 232 detects a hardware failure alarm of the standby state board 237, and the state of the standby state board 237 is mounted due to a hardware failure of the BALA 234. Confirm that the condition is recognized as a hernia condition. Therefore, the standby state board 237 releases the failure alarm of the standby state board 237 in a mounted state.

On the other hand, if the state of the standby board 237 is changed from mounting to hernia in step 600, the standby board 237 is recognized as a mounting state due to a hardware failure of the BALA 234 in the original hernia state. Check and generate a failure alarm of the standby state board 237.

That is, the BTS failure processing block 232 checks the failures of the plurality of functional boards provided in the BTS system 230, and prioritizes the information of the alarm board that detects the hardware failure as the priority. To identify their disabilities. In this case, when the alarm board is detached or a power failure occurs due to an abnormality in power supply, the BTS failure processing block 232 transmits a response message to the respective functional boards. At this time, upon receiving the response message from each board, it checks the failure information transmitted from the boards to process failure alarms of the corresponding function boards. Therefore, when a failure occurs in the hardware alarm board that detects a failure alarm of each functional board in the system, the BTS failure processing block receives failure information of each functional board and failure information from standby boards of the respective functional boards. The board failure will be handled reliably.

As described above, in the present invention, when each lower fault processing block collects fault alarms of a corresponding system, fault alarm information received from each board as well as fault alarm information received from a hardware alarm board of the corresponding system. This function has the effect of grasping the fault alarm of the current system more accurately. In addition, when a failure occurs in the hardware alarm board to detect the failure of the system, by receiving a response message received from each board has the effect of reducing the failure occurring in the entire system.

1 illustrates failure handling software blocks for processing an alarm in accordance with the prior art;

2 is a diagram illustrating a process of transmitting a hardware failure state of each functional board to a failure processing software block through a hardware alarm board according to the related art.

3 illustrates failure handling software blocks for processing an alarm in accordance with the present invention.

4 is a diagram illustrating a process of transmitting a hardware failure state of each functional board to a failure processing software block according to the present invention.

FIG. 5 is a flowchart illustrating a process of processing a hardware failure of each functional board by a failure handling soft air block according to the present invention; FIG.

Claims (12)

Alarm board for detecting a hardware failure of the plurality of functional boards and the plurality of functional boards, and a failure processing software block for receiving the failure information of any functional board from the alarm board to collect and process the corresponding failure alarm In the mobile communication system, the failure processing software block for detecting hardware failure information of the plurality of functional boards, Receiving, by the failure processing software block, hardware failure information of the alarm board from the alarm board through a protocol; If it is confirmed that hardware failure occurs in the alarm board through the hardware failure information of the alarm board, a response request message is transmitted to the plurality of function boards and hardware failure of each function board through a protocol from the plurality of function boards. The method comprising the step of receiving information. The method of claim 1, When the failure processing software block receives hardware failure information of the alarm board from the alarm board through the protocol and confirms that hardware failure of the alarm board does not occur, failure information of the plurality of functional boards detected by the alarm board. Checking them and handling the failure of the functional board according to the failure information of the alarm board. The method of claim 1, When the failure processing software block receives the hardware failure information of the alarm board from the alarm board through the protocol and confirms that the hardware failure of the alarm board occurs, the response request message is transmitted to the plurality of function boards in the active state. And receiving a message corresponding to the response request message through a protocol from the plurality of function boards in the activated state and releasing a hardware failure alarm of the plurality of function boards in the activated state. Way. The method of claim 3, wherein If a message corresponding to the response request message is not received through the protocol from the plurality of functional boards in the activated state, the alarm status of the plurality of functional boards in the standby state is checked to determine a hardware failure alarm of the plurality of functional boards. The method comprising generating or releasing. The method of claim 4, wherein When the alarm state of the plurality of functional boards in the standby state is changed from the hermetic state to the mounted state, releasing a fault alarm of the functional board in the standby state. The method of claim 4, wherein And a failure alarm of the functional board in the standby state when an alarm state of the plurality of functional boards in the standby state is changed from the mounted state to the hernia state. Alarm board for detecting a hardware failure of the plurality of functional boards and the plurality of functional boards, and a failure processing software block for receiving the failure information of any functional board from the alarm board to collect and process the corresponding error alarm In the mobile communication system, the error processing software block for receiving the failure information of the functional board, Receiving hardware failure information from the plurality of functional boards and confirming the presence or absence of hardware failure of the notification board for transmitting to the failure processing software block through a protocol, and if the hardware failure occurs in the alarm board, the plurality of functions And a failure handling software block for sending hardware request information of each function board through a protocol from the plurality of function boards by sending a response request message to the boards. The method of claim 7, wherein The failure processing software block receives hardware failure information of the alarm board through a protocol from the alarm board, and if it is confirmed that a hardware failure of the alarm board does not occur, the failure of the plurality of functional boards detected by the alarm board. Device for checking the information and to handle the failure of the functional board according to the failure information of the alarm board. The method of claim 8, The failure processing software block receives the hardware failure information of the alarm board through the protocol from the alarm board and sends a response request message to the plurality of function boards in the activated state when the hardware failure of the alarm board is generated. And receiving a message corresponding to the response request message through a protocol from the plurality of function boards in the activated state and releasing a hardware failure alarm of the plurality of function boards in the activated state. . The method of claim 9, If the failure processing software block does not receive a message corresponding to the response request message through a protocol from the plurality of functional boards in the activated state, the alarm state of the plurality of functional boards in the standby state is checked to determine the plurality of functional boards. And generating or releasing a hardware failure alarm for each of the devices. The method of claim 10, The failure processing software block releases the failure alarm of the function board in the waiting state when it is confirmed that the alarm state of the plurality of function boards in the waiting state is changed from the hermetic state to the mounting state. The failure processing software block is configured to generate a failure alarm of the functional board in the standby state when it is confirmed that the alarm state of the plurality of functional boards in the standby state is changed from the mounted state to the hernia state.