KR20000047662A - System and method for detecting and isolating faults in a wireless network - Google Patents

Abstract

PURPOSE: A system for detecting and intercepting an error of a wireless communication network is provided to verify an operation of sub systems and be used in a transceiving terminal of a base station, to transmit prompt message to a selected sub system, to receive a message on an error from an error detection controller, and to identify at least one sub system to cause an error, responding to the received message on the error. CONSTITUTION: A system for detecting and intercepting an error of a wireless communication network, comprises an error detection controller(340) and an error interception controller(330). The error detection controller(340) transmits a prompt message operating to generate a response message from a selected sub system, to the same. The error interception controller(330) receives an error message in the selected sub system, from the error detection controller(340), and identifies at least one sub system to cause an error.

Description

SYSTEM AND METHOD FOR DETECTING AND BLOCKING WIRELESS COMMUNICATION NETWORK

TECHNICAL FIELD The present invention relates to a wireless communication network, and more particularly to a system for detecting and blocking a failure in a wireless telephone system.

Typically, various test systems are used to ensure the reliability and performance of wireless communication networks such as digital and analog telephone systems. The fault tolerance and reliability of a wireless communication system is highly dependent on how the system handles fault management. Conventional test systems generally rely on one of two: structured design or object-oriented design.

In a structured design (or "navigation") manner, fault detection and fault isolation systems are designed as a single system, sometimes referred to as fault and fault manager. Failure and shutdown managers model all subsystems they manage. In the event of a device failure, all shutdown and recovery mechanisms are activated by the failure and shutdown manager. Sometimes new devices are introduced into the system, where the fault and shutdown manager must be modified to model the new device. And if the new device requires a new blocking technology, the blocking function of the failure and blocking manager should be modified accordingly.

However, conventional structured fault management and shutdown systems have the following significant disadvantages. These structured fault management and blocking systems rely on complex alarm codes and lookup tables to detect and block faults. For example, if a signal is out of tolerance or lost, an alarm code is generated indicating that a failure has occurred. Each alert code refers to a specific entry in the lookup table. The lookup table entry for each alert code contains a list of one or more subsystems that may have caused the failure. Failure and Shutdown The administrator performs a series of tests to determine that the subsystem (s) of the suspect subsystems have caused the failure. This type of fault detection and fault interruption is complex and time consuming to delay recovery of faults.

In an object-oriented manner, each subsystem is treated as a separate entry and includes its own fault detection and fault isolation hardware and / or software. Therefore, each subsystem is responsible for its own fault detection, fault isolation and fault recovery (or normal operation maintenance mechanism). To accomplish this, each subsystem maintains a state / event table for different types of failures and performs corresponding blocking actions.

On the other hand, like structured fault management and blocking systems, object oriented fault management and blocking systems also have significant drawbacks. The use of object-oriented fault management and isolation systems in each subsystem of a number of independent subsystems results in massive redundancy of test fixtures in large systems. In addition, because the subsystem is independent of the object-oriented approach, there is little coordination between separate object-oriented fault management and blocking systems. The object-oriented fault management and blocking system can detect and block a failure in the system where the failure is located, but other subsystems dependent on the system where the failure occurred will not be able to detect the failure. As a result, the other subsystem will unnecessarily initiate a failure detection procedure because the required signal is not received from the failed subsystem.

Accordingly, there is a need in the art for improved fault detection and fault isolation systems. In particular, there is a need for a failure detection and failure blocking system that is simpler in structure than a structured design failure management and blocking system and can more quickly block failure. There is also a need for a failure detection and failure blocking system that is more comprehensive and more integrated than an object oriented failure management and blocking system.

In order to solve the above-mentioned problems of the prior art, the present invention is used in a base station transceiver of a wireless communication network, and is a test control system for verifying the operation of a plurality of subsystems of the base station transceiver. A fault detection controller capable of sending a prompt message to the selected subsystem, operable to generate a response message from the selected subsystem, and 2) a fault message indicating that a fault has occurred in the selected subsystem; It is an object of the present invention to provide a test control system comprising a fault isolation controller that receives and, in response, identifies at least one suspicious subsystem that may cause a fault.

1 illustrates an exemplary wireless communication network in accordance with one embodiment of the present invention.

2 illustrates a more detailed example base station in accordance with one embodiment of the present invention.

3 illustrates the more detailed BTS controller and test control system of FIG. 2 in accordance with an embodiment of the present invention.

4 is a flow diagram illustrating operation of the test control system of FIG. 3 in accordance with one embodiment of the present invention.

5 illustrates an exemplary redundant test control system in accordance with one embodiment of the present invention.

6 illustrates an example alarm and notification scheme for a test detection module, according to one embodiment of the invention.

<Description of Symbols for Main Parts of Drawings>

220: base station transceiver (BTS)

225-BTS Controller

226-test control system

245-Transceiver IF

250-transceiver unit

300; Subsystem

310; Configuration Manager Module

320; Call handling module

330; Fault isolation and recovery module

340; Fault detection module

350; Test manager module

According to an embodiment of the present disclosure, the failure detection controller generates a failure message when the selected subsystem fails to generate a response message in response to the prompt message.

According to another embodiment of the present invention, the fault detection controller generates a fault message when the response message indicates that a fault has occurred in the selected subsystem.

According to another embodiment of the present invention, the test control system further includes a test controller capable of testing at least one suspicious subsystem and determining whether a failure has actually occurred.

According to another embodiment of the present invention, the failure blocking controller causes the base station transceiver to prevent the selected subsystem from operating.

According to another embodiment of the present invention, the failure blocking controller causes the base station transceiver to operate the selected subsystem again in response to the determination by the test controller that no failure has occurred.

According to another embodiment of the present invention, the failure blocking controller causes the failure detection controller to resume transmission of the prompt message for the selected subsystem in response to the determination by the test controller that no failure has occurred.

According to another embodiment of the present disclosure, the failure detection controller may receive an unsolicited message indicating an operating state of the selected subsystem from the selected message.

The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that those skilled in the art may more clearly understand the following detailed description of the invention, and further features and advantages of the present invention will also be described below. . Various modifications and variations are possible in order to achieve the purposes of the invention based on the specific embodiments disclosed herein, and such equivalent constructions are also included in the spirit of the invention.

The term "controller" as used herein refers to any device, a system or part thereof, or a combination thereof, which may be implemented in hardware, firmware or software and controls at least one operation, or at least two combinations thereof. . The functionality associated with any particular controller can be centralized or distributed in one location, local or remote. Definitions for specific terms and phrases are provided herein, and the terms and phrases so defined are mostly used in the past and will be used in the future.

BRIEF DESCRIPTION OF DRAWINGS For a more clear understanding of the invention, the following detailed description is described with reference to the accompanying drawings, wherein like reference numerals are assigned to like elements.

1 and 6 and the various embodiments used to describe the principles of the present invention described below are for illustrative purposes only and do not limit the technical spirit of the present invention. Those skilled in the art will appreciate that the principles of the present invention may be practiced in any suitable configuration of wireless communications networks.

1 illustrates an example wireless communication network 100 in accordance with one embodiment of the present invention. The wireless telephony network 100 has a plurality of cell sites 121-123 each including one of the base stations BS 101, 102 or 103. The base stations 101-103 can operate to communicate with a plurality of mobile stations (MSs) 111-114. The mobile stations 111-114 can be any suitable cellular device, including conventional cellular telephones, PCS handset devices, portable computers, telemetry devices, and the like.

The dotted line in the figure indicates the rough boundary of the cell sites 121 to 123 where the base stations 101 to 103 are located. The cell site is shown in a circle for the convenience of illustration and description. The cell site may have other irregular shapes depending on the selected cell configuration and natural and artificial limitations.

In one embodiment of the present invention, the base stations 101 to 103 include a base station controller (BSC) and a base station transceiver (BTS). Base station controllers and base station transceivers are well known in the art. A base station controller is a device that manages a wireless communication resource including a base transceiver station for a specific cell in a wireless communication network. The base station transceiver includes an RF transceiver, an antenna and other electrical equipment located at each cell site. Such equipment would include air conditioning, heating, electricity supply, telephone line interface and RF transmitters and RF receivers. In order to simplify and clarify the description of the operation of the present invention, the base station transceiver end of each cell 121-123 and the base station controller associated with each base station transceiver end are collectively referred to as BS 101, 102 or 103 respectively. Is displayed.

BSs 101, 102, and 103 transmit voice and data signals between each other and between public telephone systems (not shown) via communication line 131 and mobile switching center (MSC) 140. The communication line 131 may be any suitable connection means including a T1 line, a T3 line, an optical fiber link, a network backbone connection, and the like. Mobile exchange center 140 is well known to those skilled in the art. The mobile switching center 140 is a switching device that provides service and coordination between subscribers in a wireless communication network and an external network such as a public telephone system. In some embodiments of the present invention, the communication line 131 is capable of several different data links connecting one of the base stations 101, 102, or 103 to the mobile switching center 140.

2 illustrates a more detailed example base station 101 in accordance with one embodiment of the present invention. The base station 101 includes a base station controller (BSC) 210 and a base station transceiver (BTS) 220. The base station controller and the base transceiver station have been described above with reference to FIG. 1. The BSC 210 manages resources in the cell site 121 including the BTS 220. The BTS 220 includes a BTS controller 225 that includes a test control system (TCS) 226 in accordance with the principles of the present invention. The BTS 220 includes a T1 / E1 interface (IF) 230, a thermal management system (HMS) 235, a global positioning system (GPS) 240, a transceiver interface (IF) 245, a transceiver device 250, An antenna array 255 and a data bus 260.

The BTS controller 225, which may include a motherboard of the BTS 220, controls the overall operation of the BTS 220 and interfaces with the BSC 210. The BTS controller 225 supervises the operation of the transceiver interface (IF) 245 that includes a plurality of transmitter / receiver channel cards that perform bidirectional communication in the forward and reverse channels. Depending on the system type of the base station 101, the channel component connects communication with the mobile stations in the cell 121 in time division multiplex (TDMA), frequency division multiplex (FDMA) or code division multiplex (CDMA). The transceiver IF 245 transmits a bidirectional channel signal between the T1 / E1 IF 230 and the transceiver device 250. The T1 / E1 IF 230 transmits data to and from the communication line 131, for example, a communication line 131 including a T1 line and / or an E1 line.

HMS 235 includes heating and / or cooling equipment used to control the temperature of BTS 220 under variable environmental conditions. GPS 240 receives very accurate clock data from satellites. This clock signal is used by various subsystems in the BTS 220. The data bus 260 transfers commands and data between components of the BTS 220.

The antenna array 255 transmits the forward channel signal received from the transceiver device 250 to the mobile station in the coverage area of the BS 101. The antenna array 255 also transmits the reverse channel signal received from the mobile station in the coverage area of the BS 101 to the transceiver device 250. In a preferred embodiment of the present invention, antenna array 255 is a multi-sector antenna, such as a three sector antenna, in which each antenna sector is responsible for transmitting and receiving within an arc of 120 ° of the area of interest. In addition, the transceiver device 250 may include an antenna selection device for selection among different antennas in the antenna array 255 during both transmit and receive operations.

3 illustrates a test control system 226 and a more detailed BTS controller 225 according to one embodiment of the invention. Test control system (TCS) 226 in BTS controller 225 is BS 101 including T1 / E1 IF 230, HMS 235, GPS 240, transceiver IF 245, and transceiver device 250. Can be used to test other subsystems in the module. In a preferred embodiment of the invention, the BSC 210 is one of the subsystems tested by the test control system 226. These other subsystems are collectively represented as subsystem 300 in FIG. 3.

The BTS controller 225 includes a control processor and associated memory for performing various tasks. The processor and memory in the BTS controller 225 associated with the two basic tasks are represented as the configuration management module 310 and the call processing module 320. The configuration management module 310 configures each subsystem in the BTS 220 upon initiation or reinitialization of the BTS 220. For example, configuration management module 310 may reinitialize the channel card in transceiver IF 245 to operate using a particular frequency band, time slot and / or spreading code. Similarly, configuration management module 310 may turn on HMS 235 and select environmental operating conditions of BTS 220. During the routing operation, the call processing module 320 processes the signal between the channel card of the transceiver IF 245 and the T1 / E1 IF 230 and the signal processing within the BTS 220 including the transmission of voice and data traffic. Control the transmission of voice and data traffic.

The TCS 226 may be implemented in hardware, software or a combination of hardware and software. In a preferred embodiment of the present invention, the TCS 226 includes a control processor and associated memory for performing fault detection, fault management, and fault isolation tasks. The processor and associated memory in the TCS 226 associated with the three main tasks are represented as the failure blocking and recovery module 330, the failure detection module 340, and the test manager module 350.

The main task of the fault detection module 340 is to detect faults in the subsystem 300. If a failure is detected by sending a message to the subsystem or responding, the failure detection module 340 reports the failure by notifying the failure blocking and recovery module 330 that the failure module is present. In some cases, fault isolation and recovery module 330 will attempt to replace the faulty resource in the failed subsystem with a resource of normal operation if redundant resources are available in BTS 220. To execute resource swap, fault isolation and recovery module 330 communicates with configuration manager module 310 and call processing module 320 that control the initialization, configuration, and operation of subsystem 300.

For example, if a channel card fails in the transceiver IF 245, the fault isolation and recovery module 330 will replace the failed channel card with a channel card that operates properly. To do this, the failure blocking and recovery module 330 sends a message to the configuration manager module 310 to instruct the configuration manager module 310 to disable the failed channel card and configure another channel card to replace the failed channel card. The fault isolation and recovery module 330 then stops processing the data from the failed channel card and sends a message to the call processing module 320 instructing it to process the data from the replacement channel card.

After the BTS 220 completes the resource swap procedure, the failure blocking and recovery module 330 may attempt to block and verify the presence of the failure, if necessary. The failure blocking and recovery module 330 instructs the test manager module 350 to verify a failure for the failed resource (or subsystem) reported by the failure detection module 340. If the test manager module 350 verifies a failure for the failed resource, the resource continues to stop service. However, if the failure is not verified (ie, a false alarm), the test manager module 330 notifies the failure blocking and recovery module 330 that no failure exists. The fault isolation and recovery module 330 then causes the resource to be serviced again via appropriate messages to the configuration manager module 310 and the call processing module 320. Finally, failure blocking and recovery module 330 notifies failure detection module 340 that the resource is to be serviced again so that failure detection module 340 resumes monitoring of the resource.

To prevent an infinite loop for a subsystem that is repeatedly detected as having a failure, the failure blocking and recovery module 330 maintains a counter that counts the number of failure notifications for each particular subsystem. If the selected subsystem exceeds a certain number of failures within a given period of time, the selected subsystem is permanently removed from the system (indicated as fault) and subsequent failure alerts from the selected subsystem are ignored.

The aforementioned operation of the TCS 226 is summarized in FIG. 4 illustrates a flow diagram 400 illustrating the operation of the test control system of FIG. 3 in accordance with an embodiment of the present invention. Under normal operating conditions of the BTS 220, the failure detection module 340 receives an error message from the subsystem 300 or sends a status and / or data request to the subsystem 300 as described in more detail below. In practice, the failure detection module 340 detects the failure and notifies the failure blocking and recovery module 330 that the device has failed (step 401).

Next, the failure blocking and recovery module 330 notifies the configuration manager module 310 and the call processing module 320 about the failure and attempts to immediately replace the failed device, if possible (step 402). Failure blocking and recovery module 330 also notifies test manager module 350 of the failure and instructs test manager module 350 to verify the failure (step 403). If the test manager module 350 verifies the failure, the failed device stops service, and the failure blocking and recovery module 330 notifies the failure detection module 340 to stop testing for the failed device (step 404). ). If the failure is not verified, the failure manager notifies the failure blocking and recovery module 330 that the device is operational. The fault isolation and recovery module 330 then instructs the configuration manager module 310 and the call processing module 320 to re-service the device, and resumes the failure detection module 340 to test the device. (Step 405).

In a preferred embodiment of the present invention, the TCS 226 is implemented as a pair of redundant processors that control tasks performed by the failure blocking and recovery module 330, the failure detection module 340, and the test manager module 350. Can be. This allows the TCS 226 to perform fault detection for the software controlling the software BTS controller 220 controlling the TCS 226 itself. 5 illustrates an exemplary redundant test control system 226 according to one embodiment of the invention. The redundant test control system 226 includes an associated memory 510 that stores a primary control processor 505 and a task initialization manager application (TIM program) 515. The redundant test control system 226 also includes an associated memory 525 that stores a secondary control processor 520 and a task initialization manager application (TIM program) 530. The TIM program 530 is a duplicate copy of the TIM program 515.

The primary control processor 505 is responsible for detecting failures in various software tasks executed by the TCS 226 under the control of the TIM program 515. The task 1 routine, task 2 routine, task 3 routine, and task N routine are example software tasks executed by the TCS 226. The primary control processor 505 generates an interrupt (or “ping”) that leads to acknowledgment from the selected routine among the software tasks (task 1 routine to task N routine). No response indicates that the software task is stuck in an infinite loop or broken. If the task is "pinged" and fails to respond with the appropriate confirmation, the TIM program 515 may reinitialize the software task to recover from the crash.

In addition, software failures in the TIM program 515 that cause damage in the primary control processor 505 may be detected by the secondary control processor 520. The TIM program 515 will periodically send a status message to the TIM program 530 indicating that the TIM program 515 and the primary control processor 505 are operating properly. If the status message is not received at the appropriate time, the secondary control processor 520 is responsible for controlling the test under the control of the TIM program 530 and reinitializes the primary control processor 505 and the TIM program 515. something to do. In another embodiment of the present invention, the TIM program 530 may send a "ping" message to the TIM program 515 to verify the operation of the TIM program 515 and the primary control processor 505 under its own initiative. have. If no suitable acknowledgment for the "ping" message is received, the secondary control processor 520 and the TIM program 530 are responsible for controlling the test and the primary control processor 505 and the TIM program 515. You can reinitialize it.

Fault detection and blocking is executed at a higher priority level than that executed by the TIM program 515 alone in the BTS 220. The TIM program 515 is executed at the highest priority level to ensure "sanity" of the application software in the BTS 220. Without functional application software, the fault management system becomes useless. Failure detection and blocking is implemented at the second priority level following the TIM as a mechanism for providing runtime errors and their recovery.

6 illustrates an exemplary alarm and notification method for the failure detection module 340 according to an embodiment of the present invention. Failure detection module 340 is in communication with different types of hardware and software failure detection circuits or modules implemented in each subsystem in subsystem 300. These fault detection circuits / modules include: 1) device polling circuit 605, 2) random alarm reporting circuit 610, 3) device pinging circuit 615, 4) task pinging module 620, and 5 A periodic status report circuit 625.

To perform device polling, the failure detection module often accesses device polling circuitry 605 in the subsystem to determine selected system values. For example, the failure detection module 340 may periodically poll the data register of the power supply of the BTS 220 that stores the value of the +115 VAC supply. Similarly, fault detection module 340 may poll a channel card in transceiver IF 245 to read the received signal strength indication for a particular communication channel. If the polled data is out of tolerance, the TCS 226 will perform a failure verification and failure blocking procedure.

The random alert reporting circuit 610 is an automatic device in the subsystem that detects a failure in the subsystem or is notified by the subsystem that a failure exists. The random alert report circuit 610 then sends a random alert report message regarding the subsystem failure to the fault detection circuit 340. The arbitrary alarm is treated as an interrupt by the failure detection circuit 340. In response to the interrupt, the TCS 226 performs a fault verification and fault isolation procedure.

To perform the device “pinging” procedure, the failure detection circuit 340 sends a prompt message to the device pinging circuit 615 of one of the subsystems 300 to verify the presence of the device and proper operation. do. The device pinging circuit 615 responds with a confirmation message indicating that it is performing properly or that a failure is occurring. If the acknowledgment message indicates that a failure has occurred, the TCS 226 executes a failure verification and failure blocking procedure.

The task pinging module 620 confirms that the task executed by the TCS 226 is functioning. As discussed above in connection with FIG. 5, the primary control processor 505 may interrupt (or “ping”) to derive confirmation messages from selected tasks of software tasks executed within the TCS 226 and / or subsystem 300. ") Occurs.

Some subsystems in the BTS 220, such as GPS 240, automatically generate periodic status reports via periodic status reporting circuit 625. The status report includes data and status information that is periodically sent to selected subsystems of subsystem 300 and will be monitored by failure detection circuit 340. If a periodic report is not sent at the scheduled time, the fault detection circuit 340 will generate an alarm signal, and then the TCS 226 executes the fault verification and fault isolation procedures.

The present invention provides improved fault detection and fault isolation over prior art methods. The failure detection module 340 provides for faster and more precise detection of system failure by actively monitoring the status of each subsystem without waiting for the subsystem to generate its own alarm indication. Often, during extended periods of time, the subsystem has a "potential" fault that produces no outward indication of the disaster. This is even more pronounced when the subsystem is resting when a failure occurs. In this case, the failure will not be detected until the subsystem is in use by the BTS 220. Software crashes also do not generate a visual fault indication, such as when an application program enters an infinite loop. By actively and frequently prompting devices in BTS 220, the present invention immediately detects these potential failures and, in some cases, replaces the failed device before the failure affects the performance of other subsystems or BTS 220. Can be.

In addition, the present invention improves the classic fault tree for fault isolation. In a conventional test system, the classical fault tree approach proceeded through sequential branching to eventually reach a specific fault isolation node. By collecting diagnostic data from subsystem 300 through device polling requests, device pinging requests, and periodic status reports, the TCS 226 quickly narrows down the list of suspicious devices to quickly pinpoint the exact cause of the failure. Can be deduced. This minimizes "guessing" or random testing of suspicious devices. Therefore, the failure blocking and recovery module 330, the failure detection module 340, and the failure manager module 350 determine the failure through the pinpoint matrix determination method. Once a general fault alert report is provided, a test and diagnostic procedure is initiated by fault break and recovery module 330 and fault manager module 350 to verify and block the nature of the reported fault.

In accordance with the present invention, fault detection module 340 provides for faster and more accurate detection of system failure by actively monitoring the status of each subsystem without waiting for the subsystem to generate its own alarm indication.

The above-described preferred embodiments are not intended to limit the present invention, but are intended to be illustrative, and various modifications and changes may be made without departing from the spirit of the present invention.

Claims (20)

A test control system for use in a base station transceiver of a wireless communication network and for verifying the operation of a plurality of subsystems of the base station transceiver, A failure detection controller for transmitting a prompt message to the selected subsystem, the prompt message operable to generate a response message from the selected one of the plurality of subsystems; A failure blocking controller that receives a failure message from the failure detection controller indicating that a failure has occurred in the selected subsystem and, in response, identifies at least one suspicious subsystem that may cause the failure. Characterized by a test control system. The method of claim 1, wherein the failure detection controller, And if the selected subsystem fails to generate the response message in response to the prompt message, process to generate the failure message. The method of claim 1, wherein the failure detection controller, And if the response message indicates that a failure has occurred in the selected subsystem, process to generate the failure message. The test control system of claim 1, further comprising a test controller that tests the at least one suspected subsystem and determines whether the failure actually occurred. The method of claim 4, wherein the failure blocking controller is tested, Test base station preventing the base station transceiver from operating the selected subsystem. The method of claim 5, wherein the failure blocking controller, And in response to determining by the test controller that the failure has not occurred, cause the base station transceiver to return the selected subsystem to an operational state. The method of claim 6, wherein the failure blocking controller, And in response to determining by the test controller that the failure has not occurred, cause the failure detection controller to resume transmitting the prompt message to the selected subsystem. The method of claim 1, wherein the failure detection controller, And any message indicative of an operational state of the selected subsystem may be received from the selected subsystem. In a wireless communication network; The test control system includes a plurality of base transceiver stations, wherein the at least one base transceiver station includes a plurality of subsystems and a test control system for verifying operation of the plurality of subsystems; A failure detection controller capable of sending a prompt message to the selected subsystem, the prompt message operable to generate a response message from a selected one of the plurality of subsystems; A failure blocking controller that receives a failure message from the failure detection controller indicating that a failure has occurred in the selected subsystem and, in response, identifies at least one suspicious subsystem that may cause the failure. Wireless network. The method of claim 9, wherein the failure detection controller, And generate the failure message if the selected subsystem fails to generate the response message in response to the prompt message. The method of claim 9, wherein the failure detection controller, Generate the failure message if the response message indicates that a failure has occurred in the selected subsystem. 10. The wireless communication network of claim 9, further comprising a test controller that tests the at least one suspicious subsystem and determines whether the failure actually occurred. The method of claim 12, wherein the failure blocking controller, And cause the base station transceiver to not operate the selected subsystem. The method of claim 13, wherein the failure blocking controller, In response to determining by the test controller that the failure has not occurred, causing the base station transceiver to return the selected subsystem to an operational state. The method of claim 14, wherein the failure blocking controller, In response to determining by the test controller that the failure has not occurred, causing the failure detection controller to resume transmission of the prompt message to the selected subsystem. The method of claim 9, wherein the failure detection controller, And receive any message from the selected subsystem indicative of an operating state of the selected subsystem. A method for verifying the operation of a plurality of subsystems of a base station transceiver, the base station transceiver end in a wireless communication network, Intermittently sending a prompt message to the selected subsystem, the prompt message being capable of generating a response message from a selected one of the plurality of subsystems; Determining whether a failure has occurred in the selected subsystem; Identifying at least one suspicious subsystem that may cause the failure in response to determining that the failure has occurred. The method of claim 17, wherein the determining step, Waiting a predetermined period of time to receive a response message from the selected subsystem; Determining that a failure has occurred in the selected subsystem when no response message has been received for the predetermined period of time. The method of claim 17, wherein the determining step, Receiving a response message from the selected subsystem; Determining from the response message whether a failure has occurred in the selected subsystem. The method of claim 17, Receiving from the selected subsystem an arbitrary message indicating an operating state of the selected subsystem.