中国联通企业信息化规划咨询项目3G规划组3G支撑演进专题规划 附录三融合计费 v1.0.doc

中国联通企业信息化规划3G支撑演进专题规划附录三融合计费Sign Off PagePrepared by :Date :Reviewed by :Date :Date :Date :Date :Approved by :Date :变更记录RevisionDateDescription of Contents缩略语文档中所涉及的缩略语解释请参见下表。缩略语英文全称中文全称AOCAdvice of Charge计费通知APIApplication Programming Interface)应用程序接口ARPUAverage Revenue Per User每个用户带来的平均收入值BSCBase Station Controller基站控制器BSSBusiness Support System业务支撑系统CDMACode Division Multiple Access码分多址，扩频多址CDRCall Detailed Record通话详单CPDContent Provider Directory内容供应商目录CRBTCustomized Ring Back Tone个性化回铃音CRMCustomer Relationship Management客户关系管理CSGContent Service Gateway内容服务网关CSRCustomer Service Representative客服代表DRMDigital Right Management数字版权管理DSLADigital Speech Level Analyser语音质量测试工具EAIEnterprise Application Integration企业应用集成ERPEnterprise Resource Planning企业资源规划GGSNGateway GPRS Support NodeGPRS支持节点网关GSMGlobal System for Mobile communication全球移动通信系统IMSIInternational Mobile Subscriber Station Identity全球移动用户识别号INIntellegence Network智能网IVRInteractive Voice Response交互式语音应答LBSLocation Based Service位置服务MCPMaster Content Provider集成内容供应商MDNMobile Directory number移动电话号码MPMobile Portal移动门户MSCMobile Switching Center移动交换中心MSPMaster Service Provider集成服务供应商MSSManagement Support System管理支撑系统OMAOpen Mobile Alliance国际移动标准机构OSSOperation Support System运营支撑系统PDSCPPrepaid Data Service Control Point预付费数据服务控制点PDSNPacket Data Serving Node分组数据服务节点PGPayment Gateway支付网关PMOProject Management Office项目管理办公室PPCPrepaid Postpaid Convergence预付费后付费融合PRMPartner Relationship Management合作伙伴管理PSPVAGProvince Service Provider Voice Access Gateway地方性SP语音接入网关QoSQuality of Service服务质量SCGService Content Gateway服务内容网关SCPService Control Platform服务控制平台SDPService Delivery Platform服务交付平台SGSNServing GPRS Support NodeGPRS服务支持节点SLAService Level Agreement服务水平协议SMGShort Message Gateway短信网关SMSAhort Message Service短消息服务SMSCShort Message Service Center短消息服务中心SPMCService Provider/Content Provider Managing Center“炫铃”业务统一接入管理中心SPMSService Provider Management SystemSP管理系统SPSMGService Provider Short Message Gateway全国性SP集中接入网关SPVAGService Provider Voice Access Gateway全国性SP语音接入网关SSPService Swithing Point业务交换点UMTSUniversal Mobile Telecommunications System通用移动通信系统VAGVoice Access Gateway语音接入网关WAPWireless Application Protocol无线应用协议目 录1.融合计费的概念、市场驱动及优势82.融合计费的难点103.AOC（计费通知）143.1.AoC的定义143.2.AoC在移动数据业务流程中所处的位置153.3.移动数据战略与定价模型163.4.案例163.5.功能问题184.联通预付费/智能网的现状205.国际上融合计费的案例介绍255.1.案例一：某走在行业前端的智能网厂商255.2.案例二：某成熟的运营商265.3.案例三：某起步不久的运营商265.4.其他案例：东欧、挪威等地的运营商275.5.案例比较286.融合计费的方案解析306.1.融合计费方案概述306.2.方案一：完全由IT支撑系统实现实时计费326.2.1.方案介绍326.2.2.优势336.2.3.劣势336.2.4.场景一：利用ConvergysAM-BEO的融合场景336.2.5.场景二：利用Geneva 和 Comptel OnlineLink的融合场景346.2.6.场景三：下一代全业务融合批价/计费场景356.3.方案二：IT支撑系统主导实现实时计费的方案366.3.1.方案介绍366.3.2.优势376.3.3.劣势376.4.方案三：SCP主导实现实时计费的方案376.4.1.方案介绍376.4.2.优势386.4.3.劣势386.4.4.场景：进一步向智能网方向倾斜的预/后付费融合场景387.融合计费方案的优劣比较398.演进方案409.参考资料421. 融合计费的概念、市场驱动及优势这里的融合计费主要是指预付费和后付费的融合（Pre-paid Post-paid Convergence，英文缩写为PPC）。对于以预付费/后付费为标准的客户细分，可以看到两种不同的看法。对预付费用户/后付费用户的传统看法认为：§ 相对于后付费用户，预付费用户是低端客户§ 预付费用户最终都会转向选择后付费的方式§ 用户是因为有信用风险才使用预付费的§ 预付费用户不需要使用所有服务，而后付费用户需要使用大部分的业务§ 相对于后付费用户，预付费用户具有高流失率的特性而另一种观点融合的观点则认为：§ 预付费用户中象后付费用户一样也有高消费者§ 预付费有控制成本等好处，预付费用户选择预付费只是喜欢这种消费方式，他们中的大部分仍会保持这种付费方式而不是象传统的观点认为的他们会转向后付费用户§ 预付费只是另一种形式的支付方式，并没有更多的其他意义§ 预付费用户也会使用高端服务 § 预付费用户流失率依赖于客户得到的offer，预付费用户的流失率并不必然比后付费用户的流失率高事实上，对客户按“预付费”“后付费”来进行划分，完全是系统系统的驱动的划分，而不是按市场营销的特性来区分的划分。这种系统驱动业务行为，或者说用系统支撑来确定客户细分的方式，我们认为是不明智的。必须要指出的是，预付费和后付费两种付费方式各有好处，前者能更好地控制成本，能实时获取流量信息，能更精确地开展防欺诈管理；后者则可以提供更为复杂的资费计划、更灵活的折扣策略，并且能够支持不同的支付选择。将预付费和后付费两种计费方式融合的驱动力就在于，预付费和后付费用户能够共用一个批价计费引擎；运营商可以向预付费客户和后付费客户提供所有的增值服务和传统语音服务和相配套的资费计划，并将两种计费方式的综合优势展现出来，如图1-1所示：图1-1 预付费与后付费融合的驱动力示意图综观融合计费的好处，可以看到：§ 在操作层面的好处有ð 维护统一的产品目录ð 当运营商推出新产品时，对总体IT支撑架构造成冲击较小ð 更简单的运维环境§ 除此之外，还有额外的商业价值如下ð 为客户在不同支付方式之间的选择提供无缝衔接，换言之，客户在更换支付方式的时候感觉不到明显变化ð 在不同的客户群之间能更便捷地配置新产品，不会因为付费方式的区别而无法配置某些产品ð 有可能提供更具有创新性的资费表实现了后付费和预付费得融合后，一个客户就可以同时拥有预付费和后付费两个帐户。这在商业上也是有需求的。例如，小顾是公司的卡车司机。公司为其开通了手机服务。一个号码绑定了2个帐户，其中一个帐户是后付费的，公司为该客户设定若干与业务相关的号码，拨打这些号码可以被当作后付费帐户的行为处理；同时，另一个帐户是预付费帐户，是小顾的个人账户，对其他号码的拨打可以进行实时费用控制。2. 融合计费的难点尽管融合计费具有诸多的好处，成为了各国运营商积极探讨和尝试的一个热门主题。但是总的来讲，还没有出现一个成熟的经历了大的运营商考验的融合计费的案例。技术问题是造成目前情况主要原因。因为融合计费也面临很多难点和挑战，概括地说来，主要有以下几个难点。难点一：每次实时计费过程都需要处理多个事件对于后付费用户的计费，从理论上讲，只需要在接通前知道通话的呼叫方、被呼叫方，并在通话结束后知道通话时长。但是与以前的后付费用户的计费过程不同，实时计费的过程相对复杂，至少会包括以下一系列事件:§ 会话开始§ 会话应答§ 会话延时（可选）§ 会话 延时应答（可选）§ 会话终止请求§ 会话终止应答在具体场景中，还可能有更多的事件发生，例如§ 预付费帐户余额为零，呼叫终止§ 预付费帐户余额不为零，信用额度被扣除产生事件越多，在通过网络界面的时候产生的 I/O 信号就会越多，对整个系统实时性的要求就会越高，此时，如果系统性能不足的话，会影响系统的表现。图2-1 多个事件处理流程示意图难点二：实时计费要能满足峰值需求对传统的后付费用户话单的处理一般是批处理，批处理的能力只需要能够承载平均容量，而对预付费用户的请求一般是实时处理，实时计费的能力必须要能够承载峰时的容量。举例来说，如果在一天内，下午2点网络上产生话单的速率最大，达到了20万条每分钟，而每天平均每分钟网络上的话单则为8万4千条。那么对于后付费系统，在极端的情况下，只需要具有平均每分钟能处理8万4千条话单的能力就足以满足业务需求了；对于预付费系统，就需要具备满足每分钟20万条话单处理的能力。系统的软硬件投资很明显就要加大，而且系统在非忙时的和总的利用率也会大大下降。峰时流量平均流量图2-2 流量示意图难点三：反算§ 反算就是根据现有的余额（信用度等）计算出可使用的时间（或者其他通信单位）：如果已知金额 = f (时间)那么，根据一个金额值，我们也可以得到相应的可使用时间时间 = f-1 (金额)§ 为了允许并发的余额控制（比如同时打电话和下载游戏），需要有必要的政策来确定当并发请求发生时，用户余额如何在这些并发请求中进行分配的问题。§ 非线性的定价在很多套餐里时常见的。而非线性的定价算法的反算要求使用迭代算法，迭代算法非常消耗系统的资源，这就大大降低了系统性能。难点四：事件的关联§ 某些客户的同一行为产生了不同种类的事件：ð (例如: 下载一个视频游戏产生了流量使用和信息使用的事件)§ 事件如果不受控制地导入计费系统也会导致重复计费。流量和增值服务事件应当被关联，然后应用合适的扣费策略。§ 很多相关事件的关联成为一个事件记录如果让下游应用去做效率会比较低，相对的讲，在采集层进行这种工作会比较合适。难点五：可扩展性§ 传统的后付费系统可以并行实例配置，增大系统的容量。§ 每个实例包含一个基于客户的分割，也就是说包含一部分的客户资料。§ 事件在采集后被送至不同实例，加快处理的速度。§ 该解决方案对于批处理方式来说比较容易执行，而对于实时批价需要双向接口来说，会复杂得多（见图2-3）。图2-3 可扩展性示意图3. AOC（计费通知）随着移动数据和互联网业务在世界范围内的兴起，客户已不仅仅用手机来打电话或接听电话，而是用来做更多的事，例如收发文本消息、彩信，下载/传输数据文档，收听新闻，获得帐户的财务余额提醒等信息。在众多业务当中，每种业务又可以有多种不同的计费模式。开展的业务越多，带给客户的体验就越丰富。但与此同时，运营商担心一些潜在的因素可能会给客户造成困惑，因此客户不愿意过多的尝试新的服务。而且，移动数据服务允许用户从第三方定购逻辑内容（如新闻消息）和物质产品，每种产品/服务都有它自己的定价策略，这将加剧运营商的担心。如果由运营商提供服务，让客户在接收服务之前能及时得到该服务的价格反馈。对于一些3G产品，用户能够在定购服务之前事先知道该项服务所需要的花费或者所需传输的数据的大小。这样就能有效减少运营商的担心，减少给用户带来的困惑。举例说明如下：客户需要下载一段视频，客户的请求发送至计费系统，出于报价的目的，系统即需对该视频进行批价（考虑视频大小、时间、该客户已订购的业务包，等等），但不向用户收费。在短短几秒钟内，系统就要向客户提供相应的价目单，使客户能够决定是否要下载该段视频。信息反馈的快慢将直接影响到客户对3G业务的感受。3.1. AoC的定义上述的服务就叫作 AOC (Advice of Charge)，即：计费通知。计费通知是无线智能网（WIN）的一种计费业务，AoC 是指在计费帐务系统里，对需要批价的业务进行费用预估，并将费用展示给用户。发送的时间可以在呼叫前、呼叫中或呼叫后。发送信息的方式可以是视觉显示的方式，也可以是播放语音提示的方式，也可以是同时有两种方式的结合。从移动数据的角度来看，AoC又可以被定义为：在终端用户决定使用产品/服务之前就能让该用户知道该产品/服务价格的一种能力，这样的价格可以是对一项明细的固定费用，比如铃音；或者是根据购买的单位数量计算费用, 例如MP3下载；或者是按时长计费，基于预期的下载时长，来对该产品/服务进行估价。这样的需求反过来对实时批价机制提出更多的性能需求，要求不仅在处理实时批价的容量要有较大的承载量，同时对处理时间也提出了更高的期望。3.2. AoC在移动数据业务流程中所处的位置为了能更好地理解AoC在移动数据业务中所扮演的角色，需要先回顾使用一项移动数据业务时所发生的步骤。为了清晰起见，在下述例子中我们假设所有的支付方式都是现金而非通过银行贷记卡或信用卡，尽管在现实生活中，后两种情况也是存在的。当定购/使用移动数据业务时，主要流程如下所述：步骤一：用户发出内容请求。用户挑选出一项内容（逻辑的或者是物理的）。移动门户（通常属于移动网络运营商）将该请求转发给内容供应商，有可能是通过支付网关来实现。步骤二：内容供应商发送该项业务的信息。内容供应商提供被用户挑中的该项业务的价格信息。如果无法提供该项业务的价格信息，内容供应商会提供该项业务的其他属性，如文件大小等。支付网关将这些信息转发给移动门户。步骤三：AoC的预批价。该业务的属性被发送到计费帐务系统用来批价。此时，会有一条业务规则负责决定是否向该用户展示该批价信息。如果可以展示，那么，计费帐务系统将计算包含折扣在内的总价格，并将其发回给移动门户。步骤四：用户确认。终端用户收到该项业务的价格提示后，可以接受或者拒绝使用该项业务。而且，用户可以选择支付方式（预付费、月出帐，或者信用卡付费等），或者由系统根据业务规则自动作出决定。如果支付方式为预付费，需要确认用户的余额是否充足。当确认余额充足的情况下，移动门户将通知支付网关，可以继续该业务的交易。步骤五：认证。假设支付网关可以得到用户资料，那么支付网关将通过PIN，或数字通行证，或SIM卡，对用户进行认证。对后者而言，手机终端中的SIM卡与用户帐户（帐户中包含资金）相连。步骤六：对交付件的授权。当对用户身份进行认证之后（包括帐户资金是否充足，等），支付网关通知内容供应商可以向用户交付该业务。步骤七：交付。内容供应商向用户提交 物理的/逻辑的 内容。步骤八：交付通知。内容供应商通知支付网关，交付成功。而后，支付网关向计费帐务系统提交交付成功的通知。步骤九：对终端用户计费。根据支付方式的不同，计费帐务系统对该项业务进行计费，例如：按月计费，或者从预付费帐户余额中进行扣减。步骤十：收入结算计算。收入结算系统从计费帐务系统接到业务使用信息，根据事前签署的合作伙伴结算协议，决定哪些收入归运营商所有，哪些归内容供应商所有。步骤十一：收入结算。比较简单的一种情况是，由运营商扣减佣金或费用之后，将支付额转发给内容供应商。根据以上这些步骤可以得到，如果想要提供计费通知功能，那么至少需要一个能提供此项功能的计费帐务系统。其他系统诸如运营商、内容供应商、支付网关提供商，等的系统也需要各就各位，各司其职。3.3. 移动数据战略与定价模型随着3G业务的不断推出，运营商面临的挑战也越来越大。运营商需要创建这样一种价格模型：该价格模型能使运营商尽可能多地从用户那里获得收入的，并能反应提供这些业务的成本。统一费率和套餐计划在2G时代很风靡，但在3G时代执行起来会遇到一些问题，因为运营商在基础服务和增值服务之间不会有明显的区别。例如统一费率的使用，会难以从高消费的用户那里得到额外的收入，同时会将偶尔使用的用户拒之门外，难以从这些用户那里得到收入。DoCoMo是日本最大的运营商，DoCoMo的定价由每月连接费用2.56美元，以及每个数据包（128字节）0.0028美元的传输费用组成，除此之外，DoCoMo对特殊的内容和服务收取额外的费用，有时候会采用每月定购费的形式。DoCoMo代替内容供应商收费之后，向内容供应商收取9的佣金。从欧洲运营商和日本运营商的例子可以发现，各个运营商的定价机制十分不同，有的按月计费，或按内容大小计费，有的按时长计费，也有运营商采用多种方式混合计费。在定价计划的简单化和价值最大化之间需要有权衡。我们相信用户能区分和记住5种不同业务的资费。但是当资费远远多于5种，很容易给用户带来困惑，而在这种时候，AoC能有效地减少这种困惑的发生。3.4. 案例为了更好地了解AoC如何影响客户的感知，以及更好地分析后台支撑系统该如何提供计费通知服务，我们将用下面的例子来说明。在一天繁忙的工作结束之后，小王离开公司，决定去看新上映的电影“神话”。小王想先上网浏览电影预告片，但是他已经不在公司，没法上网。幸好他是某运营商的预付费用户，因此可以通过他的移动电话获取视频和音频文件。该运营商新近与某电影公司签署了合作伙伴协议：该电影公司将向该运营商的用户提供MPEG格式的电影预告片。小王打算先浏览预告片，如果喜欢，再买电影票这是电影公映的第一周，票很热销。案例一：浏览电影预告片小王使用手机终端浏览移动门户，进入娱乐板块中有关电影介绍的部分，挑选“神话”，决定在买电影票之前先看电影预告片。小王的请求被转发到电影城，运营商关于数据和内容的定价模型是基于流量大小的，因此电影城作出回应，将电影预告片的属性发回：大小为1.00MB，MPEG格式。该信息被转发给计费帐务系统。此时，由系统决定该使用是否需要批价。因为这是一个视频文件，批价的时候可以应用所有合适的折扣。同时也要确认小王的预付费余额是否足够支付该预告片的费用。小王收到计费通知信息询问他是否同意1元钱的费用，并询问他采用何种支付方式。小王认为1元钱的费用相当合理，因此他按下确认键，选择用他的预付费帐户来支付这笔费用。运营商的门户将此请求转发给支付网关（Payment Gateway），在那里主要确认用户的身份。随后，电影城收到来自支付网关的确认，开始下载。一旦下载发生，电影城将通知支付网关，继而通知计费帐务系统。此时此刻，计费帐务系统将从小王的预付费帐户中扣减1元钱。在月末，运营商将这笔收入与电影城进行结算。收入结算系统将基于来自计费帐务系统的信息来执行计算操作。根据他们之间的合作伙伴协议，运营商将收取用户支付费用的10作为佣金，并将剩余的部分给电影城。在这个例子中，即：运营商将付给电影城0.90元钱，自己保留0.10元钱。案例二：购买电影票小王在手机浏览界面上选择“购买电影票”的选项。由于运营商与电影城没有合作伙伴协议，而与信用卡中心/银行 有合作伙伴协议，因此，在“购买电影票”这项服务上，运营商目前只能向用户提供信用卡/银行卡支付的方式，以便监控用户购买电影票所发生的费用，为与合作伙伴之间的结算提供必要的数据信息。下面将主要以小王使用信用卡支付购买电影票的方式来举例。在购买电影票的流程中，前两个步骤与前面的例子相仿。不过，在这个例子中，计费通知服务不必进行预先批价（因为电影票的票价是固定的）。计费帐务系统不会进行批价计算的操作，而只是对业务作记录。小王依然会收到计费通知。在这个例子中，计费通知功能比较简单，主要是由电影城把一个固定价格信息发送到支付网关，并经由运营商的移动门户，最终发送到小王的手机上。与前述例子还有一处不同，在这里，用户选择“信用卡”作为支付手段，因此其确认方式也不相同。这就意味着当用户通过认证之后，还需要支付网关向信用卡中心/银行确认该用户的信用额度是否足够支付该项业务所产生的费用。假设用户信用卡的余额没有问题，接下来的步骤与前面的例子相仿：支付网关授权给电影城发售电影票。出于实用的目的，电影城不会向小王出纸质的票，而是一个确认代码，电影开场时，只要在入口处声明该代码就入场。电影城将通知且发送确认代码给支付网关。从小王的角度来看，购买都完成了：手机收到确认代码，在电影院只需凭此代码就可入内。但是，后台的支撑系统还有一些工作需要完成：支付网关要能够将交易信息转发给计费帐务系统以便将来之需。另外，支付网关将授权给小王持有信用卡的发卡行在扣减费用之后，负责发送支付信息给电影城。注意案例一和案例二中的主要区别：§ 采用不同的支付方式，在整个业务流程中就会涉及不同的实体（例如，在案例二中，引入了第三方：银行和/或信用卡公司）。§ 不是所有的情况下都需要提供预先批价的计费通知服务。主要依赖于支付方式、定价策略、或者支付的总金额等。§ 即使在提供计费通知服务的案例中，计费帐务系统所起的作用也可能存在区别，例如，案例一中，需要计费帐务系统进行预先批价，而在案例二中，计费帐务系统只要对业务作相应记录即可，不必作预先批价。3.5. 功能问题在执行AoC时，需要考虑以下这些技术和功能方面的问题。1、 AoC所需的输入信息如果所购买的业务需要预先批价，那么需要从某些地方获得用来计算AoC价格的信息。如果价格信息不是运营商完全控制的，还可以通过支付网关从内容供应商处得到该信息，这就说明批价引擎需要与支付网关有接口。2、 业务规则移动数据业务有多种支付方式。一项业务的价格可以被计入当月费用（后付费场景），也可以被计入信用卡帐户，或者从预付费余额中扣除，或者贷记到该用户的银行帐户。不仅有多种支付方式，而且作支付方式决定的主体也可以变化：是否为用户在购买该业务的时候作决定？或者由运营商作决定？更进一步，什么类型的业务需要计费通知？哪些业务可以略去该步骤？等等。如果由运营商决定支付方式，需要有一系列相配套的业务规则来支持。通常情况下，较贵的业务会带来更高的财务风险，这些业务会需要计费通知服务，在得到用户确认之后，才会将计费通知转发给财务机构（信用卡或银行）。实物产品一般更倾向于遵循这条路径。虚拟内容例如新闻、信息服务、MP3文件和其他非物质的内容可以通过扣除预付费余额或计入后付费帐单的方式进行计费。3、 计费通知的准确性在众多案例中我们可以看到，提供十分精确的费用预估不是没有可能，而且甚至在非常复杂的定价和折扣机制下，也可能提供准确的费用预估。一个强大的灵活性高的批价引擎堪当此重任。4. 联通预付费/智能网的现状总的来说，目前中国联通在预付费用户群主要面临两大问题：§ 由IT支撑系统实现的预付费用户（又称准实时用户、假预付费用户）存在无法实时计费，因而产生欠费问题，需要加以风险控制§ 由智能网实现的预付费用户还不能够使用各类灵活的套餐，因而产生用户发展问题，需要采取措施使这些用户也能使用各类产品组合这两大问题是一对矛盾体。智能网（如果不考虑移动数据业务）基本解决了实时计费的问题，但是业务逻辑简单，无法支持灵活的各种套餐；IT支撑系统目前看来完全解决实时计费的问题还有一定困难，但是业务逻辑灵活，可以支持各种灵活的资费政策。§ 传统语音智能网实时计费智能网的出现，能够通过SCP、SSP等控制节点和7等控制协议对交换机进行实时控制，从系统上实现了费用实时控制，解决了用户欠费的问题。但也带来以下问题：ð 形成了智能网和普通用户的两张网，并且两网用户资料是割裂的，很难作为一个整体来处理ð 智能网无法支持灵活的套餐，没有解决用户发展的问题ð 由于智能网出现的较早，当时没有考虑到对数据业务的支撑；导致该解决方案只能支持传统语音业务，尚未考虑对运营商的短信和其他数字业务的支持§ 短信和移动数据业务的智能网准实时计费目前在联通大部分省分，对智能网用户短信扣费的支撑是短信网关（SMG）通过营帐系统向服务控制平台（SCP）传送话单。如图4-1所示：图4-1 短信和移动数据业务计费流程示意图因为营帐和SMG之间的接口是非实时的批处理形式，SCP与SMG之间的通信也是非实时的。由于存在延时而且SMG也无需等待从营帐的反馈，因此这种方案只是一个准实时方案，技术上可能产生欠费问题。§ PDSCP提供的短信和移动数据业务的智能网实时计费的可能PDSCP(Prepaid Data Servie Control Point) 预付费用户数据业务控制点具有对短消息各业务集中批价功能，对于点到点消息PDSCP通过费率表的维护可以为用户提供个性化服务，能够针对用户特性设置费率；对于联通在信短消息，由于SGIP协议中已带有信息费，PDSCP可以通过计算信息费与通信费之和便可对用户进行批价PDSCP与SMSC之间有接口：SMSC判断用户是否为预付费用户，如果是预付费用户需要提交消息到PDSCP，由PDSCP做鉴权并通过SCP扣费。PDSCP与SMSC之间通过TCP/IP组网。PDSCP与SCP之间也有接口：PDSCP需要向SCP提交消息，请求计费。同时PDSCP需要从SCP取用户属性变更通知文件。PDSCP与SCP之间通过TCP/IP组网。请求计费等消息使用实时类协议；取用户属性变更文件等使用FTP方式传送文件。为预付费用户实现联通在信短消息实时扣费业务，PDSCP需要与SMG互联。PDSCP与SMG之间通过TCP/IP组网，采用SGIP协议。为实现网间点到点预付费用户短消息业务，PDSCP需要到SMB取补款话单，采用文件方式，批量异步完成；一般采用TCP/IP，通过FTP方式传送文件。一般而言，PDSCP会具有以下模块：运行支撑模块：处理预付费用户实时扣费功能，同时能为其它功能模块提供承载。协议转换模块：能保证PDSCP与各功能实体之间有效通信，进行协议转换的功能模块。支持与SMSC、SMG、SMG、SCP以及计费中心的接口。业务处理模块：提供数据管理、批价、扣费、补款等功能。监控维护、统计模块：为系统提供实时监测、故障告警等功能和手段，并实现对系统的各类局数据和用户数据的维护，对系统运行的各类信息数据进行统计和管理。PDSCP还应提供图形化的操作维护终端，便于维护。对于经过PDSCP处理的短消息业务，PDSCP应能自动记录以下主要信息：话单序号（注明为唯一标志）、主叫用户号码、被叫用户号码、短消息应用类别（包括人工/自动、语音信箱通知、移动台主叫/被叫、其他业务连接等）、优先级、存档时间、状态报告标记、信息量等。关于计费格式要求应该符合联通公司的其它具体规范。从上面的介绍我们可以看出，PDSCP并不是专门面向3G才产生的。通过增加PDSCP，对计费架构并无影响，只是对原先智能网能力的完善。没有PDSCP的时候，联通的智能网由于历史的原因，只能支持传统语音业务的预付费用户。本质上作为智能网SCP和各业务平台的协议转换的接口，PDSCP使得智能网不仅能对传统语音业务提供实时计费，也向移动数据业务提供实时计费。目前PDSCP提出是为了解决短信的实时计费，可以通过对PDSCP的改造，使它支持其他移动数据业务的实时计费。我们前面介绍过,目前在联通大部分省分，对智能网用户短信扣费的支撑是短信网关（SMG）通过营帐系统向服务控制平台（SCP）传送话单。目前对智能网用户的短信实时计费改造主要是以PDSCP替代营帐系统。PDSCP是SCP与SMG之间的实时接口并负责必要的协议转换，在PDSCP中对各业务进行批价，再向SCP申请计费请求 ，这样就实现了实时计费。如图4-2所示：图4-2 联通在信智能网实时计费示意图当用户发送短信，产生话单，通过短信网关，经过PDSCP到达SCP，由SCP进行余额查询，扣费之后，返回给SMG。下图是点对点短信（包括网间点对点短信）情况下，智能网实现计费的流程示例。图4-3 点对点短信智能网实时计费示意图从上面的介绍看以看出，PDSCP可以被简单的看作短信网关和智能网SCP之间的适配器，完成协议转化的功能，实现智能网网员之间私有协议和外部其他协议的转换。那么很自然的，今后可以根据实际情况，对PDSCP与增值业务各业务平台（或者在SDP建立之后，只与SDP的控制层系统）进行接口改造，使得PDSCP成为智能网和其他移动数据业务之间的适配器，这样SCP就能够对移动数据业务进行实时计费。综上所述，PDSCP只是对原有智能网体系的完善，并没有涉及智能网与非智能网用户的计费融合。只是继续对欠费问题的智能网解决方案进行补充，还是没有解决智能网用户灵活使用套餐的问题。§ 营帐系统实现准实时计费的现状中国联通很多省分为了解决用户发展的问题，使预付费用户能够灵活使用套餐，选择在IT支撑系统的基础上实现准实时计费。在这种方案下，所有账户资料保存在IT支撑系统中。IT支撑系统基本不需要改造，因此不具有原智能网协议转换、服务访问控制（信令控制）反算等功能。当一个用户拨打另一个用户时，MSC/AAA根据自己保存的用户状态决定是否接续该电话。IT支撑系统不介入这个判断过程。每次通话完成后产生话单，IT支撑系统根据话单进行扣费，然后更新用户余额和状态。如果用户余额为负，IT支撑系统将会更新AAA中用户的状态。这样就实现了准实时计费。这个方案基本解决了预付费用户使用套餐的问题。也解决了用户资料在智能网和IT支撑系统内分立的问题。目前需要每15分钟IT支撑系统才能交换机上采集一次话单（如图4-4所示），考虑到其他后续的处理时间，对话单的处理可能需要分钟或者更长的时间。而且即使IT支撑系统具有了实时处理的能力，因为IT支撑系统对交换机没有实时控制的能力，还是会产生“最后一个电话”的问题。因此这个方案从技术上讲没有解决防止用户欠费的问题。考虑到这个方案的优点和可行性，我们可以从两个方面改进欠费控制。一个是从系统方面，提高话单采集的频率，缩短话单处理的时间。另一个方面从管理、市场营销的政策上入手，对存在信用风险的准预付费用户群加收一定的押金等。IT支撑系统MSC每次通话结束后或者间隔固定时间段用户余额认证、会话控制图4-4 由IT支撑系统实现准实时计费示意图 综合上述对中国联通预付费/智能网的现状分析，大致可以概括如下：§ 中国联通在预付费用户的支撑实践中，已经尝试了两条道路：智能网导向的解决方案和IT支撑系统导向的解决方案。§ 在IT支撑系统导向的解决方案里，基本保证了资费政策灵活性的支撑，但是用户欠费问题没有得到妥善解决。§ 在智能网导向的方案里，基本从技术上解决了用户欠费控制问题，但是智能网的业务逻辑比较简单，无法支撑复杂的资费政策，产生了灵活性不足的问题。§ 与IT支撑系统导向的方案相结合，联通可以通过提高系统性能、加快系统响应速度、增大话单采集频率等技术手段，加强对欠费的控制。同时从管理、市场营销的政策上下功夫，比如对信用度不够的客户，收取一定数额的押金。§ 对于智能网导向的方案，通过对PDSCP的改造，可以建立对大部分移动数据业务的预付费支持§ 下一代网络将是逐步向IP网络，软交换过渡，IT支撑系统为导向的解决方案应该是最终的解决方案，但是在本次规划期的3年时间内，还看不出明显的胜利者。§ 在计费融合最终实现之前，建议中国联通对自身的业务进行深入的分析，确定欠费控制和用户发展的优先次序，以确定目前的侧重点，并仔细探讨通过管理、市场而不是单纯的IT支撑技术上进行改善的可能性。5. 国际上融合计费的案例介绍在这一部分将给出若干种不同的预后付费融合途径，如下表所示：实施融合计费的客户融合计费的方案某走在行业前端的智能网厂商基于智能网的预/后付费融合某家成熟的运营商智能网和BSS共同实现预/后付费的融合某家刚起步的3G运营商由B