专利名称：一种push业务实现内容计费的方法
技术领域：
本发明涉及通信网络中的一种计费方法，尤其涉及一种PUSH业务实现内容计费的方法。
背景技术：
PUSH(推送)业务是一种由服务方主动发起，把信息“推送”给用户的一种业务。PUSH业务从业务开展的角度来看一般包括包括PUSH发起者(PI)、PUSH代理(PPGPush Proxy Gateway，根据PUSH指令递送内容给终端)和PUSH接收者(终端，MSMobile Station)三个实体。图1以WAPPUSH为例描述了PUSH体系的一个示意图。参考图1，PI位于Internet中，通过推送访问协议(PAP)同PPG通信，PPG是Internet网和移动网之间的访问接入点，PPG通过空间传输协议(OTA)把消息推送到客户。基本的工作流程如下1、PI推送消息给PPG当有消息要推送到客户时，PI首先根据消息的内容和性质构造推送消息，通过PAP协议向PPG发出推送请求；2、PPG处理PUSH消息，PPG收到请求后进行一些必要的处理工作(包括压缩、协议转换、安全认证等)，然后通过OTA协议将推送内容传送给客户端；3、客户端处理收到的PUSH消息，客户端收到PUSH消息后，根据消息内容和服务类型同PPG进行交互。
在2G电路交换网络中，用户使用移动电话进行通信，占用了网络资源，需要给网络运营商支付通信费；在2.5G/3G网络中，用户使用多样化、个性化数据业务，一方面用户需要占用网络资源，给运营商支付通信费，同时内容提供商PI/CP开发业务，提供业务给用户使用，用户使用业务需要支付内容(信息)费。PI主动发起把信息PUSH到终端，需要针对不同的应用场景分别对PI、接收方进行计费。
图2为现有技术中PI、PPG、MS处理PUSH消息的业务流程流程1)PI提交PUSH消息到PPG；2)PPG向PI返回所述PUSH消息的响应Response3)PPG通过OTA协议把PUSH下发给终端MS；4)终端向PPG返回所述下发的PUSH消息的响应Response；5)PPG向PI发送PUSH消息的结果通知Result；6)PI向PPG返回所述结果通知的响应Response；其中，PI按照标准的PAP接口规范构造PUSH消息请求，提交PUSH消息给PPG，标准PAP接口Push-message定义如下<！ELEMENT push-message(address+，quality-of-service？)><！ATTLIST push-messagepush-id CDATA #REQUIRED//push消息标识IDreplace-push-id CDATA #IMPLIED//被替换的push消息标识replace-method(pending-only|all)″all″//push消息替换方法deliver-before-timestamp ％Datetime； #IMPLIED//push消息在时刻前下发的时间戳deliver-after-timestamp ％Datetime； #IMPLIED//push消息在时刻后下发的时间戳source-reference CDATA #IMPLIED//发送push消息内容提供商名称ppg-notify-requested-to CDATA #IMPLIED//接收push消息结果通知消息的地址progress-notes-requested (true|false)″false″//push消息处理进展状态通知标志位(需要通知|不需要通知)>
PPG解析PAP协议，PAP协议中没有定义PUSH消息有关计费信息，PUSH消息业务的标识、计费方等信息，PPG无法确定是对发送方计费还是对接收方计费，PUSH业务只能根据运营商的要求统一为一种计费模式，同时不同PUSH业务类型没有业务标识，因此所有的PUSH业务不能按PUSH业务内容进行计费。
PPG对PI的所有PUSH消息采取统一计费模式，按PUSH消息条数对PUSH消息进行信息费批价、计费，对所有PUSH消息采取统一的计费价格计费、写话单，话单中记录的字段信息
从上述现有方案可以看出，PUSH业务计费只能采用固定的计费模式，主要缺点1)无法确定是对发送方进行计费、接收方进行计费，还是双方同时进行计费；2)不能区分同一PI不同PUSH业务进行计费，不能区分不同PUSH业务的内容进行计费；3)对所有的PUSH业务采取同一计费策略，不能针对差异性、多样性业务采取不同的计费策略。
发明内容
本发明的目的是提供一种PUSH业务实现内容计费的方法，该方法能够针对不同PI、不同的PUSH业务采取不同的计费策略。本发明采用如下技术方案以实现本发明的目的本发明提供一种PUSH(推送)业务实现内容计费的方法，包括如下步骤1)推送的发起者向推送代理发送推送消息，消息中包含计费信息；
2)推送代理将所述计费信息作为计费请求消息发送给数据业务管理平台；3)数据业务管理平台对收到的推送代理发送的计费请求消息进行处理，并返回应答消息给推送代理，通过应答消息将信息费价格发送给推送代理；4)推送代理处理接收到的所述应答消息，分析推送消息计费结果，如果预扣成功，则进入步骤5)；如果预扣不成功，则中断当前业务请求；5)推送代理把推送消息下发给终端，终端向推送代理返回推送消息的应答消息；6)推送代理根据终端返回的应答消息向数据业务管理平台发送计费确认请求消息，计费确认请求消息中包含了推送消息下发结果的状态码；7)数据业务管理平台根据推送消息下发结果中的状态码决定需要进行真实计费还是进行计费回补，并向推送代理发送包括推送消息信息费的计费确认应答消息。
在步骤2)之前还可以包括步骤1a)推送代理向推送的发起者返回推送消息的响应。
在步骤7)之后还可以包括步骤7a)推送代理根据推送消息下发结果和所述推送消息信息费生成话单。
在步骤1)中发送的推送消息中包含业务类型标识和计费方信息。
所述数据业务管理平台保存了各类业务类型的计费策略。
所述计费策略包括推送的发起者的代码标识、业务代码标识、推送的发起者的IP地址和该业务的价格中的一个或几个。
所述话单包括推送的发起者的代码标识、业务代码标识、推送的发起者的IP地址、推送消息下发结果、接收方号码、计费方和推送消息信息费中的一个或多个。
在所述步骤3)中对收到的推送代理发送的计费请求消息进行处理的步骤包括利用请求消息中的字段查询计费策略表，匹配到该推送的发起者发送的推送消息对应的信息费价格。
所述步骤7)包括如果推送消息下发成功，数据业务管理平台进行真实扣费，如果推送消息下发失败，数据业务管理平台进行信息费回补。
应用本发明的上述方案，可以针对不同PI发送的PUSH消息，对不同PI采取不同的计费策略；可以对同一PI发送的不同的PUSH业务采取不同的计费策略；PUSH业务可以对PI进行计费，也可以对接收方进行计费，或者对双方同时进行计费；本发明的PUSH业务能够采取灵活的计费策略发布PUSH业务。
通过以下结合附图对本发明优选实施方式的描述，本发明的其他特点、目的和效果将变得更加清楚和易于理解。
图1为现有技术中的以WAP PUSH为例描述了PUSH体系的一个示意图；图2为现有技术中PI、PPG、MS处理PUSH消息的业务流程流程图3为本发明的包括计费的PUSH业务流程图；具体实施方式
下面结合附图对本发明做进一步的说明。
本发明中PI在发送PUSH消息给PPG时，首先需要扩展PUSH消息，在PUSH消息中增加计费相关字段，PI发送PUSH业务时，在PAP接口协议中增加计费方标识、业务代码标识字段；将PAP接口协议进行扩展，扩展了的PAP接口规范如下<！ELEMENT push-message(address+，quality-of-service？，payment-control-information？)><！ATTLIST push-messagepush-id CDATA #REQUIRED//push消息标识IDreplace-push-id CDATA #IMPLIED//被替换的push消息标识IDreplace-method (pending-only|all)″all″//push消息替换方法deliver-before-timestamp ％Datetime；#IMPLIED//push消息在某时刻前下发的时间戳deliver-after-timestamp ％Datetime；#IMPLIED//push消息在某时刻后下发的时间戳
source-reference CDATA#IMPLIED//发送push消息内容提供商名称ppg-notity-requested-to CDATA#IMPLIED//接收push消息结果通知消息的地址progress-notes-requested (true|false)″false″//push消息处理进展状态通知标志位(需要通知|不需要通知)<！ELEMENT pavment-control-information EMPTY>
<！ATTLIST payment-control-informationserviceIDCDATA #IMPLIED//push业务标识IDcharged-party CDATA#IMPLIED//计费方>>
具有下划线的字段为PAP接口中扩展的字段信息
PPG收到PI发送的PUSH消息后，对扩展的PAP接口协议进行解析，分析PUSH业务的计费策略，针对PUSH消息的计费策略进行计费；PPG解析PUSH消息时，对扩展的PAP接口规范进行分析，提取业务标识、计费方信息。
下面参照图3，对整个计费流程作一个详细的说明1)PI向PPG发送PUSH消息(push-message)，消息中包含了业务类型标识“0101010101”和计费方信息“receiver”；该计费方信息表示对接收方计费。下面是扩展了的PAP接口的PUSH消息Content-Typemultipart/related；boundary＝asdlfkjiurwghasf；//Push消息内容类型type＝″application/xml″//类型--asdlfkjiurwghasf//push消息内容Content-Typeapplication/xml//内容类型<？xml version＝″1.0″？>//xml文档版本号<！DOCTYPE pap PUBLIC″-//WAPFORUM//DTD PAP 2.0//EN″http//www.wapforum.org/DTD/pap_2.0.dtd[<？wap-pap-ver supported-versions＝″2.0，1.*″？>]><pap>//PAP协议开始标识<push-message push-id＝″9fieo39if084@pi.com″>//push消息ID<address address-value＝″warpush＝12345/type＝user@ppg.operator.com″></address>//push消息接收方地址<payment-control-information//push消息扩展协议内容开始serviceID＝″0101010101″//push业务IDcharged-party＝″receiver″//push消息计费方</payment-control-information>
//push消息扩展协议内容结束</push-message>
</pap>
其中有下划线的语段表示在PUSH消息中扩展了的计费信息。
2)PPG向PI返回一个PUSH消息的响应(Push-Response)，当然返回响应并不是必需的，只是一个优选方案，不返回也不影响计费；然后解析请求消息，分析PUSH消息中与payment-control-information标签有关的计费信息，如果PUSH消息中包含了serviceID和charge-party字段信息，则把相应的业务类型标识和计费方信息提取出来；3)PPG将业务标识和计费信息(包括Source-Reference、ServiceID、ChargeParty)作为计费鉴权、批价请求消息发送给数据业务管理平台(DSMP)；计费鉴权、批价请求消息也可以称之为计费请求消息；其中数据业务管理平台(DSMPData Service Manage Platform)保存了不同业务类型的计费策略，包括各类业务的批价信息；如Source-Referece(PI代码标识)、ServiceID(业务代码标识)和Price(该业务的价格)等，下面有对这些参数的说明；PI发送PUSH消息前，对需要计费的PUSH业务，都需要在运营商的数据管理平台DSMP进行发布、业务发布时规定了该业务的计费模式、价格，这种形式可以是在线发布，也可以是事先在DSMP上进行设定；PUSH业务发布时，确定了该业务类型的标识、该业务对应的计费策略、信息费价格等。计费策略表(PrcieTable)如下
4)DSMP收到PPG发送的计费鉴权、批价请求，把请求消息中的ServiceID、Source-Referece字段作为联合主健，查询计费策略表(PrcieTable)，匹配到该PI发送的PUSH消息对应的信息费价格，查询到信息费价格通过向PPG发送鉴权、批价应答消息返回给PPG。
5)PPG处理接收到的所述鉴权、批价应答消息，分析PUSH消息计费鉴权应答消息的状态码，如果状态码为“OK”表示预扣成功，则进入步骤6)；否则预扣不成功，则中断当前业务请求；6)PPG把PUSH消息下发给终端；终端向PPG发送PUSH消息的应答消息；7)PPG处理下发应答结果(即push消息发送是“成功”还是“失败”)；应答结果反应所述PUSH消息下发是否成功；根据PUSH消息下发结果(即push消息发送是“成功”还是“失败”)，给DSMP发送计费确认请求消息，计费确认请求消息中包含了PUSH消息下发结果的状态码，如果push消息发送“成功”、计费确认请求消息中为“成功”；否则为“失败”；8)DSMP根据PUSH消息下发结果中的状态码决定需要进行真实计费还是进行计费回补，并向PPG发送计费确认应答消息，该消息包括PUSH消息信息费；如果PUSH消息下发成功，DSMP进行真实扣费，如果PUSH消息下发失败，DSMP进行信息费回补；9)PPG根据PUSH消息下发结果和PUSH消息信息费写话单，话单中需要记录如下字段信息
10)PPG向PI发送结果通知请求；PI返回结果通知请求的应答消息。该步骤并不是必需的，为可选项，并不影响PUSH消息的发送，也不影响PUSH消息的计费。
通过上述实施例可知，本发明的方法可以针对不同PI发送的PUSH消息，对不同PI采取不同的计费策略；可以对同一PI发送的不同的PUSH业务采取不同的计费策略；PUSH业务可以对PI进行计费，也可以对接收方进行计费，或者对双方同时进行计费；本发明的PUSH业务采取灵活的计费策略发布PUSH业务。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
权利要求
1.一种推送业务实现内容计费的方法，包括如下步骤1)推送的发起者向推送代理发送推送消息，消息中包含计费信息；2)推送代理将所述计费信息作为计费请求消息发送给数据业务管理平台；3)数据业务管理平台对收到的推送代理发送的计费请求消息进行处理，并返回应答消息给推送代理，通过应答消息将信息费价格发送给推送代理；4)推送代理处理接收到的所述应答消息，分析推送消息计费结果，如果预扣成功，则进入步骤5)；如果预扣不成功，则中断当前业务请求；5)推送代理把推送消息下发给终端，终端向推送代理返回推送消息的应答消息；6)推送代理根据终端返回的应答消息向数据业务管理平台发送计费确认请求消息，计费确认请求消息中包含了推送消息下发结果的状态码；7)数据业务管理平台根据推送消息下发结果中的状态码决定需要进行真实计费还是进行计费回补，并向推送代理发送包括推送消息信息费的计费确认应答消息。
2.根据权利要求1所述的一种推送业务实现内容计费的方法，其特征在于，在步骤2)之前还包括步骤1a)推送代理向推送的发起者返回推送消息的响应。
3.根据权利要求1所述的一种推送业务实现内容计费的方法，其特征在于，在步骤7)之后还包括步骤7a)推送代理根据推送消息下发结果和所述推送消息信息费生成话单。
4.根据权利要求3所述的一种推送业务实现内容计费的方法，其特征在于，在步骤1)中发送的推送消息中包含业务类型标识和计费方信息。
5.根据权利要求3所述的一种推送业务实现内容计费的方法，其特征在于，其中数据业务管理平台保存了各类业务类型的计费策略。
6.根据权利要求5所述的一种推送业务实现内容计费的方法，其特征在于，所述计费策略包括推送的发起者的代码标识、业务代码标识、推送的发起者的IP地址和该业务的价格中的一个或几个。
7.根据权利要求3至6中任一项所述的一种推送业务实现内容计费的方法，其特征在于，所述话单包括推送的发起者的代码标识、业务代码标识、推送的发起者的IP地址、推送消息下发结果、接收方号码、计费方和推送消息信息费中的一个或多个。
8.根据权利要求1至6中任一项所述的一种推送业务实现内容计费的方法，其特征在于，在所述步骤3)中对收到的推送代理发送的计费请求消息进行处理的步骤包括利用请求消息中的字段查询计费策略表，匹配到该推送的发起者发送的推送消息对应的信息费价格。
9.根据权利要求7所述的一种推送业务实现内容计费的方法，其特征在于，在所述步骤3)中对收到的推送代理发送的计费请求消息进行处理的步骤包括利用请求消息中的字段查询计费策略表，匹配到该推送的发起者发送的推送消息对应的信息费价格。
10.根据权利要求1至6中任一项所述的一种推送业务实现内容计费的方法，其特征在于，所述步骤7)包括如果推送消息下发成功，数据业务管理平台进行真实扣费，如果推送消息下发失败，数据业务管理平台进行信息费回补。
11.根据权利要求7所述的一种推送业务实现内容计费的方法，其特征在于，所述步骤7)包括如果推送消息下发成功，数据业务管理平台进行真实扣费，如果推送消息下发失败，数据业务管理平台进行信息费回补。
12.根据权利要求8所述的一种推送业务实现内容计费的方法，其特征在于，所述步骤7)包括如果推送消息下发成功，数据业务管理平台进行真实扣费，如果推送消息下发失败，数据业务管理平台进行信息费回补。
13.根据权利要求9所述的一种推送业务实现内容计费的方法，其特征在于，所述步骤7)包括如果推送消息下发成功，数据业务管理平台进行真实扣费，如果推送消息下发失败，数据业务管理平台进行信息费回补。
全文摘要
本发明涉及一种PUSH业务实现内容计费的方法，通过扩展现有技术中的PAP接口协议，在PUSH消息中增加计费信息的字段，PPG从所述PUSH消息中提取所述计费信息；所述计费信息作为计费鉴权、批价请求消息发送给数据业务管理平台DSMP；DSMP对收到的PPG发送的计费鉴权、批价请求消息进行处理，PPG处理从DSMP接收到的所述鉴权、批价应答消息，分析PUSH消息计费结果，把PUSH消息下发给终端；PPG根据终端返回的应答消息给DSMP发送包含了PUSH消息下发结果的状态码的计费确认请求消息，DSMP根据PUSH消息下发结果中的状态码进行计费。根据本发明的方案，使PUSH业务计费方式更加灵活。
文档编号H04L29/06GK1866842SQ20061007253
公开日2006年11月22日 申请日期2006年4月7日 优先权日2006年4月7日
发明者李荣高 申请人:华为技术有限公司