CN1968105A - 基于通信网络的计费系统及计费方法 - Google Patents

Abstract

本发明提供了一种基于通信网络的计费系统，通信网络至少包括客户关系管理单元CRM、计费触发单元及话单采集单元Mediation，计费系统包括：管理中心，提供所述计费系统的全部配置管理功能，并接收所述客户关系管理单元CRM同步的业务数据；计费单元，用于处理所述计费触发单元发出的计费请求及获取所述话单采集单元Mediation采集的话单；其中，所述管理中心接收并处理所述计费单元同步的帐务数据，所述计费单元接收并处理所述管理中心同步的业务数据。本发明基于上述计费系统，还提供了一种计费方法。

Description

基于通信网络的计费系统及计费方法

技术领域

本发明涉及通信网络的计费技术，尤其涉及基于通信网络的计费系统及计费方法。

背景技术

目前，计费技术是一个研究热点，本领域普通技术人员针对这项技术提出了多个计费系统及计费方法，图1所示的基于INGW(智能网关)的计费系统就是一例。这种系统可以提供准实时条件下的预付费/后付费融合，通过INGW与BOSS(Business Operation Support System，业务运营支撑系统)、SCP(ServiceControl Point，业务控制点)的结合实现话音业务信用控制。

现在结合图2，对基于INGW的计费系统的基本信用控制流程说明如下：

S201：BOSS将签约信息加载到HLR(归属位置寄存器)上；

S202：BOSS将用户资料以及帐户资料发送给INGW；

S203：INGW运算出用户业务许可表；

S204：INGW将用户业务许可表发送给SCP；

S205：SCP与MSC(Mobile switching Center，移动交换中心)/SSP(ServiceSwitch Point，业务交换点)交互信息；

S206：通话开始后，SCP按照该用户的业务许可表进行通话控制；

S207：通话过程中，SCP向INGW报告呼叫时长等信息；

S208：通话结束后，SCP将用户通话情况报告INGW；

S209：INGW计费并修改虚拟帐户，返回S203；

S210：BOSS根据MSC/SSP的话单进行计费，修改BOSS帐户。如果需要，BOSS将发起更新INGW的虚拟帐户和用户资料，返回S202。

由上述流程可以看出，基于INGW的计费系统可以实现对高风险用户的实时欠费控制，但是，由于BOSS采用准实时计费方式，所以导致信用控制方面主要存在下述问题：用户通话结束直至BOSS完成计费处理的过程存在较大时延；如果BOSS向HLR申请停机，则可能因HLR接口能力的限制造成阻塞延迟，而从用户余额用尽至HLR停机期间，用户所有呼叫费用都将成为欠费；用户通话过程中，BOSS不能对通话按费用监控，余额用尽不会切断通话，余额很少也能进行长时间通话；用户不能实时了解其消费情况，不能对其通话消费有效控制。

目前的INGW尚不成熟，主要存在下列缺陷：INGW保留用户虚拟帐户，实时根据呼叫的计费结果进行扣减余额，而BOSS根据话单进行批价后扣减帐户余额。如果在某次通话过程中，用户虚拟帐户的余额不足，INGW会及时结束通话，此时，如果用户查询余额，BOSS会反馈余额尚未用完，这就有可能导致用户投诉；预付费用户消费数据业务造成帐户余额减少的信息不能及时反映到INGW中，由于余额同步机制方面的原因，可能会出现用户余额不足但仍然可以通话的情况，即没能实现信用控制。

由上述可知，不能实现完全的实时计费和良好的信用控制是基于INGW的计费系统的主要缺陷。

双引擎计费系统是本领域普通技术人员提出的另一个计费模式。图3为双引擎计费系统的结构示意图，在所述系统中，OCS(Online Charging System，在线计费系统)用于在线计费，Hot-Billing(热计费系统)用于准实时计费，SID(Share Information/Data Model，共享数据模型系统)用于共享数据存储。SID建成前，CRM(Customer Relationship Management，客户关系管理)可以分别与OCS或Hot-Billing之间直接同步数据，SID建成后，CRM通过SID与OCS及Hot-Billing同步数据。其中，SCP、ISMP(Integrated ServiceManagement Platform，综合业务管理平台)、CCG(Content Charge Gateway，内容计费网关)等网元负责业务控制，同时通过OCP(在线计费协议)接口将实时鉴权计费请求触发到OCS，OCS将处理的结果返回，若预付费帐户余额不足，SCP、ISMP、CCG等网元将停止业务的使用；MSC/CG(ChargeGateway，计费网关)等网元输出话单，通过FTP(文件传输协议)到Hot-Billing中批价计费。

下面对双引擎计费系统涉及的几个常用流程进行说明。

对于余额充值，首先由CRM发起充值请求，先充值到SID中，再由SID通知OCS、Hot-Billing同步余额数据。

对于余额查询，由CRM发起，同时向OCS、Hot-Billing查询余额，汇总后展示给用户。

对于业务开通或变更，CRM接收业务发出的业务申请或变更请求后，同时将修改后的档案信息同步到ISMP及SID中，OCS或Hot-Billing从SID中获得档案信息，以便进行相应的计费、授权处理，最后，服务开通系统通过接口修改SCP、HLR中的相关信息。

对于预付费与后付费互转，以后付费转预付费为例，如图4所示：

S401：CRM对接收到的付费方式修改请求进行合法性验证、资费变更等处理，并向SID同步付费方式修改信息；

S402：SID向Hot-Billing发送付费方式修改通知；

S403：Hot-Billing对涉及的产品实例结帐处理并将涉及的帐本余额同步到SID；

S404：SID向OCS发送付费方式修改通知；

S405：OCS从SID中获取档案信息；

S406：服务开通系统向HLR、ISMP同步付费方式修改通知；

S407：HLR、ISMP修改资料。

双引擎计费系统可以实现在线/离线计费融合，但其也存在如下几个问题：

(1)两个计费引擎OCS及Hot-Billing在资费模型方面很难统一，用户的体验不同；

(2)对于余额充值等业务需要通过SID在两个计费引擎之间同步数据，效率不高；

(3)对于预付费与后付费互转等业务，需要在多个系统之间操作，流程比较繁琐；

(4)管理流程涉及多个系统的交互，故障点多，数据同步时延和可靠性难以保障；

(5)整个计费体系由OCS、Hot-Billing、SID三套系统构成，维护工作量大。

由上述可知，由于具有两个计费引擎，操作效率不高及管理流程复杂是双引擎计费系统的主要缺陷。

发明内容

本发明要解决的技术问题在于提供一种基于通信网络的计费系统及计费方法，实现在线/离线的融合，以提高计费系统的操作效率并降低管理流程的复杂度。

为解决上述问题，本发明提供了一种基于通信网络的计费系统，所述通信网络至少包括客户关系管理单元CRM、计费触发单元及话单采集单元Mediation，所述计费系统包括：管理中心，提供所述计费系统的全部配置管理功能，并接收所述客户关系管理单元CRM同步的业务数据；计费单元，用于处理所述计费触发单元发出的计费请求及获取所述话单采集单元Mediation采集的话单；其中，所述管理中心接收并处理所述计费单元同步的帐务数据，所述计费单元接收并处理所述管理中心同步的业务数据。

所述计费单元包括：多个计费设备，用于处理所述管理中心同步的业务数据；分发器，用于将接收到的计费请求或所述话单转换为标准计费事件以及将所述标准计费事件交由相应的计费设备处理，并用于处理或转发所述多个计费设备的响应信息，所述分发器还获取所述管理中心中的所述业务数据。

所述计费单元对所述计费请求进行预处理、鉴权、业务包识别、批价及入帐处理，对所述话单进行预处理、业务包识别、批价及入帐处理，其中，批价处理包括正算、反算及预留。

所述管理中心配置有数据分布策略，所述数据分布策略具有所述业务数据在各个计费设备之间的分布信息及客户之间的关联信息。

所述分发器还包括：格式转换装置，用于将接收到的计费请求或所述话单转换为中间计费事件；预处理自动机，用于将所述中间计费事件生成待求解标准计费事件；计费要素求解装置，用于对所述待求解标准计费事件中的计费要素求解并生成标准计费事件；分流装置，用于根据数据分布策略将所述标准计费事件交由相应的计费设备处理。

所述计费系统还包括：配置门户，用于提供数据维护及配置界面；中央数据库，用于存储所述计费系统的参数数据、所述业务数据及所述帐务数据；其中，所述配置门户直接从所述中央数据库中获取所述参数数据，或者通过所述管理中心从所述中央数据库中获取所述帐务数据。

所述管理中心还用于在所述CRM中展示从所述多个计费设备、所述分发器或所述中央数据库中查询到的信息。

所述计费系统还包括：网管代理设备，用于将收集的所述计费系统的性能及告警信息提供给所述通信网络中的网管系统。

所述客户关系管理单元CRM同步的业务数据包括产品数据、客户数据、定购关系数据及定价数据。

所述计费单元同步的帐务数据包括帐户帐本数据、明细帐目数据及累计数据。

所述计费请求为Diameter信用控制协议DCC请求消息，所述话单为计费数据记录CDR。

如果所述计费请求为Diameter信用控制协议DCC请求消息，则所述相应的计费设备将计费结果直接或通过所述分流装置返回给所述格式转换装置转换为DCC应答消息，并返回给所述计费触发单元。

本发明还提供了一种基于通信网络的计费方法，应用于上述计费系统，包括：计费单元接收计费触发单元发出的计费请求或获取话单采集单元Mediation采集的话单；所述计费单元根据资费规则处理所述计费请求或所述话单。

所述计费请求为Diameter信用控制协议DCC请求消息，所述话单为计费数据记录CDR。

如果所述计费请求为Diameter信用控制协议DCC请求消息，则所述计费单元将所述处理DCC请求消息产生的结果转换为DCC应答消息后，返回给所述计费触发单元。

所述计费单元对所述计费请求进行预处理、鉴权、业务包识别、批价及入帐处理，对所述话单进行预处理、业务包识别、批价及入帐处理，所述批价处理包括正算、反算及预留。

所述计费方法还包括：所述计费单元将经过处理所述计费请求或所述话单产生的帐务数据同步到管理中心。

所述计费单元根据资费规则处理所述计费请求或所述话单的过程包括：所述计费单元的分发器将接收到的所述计费请求或所述话单生成标准计费事件；所述分发器根据数据分布策略将所述标准计费事件交由所述计费单元包括的相应的计费设备处理；所述计费设备根据所述标准计费事件进行业务包识别、批价、入帐处理。

所述计费单元的分发器将接收到的所述计费请求或所述话单生成标准计费事件的过程包括：所述分发器的格式转换装置将接收到的所述计费请求或所述话单转换为中间计费事件；所述分发器的预处理自动机将所述中间计费事件生成待求解标准计费事件；所述分发器的计费要素求解装置对所述待求解标准计费事件的计费要素求解，并生成标准计费事件。

本发明的计费系统包括管理中心及计费单元，计费单元可用于处理在线计费请求及话单，所以，本发明的计费系统将多种业务、多种计费模式进行了融合，简化了管理流程，降低了操作的复杂度，由于不需要多个系统或多个实体之间同步数据，所以提高了工作效率。

本发明的计费系统包括的实体比较少，所以减少了维护的工作量。

本发明利用一个计费系统即可实现多种计费模式，便于市场营销。

附图说明

图1为基于INGW的计费系统的结构示意图；

图2为基于INGW的计费系统的基本信用控制流程；

图3为双引擎计费系统的结构示意图；

图4为基于双引擎计费系统的后付费转预付费过程的流程图；

图5为本发明基于通信网络的计费系统的第一结构示意图；

图6为本发明基于通信网络的计费系统的第二结构示意图；

图7为本发明分发器的结构示意图；

图8为本发明计费方法的一个实施例的流程图；

图9为图8中步骤S802实现方法的流程图；

图10为图9中步骤S8021实现方法的流程图；

图11A、11B、11C为计费设备处理实时计费请求过程的流程图；

图12为计费设备处理话单过程的流程图；

图13为基于本发明计费系统的针对增值业务开通/变更过程的流程图；

图14为基于本发明计费系统的针对增值业务后付费转预付费过程的流程图；

图15为基于本发明计费系统的余额充值的流程图；

图16为基于本发明计费系统的余额查询的流程图；

图17为本发明计费过程中的数据传送流程的示意图。

具体实施方式

下面我们将结合附图，对本发明的最佳实施方案进行详细描述。首先要指出的是，本发明中用到的术语、字词及权利要求的含义不能仅仅限于其字面和普通的含义去理解，还包括进而与本发明的技术相符的含义和概念，这是因为我们作为发明者，要适当地给出术语的定义，以便对我们的发明进行最恰当的描述。因此，本说明和附图中给出的配置，只是本发明的首选实施方案，而不是要列举本发明的所有技术特性。我们要认识到，还有各种各样的可以取代我们方案的同等方案或修改方案。

首先结合图5，对本发明基于通信网络的计费系统进行说明。如图5所示，计费系统501包括管理中心5011及计费单元5012，其中，管理中心5011提供所述计费系统501的全部配置管理功能，并接收客户关系管理单元CRM502同步的业务数据，计费单元5012用于处理计费触发单元503发出的计费请求及获取话单采集单元Mediation504采集的话单，管理中心5011接收并处理计费单元5012同步的帐务数据，计费单元5012接收并处理管理中心5011同步的业务数据。另外，由于计费系统501是通信网络的一个组成部分，所以，图5还指明了计费系统501与外部通信的接口。请再参照图5，管理中心5011与CRM502之间的接口为IF-CRM接口，接口协议可以为RMI(Remote MethodInvocation，Java远程方法调用)、SOAP(Simple Object Access Protocol，简单对象访问协议)、CORBA(Common Object Request Broker Architecture，公共对象请求代理体系结构)、MML(Man-Machine Language，人机语言)或中间表，管理中心5011可以通过这个接口将CRM502业务受理、业务变更、帐务管理等产生的数据同步到计费单元5012，并可从计费单元5012中查询出相关信息在CRM502中展示，计费单元5012与计费触发单元503及话单采集单元Mediation504之间的接口分别为IF-DCC接口及IF-CDR接口，接口协议可以为Diameter CC，计费单元5012可以通过这两个接口处理计费触发单元503的在线计费请求及获取的话单采集单元Mediation504采集的话单。

计费单元501可以对计费触发单元503发出的计费请求进行预处理、鉴权、业务包识别、批价及入帐处理，对获取的话单进行预处理、业务包识别、批价及入帐处理，批价处理可以包括正算、反算、预留处理。正算是根据用户使用某电信业务的实际用量以及系统配置的资费，计算出应该收费的值；反算，也可称为预算，是根据用户的帐户余额以及系统配置的资费，计算用户使用某电信业务的允许用量。预留是用户使用电信业务前，提前封存一定额度的帐户资金，以便后续正算时帐户有足够资金支付用户本次使用电信业务的收费，使用预留可避免并发电信业务扣费引起的透支。在一次批价操作中，一般先正算，即计算出上一次业务使用的费用，再反算(预算)，计算下一次业务使用的允许用量，可能大于或小于一个最小的业务量单元，最后做预留。

另外，计费单元5012可以进一步包括：多个计费设备，用于处理所述管理中心同步的业务数据；分发器，用于将接收到的计费请求或话单转换为标准计费事件以及将所述标准计费事件交由相应的计费设备处理，并用于处理或转发多个计费设备的响应信息，分发器还可获取管理中心5011中的业务数据。

计费系统501还可包括：配置门户，用于提供数据维护及配置界面；中央数据库，用于存储计费系统的参数数据、业务数据及帐务数据；其中，配置门户直接从所述中央数据库中获取参数数据，或者通过管理中心5011从中央数据库中获取帐务数据。

管理中心5011可以配置有数据分布策略，所述数据分布策略具有业务数据在各个计费设备之间的分布信息及客户之间的关联信息，相应的，计费单元5012的分发器可获取管理中心5011的数据分布策略，当接收到计费请求或话单时，根据数据分布策略将处理计费请求或话单时产生的标准计费事件交由相应的计费设备处理。管理中心5011还可用于在CRM502中展示从多个计费设备、分发器或中央数据库中查询到的信息。

CRM502同步的业务数据可以包括产品数据、客户数据、定购关系数据及定价数据等。计费单元5012同步的帐务数据可以包括帐户帐本数据、明细帐目数据及累计数据等。

计费请求可以为Diameter信用控制协议DCC请求消息，话单为计费数据记录CDR。如果计费请求为Diameter信用控制协议DCC请求消息，则相应的计费设备将计费结果直接或通过分流装置返回给分发器的格式转换装置转换为DCC应答消息，并返回给计费触发单元503。

计费系统还可包括网管代理设备，用于将收集的计费系统的性能及告警信息提供给通信网络中的网管系统。

现在结合图6，对本发明计费系统的优选实施方式进行说明。

如图6所示，计费系统601包括管理中心6011、n个计费设备6012、两个分发器6013、配置门户6014、中央数据库6015及网管代理设备6016。其中，管理中心6011与n个计费设备6012之间的第一接口、管理中心6011与分发器6013之间的接口及n个计费设备6012与分发器6013之间的接口分别为IF-BUS接口，接口协议为DCC(Diameter Credit Control，Diameter信用控制协议)消息或数据文件，管理中心6011与配置门户6014之间的接口为IF-MGR接口，接口协议为RMI或SOAP，配置门户6014与中央数据库6015之间的接口及管理中心6011与中央数据库6015之间的接口为IF-DB接口，接口可以是例如SQL API的数据库中间件，网管代理设备6016与n个计费设备6012之间的接口、网管代理设备6016与分发器6013及管理中心6011与n个计费设备6012之间的第二接口分别为IF-OAM接口，接口协议为TCP/IP。另外，管理中心6011与CRM602之间的接口为IF-CRM接口，接口协议为RMI、SOAP、CORBA、MML或中间表，一个分发器6013与计费触发单元603的接口为IF-DCC接口，接口协议为Diameter CC，另一个分发器6013与mediation(中介系统)604之间的接口为IF-CDR接口，接口协议为CDR(CalledDetail Record，计费数据记录)文件，网管代理设备6016与NMS(NetworkManagement System，网管管理系统)605之间的接口为IF-NMS，接口协议为SNMP(Simple Network Management Protocol，简单网络管理协议)。

在图6中，管理中心6011提供了统一的配置管理和业务开通变更入口，其可将CRM602业务受理、业务变更、帐务管理等产生的数据同步到中央数据库6015、分发器6013或n个计费设备6012的内存中，并可从中央数据库6015、分发器6013或n个计费设备6012的内存数据库中查询出相关信息在CRM602进行展示，另外，管理中心6011还可提供配置管理接口和动态数据查询接口，支持从配置门户6014发起的数据配置和从CRM602发起的动态数据查询。

分发器6013在n个计费设备6012之间分发请求，起到负载均衡和网络侧统一接入的作用。分发器6013是业务侧统一接口设备，提供CDR和DCC消息预处理功能，生成标准计费事件；根据数据分布策略将标准计费事件分发给n个计费设备6012处理；对来自计费设备6012的DCC响应消息，转发给发起请求的例如为SCP、ISMP等的计费触发网元603。分发器6013与计费设备6012之间的通信协议可以是Diameter，分发器6013与计费设备6012之间的接口可以是内部接口。

计费设备6012是计费系统601的计费核心设备，提供会话管理、鉴权、业务包识别、批价、入帐、充值缴费等功能，其对外提供在线/离线、话音/数据、内容/流量及全业务融合等计费能力，分发器6013提供业务侧统一接口，对内实施请求分发，使计费系统601可以方便地横向扩展，从而提升单一节点的容量，最大可以达到千万级用户规模的应用要求。

中央数据库6015用于存储计费系统的物理数据。

配置门户6014提供数据维护和数据配置界面，其可通过两种方式获取数据：对于配置门户6014的专用数据、模板规则相关数据、参数管理涉及到的数据以及结构性的数据，配置门户6014通过直连中央数据库6015获取数据；对于动态数据，如帐户帐本、明细帐目、累计数据等，配置门户6014通过调用管理中心接口从计费设备6012获取这些数据。

网管代理设备6016负责收集计费系统601中所有的性能、告警信息，提供给NMS605。

由于图6中的分发器在图6所示的计费系统601中是一个比较关键的部件，所以现在结合图7，对图6中的分发器603做进一步介绍。

如图7所示，分发器603包括：格式转换装置701，用于将接收到的计费请求或话单转换为中间计费事件，其中，计费请求可以为DCC请求消息，话单为计费数据记录CDR；预处理自动机702，用于将中间计费事件生成待求解标准计费事件；计费要素求解装置703，用于对待求解标准计费事件中的计费要素求解并生成标准计费事件；分流装置704，用于根据数据分布策略将标准计费事件交由相应的计费设备处理。

由上述说明可看出，本发明的计费系统与双引擎计费系统最主要的区别在于，本发明的计费系统将在线/离线计费等业务融合在一起，提高了操作效率，降低了流程的复杂度。

本发明针对图5所示的计费系统还提出了一种计费方法，现在结合图8，对本发明的计费方法的实施例进行说明。步骤S801：计费单元接收计费触发单元发出的计费请求或获取话单采集单元Mediation采集的话单；步骤S802：计费单元根据资费规则处理计费请求或话单；步骤S803：如果计费请求为DCC请求消息，则计费单元将处理DCC请求消息产生的结果转换为DCC应答消息后，返回给计费触发单元；步骤S804：计费单元将经过处理所述计费请求或所述话单产生的帐务数据同步到管理中心。

在上述计费方法的实施例中，管理中心可以不要求计费单元将处理计费请求或话单产生的帐务数据上报同步，如果计费单元处理的是话单采集单元Mediation采集的话单，则计费单元不需将处理的结果返回给话单采集单元Mediation，所以，上述步骤S803及S804不是计费方法所必须的步骤。

上述步骤S802还可以由多个步骤实现，如图9所示，步骤S8021：计费单元的分发器将接收到的计费请求或话单生成标准计费事件，计费请求可以为DCC请求消息，话单可以为计费数据记录CDR；步骤S8022：分发器根据数据分布策略将所述标准计费事件交由计费单元包括的相应的计费设备处理；步骤S8023：计费设备根据所述标准计费事件进行业务包识别、批价、入帐处理。

上述步骤S8021还可以由多个步骤实现，如图10所示，步骤S80211：分发器的格式转换装置将接收到的计费请求或话单转换为中间计费事件；步骤S80212：分发器的预处理自动机将所述中间计费事件生成待求解标准计费事件；步骤S80213：分发器的计费要素求解装置对所述待求解标准计费事件的计费要素求解，并生成标准计费事件。

在图8所示的实施例中，步骤S802还可以分为两种情况：一种是对于计费触发单元发出的计费请求进行实时计费处理，另一种是对于话单采集单元Mediation采集的话单进行准实时计费处理。对于实时计费请求的处理可以分三种情况：对于Initial(初始化)消息，基本流程如图11A所示，从就绪状态开始，依次经过鉴权、业务包识别、反算、预留处理，之后返回就绪状态；对于Update(更新)消息，基本流程如图11B所示，从就绪状态开始，依次经过业务包识别、批价、入帐处理，之后返回就绪状态，其中，话音或流量计费有Update消息，事件计费没有Update消息；对于Terminate(终结)消息，基本流程如图11C所示，从就绪状态开始，依次经过业务包识别、批价、入帐处理，处理过程结束。对于话单的处理，计费设备处理的过程如图12所示，从就绪状态开始，依次经过业务包识别、批价、入帐处理，处理过程结束。在一个具体的计费处理的实例中，本发明的计费设备还需调用其它公共服务，如定期事务、AoC(Advice Of Charge，计费通知)等，从而构成完整的计费流程。需要说明的是，在处理实时计费请求或话单之前，进一步说，在就绪状态之前，本发明的分发器还需对实时计费请求或话单进行预处理，生成标准计费事件。

另外，计费系统还可以进行业务开通、业务变更、余额查询、余额充值、预付费与后付费互转等业务，现在结合附图，对这几个业务流程分别进行说明。

图13为针对增值业务开通/变更的流程图。

如图13所示，步骤S1301：客户在CRM中进行业务开通/变更申请，在这个步骤中，客户通过CRM接入方式进入开通系统，进行业务开通/变更；步骤S1302：CRM将修改后的档案信息同步到综合业务管理平台中，在这个步骤中，CRM负责将修改后的档案信息同步到综合业务管理平台中，以保证CRM与综合业务管理平台相关资料的一致；步骤S1303：CRM将修改后的档案信息同步到计费系统中，在这个步骤中，CRM负责将客户的定购信息同步到计费系统中，由计费系统启动相关的数据加载服务将数据加载到中央数据库、计费设备等存储设备中，另外，此步骤可与步骤S1302同时进行；步骤S1304：通信网络中的服务开通系统通过接口修改其他相关系统中的相关信息，其中，只有点对点的业务才需要步骤S1304，非点对点的业务可以省略此步骤。

图14为针对增值业务的后付费转预付费的流程图。

如图14所示，步骤S1401：客户或运营商发出付费方式修改请求，在这个步骤中，客户可以利用CRM统一提供的各种门户，发出付费方式修改请求，请求将其拥有的一个或多个产品实例由后付费方式改为预付费方式，运营商也可以根据客户的信用情况和欠费风险状况，将其从准实时计费转为实时计费，并允许一定额度的透支；步骤S1402：CRM对客户进行合法性验证、资费变更等处理，在这个步骤中，CRM根据一定的业务规则，对客户的付费方式变更请求进行审核，必要时需要进行人工审核，同时，如果付费方式的修改涉及到资费变更，例如，部分定价或优惠等只适用于后付费方式，而不适用于预付费方式，或者预付费无法支持该定价方式等，就必须进行相关的资费变更处理，并将变更情况通知客户；步骤S1403：CRM向计费系统发送付费方式修改通知，在这个步骤中，CRM向计费系统通知客户将部分或全部后付费产品实例转换为预付费方式；步骤S1404：计费系统对涉及的后付费产品实例进行结账处理，在这个步骤中，计费系统对涉及的后付费产品实例进行包括冻结相关的帐本余额、等待当前Session(会话)终结、停止该产品实例接受服务、将相关帐本余额设为预付费并接手该产品实例等处理；步骤S1405：通信网络中的服务开通系统向HLR、综合业务管理平台同步付费方式修改通知，在这个步骤中，根据涉及的产品实例的具体情况，服务开通系统通过相应的接口，向HLR、综合业务管理平台发送相关修改信息，其中，HLR接受涉及语音业务的修改，综合业务管理平台接受涉及数据业务的修改；步骤S1406：HLR、综合业务管理平台进行资料修改，在这个步骤中，HLR、综合业务管理平台收到付费方式修改通知以后，将进行相应的档案修改，将产品实例的后付费属性改为预付费属性。

图15为余额充值的流程图。

如图15所示，步骤S1501：客户向CRM发出充值请求，在这个步骤中，客户利用CRM统一提供的各种门户，如CRM界面、帐务系统界面、充值中心等发出充值请求；步骤S1502：CRM将充值信息同步到计费系统，在这个步骤中，CRM的统一门户将客户的充值信息发送给计费系统；步骤S1503：计费系统修改相关帐户的余额，在这个步骤中，计费系统根据充值信息，修改相关帐户的帐户余额。

图16为余额查询的流程图。

如图16所示，步骤S1601：客户通过CRM发起余额查询请求；步骤S1602：CRM将余额查询请求转发给管理中心；步骤S1603：管理中心查询用户帐户分布情况，获取计费设备信息；步骤S1604：管理中心通过动态数据查询接口，向计费设备发起余额查询请求；步骤S1605：计费设备将各帐本数据，例如预付、后付、优惠等帐务数据进行汇总；步骤S1606：计费设备将汇总的余额信息返回给管理中心；步骤S1607：管理中心将余额信息返回CRM；步骤S1608：CRM以语音、Portal(门户)或短信方式展示帐户余额。

此外，传统的数据传递方式有两种：一种是通过消息携带数据来传递，这种方式的优点是比较简单，只需要在消息中定义一个数据块即可，但是，当消息量比较大时，内存消耗较大，也影响主机处理性能；另一种方式是通过数据库共享方式，这种方式的实现更简单，只需要在数据库中定义一张表，将数据写入即可，但这种方式效率较低，不适应实时计费系统的响应要求。本发明的计费系统采用基于共享内存指针和内存链表的消息传递机制，如图17所示，数据传送流程如下：

(1)系统启动时首先创建一个全局的共享内存，其中，共享内存的大小根据系统的处理能力计算获得，也可以动态调整；

(2)识别组件接收到消息后，把消息参数在共享内存中展开，并把参数指针存放到TAG(标签)数据中，其中，识别组件用于对业务包识别；

(3)识别组件在处理过程中，会对某些业务特征量进行修改、删除、增加等操作，相应的对TAG数据也进行了修改、删除、增加等操作；

(4)识别组件处理完成之后，将TAG数组的地址返回给会话，会话在调用下一个功能组件即计费组件时，将所述地址传递给计费组件，计费组件就可以直接用；

(5)计费组件对数据的处理与识别组件一样；

(6)当会话结束后，TAG数组以及所指向的业务特征量内存被释放。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (19)

1.一种基于通信网络的计费系统，所述通信网络至少包括客户关系管理单元CRM、计费触发单元及话单采集单元Mediation，其特征在于，所述计费系统包括：

管理中心，提供所述计费系统的全部配置管理功能，并接收所述客户关系管理单元CRM同步的业务数据；

计费单元，用于处理所述计费触发单元发出的计费请求及获取所述话单采集单元Mediation采集的话单；

其中，所述管理中心接收并处理所述计费单元同步的帐务数据，所述计费单元接收并处理所述管理中心同步的业务数据。

2.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述计费单元包括：

多个计费设备，用于处理所述管理中心同步的业务数据；

分发器，用于将接收到的计费请求或所述话单转换为标准计费事件以及将所述标准计费事件交由相应的计费设备处理，并用于处理或转发所述多个计费设备的响应信息，所述分发器还获取所述管理中心中的所述业务数据。

3.如权利要求1或2所述的基于通信网络的计费系统，其特征在于，所述计费单元对所述计费请求进行预处理、鉴权、业务包识别、批价及入帐处理，对所述话单进行预处理、业务包识别、批价及入帐处理，其中，批价处理包括正算、反算及预留。

4.如权利要求2所述的基于通信网络的计费系统，其特征在于，所述管理中心配置有数据分布策略，所述数据分布策略具有所述业务数据在各个计费设备之间的分布信息及客户之间的关联信息。

5.如权利要求2所述的基于通信网络的计费系统，其特征在于，所述分发器还包括：

格式转换装置，用于将接收到的计费请求或所述话单转换为中间计费事件；

预处理自动机，用于将所述中间计费事件生成待求解标准计费事件；

计费要素求解装置，用于对所述待求解标准计费事件中的计费要素求解并生成标准计费事件；

分流装置，用于根据数据分布策略将所述标准计费事件交由相应的计费设备处理。

6.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述计费系统还包括：

配置门户，用于提供数据维护及配置界面；

中央数据库，用于存储所述计费系统的参数数据、所述业务数据及所述帐务数据；

其中，所述配置门户直接从所述中央数据库中获取所述参数数据，或者通过所述管理中心从所述中央数据库中获取所述帐务数据。

7.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述管理中心还用于在所述CRM中展示从所述多个计费设备、所述分发器或所述中央数据库中查询到的信息。

8.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述计费系统还包括：网管代理设备，用于将收集的所述计费系统的性能及告警信息提供给所述通信网络中的网管系统。

9.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述客户关系管理单元CRM同步的业务数据包括产品数据、客户数据、定购关系数据及定价数据。

10.如权利要求1所述的基于通信网络的计费系统，其特征在于，所述计费单元同步的帐务数据包括帐户帐本数据、明细帐目数据及累计数据。

11.如权利要求1、2或5所述的基于通信网络的计费系统，其特征在于，所述计费请求为Diameter信用控制协议DCC请求消息，所述话单为计费数据记录CDR。

12.如权利要求11所述的基于通信网络的计费系统，其特征在于，如果所述计费请求为Diameter信用控制协议DCC请求消息，则所述相应的计费设备将计费结果直接或通过所述分流装置返回给所述格式转换装置转换为DCC应答消息，并返回给所述计费触发单元。

13.一种基于通信网络的计费方法，应用于权利要求1所述的计费系统，其特征在于包括：

计费单元接收计费触发单元发出的计费请求或获取话单采集单元Mediation采集的话单；

所述计费单元根据资费规则处理所述计费请求或所述话单。

14.如权利要求13所述的基于通信网络的计费方法，其特征在于，所述计费请求为Diameter信用控制协议DCC请求消息，所述话单为计费数据记录CDR。

15.如权利要求14所述的基于通信网络的计费方法，其特征在于，如果所述计费请求为Diameter信用控制协议DCC请求消息，则所述计费单元将所述处理DCC请求消息产生的结果转换为DCC应答消息后，返回给所述计费触发单元。

16.如权利要求13所述的基于通信网络的计费方法，其特征在于，所述计费单元对所述计费请求进行预处理、鉴权、业务包识别、批价及入帐处理，对所述话单进行预处理、业务包识别、批价及入帐处理，所述批价处理包括正算、反算及预留。

17.如权利要求13所述的基于通信网络的计费方法，其特征在于还包括：所述计费单元将经过处理所述计费请求或所述话单产生的帐务数据同步到管理中心。

18.如权利要求13所述的基于通信网络的计费方法，其特征在于所述计费单元根据资费规则处理所述计费请求或所述话单的过程包括：

所述计费单元的分发器将接收到的所述计费请求或所述话单生成标准计费事件；

所述分发器根据数据分布策略将所述标准计费事件交由所述计费单元包括的相应的计费设备处理；

所述计费设备根据所述标准计费事件进行业务包识别、批价、入帐处理。

19.如权利要求18所述的基于通信网络的计费方法，其特征在于所述计费单元的分发器将接收到的所述计费请求或所述话单生成标准计费事件的过程包括：

所述分发器的格式转换装置将接收到的所述计费请求或所述话单转换为中间计费事件；

所述分发器的预处理自动机将所述中间计费事件生成待求解标准计费事件；

所述分发器的计费要素求解装置对所述待求解标准计费事件的计费要素求解，并生成标准计费事件。

Images