王大头

好吧，最近我又开发犯懒了，本来准备31号晚上月结的时候写这篇文章，结果拖了好几天，我快成了拖拉机了。言归正传，开始介绍批价中的一些概念。

 

计费量：所谓计费量，就是话单中需要进行计费的数量，貌似这么说很抽象，举几个例子：语音业务，计费量一般是通话时长；短信业务，计费量一般默认为“1”，即每条话单即是一个计费量；GPRS业务说起来蛮复杂，计费量一般是流量，流量又要分为忙时流量、闲时流量，还分为上行流量、下行流量，分解的结果就是忙时上行、忙时下行、闲时上行、闲时下行四个流量，另外GPRS业务还有按时长计费的应用，因此GPRS业务的计费量也可以是时长。所以计费量不是一个数值，也不是一组数值，而是多组数值。最近的一个长话单的项目把语音业务的计费量又搞乱了，后续再详细说。

 

费率：费率就是计费量的单价，基础费率就是费用/计费量单位，当然还有多段费率之类的，其本质也是由多个基础费率组合而来的。而优惠的本质也是费率，只不过是零费率而已。

 

费用：费用就是按照计费量和费率计算出来的最终的数值，单个话单中可能包含多个费用。比如语音业务中包含基本费、长途费、信息费等；呼转业务，长途费还包含第一段长途费和第二段长途费；梦网业务一般会包含按条点播费用和包月费用。

 

累积量：累积量包括计费量累积量和费用累积量两类。比如计费量的累积量，如果存在对用户优惠一定量计费量的情况下，需要将优惠的汇总信息记录下来，产生的记录就是累积量，累积量一般会包含：计费对象、开始时间、结束时间、累积量标识、累积量数值等信息。累积量的操作一般需要加锁，但是如果能够在前续流程中，将特定计费对象的所有话单都分配给某一特定计费实例，也就无需在使用前加锁，这样可以提升效率，一般来说个人用户的话单，会在前续流程中被路由到一个确定的计费实例，因此不加锁，而集团用户的话单，分布在多个计费实例中，对计费量的操作，都需加锁后进行。

 

最近半年对于计费量考虑了很多，现在我们现有体系对计费量考虑的太少，如多优惠叠加，不同费用的优惠叠加，长话单的计费量取整等等都会牵扯到计费量的耗减。

 

多优惠叠加：分析一下场景，如用户存在两个GPRS套餐。A套餐，优惠10M，剩余10K可优惠；B套餐，优惠20M，剩余20K可优惠。如果再来一条100K流量的话单，需要将可优惠的30K优惠流量占用之后，再计算超出优惠流量的费用。优惠在我们程序实现中概念也不是很统一，虽然本质上都是零费率而已。因此提取所有优惠，只能是通过真实的算费来实现，而不是在算费之前就可以将优惠提取出来。在这种模式下只能做计费量的耗减，别无他法。即首先占用A套餐的10K可优惠流量，再占用B套餐的20K优惠流量，剩余70K流量，使用A套餐和B套餐分别算费，取费用最优者作为结果。

 

不同费用的优惠叠加：说起来比多优惠叠加更抽象，还是继续举例：两个语音套餐，套餐A可对基本费优惠，套餐B可对长途费优惠，而套餐A和套餐B计费量累积并非同步的。如A套餐还可优惠3分钟基本费，B套餐可优惠1分钟长途费；如果有一个5分钟的语音通话，应该怎么算费？结果就是基本费免3分钟，2分钟参与计费；长途费免1分钟，4分钟参与计费。说道这里，计费量就已经分裂了，不能是单独的一个数值了，而应该每个输出的费用都要对应自己独有的计费量。

 

长话单的计费量取整：背景是这样，集团公司要求对超长截断话单（一般通话时间超长，一次通话会被截断成15分钟或者30分钟的子话单）不进行合并，有批价对每条子话单进行批价，但是汇总后的总费用不能大于将话单合并后的按一次通话计算的费用。这里就会出现一个对时长取整的过程。而时长取整，也会导致计费量的分裂。如一次通话被拆分为61秒和59秒两个子话单，如果这次通话是长途通话，61秒的话单会被计算2分钟基本费和66秒长途费，那么第二条59秒的话单，需要计费的基本费时长为0秒，需要计费的长途费时长是54秒；如果按照60秒或者6秒取整都会有问题，统一按照60秒取整，会导致54秒的长途费无法收取，按6秒取整，会导致多收一分钟基本费。因此最终的解决方案就是要用60秒对基本费时长取整，6秒对长途费时长取整，而这里的60秒/6秒是根据上条话单的计算结果记录下来的。

 

整个批价算费，无非就是condition->rule->result这么个过程，所谓condition就是一系列的条件，使用话单进行匹配，匹配到具体的规则（rule），按照规则计算结果（result）。在MDB应用到批价中以后，IPC、FILE I/O已经不是批价最耗时过程了，反倒匹配condition占到了批价一半的运算时间……，这也是之前我用caliper分析才看到的，对于这个结果很是吃惊……

 

下一篇讲讲批价的功能框架。

      剔重有很多可选的策略，分为两类：库内剔重、库外剔重。所谓的库就是数据库，比如oracle。

      库内剔重一般做法就是建一系列表，使用唯一索引或者主键进行唯一性的判定。这种策略最大的优点就是开发比较容易，因为很多工作交给数据库做了；缺点非常明显，浪费空间，效率低下。因为数据库中表数据和索引数据要占用双份空间，就算表数据只有关键字段，也要浪费一倍的空间，因为写双份数据，因此效率也就要低一倍。

      库外剔重相对库内剔重，主体思路就是省去写表数据的动作，只记录索引数据，这样下来空间节约了，效率也提升了。而缺点也很明显，就是开发成本会比库内剔重要高很多。至于索引文件该怎么写，怎么判定通话记录的唯一性，实现方式比较多。这里就不详细写了。

 

 

      内部数据格式可选策略分为两类：ASCII、BINARY两种。其中ASCII又可分为定长、变长。BINARY实现起来很麻烦，也不容易查看。

      定长ASCII策略，这种方式在数据分析的过程中效率最高，因为要取的数据，能够直接使用指针加偏移量。话单中的字段是由字段在话单中的绝对偏移量确定的。话单长度和字段数都是确定的。当然可以为了便于扩展先预留一些空间便于扩展，但是总体来说还是不便于扩展的。

      变长ASCII策略，和定长ASCII比较来看，分析的效率低一些，但是能够节约一些空间，尤其在多种网元设备统一的情况下。话单中的字段是由字段在话单中的绝对序号决定的。因此在一定时期内，要求字段数量要固定，也可以预留部分序号便于扩展。

 

      以上两种方案，在3G时代对于业务的支撑存在更大的劣势，比如GPRS的分组数据，一次通话过程中，使用了多个业务，对于这种话单中需要支撑GROUP类型的时候，就很难搞。

 

      二进制策略，一般来说语音交换机的话单格式采用ASN.1格式，其本质就是TLV，也就是TAG LENGTH VALUE。这样做的好处就是便于扩展，字段数量可以不固定，长度也不固定，而ASN.1实现起来难度也较大，一种精简版的ASN.1是最好的选择。而这种方案劣势也很明显，就是分析话单的过程会比较低效，也许会是定长ASCII策略的1/5-1/10左右的效率。第二个劣势就是不便于人查看，必须有充足的工具支撑。第三个劣势，TL（TAG LENGTH）会消耗一定的空间，也许不会比ASCII定长策略省空间，但是只是相对的，如果想好好压缩空间使用，还是有很大的余地的，比如把数字压缩为4bit等等做法，只不过效率会进一步下降。

 

      还有很多其他可选的方案，如XML，但是XML太浪费空间了而且解析效率低下，虽然很易于扩展；在这个行业，就连google的protocol buffer都过于浪费空间了。

 

下一篇开始写批价。

首先说采集模块，采集在整个计费系统里面基本是最简单的模块了，采集大概分为三类：脱机采集、联机采集、在线采集。（貌似最近三用的很多，嘿嘿）

 

一、脱机采集

很久很久以前都是这么个模式，其实呢，就是人拿着硬盘直接到网元上面去拷贝，属于稍有技术含量的力工，这里就不多扯了。

 

二、联机采集

也是现在应用最多的采集模式了，一般就是在网元和计费系统之间建立一个链路，计费系统的采集程序到网元上面获取文件，现在FTP协议用的最多，貌似还有一些X.25或者FTAM之类的协议，不过我没见过。各个公司的采集产品应该差距不大，主要是因为采集要完成的功能很简单，总结以下，采集需要的功能：

1、采集文件

2、重命名

3、解压缩

4、文件名剔重

 

采集文件，这是最基础的功能，如果是ftp协议的话，无非是ftp host->use user passwd->get remote_file local_file->bye这么个过程。

重命名，重命名主要是为了保持文件名在系统内部容易识别，另外也是为了避免重复，尤其同一个厂商的多台网元的情况下。

解压缩，有些网元下发话单的量比较大，需要在网元侧进行压缩，计费系统采集后进行解压缩，主要是为了降低传输压力。

文件名剔重，这个其实是可有可无的功能，成功采集文件之后一般会有一个可选的操作，比如：删除远程文件、重命名远程文件、或者不做任何操作，其实文件名剔重功能仅仅在不做任何操作的这种情况下才会用到，如果从采集程序列表的效率来考虑，最好还是采取删除远程文件或者重命名远程文件（也可挪到其他目录）这种操作。

 

三、在线采集

在线采集是NGBOSS规范新划入采集功能域的，直白点，就是在用户拨打电话的同时，由网元发起鉴权消息，计费系统获取鉴权消息，生成的服务使用记录，这个模块计划在智能网关、在线计费的文章里面详细说。

 

 

再说说预处理模块，预处理是一个很重要的模块，它起到的作用是隔离外部系统变更对内部系统的冲击，预处理将各种外部数据转换成内部数据格式，为后续系统降低开发难度起到了决定性的作用。一般预处理模块至少有以下几种功能：

1、数据格式化输出

2、格式及字段检错

3、路由分发

 

为啥我想了三个就再也想不出来了呢。。。。

数据格式化输出，预处理最核心的功能，预处理将外部格式的话单转为内部格式，外部格式从大类分为两类：ASCII和二进制，ASCII又可以分为定长和变长，二进制也有定长变长之分，还有BCD、EBCD、ASN.1等等编码方式，如果没有预处理模块，而由计费核心模块识别这么多的格式，那计费核心模块需要经常变化，变化多了故障就难免了。

格式及字段检错，比如语音交换机下发的话单里面，包含了很多无用的话单，短信话单、智能网语音话单、零时长话单等等，还有一些字段错误的，如时间值错误、交换机代码无效等等。

路由分发，一般来说，计费系统的核心处理模块并非只有一个实例，也就需要根据每个核心模块负责的用户群对话单进行路由分发，或者根据用户属性进行分发，本省用户、外省来访用户、国际来访用户分发到不同的核心处理实例。

 

关于系统设计中隐含的一些智慧，总结一下：

1、如果系统外部的环境经常变化，最好有一个模块起到隔离内外的作用；而不是将复杂多变的外部环境直接交给核心模块处理。

2、数据流，也就是生产者——消费者模式，前端模块的输出作为后端模块的输入，每个模块负责独有的功能。

 

 

下篇文章准备讲讲剔重模块，还有内部数据结构的一些思考。

 

分析一个系统，本人习惯使用IOL的角度，即输入（input）、输出（output）、逻辑（logic）。

一般情况下，把纯输入、依据统称输入；纯输出、统计（累计）数据统称输出；中间的业务逻辑或者技术逻辑统称逻辑。

 

计费系统的输入大约分为三类：
1、服务使用记录（或者被称为：话单|原始话单|原始通话记录)
2、服务订购记录（梦网订购关系）
3、套餐订购信息（套餐、亲情号码、BOSS集团、VPMN集团等）

 

计费系统输出大约也可分为三类：
1、带费用的服务使用记录（批价后的详单，提供查询；传送给经营分析系统，出报表等）
2、增量账单（根据带费用的服务使用记录，即批价后的详单汇总的账单数据，提供给帐务处理系统）
3、优惠量信息（优惠量信息提供给用户查询）

 

那么计费系统内部，至少要做这么几件事情：

1、验证服务使用记录（话单）的有效性，如：短信是否发送成功，话单是否重复等。

2、计算话单的费用，要考虑优惠的情况。

3、话单优惠记录提供查询。

4、算费后的话单提供查询。

5、话单经过整理后传送给帐务功能域，对用户收费，并且进行停机等操作。

 

为了完成这些工作，计费系统内部一般分为以下几个模块：

1、采集，从各个网元获取服务使用记录（话单）。

2、预处理，把外部格式的服务使用记录（话单）转换成内部格式。

3、剔重，剔除重复的服务使用记录（话单）。

4、批价，计算话单的费用。

5、详单管理，保存提供给用户查询的服务使用记录（话单或者称为详单）。

 

为了适应现有超大数据量及效率要求，内存数据库成为计费系统必选模块。

在梦网业务内容计费驱动下还有一个新增的模块，即梦网包月计算模块。

 

计费系统包含了：采集、预处理、剔重、批价、详单管理、梦网包月计算、内存数据库等模块。当然还有一些周边模块，不作为核心也就不多介绍。

 

下一篇将主要介绍采集、预处理两个模块。

 

要了解计费系统，首先要看计费系统在整个电信网中扮演什么样的角色、发挥什么样的作用、归属于那个上级系统。

总体来看：电信网->业务支撑系统->二级业务支撑系统->BOSS系统->计费系统；计费系统按级来分只能算是一个五级系统。是电信网中很小的一个组件系统。

 

首先了解一下各个系统的概念：

 

电信网从总体来看，可以分成两部分：即业务承载系统和运行支撑系统。终端、链路、交换设备这些都是属于业务承载系统，信令系统、通信协议不单单属于业务承载系统，运行支撑系统也会使用到信令和通信协议，而运行支撑系统，在CM的体系中，就是所谓的中国移动业务支撑系统（BOSS）。其实说起来BOSS系统这个概念容易被混淆，BOSS可以指中国移动的业务支撑整个体系，也可以单指二级（升级）业务支撑系统中的BOSS子系统。本文中没有特殊指出的情况，BOSS特指二级业务支撑系统中的BOSS子系统。

 

业务承载网（语音、GPRS）示意图

 

业务支撑网结构

 

NGBOSS结构

 

BOSS系统组成

 

计费系统在电信网中的位置

 

看了上面几个图，基本就能在整个电信网中定位到计费系统的位置了。从总体来看，他的确很渺小，但是作用并不小。接下来简单说一下计费系统做什么。