KR0123253B1 - Method for sorting the call scenarios in atm system - Google Patents

Abstract

The call scenario extracting method in an ATM exchange comprises the steps of: determining whether received information is at a blocking state; if at the blocking state, transmitting a service blocking message; if at a service implementing state, determining whether a received message from a TRCT(TRansaction Control Table) is valid; if invalid message, transmitting a service blocking message; if valid message, determining whether received information is processed; if not processed, recording the information on a multi processing control table and starting a call process processor.

Description

ATM exchange call scenario extraction method

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

2 is a structure diagram of a call control software in accordance with the present invention.

3 is a configuration diagram of a drive table for call control according to the present invention.

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

5 is a block diagram of a double call progress control table according to the present invention.

The present invention provides a method for extracting an ATM exchange call scenario that can be performed by a table driving method for selecting a protocol processing and execution function that can provide an independent call processing function when a call connection establishment request is required in an ATM (Asynchronous Transfer Mode) exchange. It is about.

At present, due to unspecified factors and technical problems, ATM (Asynchronous Transfer Mode) exchangers are not fully commercialized and developed in the world, and there are many difficulties in development and realization.

However, it is clear that the advent of the Broadband Intergrated Service Digital Network (B-ISDN) era and the development of an Asynchronous Transfer Mode (ATM) exchange, a key element thereof, are coming to reality.

Nevertheless, the types of services and their demand forecasts are uncertain, and the software structure that is used to design the nearly-deterministic functions as in the past to make an electronic switchboard has a lot of undetermined elements, such as an ATM switch, and a specification that may change over time. At that time, it can be difficult to apply to the system easily.

In order to solve this problem, a new type of software architecture is inevitably required from the past. Thus, in order to accommodate various types of service control protocols, the software structure is substantially functional in order to accommodate standardized specification of steps, complexity of functions to be added, and various kinds of service control protocols. It should be easy to add and delete, and should be researched and developed to accommodate one call processing function independent of each protocol. This is a software architecture that is flexible in the addition and deletion of functions and protocols, and in which the test and error propagation can be localized and minimized. In addition, the developed system software plays a role in reducing development and system maintenance costs, and the system must be implemented to provide various ATM (Asynchronous Transfer Mode) services to users in a timely manner.

The present invention devised to meet the above needs can provide a protocol independent call processing function among software architecture requirements, that is, call processing once implemented various protocols that can be used in ATM VP exchanges. It is an object of the present invention to provide a method for extracting an ATM exchange call scenario using a table driving method that can extract related call processing information using a protocol transaction table so that the function can be reused.

In order to achieve the above object, the present invention provides a first step of receiving a status of a virtual path identifier (VPI) from a database when receiving a message and determining whether the received information is in a state in which a service cannot be performed. After performing the step, if the service can not be performed, the second step of transmitting and ending the service unavailable message: After performing the first step, if the service is available, after receiving a message required to perform a call from the call processing transaction table (TRCT) A third step of examining whether a message is valid; After performing the third step, if the message is an invalid message, the service is terminated after transmitting the service unavailable message. If the message is valid, the fourth step of determining whether the received information is being performed: After performing the fourth step, and terminates after transmitting the service unavailable message, and if it is not performed, the fifth step of starting and returning the call execution processor after recording in the dual performance control table.

A scenario is defined as a set of function pieces to be executed according to one external input by dividing the part that handles the call processing function into several pieces. This algorithm designed the data structure and driving algorithm to extract these scenarios by driving the transaction table.

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

1 is a block diagram of a hardware system of an ATM switch to which the present invention is applied.

Electronic switchboards are divided into two sub-systems, which are equipped with subscriber and trunk interfaces, time system (T-SWITH), and various signaling devices, and are responsible for most call processing and self-maintenance functions. ALS (ATM local switching subsystem), which performs overall maintenance of the system, and translates the number of ISNM (Interconnection Switch-Network Module) and call processing functions that perform switch functions with a time space time (TST) switch structure It consists of ACS (ATMCentral Switching subsystem) in charge of functions.

When the call connection request message is received from the User Network Interface (UNI), the Call Processing Part (CPP), which is responsible for the call processing function existing in the ATM Local Switching Subsystem (ALS), is sent to establish a physical path. It configures hardware channels of the side Subscriber Interface Module (SIM) and the Link Interface Module (LIM), and also the receiving Subscriber Interface Module (SIM) or the Link Interface Module (TIM). The hardware channel of the Trunk Interface Module (LIM) and the Link Interface Module (LIM) is set to provide the requested service through the TST switch ISNM (Interconnection Switch Network Module). The present invention is embedded in a Call Processing Part (CPP) located in an ATM local switching subsystem (ALS), and is responsible for extracting a call scenario during a call processing process in charge of the entire process of call setup and call release.

Referring to the call control software structure of the present invention through FIG. 2, the table-driven protocol control algorithm configures a call control engine processor for call execution, and includes a call processing transaction table (TRCT) and a call processing transaction table (TRCT). Construct a Multi Processing Control Table (MPCT). The call execution process is defined as one that can adapt to the protocol applied in the ATM VP switch, and is designed to put as many calls as the copy is requested. That is, a call execution processor for call execution is formed in one and the same structure, and a processor for performing a service for each service request is formed. When the service is completed, the processor is destroyed. In the above process, when a service connection request is received, a message for performing a call is received from MMC (Man Machine Communication) in a call processing part (CPP), and the call control engine processor extracts a scenario required to perform a call using a table of TRCT. Provide services in the call execution process.

Referring to FIG. 3, the structure of TRCT is configured by a call transition state and determines whether or not a message can be input for each state, and is changed after performing a scenario number and a message processing function according to an input message. Configured to know the next state.

For example, when the AAA message is received, the message is allowed. After executing scenario 1234, the next callstate is activated. Next, when BBB is input, it is not allowed. After executing scenario 5678, the next state is idle.

There are two types of messages: incoming external messages for external call processing and internal messages required for the function implementation in the call processing process. Only external messages are defined as input to the table, and the current call state is also input.

The TRCT outputs a scenario name to be executed, a call state to be transitioned after the scenario execution, and an output message.

Referring to the control flow diagram of the call control engine process through FIG. 4, first, when a message is received (1), a status of the VPI is received from a database already established (2) Determine if blocking is possible (3) If it is not possible, send and terminate the service unavailable message (10). If the service is available, receive the message necessary to perform the call from TRCT (4) (5) If the message is invalid, send the service out message and exit (10). If the message is valid, check the current service status and scenario number. After receiving the output message (6), it is determined whether the currently received information is currently being performed or not (7). Perform control tables to (MPCT Multi Processing Control Table) start after (8) of the processor to perform the recording and return (9).

5 is a configuration diagram of a dual processing control table (MPCT) for controlling dual call progress and configures a table for each subscriber interface module (SIM) embedded in an ATM local switching subsystem (ALS). The maximum size of the table is 226, which is the number of VPCIs that one Subscriber Interface Module (SIM) can accommodate, and each configuration item is a VPCI number to which a call can be connected and whether or not it is receiving call service. Consists of processing for display.

The method for extracting a call scenario configured and operated as described above allows the call processing engine table to efficiently control the pieces of functions constituting each scenario by allowing call processing functions to be independent of various protocols. When added (TRCT), software reusability can be increased, and the addition of undetermined functions to the system can be implemented with minimal effect on the implemented system.

Claims (2)

Compose a call processing transaction table (TRCT) and a dual processing control table (MPCT) to receive a message to perform a service connection request call from an external MMC (Man Machine Communication). Call control engine process for extracting scenarios required for call execution using a table: A call execution process that is formed in the same structure for call execution, performs a service every time a service is required, and expires when service execution is completed: and the call execution process And a subscriber interface module control unit connected to the call control engine process. When receiving a message in the transaction table control method, a status of a VPI (Virtual Path Identifier) is received from a database. Information received does not perform service Step 1: Determining whether or not the state: After performing the first step, if the service can not be performed, the second step of transmitting and ending the service unavailable message: After performing the first step, if the service is available, call processing transaction table (TRCT) After receiving the message required to perform the call from the third step to check whether the received message is valid: After performing the third step, if the message is an invalid message (Invalid) message, the service is terminated after sending a service unavailable message, Is a valid state, the fourth step of determining whether the received information is being performed; and after the fourth step is performed, the service is terminated after transmitting a service unavailable message. And a fifth step of starting and returning to the ATM switch scenario extraction method. The method of claim 1, wherein in the fifth step, the dual performance control table configures a table for each subscriber interface module (SIM) embedded in an ATM local switching subsystem (ALS), and includes one subscriber interface module (SIM). : The number of VPCIs (256) that Subscriber Interface Module can accommodate is the maximum size of the table, and each configuration item is composed of a VPCI number to which a call can be connected and an indication of whether a call is being received or not. ATM Switch Call Scenario Extraction Method.