Microcomputer Applications V ol.27,No.5,2011开发应用微型电脑应用2011年第27卷第5期
文章编号：1007-757X(2011)05-0049-03
王倩
摘要：对上海电信的跨越在线计费和离线计费平台的交叉业务现状进行了分析，对3种可行的解决方案进行了对比分析，在此基础上重点阐述了支持在线和离线分别计费但批价依据、计费累积量、余额集中共享的计费系统的设计方案。 关键词：在线计费，离线计费
中图分类号：TP311文献标志码：A
0引言
由于预付费业务具有使用方便、易于进行成本控制等特点，因此一直以来受到用户的青睐，目前全球移动通信用户中有60%以上选择预付费。为了有效控制欠费风险，运营商越来越倾向于采用在线计费 系统（OnlineChargingSystem，简称OCS）承载预付费业务。但是，由于在线计费系统的建设和运营成本高于离线计费系统（OfflineChargingSystem，也可以称HotbillingSystem，简称Hotbilling），而且在线计费对于业务网元的计费接口和内部改造要求也较高，部分业务网元经常达不到改造要求，因此，运营商还是会把相当一部分用户承载在Hotbilling系统之上。因此，就出现了有的预付费用户在OCS上，有的预付费用户在Hotbilling上的局面。
后付费业务目前基本由Hotbilling承载，但也不排除今后为了提升用户服务、运营商实施监控或实时营销的目的，逐渐会有后付费业务承载在OCS上。
同时，不少家庭客户、企业客户往往同时拥有预付费和后付费业务，即使是个人客户，也会有类似情况。往往这些客户还希望这些业务能够实现交叉折扣和捆绑优惠，从而获得价值最大化。对于运营商而言，就面临着如何实现跨越不同的计费平台交叉业务的问题。
1交叉业务需求现状、系统承载现状
在线计费OCS：在线计费是指用户在使用电信服务的时候，服务费用的计算和余额的更新参与了用户服务使用过程的计费方式。并依据用户在线业务使用信息进行正算和反算，结合在线业务控制网元的实时话务控制能力，以在线事件作为计费依据，实现对用户的精确计费和精确控制。
离线计费hotbilling：离线计费是指用户在使用电信服务的时候，服务费用的计算和余额的更新没有参与用户服务使用的过程，服务费用的计算和余额更新是在用户服务使用后进行的计费方式。
交叉业务的场景可以归为两类：
业务场景1：单个用户不同业务分别在在线计费和离线计费中，需要进行交叉处理。
业务场景2：不同用户分别在在线计费和离线计费中处理，需要进行交叉处理。
交叉业务处理的主要分类：
跨平台的多个用户或业务共享余额
跨平台的多个用户或业务共享免费资源元数据管理平台
跨平台的多个用户或业务之间激励赠送，即，这个平台的某些用户或业务当月达到了多少收入贡献后，给另一个平台上的用户或业务进行赠送
2三种解决方案的建议
为了实现跨平台的交叉，主要建议的方案有三种。分别是引入第3方应用系统传递优惠信息的解决方
案、在线计费与离线计费系统增加实时和非实时接口的解决方案、在线和离线分散计费但批价依据、计费累积量、余额集中共享的解决方案。
2.1保持计费系统现状，引入第3方应用系统传递优惠信息的解决方案
系统逻辑示意图如图1所示：
图1引入第3方应用系统传递优惠信息的解决方案系统逻辑示意图
该方案实现的原理是引入第3方应用系统获取Hotbilling系统和OCS系统的准实时或实时的累积量信息，再获得外部如crm系统的资产数据，根据交叉业务逻辑进行计算得出向哪个系统给予赠送，将赠送信息以文件形式返回给该计费系统。
业务需求是在hotbilling上的业务A打满x元以后，给该业务在OCS上捆绑的业务B予以赠送。根据此需求，主要实现方法为：
电磁悬浮
1)第3方应用先从Hotbilling系统获得业务A的当前使用量
———————————
作者简介：王倩(1977-)女，汉族，上海电信局，资深业务分析师，研究方向：计费平台发展演进，上海，200071
49
Micr ocomputer Applica tions V ol.27,No.5,2011开发应用微型电脑应用2011年第27卷第5期
5信息（即图1中的第1步，如果案例是OCS 上的业务B 为
优惠条件，则需要从OCS 获得使用量，即图1中的第2
开关柜无线测温步）；
2)再从crm 获得业务A 与业务B 的捆绑信息，以确定应该向
哪个计费系统赠送（即图1中的第2步）；
3)根据业务规则，计算出可以获赠的具体金额；
4)根据业务B 所属的平台，决定向Hotbilling 还是OCS 进行
赠送（即图1中的第4、5步）；
5)由OCS 、Hotbilling 根据赠送文件加载到各自的余额帐本
中。
该方案是在保持计费系统现状的基础上提出的解决方
案，优点是对于现有的交叉优惠的业务需求可以快速支撑。
缺点是由于采用的是实时性较弱，有一定局限性，比较适用
于跨平台的多个用户或业务之间激励赠送，而对于跨平台共
享余额、共享免费资源这类实时性要求较高的需求则不适
用。
电解阳极板2.2在线计费与离线计费系统增加实时和非实时接口的解丙纶长丝
决方案
该方案系统逻辑示意图如图2
所示：图2在线计费与离线计费系统增加实时和非实时接口的解决方案系统
逻辑示意图这个方案的主要思想是余额、共享的免费资源统一由
OCS 管理，而非共享免费资源还是由两个平台各自管理，并
增加OCS 与hotbilling 之间的实时、非实时接口来解决3类交
叉业务场景。
共享余额的实现方法：OCS 开放余额查询接口给
hotbilling ，以实现准预的信控。由于信控的及时性要求，建
议是实时接口。Hotbilling 月末开账后输出批量扣款文件给
OCS ，每月一次，建议文件接口。
共享免费资源的实现方法：由于OCS 的免费资源也是帐
本方式存放，因此OCS 可以开放扣款接口给Hotbilling 调用，
以实现共享免费资源，由于批价实时性要求，建议实时接口。
跨平台的业务使用激励赠送：OCS 、Hotbilling 各自开放
调帐接口给对方调用（前提是两个计费系统本身必须具备跨
业务赠送的计费核心能力），建议准实时文件接口。
上述方案中的OCS 余额查询接口、OCS 扣款接口、OCS
调帐接口都是OCS 现有接口，无需改造。OCS 只要通过外挂
应用对于跨平台的使用激励赠送能够取出赠送给对方平台
的金额并生成文件即可。可以看出，该方案是尽量利用OCS
现有接口，尽量减少对OCS 系统核心改造较少。
Hotbilling 的调帐接口也是现有的。但Hotbilling 系统的
访问余额的模式要从原来的被动同步，改为主动从OCS 同
步，对信控模块改动较大。同时Hotbilling 系统还要能够对
于共享免费资源的用户增加标志，遇到这类用户不能从本地
取免费资源，而是要改为从OCS 获取免费资源。另外需要增加与OCS 间的批量扣款接口，该接口在ABM 规范中集团已经明确，本方案实际上是利用了OCS 内部已有的余额管理功能，因此该接口可以参加集团规范新建，同时也便于今后向ABM 的过渡。还需要考虑的问题是：OCS 从仅存放预付费业务的用户资料和余额帐本改为后、预都要存放，要考虑容量问题。另外在进行营销活动配置之前，要做好需求分析工作，对于需要共享免费资源的套餐，要将免费资源配置在OCS 系统中，并在Hotbilling 系统中对此类套餐配置相应标志。2.3在线和离线分别计费但批价依据、计费累积量、余额集中共享的解决方案该方案的示意图如图3
所示：
图3在线和离线分别计费但批价依据、计费累积量、余额集中共享的方案系统逻辑图
该方案的主要思想是将批价依据、计费累计量、可用余额这些关键信息从在线计费和离线计费中剥离出来集中共享，在线计费和离线计费使用同一批价引擎（但在线计费和离线计费的应用实例还是分别部署），从而实现交叉业务。系统架构描述如下：在线计费接收来自业务网元的OCP 协议请求消息，
由在线计费的计费控制调用计费引擎及批价依据、累积量等信息，以在线消息作为计费及余额计算的依据，并输出话单。离线计费接收业务网元的服务请求记录（CDR ）进行离线计费处理，并能对在线计费结果进行稽核，并对在线计费以外的话单进行计费，提供在线计费异常情况下的补计功能。共享数据：计费累积量放在融合计费统一管理、帐户当前可用余额在综合帐务进行统一管理。对于一个用户，只存在一份可用余额、计费累积量和帐务信息，供在线计费、离线计费、综合帐务使用。2.4几种方案的比较在表2中对上述3种方案进行了分析比较。总体上说，方案3.1适合于实时性要求不高的业务场景，并且缺陷最多，但由于不涉及计费系统的改造，因此部署最快，目前已经上线运行，可以做为过渡方案支撑。方案2.2和2.3都实现了3类交叉业务场景。是同一批价引擎，是比较理想的方案。不同之处在于，方案2.2可以不要同一计费厂商，最大限度地利用了OCS 现有接口，只要求Hotbilling 做核心改造。但正因为不是同一厂商，今后在线、离线计费系统能力一致性上容易存在问题，而且由于在线、离线系统之间增加接口调用，实时性也稍逊。由于上述原因，如果从考虑保护已有投资、较快部署上
Microcomputer Applications V ol.27,No.5,2011开发应用微型电脑应用2011年第27卷第5期5线的角度，建议采用方案3.2；否则建议直接采用方案3.3，
能更好支撑业务的发展。下面的内容也主要介绍方案3.3如
何有效支持交叉业务。表2三种交叉业务计费解决方案比较比较内容
方案3.1方案3.2方案3.3交叉业务计费需求满足程
度
满足跨平台的多种业务的使用激励优惠，但不适合共享余额、共享免费资源的交叉业务3类交叉业务场景都能满足3类交叉业务场景都能满足实时性的比较
实时性较差实时性较好实时性最好对于计费产品厂商一致性
的要求
不要同一厂商不要求同一厂商要求同一厂商系统改造的复杂程度
最小（该方案已上线使用）对Hotbilling 改造要求较多，对OCS 改造较少几乎重新建设、改造量最大外部系统工作量
由于要引入第3方应用实现业务主体逻辑，因此工作量最大主要是充值系统调整充值方向、EAI 系统调整订单方向重新建设，相关系统要配合调整或调试在线、离线计费支撑业务
的能力一致性由于可能是不同厂商的批价引擎，能力可能不一致。新功能需要两个厂商评估
改造同方案3.1同一批价引擎，一致性最好
3方案3.3实现交叉业务的系统流程
以单用户不同业务交叉优惠场景举例：用户A 享受“数
据上网流量满500M 后，送30分钟语音通话时长”的优惠。
用户A 在使用数据流量业务进行流量下载的同时，进行
语音呼叫。假设用户A 的语音业务是通过在线计费中进行计
费处理。用户A 的数据上网流量业务在离线计费中进行计费
处理。用户A 的可用余额和计费累计量存放于共享数据中，
供在线计费和离线计费进行实时和准实时的扣减如图4所
示：图4方案3.3实现共享余额、共享免费资源的流程图
流程1：用户A 发起语音呼叫请求，由在线计费对其进
行计费处理，通过实时余额计算实时更新用户A 的可用余
额。
流程2：用户A 上网时，网元设备产生离线的话单，由
离线计费对其进行计费处理并更新用户A 的数据流量的计
费累计量，之后通过帐务处理更新用户A 的可用余额（图中
蓝线流程）。
当用户A 的数据流量达到500M 的时候，触发语音通话
送30分钟时长的优惠规则，在线计费对后续30分钟的语音通
话做免费处理，并记录时长的计费累计量，直至时长的计费累计量到达30分钟后，该优惠结束。如果
是多个用户或业务共享余额、共享累积量或多个用户的不同业务进行交叉优惠的业务场景，系统实现的流程与单用户不同业务交叉优惠是一致的，只是将优惠条件或目的对象范围扩大到组即可，因此不再赘述。4结束语
目前建议的在线和离线分别计费但批价依据、计费累积量、余额集中共享的解决方案也存在一定的需要业务认可的前提。前提1：单个用户不同业务分别在在线计费和离线计费中处理，且涉及不同业务间的交叉优惠时，因为离线话单有延迟，系统无法按照业务实际发生的时序得到计费信息，所以业务必须认可按照系统处理的时序进行优惠。前提2：不同用户分别在在线计费和离线计费中处理，且涉及不同用户间的交叉优惠时，因为离线话单有延迟，系统无法按照业务实际发生的时序得到计费信息，所以业务必须认可按照系统处理的时序进行优惠。但此方案仍然是一个最佳解决方案，也是近期各运营商最推崇的方案。该方案还需深入考虑的问题是如何控制离线计费中的“最后一次通话”的欠费风险。目前业界已经有了一些尝试，如设置某一余额基准阀值（如15元），将小于该阀值的用户转为在线计费方式以根除欠费风险。但基准阀值如何测算？如果防止恶意用户试出阀值？离线计费和在线计费的转换需要业务网元支持，如何提高转换效率？这些都是待研究的问题。解决这些问题后的计费系统将为融合业务、实时业务的发展发挥更大作用。参考文献：[1]中国移动NGBOSS1-BOSS(V2.0)系统流程框架规范[2]中国电信计费规范V2.8策略与实施分册
拼接处理器（收稿日期：2010.10.15）
1
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议