KR100547872B1

KR100547872B1 - 이동통신시스템에서 하드웨어알람보드의 이상 발생시하드웨어 장애 발생 유무를 감지하는 장치 및 방법

Info

Publication number: KR100547872B1
Application number: KR1020030054076A
Authority: KR
Inventors: 손지원; 전진숙
Original assignee: 삼성전자주식회사
Priority date: 2003-08-05
Filing date: 2003-08-05
Publication date: 2006-01-31
Also published as: KR20050015308A

Abstract

본 발명은 이동통신시스템에 관한 것으로, 장애처리소프트웨어블록이 관리 대상인 시스템내의 다수의 기능보드들의 하드웨어 장애 발생 유무를 감지하기 위하여 상기 다수의 기능보드들에게 소프트웨어 신호를 전송하는 장치 및 방법을 제공함에 있다.

이러한 본 발명은 다수의 기능보드들과 상기 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드와, 상기 알람보드로부터 임의의 기능보드의 장애 정보를 수신하여 해당 장애 알람을 수집하여 처리하는 장애처리소프트웨어블록을 구비한 이동통신시스템에서, 상기 장애처리소프트웨어블록이 상기 다수의 기능보드의 하드웨어 장애 정보를 감지하는 방법에 있어서, 상기 장애처리소프트웨어블록이 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하는 과정과, 상기 알람보드의 하드웨어 장애 정보를 통해 상기 알람보드에 하드웨어 장애가 발생함을 확인하면, 상기 다수의 기능보드들에 응답 요구 메시지를 전송하고 상기 다수의 기능보드들로부터 프로토콜을 통해 각 기능보드들의 하드웨어 장애 정보를 수신하는 과정으로 구성됨을 특징으로 한다.

HACA(Hard-Ware Alarm Collection Assembly), BALA(BTS Alarm Assembly)

Description

이동통신시스템에서 하드웨어알람보드의 이상 발생시 하드웨어 장애 발생 유무를 감지하는 장치 및 방법{AN APPARATUS AND METHOD FOR DETECTING HARD-WARE ALARM WITH IN CASE OF HARD-WARE ALARM DEVICE FAULT STATE IN MOBILE COMMUNICATION SYSTEM}

도 1은 종래 기술에 따라 알람을 처리하는 장애처리소프트웨어블록들을 도시한 도면.

도 2는 종래 기술에 따라 하드웨어알람보드를 통해 각 기능보드들의 하드웨어 장애 상태를 장애처리소프트웨어블록에 전송하는 과정을 도시한 도면.

도 3은 본 발명에 따라 알람을 처리하는 장애처리소프트웨어블록들을 도시한 도면.

도 4는 본 발명에 따라 각 기능보드들의 하드웨어 장애 상태를 장애처리소프트웨어블록에 전송하는 과정을 도시한 도면.

도 5는 본 발명에 따라 장애처리소프트에어블록이 각 기능보드들의 하드웨어 장애를 처리하는 과정을 도시한 흐름도.

본 발명은 이동통신시스템에 관한 것으로, 장애처리소프트웨어블록이 하드웨어 알람보드의 장애 발생시 관리 대상인 시스템내의 다수의 기능보드들의 하드웨어 장애 발생 유무를 감지하는 장치 및 방법을 제공함에 있다.

도 1은 종래 기술에 따라 알람을 처리하는 장애처리소프트웨어블록들을 도시한 도면이다.

상기 도 1을 참조하면, 일반적으로 장애처리소프트웨어블록은 무선네트워크제어기(Radio Network Controller, 이하 'RNC'라 칭함)장애처리블록(20)과 기지국(Base Station Transceiver Subsystem, 이하 'BTS'라 칭함)장애처리블록(30)을 구비하여 복수개의 RNC시스템들과 복수개의 BTS시스템들에서 발생하는 장애 알람들을 수집하여 상위 장애처리블록인 무선네트워크관리시스템(Utran Radio Management, 이하 'URM'이라 칭함)장애처리블록(10)에 전송하는 상/하위 구조를 가진다.

상기 URM장애처리블록(10)은 URM시스템에 속하는 블록으로 무선 접근 네트워크시스템 전반에 걸쳐 각 프로세서들과 링크들 디바이스들, 호자원 등의 상태를 종합적으로 관리하고 결과를 출력한다. 상기 RNC장애처리블록(20)은 복수개의 RNC시스템들에 속하는 블록으로서 상기 RNC시스템의 메인 프로세서(RNC Switch control Processor, 이하 'RCP'라 칭함)에서 실행된다. 상기 RNC장애처리블록(20)은 상기 RNC시스템들 내부에서 발생한 장애 알람들을 수집하여 상기 URM장애처리블록(10)에 보고하는 역할을 수행한다. 또한 BTS장애처리블록(30)은 복수개의 BTS시스템들에 속하는 블록으로서 BTS시스템의 메인 프로세서(BTS Control Processor, 이하 'BCP'라 칭함)에서 실행된다. 상기 BTS장애처리블록(30)은 상기 BTS시스템들 내부에서 발생한 장애 알람들을 수집하여 상기 URM장애처리블록(10)에게 보고하는 역할을 수행한다.

이때, 상기 URM장애처리블록(10)은 복수개의 RNC시스템들과 BTS시스템들로부터 전송된 장애알람 및 각 시스템들의 상태정보들을 관리하기 위해 사용자 인터페이스(Graph User Interface. 이하'GUI'라 칭함)를 이용하여 상기 장애알람들을 메시지 창 형태로 출력하거나 그래픽 형태로 출력한다.

상기와 관련하여 상기 RNC(20)는 하드웨어 알람 보드(Hard-Ware Alarm Collection Assembly, 이하 'HACA'라 칭함, 24)를 구비하여 상기 RNC 시스템내의 각 보드들의 하드웨어 장애를 감지하도록 한다. 여기서 하드웨어 장애란 해당 보드가 상기 시스템에서 탈장되었거나, 전원 공급에 이상이 생긴 상태들을 말한다. 따라서, 상기 HACA(24)는 상기 RNC 시스템을 구성하는 보드들, 예를 들어 LRIA의 장애 알람 상태를 감지하고 이를 상기 RNC장애처리블록(22)에 알린다. 따라서, 상기 RNC장애처리블록(22)는 상기 HACA(24)를 주기적으로 확인하여 상기 RNC 시스템내의 각 보드들의 하드웨어 장애상태를 확인하게 되는 것이다.

또한, BTS(30)도 하드웨어 알람보드(BTS Alarm Assembly, 이하 'BALA'라 칭함, 34)를 구비하여 상기 BTS시스템내의 각 보드들의 하드웨어 장애를 감지하도록 한다. 즉, 상기 BALA(34)는 상기 BTS시스템을 구성하는 각 보드들의 탈장 유무를 감지하거나, 각 보드의 전원 공급이 정상적인지를 감지한다. 따라서, 상기 BTS장애처리블록(32)는 상기 BALA(34)를 주기적으로 확인하여 상기 BTS 시스템내의 각 보드듣의 하드웨어 장애상태를 확인하게 된다.

상기 BTS 장애처리블록(32)가 BALA(34)를 통해 하드웨어 장애를 확인하는 과정은 하기의 도 2에서 보다 구체적으로 설명하고자 한다.

도 2는 종래 기술에 따라 장애알람보드를 통해 해당 보드의 알람상태를 장애처리소프트웨어블록에 전송하는 과정을 도시한 도면이다.

상기 도 2를 참조하면, BCP(132)는 BTS시스템의 다수의 기능보드들을 제어하는 메인 프로세서로, BTS시스템에 구비된 각 보드들의 하드웨어 장애상태를 확인하는 BTS장애처리블록(32)를 구비한다. BAP(134)는 상기 BTS시스템에 구비된 다수의 기능보드들의 하드웨어적인 장애를 감지하는 알람보드이다. 이러한 상기 BAP(134)는 상기 다수의 기능보드들로부터 전송되는 하드웨어 신호(ON/OFF)를 감지하여 이를 상기 BCP(132)로 전송한다.

예를 들면, 상기 BTS시스템에 구비된 다수의 기능보드들에게 동작 시간 정보를 제공하는 보드를 A라고 정의하고, 상기 A보드(136)의 전원 공급이 갑자기 중단되었거나, 탈장되었다고 가정하자. 이때, 상기 BAP(134)는 상기 A보드(136)로부터 하드웨어 오프(OFF)신호를 감지하게 된다. 이에 따라 상기 BAP(134)는 상기 A보드(136)의 하드웨어 오프(OFF)신호를 프로토콜을 통해 소프트웨어 신호로 변환하여 이를 BCP(132)에 전송한다,

따라서, 상기 BCP(132)는 상기 BAP(134)로부터 전송된 상기 A보드(136)에 해 당하는 소프트웨어 신호를 수신하고, 상기 A보드(136)의 하드웨어 장애를 파악하게 된다.

그러나, 상기 BAP(134)가 탈장하는 경우, 상기 BCP(132)는 각 기능보드들의 하드웨어 장애를 인식하지 못하는 문제점이 있었다. 즉, 상기 BAP(134)가 탈장된 후, LRIA(26)이 탈장되면, 상기 BCP(132)은 상기 LRIA(26)이 탈장됨을 감지하지 못하게 되는 문제점이 있었다.

즉, 상기 BCP(132)는 관리 대상인 시스템 내의 하드웨어 장애를 상기 BAP(134)에 의존하여 확인하고, 상기 BAP(134)가 탈장하는 경우, 타 기능보드들에 대하여 신규로 발생하는 장애를 감지할 수 없는 문제점이 발생한다.

이에 따라 본 발명에서는 상기 BCP(132)가 상기 BAP(134)로부터 수신한 하드웨어 장애 정보뿐만 아니라 각 기능보드들로부터 하드웨어 장애 정보를 수신하는 장치 및 방법을 제공하고자 한다.

본 발명의 목적은 이동통신시스템에서, 장애처리소프트웨어블록이 다수의 기능보드들의 하드웨어 장애 발생 유무를 감지하기 위하여 상기 다수의 기능보드들에 소프트웨어 신호를 전송하는 장치 및 방법을 제공함에 있다.

본 발명의 또 다른 목적은 이동통신시스템에서 장애처리소프트웨어블록이 활성화 상태인 기능보드들과 대기 상태인 기능보드들에 하드웨어 장애 발생 유무를 감지하기 위한 소프트웨어 신호를 전송하는 장치 및 방법 제공함에 있다.

상기한 목적을 달성하기 위한 제1견지에 따른 본 발명은 다수의 기능보드들과 상기 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드와, 상기 알람보드로부터 임의의 기능보드의 장애 정보를 수신하여 해당 장애 알람을 수집하여 처리하는 장애처리소프트웨어블록을 구비한 이동통신시스템에서, 상기 장애처리소프트웨어블록이 상기 다수의 기능보드의 하드웨어 장애 정보를 감지하는 방법에 있어서, 상기 장애처리소프트웨어블록이 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하는 과정과, 상기 알람보드의 하드웨어 장애 정보를 통해 상기 알람보드에 하드웨어 장애가 발생함을 확인하면, 상기 다수의 기능보드들에 응답 요구 메시지를 전송하고 상기 다수의 기능보드들로부터 프로토콜을 통해 각 기능보드들의 하드웨어 장애 정보를 수신하는 과정으로 구성됨을 특징으로 한다.

상기한 목적을 달성하기 위한 제2견지에 따른 본 발명은 다수의 기능보드들과 상기 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드와, 상기 알람보드로부터 임의의 기능보드의 장애 정보를 수신하여 해당 장애아람을 수집하여 처리하는 장애처리소프트웨어블록을 구비한 이동통신시스템에서, 상기 장애처리소프트웨어블록이 상기 다수의 기능보드의 하드웨어 장애 정보를 수신하는 장치에 있어서, 상기 다수의 기능보드들로부터 하드웨어 장애 신호를 수신하여 프로토콜을 통해 상기 장애처리소프트웨어블록에 전송하는 상기 알림 보드의 하드웨어 장애 유무를 확인하고, 상기 알람 보드에 하드웨어 장애가 발생함을 확인하면 상기 다수의 기능보드들에 응답 요구 메시지를 전송하여 상기 다수의 기능보드들로부터 프로토 콜을 통해 각 기능보드들의 하드웨어 장애 정보를 수신하는 장애처리소프트웨어블록을 구비하는 특징으로 한다.

이하 본 발명의 실시 예를 첨부된 도면을 참조하여 설명하면 다음과 같다.

후술될 상세한 설명에서는 상술한 기술적 과제를 이루기 위해 본 발명에 있어 한 개의 대표적인 실시 예를 제시할 것이다. 그리고 본 발명으로 제시될 수 있는 다른 실시 예들은 본 발명의 구성에서 설명으로 대체한다.

본 발명에서 설명하고자하는 이동통신시스템은 특정한 기능을 수행하기 위해서 다수의 기능보드들을 구비하고, 상기 다수의 기능보드들은 특정한 기능을 구현하기 위해 다수의 응용블록들을 구비하여 해당하는 기능을 동작한다. 이때, 각각의 기능보드들은 상위시스템의 중앙처리장치로부터 인가되는 제어신호를 수신하고 내부에 구비된 중앙 제어부를 통해 상기 다수의 응용블록들의 동작을 제어한다. 이때, 상기 상위시스템이 다수의 기능보드들 및 상태정보를 제어하거나, 또는 각각의 기능보드들이 상기 응용블록들 및 상태 정보를 제어하기 위하여 프로세서간의 통신 데이터(Inter Processor Communication, 이하 "IPC 데이터"라 칭함)를 송/수신한다.

여기서, IPC 데이터는 일종의 제어 신호로 각각의 응용블록들이 가지는 다양한 특성이나 요구 조건을 만족시키고, 상기 시스템의 안정화를 도모하기 위한 정보이다.

이와 관련하여 본 발명은 관리 대상인 시스템내의 각 기능보드들의 탈장 및 전원 공급에 대한 하드웨어 장애를 감지하는 알람보드에 장애가 발생한 경우, 상기 알람보드 이외의 각 기능보드들로부터 하드웨어 장애 정보를 포함하는 IPC 데이터를 송/수신하는 장치 및 방법을 제공하고자 한다.

또한, 본 발명은 각 기능보드들의 장애알람을 감지하는 알람보드로부터 전송되는 IPC 데이터 뿐만아니라 각 기능보드의 활성화상태 보드와 대기상태 보드로부터 전송되는 장애 정보를 수집하여 각 기능보드들의 하드웨어 장애 정보를 보다 효율적으로 수집하는 방법 및 장치를 제공하고자 한다.

이와 관련하여 본 발명에서 제안하는 장애처리소프트웨어블록을 살펴보기로 한다.

도 3은 본 발명에 따라 알람을 처리하는 장애처리소프트웨어블록들을 도시한 도면이다.

상기 도 3을 참조하면, 상위장애처리소프트웨어블록((Utran Radio Management, 이하 'URM 장애처리블록'이라 칭함), 212)은 무선네트워크제어기(Radio Network Controller, 이하 'RNC'라 칭함)장애처리블록(222)과 기지국(Base Station Transceiver Subsystem, 이하 'BTS'라 칭함)장애처리블록(232)을 구비하여 복수개의 RNC시스템들과 복수개의 BTS시스템들에서 발생하는 장애 알람들을 수집한다.

상기 URM장애처리블록(212)은 URM시스템에 속하는 블록으로 무선 접근 네트워크시스템 전반에 걸쳐 각 프로세서들과 링크들 디바이스들, 호자원 등의 상태를 종합적으로 관리하고 결과를 출력한다. 즉, 상기 URM장애처리블록(212)은 복수개의 RNC시스템들과 BTS시스템들로부터 전송된 장애알람 및 각 시스템들의 상태정보들을 관리하기 위해 사용자 인터페이스(Graph User Interface. 이하'GUI'라 칭함)블록(214)를 이용하여 상기 장애알람들을 메시지 창 형태로 출력하거나 그래픽 형태로 출력한다.

상기 RNC장애처리블록(222)은 복수개의 RNC시스템들의 장애알람을 관리하는 블록으로 상기 RNC시스템의 RCP에 구비된다. HACA(224)는 상기 RNC시스템내의 각 기능보드들의 탈/실장상태와, 전원 공급 장애 상태와 같은 하드웨어 장애를 감지하여 상기 RNC 장애처리블록(222)으로 전달한다. 즉, 상기 RNC 장애처리블록(222)은 상기 HACA(224)로부터 전송되는 IPC 데이터를 주기적으로 확인하여 RNC 시스템내에 존재하는 각각의 기능보드들의 하드웨어 장애를 확인한다. 또한, 상기 RNC 장애처리블록(222)은 상기 활성화 상태인 LRIA(226) 및 대기상태 LRIA(227)로부터 전송되는 IPC 데이터를 직접 수신하여 상기 각 보드들의 하드웨어 장애를 감지하게 된다. 따라서, 상기 RNC 장애처리블록(222)은 상기 HACA(224)가 탈장한 경우, 상기 활성화 상태인 LRIA(226) 및 대기상태인 LARI(227)로부터 전송되는 IPC 데이터를 확인하여 발생한 하드웨어 장애에 대하여 신뢰성을 가지게 된다.

상기 BTS장애처리블록(232)은 복수개의 BTS시스템들의 장애알람을 관리하는 블록으로 상기 BTS시스템의 BCP에 구비된다. BALA(234)는 상기 BTS시스템내의 각 기능보드들의 탈/실장상태와, 전원 공급 장애 상태와 같은 하드웨어 장애를 감지하여 상기 BTS장애처리블록(232)으로 전달한다. 상기 BTS장애처리블록(232)은 상기 BALA(234)로부터 전송되는 IPC 데이터를 주기적으로 확인하여 BTS시스템내의 각 기능보드들의 하드웨어 장애를 확인한다. 또한, 활성화 상태인 LRIA(236) 및 대기상태 LRIA(237)로부터 IPC 데이터를 직접 수신하여 상기 각 보드들의 하드웨어 장애를 감지하게 된다. 따라서, 상기 BTS 장애처리블록(232)은 상기 BALA(234)가 탈장한 경우, 상기 활성화 상태인 LRIA(236) 및 대기상태인 LRIA(237)로부터 전송되는 IPC 데이터를 확인하여 발생한 하드웨어 장애에 대하여 신뢰성을 가지게 된다. 이는 하기의 도 4에서 보다 자세히 설명하고자 한다. 하기에서는 설명의 용이를 위하여 BTS시스템을 예를 들어 설명하고자 한다. 그러나, 이는 RNC시스템에도 적용됨은 자명하다.

도 4는 본 발명에 따라 해당 보드의 알람상태를 장애처리소프트웨어블록에 전송하는 과정을 도시한 상태도이다.

상기 도 4를 참조하면, BCP(332)는 BTS시스템에 구비된 각 보드들을 제어하는 메인 프로세서이다. 상기 BCP(332)는 장애처리소프트웨어블록을 구비하여 상기 BTS 시스템내의 각 기능보드들의 장애상태를 수집하여 상위 네트워크의 장애처리 블록(212)으로 전송한다. BAP(334)는 상기 BTS시스템에 구비된 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드이다. 이러한 상기 BAP(334)는 해당 기능보드에 하드웨어적인 장애가 발행하는 경우, 상기 기능보드에 관련된 IPC데이터를 프로토콜을 통해 상기 BCP(332)로 전달한다. 예를 들면, 상기 BTS시스템에 구비된 다수의 기능보드들에게 동작 시간 정보를 제공하는 A보드(336)에 전원 공급이 갑자기 중단되었거나, 탈장되었다고 가정하자. 이때, 상기 BAP(334)는 상기 A보드(336)로부터 하드웨어 오프(OFF)신호를 감지하고, 상기 하드웨어 오프(OFF) 신호를 프로토콜을 통해 상기 BCP(332)에 전송한다, 이는 소프트웨어 신호 X(338)와 같다. 즉, 상기 BCP(332)는 상기 BAP(334)로부터 전송되는 제1 IPC데이터를 확인하여 해당 기능보드의 하드웨어 장애알람을 파악하게 된다.

이때, 상기 BAP(334)에 하드웨어적인 장애가 발생하면, 상기 BCP(332)는 각 해당 활성화 보드(336)에 탈/실장 유무를 판단하기 위한 응답 요구 메시지를 전송한다. 이때, 다수의 활성화 보드(336)로부터 상기 응답 요구 메시지에 대응하는 제2 IPC데이터(340)를 프로토콜을 통해 수신하면, 상기 BCP(332)는 상기 제2 IPC데이터(340)를 확인하여 해당 기능보드의 하드웨어 장애알람을 파악하게 된다.

또한, 이때 상기 활성화 보드(336)로부터 상기 응답 메시지에 대응하는 제 2 IPC 데이터(340)가 존재하지 않으면, 상기 BCP(332)는 각 해당 기능보드(336)의 대기 상태 보드(337)의 상태를 확인하여 상기 대기 상태 보드(337)로부터 프로토콜을 통해 전송되는 제3 IPC 데이터(342)를 확인하여 해당 기능보드(336)의 하드웨어 장애 알람을 파악하게 된다.

다시 설명하면, 상기 BCP(332)는 상기 BAP(334)를 주기적으로 확인하여 상기 BTS 시스템내의 각 기능보드들의 하드웨어 장애 상태를 프로토콜 X(338)를 통해 수신하게 된다. 이때, 상기 BAP(334)가 탈장되어 더 이상 각 기능보드들의 장애 상태를 확인할 수 없게 되면 해당 기능보드(A보드,336)로부터 IPC 데이터(340)를 수신하여 장애 상태를 확인한다. 이때, 상기 IPC 데이터를 확인한 결과에 대하여 신뢰성을 보장하기 위하여 상기 활성화 상태인 A 보드(336)의 대기상태인 B보드(337)로부터 IPC 데이터(342)를 수신한다. 이때, 상기 대기 상태인 B 보드(337)는 상기 활 성화 상태 A 보드(336)과 동일한 동작을 수행하는 보드로 상기 활성화 상태 A보드(336)의 장애 발생시 대체되어 해당 동작을 수행하는 보드이다.

따라서, 상기 활성화 상태인 A보드(336)와 대기 상태인 B보드(337) 각각으로부터 IPC 데이터를 수신한 상기 BCP(332)는 상기 BTS시스템의 하드웨어 장애 알람을 수집하여 상위 장애처리 블록(212)에 전달하여 해당 알람을 처리하게 된다.

즉, 상기 BCP(332)는 하드웨어 장애를 감지하는 BAP(334)의 하드웨어 장애가 발생되는 경우, 각각의 기능보드들로부터 전송되는 IPC데이터들을 확인하여 상위 장애처리블록에 전달함으로 해당 시스템의 장애알람을 보다 효율적으로 처리하는 효과를 가진다.

상기 BCP(332)의 동작을 하기의 도 5에서 보다 구체적으로 살펴보기로 한다.

도 5는 본 발명에 따라 장애처리소프트에어블록에서 해당 보드의 알람을 처리하는 과정을 도시한 흐름도이다.

상기 도 5를 참조하면, 510단계에서 BTS장애처리블록(232)은 관리 대상인 시스템(230)의 각 기능보드들의 하드웨어 장애를 감지하는 BALA(234)의 상태를 확인한다. 이때, 상기 장애처리소프트웨어블록(232)은 프로토콜을 통해 상기 BALA(234)의 하드웨어 장애 발생 유무를 확인한게 된다. 이때, 520단계에서 상기 BALA(234)에 하드웨어 장애가 발생하면, 예를 들어 탈장 상태이면, 540단계로 진행하여 상기 BTS시스템(230)내의 모든 프로세서 보드들에게 응답 요구 메시지를 전송한다, 즉, 상기 BTS시스템(230)내에 각 기능보드들의 하드웨어 장애 상태 존재 유무를 확인하기 위함이다. 반면에 상기 520단계에서 상기 BALA(234)가 실장상태이면, 530단계로 진행한다. 상기 530단계에서 상기 BTS 장애처리블록(232)은 상기 BALA(234)로부터 프로토콜을 통해 전송된 각 기능보드들의 하드웨어 장애 정보를 확인하고, 각각의 장애 정보에 따라 해당 기능보드의 장애알람을 처리하게 된다.

550단계에서, 상기 BTS장애처리블록(232)은 상기 BTS시스템(230)내의 기능보드로부터 상기 응답 요구 메시지에 대응하는 메시지가 존재하는지를 확인한다. 상기 550 단계에서 이전에 탈장 상태로 인식되었던 기능보드(236)로부터 응답 메시지가 존재하면, 560단계에서 상기 BTS장애처리블록(232)은 상기 탈장 상태로 인식되었던 상기 기능 보드(236)의 장애 알람을 해제한다. 이는 상기 BALA(234)의 하드웨어 장애가 발생한 이후 신규로 발생한 알람이므로 하드웨어 장애로 인식되지 못하게 된다. 이는 상기 정상적으로 동작하는 기능보드(236)의 실장 상태를 탈장 상태로 인식하게 된 것이기 때문이다. 반면에, 상기 550단계에서 탈장 상태인 활성화 보드로부터 응답 메시지를 수신하지 못하면, 570단계로 진행하여 해당하는 기능을 수행한다.

570단계에서 상기 BTS 장애처리블록(232)은 상기 탈장 상태로 인식된 상기 기능보드(236)가 이중화 구조를 가지는 보드인지를 확인한다. 580단계에서 상기 보드가 활성화 상태인 보드(236)와 대기 상태인 보드(237)로 구성되는 이중화보드이면, 580단계에서 상기 대기 상태보드(237)의 하드웨어 장애 상태를 확인하여 상기 기능보드(236)의 하드웨어 장애 정보의 신뢰성을 보장한다.

즉, 단계 590에서 상기 BTS 장애처리블록(232)은 상기 대기 상태보드(237)의 하드웨어 장애 변경상태를 확인한다. 600단계에서 상기 대기 상태보드(237)가 탈장 상태에서 실장 상태로 번경되었는지를 확인한다. 이때, 상기 대기 상태의 보드(237)가 탈장 상태에서 실장 상태로 변경되었으면, 600단계로 진행한다.

상기 600단계에서 상기 BTS 장애처리블록(232)은 상기 대기 상태 보드(237)의 하드웨어 장애 알람을 파악함에 있어서, 상기 BALA(234)의 하드웨어 장애로 인해 상기 대기 상태 보드(237)의 상태가 실장 상태가 탈장 상태로 인식됨을 확인하게 된다. 따라서, 상기 대기 상태 보드(237)는 실장된 상태로 상기 대기 상태 보드(237)의 장애 알람을 해제한다.

반면에 상기 600단계에서 상기 대기 상태 보드(237)의 상태가 실장에서 탈장으로 변경되었으면, 상기 대기 상태 보드(237)가 원래 탈장 상태에서 상기 BALA(234)의 하드웨어 장애로 인해 실장 상태로 인식됨을 확인하고, 상기 대기 상태 보드(237)의 장애 알람을 발생한다.

즉, 상기 BTS장애처리블록(232)은 상기 BTS시스템(230)내에 구비된 다수의 기능 보드들의 장애를 확인함에 있어서, 하드웨어 장애를 감지하는 알람보드의 정보를 우선 순위로 하여 상기 다수의 기능 보드들의 장애를 파악하게 된다. 이때, 상기 알람보드가 탈장되거나, 전원 공급에 이상이 발생하여 하드웨어 장애가 발생하는 경우, 상기 BTS 장애처리블록(232)은 상기 각각의 기능보드들에게 응답 메시지를 전송한다. 이때, 각각의 보드들로부터 상기 응답 메시지를 수신하면, 상기 보드들로부터 전송된 장애 정보를 확인하여 해당 기능보드들의 장애 알람을 처리하게 된다. 따라서, 상기 BTS 장애처리블록은 상기 시스템내의 각 기능보드들의 장애 알람을 감지하는 하드웨어알람보드에 장애가 발생하면 상기 각 기능보드들의 장애 정보 및 상기 각 기능보드들의 대기상태 보드들로부터 장애 정보를 수신하여 해당 보드의 장애를 신뢰성 있게 처리하게 된다.

상기 전술한 바와 같이 본 발명은 각각의 하위 장애 처리블록들이 해당 시스템의 장애알람을 수집함에 있어서, 해당 시스템의 하드웨 어알람보드로부터 수신된 장애 알람 정보뿐만 아니라 각 보드들로부터 수신된 장애 알람 정보를 확인하여 현재 시스템의 장애 알람을 보다 정확하게 파악하는 효과를 가진다. 또한, 상기 하드웨어 알람 보드에 장애가 발생하여 상기 시스템의 장애를 감지하지 못하게 되는 경우, 각각의 보드들로부터 수신된 응답 메시지를 수신하여 전체 시스템에 발생하는 장애를 줄이게 되는 효과를 가진다.

Claims

다수의 기능보드들과 상기 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드와, 상기 알람보드로부터 임의의 기능보드의 장애 정보를 수신하여 해당 장애 알람을 수집하여 처리하는 장애처리소프트웨어블록을 구비한 이동통신시스템에서, 상기 장애처리소프트웨어블록이 상기 다수의 기능보드의 하드웨어 장애 정보를 감지하는 방법에 있어서,

상기 장애처리소프트웨어블록이 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하는 과정과,

상기 알람보드의 하드웨어 장애 정보를 통해 상기 알람보드에 하드웨어 장애가 발생함을 확인하면, 상기 다수의 기능보드들에 응답 요구 메시지를 전송하고 상기 다수의 기능보드들로부터 프로토콜을 통해 각 기능보드들의 하드웨어 장애 정보를 수신하는 과정으로 구성됨을 특징으로 하는 상기 방법.
제 1항에 있어서,

상기 장애처리소프트웨어블록이 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하여 상기 알람보드의 하드웨어 장애가 발생하지 않음을 확인하면, 상기 알람보드가 감지한 상기 다수의 기능보드들의 장애 정보들을 확인하고 상기 알람보드의 장애 정보에 따라 해당 기능보드들의 장애를 처 리함을 특징으로 하는 방법.
제 1항에 있어서,

상기 장애처리소프트웨어블록이 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하여 상기 알람보드의 하드웨어 장애가 발생함을 확인하면, 상기 활성화 상태인 다수의 기능보드들에 응답 요구 메시지를 전송하고, 상기 활성화 상태인 다수의 기능보드들로부터 프로토콜을 통해 상기 응답 요구 메시지에 대응하는 메시지를 수신하여 상기 활성화 상태인 다수의 기능보드들의 하드웨어 장애 알람을 해제하는 과정을 포함함을 특징으로 하는 상기 방법.
제 3항에 있어서,

상기 활성화 상태인 다수의 기능보드들로부터 프로토콜을 통해 상기 응답 요구 메시지에 대응하는 메시지를 수신하지 않으면, 대기 상태인 다수의 기능보드들의 알람 상태를 확인하여 상기 다수의 기능보드들에 대한 하드웨어 장애 알람을 발생하거나, 해제하는 과정을 포함함을 특징으로 하는 상기 방법.
제 4항에 있어서,

상기 대기 상태인 다수의 기능보드들의 알람 상태가 탈장 상태에서 실장 상태로 변경되면 상기 대기 상태인 기능보드의 장애 알람을 해제함을 특징으로 하는 상기 방법.
제 4항에 있어서,

상기 대기 상태인 다수의 기능보드들의 알람 상태가 실장 상태에서 탈장 상태로 변경되면 상기 대기 상태인 기능보드의 장애 알람을 발생함을 특징으로 하는 상기 방법.
다수의 기능보드들과 상기 다수의 기능보드들의 하드웨어 장애를 감지하는 알람보드와, 상기 알람보드로부터 임의의 기능보드의 장애 정보를 수신하여 해당 장애아람을 수집하여 처리하는 장애처리소프트웨어블록을 구비한 이동통신시스템에서, 상기 장애처리소프트웨어블록이 상기 기능보드의 장애 정보를 수신하는 장치에 있어서,

상기 다수의 기능보드들로부터 하드웨어 장애 정보를 수신하여 프로토콜을 통해 상기 장애처리소프트웨어블록에 전송하는 상기 알림 보드의 하드웨어 장애 유무를 확인하고, 상기 알람 보드에 하드웨어 장애가 발생함을 확인하면 상기 다수의 기능보드들에 응답 요구 메시지를 전송하여 상기 다수의 기능보드들로부터 프로토 콜을 통해 각 기능보드들의 하드웨어 장애 정보를 수신하는 장애처리소프트웨어블록을 구비하는 상기 장치.
제 7항에 있어서,

상기 장애처리소프트웨어블록은 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하고, 상기 알람보드의 하드웨어 장애가 발생하지 않음을 확인하면, 상기 알람보드가 감지한 상기 다수의 기능보드들의 장애 정보들을 확인하고 상기 알람보드의 장애 정보에 따라 해당 기능보드들의 장애를 처리함을 특징으로 하는 장치.
제 8항에 있어서,

상기 장애처리소프트웨어블록은 상기 알람보드로부터 프로토콜을 통해 상기 알람보드의 하드웨어 장애 정보를 수신하여 상기 알람보드의 하드웨어 장애가 발생함을 확인하면, 상기 활성화 상태인 다수의 기능보드들에 응답 요구 메시지를 전송하고 상기 활성화 상태인 다수의 기능보드들로부터 프로토콜을 통해 상기 응답 요구 메시지에 대응하는 메시지를 수신하여 상기 활성화 상태인 다수의 기능보드들의 하드웨어 장애 알람을 해제하는 과정을 포함함을 특징으로 하는 상기 장치.
제 9항에 있어서,

상기 장애처리소프트웨어블록은 상기 활성화 상태인 다수의 기능보드들로부터 프로토콜을 통해 상기 응답 요구 메시지에 대응하는 메시지를 수신하지 않으면, 대기 상태인 다수의 기능보드들의 알람 상태를 확인하여 상기 다수의 기능보드들에 대하여 하드웨어 장애 알람을 발생하거나, 해제하는 과정을 포함함을 특징으로 하는 상기 장치.
제 10항에 있어서,

상기 장애처리소프트웨어블록은 상기 대기 상태인 다수의 기능보드들의 알람 상태가 탈장 상태에서 실장 상태로 변경됨을 확인하면 상기 대기 상태인 기능보드의 장애 알람을 해제함을 특징으로 하는 상기 장치.
제 10항에 있어서,

상기 장애처리소프트웨어블록은 상기 대기 상태인 다수의 기능보드들의 알람 상태가 실장 상태에서 탈장 상태로 변경됨을 확인하면 상기 대기 상태인 기능보드의 장애 알람을 발생함을 특징으로 하는 상기 장치.