用量信息确定方法、发送方法、接收方法及装置与流程

文档序号:11845818阅读:346来源:国知局
用量信息确定方法、发送方法、接收方法及装置与流程

本发明涉及通信领域,具体而言,涉及一种用量信息确定方法、发送方法、接收方法及装置。



背景技术:

第三代合作伙伴计划(3rd Generation Partnership Project,简称为3GPP)的策略和计费控制(Policy and Charging Control,简称为PCC)架构是一个能够应用于多种接入技术的功能框架。例如,应用于通用移动通信系统(Universal Mobile Telecommunications System,简称为UMTS)的陆上无线接入网(UMTS Terrestrial Radio Access Network,简称为UTRAN)、全球移动通信系统(Global system for Mobile Communication,简称为GSM)/GSM数据增强演进(Enhanced Data rates for Global Evolution,简称为EDGE)无线接入网、互通无线局域网(I-WLAN)以及演进的分组系统(Evolved Packet System,简称为EPS)等。

图1为相关技术的Rel-8PCC非漫游架构的示意图一,以下参照图1对该PCC架构中的各个逻辑功能实体及其接口功能进行描述:

应用功能实体(Application Function,简称为AF),提供业务应用的接入点,这些业务应用所使用的网络资源需要进行动态的策略控制。在业务面进行参数协商时,AF将相关业务信息传递给策略与计费规则功能实体(Policy and Charging Rules Function,简称为PCRF),如果这些业务信息与PCRF的策略相一致,则PCRF接受该协商;否则,PCRF拒绝该协商,并在反馈中同时给出PCRF可接受的业务参数。随后,AF可将这些参数返回给用户设备(User Equipment,简称为UE)。其中,AF和PCRF之间的接口是Rx接口。

PCRF是PCC的核心,负责策略决策和计费规则的制定。PCRF提供了基于业务数据流的网络控制规则,这些网络控制包括业务数据流的监测、门控(Gating Control)、服务质量(Quality of Service,简称为QoS)控制以及基于数据流的计费规则等。PCRF将其制定的策略和计费规则发送给策略与计费执行功能实体(Policy and Charging Enforcement Function,简称为PCEF)执行,同时,PCRF还需要保证这些规则和用户的签约信息一致。PCRF制定策略和计费规则的依据包括:从AF获取与业务相关的信息;从用户签约数据库(Subscription Profile Repository,简称为SPR)获取用户策略计费控制签约信息;从PCEF获取与承载相关网络的信息。

PCEF,用于在承载面执行PCRF所制定的策略和计费规则。PCEF按照PCRF所发送的规则中的业务数据流过滤器对业务数据流进行监测,进而对这些业务数据流执行PCRF所制定的策略和计费规则。在承载建立时,PCEF按照PCRF发送的规则进行QoS授权,并根据AF的执行进行门控控制。根据PCRF发送的计费规则,PCEF执行相应的业务数据流计费操作,计费既可以是在线计费,也可以是离线计费。如果是在线计费,则PCEF需要和在线计费系统(Online Charging System,简称为OCS)一起进行信用管理。离线计费时,PCEF和离线计费系统(Offline Charging System,简称为OFCS)之间交换相关计费信息。PCEF与PCRF之间的接口是Gx接口,与OCS之间的接口是Gy接口,与OFCS之间的接口是Gz接口。PCEF通常位于网络的网关(Gate-Way,简称为GW)内,如GPRS中的GPRS网关支持节点(GGSN)以及I-WLAN中的分组数据网关(Packet Data Gateway,简称为PDG)。

承载绑定和事件报告功能实体(Bearer Binding and Event Reporting Function,简称为BBERF),其功能包括承载绑定、上行承载绑定的验证、以及事件报告。当UE通过E-UTRAN接入,并且S-GW与P-GW之间采用PMIPv6协议时,BBERF就位于S-GW,当UE通过可信任非3GPP接入系统接入时,BBERF位于可信任非3GPP接入网关,当UE通过不可信任非3GPP接入系统接入时、BBERF位于演进的分组数据网关(Evolved Packet Data Gateway,简称为ePDG)。此时,PCEF不再执行承载绑定功能。

用户签约数据库(SPR)存储了和策略控制与计费相关的用户策略计费控制签约信息。SPR和PCRF之间的接口是Sp接口。

在线计费系统(OCS),与PCEF一起进行在线计费方式下用户信用的控制和管理。

离线计费系统(OFCS),与PCEF一起完成离线计费方式下的计费操作。

以上PCC架构通过各功能实体实现了对UE为访问一个分组数据网络(Packet Data Network,简称为PDN)所建立的IP连接接入网(IP Connectivity Access Network,简称为IP-CAN)会话的策略计费控制。

随着移动互联网的发展,运营商需要与第三方数据应用提供商进行互通,为第三方数据应用提供商提供的业务进行QoS保障。由于目前PCC支持的Rx接口采用的Diameter协议,而对于大多数第三方数据应用提供商来说,他们更擅长基于SOAP、REST协议的开发。目前业界研究PCC架构支持基于SOAP/REST协议的Rx接口。在PCRF和AF直接设置一个称为协议转换器(Protocol Converter,简称PC)的逻辑功能,用于将SOAP或REST协议转换成Diameter,可以如图2所示,图2是相关技术中的Rel-8PCC非漫游架构的示意图二。其中,还可以 在PC上面增加一些接入控制功能,以便能够更好的实现运营商对第三方数据应用的接入控制,此时该逻辑功能还称为应用接入控制(Application Access Control,简称AAC)功能实体或者称为业务能力开放功能(Service Capability Exposure Function)。

第三方数据应用提供商可以在会话发起或会话过程中改变会话业务的可计费的主体(chargeable party),即访问业务的用户被计费或是第三方业务提供商被计费。

对于在会话过程中改变可计费主体的场景,由于当第三方应用提供商向PCRF发起变更请求到PCEF根据PCRF更新的策略执行计费策略有一个时间间隙,因此在这个时间间隙过程中会差生一定的计费误差。对单个用户单次访问,这个计费误差会比较小,但考虑到会有海量的用户访问一个第三方数据应用,因此运营商给第三方应用进行费用结算时,会出现非常大的累计误差。考虑到未来网络提供的速率将越来越快,因此这个误差将是非常惊人的。特别是考虑的存在PC/AAC的架构,由于新的网元的出现,势必会增加消息传递的延迟。因此,在相关技术中存在着计费误差的问题。

针对相关技术中存在的计费误差的问题,目前尚未提出有效的解决方案。



技术实现要素:

本发明提供了一种用量信息确定方法、发送方法、接收方法及装置,以至少解决相关技术中存在的计费误差的问题。

根据本发明的一个方面,提供了一种用量信息确定方法,其特征在于,包括:策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息,所述第一用量信息用于所述第三方应用的服务器确定第二用量信息,所述第二用量信息为所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的用量的信息。

进一步地,所述第一用量信息包括可计费主体变化之前所述UE访问所述第三方应用时所使用的流量和/或时长的信息;所述第二用量信息包括所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的流量和/或时长的信息。

进一步地,若变化之前的可计费主体是所述UE,则所述第二用量信息为第三用量信息减去所述第一用量信息,所述第三用量信息为所述第三方应用的服务器统计的所述UE在可计费主体变化之前和变化之后访问所述第三方应用的总用量;若变化之前的可计费主体是所述第三方应用的提供商,则所述第二用量信息 为所述第一用量信息。

进一步地,所述PCEF将可计费主体发生变化之前的第一用量信息发送给所述第三方应用的服务器之前,还包括:所述PCEF确定用于计量所述第一用量信息的用量计量方法,其中,所述PCEF和所述第三方应用的服务器采用相同的用量计量方法;所述PCEF根据确定的用量计量方法计量所述第一用量信息。

进一步地,所述PCEF确定用于计量所述第一用量信息的用量计量方法包括:所述PCEF接收策略和计费规则功能PCRF发送的策略和计费控制PCC规则,其中,所述PCC规则中携带所述用量计量方法的指示信息,所述PCRF根据所述第三方应用的提供商确定与所述第三方应用的服务器相同的用量计量方法。

进一步地,所述第三方应用的服务器向所述PCRF提供所述第三方应用的服务器采用的用量计量方法的指示信息,所述PCRF根据所述第三方应用的服务器提供的用量计量方法的指示信息确定所述PCEF采用的用量计量方法。

进一步地,所述PCEF根据确定的用量计量方法计量所述第一用量信息包括以下至少之一:所述PCEF根据确定的用量计量方法通过由所述PCEF统计的方式确定第一用量信息;所述PCEF根据确定的用量计量方法通过由所述PCEF与在线计费系统OCS进行交互的方式确定所述第一用量信息;所述PCEF根据确定的用量计量方法通过由所述PCEF与离线计费系统OFCS进行交互的方式确定所述第一用量信息。

进一步地,所述PCEF将所述第一用量信息发送给所述第三方应用的服务器包括以下至少之一:所述PCEF将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF将所述第一用量信息发送给应用功能AF,所述AF将所述第一用量信息上报给所述第三方应用的服务器;所述PCEF将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将所述第一用量信息发送给应用功能AF,所述AF将所述第一用量信息上报给所述第三方应用的服务器。

根据本发明的另一方面,提供了一种用量信息发送方法,包括:策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给应用功能AF,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问第三方应用所使用的用量的信息。

进一步地,所述第一用量信息包括访问所述第三方应用所使用的时间和/或流量。

进一步地,所述PCEF将所述第一用量信息发送给所述AF包括以下至少之一:所述PCEF将所述第一用量信息发送给策略和计费规则功能PCRF,所述 PCRF将所述第一用量信息发送给所述AF;所述PCEF将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将所述第一用量信息发送给所述AF。

根据本发明的另一方面,提供了一种用量信息确定方法,包括:第三方应用的服务器接收策略与计费执行功能实体PCEF发送的第一用量信息,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问所述第三方应用的用量的信息;所述第三方应用的服务器根据所述第一用量信息确定第二用量信息,其中,所述第二用量信息为所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的用量的信息。

进一步地,所述第一用量信息包括可计费主体变化之前所述UE访问所述第三方应用时所使用的流量和/或时长的信息;所述第二用量信息包括所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的流量和/或时长的信息。

进一步地,所述第三方应用的服务器根据所述第一用量信息确定第二用量信息包括:若变化之前的可计费主体是所述UE,所述第三方应用的服务器通过将第三用量信息减去所述第一用量信息得到所述第二用量信息,其中,所述第三用量信息为所述第三方应用的服务器统计的所述UE在可计费主体变化之前和变化之后访问所述第三方应用的总用量;若变化之前的可计费主体是所述第三方应用的提供商,所述第三方应用的服务器将所述第一用量信息确定为所述第二用量信息。

进一步地,所述第三方应用的服务器根据所述第一用量信息确定所述第二用量信息之前,还包括:所述第三方应用的服务器确定用于计量所述第三用量信息的用量计量方法;所述第三方应用的服务器根据确定的用量计量方法计量所述第三用量信息。

进一步地,所述第三方应用的服务器确定用于计量所述第三用量信息的用量计量方法包括:所述第三方应用的服务器通过与所述第三方应用的运营商签约协议的方式确定所述用量计量方法;所述第三方应用的服务器通过与所述第三方应用的运营商进行动态协商的方式确定所述用量计量方法。

根据本发明的另一方面,提供了一种用量信息接收方法,包括:应用功能AF接收策略与计费执行功能实体PCEF发送的可计费主体发生变化之前的第一用量信息,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问第三方应用所使用的用量的信息。

进一步地,所述第一用量信息包括访问所述第三方应用所使用的时间和/或流量。

进一步地,所述AF接收所述PCEF发送的所述第一用量信息包括:所述AF通过策略和计费规则功能PCRF接收所述PCEF发送的所述第一用量信息。

根据本发明的另一方面,提供了一种用量信息确定装置,所述装置应用于策略与计费执行功能实体PCEF中,包括:第一发送模块,用于将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问所述第三方应用的用量的信息,所述第一用量信息用于所述第三方应用的服务器确定第二用量信息,所述第二用量信息为所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的用量的信息。

进一步地,所述第一用量信息包括可计费主体变化之前所述UE访问所述第三方应用时所使用的流量和/或时长的信息;所述第二用量信息包括所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的流量和/或时长的信息。

进一步地,若变化之前的可计费主体是所述UE,则所述第二用量信息为第三用量信息减去所述第一用量信息,所述第三用量信息为所述第三方应用的服务器统计的所述UE在可计费主体变化之前和变化之后访问所述第三方应用的总用量;若变化之前的可计费主体是所述第三方应用的提供商,则所述第二用量信息为所述第一用量信息。

进一步地,所述装置还包括:第一确定模块,用于确定用于计量所述第一用量信息的用量计量方法,其中,所述PCEF和所述第三方应用的服务器采用相同的用量计量方法;第一计量模块,用于根据确定的用量计量方法计量所述第一用量信息。

进一步地,所述第一确定模块包括:第一接收单元,用于接收策略和计费规则功能PCRF发送的策略和计费控制PCC规则,其中,所述PCC规则中携带所述用量计量方法的指示信息,所述PCRF根据所述第三方应用的提供商确定与所述第三方应用的服务器相同的用量计量方法。

进一步地,所述第三方应用的服务器向所述PCRF提供所述第三方应用的服务器采用的用量计量方法的指示信息,所述PCRF根据所述第三方应用的服务器提供的用量计量方法的指示信息确定所述PCEF采用的用量计量方法。

进一步地,所述第一计量模块包括以下至少之一:所述PCEF根据确定的用量计量方法通过由所述PCEF统计的方式确定第一用量信息;所述PCEF根据确定的用量计量方法通过由所述PCEF与在线计费系统OCS进行交互的方式确定所述第一用量信息;所述PCEF根据确定的用量计量方法通过由所述PCEF与离线计费系统OFCS进行交互的方式确定所述第一用量信息。

进一步地,所述第一发送模块包括以下至少之一:第一发送单元,用于将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF将所述第一用量信息发送给应用功能AF,所述AF将所述第一用量信息上报给所述第三方应用的服务器;第二发送单元,用于将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将所述第一用量信息发送给应用功能AF,所述AF将所述第一用量信息上报给所述第三方应用的服务器。

根据本发明的另一方面,提供了一种用量信息发送装置,所述装置应用于策略与计费执行功能实体PCEF中,包括:第二发送模块,用于将可计费主体发生变化之前的第一用量信息发送给应用功能AF,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问第三方应用所使用的用量的信息。

进一步地,所述第一用量信息包括访问所述第三方应用所使用的时间和/或流量。

进一步地,所述第二发送模块包括以下至少之一:第三发送单元,用于将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF将所述第一用量信息发送给所述AF;第四发送单元,用于将所述第一用量信息发送给策略和计费规则功能PCRF,所述PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将所述第一用量信息发送给所述AF。

根据本发明的另一方面,提供了一种用量信息确定装置,所述装置应用于第三方应用的服务器中,包括:第一接收模块,用于接收策略与计费执行功能实体PCEF发送的第一用量信息,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问所述第三方应用的用量的信息;第二确定模块,用于根据所述第一用量信息确定第二用量信息,其中,所述第二用量信息为所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的用量的信息。

进一步地,所述第一用量信息包括可计费主体变化之前所述UE访问所述第三方应用时所使用的流量和/或时长的信息;所述第二用量信息包括所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的流量和/或时长的信息。

进一步地,所述第二确定模块包括:若变化之前的可计费主体是所述UE,所述第三方应用的服务器通过将第三用量信息减去所述第一用量信息得到所述第二用量信息,其中,所述第三用量信息为所述第三方应用的服务器统计的所述UE在可计费主体变化之前和变化之后访问所述第三方应用的总用量;若变化之前的可计费主体是所述第三方应用的提供商,所述第三方应用的服务器将所述第一用量信息确定为所述第二用量信息。

进一步地,所述装置还包括:第三确定模块,用于确定用于计量所述第三用量信息的用量计量方法;第二计量模块,用于根据确定的用量计量方法计量所述第三用量信息。

进一步地,所述第三确定模块包括以下至少之一:第一确定单元,用于通过与所述第三方应用的运营商签约协议的方式确定所述用量计量方法;第二确定单元,用于通过与所述第三方应用的运营商进行动态协商的方式确定所述用量计量方法。

根据本发明的另一方面,提供了一种用量信息接收装置,所述装置应用于应用功能AF中,包括:第二接收模块,用于接收策略与计费执行功能实体PCEF发送的可计费主体发生变化之前的第一用量信息,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问所述第三方应用所使用的用量的信息。

进一步地,所述第一用量信息包括访问所述第三方应用所使用的时间和/或流量。

进一步地,所述第二接收模块包括:第二接收单元,用于通过策略和计费规则功能PCRF接收所述PCEF发送的所述第一用量信息。

通过本发明,采用策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,所述第一用量信息为可计费主体变化之前用户设备UE访问所述第三方应用的用量的信息,所述第一用量信息用于所述第三方应用的服务器确定第二用量信息,所述第二用量信息为所述第三方应用的提供商为所述UE支付的用于所述UE访问所述第三方应用的用量的信息,解决了相关技术中存在的计费误差的问题,进而达到了减小计费误差的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:

图1为相关技术的Rel-8PCC非漫游架构的示意图一;

图2是相关技术中的Rel-8PCC非漫游架构的示意图二;

图3是根据本发明实施例的第一种用量信息确定方法的流程图;

图4是根据本发明实施例的用量信息发送方法的流程图;

图5是根据本发明实施例的第二种用量信息确定方法的流程图;

图6是根据本发明实施例的用量信息接收方法的流程图;

图7是根据本发明实施例的第一种用量信息确定装置的结构框图;

图8是根据本发明实施例的第一种用量信息确定装置的优选结构框图;

图9是根据本发明实施例的第一种用量信息确定装置中第一确定模块82的结构框图;

图10是根据本发明实施例的第一种用量信息确定装置中第一发送模块72的结构框图;

图11是根据本发明实施例的用量信息发送装置的结构框图;

图12是根据本发明实施例的用量信息发送装置中第二发送模块112的结构框图;

图13是根据本发明实施例的第二种用量信息确定装置的结构框图;

图14是根据本发明实施例的第二种用量信息确定装置的优选结构框图;

图15是根据本发明实施例的第二种用量信息确定装置中第三确定模块142的结构框图;

图16是根据本发明实施例的用量信息接收装置的结构框图;

图17是根据本发明实施例的用量信息确定装置中第二接收模块162的结构框图;

图18是根据本发明实施例一的用量上报流程图;

图19是根据本发明实施例二的用量上报流程图;

图20是根据本发明实施例三的用量上报流程图;

图21是根据本发明实施例四的用量上报流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种用量信息确定方法,图3是根据本发明实施例的第一种用量信息确定方法的流程图,如图3所示,该流程包括如下步骤:

步骤S302,策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,该第一用量信息为可计费主体 变化之前用户设备UE访问第三方应用的用量的信息,该第一用量信息用于第三方应用的服务器确定第二用量信息,该第二用量信息为第三方应用的提供商为UE支付的用于UE访问第三方应用的用量的信息。

上述的可计费主体可以是用户设备UE,也可以是第三方应用的提供商,可计费主体的变化可以使在二者之间进行的切换。通过上述步骤,在变更可计费主体时,将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,从而使得该第三方服务器能够精确的计量出第三方应用的提供商应该为用户设备UE支付的用量信息,提高计费精度,从而解决了相关技术中存在的计费误差的问题,进而达到了减小计费误差的效果。

UE访问第三方应用时,可以是以访问的时间进行计费的,也可以是以消耗的流量进行计费的,还可以综合时间和流量进行计费,如,将流量费用划分为闲时的费用和忙时的费用。在一个可选的实施例中,上述第一用量信息包括可计费主体变化之前UE访问第三方应用时所使用的流量和/或时长的信息;上述第二用量信息包括第三方应用的提供商为UE支付的用于UE访问第三方应用的流量和/或时长的信息。

其中,若变化之前的可计费主体是UE,则该第二用量信息为第三用量信息减去第一用量信息,该第三用量信息为第三方应用的服务器统计的UE在可计费主体变化之前和变化之后访问第三方应用的总用量;若变化之前的可计费主体是第三方应用的提供商,则该第二用量信息为第一用量信息。

在一个可选的实施例中,上述的PCEF将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器之前,还包括:PCEF确定用于计量第一用量信息的用量计量方法,其中,该PCEF和第三方应用的服务器采用相同的用量计量方法;PCEF根据确定的用量计量方法计量该第一用量信息。

其中,上述的PCEF确定用于计量第一用量信息的用量计量方法包括:该PCEF接收策略和计费规则功能PCRF发送的策略和计费控制PCC规则,其中,PCC规则中携带用量计量方法的指示信息,该PCRF根据第三方应用的提供商确定与第三方应用的服务器相同的用量计量方法。

第三方应用的服务器向PCRF提供第三方应用的服务器采用的用量计量方法的指示信息,该PCRF根据上述第三方应用的服务器提供的用量计量方法的指示信息确定PCEF采用的用量计量方法。

在一个可选的实施例中,上述PCEF根据确定的用量计量方法计量第一用量信息时,可以有多种确定方法,可以包括以下至少之一:PCEF根据确定的用量计量方法通过由PCEF统计的方式确定第一用量信息;PCEF根据确定的用量计量方法通过由PCEF与在线计费系统OCS进行交互的方式确定第一用量信息; PCEF根据确定的用量计量方法通过由PCEF与离线计费系统OFCS进行交互的方式确定第一用量信息。

在一个可选的实施例中,上述的PCEF将第一用量信息发送给第三方应用的服务器包括以下至少之一:PCEF将第一用量信息发送给策略和计费规则功能PCRF,该PCRF将第一用量信息发送给AF,该AF将第一用量信息上报给第三方应用的服务器;PCEF将第一用量信息发送给策略和计费规则功能PCRF,该PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将第一用量信息发送给AF,AF将第一用量信息上报给第三方应用的服务器。

图4是根据本发明实施例的用量信息发送方法的流程图,如图4所示,该方法包括如下步骤:

步骤S402,策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给应用功能AF,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的所使用的用量的信息。

通过上述步骤,当可计费主体发生变化时,PCEF将变化前的UE的用量信息发送给AF,从而可以明确可计费主体发生变化前,UE访问第三方应用的用量信息,从而为后续的计费做好了铺垫,提高计费精度。解决了相关技术中存在的计费误差的问题,进而达到了减小计费误差的效果。

UE访问第三方应用时,可以是以访问的时间进行计费的,也可以是以消耗的流量进行计费的,还可以综合时间和流量进行计费,如,将流量费用划分为闲时的费用和忙时的费用,在一个可选的实施例中,上述第一用量信息可以包括访问第三方应用所使用的时间和/或流量。

其中,PCEF将第一用量信息发送给AF可以包括以下至少之一:PCEF将第一用量信息发送给策略和计费规则功能PCRF,该PCRF将第一用量信息发送给AF;PCEF将第一用量信息发送给策略和计费规则功能PCRF,该PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将第一用量信息发送给AF。

图5是根据本发明实施例的第二种用量信息确定方法的流程图,如图5所示,该流程包括如下步骤:

步骤S502,第三方应用的服务器接收策略与计费执行功能实体PCEF发送的第一用量信息,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息;

步骤S504,该第三方应用的服务器根据第一用量信息确定第二用量信息,其中,第二用量信息为第三方应用的提供商为上述UE支付的用于UE访问第三 方应用的用量的信息。

上述的可计费主体可以是用户设备UE,也可以是第三方应用的提供商,可计费主体的变化可以使在二者之间进行的切换。通过上述步骤,在变更可计费主体时,将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,从而使得该第三方服务器能够精确的计量出第三方应用的提供商应该为用户设备UE支付的用量信息,提高计费精度,从而解决了相关技术中存在的计费误差的问题,进而达到了减小计费误差的效果。

UE访问第三方应用时,可以是以访问的时间进行计费的,也可以是以消耗的流量进行计费的,还可以综合时间和流量进行计费,如,将流量费用划分为闲时的费用和忙时的费用。在一个可选的实施例中,上述第一用量信息包括可计费主体变化之前UE访问第三方应用时所使用的流量和/或时长的信息;第二用量信息包括第三方应用的提供商为UE支付的用于该UE访问第三方应用的流量和/或时长的信息。

在一个可选的实施例中,上述第三方应用的服务器根据第一用量信息确定第二用量信息包括:若变化之前的可计费主体是UE,第三方应用的服务器通过将第三用量信息减去第一用量信息得到第二用量信息,其中,该第三用量信息为第三方应用的服务器统计的UE在可计费主体变化之前和变化之后访问第三方应用的总用量;若变化之前的可计费主体是第三方应用的提供商,该第三方应用的服务器将第一用量信息确定为第二用量信息。

在一个可选的实施例中,上述第三方应用的服务器根据第一用量信息确定第二用量信息之前,还包括:第三方应用的服务器确定用于计量第三用量信息的用量计量方法;该第三方应用的服务器根据确定的用量计量方法计量第三用量信息。

其中,第三方应用的服务器确定用于计量第三用量信息的用量计量方法包括:该第三方应用的服务器通过与第三方应用的运营商签约协议的方式确定用量计量方法;该第三方应用的服务器通过与第三方应用的运营商进行动态协商的方式确定用量计量方法。

图6是根据本发明实施例的用量信息接收方法的流程图,如图6所示,该流程包括如下步骤:

步骤S602,应用功能AF接收策略与计费执行功能实体PCEF发送的可计费主体发生变化之前的第一用量信息,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用所使用的用量的信息。

通过上述步骤,当可计费主体发生变化时,PCEF将变化前的UE的用量信息发送给AF,从而可以明确可计费主体发生变化前,UE访问第三方应用的用 量信息,从而为后续的计费做好了铺垫,提高计费精度。解决了相关技术中存在的计费误差的问题,进而达到了减小计费误差的效果。

UE访问第三方应用时,可以是以访问的时间进行计费的,也可以是以消耗的流量进行计费的,还可以综合时间和流量进行计费,如,将流量费用划分为闲时的费用和忙时的费用,在一个可选的实施例中,上述第一用量信息包括访问第三方应用所使用的时间和/或流量。

在一个可选的实施例中,上述AF接收PCEF发送的第一用量信息包括:该AF通过策略和计费规则功能PCRF接收PCEF发送的第一用量信息。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例的方法。

在本实施例中还提供了一种用量信息确定装置,该装置用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。

图7是根据本发明实施例的第一种用量信息确定装置的结构框图,该装置应用于策略与计费执行功能实体PCEF中,如图7所示,该装置包括第一发送模块72,下面对该装置进行说明。

第一发送模块72,用于将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息,第一用量信息用于第三方应用的服务器确定第二用量信息,该第二用量信息为第三方应用的提供商为用户设备UE支付的用于UE访问第三方应用的用量的信息。

其中,上述的第一用量信息包括可计费主体变化之前UE访问第三方应用时所使用的流量和/或时长的信息;上述第二用量信息包括第三方应用的提供商为UE支付的用于UE访问第三方应用的流量和/或时长的信息。

若变化之前的可计费主体是UE,则该第二用量信息为第三用量信息减去第一用量信息,第三用量信息为第三方应用的服务器统计的UE在可计费主体变化之前和变化之后访问第三方应用的总用量;若变化之前的可计费主体是第三方应 用的提供商,则该第二用量信息为第一用量信息。

图8是根据本发明实施例的第一种用量信息确定装置的优选结构框图,如图8所示,该装置除包括图7所示的模块外,还包括第一确定模块82和第一计量模块84,下面对该装置进行说明。

第一确定模块82,用于确定用于计量第一用量信息的用量计量方法,其中,该PCEF和第三方应用的服务器采用相同的用量计量方法;第一计量模块84,连接至上述第一确定模块82和第一发送模块72,用于根据确定的用量计量方法计量第一用量信息。

图9是根据本发明实施例的第一种用量信息确定装置中第一确定模块82的结构框图,如图9所示,该第一确定模块82包括第一接收单元92,下面对该第一确定模块82进行说明:

第一接收单元92,用于接收策略和计费规则功能PCRF发送的策略和计费控制PCC规则,其中,该PCC规则中携带用量计量方法的指示信息,PCRF根据第三方应用的提供商确定与第三方应用的服务器相同的用量计量方法。

其中,上述第三方应用的服务器向PCRF提供第三方应用的服务器采用的用量计量方法的指示信息,PCRF根据第三方应用的服务器提供的用量计量方法的指示信息确定PCEF采用的用量计量方法。

在一个可选的实施例中,上述第一计量模块84包括以下至少之一:PCEF根据确定的用量计量方法通过由PCEF统计的方式确定第一用量信息;PCEF根据确定的用量计量方法通过由PCEF与在线计费系统OCS进行交互的方式确定第一用量信息;PCEF根据确定的用量计量方法通过由PCEF与离线计费系统OFCS进行交互的方式确定第一用量信息。

图10是根据本发明实施例的第一种用量信息确定装置中第一发送模块72的结构框图,如图10所示,该第一发送模块72包括第一发送单元102和/或第二发送单元104,下面对该第一发送模块72进行说明。

第一发送单元102,用于将第一用量信息发送给策略和计费规则功能PCRF,该PCRF将第一用量信息发送给AF,AF将第一用量信息上报给第三方应用的服务器;第二发送单元104,用于将第一用量信息发送给策略和计费规则功能PCRF,该PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将第一用量信息发送给AF,该AF将第一用量信息上报给第三方应用的服务器。

图11是根据本发明实施例的用量信息发送装置的结构框图,该装置应用于策略与计费执行功能实体PCEF中,如图11所示,该用量信息发送装置包括第二发送模块112,下面对该装置进行说明。

第二发送模块112,用于将可计费主体发生变化之前的第一用量信息发送给应用功能AF,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的所使用的用量的信息。

其中,上述第一用量信息包括访问第三方应用所使用的时间和/或流量。

图12是根据本发明实施例的用量信息发送装置中第二发送模块112的结构框图,如图12所示,该第二发送模块112包括第三发送单元122和/或第四发送单元124,下面对该第二发送模块112进行说明。

第三发送单元122,用于将第一用量信息发送给策略和计费规则功能PCRF,该PCRF将第一用量信息发送给AF;第四发送单元124,用于将第一用量信息发送给策略和计费规则功能PCRF,该PCRF通过协议转换器PC、应用接入控制AAC或业务能力开发功能SCEF将第一用量信息发送给AF。

图13是根据本发明实施例的第二种用量信息确定装置的结构框图,该装置应用于第三方应用的服务器中,包括第一接收模块132和第二确定模块134,下面对该装置进行说明。

第一接收模块132,用于接收策略与计费执行功能实体PCEF发送的第一用量信息,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息;第二确定模块134,连接至上述第一接收模块132,用于根据第一用量信息确定第二用量信息,其中,该第二用量信息为第三方应用的提供商为上述UE支付的用于该UE访问第三方应用的用量的信息。

其中,上述的第一用量信息包括可计费主体变化之前UE访问第三方应用时所使用的流量和/或时长的信息;该第二用量信息包括第三方应用的提供商为UE支付的用于UE访问第三方应用的流量和/或时长的信息。

在一个可选的实施例中,第二确定模块134包括:若变化之前的可计费主体是UE,第三方应用的服务器通过将第三用量信息减去第一用量信息得到第二用量信息,其中,该第三用量信息为第三方应用的服务器统计的UE在可计费主体变化之前和变化之后访问第三方应用的总用量;若变化之前的可计费主体是第三方应用的提供商,该第三方应用的服务器将第一用量信息确定为第二用量信息。

图14是根据本发明实施例的第二种用量信息确定装置的优选结构框图,如图14所示,该装置除包括图13所示的所有模块外,还包括第三确定模块142和第二计量模块144,下面对该装置进行说明。

第三确定模块142,用于确定用于计量第三用量信息的用量计量方法;第二计量模块144,连接至上述第三确定模块142和第一接收模块132,用于根据确定的用量计量方法计量第三用量信息。

图15是根据本发明实施例的第二种用量信息确定装置中第三确定模块142的结构框图,如图15所示,该第三确定模块142包括第一确定单元152和/或第二确定单元154,下面对该第三确定模块142进行说明。

第一确定单元152,用于通过与第三方应用的运营商签约协议的方式确定用量计量方法;第二确定单元154,用于通过与第三方应用的运营商进行动态协商的方式确定用量计量方法。

图16是根据本发明实施例的用量信息接收装置的结构框图,该装置应用于应用功能AF中,如图16所示,该装置包括第二接收模块162,下面对该装置进行说明。

第二接收模块162,用于接收策略与计费执行功能实体PCEF发送的可计费主体发生变化之前的第一用量信息,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用所使用的用量的信息。

其中,上述的第一用量信息包括访问第三方应用所使用的时间和/或流量。

图17是根据本发明实施例的用量信息确定装置中第二接收模块162的结构框图,如图17所示,第二接收模块162包括第二接收单元172,下面对该第二接收模块162进行说明。

第二接收单元172,用于通过策略和计费规则功能PCRF接收PCEF发送的第一用量信息。

下面结合具体实施例对本发明进行说明:

实施例一

本实施例描述在在发起业务时,可计费主体为用户设备UE,在业务访问过程中,可计费主体变为第三方应用的提供商的流程。

图18是根据本发明实施例一的用量上报流程图,如图18所示,该流程包括如下步骤:

步骤S1802:UE附着到网络,建立IP-CAN会话。在这个过程中,PCEF与PCRF之间建立用于策略和计费控制的Gx会话。若IP-CAN会话涉及BBERF,则BBERF与PCRF之间建立用于策略控制的网关控制会话。

步骤S1804:UE与第三方应用服务器交互,发起业务访问。在业务访问的过程中,第三方应用服务器会对UE的业务访问计费,统计(Accounting)(也称计量,Metering)UE访问的用量信息(Usage Information),用量信息可以是流量和/或时长。

步骤S1806:第三方应用服务器与AF之间执行特定的交互流程,向应用服务器或AF提供用户请求的业务信息。

步骤S1808:AF向PCRF发送Diameter AAR消息,携带业务信息。

步骤S1810:PCRF向AF返回确认消息。

步骤S1812:PCRF根据业务信息、网络策略以及用户签约等信息制定PCC规则。若BBERF存在,则PCRF还根据PCC规则制定QoS规则。

步骤S1814:PCRF向BBERF提供QoS规则。

步骤S1816:PCRF向PCEF提供PCC规则。PCEF执行PCC规则,并根据PCC规则中的计费策略对UE访问的第三方业务进行计费,统计(也称计量)UE访问业务产生的用量信息。用量信息可以是流量和/或时长。该计费是针对UE进行计费的。

步骤S1818:在UE访问第三方业务的过程中,第三方应用决定赞助UE正在访问的第三方业务,应用服务器与AF交互,向AF发送赞助业务的指示,以及赞助商标识,应用提供商标识。

步骤S1820:AF向PCRF发送AAR消息,消息中携带被赞助数据连接信息,包括赞助商标识、应用提供商标识。

步骤S1822:PCRF保存信息后,返回确认消息;

步骤S1824:PCRF根据进行策略决策,更新之前制定的PCC规则。PCRF根据赞助商标识和应用提供商标识确认相应的计费键(Charging key)和/或PCRF在PCC规则中增加赞助商标识和应用提供商标识。

步骤S1826:PCRF向PCEF提供PCC规则。

步骤S1828:PCEF向PCRF返回确认消息,并在消息中携带UE本次业务访问中,在可计费主体发生切换前的累计用量信息(该用量可以是流量和/或时长)。PCEF可以自己统计(也称计量)UE发起本次业务以来的累计用量信息,也可以通过与计费系统(OCS或OFCS)交互获取UE发起本次业务以来的累计用量信息。

步骤S1830:PCRF向AF发送RAR消息,消息中携带累计用量信息。

步骤S1832:AF返回确认消息。

步骤S1834:AF与第三方应用服务器的特定消息,譬如将累计用量信息上报给第三方应用服务器。

AF和第三方应用服务器从实现上可以是独立部署,AF也可以集成在第三方应用服务器上。不管哪种部署,从PCRF角度,PCRF与AF的互通也可以认为是PCRF与第三方应用服务器的互通。

实施例二

本实施例描述了在存在PC/AAC/SCEF的场景下,在发起业务时,可计费主体为用户设备UE,在业务访问过程中,变为第三方应用提供商的流程。

图19是根据本发明实施例二的用量上报流程图,如图19所示,该流程包括如下步骤:

步骤S1902:UE附着到网络,建立IP-CAN会话。在这个过程中,PCEF与PCRF之间建立用于策略和计费控制的Gx会话。若IP-CAN会话涉及BBERF,则BBERF与PCRF之间建立用于策略控制的网关控制会话。

步骤S1904:UE与第三方应用服务器交互,发起业务访问。在业务访问的过程中,第三方应用服务器会对UE的业务访问计费,统计(也称计量)UE访问的用量信息,其中用量信息可以是流量和/或时长。

步骤S1906:第三方应用服务器与AF之间执行特定的交互流程,第三方应用服务器向AF提供用户请求的业务信息。

步骤S1908:AF向PC/AAC/SCEF发送HTTP POST,消息中携带业务信息。

步骤S1910:PC/AAC/SCEF向PCRF发送Diameter AAR消息,携带业务信息。

步骤S1912:PCRF向AF返回确认消息。

步骤S1914:PC/AAC/SCEF向AF返回确认消息。

步骤S1916:PCRF根据业务信息、网络策略以及用户签约等信息制定PCC规则。若BBERF存在,则PCRF还根据PCC规则制定QoS规则。

步骤S1918:PCRF向BBERF提供QoS规则。

步骤S1920:PCRF向PCEF提供PCC规则。PCEF执行PCC规则,并根据PCC规则中的计费策略对UE访问的第三方业务进行统计(也称计量)UE访问业务产生的用量信息。用量信息可以是流量和/或时长。该计费是针对用户进行计费的(可计费主体是UE)。

步骤S1922:在UE访问第三方业务的过程中,第三方应用决定赞助UE正 在访问的第三方业务,第三方应用服务器与AF交互,向AF发送赞助业务的指示,以及赞助商标识,应用提供商标识。

步骤S1924:AF向PC/AAC/SCEF发送HTTP PUT消息,消息中携带被赞助数据连接信息,包括赞助商标识、应用提供商标识。

步骤S1926:PC/AAC/SCEF向PCRF发送AAR消息,消息中携带被赞助数据连接信息,包括赞助商标识、应用提供商标识。

步骤S1928:PCRF保存信息后,向PC/AAC返回确认消息。

步骤S1930:PC/AAC/SCEF向AF返回确认消息。

步骤S1932:PCRF根据进行策略决策,更新之前制定的PCC规则。PCRF根据赞助商标识和应用提供商标识确认相应的计费键(Charging key)和/或PCRF在PCC规则中增加赞助商标识和应用提供商标识。

步骤S1934:PCRF向PCEF提供PCC规则。

步骤S1936:PCEF向PCRF返回确认消息,并在消息中携带UE本次业务访问中,在可计费主体发生切换前的累计用量信息(该用量可以是流量和/或时长)。PCEF可以自己统计(也称计量)UE发起本次业务以来的累计用量,也可以通过与计费系统(OCS或OFCS)交互获取UE发起本次业务以来的累计用量信息。

步骤S1938:PCRF向PC/AAC发送RAR消息,消息中携带累计用量信息。

步骤S1940:PC/AAC向AF发送HTTP PUT消息,消息中携带累计用量信息。

步骤S1942:AF向PC/AAC返回确认消息。

步骤S1944:PC/AAC向PCRF返回确认消息。

步骤S1946:AF与第三方应用服务器的特定消息,譬如向累计用量信息上报给应用服务器。

通过实施例一和实施例二的流程,第三方应用提供商获得了网关在执行变更可计费主体策略之前,用户(同上述的UE)访问第三方数据应用产生的累计用量信息。这部分累计用量信息是由用户承担的。同时第三方数据应用自身也会统计用户访问第三方数据的用量信息。这样,第三方数据应用提供商就可以比较精确的获知其真正赞助的第三方数据应用的累计用量信息了。若到UE结束业务访问时,可计费主体始终是第三方应用,那么第三方应用提供商赞助的用量为第三方数据应用自身统计的用户访问第三方数据的用量减去网关上报的可计费主体 变更前用户承担的累计用量信息。

AF和第三方应用服务器从实现上可以是独立部署,也可以AF集成在第三方应用服务器上。不管哪种部署,从PC/AAC/SCEF角度,PCRFPC/AAC/SCEF与AF的互通也可以认为是PC/AAC/SCEF与第三方应用服务器的互通。

实施例三

本实施例描述在在发起业务时,可计费主体为第三方应用提供商,在业务访问过程中,变为UE的流程。

图20是根据本发明实施例三的用量上报流程图,如图20所示,该流程包括如下步骤:

步骤S2002:UE附着到网络,建立IP-CAN会话。在这个过程中,PCEF与PCRF之间建立用于策略和计费控制的Gx会话。若IP-CAN会话涉及BBERF,则BBERF与PCRF之间建立用于策略控制的网关控制会话。

步骤S2004:UE与第三方应用服务器交互,发起业务访问。在业务访问的过程中,第三方应用服务器会对UE的业务访问计费,统计(也称计量)UE访问的用量信息,其中用量信息可以是流量和/或时长。

步骤S2006:第三方应用服务器与AF之间执行特定的交互流程,向应用服务器向AF提供用户请求的业务信息,其中第三方应用决定赞助用户访问的数据应用,第三方应用服务器向AF提供赞助业务的指示,以及赞助商标识,应用提供商标识。

步骤S2008:AF向PCRF发送Diameter AAR消息,携带业务信息,被赞助数据连接信息,包括赞助商标识,应用提供商标识。

步骤S2010:PCRF向AF返回确认消息。

步骤S2012:PCRF根据业务信息、网络策略以及用户签约等信息制定PCC规则。PCRF根据赞助商标识和应用提供商标识确认相应的计费键(Charging key)和/或PCRF在PCC规则中增加赞助商标识和应用提供商标识。若BBERF存在,则PCRF还根据PCC规则制定QoS规则。

步骤S2014:PCRF向BBERF提供QoS规则。

步骤S2016:PCRF向PCEF提供PCC规则。PCEF执行PCC规则,并根据PCC规则中的计费策略对UE访问的第三方业务进行计费,统计(也称计量)UE访问业务产生的用量信息。用量信息可以是流量和/或时长。该计费是针对第 三方应用提供商进行计费的。

步骤S2018:在UE访问第三方业务的过程中,第三方应用决定取消赞助UE正在访问的第三方业务,第三方应用服务器与AF交互,向AF发送取消赞助的指示。

步骤S2020:AF向PCRF发送AAR消息,消息中携带被取消赞助指示。

步骤S2022:PCRF保存信息后,返回确认消息。

步骤S2024:PCRF根据进行策略决策,更新之前制定的PCC规则,携带取消赞助指示。PCRF在PCC规则携带其他可以对用户进行计费的计费键。

步骤S2026:PCRF向PCEF提供PCC规则。

步骤S2028:PCEF向PCRF返回确认消息,并在消息中携带UE本次业务访问中,在可计费主体发生切换前的累计用量信息(该用量可以是流量和/或时长)。PCEF可以自己统计(也称计量)UE发起本次业务以来的累计用量信息,也可以通过与计费系统(OCS或OFCS)交互获取UE发起本次业务以来的累计用量信息。

步骤S2030:PCRF向AF发送RAR消息,消息中携带累计用量信息。

步骤S2032:AF返回确认消息。

步骤S2034:AF与第三方应用服务器的特定消息,譬如向累计用量上报给应用服务器。

AF和第三方应用服务器从实现上可以是独立部署,也可以AF集成在第三方应用服务器上。不管哪种部署,从PCRF角度,PCRF与AF的互通也可以认为是PCRF与第三方应用服务器的互通。

实施例四

本实施例描述在在发起业务时,可计费主体为第三方应用提供商,在业务访问过程中,变为UE的流程。

图21是根据本发明实施例四的用量上报流程图,如图21所示,该流程包括如下步骤:

步骤S2102:UE附着到网络,建立IP-CAN会话。在这个过程中,PCEF与PCRF之间建立用于策略和计费控制的Gx会话。若IP-CAN会话涉及BBERF,则BBERF与PCRF之间建立用于策略控制的网关控制会话。

步骤S2104:UE与第三方应用服务器交互,发起业务访问。在业务访问的过程中,第三方应用服务器会对UE的业务访问计费,统计(也称计量)UE访问的流量和/或时长。

步骤S2106:第三方应用服务器与AF之间执行特定的交互流程,向应用服务器向AF提供用户请求的业务信息,其中第三方应用决定赞助用户访问的数据应用,第三方应用服务器向AF提供赞助业务的指示,以及赞助商标识,应用提供商标识。

步骤S2108:AF向PC/AAC/SCEF发送HTTP POST消息,消息中携带业务信息,被赞助数据连接信息,包括赞助商标识,应用提供商标识。

步骤S2110:PC/AAC/SCEF向PCRF发送AAR消息,消息中携带业务信息,被赞助数据连接信息,包括赞助商标识,应用提供商标识。

步骤S2112:PCRF向PC/AAC/SCEF返回确认消息。

步骤S2114:PC/AACSCEF向AF返回确认消息。

步骤S2116:PCRF根据业务信息、网络策略以及用户签约等信息制定PCC规则。PCRF根据赞助商标识和应用提供商标识确认相应的计费键(Charging key)和/或PCRF在PCC规则中增加赞助商标识和应用提供商标识。若BBERF存在,则PCRF还根据PCC规则制定QoS规则。

步骤S2118:PCRF向BBERF提供QoS规则。

步骤S2120:PCRF向PCEF提供PCC规则。PCEF执行PCC规则,并根据PCC规则中的计费策略对UE访问的第三方业务进行计费,统计(也称计量)UE访问业务产生的用量信息。用量信息可以是流量和/或时长。该计费是针对第三方应用提供商进行计费的。

步骤S2122:在UE访问第三方业务的过程中,第三方应用决定取消赞助UE正在访问的第三方业务,第三方应用服务器与AF交互,向AF发送取消赞助的指示。

步骤S2124:AF向PC/AAC/SCEF发送HTTP PUT消息,消息中携带被取消赞助指示。

步骤S2126:PC/AAC/SCEF向PCRF发送AAR消息,消息中携带被取消赞助指示。

步骤S2128:PCRF保存信息后,向PC/AAC返回确认消息。

步骤S2130:PC/AAC/SCEF向AF返回确认消息。

步骤S2132:PCRF根据进行策略决策,更新之前制定的PCC规则,携带取消赞助指示。PCRF在PCC规则携带其他可以对用户进行计费的计费键。

步骤S2134:PCRF向PCEF提供PCC规则。

步骤S2136:PCEF向PCRF返回确认消息,并在消息中携带UE本次业务访问中,在可计费主体发生切换前的累计用量信息(该用量信息可以是流量和/或时长)。PCEF可以自己统计(也称计量)UE发起本次业务以来的累计用量信息,也可以通过与计费系统(OCS或OFCS)交互获取UE发起本次业务以来的累计用量信息。

步骤S2138:PCRF向PC/AAC发送RAR消息,消息中携带累计用量信息。

步骤S2140:PC/AAC向AF发送RAR消息,消息中携带累计用量信息。

步骤S2142:AF向PC/AAC返回确认消息。

步骤S2144:PC/AAC向PCRF返回确认消息。

步骤S2146:AF与第三方应用服务器的特定消息,譬如向累计用量信息上报给第三方应用服务器。

通过实施例三和实施例四的流程,第三方应用提供商获得了网关在执行变更可计费主体策略之前,第三方应用提供商赞助的用量信息。若到UE结束业务访问时,可计费主体始终是UE,那么第三方应用提供商赞助的用量网关上报的可计费主体变更前第三方应用提供商赞助的累计用量信息。

AF和第三方应用服务器从实现上可以是独立部署,也可以AF集成在第三方应用服务器上。不管哪种部署,从PCRFPC/AAC/SCEF角度,PC/AAC/SCEF与AF的互通也可以认为是PC/AAC/SCEF与第三方应用服务器的互通。

在上述所有实施例中,运营商和所有第三方应用提供商均采用相同用量计费方法(运营商与所有第三方应用提供商都采用时长计费、流量计费或是同时时长和流量计费)。在其他实施例中,也可以对计量方法进行差异化处理,可采用如下两种方式之一:

1)运营商与第三方应用提供商可以签约协议决定固定的计量方法(Metering Method)。举例,若运营商A与第三方应用提供商A签约的是按流量的计量方法统计,在UE访问第三方应用后,第三方应用服务器判断用户UE通过运营商A访问业务,在第三方应用服务器以流量作为用量信息;PCRF在策略决策时,根据提供业务的第三方应用提供商确定计量方法,并在PCC规则中携带计量方法为流量的指示,PCEF根据计量方法指示对用户访问业务产生的流量进行统计。在可计费主体发生变化时,PCEF向PCRF返回的是流量的用量信息,进一步地, PCRF向AF返回的是流量的用量信息。采用时长或是同时时长和流量的计量方法类似,不再赘述。

2)运营商与第三方应用提供商动态协商计量方法。举例,若运营商A与第三方应用提供商A签约可以采用时长、流量或是同时时长和流量进行计费。在UE访问第三方应用后,第三方应用服务器判断用户UE通过运营商A访问业务,第三方应用服务器可以决定三种中的一种作为这次业务方位的计量方法,若第三方应用服务器决定采用流量的计费方法,则第三方服务器将计量方法为流量的指示同业务信息一同发送给PCRF;PCRF在策略决策时,根据第三方应用服务器的指示,在PCC规则中携带计量方法为流量的指示,PCEF根据计量方法指示对用户访问业务产生的流量进行统计。在可计费主体发生变化时,PCEF向PCRF返回的是流量的用量信息,进一步地,PCRF向AF返回的是流量的用量信息。采用时长或是同时时长和流量的计量方法类似,不再赘述。

需要说明的是,上述各个模块是可以通过软件或硬件来实现的,对于后者,可以通过以下方式实现,但不限于此:上述模块均位于同一处理器中;或者,上述模块分别位于多个处理器中。

本发明的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以被设置为存储用于执行以下步骤的程序代码:

S1,策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给第三方应用的服务器,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息,该第一用量信息用于第三方应用的服务器确定第二用量信息,该第二用量信息为第三方应用的提供商为UE支付的用于UE访问第三方应用的用量的信息。

可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:

S1,策略与计费执行功能实体PCEF将可计费主体发生变化之前的第一用量信息发送给应用功能AF,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的所使用的用量的信息。

可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:

S1,第三方应用的服务器接收策略与计费执行功能实体PCEF发送的第一用量信息,其中,该第一用量信息为可计费主体变化之前用户设备UE访问第三方应用的用量的信息;

S2,该第三方应用的服务器根据第一用量信息确定第二用量信息,其中,第二用量信息为第三方应用的提供商为上述UE支付的用于UE访问第三方应用的用量的信息。

可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地,本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例,本实施例在此不再赘述。

显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1