CN1126357C - 用于在通信网络中的数据采集和处理系统 - Google Patents

Abstract

供在诸如英国公共电话交换网等通信网络中使用的一种网络间通话会计系统，允许在定价与收费之前，将通话记录按照应对通话付费的网络经营者分类。设置了一个包含专家系统的数据分析器(7)，用于不能确认的通话记录。该数据分析器(7)能施加省缺或补正值，或者能将无效数据输出到等待更新参照信息的一个挂起进程。不能修补的数据输出到一个贮存槽供管理目的。一个定价与收费机处理已按照可记帐实体分类的数据，并且包括进一步的数据分析装置，处理因定价与收费相关的信息的原因而失效的数据。

Description

用于在通信网络中的数据采集和处理系统

本发明涉及用于在多网络通信中的数据采集与处理的一种数据系统。

在一个单一网络中出现诸如电话通话或数据传输等通信事例时，登录与处理与这些通信事例相关的数据是已知的。通常，在一个公用交换电话网(PSTN)中，有关通话持续时间的数据被采集，并至少对于日期时间及通话类型进行处理，以便网络经营者能在送往启动通话的用户的帐单上生成一项。

近年来，随着用户能得到的服务选择与通话类型的大规模增加，而必然地导致PSTN的数据系统日愈复杂。例如，由于0800号码的引入，不再由启动的用户付费。在PSTN上的许多更复杂的服务接踵而来或可以利用，诸如呼叫转送，其中第一用户对一个选中的号码的呼叫由网络自动转送给一个不同的号码，费用的差价是由接收用户负担的。

通信网络的另一显著改变过程中的特点是多个网络经营人员的出现。过去PSTN主要是由作为国家内部结构的政府部门运行的。当前并且日益增加地，PSTN的私有化及受规章制度的垄断的放松意味着用户可得到更多的网络经营人员而为了实际的原因这些网络经营人员必须提供网络间互连。这意味着网络经营人员不仅必须考虑发生在他们自己的网络或者在有限数目的独立但相同管理方式的互连网络中的通信事例，但也要考虑发生在理论上不同类型的非常大数量的竞争网络中的通信事例而为用户提供广泛的各式各样的服务。

因此，与发生在一名经营者的网络外面但终止在或者只是经过该经营者的网络的通信事例相关联的数据采集与处理日益重要。

在Obuchowski的论文“通路经费与收益系统结构”，(AT&T技术学报，卷66，第三号，1987年5月美国，纽约)73-81页中公开了预测通路经费与收益的一个数据系统，供80年代将本地与长途媒体分开(剥夺)之后美国型式的一个PSTN中的交换机间媒体使用。

当通话通过一个以上经营者的网络时，互相传送通话的经营者之间的价格与收费协议已提到日程上来。这种协议可从简单的发送者收取全部费用(SKA)协议变化到复杂的价格公式。

在电讯中独立的网络经营者或管理机构之间曾建立过由负责发生通话的网络管理机构采集数据的惯例。如果随后这一通话终止在第二网络上，则与该第二网络相关的管理机构依赖于负责第一网络管理机构所采集的数据，诸如用于记帐目的的数据。以富士通有限公司名义的英国专利申请号GB2254224中，描述了根据智能网络技术的避免外出国际长途通话的双重记帐的一个系统。

但是电讯环境在政治上与技术上正在迅速改变。随着竞争的加剧，网络管理机构不仅对发生在它们自己的网络中的通信量还对发生在别处但通过或终止在它们自己的网络中的通信量越来越关注。如果网络中出现的通信量属于一个竞争经营者或管理机构，希望至少有可能互相校验验竞争经营者的帐目。

在已知的装置中，由于本地交换机在出现通信量时采集它们，关注一个PSTN中的通话的数据采集点是设置在一个网络的本地交换机上的。但是这种装置对于网络间通信量并不提供数据采集。即使存在着采集进入一个网络的通话数据的数据采集点，但包含在将这种数据处理到任何详细的层次中的计算是难以实现的。例如，估计在1992年3月以前的十二个月中每天从包含Isle of Man及Cellnet蜂窝式网络在内的其它网络管理机构进入英国电讯有限公司(BT)在英国经营的PSTN中的通话总数为15.4兆次通话。预期到1995年3月的年度中这一数字将增加到每天27兆次通话的数量级。包括发生在BT PSTN内部的通话在内的全部通话事例，1995年的预期数为每天60兆次通话事例。

尽管包含如此大量的数据，已发现使本发明设计出一种用于采集与处理关于进入一个主电讯网络(英国PSTN)中的通话的数据的方法是可能的，该方法能以充分细节产生输出以允许相关的网络管理机构生成记帐信息，这种信息不仅能适当地分配给外部网络管理机构，还能支持分项列记帐单。这便是，记帐信息能够充分详细地分解到甚至指明单次的通话，只要它们满足以当前可从英国电讯有限公司的英国PSTN的国家帐单系统中得到的分项列记帐单的方式预先选定的标准。

按照本发明的第一方面，提供了一种用于在一个第一通信网络中采集与处理有关通信事例的数据的方法，其中该网络至少包括一个直接或间接连接在一个第二通信网络上的连接点，利用该连接点发生在所述第二网络中的一个通信事例能传输进并且通过或者终止在所述第一网络中，该方法包括下述步骤：

i)在所述连接点上的数据访问点上采集数据，所述数据涉及所述第二网络中发生的一个通信事例并包括关于所述通信事例的记帐的路由信息及至少一个参数测量值，诸如持续时间；

ii)将所述数据传输进一个数据处理系统；以及

iii)处理所述数据以生成记帐信息。

通过在第一网络与另一网络之间的连接点上采集数据，第一网络的管理机构便能得到有关进入第一网络的通信事例的第一手信息，从而有能力交互检验由其它网络经营者或管理机构提供的数据。

按照本发明的第二方面，提供了一种用于处理在与另一个网络的连接点上采集的PSTN中的数据的数据处理装置，该装置包括：

i)一个数据输入端，用于输入涉及来自一个通信网络的通信事例的数据，所述数据至少包括多种分类特征中的一种；

ii)校验装置，用于检验在数据输入端上接收的数据的完整性及充分性；

iii)一个数据分析器，用于分析被校验装置拒绝的数据，及用于提交补正后的或省缺的数据给校验装置；

iv)定价装置，用于按照可更新的参照信息定价由校验装置输出的经过校验的数据；以及

v)输出装置，用于将来自定价装置的经过定价与校验的数据输出到存储单元中，各存储单元是与一种或多种所述分类特征相关的数据所专用的。

最好，定价装置也能确认数据并将有错误的数据输出到一个数据分析器，该分析器可以是上述数据分析器或者另一个分析器，使得受到破坏的数据得从重新格式化或者校正，从而作为一个通信事例的有效记录重新输入该系统。

这一进一步的数据分析步骤也可以(或替代地)用于分析与不同类型的错误相关的数据。例如，对已被校验装置定位的错误数据所进行的数据分析可以是原则上针对格式与路由信息错误的而来自定价装置的错误数据则可能是原则上针对定价信息的错误。

分类特征通常是使得存储单元各保存与可向一个公共会计实体收费的通信事例相关的数据，例如发生在一个公共的对应通信网络中的通信事例。

可以在上述数据处理装置的若干阶段的任何一阶段上施加分类特征。然而，例如在一个PSTN中，通常出现的错误数据的性质使它最好在(iii)与检验装置相关联的数据分析器与(iv)定价装置之间设置分类装置。因此，定价装置在已经分类的数据上工作。如果分类特征涉及相对于由数据表示的通信事例而将被收费的不同实体，那末这种装置还能具有这样的优点，使得定价装置在施加与各个实体相关的制约时有可能被简化。

应当指出，诸如BT PSTN的网络包括本地与长途交换机两者，并且不仅提供交换机间通话传输还提供发送给最终用户的本地通话。这意味着，支持收费或帐单确认所要求的数据采集与处理必须复杂得足以处理极宽的变量范围。这是与一网络只提供长途交换机间传输或只提供本地通话发送的情况的不同之处。

按照本发明的第三方面，提供了一种供在一个第一通信网络中使用的数据采集与处理装置，该第一网络连接在多个其它网络上并接受来自它们的通信事例，该装置包括：

a)登记装置，用于登记发生在所述其它网络之一中的进入该第一网络的一次通信事例；

b)用于格式化所述通信事例的一个记录的装置，该记录包括识别其它网络中的所述一个的数据及一个参数值，诸如与该通信事例相关的持续时间，

c)用于确认所述记录的确认装置，

d)定价与收费装置，用于将定价与收费数据与一个确认的记录关联，并提供经过定价、收费与确认的记录的一个分类的数组，该数组是按照这些其它网络的本体分类的，以及

e)分析装置，用于分析被该确认装置拒绝的记录，该分析装置配置成根据拒绝的原因以至少三种方法的一种处理被拒绝的记录，所述三种方法为将一个未被确认的记录中的值设定为一个最佳吻合的值，或将未被确认的记录中的值设定为省缺值，或者归档或转储该未被确认的记录，将已经以第一或第二方法处理过的记录作为确认的记录直接或间接传输到定价与收费装置。

按照本发明的第四方面，提供了一种在采集与处理与多个网络相关的通信记录中使用的数据采集与处理系统，其中所述系统包括至少一个输入端，用于接收在所述多个网络中的一个第一网络与所述多个网络中至少另一个之间的一个连接点上生成的通信记录，所述记录提供在其中发生一个相关通信事例或该通信事例从其中进入所述第一网络的该网络的识别及一个与该通信事例相关的对记帐有影响的参数测定值，诸如持续时间，该系统还包括确认装置，用于确认该记录的格式与路由信息方面；数据分析装置，用于分析被所述确认装置拒绝的错误记录，该分析装置能分类所述错误记录及将省缺值施加在至少一类错误记录上；数据分类装置，用于按照所述网络识别分类经过确认与省缺的记录；以及定价装置，用于接收经过分类的记录并根据包含在其中的信息生成供向与识别的网络相关的实体开帐单中使用的记帐信息。

下面参照附图，只是作为一个示例，描述按照本发明的一个实施例的系统，附图中：

图1图示用于采集与处理包含通话信息的数据以便支持进入一个电讯网络的通话事例的记帐系统的一个系统的系统结构；

图2、3、与4示出图1中所示的系统的概要流程图；

图5示出图1的系统的硬件与通信设备图；

图6示出用在按照图1的系统中的流部件与数据分析器之间的软件系统结构；

图7示出提供一个公司系统用于在图1的系统中的硬件的系统结构；

图8示出用在图7的公司系统中的成批阵列处理系统结构的示意图；

图9与10示出用于图1的系统中的与自交换机的数据轮询相连的交换机文件及高级协议数据单元(APDU)格式；

图11至21示出用在按照图1的系统的流部件与数据分析器中的流程图；

图22示出图1中的系统的部件之间的进程交互作用；

图23至30提供实体生命周期图，其中示出各实体内的一个记录可能处于的状态，及通过何种动作可以从该状态到达何种其它状态；

图31与32示出用在图1的系统中的一个专家系统在数据聚集且起动了一条规则之后的议程状态，及一个模式图；

图33与34分别示出用在按照图1的系统中的数据分析器中的一个规则库系统与事例库系统的目标层次结构；

图35示出包含在为按照图1的系统中的数据分析器建立一个专家系统/ORACLE接口中的设计原则；

图36示出用在按照图1的系统中的公司系统的数据模型；

图37至43示出与用在图1的系统中的数据分析器的操作相关的流程图；以及

图44示出数据流，着重在与用在按照图1的系统中的公司系统相关的数据。

在下面的描述与图的某些部分中，时而使用了名词“INCA”与“IDA”。它们代表网络间通话记帐(整个系统的一种描述)，及代表INCA数据分析器。后者为对包括一个专家系统及与流部件6接口的数据分析器7的参照。

以下述方式陈述后面的说明：

1.图1：系统结构方框图；

2.图2、3与4，进程概要流程图

i)至连点与DDC

ii)流部件

iii)公司系统(或框)

3.图1与5至8，硬件、通信设备与软件系统结构

i)POI与DDC

ii)流部件与数据分析器

iii)公司系统

iv)用户框

4.图9与10，通话记录与数据格式

i)通话记录

ii)将数据结构映射在交换机数据上

5.图11至19及22至30：流部件与数据分析器进程的更详细的流程图

i)流部件：DDC轮询

ii)流部件：文件进程

iii)流部件：DDC删除

iv)数据分析器：进程

v)实体生命周期

6.图31至35：专家系统

i)概要

ii)规则库通用规则

iii)事例库

iv)Oracle接口

7.图20、21及37至43：通过数据分析器使用专家系统

8.图36与44：公司系统、数据分析与定价及收费

9.数据检查跟踪

1.图1：系统结构方框图

参见图1，将系统设置成便于在诸如BT PSTN等第一网络1中采集涉及发生在或来自第二网络2中的通话事例的数据。该数据是在由所述第一网络1的交换机提供的互连点(POI)3上采集的，并被带到PSTN中大约十个地区数据采集器(DDC)5中的一个。它们保存包含各进入通话的路由信息的数据，从而允许标识诸如通话的意向目的地、进入的通话来自的载体、使各次通话作为一个事件对待的分项列记数据、以及(最好还包含)使得在第二网络2中单纯地过渡的通话也能精确地相对于产生它们的网络进行记帐的通话线路本体。

一个流部件系统6轮询各地区数据采集器(DDC)5，该系统主要对照路由参照模型在文件与记录两级上扩展与确认通话数据。(虽然BT PSTN的地区数据采集器5拾取相关的数据，它们的作用也同样可以由记帐装置的其它部件系统提供，诸如称作网络调解处理器的)。流部件6将它认为无效的数据转换方向到数据分析器7上，在其中用一个基于知识的系统来确定无效性，并且在可能时力图变换该数据来解决问题。由于通常会失去作为一个可记帐的输入的无效数据，这是本系统的一个重要部件。按照从那里接收到相关通话的第二网络5的经营者，同时流送经过确认的数据，并向前传送到公司系统8。

流部件6提供下述功能：

·向各DDC轮询等待由本发明的数据系统处理的文件

·对照路由参照模型确认文件及其通话记录。

·扩展通话记录并分配给正确的电讯网络经营者。

·拒绝无效数据到IDA7。

·将来自IDA7的原始文件复制到原始记录后备接口目录。

·一旦将数据固定在接口目录中，便从DDC5中删除该文件。

·向用户提供用户接口以输入路由参照模型数据。

·提供通过流部件的一次完整的数据检查跟踪。

·提供用户监视流操作的操作及数据完整性的能力。

数据分析器7提供下述功能：

·为包含一个或多个错误的文件轮询接口目录。

·如果错误的通话记录是有效通话记录但不与路由参照模型匹配，便将它们保存在一个挂起区中。

·提供一个用户接口，使得在更新路由参照模型之后，用户能重新流送数据。

·按照规则规定将省缺通话记录值施加在不正确的字段中。

·流送任何由于超过了错误阈值而尚未流送的正确数据。

·流送任何校正后的数据。

·在通话记录级上提供一次通过IDA7的完整的数据检查跟踪。

由于公司系统不仅进口从通话参数导出的因素还进口从两个互连的网络1、2的经营者之间的关系导出的因素，因此公司系统8现在也有重要的角色要扮淀。在记帐过程中一次通话所具有的影响将部分地由诸如相关的经营者之间的“服务级协议”等因素确定。这些因素正是在公司系统8上通过参照可包含查找表与/或国家收费数据库(NCDB)9在内的各种信息源而起作用的。特别是参照该数据库，还在这里考虑到诸如随时间变化的收费率等的记帐。

从而，从公司系统8的输出是最终用在记帐系统中的表示从至连点3采集的原始通话数据，及参照必须应用的诸如经营者特定的与随时间变化的参数等有关参数处理过的数据的信息。将这一输出提供给一个客户系统10，用户可用个人计算机来访问该客户系统。

2.图2、3与4：进程概要

参见图2、3与4，流程图可用于给出响应一次通话事例的操作中的上述的进程概要。

2(i)至连点与DDC

图2示出响应一次进入的通话由POI交换机3与DDC5执行的进程步骤。所有这些步骤都是已知的，用于本发明的目的的交换机3与DDC5未做修改。

参见图2，一次进入相关网络1或从其中出去的通话在步骤200在POI交换机3中生成一个通话记录。在步骤210，交换机3给予每一次通话事例在一个序列0-9999中的“文件生成号”。在步骤220，交换机3将通话记录组合进高级协议数据单元(APDU)中，并将这些APDU组合成文件。

在步骤230，DDC5轮询交换机3查找APDU格式中的所有通话记录数据。在步骤235，DDC5以首部APDU及尾部APDU的形式加上控制数据。DDC5还在步骤240给予各文件0-999999范围中的一个文件序号，并在步骤245给予各APDU一个在范围0-16353中的APDU序号，APDU是二进制格式的。在步骤250，DDC5将该文件放置在一个目录结构中，流部件6便能通过轮询从其中取出它们。同时，在步骤260，在一个称作DIRINDEX的总目文件中为该文件生成一个登记。这一总目文件中包含所有可供流部件6轮询的文件的一张表。

2(ii)流部件

参见图3，在步骤300，流部件6周期性地轮询DDC目录结构，将通话记录输入一个随机存取存储器(RAM)中，每一个文件加载进一兆字节中。这一轮询进程包括复制最新的DIRI NDEX文件的步骤。在步骤310，它实际上可以是在步骤300的DDC轮询进程的一部分，将数据从二进制转换成ASCII(美国信息交换标准码)格式。

在步骤320，流部件6执行通话记录的确认。如果一个通话记录是不完整或不正确而不能得到确认时，不是进行到流部件6中的后续处理步骤中而是最终到一个记帐进程，它被转换到一个接口目录(步骤330)供进一步在不正确数据分析器7中分析。

然而有效数据在步骤340进行到一个识别进程，在其中用通话记录中的数据确定该通话起源于哪一个其它网络、或从哪一个其它网络进入该BT PSTN、或者在某些情况中在哪一个网络中终止它。在步骤350将表示用于记帐的有关网络经营者的代码加在该通话记录上，然后根据该代码将文件分解与重构。因此通话记录在这一点上能够按照网络经营者或其它有关实体(它至少首先应为这些通话的费用负责的)存储。

在步骤360与370，流部件将新构成的文件输到公司系统8并从DDC5上的FTAM文件存储器中删除文件数据。

参见数据分析器7，由于未被确认的数据不能记帐，因此分析器7具有重要的作用。数据分析器7在步骤380轮询接口目录查找流部件6在步骤330输入的错误文件。从而数据分析器7有三次不同的机会将错误数据放回系统中。

在步骤382，期望对数据进行修补。如果能够修补，便将修补后的数据返回到接口目录，流部件6便能从那里拾取它。在步骤384，数据分析器7将省缺值施加在不能修补的数据上。某些数据元素不能以这一方式“修补”，诸如由于它会影响数据检查跟踪。最后在步骤386，数据分析器7检验是否只是在数据与路由参照模型(RRM)之间有一个失配。路由参照模型是一个给出路由信息的数据库，并用于在DDC5上来识别诸如一次通话的目的地。RRM的复制品保存在通信网络中不同的地方，并且如果一份复制品没有及时更新或错误地更新，便能出现数据中的失配。如果出现这种情况，数据分析器7便将这些通话记录输入到一个挂起文件中(步骤388)，后者允许RRM经过检验之后将它们放回到流部件6进程中。

如果数据分析器7不能以任何上述方法处理数据，它便在步骤390将数据输出到一个“贮存槽”中。这意味着该数据实际上丢失了并且永远不能记账。然而从长期观点上，它可能在分析中用以便对系统进行改变与校正。

2(iii)公司系统

参见图4，经过流部件6确认与处理的文件级上的数据被输入到公司系统8，其中的第一步骤400为确认文件序号。公司系统8按文件序号的次序处理文件，但流部件6是并行处理来自不同的交换机3的数据的。如果文件序号是错的，公司系统便使该文件失效并停止处理之(步骤410)。

如果文件序号是可接受的，公司系统8进行到步骤420来确认通话记录，这一次主要不是如在流部件6上那样关于RRM的，而更着重于与可记帐的实体及可记帐的实体与诸如BT的第一网络1的经营者之间的关系有关的数据。可记帐的实体与BT将已进入服务级协议(SLA)而通话记录可能表示在当前的SLA下可记帐实体所不能利用的通话类型。公司系统8在步骤430取出该记录作为无效记录，并试图修正错误的通话记录。如果该通话记录能被修正，便在440将它送交被集积并重新输入到公司系统8。如果它不能修正便在步骤450将它存储起来供分析之用。

同时在步骤460将有效通话记录提交给公司系统定价机，在定价机上按照NCDB9、相关的可记帐实体与BT之间的SLA及任何其它相关信息对单个的通话记录定价。然后在步骤470便可将定价的通话记录加载进一个汇总数据库供对有关的可记帐实体收费，并且还将通话记录输出到光盘(步骤480)供存储。

客户框10在每周的基础上接收从汇总数据库卸载的信息。各客户框10专用于单一的可记帐实体并且也能用于访问光盘存储器以只获得其“自己的”通话记录。

3.图1、5、6、7与8：硬件通信与软件系统结构

3(i)互连点3及DDC5

交换机3与DDC5具有已知的类型，在这里不作详细描述。简要地说，它们的操作如下：

参见图1与2，任何进入或离开英国电讯有限公司(BT)经营的英国PSTN的通话现在都通过作为互连点(POI)3的一个数字电话交换机。所有与本发明的数据系统相关的交换机当前都是数字中继转接单元(DJSU)、数字本地交换机(DLE)或数字主转接单元(DMSU)类型的系统X电话交换机。

如图2的步骤200所示，每一个进入或离开BT网络1的电话通话以称作英国电讯通话记录类型6的格式在POI交换机3中生成一个通话记录。在步骤230，DDC5每天轮询系统XPOI交换机3查找所有APDU格式的通话记录数据。轮询在高速BT数据链路上用文件传输访问与管理(FTAM)协议进行。DDC5单纯地作为来自POI的通话记录文件的采集器工作：在DDC内不进行通话记录处理。DDC不专用于通话记录轮询，但执行各式各样的其它数据采集、处理及提交任务。

为了使流部件系统6得到对DDC5上的FTAM文件存储器的访问，它必须提出标识符。这是通过分配一个网络节点身份(NNI)作为一个相关的终端系统给流部件6而实现的。该NNI然后连同一个口令被用作一个用户名以得到对FTAM文件存储器的访问。

3(ii)流部件6及数据分析器7

参见图5，流部件6与数据分析器7的硬件与通信设备图如下。(应理解图5的通信设备系统结构只是表示适合不同环境的许多通信设备系统结构中的一种。)流部件6具有一个“热备用”流部件框后备装置(SBB)6a，它在主流部件系统6上出现故障时立即切入，并且两者都能设置在运行UNIX操作系统的惠普HP8575小型计算机上。流部件6与SBB6a可连接在局域网络(LAN)515上。

流部件6(或热备用6a)从DDC5(未示出在图5中)轮询到的原始数据用一个光盘存储系统(未示出)备份。数据是用FTAM(文件传输、访问与管理)在BT巨流高速数据链路及多协议路由网络(MPRN)510上轮询的。MPRN510为依从OSI(开放系统互连)的。在流部件6与数据分析器7之间有直接通信链路515，而一个“以太网”桥路则给予流部件6及数据分析器7对至少一个广域网(WAN)510的访问，诸如BT为PSTN所使用的。WAN510又依次给予位于主BT PSTN网络管理与数据中心的公司系统8及客户框10访问。这意味着网络管理与数据中心能够输入与输出数据，诸如供分析及输入初始及更新后的路由参照数据。

参见图6，数据分析器7可设置在一台惠普HP9000上。流部件6及数据分析器7的软件利用下述技术：

·用于批处理的IEF

·用于专家系统能力的ART/IM

·HP/UX版本9.0

·作为一个PC客户用于报告的商业目标程序

·Oracle版本6

-SQLFORMS  3

-SQL*报告写程序1.1

-PL/SQL版本1.0

-PRO*C

-SQL*NET TCP/IP版本1.2

所有这些都是已知的并且是公开出售的。例如“IEF”是来自James Martin联合公司的“信息工程设备”计算机辅助软件工程(CASE)软件，它是生成可执行代码的一种软件工程工具。数据分析器进程物理地在数据分析器7平台上运行，并使用SQL*NET以连接在流部件6平台上的一个Oracle数据库60上。为了在MPRN510或一个适当的TCP/IP载体网络上访问位于流部件6上的Oracle数据库60，流部件/数据分析器商业目的Oracle用户65也能使用SQL*NET TCP/IP(传送控制协议/互连网络协议)。

流部件6与数据分析器7共享数据库设施60，而用户可能需要进行访问诸如对流部件(6)在确认时使用的参照数据进行检验或更新。数据库设施60尤其还维持对哪些来自DDC5的已被处理过的文件的控制，并包含路由参照模型的一个版本。

IEF将PRO*C代码生成为IEF代码61及外部动作块(EAB)62，如图6中所示。流部件/数据分析器软件库63是一组可从EAB62内部或ART-IM(用于信息管理的自动推理工具)64调用的“C”与PRO*C模块。ART-IM是拥有专利的专家系统应用开发软件。ART-IM开发是在“技术作业室”对专家系统的一个主题(Motif)接口内进行的。一旦专家系统在“技术作业室”内通过了单元调试，它便从“技术作业室”内部通过生成“C”模块而展开。因此，例如可以通过在一个OS/2工作站上生成IEF代码61并将该代码与展开平台上的EAB62、流部件/数据分析器软件库63与ART-IM代码库64相链接而建立进程。

3(iii)公司系统8

参见图7与8，公司框(或系统)8包括一台运行UNIX操作系统、ORACLE关系数据库管理系统(ROMS)及用来自James Martin联合公司的IEF CASE软件编写的用户应用软件的惠普小型计算机70“翡翠890/400”。

在公司框8内，按照复杂的定价与收费参照表定价所有的通话记录，并增加ORACLE汇总表。参照表提供交换机配置数据、路由参照数据、记帐协议、定价及收费数据以及各种例外类别。定价与收费参照表是从BT的国家收费数据库(NCDB)及经营者之间批发定价协议中导出的。

为了协助小型计算机执行所涉及的非常大量的处理任务，可将诸如“735”等惠普UNI X工作站80作为争取处理任务的协处理器附加在上面。事实上无限制数量的这种工作站可以连接在小型计算机70上来提高公司框能处理的通话记录的数目，但对于BT PSTN的合理的最小数量当前是诸如12个工作站。如上所述，到1995年可能将要求本发明的数据系统日处理60兆通话记录。配置依赖于称作“任务代理器”81的惠普产品，本发明的数据系统是配置成在批阵列上运行的。为了做到这一点，客户参数必须馈送到任务代理器中，这些参数的一个适当的组被列出在下面：

i)全程参数设置(它们是选用的)

-哪些客户可以访问服务器

-哪些机器可以远程管理任务代理器

-使用哪些网络屏蔽

-允许的最小与最大UID(用户标识)

-登录冗余度

-并发处理的最大任务提交数

-列出客户要求服务必须接触的机器

ii)客户参数设置(它们是选用的)

-为各种服务列出客户要求服务必须接触的服务器

iii)组参数设置

-每一次服务都必须在一个组中；为各机器将提供的各种服务建立一个组。

iv)服务定义(必须为每一种服务指定以下各项)

-组

-亲和力

-自变量

注：亲和力是0-1,000之间的一个数，它表示一个节点能够提供一种服务的良好程度。

任务代理器是一个排队系统，它控制哪一个工作站争取与处理文件。为了与公司系统8一起使用任务代理器，存在三个程序及一个配置文件。配置文件建立任务代理器在公司系统环境中操作所需要的参数，其中包括它能与哪些工作站通信、调用哪些程序来处理文件以及如何得优先权。上面列出的便是配置文件参数。

三个控制程序的操作总起来说简述如下。当一个文件来到公司系统8的翡翠小型计算机时，一个主程序“run-cp.sh”通过任务代理器将它送去处理，并断开小型计算机中的一个监视程序“cleanup-cp.sh”。任务代理器将该文件分配给一个工作站，工作站按照第三个程序“cp.sh”处理该文件。如果进展得顺利，文件返回到小型计算机，在那里“cleanup-cp.sh”将它分配给客户系统10的正确目录。“Cleanup-cp.sh”还监视工作站。如果在一个工作站的处理中存在过长的延迟，由于这时明显地存在问题，它便停止该工作站上的任务代理器。最后，“Cleanup-cp.sh“还控制记录与事件登录。

最后，除了输出到客户系统10之外，将来自公司框8的定价后的通话记录保存在一个光盘驱动器阵列71中，以便将来检索与分析单个的定价的通话记录。

3(iv)客户系统(或框)10

每周将互连通话的汇总ORACLE数据库表从公司框8卸载到客户框10。各客户框(CLB)10是一个惠普UNIX工作站，并且只处理汇总数据库表及在BT与另一经营者(诸如Manx电讯)之间的单一互连协议下生成的通话记录。一个客户框10运行一个ORACLE RDMS与商业目标软件。来自各客户框10的信息不仅允许BT相对于它们对BT网络的使用向另一网络经营者开帐单，还能检验从另一网络经营者对BT开入的帐单。各客户框10也能查询光盘41，但只能查询与该客户框10相关联的互联协议下的通话记录。客户框不可能向公司框8直接查询它自己的通话记录，更不用说查询涉及BT与其它经营者之间的其它协议的通话记录。在客户框10上连接有个人计算机，以允许分析汇总表。4、图9与10：通话记录与数据格式

4(i)通话记录

为了向客户开帐单这一主要目的而生成英国电讯类型6通话记录。通话记录中应包含根据日期、时间、持续时间、通过的距离及其它因素来精确定价一次通话的足够信息。各类型6通话记录可包含下述各项：

·记帐记录的长度；

·记录用途；

·记录类型；

·通话类型与通话有效性；

·通信断开原因；

·通信不连续性标志(通话中GMT与BST之间的互相改变)

·通话线路标识(CLI)

·路径组类型；

·抽样类别；

·路径组；

·节点代码(NPC)：POI交换机产生记录的唯一标识符；

·链接字段(当通话跨越一个以上按时段收费的段时使用)

·通话方类型(公司、住户、对方付费电话)；

·收费时段；

·地址完成的日期与时间

·应答者的日期与时间

·呼叫方中断通信的日期与时间；

·被呼叫方中断通信的日期与时间；

·被呼叫的号码字段。

通话记录由所有系统X交换机上的通话记帐子系统(CAS)收入按比例分配与记帐(RAA)设施所捕捉。如上所述，在步骤220将通话记录组合成APDU，并进一步将APDU组合成一文件，各文件的大小高达一兆字节。在系统XPOT交换机中的这一组合过程中不会损坏单个通话记录的任何部分。所有通话记录都是简单的二进制格式。

参见图9，各交换机文件40包含若干个APDU51，它们具有可变长度。各APDU51包含若干个记帐记录，它们也具有可变长度。然而下述各项是固定的。

·交换机文件最大大小一兆字节

·APDU最大大小512字节

·记帐记录最大大小70字节

DDC首部与尾部APDU除了首部APDU为241而尾部APDU为245的APDU类型外，其余相同。

在首部与尾部APDU中可得到下述信息：

APDU长度    首部/尾部APDU的长度

APDU类型    首部为241，尾部为245

唯一的文件标识符  见下面关于DI RI NDEX内容

目的地NNI       INCA流部件的NNI

应用组          INCA数据＝14的应用组

输入磁带/盒式带

序号            磁带/盒式带的序号

输出文件序号    DDC序号

时间印记

DDC接收的数据   DDC接收的日期与时间数据

部分文件指示符  指示文件是否是部分文件

异常指示符      指示文件可能错在何处

读计数          读过该文件的次数

文件大小        该文件的字节数

未选择的APDU

的计数      错误APDU类型的APDU数

选择的APDU类型    INCA数据类型的APDU类型

APDU计数    该文件中的APDU数

第一序号    开始APDU的序号

最后序号    结束APDU的序号

读计数表示流部件6从DDC轮询过该文件的次数。部分文件指示符指示DDC5是否成功地接收到整个文件，或者是否部分文件丢失了。

异常指示符为两个一字节位屏蔽字段，它们指示涉及这一传输的由DDC5检测到任何错误。

上述所有字段中的有效值在下面参照“公司系统(或框)”8描述的计算机辅助软件工程(CASE)应用软件中将被确认。

参见图10、APDU结构51的简要描述将包含AP.DU首部52、所涉及的实际记帐记录53及APDU尾部54。

记帐记录53的格式具有标准类型，且可以设计一种“C”结构以准确映射到该格式上。

当数据已从交换机3轮询到DDC5上时，DDC5剥掉在各数据APDU头部上的某些数据。这一数据表示DDC5及交换机3而与作为输送到一个终端处理系统的数据无关。

当DDC5将该文件复制到一个适当的目录中时，这便使它能供流部件6用FTAM复制，在称作DI RI NDEX的一个类别文件中为它建立一个项。DI RI NDEX文件项带有下述数据：

1)活动标记(一字节)，它可示出

a)不活动项

b)文件可用于传输

c)文件当前正在使用(诸如在FTAM传输中)

d)文件已成功地传输(尚未删除)

ii)INCA文件名格式

iii)输出路由，它可示出

a)文件可供FTAM利用

b)只用于磁带

iv)唯一的文件标识符，包含诸如建立时间与相关的交换机NNI等细节。

v)以字节表示的文件大小

vi)文件中的APDU数

观察ii)，INCA文件名格式，包括：

vii)流部件NNI

viii)交换机的NNI与群集号

ix)INCA数据的应用组

x)交换机文件的DDC文件序号

4(ii)将数据结构映射到交换机数据上

流部件6利用下述原则将数据映射到数据结构中供在公司框8的模型中使用：

·假定APDU长度字段及记帐记录长度字段是正确的。如果它们不正确，则确认将在APDU级或记帐记录级上失败，并且文件将流到数据分析器7中。

·首先扫描输入数据以找到首部APDU52。它将用APDU类型241(十六进制F1)来标识。然后将选中的APDU类型字段与唯一的文件标识符进行校验来确认这正是首部APDU52。

·找到首部APDU52并映射了首部APDU数据结构之后，假定文件中所有的APDU都遵循一个字的记录长度后面跟随一个APDU的标准，诸如

/首部APDU//RL/APDU/RL/APDU…/RL/APDU/RL/尾部APDU

其中RL为记录长度。

如果文件结构偏离这一标准，则将该文件流送到数据分析器7供进一步分析。这一错误条件将在紧随偏离的APDU的确认中检测到。

·假定各APDU内部的结构遵循图6。任何从这一结构的偏离都将再度使整个数据结构的映射成为不对准的，并将导致文件遭到拒绝而流向数据分析器7。

·假定在尾部APDU54后面不再有数据。任何出现在尾部APDU54后面的数据都将丢失。

5.图11至19及22至30：流部件及数据分析器进程

5(i)流部件：DDC轮询进程

如上面参照图2所提到的，当DDC5接收到文件时，它们被确认(利用求检验和)并在文件的开头与结尾的APDU首部与尾部52、54中加上某些附加信息。然后通过将它们放置在供流部件6使用的目录结构中及更新DIRI NDEX文件，而使得这些文件能供流部件6轮询。这一DIRI NDEX文件中包含能供流部件6轮询的所有文件的一张表，而流部件6则利用该表来保证它轮询所有的新文件。

参见图11，流部件6通过进入一个“流过所有DDC”进程而准备轮询多个DDC5。在步骤700，触发流部件6的“流过所有DDC”进程，诸如在一个指定的时间上。在步骤710，它进行一次检验流部件6是否可以利用来接收来自DDC5的文件。如果流部件6可以利用，它便进入一个循环，步骤720、730与740，在其中它运行通过一张DDC5的表并为要被轮询的各DDC5建立一个“DDC进程”。在该表的末尾，该进程结束(步骤750)。

对于各DDC5，流部件6现在运行“DDC进程”。参见图12，在步骤800、805，该DDC进程开始检验该进程所关注的DDC5或流部件6是否停止运转，并在步骤810检验DDC轮询是否到期。有时DDC5不能轮询，而步骤815进行一次检验是否进入了一个非轮询窗口。如果否，步骤820寻找一个自由进程槽来处理文件。如果所有这些检验都是畅通的，流部件6便在步骤825访问DDC DI RI NDEX，并在步骤830启动进程表及在步骤835启动文件表，这将保证流部件6将所有相关的进程应用在从DDC5接收的各交换机文件上。在步骤840、845与850，流部件6运行通过来自DDC DI RI NDEX的文件，建立起它自己的待处理的交换文件的登录，并在步骤855与860提供文件处理能力来处理文件表中的文件。一旦对来自DDC DI RI NDEX表的所有交换机文件都具有了所分配的处理能力，“DDC进程”便在步骤865更新其下一次轮询何时到期的记录，并返回到步骤870去睡眠。

如果DDC5或流部件6已停止运转，DDC进程当然在步骤875上停止，并在一次轮询尚未到期或者DDC是在一个非轮询窗口或者没有可利用的处理能力时便保持在步骤870的睡眠模式中。DD轮询系统结构内的典型事件循环假定下述各点DDC-POLLING-MPH＝17这是轮询的小时后面的分钟数DDC-POLLING-INT-HRS＝1这是下一次轮询要等待的小时DDC-DELAY-IN-DELETE＝12文件加上删除标记后等待多久出现实际删除请求该系统是在前一天23：30被引导的。时间表00：17  DDC进程醒过来，复制DI RI NDEX文件并建立进程将数据流送到流部件6。00：30由于已建立了最大数目的进程或者已将能利用的所有文件都交给了文件进程去卸载而DDC结束建立进程去流送文件。

醒过来时间计算为00：30+DDC-POLLING-INT-HRS

并将分钟设置为DDC-POLLING-MPH

＝＞下一次轮询时间＝00：30+1：00＝

1：30(设置MPH)＝01：17

计算睡觉的秒数＝TO-SECONDS(01：17-CURRENT-TIME)

睡觉(seconds-to-sleep)

……文件进程完成数据流送

01：17 DDC进程醒过来

5(ii)流部件：文件进程

参见图13，在DDC进程期间在步骤855建立的文件进程的操作如下。文件进程在步骤1302从DDC进程接收到的一个文件表上开始工作。运行通过文件表，步骤1303；为各列出在表中的交换机文件，文件进程读取交换机文件登录，步骤1305；确认通话记录，步骤1306；将文件复制到原始记录备份，步骤1307；如果流部件6继续前进则供应用，而如果存在确认失败则将文件改送到数据分析器7，步骤1310；或将文件流送到公司框8，步骤1312。

如果DDC5或流部件6停止运转，步骤1304；或者如果文件严重损坏，步骤1311，诸如由于与DDC5的通信故障；则文件进程停止，步骤1313。交换机文件登录监视一个交换机文件到达了相对于流部件6的哪一个阶段，并为各文件携带选自活跃、经过处理及删除中的一种状态，其中“活跃”表示它正在受到流部件6处理，“经过处理”指示已被流部件6处理过，而“删除”则指示它已被流部件6从DDC5中删除掉。

参见图14，在步骤1306，其中经过确认的通话记录可以展开如下。在步骤1401与1402从DDC5复制交换机文件，在步骤1403、1405确认文件首部及第一个APDU首部52。如果两者之一失败，在步骤1412建立一个文件错误登录。如果两者都可接受，则在步骤1407、1408各自确认通话记录，如果一个记录失败，则在步骤1409建立一个通话记录错误登录。对各APDU51重复确认。无论确认都显示正确，或者登录了错误，都在1413更新数据检查跟踪并且文件进程前进到步骤1307，如上所述。

参见图15，在文件进程中已确认的文件现在准备好进入公司框8。在这一阶段，分解文件结构，使得单个通话记录53能按照与它们相关的可记帐的实体被分类。在步骤1503将通话记录53写入不同的可记帐实体的物理文件中。

5(iii)DDC文件删除进程

一旦一个数据文件成功地从DDC5卸载到流部件6，且数据已扩展及流送到适当的公司框8，该数据文件便必须从DDC上的FTAM文件存储器中删除。在该文件保持在公司框8中的一个上(或者如果对公司框8的链路已经断开的话则在本地存储器上)之后结过数小时，流部件6将用一个FTAM删除请求删除该文件。保持数据与删除文件之间的实际时间可在逐个DDC的基础上设定。

5(iv)数据分析器：进程

参见图16，文件进程中确认通话记录的步骤，图13中的步骤1306，生成一个文件错误登录，步骤1412；及一个通话记录错误登录，步骤1409。数据分析器7运行两个进程，“DA进程”与“挂起文件进程”，它们在HP9000的引导序列期间启动。

DA进程连续地监视流部件6送来的数据是否能供数据分析器7处理。该数据开始时总是作为原始交换机文件出现的，无论该数据包含不能流送的单个通话记录还是失败出现在文件级上。

只要数据分析器7在步骤1602不标志为停止运转，DA进程便首先在步骤1603拾取最早的待处理文件错误登录，并在步骤1604检验它是文件/APDU级还是通话记录级上的失败。

参见图16、17与20，如果失败在通话记录级上，则DA进程在步骤1702拾取关于该文件的下一个通话记录错误登录并在步骤2000将有关通话记录送至ART IM规则库供校正。如果失败在文件级上，则整个交换机文件被流部件6拒收。在这一情况中，在步骤1606将整个文件加载到存储器中，并在步骤1607将文件首部与APDU51送至ART IM供校正。

数据分析器7所进行的分析可有若干结果。可修补的数据将送至ART IM去校正，并随后加以确认及流送到公司框8。如果涉及到路由错误，则对于具有系统中某处的路由信息的记录的问题的情况中，便将数据挂起，例如由于它需要更新。一旦校正了路由信息，最终便有可能确认通话数据，如果整个文件是不能读出的，它可能必须仍然以二进制格式送到一个二进制文件信息转储上。如果ART IM判定数据(诸如一个文件)是不能修补的，并且错误不涉及路由而不应挂起，则可将它归档。该数据不再能记帐但可用于在分析器中识别长期的或显著的问题，这些问题本身是可以校正的从而避免将来丢失可记帐的项目。

返回到图16，主DA进程在步骤1605与1607已利用ART IM运行检验，接着分类出从ART IM作为不能修补返回的文件。如果在步骤1608它们甚至是不能读的，则将它们提交给二进制文件信息转储。由于它们可能是十六进制、八进制或ASCII格式的，这些文件有被读出的潜力，并可能在稍后能用于分析。此外，文件可能是数据分析器能够读的，但仍然被ART IM定为“不能修补”的。在步骤1609将它们加载进一个“贮存槽”数据库中，在那里它们再一次永远不提供可记帐的数据但能被查询与分析。

如果一个文件已被送至ART IM且是可修补的，则ART IM顺序地返回各通话记录供确认，步骤1610与1611。然后DA进程首先在步骤1612通过检验路由错误而确认这些通话记录，并在步骤1615建立一个通话记录错误登录(在存在通话记录错误时)。这些记录将得到拾取并通过ART IM再处理，步骤1603至1605及1701至1703。如果通话记录是可接受的，通过步骤1616至1618，它将被流送到公司框8。

参见图18，当在步骤1612、1704或1907(见下图)检测到存在一个通话记录路由错误时，便将这些通话记录分类与挂起。这便是，错误被分析到能与一种存在的路由错误模式匹配的程度，步骤1802，然后在步骤1803将该通话记录加到一个存在的模式文件上，该文件中包含显示相同的路由错误模式的所有通话记录。将这些模式文件保持在挂起中，通知主BT PSTN网络管理与数据中心。然后由一个独立的进程，挂起文件进程，来处理这些文件。

挂起文件进程是数据分析器7的一种重要特色，因为它从数据处理的“主流”中取出一类有可能校正的错误文件。这些文件可能只是由于没有更新系统中某处的路由数据而被作为错误的文件拾取的。它们是潜在地可记帐的。利用挂起文件进程，主网络管理与数据中心便有机会更新系统中的路由数据而仍然抓住以前认为错误的文件。再者，通过将通话记录附加到一种特定路径模式的一个存在的模式文件，一个“路径模式挂起文件”上，便能通过简单地运行一个选择的路径模式挂起文件而选择文件供再一次试图确认。

参见图19，只要在步骤1902进程不停止运行，挂起文件进程便通过确定已补正的最早路由模式(诸如由网络管理与数据中心)而启动，步骤1903。然后，取出包含该路由模式的下一个挂起文件，步骤1904，并在步骤1905与1906中试图确认这些通话记录。在通话记录中当然有可能存在一个以上的路由错误。如果是这样，挂起文件进程返回到图18上的步骤1801，在一个路由错误模式文件中建立一个路由错误项，从而重新挂起该通话记录。但是，如果没有其它路由错误，挂起文件进程通过回到图15上的步骤1501试图将该通话记录流送到公司框8。进程以这一方式运行通过挂起文件中的所有通话记录，步骤1910，并且通过相对于特定的路径模式挂起的所有文件，步骤1911。

参见图22，其中示出流部件系统6、公司框8与数据分析器7之间的进程交互作用。流部件6的主进程区称作“文件进程”。它在一个文件上执行所有的确认与内部操作。在数据分析器区中有“IDA文件进程”，它输入数据到专家系统中。重要的是，这一进程通过将数据附加在一个路径模式挂起文件上而触发路径模式挂起文件与“挂起文件进程”。便是它避免由于挂起文件进程在主IDA文件进程外部操作而建立起大量的数据备份登录。值得关注的另一个区是接收来自“贮存槽加载程序”(“SUMPLOADER”)的输出的“贮存槽数据库”(“SUMPDATABASE”)。虽然贮存槽数据库中的数据不能校正，但它们可以查询与分析，使得IDA文件进程的规则有可能改变而使后面的数据能够重新流送。

在图22中，进程示出在圆圈中，公司框8是一个方框，数据文件、登录之类示出在断开端点的平行线之间，而归档数据则由用于数据库的传统符号表示。

参照图22上(a)至(y)交互作用的进程与存储的数据可列出如下，箭头表示相关的传输方向：

a)待处理、传输的NNI与文件名表

b)建立交换机文件登录，状态＝A

c)访问DIRINDEX文件

d)复制FTAM交换机文件

e)删除FTAM交换机文件

f)状态＝P时读取交换机文件

g)如果成功地删除交换机文件，状态设置为D(在上面(e)处)

h)状态＝A时读取交换机文件登录

i)更新交换机文件登录数据，状态设置为P

j)文件错误，因此建立文件错误登录

k)通话记录错误，因此建立通话记录错误登录

l)如果文件错误，将文件复制到数据分析器目录

m)读取文件错误登录

n)读取通话记录错误登录

o)查找原始(二进制)数据文件

p)将数据附加在这一路径模式的路径模式挂起文件上

q)在路径错误模式中建立项

r)ART/IM建立最接近的匹配

s)ART/IM已识别该数据不能修补。数据放置在贮存槽中供进一步分析或删除

t)用户识别该问题无法修补。文件放置在贮存槽中供进一步分析或删除

u)文件结构不能理解时将其扔入二进制文件转储

v)建立流送的文件

w)由路径错误模式状态设置成就绪启动挂起文件进程。如果问题继续存在便更新计数字段并将状态设置为挂起

x)如果选定的解决办法不能修补问题便更新最接近的匹配

y)建立流送的文件

5(v)实体生命周期

参见图23至30，实体生命周期图示出该实体内的一个记录能进入的状态，以及通过何种动作能从该状态到达哪些其它状态。在各图中，这些状态是简单地用参照数字2300标识的，而状态的定义则给出如下。

图23：文件错误登录；

就绪-该文件准备好由数据分析器7流送。

挂起-或者整个文件或者该文件中至少一个通话记录已送至挂起区中

BIN-数据分析器7不能读出该文件并已将其送至bin区

贮存槽-整个文件已送至贮存槽区

完成-数据分析器7已流送该文件，并且挂起区中该文件的任何通话记录都已成功地重新流送或归档

图24：通话记录错误登录；

就绪-通话记录准备好由数据分析器7流送

挂起-通话记录已送至挂起区

槽-通话记录已送至贮存槽区

归档-通话记录已送至废物区(即归档)

完成-数据分析器7已成功地流送该通话记录

VAL_FAILURE-ART-IM与IEF确认过程中存在差别

图25：路径错误模式

未选中-由ART-IM建立并等待由数据分析器用户分析，或在分析失败后重新流送

示决-被数据分析器用户选中供分析

就绪-数据分析器用户完成分析并准备好重新流送

关闭-成功地重新流送或归档

图26：最接近的匹配

未选中(或空)-由ART-IM生成

选中-被数据分析器用户选中供分析

图27：贮存槽文件登录

槽-一个文件准备好用于贮存槽进程

处理-该文件准备好由数据分析器用户观察

归档-该文件已归档

图28：文件路径错误链接

挂起-该文件在挂起区中

完成-该文件已从挂起区中成功地重新流送

图29：交换机文件登录

A(活跃)-交换机文件正在由流部件处理

P(已处理)-交换机文件已由流部件处理过

D(删除)-交换机文件已被流部件删除

图30：地区数据采集器；

(所有状态都是由流部件6用户通过SQL*格式改变的)

P(预先重复)-DDC是预先重复的(prebis)

L(活)-DDC是活的

C(停止)-DDC已停止

参见图6，可以看出，流部件6/数据分析器7软件系统结构中包含IEF外部动作框(EAB)62。当不适合或不可能在IEF内部实现时，使用EAB62。例如，下述功能可用EAB62执行：

·“将通话记录加到挂起”

这一模块在包含待送至挂起区的一个交换机文件的通话记录的链接表内建立一个通话记录的一个新项。

·“将通话记录加到归档”

将包含已修补但不能重新流送的交换机文件的通话记录的一个链接表内的一个通话记录的一个新项建立在归档目录上。

“加网络经营者记录”

检验这是否是一个新的网络经营者，如果是，便在“网络经营者结构”的链接表中建立一个新项。如果这是一个已使用的网络经营者名，便将一个链接表项加入到该网络经营者的通话记录的链接表中。当在一个通话记录上施加修补时，它便用“网络经营者记录”本体及流送的通话记录序号更新“通话记录错误登录”。

·“通话记录到IDA规则”

将一个单一通话记录传送到数据分析器ART-IM规则库。该通话记录是用IEF传来的APDU序号与通话记录序号标识的。然后在加载在存储器中的数据结构中搜索该通话记录及拥有该记录的APDU与交换机文件首部数据。将这一数据馈送进规则库中并加以确认。任何找到的错误各生成一个通话记录规则登录行项。规则库还更新该通话记录错误登录记录状态。

·“提交”

提交所有当前数据库改变。

·“建立DDC进程”

建立一个负责轮询一个特定的DDC的DDC进程的发生。它将建立/打开一个fifo(文件进/文件出)到子进程并将该DDC-NNI的值写该fifo。

·“建立文件进程”

建立执行流送在文件名数组中传送的文件名的任务的进程。

·“从DDC中删除文件”

用FTAM协议从DDC上的盘中删除一个文件。

·“删除数据分析器文件”

从流部件/数据分析器目录中删除一个文件。

·“删除挂起文件”

从挂起文件目录中删除一个文件。

·“文件到bin”

将一个不能读入到ART/IM规则库中的文件传送到二进制文件转储。

·“文件到数据分析器规则”

将一个完整的文件传送到数据分析器ART-IM规则库并初始化该规则库。规则库的初始化包含清除老数据、选择省缺与路由参照数据、以及将这些数据提供给规则库。然后将数据分析器二进制文件加载进存储器中的一个数据结构。然后将该数据馈送进规则库并加以确认。任何找到的错误各生成适当的规则登录行项。通话记录错误登录将在适当时由规则库连同路径错误模式、最接近的匹配及文件路径错误链接记录一起建立。一旦得到确认，规则库将返回一个确认状态给IEF并保持其内部数据供以后检索。

·“文件到贮存槽”

将一个不能由ART-IM规则库修补的文件传送到贮存槽中。

·“FTAM HLCOPY”

用FTAM协议将DDC文件名从使用DDC用户名、DDC口令与DDC帐户的DDC FTAM地址复制到流部件6。必要时，可将流部件6的用户名、口令、帐户及FTAM地址省缺为空的。这一例程并不直接从IEF调用，因此并不返回IEF形式的状态。

·“DDC进程参数”

建立或打开流部件/TMP目录中名为“DDC进程fifo<PID>”的一个fifo。从该fifo中读取DDC NNI的值，这些数据是已经由“建立文件进程”例程插入fifo中的。

·“取文件进程参数”

建立或打开流部件/TMP目录中名为“文件进程fifo<PIO>”的一个fifo。从该fifo中读取上述变量的值，这些数据是已经由“建立文件进程”例程插入fifo中的。

·“取交换机文件”

用FTAM协议将一个文件从DDC上的盘上直接复制到流部件6上的盘上。然后将该文件读入流部件6上的存储器中，然后更名到原始记录备份目录中，从那里将其归档。为了建立指向第一记帐记录、第一APDU、以及首部与尾部APDU的初始指针，该模块调用“将数据结构映射到文件”。

·“取无效数据分析器APDU数”

返回使流部件确认进程失败的通话记录的无效APDU重新处理的一个计数。

·“映射数据分析器文件”

将一个文件读入存储器中供以后处理。

·“进程活跃”

判定一个特定PID是否活跃并返回一个相应的标志。

·“读交换机文件首部”

使用指向首部与尾部APDU的指针在一个结构中返回来自首部的所有字段及来自尾部的APDU类型。

·“读取数据分析器交换机文件首部”

使用指向首部与尾部APDU的指针在一个结构中返回来自己送至该数据分析器的一个文件的首部的所有字段及来自尾部的APDU类型。

·“读取第一个DI RI NDEX记录”

用FTAM协议将DI RI NDEX文件从该DDC复制到暂时存储器中，并打开该文件并返回第一个记录给调用者。

·“读下一个APDU”

返回当前APDU指针所指向的APDU结构并将当前APDU指针设定在下一个APDU上。还将当前记帐记录指针设定在返回的APDU内的第一个记帐记录上，以及将数据复制与字节返回到当前APDU数组中。

·“读下一个DI RI NDEX记录”

从DDC上的DI RI NDEX文件中读取下一个记录。

·“读下一个数据分析器记录”

返回从ART-IM规则库输出的下一个记帐记录。首先会出现成功地处理的记录，后面跟随着需要送至挂起文件的记录。

·“读下一个挂起记录”

返回从挂起文件输出的下一个记帐记录。

·“读下一个记录”

返回当前记帐记录指针当前指向的记帐记录，如果该记录不是当前APDU中最后的记录便将指针设定在下一个记帐记录上。(这是用APDU长度及一个记帐记录的最大长度确定的。)

·“更名网络经营者文件”

更名已写入工作目录中的暂时目录准备好由公司框8处理的任何网络经营者文件。

·“睡觉”

睡觉指定的秒数。

·“流送文件”

将存储器中的文件转储到数据分析器中准备好供数据分析器处理。

·“流送文件网络经营者”

使用指向第一网络经营者的指针取出该经营者的所有经过确认的扩展的记录。然后试图将来自链接表的记录写入一个nfs暂时目录中。如果成功，将该文件更名到该nfs目录中。如果该文件不能在该nfs暂时目录上重新打开，则将该文件在本地暂时目录上打开，并且在成功地写入时，将该文件更名进本地目录中。

·“流送文件RRB”

将存储器中的文件转储到原始记录备份目录中。

·“写控制台”

将一则报文写到一个网络管理工作站。

·“写到挂起文件”

将来自一个交换机文件的挂起通话记录的链接表的记录写入挂起目录中。

·“写到归档文件”

将记录从一个交换机文件的归档通话记录的链接表写入归档目录。

6.图31至35：专家系统：ART-IM

6(i)概述

专家系统使用Inference公司供应的基于ART-IM知识的专家系统工具箱设施。这是一个知识/规则库编程系统，它提供一个作出决定的灵活模型，并在知识层次内作出现实世界的模型，以及为解决问题提供一种更具启发性的方法。该工具箱中包含ART-IM语言以及一个集成的编辑程序、一个交互式开发环境、用于开发终端用户接口的工具、一种调度已开发的应用的运行期版本的方法以及智能地解释外部数据的设施。

在数据分析器7中，专家系统分成两个子系统，规则库与事例库。通常，事例库用于处理基于路由的错误，而规则库则用于省缺的及可计算的错误。两者都利用ART-IM功能。

规则库使用包含规则、功能与方法的ART-IM过程语言。各种错误是在一种方案内定义的而这些方案的事例则用在数据结构上。一个进入数据目标层次结构内的所有方案都利用ART-IM的“定义外部功能”设施通过IEF/ART-IM接口集中。ART-IM所使用的程序流控制机制与通常在编程语言中见到的顺序的逐个语句流十分不同。参见图31与32，专家系统在一个模式网3100中保存其所有的内部数据，即图式与事实。在图31中，这是用多个加图式的圆圈表示的，各表示一个内部数据(一种方案或事实)。这些数据可通过下述方法建立：

·加载一个ART-IM测试事例文件(更经常地在一种开发/单元测试前后关系中进行)。

·通过从一个外部源集中(诸如Oracle或IEF；较常在一种生产/系统测试环境中)。

·通过从ART-IM规则中生成(用作非常灵活的“工作存储器”，诸如在确认测试失败后的错误图式生成)。

一旦建立，数据便直接与规则中指定的条件相比较。一条规则象更传统的编程语言的“IF<条件>THEN<动作>”。如果规则的条件完全与数据的事例匹配，便在一个相关的议程3105中建立一个激活。对照所有规则检验所有的事例。在性能方面，模式网与规则条件是由ART-IM运行期系统中的高效模式匹配算法管理的。

在周期的评估部分结束时，所有的规则激活按次序放置在议程栈上。起动栈上的第一个规则激活。除非跳跃，即由开发者设定规则的优先权，激活出现的次序是由系统设定为随机的。

参见图32，启动了议程3105上的最上面的规则激活之后，规则的动作实际上已经改变了模式网中的数据，后者又改变议程栈上下一个评估周期后面出现的规则激活。

应当指出，导致最先起动的数据事例(如圆圈的事例3110)将不再重新评估从而即使数据事例中的数据改变且新模式与一个规则条件匹配也能避免连续的循环，然后建立一个规则激活。

在下述情况中ART-IM运行结束：

·未找到匹配的条件与模式。

·所有匹配的条件与模式都已起动了规则。

上述各点可归结如下：

1)规则起动是由数据模式与规则条件匹配生成的

2)虽然可以设定优先权，但根据系统设定，规则能以任何次序起动

3)所有数据是并行评估的

4)每次起动一条规则时出现重新评估

5)在一次运行期间同一条规则可多次起动，这取决于匹配的数据事例的数目。

6)规则条件是对模式网中的改变敏感的

7)如果未找到匹配的规则条件或模式网数据或者已经起动了所有匹配的激活，ART-IM便停止。

参见图33，规则库系统是基于一个目标层次结构的，如图所示。各目标3300在ART图式中定义，目标3300之间的连线描绘从上面的目标的继承。

交换机文件、APDU与通话记录的结构中包含各数据项的槽。各槽在适当的省缺目标中具有一个对应的槽，用于说明结果具有一个省缺值、一个计算值、还是是一个不可修改的字段。规则库使用省缺系统来检验一个错误校正(如果允许)必须是什么形式的。

以上覆盖了数据图式。对于错误图式，每一种可能的数据分析器错误的细节描述在一个适当的图式中。各错误描述及其事例包含用于下述各项的一个槽：

错误所涉及的目标，即一个交换机文件。

一个错误描述。

受影响的槽。

一个错误事例的特定数据目标。

修复值的名。

错误源。

结果修复值。

起动次序中的规则位置。

施加任何修补前的槽的值。

6(ii)规则库的通用规则

规则库操作流是由若干通用规则控制的，它们执行下述功能：

·对一个错误触发的每一次出现，起动该错误修补方法来生成一个修补值及其分配的起动次序。

·对于只影响一个槽的一个可修补的错误，用生成的修补值更新该受影响的槽，并将改变的时间印记与错误事例一起存储。

·对于修补描述说明错误类型为可挂起的一个错误的每一个事例，将受影响的数据项移到挂起文件中，并将移动的时间印记与该错误的事例一起存储。

·对于修补描述说明该错误类型为可进入贮存槽中的一个错误的每一个事例，将受影响的数据项移到贮存槽中，并将文件贮存的时间印记与该错误的事例一起存储。

·为一个APDU或交换机文件的每一个修补，在文件结构规则登录上建立一个记录。

·为带有适当错误信息的一个通话记录上的每一个修补，在通话记录错误登录上建立一个Oracle记录。可修补的错误

1)在下列字段中可分配省缺值

APDU类型与尾部

已记帐的通话指示符

被呼叫方中断通信

PBX后缀

记录用途

记录类型

DDC时间印记

首部APDU类型

数据传输级

格式版本号

节点时间印记

部分文件指示符

表大小

尾部APDU类型

被呼叫方中断通信

应用程序组

2)下列错误是可计算的：

APDU长度；APDU的长度。

APDU计数；APDU序列的长度。

结尾APDU序号；开始序号加上有效APDU的数目。

开始APDU序号；从交换机文件中的第一个APDU的序号得出。

拨号位数计数；所拨的数字串的长度。

关于以上各项存在着错误异常，诸如一个APDU的检验和显示出错误。这种类型的错误立即在规则库内加以贮存。关于APDU序列的某些错误导致序号的整个范围重新从“1”排序，并且更新相关的交换机文件。它可能是一个所拨的数字串的最后一位为在A与F之间的一个字符。这里的修补值是所拨的数字串减掉最后一位。不能修补的错误

在一个不能修补的错误的出现上，将错误的数据项，即一个通话记录，传送给贮存槽，如上所述，并更新适当的错误登录。不能补正并从而生成不能修补的错误的区如下：

地址捕获的时间印记

地址完成的时间印记

地址或应答时间印记

呼叫方中断通信时间印记

呼叫线路目录号

捕获时间印记

所拨的数字串(最后一位在A与F之间除外)

6(iii)事例库系统

路由参照事例库是路由模式(即TUN、路径组、路径号、NNI、节点代码)如上其它参照数据(诸如可记帐的网络经营者名、以及活动与停止的节点时间印记等)的一个事例库。事例库参照数据是从路由参照图式提供的，后者又从包含在数据模型的流部件参照数据主题区3600内的数据提供(见图36)。

参见图34，可以看出事例库系统的目标层次结构与图33中所示的规则库系统的相似，但加上了三个目标级3400：“建议的解决方案”、“可能的解决方案”以及“路由参照”。可以看出，“建议的解决方案”及“可能的解决方案”只是跟随在一个路由参照错误的识别后面建立，并且主要包含指向其它数据的指针，即错误的进入通话记录及最接近地匹配的路由参照图式。“路由参照”图式是从Oracle数据库上的路由参照数据建立的。

关于路由事例库与初始化，路由事例库是在一次运行开始时从路由描述图式提供的。为每一个路由描述图式建立一个事例。路由事例库将用下列参数建立：

·最多三个匹配

·忽略一切在零概率的阈值以下的匹配，以便清除高度不可能的匹配。

·在模式匹配中只使用事例库上的下述槽：

 TUN(即电话单元号)、路径组、节点代码、路径号、NNI、及方向

·在模式匹配中忽略以下各项：

活节点时间印记

停止节点时间印记

电读网络经营者角色与姓名

·方向略为不同于用作匹配目的地对待。这是最不重要的匹配槽并只给予总体权重的5％的固定权重上限。其余的槽加权平均分配总体权重的剩余95％。

模式匹配连同诸如设定初始化参数等其它事例库功能是通过发送报文到事例库达到的。模式匹配分两步完成，它们是将一个进入通话记录图式送至事例库，事例库则返回找到的匹配的数目；以及送出一则确定各返回的事例的匹配接近程度的检索匹配得分报文连同与该返回的事例相关联的路由参照图式的键。

在节点代码或路径组未找到、无效路径号或方向无效等情况中，事例库用于确认涉及通话模式的以下错误码：

·试图找到各进入通话记录与路由参照事例库上的一个事例之间的精确匹配。如果存在一个精确匹配，则通话记录具有一个有效的路由模式而无需对上述错误进一步确认。

·如果未找到精确匹配，则生成一个错误图式，后者触发规则库通用规则，如上所述，而通用规则将施加一种修补方法。

·该特定的修补方法建立一个建议的解决方案，其中包含(见图34)：

i)多达三种可能的解决方案，各包含指向相关联的路由参照图式的一个指针。该可能解决方案还包含匹配位置(即最接近的、次最接近的等)及匹配的接近程度的百分比度量；以及

ii)指向错误的进入通话记录的一个指针。

应当指出，该修补方法与通过生成一个错误图式事例调用的通常修补方法不同，因为它包括一种功能(路由失配，它认定建议的解决方案事例以及包含指向路由参照图式的键的事实)及另一条规则(生成最接近的匹配，它将触发由路由失配建立的事实的生成，并为各找到的事例库匹配生成一种可能解决方案的一个事例)。

在考虑到节点时间印记确认时，事例库可使用如下：

·试图找到各进入通话记录图式与一个路由参照图式之间的精确匹配。如果存在一个精确匹配，规则便检验匹配的进入通话记录图式与路由参照图式上的时间印记差异(即捕获时间印记应在节点活着与停止时间之间)。如果不存在差异，不进行与这一错误相关的进一步处理。

·如果找出时间印记差异便生成一个错误图式来触发规则库通用规则，如上所述，该通用规则将施加一种修补方法。

·该特定的修补方法将建立一个建议的解决方案，其中包含(见图34)：

-一种可能解决方案，它包含指向相关路由参照图式的一个指针。该可能解决方案还包含匹配位置(即最接近的、次最接近的等)及匹配的接近程度的一个百分比度量。

-指向错误的进入通话记录图式的一个指针

应当指出，该修补方法再一次与通过生成一个错误图式事例调用的通常修补方法不同，因为它包含一种功能(节点时间印记差异，它认定建议的解决方案事例以及包含指向路由参照图式的键的事实)以及另一条规则(生成节点时间差异，它触发由路由失配建立的事实的生成，并生成一种可能解决方案的一个事例)。

6(iv)ART-IM与ORACLE接口

参见图35，为了全部利用ART-IM规则库的“并行”确认特性，需要从ART-IM对ORACLE的直接访问。共有四种主要接口：

·提供路由参照数据3500

·提供省缺数据3505

·输出修补数据以构成数据检查跟踪3510

·输出路由错误图式作为挂起数据处理的先导3515。

观察路由参照数据的提供，这一接口3500包含从物理地保存在ORACLE表内的路由参照模型中的数据刷新内部ART-IM方案与数据库：

·在一次ART-IM运行的初始化阶段中触发该刷新。

·将现有的内部ART-IM路由参照图式连同它们的数据库项一起清除。

·由一个ProC程序(EAB初始化IDA规则库)从ORACLE表中选择数据，该程序用作两个外部动作框的一部分(文件到ida规则及通话记录到ida规则)。

·内部ART-IM图式由ProC程序提供。

·再由作为事例库初始化进程的一部分的功能(inca_ida初始化事例库)从内部路由参照图式提供路由参照事例库。

观察者缺数据的提供：

·在一次ART-IM运行的初始化阶段中触发刷新

·将现有的内部ART-IM省缺(df通话记录、df-apdu等)图式连同它们的事例库项一起清除。

·由一个ProC程序(EAB初始化IDA规则库)从ORACLE表中选择数据，该程序用作两个处部动作框(文件到ida规则及通话记录到ida规则)的一部分。

·由Proc程序提供内部ART-IM图式。

观察错误与修补数据的建立，如果在进入数据确认期间检测到与能够修补的数据相关联的错误，则需要维护规则库所施加的修补的数据检查跟踪：

·对于每一个错误的文件结构，在文件错误登录表中建立一个行项。这是由流部件进程完成的。

·对于每一个错误的通话记录在通话记录错误登录中建立一个行项。这能由流部件进程或ART-IM完成。

·对于每一个文件结构级上检测到的错误与施加的修补，在ORACLE数据库上的通话记录规则登录中建立一个行项。这最好由规则库用一条通用规则完成，该规则是在完成了所有通话记录级错误检测与修补时触发的。再一次应为每一个检测到的错误/施加的修补起动一次该规则，并在起动时调用一个称作sql_exce_immed的用户定义的过程，该过程进行必要的插入。

·该ART-IM规则提供来自内部图式上的槽中的插入值。观察路由错误模式与最接近的匹配数据的建立，如果在进入数据确认期间检测到与挂起的数据相关联的错误，则需要将该进入通话记录错误模式的一个记录(根据TUN、NNI、路径组号、路径组、方向)连同三个最接近的匹配(根据路由参照模型上对错误的进入通话记录的最接近模式)一起存储在ORACLE数据库上供以后挂起文件处理。模式是在完成了所有确认/修补处理后面存储的。更详细地：

·对于每一个生成的挂起文件错误(并假定在同一个通话记录上未生成不能修补的错误，这些不能修补的通话记录是用移至贮存槽通用规则清除的)，起动一条通用规则(移至挂起文件区)。该规则试图从数据库中选择该错误的模式，并且如果该错误模式存在：

i)用相关的模式交换机文件与外来键在文件路径错误链中测试任何项。

ii)如果该项存在，不需要进一步的动作。

iii)如果该项不存在，便在文件路径错误链中插入一个行项。

如果该错误模式不存在：

iv)在一个路径错误模式表中插入一个由来自进入通话记录的错误模式数据提供的行项。

v)在文件路径错误链中插入一个行项。

vi)在最接近的匹配表中插入从前面的事例库处理中找到的最接近错误路径模式的路由参照模式提供的三个行项。

·一个用户定义的过程用于将SQL命令传送给ORACLE。

·ART-IM规则从内部图式上的槽中提供插入值。

7.图20、21、37至43：数据分析器7使用专家系统

在下面参照的流程图中，可以注意到应用了与本说明书中较早的流程图中略为不同的格式。即，功能调用是用带双竖线的框表示的，单个的语句是用带单竖线的框表示的，而是/否判定则是用简单的菱形表示的。

数据分析器7使用ART-IM专家系统可以用流程图表示。参见图16、17与20，一旦在步骤1605判定了在通话记录级上存在毛病，并且在步骤1702从一个文件中选定了下一个通话记录错误登录，便在步骤2000将相关通话记录送至专家系统。专家系统在步骤2005、2010定位正确的APDU，然后在步骤2015、2020定位错误的通话记录。

然后，专家系统检验该通话记录是否是正确地分项的(步骤2025)，在这一实例中按照系统X分项，如果否，在步骤2030通过将IEF状态设置为“贮存槽”而将该通话记录引导到贮存槽中，同时在步骤2035更新通话记录错误登录。如果该通话记录是正确地分项的，则在步骤2040、2045、2050令其通过专家系统，并在步骤1704将结果提交给数据分析器7去评估。

参见图16与21，在步骤1604可能已判定在文件或APDU级上存在毛病。在这一情况中，步骤2100将文件加载到存储器并将文件首部及APDU送至专家系统。在步骤2105调用专家系统数据库，并在步骤2110删除前面运行中的APDU图式。步骤2115中的第一次试运行为更新路由参照模型的专家系统版本，这可能立即得到校正明显的错误。如果没有校正，步骤2120刷新用于专家系统的省缺值，以防诸如有关错误的省缺数据早已丢失。如果其中之一是成功的，数据分析器进程再坚持自己的运行，图16，并在步骤1611来自专家系统刷新步骤的结果允许文件对其通话记录进行确认。如果都不成功，必须单个地确认它们的通话记录。这在下面描述。

参见图37，图21的功能框2125“映射首部与APDU图式”，相对于来自在刷新路由参照模型与省缺数据之后不能成功地得到处理的错误文件的通话记录，扩展到包含加载(步骤3700至3725、3735)与运行(步骤3730、3740、3745、3750)专家系统ART-IM。这一加载进程包括在步骤3715中取诸如来自流部件6的数据等在ART数据库上不能得到的数据(“外来键”)，使得专家系统能访问这些文件。分析过各通话记录时，ART提供一种状态(步骤3755)，该状态可指出该通话记录是修补好了、或者应当挂起或者存贮。在步骤3760数据分析器进程(IEF)保存待贮存的通话记录的一个计数，并在步骤3765在ART-IM中设置一个标志，该标志在步骤3770触发ART-IM进行清除，以清除各通话记录与相关图式，以避免将它们简单地建立起来。

参见图38至43，专家系统文件规则的应用也能以流程图表示，并示出下述实例，流程图是自我说明的：

i)图38：ART文件规则(交换机文件首部)

这可应用于-

尾部APDU

格式版本号

文件类型

节点时间印记

DDC/NMP时间印记(NMP代表网络调解处理器)

数据传输的级

节点群集本体

流部件NNI

应用组

部分文件指示符

文件字节大小

表大小

选择的APDU类型

ii)图39：APDU第一序号规则

iii)图40：APDU最后序号规则

iv)图41：APDU序号计数规则

v)图42：ART APDU规贝

这可应用于-

转发指示符

链接字段

vi)图43：ART通话记录规则

这可应用于-

记录用途

记帐的通话指示符

通信中断原因

PBX后缀

CLI群集本体

网络电路

网络带

电路本体

电路号收费时段

通话的样方法

抽样模式

计数复位指示符

N的值(N涉及诸如在运行通话记录的试设置时进行的一次计数)

被呼叫方通信中断时间印记

8.图36与44：公司系统

参见图4，从流部件6到公司系统8的输出中包括按照可记帐实体分类并采用包含ART-IM专家系统的数据分析器如上所述地确认的通话记录。

公司系统8的主要任务是为通话记录定价并将定价后的记录输出，以便向客户收费。然而，如上面所提到的它还具有着重于与可记帐的实体相关的数据及该可记帐实体与第一网络1之间的关系的确认任务。因此，公司系统8包含或访问在下面称“cIDA”的一个公司系统数据分析器。

cIDA应用程序可与确认来自流部件6的数据的数据分析器7在一起，如上所述。在图4中，修补错误通话记录的步骤430，堆积修补后的通话记录的440，以及探查不可修补的通话记录的450全部都能用cIDA应用程序执行。

有趣地，已注意到大多数错误，占公司系统8检测的错误中90％的数量，主要与“时间线”(诸如“123”)及“急救服务”(999)通话的解码异常相关。其余的错误大部分来自参照数据中的差异。因此可在两个主要方面建立与公司系统8一起使用的数据分析器，它们对付提供大多数错误的解码异常的记录，然后提供一个能将校正后的文件重新提交回公司系统8的底层结构。处理概述

一种适用的装置可以如下。从公司框8将错误与警告文件送到cIDA，在那里将它们加载到特定的目录中，每一经营者一个目录。一个单一的文件可保存零或许多记录。最好cIDA为所有经营者提供并发运行的并行处理设施，并带有手工改写的能力。为了控制出入cIDA的文件序列，维护了一个登录。

一旦选择了一个错误文件供处理，假定该文件不是空的时，cIDA便依次选择各记录并将错误估价到两种类别之一中，能修补的与不能修补的。不能修补的记录写入与报告在一张表中，并且以后能从数据库中去掉以供归档。当认为一个记录能修补时，它便能应用规则自动修补，或者在它能被修补之前需要人工干预。

将不论哪种错误类型的各记录连同从公司框8传送来的所有细节及设定为指示该“状态”的一个标志一起插入到一张ORACLE数据库表中。按照上面所述，该状态可选自：

挂起

不能修补

规则

具有商业目标的在有规则的时间间隔上运行的用户具有观察所有当前保存的记录及分配给它们的状态的能力。可将一个检查登录保存一个相关时间间隔，诸如为所有“收费号码串”校正保存一个月。

应指出，自动规则的使用可能是不必要的。通过校正由解码异常引起的错误，即90％的当前错误，已发现出错率下降到了0.01％。因而发生错误的简单程度意味着利用自动规则的系统显得过于复杂。

参见图44，可以看出关于本发明的数据采集与处理系统的数据流路径。在该图中，诸如文件与表等数据存储是用带有垂直虚线的水平延伸的矩形表示的，并且进程是用包含矩形的较大的框表示的。诸如NCDB9等整个系统外部的实体是用“胶囊”表示的。

如已描述过的，将原始通话数据输入到流部件中，它转换这些原始通话数据、确认与处理通话记录(必要时涉及一个数据分析器)，并将经过确认的分项通话记录输出到公司框。公司框首先执行经营者特定的确认，然后集合分项的通话记录。在这一阶段，用诸如来自国家收费数据库(NCDB)9的收费信息为通话记录定价，并以汇总格式输出，以便向有关客户系统10生成一张帐单报告。其它输出包括存储在光盘71上的扩充通话记录以及用于一个管理报告系统4400的汇总通话记录。

在图44中可以看出，还有一个从数据分析器到检查系统“CARDVU”4405的输出。虽然本发明的实施例能够提供用于检查目的的极为详细的信息，但检查系统本身不是本发明的一个部分，因此这里不作超出下面“9.数据检查跟踪”的说明的描述。

参见图36，公司系统8的数据模型清楚地示出公司系统8用在收费与定价上的数据源。极大量数据中的大部分，“C&P参照数据”是从NCDB9中得出的。然而，存在着可记帐实体与网络1的经营者之间的会计合同4500所订立的约束。许多问题可从网络管理中心处理，并且图36的数据模型利用“电讯网络经营者任务”框4505提供适当的可视性。

用在图36中的下列字头字母可扩充如下：

CBM    收费带矩阵

CB     收费带

NN     网络节点

KCH    Kingston通讯公司，Hull(与BT PSTN互连的一个网络的英国经营者)

TE     Telecom Eirann(同上)

NCIP   国家收费信息插件(对NCDB上的数据的一个接口)

符合本发明的系统所提供的约束类型的定价与收费机是已知的，因此在这里不再给出收费与定价机的具体描述。虽然图36的数据模型果真示出了所有涉及的实体，但为了免使该图变得太复杂而未示出所有的关系。然而，总的在思想上应认识到公司系统8所处理的通话记录是已经按照可记帐实体分类了的。数据的这一面目必须清楚地保待，使得有关报告能分配给正确的客户系统10。这一点可以通过诸如为可记帐的实体维护分配的目录而做到，有如上述。

9  数据检查跟踪

如上所述的一种配置能提供机灵的数据检查跟踪。来目互连点上的交换机的数据以文件形式进入，并被包装成APDU。流部件系统6利用FTAM协议轮询从DC5出来的数据，该数据是二进制的通话记录。流部件系统6对照包含参照数据、路由参照模型及应记帐的其它网络经营者的评估的数据库确认这些数据。流部件系统6写出加上经营者与交换机信息的ASCII形式的全面的通话记录。

一次数据检查跟踪出现如下。在交换机上，通话事例是用从0到9999循环的一个文件生成号编号的。DDC5还在文件级上加上一个从0到999999循环的序号。在文件中，APDU也用一个从0到16353循环的二进制APDU序号排序。

这意味着存储了具有文件中的记录号、APDU起始与结束号及APDU号的一个记录。

由于在交换机上的各号码上加上了一个序号，便能保证公司框8按序接收号码，虽然它们不一定是按序处理的。实际上流部件系统6是并行处理同时来自不同交换机的。

在数据分析器中，利用如果数据不符合有效内容便“起动”一条规则的一个“模式网”，该分析器便能只在有关数据项不影响价格或数据检查跟踪时才修补数据项。本文中的修补是指设定为一个标准值。因此由于序号标识通话记录而数据分析器不能改变通话记录的序号。如果可以改变通话记录的序号，则无从谈起数据检查跟踪。

如上所述的系统只是本发明的一个特定实施例。如上所述，它涉及一个PSTN并处理话音通信系统中的通话记录。再者，所讨论的系统X类型6的特定格式的通话记录只涉及可用在网络之间的互连点(POI)上的一种类型的交换机。

除了利用通话记录数据以生成记帐信息之外，本发明的应用的一种简单扩展为也能拾取与处理通信量分析信息。例如，不能到达目的地的通话“无效通话”也能由POI上的交换机计数，并将“聚集的”结果输入到数据处理系统。

然而，更明显的改变可包含将本发明用在带有话音通信以外的通信形式的系统中，甚至排除话音通信的系统中，并且如已经提及的，是否涉及PSTN显然并不是主要的，虽然鉴于记录的绝对容量及涉及的源的复杂性，本发明的实施例用在PSTN中的效益十分明显。

Claims (15)

1、一种在一个第一通信网络中采集与处理通信记录的方法，在该网络中通信终止，数据是关于通信事例，其中该网络至少包含一个连接在一个或多个其中发生通信的第二通信网络上的点，该方法包括下述步骤：

i)在所述连接点的一个数据访问点上采集数据，所述数据涉及发生在与所述第一网络不同的一个起源网络中的一个通信事例，并为每个通信事例产生相应的数据记录，每个这样的记录包含识别关于所述通信事例的起源网络的路径信息及至少一个对于所述通信事例的记帐有影响的参数测定值，诸如持续时间；

ii)将所述记录传输到一个数据处理系统6中，该系统包括一个数据分析器；

iii)相对于格式和路径信息方面，确认所述记录中的数据，随后分析其中的无效数据；

iv)在无效数据的分析中，识别可能被设置为省缺值的数据；

v)设置该数据为省缺值；以及

vi)根据其中的信息处理每个所述记录，以生成记帐信息，用于向与所述一个或多个第二通信网络之每一个相关的实体开帐单。

2、按照权利要求1的方法，其中所述第一网络包括一个公共电话交换网。

3、按照权利要求1的方法，其中所述数据处理步骤包括按照所述起源网络的实体流送所述数据。

4、按照权利要求3的方法，其中该第一网络包括一个含有本地交换机与长途交换机的通信网络，并且该数据处理步骤包含按照标识起源网络的路径信息使来自一个数据库的定价与收费数据互相关联。

5、按照权利要求4的方法，其中所述互相关联是在流送数据后进行的。

6、一种在采集与处理与多个网络相关的通信记录中使用的数据采集与处理系统，每个网络发起或终止通话，其中所述系统包括至少一个输入端，用于接收在所述多个网络中的一个第一网络与所述多个网络中至少另一个之间的一个连接点上生成的通信记录，所述记录提供在其中发生一个相关通信事例或该通信事例从其中进入所述第一网络的该网络的识别及一个与该通信事例相关的对记帐有影响的参数测定值，诸如持续时间，该系统还包括确认装置，用于确认该记录的格式与路由信息方面；数据分析装置，用于分析被所述确认装置拒绝的错误记录，该分析装置能分类所述错误记录及将省缺值施加在至少一类错误记录上；数据分类装置，用于按照所述网络识别分类经过确认与省缺的记录；以及定价装置，用于接收经过分类的记录并根据包含在其中的信息生成供向与识别的网络相关的实体开帐单中使用的记帐信息。

7、一种如权利要求6所述的数据处理装置，用于处理多个通信网络中的第一网络中采集的数据，其中通信终止但是关于通话事例发生在该第一网络外面，该装置包括：

i)用于输入所述数据的一个数据输入端，所述数据至少包括多种分类特征中的一种；

ii)用于检验在该数据输入端上接收的数据的检验装置；

iii)一个数据分析器，用于分析被该检验装置拒绝的数据，及用于为此代入补正的或省缺数据。

iv)定价装置，用于按照可更新的参照信息，为检验装置或数据分析器所输出的数据定价；以及

v)输出装置，用于将定过价的数据从定价装置输出到存储器单元中，各存储器单元是专用于与所述分类特征中的一种或多种相关的数据的。

8、按照权利要求7的数据处理装置，其中各分类特征识别所述第一通信网络外面之网络的另一个网络，一次相关的通信便是在该另一网络中发生的。

9、按照权利要求7或8中任何一项的装置，其中所述通信网络的所述第一网络和至少一个另外的网络各构成为一个相应的公共电话交换网。

10、按照权利要求7或8中任何一项的装置，其中所述数据分析器包括将不能补正或省缺的数据存储在一个挂起数据存储器中供可能的后续处理的装置。

11、一种如权利要求6所述的数据采集与处理装置，用于若干通信网络的一个第一通信网络中，其中通信终止，该第一网络连接在这些网络的其它网络上并接收来自它们的通信事例，该装置包括：

a)登记装置，用于登记发生在所述其它网络之一中的进入该第一网络的一次通信事例；

b)用于格式化所述通信事例的一个记录的装置，该记录包括识别其它网络中的所述一个的数据及一个参数值，诸如与该通信事例相关的持续时间，

c)用于确认所述记录的确认装置，

d)定价与收费装置，用于将定价与收费数据与一个确认的记录关联，并提供经过定价、收费与确认的记录的一个分类的数组，该数组是按照这些其它网络的本体分类的，以及

e)分析装置，用于分析被该确认装置拒绝的记录，该分析装置配置成根据拒绝的原因以至少三种方法的一种处理被拒绝的记录，所述三种方法为将一个未被确认的记录中的值设定为一个最佳吻合的值，或将未被确认的记录中的值设定为省缺值，或者归档或转储该未被确认的记录，将已经以第一或第二方法处理过的记录作为确认的记录直接或间接传输到定价与收费装置8。

12、按照权利要求11的装置，其中所述第一网络的一个交换机配置成接受一次通信事例，一个数据采集器配置成作为所述登记装置登记该通信事例的一个记录，包含在所述记录中的路由信息提供识别其它网络中的所述一个数据，以及其中该确认装置能访问一个路由参照数据模型并且配置成利用该路由信息与该路由参照数据模型之间的互相关联程度作为确认一个记录的标准之一。

13、按照权利要求11的装置，其中该分析装置还配置成处理被拒绝的记录，该处理是通过将关于一个未被确认的记录的数据附加在一个挂起数据存储器中的一个文件上，该数据能在以后被访问与分析。

14、按照权利要求13的一种装置，其中该挂起数据存储器中的各文件是专用于具有相同的错误模式的未被确认的记录的。

15、按照权利要求11至14中任何一项的装置，其中该定价与收费装置包括确认装置或者能访问确认装置，并且配置成将未被确认的记录输出到分析装置，以便从第一次在该装置中得到确认起，允许重新处理曾经损坏的数据。

Images