CN1882002A - 一种通信系统中业务信息的收集系统和方法 - Google Patents

Abstract

本发明公开了一种通信系统中业务信息的收集系统和方法，收集系统包括业务系统和呼叫日志系统，业务系统设置在通信系统的业务处理设备内，用于进行业务处理，在有新业务接入时通知呼叫日志系统收集业务信息，在本次业务处理过程中将业务处理设备内部处理的业务信息发送到呼叫日志系统收集，本次业务终止时通知呼叫日志系统；呼叫日志系统在业务过程中收集业务系统发送的业务信息，并在业务终止时生成由收集到的业务信息组成的本次业务的呼叫日志。本发明可以实现对单个业务过程的业务信息进行记录，便于故障分析和定位，减少工作量。

Description

一种通信系统中业务信息的收集系统和方法

技术领域

本发明涉及通信系统的故障分析技术，尤其是涉及一种作为业务故障分析基础的通信系统中业务信息的收集系统和方法。

背景技术

目前的通信系统已经发展到第三代(3G)移动通信系统。例如通用移动通信系统(UMTS，Universal Mobile Telecommunications System)是采用宽带码分多址(WCDMA，Wideband Code Division Multi-Access)空中接口技术的第三代移动通信系统。陆地无线接入网(UTRAN)、核心网(CN)与用户设备(UE)一起构成了整个UMTS系统。移动交换中心(MSC)/拜访位置寄存器(VLR)是WCDMA核心网电路(CS)域的业务处理功能节点。

由于通信系统的发展，通信系统内业务处理设备的业务复杂程度和用户容量都大大增加。例如是在3G R4架构下的业务处理设备移动交换中心(MSC)分为MSC服务器(MSC Server)和媒体网关(MGW)，一个MSCServer可以管理多个MGW，同时接入全球移动通信系统(GSM)和UMTS，MSC的主要功能之一表现在MSC对业务流程的控制处理上，而在其上运行的业务流程十分复杂。复杂的业务流程和巨大的用户容量导致业务处理设备在处理业务过程中的故障率提高了，因此当处理设备内部的业务发生故障时如何进行快速诊断和定位，直接影响到了网络运营上的服务提供质量和网络可维护程度。如果要分析故障原因并进一步定位故障，需要对业务处理设备的业务处理过程中的业务信息进行收集，并在此基础上进行分析以确定故障，进而排除故障。

在现有通信系统的日常维护工作中，通过如下方法来收集业务处理设备内在业务处理过程中的业务信息以进行故障分析：

1)性能统计方案。性能统计是通过统计网络中关键的统计项来衡量当前网络的质量，该方法是在一个特定测量周期内对通信设备内部的各种业务处理数据进行统计，并将该统计数据反馈给网络管理系统，由网络管理系统进行全面的分析，通过分析结果指导对现有业务处理设备的扩容和问题解决。

该性能统计方案存在着明显的缺点：该方案是一种长时间，或者说是一种周期任务的统计方案，即在一段时间内统计业务设备内部处理业务的成功率或者失败率是多少，其反映的是一个业务处理设备的整体的运行情况，对于单个业务处理流程的失败不能提供更多的定位信息，因而难以对单个业务处理过程出现故障的原因进行细致的异常分析。

2)全网信令跟踪检测方法。信令跟踪的方法是通过信令分析仪器在通信设备的标准协议接口上跟踪业务过程中业务处理设备(例如MSC)与其它网元的符合标准协议的信令接口消息(也称为挂表跟踪)，如Iu接口，C/D接口，ISDN用户部分(ISUP)接口，并将这些相关的消息发送给网络管理中心，通过对这些跟踪到的消息来进行分析，根据分析结果对网络进行优化，同时解决部分故障问题。对于业务处理设备内部一般根据厂家自行设计的消息跟踪仪进行跟踪分析。

全网信令跟踪检测方法的缺点如下：全网信令跟踪检测方法是一种实时的跟踪，需要预先配置第三方仪器进行跟踪，信令跟踪的数据量很大，而从大量的信令消息跟踪中获取有用的信息，需要巨大的工作量。另外由于跟踪到的信息只是简单的罗列，没有顺序与分类，很难进行对于单个业务流程的失败分析，不易于按照用户行为进行提取和分析，为分析工作带来了巨大的困难。另一方面在收集业务处理设备的内部业务信息时，由于业务处理设备的性能限制不可能进行全部信息的跟踪。另外由于很多故障是不可预知的，因此不可能在业务处理设备上事先定义相关的跟踪条件。

发明内容

有鉴于此，本发明的主要目的在于提供一种通信系统中业务信息的收集系统，以实现对单个业务处理过程的业务信息进行记录，便于故障分析和定位，减少工作量。

本发明的另一目的在于提供一种通信系统中业务信息的收集方法，也可以实现对单个业务处理过程的业务信息进行记录，便于故障分析和定位，减少工作量。

为了实现上述发明目的，本发明的主要技术方案为：

一种通信系统中业务信息的收集系统，该收集系统包括业务系统和呼叫日志系统，其中：

业务系统设置在通信系统的业务处理设备内，用于进行业务处理，并用于在有新业务接入时通知呼叫日志系统收集业务信息，在本次业务处理过程中将业务处理设备内部处理的业务信息发送到呼叫日志系统收集，在本次业务终止时通知呼叫日志系统生成呼叫日志；

呼叫日志系统用于收集业务系统发送的业务信息，并在所述业务终止时生成由收集到的业务信息组成的本次业务的呼叫日志。

优选的，所述呼叫日志系统具体包括：

呼叫日志启动单元，用于接收业务系统的新业务接入通知，并向业务信息收集单元发送启动指令；

业务信息收集单元，用于启动后收集业务系统发送的业务信息；

呼叫日志生成单元，用于在收到业务系统发送的本次业务终止通知后，根据业务信息收集单元收集的业务信息生成本次业务的呼叫日志。

优选的，所述呼叫日志生成单元中进一步包括：呼叫日志的触发单元，用于在收到业务系统发送的本次业务终止通知后，根据预设的触发条件判断是否需生成呼叫日志，如果需要则触发呼叫日志生成单元生成本次业务的呼叫日志，否则，不触发生成呼叫日志。

优选的，所述触发单元具有面向用户的触发条件设置接口，通过该接口根据用户指令设置所述触发条件。

优选的，所述收集系统进一步包括呼叫日志服务器，用于接收存储呼叫日志，进行统一管理；

所述呼叫日志系统进一步包括编码发送单元，用于按照预定的编码格式对所生成的呼叫日志进行编码并发送给呼叫日志服务器。

优选的，所述呼叫日志系统中进一步包括：过滤缓存单元，用于对当前生成的呼叫日志进行缓存，并判断该呼叫日志是否符合预设的过滤条件，是则继续缓存并传输到编码发送单元进行发送；否则取消发送。

优选的，所述过滤缓存单元具有面向用户的过滤条件设置接口，通过该接口根据用户指令设置所述过滤条件。

一种通信系统中业务信息的收集方法，包括：

当通信系统中的业务处理设备在处理某次业务时，收集该业务处理设备内部处理的业务信息，该项业务终止时生成由所收集到的业务信息组成的呼叫日志，该呼叫日志与该次业务相对应。

优选地，该方法进一步包括：当所述业务处理设备收到来自外部实体新的业务建立请求时，则启动收集所述业务信息的过程；当本次业务终止时，则停止收集所述业务信息，生成本次业务的呼叫日志。

优选地，该方法进一步包括：设置生成呼叫日志的触发条件；当所述本次业务终止时，根据所述触发条件判断是否需要触发生成呼叫日志，是则执行后续的生成本次业务的呼叫日志的步骤，否则不生成本次业务的呼叫日志，结束本流程。

优选地，所述触发条件为本次业务的处理结果：如果本次业务处理失败，则需要触发生成本次业务的呼叫日志，否则不需触发生成本次业务的呼叫日志。

优选地，该方法进一步包括：设置呼叫日志服务器；将生成的呼叫日志发送给该呼叫日志服务器统一管理。

优选地，该方法进一步包括：

设置过滤条件；在向呼叫日志服务器发送呼叫日志之前进一步判断该呼叫日志是否符合过滤条件，如果符合则执行后续的向呼叫日志服务器发送该呼叫日志的步骤；否则不向呼叫日志服务器发送该呼叫日志，结束本流程。

优选地，所述的过滤条件包括：所处理业务的业务类型和失败原因。

优选地，所述业务处理设备为第三代移动通信系统中的移动交换中心服务器MSC-S；所述MSC-S所处理的业务为连接管理CM业务；所述集MSC-S内部处理的业务信息的具体过程包括：

A、在MSC-S收到本次业务相关的基站控制器BSC发送的CM业务请求消息后，启动收集业务信息的过程，记录本次业务的业务类型；

B、在MSC-S完成加密判断处理、向所述BSC发送加密命令消息的过程后，记录本过程相关的加密信息；当BSC向MSC-S返回加密完成消息后，MSC-S记录相关的加密完成信息；

C、当MSC-S收到终端的呼叫建立消息后记录相关的被叫号码信息，之后继续业务处理，向BSC返回呼叫正在进行消息；

D、在MSC-S向本次业务相关的媒体网关MGW发送增加端点请求消息、MGW返回增加端点响应消息的过程后，记录该过程相关的主叫侧承载信息；

E、在MSC-S向BSC发送指配请求、BSC返回携带指配失败原因信息的指配失败消息的过程后，记录指配失败原因信息；

F、在MSC-S向BSC返回拆离消息后，记录呼叫释放信息；

G、在本次业务结束时，结束对本次业务的业务信息的收集。

优选地，所述业务处理设备为宽带码分多址系统中的移动交换中心、拜访位置寄存器、媒体网关、或网关移动交换中心。

由于本发明是指针对业务处理设备内部的一次业务处理过程(例如呼叫、短消息、切换、多连接呼叫等)中的业务信息进行收集并生成呼叫日志，业务处理设备的单次业务的整个业务过程的业务信息被存放到呼叫日志服务器，用户可以利用浏览查看各次业务过程的呼叫日志，很容易对单个的具体业务的流程进行分析，容易对业务处理设备内部故障进行准确的定位；由于本发明的业务信息可以分类存储，使得在定位不同类型问题时，可以有侧重的分析不同类别的信息，因此可以更方便地对业务处理设备内的业务流程进行分析和故障定位。另外，由于本发明在业务终止时，可以根据预定的触发条件判断是否生成呼叫日志，例如只有对于失败的业务才生成呼叫日志，对于数量占多数的成功的业务过程不产生呼叫日志，而且可设置过滤条件，只有符合过滤条件的呼叫日志才可以发送给呼叫日志服务器处理，因此本发明可以减少业务信息的收集量，降低收集业务信息的设备的处理工作量，同时降低工作人员的分析工作量，节约成本。

附图说明

图1为本发明所述方法实现呼叫日志的架构图；

图2为本发明所述业务信息收集系统的一种实施例的结构图；

图3为本发明所述方法的一种实施例的流程图；

图4为本发明所述收集业务信息的一种具体实例的示意图；

图5为本发明所述设置过滤条件的一种实施例的示意图。

具体实施方式

下面通过具体实施例和附图对本发明做进一步详细说明。

本发明所述的呼叫日志，是指针对业务处理设备的一次业务过程(例如呼叫、短消息、切换、多连接呼叫等)中，收集记录业务处理设备内部在整个业务过程中的业务信息(也可以称为轨迹信息)，将本次业务过程中所收集的业务信息组合为一个呼叫日志。用于管理员对本次业务过程的业务处理设备内的业务流程进行分析，从而定位业务处理设备内部的故障。呼叫日志是面向用户，面向业务流程的，是业务处理设备对一次完整的业务流程中业务信息内容的记录。

图1为本发明所述方法实现呼叫日志的一种架构图。如图1所示，本发明的方法可设置呼叫日志服务器，该呼叫日志服务器可以设置在网络管理系统中，也可单独设置；当通信系统中的业务处理设备(例如MSC)在处理某项业务时，收集该业务处理设备内部业务处理流程中的业务信息，在该项业务终止时生成由所收集到的业务信息组成的呼叫日志，将生成的呼叫日志通过标准协议消息发送给呼叫日志服务器进行统一管理。用户可以通过呼叫日志工作台登陆呼叫日志服务器对呼叫日志进行管理分析，根据这些呼叫日志来分析呼叫出现的问题，并通过呼叫日志中的消息信元分析定位问题，并通过相应的手段来排除故障。

本发明适用于通信系统中所有的业务处理设备的业务信息的收集，所述业务处理设备例如：WCDMA系统中的移动交换中心MSC、VLR、媒体网关(MGW)、或网关MSC(GMSC)等。本文中以应用到MSC为例对本发明进行说明。

图2为本发明所述业务信息收集系统的一种实施例的结构图。参见图2，该收集系统包括业务系统21、呼叫日志系统22、呼叫日志服务器23，其中：

业务系统21设置在通信系统的业务处理设备(此处为MSC)内，用于进行业务处理，并用于在有新业务接入时由业务接入单元211通知呼叫日志系统22收集业务信息，在本次业务处理过程中由业务处理单元212将业务处理设备内部的业务信息发送到呼叫日志系统22收集，本次业务终止时由业务终止单元213通知呼叫日志系统22；

呼叫日志系统22用于在业务开始时启动收集业务系统21发送的业务信息，并在本次业务终止时生成由收集到的业务信息组成的本次业务的呼叫日志，发送到呼叫日志服务器23；具体包括：

呼叫日志启动单元221，用于接收业务系统21的有新业务接入的通知，并向业务信息收集单元发送启动指令；

业务信息收集单元222，用于收集业务系统21发送的业务信息；

呼叫日志生成单元223，用于在收到业务系统21发送的本次业务终止通知后，根据业务信息收集单元222收集的业务信息生成呼叫日志；该呼叫日志生成单元223中进一步包括：呼叫日志的触发单元224，用于在收到业务系统21发送的本次业务终止通知后，根据预设的触发条件判断是否需生成呼叫日志，如果需要则触发呼叫日志生成单元223生成呼叫日志，否则，不触发生成呼叫日志。所述触发单元具有面向用户的触发条件设置接口，通过该接口根据用户指令设置所述触发条件。

过滤缓存单元225，用于对当前生成的本次业务的呼叫日志进行缓存，并判断该呼叫日志是否符合预设的过滤条件，是则继续缓存并传输到编码发送单元226进行发送；否则取消发送或减少发送量。所述过滤缓存单元225具有面向用户的过滤条件设置接口，通过该接口根据用户指令设置所述过滤条件。

编码发送单元226，用于按照预定的编码格式对所生成的呼叫日志进行编码并发送给呼叫日志服务器23。

呼叫日志服务器23用于接收存储呼叫日志，进行统一管理，可以实现对业务故障进行检索、分类、统计和深入挖掘分析。

图3为本发明所述方法的一种实施例的流程图。参见图3，该实施例的流程具体包括：

步骤31、当所述业务处理设备收到来自外部实体的新的业务建立请求时(即有新业务接入时)启动呼叫日志。比如收到从A接口、Iu接口收到CM Service Request消息或者中继入局的IAM消息、或者E接口的切换入局请求MAP-Prepare-Handover-Request时，此时一个新的业务处理流程在业务处理设备中启动，这时业务系统21向呼叫日志系统22申请启动呼叫日志，呼叫日志系统为本次业务分配一个呼叫日志的标识，返回给业务系统21，启动本呼叫日志的业务信息收集的过程。在后续的业务系统21向呼叫日志系统22发送的关于本次业务的业务信息都以所分配的呼叫日志标识作为句柄进行索引。

步骤32、业务信息收集。当业务系统21启动了呼叫日志后，在本次业务流程中收集该业务处理设备内部的业务信息，即将业务处理流程中的关键信息以消息的格式输出到呼叫日志系统22中进行记录，上述的呼叫日志标识作为这些业务信息的句柄，呼叫日志系统22记录所收集的业务信息。

在所述业务信息中，尤其要包括导致信令流程失败的关键信息：例如业务类型以及导致业务处理过程失败的原因等信息。

图4为本发明所述收集业务信息的一种具体实例的示意图，该具体实例中所处理的业务为CM业务。参见图4，MSC-S(即业务处理设备)在收到BSC的CM业务请求消息(即CM Service Request)后，开始进行业务处理，在进行业务处理的同时向呼叫日志系统发送业务信息，具体如下步骤：

步骤401～步骤402、MSC-S收到连接管理CM业务请求消息(CM ServiceRequest)后，向呼叫日志系统发送本次业务的业务类型进行收集记录，并以此申请启动呼叫日志，日志系统分配本次业务的呼叫日志标识，向MSC-S返回携带该呼叫日志标识的响应，MSC-S收到呼叫日志系统的响应后继续本次业务的处理。

步骤403～步骤404、MSC-S在完成加密判断处理后，向BSC发送加密命令消息(Ciphering Command)，同时将本处理过程相关的加密信息发送到日志系统进行收集记录；当BSC返回加密完成消息(Ciphering Complete)后，发送相关的加密完成信息到日志系统进行收集记录；

步骤405、当MSC-S收到终端的呼叫建立消息(Setup)后向呼叫日志系统发送被叫号码等信息进行记录，之后继续业务处理，向BSC返回呼叫正在进行(Call Proceeding)消息。

步骤406、MSC-S向MGW发送增加端点请求消息ADD.req(T1，$)、MGW返回增加端点响应消息ADD.reply(T1)的过程后，MSC-S发送该过程相关的主叫侧承载信息到呼叫日志系统进行收集记录；

步骤407、MSC-S向BSC发送指配请求Assignment Request，BSC在指配失败的情况下返回携带指配失败原因信息的指配失败消息AssignmentFailure的过程后，MSC-S发送指配失败原因到呼叫日志系统进行收集记录。

步骤408、MSC-S返回拆离消息Disconnect后，发送呼叫释放信息到呼叫日志系统进行记录。

步骤409、本次业务结束，MSC-S通知日志系统结束对本次业务的业务信息的收集，生成由所收集到的业务信息(即所记录的业务种类、加密信息、加密完成信息、被叫号码信息、主叫侧承载信息、记录指配失败信息，呼叫失败原因信息等)本次业务呼叫日志。

优选的，本步骤收集的业务信息可以是整个业务处理过程中，业务处理设备进行业务处理的所有业务信息。

步骤33、呼叫日志生成。当本次业务流程终止的时候，呼叫日志系统22需要生成由所收集到的业务信息组成的呼叫日志，该呼叫日志与该次业务相对应，以所述的呼叫日志标识为句柄。本发明中可对呼叫日志中的业务信息分类存储，使得在定位不同类型问题时，可以有侧重的分析不同类别的信息，例如将上述业务种类、被叫号码、主叫侧承载信息等分类存储。

本发明中可由用户预先设置生成呼叫日志的触发条件；当所述本次业务终止时，根据所述触发条件判断是否需要触发生成呼叫日志，是则生成本次业务的呼叫日志，否则不生成本次业务的呼叫日志，结束本流程。所述的触发条件可以设置为本次业务的处理结果：如果本次业务处理失败，则需要触发生成本次业务的呼叫日志，否则不需触发生成本次业务的呼叫日志。因此对于数量占多数的成功的业务过程，是不需要产生呼叫日志的。

步骤34、呼叫日志的过滤与缓存。本发明可预先由用户设置过滤条件，在向呼叫日志服务器23发送呼叫日志之前进一步判断该呼叫日志是否满足过滤条件，满足过滤条件则需向呼叫日志服务器23发送呼叫日志，执行步骤35；否则，不向呼叫日志服务器23发送该呼叫日志，结束本流程。

图5为本发明所述设置过滤条件的一种实施例的示意图。参见图5，用户可以通过面向用户的接口设置过滤条件，该接口提供的设置方式主要包括两部分：首先是对业务类型进行设置，例如需要过滤的是语音呼叫业务、视频呼叫业务、切换业务、位置更新业务、还是短消息业务等；其次是对该业务的失败原因进行设置，例如需要过滤的可以是主叫早释、拨号错误、振铃早释、电路堵塞、寻呼无响应等失败原因。所述生成的呼叫日志输入过滤缓存单元后，经过业务类型和失败原因两层过滤，再输出到缓存中发送。例如用户设置的过滤条件为业务类型为语音呼叫，失败类型为拨号错误，则判断呼叫日志中所收集的业务信息是否为语音呼叫业务且是否发生拨号错误，如果是，则输出到缓存中发送，否则不输出发送该呼叫日志。此处的图5只是对过滤条件的一个举例说明，本发明也可为用户提供其他的设置接口，以设置不同的过滤条件：例如可以用业务建立起始时间作为过滤条件。

对呼叫日志进行过滤，一方面是考虑到对于某些失败流程，比如主叫用户振铃早释、被叫拒绝应答等用户行为导致的业务失败，不需要通过呼叫日志进行具体分析。另一方面如果某个故障原因已经诊断清楚，可以通过过滤减少大量的呼叫日志输出，减少对系统资源的占用，并减少分析工作量。

步骤35、呼叫日志编码与发送。呼叫日志在输出给呼叫日志服务器23时需要按照预先定义的格式标准进行编码，比如可以采用文本、二进制或ASN.1格式，编码后再发送给呼叫日志服务器23，由呼叫日志服务器23进行统一管理。采用适当的编码方案可以减少网络设备和呼叫日志服务器23之间的通信流量，提高系统整体效率。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人在本发明所揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (16)

1、一种通信系统中业务信息的收集系统，其特征在于，该收集系统包括业务系统和呼叫日志系统，其中：

业务系统设置在通信系统的业务处理设备内，用于进行业务处理，并用于在有新业务接入时通知呼叫日志系统收集业务信息，在本次业务处理过程中将业务处理设备内部处理的业务信息发送到呼叫日志系统收集，在本次业务终止时通知呼叫日志系统生成呼叫日志；

呼叫日志系统用于收集业务系统发送的业务信息，并在所述业务终止时生成由收集到的业务信息组成的本次业务的呼叫日志。

2、根据权利要求1所述的收集系统，其特征在于，所述呼叫日志系统具体包括：

呼叫日志启动单元，用于接收业务系统的新业务接入通知，并向业务信息收集单元发送启动指令；

业务信息收集单元，用于启动后收集业务系统发送的业务信息；

呼叫日志生成单元，用于在收到业务系统发送的本次业务终止通知后，根据业务信息收集单元收集的业务信息生成本次业务的呼叫日志。

3、根据权利要求2所述的收集系统，其特征在于，所述呼叫日志生成单元中进一步包括：呼叫日志的触发单元，用于在收到业务系统发送的本次业务终止通知后，根据预设的触发条件判断是否需生成呼叫日志，如果需要则触发呼叫日志生成单元生成本次业务的呼叫日志，否则，不触发生成呼叫日志。

4、根据权利要求3所述的收集系统，其特征在于，所述触发单元具有面向用户的触发条件设置接口，通过该接口根据用户指令设置所述触发条件。

5、根据权利要求1所述的收集系统，其特征在于，

所述收集系统进一步包括呼叫日志服务器，用于接收存储呼叫日志，进行统一管理；

所述呼叫日志系统进一步包括编码发送单元，用于按照预定的编码格式对所生成的呼叫日志进行编码并发送给呼叫日志服务器。

6、根据权利要求5所述的收集系统，其特征在于，所述呼叫日志系统中进一步包括：过滤缓存单元，用于对当前生成的呼叫日志进行缓存，并判断该呼叫日志是否符合预设的过滤条件，是则继续缓存并传输到编码发送单元进行发送；否则取消发送。

7、根据权利要求6所述的收集系统，其特征在于，所述过滤缓存单元具有面向用户的过滤条件设置接口，通过该接口根据用户指令设置所述过滤条件。

8、一种通信系统中业务信息的收集方法，其特征在于，

当通信系统中的业务处理设备在处理某次业务时，收集该业务处理设备内部处理的业务信息，该项业务终止时生成由所收集到的业务信息组成的呼叫日志，该呼叫日志与该次业务相对应。

9、根据权利要求8所述的方法，其特征在于，该方法进一步包括：当所述业务处理设备收到来自外部实体新的业务建立请求时，则启动收集所述业务信息的过程；当本次业务终止时，则停止收集所述业务信息，生成本次业务的呼叫日志。

10、根据权利要求9所述的方法，其特征在于，该方法进一步包括：设置生成呼叫日志的触发条件；当所述本次业务终止时，根据所述触发条件判断是否需要触发生成呼叫日志，是则执行后续的生成本次业务的呼叫日志的步骤，否则不生成本次业务的呼叫日志，结束本流程。

11、根据权利要求10所述的方法，其特征在于，所述触发条件为本次业务的处理结果：如果本次业务处理失败，则需要触发生成本次业务的呼叫日志，否则不需触发生成本次业务的呼叫日志。

12、根据权利要求8所述的方法，其特征在于，该方法进一步包括：设置呼叫日志服务器；将生成的呼叫日志发送给该呼叫日志服务器统一管理。

13、根据权利要求12所述的方法，其特征在于，该方法进一步包括：

设置过滤条件；在向呼叫日志服务器发送呼叫日志之前进一步判断该呼叫日志是否符合过滤条件，如果符合则执行后续的向呼叫日志服务器发送该呼叫日志的步骤；否则不向呼叫日志服务器发送该呼叫日志，结束本流程。

14、根据权利要求13所述的方法，其特征在于，所述的过滤条件包括：所处理业务的业务类型和失败原因。

15、根据权利要求8所述的方法，其特征在于，所述业务处理设备为第三代移动通信系统中的移动交换中心服务器MSC-S；所述MSC-S所处理的业务为连接管理CM业务；所述集MSC-S内部处理的业务信息的具体过程包括：

A、在MSC-S收到本次业务相关的基站控制器BSC发送的CM业务请求消息后，启动收集业务信息的过程，记录本次业务的业务类型；

B、在MSC-S完成加密判断处理、向所述BSC发送加密命令消息的过程后，记录本过程相关的加密信息；当BSC向MSC-S返回加密完成消息后，MSC-S记录相关的加密完成信息；

C、当MSC-S收到终端的呼叫建立消息后记录相关的被叫号码信息，之后继续业务处理，向BSC返回呼叫正在进行消息；

D、在MSC-S向本次业务相关的媒体网关MGW发送增加端点请求消息、MGW返回增加端点响应消息的过程后，记录该过程相关的主叫侧承载信息；

E、在MSC-S向BSC发送指配请求、BSC返回携带指配失败原因信息的指配失败消息的过程后，记录指配失败原因信息；

F、在MSC-S向BSC返回拆离消息后，记录呼叫释放信息；

G、在本次业务结束时，结束对本次业务的业务信息的收集。

16、根据权利要求8所述的方法，其特征在于，所述业务处理设备为宽带码分多址系统中的移动交换中心、拜访位置寄存器、媒体网关、或网关移动交换中心。

Images