JPH04334195A - Call control system - Google Patents

Abstract

PURPOSE:To attain the start of other feature not causing mutual interference from the state of executing an optional feature with respect to the call control system in an intelligent network. CONSTITUTION:An interface device 2 connecting between a service control node 1 and a transmission network 3 is provided with a call view management data table 8 storing management information to manage the connection state between resources for each call and a feature view management data table 9 storing the above management information during execution for each feature. The contention of the resource utilization is detected and an order 6 from the service control node 1 to a trigger event 5 is converted into a task start instruction controlling an exchange node 4 to implement the call control.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a call control system in which call control in an intelligent network is performed centrally from a service control node. In an intelligent network (hereinafter abbreviated as "IN"), by providing a standard interface between a service control node and a transmission network, a logical Since it is possible to develop features that are services, it is possible to introduce services early, support multi-vendor exchange nodes, and facilitate maintenance. In such an IN, it is necessary to increase the independence of features for early development of features.

0002

2. Description of the Related Art A conventional IN proposed previously includes, for example, a service control node 81, an interface device 82, and a transmission network 83, as shown in FIG.
The transmission network 83 includes, for example, a plurality of switching nodes 84 and a plurality of subscribers 89, 90 accommodated in the terminal switching node, etc., and is capable of transmitting multimedia such as voice and various image information. Events 87 from the transmission network 83 associated with various service requests from subscribers are added to the service control node 81 as standardized trigger events 85 by the interface device 82, and the service control node 8
1 sends out an order 86 based on a call model that virtualizes the connection state between subscribers. Interface device 82
translates this order 86 and sends a task activation command 88 to the transmission network 83.

[0003] The service control node 81 centrally controls the provision of various services, and the call model used in this case simply defines the connection state between subscribers as a leg of a logical communication path. Some methods are known, such as those in which the legs are connected via connection points, and those in which the legs are connected via connection points to easily represent a connection state such as a three-way call.

0004

[Problems to be Solved by the Invention] Conventional IN call control is performed on a feature-by-feature basis, and in what form resources are shared among multiple features in one IN call. However, there is no control over whether or not the Therefore, it is difficult to judge mutual influences between features, and therefore, there is a drawback that it is difficult to detect resource usage conflicts between a plurality of features.

[0005] Furthermore, in the conventional example, since it is assumed that the feature is activated from the state of a two-party conversation, it is assumed that the feature is activated from the state where a feature other than the two-party interconnection service is being executed. The disadvantage was that it was difficult to An object of the present invention is to enable activation of other features that do not cause mutual interference from a state in which any feature is being executed.

[0006]

[Means for Solving the Problems] The call control method of the present invention includes:
A service control node that has an interface device 2 that connects a service control node 1 and a transmission network 3 that includes an arbitrary number of exchange nodes 4, and that describes an order 6 that is activated by a trigger event 5 from this interface device 2. 1
In an intelligent network call control method that executes a feature program, the interface device 2 has a call view management data table 8 that stores management information for managing the connection status between resources for each call, and a call view management data table 8 that stores management information for managing the connection status between resources, and Based on the data in the feature view management data table 9 that stores the management information of It is something.

[0007] In addition, the resource usage state and inter-resource connection state in each feature are managed by a call model, and this call model is used to manage the communication entity leg that connects the communication entity and the connection point, and the communication entity leg that connects the communication entity and the connection point, and the connection state between each feature. It is composed of feature legs that connect connection points that transmit main information and transmit events that occur within a parent feature to child features.

[0008] Also, in the interface device 2, a conflict in resource usage between features is detected based on data in the call view management data table 8, feature view management data table 9, and information from feature legs. It is.

[0009]

[Operation] The call view management data table 8 is a resource list for call views that represents the connection status between all resources regarding the entire IN call and the resource control range of each feature (a collection of resources controlled by a certain feature). The feature view management data table 9 stores resource status information regarding feature views of information representing connection status between resources within one feature, flow of main information, and leg status.

Events in the exchange node 4 are notified to the interface device 2, and the interface device 2 refers to the call view management data table 8 and determines the instance of the feature program currently controlling the leg in the call view. It is checked, converted into a trigger event 5 on the leg in the call view, and notified to the service control node 1. The service control node 1 interprets the feature program corresponding to the trigger event 5 and sends an order 6 to the interface device 2. The interface device 2 refers to the call view management data table 8, converts the orders into orders for resources in the call view, checks whether or not there are any conflicts between the orders, and selects a set of orders that do not cause any conflicts. Based on this set of orders, the data in the call view management data table 8 and the feature view management data table 9 are updated. and,
This set of orders is converted into a task activation command and sent to the switching node 4, and the switching node 4 performs call control by performing state transition according to the task activation command.

[0011] Furthermore, a communication path (leg) in the call model is constructed using a communication entity leg between a communication entity and a connection point, and a feature leg between connection points. The latter is a logical connection relationship between features, and represents the flow of main information between features. Also, events that occur within the parent feature are transmitted to the child features.

[0012] Also, based on data in the call view management data table 8 and feature view management data table 9 of the interface device 2, and information from feature legs, resources in one IN call can be distributed between multiple features. Since it is possible to determine how a feature will be shared, conflicts in resource usage can be prevented and other features can be started from a state where any feature is being executed.

[0013]

[Embodiment] FIG. 2 is an explanatory diagram of an embodiment of the present invention.
is a service control node, 2 is an interface device, 3 is a transmission network, 4 is an exchange node, 5 is a trigger event, 6 is an order, 7 is a feature program execution environment, 8 is a call view management data table, 9 is feature view management data Table 10 is an IN call state management device 11
12 is a state data translation device; 13 is a basic call processing translation device; 14 is an event; 15 is a feature state management device;
is a task activation instruction, 16 is a feature program, 1
7 is a feature interaction control device. The feature view management data table 9 and the feature state management device 11 are provided for different feature programs 16, respectively.

In the present invention, an IN (intelligent network) call is made during a non-IN call.
It refers to a series of processing units until the execution of all features that are directly or indirectly related to the subscriber who started the feature is completed, and also refers to a series of processing units until the execution of all features that are directly or indirectly related to the subscriber who activated the feature is completed.Also, it refers to a series of processing units until the execution of all features that are directly or indirectly related to the subscriber who started the feature is completed. When any subscriber activates another feature, the feature that is executed first is called the parent feature, and the feature that is executed later is called the child feature. Also, the period from when a certain subscriber activates an IN feature until the execution of the feature itself or all of the child features whose final parent feature is completed is considered to be the period of existence of an IN call.

[0015] The call view also represents the connection state between all resources regarding the entire IN call and the range of resources controlled by each feature, and is used by IN call control functions such as feature interaction control. This resource state information regarding the call view is stored in the call view management data table 8 of the interface device 2 as call view management data. Also, a feature view is information that represents the connection state between one bound resource, the flow of main information, and the leg state, and the resource state information regarding this feature view is stored in the feature view management data table 9 as feature view management data. Stored. In this way, by managing resource status not only on a feature-by-feature basis but also on a call-by-call basis using the call view and feature view, it is possible to control how resources are shared among multiple features in one IN call. can be identified. Therefore, mutual influence between a plurality of features can be easily detected.

Further, the IN call state management device 10 performs control to set, update, and delete resource state information managed on a call-by-call basis in the call view management data table 8, and the feature state management device 11 controls the feature view Control is performed to set, update, and delete resource status information managed on a feature-by-feature basis in the management data table 9. The state data translation device 12 also associates information between call view management data and feature view management data. That is, resource state information in the feature view is translated into resource state information in the call view regarding the IN call to which the feature belongs. The basic call processing translation device 13 also converts the event 14 detected by the switching node 4 into a trigger event 5, and also interprets the order sent from the service control node 1 to the switching node 4.
A task that causes an appropriate state transition in the exchange node 4 is selected.

FIG. 3 is an explanatory diagram of an image of information expressed by a call model, and shows an example of a four-party connection of one IN call. In the figure, reference numeral 21 indicates a call view, and reference numeral 22 indicates a feature view that constitutes the call view.The feature view 22 indicates the range of resources controlled by one feature. In the same figure, when a feature segment fs1 is activated by a non-IN feature segment nfs, and a feature segment fs2 is activated by this feature segment fs1, the feature segment fs1 becomes a parent feature and the feature segment fs2 becomes a child feature. Also, cs1, cs2, cs3, cs4 are communication entities corresponding to subscribers, cp1, cp2, cp3 are connection points, leg0, leg1, leg3,
leg5 is the communication entity (cs) and the connection point (
cp), the communication main leg (cs leg), l
eg2 and leg4 are feature legs that connect connection points (CP). This communication entity (cs
), connection point (cp), cs leg,
These resources, including feature legs, are referred to as resources.

Furthermore, an event on cs leg leg0 is notified to feature segments fs1 and fs2, and an event on cs leg leg1 is notified to feature segment leg2.
, leg4, and is notified to feature segments fs1 and fs2. Further, an event on the cs leg leg3 is notified to the feature segment fs2 as an event on the feature leg leg4.

FIG. 4 is an explanatory diagram of an IN call and IN call control, and is a conceptual representation. In the figure, 31 is a service control node, 32 is an interface device and switching node, and 33 is a resource. Further, SLPI1 to SLPIn of the service control node 31 are instances of feature programs, BC1-1, . . . BCn-1, .
. . . indicates an arbitrary number of basic call processes corresponding to instances of the feature program. In addition, the relationship between feature execution control is that the feature program corresponds to basic call processing, as shown by the dashed line 35, and the relationship of feature interaction control is that there is a correspondence between the feature programs, as shown by the dashed line 34. control.

[0020] The aforementioned call view management data table 8
is composed of a set of an IN call state management table, a leg state management table, a CS state management table, and a connection point state management table, and the feature view management data table 9 includes a feature state management table and a leg state management table. It is composed of a table, a CS state management table, and a connection point state management table.

FIG. 5 shows the call view management data table 8.
It is an explanatory diagram of an IN call state management table that constitutes a part of the call ID (A1), a call state (A2) indicating call execution, etc.
, feature segment ID counter (A3), CS
- ID counter (A4), leg ID counter (A5),
An area for a connection point ID counter (A6), multiple areas for sets of feature segment ID (A7) and feature state management table pointer (A8), and a plurality of areas for pairs of CS-ID (A9) and CS state management table pointer (A10). multiple areas of pairs of leg ID (A11) and leg status management table pointer (A12), multiple areas of pairs of connection point ID (A13) and connection point status management table pointer (A14) It has an area of

FIG. 6 is an explanatory diagram of the feature state management table that constitutes a part of the feature view management data table 9, and the feature segment ID (B1)
, feature segment status (B2), CS-ID counter (B3), leg ID counter (B4), connection point ID counter (B5) area, and CS-
ID (B6) and CS status management table pointer (B7)
, multiple areas of a pair of leg ID (B8) and leg status management table pointer (B9), and multiple areas of a pair of connection point ID (B10) and connection point status management table pointer (B11). It has multiple areas.

FIG. 7 is an explanatory diagram of the connection point status management table, in which the connection point ID (C1
), connection type (C2), number of connection allowable legs (C3), connection leg information (C4), and belonging feature segment information (C5), and the connection leg information (C4) is the connection leg ID (C41). and the connection leg status management table pointer (C42), and the belonging feature segment information (C5) consists of the area of the number of connected legs of the pair of the feature segment ID (C51) and the corresponding connection point ID (C52). It has an area equal to the number of features that control resources. In addition, when this connection point state management table represents call view information, the belonging feature segment information (C5) includes the ID of the feature segment to which the resource belongs at that time and the resource in the feature view information corresponding to the feature segment. The corresponding resource ID is stored. However, if it is not controlled by the IN feature,
That is, if it belongs to a non-IN feature segment nfs, it is not set. Also, if this connection point state management table represents feature view information,
Belonging feature segment information (C5) is not set.

FIG. 8 is an explanation of the CS status management table, which includes CS-ID (D1), CS type (D2), CS status indicating call etc. (D3), CS size (D4), and CS specific information (D5). , media information (D6), and belonging feature segment information (D7), and the media information (D6) includes the media type (D61) such as audio, the leg ID (D62), and the leg status management table pointer (D6).
3), and the belonging feature segment information (D7) consists of an area for the number of features in a pair of feature segment ID (D71) and corresponding CS-ID (D72). The feature segment information (D7) is the belonging feature segment information (C
Similarly to 5), set to represent call view information,
It is left unset if it belongs to a non-IN feature segment or if it represents feature view information.

FIG. 9 is an explanatory diagram of the leg status management table, which includes the leg ID (E1), the leg type (E2) such as a feature leg, the leg status such as a call (E3), and the connection status (E
4), connection CS information (E5), connection point information (E6), belonging feature segment information (E
7), and the connection CS information (E5) is the CS-I
D (E51) and CS state management table pointer (E52)
) and media type (E53), and the connection point information (E6) consists of the connection point ID (E61), connection point status management table pointer (E62), connection type and connection surface (
The feature segment information (E7) consists of the feature segment ID (E63) and the belonging feature segment information (E7).
71) and the corresponding leg ID (E72). When the relevant leg is a feature leg, the connection CS information (E5) stores connection connection point information when the relevant table represents call view information, and is unset when the relevant table represents feature view information. do. Also, the affiliated feature segment information (E7) is the affiliated feature segment information (C5) in FIG. 7 or the affiliated feature segment information (D7) in FIG.
), it is set when it represents call view information, and it is left unset when it belongs to a non-IN feature segment or when it represents feature view information.

Each part is configured as described above, and when the event 14 (see FIG. 2) from the exchange node 4 is notified to the interface device 2, the basic call processing translation device 13 of the interface device 2 converts the information in the call view. Translated into a trigger event on the leg. This trigger event is IN
The state data translation device 12 refers to the call view management data table 8 to determine the feature program currently controlling the leg in the call view. Feature state manager 1 that examines the instance and responds as a trigger event on the leg in the feature view
Transferred to 1. In this case, leg sharing may occur when multiple features are executed in one IN call. In other words, one leg may belong to multiple features at the same time, and an event that occurs on a shared leg will affect instances of the feature program corresponding to all features to which that leg belongs. Be notified.

Each feature state management device 11 that has received the trigger event notifies the corresponding feature program execution environment 7 in the service control node 1 of the trigger event 5. The feature program execution environment 7 interprets and executes the feature program 16 and sends an order 6 corresponding to the trigger event 5 to the interface device 2.

Each order 6 for controlling resources in each feature view is transferred to the state data translation device 12 via the feature state management device 11 in the interface device 2. This state data translation device 12 refers to the call view management data table 8 and converts each order 6 into an order for a resource within the call view corresponding to the order. The converted orders are checked by the feature interaction control device 17 to see if they are consistent with each other, and a set of orders that does not cause any conflicts is selected. The selected order set is transferred to the IN call state management device 10, and the IN call state management device 10 interprets these orders and updates the call view management data table 8. Also, the feature state management device 11 that has processed the orders in the selected order set interprets the orders and updates the feature view management data table 9.

The selected set of orders is then converted into an appropriate task start command or the like in the basic call processing translation device 13, and sent to the exchange node 4. The exchange node 4 executes the task according to the task activation instruction.

[0030] Next, from the state where the two parties of subscribers A and B are interconnected, the add-on service defined as the IN feature is activated twice in succession to connect subscribers A, B, C,
The sequence when providing D's four-party call service is as shown below. (T1) Two parties A and B are interconnecting, (T2) Add-on service starts due to A hooking, (T3) B
is on hold, A turns C's dial, (T4) A and C are on call after A completes dialing, (T5)
Due to A's hooking, A, B, and C are on a call, (T6) A hooks again and the add-on service is activated, (T7) B and C are on hold, and A calls D. (T8) A hooking causes A to call. ,B,C,D 4
The user is on a call.

(State T1) In this state, subscribers A and B are interconnected via switching node 4 and are in a talking state. (State T2) When subscriber A hooks in state T1, the exchange node 4 that detects it identifies it as an IN feature activation request by event analysis,
The exchange node 4 notifies the interface device 2 of the event and the internal state of the exchange node. FIG. 10 shows the configuration in state T2, and the same reference numerals as in FIG. 2 indicate the same parts. Also, in the transmission network 3, the subscriber A
, B are connected, and due to the above event, add-on feature program 1 of service control node 1
6 is activated. In addition, the call view shows the communication entity c corresponding to subscribers A and B, as shown in the dashed line.
s1, cs2 and connection point cp1 and leg le
The non-IN feature segment nfs is represented by g0 and leg1.

FIG. 11 shows a schematic flowchart when starting the add-on service. When subscriber A hooks into state T1 where subscribers A and B are interconnecting, (a)
This is processed as an event on leg leg0, and when the exchange node 4 identifies that it is an IN feature activation request, it notifies the interface device 2 of the event and the internal state of the exchange node 4. Thereby, the interface device 2 performs the IN according to the initial state generation order (b).
Call state management device 10, feature state management device 11,
Instances of the state data translation device 12, basic call processing translation device 13, and feature interaction control device 17 are generated.

[0033] The add-on feature program 16 is activated by a trigger event from the interface device 2 to the service control node 1.
, digit reception (leg0, leg2)" is executed (c), the leg leg1 of the call view within the dashed line in FIG. state. Then, when the number reception is completed (e), the order for "connection (leg0, leg2, cp1)" is executed (f). As a result, as shown in (g), communication entities cs1 (subscriber A), cs2 (subscriber C)
and connection point cp1 and legs leg0,le
It is in a connected state by g2. Then, when subscriber A hooks (h), the pending connection with subscriber B is made, the feature view becomes as shown in (i), and the call is made with the feature view containing the communicating entity indicating subscriber B. A view is formed and a three-way connection is established. By repeating these steps, a four-party connection state can also be realized.

The IN call state management device 10 is notified of the event and the internal state of the switching node by the switching node 4 described above.
generates call view management data and stores it in the call view management data table 8. Furthermore, an event caused by hooking from an exchange node is translated into a trigger event in the basic call processing translation device 13, and is notified to the service control node 1 via the feature state management device 11. In the service control node 1, an instance of the feature program execution environment 7 is generated, the trigger event is analyzed, and the add-on feature program 16 is activated.

FIG. 12 shows an example of the IN call state management table in state T2, FIG. 13 shows an example of the CS state management table, and FIG. 14 shows examples of the leg state management table and connection point state management table. show. Also, (1) to (5) in each figure show the relationships between the tables indicated by the pointer, A1 to A14, C1 to C42,
D1 to D63 and E1 to E63 are shown in FIGS. 5 and 7, respectively.
This corresponds to the area with the same reference numeral in FIGS. 8 and 9. For example, in the IN call status management table (see FIG. 12), the call ID (A1) is call1, the call status (A2) is call in progress, the feature segment ID counter (A3) is 0,
CS-ID counter (A4) is 2, leg ID counter (
A5) is 2, connection point ID counter (A6
) is 1, the CS-ID (A9) is 1, the CS state management table pointer (A10) paired with this CS-ID is (4), which points to the CS state management table on the left side of FIG. The CS-ID (A9) is 2, the CS status management table pointer (A10) paired with this CS-ID is (5),
Indicates the CS status management table on the right side of FIG. That is, the communication entity cs1 of the call view shown within the chain line in FIG.
, cs2 will be managed using the CS state management table shown in FIG.

[0036] Also, the leg ID (A
11) is 0, the leg status management table pointer (A12) paired with this leg ID is (1), which points to the leg status management table on the left side of FIG.
) is 1, and the leg status management table pointer (A12) paired with this leg ID is (2), which points to the leg status management table on the right side of FIG. That is, for the legs leg0 and leg1 of the call view shown within the dashed line in FIG.
It is managed using the leg status management table in step 4. Also, the connection point ID (A13) is 1, and the paired connection point status management table pointer (A14) is (3).
Indicates the connection point status management table at the bottom of FIG. That is, the call view connection point cp1 shown within the chain line in FIG. 10 is managed using the connection point status management table in FIG. 14.

As shown in FIG. 13, the CS status management table is formed corresponding to the communication entities cs1 and cs2.
The ID (D1) is set to 1 and 2, the CS type (D2) is the subscriber terminal, the CS status (D3) is in a call, the CS size (D4) is 1, and the CS specific information (D5) is set to the telephone number, etc. . Also, the media type (D61) is audio, connection leg ID (D6
2) are 0 and 1 (indicating leg0 and leg1), and the leg status management table pointer (D63) is (1) and (2).

As shown in FIG. 14, the leg status management table is formed corresponding to legs leg0 and leg1, and the leg IDs (E1) are 0 and 1 (indicating leg0 and leg1),
Leg type (E2) is CS leg (equivalent to the above-mentioned CS leg)
, the leg status (E3) is talking, the connection status (E4) is connected, and the CS-ID (E51) of the connection CS information (E5) is 1.
and 2 (indicates cs1, cs2), CS state management table pointer (E52) is (4) and (5), media type (
E53) is audio, connection point information (E6
) connection point ID (E61) is 1 (cp1
), the connection point status management table pointer (E62) is (3), the connection type and connection plane (E6
3) is bidirectional.

Furthermore, as shown in the lower part of FIG. 14, the connection point status management table has a connection point ID (C1) of 1 (indicating cp1) and a connection type (C2
) is a conference type, the number of allowed connection legs (C3) is 3, the connection leg ID (C41) of the connection leg information (C4) is 0 (indicates leg0), and the paired connection leg status management table pointer (C42) is (1), another connection leg ID (C41
) is 1 (indicating leg1), and the paired connection leg status management table pointer (C42) is (2), so the relationship between each table can be obtained.

(State T3) The add-on feature program 16 is activated and shifts to state T3. One step of this add-on feature program 16 is executed, and step (c) in the flowchart of FIG.
'Hold (leg1), receive numbers (leg0, leg2)
)” and the initial state information of the feature view are notified to the feature view state management device 11. As a result, the feature view state management device 11
Feature view management data is generated based on the initial state information of the feature view and stored in the feature view management data table 9. In addition, the initial state information of the feature view is passed to the state data translation device 12, translated into call view data, and then sent to the IN call state management device 10.
passed to. Thereby, the IN call state management device 10 updates the call view management data table 8. Further, the initial state information of the feature view is passed to the basic call processing translation device 13, resources in the exchange node corresponding to the call view are secured, and a state corresponding to the call view is realized.

FIG. 15 shows a call view 51 and a feature view 52 in this state T3.
Connection points cp1, cp2 and leg leg
The configuration is connected by 0, leg1, and leg2,
Also, the feature view 52 shows a pending state of the communication subject cs2 representing subscriber B from the initial state shown in FIG. The internal state of the switching node corresponding to this call view 51 is as shown in FIG. This is a connection point formed during a telephone call. Furthermore, subscribers A and B correspond to communication entities cs1 and cs2, and add-on trunk 62 corresponds to connection point cp2.
Correspondingly, between subscriber B and add-on trunk 62,
Leg leg1 and connection point cp1 and leg le
g2, and this leg leg2 becomes a feature leg that connects the connection points cp1 and cp2. Also, between subscriber A and add-on trunk 62,
The configuration is such that they are connected by leg leg0.

The order in step (c) of FIG. 11 is converted by the state data translation device 12 into an order for the resource within the call view, and is passed to the feature interaction control device 17. In this case, since only one feature related to the IN call is active, there will be no inconsistency between the features, so the order converted by the state data translation device 12 is notified to the IN call state management device 10 and the feature state management device 11. Then, the call view management data table 8 and feature view management data table 9 are updated. The order converted by the state data translation device 12 is sent to the basic call processing translation device 1.
3, it is converted into a command to start an appropriate task, and is notified to the exchange node 4, which puts subscriber B on hold and subscriber A in the process of receiving numbers.

(State T4) When subscriber A's dial input in state T3 is completed, subscriber C is called by the dial, and subscribers A and C are connected. The call is in progress.

(State T5) In state T4, subscriber A
When subscriber B hooks up, subscriber B who was on hold is connected via the add-on trunk 62, and a three-party call is in progress. That is, connection point c in the call view of FIG.
Subscribers A, B, and C are now connected via p2 (add-on trunk 62 in FIG. 16).

(State T6) In state T5 during a three-party call, for example, if subscriber A hooks up again, state T
It is processed in the same way as adding-on service startup in 2.
Add-on service is started.

(State T7) As the add-on service is activated, subscribers B and C are put on hold, and subscriber D is called by dial input by subscriber A, and a call between subscribers A and D is in progress.

(State T8) When subscriber A hooks, subscribers B and C who were on hold are hooked up in the same way as in state T5.
A four-party call is established, including the following.

FIG. 17 is an explanatory diagram of the transfer service among the add-on services, and is expressed as a call view. 71 in the same figure shows that subscribers A, B, and C (communication subjects) connect to connection points cp11 and cp12, and
11, leg12, and leg13, indicating that a three-party call is in progress. In this state, when subscriber C transfers a call to subscriber D, subscriber C generates an event such as hooking or dialing, and the feature of service control node 1 is transferred from exchange node 4 via interface device 2. The program is activated, a feature view is created for subscriber C, and as shown at 72, subscribers A and B are connected, and subscriber C is disconnected and enters a dialing state.

Upon completion of the dial input by subscriber C, subscriber D is called, and as shown at 73, subscribers C and D are connected and a conversation is in progress. In this state,
For example, when subscriber C hooks, subscribers C and D are disconnected, subscriber D is connected to subscribers A and B, and 7
4, subscribers A, B, and D connect connection points cp11, cp12, and cp13 and leg leg11.
, leg12, leg13, leg15, and leg16, and the data is transferred from subscriber C to subscriber D. That is, if the next service does not conflict with the service currently being executed, it is possible to transition from any connection state to the next arbitrary service.

[0050]

As explained above, the present invention provides an interface device 2 between a service control node 1 and a transmission network 3, and a call view management data table 8 and a feature view management data table 8 in this interface device 2. Data table 9 is provided, and the resource status is managed not only for each feature but also for each IN call using the call view and feature view, so it is possible to easily detect conflicts in resource usage between features. Also, during the execution of any feature, it is possible to activate any other feature that does not cause resource usage conflicts. Therefore, since the independence of features can be increased, there is an advantage that early development of features is possible.

[0051] Also, using the cs leg and feature leg,
By connecting the communication entity and the connection point using the cs leg, and connecting the connection points using the feature leg to form a call view, there is an advantage that the information transmission/reception relationship between the feature segments can be easily expressed.

[Brief explanation of drawings]

FIG. 1 is a diagram explaining the principle of the present invention.

FIG. 2 is an explanatory diagram of an embodiment of the present invention.

FIG. 3 is an explanatory diagram of information expressed by a call model.

FIG. 4 is an explanatory diagram of an IN call and IN call control.

FIG. 5 is an explanatory diagram of an IN call status management table.

FIG. 6 is an explanatory diagram of a feature state management table.

FIG. 7 is an explanatory diagram of a connection point state management table.

FIG. 8 is an explanatory diagram of a CS state management table.

FIG. 9 is an explanatory diagram of a leg status management table.

FIG. 10 is an explanatory diagram when starting an add-on service.

FIG. 11 is a flowchart when starting an add-on service.

FIG. 12 is an explanatory diagram of an example of an IN call state management table.

FIG. 13 is an explanatory diagram of an example of a CS state management table.

FIG. 14 is an explanatory diagram of a leg status and connection point status management table.

FIG. 15 is an explanatory diagram of a call view and a feature view.

FIG. 16 is an explanatory diagram of the internal state of the exchange node.

FIG. 17 is an explanatory diagram of a transfer service among add-on services.

FIG. 18 is an explanatory diagram of a conventional example.

[Explanation of symbols]

1 Service control node 2 Interface device 3 Transmission network 4 Exchange node 5 Trigger event 6. Order

Claims (3)

[Claims] Claim 1: comprising an interface device (2) connecting a service control node (1) and a transmission network (3) including an arbitrary number of switching nodes (4); The service control node (1) describes the order (6) to be activated by the trigger event (5) of
In a call control method for an intelligent network that executes a feature program, the interface device (2) includes a call view management data table (8) that stores management information for managing connection states between resources for each call; The order (6) from the service control node (1) is sent to the exchange node (4) based on the data in the feature view management data table (9) that stores the management information being executed for each feature. A call control method characterized in that call control is performed by converting into a start command for a task that performs a state transition. 2. The resource usage state and inter-resource connection state in each feature are managed by a call model, and the call model is applied to a communication entity leg that connects a communication entity and a connection point, and each feature. 2. The call control method according to claim 1, further comprising a feature leg connecting connection points that transmit main information between parent features and transmit events occurring within a parent feature to child features. 3. The interface device (2) stores data in the call view management data table (8) and the feature view management data table (9);
2. The call control method according to claim 1, further comprising detecting resource usage conflicts between features based on information from the feature leg.