CN1731811A - 一种基于业务数据流计费中信息传送的交互方法 - Google Patents

Abstract

本发明公开了一种基于业务数据流计费中信息传送的交互方法，该方法包括：A.计费规则功能实体CRF收到应用功能实体AF或在线计费系统OCS的计费输入信息后，根据该信息确定对应的业务及计费规则，并且确定该对应的业务在后续实施过程中需要的触发点信息；B.CRF将该触发点信息携带在确认消息中发送给AF或OCS；C.AF或OCS保存该触发点信息并根据触发点信息设置触发点；D.AF或OCS在后续实施过程中对收到的信息进行触发点匹配判断，如果匹配，则执行步骤E；否则，对收到的信息不做处理，结束；E.AF或OCS将收到的信息构造为计费输入信息发送给CRF，CRF根据该输入信息对计费规则进行更改。

Description

一种基于业务数据流计费中信息传送的交互方法

技术领域

本发明涉及移动分组业务的计费技术，特别涉及一种基于移动分组业务数据流计费中信息传送的交互方法。

背景技术

随着移动分组业务应用的逐渐广泛，如何针对移动分组数据业务进行准确合理的计费，已成为移动运营商普遍关注的课题。

当前通用分组无线业务(GPRS)网络结构，针对数据流只能识别到接入点名称(APN)和激活分组数据协议内容(PDP Context)这一级别。而现实中，并行的多个业务数据流很可能使用同一个PDP Context承载，而不同业务数据流可能采用不通的计费方式，当前GPRS网络就无法满足这一需求。为了对不同类型的业务数据流采用不同的计费解决方案，需要对当前GPRS提出一种新的承载计费结构，采用一种通用的基于业务数据流的计费机制。

PDP，是分组数据包以离散形式传送的各种协议的通称，如IP协议和X.25协议，可以用于外部数据网与核心网的交互，以及核心网络功能实体之间的交互。PDP上下文是在移动台(MS)和GPRS支持节点(GSN)内，为一个会话保存的信息集合。APN是标识终端要接入的网络或者业务的一个标识，采用类似域名的格式。

目前3GPP提出了如何实现基于网际协议(IP)流的计费(FBC，FlowBased Charging)，对于一个分组业务来说，用户在使用该项业务所消耗的数据量称为业务数据流(Service Data Flow)，业务数据流是多个IP流组成的集合。而在一个PDP context中可以承载多个不同的分组业务，因此FBC粒度可以小于基于PDP context的计费粒度，从而能够提供更为丰富的计费手段。

在3GPP的TS23.125中对FBC的系统结构、功能要求以及消息流程等方面进行了描述。其中支持在线计费的FBC系统结构如图1所示；支持离线计费的FBC系统结构如图2所示。图1和图2中所示的各个功能实体作用分别为：

传输面功能实体(TPF，Traffic Plane Function)，TPF是承载分组数据流的功能实体，其可区分属于不同业务数据流中的分组包，用于离线计费信息收集和执行在线信用控制。当承载的分组数据流发生变化时，例如承载分组数据流的建立、修改或删除过程，TPF通过Gx接口向基于业务流计费的计费规则功能实体(CRF，Service Data Flow Based Charging Rule Function)发送请求计费规则消息，消息中可以携带：用户和用户使用的终端相关信息，如移动台国际ISDN号码(MSISDN)和国际移动签约用户标识(IMSI)，承载特性如业务质量(QoS)信息，以及网络相关的信息，如移动网编码(MNC)和移动国家码(MCC)。TPF根据CRF返回的计费规则，TPF在对应的业务数据流上执行分组过滤和计费数据收集。

一个TPF可以由一个或多个CRF服务，根据用户的标识信息来选择为其服务的CRF，TPF可以支持预定义的计费规则以及预定义的过滤器。

CRF，CRF是保存有计费规则的功能实体，支持动态的计费规则，即根据业务准则实时生成一些计费规则数据，和静态的计费规则，即在用户使用数据业务过程中计费规则是一成不变的。静态的计费规则可以被动态的计费规则激活。CRF通过接收到的TPF信息，应用功能实体(AF，ApplicationFunction)信息以及在线计费系统(OCS，Online Charging System)信息作为输入，用于选取适当的计费规则，在TPF请求或者有特定事件触发的时候将选取的计费规则发送给TPF。

一个CRF可以对应多个TPF。

AF，AF代表所有和应用相关的功能实体，AF向CRF提供相应的信息使得CRF可以选择或配置相应的计费规则，AF提供的信息包括：业务数据流的标识信息，可以设置为通配，计费规则选择的信息，应用/业务标识，应用/业务计费规则触发时间，流类型，可以选择为视频或音频，流速率。

一个AF可以对应于多个CRF。AF可以根据用户的标识信息选择CRF进行交互。

OCS，OCS作为在线计费系统由业务控制点(SCP，Service Control Point)和信用控制功能(CCF，Credit Control Function)两个功能实体组成，其中CCF对在线计费时的用户信用进行管理。当用户使用业务时，CCF对该用户信用池中的信用进行授权，并向TPF下发用户可以使用的信用。通过Ry接口，OCS可以向CRF提供计费规则选择的输入信息。

计费网关实体/计费收集实体(CCF/CGF，Charging GatewayFunction/Charging Collection Function)，这两个功能实体是用于离线计费系统的，可以沿用现有的GPRS网络计费中的实现。

如果承载网络是GPRS网络，则TPF位于GGSN处，AF为PDN中的一个业务网关，或是业务服务器。当IP多媒体子系统(IMS)承载在GPRS网络之上时AF就是P-CSCF，CRF为新增的逻辑实体。这种计费机制也可以应用于3GPP2和无线局域网(WLAN)的网络结构中。

图3为现有技术在承载网络中用FBC系统实现业务计费的流程图，其具体步骤为：

步骤300、用户设备(UE)向TPF发送承载建立请求消息(Establish BearerServ Req)；当承载网络是GPRS时，就是UE向GGSN发送激活PDP上下文请求消息；

步骤301、TPF向CRF发送计费规则请求(Request Charging Rules)的消息，消息中携带决定CRF选择计费规则的输入信息；

步骤302、CRF根据得到消息携带的输入信息来选择相应的计费规则(Identify Charging Rules to Install)，该计费规则的选取除了依据TPF带上来的输入信息以及UE相关的信息之外，此时CRF处可能也会得到来自AF的应用和业务相关信息以及来自OCS的信用控制相关信息；

步骤303、CRF将计费规则(Provision Charging Rules)提供给TPF，作为Request Charging Rules消息的应答；

步骤304、TPF根据CRF提供的计费规则进行建立或删除计费规则(Install/Remove Charging rules)；

步骤305、TPF向UE返回承载建立响应(Establish Bearer Serv Accept)消息，UE可以在已经建立的承载上传输数据了，例如UE可以请求和承载网络中的一个应用服务器建立业务连接、传送业务请求过程、执行过程以及中止过程所需的数据、接收来自应用服务器的信息等等。

图3所述的过程只描述了当承载建立时候TPF向CRF请求计费规则的情况，除了在承载最初建立的时候TPF需要向CRF上报一些承载相关信息用于选择计费规则之外，在承载修改或者承载删除等涉及到承载使用变化的情况，也会导致相应的计费规则变化，这时TPF也需要向CRF发起计费规则请求消息，由CRF根据来自TPF、AF和OCS的信息进行选择，决定是否实施新的计费规则。

在图3所述的步骤302中，和TPF向CRF请求计费规则的过程相独立的，AF和OCS也可以向CRF提供选择计费规则的输入信息，其中AF提供的信息和应用层业务相关，OCS提供的信息则和在线计费中业务的信用相关，CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费规则。

图4为现有技术中AF和CRF之间的交互流程图，其具体步骤为：

步骤400、AF向CRF发送应用/业务数据流计费信息(Sendapplication/Service Data FLOW Charging Information)；

步骤401、CRF向AF确认收到该信息。

在图4中，通过Rx接口，AF向CRF提供application/Service Data FLOWCharging Information，CRF根据该信息，选择和构造适当的计费规则发送给TPF。AF决定什么时候发送该信息给CRF，CRF从收到该信息的那一刻开始在计费规则的选择和决定上将application/Service Data FLOW ChargingInformation考虑在内。

图5为现有技术中OCS和CRF之间的交互流程图，其具体步骤为：

步骤500、OCS向CRF发送与在线计费相关的计费信息(Send OCSrelated Charging Information)；

步骤501、CRF确认收到该信息。

在图5中，通过Ry接口，OCS向CRF提供与在线计费相关的计费信息，CRF根据该信息，选择和构造适当的计费规则发送给TPF。OCS决定什么时候发送该信息给CRF，CRF从收到该信息的那一刻开始在计费规则的选择和决定上将与在线计费相关的信息(OCS related ChargingInformation)考虑在内。

从图4和图5所述的方法，现有基于FBC系统的计费规则中定义了Rx和Ry接口，Rx接口负责将信息从AF传送到CRF，执行连接的建立过程并维持这个连接，该连接可以是直接建立的，也可以是通过一个中继或代理节点建立的，甚至可以被重定向到另一个CRF。Ry接口的功能和Rx接口类似，只不过传送的是OCS和CRF之间的信息。这两个接口可以使用同一个接口规范来实现。

在现有基于FBC系统实现业务数据流计费的过程中，AF/OCS和CRF之间的信息传送采用的是推(PUSH)方式，由AF/OCS决定什么时候下发计费数据信息并到时下发给CRF。对于第一次发送信息给CRF来说，由AF/OCS决定是可以的，因为CRF不知道UE要联系的AF/OCS是哪一个，也不知道这个AF使用什么应用层协议和什么时候才能够得到有用的计费输入信息，而AF/OCS作为UE在应用层面或在线计费业务上的联系点，在收到UE发送的业务请求之后，就可以将应用层相关的信息或在线计费业务相关的信息发送给CRF，CRF根据该信息选择和构造计费规则。但是AF/OCS作为UE使用业务时在应用层面或在线计费业务的一个中间节点，在后续业务执行过程中会收到很多应用/业务相关的消息，这些消息都是针对当前业务进行的各种操作。这些操作会修改应用/业务的参数等信息，而这些参数又可能导致用户应用的计费规则改变，但是并不是所有的参数变化都会导致计费规则的改变，具体哪些参数的变化会导致CRF应该下发新的计费规则给TPF，只有CRF才能知道，AF上不保存任何与计费规则相关的信息，那么AF/OCS或者在每次有业务参数改变的时候就通知CRF，或者预先配置一些触发点，在满足触发条件的参数发生变化时才通知CRF。

但是，这样的实现很不灵活，每当参数改变就通知CRF的做法会增加Rx/Ry接口的负荷，而下发的信息很多都是没有意义的。预先配置触发点的方法只能应付简单的情况，配置的触发点都是静态的，如果运营商希望结合业务的使用提供灵活多样的计费策略，这种方法就无法满足了。更何况AF/OCS和CRF不一定位于同一个运营商网络，而不同运营商网络中对基于业务数据流计费的策略是不同的，同样的业务，在一个运营商的计费策略中，一个参数的修改需要改变当前的计费规则，但是在另一个运营商的计费策略中可能就不需要对正在实施计费规则做任何改变。因此，这种在业务执行过程中始终由AF/OCS决定计费输入信息下发的方法不利于基于业务数据流计费的开展和实施。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于移动分组数据业务流计费中信息传送的交互方法，该方法能够避免下发无效信息给CRF，减轻了Rx/Ry接口的负担，便于FBC计费的实施；该方法还可以通过修改CRF中的计费策略来影响AF/OCS实体的选择，而且在制定计费策略的时候不会受AF/OCS的限制，扩展性和灵活性好。

根据上述目的，本发明的技术方案是这样实现的：

一种基于业务数据流计费中信息传送的交互方法，该方法包括：

A、计费规则功能实体CRF收到应用功能实体AF或在线计费系统OCS的计费输入信息后，根据该信息确定对应的业务及计费规则，并且确定该对应的业务在后续实施过程中需要的触发点信息；

B、CRF将该触发点信息携带在确认消息中发送给AF或OCS；

C、AF或OCS保存该触发点信息并根据触发点信息设置触发点；

D、AF或OCS在后续实施过程中对收到的信息进行触发点匹配判断，如果匹配，则执行步骤E；否则，对收到的信息不做处理，结束；

E、AF或OCS对收到的信息构造为计费输入信息发送给CRF，CRF根据该输入信息对计费规则进行更改。

在所述的步骤E之后，该方法进一步包括：

F、CRF根据步骤E收到的计费输入信息决定是否还有触发点要设置或者要删除已有的触发点，如果是，确定触发点信息并将触发点信息携带在确认消息中发送给AF或OCS；

G、AF或OCS保存该触发点信息并重新根据触发点信息设置触发点，执行步骤D。

步骤F所述的触发点信息包含全部触发点或者包含需要更新的触发点。

当应用协议为会话发起协议SIP时，步骤F所述的触发点信息为发起呼叫(INVITE)消息、或者对应答做出回应(ACK)消息、或者拆除连接(BYE)消息、或者中途取消(CANCLE)消息、或者查询对方的能力(OPTIONS)消息、或者注册(REGISTER)消息、或者在会话参加者之间传递信息(INFO)消息、或者实现呼叫转移(REFER)消息、或者检验能够用于会话的资源(COMET)消息、或者传递消息(MESSAGE)消息、或者签约(SUBSCRIBE)消息、或者通知(NOTIFY)消息、或者更新(UPDATE)消息、或者临时响应(PRACK)消息。

该方法适用于通用分组无线业务GPRS网络、3GPP2的分组数据网络和无线局域网WLAN的承载网络结构中。

当该方法应用在GPRS网络时，所述的AF为PDN中一个业务网关或是业务服务器。

在步骤A之前，该方法进一步包括：TPF收到用户设备UE发送的承载建立请求消息后，向CRF发送计费规则请求的步骤。

步骤A所述确定对应的业务及计费规则还根据TPF发送给CRF的承载以及UE相关信息，及CRF自身保存的信息。

当步骤A所述的计费输入信息是AF发送的，该计费输入信息为应用层的计费信息；

当步骤A所述的计费输入信息是OCS发送的，该计费输入信息为在线计费相关的计费信息。

步骤A所述的触发点信息对应的应用层协议是根据应用功能实体AF的计费输入信息携带的应用层协议内容确定的。

从上述方案可以看出，本发明提出的基于业务数据流计费中信息传送的交互方法，在CRF第一次收到来自AF/OCS的计费输入信息之后，根据其中携带的输入信息判断对应的业务，并且根据保存的有关该业务的计费规则选择信息，决定后续业务实施过程中会导致计费规则变化的触发点信息，将触发点信息发送给AF/OCS保存并设置相应的触发点。AF/OCS在后续业务进行过程中，只有当满足触发点的时候才将应用层变化的信息或在线计费业务变化的信息下发给CRF，供CRF选择新的计费规则。通过这种方案来实现CRF和AF/OCS之间的信息交互，可以避免无用的信息从AF/OCS发送给CRF，造成接口负荷的增加，便于FBC计费的实施，并且该方法通过修改CRF中的计费策略来影响AF/OCS实体的选择，而且在制定计费策略的时候不会受AF/OCS的限制，扩展性和灵活性好。

附图说明

图1为支持在线计费的FBC系统结构图。

图2为支持离线计费地FBC系统结构图。

图3为现有技术在承载网络中用FBC系统实现业务计费的流程图。

图4为现有技术中AF和CRF之间的交互流程图。

图5为现有技术中OCS和CRF之间的交互流程图。

图6为本发明中AF和CRF之间的交互流程图。

图7为本发明基于FBC系统的承载网络实施业务时的计费流程图。

图8为本发明基于FBC系统的承载网络实施业务时的在线计费流程图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚明白，以下举实施例并参照附图，对本发明进行进一步详细说明。

由于AF和CRF通过Rx接口进行信息交互的过程，与OCS和CRF通过Ry接口进行信息交互的过程相同，只不过功能实体和接口不同而已，所以本发明用AF和CRF通过Rx接口进行信息交互的过程来详细说明怎样对业务数据流进行计费。

在实现Rx接口的时候，CRF会保存一些和应用/业务相关的信息，用于收到AF的计费输入信息之后决定如何使用这些输入。因此，虽然AF上使用的应用协议可能是多种多样的，但是CRF在收到AF第一次的计费输入信息之后，就可以根据其中的输入信息确定和这个AF的业务关系。根据CRF上保存的应用/业务相关信息，CRF就可以得知和这种类型业务有关的计费策略是什么，哪些应用层的参数变化会导致计费规则的修改或重选。CRF根据这些信息确定一些触发点信息，放在CRF返回给AF的确认消息中返回。AF收到确认信息之后，查看是否有触发点信息返回，如果有，保存并根据触发点信息设置这些触发点。在该业务的实际实施过程中，AF每当收到应用层会话消息，就进行触发点的匹配，如果匹配成功的话，再次向CRF下发应用/业务相关计费输入信息，输入的信息可以是经过匹配成功的部分应用层信息，也可以为全部应用层信息；如果没有匹配的触发点，那么继续会话的进行，不向CRF下发任何消息。

图6为本发明中AF和CRF之间的交互流程图，其具体步骤为：

步骤600、当AF收到UE的业务请求后，AF发送计费输入信息给CRF；

步骤601、CRF按照现有技术根据该输入信息找到对应的业务，根据该业务的配置，结合其他可用的信息，选择新的计费规则或者配置计费规则中的某些参数，并且确定该业务在后续实施过程中需要应用层下发信息的触发点信息；

步骤602、CRF返回确认消息给AF，该消息携带触发点信息；

步骤603、AF收到该确认消息后，查看该确认消息中是否带有触发点信息，如果有，执行步骤605；否则，执行步骤604；

步骤604、AF继续后续的会话处理；

步骤605、保存并根据触发点信息配置相应的触发点；

步骤606、在业务后续执行过程中，AF收到应用层面的消息；

步骤607、AF根据预先保存触发点的信息判断该应用层面的消息是否有匹配的触发点，如果有，执行步骤609；否则，执行步骤608；

步骤608、AF继续后续的会话处理；

步骤609、AF构造新的计费输入信息；

步骤610、AF按照现有技术发送计费输入信息给CRF，CRF根据得到的计费输入信息找到对应的业务，根据该业务的配置，结合其他可用信息，选择新的计费规则，或者配置计费规则中的某些参数，并且判断该业务是否有了新的触发点或者有旧的触发点需要删除，如果是，执行步骤611；否则，执行步骤613；

步骤611、CRF向AF返回确认信息，该确认信息携带有全部的触发点信息或者只返回需要更新的触发点信息；

步骤612、AF收到确认信息后，查看该确认消息中是否带有触发点信息，如果有，保存并根据触发点信息配置相应的触发点；否则，继续后续的会话处理。

图7为本发明基于FBC系统的承载网络实施业务时的计费流程图，该承载网络的网络实体有UE、TPF、CRF、计费相关功能实体(Charging)、AF/P-CSCF、用于与UE进行会话交互的目的UE/应用服务器AS，其具体步骤为：

步骤700、UE和目的UE/AS之间建立会话发起协议(SIP)会话，协商媒体过程，建立完成后，目的UE/AS给AF/P-CSCF发送建立会话通知消息；

步骤701、AF/P-CSCF收到通知消息后，知道会话的建立过程完成，则下发计费输入信息给CRF，供CRF选择计费规则使用，一些高层信息会指示CRF这是一个IMS应用；

步骤702、CRF返回确认消息，该消息包括UE使用该业务时在后续过程中会导致计费规则修改的触发点；

步骤703、CRF根据AF/P-CSCF的输入信息选择计费规则或配置计费规则中的参数，下发计费规则给TPF，和TPF之间进行提供计费规则的过程；

步骤704、TPF根据计费规则，执行离线计费报告或者在线计费请求等过程，将执行的过程上报给Charging；

步骤705、在业务进行过程中，UE和目的UE/AS中的某一方发起了会话修改，在双方之间更新了已经协商成功的媒体参数，更新完成后发送更新(UPDATE)消息给AP/P-CSCF；

步骤706、当AF/P-CSCF收到UPDATE消息后，知道会话的更新过程完成，根据保存的触发点信息，当参数修改导致根据保存的触发点相匹配，则将更新过的计费输入信息下发给CRF；

步骤707、CRF返回确认给AF/P-CSCF，如果有新的触发点信息或者需要删除旧的触发点，也会包括在该消息中，AF/P-CSCF重新保存并根据触发点信息重新配置相应的触发点；

步骤708、CRF根据AF/P-CSCF的输入信息选择计费规则或配置计费规则中的参数，下发计费规则给TPF，和TPF之间进行提供计费规则的过程；

步骤709、TPF根据计费规则，执行离线计费报告或者在线计费请求等过程，将执行的过程上报给Charging。

在上述步骤705中，可以配置的触发点消息很多，如在SIP协议中，触发点信息为发起呼叫(INVITE)消息、或者对应答做出回应(ACK)消息、或者拆除连接(BYE)消息、或者中途取消(CANCLE)消息、或者查询对方的能力(OPTIONS)消息、或者注册(REGISTER)消息、或者在会话参加者之间传递信息(INFO)消息、或者实现呼叫转移(REFER)消息、或者检验能够用于会话的资源(COMET)消息、或者传递消息(MESSAGE)消息、或者签约(SUBSCRIBE)消息、或者通知(NOTIFY)消息、或者更新(UPDATE)消息、或者临时响应(PRACK)消息。各种消息发送给CRF的信息也有些不同，比如UPDATE消息会触发AF/P-CSCF返回修改过的媒体参数，而REFER消息会触发P-CSCF返回重定向的地址信息。当应用层协议为其他协议的时候，对应的消息也可以被配置成上述的触发点。

同样的，OCS和CRF之间的信息交互也可以采用图6和图7所述的方法，只是传输的计费输入信息是在线业务信息，而不是应用层的业务信息。

图8为本发明基于FBC系统的承载网络实施业务时的在线计费流程图，其具体过程为：

步骤800、UE向TPF发送Establish Bearer Serv Req；当承载网络是GPRS时，就是UE向GGSN发送激活PDP上下文请求消息；

步骤801、TPF向CRF请求计费规则，消息中携带决定CRF选择计费规则的输入信息；步骤802、CRF根据得到的输入信息来选择相应的计费规则，除了TPF带上来的承载以及UE相关的信息之外，此时CRF处可能也会得到来自AF的应用和业务相关信息和来自OCS的信用控制相关信息；

步骤803、CRF将计费规则下发给TPF，作为计费规则请求消息的应答；

步骤804、TPF根据CRF提供的计费规则，对相应的计费规则执行应用或者删除的动作；

步骤805、在线计费情况下，TPF向OCS请求信用信息，消息中携带OCS决定信用所需的输入信息；

步骤806、OCS向TPF提供信用信息；

步骤807、TPF向UE返回承载建立接受消息，UE可以在已经建立的承载上传输数据；

步骤808、OCS向CRF提供和信用相关的在线计费信息；

步骤809、CRF根据得到的在线计费信息选择计费规则，和TPF之间发起一次新的提供计费规则的过程；

步骤810、CRF根据收到的在线计费信息找到对应的用户和业务，发现当该用户使用这个业务每次消耗的信用超过100个单位之后，根据计费策略需要使用新的计费规则，于是将这个会导致计费规则修改的触发信息放在应答消息中返回给OCS；

步骤811、OCS根据得到的应答信息配置触发点，当触发条件满足的时候，再一次向CRF提供和信用相关的在线计费信息；

步骤812、CRF根据得到的在线计费信息选择计费规则，和TPF之间可能会发起一次新的提供计费规则的过程；

步骤813、CRF根据得到的在线计费信息确定对应的用户和业务是否存在新的触发点，有的话放在应答消息中带给OCS使用。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1、一种基于业务数据流计费中信息传送的交互方法，其特征在于，该方法包括：

A、计费规则功能实体CRF收到应用功能实体AF或在线计费系统OCS的计费输入信息后，根据该信息确定对应的业务及计费规则，并且确定该对应的业务在后续实施过程中需要的触发点信息；

B、CRF将该触发点信息携带在确认消息中发送给AF或OCS；

C、AF或OCS保存该触发点信息并根据触发点信息设置触发点；

D、AF或OCS在后续实施过程中对收到的信息进行触发点匹配判断，如果匹配，则执行步骤E；否则，对收到的信息不做处理，结束；

E、AF或OCS对收到的信息构造为计费输入信息发送给CRF，CRF根据该输入信息对计费规则进行更改。

2、如权利要求1所述的方法，其特征在于，在所述的步骤E之后，该方法进一步包括：

F、CRF根据步骤E收到的计费输入信息决定是否还有触发点要设置或者要删除已有的触发点，如果是，确定触发点信息并将触发点信息携带在确认消息中发送给AF或OCS；

G、AF或OCS保存该触发点信息并重新根据触发点信息设置触发点，执行步骤D。

3、如权利要求2所述的方法，其特征在于，步骤F所述的触发点信息包含全部触发点或者包含需要更新的触发点。

4、如权利要求2所述的方法，其特征在于，当应用协议为会话发起协议SIP时，步骤F所述的触发点信息为发起呼叫(INVITE)消息、或者对应答做出回应(ACK)消息、或者拆除连接(BYE)消息、或者中途取消(CANCLE)消息、或者查询对方的能力(OPTIONS)消息、或者注册(REGISTER)消息、或者在会话参加者之间传递信息(INFO)消息、或者实现呼叫转移(REFER)消息、或者检验能够用于会话的资源(COMET)消息、或者传递消息(MESSAGE)消息、或者签约(SUBSCRIBE)消息、或者通知(NOTIFY)消息、或者更新(UPDATE)消息、或者临时响应(PRACK)消息。

5、如权利要求1所述的方法，其特征在于，该方法适用于通用分组无线业务GPRS网络、3GPP2的分组数据网络和无线局域网WLAN的承载网络结构中。

6、如权利要求5所述的方法，其特征在于，当该方法应用在GPRS网络时，所述的AF为PDN中一个业务网关或是业务服务器。

7、如权利要求1所述的方法，其特征在于，在步骤A之前，该方法进一步包括：TPF收到用户设备UE发送的承载建立请求消息后，向CRF发送计费规则请求的步骤。

8、如权利要求1所述的方法，其特征在于，步骤A所述确定对应的业务及计费规则还根据TPF发送给CRF的承载以及UE相关信息，及CRF自身保存的信息。

9、如权利要求1所述的方法，其特征在于，当步骤A所述的计费输入信息是AF发送的，该计费输入信息为应用层的计费信息；

当步骤A所述的计费输入信息是OCS发送的，该计费输入信息为在线计费相关的计费信息。

10、如权利要求9所述的方法，其特征在于，步骤A所述的触发点信息对应的应用层协议是根据应用功能实体AF的计费输入信息携带的应用层协议内容确定的。

Images