CN1158206A

CN1158206A - 一个灵活的呼叫记录机制

Info

Publication number: CN1158206A
Application number: CN95195162A
Authority: CN
Inventors: M·P·E·基尔黑格; J·E·施特兰
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1994-09-19
Filing date: 1995-09-12
Publication date: 1997-08-27
Anticipated expiration: 2015-09-12
Also published as: AU691341B2; EP0782812A1; MX9702003A; CN1092901C; SE9403131D0; DE69534777D1; KR100293143B1; DE69534777T2; TW298695B; JPH10505984A; NO971163D0; SE503393C2; EP0782812B1; FI971144A; FI971144A0; SE9403131L; NO971163L; WO1996009730A1; AU3580395A

Abstract

本发明表明了电信系统中体现灵活记录机制的方法和系统，优选地通过软件实现，它使用一种半呼叫原理，使得用新的业务和数据扩展所述系统而不影响已经存在的系统主操作软件成为可能，通过存储器指针(PTR)，在执行对话期间呼叫处理中，将数据存储在与每个被执行的对话期间有关的记录中，所述指针还与一个标记元件(TAG)相结合，通过该单元本地存储的数据将被唯一地标识并可在对话期间有选择地被调用并存储在外部数据库中随后处理。

Description

一个灵活的呼叫记录机制

技术领域

本发明涉及电信系统中的一种记录机制并且特别涉及一种数据结构，使得在电信应用方面的业务控制处理中必要数据的记录变得容易。

本发明的背景

在电信系统中一个呼叫的处理过程中，大量数据需要被处理或采集。这种与呼叫有关的数据，根据特定呼叫中应用何种业务类型、使用何种协议与周围的网络通信、等等，而在呼叫中存在很多差别。数据包括对电信系统的不同种类的用户有用的信息。一个网络/业务提供商可能要建立计费记录，而另一个则可能要创立不同类型的统计。由于厂商需要与用户所要使用的数据无关而且还要能够与新业务一起增加新数据而不必改变已经存在的软件，这种与呼叫有关的数据记录必须用新的有效的方式处理。

存在很多可能的解决办法处理与呼叫有关的数据。一种显然的方式是使用常规的数据库收集信息，它会很快地导致容量问题。另一个解决办法是选择一种说明性办法，做内容的说明(例如，在Pascal中比较一个记录)。说明性办法的缺点同Pascal记录一样，不能体现所需要的灵活性。而另一个作法是在需要时，在对象之间循环发送数据，这会产生数据的复制。

在本领域的当前状态下，已经发现了几个关于面向对象的软件结构的概念，用于现代电信系统中的处理。EP-0524089A1、题为“Structure de logiciel pour système de traitement de données，notamment pour systeme de télécommunicaitons”描述了一种处理数据、特别是电信系统的逻辑结构系统。该结构根据CCITT X 200准则，特别简化了对象之间的实时通信。EP-0524077A1、题为“Structurede logiciel pour systeme de traitement d’informations”描述了一种对应用程序隐藏硬件和软件系统特性的结构。

EP-0470415A2描述了一种在电话系统中提供多个应用处理器访问公共数据库中与呼叫有关的信息的方法。只要通信仍进行，该信息被标记并暂时作为数据库中的记录存储。该信息特别用于在显示终端上直接查看，以供操作员控制的交换系统中的监控。

本发明的概述

因此，电信系统中存在一种建立呼叫记录机制的需求，使得用新业务和数据扩展所述它使用半呼叫原理系统而不影响系统已经存在的操作软件成为可能。

根据本发明的第一目的是，在执行呼叫处理的对话期间中，通过存储器指针，将数据本地地、暂时地存储在与每个被执行的对话期间有关的记录中，该指针还与一个标记单元相结合，通过该单元本地存储的数据将被唯一地标识并可在对话期间期间有选择地被一个记录视对象函数调用并存储在数据库中随后处理。

根据本发明的第二目的是，特殊的对话期间使用一个对话期间记录和一个事务处理记录，分别在对话期间中存储对象和数据的指针和标记，并且如果所需的数据信息在其下存储的标记单元是已知的，则从该记录可以定位对话期间内的所有对象和数据。

根据本发明的第三个目的是在呼叫处理中，定义一个具有与对话期间作用域类似结构的业务情况作用域，而且从所述对话期间引用并建立一个业务情况记录存储呼叫的执行对象，此外在业务情况记录中有一个事务处理记录，存储属于所述业务情况的数据。

根据本发明的第四个目的是，通过简单修改本地数据库中存储的标记列表，可以在任意时刻改变业务，而不干扰正在操作的开销系统。

根据本发明的第五个目的是标记单元用一个整数号码实现，优选的是二进制字，唯一地指定给对话期间中使用的每个执行对象或数据对象。

附图的简要描述

本发明，以及其目的和优点，可以通过参考下面的描述和所附的附图得到最好的理解，其中：

图1是一个具有对话期间控制器SC的对话期间的示意图，该控制器

处理几种业务情况，每个业务情况包括各自的发起呼叫OC，与

其它的包括各自的终接呼叫TC的业务情况通信；

图2表示一个对话期间控制器SC，根据本发明的方法和系统，使用一个对话期间记录存储执行对象的参考，并使用一个事务处理记录存储数据对象的参考；

图3表示根据本发明的方法和系统的集合，存储一个发起呼叫OC内的业务情况对象；

图4是控制对话期间中数据流的对象的表示；

图5表示当用于计费依据的数据从对话期间中提取时的一个例子；

图6用一个简单例子表示创建的被管理对象之间的关系；

图7表示根据图6的简单例子的完整的静态视；

图8是在呼叫处理过程中在事务处理记录中收集呼叫数据的一个简单的流程图；以及

图9是为包括一个输出而进行数据说明的一个简单流程图。

基础

为了用有效的方式处理本申请的主题，首先定义几个在如下描述中一直很有用的技术术语是比较实用的。

在电话呼叫处理交换系统中用于结构化软件的共同方法是把呼叫控制分成两半，半呼叫A(Half-Call A)和半呼叫B(Half-Call B)。控制半呼叫的软件在所谓对话期间(Session)的处理中执行。一个对话期间可以同时处理一种或几种业务情况(Traffic Cases)(例如在多呼叫情况下)。业务情况定义了对话期间处理呼叫的功能和数据。也要注意通过对话期间中的两个业务情况可以处理第三方呼叫，每个呼叫方一个情况。

为了简便起见，对话期间在不同的作用域内构成，因此引入对话期间作用域(Session Scope)和业务情况作用域(Traffic Case Scope)。对话期间作用域是由基本流对话期间控制器(Baseflow SessionController)SC控制的。对话期间控制器的主要任务是作为接入协议(Access Protocol)ACP的命令解释器并且在这些命令(消息)上做业务分析。例如，这包括启动和结束新的业务情况，从接入协议分配信息以纠正业务情况，启动新业务，等等。

对话期间内的每个业务情况由一个基本流控制。这样的基本流可以是一个发起呼叫(Originating Call)OC，或一个终接呼叫(Terminating Call)TC。这个基本流的主要任务是管理基本呼叫处理。例如包括建立/拆除一个呼叫(包括呼叫双方之间的电信业务协议(Telecommunication Service Protocol)TSP的处理)，命令建立/拆除连接(例如一个语音连接)，以及命令地址信息分析，等等。

为了在其中支持不同的作用域和控制逻辑操作，需要类似的数据结构。因此数据必须用某种方式构造以使实现和维护本申请成为可能。相应地存在两种不同类型的对象，在这个描述中称为执行对象(Executing Objects)和数据对象(Data Objects)。

一个执行对象在对话期间中执行，例如，控制对象、协议对象、资源对象等。一个纯数据对象包括、例如从远程业务协议消息(Teleservice Protocol Message)中接收的数据。也可能做一个这种类型数据的输出，为了计费或统计的目的。两种类型的对象有不同的语义并存储在对话期间中不同的记录中。这样一个记录称为对话期间记录(Session Record)并用于存储对话期间内指向控制和资源对象所示例的协议对象和资源对象的指针。存储在对话期间记录中的对象在整个对话期间中是公共的。为了存储纯数据对象的参考，使用了一个事务处理记录(Transaction Record)。用类似对话期间记录存储对象指针的方式，事务处理记录(也称做呼叫记录)用于存储，对话期间内或对话期间的业务情况执行中，由控制、协议和资源对象所示例的纯数据对象的指针。

对话期间记录的用户视称做对话期间记录视(Session RecordView)并在高抽象级上给用户一个对话期间记录的接口。类似地，事务处理记录的用户视可称做事务处理记录视(Transaction RecordView)并在高抽象级上给用尸一个事务处理记录的接口。

最后，还建立了一个业务情况记录(Traffic Case Record)，它是存储属于业务情况的对象的指针的记录。在这个记录中只存储协议对象和资源对象的指针。为了存储纯数据对象，应该使用事务处理记录。业务情况记录的用户视称为业务情况记录视(Traffic Case RecordView)并在高抽象级上给用户一个对话期间记录的接口。

优选实施例的详细描述

为了在电信系统中支持呼叫记录机制的不同作用域和相应的控制逻辑，我们需要一个合适的数据结构。数据必须构造为使实现和维护本申请成为可能。因此我们引入了两种不同类型的对象，分别是执行对象和数据对象，在对话期间中做记录。这两个术语，上面已经定义过，确实具有不同的语义并存储在所创建对话期间的不同记录中。当在一个集合中存储对象时，只是存储对象的指针的问题，存储该指针并且随后在这样的步骤中就不再复制对象本身。也意味着对于这样的指针存储，实际上就不需要知道特定对象的大小。

图1是一个由对话期间控制器SC控制的对话期间作用域的通用图。对话期间控制器作为接入协议ACP的命令解释器，ACP是用于用户或网络接入的类属术语。图1中很显然，对话期间包括一种或几种业务情况，而且这里的特定对话期间包括两种业务情况，都是OC类型(发起呼叫)的。OC类型的两种业务情况中的每一个依靠各自的业务情况通过处理电信业务协议TSP建立到另一个TC类型的业务情况。

如图2中所示，在对话期间范围中有一个对话期间记录SR，用于存储每个执行对象、例如一个所谓对话期间代理的指针PTR。依靠其它指针该对话期间记录是每个对话期间中数据结构的根。整个对话期间的数据对象依靠它们各自的指针PTR在事务处理记录中被找到。对话期间记录中的每一项有一个特殊名字或关键字，TAG，如果特定的系统操作员知道特定的名字或TAG，就可以在对话期间作用域内定位任一对象。

图3是业务情况作用域的通用图，这里包括一个发起呼叫类型OC，而是一个终接呼叫类型TC会有一个相应的结构。如果应用程序需要在对话期间中执行任意数目的并行业务情况，就必须引入这个作用域。业务情况作用域的结构因此类似于对话期间作用域的结构。对于对话期间中的每个业务情况创建一个业务情况记录，存储执行对象。类似对话期间记录，使用一个名字或TAG以及一个指针PTR。业务情况记录因此参照于对话期间记录。为了存储属于业务情况的数据对象，使用了一个业务处理记录TR，在这个业务情况级别上为数据对象创建一个表格。

对话期间或业务情况记录的每个用户有一个自己的视对象，通过它可以访问存储的执行对象或数据对象。

图4更详细地表示经过执行一个发起呼叫OC的对话期间的数据流。当一些数据被一个访问代理或输入代理接收时开始数据流。接收的数据被转换成AXE内部表示。转换的数据随后被存储在事务处理记录TR中。该数据对象带一个标记被存储。标记是一个整数，为这个特定的数据对象保留。其他用户，例如，一个应用程序分析，需要该数据对象可以通过标记并利用事务处理记录视对象TR_View从事务处理记录中取得。上面的例子也表明数据由输出代理通过电信业务协议TSP发送到其它半呼叫的情况。数据以参数发送，除数据外包括标识它的标记。

如上所述，数据对象存储于事务处理记录中(事务处理记录的同义词也称为呼叫记录)。事务处理记录TR，已经提到过总是通过一个视对象被访问。视对象给用户提供了到TR的高级接口，下面将进一步描述。每个存储在事务处理记录中的数据对象通过一个称之为TAG的名字或关键字做语义标识。TAG是一个整数，在示范实施例中是一个为特定数据对象保留的16比特字。通过使用诸如事务处理记录这样的动态存储，在那里数据对象是带TAG存储的，可以支持非常灵活的输出机制。换句话说，将会特别容易地、且不影响电信系统的常规操作，在任意特定时间段根据用户为后面分析的需要而提取任意选取的数据对象。其结果是将会特别容易地根据这样一种结构化的操作方式为系统操作添加附加业务。

假设代理接收协议ACP的参数“呼叫方号码”。数据将被转换成一个AXE内部表示并与一个专用标签，“AppCallingPartyNumberTag”，一起存储在TR中。需要呼叫方号码的TR的其他用户随后转到TR并请求带TAG“AppCallingPartyNumberTag”存储的数据对象。一个接口、应用平台标签接口(Application Platform Tags Interface)ATI、包括函数所使用的标签数。ATI也包括保存新标签时要遵循的法则。

正如已经提到过的TR总是通过视对象而被访问的。视对象有两个主要任务。第一个是代表面向TR的定制的接口。TR的每个用户应该有一个对TR中内容的专用接口。第二个任务是作为TR的句柄对象，该句柄保证在所有句柄都被删除以前，TR不会被删除。

视对象也用于访问所存在的其它两种类型记录-对话期间记录和业务情况记录-的内容。如上面提到过的，视对象的一个任务是在高抽象级上给用户提供面向记录的定制接口。定制意味着该接口使用户只访问需要被访问的对象，可能只是记录中整个内容的一部分。

针对事务处理对象和业务情况对象的视对象的第二个主要任务是作为一个句柄。只要记录有一个句柄，它就不能被删除。当记录的最后一个句柄被删除时，该记录以及它的所有内容也从本地存储器存储中被删除。显然这就建立了一个很方便的本地存储器存储管理。

已经提到过的呼叫记录输出机制用于输出事务处理记录内容的一些部分用于后处理。应该记住的是对话期间记录和业务情况记录以及事务处理记录的内容只在特定对话期间持续过程中存在，当对话期间结束时消失。输出机制是围绕多个包含标记列表的被管理对象而建立的。在电信系统操作中，例如，需要收集计费数据以便能够正确地对不同用户计帐。在图5中，示范了一个对话期间中可能发生的情况。一个控制对象“计费(Charging)”已打开了一个对象Cro_Type。这个特定的Cro_Type对象包括一个从数据库中取出的标记列表，表示数据对象被从事务处理记录中提取。随后命令Cro_Type编辑一个由存储在数据库中的标记列表所标识的数据对象组成报告。控制对象然后使用Cro_Type接口，命令它收集特定对话期间存在过程中的数据。数据可以被填入数据区，然后送到一个后处理节点。此后，由于增加了业务而改变计费基础可以在任意时刻通过简单地修改标记列表而根本不干扰具有根据本发明结构的现有系统就可实现。

这种作法的有效结果是，即使不同对话期间的内容被定义为本地数据，也可以同时使用该内容的需要部分，好象它构成了全局数据一样。例如，本地和全局数据之间的区别是后者一般必须被分配到预定的存储位置，以便其他用户能够访问。

在说明性的实施例中，我们使用三种类型的被管理对象使这里所描述的灵活输出机制得以实现。它们被表示为CroServiceTemplate、CroType和CroCustomerTemplate。第一个被管理对象类型，CroServiceTemplate，用于说明什么数据对象可能为一种特定的基本或补充的业务而提取。CroServiceTemplate包括一个属性，可能的TAG，表示哪个数据可能为一个特定业务而从事务处理记录TR中提取，例如在这种情况下是为一个“基本通话(Basic Call)”或一个“三方通话(Three Party Call)”。

第二个被管理对象类型是CroType，用于说明某个输出类型。CroType的每个实例与一个或多个CroServiceTemplate实例相联系。在这些CroServiceTemplate中的数据联合确定什么数据可能为一个特定的CroType而输出。

第三个也是最后一个被管理对象类型是CroCustomerTemplate，它是含有如下信息的被管理对象：哪个数据为一个特定用户以一个特定输出类型，CroType，而提取。

图6表示具有如下条件的小例子：

-有两个顾客，A和B。

-有两个业务，“基本通话”和“三方通话”。

-有两种CroType，CroType1和CroType2。

因为有两种业务，我们需要两个CroServiceTemplate：

-CroServiceTemplate基本通话(Basic Call)，包括标记1、2、

5和8。

-CroServiceTemplate三方通话(Three Party Call)，包括标记

1、2、6和9。

这意味着对于“基本通话”我们可以输出存储在TR中的带有标记1、2、5和8的数据，而对于“三方通话”业务我们可以输出标记1、2、6和9下存储的数据。

我们然后定义了两个输出类型，CroType1被设计为它能够输出与两种业务有关的数据而CroType2被设计为它能够输出与基本通话有关的数据。在图6中，可以看到基本结构和所建立的被管理对象之间的关系。

每个顾客和CroType需要一个CroServiceTemplate，以使输出机制“呼叫记录输出(Call Record Output)CRO”能够执行所有CroType对所有顾客的输出。这使这个例子总共有四个CroServiceTemplate。在图7中表示了所产生的结构。顾客A需要CroType1的所有可能标记以及CroType2的标记号1和2，顾客B需要所有CroType的所有号码比8低的标记。然后我们就有了一个最后的结构，输出机制CRO需要进行适当的分配。我们规定了来自所有不同的Crotype的哪个数据满足所有不同顾客的需要。

图4中数据流的最后部分描述了何时将数据送到其它半呼叫。半呼叫通过电信业务协议TSP通信。TSP携带自身标识参数。一个参数包括一个数据对象并由一个标记标识。接收机可以通过查看标记确定接收什么数据。用于标识TSP上的一个参数的标记与用于标识存储在TR中的数据的标记相同。

在图8中通过呼叫处理过程中收集事务处理记录中呼叫数据的简单流程图中的多个步骤做了总结。这样的处理起始于步骤100。在处理的第一个实步骤101中，一个消息通过一个外部协议接收。它是在系统内动态处理中的一个协议代理中接收的。下面的步骤102中数据从外部表示转换为内部表示。一个数据对象在处理中建立。这个数据对象包括被接收数据的内部表示。

在第三步骤103中，数据对象被存储在事务处理记录的一个唯一的标记元件下。在呼叫处理过程中，数据在第四个步骤104中使用一个事务处理记录视对象，从事务处理记录中被提取，然后利用标记单元得到正确的指针PTR恢复指定的数据。

当呼叫结束或为了统计或计费目的而需要输出呼叫数据时，功能调用记录输出在第五个步骤105中被调用。这个功能访问数据库找到输出的数据。结果该功能得到一个标记单元列表。所需要的数据在步骤104中从TR收集并放入输出缓存器。这个缓存器可以输出到一个外部介质。该数据随后可以做后处理，例如为了产生计费信息，等等。

最后在图9中通过三个步骤表示了一个简单流程图，数据的说明被包括在一个输出中。该过程以步骤200开始。在步骤201中业务提供者或任何其他管理系统的操作员决定为不同的呼叫类型输出何种数据。这些不同的输出类型在第二个步骤202中通过在模板中填入输出标记列表来指定。通过，例如，借助独立终端和/或键盘输入标记列表，在最后步骤203中这些模板被存储在数据库中。输入标记列表将不会干扰电信系统中一般的呼叫处理：启动和结束业务情况、从接入协议向正确的业务情况分配信息、启动新业务，等，但是，当输入时，将要决定哪些数据将被存储在数据库中由于后处理。

本领域的技术人员将会理解的是可以在不背离本发明的精神和范围的情况下，对其做不同的修正和修改，该范围将由附加的权利要求所规定。

Claims

1.一个在电话或电信系统中用于灵活呼叫记录机制的方法，使得可以用新业务和数据扩展所述使用半呼叫原则的系统而不影响系统的一个已经存在的主操作软件，其特征在于，在执行对话期间呼叫处理时，通过与每个被执行对话期间有关的记录(SR、TR)中的存储器指针(PTR)完成数据的本地临时存储，所述指针(PTR)还结合一个标记单元(TAG)，通过它特定的所需的本地存储的数据被唯一标识而且可以在对话期间持续过程中有选择地被记录视对象功能调用并随后存储在一个外部数据库中用于随后的处理。

2.根据权利要求1的方法，其特征在于，特定对话期间使用一个对话期间记录(SR)和一个事务处理记录(TR)，分别在所述的对话期间中存储对象和数据的指针(PTR)和标记(TAG)，而且，如果在其下存储了所需要的数据信息的标记单元(TAG)是已知的，就可以在对话期间存在过程中从该记录中提取对话期间内的任何对象或数据。

3.根据权利要求2的方法，其特征在于，在呼叫处理中定义了一个业务情况作用域，具有类似对话期间作用域的结构，而且业务情况记录以所述对话期间记录(SR)索引，建立业务情况记录以存储呼叫的执行对象。

4.根据权利要求2的方法，其特征在于，在所述业务情况记录中事务处理记录(TR)存储了属于所述业务情况的数据。

5.根据权利要求4的方法，其特征在于，通过简单修改存储在本地数据库中的标记列表可以在任意时刻改变业务，而不干扰现有的正操作的开销系统。

6.根据权利要求5的方法，其特征在于，所述标记单元(TAG)由一个整数号码实现，优选的是一个二进制字，唯一地分配给每个被存储的执行对象或数据对象。

7.一个在电话或电信系统中的呼叫记录机制，使得可以用新业务和数据扩展所述使用半呼叫原则系统而不影响系统的一个已经存在的主操作软件，其特征在于，通过一个存储器指针(PTR)，在执行呼叫处理时，本地临时对话期间对象或数据被存储在与每个被执行对话期间有关的记录中，所述指针(PTR)还结合一个标记单元(TAG)，通过它特定的需要临时本地存储的数据被唯一标识而且可以在对话期间持续过程中有选择地被记录视对象功能调用并随后存储在一个外部数据库中用于随后的处理。

8.根据权利要求7的系统，其特征在于，特定对话期间使用一个对话期间记录(SR)和一个事务处理记录(TR)，分别在所述的对话期间中存储对象和数据的指针(PTR)和标记(TAG)，而且，如果在其下存储了所需要的数据信息的标记单元(TAG)是已知的，就可以在对话期间存在过程中从该记录中提取对话期间内的任何对象或数据。

9.根据权利要求8的系统，其特征在于，一个业务情况作用域，具有类似对话期间作用域的结构，而且业务情况记录以所述对话期间记录索引，建立所述业务情况记录以存储呼叫的执行对象。

10.根据权利要求9的系统，其特征在于，在所述业务情况记录中事务处理记录(TR)存储了属于所述业务情况的数据。

11.根据权利要求10的系统，其特征在于，通过简单修改存储在本地数据库中的标记列表可以在任意时刻改变业务，而不干扰现有的正操作的开销系统。

12.根据权利要求11的系统，其特征在于，所述标记单元(TAG)由一个整数号码实现，优选的是一个二进制字，唯一地分配给每个被存储的执行对象或数据对象。