KR0146643B1 - Method for controlling the senario of atm vp exchange system - Google Patents

Abstract

The present invention devises a method that can use a call scenario to implement a call processing function of an ATM VP switch, which can efficiently design and realize the call processing function. And an ATM VP exchange system and a call scenario control method having a call scenario that can effectively accommodate various additional services while minimizing the effects on existing functions by establishing a role and function of a handler to control the same. By dividing the call processing software into procedures of a certain size, it is configured as a set of procedures for each function and service type (hereinafter referred to as a call scenario), and the configuration of the software is simplified by providing a handler to control and manage this. Clear, minimal additions to existing implementations when adding new features , To facilitate the testing and tracking features, and to respond effectively in the absence of the developers, there is an effect that can easily provide new services to set up the necessary call scenarios than before.

Description

Scenario Control Method for ATM VP Switching System

1 is a block diagram of a hardware system to which the present invention is applied

2 is a schematic diagram of a software structure according to the present invention.

3 is a diagram illustrating a call scenario structure according to the present invention.

4 is a flowchart illustrating a scenario control method according to the present invention.

5 is a scenario flow diagram according to the present invention.

In the present invention, in implementing the call processing function of an Asynchronous Transfer Mode (VP) exchange, various additional services are established by establishing the type, definition, and role and function of a handler to control the call processing scenario in the ATM VP exchange. The call scenario control method of the ATM VP switching system that can effectively accommodate the.

The call processing software structure of the current communication system is implemented to sequentially perform the functions related to the input message. The complexity is increased due to the addition of various services and the addition of functions, which requires a lot of cost and effort for maintenance and testing. It is becoming. In addition, as the network becomes intelligent, it is required to provide services by network providers. With the existing call processing software structure, various problems occur according to each additional service, and the amount of software that one person must design and implement. There is a problem that it is difficult to effectively cope with the various skill levels of each individual (developer) and the absence of the developer, and there is a problem that the management and maintenance costs are high accordingly.

In order to solve the above problems, the present invention divides call processing software into procedures of a certain size and configures a set of procedures for each function and service type (hereinafter referred to as a call scenario), and controls and manages them. The software configuration is simple and clear. By adding new functions, it is easy for testing and function tracking, effectively coping with the absence of developers, and providing new services easily while minimizing the effect on existing parts when adding new functions. The purpose of the present invention is to provide a call scenario control method of ATM VP switching system.

The method of the present invention for achieving the above object is a call scenario control method applied to an ATM VP switching system having a call scenario, by dividing the call control software into a procedure of a predetermined size for each function and service type Forming a set of procedures to include a call scenario; After performing the procedure, obtaining a result to determine whether it is the end of the scenario (EOS); After execution of the second step, if the end of the scenario, the service is terminated, if not the end of the scenario terminates the execution of the currently performed procedure and increases the pointer to find out what to do next and whether the next operation is debugging mode Determining a third step; A fourth step of performing a procedure of a corresponding type according to a scenario type in a debugging mode after performing the third step, and performing a corresponding process according to each type in a debugging mode; And performing a fifth step after the fourth step, if the result value branches to another procedure or scenario, and returns if the result value does not branch.

Hereinafter, with reference to the accompanying drawings will be described an embodiment of the present invention;

FIG. 1 is a structural example of a hardware system to which the present invention is applied, FIG. 2 is a structural example of a software structure according to the present invention, and FIG. 3 is a structural example of a scenario according to the present invention. Can be.

That is, N type defines a procedure to perform call processing function, and T type means a debugging procedure, which can be easily detached at any time, and is executed only when debugging mode is set. Define the scenario to be replaced so that transition of other scenarios is possible, and EOS type represents the end of the currently defined scenario.

In addition, the data definition is implemented as follows to define the scenario and procedure definition as one complex data type to automatically distinguish whether it is a scenario or a procedure according to four types.

Also, the syntax grammar table for the scenario definition is as follows.

Call scenario extraction for input is performed in the call control process of FIG. 2 and execution of the corresponding scenario is performed in the call scenario execution process.

The scenario control handler in the call execution process has the same algorithm as in the fourth diagram. The detailed procedure is as follows.

Obtain an action list number corresponding to the scenario number corresponding to the input, that is, obtain a result after performing the procedure (41) determine whether to approve EOS (42), if the result is EOS, terminate the service; Ends the execution of one procedure and increases the pointer by grasping the contents of the next operation (43). It is determined whether the content to be executed next is debugging mode (44). If the scenario type is 'N', 'T', or 'J' type, the procedure of the type is executed and returned (45). If the 'N' and 'J' type, the contents are executed, if the 'T' type, the shift is performed, and the next type and the naming are performed (46). After the procedure is executed, if the result branched to another procedure or scenario (47), the branching is repeated (48), the scenario is changed (49), and if not, it is returned.

When a function is performed using the above algorithm, a plurality of scenario sets may be involved instead of one scenario.

In other words, a procedure may need to look at the result and branch to it. In this case, the call control engine process initially finds a new scenario number to be executed (where the procedure is to be executed next). As the number of scenarios is passed, the technique that allows the linked scenarios to find and execute the procedures sequentially is performed.

As shown in FIG. 5, it can be seen that a scenario for one input may consist of one or more scenario sets.

The present invention made as described above is to divide the call processing software into procedures of a certain size to configure a set of procedures for each type of function and service (hereinafter referred to as call scenario), by providing a handler for controlling and managing this Simple configuration of the software, minimal impact on the existing implementation when adding new functions, easy testing and function tracking, effective coping in the absence of developers, and new service by setting required call scenarios There is an effect that can be provided easier than the existing.

Claims (2)

In a call scenario control method applied to an ATM VP switching system having a call scenario, a call scenario is divided into a procedure of a predetermined size to form a set of procedures for each type of function and service to provide a call scenario. step; After performing the procedure, obtaining a result to determine whether it is the end of the scenario (EOS); After execution of the second step, if the end of the scenario, the service is terminated, if not the end of the scenario terminates the execution of the currently performed procedure and increases the pointer to find out what to do next and whether the next operation is debugging mode Determining a third step; A fourth step of performing a procedure of a corresponding type according to a scenario type in a debugging mode after performing the third step, and performing a corresponding process according to each type in a debugging mode; And a fifth step of repeating if the resultant branches to another procedure or scenario after performing the fourth step, and returning if the resultant does not branch to a call scenario of the ATM VP exchange system. Control method. The method of claim 1, wherein the call scenario is a first type that defines a procedure to perform a call processing function, and is removable as a debugging procedure and performs a call processing function only when a debugging mode is set. Call scenario of ATM VP exchange system, configured to have a second type, a third type defining a scenario to be replaced so that transition to another scenario can be made, and a fourth type indicating the end of the scenario. Control method.