MXPA97001999A - A method for structuring the processing of calls and a transmission system of processing calls for telefo - Google Patents

Abstract

The present invention demonstrates a method for structuring call processing in a telecommunication system, preferably through software, to create a normal and generic structure that makes it possible to expand the system with new services and data without affecting a superior operation that already exists from the system using the half-call principle, combining this middle-call principle with a generic protocol between the half-calls of execution in a session with a field of action of the section t a field of action of the traffic case that they are using memory functions where the different registers are stored towards the local memory function, the indicators are combined with a tag element by means of which the locally stored data will be identified in a singular way and in spite of not being the real global data , can still be used as a global data for the duration of a specific session in guinea pig or period there are specific records

Description

"A METHOD FOR STRUCTURING CALL PROCESSING AND A CALL PROCESSING SWITCHING SYSTEM FOR TELEPHONY TECHNICAL FIELD The present invention relates to a data structure for call processing and particularly to a data that is structured in a traffic control process for a telecommunication application.

BACKGROUND OF THE INVENTION During the processing of a call in a telecommunication system, a large amount of data needs to be handled or collected. This data related to the call differs considerably between calls that depend on what kinds of services are used in the specific call, whose protocols are used to communicate with the surrounding networks, etc. The data contains useful information for different classes of users of the telecommunication system. One network / service provider may want to create billing records while another wants to create statistics for different classes. Since the vendor wants to be independent of what data the user wants to use and still be able to add new data along with a new service without having to change the existing software, this record of the data related to the call has to be handled in a way efficient new. There are a number of possible solutions to handle the data related to the call. One obvious way is to use a conventional database to collect information that quickly becomes capacity problems. Other solutions selected a declarative solution where a content declaration is made (eg, compare a record in Pascal). The inconvenience of a declarative solution as a Pascal registry is that it does not have the desired flexibility. Still another approach is to send around the data between the objects when this is necessary, which creates duplication of data. In the current state of the art there are different concepts related to object-oriented software structures for processing in a modern telecommunication system. The patent number EP-0 524 089 The so-called "Structure of logiciel pour systéme de traitement de données, notamment pour systéme de télécommunications" describes a logical structure system for processing data, specifically for telecommunication systems. The structure particularly simplifies the real-time communication between the objects according to the rules of CCITT X 200. The Patent Number EP-0 524 077 The so-called "Structure of logiciel pour systéme de traitement d 'informations" describes a structure that conceals the particularities of the hardware and software system to the application programs. Patent Number EP-0 470 415 A2 describes a method for providing a number of application processors in a telephony system access to information related to the call in a common database. The information is identified and stored temporarily as a record in the database until the communication lasts. The information is particularly directed to be viewed directly in a presentation terminal for supervision in a control system controlled by the operator.

COMPENDIUM OF THE INVENTION Therefore, there is a demand in a telecommunication system, preferably through software, to create a normal and generic structure that makes it possible to expand the system with new services and data without affecting the existing operating software of a system that use a half call principle. A first object in accordance with the present invention is to combine the middle call principle with a generic protocol between the execution of the means calls and including a session comprising a session action field and a traffic case action field that they are using memory functions where different registers are being stored indicators towards a local memory function, the indicators are combined with a tag element by means of which the locally stored data will be identified in a singular way and in spite of not being the real global data it can still be used as the global data during the duration of a specific session where it exists a specific record period. A second object in accordance with the present invention is that the specific session action field is using a session register to store indicators to execute objects of the call, and from whose registration it will be possible to find all the other objects within the session, if the tag elements under which the objects are stored are known, the other data objects being stored in a transaction record related to the session record or a traffic case record. A third object according to the present invention is that the field of action of the traffic case is having a structure similar to the session action field and the registration of the traffic case is acquired from the session record and registration of the traffic case is create to store the execution objects of a call. A fourth object in accordance with the present invention is that the transaction register is storing data objects belonging to the traffic case. A fifth object according to the present invention is that the tag element is being carried out by an integer assigned in a unique manner to each object of execution or data object being stored.

BRIEF DESCRIPTION OF THE DRAWINGS The invention, together with the additional objects and advantages thereof, can be better understood by reference to the following description taken in conjunction with the accompanying drawings, in which: Figure 1 is an illustration of a session having a session controller, SC, which handles the different traffic cases including, for each traffic case, a respective originating call, OC, in communication with other traffic cases including a respective termination call, TC; Figure 2 demonstrates a session controller, SC, which uses in accordance with the method and system of the present invention, a session record for storing references to carry out the objects and a transaction record for storing the references to the data objects; Figure 3 demonstrates the collections in accordance with the method and system of the present invention for storing an object of the traffic case within a call of origin, OC; Figure 4 is a demonstration of the objects that control the flow of data in a session; Figure 5 demonstrates an example when the data for a charge base is extracted from a session; Figure 6 shows in a simple example the relationship between the managed objects created; Figure 7 shows the complete static view in accordance with the simple example of Figure 6; Figure 8 is a simple flow chart of the call data collection in a Transaction Log during call processing; and Figure 9 is a simple flow chart of the data specifications to be included in an output.

FUNDAMENTAL In order to be able to handle the object of the present request in an efficient manner, it will be practical to first define a number of technical terms that will be useful through the following description. A common way to structure the software into a call processing switching system for telephony is to divide the call control into two halves, a Media-Call A and a Media-Call B. The software that controls a Media-Call is taking place in a process called a Session. A session can handle one or several Traffic Cases simultaneously (for example in a multiple call situation). The Traffic Case defines the functionality and the data that a call handles in a Session. Note that a three-part call is handled by two Traffic Cases in a Session, one for each leg called. For reasons of simplification, the session is structured in different fields of action and therefore the Session Action Field and the Traffic Case Action Field are introduced. The Session Action Field is controlled by the Base Flow Session Controller, SC. The main task for the session controller is to act as a command interpreter against the Access Protocol, ACP and perform a service analysis on these commands (Messages). This then includes, for example, initiating and terminating the new Traffic Cases, distributing the information from the Access Protocol protocol to the correct Traffic Case, initiating new services, etc. Each Traffic Case within the Session is controlled by a base flow. This base flow can either be a Call of Origin, OC or a Call of Termination, TC. The main task for this base flow is to take care of the handling of the basic call. This includes, for example, establishing / disconnecting a call (including handling of the Telecommunication Service Protocol, TSP, between the call halves), ordering the establishment / disconnection of connections (for example, a conversation connection), and ordering analysis of address information, etc. To sustain the different fields of action and logical control operation within those, there is a need for a similar data structure. In this way, the data must be structured in a certain way to make it possible to implement and maintain the applications.

Correspondingly, there are two different types of objects that in this description are represented as Execution Objects and Data Objects. An Execution Object will execute in the session, eg, the control objects, the protocol objects, the resource objects, etc. A pure Data Object will contain the data received, for example, from a Teleservice Protocol Message. It will also be possible to make an output of this type of data for charging or statistics purposes. The two types of Objects have different semantics and are stored in different registers in the Session. This record is referred to as a Session Record and is used to store indicators for protocol objects and resource objects installed by the control and resource objects within the Session. Objects stored in a Session record are common for the entire Session. A Transaction Record is used to store the Pure Data Objects. Similarly, the one in which the Session Record stores an indicator of the objects, the Transaction Record (also called call record) is used to store the indicators towards the Pure Data Objects installed by means of control objects, protocol and of appeal within the Session or a Traffic Case that is executed in the Session.

A view of users of a Session Record is referred to as a Session Registration View and provides the user with an interface to the Session Record at a high abstraction level. Similarly, a view of the users of a Transaction Log is referred to as the Transaction Log View and provides the user with an interface to the Transaction Log at a high abstraction level. Finally, there is also a Traffic Case Record that is a record where the indicators are stored towards the Objects belonging to a Traffic Case. Only the indicators to the Protocol Objects and the Resource Objects are stored in this record. To store the Pure Data Objects a Transaction Record must be used. A view of the users of a Traffic Case record is referred to as a Traffic Case Registration view and provides the user with an interface to the Session Log at a high level of abstraction.

DETAILED DESCRIPTION OF THE PREFERRED MODALITY In order to sustain the different fields of action and the corresponding control logic for a call processing in a telecommunication system, we need an appropriate data structure. The data must be structured to make it possible to implement and maintain the applications. Therefore, we introduce two different types of objects, the execution objects and the data objects, respectively, to keep abreast of an assignment. These two terms that are already defined in the above, have different semantics and are stored in different registers in the created session. When an object is stored in a collection it is only a question of storing an indicator towards the object to be stored and consequently, no duplication of the object itself is made in this step. This also implies that for this storage of the indicator there is really no need to know the size of the specific object. Figure 1 is a generalized view of the session scope that is controlled by the SC session controller. The session controller is acting as a command interpreter against the ACP access protocol, which is the generic term used for subscriber or network access. As is evident from Figure 1, the session contains one or several traffic cases and here the specific session contains two cases of traffic that are both of the OC type (originating call). Each of the two cases of traffic of type OC is established by means of the case of respective traffic to another case of traffic of type TC (call of termination) through a protocol of telecommunication service of handling, TSP. As indicated in Figure 2, there is in the field of the session action a session record that will be used to store an indicator, PTR, towards each execution object, for example to a so-called session agent. The session record, SR, is by means of other indicators the root for the structure of the data in each session. The data objects of the entire session are in the transaction log by means of their respective indicators, PTR. Each entry in the session record has a specific name or key, TAG, which makes it possible to locate any object within the session action field if the operator of the specific system knows the specific name or TAG. Figure 3 is a generalized view of a field of action of the traffic case, here containing a type of originating call, OC, but a type of termination call, TC, would have the corresponding structure. This field of action has to be introduced if the application needs to execute an arbitrary number of parallel traffic cases in the session. The structure of the field of action of the traffic case is therefore similar to that of the session action field. For each case of traffic in a session, a traffic case record is created to store the execution objects. Like the session record, a name or TAG is used towards a PTR indicator. The corresponding traffic case record is acquired from the session record. To store the data objects belonging to the traffic case, a transaction record TR is used which creates a frame for the data objects at this traffic case level. Each user of a session or traffic case record has its own view object through which it can have access to executed objects or data objects. Figure 4 shows in greater detail the flow of data through a session that executes a call of origin, OC. The data flow begins when a certain data is received by an access agent or the input agent. The received data becomes an internal AX representation. The converted data is then stored in the transaction log, TR. The data object is stored with a tag. The tag is an integer that is reserved for this specific data object. Other users, eg, an Application Analysis, which needs the data object can be collected from the transaction record by means of the tag and using a transaction record view object, TR Vista. The aforementioned example also illustrates when the data is sent by the output agent to another Media-Call via the telecommunication service protocol, TSP. The data is sent in a parameter that in addition to the data contains the tag that identifies it. As mentioned above, a data object is stored in the transaction record (a synonym for transaction record, it is also called a call record). The transaction record, TR, as already stated, always has access through an object of view. The view object provides the user with a high level interface to TR, which will be described further below. Each data object that is stored in the transaction log is semantically identified by a name or key that is referred to as TAG. The TAG is an integer in an exemplification mode, a 16 bit mode, which has been reserved for a specific data object. By using a dynamic storage such as the transaction record, where the data objects are stored with tags, it will be possible to support a very flexible output mechanism. In other words, it will be extremely easy without influencing the overall operation of the telecommunication system, in any specific period of time to extract any of the selected data objects at the request of the user for further analysis. A consequence of this is that it will be extremely easy to add additional services in a system that works in a manner that is structurally functioning. Suppose that the agent receives the parameter "number of the calling party" in the protocol, ACP. The data will become an internal AX representation and will be stored in TR together with a dedicated tag, "AppCallingPartyNumberTag". Other uses of the TR that the calling party number needs can then go to TR and ask for the data object that is stored with TAG "AppCallingPartyNumberTag". An Application Platform Tag Interface, ATI, contains the number of tags used by the functions. ATI also contains the rules that must be followed when reserving the new tags. As already mentioned, the TR always has access through an object of view. The object of view has two main tasks. The first is to present an interface tailored to the client towards TR. Each user of TR must have an interface dedicated to the content in the TR. The second task is to act as a handle object towards TR, and the handle ensures that TR is not removed until all the handles are removed.

View objects are also used to give access to the contents of the other two types of records that exist, the session record and the traffic case record. As mentioned above, a task of the view object is to provide the user with an interface tailored to the client at a high abstraction level towards a record. The interface manufactured to the customer's liking means that the interface provides access to users only to the necessary objects that must have access which can be only a part of the total content in a registry. The second main task of the view objects towards the transaction record and the traffic case record is to act as handles. As long as a record has a handle it can not be deleted. When the last handle to a record is removed, the record and all its contents are also removed from the local memory store. It is evident that this creates a very convenient local memory storage management. The aforementioned call record output mechanism is used to send parts of the contents of a transaction record for post-processing. It must be taken into account that the content of the session record and the traffic case record and a transaction record are existing only through the duration of that specific session and that they will disappear when the session is terminated. The exit mechanism is built around a number of managed objects that contain tag lists. In the operation of a telecommunication system for example there is a need to charge the charging data to be able to correctly bill the different subscribers. Figure 5 shows what can be done in a session. A "Load" control object has opened a Cro_Type object. This specific Cro-Type object contains a list of Tags that are collected from the database representing the data objects to be extracted from the transaction record. The Cro_Type is then ordered to collect a report consisting of the data objects identified by the list of tags that is stored in the database. The control object then uses the Cro_Type interface to order it to collect the data during the existence of the specific session. The data can be packaged in a data area that will be sent to a post-processing node. Consequently, a base charge due to increased services can be changed at any time by a simple modification of the list of tags without interfering with the existing system having a structure in accordance with the present invention.

The effective result of this is that even when the content of the different sessions is defined as a local data, it is possible to make simultaneous use of desired parts of the content as if it were the global data. A difference between local and global data, for example, is that the latter must necessarily be assigned in predetermined memory locations in order to be able to give access to other users. In the illustrative mode we use three types of managed objects to perform the flexible output mechanism described here. They are represented as CroServiceTemplate, CroType and Cro-CustomerTe plate. The first type of managed object, the CroServiceTemplate is used for the specification of which data objects are possible to extract for a specific basic or supplementary service. The CroServiceTemplate contains an attribute of the possible TAGs that represent which data it is possible to extract from the transaction record, TR, for a specific service, for example, in this context a "Basic Call" or a "Three Party Call". The second type of managed object is CroType that is used to specify a certain type of output. Each case of CroType connects with one or more cases of CroServiceTemplate. The union of the data in these CroServiceTemplates determines which data it is possible to send for a specific CroType. The third and last managed object type is the CroCustomerTemplate, which is a managed object that holds the information which data should be extracted for a specific client at a specific output type CroType. Figure 6 shows a small example that has the conditions: - There are two clients, A and B There are two services, "Basic Call" and "Three Call".

Parts. "There are two CroTypes, CroType 1 and Crotype 2. Because there are two services we need two CroServiceTemplates: Basic Call from CroServiceTemplate, which contains the Labels 1, 2, 5 and 8. Three Party Call CroServiceTemplate, which contains the Labels 1, 2, 6 and 9. This means that for the "Basic Call" we can send the data stored in TR that has the Labels 1, 2, 5 and 8, while for the "Three Party Call" service we can send the data stored under tags 1, 2, 6 and 9.

Then, we define two types of output, CroType 1 designated in such a way that it is able to output the data related to both services and CroType designated in such a way that it will be able to output the data related to the Basic Call. In Figure 6 the basic structure and the relationship between the administered object created is displayed. A CroCustomerTemplate is required for each client and a CroType to make the output mechanism "Call Record Exit", CRO, capable of performing outputs of all CroTypes to all clients. This results in a total of four CroCustomerTemplates in this example. In Figure 7 the resulting structure is demonstrated. Client A requires all possible tags of Crotype 1 and Tag # 1 and 2 of CroType 2 and client B requires all of the Tags with a number less than 8 of all CroTypes. We then have a final structure where the CRO exit mechanism needs to make an appropriate distribution. We have specified which data fields all the different clients of all the different CroTypes need. A final part of the data flow in Figure 4 describes when the data will be sent to another Media-Call. Media-Calls are communicated through the Telecommunications Service Protocol, TSP. The TSP carries self-identifying parameters. A parameter contains a data object and is identified by a tag. The receiver can determine which data is received by looking at the tag. The tag used to identify a parameter in the TSP is the same tag used to identify a data stored in TR. Figure 8 summarizes a number of steps in a simple flow chart of a call data collection in a Transaction Log during call processing. This processing is initiated in a step 100. In the first real step 101 of the process, a message is received through an external protocol. It is received in a protocol agent within a dynamic process within the system. Then in a step 102, the data is converted from an external representation to an internal representation. A Data Object is created within this dynamic process. This Data Object then contains the internal representation of the received data. In a third step 103, the Data Object is stored under a singular tag element in a transaction record. During the call the processing data is collected in a fourth step 104 from the transaction record using an object of view of the transaction record and then using the tag element to obtain the correct indicator PTR to retrieve the specified data. When the call ends or when an output of the call data is desired for statistical or charging purposes, the function call register output is called in a fifth step 105. This function provides access to the database to find which is the data that should be sent. As a result, the function obtains a list of tag elements. The desired data is collected from TR in step 104 and placed in an output buffer. This buffer is then sent to an external medium. The data may subsequently be post-processed so that, for example, it produces the billing information, etc. Finally, Figure 9 shows by means of three steps a simple flow chart a specification of the data to be included in an output. The procedure begins in a step 200. In a step 201 the service provider or any other operator administering the system decides what data should be sent for different call types. These different output types are specified in a second step 202 by filling in the templates with views of tags that must be sent. In a final step 203, these templates are stored in the database by, for example, accepting the list of tags by means of a separate terminal and / or a keyboard.

This admitted list of tags will subsequently lend access during the processing of the call. The admission of the list of tags will not interfere with the general call processing in the telecommunication system to initiate and terminate the traffic cases, distributing the information from the access protocol to the case of correct traffic, initiating new services, etc. ., but when they are admitted, they will decide which data should be stored in the database for post-processing. It will be understood by those skilled in the art that various modifications and changes may be made in the present invention without deviating from the spirit and scope thereof, which is defined by the appended claims.

Claims (10)

CLAIMS:

1. A method to structure the call processing in a telecommunication system, preferably through software, to create a normal and generic structure, which makes it possible to expand the system with new services and data without affecting a main operating software that already exists of the system, using the half-call principle, characterized by combining this middle-call principle with a generic protocol between the execution of call-ins and including a session comprising a session action field and a traffic action field that they use memory functions where different registers are storing indicators (PTR) in a local memory function, the indicators are combined with a tag element (TAG) by means of which the locally stored data will be uniquely identified and in spite of not be the actual global data can still be used as the global data for the duration of a specific session a in which period there is a specific record.

2. The method according to claim 1, characterized in that the action field of the specific session uses a session register (SR) to store the indicators to the execution objects of the call and from whose registration it will be possible to find all the other objects within the session, if the tag elements (TAG) under which the objects are stored are known, and the other data objects are being stored in a transaction register (TR) of a session record (SR) or from a traffic case record. The method according to claim 2, characterized in that the field of action of the traffic case has a structure similar to that of the session action field and reference is made to the registration of the traffic case from the session record (SR ) and the traffic case record is created to store the execution objects of a call. The method according to claim 2, characterized in that the transaction register (TR) stores the data objects belonging to the traffic case. 5. The method according to any of claims 1 to 4, characterized in that the tag element (TAG) is obtained by an integer assigned uniquely to each object of execution or data object that is stored. 6. A call processing switching system for telephony which makes it possible to extend the system with service and data movements without affecting a main operating software that already exists in the system using the media-11amada principle, characterized in that the principle of media- call is combined with a generic protocol between the half-calls of execution and that includes a session that includes a session action field and a field of action in the case of traffic, which uses memory functions where different records are storing indicators (PTR) to a local memory, the indicators are combined with a tag element (TAG) by means of which the locally stored data are identified in a singular way and in spite of not being the real global data, they will be usable as a global data during the duration of a specific session in which period there is a specific record. The system according to claim 6, characterized in that the action field of the specific session uses a session register (SR), to store indicators (PTR) for call execution objects and from whose registration it is practical to find any of the other objects within the session if the tag elements (TAG) under which the objects are stored are known, whereby the other data objects are being stored in a transaction register (TR) of a record of session (SC) or a traffic case record. 8. The system according to claim 7, characterized in that the field of action of the traffic case has a structure similar to the session action field and reference is made to the registration of the traffic case from the session (SR) register and the traffic case record is created to store objects for executing a call. 9. The system according to claim 8, characterized in that the transaction register (TR) stores the data objects that belong to the traffic case. 10. The system according to any of claims 6 to 9, characterized in that the tag element (TAG) is constituted by an integer assigned in a singular manner to each object of execution or data object that is being stored.