KR100810249B1 - Method for processing message from a user interface manager in a base station manager - Google Patents

Abstract

The present invention relates to a method of processing a message from a user interface unit (UIM) in a base station manager that manages and maintains a plurality of base stations and base station controllers. Checking whether the message is a Man Machine Command related message, registering a timer if the message is an MMC related message from the user interface unit, and requesting the MMC to the plurality of base stations and base station controllers; Generating a thread to process MMC results when receiving an MMC from the plurality of base stations and base station controllers.

Thread, base station management

Description

METHODO FOR PROCESSING MESSAGE FROM A USER INTERFACE MANAGER IN A BASE STATION MANAGER}             

1 is a block diagram of a general mobile communication system;

2 is a view showing the internal structure of the STM according to the present invention,

3 is a diagram illustrating a thread creation process in an STM according to the present invention.

The present invention relates to a method of operating and maintaining a communication system, and more particularly, to a method of processing a message from a user interface unit in a base station manager.

1 is a block diagram of a general mobile communication system. As shown in FIG. 1, a mobile communication system includes a base station transceiver subsystem (BTS) 1 that is in charge of a wireless connection with a mobile station, and a base station controller (BSC) that manages the BTS 1. (2), a Mobile Switching Center (MSC) 3 for exchanging mobile communication service signals from the BSC 2 to provide mobile communication services, and a BTS 1 and a BSC 2; A base station manager (BSM) 4 which manages and maintains operation. In order to manage and maintain such a mobile communication system, an operator accesses the BSM 4 through a UIM (User Interface Manager) and inputs a command for operation processing, and inputs the command of the BSM 4. The software handles and performs operational management and maintenance functions. As such, the BSM 4 operates on a work system as a console system that provides an operator with a system interface to perform operations and maintenance on BSC, BTS, Global ATM Switch Network (GAN), etc., which are components of the cdma2000 network. do. In BSM, a command that an operator performs to obtain status of BSC, BTS, and GAN systems, that is, a command (COMMAND) is called a MMC (Man Machine Command). UIM (User Interface Manager) uses this MMC to enable information input and output between the operator and the system. The operator can unload the MMC to be executed on the system through the graphical user interface provided by the UIM, and can view the result of executing the command from the system.

The application block of the BSM communicates with the UIM through a call control management (CCM) block. The CCM block transmits the command data description (CDD) files to the UIM with which the connection is established to enable a command tree. The CCM block receives the operator's command from the connected UIM and delivers the command to other application blocks operating in the BSM. In addition, the CCM block transmits command execution results, system messages, and faults and alarms detected by the system to the corresponding UIM. MMCs processed in BSM application blocks are divided into two types: MULTI MMC and SINGLE MMC. The MULTI MMC may continue to perform MMC continuously. In other words, when the operator provides the MMC continuously, the UIM directly delivers the MMC to the application block. However, SINGLE MMC does not deliver the MMC to the application block if the operator provides the MMC continuously and the previously executed MMC is not completed. In general, MMC must be able to perform MULTI JOB, so each application block of BSM should be able to execute it at the same time. SINGLE MMC is used when a heavy load is placed on a lower block or it is difficult to execute concurrently with continuous instruction execution.

On the other hand, BSM's Status Manager (STM) block manages the system's status in real time and provides the operator with the ability to query the system's status. There are two ways to query the status of such a system. In the first method, the status can be confirmed through graphic information reflecting the faults and alarms detected in the system in real time. The second method is to run the MMC to know the state of the system. Both of these methods implement UIM and interface identically with SOCKET communication. Graphical information is provided from the STM to the UIM at regular intervals, and the MMC is performed only when an operator commands. Also, the STM block has a SINGLE task (TASK) structure, not a structure that can perform MULTI JOB internally. In the structure of STM and UIM, there is no problem when the JOB execution time is short when performing MMC. However, when the JOB execution time is long or when waiting for a response to a plurality of lower blocks, the MULTI MMC cannot be processed normally. In order to solve this problem, the MMC, which has long JOB performance and affects the load of the system, is minimized by SINGLE MMC. However, multiple MULTI MMCs should be able to run while SINGLE MMC is running. For example, in the case of the MTS on the BTS side, the DIS-CALL-CNT (display call count) command, which displays the number of calls, requires a long JOB and receives a response from all normal BCPs connected to one BSC. In this case, if a different MMC is performed during string formatting to receive responses from several BCPs, the result of the command execution is broken or delayed. In addition, although it is an abnormal case, a problem occurs during MMC processing, and if it is delayed and no longer executes the JOB, other functions such as a function for providing graphic information of the UIM and a processor polling function occur. In other words, if any one of the functions performed by the STM fails, the STM will not perform all the functions properly.

Therefore, an object of the present invention is to implement the MMC task by solving the problem that the result is broken or delayed when the task execution time is long when the multi- and single MMC is performed simultaneously by implementing the internal structure of the STM of the BSM from a single task to a multi-task environment. The present invention provides a message processing method in the BSM with improved performance.

In order to achieve the above object, the present invention provides a method for processing a message from a user interface unit (UIM) in a base station management unit that manages and maintains a plurality of base stations and base station controllers. Checking whether the message is a graphic message or a MMC (Man Machine Command) message; and if the message from the received user interface is an MMC message, a timer is registered and the MMC is transmitted to the plurality of base stations and the base station controller. Requesting and generating a thread for processing the MMC result when the requested MMC is received from the plurality of base stations and the base station controller.

DETAILED DESCRIPTION A detailed description of preferred embodiments of the present invention will now be described with reference to the accompanying drawings. It should be noted that reference numerals and like elements among the drawings are denoted by the same reference numerals and symbols as much as possible even though they are shown in different drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

The STM block comprehensively manages the states of the processors and the state of the link, parses the instruction string from the UIM when MMC is executed, delivers MMC-related messages to each subsystem, and analyzes the results of instruction execution received from each subsystem. To create the output string. In addition, the STM block constructs an output string to be displayed in the message window and delivers it to a file. The STM monitors the status of the system's processor, links, and devices, and the STM must provide operators with the information they need in real time and provide it on demand.                     

This STM internal structure was previously a SINGLE task, but in the present invention, it consists of three threads (THREAD) for each function. A thread is a unit program unit that is smaller than a process or task, and is a unit of scheduling of an STM, regardless of resource allocation such as an input / output device, and is executed without being interrupted by an interrupt function. . One task can be performed by being divided into several threads. The first thread processes the message coming from the UIM. The second thread periodically provides the information required by the UIM. The third thread handles processor polling and MMC. In the present invention, the functions of the STM are largely divided into parts for providing UIM related information and parts for processor polling and MMC processing.

On the other hand, the MMC processed by the STM is largely divided into three. Firstly, when the STM reports the result of MMC received from the UIM. Secondly, when the STM requests the lower blocks such as BMP (BSC Main Processor) and BCP (BTS Control Processor). This is the case where the result is requested from the lower blocks of BMP and BCP, and the result is collected and informed. In all of these cases, the present invention does not affect the processing of other MMCs without affecting the processing of other MMCs even when MMC JOB execution is long or waiting for a response to several sub-blocks by using a thread to compensate for the problem of the existing MMC processing. Allow MMCs to be processed.

2 is a view showing the internal structure of the STM according to the present invention.

In FIG. 2, the MAIN thread 100 initially generates the UIM message processing thread 200, the UIM graphic information processing thread 300, and the polling and MMC processing thread 400. The main thread 100 periodically monitors the created thread and regenerates the thread if it is abnormal. The main thread 100 periodically increases the value of the GLOBAL variable called uim_alive within each thread to determine that the thread is abnormal, and compares old and new of uim_alive to delete the thread if the value has not changed for a certain period of time. And recreate it.

The UIM message processing thread 200 receives and parses a graphic information request and an MMC request message from the UIM and processes the message. When the message received from the UIM is a graphic information request message, the UIM message processing thread 200 changes a related GLOBAL variable such as a requested BSM ID and a graphic window ID. The UIM graphic information processing thread 300 requests the graphic information to the lower block through the STM_UIM_MBOX 300 according to the changed GLOBAL variable in the state UI global data buffer 20 and sends the information received from the target to the UIM.

If the message received from the UIM is an MMC request message, the UIM message processing thread 200 processes the message according to the type of MMC. In the case of informing the information managed by the first STM, the UIM message processing thread 200 registers the timer ID in the timer table 30 and causes the polling and MMC processing thread 400 to notify the UIM through the MMC transmission thread. Accordingly, the polling and MMC processing thread 400 generates the MMC transmission thread 500 and registers the thread ID in a local table (LOCAL TABLE) such as the timer table 30. The polling and MMC processing thread 400 normally deletes the timer after sending information to the UIM. If the MMC transfer thread 500 fails to send data to the UIM normally and there is a delay, a time out occurs. The polling and MMC processing thread 400 searches for a thread ID with a timer ID from a local table and deletes the thread. Then send an error message to the UIM.

Secondly, if the message received from the UIM is an MMC request message and informs the lower block of the result, the UIM message processing thread 200 registers the timer ID in the local table and requests the lower block through the STM_MBOX 40. When the response comes from the lower block, it causes the polling and MMC processing thread 400 to notify the UIM through the MMC transmission thread 500. Accordingly, the polling and MMC processing thread 400 creates a thread and registers the thread ID in the local table. The polling and MMC processing thread 400 then cancels the timer after sending data to the UIM normally. At this time, if there is no response from the lower block or the MMC processing thread 400 receives a response or delays from the MMC transmission thread 500, the polling and MMC processing thread 400 retrieves the thread ID with the timer ID from the local table, deletes the thread, and then sends an error message to the UIM. send.

The third is a case in which the STM requests a result from a plurality of sub-blocks and informs them of the aggregation. The UIM message processing thread 200 registers a timer ID, requests a request from several sub-blocks, and if a response is received, the polling and MMC processing thread 400. Collects information. The polling and MMC processing thread 400 informs the UIM of the information through the MMC transmission thread 500 when the response is completed from all lower blocks. In this case, when there is no response or timeout occurs, the polling and MMC processing thread 400 retrieves the thread ID using the timer ID from the local table, deletes the thread, and sends an error message to the UIM.                     

3 is a diagram illustrating a thread creation process in an STM according to the present invention.

2 and 3, the STM of the BSM first receives an operator command and graphic related message from the UIM in step 610. The STM then checks in step 620 whether the message received from the UIM is a graphic related message or an MMC. If the message received from the UIM is a graphic related message, the STM updates state UI information of the state UI global data buffer 20 in step 630. Accordingly, in step 640, the UIM graphic information processing thread 300 requests the graphic information to the lower block through the STM_UIM_MBOX 300 according to the changed GLOBAL variable in the state UI Global data buffer 20 and sends the information received from the target to the UIM. send.

Meanwhile, if the message received from the UIM is an MMC related message, the STM registers a timer in the MMC timer table 30 in step 650. The STM then requests the MMC from the lower block in step 660 and receives the result of the MMC requested in step 670 from the lower block. The STM then creates a thread that processed the MMC result in step 680. Accordingly, the MMC thread generated in step 690 sends the MMC results to the UIM.

As such, the present invention allows the internal structure of the STM to create a thread for each function so that when multiple MMCs are executed at the same time, the present invention can be efficiently processed and the result report is not delayed.

As described above, the present invention solves the problem of delayed reporting of MMC results by efficiently processing when multiple MMCs are executed simultaneously by creating threads for each function of the internal structure of the STM. In other words, the present invention creates a thread for each function, so even if one thread fails to perform a function due to an abnormal phenomenon, another function can be executed and since the main thread monitors each thread, the abnormal thread is canceled after a certain time. It can be recreated and restored to perform the function. As a result, the present invention provides accurate information in real time when the operator inquires the status in the system, and if the failure state of the system occurs, it is possible to accurately grasp and quickly take action.

Claims (3)

A method of processing a message from a user interface unit (UIM) in a base station manager that manages and maintains a plurality of base stations and a base station controller, Checking whether the message is a graphic message or a MMC message when the message is received from the user interface; Registering a timer and requesting the MMC to the plurality of base stations and the base station controller if the message from the received user interface unit is the MMC related message; And generating a thread to process the MMC result when the requested MMC is received from the plurality of base stations and the base station controller. The message processing method of claim 1, wherein the thread transmits the MMC result to the user interface unit. 3. The method of claim 2, further comprising: if the timer times out before the thread sends the MMC result to the user interface, deleting the thread and transmitting an error message to the user interface. Including message handling method.

Images