CN1735024A - 一种基于业务数据流计费的计费信息处理方法 - Google Patents
一种基于业务数据流计费的计费信息处理方法 Download PDFInfo
- Publication number
- CN1735024A CN1735024A CN 200410070070 CN200410070070A CN1735024A CN 1735024 A CN1735024 A CN 1735024A CN 200410070070 CN200410070070 CN 200410070070 CN 200410070070 A CN200410070070 A CN 200410070070A CN 1735024 A CN1735024 A CN 1735024A
- Authority
- CN
- China
- Prior art keywords
- charging
- tpf
- information
- crf
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Meter Arrangements (AREA)
Abstract
本发明为一种基于业务数据流计费的计费信息处理方法,该方法包括以下步骤:传输面功能实体获取计费配置信息,并根据计费配置信息生成计费信息,然后上报给计费功能实体。其中,传输面功能实体获取计费配置信息可以是通过接收计费规则功能实体发送的计费规则,从中获取计费配置信息,也可以是获取配置在传输面功能实体自身的计费配置信息。由于增加了计费配置信息,并根据计费配置信息进行计费信息的上报,实现了根据不同类型的业务进行计费,使得产生的计费信息和业务密切相关,减轻了TPF设备的负荷。
Description
技术领域
本发明涉及移动分组业务的计费技术,特别是指一种基于业务数据流计费的计费信息处理方法。
背景技术
随着移动分组业务应用的逐渐广泛,如何针对移动分组数据业务进行准确合理的计费,已成为移动运营商普遍关注的课题。
当前通用分组无线业务(GPRS)网络结构,针对数据流只能识别到接入点名称(APN)和分组数据协议上下文(PDP Context)这一级别。而现实中,并行的多个业务数据流很可能使用同一个PDP Context承载,而不同业务数据流需要采用不同的计费方式,当前GPRS网络无法满足这一需求。为了对不同类型的业务数据流采用不同的计费解决方案,需要一种新的承载计费结构,采用一种通用的基于业务数据流的计费机制。
PDP,是分组数据包以离散形式传送的各种协议的通称,如IP协议和X.25协议,可以用于外部数据网与核心网的交互,以及核心网络功能实体之间的交互。PDP上下文是在移动台(MS)和GPRS支持节点(GSN)内,为一个会话保存的信息集合。APN是标识终端要接入的网络或者业务的一个标识,采用类似域名的格式。
目前3GPP提出了如何实现基于互联网协议(Internet Protocol,IP)流的计费(Flow Based Charging,FBC),对于一个分组业务来说,用户在使用该项业务所消耗的数据量称为业务数据流(Service Data Flow),业务数据流是多个IP流组成的集合。而在一个PDP context中可以承载多个不同的分组业务,因此FBC的计费粒度小于基于PDP context的计费粒度,从而能够提供更为丰富的计费手段。
在3GPP的TS23.125中对FBC的***结构、功能要求以及消息流程等方面进行了描述。其中支持在线计费的FBC***结构如图1所示;支持离线计费的FBC***结构如图2所示。图1和图2中所示的各个功能实体作用分别为:
传输面功能实体(Traffic Plane Function,TPF),TPF是承载分组数据流的功能实体,可区分属于不同业务数据流中的分组包,用于离线计费信息收集和执行在线信用控制。当承载的分组数据流发生变化时,例如承载分组数据流的建立、修改或删除过程,TPF通过Gx接口向基于业务流计费的计费规则功能实体(Service Data Flow Based Charging Rule Function,CRF)发送请求计费规则消息,消息中可以携带:用户和用户使用的终端相关信息,如移动台国际ISDN号码(MSISDN)和国际移动设备标识及业务版本号(IMEISV),承载特性如业务质量(QoS)信息,以及网络相关的信息,如移动网络码(MNC)和移动国家码(MCC)。TPF根据CRF返回的计费规则,TPF在对应的业务数据流上执行分组过滤和计费数据收集。
一个TPF可以由一个或多个CRF服务,根据用户的标识信息来选择为其服务的CRF,TPF可以支持预定义的计费规则以及预定义的过滤器。
CRF,CRF是保存有计费规则的功能实体,支持动态的计费规则,即根据业务准则实时生成一些计费规则数据和静态的计费规则,即在用户使用数据业务过程中计费规则是一成不变的。静态的计费规则可以被动态的计费规则激活。CRF通过接收到的TPF信息,应用功能实体(Application Function,AF)信息以及在线计费***(Online Charging System,OCS)信息作为输入,选取适当的计费规则,在TPF请求或者有特定事件触发的时候将选取的计费规则发送给TPF。
一个CRF可以对应多个TPF。
AF,AF代表所有和应用相关的功能实体,AF向CRF提供相应的信息使得CRF可以选择或配置相应的计费规则,AF提供的信息包括:业务数据流的标识信息,可以设置为通配,计费规则选择的信息,应用/业务标识,应用/业务计费规则触发时间,流类型,可以选择为视频或音频,流速率。
一个AF可以对应于多个CRF。AF可以根据用户的标识信息选择CRF进行交互。
OCS,OCS作为在线计费***由业务控制点(Service Control Point,SCP)和信用控制功能实体(Credit Control Function,CCF)两个功能实体组成,其中CCF对在线计费时的用户信用进行管理。当用户使用业务时,CCF对该用户信用池中的信用进行鉴权,并向TPF下发用户可以使用的信用。通过Ry接口,OCS可以向CRF提供计费规则选择的输入信息。
计费网关实体/计费收集实体(Charging Gateway Function/ChargingCollection Function,CCF/CGF),这两个功能实体是用于离线计费***的,可以沿用现有的GPRS网络计费中的实现。
如果承载网络是GPRS网络,则TPF位于GGSN处,AF为PDN中的一个业务网关,或是业务服务器。当IP多媒体子***(IMS)承载在GPRS网络之上时AF就是代理呼叫会话控制功能实体(Proxy Call Session ControlFunction,P-CSCF),CRF为新增的逻辑实体。这种计费机制也可以应用于3 GPP2和无线局域网(WLAN)的网络结构中。
图3为现有技术中基于业务数据流计费的离线计费的流程图,具体步骤为:
步骤301、用户设备(UE)向TPF发送承载建立请求消息(Establish BearerServ Req);当承载网络是GPRS时,就是UE向GGSN发送激活PDP上下文请求消息;
步骤302、TPF向CRF发送请求计费规则消息(Request Charging Rules),消息中携带决定CRF选择计费规则的输入信息;
步骤303、CRF根据得到消息携带的输入信息来选择相应的计费规则(Identify Charging Rules to Install),该计费规则的选取除了依据TPF带上来的输入信息以及UE相关的信息之外,此时CRF处可能也会得到来自AF的应用和业务相关信息;
步骤304、CRF将计费规则(Provision Charging Rules)发送给TPF,作为请求计费规则消息的应答;
步骤305、TPF根据CRF提供的对计费规则的操作指示,对相应的计费规则执行相应的动作(Install/Remove Charging rules);
步骤306、TPF向UE返回承载建立接受消息(Establish Bearer ServAccept)。
图4为现有技术中基于业务数据流计费的在线计费的流程图,具体步骤为:
步骤401、UE向TPF发送承载建立请求消息;对于GPRS,就是GGSN接收到激活PDP上下文请求消息;
步骤402、TPF向CRF请求计费规则,消息中携带决定CRF选择计费规则的输入信息;
步骤403、CRF根据得到的信息来选择相应的计费规则,除了TPF带上来的承载以及用户相关的信息之外,此时CRF处可能也会得到来自AF的应用和业务相关信息和来自OCS的信用控制相关信息;
步骤404、CRF将计费规则下发给TPF,作为计费规则请求消息的应答;
步骤405、TPF根据CRF提供的对计费规则的操作指示,对相应的计费规则执行相应的动作;
步骤406、TPF向OCS请求信用信息,消息中携带OCS决定信用所需的输入信息;
步骤407、OCS向TPF提供信用信息;
步骤408、TPF向UE返回承载建立接受消息,UE就可以在已经建立的承载上传输数据了。
离线计费执行完步骤306之后,在线计费执行完步骤408之后,UE就可以在已经建立的承载上执行各种业务请求和数据传输了,如请求和网络中的一个应用服务器建立业务连接,传送业务请求过程、执行过程以及中止过程中所需的数据,接收来自应用服务器的信息等等,这些数据的传输都要占用承载资源。对于实现了基于业务数据流计费的承载网络来说,在TPF处,根据每个分组数据包所属的业务流的不同,TPF将应用不同的计费规则,将相关的承载计费信息上报给计费相关功能实体,如在GPRS中,GGSN将生成不同的呼叫细节记录(Call Detail Record,CDR),送给计费网关(ChargingGateway,CG)加以合并之后由收费***(Billing System,BS)用来生成最终的话单。CDR是一种计费用的格式化的信息集合。
上面只说明了当承载建立时候TPF向CRF请求计费规则的情况,除了在承载最初建立的时候TPF需要向CRF上报一些承载相关信息用于选择计费规则之外,在承载修改或者承载删除等涉及到承载使用变化的情况,也会导致相应计费规则的变化,这时TPF也需要向CRF发起计费规则请求消息,由CRF根据来自TPF、AF和OCS的信息进行选择,决定是否实施新的计费规则。
与TPF向CRF请求计费规则的过程相对独立的,AF和OCS也可以向CRF提供选择计费规则的输入信息,其中AF提供的信息和应用层业务相关,OCS提供的信息则和在线计费中业务的信用相关,CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费规则,实现流程如图5所示,具体步骤如下:
步骤501、CRF接收到某个触发事件以及该事件的相关信息,如AF向CRF发送的计费规则选择输入信息的事件。
步骤502、CRF根据获知的信息,如由AF提供的相关输入信息,或由TPF提供的相关输入信息,选择相应的计费规则;
步骤503、如果计费规则发生变化,则CRF向TPF发送计费规则;
步骤504、TPF根据CRF提供的对计费规则的操作指示,对相应的计费规则执行相应的动作。
目前,根据在3GPP的TS23.125中对计费规则的定义,计费规则包含的内容有:
一个特定业务数据流的计费方式:在线计费还是离线计费;
在离线计费时,是按流量、时长还是流量和时长进行记录;
计费键,用于确定费率;
一个或者多个业务数据流过滤器,过滤器是用来区分属于一个特定业务数据流的分组数据包的,基本的构成是IP五元组,包括源IP地址,目的IP地址,源端口号,目的端口号,传输协议号或者应用协议号;
优先级,在计费规则出现重叠的时候用于确定应用哪一个计费规则;
计费规则标识,用来标识一个计费规则,当CRF决定使用预先配置在TPF中的计费规则时,可以只下发对应的计费规则标识。
在实施业务的时候,TPF根据选定的计费规则,对该业务数据流的分组数据包进行过滤,可能是以时长为单位,也可能是以流量为单位,或者以流量加时长为单位,生成承载计费信息,送给计费相关功能实体产生用户的最终话单。
在离线计费时,CRF通过将上述计费规则下发给TPF,TPF根据计费规则中的信息确定按时长进行记录或是按流量进行记录,在达到预先设定的触发域值后,向计费功能实体上报计费信息。但是,由于对于不同类型的业务来说,需要的触发域值不同,例如对于热计费(hot-billing)类型的业务来说,需要很快上报计费信息,即需要触发域值是很小的时长,而对于统一费率(flating-rating)类型的业务来说,计费信息由于仅仅是一个参考信息,不需要很频繁的上报,因此可以设置一个较长的触发域值。而在TPF中,因为无法获知计费规则应用的业务类型,因此只能预先设定域值,这个域值也只能是一定的,不能够根据业务类型的不同生成并上报计费信息。
发明内容
有鉴于此,本发明的主要目的在于提供一种基于移动分组数据业务流计费的计费信息处理方法,该方法能够根据不同类型的业务生成并上报计费信息。
为了达到上述目的,本发明提供了一种基于业务数据流计费的计费信息处理方法,其特征在于该方法包括:
TPF获取计费配置信息,根据计费配置信息生成计费信息,并将该计费信息上报给计费功能实体。
上述计费配置信息可以携带在CRF下发的计费规则中。
上述计费配置信息可以包括:离线计费时,产生中间话单的时间门限和/或流量门限。
计费配置信息还可以包括:激活/去激活呼叫细节记录,或支持计费条件的最大数目,或支持计费条件改变的最大次数和费率变化时段,或以上任意的组合。
TPF获取计费配置信息可以为TPF根据存储的计费配置文件和CRF提供的业务类型指示获取计费配置信息,所述计费配置文件与业务类型相对应。
较佳地,业务类型指示包括:用于不同网络之间CRF和TPF之间互通的标准化部分,和用于归属于同一网络CRF和TPF之间互通的可扩展部分。
业务类型指示可以携带在计费规则的计费键中。
业务类型指示还可以携带在计费规则中。
上述计费配置文件可以包括:在离线计费时,产生中间话单的时间门限和/或流量门限。
上述计费配置文件还可以包括:激活/去激活呼叫细节记录,或支持计费条件的最大数目,或支持计费条件改变的最大次数和费率变化时段,或以上任意的组合。
上述业务类型由CRF根据TPF、AF和/或OCS提供的用于确定计费规则的输入信息确定。
从上述方案可以看出,本发明通过在基于业务数据流计费***中设置计费配置信息,传输面功能实体获取计费配置信息,并根据计费配置信息生成计费信息,然后上报给计费功能实体,实现了根据不同的业务类型进行计费,而且使得产生的计费信息和业务密切相关,减轻了TPF设备的负荷。
此外,本发明通过对在CRF的计费规则中增加离线计费时,产生中间话单时间门限的时间门限和/或流量门限等,实现了对于不同类型的业务,按不同的时间门限和/或流量门限上报中间话单,解决了现有技术中,对于不同类型的业务按照相同的触发域值上报中间话单的问题。由于本发明根据不同的业务类型进行计费,能够针对不同业务设置不同的上报门限,控制是否激活CDR的产生,以及支持计费条件的最大数目,支持计费条件改变的最大次数和费率变化时段等,使得产生的计费配置信息和业务密切相关,减轻了TPF设备的负荷。
附图说明
图1为支持离线计费的FBC***结构图;
图2为支持在线计费的FBC***结构图;
图3为现有技术在承载网络中用FBC***实现离线计费的流程图;
图4为现有技术在承载网络中用FBC***实现在线计费的流程图;
图5为CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费规则的流程图;
图6为本发明第一实施例中基于FBC***的承载网络实现离线计费的流程图;
图7为本发明第二实施例中基于FBC***的承载网络实现在线计费的流程图;
图8为本发明第三实施例中基于FBC***的承载网络实现离线计费的流程图;
图9为本发明第三实施例中基于FBC***的承载网络实现在线计费的流程图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚明白,以下举实施例并参照附图,对本发明进行进一步详细说明。
本发明的主要思想是在FBC中增加和业务类型相关的计费配置信息,传输面功能实体获取设置的计费配置信息,并根据计费配置信息生成计费信息,然后上报给计费功能实体。比如可以增加在离线计费时上报计费信息的时间门限和流量门限,还可以增加CDR激活、去激活信息,支持计费条件的最大数目以及改变的最大次数,费率变化时段等计费配置信息。本发明中所述的业务类型可为具有相同计费属性的一类业务,也可为特定的一种业务。
计费配置信息是由计费配置得到的信息,计费配置指的是计费***在产生计费信息的时候需要依据的一些设置和条件,一般情况下,根据这些设置产生和上报计费信息,同时当某些条件满足的时候,需要重新构造计费信息。
本发明的第一实施例为在CRF功能实体中增加计费配置信息的基于业务数据流计费的计费信息处理方法。具体为:
在CRF下发给TPF的计费规则中增加以下计费配置信息:
在离线计费时,产生中间话单的时间门限和/或流量门限;
在离线计费时,产生中间话单的时间门限和/或流量门限,在离线计费时,如果是依据流量计录,是指TFP产生中间话单的流量门限,即流量达到该流量门限即产生中间话单;如果是依据时长计录,是指TPF产生中间话单的时间门限,即TPF产生中间话单的时间周期;如果是依据时长和流量计录,是指TPF上报给计费功能实体的时间门限和流量门限,即两个门限中任何一个达到时,TPF都上报计费信息。
在CRF中增加了上述计费配置信息,即在离线计费时,产生中间话单的时间门限和/或流量门限后,离线计费的流程如图6所示,具体为:
步骤601、UE向TPF发送承载建立请求消息(Establish Bearer Serv Req);当承载网络是GPRS时,就是UE向GGSN发送承载建立请求消息;
步骤602、TPF向CRF发送请求计费规则消息(Request Charging Rules),消息中携带决定CRF选择计费规则的输入信息;
步骤603、CRF根据得到消息携带的输入信息来选择相应的计费规则(IdentifyCharging Rules to Install),计费规则中包含上述增加的计费配置信息,即在离线计费时,产生中间话单的时间门限和/或流量门限;该计费规则包括增加的计费配置信息的选取,不仅依据TPF带上来的输入信息以及UE相关的信息,还依据来自AF的应用和业务相关信息;
步骤604、CRF将包含了在离线计费时,产生中间话单的时间门限和/或流量门限的计费规则(Provision Charging Rules)发送给TPF,作为请求计费规则消息的应答;
步骤605、TPF根据CRF提供的对计费规则的操作指示,执行相应的动作(Install/Remove Charging rules),并应用其中包含的计费配置信息,即在离线计费时,产生中间话单的时间门限和/或流量门限;
步骤606、TPF向UE返回承载建立接受消息(Establish Bearer ServAccept),至此,完成承载建立;
步骤607、UE在已经建立的承载上执行各种业务请求和数据传输;
这里的业务请求和数据传输包括:请求和网络中的一个应用服务器建立业务连接,传送业务请求过程、执行过程以及中止过程中所需的数据,接收来自应用服务器的信息等;
步骤608、当TPF处收到该用户的业务数据时,根据应用的计费规则中的计费配置信息生成计费信息;
步骤609、TPF将生成的计费信息上报给有关的计费功能实体。
对于实现了基于业务数据流计费的承载网络来说,在TPF处,根据每个分组数据包所属的业务流的不同,TPF将应用不同的计费规则,按照计费规则中规定的时间门限和/或流量门限将相关的承载计费信息上报给计费相关功能实体,如在GPRS中,GGSN将生成不同的CDR,根据指定的门限值触发上报计费信息给计费网关(Charging Gateway,CG),CG加以合并之后由收费***(Billing System,BS)生成最终的话单。
本发明的具体实施例二是基于具体实施例一的基础上的基于业务数据流计费的计费信息处理方法,其主要区别在于在计费规则中增加的计费配置信息是可扩展的,可以增加一些通用的计费配置信息,还可以由运营商根据自己要实施的业务的特征,制定不同的计费配置,从而实现不同的计费策略,增强业务对用户的吸引力。通用的计费配置信息除了离线计费时,生成中间话单的时间门限和/或流量门限之外,还可以包括激活/去激活CDR、支持计费条件的最大数目、支持计费条件改变的最大次数,费率变化时段等。当用户签约时决定自己的各类业务的计费配置,保存在CRF中,在实施业务的时候,尽管TPF可能是另一个网络运营商的功能实体,但是根据各个运营商之间的协定,具体的计费配置以用户的签约为主,因此,当用户建立承载面连接用于实现业务的时候,不论使用的是否是同一个运营商的网络设备,TPF都根据从CRF收到的计费规则和触发器等信息进行基于业务数据流的计费,在这种实现中,这些计费配置信息由CRF提供。
在计费规则中增加了其他的计费配置信息后,离线计费时,流程和具体实施例一中离线计费流程基本一致,只是在涉及到计费规则时,计费规则不仅包括上述的离线计费时,产生中间话单的时间门限和/或流量门限,还包括增加了的其他的计费配置信息。
在计费规则中增加了其他的计费配置信息后,增加的计费配置信息可以应用于在线计费流程,在线计费流程的流程图如图7所示,具体步骤为:
步骤701、UE向TPF发送承载建立请求消息(Establish Bearer Serv Req);当承载网络是GPRS时,就是UE向GGSN发送承载建立请求消息;
步骤702、TPF向CRF发送请求计费规则消息(Request Charging Rules),消息中携带决定CRF选择计费规则的输入信息;
步骤703、CRF根据得到消息携带的输入信息来选择相应的计费规则(Identify Charging Rules to Install),计费规则中包含上述增加的计费配置信息;该计费规则,包括增加的计费配置信息的选取,不仅依据TPF带上来的输入信息以及UE相关的信息,还依据来自AF的应用和业务相关信息以及来自OCS的信用控制相关信息;
步骤704、CRF将包含了增加的计费配置信息的计费规则(ProvisionCharging Rules)发送给TPF,作为请求计费规则消息的应答;
步骤705、TPF根据CRF提供的对计费规则的操作指示,执行相应的动作(Install/Remove Charging rules),并应用计费规则中增加的计费配置信息;
步骤706、TPF向OCS请求信用信息,消息中携带OCS决定信用所需的输入信息;
步骤707、OCS向TPF提供信用信息;
步骤708、TPF向UE返回承载建立接受消息(Establish Bearer ServAccept),至此,完成承载建立;
步骤709、UE在已经建立的承载上执行各种业务请求和数据传输;
这里的业务请求和数据传输包括:请求和网络中的一个应用服务器建立业务连接,传送业务请求过程、执行过程以及中止过程中所需的数据,接收来自应用服务器的信息等;
步骤710、当TPF处收到该用户的业务数据时,根据应用的计费规则中的计费配置信息产生计费信息;
步骤711、TPF将生成的计费信息上报给有关的计费功能实体。
对于实现了基于业务数据流计费的承载网络来说,在TPF处,根据每个分组数据包所属的业务流的不同,TPF将应用不同的计费规则,按照计费规则中增加的计费配置信息将相关的计费信息上报给计费相关功能实体,如在GPRS中,GGSN将生成不同的CDR,根据指定的门限值触发上报计费信息给计费网关(Charging Gateway,CG),CG加以合并之后由收费***(Billing System,BS)生成最终的话单。
本发明的第三实施例为在TPF中增加计费配置信息的基于业务数据流计费的计费信息处理方法。首先在TPF中实现计费配置文件,在计费配置文件中包含FBC计费中的一些通用的静态信息所实现的功能,包括静态计费规则、静态过滤器以及静态触发器等实现的功能。
在TPF中增加的计费配置信息除了将已有的通用静态规则等能够实现的功能包含在内外,还包括:
在离线计费时,产生中间话单的时间门限和/或流量门限;
激活/去激活CDR的指示;
其中,在离线计费时,产生中间话单的时间门限和/或流量门限,是指在离线计费时,如果是依据流量计费,TFP上报给计费功能实体的流量门限,即流量达到该流量门限即上报计费信息;如果是依据时长计费,TPF上报给计费功能实体的时间门限,即TPF上报计费信息的时间周期;如果是依据时长和流量计费,TPF上报给计费功能实体的时间门限和流量门限,即两个门限都达到时,TPF上报计费信息。
这些计费配置信息是可扩展的,即可以由运营商根据自己要实施的业务的特征,制定不同的计费配置,从而实现不同的计费策略,增强业务对用户的吸引力。
计费配置文件的设置要根据不同的业务类型进行,业务类型的指示由CRF下发给TPF,TPF根据业务类型的指示选择相应的计费配置文件。业务类型的指示可以是在现有计费规则中增加的一个新的内容,也可以是在计费规则中的计费键上进行扩展。
对于同一个运营商的CRF和TPF来说,CRF和TPF之间对业务类型的定义是唯一的,对于不同的运营商来说,由于对业务类型的定义可能会有所不同,则将业务类型设置可以分为标准化的部分和可扩展部分,其中标准化部分用于不同网络之间的CRF和TPF之间的互通,扩展部分用于CRF和TPF属于同一个网络时,运营商自己对其进行设置,以开展特色业务。在TPF中增加了计费配置文件后,离线计费的流程如图8所示,具体为:
步骤801、UE向TPF发送承载建立请求消息(Establish Bearer Serv Req);当承载网络是GPRS时,就是UE向GGSN发送承载建立请求消息;
步骤802、TPF向CRF发送请求计费规则消息(Request Charging Rules),消息中携带决定CRF选择计费规则的输入信息;
步骤803、CRF根据得到消息携带的输入信息选择相应的计费规则(Identify Charging Rules to Install),在计费规则中或计费规则中的计费键中包含上述增加的业务类型的指示;该计费规则的选取除了依据TPF带上来的输入信息以及UE相关的信息外, CRF也可能会得到来自AF的应用和业务相关信息,CRF根据上述信息确定计费规则,包括确定业务类型,并在其中增加业务类型的指示;
步骤804、CRF将计费规则(Provision Charging Rules)发送给TPF,作为请求计费规则消息的应答;
步骤805、TPF根据CRF提供的对计费规则的操作指示,执行相应的动作(Install/Remove Charging rules),并根据规则中的业务类型的指示确定并应用相应的计费配置文件;
步骤806、TPF向UE返回承载建立接受消息,至此,完成承载建立;
步骤807、UE在已经建立的承载上执行各种业务请求和数据传输;
步骤808、当TPF处收到该用户的业务数据时,根据应用的计费配置文件生成计费信息;
步骤809、TPF将生成的计费信息上报给有关的计费功能实体。
在TPF中增加了计费配置文件后,在线计费的流程如图9所示,具体为:
步骤901、UE向TPF发送承载建立请求消息(Establish Bearer Serv Req);当承载网络是GPRS时,就是UE向GGSN发送承载建立请求消息;
步骤902、TPF向CRF发送请求计费规则消息(Request Charging Rules),消息中携带决定CRF选择计费规则的输入信息;
步骤903、CRF根据得到消息携带的输入信息选择相应的计费规则(Identify Charging Rules to Install),在计费规则中的计费键中或直接计费规则中包含上述增加的业务类型的指示;该计费规则的选取除了依据TPF带上来的输入信息以及UE相关的信息外,CRF也可能会得到来自AF的应用和业务相关信息和来自OCS的信用控制相关信息,CRF根据上述信息确定计费规则,包括确定业务类型,并在其中增加业务类型的指示;
步骤904、CRF将计费规则(Provision Charging Rules)发送给TPF,作为请求计费规则消息的应答;
步骤905、TPF根据CRF提供的对计费规则的操作指示,执行相应的动作(Install/Remove Charging rules),并根据规则中的业务类型的指示确定并应用相应的计费配置文件;
步骤906、TPF向OCS请求信用信息,消息中携带OCS决定信用所需的输入信息;
步骤907、OCS向TPF提供信用信息;
步骤908、TPF向UE返回承载建立接受消息,至此,完成承载建立;
步骤909、UE在已经建立的承载上执行各种业务请求和数据传输;
步骤910、当TPF处收到该用户的业务数据时,根据应用的计费配置文件生成计费信息;
步骤911、TPF将生成的计费信息上报给有关的计费功能实体。
本发明的具体实施例四与具体实施例三的技术方案大部分相同,区别在于在TPF中的计费配置文件中不包含FBC计费中的一些通用的静态信息所实现的功能,而只是包括在离线计费时,产生中间话单的时间门限和/或流量门限和激活/去激活CDR的指示等实现原有的静态信息不能实现的功能的计费配置信息。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所做的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
Claims (11)
1、一种基于业务数据流计费的计费信息处理方法,其特征在于该方法包括:
TPF获取对应于业务类型的计费配置信息,根据计费配置信息生成计费信息,并根据计费配置信息将该计费信息上报给计费功能实体。
2、如权利要求1所述的方法,其特征在于,所述计费配置信息携带在CRF下发的计费规则中。
3、如权利要求2所述的方法,其特征在于,所述的计费配置信息包括:离线计费时,产生中间话单的时间门限和/或流量门限。
4、如权利要求2或3所述的方法,其特征在于,所述的计费配置信息包括:激活/去激活呼叫细节记录,或支持计费条件的最大数目,或支持计费条件改变的最大次数和费率变化时段,或以上任意的组合。
5、如权利要求1所述的方法,其特征在于,所述的TPF获取对应于业务类型的计费配置信息为:TPF根据存储的计费配置文件和CRF提供的业务类型指示获取计费配置信息。
6、根据权利要求5所述的方法,其特征在于,设置所述业务类型指示包括:用于不同网络之间CRF和TPF之间互通的标准化部分,和用于归属于同一网络CRF和TPF之间互通的可扩展部分。
7、如权利要求5所述的方法,其特征在于,所述业务类型指示携带在计费规则的计费键中。
8、如权利要求5所述的方法,其特征在于,所述业务类型指示携带在计费规则中。
9、如权利要求5所述的方法,其特征在于,所述的计费配置文件包括:在离线计费时,产生中间话单的时间门限和/或流量门限。
10、如权利要求5所述的方法,其特征在于,所述的计费配置文件包括:激活/去激活呼叫细节记录,或支持计费条件的最大数目,或支持计费条件改变的最大次数和费率变化时段,或以上任意的组合。
11、如权利要求5所述的方法,其特征在于,所述业务类型由CRF根据TPF、AF和/或OCS提供的用于确定计费规则的输入信息确定。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410070070 CN1735024A (zh) | 2004-08-10 | 2004-08-10 | 一种基于业务数据流计费的计费信息处理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410070070 CN1735024A (zh) | 2004-08-10 | 2004-08-10 | 一种基于业务数据流计费的计费信息处理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1735024A true CN1735024A (zh) | 2006-02-15 |
Family
ID=36077236
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200410070070 Pending CN1735024A (zh) | 2004-08-10 | 2004-08-10 | 一种基于业务数据流计费的计费信息处理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1735024A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102388564A (zh) * | 2011-05-06 | 2012-03-21 | 华为技术有限公司 | 费率组处理方法、数据业务计费方法和相关设备及*** |
CN101179403B (zh) * | 2006-09-29 | 2012-04-04 | 朗迅科技公司 | 用于传送计费数据记录的***和方法 |
CN103384202A (zh) * | 2013-07-17 | 2013-11-06 | 大唐移动通信设备有限公司 | 一种流量上报消息的传输方法和设备 |
CN103702308A (zh) * | 2013-12-23 | 2014-04-02 | 大唐移动通信设备有限公司 | 业务流量上报方法与装置 |
CN107979707A (zh) * | 2016-10-21 | 2018-05-01 | 中国电信股份有限公司 | 用于提升断网控制精度的方法、装置和*** |
CN109428734A (zh) * | 2017-08-30 | 2019-03-05 | 中兴通讯股份有限公司 | 计费实现***、计费实现方法及计费管理功能实体 |
CN110838923A (zh) * | 2018-08-17 | 2020-02-25 | ***通信集团安徽有限公司 | 流量计费的方法、装置、设备和介质 |
-
2004
- 2004-08-10 CN CN 200410070070 patent/CN1735024A/zh active Pending
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101179403B (zh) * | 2006-09-29 | 2012-04-04 | 朗迅科技公司 | 用于传送计费数据记录的***和方法 |
US11330409B2 (en) | 2011-05-06 | 2022-05-10 | Huawei Technologies Co., Ltd. | Method for processing rate group, method for charging for data service, and related device and system |
US9628977B2 (en) | 2011-05-06 | 2017-04-18 | Huawei Technologies Co., Ltd. | Method for processing rate group, method for charging for data service, and related device and system |
CN102388564A (zh) * | 2011-05-06 | 2012-03-21 | 华为技术有限公司 | 费率组处理方法、数据业务计费方法和相关设备及*** |
US11689902B2 (en) | 2011-05-06 | 2023-06-27 | Huawei Technologies Co., Ltd. | Method for processing rate group, method for charging for data service, and related device and system |
US10462623B2 (en) | 2011-05-06 | 2019-10-29 | Huawei Technologies Co., Ltd. | Method for processing rate group, method for charging for data service, and related device and system |
CN103384202A (zh) * | 2013-07-17 | 2013-11-06 | 大唐移动通信设备有限公司 | 一种流量上报消息的传输方法和设备 |
CN103384202B (zh) * | 2013-07-17 | 2017-06-13 | 大唐移动通信设备有限公司 | 一种流量上报消息的传输方法和设备 |
CN103702308A (zh) * | 2013-12-23 | 2014-04-02 | 大唐移动通信设备有限公司 | 业务流量上报方法与装置 |
CN103702308B (zh) * | 2013-12-23 | 2017-12-05 | 大唐移动通信设备有限公司 | 业务流量上报方法与装置 |
CN107979707A (zh) * | 2016-10-21 | 2018-05-01 | 中国电信股份有限公司 | 用于提升断网控制精度的方法、装置和*** |
CN107979707B (zh) * | 2016-10-21 | 2020-02-21 | 中国电信股份有限公司 | 用于提升断网控制精度的方法、平台和*** |
CN109428734A (zh) * | 2017-08-30 | 2019-03-05 | 中兴通讯股份有限公司 | 计费实现***、计费实现方法及计费管理功能实体 |
CN109428734B (zh) * | 2017-08-30 | 2023-04-07 | 中兴通讯股份有限公司 | 计费实现***、计费实现方法及计费管理功能实体 |
WO2019042218A1 (zh) * | 2017-08-30 | 2019-03-07 | 中兴通讯股份有限公司 | 计费实现***、计费实现方法及计费管理功能实体 |
CN110838923B (zh) * | 2018-08-17 | 2022-02-18 | ***通信集团安徽有限公司 | 流量计费的方法、装置、设备和介质 |
CN110838923A (zh) * | 2018-08-17 | 2020-02-25 | ***通信集团安徽有限公司 | 流量计费的方法、装置、设备和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2555254C (en) | Method for reducing load of traffic plane function | |
CN1691821A (zh) | 一种实现漫游计费的方法及*** | |
CN1302636C (zh) | 一种完善基于业务数据流在线计费的处理方法 | |
CN101667920B (zh) | 一种计费方法、***及话单生成设备 | |
CN1303781C (zh) | 一种分组数据业务的计费控制方法 | |
CN1968139A (zh) | 策略与计费控制中用户签约信息的处理方法及装置 | |
CN1444824A (zh) | 用于通信网络的公共计费标识符 | |
CN1735017A (zh) | 一种基于分组数据流计费的对话建立方法 | |
CN1473443A (zh) | 用于为多媒体会话中提供的业务协调计费的方法和设备 | |
CN1859300A (zh) | 为移动终端用户传输多服务质量业务流的方法 | |
CN101047874A (zh) | 移动通信网络中业务信息决策方法 | |
CN1697387A (zh) | 一种针对用户选择计费规则的方法 | |
CN1260910C (zh) | 基于分组数据流计费触发事件和重授权事件的处理方法 | |
CN1735024A (zh) | 一种基于业务数据流计费的计费信息处理方法 | |
CN1645804A (zh) | 一种分组数据业务中增强计费规则及进行操作的方法 | |
CN1738303A (zh) | 一种根据不同承载网络类型实施不同业务处理的方法 | |
CN1780347A (zh) | 一种基于流量/时长和业务质量的分组预付费业务实现方法 | |
CN1773922A (zh) | 一种基于分组数据流计费的处理方法及*** | |
CN1753370A (zh) | 一种移动分组数据业务中实现用户设备重定向的方法 | |
CN1286292C (zh) | 基于通用分组无线业务流量的计费方法 | |
CN1773917A (zh) | 一种计费信息的处理方法 | |
CN100341278C (zh) | 一种基于分组数据流计费的***及处理方法 | |
CN1684420A (zh) | 一种实现分组数据业务计费及控制业务接入的方法 | |
CN1933407A (zh) | 业务控制设备、漫游计费***及漫游计费方法 | |
CN100341277C (zh) | 一种完善基于业务数据流在线计费的实现方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |