JPH04270531A - Method for extracting call processing task by purpose of distribution - Google Patents

Abstract

PURPOSE:To extract a task by replacing a task decision table by purpose of distribution when a software whose distribution function differs partially is distributed with respect to the extraction method of the distribution purpose call processing task of an exchange software. CONSTITUTION:The method is provided with a 1st task decision table 3 setting an address of a message number by a state number data of call processing and deciding a task number with the message number address, a 2nd task decision table 4, a common task macro unit 5 storing a task to be executed by the task number decided by the 1st task decision table or the 2nd task decision table, a task decision means 6 deciding a task, and a task execution means 7 to execute the task. Then the 1st and 2nd task decision tables are provided by distribution purpose and the common task macro unit 5 is used in common with the 1st and 2nd task decision tables 3, 4.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for retrieving call processing tasks for different purposes of switching software. In recent technology, when a call from an ISDN terminal is processed by an exchange, a call processing program is determined from the call status number and message number. This call processing method differs slightly depending on the country, with some methods based on CCITT specifications and others based on Bel
There are some based on lcore specifications, and call processing is performed in accordance with each country according to each specification.

FIG. 4 shows an example of a sequence of ISDN call processing according to the CCITT specifications using layer 3 messages. The diagram is I
This figure shows the relationship between messages and call states in the processing tasks of the exchange, from call origination from an SDN terminal to call release. In the figure, when a call is set up from a terminal when the exchange is in an idle state N0, the exchange enters a calling state N1 in response to a call setup message. A call setup acceptance message from the exchange is issued to the terminal, and the exchange enters the outgoing call setup state N3. A ringing message is sent from the exchange to page the terminal, and the exchange enters the call carrying state N4. When there is a response from the terminal, a response confirmation message causes the exchange to enter a busy state N10. When a disconnection request is received from a terminal, the exchange enters the disconnection request state N11 due to the disconnection message, and sends a release message to the terminal. The exchange enters the release request state N19, sets a timing and waits for a release completion message from the terminal, and if there is a release completion message within the timing, the exchange returns to the original idle state N0.

[0003] The above-mentioned call state setting messages enable the switch to perform call processing tasks. The timing for setting the call status N19 of the above release request is C.
This differs depending on the CITT specification and the Bellcore specification, and the timing and processing method must be changed depending on the specification.

0004

[Prior art] Conventional CCITT specifications and Bellcor
Sequence diagram 5 shows a comparison between the e specification and the case without call release. The figure shows the call release request state 1 from the busy state N10.
A comparison of processing methods up to 9 is shown. Figure (a) is CCITT
In the case of the specifications, Figure (b) shows a sequence diagram in the case of the Bellcore specifications.

[0005] In Figure (a), when a call is in progress in the state N10 of the exchange, when a disconnection signal is received from the terminal, the exchange sends a disconnection message in process 1, enters the disconnection request state N11, and releases the exchange. As soon as the release signal is sent to the terminal in process 2 by the message, the state becomes release request N19, the timing of T308 starts, and if the release completion signal does not come from the terminal at the first timing out of T308, process 3 The second release signal is sent to the terminal, and the second T308 timing starts.If the release completion signal does not come from the terminal even after the second T308 timing is out, the process moves to process 4. The exchange is released and returns to idle state N0.

[0006] In Figure (b), when the exchange is in state N10 during a call and there is a disconnection signal from the terminal, the exchange sends a disconnection message in process 1 and enters the disconnection request state N11, and the exchange is released. As soon as the release signal is sent to the terminal in process 2 by the message, the state becomes release request N19, the timing of T308 starts, and if the release completion signal does not come from the terminal at the first timing out of T308, process 3 The second release signal is sent to the terminal, and the second T408 timing starts. If the release completion signal does not come from the terminal even after the second T408 timing is out, the process moves to process 4. The exchange is released and returns to idle state N0.

Comparing the above two specifications, CC
In the case of ITT specifications, T3 is surrounded by dotted line A and dotted line A'.
The timing of 08 is the same, and the release request from the terminal is monitored twice at the same timing. On the other hand, Bel
In the case of lcore specification, T3 surrounded by dotted line B and dotted line C
The timings of 08 and T408 are different, and the timings of processing 3 and processing 4 are set separately and monitored. Comparing the call processing tasks of the two, in the case of figure (a), T30
The comparison is made twice with 8 execution programs at the same timing, and in the case of FIG. 8B, separate execution programs are created at different timings at T308 and T408. Therefore, messages in the call state of N19 are different, and different execution programs are processed using these different messages.

A comparison of execution procedures based on conventional task determination is shown in block configuration diagram 6. Figure (a) shows the case of CCITT specification, Figure (b) shows the case of Bellcore specification,
Each shows the area of the task macro unit on the memory based on the state number, message number, and task number. In the figure, 21 is a head table, 22 is a state number table, 23 is a task determination table, and 24 is a CCIT.
Task macro unit in case of T specification, 25 is Bell
The task macro unit in case of core specification is shown.

In the case of FIG. 3(a), the state number N19 is set by the address setting of the head table 21, and the message number T3 is set from the data of N19 of the state number table 22.
Set the address of 08, set the address of the task number from the data of T308, and set the address of the task macro unit 24.
Execute the execution program twice, A and A'.

In the case of FIG. 2B, the state number N19 is set by the address setting of the head table 21, and the message number T3 is set from the data of N19 of the state number table 22.
Set the addresses of 08 and T408 separately, and
The address of each task number is set from the data of and T408, and the execution programs of the task macro unit 25 are executed separately for B and C.

[0011]

[Problems to be Solved by the Invention] As described above, in call processing, there may be some differences in task processing depending on the purpose of provision (specification by country). In this case, conventionally, modules for each task macro unit are created depending on the purpose of provision. Replacing the task macro unit on a large scale takes time and effort, increases manufacturing man-hours during development, and causes troublesome feedback when dealing with bugs. This problem occurs because the task decision tables are the same and the task macro units are separate.

An object of the present invention is to provide task determination tables for setting task numbers based on message numbers for different purposes, and to unify task macro units and extract task units.

[0013]

[Means for Solving the Problems] A diagram of the principle configuration of the present invention is shown in FIG. In the figure, 1 is a head table that stores the address of the call processing state number table, 2 is a state number table that sets data set by the address of the head table, and tasks are determined by indexing with the state number. Set the table address. 3 is a first task determination table set by the address of the task determination table, and the task number is determined by indexing with the message number data. 4 is a second task determination table that is set based on the address of the task determination table, and another task number is determined by indexing with the message number data. 5 is a common task macro unit that stores the task to be executed according to the task number determined by the first task determination table or the second task determination table; 6 is task determination means; 7
8 indicates a task execution means, 8 indicates a state number, and 9 indicates a message number.

The first task determination table 3 and the second task determination table 4 are provided for different purposes, and the common task macro unit 5 uses the first task determination table 3.
and the second task determination table 4, the same task processing is used in common regardless of the purpose of provision, and different task processing is provided by coexisting on the common task macro unit 5. The task determination tables 3 and 4 are configured to be replaced depending on the purpose.

[0015]

[Operation] A processing flowchart for controlling the above-mentioned memory is shown in FIG. In the figure: (1) A layer 3 message is received and ISDN call processing is started. (2) Check whether the layer 3 message is normal and recognize the type of message. (3) Control execution of call processing by checking call contention and resource hunting. (4) The task determination means 6 sets a state number from the head table 1, sets a message number from the state number, searches the first task determination table 3 or second task determination table 4 from the message number, and selects a task. Determine the number. (5) The task execution means 7 executes the task corresponding to the task number from the common task macro unit 5. Processing is divided into call status and received message correspondence.

[0016]

Embodiment FIG. 3 shows a block diagram of an embodiment of the present invention. Figure (a) is for CCITT specifications, Figure (b) is for Be
The case of llcore specification is shown. In the figure, 11 is a head table, 12 is a state number table, and 13 is a CCI.
TT specification task determination table, 14 is Bellcor
In the e-specification task determination table, 15 indicates a task macro unit.

The task determination tables 13 and 14 are used interchangeably depending on the specifications provided, and the task macro unit 15 is a program execution module shared by the two specifications. The task macro unit 15 consists of a task unit group (mostly) that executes a program common to both specifications, and task units A (A'), B, and C that execute programs of specifications for different purposes.

In the case of FIG. 3A, when the state number address N19 is set by the head table 11, the message number is set by the state number table 12, and the address of T308 of timings T308 and T408 of the task determination table 13 is set. is set, the task number A is determined, and the execution program A is executed from the task macro unit 15. Furthermore, if there is no response for call release, the same task number A' is determined and execution program A' is executed for the second time, and if there is no response during that timing, call release processing is executed.

In the case of FIG. 3B, when the state number address N19 is set by the head table 11, the message number is set by the state number table 12, and the addresses at timings T308 and T408 of the task determination table 13 are set. , the task numbers are determined to be B and C, and execution program B is executed from the task macro unit 15. Furthermore, if there is no call release response, the next task number B is determined, and if there is no response during that timing, call release processing is performed.

[0020] In the case of the above diagram (a) and the case of diagram (b), the method of timing processing in the call release request is different, but all other processing methods are the same, so the task macro unit 15 is the processing unit A. Only parts (A'), B, and C are different, and most of the other processing units can be used in common. Note that task determination table 13
and 14 are small-scale modules, and can be easily replaced depending on the purpose of provision.

[0021]

[Effects of the Invention] According to the present invention, provided functions can be selected simply by replacing the task determination table, which eliminates the need to create multiple task macro units, reduces manufacturing man-hours during development, and simplifies bug handling. It is possible to aim for

[Brief explanation of the drawing]

[Figure 1] Principle configuration diagram of the present invention

[Figure 2] Processing flowchart of the present invention

[Figure 3]
Block configuration diagram of the embodiment

[Figure 4] Example of ISDN call processing sequence

[Figure 5]
Conventional call release sequence diagram

[Figure 6] Block configuration diagram of conventional example

[Explanation of symbols]

1, 11, 21 Head table 2, 12, 22 State number table 3, 4, 13, 14, 23 Task determination table 5
Common task macro unit 6 Task determination means 7 Task execution means 8 Status number 9 Message numbers 15, 24, 25 Task macro unit

Claims (1)

[Claims] 1. A head table (1) for storing the address of a call processing state number table; and a state number table (2) for setting the address of a task determination table based on the address of the head table and state number data (8). and the address and message number (9) of the task determination table.
a first task determination table (3) that determines a task number based on the address and message number of the task determination table; a second task determination table (4) that determines another task number based on the address and message number of the task determination table; a common task macro unit (5) that stores a task to be executed according to a task number determined by a determination table or a second task determination table; and a task determining means (6) that determines the task.
) and a task execution means (7) for executing the task, the first task determination table (3) and the second task determination table (4) are provided for different purposes, and the common task macro The unit (5) is commonly used for the first task determination table (3) and the second task determination table (4), and is used for the same task processing regardless of the purpose of provision, and for different task processing. A method for extracting call processing tasks by purpose of provision, characterized in that each task process is made to coexist on the common task macro unit (5), and task determination tables (3) and (4) are replaced depending on the purpose of provision.