纪元软件工程杜孝平软件学院
ThedesignandimplementationofTelecom’integrationbillingsystemADissertationSubmittedfortheDegreeofMaster
Candidate：JiYuanSupervisor：Pro.DuXiaoPingSchoolofSoftwareBeihangUniversity，BeijingChina中图分类号：TP3论文编号：10006GS1221C53硕士学位论文电信运营融合计费系统的设计与实现
作者姓名指导教师姓名学科专业学习时间自论文提交日期学位授予单位
纪元杜孝平软件工程2012年
9月10日
申请学位级别职
称
工程硕士副教授移动云计算
2014年12月12日2014年12月12日
年
月
日
研究方向起至论文答辩日期学位授予日期
2014年11月25日北京航空航天大学
关于学位论文的独创性声明
本人郑重声明：所呈交的论文是本人在指导教师的指导下独立进行研究工作所取得的成果，论文中有关的数据和资料是实事求是的。尽我所知，除文中加以标注的内容和致谢外，本论文不包含其他人已经撰写或发表的研究成果，也不包含本人或他人为获得北京航空航天大学或其它的教育机构的学历或学位证书而使用过的材料。并且与我一同工作的同志对研究所做出的任何贡献均已在论文中作出明确的说明。
若有不实之处，本人愿意承担相关法律责任。
学位论文作者签名：日期：年月日
学位论文使用授权书
本人完全同意北京航空航天大学有权使用本学位论文（包括但不限于其电子版和印刷版），使用方式包括但不局限于：保留学位论文，按规定向国家有关部门（机构）送交学位论文，以学术交流为目的赠送和交换学位论文，允许学位论文被查阅、借阅和复印，将学位论文的全部或部分内容编入有关数据库进行检索，采用影印、缩印或其他复制手段保存学位论文。保密学位论文在解密后的使用授权同上。
学位论文作者签名：指导教师签名：
日期：日期：
年年
月月
日日
摘要
目前，虚拟运营商都在试图维持现有客户关系的同时不断推出新的特色业务。以往旧式的计费系统不能再满足各种增值业务的要求，因此虚拟运营商需要抛弃以往预付费和后付费分离，业务单一的旧式计费系统而建立一个功能更加完善的融合计费系统。让新一代的融合计费系统可以实现以下目标：具有灵活的付款方式，实现计费全业务的融合，能够快速的推出新型增值业务，并同时完成各类新型业务的迅速部署，在实现降低运营成本的同时还能有效处理计费过程中遇到的复杂性问题。
本论文主要论述支撑虚拟运营商庞大增值业务的融合计费系统，融合计费系统的设计主要为支持全业务的融合，既全业务融合计费。并支持多种采集方式和计费方式的融合，比如可以实现在线采集和离线采集两种模式的综合采集，可以实现离线准实时计费、离线计费和在线实时计费方式多种计费方式的计费系统，本论文将并分析讨论并给出本系统的最优解决方案。
本系统主要采用离线采集的方式采集原始话单，既通过FTP协议采集联通侧给定的话单，并送入计费子系统，其中计费是依据计费资源、产品资费、用户资料信息实现个人客户、家庭客户和集团客户跨地域、跨业务等的计费过程。计费采用离线计费的模式，既计费机制不受计费信息的实时影响。计费完成后再进行详单的处理和固定费用的计算，最后生成用户的实时账单，并且对月账单按规定同步到账务管理。
本系统以B/S（BrowserandServer）架构实现的，运用C++语言设计程序，结合Oracle数据库搭建系统，运用Lua脚本实现编解码和特色业务功能的扩充。最终实现了融合计费系统的统一和全业务的融合，并支持计费功能和特色业务的捆绑结合。本论文对系统进行了详细的需求分析、概要设计和详细设计，并在最后给出相应的测试方法。系统不仅能涵盖运营商计费系统所有的功能，而且实现了系统的多业务融合和实时更新，同时可以保证主机系统和网络侧系统在不影响生产环境运行的情况下进行扩容。
关键词：虚拟运营商，融合，全业务，离线采集，离线计费IAbstract
Currently,virtualoperatorsaretryingtomaintaintheexistingrelationshipswithcustomerswhilecontinuingtointroducenewfeaturesbusiness.theoldbillingsystemcannolongermeettherequirementsofvariousvalue-addedservices.Therefore,virtualoperatorsneedestablishamoreperfectconvergentbillingsystemandabandonlegacybillingsystemwithprepaidandpostpaidseparationandsinglebusiness.Thenextgenerationconvergentbillingsystemcanachievethefollowingobjectives:owingflexiblepaymentoptionsandfull-serviceintegration.Itcouldcompletetherapiddeploymentofnewtypesofbusinesswhilequicklyintroducingnewvalue-addedservices.
Thispaperdiscussestheconvergentbillingsystemwhichsupportthevalue-addedservicesofvirtualoperators.Convergentbillingsystemdesignedprimarilytosupportthewholebusiness,theintegrationofthewholeofthenetwork,namelythewholenetworkserviceconvergencebilling.Itsupportsavarietyofcollectionmethodsandbillingintegration.
ThesystemmainlycollectsbillsbyUnicomsideandsentthemtothebillingsubsystemthroughSFTPprotocol.Thebillingistheprocesswhichisbasedbillingresources,goodstariffs,userprofileinformationtoachieveindividualcustomers,residentialcustomersandcorporateclientscross-regional,cross-business,etc..Chargingisusingofflinechargingmodewhichreal-timebillingmechanismwillnotaffectbillinginformation.
ThissystemachievedbyB/S(BrowserandServer)architecture,designedtheprogramsbyusingC++language,buildedsystemcombinedwiththeOracledatabase,expandedfeaturesbusinessfunctionsbyusingLuascripting.Anditultimatelyachievedtheintegrationofbillingsystemandtheintegrationoffullservice.Itsupportstheintegrationofthebillingfunctionsandfeaturesservices.Therearedetailedrequirementsanalysis,preliminarydesignanddetaileddesigninthethesis.Whileitensure
thehostsystemand
networksideofthesystemcanbeexpandedWithoutaffectingtheproductionenvironmentrunning.
Keywords:virtualoperators,integration,fullservice,offlinecollection,offlinebillingII目录第一章绪论..............................................................................................................................1
1.1研究背景及意义..........................................................................................................1
1.1.1课题背景..............................................................................................................................11.1.2课题意义..............................................................................................................................21.2国内外发展现状对比分析..........................................................................................2
1.2.1国外发展现状......................................................................................................................21.2.2国内发展现状......................................................................................................................31.2.3对比分析..............................................................................................................................31.3研究目标和研究内容..................................................................................................4
1.3.1研究目标..............................................................................................................................41.3.2研究内容..............................................................................................................................41.4论文组织安排..............................................................................................................51.5本章小结......................................................................................................................5第二章相关技术介绍..............................................................................................................6
2.1Oracle数据库技术.....................................................................................................62.2Lua介绍.....................................................................................................................8
2.2.1Lua介绍..............................................................................................................................82.2.2Lua与其他语言的对比......................................................................................................92.3面向对象技术...........................................................................................................102.4授权访问管理技术...................................................................................................102.5本章小结...................................................................................................................11第三章系统需求分析............................................................................................................12
3.1需求概述...................................................................................................................123.2产品功能需求...........................................................................................................12
3.2.1运行框架...........................................................................................................................123.2.2综合采集...........................................................................................................................153.2.3计费...................................................................................................................................163.3业务功能需求...........................................................................................................203.4需求难点分析...........................................................................................................203.5本章小结...................................................................................................................20第四章系统概要设计方案....................................................................................................21
III4.1系统设计概述...........................................................................................................214.2系统设计原则...........................................................................................................214.3融合计费系统的体系结构.......................................................................................234.4计费系统与其它关联系统之间的关系....................................................................254.5数据库设计................................................................................................................27
4.5.1分表规则...........................................................................................................................274.5.2数据库处理能力的软件解决方案...................................................................................304.6技术关键点...............................................................................................................30
4.6.1查重技术...........................................................................................................................304.6.2查重机制...........................................................................................................................314.6.3查重算法...........................................................................................................................314.6.4基于键树索引计费系统查重设计...................................................................................314.6.5键树索引技术在计费系统中的实现...............................................................................324.7系统环境...................................................................................................................334.8本章小结...................................................................................................................35第五章系统详细设计............................................................................................................36
5.1详细设计概述...........................................................................................................365.2主要功能模块设计...................................................................................................37
5.2.1离线采集...........................................................................................................................375.2.2解码功能模块...................................................................................................................395.2.3业务分析功能模块...........................................................................................................415.2.5查重模块...........................................................................................................................445.2.5批价功能模块...................................................................................................................455.2.5分发入库功能模块...........................................................................................................485.2.6错单回收功能模块...........................................................................................................515.3本章小结...................................................................................................................53第六章系统测试....................................................................................................................54
6.1系统测试概述...........................................................................................................546.2场景测试...................................................................................................................54
6.2.1测试前准备.......................................................................................................................546.2.2用户订购的套餐...............................................................................................................546.2.3构建话单...........................................................................................................................546.2.4测试步骤...........................................................................................................................55IV6.2.5测试结果...........................................................................................................................556.3全业务测试...............................................................................................................57
6.3.1功能描述...........................................................................................................................576.3.2测试用例...........................................................................................................................576.2.3测试条件...........................................................................................................................586.2.4测试步骤...........................................................................................................................586.2.5测试结果...........................................................................................................................586.4本章小结....................................................................................................................59总结和展望..............................................................................................................................60参考文献..................................................................................................................................61致谢......................................................................................................................................63
V北京航空航天大学硕士学位论文第一章绪论
1.1研究背景及意义
1.1.1课题背景
面对着逐步开放、百花争鸣的电信业务，传统的以国家垄断为特色的电信业正遭受越来越大的冲击。外部以即时通信系统为主的OTT应用（通过互联网向用户提供各种应用服务）不断侵蚀传统运营商基本业务，在这种背景下三大运营商与更加专业的企业合作运营，将大量的功能型业务和增值业务转售给企业，而自己则加强核心网络建设与维护。如此一来传统电信运营商既能高效率的完成市场运营又能降低成本，同时也保持了三大运营商的核心市场竞争力。
工信部在2013年底和2014年初先后向迪信通、苏宁、阿里巴巴、鹏博士等共二十多家民营企业颁发了虚拟运营商牌照。所谓虚拟运营商，即通过租用三大运营商的电信基础设施，并对电信提供的服务进行二次开发和深度加工，树立以自己的品牌为特点的新型电信运营商户。换言之虚拟运营商自身没有电信网络资源，而只提供增值服务的内容。面对业务发展的压力，传统的经营模式正在经受新环境的挑战，同时对电信运营计费系统提出了更高的要求。而虚拟运营商需要成熟的电信运营支撑系统(BusinessOperationSupportSystem，简称BOSS)的支持，融合的计费系统是其核心。
由于用户对于电信业务质量和特色服务的要求越来越高，无月租、无套餐、流量不清零，语音短信阶梯收费等特色业务的涌现使的虚拟运营商为越来越多的用户所接受。然而旧的计费系统阻碍和限制了业务的发展，主要体现在旧的计费系统功能简单，以核算资费、记录账务和收取资费等简单功能实现。预付费、后付费分立并且业务模式单一，早期的电信业务只有语音、短信、流量并对应单一的批价引擎，采用单一的客户管理数据库等。因此搭建一个功能更加完善，实现预付费和后付费的融合，综合多种采集方式和计费模式，实现全业务融合并支持统一批价，支持虚拟运营商更加多的特色业务的融合计费系统已经迫不及待。
1第一章绪论1.1.2课题意义
目前，所有的虚拟运营商都在试图在维持现有的客户关系的同时不断推出新的特色业务。以往旧式的计费系统不能再满足各种增值业务的要求，因此虚拟运营商需要抛弃以往预付费和后付费分离的旧式计费系统而建立一个功能更加完善的融合计费系统。让新一代的融合计费系统可以实现以下目标：具有灵活的付款方式，实现计费全业务的融合，能够快速的推出新型增值业务，并同时完成各类新型业务的迅速部署，在实现降低运营成本的同时还能有效处理计费过程中遇到的复杂性问题。
论文内容来自实际项目，为首批虚拟运营商提供全业务融合的计费系统并开辟了多个档位套餐的摸索性尝试。响应了虚拟运营商时代“产业为本、战略为势、融合为魂、创新为器”的口号。
1.2国内外发展现状对比分析
1.2.1国外发展现状
在国外，虚拟运营商在业务推出创新的同时同样重视自身融合计费系统的建设。在融合计费的需求下，如英国虚拟运营商Virgin推出了以账户为核心的融合计费系统和预付费\\后付费融合的计费解决方案，系统在设计中强调对回话控制、余额管理、综合采集、预付费和后付费等的融合。而在业务创新上，国外虚拟运营商上主打细分市场：锁定特殊用户群体。比如英国的虚拟运营商维珍移动。成立初期，维珍移动观察到传统运营商针对低端消费用户的服务并不多，掌握了用户的行为习惯后，维珍移动和MTV网络签订协议：MTV网络向维珍移动的用户提供游戏、音乐、综艺节目等活动内容，而维珍移动将自己的广告嵌入MTV官方网站，达到互利共赢的目标。由此可见，维珍移动没有和传统运营商正面较量，而是找到了市场真空地带，并有针对的推出服务。国外的虚拟运营商在推广自身电信业务的时候分析自己的优势，取长补短，通过细化市场和发挥渠道优势，将自己的优势最大化。中国可以借鉴国外虚拟运营商的发展方式，应当首先确定自身在中国市场中的定位。在保证服务质量的同时推出特色服务，才能在激烈的竞争中站稳脚跟，稳步发展。
2北京航空航天大学硕士学位论文1.2.2国内发展现状
国内的虚拟运营商为了将自己的业务扩向更广大的群众，必须依靠自己原有的业务打特色牌。如京东通信，虽然没有价格优势，采用的是全国统一资费标准，但京东将170号与自己的电商业务相捆绑，推出了“211”赠送规则。即只要在京东商场购物没满2元，就赠送1分钟语音和1M流量。根据会员级别不同，会有每月300分钟语音，300M流量或每月每月500分钟语音、500M流量封顶。对比三大运营商繁杂的电信业务，这种业务模型更加标准，使用户更容易理解。随着时代的进步，越来越多的捆绑式特色业务浮现在用户面前，虚拟运营商的出现大大推动了国内计费系统的优化。
目前国内的计费系统有在线计费的实时计费系统，离线计费的准实时计费系统和离线计费系统，还有同时支持在线计费和离线计费的融合计费系统。其中实时计费系统（OnlineChargingSystem）[1]，简称OCS，其特点是计费子系统可能受账户余额的限制，用户变更业务等实时因素的影响而不得不进行更新。这种计费模式往往针对的是预付费用户，支持实时采集、实时计费、实时销账的计费模式。需要与服务管理、会话控制、账务等直接交互。准实时计费是指当用户使用完业务后才生成相应的资费信息并立刻进行处理，这种计费模式也成为热点计费（HB）。热点计费优势是可以使用户从使用业务到开始计费之间的时间缩短，从而保证计费的准确。离线计费的特点是计费批价引擎不受计费信息的实时影响，也不实时生效，主要通过网元获取的各种业务使用记（CDR）通过脱机的方式交给计费系统处理。在目前的电信行业，三大运营商习惯把用户分为预付费用户和后付费用户，并分别由在线计费系统和离线计费系统承载计费。因此为实现预付费用户和后付费用户的统一提出了融合计费系统。
本课题的研究意义也在于为虚拟运营商建设一套高效、可靠、稳定的全业务融合的计费系统[2]，在保持易扩展性和高健壮性的同时来满足实现国内虚拟运营商特色业务功能的需求。
1.2.3对比分析
国外虚拟运营商已经得到广大用户的青睐，而支撑其庞大业务功能的融合计费系统也足够完善。相比较而言，国内虚拟运营商还没有一套成熟的电信计费产品，反映在计费系统的融合能力差。
3第一章绪论所谓融合计费系统的融合是首先体现在预付费和后付费的融合。以前为实现业务的差异化，电信运营商把用户分为后付费用户和预付费用户两种类型，其中预付费是指月初扣除当月套餐资费，实现先扣费后使用的政策，这种付费模式更能保证运营商的利益，但在实现中发现用户体验度不高。后付费是指用户可以正常使用当月套餐，统一在下个月初进行结算，实现用户先消费，后付款的政策，这种付费模式贴近用户的消费模式。两种付费模式只是体现用户支付手段的不同，相对而言，虽然后付费的方式对运营商存在一定的风险性，但是运营商也对用户实行账户信用余额的控制。用户拥有一定额度的信用度，当用户当月使用的资费超出套餐费用，并超过一定的信用度时，运营商可以对该用户实行停机保号的政策。其次融合计费系统的融合体现在支持多种采集方式和计费模式的融合，并可以实现全业务的融合并统一批价。
根据对国内外现状的对比分析，选择了电信运营融合计费系统的设计与实现这一课题，通过研究分析计费系统的融合能力来促进国内融合计费系统的进一步优化。
1.3研究目标和研究内容
1.3.1研究目标
本项目运用C++程序设计语言，结合Oracle10g数据库平台搭建了基于B/S体系的融合计费系统[3]。实现了预付费/后付费融合，全业务的融合并统一批价。并重点研究了计费下的解码、业务处理、错单回收、错单入库、详单入库等功能。为虚拟运营商提供了全业务运营的IT解决方案，并从技术上提供整套计费系统的设计方案。1.3.2研究内容
本文借鉴国内三大运营商融合计费系统的设计方案和建设经验，通过分析现有融合计费系统的问题，展望未来电信运营融合计费系统的发展前景，设计了融合计费系统总体的系统架构、软件的框架体系结构、系统模型[4]。
本系统不仅保证了计费系统新旧版本的兼容性和平稳过渡，而且保证了实时可靠的系统更新，同时保证了计费系统将来可以在不影响生产运行的情况下进行扩容。其中融合计费系统提供基于事件与会话的在线与离线计费功能，由综合采集、解码、业务处理、查重、批价、分发入库、错单回收、错单入库等功能模块组成。
4北京航空航天大学硕士学位论文在系统的设计与实现中，本人的研究内容主要集中在以下几个方面:1.研究融合计费系统的系统架构。2.研究融合计费系统的融合能力。3.研究融合计费系统计费引擎。
基于上述几点，最终实现了电信运营融合计费系统的设计和开发。
1.4论文组织安排
论文共分为七章。
第一章为绪论。通过对比分析国内外虚拟运营商的发展现状，引出其核心竞争力融合计费系统并提出论文的研究目标和内容。
第二章为相关技术介绍。介绍了在实现该系统时所利用的相关技术，主要利用C+++LUA+ORACLE实现服务端的开发。
第三章为需求分析。阐述软件基本需求，从用户角度出发，细化和分解各个用例场景，设计出系统的功能用例，以及整个系统所需要的功能模块。该章从总体上构建系统的轮廓，为后来的概要设计和详细设计做下铺垫。
第四章为系统概要设计。通过上一章节的需求分析并进一步深化，分解出各个需求的详细场景，并结合实际需求，提出系统的总体设计方案，解决方案和关键技术。
第五章是系统详细设计。通过对上一章节的更进一步细化，落实到代码层面，包括具体的具体模块的设计与实现过程。
第六章是系统测试。通过对系统进行总体测试，并给出测试内容，测试方法以及测试用例，证明系统设计符合预期。
最后一章是总结和展望。该部分总结了整个研究过程所取得的成果，并对实际项目中遇到的问题做了进一步的思考，同时提出了一些可进一步解决和优化的地方。
1.5本章小结
概要性的介绍了电信运营融合计费系统的发展方向和趋势，总述了本文的主要工作和论文的主要结构。
5第一章绪论第二章相关技术介绍
2.1Oracle数据库技术
新世纪以来，随着电子行业特别是计算机技术的迅猛发展，电信行业也随之崛起。随着科技的创新和经济的发展，人们对于日常通信也有了更新的需求。电信行业在激烈的竞争下，除了将预付费、后付费分离的旧事计费系统融合之外，在业务方面，不仅涵盖语音增值、E-mail数据业务、人工信息服务、自动信息服务、存储转发等业务，还要顺应时代的发展，将迎来无套餐、无月租、流量不清零等新时代。这些特色业务除了需要计算机软硬件和网络的支持外，还必须依靠大型数据库管理系统的支撑。
在数据库的选择上选取的是当今最为主流的Oracle数据库。采用Oracle数据库技Oracle术的原因主要从系统技术特点和体系结构两方面考虑，相对于其他数据库而言，是目前最为流行的B/S体系结构或客户服务器((CLIENT/SERVER)的数据库。
Oracle数据库有如下的技术特点，如：1.支持海量存储、多用户高性能的事务处理。
2.Oracle遵守统一标准并支持多种系统平台（如windows、vms、os\\2、SUNOS），
在用户接口和网络通信协议上有统一的工业标准。
3.支持B/S体系结构及其它的混合体系结构（如分布式、集中式、B/S），并对
分布式的数据库可以进行分部处理。
4.具有数据透明、网络透明、支持异种网络、异构数据库系统，并行处理采用
动态数据分片技术。
5.可以进行良好的移植，具有兼容性和连接性。
本系统采用的是最新版的Oracle10g，相对于其它版本的Oracle，除了上述的技术特点外它还具备如：
1.高速数据处理能力。
使用一种被优化的表结构改进电信级应用的性能。其中这一表结构来源于一种新类型的表对象。该表结构可以很好的支持数据处理并且对大量插入和解析数据很有益。
6北京航空航天大学硕士学位论文2.对新的架构支持。
支持infiniband和Intel64位平台。新版本的Oracle通过Windows操作系统对Fiber的支持提高了多层开发架构下的开发性能和可扩展性能，如该版本的Oracle扩展了Flashback的能力。加了一个新类型的Log文件，该文件记录了数据库块的变化。这个新的Log文件也被自动磁盘备份和恢复功能所管理。如果有错误发生，例如针对不成功的批处理操作，DBA可以运行FlashBack。用这些beforeImages快速恢复整个数据库到先前的时间点--无须进行恢复操作，这个新功能也可以用到Standby数据库中。
3.超大数据库的支持。
可支持到8E的数据量。改进的存储、备份、恢复管理也对超大数据库有着很好的支持。分区可以支持索引组织表。
4.缩短信息周转时间。
新版本的Oracle提供了加强的ETL功能。可以方便的构建大型数据仓库和多个数据集市。一个新的变化数据捕捉的框架允许管理员能够轻易的捕捉并发布数据的变化。新的CDC功能利用的是Oracle的Stream技术架构。
对于大数据量的转移，新版本提供了对可传输表的跨平台的支持，允许大批量数据快速从数据库上的脱离并附接到第二个数据库上。
5.简化的数据库配置与升级。
提供了预升级检查能力，有效地减少升级错误。去除了了很多和数据库配置有关的任务或者对其加以自动化。在初始安装的时侯，所有数据库都被预配置包括在OEM环境中而无需建立一个管理资料库。补丁程序可以自动标记并自动从OracleMetalink下载。
6.自动存储管理。
新版本的数据库能够配置成使用Oracle提供的存储虚拟层（Storage
VirtualizationLayer)。自动并简化数据库的存储。管理员现在可以管理少数的磁盘组而无需管理数千个文件--自动存储管理功能可以自动配置磁盘组，提供数据冗余和数据的优化分配。
7.PL/SQL的增强。
最重要的当数新的PL/SQL优化编译器，提供了一个框架有效地优化编译PL/SQL程序。这个版本还引入了两个新的数据库包：UTL_COMPRESS、UTL_MAIL。
7第一章绪论2.2Lua介绍
2.2.1Lua介绍
Lua是一种灵巧的小型脚本语言，核心代码紧凑，可用的扩展库也有很多。可以支持多线程，socket，图形编程等等。同时，Lua也是一种嵌入式的脚本语言，该语言设计的目的也是签入到应用程序中，扩展应用程序并提供特色功能。Lua最大的特点就是不仅可以单独使用，还能与其它语言混合调用。比如说C/C++代码可以调用lua脚本，lua脚本也可以调用C/C++的函数，并且可以代替XML等文件格式做为配置文件。
Lua由由标准C语言编写而成的，能在几乎所有的操作系统和平台上编译和运行。而一个完整的Lua解释器大约在200k左右，在目前所有脚本引擎中，Lua的速度是最Lua快的，这一切都决定了Lua是作为嵌入式脚本的最佳选择。和Python等脚本不同，并没有提供强大的库，这是由它的定位决定的。所以Lua不适合作为开发独立应用程序的语言。不过Lua还是具备了比如数学运算和字符串处理等基本的功能。
Lua和Python、JSP、PHP等脚本不同，Lua是由标准C语言编写而成，因此Lua具有很强的跨平台性，可以在绝大多数操作系统上编译并且运行。而且一个完整的Lua解析器非常小，大约在200k左右。虽然Lua没有提供强大的库，但是Lua还是同时兼具字符串处理、数学运算等基本的库。因此虽然Lua不能作为一个开发应用程序的语言，但是作为一个嵌入式脚本具有得天独厚的优势。
Lua的特性包括：
1.灵巧简易。Lua简单、小巧、内容少但功能却很强大并且lua现在的扩展库非常齐全。
2.容易扩展。Lua具有非常强的扩展性而且容易与其他语言（如C/C++、Smalltalk、java等）实现接口。通常可以使用标准C语言或者Lua代码实现脚本的扩展，而Lua的很多功能也可以通过外部库来进行扩充，因此很多人使用Lua来搭建领域（比如本计费子系统的编解码模块）。
3.跨平台性。Lua的条件编译使用ANSI(ISO)C，不通过条件编译。因此如果具备ANSIC编译器就可以对Lua进行编译和使用。
8北京航空航天大学硕士学位论文4.具有较高的执行效率。相对于其它脚本语言，目前Lua是平均效率很高的脚本语言，执行效率可以达到C语言的1/10。2.2.2Lua与其他语言的对比
目前而言服务端脚本技术上，除了Lua以外，还有PHP、ASP、JSP和.NET，他们都各有千秋，都有广泛的使用。
表1对比点夸操作系统Web服务器执行效率稳定性开发敏捷度Lua支持多快高高Lua和C/C++、javafortran等支持语言语言扩展PHP和C语言扩展VBScriptJavaC#、VB、C++语言与其它语言的对比PHP支持多快高高ASP只支持Win32IIS快低高JSP支持很多极快高中.NET只支持Win32IIS极快高高由上表1所示，在多方面测试中如：跨平台性，通用WEB服务器支持、执行速度对比、通用的稳定性、支持语言等方面都有不错的表现。
表2比较项目函数支持系统安全版本升级难易程度Lua多高快易Lua与其他语言在其他方面的比较PHP多高一般易ASP少低慢易JSP中高慢难.NET多高一般中表2中所展示了一些语言在其他方面的对比，比如函数支持、系统安全、版本升级、难易程度。其明显展示了，Lua语言优于其他语言的地方。同时在移动互联网方面的特性，开发速度快、迭代周期短、需要抢占市场先机等需求上考虑Lua作为服务
9第一章绪论端首选脚本语言显得更加符合。Lua脚本在本系统的中的应用是扩充业务功能，能够与C++的函数实现接口。
在本系统解码模块的对报文的编解码，主要是在Lua脚本里做，而C++代码主要实现的是对协议和Lua中调用的函数的封装，在Lua脚本里调用C实现的接口进行编码和解码。为了实现变长编解码且要针对不同规范编解功能的统一化，求同存异，最大化得利用共同点、最小化差异影响是解决问题的关键。
2.3面向对象技术
在计费系统开发的过程中，采用的是基于c++的面向对象技术，面向对象三大特性是封装、集成、多态。核心概念是类、对象。类是具有相同特征与功能的对象的集合，其中属于一个类的对象称之为这个类的实例，它可以共享这个类的函数和变量。对象是一种抽象和封装。采用面向对象的技术可以对软件进行重用，它通过多态性和继承性更容实现功能上的扩展。在开发过程中，始终保持一致的结构和形式，支持模块化，通过抽象实现系统的强内聚和弱耦合。
2.4授权访问管理技术
在本系统中，为了保证操作系统的数据不被非法用户盗取，将对不同的注册用户授予不同的操作权。防止非法用户对数据库访问的主要途径是存取控制。所谓存取控制是对用户访问数据库的各种资源(包括表、表视图、索引等)增删改查等的控制。通常采用下面两种方式来实现存取控制：对用户授权和把数据库系统的权赋予用户。
本系统所有的用户数据都存放在分布式架构的Oracle数据库中，用户在客户端进行登录的时候应当先进行身份验证，获得数据库的访问权后方能进入系统。但是这种访问权限会受到应用程序的限制。所以系统会首先验证用户是否为授权用户，如果用户已被授权则进行口令验证，否则不允许该用户访问本系统。所谓的口令验证就是将用户输入的密码进行加密算法，然后与数据库中的存储值进行比较，若相同则予许登录。在用户登录的时候，还要判断操作系统中是否已经运行一个同名的程序或是否有人用相同的用户名在其他主机上登录。
10北京航空航天大学硕士学位论文2.5本章小结
本章主要介绍了系统整体实现所需要的相关技术，主要包括Lua简介、Oracle数据库技术、面向对象技术，它也是本文关键技术的难点和主要实现部分，用其特性解决实际问题。
11第一章绪论第三章系统需求分析
3.1需求概述
随着信息技术和通信技术的迅猛发展，在工信部颁发虚拟运营商牌照的浪潮下，虚拟运营商业务迅速发展。针对虚拟运营商计费系统需求的特点，在设计融合计费系统必须先搜集需求，对虚拟运营商的业务形态、特色服务、运营模式等方面进行深入的分析，找准方向，分析设计中将会遇到的难点，对设计方案进行多角度、全方位的审视。而进行需求分析的目的在于让委托方和开发人员的软件需求得到具体的共识，为开发过程的质量保证以及最后的提交验收提供标准，供后续的概要设计者熟悉业务并为下一步软件设计提供标准。经过一番摸索，总结出了虚拟运营商总体计费需求：
1.支持预付费和后付费用户的融合。2.支持实时在线计费和离线计费并行处理。
3.支持语音、短信、流量、固网、其他的特色捆绑业务全业务的融合。4.支持语音、短信、流量、固网、其他的特色捆绑业务等全业务的统一批价。
[5]
3.2产品功能需求
根据上述对虚拟运营商业务总体的分析，运行框架、综合采集和计费的功能和流程是融合计费系统需求分析的重点。3.2.1运行框架
由于计费系统庞大、复杂，需求变化频繁，经过长期的演化，计费功能由多个模块共同完成，如解码、业务分析、批价、分发入库等各模块相互协调，组成完整的计费系统。计费框架的开发就是为了在日常协调各模块的运行，适应客户不断提出的需求开发，实现对计费各模块的统一管理。
计费各模块开发成动态库的模式，由计费框架调用。计费框架在计费过程中主要起到装载、协调和调度的作用，用来给各模块提供运行平台。计费不同模块的顺序执
12北京航空航天大学硕士学位论文行完成计费，计费框架以任务的方式管理各计费模块。框架从磁盘读入文件，按任务上定义的顺序，进行流水线式处理，前一任务模块的输出结果是后一任务模块的输入。
图1运行框架流程图13第一章绪论运行框架是需要完成下面几个功能点：
1.模块注册管理。加载模块，模块封装成动态库，并提供调用函数，由框架加载和调用，处理数据。
2.任务管理、组件管理。组织、协调各模块的运行。各模块之间以XDR传递数据（XDR是一个详单结构，包括详单的所有字段），每个模块将处理的结果填充到XDR，将XDR送给框架，框架将XDR送到其后面的模块，后面的模块从XDR里获取前面模块的处理结果。
3.文件管理。需要支持输出文件和输入文件时多发情况的处理。输出文件时：
1）任务最终输出。所有模块都处理完成后最终的输出。释放XDR，释放文件对象。
2）任务中间输出。输出到文件，输出完成后，XDR和文件对象被后续的模块继续使用。
3）输出分文件，输出按详单里的字段XDR_OUT_POSTFIX的值分文件，分出来的子文件以原文件名为前缀，以XDR_OUT_POSTFIX的值为子文件名的后缀。当有模块需要分文件输出详单时，填充XDR里的XDR_OUT_POSTFIX字段。
4）错误话单输出分文件。错误号（一组数字）按段分配给每个模块，每个模块产生错误话单时，都会打上自己独有的错误号，框架按照错误号分文件输出错误详单，每个错误号一个文件。输入文件时：
1）从输入目录读取文件，可以从多个输入目录读取文件。将输入目录里的文件按文件时间排序，以时间顺序处理。读取文件时，可以配置规则表达式，只处理文件名符合规则表达式的文件。
2）将输入的文件读取到XDR里。
4.前台交互。框架和前台通过socket交互。交互的数据使用xml的格式。不同的业务处理模块，可以按照自身特点，定制消息。框架提供消息通道，使前台和模块可以交互。新定制的消息不需要重新编译或启动框架。
5.支持发起消息的处理，其中消息分控制类和采样类。控制类消息：
14北京航空航天大学硕士学位论文1）控制类消息由前台发起，用于控制后台的进程。2）查询库和函数被哪些组件使用。3）启动、停止任务，查询任务状态。4）查询组件状态。
5）前台和模块的自定义消息。采样类消息：
1）一部份采样类消息由后台发起，向前台发运行信息，如告警日志。一部
份由前台定时取，如状态信息、统计稽核数据等。消息里包括，消息的来源（进程、任务、组件），消息的内容。
2）定时取组件状态。
3）初始化、启动失败消息（任务、组件）。4）运行时的告警日志。5）运行时的告警消息。6）运行时的状态消息。
3.2.2综合采集
首先综合采集有两种采集方式，针对不同类型网元设备实现计费事件的实时在线采集。在线采集模式支持SCP、SACP、SMSC、ISMP/DSMP、GGSN、MMSC、SVR、USSD等多种网元设备，采集数据类型包括在线计费事件的实时消息与离线计费事件的离线话单。离线采集模式支持FTP、UDP、SFTP等多种传输协议，简言之，离线采集是一个数据通道，支持多个子系统内部在网络上进行文件传递，同时也是外部系统通过网络与子系统进行数据交换的重要途径。
在线采集需要支持多种网元设备和传输协议，虚拟运营商目前采用的是离线采集的方式[6]，支持联通VOP平台所需要的FTP协议，拥有统一的传输功能接口，可根据用户的需求进行传输功能的扩展。其中，在数据传输时需要支持任务定制，即将传输任务提前以配置文件的方式保存，需要时后台启动进程进行传输。在文件的处理上，需要支持文件的匹配、更名、校验、压缩、解压缩、稽核等功能。在数据上可以支持备份，在源文件被删除的情况下可以提供数据恢复手段。综上所述，综合采集需要支
15第一章绪论持很多功能，在系统的设计和开发中面临到的难题是如何实现统一的传输功能接口来支持多种网元设备。如下为综合采集的实时数据采集流程图：
爱立信交换机FTP诺机亚交换机FTP采集子系统计费系统FTP华为交换机FTP数据流原始话单文件数据流西门子交换机图2离线采集内外部关系图3.2.3计费
根据调研，计费的流程是首先从用户的资料中获取用户订购时的计费资源、产品资费，继而实现用户跨地域、跨业务的计费过程。在实现过程中，原有预付费\\后付费分离，在线计费、离线计费不能同时兼容的计费模式已经不能满足客户对采集计费实时、准确的要求，因此新一代融合计费系统融合了在线实时计费、离线计费、准实时计费多种计费模式，实现了预付费\\后付费融合和全业务的融合。其中计费中全业务的融合是指语音、短信、流量、固网、其他的特色捆绑业务的融合，并可以对全业务实现实时统一批价处理。
计费子系统是融合计费系统的核心环节，为了应对客户的需求需要融合多种计费模式，融合计费系统满足在线计费和离线计费两种计费方式同时运行，其中在线计费系统和离线计费系统同时运行时的协作主要体现在当在线计费系统出现事故或者由于电信
16[7]
北京航空航天大学硕士学位论文业务繁忙，此时由网元传来的话单可以由接口模块转交给离线计费系统进行计费处理。在线计费系统的预付费/后付费用户由离线计费系统统一账户管理。而在线计费系统不能处理的优惠处理，如特色业务捆绑优惠等交给离线计费系统处理，处理完后再对预付费用户多扣除的费用进行余额冲正。该融合计费系统具备全业务运营支撑能力，具有为用户提供标准化与差异化使用体验的综合支撑能力，满足不同市场对于基础业务与增值业务的全部需要。通过对现状的分析，计费需要满足下面的总体要求：
1.全业务融合资费。
支持语音业务与数据业务、在线业务与离线业务、实时业务与非实时业务、预付费业务与后付费业务以及标准资费与协议资费等多种模式的计费需求，支持针对各类业务的交叉优惠。
2.数据业务。
支持对数据业务的计费与账务支撑。支持GPRS业务的实时计费控制，支持2G与3G网络的实时切换，支持计费模式进行相应切换后对2G与3G网络采用不同收费模式。
3.账户/用户/业务层的融合。
提供账户级、用户级、业务级的多层级资源分配与计费模式，在业务实现与资源管理上具备多层级融合能力，如支持多层级的产品订购与费用收取，支持多层级的税费计算与捆绑优惠，支持多层级的预算控制与信用控制。
4.资源携转。
支持对失效的免费资源延长使用有效期的携转功能，提高资源利用率。周期性免费资源失效时间为当前周期结束时间，一次性免费资源失效时间为免费资源创建时的指定失效时间，资源携转功能为用户提供对已失效免费资源的使用权限。
5.预算控制。
17第一章绪论支持个性化的预算控制功能，实现对一定周期内消费额度的限制。预算控制功能用于提高消费透明度与提升用户体验，在设置与实现上具有极高的灵活性，客户可以自由定义使用额度阀值与预算控制规则。
1)多层级：预算控制功能支持账户级、用户级、业务级三个维度的限额判断，客
户可以对其拥有的一个或多个指定账户在一定周期内的使用额度进行限制，亦可对某个账户下的一个或多个用户以及某个用户对指定业务的使用额度进行限制。
2)多业务：预算控制的触发通过系统对使用额度是否达到预置阀值的判断实现，
阀值的预置支持资源型与费用型，即在一定周期内，客户可以从其使用费用、通话时长、数据流量等多个角度进行额度控制。
3)多执行方式：预算控制的执行动作支持暂停服务、触发提醒、暂不处理三种方
式，触发提醒的动作支持设置多个阀值并触发多次提醒，提醒的方式包括SMS、Email。6.资产转移转换。
支持资产的转移与转换功能，提高用户对资源的优化整合能力，提升资源利用率。1)资产转移功能实现资产归属属性的变更，支持针对免费资源、账本资金、积分、有效期在不同账户间及同账户下不同设备间进行转移。
2)资产转换功能实现资产形式的变更，支持免费资源、账本资金、积分、有效期在同账户下的转换。
7.多级信控。
支持信控提醒功能实现系统对用户消费的实时监控，根据用户消费状况与状态信息为其执行通知、状态变更等服务，通过增加系统与用户的交互提升业务的使用透明度与用户参与度。
8.灵活账期。
18北京航空航天大学硕士学位论文支持标准化账期与定制化账期，提供年、月、周、日等多种账期跨度。支持对产品设定个性化计费周期并按照产品周期计算周期性费用，费用收取支持周期初收取与周期末收取两种方式，具备自动化出账功能完成全部费用的汇总并生成账单。
9.代付分账。
为用户提供由其归属账户之外的其他账户代为支付费用的功能。代付支持计费与账务两类代付规则，支持固定值、按比例、自定义额度三种不同限额的复杂代付，支持在代付者与被代付者的详单、账单中准确记录代付或被代付号码。
10.多语种。
支持多语言应用，为用户提供多语种的选择功能。
1)在界面中，系统使用UTF-8与Unicode分别进行语言资源的存储与处理，实现在不同界面上对多种文字类型的同步显示，屏蔽编码混乱、异常字符等问题，同时支持按照文字的字型结构进行变化，提高界面交互的美观性体验。
2)在账单中，支持语言资源包的升级与扩充，通过代码与语言资源包的分离设计，实现语言资源包的快速扩充。
11.内容计费。
支持基于数据来源与业务内容的分类计费功能。通过对终端用户上下行数据包的过滤与分析，实现对数据业务的流量来源与业务内容的识别，对不同来源与不同内容数据业务使用不同的计费策略进行分别计费，为电信运营商在移动互联网的业务实施提供区别于以时长、流量、次数为依据的计费方式扩展。
12.带宽控制。
支持基于终端用户的差异化流量控制功能，可面向不同网络、不同运营商以及使用不同业务的终端用户使用不同的带宽控制规则，结合内容计费能力为运用商构建深度流量经营模式提供完整的运营支撑体系。
19第二章相关技术介绍3.3业务功能需求
针对手机用户的产品及资费：
1．个人客户包月包年套餐可议价,且每个社区可设置最大议价额度新系统不需要支持,只议价一次性费用,老数据通过赠送预存来出来处理，赠送部分预存不计权责。
2．政企客户产品可以订购多份,业务场景:满足对于部分政企用户包年包月/计时费不同的需求(目前在网用户1040多户),议价仅议价月租费。3．暂停期间不收费,恢复后有效期顺延，暂停只支持按账期暂停。4．计时产品套餐外计费标准：每秒0.0008333元。
3.4需求难点分析
1．虚拟运营商如何选取解决方案。2．如何完成预付费和后付费的融合。3．如何实现全业务的融合并统一批价。
3.5本章小结
本章由需求分析为切入点，通过之前对国内外融合计费系统的分析和对当前虚拟运营商现状的需求调研。通过对系统各个模块功能需求的分析，了解了系统应当具备的功能，并提出实现功能时会遇到的难点，完成了本章的介绍。
20北京航空航天大学硕士学位论文第四章系统概要设计方案
4.1系统设计概述
目前在线计费所需的建网成本是离线计费的7倍之多，而且国内人多地域广，中国传统的电信运营商采取的计费方案基本都是离线计费方式[8]。由于虚拟运营商自身没有电信网络资源，是通过租用三大运营商的电信基础设施方式来对电信提供的服务进行二次开发和深度加工。换句话说三大运营商将用户使用的电信服务通过路由分发以文件的方式定时下发给虚拟运营商，虚拟运营商再对采集到的话单进行后续的计费处理和优惠处理。基于上述思考，我们提出了离线采集+离线计费的解决方案。
4.2系统设计原则
为保证系统的合理性、可靠性、功能的完备性、安全性和可扩充性，设计遵循以下原则:采用框架式与组件式的总体设计方案，运用云技术实现系统架构与功能模块的有机结合，使用闭环工作流管理技术对所有业务的工序环节进行严格控制与管理，具备优秀的功能扩展性与产品演进性。
1.扩展性。
融合计费系统从架构设计到功能实现均以统一性与扩展性作为总体思路进行实施与部署，高度的可扩展性为运营商在全业务运营的复杂环境下提升综合运营能力提供条件。
1)架构设计上采用框架式与组件式的总体设计方案，在统一的框架模型下，运用
云技术实现对功能对象与数据对象的组件化集成。
2)功能实现上由应用框架以读取配置文件的方式完成应用实例的统一管理与流
水线任务的统一执行，仅通过修改配置文件即可快速增加与删除应用。2.稳定性。
稳定性是检验电信运营支撑系统支撑能力的重要标准，融合计费系统通过保障数据安全性与运行连续性确保系统的高稳定性。
21第二章相关技术介绍1)采用以云平台为基础面向总线的系统架构设计，确保系统在计算节点发生故障
时具备屏蔽故障节点的能力，减少局部故障对系统整体运行的影响。2)后台存储使用内存数据库技术，支持内存数据库的文件HA与双机HA机制，
在系统异常运行时备用内存数据库可迅速接管主用内存数据库，确保系统对客户端业务处理请求的不间断响应。
3)系统监控模块提供系统总体运行、业务流程运行、总体资源使用等各类情况的
实时监测与提醒功能，降低潜在事故发生率。3.维护性。
融合计费系统提供统一的配置管理中心用于保存、维护、发布产品线的所有系统配置数据，通过配置管理中心集成的功能简化系统维护流程，提高系统维护效率。
1)配置管理中心自动生成并保存配置数据版本，维护人员通过配置管理中心可以
实时获取目前使用的配置数据版本。
2)配置数据采用统一的标准化格式保存，便于数据的复制与移植。
3)提供图形化的配置管理工具及监控工具，为维护人员在异常情况下快速定位故
障节点提供帮助。4.可配置性。
融合计费系统的柔性软件设计理念使其在开通流程、功能配备、参数设置以及各类关键性应用的选择等多个层面表现出高度的可配置性，并集中体现为系统的高灵活度、高适配能力以及高复用能力。
1)高灵活度：清晰的架构体系与组件式业务模型使系统在面向不同需求时可完成模块级的独立配置与系统级的个性化流程管理，多维度的可配置化特性确保系统能够灵活应对复杂的账务流程与多变的资费策略。
2)高适配能力：标准化的功能配备、通用型的接口设计以及多运行环境的搭载能力使系统具备高度的可移植性，公共信息总线技术的应用使系统通过中间层进行应用服务的添加即可实现对新业务的支持，减少对底层代码的设计。
[9]
22北京航空航天大学硕士学位论文3)高复用能力：对功能模块与中间层服务插件的统一开发与测试，使各功能模块成为具备复用能力的可复用部件，在新系统的实施过程中对可复用资源的利用可实现开发效率的极大提升与开发成本的有效降低。5.开放性。
融合计费系统为各类外围系统提供统一的接口组件实现其与外围系统的数据交互与信息传递。所有业务组件采用XML技术通过ESB交互，支持与多种外部IT系统的互联。
6.全面性。
支持FTP、STFP、FTAM、Diameter等文件或在线传输协议，支持事件与会话型网络的交互。
7.高效性。
融合计费系统通过内存数据库、共享内存等先进技术提高数据的吞吐量与系统运行的整体效率从而体现系统的高效性。
4.3融合计费系统的体系结构
融合计费系统整个系统架构可以分为三层：管理层、业务层和数据层。
1.由于目前虚拟运营商主要是离线计费模式，管理层中主要应用的是网管系统，包括系统监控、权限管理、日志管理、告警管理。系统监控的作用是实时查看进程的运行状态，权限管理针对不同的用户角色配置权限，日志管理用来查看日常服务器中的日志，告警管理用来给用户发提示信息，比如用户余额不足或欠费等。
2.业务层有融合计费引擎和ECFrame调度平台[10]，ECFrame调度平台是一种运行框架，融合计费引擎运行在这个机制上。
3.数据层分为数据库和内存数据库。融合计费系统体系架构如图3所示：
23第二章相关技术介绍图3融合计费系统体系架构图从融合计费系统的系统架构可以看出系统基于统一的运行框架，这种方式可以方便快捷地满足融合业务下各种业务计费流程的调整和部署。而业务组件与框架的分离，可以支持融合业务丰富多变的计费业务流程，保证进程运行的高效稳定。拥有统一的运行框架，支持对融合业务各计费流程的统一调度，统一监控管理。支持全面的数据稽核，包括文件平衡性、话单平衡性、费用平衡性。拥有良好的扩展性，可以任意增加、删除、拆分、合并模块进行流程组合。支持完善的系统监控，基于框架的统一接口，前台通过接口调用，实现整个计费运行的实时监控。
整个计费的流程是计费系统使用离线采集的方式从网元采集话单，随后将话单送入解码模块翻译成计费识别的格式—详单，随后将解析出的详单送入业务分析模块分析出批价所需要的计费要素，批价则通过查询用户订购的产品信息及用户使用的累积量批出资费，最终将处理后的详单分发入库。在计费过程中最重要的功能模块是解码、业务分析、查重、批价、分发入库、错单回收，如下为计费总体业务的数据流图：
24北京航空航天大学硕士学位论文业务平台核心网元计费预处理主机1、话单采集1、话单采集话单传输XDRMCAS MDB内容计费XDRCRMISMP MDB离线采集话单采集原始话单统一查重2、XDR流入预处理XDR计费数据库计费数据库4.1话单入库8、详单查询话单累计梦网稽核扣费提醒业务分析统一查重扣费确认3、预处理后话单流入计费CMOD主机解码话单接口机传输帐务处理主机话单传输帐务处理分话单CMOD计费批价主机话单流帐务流交易流充值帐管计费批价话单合并计费MDBBI主机6取转换后话单格式转化5、话单分发BI结算主机结算用户MDB4.2合帐FileServerFileserver分发入库4.3流入话单接口机帐务MDB7、透传给结算、经分、CMOD1.2透传文件流入话单接口机1.3解码后文件流入话单接口机图4计费总体业务流图4.4计费系统与其它关联系统之间的关系
在电信行业习惯把整个电信运营支撑系统（BOSS）简称为计费系统
[11]
，而融合计费
系统是其中的核心部分。其中与计费系统相关联的系统的可分为同级系统、上下级系统和外围系统三类。计费系统与其它系统相互关联来保证业务信息和服务数据能够准确实时的传递给所需的部门。
25第三章系统需求分析图5计费系统与关联系统的关系图1.计费系统与同级系统的关系。
从宏观上讲，计费系统可以划分为很多子系统，融合计费系统只是其中之一。在计费系统中与融合计费系统同级的系统有客户关系管理系统（CRM）、账务系统、结算系统等子系统，它们之间共享数据和客户资料。
2.计费系统与上下级系统的关系。
通常我们所指的上下级系统是指为虚拟运营商下发话单的三大运营商网络侧系统以及下属的省级系统。计费系统接受上级系统下发的计费数据、客户资料、统计信息等。
3.计费系统与外围系统的关系。
计费系统除了与三大运营商的上下级系统相关联外，还会与一些金融企业如银行等的金融系统相关联。从而计费系统可以与金融系统互相接受和传递数据，并完成如代扣、实时优惠、实时扣费等费用数据的处理。从而在方便客户使用的业务的同时加快虚拟运营商的资金回笼。
26北京航空航天大学硕士学位论文图6BOSS内部同级系统交互关系图4.5数据库设计
在计费日常处理过程中，电信用户数量可能达到几百万甚至上千万。如此大的用户量产生的语音记录、数据流量记录、短信记录等会造成数据库中相关表的数据太过庞大，从而导致数据库的性能降低。因此设计一套兼顾性能和系统实现的数据库尤为重要。4.5.1分表规则
1.详单表，详单按月分表。
[12]
表3详单表分表规则27第三章系统需求分析service_id50001500055000650014530017000170002详单母表USAGE_VOICEUSAGE_SMSUSAGE_ISMPUSAGE_MMSUSAGE_GPRSUSAGE_RECURRINGUSAGE_ONE_TIME详单分表VOICE_TENANT_YYYYMMSMS_TENANT_YYYYMMISMP_TENANT_YYYYMMMMS_TENANT_YYYYMMGPRS_TENANT_YYYYMMRC_TENANT_YYYYMMOTC_TENANT_YYYYMM详单分表示例如下：
图7语音表示例图2.重批表。正常话单同时需要入详单表和重批表，重批表表名在入库时通过正常详单表表名得来，在详单表名前加REDO_，这段逻辑在代码中实现。重批表示例如下:
图8重批表示例图3.错单分表规则。系统对错单有不同的分类，根据md.SO_REDO_XDR_ERR_DEF表中recycle_limit来区分，不同错误码对应不同的recycle_limit。目前需要入库的有普通错单，notout错单,按月分表。
28北京航空航天大学硕士学位论文表4service_id50001500055000650014530017000170002错单母表ERR_USAGE_VOICEERR_USAGE_SMSERR_USAGE_ISMPERR_USAGE_MMSERR_USAGE_GPRSERR_USAGE_RECURRINGERR_USAGE_ONE_TIME错单分表规则普通错单NOTOUT类错单ERR_VOICE_NOTOUT_YYYYMMERR_SMS_NOTOUT_YYYYMMERR_ISMP_NOTOUT_YYYYMMERR_MMS_NOTOUT_YYYYMMERR_GPRS_NOTOUT_YYYYMMERR_RC_NOTOUT_YYYYMMERR_OTC_NOTOUT_YYYYMMERR_VOICE_YYYYMMERR_SMS_YYYYMMERR_ISMP_YYYYMMERR_MMS_YYYYMMERR_GPRS_YYYYMMERR_RC_YYYYMMERR_OTC_YYYYMM错单分表示例如下:
图9错单表示例图4.科目事件分表规则。目前虚拟运营商支持的科目主要分为语音、短信、流量三种类型，每种科目都有很多不同的事件，不同的事件配置不同的资费。由于科目较多，不一一列举，科目事件的分表规则如下所示：
表5EVENT_ID112011120211203112041120511206短信事件定义表EVENT_NAME本地发送本地事件本地发送省内事件本地发送国内事件省内漫游发送省内事件国内漫游发送省内事件国内漫游发送国内事件ITEM_ID50005201500052025000520350005204500052055000520629第三章系统需求分析4.5.2数据库处理能力的软件解决方案
在进行数据库的设计时，按照一定的分表规则划分表空间，并在数据库物理磁盘上划分区域存储表空间
[13]
。并在设计的过程中利用Oracle分区的技术进一步缩小分区空
间，这样的设计可以在数据库磁盘的不同物理物质区分表空间，表空间中又区分不同的表。这样的数据库设计可以使不同进程访问系统资源的冲突大大减少。
1.建立合理的数据库索引。
在拥有大数据量的情况下，索引可以提高数据的查找速度，但是过多的索引会消耗系统的资源并制约数据的修改。因此在设计数据库的结构时应当建立合理的数据库索引，可以显著提升数据库对表的访问速度。
2.内存数据共享。
本系统采用内存共享的方法来减少资源的浪费。计费系统多个功能模块可以共享同一内存区域中的数据，既将多个进程共享的数据存放到内存中的共享区域，使用时只需要在共享的数据发生改变时进行一次初始化设置。这种方式减轻了数据库的压力，大大提高了程序运行的速度。
3.多进程处理。
计费系统采用多进程的技术来防止数据处理过程中产生的瓶颈，并在进程间采取交叉处理的方式来减少内存资源的浪费。
4.6技术关键点
4.6.1查重技术
传统的查重方法是在详单库中建立唯一索引并利用Oracle数据库索引的唯一性进行查重[14]。既在详单入库前，对每一条将入库的详单进行查重，从而剔除重复的详单达到排重的目的，但是这种查重方法在大批量详单入库时会对数据库的处理速度造成影响。目前的解决方案是对详单表进行分割处理，但是随着数据量的增大，这种查重方法已经越来越不能满足计费系统对处理效率的要求。因此在设计新一代查重算法的时候需要注意两点：一是选择在哪种查重，二是选择使用哪种查重算法。
30北京航空航天大学硕士学位论文4.6.2查重机制
计费系统常用的查重机制有两种：在预处理阶段查重和合账前查重。
1.预处理阶段查重是指在详单批价之前就进行查重处理，这种查重机制能保证整个计费系统在运行期间负载均衡，也能保证后续的模块不需要再对详单进行查重处理。
2.合账前查重是指在累账之前，统计分析之后对详单进行查重处理。这种查重机制的优势在让系统在每个账务周期中加快详单处理的速度，但是当月末出账时会出现重单很多的情况。
目前由于虚拟运营商业务种类繁多，为了保证计费系统内各功能模块的负载均衡和查重的准确性，选择在预处理阶段查重的查重机制。4.6.3查重算法
由于虚拟运营商的话单是三大运营商以文件的形式下发的，目前新一代查重技术是利用关键值文件进行查重。实现方式是将详单中的关键字段值写到事先构建的关键值文件中，当有新的详单需要处理时先将关键值文件调入内存数组中，再通过判断关键值文件中是否存在新详单的关键字段值。如果存在，则将重复的详单剔除。不存在的话将关键值字段写入到关键值文件中，以此机制继续对新的详单进行处理。但是这种机制会占据较大的内存资源，违反了查重机制查找速度快，占据空间小的原则。目前计费系统基于这种查重机制并对查重技术做了进一步优化。4.6.4基于键树索引计费系统查重设计
目前虚拟运营商从网元采集到的原始话单是以主叫号码和通话时间拼成的字符串作为关键字段值。每个话单都有唯一的主叫号码，加上通话时间拼成的字符串可以作为唯一性标识。因此如果以主叫号码加通话时间拼成的字符串作为关键字段值就能保证对重单的查重精度。1.
文件分拣。
为了避免内存资源的浪费，将网元传来的文件中的话单按照一定的规则进行拆分和分配。如按照主叫号码的最后一位进行分类，可以将网元传来的文件按规则分配到0~9共10个不同的文件夹中。这样在进行查重时就可以避免将所有的文件加载到内存中，实际操作中只需要将主叫号码最后一位对应的文件加载到内存中进行比较和查重。
2.文件排序。
31第三章系统需求分析由于在网元采集到的话单文件中话单是随机排放的，因此话单的排序方式是按照主叫号码的通话时间进行堆排序，其中堆就是完全二叉树。
3.查重原理。
查重技术的关键在于对键树的索引处理。在查重处理中，以主叫号码和通话时间拼成的字符串作为关键字段值建立索引，建立索引的过程中就把重复话单做上标记并完成了查重的过程。在建立索引时，只需要保存文件在内存数组里的下标，通过该下标来引用话单数据，这样的方式大大节省了内存空间。由于同一个主叫号码可能同时存在多条话单，目前用链表的结构存放数组的下标。实现算法如下：
typedefstructkeyData{
intindex;
KEYDATE*nextData;}KEYDATE;typedefstructkeyNode{
char*key;inttype;void*parent;KEYDATE*data;KEYDATE*lastLink;}KEYNODE,*PKEYNODE;
/*关键字段值*//*节点类型*//*父节点指针*//*头节点指针*//*尾节点指针*//*键树插入方法*//*信息节点结构体*/
/*详单在内存数组中的下标*//*下一个节点的指针*//*键树节点结构体*/
PKEYNODEkey_insert(PKEYNODEproot,charval[]，intindex);
/*插入方法。其中proot代表根节点，val代表主叫号码，index为待插入记录数组下标*/
PKEYNODEkey_search(PKEYNODEproot,通过以上的处理，对文件内的重单做上标志。4.6.5键树索引技术在计费系统中的实现
1.文件分拣。
32charval[]);/*键树查找方法*/
北京航空航天大学硕士学位论文文件分拣是指将文件按照一定的拆分规则分成多个文件，在本系统中按照主叫号码最后一位拆分成0~9共10个文件夹，为以后的查重处理和计费处理做准备。2.查重处理。
将采集到的文件按找主叫号码进行分类，并按通话的开始时间进行堆排序。其中键树里存放文件对应的数组下标，然后将详单依次插入树中，如果插入不成功则证明为重单，将其剔除。
3.计费处理。
计费处理就是将每条处理后的详单进行批价处理，计算出费用的过程。具体实现为根据业务分析处理后的详单中的信息查询初用户订购的产品信息，并根据用户的累计使用量批出费用。其中以主叫号码和通话时间拼成的字符串作为关键值字段建立键树索引，如果为重单则剔除，不为重将计费结果累计到内存数据库。
基于计费系统对于查重处理效率和准确性的要求，提出了上述查重算法的实现方法和设计原则，并结合键树索引技术，有效的提高了计费系统的查重效率。目前基于键树索引的查重技术在处理效率上显著并优于之前的查重算法。据统计，从数据库加载600多万的客户信息，并按照键树索引的技术进行查重性能可以达到8000条/秒左右，并且能够保证查找时系统的稳定性。
4.7系统环境
本系统致力于为全球电信运营商提供专业化、一体化、国际化的电信运营支撑服务，打造兼顾用户个性化与产品市场化的综合产品套件是亚信联创对于融合计费系统的基本定位。
1．作为一款高度产品化的软件产品，在专注于面向用户的个性服务与基于需求的体验设计基础上，融合计费系统系统具备极强的适配能力，为其在计费方案制定后实现短期内的快速上线提供保障。
2．系统可部署于各类主流小型机及IBM、HP等多种刀片机，同时支持各类云框架平台上的部署。
333．数据存储可支持Oracle、Mysql等多种主流数据库，服务端支持目前所有主流操作系统，如AIX5.3、HP-UX等。
4．由客户端所提供的基于WEB的界面服务支持多种主流网络浏览器，如IE、GoogleChrome、MozzilaFirefox等。
根据融合计费系统通用技术方案与历次成功上线与部署的实践经验，兼顾系统的高效运行与资源的有效利用，建议系统配置如下：
1.硬件环境。
表6主机后台中间件主机WEB服务器主机数据库主机硬件环境操作系统AIX5.3/HP-UX/SUNOS5.10AIX5.3/HP-UX/SUNOS5.10AIX5.3/HP-UX/SUNOS5.10主机类型IBM/HP/SUNIBM/HP/SUNIBM/HP/SUN2.软件环境。
表7软件项数据库中间件软件环境备注软件及版本ORACLE9ior10gTUXEDO8.1orVisiBrokerTuxedo为oracle公司产品，VisiBroker为borland公司产品Weblogic为oracle公司产品，BESr为borland公司产品Web服务器C++编译器Java编译器报表服务器Weblogic8.1orBESVisualAgeC++6.0JDK1.4orJDK1.5Hyperion8.3.23.客户端。
融合计费系统提供多种基于WEB的界面服务，可支持IE7及以上版本、GoogleChrome、MozzilaFirefox等主流网络浏览器，普通用户可通过浏览器登录系统并实现对
34北京航空航天大学硕士学位论文系统各类常规任务的执行，降低系统管理与维护的难度，使系统的管理与维护更加趋于常态化。
1．产品管理界面：提供产品相关信息数据的维护与管理功能，将对产品数据模型的核心工作由复杂的数据库底层操作转变为简洁清晰的界面配置，有效减少数据准备周期并提高数据准确性。
2．信息管理界面：基于信息管理系统对系统数据进行校验、测试、管理，包括个人、企业、集团客户的资料创建与管理，虚拟网与群组的创建与管理、各层级产品的受理等。
3．账务管理界面：提供对各类资产的管理与操作功能，包括充值、缴费、资产信息查询、资产转移与转换等。
4．系统管理界面：提供基本管理功能如用户管理、权限管理、角色管理等来支持融合计费系统正常运行。
5．话单查询界面：提供对不同业务与支付类型的话单进行查询的功能，话单查询系统对查询界面发出的查询条件进行解析，通过内部生成的查询语句与脚本完成自动查询操作并将结果反馈至查询界面。
4.8本章小结
本章阐述的是系统概要设计。从实际出发考虑问题，并用技术手段解决实际问题。并概述了系统的架构，设计原则、数据结构的融合设计、系统环境等完成了本章的论述内容，突出体现融合计费系统的融合能力。
35第四章系统概要设计方案第五章系统详细设计
5.1详细设计概述
对于融合计费系统而言，计费子系统是其中最重要的子系统。本章是电信融合计费系统的核心部分，在第四章概要设计的基础之上，阐述虚拟运营商融合计费系统离线计费模式下的设计与实现过程。
计费子系统包含采集、解码、业务处理、查重、批价、入库等功能模块，其中入库分为详单入库和错单入库两个部分。除了上述模块外，本章还会介绍当话单文件出错时是如何进行回收的处理，其中相关联的功能模块是错单回收。
本系统的业务流程是将离线采集的原始话单送入解码功能模块进行解析，翻译成
[15]
计费识别的格式XDR（详单）。解析后的详单进行业务处理，包括分析号段归属地、
通话时间、被叫信息、优惠时间段等并对详单进行查重，处理后的详单会匹配相应的业务场景并批出消费金额，最终将批出的XDR入库存储。期间如果出现错单将进行回收并入错单库，以备以后处理。
图10计费数据流图36北京航空航天大学硕士学位论文5.2主要功能模块设计
5.2.1离线采集
综合采集模块基于标准文件传输协议，并针对不同类型网元设备实现计费事件的数据采集，支持SCP、SACP、SMSC、ISMP/DSMP、GGSN、MMSC、SVR、USSD等多种网元设备，能够实现对数据完整性的校验[16]。采集数据类型包括在线计费事件的实时消息与离线计费事件的离线话单。
1.采集实时消息：采用SOCKET通讯方式完成实时消息接收，支持TCP、UDP网络通讯协议。
2.采集离线话单：采用读取离线文件方式完成离线话单采集，支持FTP、FTAM等文件传输协议。
3.完整性校验：对采集获得数据的完整性进行校验，降低由于网络或其他原因导致的数据不完整对业务处理造成的影响。
综合采集是用来连接网元和计费模块的一个桥梁。作用是与网元保持通讯连接，接收从网元过来的消息包，返回给框架接口即可。有在线和离线两种采集方式。目前虚拟运营商主要通过离线采集获取联通下发的详单。主要完成以下功能：
1.2.3.4.5.6.7.8.
提供FTP传输协议的功能支持。提供对象文件名的模式匹配功能。提供传输对象的自动更名机制。提供传输对象的本机和异机备份功能。提供传输对象的剔重功能。
提供对文件系统容量的实时信息采集的功能。提供完整的、详细的、准确的日志记录。为监控系统提供全面的实时的监控数据。
离线采集一般是由网元提供话单的的策略来决定采集的方式。目前交换机有两种提供话单的策略，一是按时间输出话单，二是按文件大小输出话单。相比较而言，第一种策略更加准确，但是受网络、设备等环境的影响容易出现丢单等情况,因此在不紧急的状况下我们选择第二种策略。按文件大小输出话单是指当话单文件的数量达到指
37第四章系统概要设计方案定的大小，就由交换机输出。系统用ftp的方式离线采集这些话单文件，然后将采集完成后的话单文件储存到备份目录中。我们统称网元获取的各种业务使用记录为CDR（calldetailrecord），包括我们经常使用的语音、短信、流量等业务。CDR严格遵循联通侧给定的协议标准，包含通话开始时间、结束时间、通话地点、通话时长、IMSI号、手机号、主叫、被叫等通话信息，其中批价是以通话结束时间作为开始进行处理的，所以如果当我们余额不足时，如果还没有停止通话则还可以持续继续使用一会。
离线采集的流程：1．检查本地路径。
2．根据配置项（远程IP地址，端口，用户名，口令）登录远程主机。
3．根据本地配置远程路径，获取远程路径文件列表，根据配置项（掩码）确定需
要采集的文件。
4．与本地已经采集的列表比较，去掉已经采集的文件。5．执行下载，下载完文件后执行远端操作。6．执行本端操作（shell脚本）。7．写日志、更新已经采集文件的列表。
38北京航空航天大学硕士学位论文图11离线采集流程图5.2.2解码功能模块
作为计费系统处理的第一步，解码模块将不同网元设备的报文处理成内部定义的统一格式（详单）。具体来说，首先综合采集子系统获取用户使用电信业务生成的话单文件，解码模块负责对这些文件进行解码、格式转化、检错、过滤等操作，最终生成计费所需要的标准计费记录XDR，再交给下一级子系统进行处理。
解码模块所具有的功能：
39第四章系统概要设计方案1．解码：原始服务记录的编码方式是多种多样的，根据不同的编码方式，调用相应的解码脚本进行解码，统一转化为内部使用的XDR。目前已知的编码方式有ASCⅡ编码、二进制BCD编码、二进制ASN1.0编码、RADIUS编码、AVP编码。2．格式转化：将解码的结果根据原始话单定义的各字段含义，转化为内部定义数据类型和含义。比如原始字段枚举值与内部定义数据枚举值的转换，格式化原始字段的前缀，后缀等操作。
3．过滤：根据单个字段的特征值进行整条话单的过滤操作。如果为无效话单，则不输出。
4．检错：针对单个字段的特征值对话单记录做检错操作，话单给出错误信息，输出到错单目录。
整个解码子系统从功能模块上讲，可以分成两部分，一是表示原始话单数据结构的协议组件，二是描述话单组成规则的模板。前者是数据层的；后者是业务层的。总体思路是，先建立底层数据结构，然后解码。其中，当原始记录采取BCD编码规则时，将按照按记录长度取数据，然后解码。当原始记录采取ASCII编码规则时，将按行取数据，然后解码。其中，当原始记录采取ASN.1编码规则时，首先将根据ASN.1编码规则，通过协议组件生成树的结构，然后根据模板的配置定位、查询树，获得字段数据。
40北京航空航天大学硕士学位论文图12解码模块流程图5.2.3业务分析功能模块
业务分析模块以离线话单，或者网元发送的实时消息为分析对象，结合静态数据、用户资料、用户订购等信息，分析出用户当前所使用业务的计费场景，用户当前业务可
41第四章系统概要设计方案以使用的产品信息，以标准化服务记录的形式为批价提供数据准备，并根据运营商制定的业务规则对当前业务的使用做出计费以及使用控制，并向用户发送相应的离线或者实时的在线提醒。
业务分析是计费系统的一个重要处理环节，主要作用是处理解码之后的详单记录，根据详单中的数据信息，结合查询到的用户资料、以及计费局数据等信息，完成计费要素的分析工作、得到用户促销信息，最终形成便于进行批价的有效的标准格式服务使用记录。
其中，用户资料是指保存在用户MDB中的手机号、IMSI、用户账号、用户定购的促销等信息，对于用户定购促销，业务分析模块需要根据详单的业务使用信息，判断其是否生效。
另外，计费局数据是指静态数据管理器加载的、已存放在共享内存中的计费系统局数据表中的数据，只有结合这些局数据信息，才能准确的对详单进行计费方号码归整、对端号码归整处理，并正确分析其计费方归属地、对端类型、对端归属地、IP接入、特殊号码、特殊业务接入等，从而得到计费要素[17]。
计费要素是指能确定业务使用场景的、跟详单资费有关的业务使用关键信息，对于不同的业务，我们定义了不同的计费要素，如：语音的计费要素是呼叫类型、长途类型、对端号码类型、特殊接入类型；短信的计费要素是计费方标示、短信类型；
42北京航空航天大学硕士学位论文图13业务分析总体数据流图系统能够支持的功能：
1)支持对用户详单按业务规则进行计费要素分析。2)支持对用户资料定购信息进行查询，得到用户生效促销。3)支持对用户详单按条件过滤。4)支持对用户详单中的号码进行规整。
5)支持对用户详单相关信息做局数据的查询补充，提供对无效详单的错单处理。6)支持对错单、入库详单进行重处理。7)区分网内、网外，漫游。8)长途3秒内不计费。
10)支持多个用户组成亲情网或者集团网，网内通话执行优惠(半价或者免费)。
43第四章系统概要设计方案11)支持累积量提醒。5.2.5查重模块
查重是业务分析的一部分，可以在详单的有效时间防止重单，从而保证计费子系统无重复计费。
查重分为两部分：服务端和客户端。客户端以动态库的形式对外提供查重接口给框架调用，当查重接口被调用后，根据传入的XDR，获取话单的查重要素，生成话单摘要信息，调用框架的路由查询接口，获取要发送的查重MDB（查重服务端）信息，通过配置文件生成的通讯接口，调用SAL访问插件来和查重服务端进行通讯交互。查重服务端主要实现查重功能，接收客户端上发的话单摘要信息，对其进行判断，如果之前有收到过同样的话单信息则认为是重单，否则保存收到的摘要信息。本论文主要阐述服务端查重的设计原理。
查重服务端有两类线程：业务线程（一个客户端对应一个业务线程）和自有循环线程（用于定时将缓存中的话单摘要信息写入文件）。客户端发送过来的查重请求通过业务线程进行处理，下面是业务线程的处理流程：
1．根据请求的话单开始时间，计算对应时间段。2．根据时间段的开始时间，查找对应数据表。3．在对应表中查询，是否有重复数据。
4．如果在3中没有找到重复数据，则将本次的数据插入查询的表中，并写入对应
的缓存中。
5．设置返回结果，返回给客户端。业务规则和要点：
1)查重具有多个规则，如话单开始时间、结束时间、主被叫号码等等，同时，不同规则的查重关键字也可以不同。
2)如果有错单，则说明查重配置有错误，此时，须用户重新配置匹配规则。
44北京航空航天大学硕士学位论文图14查重模块数据流图5.2.5批价功能模块
融合计费系统是一个基于流程线的计费引擎，可根据不同的业务类型或流量配置不同的处理流程，因此在负载均衡与备份恢复机制方面具备极强的处理能力。其中批价依据服务使用的客户资料、使用资源及相应的资费政策等相关信息，对业务分析处理后生成的标准服务使用记录进行资费计算，从而形成数据流或清单文件。同时将批价后的用户服务记录CDR送给ABM服务，由ABM服务累加至用户的账本、信用度上。最后形成有效的标准格式的计费服务记录，传递给账务系统进行汇总。
批价支持目前的所有业务，包括周期性事件、实用性事件和一次性事情。其中使用性事件一般来讲就是我们平时使用的语音、流量、短信及一些增值业务等。而周期性事件一般是指月租事件。
批价的流程的步骤如下:1．接收事件。
2．调用定价计划查找模块查找定价计划。
3．调用定价计划执行模块执行定价计划(过程中会调用累积量管理模块)。
45第四章系统概要设计方案4．生成账单批价事件。
5．调用定价计划查找模块查找定价计划。
6．调用定价计划执行模块执行定价计划(过程中会调用累积量管理模块)。7．事件的事务控制。
批价拥有自己的引擎，批价引擎是根据用户所定购的产品信息，结合产品对应的资费定价策略、用户资料、账务资料，对业务分析后的标准服务使用记录（CDR）进行资费计算。根据用户业务的使用情况完成资费的计算,并计算出最终的清单文件或数据流。同时将批价后的用户服务记录CDR费用信息,资源量信息,告警信息等送给内存数据库（MDB），由MDB完成费用,资源量部分的累加。最后形成有效的标准格式的计费服务记录，传递给账务系统进行汇总同时供外围系统查询。
批价引擎可以对计费所支持的所有业务完成计费。因为用户的服务使用记录在业务分析处理后会生成相应的条件表达式，批价引擎根据条件及用户订购的产品信息和使用的累积量寻找相应的资费定价，对CDR完成计费过程。所以批价引擎不局限于具体业务，是一个融合所有业务（如语音、流量、短信、CDMA、MMS、IP、VC等）的计费过程。
其中在批价的过程中，需要遵循计费优惠信息透明化的基本原则，系统支持记录优惠的金额并提供相关证据，以便在之后详单中体现，使用户可以从详单中查到自己使用的优惠信息。其中优惠定义在产品里，产品不但包含一些优惠政策，还包含相应资费的。简而言之，产品信息中既包含服务又包含资费政策。
关于如何进行优惠处理，需要先在批价中建立一个资费模型，模型可配置所有优惠的条件、计费科目及计费类型等因素。批价引擎是通过配置的模型来实现优惠，通俗的说资费配置的模型可以体现资费的定义、封装及构成的形式，而相对应的解析模型则用来描述批价过程中的条件判断。两者共同描述资费信息在计费中的作用和组合方式。
资费不仅仅在批价引擎中可配置，在综合客服（CRM）及账务处理和账务管理等子系统都可以配置相应的资费信息。但是资费配置在批价引擎中是相对独立的，不包含其他领域的资费配置。计费子系统只配置批价所使用到的不同业务单次使用的资费信息，而向开通业务、停机保号、月租等其他的计费事件则交给其他子系统受理。统一体现在
[18]
46北京航空航天大学硕士学位论文所有的配置信息由统一的管理界面配置，此不同领域配置的资费信息，是相互关联而又独立存在的。
具体而言，批价资费信息和其它资费信息在计费系统中的处理处于不同的阶段，计费子系统与CRM通过资费定义接口和用户资料接口来建立相关连接，从综合客服子系统取得一些批价所用的重要参数，如用户资料。在与外围系统相连接时，用户资料接口必须包含计费的全部内容：如用户类型、产品信息及其它附加信息等。而资费定义接口包含CRM所必需的产品套餐和可预定义的免费资源。由此一来，系统管理通过接口表来封装免费资源，而同时计费子系统也实现了用户资料的个性化批价。使计费子系统和CRM形成关联，从而实现了业务的连贯。而资费信息在账务中的处理是已批价引擎处理后的合账科目作为接口，对批价处理过的资费信息进行再处理。
图15批价引擎定价域设计图47第四章系统概要设计方案批价引擎负责根据用户定购产品,使用其对应的资费定价计划,对经过业务分析计费要素标准化后的用户服务使用记录,完成基本费率计算,免费资源处理,累计量优惠等优惠处理,并将最终费用,累计量信息更新回MDB,同时将批价结果写入XDR,送给后续账务系统合账处理。
5.2.5分发入库功能模块
分发入库处理批价后的话单文件，将存放在其中的话单数据装载到目标话单表中。具体是指，从话单文件读取一条话单，根据一定的分发策略和配置，通过解析话单内容，生成要入的表名和数据库名，并将该话单插入到该话单表，和对应的重批表中。对于入库过程中入库失败，或发生异常的话单将打错单。简而言之，详单入库的是对详单数据进行有效性和完整性的校验。
图16分发入库数据流图分发入库提供的功能有：1.详单分发。
根据详单字段内容，分发策略以及配置文件中的相关配置生成一个详单表名，这个过程叫做详单分发。详单入库时详单入在这个详单表中。详单分发的具体流程：
1)判段是否是错单
通过话单里TREAT_FLAG字段判段是否为错单（非0为错单）。若为错单，通过SO_REDO_XDR_ERR_DEF获取是否回收的标志（CYCLE_LIMIT）。
48北京航空航天大学硕士学位论文2)自回收。
对于分发,入库模块打的错单,在分发模块支持自回收。在
SO_REDO_XDR_ERR_DEF表中配置CYCLE_LIMIT=4表示该错误码需要分发模块自回收,程序将清除原来的错误信息,重新分发入库。
3)
过滤。
过滤不入库的话单，将IS_FILTER的值设为1。如下表
表8序号1类型测试话单过滤不入库话单分表规则特征test_cdr_flag=1TREATE_FLAG=12不入库的错单并且代码写死CYCLE_LIMIT=1找不到3CYCLE_LIMIT的错单TREATE_FLAG=1并且代码写死CYCLE_LIMIT未知过滤方式lua脚本中配置4)获得分表。
错单和正常话各自传入自己的参数获取库和分表信息，分别填入话单的database_name,table_name。
由于子话单需要入库，以上过程会作用到所有子话单。
49第五章系统详细设计图17详单分发流程图2.详单入库。
利用数据库的外部数据导入工具语句，有选择性的将详单字段以及一些临时才能决定取值的字段插入到分发生成的目标详单表中，这个过程叫做详单入库。入库时，直接用详单分发时获取的目标详单表名直接代替%TABLENAME%即可。入库速度是非常重要的性能指标，本模块支持多线程入库，若有必要，开启多线程，可进一步加快入库速度。
3.详单分拣。
一个详单文件中每一条详单在入库过程中，将会经过完整性检测和有效性检测，来判定是否是错单（错单包含重单），还是正确详单。根据一条详单限定的最大长度、最小长度和字段总数对详单进行检测，称为完整性检测。根据详单字段的具体取值是否符合建立详单表时设置的各种约束，如主键约束，非空约束等，来检测详单是否有效，称
50北京航空航天大学硕士学位论文为有效性检测。经过详单分拣，那么一个详单文件将会分解成为错误详单文件，正确详单文件。
4.错单处理。
根据入库过程中对详单内容和相关配置以及各种约束的校验，来分辨出错误详单，连同出错原因及错单所在的源文件名等相关信息，写入错误详单文件。
出错原因的来源有三处：1)ORACLE返回的错误码。2)OTL返回的错误信息。3)程序定义的错误码。5.详单统计。
将详单文件名，文件中详单总数，正确详单数，错误详单数，重复详单数，入库开始时间，入库结束时间以及其他细节信息写入详单统计信息文件。
格式:
fileName:<>;total:<>;correct:<>;error:<>;dup:<>;earlyTime:;lastTime:;beginTime:<>;endTime:<>; 考虑到信控和详单一致性的要求，入库程序需要增加进度记录功能[19]。在完成详单文件入库的同时，需要记录本文件中最大的累账时间到入库进度表中。在入库程序异常情况下，账务的告警导出进程根据该进度进行判断，是否需要把产生的告警信息导出到账务管理子系统。5.2.6错单回收功能模块 错单回收子系统主要对计费系统中各阶段（如解码，业务分析，批价）由于某种原因所产生的错误、详单进行入库，编辑，重处理的一个过程。通过修正某些错误原因，对错误换单的重新进行业务处理，可以最大范围的减少客户的话费损失。 计费系统的各业务模块在处理详单的过程中都会产生各种原因导致的错误详单，并且以详单文件的形式输出到指定的磁盘文件。回收系统的入库模块会监视这些磁盘目 51第五章系统详细设计录，当有错单文件待处理时，入库模块将这些错单文件的数据录入的数据库系统中，并备份原错单文件。 在重处理话错误详单之前，可以利用前台编辑界面对错单进行筛选，比如按错误类型，业务类型，生成时间等等条件。 错单重处理的过程，就是在修正某些错误之后，错单出库模块将错误详单从数据库系统中提取出来，组成计费模块能够识别的详单文件。错单重处理的出库模块是根据预先定义的控制信息将指定错误详单进行出库的。 图18错单回收数据流图1．错单入库：错单入库后台程序监视各计费业务处理模块的错单输出目录，当发现可用的错单文件时，入库模块根据错单文件结构定义表的描述，将错单文件录入到数据库系统中。 2．入库分析：对于本地错单（不包括本地上发拦截的错单），其错单文件的格式和xdr的详单格式一致，所以可以直接把对应的字段入到错单表中(错单表格式见附录)； 52北京航空航天大学硕士学位论文对于部中心下发错单和本地上发拦截的错单，由于其格式是上发（下发）详单格式，需要从详单表中取出对应详单数据再插入到错单中。 3．前台控制：通过使用前台界面，根据用户指定的条件，选择若干错误话单项插入到重处理表中；并且根据条件，确定是否需要删除错单表中的记录；记录操作日志，并将控制信息记录到控制表中。 4．错单出库：根据需要导出的字段定义，错单出库模块，将错单信息表中的错单以详单文件的形式输出。如果需要删除已经出库的详单，则将错单信息表中的错单删除。 5．错单统计：出库模块将记录已经出库的错单数到错单出库统计表中。 6．文件过滤：根据规则，有些业务模块输出的错误话单文件不需要回收的，需要做过滤处理。 5.3本章小结 本章主要阐述了融合计费系统核心计费子系统整个的详细设计，并介绍了计费子系统中关键模块的实现。 53第五章系统详细设计第六章系统测试 6.1系统测试概述 公司一般会有测试和生产两个环境并分别部署，在项目完成后需要先在测试环境测试，通过后再同步到生产环境。而系统上线之前一般都会经历提测-测试-发现bug-提测的一种闭环方式，直到问题解决并且系统稳定。 对于计费系统的测试往往先分场景然后进行全业务测试[20]，就是模拟不同的场景查看配置及系统是否有异常。目前系统有语音、短信、流量三大业务，模拟的场景有本地主叫无长途、本地主叫省内长途、主叫省内漫游无长途、被叫省内漫游国际长途等，模拟的业务有开户、业务变更、过户、补办卡、停机保号、取消停机保号、停机、复机、销户等业务等，下面将分别对场景和业务进行测试。 6.2场景测试 6.2.1测试前准备 1.主叫号码（测试号码）：17092870035（0531）充值200元Custid：21128400000244Acctid：31283000001846Userid：412840000006082.被叫号码：170928700356.2.2用户订购的套餐 1.迪加平衡卡89元（周期性主产品）。2.流量可选包20元（一次性）。3.语音可选包10元（一次性）。6.2.3构建话单 此话单为济南用户（0531）打给石家庄（0311），构建话单请考VOP–Interface–Specification-File-Interface-Volume-0.5.0.pdf。如下所示： 54北京航空航天大学硕士学位论文6.2.4测试步骤 1.将构建的话单放到解码中的decode文件目录下。2.启动解码、批价、入库流程。6.2.5测试结果 1.检查免费资源是否都有赠送，（方式：免费资源的赠送是通过新账期首话激活触发赠送）查看语法：select*fromCAbmFreeRes；请查看amount字段，测试结果如下所示： 2.再次跑话单后：select*fromCAbmFreeReswhereacct_id=31283000001846；测试结果：用掉套餐里面的2分钟，120秒（具体时耗请查看用户订购的套餐）。请查看used_value字段，测试结果如下所示： 1）检查用户订购的产品实例化的生失效时间是否正确。特别是可选包的生命周（生失效时间为一个月）只能为一个月。其中credit_flag字段：0代表信用度账本。 2代表 55第五章系统详细设计2）检查是否可以正常冲销，即确认CRM通过信管上发的资金账本和信用度账本ID在计费侧是否可以正常冲销。查看语法：select*fromCAbmCreditwhereacct_id=31283000001846；请查看deduct_value_cur字段，测试结果如下所示： 由于优先级的问题，话单的资费先扣免费资源，再冲销，测试结果：由于此话单没有消耗完免费资源，所以冲销（看deduct_value_cur）为0。冲销的过程是先扣账本再扣信用度，其中credit_flag字段：0代表信用度 2代表账本。 3）累账是否正确。查看语法：select*fromCRasResBillwherepay_acct_id=71411000008904;--找下面的bill_id，如下所示： select*fromCRasUsageBillwherebill_id=214;--查看累账，如下所示： 需要查看的字段：accumulate_value（累计时长）和primal_fee（累计的费用）是否为测试话单的累计。 测试结果：由于此用户没有使用完此套餐的免费资源，所以值为0。 4）检查语音详单表中的主叫、被叫、科目、费用、长途类型、漫游类型、到访地是否正确（请通过VOP-Interface-Specification-File-Interface-Volume-0.5.0.pdf\\文件服务\\话单文件\\文件格式\\移网语音来校验） 56北京航空航天大学硕士学位论文6.3全业务测试 6.3.1功能描述 业务场景是通过CRM（客户关系管理系统）开户、订购套餐并办理不同业务来进行全业务测试。目前计费系统拥有的业务有开户、业务变更、过户、补办卡、停机保号、取消停机保号、停机、复机、销户等业务。测试时需要对每种场景下的语音、流量、短信等三种业务进行测试。其中月租指的是每月订购套餐的租金，而超出套餐外的费用会扣预存的费用。6.3.2测试用例 办理不同业务并订购不同套餐，对一些业务冲缴一部分金额，模拟冲销测试。 表9模拟测试用例表月租7959202039缴费10010030050预存退费姓名号码17096820944170968203071709682154117096820307170968214261709682184217096820027170968208101709682154117096820944IMSI460016829800021460016829800024460016829802025460016829800024460016829802032460016829802031460016829800026460016829800023460016829802025460016829800021办理业务订购套餐test01test02test03test04test06test07test08test10test11test12***79元开户***59元流量包20业务变更元语音加油包20元过户补换卡停机保号取消停机保号复机销户***59元***19元资金不转移3010022.4757第五章系统详细设计test13170968209624600168298000196月办理停机保号***19元1006.2.3测试条件 1.用户符合本账期的出账要求。2.CRM办理不同业务。3.用户订购了不同套餐。 6.2.4测试步骤 1.造话单，话单的制做严格遵守《中国联通虚拟运营开放平台(VOP)API接入规范文件接口规范》。 2.将造好的话单放在计费子系统解码的输入文件下，启动业务流程。6.2.5测试结果 表10冲销账本表通话姓名套餐内test01test02test03test04test06test07test08-1.81.8---0.9超套餐11.1--60-8.1-短信套餐内-0.20.20.2--0.1超套餐0.2----0.6-流量套餐内-0.6-0.6-0.315.027超套餐0.62-307.43---59+30-超-59-20100-59-20-超50-39100-79-超100-5959+20+超20+59+超3979+超5928.2711012.34128.2711012.3418月批销预期结果账本余额100-79-超账单79+超说明（预期）9.08实际9.0858北京航空航天大学硕士学位论文test10test11test12test130.91.8------0.10.2------0.3-------100-5959414150-19-超余额-519+超59595由于测试业务比较多，这里就不一一介绍。 6.4本章小结 在本章我们主要对计费子系统的固定费用和业务场景进行了测试，分别介绍了测试功能、测试用例、测试条件、测试步骤并最终得出一个结果。 59第五章系统详细设计总结和展望 在经过深入的调研，设计和开发后，使我对整个的互联网软件开发过程有了一定的了解，并深入的了解了整个软件工程的思想。对于C++在开发服务端软件编码上有了较多的实践，其中处理了很多实际需求所带来的问题。提高了自己对于实际问题的分析和解决能力以及与团队写作的能力也得到了大大的提高。 论文主要阐述的是如何利用设计一个满足虚拟运营商特色业务的融合计费系统，其中采用了C++、Lua、Oracle多个技术来解决实际问题。当前我们已经开发完成，并已经在线上运行12个月以上，从整体效果来看还是符合预期的。作为公司的一款产品，其实际效果已经超出预期。 项目是一个从无到有的过程，所以要完成的不仅仅是开发工作，还有开发完后的设施维护工作。当前不仅仅在探索业务，同时也在探索新的商业模式。 在线上运行的这段期间和用户反馈的意见来看，我们的应用满足了大部分用户的使用场景，并且也给公司带来了一定的盈利。 由于作者的学识和精力有限，论文中还存在一些不足： 1.论文主要介绍了系统的整个的架构和设计实现，但是对于测试方面并没有给予过多的篇幅，同时由于移动互联网竞争激烈，也不允许我们做更多的测试，来探索整个系统的极限。 2.本系统月末出账的时候还存在很多呆账、坏账的情况，所能做的只能是手动批价并重新计费处理，在这一环节上还待于研究一套机制，能够实现自动化的处理。 3.在整个交互设计上，可能有些地方并没有做到人性化的实现，后期随着版本的迭代我们会考虑到加入一些更人性化的东西进去。 60北京航空航天大学硕士学位论文参考文献 [1]孙砚，福建电信在线计费系统项目可行性研究［J］，南京邮电大学，2012[2]陈大洲，广东电信融合计费系统的建设［D］，华南理工大学，2011[3]项静文，上海电信业务融合计费系统设计［R］，大连理工大学，2012 [4]张钰，基于B/S模式下电信运营融合计费系统的设计与实现［D］，南昌航空大学， 2013 [5]黄兵杏，全业务融合时代A省电信运营支撑系统建设研究［D］，华中科技大学， 2012 [6]慈晓丽，数据业务计费融合设计［D］，北京邮电大学，2012[7]邓昀，计费批价系统的设计与实现［J］，华北电力大学，2013[8]曾米莎，3G环境下的在线计费系统研究［D］，南京邮电大学，2013[9]李惠林，电信计费批价管理信息系统的研究［M］，西安石油大学，2013[10]叶陈刚，翟健勇，海外上市电信企业内部控制体系研究—以中国网络通信集团公 司内部控制为例［R］，对外经济贸易大学，2013 [11]李红平，李仲国，电信基础设施共建共享模式探讨［R］，2010 [12]Khandual.PerformanceMonitoringinLinuxKVMCloudEnvironment.[M].Cloud ComputinginEmergingMarkets(CCEM),2012IEEEInternationalConferenceon,2012 [13]McKinley.H-RMC:AHybridReliableMulticastProtocolfortheLinuxKernel. [M].Supercomputing,ACM/IEEE1999Conference,2010 [14]Manjikian.ImplementationandperformanceassessmentofLinuxdevicedriversfor thecoldfireMCF54418microcontroller.[J].2013 [15]HongLan.ResearchandDesignofConcurrentWebServeronLinuxSystem. [M].ComputerScience&ServiceSystem(CSSS),2012InternationalConferenceon,2012 [16]LanYuqing.TheResearchofPerformanceTestMethodforLinuxProcessScheduling. [J].2012 61第五章系统详细设计[17]Ke-FeiLiu.Co-competitiongameanalysisofmobilecommunicationmarketafter companyrestructuring.[M].MachineLearningandCybernetics(ICMLC),2012InternationalConferenceon,2012 [18]CarlaM.Pugh.ARetrospectiveReviewofTATRCFundingforMedicalModeling andSimulationTechnologies.[J].SimulationinHealthcare:TheJournaloftheSocietyforSimulationinHealthcare,2011 [19]HiroyukiODAandEtsuroOKUYAMAAkishimaLaboratories(MitsuiZosen)Inc. 1-50,Tsutsujigaoka1-chome,Akishima,Tokyo196-0012,Japan [20]MinLi.CooperativeStorage-LevelDe-duplicationforI/OReductioninVirtualized DataCenters.[M].Modeling,Analysis&SimulationofComputerandTelecommunicationSystems(MASCOTS),2012IEEE20thInternationalSymposiumon,2012 62北京航空航天大学硕士学位论文致谢 历经半载，从一开始论文的选题到搜索材料，从写开题报告到完成初稿和反复修改。经历了痛苦、挣扎、彷徨和喜悦。如今，伴随着论文的最终成稿，一切也都烟消云散，甚至还有一些成就感。 首先要向我的导师杜孝平老师表达最真挚的谢意，他的悉心指导和亲切关怀对我完成这篇论文起着至关重要的作用。他严肃的科学态度，严谨的治学精神，精益求精的工作作风，深深地感染和激励着我。最重要的是导师的这些优秀品质也会潜移默化的影响着我，他不仅给予我学术上的成就，更重要的是他将会影响我今后的工作和生活。在这里再次向我的导师黄坚导师说一声：“老师，您辛苦了”。 同时，我也要向我的家人表达深深的谢意，感谢你们在生活上的帮助和无声的支持，你们就像一座灯塔，照亮了我前进的方向。 最后，诚挚地感谢为评阅本论文而付出辛勤劳动的各位的学者和专家，感谢你们白忙之中能抽出时间审阅我的论文。 63 因篇幅问题不能全部显示，请点此查看更多更全内容