KR20010054504A - Apparatus for managing fault in mobile communication system - Google Patents

Abstract

A failure processing apparatus of a mobile communication system according to the present invention includes a first failure processing block for collecting a failure of a base station system, a second failure processing block for collecting a failure of a control station system, and a failure from the base station and a control station. And a third failure processing block for receiving and processing the first failure processing block and the second failure processing block, characterized in that the third failure processing block and independently communicate with each other.

Description

Failure handling device of mobile communication system {APPARATUS FOR MANAGING FAULT IN MOBILE COMMUNICATION SYSTEM}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a fault handling apparatus of a mobile communication system. In particular, in a mobile communication system, a main processor of a base station transceiver (BTS) and a control station (BSC) is a BSS (BTS / BSC) system. It is a device that can inform the operator of the failure status of the system through the BSM (Graphic User Interface) by collecting the alarm of the BSM (BSS System Manager).

In the conventional mobile communication system, when the failure block of the BSM collects failure information of BSC and BTS, which are subordinate devices, the BSM has a hierarchical structure as follows: BTS-> BSC-> BSM. That is, the failure block of the BTS transmits the failure information to the failure block of the BSC, and the failure block of the BSC transfers the failure information to the failure block of the BSM.

As described above, the fault block of the BSC directly manages the information of the fault block of the BTS and transmits an alarm message of the BTS to the BSM. The method of collecting and processing an alarm is separated, and the message is processed in two steps. Since it is delivered to the BSM, there is a high probability that the message is lost in the middle due to instability of the IPC, thereby delaying the processing speed of the message.

In addition, configuration settings such as the shape of BTS and BSC are determined by PLD (Program Load Data) received when the board is mounted to express the fault UIM.In the existing system, the contents of PLD cannot be changed during system operation. To change the contents, after modifying the contents of the PLD, there was a problem in that the initialization was performed again by downloading the modified PLD.

Accordingly, an object of the present invention is to provide an apparatus in which a failure processing block of a control station and a base station can independently communicate with a BSM failure processing block in a mobile communication system.

Another object of the present invention is to provide an alarm information processing apparatus that checks PLD information by calling a PLD library whenever an alarm occurs in a mobile communication system.

A failure processing apparatus of a mobile communication system for achieving the above objects includes a first failure processing block for collecting a failure of a base station system, a second failure processing block for collecting a failure of a control station system, and the base station and the control station. And a third failure processing block configured to receive and process a failure, wherein the first failure processing block and the second failure processing block communicate with each other independently of the third failure processing block.

1 is an illustration of a disabled software block in accordance with the present invention.

FIG. 2 is a diagram illustrating a message transmission / reception structure between the MFH and the FLM in FIG. 1.

FIG. 3 is a diagram illustrating a message transmission and reception structure between a BFH and an FLM in FIG. 1.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

The IMT2000 system, the next-generation mobile communication system, is a system in which each system is connected to an ATM network and the capacity is significantly improved over the PCS system. Therefore, we can consider the way BFH (BTS block) directly sends a failure message to BSM through ATM switch of BSC without going through MFH block (BSC block).

Accordingly, the present invention implements a message delivery system in which the BFH block directly transmits an IPC message to a BSM Fault Block (FLM) without passing through the MFH block. The BFH block manages an alarm of a BTS system by itself, and if an alarm is detected, directly transmits an IPC message to the FLM, and the MFH block manages and detects only an alarm of a BSC system and reports it to the FLM. In this way, the software architecture of the system can be more straightforward and the number of message delivery steps can be reduced, reducing the probability of missing or delayed messages.

In addition, when the PLD is initialized, the MFH and the BFH directly check the PLD and determine whether to generate an alarm message each time an alarm occurs, instead of following the method received from the configuration block. To be sensitive to changes in BSC / BTS system configuration such as

The present invention relates to a software block structure in which the BFH (BTS Fault Block) and the MFH (BSC Fault Block) independently communicate with the BSM Fault Block (FLM). A message transmission and reception structure between the MFH211 and the FLM and a detailed message transmission and reception structure between the BFH and the FLM are shown in FIGS. 2 and 3.

Hereinafter, various failure processing blocks in the MFH211 will be described with reference to FIG. 2.

① Hardware failure: Hardware failure detected on HACA board is collected directly from MFH211 of BMP and informed to status block MSH213, and MFH211 sends to BSM. If the ATM link is disabled, pass it to MSNH214. Hardware failures detected by the ACMA board are detected by the AMPMP221 block in the ACMA and communicated to the MFH211. The MFH211 passes back the hardware failure received from the AMPMP221 to the MSH213.

② Software failure: Detected by MSH213 of BMP and delivered to MFH211.

③ Link failure: If the AEPMP subblock detects a failure condition related to the BSC-BTS link and informs MSH213, MSH213 forwards it to MFH211. The fault condition associated with the link between MSCs is transmitted from TMH215 to the MFH211 block.

④ Other Disorders: The MSH213 receives the disturbances detected in other redundancy 216, the TMH215, and the MTH217217.

⑤ sanity: When the item to notify MSAH212 occurs during the operation of MFH211, it delivers a message.

⑥ MFH: Delivers the alarm result collected by MFH211 to FLM12.

Hereinafter, various failure processing blocks in the BFH311 will be described with reference to FIG. 3.

1) Hardware failure: Hardware failure detected in BCAA board and BRAA board is collected in BAGH32 of BAP, BCAA board's processor, and informs BFH311. The BFH311 forwards the received hardware alarm back to the FLM12 and BSH314.

② Software failure: detected by the BSH314 and informs BFH311 and the BFH311 forwards to the FLM12.

③ Other Disturbance: The failure detected by Redundancy 312, BTH Block 313 is transmitted to the BFH311.

④ Delivers the alarm result collected by the BFH311 to the FLM12.

As shown in FIG. 2 and FIG. 3, the fault block includes a Fault Manager (FLM) 12 in the BSM (Base Station Management), a Fault Management (MFH211) and a Base Station Transceiver (BTS) in the UIM11 and the BSC (Base Station Controller). It consists of BTS (BTS Fault Handling) 311 and BGH (BTS Alarm Gather Handling) 32 in the Subsystem. Both hardware alarms and software alarms of the BSC system are collected by the MFH211 and delivered to the FLM12, and the BTS system collects the hardware alarms collected by the BAGH32 and the software alarms delivered by the tablet of the BCP processor to the FLM12. To pass. The FLM12 processes the alarm of each received BSC and BTS system and expresses the UIM. The present invention describes the operation of the failure block operation of the BSC / BTS system excluding the BLM block FLM and the failure UIM.

First, referring to BSC failure handling with reference to FIG. 2, the overall message flow can be largely divided into two cases, a hardware alarm and a software alarm. The hardware alarm refers to an alarm detected on a board having an alarm detection function such as HACA or ACMA (alarm aggregation is performed by the MFH211), and the software alarm refers to an alarm received by the MFH211 from another block such as MSH213.

Since the hardware alarm manages the alarm information directly, the message flow of MFH211-> FLM12 is the main flow, and the message is also sent to other blocks such as MSH213 (state) and MSNH214 (samp). ACMA board alarm is actually detected by ACMA maintenance block AMPMP221 and sent to MFH211, but because MFH211 manages information, it is basically MFH211-> FLM12 structure. And the alarm of the HACA board is polled by MFH211 periodically to check whether the alarm occurred. If it is determined that a hardware alarm occurs, call the PLD library function first before generating the alarm message and call the PLD shape and physical (physical). It is sensitive to the change of configuration setting such as the increase / decrease of the board by judging whether the shape is identical. In the case of the software alarm, the message structure is Tab-> MFH211-> FLM. The MFH211 performs only a function of bypassing the FLM as information sent by the other block.

In addition, there is a fault among other faults. The fault that can be distinguished by ON / OFF is an alarm, and the fault is a fault that cannot be expressed by On / Off. In case of imt2000 BSC system, it can be said that fault information that MTH217 (diagnosis) block sends to MFH211 corresponds to Fault. Fault faults and other faults, like software alarms, are routed to the fault UIM following the message flow of Tabblock-> MFH211-> FLM.

The fault handling of the IMT-2000 BSC system is based on the method of collecting all fault events from the block and alarm board through the MFH211 and transmitting them to the FLM. It also redistributes fault information into blocks. In addition to this real-time on-line alarm handling function, the MFH211 also performs periodic audits to resolve inconsistencies in alarm information collected and redistributed between each software block.

Next, referring to the BTS failure processing with reference to FIG. 3, the overall message flow is divided into ① hardware alarm and ② software alarm. The software alarm detected by the BSH314 is received by the BFH311 and bypassed by the FLM12, and other faults transmitted by the redundant 312 and the BTH313 (providing a fault fault BFHDP) are also relayed from the BFH311 to the FLM12. There are two alarm boards for detecting the hardware alarm of the BTS, BCAA and BRAA. The BCAA board has a processor, so if the fault block called BAGH32 collects the alarm and forwards it to the BFH311, the BFH311 performs detailed processing and sends it to the FLM12. Done. That is, hardware alarm processing is performed in the order of BAGH32-> BFH311-> FLM12. The alarm of the BRAA33 board is configured to detect the alarm by polling the BAHG32 block and transmit the alarm to the BFH311. The BFH311 processes the fault information collected from the alarm board and the other block by itself, generates a fault message, and transmits the fault message directly to the FLM12. The BFH311 also performs periodic audits to resolve inconsistencies in alarm information between each software block.

As described above, the present invention improves the system software structure simply and clearly by directly communicating with the BSM fault blocks independently of each other, and reduces the number of message delivery steps, thereby reducing the probability of message loss or delay in processing. Can be lowered. In addition, the library can be checked by calling the PLD whenever an alarm occurs to reduce the number of messages generated and to be sensitive to configuration settings.

Claims (5)

In the fault handling apparatus of the mobile communication system, A first failure processing block for collecting failure of the base station system; A second failure processing block for collecting a failure of the control station system; And a third failure processing block for receiving and processing a failure from the base station and the control station, And wherein the first failure processing block and the second failure processing block communicate with the third failure processing block independently of each other. The method of claim 1, The failure processing block of each system collects and processes hardware failures directly and transfers them to the third failure processing block. The method of claim 1, The failure processing block of each system is characterized in that for relaying the software failure received from other software blocks in the system relayed to the third failure processing block. The method of claim 1, And the first failure processing block determines whether the physical shape matches the PLD shape by calling a PLD library function before a failure message is generated when a hardware failure is detected. The method of claim 1, The failure processing block of each system is redistributed to other blocks that require failure information, and characterized in that the periodic monitoring (audit) is performed to detect the inconsistency of the failure information.