计费原理与实现排版后推荐先看这个

1、OCS计费原理与实现拟制: Prepared by评审: Reviewed by审核: Reviewed by日期：Date日期：Date肖呈祥2008-02-01日期：Date批准:Granted by日期：Date技术Technologies Co.,.所有s文档版本所有和1所有 (c)技术OCS计费原理与实现1目录OCS 计费原理与实现11序篇1-11.1.1-11.2 导读1-2扫盲篇2-12.1 计费流程2-12.1.1 预处理部分2-132.1.2 批价部分2-152.1.3 入帐错误!未定义书签。2.1.4 后处理2-2022.2名词解释2-62.2.1 TAG：即变量，可以理解

2、为原先 SER 中的 CID2-62.2.2 业务用量：即某类消费的消费量2-62.2.3 费用项（帐目）：即消费明细，可以理解为消费.2-62.2.4：在 CBE 侧统一理解为“定价计划”，即一套新的费用计算体系包 2-72.2.5 订购：指用户拥有哪些定价计划（费率计算体系）2-92.2.6 入帐关系：即说明消费明细应该在哪个帐户上扣2-102.2.7 模板错误!未定义书签。2.2.8 策略2-122.2.9 计费矩阵分组键值错误!未定义书签。入门篇3-13.1 概述3-13.2 呼叫流程3-23.2.1 基本计费流程介绍3-23.2.2 计费能力集层3-23.2.3 实例化资费数据层3-

3、533.2.4处理3-143.2.5 累计项处理3-193.3 充值流程3-203.3.1 说明3-20文档版本所有和1-1所有 (c)技术OCS计费原理与实现目录3.3.2 预处理3-203.3.3 模板说明3-213.4 月结3-253.4.1 月结流程3-253.4.2 回赠3-284提高篇4-14.1 批价过程详解4-14.1.1 概述4-14.1.2 业务识别4-24.1.3 批价处理4-114.2 费用计算体系4-144.2.1 费用计算 API4-14延伸5-151-2文档版本所有和所有 (c)技术OCS计费原理与实现11序篇1.1这篇文章不能告诉您如何成为一个OCS 问题的参考

4、资料，也不能直接教您如何去做版本开发，更，也不是您做资费数据配置的教您去搭好一个测试环境。那么这篇文章有什么作用？很多人反馈 OCS 门槛太高了，初学者难以入门。细细分析一下，导致 OCS 门槛过高的，主要是如下几点：OCS 好多概念了都太过于抽象，而且新名词、新概念很多；lOCS了太多细节给用户，初学者往往容易钻到细节里面出不来；l在某些版本中，OCS 被揉成了一团，动了这一个牵扯到另外一个，不容易理解；lOCS 环境要求的硬件配置比较高，比较难以协调到l动手实战练习“降低 OCS 计费入门门槛”，基于这样一个理由，那么这篇文章有如下特点：名词、概念的解释比较通俗；尽量采用比喻的形式，然后辅

5、以OCS 的实现实例作解释；封装细节；对于一些初学者不必了解的东西干脆不说，如“预/后处理”这一套机制不做说明，读者仅需要了解这一块干了什么事，输入输出是什么即可；对于很多复杂的对象、表结构仅仅讲述主要的、被用户感知的属性或字段；层层深入；文章分成三个章节：“扫盲篇”、“入门篇”、“提高篇”， 对于计费过程都有不同程度的深入和细化，很多对象、表结构在三个不同的章节有相应的扩展和延伸；同时部门好多兄弟都对以前智能网的 iCharge 比较熟，那么这篇文章也特别照顾了这群兄弟，在介绍 OCS 计费的时候，会经常拿着这个来做对比，加深理解。llll那么，对于第四个问题，这篇文章也解决不了，它当然教您

6、成为协调的高l手_。这篇文章通过上面一系列，重点把原理给阐述清楚，对于非开发的您，或许不需要 OCS 环境就可以开展各项工作了J那如果您看完这篇文章之后，还发出如此感慨：哼，OCS 也不过如此嘛，比智能网 iCharge还 easy！那么这篇文章就得到了最大的价值体现。文档版本所有和1-1所有 (c)技术OCS计费原理与实现1序篇1.2 导读本文章的内容主要分为“扫盲篇”、“入门篇”、“提高篇”三个篇章。“扫盲篇”主要讲解 OCS 计费的大体流程，以及一些比较重要的 OCS 计费概念、名词等。l“入门篇”目前 OCS 呼叫、充值、月结三种典型流程进行阐述，同时对常见l的一些计费配置需求进行讲解

7、分析，并通过解释系统的运行机制，加深您对于 OCS 运行机理有了更具体的理解。那么看完这一篇章之后，对于一些常见简单的资费套餐配置，您应该能够配置得出来。“提高篇”OCS 计费中最的批价流程做了更深入的阐述，通过这一篇的l阅读，您应该对于 OCS 计费的流程有了更具体深入的理解。来了一些复杂的计费需求，您也能够配置出来或者提出较为理想的实现方案。1-2文档版本所有和所有 (c)技术OCS 计费原理与实现2 扫盲篇2扫盲篇2.1 概述2.1.1 计费系统的演进本章节，将以一个虚构的“计费系统”的演进故事，希望以一个比较通俗的方式阐述计费的一些基础概念和原理。本故事纯属虚构，雷同，实属巧合J小程目

8、前是一家大型电信设备公司的研发总监，他所主导开发 OCS 计费系统，目前市场占有率 40，成为目前电信计费系统的霸主，这套 OCS 计费系统由他统经过一系列变迁，已经变得非常强大。小程将计费系统的变迁划为 4 个缔造的系： 原始计费 简单计费 复杂计费 OCS 计费原始计费起初局方的要求比较简单，只要实现主被叫号码不同、费率也不同即可。故该计费系统采用两张表实现这个系统：1） 用户表，用户的金额；2） 费率表，根据主被叫归属被叫拜访地号码头获得此次呼叫的费率；同时需要实现预业务的实时计费和欠费风险能力，该系统采用反算（或称预算）的功能实现，即在用户进行通话前会让计费系统预先根据用户的余额算出可

9、以通话的时长，然后把可通话的时长返回给呼叫系统进行，这样解决欠费风险功能。呼叫结束之后，呼叫系统上报实际通话时长进行扣费，这样解决实时计费的功能。这一时段的系统，计费需求比较原始，小程把他称为“原始计费系统”。文档版本所有和2-1所有 (c)技术OCS计费原理与实现2 扫盲篇简单计费后来随着系统的上线，发现而一个地区会有多个号段，而主被叫归属地、拜访地等四个维度组合在一起，造成费率表的非常庞大。最的是局方会经常修改费率，这样子每一次调整费率，需要分析每一个调整的地区涉及费率表的修改情况，这样子极不直观，修改量大，很容易出错。而且，局方随着用户数的增加，会在不同的不断开放新的号段，每一次增加新的

10、号段， 都要配置该号段到各地市号段的费率，这样造成费率表的数急剧增大。为了解决这个问题，小程将查找费率的动作分成三个步骤：1） 号码分析，根据主被叫归属被叫拜访地号码头获得主被叫归属地区号、拜访地区号，将一个地区多个号段进行归一；2） 计费矩阵，将一次呼叫分成基本费、漫游费、长途费三种消费，对应不同的费率索引（称 ChargeClass），根据前面的号码分析得到的地区号获得对应的消费类别费率列表，这样子进一步缩小由于维度不同形成的费率数。3） 费率，这个表专门描述费率，被计费矩阵求出的 ChargeClass。这个表的数据会比较小一点。因为一个局点的费率如果太多的话，连局方也会被搞晕J由于将“

11、费率”从计费中出来，这样局方如果修改费率仅需要在费率表修改几条记录，大大增加了系统可维护性；将“号码分析”出来，在某个地区增加新的号段，仅需要在号码分析表中做好配置，即可，大大降低了工作量。在这一阶段，小程认为系统的可维护性有了质的飞跃，将此次改进又划为一个阶段：“简单计费”。复杂计费随着移动用户的数目逐渐增长扩张到一定程度，简单的资费降价已经不能吸引用户入网。同时发现，入网的用户打的次数和时间很少，而资费降低到一定程度以后，仅仅是用户打次数和时间少量增加了，整体消费的额度并没有得到很大的提升。运营商决定，改变单一调整资费的销售策略，采用多元的销售：1） 消费制度，消费到一定程度，对用户进行赠

12、送，鼓励继续消费2） 专款专销，划分用户群。不用的用户群推出不同的套餐，如 50 元钱可以500 分钟的长途通话时间，10 元钱200 分钟市话通话时间。而长途通话时间只能用于拨打长途、本地通话时间只能用于拨打市话，这些本用户余额；时长用完可以使用基3） 充值送 40，分几在网时间较长的用户或者消费比较多的用户进行充值赠送等；，如充 1004） 越打越便宜，头 3 分钟 4 毛钱/分钟，后 10 分钟内 2 毛钱/分钟，10 分钟后 1 毛钱/ 分钟；。2-2文档版本所有和所有 (c)技术OCS 计费原理与实现2 扫盲篇运营商提出这一系列要求之后，原先的那套“简单计费系统”，明显不能满足这一系

13、列需求。这种情况，小程决定再次改造这套系统，进行一个大手术：1） 首先，将计费系统一分为二：分为实时计费模块和定期事物模块。 实时计费系统负责每次呼叫的消费费率计算，有些地方称这个模块为 iCharge 或sbf。 定期事物模块负责赠送和扣取月租，每天自动执行，看看需要赠送到哪个帐户中，如果是月结需要扣取月租。有些地方称这个模块为 iuser-bill 或rent。定期事物模块解决了充值分月赠送、套餐定期赠送等功能。2） 其次，将原先的用户余额抽象成为“帐户”，从“用户”中出来，单独建一张“帐户”表。系统可以定义多种“帐户”类型，存放不同的“余额”：如长途通话时长、市话通话时长、充值赠送金额、

14、累计消费金额等。3） 再次，将原先的实时计费系统进行增强扩展： 原先的“号码分析”、“计费矩阵”模块依旧保持不变（架构已经能很好的适应目前需求）； 将原先的 ChargeClass 纯粹费率索引的意义进行扩展为“消费类别”，同时定义消费类别只能在哪些帐户上扣，以及入帐优先级关系，和费率等。如定义：长途呼叫时的所有消费类别，只能从“长途通话时长”、“充值赠送金额”、“基“长途通话时长”，费率是 1/1 秒，本金额”中扣取，优先级也是先扣扣完后从“充值赠送金额”、“基本金额”等帐户扣取，费率为 20/60 秒。 将原先的费率表进行扩展，将原先单一的费率，扩展成多个分档，实现越打越便宜。通过第二步和

15、第三步，就实现了“专款转销”、“消费累积”的功能。在这一阶段，小程认为系统的计费能力得到了计费”。的提升，把这个阶段的计费为“复杂OCS 计费到了 3G经愈感吃，业务内容越来越丰富，“复杂计费系统”已经对于这些计费需求的支撑已要是体现在：1） 计费请求的内容日趋复杂，由于业务内容的丰富，需要实现“一卡多用”功能。运营商可能会推出 UC 即时通信、ADSL 上网以及其他，为了快速推广这些业务，需要这些支持原有用户，而不用重新。这样子就要求原先的用户能够同时支持多种业务的消费，原先的那套根据余额算出时长的欠费风险机制一个帐户同时只能被一个业务使用，不能满足需求；2） 由于用户的帐户用于多种计费，那

16、么计费请求不仅仅只是原先单一的根据“呼叫时长”进行计算消费金额。其他计费请求的如条数、GPRS 流量、ADSL 上网流量、直接扣款金额等等。如 3G 的场景下，一次计费请求中可能包含多种消费， 既通话又等。原先那套通过“ChargeClass+时长”来表示消费费方式不同已经非常；3） 由于电信运营竞争的加剧，局方会推出各式各样的套餐，推出时间也越来越短。而原有的系统只能通过调整 ChargeClass 来实现套餐的已经非常不直观，较难满足文档版本所有和2-3所有 (c)技术OCS计费原理与实现2扫盲篇快速推出新套餐。如 20 元套餐赠送 300 分钟市话通话时长、200 条网内、所有省内漫游低

17、至 1 毛/分钟。这样的套餐在原有的系统上较难快速实现，既要在 iuser-bill系统上配置数据，又需要 iCharge 系统上配置数据来调整费率；4） 后和预需要融合，原先的这几套系统只支持预。但是局方推出和资费套餐活动则需要同时支持预、后，不应该跟类别扯上关系；5） 由于计费请求的种类增多，因为不同计费种类计费方式不同，影响计费的因素也不同，为了满足需求，原先的代码分支越来越复杂，在修改资费和新推出套餐的时候极容易影响原有其他模块的计费。为了解决上述问题，小程决定对现在系统再作一次大手术：1） 将原先的“消费类别”（ChargeClass）进一步抽象，扩展成“业务用量”，包含两方面意思：

18、消费的业务是什么，消费的量是多少。如：20 分钟的长途费消费，2M 的GPRS 流量消费。业务用量的概念相比于 ChargeClass 更为贴切、更为复合要求。如果新增一种计费请求消费类别，能够很容易得到扩展；2） 将每种计费请求抽象成“计费”，将影响计费的一些参量抽象成“计费要素”，每种“计费”包含不同的“计费要素”和“计费要素”求解过程，这样子新增新的计费请求种类只需要新加代码， 的；修改原先的实现，这样的修改是“线性”3） 将原先的 iUser-bill 和iCharge 融合到一起，它们仅仅是实现不同的计费功能，如iuser-bill 实现的是定期事务的“计费能力”，而 iCharge

19、 实现的是根据“业务用量”进行计费（以下通称批价）的“计费能力”。将这些“计费能力”抽象成可复用的功能模块，并取了一个新的名词“模板”或“策略模板”；如将定期赠送话费的计费能力做成一个“赠送模板”，赠送的内容做成参数，供其他模块调用；呼叫提供按业务用量的计费模板，将费率和适配条件作为参数。4） 将每一次实现新的资费活动和新套餐抽象成“定价计划”。定价计划通过调用多个“模板”，数据。如“20 元套餐赠送 300 分钟市话通话时长、200 条网内短信、所有省内漫游低至 1 毛/分钟”这样的套餐，可以调用“赠送模板”，“赠送内容参数”配置成“300 分钟市话通话时长”、“200 条网内”实现赠送的，

20、调用“呼叫计费模板”，传入费率参数为“1 毛/分钟”，适配条件为“省内漫游”。这样子，通过预先定义一系列不同计费能力的“模板”，在局方推出活动的时候，只需新定义一个“定价计划”来调用这些“模板”即可实现快速推出资费包；注意要在现网上能够快速推出活动，所做的修改，需要具有两方面的特性：可测试性和兼容性。兼容性、可测试性体现在：1， 所做的改动不应该影响现性；2， 改动完成之后在测试时，只影响测试用户，不影响其他用户；2-4文档版本所有和所有 (c)技术OCS 计费原理与实现2 扫盲篇推出新的活动，采用新增“定价计划”实现，仅仅是新增数据，影响现有的特性。采用订购的方式，所有用户只有订购上了该“定

21、价计划”，才能享受到这套测试时只需将测试用户订购上，即可测试，且不影响其他用户。资费，5） 后后和预仅仅是支付方式不同，预没有欠费的风险（先把钱给预支了），计费完成之后则要考虑帐单打印、帐单邮寄、欠费自动催缴等一系列动作。计费这一方面应该是可以统一的。为实现这种统一，将业务用量类型分为“请求业务用量”、“已使用业务用量”、“业务用量”； 预用户在使用之前，业务系统应该发起计费请求，传入“请求业务用量”的大小，如果用户帐户余额足够，则返回“业务用量”的值为“请求业务用量”；如果不够，系统根据用户的帐户余额进行计算出“业务用量”。业务系统根据“业务用量”用户消费；（一般指话单，包含业务的使用量）

22、后使用业务完成之后，将消费的传送给计费系统，业务的使用量作为“已使用业务用量”，系统根据“已使用业务用量”进行批价入帐。6） 通过上面的改造，批价入帐的动作对于预和后是完全一致的，故局方推出所有新的资费及活动，对于后预都可以适用（因为“定价计划”属于批价入帐动作之内）。预批价入帐之后只需要出话单即可，而后需要出帐单、帐单邮寄、欠费自动催缴等特性可以移植原先后系统。7） 通过采用预用户进行“请求”可使用消费量的方式，即可实现“一卡多用”的需求，如用户有 10 元钱，A 业务发出呼叫 5 分钟的请求，这个需要消费 1 元钱，那么还有 9 元可用，同时 B 业务发起请求 200M 流量的请求可以被响

23、应。而不像原先系统中一定要等到 A 业务呼叫完成，B 业务才能进行消费。通过这一系列的改造，计费系统已经能够满足快速推广业务、支持多业务内容的计费，小程将当前阶段的计费为“OCS 计费”。上面说了这么长演义式的故事，其实并非纯属虚构J，其实这些计费系统在现实中是有生活原型的，如： Comvers 公司的智能网系统（M8 割接 Comvers 智能网，分析其系统得知）就是采用“原始计费”来实现； 早期的 TELLIN 业务，如 200 卡、iCard 等系统采用的是“简单计费现方式； 后期 WIN 的 iUser/PPS 业务；FIN 的 BaseCall、APS 等都是采用“复杂计费” 的实现

24、方式；”的实 目前现在的 OCS 系统采用的是“OCS”的实现方式。文档版本所有和2-5所有 (c)技术OCS计费原理与实现2扫盲篇2.2 名词解释在 2.1 节，您大致了解了 OCS 一些概念，但是可能对于这些概念的理解依旧还是云里雾里；那么在这一章节，我先将对这些重要的概念和名词先详细阐述一遍，我尽量采用比较实际的例子来阐述。2.2.1 TAG：即变量，可以理解为原先 SER 中的CID和 CID 不一样的是，在 CHG 侧一般喜欢用数值来描述 TAG，而不喜欢像 CID 变量一样名称来描述。我们常常称 TAG 1080（存放 SCP 请求的呼叫时长）值是 300，而REQUIRED_CA

25、LL_DURATION 值是 300。说变量2.2.2 业务用量：即某类消费的消费量举一个例子，我们在一次消费当中买了 2 瓶矿泉水、4 个面包。那么，矿泉水业务用量为 2，面包业务用量为 4。在 OCS 中，我们一次呼叫计费当中，在主叫的计费流程当中，我们会分析主叫是否有漫游，是否拨打的是长途。如主叫漫游的时候拨打了被叫长途 5 分钟，那么此次流程当务用量“基本费业务用量”、“长途费业务用量”、“漫游费业务用量”都是 300 秒，如果用户没有漫游，那么“漫游业务用量”为 0 秒。“市话业务用量”、“长途业务用量”、“漫游业务用量”等都是我们在设计的时候的。这个类别的划分跟智能网的 charg

26、eclass 意义比较类似。如：在OCS 中，呼叫流程主叫子流程划分了 5 个业务用量。好表2-12.2.3 费用项（帐目）：即消费明细，可以理解为消费批价完成之后会输出一系列的费用项条目，这个将作为入帐的输入，CBE 依据此消费清单入到各种帐户上，把相关金额扣除。举个例子，我们在商场购物买了 2 瓶矿泉水、4个面包。那么这个消费可能就为：2-6文档版本所有和所有 (c)技术用量名称TAG备注基本费时长2003长途费时长2005漫游费时长2004被叫漫游长途时长2311未用附加费业务量2317未用OCS 计费原理与实现2 扫盲篇表2-2费用项是对每一条“消费”的一个归纳，在一次消费中有多少中消

27、费类型，如在广东版本中主叫呼叫设计了如下的费用项(B07 及以上版本)：1|本地通话费用项2|漫游通话费用项3|长途通话费用项lll在 OCS 中一次批价所输出的费用项是采用链表方式实现的，此次计费流程业务用量的消费明细。如主叫漫游的时候拨打了被叫长途 5 分钟，市话费率是 1 毛 1 分钟、长途费率是 2 毛 1 分钟、漫游费率是 3 毛一分钟。那么此次呼叫的费用项链表为：表2-32.2.4：在 CBE 侧统一理解为“定价计划”，即一套新的费用计算体系包在很多文档里面的定义是“管理系统定义的与融合计费系统的规则的对应关系及产品级参数”，在这里，为了方便理解，我有意把他的含义窄化了。随着后面层

28、层深入的解读，您会逐层加深对“定价计划”的理解。定价计划级别现在 CBE 平台支持 3 个不同级别的定价计划： 一级、四级。一级主定价计划。一般我们设计的时候，用于提供用户基础功能的费率计算方式，如用户拨打本地、长途、作被叫时、收发时费率计算方式。这一套费率计算体系我们统一放到一个新的主定价计划里面。一般来说，每个用户都需要订购一个一级计划），否则他将不能使用基础功能。（定价如：江门现网中，移动划分了 6 个不同的子品牌，不同子品牌有一套不同的费率计算体系，故在江门版本中我们了如下 6 个主定价计划：文档版本所有和2-7所有 (c)技术业务用量数值金额（分）费用项2003|基本费时长30050

29、1|本地通话费用项2005|长途费时长3001003|长途通话费用项2004|漫游费时长3001502|漫游通话费用项消费类型数量金额（元）矿泉水24面包44OCS计费原理与实现2 扫盲篇GD动感地带普通卡主定价计划GD动感地带音乐卡主定价计划GD神州行 0 月租卡主定价计划GD神州行畅听卡主定价计划GD神州行大众卡主定价计划(18 元月租）GD神州行大众卡主定价计划(16 元月租，本地被叫GD神州行大众卡主定价计划(16 元月租，本地被叫闲时GD神州行大众卡日租卡主定价计划(0.5 元日租)lllll)l)ll附加定价计划。一般用户提供非基础功能的费率计算方式，如 GPRS 套餐、来电显示等

30、。四级类定价计划。目前在版本中没有用到。批价机制其实定价计划级别划分并不是界定死的，具体可由我们即可自行设计：设计来定，掌握平台的机制优先执行定价计划级别低的定价计划中批价策略，如先执行一级定价计划，再执行、四级等同一级别的定价计划，优先执行高优先级的定价计划，后执行优先级较低的定价计划。后面执行的批价结果（费用项）会覆盖前面执行的批价结果。定价计划级别相同、优先级也相同，那么会进行择优，选择资费比较便宜的批价结果（费用项）llll实例如何理解这套机制呢？举一个实际例子：如假设动感地带主定价计划中，市话费率是 1 毛 1 分钟、长途费率是 2 毛 1 分钟、漫游费率是 3 毛一分钟。而运营商又

31、想推出一套活动，如订购了 A 套餐则费率为：市话费是 0.5 毛一分钟、漫游费是 1 毛一分钟（注：未定义长途费）。A 定价计划的定价计划级别是。这样子如果动感地带用户 X 又参加了这套时候拨打了被叫长途 5 分钟。那么该收用户活动，订购了 A 定价计划，当 X 漫游的呢？按照上面定价计划的批价机制我们可以看到：首先执行低级别定价计划批价策略，即执行主定价计划的策略这时得出的批价结果是l2-8文档版本所有和所有 (c)技术OCS 计费原理与实现2 扫盲篇表2-4再执行高级别定价计划 A，此时得到的批价结果为（注意，此时因为没有定义长途费率，故 没有 2004 业务用量的批价结果）：l表2-5后

32、面执行的批价结果会覆盖前面的批价结果，故最终的批价结果是：l表2-6故最终会收取费用 25+100+50=175 分钱。l如果定价计划 A 和主定价计划是同一级别，而优先级比较低，跟上面的批价结果一致，如果定价计划级别和优先级都一致，那么会进行择优，取比较少的批价结果，2003业务用量取 25 分（25 和 50 比较，25 较小），2005 业务用量取 50 分（50 和 150 比较，50 较小）。2.2.5 订购：指用户拥有哪些定价计划（费率计算体系）定价计划分为两类：全局类用户订购类ll全局类的定价计划，指所有用户都默认拥有这套“费率计算体系”。文档版本所有和2-9所有 (c)技术业务

33、用量数值金额（分）2003|基本费时长300252005|长途费时长3001002004|漫游费时长30050业务用量数值金额（分）2003|基本费时长300252004|漫游费时长30050业务用量数值金额（分）2003|基本费时长300502005|长途费时长3001002004|漫游费时长300150OCS计费原理与实现2 扫盲篇而“用户订购类”定价计划，指该用户只有在订购这这个定价计划的情况下才能拥有这套费率计算体系和方式。OCS 相对于传统智能网真正体现良好可测试性的地方就在这里，局方需要推出一套新的时，可以先配制好定价计划，在进行调测的时候仅给测试用户订购上这个“定价计划”，这样就

34、影响现网的用户。其实，用户订购在真正物理数据库中实现即一个表表2-7订购表2.2.6 入帐关系：即说明消费明细应该在哪个帐户上扣帐户类型先解释帐户类型这个概念，一个用户可能有多个来存放用户的钱。类似地，在通信计费领域，我们也给用户定义了多种类型的帐户存放不同的可用于消费的“钱”，其意义跟原智能网 icharge 中 201、202、401 等帐户比较类似。如，在江门版本中我们就了（下面列举的未包含所有）：2000|资金子帐户l2001|资金子帐户l2002|测试彩玲l帐户4000|4001|4200|时间子帐户 1时间子帐户 2子帐户lll入帐再解释入帐，入帐就是根据批价完成之后的各费用项，在

35、用户的帐户上进行扣钱或加钱的动作（依据费用项的类别来看，如果费用项是消费类的费用项，则在帐户中扣钱，如果是充值或赠送类的费用项则在帐户中加钱）。入帐关系入帐关系就是定义了批价完成之后的各费用项应该入帐到那个帐户中，其先后关系是怎样的，如在版本中，呼叫的输出，在我们定义的入帐关系是：表2-82-10文档版本所有和所有 (c)技术费用项入帐帐户类型优先级1|本地通话费用项20001999用户键值键值用户 X动感地带主定价计划用户 X定价计划 AOCS 计费原理与实现2 扫盲篇优先级优先级数值越高，优先级越低。可以看得到，我们呼叫所有的消费，都只是在资金主帐户（2000）和金帐户（2001），而且都

36、是先在金帐户（2001）里面扣，如果金扣完就在主帐户（2000）中扣。这时您可能有疑问，怎么没有对求？显然不是这样，我们不是有 300 条帐户的定义呢？是不是因为没有对的需么？那是怎么实现的？这个先不说，放到后面的章节讲述，参考处理。2.2.7 模板我们把定价计划比喻成“费用计算体系包”，那么模板就是提供费用计算体系的能力承载者。我们可以把它比喻成 C 语言的功能函数：它提供一套的批价能力特性l它也有输入“参数”，根据参数不同作不同的处理。l如在版本中，呼叫的模板有：主叫流程基本费资费模板 VoiceCallingLocal，它主要进行批价；主叫流程长途费资费模板 VoiceCallingTo

37、ll，它主要是进行批价；每个呼叫所产生的基本费l每个呼叫所产生的长途费l主叫流程国内漫游资费模板 VoiceCallingRoam，它主要是游费进行批价。每个呼叫所产生的漫l模板有很好的“模块化”机制，他有三个归属条件：l子业务用量 TAGll如“主叫流程基本费资费模板 VoiceCallingLocal”它归属于“2001|呼叫”的“1 主叫子”的“2003|基本通话时长业务用量”。文档版本所有和2-11所有 (c)技术费用项入帐帐户类型优先级1|本地通话费用项200114992|漫游通话费用项200019992|漫游通话费用项200114993|长途通话费用项200019993|长途通话费

38、用项20011499OCS计费原理与实现2扫盲篇那么我们如果修改了 VoiceCallingLocal，很直观的可以看出它信或被叫等流程，这样子能保证它改动之后影响面最小。影响其他如充值、短2.2.8 策略策略就是模板的“实例化”，模板相当于函数，那么策略就相当于对“函数”调用，会给模板的各参数赋值。一个定价计划下面会挂很多策略。定价计划就是通过策略实现对模板的实例化，调用其计费能力，从而组成“费用计算体系包”。如上面“：在 CBE 侧统一理解为“定价计划”，即一套新的费用计算体系包”中提到的实例，A 套餐实现费率费率为：市话费是 0.5 毛一分钟、漫游费是 1 毛一分钟（注： 未定义长途费）

39、。该定价计划需要实现对“基本费费”和“漫游费”的批价，那么它就要对“主叫流程基本费资费模板 VoiceCallingLocal”和“主叫流程国内漫游资费模板 VoiceCallingRoam” 进行实例化。那么它下面就挂两个策略分别对这两个模板进行实例化。2.2.9/子指一类计费请求类型，如呼叫计费。、GPRS 话单计费、充值、计费子指下面的子流程，如呼叫计费下面包含主叫流程、被叫流程等子。2.3 计费流程在传统智能网中我们的计费流程：图2-1 智能网计费流程图2-12文档版本所有和所有 (c)技术策略调用模板参数策略 A主叫流程基本费资费模板VoiceCallingLocal费率参数=“5

40、分/秒”策略 B主叫流程国内漫游资费模板VoiceCallingRoam费率参数=“10 分/秒”OCS 计费原理与实现2扫盲篇而在 OCS 计费则演变成如下的流程：图2-2 OCS 计费流程图入账关系拥有的账户定购的业务用量个或N个费用项时长链表2.3.1 预处理部分呼叫流程介绍拿呼叫来说事，呼叫的计费流程是：图2-3 OCS 呼叫信令图OCPSCPCCR(Initial)CCA(Initial)复多次CCR(Update)CCA(Update)CCR(Terminate)CCA(Terminate)呼叫流程步骤如下（这一段如果看不懂可以跳过往后看）：步骤 1业务系统 SCP 在用户发起呼叫

41、后，进行接续前，向 OCS 系统CCR（Initial）消息，附带“请求通话时长”参数，告诉 OCS“通话这么长的时间”；文档版本所有和2-13所有 (c)技术可重后处理（写话单、编码等）入账（扣费、累计等）批价） （识别、批价等）预处理（、 （1号码分析等）OCS计费原理与实现2扫盲篇步骤 2 OCS 系统将“请求通话时长”赋值给“请求业务用量”，OCS 进行计费，帐户预扣， 如果帐户余额足够，则将批价的业务用量赋值给“业务用量”，如果用户余额不够扣，则根据用户余额反算出可通话的时长，赋值给“业务用量”，将“业务用量”通过 CCA(Initial)返回给 SCP，告诉 SCP“您只能用这么多

42、时长”；步骤 3 SCP 根据返回的“业务用量”进行用户进行接续、通话，当用户通话了“业务用量”的时候，是否还有必要向 OCS 继续申请通话时长。的条件是时长是否小于请求通话时长，如果小于，则表示用户的余额不够则不需要再进行申请，则掐断呼叫。否则继续向 OCSCCR(Update)，里面附带两个参数 “已经通话时长（Used-Service-Unit）”、“请求通话时长”，告诉 OCS“我已经通话 Used-Service-Unit时长，但是还想通话 Requested-Service-Unit 时长”。步骤 4OCP 把 Used-Service-Unit 赋值给“已使用业务用量”，把 Re

43、quested-Service-Unit 赋值给“请求业务用量”，“请求业务用量”和“已使用业务用量”的计费的过程是一致的， 只不过入帐的时候，“请求业务用量”消费的金额入帐到预扣金额上（见 AccountItem的 PreAmount 字段），并且会生成“业务用量”；而“已使用业务用量”入帐到帐户的余额字段上（AccountItem 的 Amount0 或 Amount0 字段），生成“业务用量”，将“业务用量”返回给 SCP；业务用量”继续进行。重复 3、4 的动作。步骤 5步骤 6SCP 返回的“如果期间用户挂断，SCPCCR（Teminate）给 OCS，附带参数“已使用通话时长”，O

44、CS 根据“已使用业务用量”进行批价入帐并返回 CCR（Teminate）结束会话。步骤 7如果在第 3 步，SCP 主动掐断呼叫，也会使用通话时长”，处理同第 6 步。CCR（Teminate）给 OCS，附带参数“已预处理机制介绍呼叫发起 CCR 消息的时候，一般带有下面的主要参数如：用户号码Subscription-Id，即计费方号码请求通话时长CC-Time计费流程类型Charge-Flow-Type（0：主叫流程1：被叫流程3：前转流程） 主叫号码Calling-Party-Address被叫号码Called-Party-Address主叫拜访地号码Calling-Vlr-Numbe

45、r 被叫拜访地号码 Called-Vlr-Numberlllllll而预处理要做的就是对这些参数（称计费要素）进行求解，获取批价入帐步骤所需要的参数变量等，如：业务用量（如：呼叫时长）、主叫拜访地/归属地区号、被叫拜访地/ 归属地区号（计费区号）、主被叫是否漫游、是否拨打网外等，这一系列变量将作为批价入帐的参数影响费用计算等。这一步跟原智能网部分的号码分析步骤的作用有一点相似，原先智能网分为两步：步骤 1通过号码分析得到主叫拜访/归属地区号（计费区号）、被叫归属/拜访地区号、呼叫类型（长途市话）等参数。2-14文档版本所有和所有 (c)技术OCS 计费原理与实现2 扫盲篇步骤 2然后再根据这些

46、参数查找计费矩阵得到 13 个 chargeclass（chargeindex）。后面的费用计算就根据每个chargeclass及duration去进行计算得出每个chargeclass所消费的金额。而在 OCS 中，其过程分为三步：步骤 1先通过号码分析之后得到跟原先智能网号码分析类似的主被叫归属地、拜访地、网络号等参数。步骤 2根据本次的计费类型得到 1N 个业务用量，根据计费消息传过来的时长（CC-Time）给业务用量赋值。步骤 3 根据业务用量、主被叫归属地、拜访地、网络号等计费要素去查找计费矩阵得到费率，再根据业务用量及其用量值计算得出每个业务用量所消费的金额。（注意：第 3 步不属

47、于预处理步骤，这里为了完整性和对比智能网放在这里讲述）计费要素这些参数是根据对外部网元输入的变量进行分析得到的，如在 Diameter 消息中，我们依据对 DCC 消息中“主叫号码 AVP”进行分析，可以获得主叫的归属地区号等。2.3.2 批价部分批价(rating)即“费用计算（calculate）”计算出此次需要费用，即根据“消费列表”（输入）算出“消费额”（输出的过程）。入帐即计算出“消费额”应该在哪些“帐户”上扣。把批价比喻成一个算法函数，该函数的输入是：业务用量列表（消费列表）计费要素集合（场景）ll输出是：费用项链表（消费额）l批价过程步骤 1步骤 2步骤 3步骤 4步骤 5步骤

48、6扫描整个系统有哪些全局定价计划（即费用计算体系）扫描该用户订购了哪些定价计划（即费用计算体系）然后按照定价计划的优先级高低，按顺序执行这些费用计算体系的资费策略和规则。通过调用规则中的计费动作函数，该动作函数最终拼装输出费用项链表。费用项链表介绍这个费用项链表其实和原先智能网 icharge 计费计算的结果类似，如原先 icharge 计费结束之后会输出：文档版本所有和2-15所有 (c)技术OCS计费原理与实现2扫盲篇表2-9换到 OCS 这一块也类似如表2-10（详细参见名词“费用项”的介绍）-结束2.3.3 入帐入帐即把批价得出的消费金额，在用户对应的帐户上扣除掉。智能网入帐处理这一个

49、动作跟原先智能网更新帐户余额动作比较类似：如我们原先定义用户基本表(_BaseTab)的 acctleft1 对应 101 帐户类型，acctleft2 对应 102 帐户类型那么对于下面这样的输出：ll表2-11我们拼装更新余额动作的 SQL 是：2-16文档版本所有和所有 (c)技术帐目帐户类型金额chargeclass110130chargeclass110240chargeclass210250业务用量费用项金额业务用量 1（基本费）1|基本费费用项30业务用量 2（长途费）2|长途费费用项40业务用量 3（漫游费）3|漫游费费用项50帐目帐户类型金额chargeclass110130

50、chargeclass110240chargeclass210250OCS 计费原理与实现2 扫盲篇update_basetab set acctleft1 = acctleft1 30, acctleft2 = acctleft2 (40 + 50)OCS 入帐处理步骤 1OCS 入帐流程而在 OCS 中入帐就 那么简单了。在 OCS 中，帐户余额就不是表中的一个字段，而是帐户表中一条 ，到底 OCS 是如何根据费用项链表中怎么把钱扣到帐户里面的呢？ 参见下面的流程：图2-4 OCS 入帐流程图入账优先级关系用户键值费用项链表步骤 2帐户介绍这个步骤介绍用户钱是怎么放的。OCS 采用了“1 个主帐户+n 个子帐户”的两层帐户模型，在用户表里面可以得到该用户的主帐户键值（即用户表 CBE_Subscriber_ext 的UserMainAcct