CN101316389A - 一种移动通信业务处理方法及装置 - Google Patents

Abstract

本发明公开了一种移动通信业务的处理方法及装置，包括：获取与移动终端建立移动通信业务的连接信息；根据所述连接信息与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；根据所述业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端；获取建立移动通信业务失败的失败原因。使用本发明可以在移动终端建立通信业务失败后，自动得到相关移动终端的失败原因，并直接反馈给移动终端用户，从而能够减少用户投诉，提高运营商网络运维管理的工作效率，以及提高运营商的竞争力。

Description

一种移动通信业务处理方法及装置

技术领域

本发明涉及移动通信领域，特别涉及一种移动通信业务的处理方法及装置。

背景技术

随着移动网络规模的日益扩大，一些如短信、彩信、电子邮件以及充值等移动通信数据业务迅速发展，用户对移动运营商整体服务的要求也越来越高，服务能力正逐渐成为企业核心竞争力之一，而其中投诉管理贯穿整个客户服务工作，是客户服务工作的基础，也是提升客户服务能力的关键因素，投诉数量的多少直接说明了运营商的服务能力和运营能力。目前各运营商都有自己的投诉处理和分析系统，但都是被动和消极的方法，是一种事后处理系统，当用户在使用运营商的服务过程中遇到问题和故障后，用户通过电话投诉，运营商的客服部门根据用户投诉问题去解决和处理问题。

目前处理投诉的方案，其主要流程是：

1、当用户在移动通信业务体验中遇到业务失败问题后，用户打电话投诉到运营商客服部门；

2、移动运营商的客服人员、网络运维管理人员根据投诉内容去查找相应的数据，并和用户多次确认，了解业务问题发生的背景，分析找出业务失败原因；

3、移动运营商的客服人员回复用户的投诉，给出问题解决方案。

显然，在这种模式下至少会产生如下缺点和问题：

1、这是一种事后的被动的移动通信业务问题处理方式，其必须等用户投诉问题发生以后才能去被动地解决和处理投诉，这不仅将导致用户满意度低，还会导致运营商客服人员和网络运维管理人员进行人工处理问题的工作量增加，运营商竞争力下降；

2、同时，涉及双方反复的沟通等协调处理，使得处理和回复投诉问题的时间周期变长。

而产生这些缺点与问题的原因在于，现有技术中缺少能够主动对移动通信业务问题进行自动处理的方案，需要依靠运维和客服人员根据用户投诉的问题查看并分析业务处理过程日志后，再根据经验主观进行判断，才可能找出移动通信业务存在的问题所在。

发明内容

本发明提供一种移动通信业务处理方法及装置，能够在移动通信业务建立发生失败时，自动获取到该业务失败的失败原因，并进行及时的处理。

本发明提供了一种移动通信业务的处理方法，包括如下步骤：

获取与移动终端建立移动通信业务的连接信息；

根据所述连接信息与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；

根据所述业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端，确定针对失败原因的解决方案；

获取建立移动通信业务失败的失败原因和解决方案。

优选的，还包括，

将建立移动通信业务失败的失败原因和解决方案及时发送至相关移动终端。

优选的，所述根据业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端，确定针对失败原因的解决方案，包括如下步骤：

根据所述业务过程信息的业务标识、信息标识和设定的时间范围识别出每一移动终端参与的移动通信业务；

根据移动终端参与的移动通信业务的业务起止时间得到移动终端的移动通信业务的业务过程信息；

根据所述移动通信业务的业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务和相关的移动终端，确定针对失败原因的对应解决方案。

优选的，所述获取建立移动通信业务失败的失败原因和解决方案，可以包括，获取设定时间范围发生的移动通信业务的失败原因和解决方案并保存，根据业务的最新状态更新所保存的内容。

优选的，所述与移动终端建立的移动通信业务包括彩信业务、短信业务、WAP上网业务或充值业务。

优选的，将建立移动通信业务的失败原因及解决方案通过短消息方式发送至相关的移动终端。

优选的，对以上各步骤的执行设置定时执行机制，按预定时间自动执行所述的各步骤。

本发明还提供了一种移动通信业务的处理装置，包括：

接口模块，用于获取与移动终端建立移动通信业务的连接信息，与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；

筛选模块，用于根据所述业务过程信息和业务分析规则，筛选出建立移动通信业务失败的业务及相关的移动终端；

获取模块，用于获取建立移动通信业务失败相关的失败原因和解决方案；

优选的，进一步还包括发送模块，用于将建立移动通信业务失败的移动终端的失败原因和解决方案发送至该移动终端。

优选的，所述与移动终端建立的移动通信业务包括彩信业务、短信业务、WAP上网业务或充值业务。

优选的，所述接口模块包括接口连接单元、业务过程信息获取单元，其中：

接口连接单元，用于获取与移动终端建立移动通信业务的连接信息，根据移动通信业务信息存储数据库的接口访问要求，配置移动通信业务信息存储数据库接口的客户端，与移动通信业务信息存储数据库的访问接口建立连接；

业务过程信息获取单元，用于从移动通信业务信息存储数据库接口获取业务过程信息。

优选的，所述接口模块进一步包括数据格式转换单元，用于在从移动通信业务信息存储数据库接口获取业务过程信息后，用于对其进行统一的格式转换，输出给筛选模块。

优选的，所述筛选模块包括识别业务单元、业务过程信息处理单元、筛选失败业务单元，其中：

识别业务单元，用于根据所述业务过程信息的信息标识和设定的时间范围识别出每一移动终端对应的移动通信业务；

业务过程信息处理单元，用于根据移动终端的移动通信业务的起止时间得到移动终端的移动通信业务的业务过程信息；

筛选失败业务单元，用于根据所述移动通信业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务过程信息和相关的移动终端。

优选的，所述筛选失败业务单元进一步包括规则解析库、业务分析子单元，其中：

规则解析库，用于存储业务分析规则，所述业务分析规则是根据业务参数是否符合业务成功的要求制订的；

业务分析子单元，用于根据移动通信业务过程信息以及所述规则解析库中存储的规则筛选出建立移动通信业务失败的业务和相关的移动终端，确定相对应的解决方案。

优选的，所述获取模块还可以进一步包括，

数据存储单元，用于保存失败业务过程信息以及业务失败原因和解决方案；

数据更新单元，根据业务的最新状态，更新数据存储单元中的内容。

优选的，所述一种移动通信业务的处理装置，进一步还包括定时任务模块，用于定时调用装置中其他各模块。

本发明有益效果如下：

本发明提出了一种主动发现移动通信业务问题并查找原因的技术方案，从而，在移动终端建立通信业务后，对于那些移动终端与移动运营网络交互操作时导致失败的移动通信业务，移动终端将会自动得到有关的失败原因及对应的解决方案。移动终端用户根据失败原因及对应的解决方案，可以自行解决问题，重新建立正常的业务；运营商根据这些失败原因，可以进行统计分析处理，从而主动地分析问题和解决问题。进一步地，主动地将这些失败原因和解决方案发送给移动终端，将大大减少相关问题的投诉，可以提高运维工作效率，以及提高运营商的竞争力。毫无疑问，本发明能够在解决用户投诉问题上变被动为主动，变解决问题为关心用户，提高了用户的满意度，同时通过预防顾客投诉也大幅度提高了解决顾客投诉问题的效率。本发明针对当前最通用的移动通信业务-彩信业务、短信业务、WAP上网、充值业务还给出了优选的规则库定义，可以有效地确定失败原因和解决方案，并发送给相关的移动终端。

附图说明

图1为现有的移动通信业务系统结构示意图；

图2为本发明技术方案移动通信业务的处理方法实施例一流程示意图；

图3为本发明技术方案移动通信业务的处理方法实施例二流程示意图；

图4为本发明技术方案移动通信业务的处理方法的实施例三针对彩信业务和充值业务的处理方法的流程示意图；

图5为本发明实施例四针对定时反馈发送信息的处理方法的流程示意图；

图6为本发明一种移动通信业务的处理装置的实施例五的结构示意图；

图7为本发明一种移动通信业务的处理装置的实施例六的结构示意图；

图8为本发明一种移动通信业务的处理装置的实施例七的结构示意图；

图9为本发明一种移动通信业务的处理装置的实施例八的结构示意图；

图10为本发明一种移动通信业务的处理装置的实施例十的结构示意图；

图11为本发明一种移动通信业务的处理装置的实施例十一的结构示意图；

图12为本发明实施例中所述彩信通信业务处理系统结构示意图；

图13为充值卡业务日志分析处理系统结构示意图。

具体实施方式

基于现有技术中缺少能够主动对移动通信业务问题进行自动处理的方案，本发明提出一种主动发现移动通信业务问题并查找原因和给出解决方案的技术方案，其基本思想是：在移动终端使用了移动通信业务后，本发明技术方案获取与移动终端建立移动通信业务的连接信息和原始业务过程信息；再进一步地根据原始业务过程信息和业务分析规则识别出建立移动通信业务失败的移动终端；然后相应地去获取建立移动通信业务失败的原因和解决方案。

为使本领域技术人员对本发明的技术方案有更好的理解，下面结合附图和实施例对本发明的具体实施方式进行说明。

图1为现有的移动通信业务支撑系统结构示意图，图中示例了几种常用的移动通信业务支撑系统，例如WAP运维系统101、彩信业务系统102、短信业务系统103、智能网系统104等，用以实现移动通信业务，如WAP上网业务、彩信业务、短信业务、充值业务。

为了实现移动通信业务，每一种移动通信业务支撑系统都有一个或多个用于存储移动通信业务过程信息的数据库，例如，图中105所示，包括彩信业务系统中的彩信日志数据库和彩信用户数据库，短信业务系统中的短信日志数据库，WAP运维系统中的WAP业务数据库等，为便于描述，本技术方案中将这些数据库统称为移动通信业务信息存储数据库。这些数据库都有可被外部系统连接和访问的对外接口，为了成功地连接到这些接口并获得访问信息，根据数据库接口的配置要求，将数据库作为服务端，配置相应的客户端，就可以从移动通信业务信息存储数据库获得业务过程信息。需要客户端配置的信息为：数据库的连接池最大值、访问超时时限、访问用户名及密码、数据库服务端IP地址及端口号、数据库驱动程序加载路径。图1中以及本发明所有实施中所述移动终端指通过移动通信网发生移动通信业务的所有终端，并不仅限于人们所惯知的手机等设备，比如一台经因特网接入移动通信网发生移动通信业务的PC也是本发明所指的移动终端。

图2为本发明技术方案移动通信业务的处理方法实施例一流程示意图，如图2所示，对移动通信业务的处理方法可以包括如下步骤：

步骤201、获取与移动终端建立移动通信业务的连接信息；

获取与移动终端建立移动通信业务的连接信息包括如下步骤：

根据移动通信业务信息存储数据库的接口访问要求，配置移动通信业务信息存储数据库接口的客户端，包括配置以下信息之一或者其组合：

连接池最大值、访问超时时限、访问用户名及密码、数据库服务端IP地址及端口号、数据库驱动程序加载路径。

步骤202、根据所述连接信息与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；

根据所述连接信息，所配置客户端与作为服务端的移动通信业务信息存储数据库的接口建立连接；

客户端从所述接口获取业务过程信息；

从所述移动通信业务信息存储数据库的接口所获取的业务过程信息包括以下信息之一或者其组合：

移动终端的发送端标识、接收端标识、移动通信业务起止时间、用户设置的延迟发送时间、业务错误码、移动终端是否内存满、移动终端上的应用程序是否功能错误、业务提交是否成功、接收端是否成功接收、接收端是否主动拒绝接收，对于彩信业务，彩信Get后面是否跟有彩信Post、彩信中心保存彩信的时间、接收端是否发出提取彩信请求、移动中心PUSH是否成功、彩信中心收到后是否延迟发送时间、彩信提取是否成功等，对于充值业务，充值结果状态码是否为成功状态等。

各数据库接口提供的访问服务可以是指移动通信业务支撑系统提供的数据服务，例如彩信日志系统开放的数据库存储过程，WAP运维系统的数据库视图，智能网系统的VC充值中心日志数据库等。

访问数据库接口的方式，可以是：WEB SERVICE接口、用于收发网络数据包协议的SOCKET(套接字程序)接口、TELNET(远程访问)接口、HTTP(HyperText Transfer Protocol，超文本传送协议)接口、数据库表接口、数据库视图接口、数据库存储过程接口等。

业务过程信息不仅包括从数据库接口获得的原始数据，还包括原始数据的类型信息，如：数据库返回的RESULTSET类型(程序调用数据库查询接口)；WEB SERVICE的标准XML(eXtensible Markup Language，可扩展标记语言)数据类型；SOCKET的字符流类型，HTTP接口方式读取的数据类型；远程读取回来的数据流类型等。

步骤203、根据所述业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端；

由于原始业务过程信息取自不同的移动通信业务信息存储数据库，因此为了便于管理这些信息，需要为不同的业务种类分别定义一个对应的业务标识，例如彩信业务标识，短信业务标识，充值业务标识等。

当从接口获得原始业务过程信息后，将这些信息标以相对应的业务标识，就得到了按照业务分类的业务过程信息。对于同一种业务类型的多个业务信息，一般用信息标识来区分各个业务，例如彩信业务1、彩信业务2等。所述的信息标识在从移动信息存储数据库中获得的原始业务过程信息中都有相应的字段。因此，对于步骤202获取到的业务过程信息都是大量无序数据记录的情况下，根据业务标识可以整理出不同类型的业务，根据信息标识可以整理出同一类型中各个业务记录信息，可按照时间先后顺序整理。

所述业务分析规则是根据业务参数是否符合业务成功的要求制订的，业务参数记录了业务过程的数据特征，例如发送信息长度(大小)、用户提交是否成功、彩信中心保存彩信的时间、接收端是否发出提取请求、充值结果状态码等。

根据业务分析规则就可以判断所获得的业务过程信息中是否含有不满足业务分析规则条件的业务信息，如果有就提取出来，其就是包含建立移动通信业务失败和相关移动终端的业务过程信息。

步骤204、获取建立移动通信业务失败的失败原因和解决方案。

从移动通信业务信息存储数据库获取到的业务过程信息中，每一个业务都有一个业务成功与否的信息状态码，该状态码所包含的信息含义是由各相应系统的制造商提供的，例如彩信日志中的信息状态码信息在彩信日志系统的制造商提供的接口手册中有相关描述，这些信息状态码给出了业务失败时的原因。在制定业务规则时，针对每一种业务失败的情况，给出针对业务失败的原因及其对应的解决方案。因此根据以上建立移动通信业务失败的业务过程信息，就可以获取到建立移动通信业务失败的失败原因和解决方案。

由此，运营商根据这些失败原因，可以进行统计分析处理，从而主动地分析问题和解决问题。

进一步地，为了减少用户投诉，本发明还提出了进一步的技术方案，参见图3为本发明技术方案移动通信业务的处理方法实施例二流程示意图，在以上的技术方案基础上，增加步骤305如下：

步骤305、将建立移动通信业务失败的失败原因及解决方案及时发送至相关移动终端。

通过发起成功的移动通信业务，例如短信业务，将建立移动通信业务失败的失败原因及解决方案及时反馈给相关移动终端。

本步骤实现主动地将移动通信业务失败的失败原因及解决方案发送给移动终端，将大大减少相关问题的投诉，可以提高运维工作效率，以及提高运营商的竞争力。

下面对各步骤的具体实施以彩信业务为例进行说明，由于短消息业务比较简单，彩信业务较为复杂，能够较好的体现本发明，因此以彩信业务为例，但是本领域技术人员结合本发明的实施易知，本发明的方案不限于彩信业务，其他如短消息业务、上网浏览业务等移动通信业务也可适用，在根据通信业务的不同特点作出适应该业务的改动后，再运用本发明所述的方案，即在发起该种移动通信业务后，获取到该业务的业务过程信息，并据此得到发生业务失败的相关移动终端后，获取失败原因，就可以实现本发明的目的。而根据通信业务的不同特点作出适应该业务的改动在本领域都是易知的。

彩信的收发一般要求发送端或接收端的移动终端支持GPRS(GeneralPacket Radio Service，通用分组无线业务)上网而且要开通并激活，只有这样才能符合建立彩信收发业务的基本条件，在一个完整的彩信收发业务实现过程中，需要无线运营商数据专业、交换专业等多专业的共同支持，包括HLR(HomeLocation Register，归属位置寄存器)的GPRS数据，SMSC(Short MessagingService Center，短消息业务中心)的支持，MMSC(Multimedia Messaging ServiceCenter，多媒体消息业务中心)的支持等。对于发送端和接收端都是移动终端的彩信业务来说，建立移动通信业务并实现彩信移动通信业务的过程是：发送端用户通过GPRS上网方式启动发送彩信业务的请求，并将彩信内容发送到彩信业务中心，彩信业务中心是整个彩信业务系统的核心，对彩信进行存储和处理，包括彩信的输入输出、地址解析、通知、报告等，存储到彩信日志数据库中，同时负责彩信在不同MMSC之间的传递等操作，彩信业务中心通过短消息业务中心向接收端用户发出PUSH(推送业务)信息，要求接收端用户提取彩信内容；然后接收端用户在确定发送提取请求后，将直接访问彩信业务中心来获取彩信内容。由上述过程也可看出，完成移动通信业务的相关设备，根据通信业务不同，所使用或涉及到的实体、设备也不同，比如彩信业务会涉及彩信业务中心和短信业务中心。

当执行移动通信业务过程中任何一个环节发生错误，例如移动终端设置错误或设备故障、网络故障时，则此移动通信业务都将不能正常完成，如本例业务中就会表现为一条彩信的发送或接收失败。

在以上的彩信业务实现过程中会涉及到相关信息，如：移动终端连接彩信业务中心成功/失败、彩信业务中心响应移动终端请求成功/失败、短消息业务中心PUSH成功/失败、移动终端提取信息成功/失败等等信息，这些即为本发明中所称的业务过程信息，该业务过程信息在上述业务建立流程的过程中以日志等形式记录相关原始数据，这些原始数据在业务实现过程中被记录并存储在彩信日志数据库和短信日志数据库中，针对这些业务过程信息记录作主动的智能化解析，可自动识别出彩信发送失败的移动通信业务、相关的移动终端以及失败原因和对应的解决方案。

可针对用户的收发数据实现定期查询和主动分析，将业务执行失败原因和对应的解决方案反馈至相关的移动终端。业务的失败原因可能是由移动终端的错误导致的，也可能是由网络侧的错误导致，对于由于移动终端设置的错误导致的失败，可以将失败原因和重新设置的解决方案发送给发起业务的移动终端，当然，如果失败原因是与接收端相关，如接收设置错误，显然该失败原因和解决方案也可反馈至该接收终端的用户，如此，就可以使用户发现问题后由于马上获得了失败原因和解决方案而自行更改移动终端的设置，从而减少了投诉量。

图4为本发明移动通信业务的处理方法的详细流程示意图。

根据图4，给出针对彩信业务和充值业务的实施例三，可以包括如下步骤：

步骤401、与移动通信业务信息存储数据库建立连接。

本步骤中首先根据移动通信业务信息存储数据库的服务端接口要求，设置客户端访问服务端的连接相关参数，包括：连接池最大值，访问超时时限，访问用户名，密码，数据库服务端IP及端口号，数据库驱动程序加载路径等信息。然后，与移动通信业务信息存储数据库建立连接。

步骤402、获取调用移动通信业务信息存储数据库接口返回的业务过程信息。

客户端与数据库服务端接口建立连接后，客户端调用接口程序，例如针对彩信业务，本步骤客户端通过调用彩信日志数据库存储过程语句，可以获取彩信日志原始信息。例如针对充值业务，本步骤客户端通过TELNET指令调用VC充值中心日志系统，客户端便可以获取充值日志原始数据。

步骤403、根据所述业务过程信息的业务标识、信息标识和设定的时间范围识别出每一移动终端参与的移动通信业务。

一般设定时间范围可以是一天时间周期，例如在今天的凌晨零点就可以得到昨天的凌晨零点到今天的凌晨零点的24小时内某一移动终端参与的多种和多个移动通信业务信息，比如彩信业务1、彩信业务2、短信业务1、充值业务1。

对于彩信业务，所述业务过程信息的业务标识为彩信业务标识。步骤402所获取的业务过程信息是由多条无序的纪录组成的，每一条纪录中都有一个唯一的信息标识字段，存在多条相同信息标识的纪录。设定的时间范围依据处理时间周期，例如一天处理一次，那么这个时间范围就可以设定为某一天的零点到第二天的零点。因此本步骤根据所述业务过程信息的信息标识和设定的时间范围识别出每一移动终端参与的移动通信业务的业务过程信息纪录，对这些纪录根据信息标识进行排序。这样就会得到彩信业务的按相同信息标识分组的排序记录，每一相同信息标识的记录组就是一个移动通信业务。

例如一条彩信日志的数据记录如下：

<record>//结果集元素

     <TIMESTAMP>2007-08-01 13:26:53 590</TIMESTAMP>//事件发生时间

     <LOGTYPE>1</LOGTYPE>//日志类型

     <SENDER>+861379662****</SENDER>//发送号码

     <RECEIVER>+861370450****</RECEIVER>//接收方号码

     <MESSAGEID>080113265394510001307</MESSAGEID>//信息ID

     <MESSAGETYPE>1</MESSAGETYPE>//消息类型

     <AFFAIRSTATUS>1</AFFAIRSTATUS>//事件状态

     <ADDONSINFO>SV：NULL；MsgCls：PRSL；DR：YES；RR：NO；MsgSz：26735 Byte(s)；PSHCD：4022；MMSTAT：REJECT；</ADDONSINFO>//附加信息

  </record>

其中：

record为结果集元素，调用一次接口，可获取多条记录，也可能为空。其子元素中包含数据的基本信息，主要内容：

<TIMESTAMP>：此事件发生时间；

<SENDER>：发送方号码；

<RECEIVER>：接收方号码；

<MESSAGEID>：信息标识ID。此ID用于区分多条纪录中的唯一标识；

<AFFAIRSTATUS>：此条记录的事件状态。根据业务支撑系统的移动通信业务信息存储数据库接口，该字段有四个值与其含义可以为：1为OK；2为SENDING；3为TMPFAL；4为PRTFAL。

<ADDONSINFO>：此条事件的详细日志；

<LOGTYPE>标识该条记录的日志类型；

<MESSAGETYPE>消息类型，业务消息的消息类型；

<ADDONINFO>附加信息，关于流程状态以及其他参数的附加描述信息；

对于<ADDONINFO>中的信息，每条记录都是不同的，对于SV：NULL；MsgCls：PRSL；DR：YES；RR：NO；MsgSz：26735 Byte(s)的含义可以解释如下：

SV(SenderVisibilityTag)，意思是地址隐藏。值NULL意思是未设置；

MsgCls(MessageClassTag)，意思是消息类型；

MsgSz(MessageSizeTag)，意思是消息大小；

PSHCD(Push code)，意思是短信中心PUSH信息是否成功；

MMSTAT(MMS state)，彩信信息状态码。

对于充值业务，所述业务过程信息的业务标识为充值业务标识。

步骤402所获取的业务过程信息由多条无序的充值日志信息纪录组成，所以首先需要按照信息标识找出每一个业务的记录信息。

如下是一个充值业务的原始日志数据记录：

2005/05/24 14:20:02 [0000440359] >>>[[277，0，0，5][394635，0，QUERY，0，0，230，0] COMM_BOSS_184566782 CHARGE UCCUSER：TRANSACTION_ID＝05241421051392082180122855887800，USER_NUMBER＝139********，REQUEST_TIMESTAMP＝20050524142451，ACCOUNT_TYPE1＝0103，AMOUNT1＝50000，CARDPIN＝021607171844953178，CARD_NO＝05947020009729949，CALL_NUMBER＝02285588780]

2005/05/24 14:20:02 [0000440359] ---BOSS_LINK[0]：sendok：[164][0164010103010000SouaddDesadd00004403590524142105139208218012285588780013920821801

20050524142451010300000005000000020017059470200097299490002001102285588780][WAIT:0s]

2005/05/24 14:20:02 [0000440359] ---BOSS_LINK[0]：getack：[48][0048010203010000SouaddDesadd0000440359000100020K]

2005/05/24 14:20:02 [0000440359]<<<[[81，5，0，0][394635，0，ANSWER，0，0，55，0]COMM_BOSS_184566782ACK：CHARGE UCCUSER：RETN＝1@0000，STATUS_DESCRIPTION＝1@0K][RUN:00s]

原始记录详解：

第一条：

//上行示：UA接口从SCP获得一个充值命令请求，UA接口seq_no编号为“0000440359”，为记录流水号。

//TRANSACTION_ID       交易流水号，也是前面所述的信息标识，是标识一个充值业务的唯一标识

//USER_NUMBER          待充值用户手机号码

//REQUEST_TIMESTAMP    操作请求时间

//ACCOUNT_TYPE1        帐户类型，0103

//AMOUNT1              充值卡金额(单位：厘)

//CARD_NO              充值卡密码

//CARDPIN              充值卡号

//CALL_NUMBER          呼入号码

第二条：

//上行示：BOSS_LINK[0]开始处理seq_no编号为“0000440359”的命令请求，由MML格式的编码转换为uasp格式，并发送到BOSS。本命令在开始处理前等待了0秒。

第三条：

//上行示：BOSS_LINK[0]得到seq_no编号为“0000440359”的命令应答。

第四条：

//上行示：将UA接口seq_no编号为“0000440359”的命令应答发送到SCP。

//RETN  充值结果状态码，命令处理结果为0000表示成功，0042表示失败

//STATUS_DESCRIPTION  信息状态码，命令的处理结果描述，提供了失败原因。

在充值日志中，最重要的用户信息、充值卡信息集中在了第一条记录中；而充值结果，及失败原因等信息在最后一条记录中。

步骤404、根据每一移动终端参与的移动通信业务的业务起止时间得到该移动终端的移动通信业务过程信息。

对于每一个业务都会对应有多组记录信息，但同一业务的相关记录信息却不一定按照时间顺序连续获取到，因此需要对每一业务的业务过程信息按照时间排序规则进行排序；如果还有记录流水号则进一步按照记录流水号排序，得到多个记录组。例如会得到彩信业务1的3个记录、彩信业务2的4个记录等。

这一步要做的就是，从步骤403中已经排序完成的数据中，逐一取出信息标识相同的数据记录，并根据业务起止时间按照事件发生时间顺序和记录号顺序进行排序，得到每一移动终端参与的移动通信业务的已分类并已分组的业务过程信息。

步骤405、根据移动通信业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务和相关的移动终端。

任何一条移动通信业务过程信息中，都通过业务参数记录了业务的数据特征，例如发送信息长度、用户提交是否成功、彩信中心保存彩信的时间、接收端是否发出提取请求等。所述业务分析规则是根据业务参数是否符合业务成功的要求制订的。以下表1包括了预先设置好的针对彩信业务的业务分析规则，对应的失败原因和相应的解决方案。

表1：彩信业务的分析方案

根据以上规则，可以判断出示例数据的PSHCD和MMSTAT符合PSHCD！＝1001‖MMSTAT＝＝“REJECT”规则，则有结论“PUSH信息下发失败，初步判断为接收终端短信收件箱已满，须继续检查短信专家系统最后确认”，由此，将继续针对短信日志数据库的数据库存储过程进行查询，找出时间相近并且发送方和接收方号码与彩信日志记录的发送方和接收方号码相同的短信日志记录，如果符合规则“短信日志记录的下发失败原因如果为“短信收发功能有误(15)”或“用户终端内存满(17)”，则得出失败原因“用户终端收发功能有误或用户终端内存满”，对应的移动终端是示例数据中的RECEIVER：接收方号码为问题终端。

以下表2包括了预先设置好的针对充值业务的业务分析规则，对应的失败原因和相应的解决方案。

表2：充值业务的分析方案

所属业务支撑数据库	业务参数	业务参数名称	业务分析规则	符合业务分析规则的结果和失败原因	对应的解决方案
						VC充值中心日志数据库	RETN	充值结果状态码	RETN＝0042	因网络原因导致充值失败	您于**年**月**日充值**元失败，现提供该充值密码：******，请重新充值

在以上表1和表2中给出了彩信业务和充值业务针对业务失败原因的对应解决方案。在步骤402之后，还可以进一步增加根据数据分析格式模板重新整理数据的过程，以便获得统一格式的数据；该模板可以根据实际需要进行设定，其目的在于使原始数据中的信息容易辨别。因此，在步骤405后可以将进行整理后的数据根据返回数据格式模板进行整合并输出格式数据。

下面为充值业务具体实施时以XML格式输出的数据举例：

<root>

<calluser>86139********</StartTime>

<callTime>2005-05-24 14:20:02</EndTime>

<sessionID>0000440359</MessageID>

<user>+86137********</Sender>

<amount>50000</Receiver>

<card_No>05947020009729949</card_No>

<cardPIN>021607171844953178</cardPIN>

<RETN>0042</RETN>

<STATUS_DESCRIPTION>BOSS超时</STATUS_DESCRIPTION>

</root>

root：为一条收发彩信记录

其子元素为：

calluser：为拨打充值电话的用户号码

callTime：充值时间

sessionID：流水号，一组信息的唯一标识

user：被充值用户号码

amount：充值金额

card_No：充值卡密码

cardPIN：充值卡号

RETN：充值结果状态码

STATUS_DESCRIPTION：充值状态描述。

步骤406、获取建立移动通信业务失败的失败原因和解决方案。

获取建立移动通信业务失败的失败原因和解决方案，可以根据用户对服务的响应需求而定，例如：

第一种方式，获取设定时间范围发生的移动通信业务的失败原因和解决方案并保存，保持更新记录以反映业务的最新状态。这是较为简单的技术方案，例如设定时间范围是1天，那么按照以上步骤403、404、405的过程，每天将前一天的移动通信业务失败的记录处理结果保存到数据库，而不必保存以前的失败记录，然后对前一天的移动通信业务失败的记录做更新处理。例如在充值业务实现对新失败信息的更新，根据设定的时间范围获取充值卡日志系统前一天充值失败数据(以当前时间为结束时间)，再逐一取出充值卡号，查询并遍历此卡号是否有充值成功记录，如果有则在数据库中将与该充值卡号相关的记录删除；如充值卡号重复，则保留最新的充值失败记录。

第二种方式，获取大于设定时间范围或者以前所有的移动通信业务的失败原因和解决方案并保存，根据业务的最新状态更新所保存内容。基于以上的第一种方式，不仅每天要将上一天的移动通信业务失败的记录处理结果保存到数据库，而且数据库中还要继续保留过去N天(N大于设定时间范围)的失败记录。然后要对这些移动通信业务失败的记录做更新处理。即要删除已经成功的业务所对应的记录，也要删除仍然是失败的业务所对应的旧记录。这种方式实现了对数据库内容的持续更新处理，通过业务过程记录的对比来实现。例如在充值业务实现对原有失败信息的更新，从当前数据库中取出历史充值失败的卡号，再逐一根据卡号查询是否有后续又充值成功的记录，如果有则删除数据库中与该充值卡号相关的记录。如果仍为失败，则将最新纪录继续保留在数据库中。

为了让移动终端用户能够更加清楚地了解失败原因及解决办法，进一步的实施方案还可以是，根据数据库中的失败业务记录生成唯一的错误标识对应于相应的失败原因和解决方案，将所有可能发生的错误标识和对应的失败原因及解决方案存放在回复口径经验库中，从而便于执行以下的步骤407，可以直接得到要发送给移动终端用户的短信内容。

步骤407、将建立移动通信业务失败的失败原因和解决方案及时发送至相关移动终端。

根据数据库中的失败业务记录或其对应的唯一错误标识，将数据库中所保存的所有建立移动通信业务失败移动终端的失败原因及解决方案，通过为相关的移动终端建立成功的移动通信业务反馈至移动终端。比如，在一个彩信业务失败时，可以建立一个成功的短消息业务实现将建立彩信业务的失败原因通过该移动终端的短消息业务反馈至该移动终端。

在上述通过上述实施例获取到彩信移动通信业务失败或充值业务失败的移动终端和失败原因后，可以通过设置定时器来控制业务过程数据的收集、分析和反馈业务失败原因和解决方案进行的时间，为保证各业务系统的正常运行，特别是要避开高峰业务时间进行业务过程数据的收集和失败原因及解决方案的反馈，可以根据业务高峰的规律，设置合理进行的时间，这样就可以减少各业务支撑系统的后台负担，从而提高各业务支撑系统的工作效率；因此，通过增加定时器控制能够更好地适应业务维护的需要，比如设置为默认每天凌晨执行业务过程数据的收集、分析和将有关信息反馈给相关的移动终端，因为在凌晨期间业务量比较少，各业务支撑系统的负担相对较低，从而在既不影响白天业务的正常运行又可以提高各系统的效率基础上就完成了业务数据的主动分析和信息反馈的功能。

图5为本发明实施例四针对定时发送反馈信息的处理方法的流程示意图，则如图所示，在发送反馈信息时可以按以下步骤实施：

步骤501、设定执行筛选失败业务的时间，可由用户自行配置。

可以在系统中开发一定时器程序，根据设置的定时时间，自动执行所设置的业务过程处理和筛选的任务，实施通过定时器控制进行筛选的时间。

步骤502、从业务过程信息的处理和筛选的结果中获取业务失败原因、解决方案和对应的移动终端。

通过上一步的筛选，将得到在设定时间范围内失败业务过程所对应的移动终端和业务失败原因以及解决方案。

步骤503、设定定时将业务失败原因和解决方案发送到对应的移动终端。

在此步骤可以将上一步得到的业务失败原因通过发起短信业务发送到对应的移动终端上。定时发送的设置用以避免在失败概率高的时间段发送反馈信息，从而可以完整地完成一次主动分析和主动反馈移动终端用户的操作。

本发明还提供了一种移动通信业务的处理装置，下面结合上述移动通信业务的处理方法对本装置的具体实施方式进行说明。

图6为一种移动通信业务的处理装置的实施例五的结构示意图，如图所示，装置中包括：接口模块601、筛选模块602、获取模块603，其中

接口模块601，用于获取与移动终端建立移动通信业务的连接信息，与移动通信业务信息存储数据库105的访问接口建立连接，从所述接口获取业务过程信息；

筛选模块602，用于根据所述业务过程信息和业务分析规则，筛选出建立移动通信业务失败的业务及相关的移动终端，确定针对失败原因的解决方案；

获取模块603，用于获取由移动终端导致的建立移动通信业务失败相关的失败原因和解决方案；

图7为一种移动通信业务的处理装置的实施例六的结构示意图，如图所示，在接口模块601中可以包括：接口连接单元6011、业务过程信息获取单元6012，其中：

接口连接单元6011，用于获取与移动终端建立移动通信业务的连接信息，根据移动通信业务信息存储数据库105的接口访问要求，配置移动通信业务信息存储数据库接口的客户端，与移动通信业务信息存储数据库的访问接口建立连接；

业务过程信息获取单元6012，用于从所述接口获取业务过程信息。

其中，访问移动通信业务信息存储数据库接口要求的配置信息中包括以下信息之一或者其组合：

连接池最大值、访问超时时限、访问用户名及密码、数据库服务端IP及端口号、数据库驱动程序加载路径。

另外，还可以有一个进一步的实施例方案，所述接口模块还可以进一步包括数据格式转换单元，用于在从移动通信业务信息存储数据库接口获取业务过程信息后，用于对其进行统一的格式转换，输出给筛选模块。

图8为一种移动通信业务的处理装置的实施例七的结构示意图，如图所示，在筛选模块602中可以包括：识别业务单元6021、业务过程信息处理单元6022、筛选失败业务单元6023，其中：

识别业务单元6021，用于根据从业务过程信息获取单元6012获得的业务过程信息的信息标识和设定的时间范围识别出每一移动终端对应的移动通信业务；

业务过程信息处理单元6022，用于根据每一移动终端的移动通信业务的起止时间得到每一移动终端的每一移动通信业务的业务过程信息；

筛选失败业务单元6023，用于根据所述每一移动通信业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务过程信息和相关的移动终端。

图9为一种移动通信业务的处理装置的实施例八的结构示意图，如图所示，所述筛选失败业务单元6023中可以包括规则解析库60231、业务分析子单元60232，其中：

规则解析库60231，用于存储业务分析规则，所述业务分析规则是根据业务参数是否符合业务成功的要求制订的。彩信业务可以根据以下信息之一或者其组合建立业务分析规则，所述信息为：彩信长度是否过大、用户是否设置延迟发送时间、是否根据厂家的错误码定义放回相应的错误信息、彩信Get后面是否跟有post或生成一条WAP浏览记录访问地址与彩信GET访问IP是否相同、用户终端是否内存满、移动终端是否错误、发送信息大小、用户提交是否成功、彩信中心保存彩信的时间、接收端是否发出提取彩信请求、接收端是否成功接收、接收端是否主动拒绝接收、移动中心PUSH是否成功、彩信中心收到后是否延迟发送时间、彩信提取是否成功等。充值业务可以根据充值结果状态码是否为成功状态等。

业务分析子单元60232，用于根据从业务过程信息处理单元6022获得的移动通信业务过程信息以及所述规则解析库60231中存储的规则筛选出建立移动通信业务失败的业务和相关的移动终端，确定针对失败原因的解决方案。

进一步地，给出一种移动通信业务的处理装置的实施例九，装置中的获取模块还可以进一步包括数据存储单元，和数据更新单元。

所述的数据存储单元，用于保存失败业务过程信息以及业务失败原因和解决方案。

所述的数据更新单元，用于根据业务的最新状态，更新数据存储单元中的内容。通过对当前数据存储单元中的移动通信业务过程信息进行对比，保证其中的业务过程信息反映当前业务的最新状态。

图10为一种移动通信业务的处理装置的实施例十的结构示意图，如图所示，装置中还可以进一步包括发送模块604，其中：

发送模块604，用于将从获取模块603得到的建立移动通信业务失败的移动终端的失败原因及解决方案发送至相关的移动终端。

例如对彩信业务，将建立彩信业务的失败原因及解决方案通过短消息方式发送至相关的移动终端。对充值业务，将充值密码通过短消息方式发送至相关的移动终端。

图11为一种移动通信业务的处理装置的实施例十一的结构示意图，如图所示，装置中还可以进一步包括定时任务模块605，其中：

定时任务模块605，用于定期定时控制调用各模块的启动执行，定时的时间可以由用户自行配置，从而控制业务过程数据的收集、分析和反馈业务失败原因进行的时间，以保证各业务系统的正常运行。尤其是控制与移动通信业务信息存储数据库交互通讯的接口模块获取业务过程数据的执行时间以及筛选分析失败业务的时间，要考虑到避开移动通信业务的高峰时间，以减轻移动通信业务信息存储数据库的负荷。

具体的，定时任务模块可以通过开发一定时器，并根据设置的时间，自动调用执行所设置的各模块。

对于有发送模块的技术方案，发送模块604被控制定时地将有问题的移动终端失败原因发送给相关的移动终端，可以提高对失败原因的反馈控制自由度，如果是使用短信业务完成发送操作，特别是要避免在失败概率较高的时间段内发送短信。

本发明一种移动通信业务的处理装置所处理的移动通信业务可以包括彩信业务、短信业务和WAP上网业务。

下面对本装置在对移动通信业务为彩信业务时的具体实施举例进行说明。

图12为彩信通信业务处理系统结构示意图，如图所示，彩信用户管理系统、短信专家系统、彩信日志系统、HLR用户信息系统、WAP运维系统，统称为移动通信业务信息存储数据库，通过访问这些数据库的接口可以获得业务过程信息。

装置的接口模块中包括接口、XML数据格式模版，可以根据数据库接口访问要求配置接口所必须的参数，接口与移动通信业务信息存储数据库建立通讯连接，通过接口调用语句来获取彩信轨迹日志的原始数据。

接口具备以下特点：

1、支持多种接口方式。如：WEB SERVICE、SOCKET、TELNET、HTTP、数据库表、视图、存储过程接口。

2、原始数据分析和统一格式功能。如：统一接收数据库返回的RESULTSET类型、WEB SERVICE的标准XML数据类型、SOCKET的字符流类型、HTTP方式读取的数据类型等，可以将上述任何一种接口返回的原始数据，根据系统制定的数据格式模板加以转换。

3、增加数据完整性及准确性功能。

可以设置标识开头、结尾参数来控制接收数据的完整性及准确性。

实施时，系统通过接口采集彩信发送数据，即从彩信用户管理系统、短信专家系统、彩信日志系统、HLR用户信息系统、WAP运维系统采集某一时间段内的所有有关彩信业务的日志。

实施例中设计彩信日志分析工具，用于对采集到的日志等业务过程信息进行分析，根据XML数据格式模版形成XML格式的数据，通过规则解析库分析提取出有问题的日志记录，找出彩信业务失败的原因，存入本地系统日志库，以便管理员查看统计使用。

实施例中设计任务定期扫描引擎用于控制定期扫描彩信日志库中的彩信记录。按定时器定期地将得到的彩信业务失败原因数据通过移动短信收发系统向移动终端进行反馈。还可以通过设置回复口径经验库，将不同的回复口径存储到回复口径经验库中，这样便于统一维护与读取。

为进一步阐述本发明的具体实施方式，现以充值卡充值业务为例进行说明，针对充值卡充值业务产生的日志进行主动分析，及时发现用户充值失败的问题，使得运营商可以在该类投诉未发生之前，主动联系用户，关怀用户，清除投诉发生的条件，从而减少投诉数量，提高用户对运营商的满意度和忠诚度。

使用充值卡充值要求充值用户拥有正确的充值卡密码信息，用户需要根据移动业务的智能网系统提示进行操作，输入充值卡密码，智能网系统接受并识别充值卡密码的有效性，如果有效，BOSS计费系统更新用户的账户余额，智能网系统向充值用户反馈最终的充值结果。

当执行移动通信业务过程中任何一个环节发生错误或网络故障时，则此移动通信业务都将不能正常完成，由于BOSS计费系统与VC充值中心间的多次交互为事务流程，因此，该事务流程期间任何一次异常，均会导致用户充值失败。

在上述基本流程的进程中都会记录相关的原始数据，由于是原始数据，而且具体参数组合复杂，需要人工判断多项数据，解决这些问题的通常是智能网充值卡专业人员及提供商的专业人员，这样下来在解决用户投诉时就会消耗大量时间和人力，同时用户也会对运营商的服务及解决投诉能力产生质疑，而本发明实施例就解决此类问题，将这其中需人工解决的过程进行客观处理，避免处理中引入人为因素，从而主动解决用户在充值卡方面的投诉。

图13为充值卡业务日志分析处理系统结构示意图，如图所示，充值卡日志系统为移动通信业务信息存储数据库，通过访问该系统的接口可以获得有关充值卡的业务过程信息，接口的功能特点与图12所示的彩信业务日志分析处理系统中的接口相同。

实施时，充值卡业务日志分析处理系统通过接口采集充值业务过程数据，即从充值卡日志系统采集某一时间段内的所有充值过程日志，经充值卡日志分析工具分析所采集到的日志后存入本地系统日志库，将有问题的日志记录提取出来，发送给移动终端用户。

实施例中，任务定期扫描引擎扫描充值卡日志库中的充值过程日志信息，定期调用接口读取充值卡日志，然后针对读取的日志，调用充值卡日志分析工具进行分析，将有问题的记录总结出来。此时还可以通过设置回复口径经验库，将不同的回复口径存储到数据库中，这样便于维护与读取。

实施中当采用XML数据格式来处理时，还可以在接口通过提供XML数据格式模版形成XML格式的数据，在充值卡日志分析工具进行分析时，则可利用XML分析数据格式模版与规则解析库一起对XML数据进行分析，分析后的输出结果也可参见前述实施例三。

进一步地，在任务定期扫描引擎处，可以通过设置定时器，按定时器的设置定期将得到的分析结果通过移动短信收发系统、或彩信系统等向移动终端进行反馈。

由上述实施例可以看出，本发明技术方案中，首先获取与移动终端建立移动通信业务的连接信息；再根据连接信息与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息后，根据业务过程信息筛选出建立移动通信业务失败的业务及相关的移动终端；然后相应地去获取建立移动通信业务失败的原因和解决方案，最后将建立移动通信业务失败的失败原因和解决方案及时发送至相关移动终端。通过该方案移动终端用户就可以在移动终端建立通信业务失败后，自动得到移动终端的失败原因和解决方案。可以预见，有意识地分析和利用这些失败原因将可以提高工作效率，以及提高运营商的竞争力。比如在自动获得失败原因后，自动或者主动将失败原因和解决方案反馈至该移动终端，毫无疑问，该反馈能够在解决用户投诉问题上变被动为主动，变解决问题为关心用户，提高了用户的满意度，同时通过预防顾客投诉也大幅度提高了解决顾客投诉问题的效率。

本发明不仅能变被动投诉为主动投诉，提高用户满意度，使处理投诉时间缩短，提高运营商竞争力，也可以自动从移动通信信息数据库的信息中发现潜在投诉，提高工作效率；进一步地，由于分析过程是基于规则解析库的规则，因此通过扩展分析规则便可以处理不断变化出现的新问题，支持不断变化的用户需求，具有很强的可扩展性。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (16)

1、一种移动通信业务的处理方法，其特征在于，包括如下步骤：

获取与移动终端建立移动通信业务的连接信息；

根据所述连接信息与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；

根据所述业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端，确定针对失败原因的解决方案；

获取建立移动通信业务失败的失败原因和解决方案。

2、如权利要求1所述的方法，其特征在于，进一步包括：

将建立移动通信业务失败的失败原因和解决方案及时发送至相关移动终端。

3、如权利要求1或2所述的方法，其特征在于，所述根据业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务及相关的移动终端，确定针对失败原因的解决方案，包括如下步骤：

根据所述业务过程信息的业务标识、信息标识和设定的时间范围识别出每一移动终端参与的移动通信业务；

根据移动终端参与的移动通信业务的业务起止时间得到移动终端的移动通信业务的业务过程信息；

根据所述移动通信业务的业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务过程信息和相关的移动终端，确定针对失败原因的对应解决方案。

4、如权利要求3所述的方法，其特征在于，获取建立移动通信业务失败的失败原因和解决方案，可以包括：

获取设定时间范围或以前发生的移动通信业务的失败原因和解决方案并保存，根据业务的最新状态更新所保存的内容。

5、如权利要求1、2或4任一项所述的方法，其特征在于，与移动终端建立的移动通信业务包括彩信业务、短信业务、WAP上网业务或充值业务。

6、如权利要求5所述的方法，其特征在于，将建立移动通信业务的失败原因及解决方案通过短消息方式发送至相关的移动终端。

7、如权利要求1、2或4任一项所述的方法，其特征在于，进一步包括：

对以上各步骤的执行设置定时执行机制，按预定时间自动执行所述的各步骤。

8、一种移动通信业务的处理装置，其特征在于，包括：

接口模块，用于获取与移动终端建立移动通信业务的连接信息，与移动通信业务信息存储数据库的访问接口建立连接，从所述接口获取业务过程信息；

筛选模块，用于根据所述业务过程信息和业务分析规则，筛选出建立移动通信业务失败的业务及相关的移动终端；

获取模块，用于获取建立移动通信业务失败相关的失败原因和解决方案。

9、如权利要求8所述的装置，其特征在于，进一步包括发送模块，用于将建立移动通信业务失败的移动终端的失败原因及解决方案发送至该移动终端。

10、如权利要求9所述的装置，其特征在于，所述与移动终端建立的移动通信业务包括彩信业务、短信业务、WAP上网业务或充值业务。

11、如权利要求8至10任一项所述的装置，其特征在于，所述接口模块包括接口连接单元、业务过程信息获取单元，其中：

接口连接单元，用于获取与移动终端建立移动通信业务的连接信息，根据移动通信业务信息存储数据库的接口访问要求，配置移动通信业务信息存储数据库接口的客户端，与移动通信业务信息存储数据库的访问接口建立连接；

业务过程信息获取单元，用于从移动通信业务信息存储数据库接口获取业务过程信息。

12、如权利要求11所述的装置，其特征在于，所述接口模块进一步包括数据格式转换单元，用于在从移动通信业务信息存储数据库接口获取业务过程信息后，用于对其进行统一的格式转换，输出给筛选模块。

13、如权利要求8至10任一项所述的装置，其特征在于，所述筛选模块包括识别业务单元、业务过程信息处理单元、筛选失败业务单元，其中：

识别业务单元，用于根据所述业务过程信息的信息标识和设定的时间范围识别出每一移动终端对应的移动通信业务；

业务过程信息处理单元，用于根据移动终端的移动通信业务的起止时间得到移动终端的移动通信业务的业务过程信息；

筛选失败业务单元，用于根据所述移动通信业务过程信息和业务分析规则筛选出建立移动通信业务失败的业务过程信息和相关的移动终端。

14、如权利要求8至10任一项所述的装置，其特征在于，所述筛选失败业务单元进一步包括规则解析库、业务分析子单元，其中：

规则解析库，用于存储业务分析规则，所述业务分析规则是根据业务参数是否符合业务成功的要求制订的；

业务分析子单元，用于根据移动通信业务过程信息以及所述规则解析库中存储的规则筛选出建立移动通信业务失败的业务和相关的移动终端，确定相对应的解决方案。

15、如权利要求8至10任一项所述的装置，其特征在于，所述获取模块还可以进一步包括，

数据存储单元，用于保存失败业务过程信息以及业务失败原因和解决方案；

数据更新单元，根据业务的最新状态，更新数据存储单元中的内容。

16、如权利要求8至10任一项所述的装置，其特征在于，进一步包括定时任务模块，用于定时调用装置中其他各模块。

Images