Note: Descriptions are shown in the official language in which they were submitted.
2 ~ 97q~3
~ wo~3~/os7~9 PCT/s~ss/01027
]
~ metho~ to structure cali processing and a call
processing switching system for telephony
TEC~ICA~ FIELD
The present invention refers to a data structure for call
processing and particularly to a data structuring in a traffic
controlling process for a telecommunication application.
BAC~GROUND OF THE INVENTI~N
During processing of a call in a telecommunication system a large
amount of data needs to be handled or collected. Such call
related data differs a lot between calls depending on what kind
of services ~re utillzed in the specific call, which protocols
are used to communicate with the bU' l~u--ding networks etc. Data
contains information useful for different kinds of users of the
telecommunication system. One network/service provider may want
to create billing records while another wants to create statis-
tics of different kinds. As the vendor wants to be independent of
which data the user wants to use and still be able to add new
data together with a new service without having to change already
existing software, this call related data record have to be
handled in a new efficient way.
There exist a number of possible solutions to handle the call
related data. One obvious way is to use a conventional database
to collect the information, which quickly renders into capacity
problems. Another solution is choose a declarative solution where
a declaration of the contents is made ~e.g. compare a record in
Pascal). The drawback ~f a declarative solution as a Pascal
record is that it does not present the desired flexibi.lity. Yet
another approach is to send around the data between the objects
whenever it is needed, which creates duplication of data.
In ~he state of the art the; are found several concepts
regarding objec~ oriented software structures for processing in
a modern teleCOmmunication system. EP-0 524 08g Al titled
"5tructure de logiciel pour système de traitement de données,
amment pour Système de télecommunications" describes a logical
ssructure system for processing data, specifically for tele-
~Os~s729 2 1 q 7 9 8 ~ P~T1S~s1011127 ~
commw1ication systems. ~he structure particul.arly simplifie:i t.hereal tin-e commurlication between the objects according to the
CCr~T'' rules X 200. ~P-0 524 077 A1 titled "Structure de logicie3
pOUI système de traitement d'informations" de.scribe a struct.ure
which hi.des the hardware and software system features to the
applicat,iollE~rograms.
EP-0 470 415 A2 describes a method to supply a nun~er of
application processors in a telephony system access to cal~.
related information in a common database, The information is
tagc,~ed and stored temporarily as a record in the database a~, long
as the communic.,ation lasts. The information is particularly
direc~ted for being directly viewed on a display terminal for
sUperVisiOrl iII an operator controlled switching sy~tem.
SUMM~RY OF THE IN~ rIO~
Therefore there is a demand in a telecommunicat,ion system,
preferably by way of software, to create a standard and generic
structure, which makes it, possible to extend the system wit.h new
services and data without effecting an already exist,ing operatinc3
software of a system using the half-call principle.
A first object according to the present invention is t,o co~bine
the half-call principle with a generic protocol between the
executing half-calls and including a session comprisi.ng a session
scope and a traffic case scope which are using memory functions
in which different records are storing pointers to a local memory
function, the pointers being combined with a tag element by means
of which locally stored data will be uniquely identified and in
spite of not, being real global data may still be ut,ili~ed ar.
qlobal data duriny the duration of a specific session in wnl.ch
period t..he particular records exist.
A second object: according to the present invention is that the
specific session scope is using a session record for storing
poi,nt.ers to executing objects of the call and from which record
it will be possible to find all other objects within the session,
2 i q79~3
~ ~ ~096/09729 PCTIS~,9SI/~1~27
if the tag elements un~er which the objects are stored are k1lowr.,
other data objects being stored in a transaction record refer-
enced session record or of a traffic case record.
A third object according to the present invention is that the
traffic case scope is having a similar structure as the session
scope and the traffic case record being referenced from the
session record and the traffic case record being created to store
executing objects of a call.
A fourth object according to the present invention is that the
transaction record is storing data objects belonging to the
traffic case.
A fifth object according to the present invention is that the
tag element is being realized by an integ~r number uniquely
assigned to each ~ ut;ng object or data object being stored.
~RIEF DESCRIPTION OE~ THE DRAWINGS
The invention, together with further objects and advantages
thereof, may best be understood hy making reference to the
following description taken together with the accompanying
drawings, in which:
~igure l is an illustration of a session having a session
controller, SC, handli}lg several traffic cases
including for each traffic case a respect.ive
originating call, OC, in communication with other
traffic cases including a respective terminatir1y
'l, TC;
~igure 2 demonstrates a session controller, SC, using,
according to the method and system c.f the present
invention, a session record to store references to
executing objects and a transaction record to store
references to data objects;
wv96~972~ 2, 9 ? ~ 8 ~ PCTISE9~101027 ~ ~
Figure 3 demonstrates collect,ions according t,o tht-~ method
and system of the present invention to store a
traffic case object within an ori,ginai,i,ng call, OC;
~igure 4 is an demonstration of objects controllillg ehe data
flow in a session;
~igure 5 demonstrates an example when data for a charging
bac;is is extracted from a session;
~igure 6 shows in a simple example the relation between
created managed ob~ects;
~igure 7 shows the complete static view accor-ding to the
si~ple example of Fig. 6;
~igure 8 is a simple flow chart of call data collection in
a Transaction Record during call processing; and
~igure 9 is a simple flow chart of specification of dat,a t,o
include in an output.
FUNDAMENTALS
To be able to handle the suhject of the present application in an
efficient, way it, will be praetical to first define a number of
techllical terms which will be useful throughout the follo~ing
description.
A common way to structure software in a call processing switchillg
system for telephony is to divide the control of tAe call into
two hal~es, d Half-Call A and a Half-Call B. The softwarl, which
controls a Half-Call is e~ecuting in a process called a Sess,ion.
A session can handle one or several Traffic Cases simultaneously
(for example in a multi call situation). The Traffic Case defirle<.;
the funct,ionality and data that handles a call in a Session, Note
also that a three party call is handled by two Traffic Cases in
2 1 ~798~
~ Wos6/~9729 PCT1~E95/01027
a Session, one for each call leg.
For the sake of simpl.icity the session is structured in different
scopes and therefore is introduced the Session Scope anà the
Traffic Case Sco~e. The Session Scope is controlled by the
Baseflow Session Controller, SC'. The main task for the session
controller is to act as a command interpreter against the Acsess
Prot~ocol, ACP and make a service analysis OII these commands
(Messages). This includes the-l, for instance, initiaeing and
terminating new Traffic Cases, distributins infon~ation from the
Access Protocol to the correct Traffic C'ase, initiating new
services, etc.
Every ~'raffic Case within the Session is controlled by one
baseflow. Such a baseflow may be either an Oriqinatinq Call, OC
or a Terminatinq Call, TC. The main task for this baseflow is to
take care of the basic call handling. This includes for example
establishing/disconnecting a call (including handling of the
Telecommunication Service Protocol, TSP, between the call
halves), ordering establishment/disconnection of conr1ections ~for
example a speech conr1ection), and orderins address information
analysis, etc.
To support the different scopes and the control logic opera~ing
within those, there is a need of a similar data structure. Thus
the data must be structured in a certain way to make it possible
to implement and m~;n~in the applications. Correspondingly there
exists two different t.ypes of objects, which in tllis descr-iption
are denoted Execu~inq Objects and Data Obiects.
An Executing Object will execute in the session, e. g., control
objects, protocol objects, resource objects etc. A pure ~ata
Object will contain data received for example from a Teleservice
Protocol Message. It shall also be possible to make an output of
this type of data for charging or statistic purposes. The two
types of Objects have different semantics and are stored in
different records in the Session. Such a record is referred to as
2 1 ~7~3
W0~6/0~729 PC~1'/SEg~/0102
a Session Recol-d and i.s used to store point:ers to protocc)l
objects and resource objects instantiated b~ control and resource
objects within the Session. The Objects storecd in a Session
Record are common for the whole Session. Por st.oring pure Data
Objec.ts is used a Transactior, Record. In a similar way as the
SessiGn Record stores pointer to objects the Transaction Record
(also named call record) is used to store pointers to pure Data
Objects instantiated by control., protocol, and resource object.s
within the Session or a Traffic Case exec-.uting in the Session
A users view of a Session Record is referred to a Session Record
~iew and gives the user an interface to the Session Record on a
high abstraction level Similarly a users view of a Transacti.on
Record is referred to as the Transaction Record View and gives
t.he user an interface to the Transaction Recprd on a high
abstraction level.
Finally there is also found a Traffic Case Record which is a
rec.ord where pointers to Objects belonging to a T~affic Case are
stored. Only pointers to Protocol Objects and Resource Objects
are stored in this record. Por storing pure Data Objects a
Transaction Record should be used. A users view of a ~'raffic Case
Record is referred to a Traffic Case Record View and g1ves the
user an interface to the Session Record on a high abstractio
level.
DETAILr~ r~ESCRIPTION OF T~E PREFERRED EMBODIME~T
'I'o support t.he different scopes and correspondiny control logic
for a c.all processing in a telecommunication sys~.em we ne~ec~ a
suit.ab1e data structure. Data must. be~ structured to ma~.:e it
possible to implement and m~jnt~in the applications WL~ there~ore
introduce two different types of objects, the executi.ng objects
and data objects, respectively, to keep track in an session
These two terms, which were. already defined above, do have
different semant..ics and are stored in different records in the
created session. ~hen storing an object in a collection it is
only a questlon of storing a pointer t.o the object that is to be
2 ~ ~79~3
~ ~ W096/09729 PCTISE!~/01027
stored and consequently no ciuplication of the object ltselL is
made in such a step. This also implies that for such a pointer
storage there is actually no need to know the size of t~ie
particular object.
Figure l is a generalized view of a session scope, which is
controlled by the session controller SC. The session controller
is acting as a command interpreter against the access protocol
ACP, which is the generic term used for the subsc.riber or network
accesses. As is evident from figure l, the session contains one
or several traffic cases, and here the particular session
contains two traffic cases which are both of the OC type
(originating call~. Eac.h one of the two traffic cases of type OC
is established by means of the respective traffic case to another
traffic case of type TC (terminating call) through a handling
telecommunication service protocol, TSP.
As indicated in figure 2 there is in the session scope a session
record, which shall be used for storing a pointer, PTR, to each
executing object, for example to a so called session agent. The
session record, SR, is by means of other pointers the root for
the data structure in each session. The data objects of the w1lole
session is found in the transaction record by means of their
respect.ive pointers, PTR. Each entry in the session record is
having a particular name or key, TAG, which makes it possible to
locate any object within the session scope if the particular
sysl-em operator knows the particular name or TAG.
Figure 3 is a generalized view of a traffic case scope, here
ccnt~ining an originating call t..ype, OC, but a terminating c.all
type, TC, would have the corre ~nding structure. This scope has
to be introduced if the appl ition has a need to execute an
arbitrary number of parallel traffic cases in the session. The
structure of the traffic case scope is thus similar to that of
the session scope. For each traffic case in a session there is
created a traffic case record to store executing objects. ~ike in
the session record is used a name or TAG and a pointel- PTP.. The
21 q~q~3
~~096rog729 PC~S~.s~ 2
traffic case record i.s accordingly referenced fro~ the sessio
record. 'I'o store data objects belonging to the traffic case is
consequently used a transaction record, TR, creating a table for
the data objects a~. this traffic case level.
Every user of a session or traffic case record has an own view
object through which the stored executing objects or data objects
7nay be accessed.
.?igure ~ demonstrates in greater detail the data flow through a
session executing an originating call, OC. The data flow starts
when some data is received by an access agent or the input a7ent.
The received dat.a is converted to an AXE internal representation.
The converted data is then stored in the transaction record, 'ï'R.
The data object is stored with a tag. The tag is an integer that
is reserved for this particular data object. Other users, e.g. an
Application Analysis, needing the data object can ~etch it from
the transaction record by means of the tag and by utili~ing a
transaction record view object, TR_View. The above exa~ple also
illustrates wherl ~ata is sent by the output agent to the other
Half-Call via the telecommunication service protocol, ~rsP r~ata
is sent in a parameter which besides the data ~nt~i7~ the tag
which identifies it.
As stated above a data object i.s stored in the transaction record
la synonym for transaction record is also call record~. 'rhe
transaction record, TR, is as already stated always accessecl vla
a view object. The view object gives the user a high le~vel
irlte.rface to TR, which will be further described below. Each clata
object that is stored in the transaction record is semanticall}/
identified by a name or key referred to as the TAG. The TA~ is an
integer, i.n an exemplifying embodiment a 16 bit word, whic'h hc15
been reserved for one particular data object. By using a dynamic
storage such as the transacti.on 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 general operation of the teieco~nu-
2 ~ q7~83
096/09~9 PCT~E~51~1027
nicat.ion system, to at any particular time period extract anychosen data objects on demand of the user for a later analysis.
A conse~uence of this is that it will be extremely easy to add
additional services into a system operating according to such a
structured way of operation.
Assume that the agent receive the parameter "calling party
number" on the protocol, ACP. The data will be converted to an
AXE internal representation and stored in the TR together with an
dedicated tag, 'lAppcallingpartyNumberTagll~ Other users oE TR that
needs the calling party number can then turn to the TR and ask
Eor the data object that is stored with the TA~ "AppCalling-
PartyNumberTag". An interEace Applicati.on Platfonn Tags In-
terface, ATI, nnn~;n~ the number of tags used by the functions.
ATI also contains the rules to follow when new tag,s are reserved.
As already mentioned the TR is always accessed via a view object.
The view object has two main tasks. The Eirst is to present a
customized interface towards the TR. Each user of the TR should
have a dedicated interface to the contents in the TR. The second
task is to act as a handle object towards the TR, the handle
ensures that TR is not removed until all handles are deleted.
View objects are also used to access the contents of the other
two types of record that exist, the session record and the
tra.ffic case record. As mentioned above one task of the view
object is to provide the user wit,h a customized interface on a
high abstraction level towards a record. The customi2ing means
that the interface gives the users access only to the objects
needed to be accessed, which may be only a part of the ~o~,al
contents in a record.
The second major task of the view object.s t.owards the transaction
record and the traffic case record is that they act a handles. As
long as a record has a handle it can not be deleted. Whell the
las~, handle towards a record is removed the record and all its
content is also removed from the local memory storage. I~. is
, .. . . . , . , .. ,, ,, ... , . ,, ,, . ,, , ... _ . _ _ _ _ _ _ _ _ _ _ _ _, ,, _ _ _
2 1 97q~3
WO Yh~'097~9 PCrlSE9~V0102/
apparen~.that this creates a very convellierlt local. memory stoIaye
management.
The call recorcd output mechanism a~ready mentioned is used to
output parts of the content of a transaction record for post.-
processing. It. should be kept in mind that the contents of the
session record and a traffic case record and a transaction record
are exist,ent only during the duration of that pa.rticular sessior
and will disappear when the session is terminated. The c~utput.
mechanism is built around a nunber of managed objects corltainir,g
tag lists. In the operation of a telecolnmunication system theIe
is for instance a need to collect charging data to be able to
correctly bill the different subscribers. In Figure 5 is
exemplified what may take place in a session. A control objec~
"C'harging" has opened an object Cro_Type. This particular
Cro_Type object contains a Tag list, fetched ;rom the data base,
denoting the data objects to be extracted from the transaction
record. Cro_Type i~ then ordered to compile a report consisting
of the data objects identified by the tag list w.hi.ch is stored in
t.he data base. The control object then uses the Cro_T~fpe
interface t.o order ie to collect the data during the existellce of
the particular se~sion. The data may be packed in a data area
which then ~ill be sent to a post-processing node. C;onsequentl~
a charging basis due to increased service~ may be challged at anr
moment by-simple modification of the tag list without interferillg
at all with the existing system having a structure accordincJ to
the present invention.
Thf' ef~ective result of this is that even if the rollten:s c.,~ the
different sessions are defined as local data, it is pc,,ssihle ~.o
simultaneously make use of desired parts of the cont.erlt as lf i~
constit.ut.es global data. A difference between local and globa]
data is for example that the }atter by necessity has normally ~o
be allocated in predetermined memory locations to l)e able~ ~.o be
accessed by other users.
In the illustrativf~ embodiment Wfe use tnree types of managed
W09G/09729 PCT~SE95/0l027
objects to effectuate the flexible OUtpllt tlleChanism desCI'i.beCi
here. They are denoted as CroServiceTemplate, Cro~pe and Cro-
CustomerTemplate. The first managed object type, the CroService-
Template is used for specification of what data objects are
possible to extract for a specific basic or supplementary
service. CroServiceTemplate contains one attribute, possible
TAGs, denoting which data is possible to extract from the
transaction record, TR, for a particular service, for example in
this context a "Basic Call~ or a "Three Party Call".
The second managed object type is CroType, which is used for
specification of a certain output tyl?e. Every instance of Cro~ype
is connected to one or more instances of CroServiceTemplate. The
union of data in these CroServiceTemplates determines what data
is possible to output for a specific CroType.
The third and last management object type is CroCustomerTemplate,
which is a managed object holding the information of which data
to extract ~or a specific customer in a specific output type,
Cro~ ype .
Figure 6 demonstrates a small example having the conditions:
- There are two customers, A and B.
- There are two services, "Basic Call" and "Three Party Call~.
- There are two CroTypes, CroType 1 and CroType 2.
Because there are two services we need two CroServiceTemplates:
- CroServiceTemplate Basic C'all, c~n~;ning the Tags 1, 2, 5
and 8.
- CroServiceT.emplate Three Party Call, c~n~inlng the Tags 1,
2, 6 and 9.
This means that for the "Basic Call" we can output the data
stored in TR having the Tags 1, 2, 5, and 8, while for the
serl~ice "Three Party Call" we may output the data stored under
the Tags 1, 2, 6, and 9.
_ _ _ _ _ _ ,
2 1 ~7~3
~096/097~9 P~'ISE9~01027
We ~,hen define two output, t,ypes, CroType I designecl such that i t
will be able to output data related to both services and CroType
2 designed such that it will be able to output dat,a related to
the Basic Call. In Figure 6 is visuali~.ed the basic structure and
the relation between the created rnanaged object.
One CroCustomerTemp,lat,e is required for each customer and Cro~ype
to make the output mechanism "Call Record Output", CRO, able to
perform outputs of all CroTypes to all customers. This resu3,ts in
thir, example in a total of four CroCustorr1erTemplates In Figure
is demonstratecl the resulting structure. Customer A recluire.s
all possible Tags from CroType l and Tag no. l and 2 from ~rol~e
2 and customer B requires all Tags with lower rlumber than 8 from
all CroTypes. We then ha~e a final structure that the output
mechanism CRO needs to make a proper distrib~tion. We have
specified which data fie.lds all different custc3mersrleecl frorr all
different CroTypes
A fillal part of the data flow in Figure 4 describes when the data
shall be sent to the other ~al~-Call. The Half-Calls cornrnunicat:e
by meanr, of the Telecommunication Service Protocol, TSP. The l'SP
carrie.s self-ider1tifying parameters. A parameter ~nt~lnrT a data
object and is identified by a Tag. The receiver can determir~.e
what data is recei~ed by loo~ing at the Tag. The Tag whic.h is
used to identify a parameter on the TSP is the same 'l'ag used to
identify a da~a stored in TR.
In E'igure 8 is summarized by a nurroer of steps in a simple~ flow
chart of a call data collection in a Transactiol1 Rec~ord durirlg
call processing. Such a processing is st,arted iII a step l00 In
the first real step l0l of the process a message is received ovec-
an exter1lal protocol IL is received in a protc.col age1lt wi~,hin
a dynamic process within the s-ystem. NeAt in a step 102 the data
is converted from an externa representation to an interIIal
representation. A Dat,a Object, is created withi1l this dy1lar1lic
process This Data Or~ect then contains tne internal reprer;enta-
i,ion of the received data.
2 1 97~83
~09610~729 PCT/S~95/1~1027
In a third step 103 the ~ata Object is stored under a uni~ue tag
element in a transaction record. During call processing data lS
fetched in a fourth step l0~ from the transactio}l record using a
transaction record view object then utilizing the tag element to
get the correct poirter PTR to retrieve the specified data.
When the call ends or when an output of call data is wanted for
statistical or charging purposes the function call record output
is cal].ed in a fifth step 105. This function accesses the
database to find out which data to output. As a result the
function gets a list of tag elements. The wanted data is
collected from TR in step 104 and put into an output buffer. This
buffer may then be output to an external media. The data may
later be post-processed in order to for instance produce billing
information etc.
Flnally in Figure 9 is shown by means of three steps a simple
flow chart a specification of data to be included in an output.
The procedure starts in a step 200. In a step 201. the service
provider or any other operator administrating the system decides
which data to output for different call types. These different
output types are specified in a second step 202 by filling in
templates with lists of tags to output. In a final step 203 these
templates are stored in the database by for example entering the
list, of tags by means of a separate terminal and/or a keyboard.
These entered list of tags are later accessed during the call
processi,ng. ~ntering of the list of tags will 110t interfere h~ith
the general ca].l processing in the telecommunication syst.e1o for
init,iating and terminating traffic cases, distributing informa-
tion from the access protocol to the correct traffic case,
init.iating new servic~eC;~ etc., but when entered it will decide
which data to be stored in the database for post-processing.
It. will be understood by t,hose skilled in the art that varlous
modi.fications and changes may be made to the prese1lt invention
withou~. departure from the spirit and scope thereof, which i.s
defined by the appended cl.aims.
