《Telfort20融合计费项目总体设计方案_V020.docx》由会员分享，可在线阅读，更多相关《Telfort20融合计费项目总体设计方案_V020.docx（225页珍藏版）》请在三一办公上搜索。
1、文档名称文档密级2 Huawei Technologies Co. Ltd.华为技术有限公司Product version 产品版本Confidentiality level密级 秘密Total pages：共225页Telfort 2.0项目总体技术方案Prepared by 拟制 Telfort 2.0分析设计组Date日期yyyy-mm-ddReviewed by 评审人Date日期yyyy-mm-ddApproved by批准Date日期yyyy-mm-ddAuthorized by签发Date日期yyyy-mm-ddHuawei Technologies Co.， Ltd.华为技术有
2、限公司All rights reserved版权所有 侵权必究Revision record 修订记录Date日期Revision Version修订版本CR ID / Defect IDCR号Section Number修改章节Change Description修改描述Author作者2008-09-120.10根据各专题的写作和检视结果，初稿合并完成Telfort 2.0分析设计组2008-10-040.20根据客户CR修正部分描述。1.DC 模块将被客户的CACS替换2.FM将被KPN系统替换部分功能的修改1、 帐户优惠方案的修改2、 接触管理的修改和批注（与IPCC部分信息未达成一致
3、）3、 MDS方案修改4、 Real time charing5、 修改订单落地方案，增加设计方案和增加订单查询及订单修改6、 补充SCP与Rating&Billing集成方案（语音计费、VMS计费以及AOC等业务）7、 预付费生命周期管理增加功能分解：1、扫描件的存储和管理Telfort 2.0分析设计组Distribution LIST 分发记录Copy No.Holders Name & Role 持有者和角色Issue Date 分发日期1yyyy-mm-dd2yyyy-mm-dd3yyyy-mm-dd4yyyy-mm-ddCatalog 目 录Telfort 2.0项目总体技术方案1
4、Huawei Technologies Co.， Ltd.1Revision record 修订记录2Distribution LIST 分发记录21项目背景111.1Telfort现状介绍111.1.1Telfort Mobile111.1.2Telfort internet121.2目标业务131.3目标用户数141.4实施阶段152系统总体描述（0级视图）152.1系统总体构架152.1.1服务控制层162.1.2计费帐务层162.1.3客户服务层172.1.4版本配套关系182.2系统外部接口描述（暂不写作，将引用架构与接口相关交付内容）182.3系统物理组网（暂不写作，将引用物理部署
5、内容）192.3.1系统总体物理组网193系统方案设计（1级视图）193.1Rating&Billing与PC 产品定义配合193.1.1业务需求描述193.1.2系统功能分解分配203.1.3接口说明203.1.4性能要求203.2Rating&Billing与帐务管理提供已批价CDR、Bill配合213.2.1业务需求描述213.2.2系统功能分解分配213.2.3接口说明213.2.4性能要求223.3Rating&Billing与CC资料接口223.3.1业务需求描述223.3.2系统功能分解分配233.3.3接口说明253.3.4性能要求253.4预付费和后付费互转253.4.1业务
6、需求描述253.4.2系统功能分解分配263.4.3接口说明283.4.4性能要求283.5Rating&Billing支持帐户级优惠283.5.1业务需求描述283.5.2系统功能分解分配283.5.3接口说明303.5.4性能要求313.6预付费用户的实时销帐313.6.1业务需求描述313.6.2系统功能分解分配323.6.3接口说明353.6.4性能要求353.7后付费用户的信控处理方式353.7.1业务需求描述353.7.2系统功能分解分配363.7.3接口说明363.7.4性能要求373.8NP计费匹配方案373.8.1业务需求描述373.8.2系统功能分解分配373.8.3接口说
7、明383.8.4性能要求393.9Rating与SCP集成方案393.9.1业务需求描述393.9.2系统功能分解分配393.9.3关键计费业务流程403.9.4接口说明423.9.5性能要求423.10MDS与RATING的配合423.10.1业务需求描述423.10.2系统功能分解分配433.10.3接口说明443.10.4性能要求443.11E-Shop方案设计443.11.1业务需求描述443.11.2系统功能分解分配443.11.3业务流程说明483.11.4接口说明493.11.5性能要求503.12营销方案设计503.12.1业务需求描述503.12.2系统功能分解分配513.1
8、2.3业务流程说明613.12.4接口说明613.12.5性能要求623.13合同相关方案设计633.13.1业务需求描述633.13.2设计思路633.13.3系统功能分解分配641. 扩展用户自定义条件，增加合同期，当合同期不同时可以使用不同的优惠；663.13.4业务流程说明693.13.5接口说明693.13.6性能要求693.14Number Porting 流程693.14.1业务需求描述69Number Porting流程分成以下3个流程693.14.2系统功能分解分配70Ecare需要调用接口部件封装的罚金查询接口，显示用户需要缴纳的罚金77NP.NPMS.FR.001系统管理
9、支持NPMS链接入口773.14.3COIN消息定义843.14.4Port In订单流程定义881)活动1：OLO Validate 请求901)活动1：Transit Operator 请求932)活动2：Transit Operator 应答931)活动1：Ready 2 Release 请求941)活动1：老号码废弃942)活动2：Port In号码服务开通953)活动3：Port in号码合同生效954)活动4：计费激活951)活动1：发送同步原始运营商请求951)活动1：Transit Operator 同步请求962)活动2：Transit Operator同步应答971)活动1
10、：OLO握手同步请求接口973.14.5Port Out订单流程定义981、资源有效性校验992、用户有效性校验1003、业务数据有效性校验1001)活动1：Transit Operator 请求1012)活动2：Transit Operator 应答101（Ready To Release在DNO侧做了哪些事情需要现场确认），102COIN相关消息：109102COIN相关消息：107,1081031)活动1：Transit Operator 同步请求1032)活动2：Transit Operator同步应答1031)活动1：号码销户1032)活动2：资源管理状态更新1043)活动3：计费通
11、知104COIN相关消息：1101043.14.6Porting请求修改和取消处理方式1043.14.7Porting准备/同步通知接收处理1083.14.8Porting请求的状态定义1103.14.9Porting请求的超时处理方式1133.14.10SP/ESP的Porting处理方式1133.14.11Phase1的架构方案114（4）NPMS修改程序或配置从华为的通道读取数据,进行处理1163.14.12接口说明1173.14.13性能要求1263.15CART系统替换方案1263.15.1业务需求描述1263.15.2系统功能分解分配1273.15.3业务流程说明1383.15.4
12、接口说明1413.15.5性能要求1423.16扫描件存储和检索1433.16.1系统架构示意图1443.16.2业务处理流程1463.16.3OSMS系统介绍1473.16.4内部接口1473.17资源管理方案1483.17.1号码和SIM卡管理流程1483.17.2Voucher管理流程1533.18订单落地方案设计1563.18.1业务需求描述1563.18.2设计思路1563.18.3系统功能分解分配1573.18.4业务流程说明1603.18.5接口说明1613.18.6性能要求1623.19充值方案1623.19.1DTU充值1623.19.2充值卡充值1873.20IPCC与CC
13、BS集成专题1903.20.1数据库建库说明1903.20.2工号、权限统一管理1903.20.3统一订单、服务请求、统一登录1943.20.4客户接触信息记录和查询（刘波、荀礼勇）1963.20.5知识库方案(内外网知识库)1983.21BI与CCBS集成专题2003.21.1传输方式2003.21.2传输协议2003.21.3传输过程2003.21.4抽取周期2013.21.5接口单元编码2013.21.6文件命名规则2013.21.7接口文件格式-数据文件2023.21.8接口文件格式-校验文件2023.22Telecom manager方案2033.22.1实现思路2033.22.2设
14、计方案2033.22.3内部接口2053.23帐户优惠方案设计2053.23.1业务需求描述2053.23.2设计思路2053.23.3系统功能分解分配2053.23.4业务流程说明2063.23.5接口说明2063.23.6性能要求2063.24收入保障 (与Ectel讨论以后再补充)2063.25VAS Real Rime Charging&Provisioning 解决方案2073.25.1业务需求描述2073.25.2设计思路2083.25.3系统功能分解2093.25.4业务流程说明2103.25.5接口说明2103.25.6性能要求2104系统内部各部件的接口汇总说明（待完全定稿后
15、汇总）2114.1系统内部各部件的接口说明2114.1.1CC/POS部件接口说明2114.1.2E-care/E-shop部件接口说明2114.1.3订单接口说明2114.1.4产品模块接口说明2114.1.5INV部件的接口说明2114.1.6Rating&Billing接口说明2114.1.7MDS部件接口说明2114.1.8PRO部件接口说明2114.1.9IPCC部件的接口说明2114.1.10SCP部件的接口说明2124.1.11报表部件的接口说明2125系统包需求及其需求分解2126附录：计费和服务开通接口上下文环境2136.1CDR Domain2136.1.1Interfac
16、e Context Diagram2146.1.2Issue2146.2Provision Domain2156.2.1Interface Context Diagram2166.2.2Issue2166.3Real-time charing Domain（需要根据DA决议修改）2176.3.1Interface Context Diagram2186.3.2Issue219Keywords 关键词：Telfort、CCBS、CBS、总体设计方案Abstract 摘 要：本文档主要描述Telfort 2.0融合计费项目的系统构成、部件部署、关键业务流程和方案、内外部接口说明，以及系统整体的需求
17、包和需求分解。在结合Telfort 2.0的外部系统环境进行方案分析和设计的基础上，本文档侧重在Huawei解决方案内部的设计说明，Huawei解决方案与Telfort外部系统的方案将在与局方的系统架构和接口文档中进行说明。List of abbreviations 缩略语清单：Abbreviations缩略语Full spelling 英文全名Chinese explanation 中文解释TF 2.0Telfort 2.0 projectTelfort 2.0项目CCBSCustom Care & Billing System综合客户管理系统，包括Custom Care、Billing&B
18、ill Formatting、AR、DC、PC、PRM、Mediation、Provision、InventoryBOSSBusiness & Operation Supporting System业务运营支撑系统，是中国移动的称谓。文中指CCBS。CCCustom Care客户关怀管理模块ARAccount Receivable应收款管理模块DCDebt Collection催欠管理模块PCPricing Catalogue产品目录管理模块BFBill Formatting帐单格式化模块ProProvision服务开通模块MDMediation采集预处理模块InvInventory资源管理模
19、块DWHData Warehouse数据仓库CBSConvergence Billing System融合计费系统，包括预付费和后付费OCSOnline Charging System在线计费系统EBITDAEarnings Before Interest, Taxes, Depreciation and Amortization利息、税收和折旧、摊销前收入TTMTime to Market上市时间TCOTotal Cost of Ownership总拥有成本SMESmall Medium Enterprises中小企业ESPEnhanced Service Provider增强服务提供商1
20、项目背景1.1 Telfort现状介绍Telfort 是于1997年在荷兰成立的一家独立移动运营商，他将自己定位于移动市场的挑战者。在2005年Telfort被荷兰最大的固定/移动运营商KPN收购。收购后两家的网络架构进行了整合，Telfort将会把其网络迁移到KPN。今天Telfort已经成为KPN整体品牌下的挑战品牌。Telfort将作为关注价格细分市场的增强服务提供商（ESP），这是KPN对Telfort品牌和历史定位。同时，KPN在2006年收购了荷兰的Internet服务提供商荷兰Tiscali（international Tiscali group的一部分），并重新进行品牌包装交由
21、Telfort管理和运营。因此，Telfort同时包括Mobile和Internet业务。为提高Telfort的EBITDA，同时也为了支撑其在Mobile和Internet业务的融合以及对应组织结构和人员进行调整，Telfort需要在其IT支撑系统上进行改造，目标包括有：l Faster time to market（TTM）l Lower TCO of IT本次的支撑系统范围为融合的CRM & Billing系统，也就是Telfort 2.0项目。（注：在此前，有Telfort 1.0项目，只涵盖预付费业务部分，目前尚未实施，将被同时包括在Telfort 2.0中，所以Telfort 2.
22、0是个预付费融合、Mobile/Internet融合的CRM & Billing解决方案）1.1.1 Telfort Mobile目前的Telfort移动基础设施的特点是： l 大量的应用l 众多专有接口l 一个复杂的系统架构l 系统支离破碎，数据冗余在多个系统，数据复制不总是完全正确复制复杂系统的堆栈含有大量的冗余功能，例如不同的系统（大致相同的功能）是用于消费者和企业的部分，这导致了以下结果： l 成本高l 需要较多人力（操作，质量保证，投诉处理） l 系统维护复杂l 产品的灵活性低，响应市场时间长l 开发新产品/服务时需要复杂的，定制的接口开发l 没有E2E服务保证 l 收入保障流程复杂
23、l 客户操作复杂，很难实施有效的客户的自助服务Telfort当前移动业务支撑系统架构如下（由欧洲厂商Capgimini等提供管理服务）：1.1.2 Telfort internet由于历史的原因荷兰Tiscali的Customer Care 和billing系统被外包给Tiscali services管理，Tiscali services的平台为多个国家服务，外包合同将在09年6月份结束，开发商为：l Billing: Geneval CRM: Siebel1.2 目标业务Telfort 2.0需要支撑的（主要）业务包括如下，其中，移动业务中包含预付费和后付费业务，对于Internet业务，仅
24、仅包括后付费业务：l Mobile Voice services(Prepaid and Postpaid)o Voiceo Voice Roamingo Voice Maill Mobile Data services(Prepaid and Postpaid)o GPRSo GPRS Roamingo WAP/WAP Pusho SMSo SMS premiumo MMSo SMS Roamingo MMS Roamingo Content Servicel Internet Access services(ADSL, VDSL)(Postpaid only)l Internet VoIP
25、 services(Postpaid only)l Internet Value Added services(Postpaid only)o eMailo Homepageo Domain registrationo Key man /F-secure另外，从客户的角度看，Telfort 2.0需要支持如下类型客户：l Consumerl Business（SME only），对于具有复杂组织结构、特殊网络业务类型的集团客户不在支持的范围之内。再有，由于Telfort本身作为KPN的一个增强服务提供商，所以原则上针对其它ESP、MVNO业务的支持不在Telfort 2.0范围之内，但由于考虑
26、到网络和系统的变迁方便，针对话单处理、服务开通部分可能会涉及我们的Mediation和Provision，需要参考更详细的方案设计内容。1.3 目标用户数整个系统需要支撑到Telfort今后5年的业务发展（即从2009年到2013年），在这个过程中，系统需支撑的用户数预计如下表所示：200820092010201120122013Subscribers eoyeoyeoyeoyeoyeoyActive prepaid subscribers920,000930,000940,000940,000940,000940,000Registered Pre paid subscribers1,150
27、,0001,150,0001,160,0001,170,0001,170,0001,170,000Active postpaid subscribers875,0001,000,0001,100,0001,175,0001,225,0001,250,000Active internet customers383,000459,700505,650556,200611,800674,000Active Subscribers (Total)2,178,0002,389,7002,545,6502,671,2002,776,8002,864,000Active voip subscribers12
28、0,000140,000170,000200,000240,000288,000注：其中的Active voip subscribers已包括在Active internet customers中了。其他更详细的信息请参见RFQ材料中的RFQ A5 Sizing final v1.1.pdf。1.4 实施阶段按照业务和网络情况考虑，整个项目将会分三个阶段实施：l 第一阶段（phase 1）：Mobile Postpaid Service支持，在迁移旧有后付费用户和业务系统功能的同时，Telfort 2.0需要支持新发展的移动后付费用户。此时，Telfort 2.0将和原有的预付费系统、Inte
29、rnet系统共存。l 第二阶段（Phase 2）：在支持后付费的基础上，迁移预付费。此时，所有的移动用户将由Telfort 2.0支持，但与旧有的Internet系统共存。l 第三阶段（phase 3）：迁移Internet用户，并支持新增Internet用户。这是系统的最终演进结果和目标架构。2 系统总体描述（0级视图）2.1 系统总体构架我司提供的融合计费解决方案共有CCBS、OCS、IPCC、BI和外协几个产品组成，在逻辑上分为三层，如下图所示：2.1.1 服务控制层服务控制层各部件的功能如下： Provision 部件将为客户服务层提供网络的服务开通接口。 Mediation 部件负责
30、采集网络设备上的话单，同时也负责漫游结算话单的解码工作。 SCP 部件负责话音类业务的呼叫控制，并触发到CBS进行计费处理。 UVC部件负责充值卡管理和对应的充值流程。2.1.2 计费帐务层计费帐务层由CCBS国内海外计费帐务统一版本完成。CBS实现对预付费用户的业务使用进行预算和实时扣费。对后付费用户的业务使用进行批价(全触发模式后需要实时批价)、出话单、累帐出帐。在计费帐务处理后，将由帐单格式化、帐务管理、欠费催缴模块完成后续的帐单生成、缴费销帐、以及欠费催缴功能。收入保障采用的是外协Ectel的产品，包括对非法使用情况的分析、一致性的分析和处理准确性的校验功能等。注1：对于话音类业务，由
31、核心网经Camel协议触发到SCP，再由SCP转换成DCC协议到CBS进行计费处理。对于其它增值类业务，由增值业务平台采用DCC协议直接触发到CBS进行计费处理。注2：考虑到核心网以及其它业务系统的性能以及业务能力的改造，同时结合我们的分阶段实施步骤，在总体上未采用全触发的方案，即预付费采用实时接口触发，后付费采用话单方式进行计费。但后付费的数据业务需要通过DCC到CBS进行鉴权注3：由于Telfort项目的特殊性，后付费的缴费是采用Telfort的财务系统支持，所以这里采用“Account Management”的说法，没有采用海外通常的“Account Receivable”，以保证与客户
32、交流的一致性。注4：欠费催缴已经明确使用原有的CACS系统，不再由我司提供。注5：E-CARE/E-SHOP可能要与portal捆绑在一起单独招标2.1.3 客户服务层客户服务层主要由CCBS 和IPCC两个产品共同提供，覆盖Telfort 2.0 所有客户服务渠道的日常功能，包含产品管理、资源管理、业务受理、业务变更、综合查询、投诉建议等功能。在业务受理流程中，客户服务层一方面将通过服务控制层的Provision 子系统对网络进行服务开通，另一方面也将更新计费帐务层的客户资料、信用度数据、产品定购数据等信息。同时计费帐务层也为客户服务层提供具体的资费规则定义、用户实时状态等信息。2.1.4
33、版本配套关系CCBS产品各部件版本配套关系如下，将基于此版本进行开发：配套产品版本个人业务受理（包括缴费、产品管理）TopEng CC&BM V200R003C01B43资源管理TopEng BOSS IM V200R003C01B190订单管理TopEng BOSS GP V200R003C02B200客户管理/营销管理渠道管理/合作伙伴管理系统管理TopEng BOSS BC V200R003C02B110E-careTopEng BOSS E-Care V300R001C02B01InterfaceTopEng BOSS INT V300R001C04B01Rating/BillingT
34、opEng CCBS CHG V300R001C01B07MediationTopEng Mediation V100R002C07B392 TopEng Mediation V100R002C07B392E32F080 System MonitoringTopEng System Monitoring V200R003C02B201ProvisionTopEng Provision V100R002C20B0412.2 系统外部接口描述（暂不写作，将引用架构与接口相关交付内容）系统外部接口总图如下（将根据架构和接口组的最终输出调整）：2.3 系统物理组网（暂不写作，将引用物理部署内容）2.3
35、.1 系统总体物理组网3 系统方案设计（1级视图）3.1 Rating&Billing与PC 产品定义配合3.1.1 业务需求描述先在测试床进行测试资费配置，在测试床进行资费验证以后，进行生产库发布资费配置，此时配置的资费政策(tariff_plan)，同步到营业的计费资费接口表(billing_plan)，供产品管理进行产品定义。3.1.2 系统功能分解分配3.1.2.1 Rat.001计费资费同步到营业PC资费接口表l Rating&Billing部件n 计费资费政策（TARIFF_PLAN）的变动通过定时启动后台进程方式进行差异同步，主要同步资费ID与资费名称的变动，到营业资费接口表（B
36、ILLING_PLAN）。TARIFF_PLAN BILLING_PLAN差异检查字段缺省处理设置Tariff_plan_idItemid是Tariff_plan_nameItemnamesubstr(tariff_plan_name,1,32)PlantypePlantypeNetworkedGSMIsbaseplan1Status1StatusdateSysdateRegion9993.1.3 接口说明3.1.3.1 内部接口接口名称接口类型接口提供方接口使用方接口说明资费同步接口表接口计费账务产品管理计费账务TARIFF_PLAN的资费ID与名称到产品管理的BILLING_PLAN的同步
37、处理。3.1.3.2 外部接口无3.1.4 性能要求无3.2 Rating&Billing与帐务管理提供已批价CDR、Bill配合3.2.1 业务需求描述计费账务通过表方式提供未销帐的后付费账单，账务处理与账务管理共用同一个数据库，后付费账单通过数据库接口表的方式提供。计费账务提供账单明细费用项与GLCODE参照表的维护。已经批价话单（CDR）采用表接口方式提供给账务管理，不作格式转换。3.2.2 系统功能分解分配3.2.2.1 批价话单提供方式计费账务已批价话单（CDR）采用表接口方式提供，不作格式转换。3.2.2.2 后付费账单提供方式计费账务提供月结出帐和立即出帐的后付费账单，账务管理直
38、接访问计费账务账单表（BILL）和明细账单表(BILLITEM)，账务管理读取计费的账单进行销帐处理并将结果生成到账务管理的账单表，3.2.2.3 GLCODE处理方式计费账务提供明细费用项与GLCODE参照表（帐单项定义表AcctItem_def）的维护。3.2.3 接口说明3.2.3.1 内部接口接口名称接口类型接口提供方接口使用方接口说明批价话单表接口计费账务账务管理采用表接口方式提供，不作格式转换后付费账单接口表接口计费账务账务管理账务管理直接访问计费账务账单表（BILL）和明细账单表(BILLITEM)GLCODE处理方式表接口计费账务账务管理计费账务提供明细费用项与GLCODE参照
39、表（帐单项定义表AcctItem_def）的维护3.2.3.2 外部接口无3.2.4 性能要求无3.3 Rating&Billing与CC资料接口3.3.1 业务需求描述营业受理产生资料的变更，需要向计费账务进行资料同步方式。由于对业务的实时性要求的不同，采用不同的同步方式。对于预付费的激活处理和资费变动时，采用实时同步方式，营业直接调用计费账务的实时客户资料刷新的socket接口，同时能够在资料同步触发器中标识出已经采用了实时接口。其他业务采用触发器异步处理方式，但是需要营业支持区分资料变动的操作类型支持不同的优先级和处理类型。新增操作类型，采用2为字符标识，第一位定义为批量类型，第二位定义
40、受理方式，具体说明如下：第一位：批量类型1单笔受理，对应优先级高2批量受理，对应优先级低第二位：受理方式1 普通受理，更新营业数据库，通过触发器同步到计费2 实时受理，先更新计费，再更新营业数据库，不需要进行同步计费3 反向同步，计费已经更新，反向同步到营业，营业进行相应操作，不再同步到计费。操作类型举例：营业单笔普通受理，标志为11，采用触发器同步方式到计费，同步优先级高。营业批量普通受理，标志为21，采用触发器同步方式到计费，同步优先级低。批量反向同步处理,，标志为23，触发器特殊处理，不生成同步数据，只生成核对数据，且同步优先级低。计费账务进行预付费用户的生命周期管理过程中，预付费用户状
41、态变动，需要由计费账务反向同步资料到营业。3.3.2 系统功能分解分配3.3.2.1 CC2RAT.001营业到计费的触发器资料同步接口l Rating&Billing部件n 通过表触发器方式进行资料同步。客户资料上增加资料同步触发器，触发到计费账务的资料增量接口表custinfo中，再同步到计费账务数据库，由计费的客户资料管理程序刷新进行增量的数据库和共享内存的资料刷新。n 由于存在普通受理、批量后台受理、实时资料同步、反向同步等资料同步方式，需要在触发器中增加受理的操作类型标识。从而区分批量受理类型，确定资料处理优先级，通过区分受理方式，决定资料同步方向。n 具体实现方式：实现方式采用数据
42、库package如果某个操作没有设置全局变量,就会使用上一笔操作的全局变量?有无风险?全局变量方式（2位字符方式）。l CC部件n 营业受理时进行数据库操作时，先设置数据库package全局变量，Rating提供的触发器检查此全局变量，进行相应的处理。l Rating&Billing部件n 在同步资料表上增加操作类型字段，触发器进行不同判断处理。n 计费资料同步触发器改造：支持营业不同受理类型，生成不同接口数据。1 判断批量处理类型，设置同步优先级。2 判断受理方式，确定同步方向。A:普通受理业务，生成到计费同步数据。B:实时受理业务，不生成同步数据。C:反向同步业务，不生成同步数据。3.3.
43、2.2 营业到计费账务的socket实时资料同步接口l Rating&Billing部件n 对于预付费的激活、预付费的修改资费，计费账务提供sockect方式的资料增量同步接口，计费账务为服务端，营业进行客户端调用。l CC部件n 调用计费提供的同步接口,完成预付费的激活预付费资费修改接口.3.3.2.3 计费账务到营业的反向资料同步接口计费账务进行预付费用户的生命周期管理，当用户状态变化时，计费账务的预付费用户的状态进行改变（包括数据库、共享内存变动），同时需要同步到营业系统，营业进行相应的处理，当需要进行停机时，营业发送HLR指令，当状态进入回收状态时（pool），需要进行销户处理，接口方式采用状态变更表方式。计费账务状态变更同步到营业，营业进行状态变更后，不再会传给计费账务。但是由此引起的其他资料变动，会通过数据库表触发方式同步到计费账务。接口表字段包括：用户
