GPRS按时长计费模块的优化与应用
2013-08-09文英成勇刘晓峰叶军
文英，成勇，刘晓峰，叶军
（中国移动通信集团广西有限公司，南宁 530022）
1 GPRS按时长计费模块的现状
目前GPRS业务主要有3种计费模式：按流量、按时长和按内容计费。按流量计费，即按用户上网时产生的上、下行流量之和来计费。按时长计费，即按用户上网时长来计费，推出的业务主要为一些包月、包半年、包年的手机及上网卡套餐业务。按内容计费的核心是将流量按照业务区分开来，进行区分的规则即内容计费的规则。
1.1 GPRS按时长计费模块的处理机制
GPRS按时长计费模块，即TBCG（Time Based Charging Gateway）， 是 CG （Charging Gateway）与BOSS之间的“时长计费网关”系统负责采集各个CG上的CDR（Charge Detail Record）文件以及BOSS同步过来的漫游CDR文件，从这些话单文件中过滤取得“时长计费”用户的CDR记录，并对非正常下线及历史记录时间交叉、重叠的话单进行处理，最后将外理后的新CDR文件提供给BOSS系统进行计费。TBCG软件架构如图1所示，各CG对应的传输是通过FTP方式取得全网GPRS话单，再由各CG对应的处理模块统一完成时长用户订购关系的读取、时长CDR筛选、话单交叉及剔重处理等操作。
图1 TBCG模块软件架构图
1.2 GPRS按时长计费模块的处理性能
现网TBCG模块通过磁盘读取用户资料将按时长计费话单筛选出来，再进行后续的话单交叉去重处理。按此方式模块I/O消耗较大，在节假日等峰值业务量较大情况下易出现效率低下问题。同时由于TBCG是通过BOSS同步时长用户订购数据来获取用户资料，而不是直接读取BOSS侧的全量时长用户订购数据，故较容易因网络故障、同步异常等情况导致TBCG与BOSS侧订购关系不一致。
2011年春节期间时长用户数仅3.5万余户，时长话单约为180～190万条CDR/天，峰值为60条CDR/s。但受到全网GPRS用户及话量增长的影响，期间全网话单量较平时增长近2倍，日均话单量达35 000～37 000万条CDR/天，峰值达2 500条CDR/s，系统性能急剧下降而无法及时采集并筛选处理话单，出现大量话单积压从而导致时长话单处理效率低下，存在计费延迟。
2 在BOSS侧新增GPRS时长计费话单处理模块
2.1 总体思路
基于现有BOSS计费系统中GPRS话单处理流程，新增GPRS时长计费话单处理模块。在业务分析结束后，GPRS按时长计费用户的GPRS话单将由该模块按使用时间进行剔重及拆分处理，处理完后将话单传送给批价模块进行批价。该模块和计费处理流程实现松耦合，若模块存在话单积压或者模块异常不会影响到其它GPRS话单的计费正常处理。同时，该模块和计费处理流程均通过MDB获取用户资料等信息，保证了数据的一致性。系统总体框架如图2所示。
2.2 GPRS时长计费话单处理流程
新增的GPRS时长计费话单处理模块，包括异常话单处理和交叉话单处理2个子模块，分别实现过滤零流量话单和剔重时间交叉话单功能。
异常话单是指单个PDP上下文激活中存在通话时间大于0、但流量为0的话单，即有时长无流量的零流量话单，其处理原则是当正常话单之后连续出现30 min异常话单的情况，之后再出现的异常话单则不再计费。
交叉话单是指单个或多个PDP上下文激活产生的话单中时间存在重叠（交叉），其处理原则是后到话单如果与先到话单产生时间片交叉，则修改后到话单的开始时间和时长字段，避免与先到话单产生时间片交叉。
表1 2011年春节期间与平时话单量比较
图2 新增GPRS时长计费话单处理模块
3 异常话单处理场景分析
考虑用户上网行为及产生的话单情况，系统中可能出现的异常话单场景共计9个，各场景下新增模块对话单的处理情况分析如下。其中Ri表示第i条话单，i为话单到达顺序；有流量话单单独标识，无标识即为无流量话单；第i条话单的原始时长记为Di，修改后的时长记为Di’，时间戳格式为开始时间-结束时间；Tib、Tis分别为第i条话单的开始时间和结束时间，Tib’、Tis’分别为修改后第i条话单的开始时间和结束时间；时间单位均为min。
场景 1：R1（有流量）: 0～ 10，R2: 10～ 40，R3: 40～50，处理后不修改R1、R2，过滤R3。
场景 2：R1（有流量）: 0～ 10，R2: 10～ 35，R3: 35～50，处理后不修改R1、R2，修改R3时长为5。
场景 3：R1（有流量）: 0～ 10，R2: 10～ 45，R3: 45～55，处理后不修改R1，修改R2时长为30 min，过滤R3。
场景4：R1（有流量）: 0～10，R2: 5-T2s（T2s>10），处理后不修改R1，修改R2开始时间为R1的结束时间，时长为D2’= T2s-R1结束时间。其中若D2’>=30，则D2’=30； 若D2’<30，则D2’取实际差值。
场 景 5：R1: 0～ 10，R2: 10～ 40，R3: 40～T3s（T3s>40），因有流量话单一直没有到达，到达设定阈值后过滤R1、R2和R3。
场 景 6：R1: 10 ～ T1s（T1s>10），R2: T1s～ T2s（T2s>T1s>10），R3（ 有 流 量 ）: 0～ 10，过 滤R1； 若D1+D2>=30,则D3’=D3+30； 若D1+D2<30,则 D3’=D3+D1+D2。
场景 7：R1: 15～ 35，R2: 40～ 55，R3（有流量）:0～10，则R1、R2继续等后续话单。
场景8：R1: 5～ T1s（T1s>5），R2: T1s～T2s（T2s>T1s>5），R3（有流量）: 0 ～ T3s（5
场 景 9：R1: 0～ T1（T1>0），R2: 30～ T2（T2>30），R3（ 有 流 量 ）: 0～ T3（T1
4 交叉话单处理场景分析
考虑用户上网行为及产生的话单情况，系统中可能出现的交叉话单场景共计7个，各场景下话单的处理情况分析如下。其中Ri表示第i条话单，在此部分均为有流量话单，其余符号同上。
场景 1：R1: 0 ～ T1，R2: T2b ～ T2s（0 场景2：R1: T1b～T1s（0 场景3：R1: 0～T1s（T1s>0），R2: T2b～T2s（0 场景4：R1: T1b～T1s（0 场 景 5：R1: T1b ～ T1s（0 场景6：R1: T1b～T1s（0 表2 TBCG模块与GPRS时长话单计费模块处理能力比较 场 景 7：R1: T1b ～ T1s（0 2011年10月在BOSS侧新增GPRS时长话单计费模块并正式启用后，系统运行平稳。统计2011年12月1～7日的GPRS按时长计费模块的处理话单速率，得出单进程时长话单处理的平均速度为102条CDR/s。由此可计算出单进程一天的处理速度：102条CDR/s×3 600 s×24 h＝8 812 800条CDR/天，即约880万条CDR/天。在模块压力测试中，输入了5天共计270余万条时长话单，按时长模块在5 h即全部处理完毕，忙时处理速度约为155条CDR/s。 结合2012年1月春节期间话单量情况，对TBCG模块与BOSS侧GPRS时长话单计费模块处理能力进行了相关比较，如表2所示。 2011年春节期间时长话单峰值话单量达60条CDR/s，此期间TBCG模块整体性能急剧下降，累计积压达40万个话单文件。 BOSS侧新增GPRS时长话单计费模块后，日均所处理的GPRS按时长话单量约为80万条CDR/天，忙时约为8～12条CDR/s，未出现积压情况。2012年春节时长话单峰值话单量为95条CDR/s，平均约57万条CDR条/天；而目前BOSS侧GPRS按时长模块平均处理速率约102条CDR/s，在压力测试中可达155条CDR/s，平均每天可达880万条CDR/天。从订购数据及用户相应话单记录来看，未出现订购数据不一致问题。从采集、解码及其它环节日志统计来看，未出现积压情况，平稳支撑了春节峰值业务量增长。 通过对现网GPRS按时长计费模块的性能及处理瓶颈的分析，在原有话单处理流程基础上，新增了GPRS时长计费话单处理模块，实现对异常和交叉话单的处理。通过分析和比较优化前后系统性能情况，上线后及2012年春节期间的统计数据表明优化后模块处理性能提升显著，有力地支撑了业务发展需求，保证了模块间数据一致性，确保BOSS平稳运行。 [1] 马莉. 3G数据业务内容计费模式探讨[D]. 北京：北京邮电大学，2009. [2] 王孟杰. 新一代互联网业务计费功能的研究与实现[J]. 北京：北京邮电大学学报，2009. [3] 王伊霖，周峰，刁艳蓉. 移动互联网融合业务的内容计费[J].电信科学，2009. [4] 叶军，周佳佳，魏立勤. 话单计费方法及装置[P]. 专利号:201010102796，2010. [5] 广西移动. TBCG系统维护手册[Z]. 2010. [6] 广西移动. OpenBillingNG操作手册-TBCG模块.doc[Z]. 2011.
5 优化前后处理性能比较
6 结束语
