KR20030054752A - Method of task managing in mobile communication exchange system - Google Patents

Abstract

PURPOSE: A method for managing a task of a mobile communication switching system is provided to check each application task state while operating a base station system processor, and to reproduce or remove a task having a fault, thereby smoothly operating the processor. CONSTITUTION: A CCP(Call Control Processor) CAFB(110) registers a callback function(S110). An application adaptive layer calls the callback function. The callback function reports fault/alarm information to the CCP CAFB(110) after transmitting a signal to a main function of a block where a removed task is included, with a parameter handed over from the application adaptive layer(S120). The main function drives and cancels a timer for periodic sensing(S130). An OAL(Operation System Adaptation Lever)/OS(Operating System)(120) transmits the signal to the main block where the corresponding task is included, and transmits the fault/alarm information corresponding to the task to a base station manager(S150).

Description

Method of task managing in mobile communication exchange system

In the present invention, a mobile communication base station system (BSS, for example, cdma2000 1X), in particular, checks the state of each application task during operation of the system processor, and reproduces or removes the corresponding task when a task fault occurs, and the processor operates smoothly. The present invention relates to a task management method of a mobile communication switching system for reporting a function failure to an operator upon task removal.

In general, as shown in FIG. 1, a mobile communication system includes a plurality of base station transceiver subsystems (BTSs) and a base station controller (BSC), and a base station for managing each base station and base station controller. Manager (BSM) and a hardware memory area for storing various data are provided by default. In addition, each base station and base station controller are provided with a plurality of subordinate processors 21 (31a to 31n). The base station and the processor 21 under the base station controller 21 (31a to 31n) manage a number of applications, such as the application for processing the call, the application for managing the subscriber address under the control of the operator.

Conventionally, when the operator of the base management station loads the code of the application program to execute a predetermined task, the entire application program is loaded in the form of one file to execute a necessary operation. That is, as shown in Figure 1, when the operator of the base management station 10 applies a predetermined control signal, the loader (Loader) which is a program that controls the execution of the entire application program of the application program and the operating system (Operating System) The code is downloaded from the base station 10 and placed in the local memory area. Therefore, under the total control of the operating system, the application program executes the operation requested by the operator of the base station 10. At this time, the conventional operating system does not separately participate in the allocation of the local memory area.

However, in the conventional method of operating an application code in a mobile communication system, a specific application may fail while an operator is operating the entire operating system, or the function blocks of a memory area may be used to test a specific application. In case of reloading or re-starting, it runs the whole application program by MMC (Man Machine Communication) method. In addition, when adding, inserting, or deleting an application program having a new function while operating the entire operating system, it may be deleted in units of tasks. Therefore, a lot of unnecessary operations are required and time-consuming to execute a predetermined function while using the entire operating system.

In the mobile communication switching system, if a hardware error occurs during system operation, the system marks the failure as an operator so that the corresponding error can be identified, and thus the system operator can appropriately deal with the corresponding error situation.

However, if a software error occurred during system operation, it could not be displayed in the same way as in the case of a hardware failure. Therefore, the method of identifying the software error during operation was to look at various software resources. Another way to deal with software errors was to install the same software in a lab and continue to run it until the same thing happened. However, even in this way, the lab environment may be different from the environment in which the actual system is serviced, so no error may occur.

Therefore, when the conventional error handling method described above is used in the mobile communication switching system, if an error occurs during operation, it is difficult to detect the error, and a large number of maintenance personnel are required to detect the error, resulting in high maintenance costs. There was a lot of trouble.

Also, transitions between states when performing call processing in a mobile switching system. For example, a process required to perform during a call in a mobile call is called a task, and is determined by call status and input information for the call according to the analysis program. These task types include tShell, tRlogind, FtpdTask, and TRoot.

If a particular task does not operate normally and is suspended between tasks, this is called a task suspend. An example of such a task suspend is to be in an active state when performing a function and to be ready when the function is finished, but not in a suspended state, that is, a state in which a task does not operate normally.

As described above, when a task suspend phenomenon occurs, a corresponding function does not perform normally, resulting in a problem of a call loss and a processor down caused by the task suspend, and also a large amount of time for the operator to directly take action. There is a problem.

The present invention has been made to solve the above-mentioned conventional problems, and checks the state of each application task during operation of the base station system processor, and when the task fault occurs, by reproducing or removing the task to operate the processor smoothly, It is an object of the present invention to provide a method of controlling a task of a mobile communication system by reporting a function failure to an operator when removing a task so that the processor can operate smoothly without the operator's control.

1 is a processor configuration diagram of a mobile communication switching system.

2 is a flowchart illustrating a task management method of a mobile communication switching system according to an exemplary embodiment of the present invention.

Task management method of a mobile communication system according to the present invention for achieving the above object,

Checking the state of each application task in the main block during processor operation of the base station management system;

Removing the task when a task fault occurs in the check result;

Reporting a function failure to a failure block upon removal of the task;

And reporting the main block to which the task from which the failure block is removed belongs as a failure state.

Preferably, the task management and status check in the main block comprises the steps of continuously managing the status of tasks running in the processor; Removing a task when a state of a specific task falls into a suspension or the like; And calling a callback function registered in the failing block, sending a signal to a main function of a block to which the removed task belongs with the corresponding parameter, and transmitting the signal to the base station management station.

Preferably, when the signal from the block of failure in the main function including the removed task, and taking action of whether or not to create the task again according to the importance of the task.

Preferably, the task may call in advance by classifying the class according to the task removal according to the importance of the task when using the creation primitive, and determine whether to report or restart according to the class.

Preferably, the class at the time of task removal is a first class not reported at the time of task removal, the second class reported as a callback function at the time of task removal, and the third class in which a processor must be restarted by calling a restart primitive in function operation. Characterized in that it comprises a.

Preferably, when reported to the operator of the base station management station, it is characterized in that the task failure message provides a result of the suspended specific task in a particular application block.

A task management method of the mobile communication system as described above will be described with reference to FIG. 2.

Referring to FIG. 2, a call control processor (CCP) is a main processor of a base station controller (BSC) and functions as a software for processing a call processing of a mobile subscriber. When a subscriber originates a call, it receives the message from the base station and sets up the subscriber's call and hands it off.

The function of the call control processor can be largely divided into call processing and maintenance functions (OAMs), and the maintenance functions can be divided into statuses, failures, statistics, tests, and functions of the corresponding processors. One software block that performs each of these functions is the call control processor failure block. In other words, the CCP Alarm Fault Block (CAFB) 110 is a fault handling software block of the call processing processor that informs the operator when the state of the call control processor changes from normal operation to non-normal operation. Giving functions and the like.

In addition, in the operating system adaptation layer (OAL) and operating system (OS) (eg, VxWorks) block 120, the operating system adaptation layer is a TCP as a common interface between the operating system (OS) and the application software. Software that provides / IP and HDLC solutions. This layer is attached to the rating system and compiled.

The base station management station (BSM) is a device in which operators operating a mobile communication system download software to hardware such as a base station, a base station controller, and detect a state.

In detail, the failure block 110 of the call processing processor registers and implements a callback function to transmit a primitive signal that registers the callback function to the main block to which the task belongs. do. In this case, the callback function is an example of a function including a block name to which a task belongs and a task identifier when a task suspended task exists in the call control processor. Also, the callback function registration message (kc_reglog ()) is kc_sendsig between primitives used when a message is sent to another processor, and kc_create is used when creating a task.

The main application block then determines a task to process the signal from the faulty block. At this time, when using task creation primitive, classify task class and call primitive. When task suspend occurs, three kinds are classified according to each task class.

Class 1: not reported when removing a task

Class 2: Reported as callback function on task removal

Class 3: Call kc_restart () after 10 seconds when removing task

In other words, depending on the importance of the task of each application, when a suspended task occurs, only the non-critical task is removed and not reported as a failure block, or the callback function is called, or the kc_restart primitive is called during function operation. It is called in three different ways to restart the processor.

Then, the application adaptation layer of each processor continuously manages the states of tasks running in the processor. That is, all tasks running in each application main block are sensed, and when a state of a specific task falls into a suspension or the like, the corresponding task is removed.

In addition, the application adaptation layer calls a callback function registered with the application adaptation layer in the failure block 110. This callback function sends a signal to the main function of the block to which the removed task belongs with the parameter passed from the application adaptation layer and reports fault information (Fault / Alarm) to the faulty block (S120).

The main function of the block including the removed task takes actions such as generating a task according to the importance of the task when a signal comes from the faulty block.

At this time, it drives and releases the timer for periodic detection (S130).

Then, the call control processor failure block 120 transmits a signal to the main block to which the task belongs to transmits the failure information corresponding to the removed task to the base station manager (S150). At this time, the operator can see which block the task is suspended in the fault message displayed in the base station management station window. The operator can automatically remove the task without restarting the processor to execute the task again. The system operator can detect application tasks.

In addition, by classifying a task class in advance when creating a task of each block, it is possible to determine which primitives the task will call upon suspension.

Meanwhile, another embodiment may be applicable to all processors that load an application, and by determining the action to be taken according to the class of the task, the call loss and the processor down due to the task suspension may be prevented.

In an embodiment, the task audit function is limited to an application task primarily, but may be applied to an operating system task when primitive support is possible at the operating system level.

In addition, by sending error statistics for each subsystem, you can see how many errors occur in which systems.

As described above, according to the task management method of the mobile communication switching system according to the present invention, in addition to monitoring the tasks running in each processor, by separating the respective execution procedure according to the task class when the application task is suspended. As a result, the system operator can take action on the processor itself without taking action when a task fails.

In addition, by adding verification function for task suspend occurring randomly in the system and adding fault reporting function, it is possible for the operator to check which processor has a large number of task suspends and take quick action on bad processor. It has the effect of providing data.

It also has the effect of being extended to other operating system tasks that can monitor and report tasks and take automatic actions.

Claims (6)

Checking the state of each application task in the main block during processor operation of the base station management system; Removing the task when a task fault occurs in the check result; Reporting a function failure to a failure block upon removal of the task; And reporting the main block to which the task from which the failure block is removed belongs as a failure state. The method of claim 1, Task management and status check in the main block comprises the steps of continuously managing the status of the tasks running in the processor; Removing a task when a state of a specific task falls into a suspension or the like; Calling a callback function registered in the block, transmitting a signal to a main function of a block to which the removed task belongs with the corresponding parameter, and transmitting the signal to a base station management station; How to manage. The method of claim 2, And when the signal is received from the block in the main function including the removed task, taking an action of whether to generate the task again according to the importance of the task. The method of claim 1, The task may call in advance by classifying the class according to the removal of the task according to the importance of the task when using the generation primitive, and determine whether to report or restart according to the class. The method of claim 4, wherein The class at the time of task removal includes a first class not reported at the time of task removal, a second class reported as a callback function at the time of task removal, and a third class that must restart the processor by calling a restart primitive in function operation. Task management method of a mobile communication switching system, characterized in that. The method of claim 1, And providing a result of a specific task suspended in a specific application block as a task failure message when reported to an operator of the base station management station.