KR100318921B1 - 이동통신시스템의 상태 관리 방법 - Google Patents
이동통신시스템의 상태 관리 방법 Download PDFInfo
- Publication number
- KR100318921B1 KR100318921B1 KR1019990021560A KR19990021560A KR100318921B1 KR 100318921 B1 KR100318921 B1 KR 100318921B1 KR 1019990021560 A KR1019990021560 A KR 1019990021560A KR 19990021560 A KR19990021560 A KR 19990021560A KR 100318921 B1 KR100318921 B1 KR 100318921B1
- Authority
- KR
- South Korea
- Prior art keywords
- state
- processor
- base station
- failure
- processors
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000010295 mobile communication Methods 0.000 title claims abstract description 11
- 230000004044 response Effects 0.000 claims description 28
- 230000008569 process Effects 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 16
- 238000012546 transfer Methods 0.000 claims description 4
- 238000007726 management method Methods 0.000 abstract description 22
- 238000004891 communication Methods 0.000 abstract description 5
- 230000008859 change Effects 0.000 description 21
- 238000010586 diagram Methods 0.000 description 8
- 238000013468 resource allocation Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 239000011111 cardboard Substances 0.000 description 3
- 206010019909 Hernia Diseases 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000012550 audit Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
가. 청구범위에 기재된 발명이 속한 기술분야
이동통신시스템의 상태관리 방법
나. 발명이 해결하려고 하는 기술적 과제
이동통신시스템에서 장애원인을 다양화하여 상태를 관리할수 있는 방법을 제공함에 있다.
다. 발명의 해결방법의 요지
통신시스템의 상태관리 방법이, 상위 프로세서나 디바이스의 장애를 하위 프로세서나 디바이스의 장애에 반영시키고, 장애의 여러 가지 원인(reason)을 두어 상태를 관리함을 특징으로 한다.
라. 발명의 중요한 용도
이동통신시스템의 프로세서 및 디바이스 상태관리에 이용된다.
Description
본 발명은 통신시스템의 상태관리 방법에 관한 것으로, 특히 이동통신시스템에 구비된 상태블럭들의 상태관리 방법에 관한 것이다.
일반적으로 제어국 및 기지국 시스템의 운용보수 소프트웨어(O&M S/W)는 여러 모듈(Module)로 구성된다. 그중 한 모듈인 상태블럭은 기지국 및 제어국 시스템 내에서 운용중인 프로세서들을 감시하고 디바이스들의 상태를 관리하여 신뢰성있는 서비스를 보장하기 위한 유지보수 소프트웨어이다. 또한, 상태블럭은 관리하는 상태정보들로부터 무선단(RFU;Radio Frequency Unit) 제어정보를 생성하여 무선단에 제공하고, 호처리블럭에 오버헤드(Overhead) 채널의 절체를 요구하며, 기지국 셀(cell)의 가용정보를 생성하여 제공하는 등 기지국 호와 관련된 주요한 기능을 수행한다.
상기한 바와 같이 유지보수 상태블럭은 프로세서와 디바이스의 상태를 관리한다. 상기 상태블럭은 기지국 시스템의 관리장치인 BSM과 제어국 및 기지국의 메인보드상에 상주하여 유지보수 기능을 수행한다. 기존의 CDMA나 PCS 시스템의 상태블럭에서는 프로세서나 디바이스의 상태가 개별적으로 관리되어 상태변화 발생시 상태만을 보고 상태변화의 원인을 파악하기가 어려웠다. 예를들면, 한 디바이스의상위 프로세서에 장애가 발생하는 경우, 디바이스의 상태가 장애처리가 되는데 디바이스의 상태만을 살펴보았을 경우 그 원인이 프로세서에 의한 것인지 디바이스 자체에 의한 것인지 파악하기 어려웠다. 또한 보드가 탈장된 경우 그 다바이스는 제기능을 수행하지 못하지만, 상태블럭에서 디바이스의 상태는 정상인 것처럼 관리되었다. 따라서 보다 정확한 상태변화의 원인이 제공된다면 상태관리를 보다 효율적으로 할수 있을 것이다.
본 발명은 이동통신시스템에서 상위 상태를 하위상태에 반영시키고, 장애종류를 다양화 하므로서 상태를 관리할수 있는 상태관리 방법을 제공함에 있다.
상기 목적을 달성하기 위한 통신시스템의 상태관리 방법이, 상위 프로세서나 디바이스의 장애를 하위 프로세서나 디바이스의 장애에 반영시키고, 장애의 여러 가지 원인(reason)을 두어 상태를 관리함을 특징으로 한다.
도 1은 통신시스템에 구비된 상위 보드와 하위 보드들을 도시하는 도면.
도 2는 본 발명에 따른 이동통신시스템에 구비된 상태블럭들을 도시하는 도면.
도 3은 본 발명에 따른 상태블럭 STM이 프로세서의 상태를 갱신하는 과정을 도시하는 도면.
도 4는 본 발명에 따른 상태블럭 MSH가 프로세서의 상태를 갱신하는 과정을 도시하는 도면.
도 5는 본 발명에 따른 상태블럭 BSH가 프로세서의 상태를 갱신하는 과정을 도시하는 도면.
도 6은 본 발명에 따른 상태블럭 MSH가 보코더 채널의 상태를 갱신하는 과정을 도시하는 도면.
도 7은 본 발명에 따른 상태블럭 BSH가 기지국 채널상태를 갱신하는 과정을 도시하는 도면.
도 8은 본 발명에 따른 상태블럭 BSH가 보코더 채널이 상태를 갱신하는 과정을 도시하는 도면.
이하 본 발명의 바람직한 실시예를 첨부된 도면의 참조와 함께 상세히 설명한다.
우선 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 한해서는 비록 다른 도면상에 표시되더라도 가능한 동일 부호를 가지도록 하였다. 또한 본 발명을 설명함에 있어서, 관련된 공지기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다.
본 발명은 상위의 상태를 하위의 상태에 반영시키고, 장애(FAULT) 종류를 다양화 함으로써 상태를 관리하는 방법을 제안한다. 이전에는 상위 상태가 하위 상태에 반영되지 않았고, 또한 상태관리도 장애와 정상(Normal)으로만 구분되어 관리되었으므로 장애가 발생하는 경우, 장애의 원인을 파악하기가 어려웠다. 이러한 경우는 다음과 같은 경우로 세분화할수 있다.
1. 상위 프로세서가 죽었는데 하위 프로세서는 살아있는 것처럼 보이는 경우
2. 상위 프로세서가 죽었는데 하위 디바이스가 동작하는 것처럼 보이는 경우
3. 보드가 탈장되었는데 디바이스가 동작하는 것처럼 보이는 경우
4. 장애블럭에 의한 알람과 장애가 구분되지 않는 경우
5. 상위 프로세서에 의한 영향이 에이티엠(ATM)쪽과 관련되는지의 여부가 구분되지 않는 경우
이의 해결을 위하여 본 발명에서는 상위 프로세서나 디바이스의 장애를 하위 프로세서나 디바이스의 장애에 반영시키고, 장애에 여러 가지 원인(RESON)을 두어 상태를 다양화 함으로써 상태를 통하여 상태변화의 원인을 쉽게 파악할수 있도록 한다. 예를들어, 도 1에 도시된 바와 같이, 메인보드(보드A)에 프로세서A와 디바이스 B에 존재하고, 상위보드(보드B)에 프로세서B와 디바이스B가 존재하며, 하위보드(보드C)에 프로세서C와 디바이스C가 존재할 경우, 각 장애에 대한 원인들을 분류하면 다음과 같이 요약된다.
프로세서 B의 장애 원인 :
프로세서 A 장애에 의한 장애(=F_HPRC)
프로세서 B 자체 장애에 의한 장애(=F_PDWN)
프로세서 C의 장애 원인 :
프로세서 B 장애에 의한 장애(=F_HPRC),
프로세서 C 자체 장애에 의한 장애(=F_PDWN)
디바이스 B의 장애 원인 :
프로세서 A 장애에 의한 장애(=F_HPRC),
프로세서 B 장애에 의한 장애(F_PDWN),
디바이스 보드 B 탈장에 의한 장애(=F_BDLT),
디바이스 B 자체의 하드웨어 장애 또는 알람에 의한 장애(=FAULT,F_BLK or F_ALM)
디바이스 C의 장애 원인 :
프로세서 B 장애에 의한 장애(=F_HPRC),
프로세서 C 장애에 의한 장애(=F_PDWN),
디바이스 C 자체의 하드웨어 장애 또는 알람에 의한 장애(=FAULT,F_BLK or F_ALM)
따라서 장애 종류는 F_PDWN(Fault Processor Down : 프로세서 자체 장애), F_APRC(Fault ATM Processor : ATM관련 프로세서 장애에 의한 장애), F_HPRC(Fault High Processor : 상위 프로세서 장애에 의한 장애 ), F_BDLT(Fault Board Deletion : 보드 탈장에 의한 장애), FAULT(장애), F_BLK(Fault Block : 블럭 장애), F_ALM(Fault Alarm : 알람 장애) 등이 있다.
일반적으로, 이동통신시스템에서의 상태관리는 크게 BSM(기지국 관리장치)에 들어가는 상태블럭인 STM(status Manager : 상태관리블럭), 제어국(BSC)의 메인보드상에 들어가는 상태블럭인 MSH(Main Status Handling : 주 상태처리블럭), 기지국(BTS)의 메인 보드상에 들어가는 상태블럭인 BSH(BTS Status Handling : BTS 상태처리블럭)에 의해 수행된다.
이하 상기 도 2의 구성에 근거한 다양한 상태관리를 설명한다.
먼저, 프로세서 상태관리를 살펴보면, 프로세서의 상태관리는 프로세서의 폴링에 의해 수행된다. 상위 상태블럭은 하위 프로세서들의 블록들에서 메시지를 보내고 응답을 보내줄 것을 요구한다. 이때 일정시간이 경과해도 응답이 오지 않을 경우 그 프로세서가 다운(down)된 것으로 판단한다. 즉, 프로세서의 상태관리는 프로세서의 폴링을 통하여 프로세서의 정상 유무를 간접적으로 파악한다. 여기서 프로세서의 상태는 NORMAL(정상), F_APRC(Fault_ATM Processor : ATM 프로세서서 장애에 의한 장애), F_HPRC(Fault_High Processor : 상위 프로세서의 장애에 의한 장애), F_PDWN(Fault_Processor Down : 프로세서 자체의 장애), N_EQP(Not Equip : 비실장) 중 하나가 된다. 또한, 프로세서의 상태관리는 크게 STM에 의한 것, MSH에 의한 것, BSH에 의한 것으로 나눌수 있다.
상기 STM이 프로세서의 상태를 갱신하는 과정을 도 3에 도시하고 있다.
상기 STM은 상기 BSC 메인 프로세서인 BMP(BSC Main Processor : BSC 주프로세서)와 GAN과 관련된 모든 프로세서들을 폴링하여 프로세서들의 상태를 조사한다. 또한, 상기 STM은 MSH를 폴링하면서 상기 MSH가 수집한 모든 BSC,BTS 프로세서들의 상태를 받아 관리한다. 상기 STM이 수집한 모든 프로세서들의 상태는 UIM에서 MMC(Man-Machine Command=운용자 명령어)를 수행하는데 이용된다.
상기 도 3을 참조하면, 상기 STM은 311단계에서 ATM관련 프로세서들을 폴링하여 프로세서들의 상태를 확인한다. 여기서 상기 ATM관련 프로세서들은 GAN관련 프로세서들이다. 이때 응답이 수신될 경우 상기 STM은 315단계로 진행하며, 상기응답이 수신되지 않을 경우 상기 STM은 313단계로 진행하여 관리하고 있는 모든 하위 프로세서의 상태를 F_APRC로 변경하고 종료한다. 한편, 상기 ATM관련 프로세서의 상태수집을 확인한 상기 STM은 상기 315단계에서 BMP상태를 확인한다. 이때 상기 BMP상태가 확인될 경우 상기 STM은 319단계로 진행하여 상기 MSH가 전해준 하부 프로세서들의 상태를 그대로 상태관리에 반영한다. 반면, 상기 BMP상태가 확인되지 않을 경우 317단계로 진행하여 해당 BMP의 상태를 F_PDWN으로 변경하고, 해당 BSC와 하부 BTS들의 모든 프로세서들의 상태를 F_HPRC로 변경한다.
상기 MSH가 프로세서의 상태를 갱신하는 과정을 도 4에 도시하고 있다.
상기 MSH는 BSC내의 하부 프로세서들과 BTS 메인 프로세서인 BCP(BTS Control Processor : BTS 제어 프로세서)를 폴링하여 프로세서들의 상태를 조사한다. 또한 MSH는 BCH를 폴링하면서 상기 BSH가 수집한 모든 BTS 프로세서들의 상태를 받아 관리한다. 상기 MSH는 수집한 프로세서들의 상태를 상기 STM의 폴링에 대한 응답 메시지에 실어 BSM으로 보낸다.
상기 도 4를 참조하면, 상기 MSH는 411단계에서 ATM관련 프로세서들을 폴링하여 상태를 확인한다. 이때 응답이 수신될 경우 상기 MSH는 415단계로 진행하며, 상기 응답이 수신되지 않을 경우 상기 MSH는 413단계로 진행하여 관리하고 있는 모든 하위 프로세서의 상태를 F_APRC로 변경한다. 한편, 상기 ATM관련 프로세서들의 상태를 확인한 상기 MSH는 상기 415단계에서 BCP 상태를 확인한다. 이때 상기 BCH로부터 응답이 수신되지 않을 경우 417단계로 진행하여 해당 BCP의 상태를 F_PDWN으로 변경하고, 모든 하위 프로세서의 상태를 F_HPRC로 변경한다. 반면, 상기 BCH로부터 응답이 수신될 경우 상기 MSH는 419단계로 진행하여 BSH가 전해준 하부 프로세서 상태를 그대로 보관한다. 그리고 상기 MSH는 421단계에서 상기 BSC의 하부 프로세서들을 폴링하여 상태를 확인한다. 이때 응답이 수신될 경우 상기 MSH는 425단계로 진행하여 해당 프로세서의 상태를 NORMAL로 변경한다. 반면, 응답이 수신되지 않을 경우 상기 MSH는 423단계로 진행하여 해당 프로세서의 상태를 F_PDWN으로 변경한다.
상기 BSH가 프로세서의 상태를 갱신하는 과정을 도 5에 도시하였다.
상기 BSH는 BTS내의 하부 프로세서들을 폴링하여 프로세서들의 상태를 조사한다. 상기 BSH는 수집한 프로세서들의 상태를 상기 MSH의 폴링에 대한 응답 메시지에 실어 BSC로 보낸다.
상기 도 5를 참조하면, 상기 BSH는 511단계에서 ATM관련 프로세서들을 폴링하여 상태를 확인한다. 이때 응답이 수신되지 않을 경우, 상기 BSH는 513단계로 진행하여 관리하는 모든 하위 프로세서의 상태를 F_APRC로 변경하며, 상기 응답이 수신될 경우 515단계로 진행한다. 그리고 상기 BSH는 상기 515단계에서 BTS내의 하부 프로세서들을 폴링하여 상태를 확인한다. 이때 응답이 수신될 경우 상기 BSH는 517단계로 진행하여 해당 프로세서의 상태를 NORmAL로 변경하고, 응답이 수신되지 않을 경우 상기 BSH는 517단계로 진행하여 해당 프로세서의 상태를 F_PDWN으로 변경한다.
여기서, 프로세서의 상태 종류를 요약하면 하기 표 1과 같다.
NORMAL | 정상적인 프로세서의 상태 |
F_APRCF_HPRC | 상위 ATM관련 프로세서가 fault가 난 경우의 프로세서 장애상위 프로세서가 fault가 난 경우의 프로세서 장애프로세서 자체의 fault 상태 |
N_EQP | deactive에 의한 pld에서 디바이스의 형상이 사라진 상태 |
다음으로, 디바이스 상태관리에 대해 설명한다.
상기 디바이스 상태관리는 상태보고 및 주기적인 요구(Audit)에 의한다. 즉, 상위 상태블럭은 하위 블록들로부터 디바이스에 대한 상태변화를 보고 받는다. 또한 일정시간 간격으로 디바이스의 상태를 요구하고, 그에대한 보고를 받는다. 상기 디바이스는 상위 프로세서가 다운될 때 제기능을 하지 못한다. 혹은, 디바이스가 있는 보드가 탈장되었을 경우 디바이스는 장애가 발생한다. 장애블럭이 디바이스의 알람을 보고하는 경우도 그 디바이스의 상태는 변화한다.
상태블럭이 관리하는 디바이스의 상태는 호블럭이 자원할당을 하는 리소스관리가 필요한 디바이스의 상태와, 자원할당과 직접적인 관계가 없는 디바이스의 상태로 구분할수 있다. 전자에는 보코더, BTS채널의 상태가 해당되며, 후자에는 중간주파수단(IF Unit), 알에프단(RF Unit), BTS test Uinit 등의 디바이스 상태가 해당된다. 전자의 경우 디바이스 상태는 Busy, Idle, M_BLK, T_BLK, F_APRC, F_HPRC, F_PDWN, F_BDLT(Fault_Board Deletion), F_BLK(Fault_Block), N_EQP 중 하나가 되고, 후자의 경우는 NORMAL, F_APRC, F_HPRC, F_BDLT, F_ALM(Fault_Alarm), FAULT 중 하나가 된다. 여기서 상기 디바이스 상태는 BMP의 MSH나 BCP의 BSH에서 관리하지만 BSM의 STM는 관리하지 않는다.
리소스 할당에 사용되는 디바이스는 MSH의 보코더(=보코더 채널)와 BTS의 채널(=트래픽 채널+오버헤드 채널)이 있다. 호처리블럭과 상태블럭은 리소스의 상태들을 공유메모리(shared memory) 형태로 공유한다. 그리고 상태블럭은 채널의 장애유무와 유지보수블럭의 MMC에 의한 리소스 블록상태를 호처리블럭으로 제공하며, 호처리블럭이 자원을 할당한 결과를 busy 및 Idle 형태로 제공받는다.
상기 MSH가 보코더 채널의 상태를 갱신하는 과정을 도 6에 도시하였다.
보코더의 경우, TCP프로세서가 다운되었을 때, 보코더 채널의 상태는 F_PDWN이 된다. 보코더 채널카드가 빠져있을 경우는 F_BDLT로 채널의 상태를 변경한다. 보코더 채널 자체의 장애시에는 채널의 상태를 F_BLK로 만든다. 그 이외에는 하위 보코더 담당 블록이 전달한 보코더 채널의 상태를 그대로 MSH의 상태로 반영한다. 정상일 경우는 NORMAL(=Busy+Idle)이고, 비정상일 경우는 F_BLK가 된다.
상기 도 6를 참조하면, 상기 MSH는 611단계에서 하위 디바이스 블록의 상태보고시(=메세지 수신시) 해당 디바이스의 상태(NORMAL or F_BLK)를 반영시킨다. 그리고 상기 MSH는 613단계에서 ATM관련 프로세서들을 폴링하여 상태를 확인한다. 이때 응답이 수신되지 않을 경우 상기 MSH는 615단계로 진행하여 M_BLK(MMC Block), T_BLK(Test Block)를 제외한 모든 채널에 대해 모든 보코더 채널의 상태를 F_APRC로 변경한다. 반면, 응답이 수신될 경우 상기 MSH는 617단계로 진행하여 TCP프로세서의 상태를 확인한다. 이때 상기 TCP의 상태가 확인되지 않을 경우 상기 MSH는 619단계로 진행하여 M_BLK,T_BLK을 제외한 모든 채널에 대해 해당채널의 상태를 F_PDWN으로 변경한다. 반면, 상기 TCP의 상태가 확인될 경우 상기 MSH는 621단계로 진행하여 보코더 보드의 상태를 확인한다. 여기서 상기 보코더 보드의 상태가 확인될 경우 하위 보코더 담당 블록이 전달한 채널의 상태를 그대로 반영하며, 상기 보코더 보드의 상태가 확인되지 않을 경우 상기 MSH는 623단계로 진행하여 M_BLK,T_BLK을 제외한 모든 채널에 대해 해당 채널의 상태를 F_BDLT로 변경한다.
상기 BSH가 기지국 채널상태를 갱신하는 과정을 도 7에 도시하였다.
기지국(BTS)내이 프로세서들중 CIP와 CEP는 계층화되어 있다. 즉, CEP가 BTS채널의 상태를 CIP에 보고하며, 상기 CIP가 상기 BSH에게 CEP상태와 채널의 상태들을 보고한다. CIP프로세서가 다운되었거나, CEP프로세서가 다운되었으면, 상기 BSH는 BTS채널의 상태를 각각 F_HPRC 및 F_PDWN로 만든다. 여기서 MSH의 폴링이 BSH로 오지 않을 경우는 BSH는 채널상태를 F_APRC로 만든다. 채널카드가 빠져있을 경우는 F_BDLT로 채널이 상태를 변경한다. 채널자체 장애시에는 채널의 상태를 F_BLK로 만든다. 그 이외에는 하위 채널 담당블럭이 전달한 채널의 상태를 그대로 상기 BSH의 상태로 반영한다. 정상일 경우는 NORMAL(=Busy+Idle)이고 비정상일 경우는 F_BLK이 된다.
상기 도 7을 참조하면, 상기 BCH는 711단계에서 하위 디바이스 블록의 상태보고시 해당 디바이스의 상태를 반영시킨다. 그리고 상기 BSH는 713단계에서 ATM관련 프로세서들의 상태수집(summation)을 확인한다. 이때 상기 상태수집이 확인될 경우 상기 BSH는 717단계로 진행하며, 상기 상태수집이 확인되지 않을 경우 715단계로 진행하여 M_BLK,TBLK을 제외한 모든 채널에 대해 모든 보코더 채널의 상태를 F_APRC로 변경한다. 한편, 상기 BSH는 상기 717단계에서 CIP 프로세서의 상태를 확인한다. 이때 상기 CIP프로세서의 상태확인시 상기 BSH는 721단계로 진행하며, 상기 CIP 프로세서의 상태가 확인되지 않을 시 상기 BSH는 719단계로 진행하여 M_BLK,T_BLK를 제외한 모든 채널에 대해 해당 채널의 상태를 F_HPRC로 변경한다.그리고 상기 BSH는 상기 721단계에서 CEP프로세서의 상태를 확인한다. 상기 CEP프로세서 상태 확인시 상기 BSH느느 725단계로 진행하며, 상기 CEP프로세서 상태가 확인되지 않을 시 상기 BSH는 727단계로 진행하여 M_BLK,T_BLK을 제외한 모든 채널에 대해 해당 채널의 상태를 F_PDWN으로 변경한다. 그리고 상기 BSH는 상기 725단계에서 채널카드 보드의 상태를 확인한다. 이때, 채널카드 보드의 상태가 확인될 시 상기 BSH는 하위 채널담당 블록이 전달한 채널의 상태를 그대로 반영하며, 상기 채널카드 보드 상태가 확인되지 않을 시 상기 BSH는 727단계로 진행하여 M_BLK,T_BLK를 제외한 모든 채널에 대해 해당 채널의 상태를 F_BDLT로 변경한다.
여기서 상기 M_BLK,T_BLK는 유지보수 블록들의 MMC에 의한 블록(Block)들이다. 상기 M_BLK는 호처리블럭이 리소스할당을 더 이상하지 않도록 하기 위한 강제적인 블록상태이며, 상기 T_BLK는 채널의 시험을 위하여 호처리블럭의 리소스할당을 막는 블록상태이다. 만약, 상기 M_BLK나 T_BLK시 그 채널에 이미 호가 할당되어 있는 경우는 호가 끝날 때까지 Busy상태를 유지하며, 이 경우 상태블럭은 채널의 상태를 P_BLK라고 만들어 시스템 운용자에게 보고한다. 여기서 상기 P_BLK는 운용자에게 보고하기 위한 상태이며 호처리블럭이 자원할당에 사용하는 채널의 상태와는 무관하다. 상기 M_BLK시는 F_BLK를 할수 없지만, T_BLK시는 M_BLK를 강제로 할수 있도록 한다. F_BLK시는 T_BLK와 M_BLK를 할수 있지만, T_BLK시나 M_BLK시는 F_BLK가 될 수 없도록 한다. 호처리블럭은 채널이 Busy 상태이거나 BLOCK이 되어 있을 경우(=M_BLK, T_BLK, F_APRC, F_HPRC, F_BDLT, F_BLK) 해당 채널에 새로운 호를 더 이상 할당하지 않는다. MMC중 재기동(deact)명령을 통하여 채널을 N_EQP상태로 변경할수 있는데 이를 위해서는 이전에 반드시 채널이 M_BLK되어 있어야 한다. 오버헤드 채널은 항상 Busy라고 할수 있으므로 M_BLK, T_BLK이 될 수 없다. 상기 F_BLK이 되려면 반드시 오버헤드채널의 절체 과정이 이루어져야 하며, F_BLK인 채널은 M_BLK나 T_BLK가 될 수 있다.
여기서 채널 상태 종류를 요약하면 하기 표 2와 같다.
NORMAL(Busy)NORMAL(Idle) | 호처리에 할당된 tce의 상태(모든 오버헤드 채널은 Busy 상태임)호처리 블록에 의해 사용되지 않는 tce의 상태 |
M_BLK | 디바이스를 deact하기 직전 디바이스의 동작을 막을 때 사용on-line 또는 on-demand 상에서 tce 시험시 사용Busy인 tce를 M_BLK 또는 T_BLK한후 tce가 idle로 되기까지의 중간단계 |
F_APRCF_HPRCF_PDWNF_BDLTF_BLK | 상위 ATM관련 프로세서가 fault가 난 경우의 채널상태상위 프로세서(=cip)가 fault가 난 경우의 채널상태채널을 관리하는 프로세서(=CEP,TCP)가 다운된 rddn의 채널상태채널카드(보코더카드)가 탈장된 경우의 채널상태채널자체의 fault 상태 |
N_EQP | deactive에 의해 pld에서 채널의 형상이 사라진 상태 |
상기 BSH가 보코더 채널이 상태를 갱신하는 과정을 도 8에 도시하였다.
리소스 관리가 되지 않는 디바이스들의 대부분은 BTS의 중간주파수단, 알에프단 및 테스트단 등과 같은 하드웨어와 관계된 디바이스들이다. 이러한 디바이스의 상태는 정상일 경우 NORMAL이며, 비정상일 경우 F_APRC, F_PDWN, F_BDLT, F_ALM, FAULT가 된다. 상기 F_ALM은 장애블럭이 통보해주는 하드웨어 장애를 표시하는데 사용된다.
상기 도 8을 참조하면, 상기 BSH는 811단계에서 하위 디바이스 블록의 상태 보고시 해당 디바이스의 상태를 반영시킨다. 그리고 상기 BSH는 813단계에서 ATM관련 프로세서들의 상태수집을 확인한다. 이때 상기 상태수집이 확인될 경우 상기BSH는 817단계로 진행하며, 상기 상태수집이 확인되지 않을 경우 상기 BSH는 815단계로 진행하여 해당 디바이스 상태를 F_APRC로 변경한다. 한편, 상기 BSH는 상기 817단계에서 상기 CIP(or BTP) 프로세서의 상태를 확인한다. 이때 상기 CIP프로세서 상태확인시 상기 BSH는 821단계로 진행하며, ??아기 CIP프로세 상태가 확인되지 않을 시 상기 BSH는 819단계로 진행하여 해당 디바이스 상태를 F_PDWN으로 변경한다. 그리고 상기 BSH는 상기 821단계에서 디바이스 보드의 상태를 확인한다. 상기 디바이스 보드 상태에 이상이 없을 경우 NORMAL로 판단하고, 상기 이상이 있을 경우 823단계로 진행하여 해당 디바이스 상태를 F_DLT로 변경한다.
여기서, 하드웨어 디바이스 상태 종류를 살펴보면 하기 표 3과 같다.
NORMAL | 정상적인 디바이스 상태 |
F_APRCF_PDWNF_BDLTF_ALMFAULT | 상위 ATM관련 프로세서가 fault가 난 경우의 디바이스 상태디바이스 제어 프로세서(=CIP or BTP)가 fault가 난 경우의 디바이스 상태디바이스 보드가 탈장된 경우의 디바이스 상태장애블럭이 통보해주는 디바이스와 하드웨어적인 장애디바이스 자체의 fault 상태 |
N_EQP | deactive에 의해 pld에서 디바이스의 형상이 사라진 상태 |
상술한 바와 같이 본 발명은 통신시스템에서 상위 프로세서나 디바이스의 장애를 하위 프로세서나 디바이스의 장애에 반영시키고, 장애의 여러 가지 원인(reason)을 두어 상태를 다양화 함으로써 상태를 통하여 상태변환의 원인을 쉽게 파악할수 있는 장점이 있다.
Claims (3)
- 기지국 관리장치(BSM : base station manager), 기지국 제어기(BSC : base station controller) 및 기지국(BTS : base station)을 구비하며, 프로세서의 장애상태를 상위 ATM관련 프로세서의 장애에 의한 장애(F_APRC), 프로세서 자체의 장애(F_PDWN) 및 상위 프로세서의 장애에 의한 장애(F_HPRC)로 구분하는 이동통신시스템에서, 상기 기지국 관리장치의 상태관리블럭(STM : status manager)이 하위 프로세서들의 상태를 관리하기 위한 방법에 있어서,상기 기지국 관리장치의 상태관리블럭(STM)이, ATM(Asynchronous transfer mode) 관련 프로세서들을 폴링하여 상태를 확인하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신될 시 상기 기지국 제어기의 주 프로세서(BMP : base station main processor)의 상태를 확인하는 과정과,상기 기지국 제어기의 주 프로세서의 상태가 정상인 경우 상기 기지국 제어기의 주상태처리블럭(MSH : Main Status Handling)으로부터 수신한 하위 프로세서들의 상태를 그대로 기록하는 과정과,상기 기지국 제어기의 주 프로세서의 상태가 정상이 아닌 경우 상기 기지국 제어기의 주 프로세서의 상태를 상기 프로세서 자체의 장애(F_PDWN)로 기록하고, 나머지 모든 하위 프로세서들의 상태를 상위 프로세서의 장애에 의한 장애(F_HPRC)로 기록하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신되지 않을 시 모든 하위 프로세서들의 상태를 상기 상위 ATM관련 프로세서의 장애에 의한 장애(F_APRC)로 기록하는 과정을 포함하는 것을 특징으로 하는 방법.
- 기지국 관리장치(BSM : base station manager), 기지국 제어기(BSC : base station controller) 및 기지국(BTS : base station)을 구비하며, 프로세서의 장애상태를 상위 ATM관련 프로세서의 장애에 의한 장애(F_APRC), 프로세서 자체의 장애(F_PDWN) 및 상위 프로세서의 장애에 의한 장애(F_HPRC)로 구분하는 이동통신시스템에서, 상기 기지국 제어기의 주상태처리블럭(MSH : Main Satus Handing)이 하위 프로세서들의 상태를 관리하기 위한 방법에 있어서,상기 기지국 제어기의 상기 주상태처리블럭(MSH)이, ATM(Asynchronous transfer mode) 관련 프로세서들을 폴링(polling)하여 상태를 확인하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신될 시 상기 기지국의 제어 프로세서(BCP : base station control processor)의 상태를 확인하는 과정과,상기 기지국의 제어 프로세서의 상태가 정상인 경우 상기 기지국의 상태처리블럭(BSH)으로부터 수신한 하위 프로세서들의 상태를 기록하고, 상기 기지국의 하위 프로세서들을 폴링하여 상태를 확인하는 과정과,상기 기지국의 하위 프로세서들중 응답이 수신되는 프로세서의 상태는 정상(NORMAL)이라고 기록하고, 응답이 수신되지 않는 프로세서의 상태는 상기 프로세서 자체의 장애(F_PDWN)로 기록하는 과정과,상기 기지국의 제어 프로세서의 상태가 정상이 아닌 경우 상기 기지국의 제어 프로세서의 상태를 상기 프로세서 자체의 장애(F_PDWN)로 기록하고, 나머지 모든 하위 프로세서들의 상태를 상기 상위 프로세서의 장애에 의한 장애(F_HPRC)로 기록하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신되지 않을 시 모든 하위 프로세서들의 상태를 상기 상위 프로세서의 장애에 의한 장애(F_APRC)로 기록하는 과정을 포함하는 것을 특징으로 하는 방법.
- 기지국 관리장치(BSM : base station manager), 기지국 제어기(BSC : base station controller) 및 기지국(BTS : base station)을 구비하며, 프로세서의 장애상태를 상위 ATM관련 프로세서의 장애에 의한 장애(F_APRC), 프로세서 자체의 장애(F_PDWN) 및 상위 프로세서의 장애에 의한 장애(F_HPRC)로 구분하는 이동통신시스템에서, 상기 기지국의 상태처리블럭(BSH : BTS Status Handling)이 하위 프로세서들의 상태를 관리하기 위한 방법에 있어서,상기 기지국의 상기 상태처리블럭이, ATM(Asynchronous transfer mode) 관련 프로세서들을 폴링하여 상태를 확인하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신될 시 상기 기지국의 하위 프로세서들을 폴링하여 상태를 확인하는 과정과,상기 기지국의 하위 프로세서들중 응답이 수신되는 프로세서의 상태는 정상(NORMAL)이라고 기록하고, 응답이 수신되지 않는 프로세서의 상태는 상기 프로세서 자체의 장애(F_PDWN)로 기록하는 과정과,상기 ATM 관련 프로세서들로부터 응답이 수신되지 않을 시 모든 하위 프로세서들의 상태를 상기 ATM관련 프로세서의 장애에 의한 장애(F_APRC)로 기록하는 과정을 포함하는 것을 특징으로 하는 방법.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1019990021560A KR100318921B1 (ko) | 1999-06-10 | 1999-06-10 | 이동통신시스템의 상태 관리 방법 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1019990021560A KR100318921B1 (ko) | 1999-06-10 | 1999-06-10 | 이동통신시스템의 상태 관리 방법 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20010001998A KR20010001998A (ko) | 2001-01-05 |
KR100318921B1 true KR100318921B1 (ko) | 2002-01-09 |
Family
ID=19591374
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1019990021560A KR100318921B1 (ko) | 1999-06-10 | 1999-06-10 | 이동통신시스템의 상태 관리 방법 |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR100318921B1 (ko) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100466585B1 (ko) * | 2001-12-22 | 2005-01-24 | 삼성전자주식회사 | 이동통신시스템의 제어국에서 분산된 제어 프로세서간연결 정보 일치성 보장 방법 |
-
1999
- 1999-06-10 KR KR1019990021560A patent/KR100318921B1/ko not_active IP Right Cessation
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100466585B1 (ko) * | 2001-12-22 | 2005-01-24 | 삼성전자주식회사 | 이동통신시스템의 제어국에서 분산된 제어 프로세서간연결 정보 일치성 보장 방법 |
Also Published As
Publication number | Publication date |
---|---|
KR20010001998A (ko) | 2001-01-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6038288A (en) | System and method for maintenance arbitration at a switching node | |
US6385665B1 (en) | System and method for managing faults in a data transmission system | |
JP2008092598A (ja) | 通信ネットワークを管理する方法および通信システム | |
JP2004516691A (ja) | 移動無線のメーカに依存しないomc‐nmcインタフェースを介してメーカ固有のハードウェア情報を更新する方法 | |
US7120633B1 (en) | Method and system for automated handling of alarms from a fault management system for a telecommunications network | |
KR100318921B1 (ko) | 이동통신시스템의 상태 관리 방법 | |
CN111786806B (zh) | 一种网元异常处理方法及网管系统 | |
CN112350889A (zh) | 一种监控区块链节点运行状态的系统及方法 | |
KR100257043B1 (ko) | 통신 관리 네트워크 시스템의 경보 처리 방법 | |
KR100506248B1 (ko) | 사설 교환시스템에서 링크를 진단하는 방법 | |
CN112650168A (zh) | 分布式控制系统及其动态调度资源的方法 | |
JPH09274575A (ja) | 統合システム管理方式 | |
KR100291073B1 (ko) | 이기종 교환기의 표준화된 경보 메세지 관리 방법 | |
JP2002297812A (ja) | 保守システムおよび保守方法 | |
KR960010869B1 (ko) | 분산시스팀에서의 프로세서 상태관리 및 감사 방법 | |
CN114253244B (zh) | 自动识别产品制造设备警报级别的系统及方法 | |
KR970007401B1 (ko) | 분산처리시스템에서 고장자원별 사건번호를 이용한 고장관리방법 | |
KR100282550B1 (ko) | 교환망관리 시스템에서의 이벤트 티켓 관리 장치 및 그 방법 | |
KR950005986B1 (ko) | 전전자 교환기의 프로세서 장애 검증 방법 | |
KR100366541B1 (ko) | 이동통신 교환기 시스템에서의 ass-t 구간별 신호링크경로 테스트 방법 | |
JP3424738B2 (ja) | アラーム状態管理方法及びシステム | |
KR100328182B1 (ko) | 이동통신 교환기에서 원격 경보 구동 패널 유닛의 링크경보 검출방법 | |
KR20030025088A (ko) | 이동 통신 시스템에서 우선순위에 따른 알람 관리 방법 | |
CN116841834A (zh) | 状态调节方法和装置、存储介质及电子装置 | |
KR100373335B1 (ko) | 비동기전달모드 교환시스템에서의 스위치 포트 상태관리 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant | ||
FPAY | Annual fee payment |
Payment date: 20081107 Year of fee payment: 8 |
|
LAPS | Lapse due to unpaid annual fee |