当前形势下国际漫游资费批价系统设计思路的研究

王敏丽 石靖宁 李 微

（中国移动通信集团信息技术有限公司，广东 深圳 518048）

1 引言

移动通信技术持续演进，新业务和新的结算模式不断涌现，未来Billing and Charging Evolution（BCE）将取代Transferred Account Procedures（TAP），成为国际漫游结算的主流机制。但正如移动通信网络技术的演进是一个逐步替代的过程，TAP在相当长的时间内无法被BCE替代是运营商的普遍共识，国际漫游的BCE和TAP结算机制势必长期共存。

在当前形势下，继续沿用TAP机制满足新技术场景、BCE结算机制下对结算资费模式的新需求，以及随着5G、物联网技术的普及，国际漫游的话单量将可能大幅度增长，都将给国际漫游结算批价系统的建设带来新的考验。

2 国际漫游资费批价系统实现的难点分析

国际漫游TAP和BCE两种结算机制共存，对国际漫游资费批价系统至少有两方面的影响：一方面，通过升级改造TAP话单支撑物联网、5G等新业务，TAP话单就会变得更加复杂；另一方面，国际漫游的部分业务的结算通过BCE机制完成，BCE下的资费模式更加灵活多样，对系统的批价能力的要求更高。当前，国际漫游资费批价系统实现所面临的难点具体分析如下：

2.1 TAP话单资费节点复杂

2.1.1 话单资费节点多

TAP文件依据ASN.1解码，资费相关节点集中在Charge Information节点组下的21个节点中，如运营商开通CAMEL业务，CAMEL Service Used节点组下也存在5个相关资费节点。此外，IMSI、主被叫号码、拨号号码、APN、通话开始时间、通话时长、OSI等节点也可能属于资费相关节点。而且话单树形结构中节点存在必填（M），重复出现（R），选填（O），在某些条件下出现（C）等不确定因素，也给话单依据节点填值匹配资费规则带来难度。

2.1.2 随着业务发展，节点填值扩展造成属性变化

随着新业务的发展，TAP话单的节点填值需要不断扩充，在不修改TAP话单节点组结构的情况下，给原有节点赋予新的填值是TAP机制支撑新业务的主要手段。比如，VoLTE话单基于GPRS流量话单承载，为识别VoLTE业务，TD.58规定根据CTL2和APN节点赋予新的填值区分；5G因为目前采用NSA架构，话单通过GPRS承载，所以在流量话单里暂时无法识别，而物联网（包括M2M/NB-IOT等）等其他话单类型则可能通过IMSI、APN等区分。

通过对TAP话单节点的赋值，改造量相对较小，可以快速支撑新业务的上线，但增加了批价系统去匹配业务以及话单类型与资费规则的复杂度，直接影响到了批价结果的准确性和效率。

2.2 资费规则复杂且模式多样

2.2.1 资费规则复杂

当前，国际漫游结算资费规则复杂，全球1000余家运营商其协议资费因国情不同，资费种类多、收费名目多，方式各异。如资费单元按线性、初始后续不同，Airtime和Toll Charge资费单元不同等；资费时段存在多个忙闲时区间；税率分为固定税率、固定税值、区间税率、可变税率等；流量分切割话单、分段资费、上下行分别收费等。再者，运营商除了在AA.14或RAEX IOT中发布了标准资费的协议外，和部分漫游伙伴又存在着优惠资费SIOT，基础资费和协议资费交叉共存。

2.2.1 资费模式灵活多样

5G网络的技术和应用场景及其商业模式分别为国际漫游的结算模式的发展提供了条件和推动力，未来国际漫游的结算模式将会更加多样化。套餐资费、阶梯计费等累计用量的模式将逐步取代当前的单价模式，成为5G国际漫游主要的结算模式；基于流量、速率、时延、连接次数或连接设备等多量纲、多层次的5G国际漫游结算模式也将逐渐成为趋势；而且，凭借BCE结算机制，资费模式将更加灵活，比如，结算周期可以按日、周、月或年等灵活进行；参与结算的对象既可以是漫游的个人用户，也可以是连接设备；既可以对全体漫游用户实行统一的资费模式，也可以针对细分群体制定相应的资费模式等。

2.3 系统处理要求高

随着4/5G的演进以及M2M、NB-IOT等技术在通信领域的应用，国际漫游话单量尤其是流量话单呈快速增长态势，例如，香港某运营商自2016年至2021年话单量增长近5倍。同时部分运营商提出了更高的话单回传时限要求，如湾区共享套餐要求出访漫游业务实时批价，VPMN话单需要在20分钟内完成包括资费校验和批价等处理下发给HPMN。国际漫游话单量大幅度的增长，极大影响着批价系统的处理能力。

3 设计思路建议

通过上文对国际漫游资费批价系统实现所面临的难点的具体分析，国际漫游资费批价系统的设计思路有以下4点建议：

3.1 统一资费规则参数，易于维护

运营商资费规则虽然复杂，但是在参数方面存在共性，可大致分类为公共参数、话单节点参数、资费协议参数、费用参数等。依据不同的参数类别进行前台公参表和后台数据库表字段设计，可以得到类别统一的资费维护数据库表。虽一套资费分不同表配置，但各表之间也存在公共参数，方便配置人员理解和维护，降低了程序识别资费规则的难度。例如，依据运营商在资费制定时，优惠资费和批价资费基于普通语音、短信和流量话单，对于短号号码、海事卫星等特殊号码不存在优惠资费或者批价，所以将普通语音和短号、海事卫星进行拆分，分表维护。

3.2 流程扁平化，减少程序黑盒

图1 资费场景参数归类图

资费规则引擎虽然具备场景丰富、匹配功能强大等优点，但存在功能复杂、流程冗长、维护难度大、可视化程度低、配置人员学习成本高等问题。复杂的系统导致操作流程牵涉人员角色多、配置流转环节多、上线流程长、资费匹配错误溯源难度大等问题，无法满足现有资费维护需求。

因此，需摒弃原有庞大复杂的规则引擎实现方式，数千套资费协议、数十万条资费规则，要求流程简洁、扁平、透明。因此，通过前台界面公参维护，后台数据库表通过内存数据库存储，实时刷新，实现一键汇聚导入导出功能，省掉资费包、规则文件配置等人工操作难度大、易错等流程，成为更优选择。

图2 资费规则前后台更新逻辑图

具体前台公参表和后台规则数据库同步逻辑可以设计为前后台定时刷新方式。当前台配置界面规则记录变更后，系统与现有配置数据按关键字进行生、失效时间的交叉判断与规则拆分，对物理库进行增删改操作，同时将增删改的数据的主键信息发送到消息中间件。内存库对比刷新应用，从消息中间件获取刷新主键，将物理库数据刷新至内存库。内存库对比刷新应用定时对内存库与物理库数据进行对比，如发现差异以物理库为准进行数据刷新。

3.3 预留节点，灵活支撑新业务场景

面对未知的新业务和技术场景以及有限的已知的TAP节点，可行的建设思路是扩展系统中资费相关节点，在资费表中增加可变字段，支持扩展TAP文件常用的节点组信息，进行灵活配置。例如预留OSI、Cell Id、IMEI、Bearer Service Code等40余个节点，同时，支持字段填值前缀、后缀、区间等灵活匹配方式，节点填值可识别、可配置，以便灵活支撑后续新业务，实现最少改动量。

设计前台展示字段和数据库表字段，同时考虑到话单通常是基于数个节点填值组合判断匹配资费规则，可以在相关界面增加节点名称+节点填值字段组，字段组数量依据语音、流量、短信等具体的话单类型而定，通常2～3个可变节点组即可满足需求。

3.4 引入分布式内存数据库，提升系统处理性能

为满足亿级话单的实时资费校验与批价需求，可以应用分布式内存数据库存放资费校验与批价业务规则，供后台资费校验程序直接使用。关系型数据库存放费校验与批价前台配置数据。HDFS共享文件系统，存放资费校验与批价处理前和处理后的话单文件。

系统架构设计中外部接口层负载分发接口负责与预处理的Socket链接，并将接收到的预处理消息通过轮询的方式以Dubbo协议分发给资费校验接口。前台配置接口负责对资费校验前台配置管理信息的处理，如配置规则的生、失效规则。处理层：由资费校验与批价负责实际的业务处理；由内存库对比刷新应用定时将内存库与物理库数据进行对比。数据访问层则统一封装数据访问组件，可分为数据库中间件访问组件、内存库查询刷新组件、HDFS读写组件。

图3 系统架构设计思路图

采用分布式架构设计，要求主体节点资源具备良好的扩展性。具体使用Redis还是MDB则依据具体的应用场景而定，如果需要缓存的数据只是简单的结构时，一般采用MDB，它也足够稳定可靠。如果涉及到存储、排序等一系列复杂的操作时，则建议选择Redis。

4 结语

本设计思路满足了国际漫游复杂结算资费的批价需求，可供拥有数十万级资费规则和百亿级业务量的结算系统进行参考。鉴于未来BCE和TAP将长期共存，如CS电路域用TAP结算、PS分组域用BCE结算等，运营商和清算中心应积极跟进BCE标准的演进进程，尽早完成国际漫游资费批价系统相关功能的建设。