一种基于业务数据流计费中信息传送的交互方法
阅读：416发布：2020-05-12
专利汇可以提供一种基于业务数据流计费中信息传送的交互方法专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种基于业务数据流计费中信息传送的交互方法，该方法包括：A.计费规则功能实体CRF收到应用功能实体AF或在线计费系统OCS的计费输入信息后，根据该信息确定对应的业务及计费规则，并且确定该对应的业务在后续实施过程中需要的触发点信息；B.CRF将该触发点信息携带在确认消息中发送给AF或OCS；C.AF或OCS保存该触发点信息并根据触发点信息设置触发点；D.AF或OCS在后续实施过程中对收到的信息进行触发点匹配判断，如果匹配，则执行步骤E；否则，对收到的信息不做处理，结束；E.AF或OCS将收到的信息构造为计费输入信息发送给CRF，CRF根据该输入信息对计费规则进行更改。，下面是一种基于业务数据流计费中信息传送的交互方法专利的具体信息内容。
1、一种基于业务数据流计费中信息传送的交互方法，其特征在于，该方法包括： A、计费规则功能实体CRF收到应用功能实体AF或在线计费系统OCS的计费输入信息后，根据该信息确定对应的业务及计费规则，并且确定该对应的业务在后续实施过程中需要的触发点信息； B、CRF将该触发点信息携带在确认消息中发送给AF或OCS； C、AF或OCS保存该触发点信息并根据触发点信息设置触发点； D、AF或OCS在后续实施过程中对收到的信息进行触发点匹配判断，如果匹配，则执行步骤E；否则，对收到的信息不做处理，结束； E、AF或OCS对收到的信息构造为计费输入信息发送给CRF，CRF根据该输入信息对计费规则进行更改。
2、 如权利要求l所述的方法，其特征在于，在所述的步骤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、 如权利要求l所述的方法，其特征在于，该方法适用于通用分组无线业 务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的计费输入信息携带的应用层协议内 容确定的。3
一种基于业务数据流计费中信息传送的交互方法
技术领域
本发明涉及移动分组业务的计费技术，特别涉及一种基于移动分组业务 数据流计费中信息传送的交互方法。
背景技术
随着移动分组业务应用的逐渐广泛，如何针对移动分组数据业务进行准 确合理的计费，已成为移动运营商普遍关注的课题。
当前通用分组无线业务（GPRS)网络结构，针对数据流只能识别到接 入点名称（APN)和激活分组数据协议内容（PDP Context)这一级别。而 现实中，并行的多个业务数据流很可能使用同一个PDPContext承载，而不 同业务数据流可能采用不通的计费方式，当前GPRS网络就无法满足这一需 求。为了对不同类型的业务数据流采用不同的计费解决方案，需要对当前 GPRS提出一种新的承载计费结构，采用一种通用的基于业务数据流的计费 机制。
PDP，是分组数据包以离散形式传送的各种协议的通称，如IP协议和 X.25协议，可以用于外部数据网与核心网的交互，以及核心网络功能实体 之间的交互。PDP上下文是在移动台（MS)和GPRS支持节点（GSN)内， 为一个会话保存的信息集合。APN是标识终端要接入的网络或者业务的一 个标识，采用类似域名的格式。
目前3GPP提出了如何实现基于网际协议（IP)流的计费（FBC， Flow Based Charging)，对于一个分组业务来说，用户在使用该项业务所消耗的 数据量称为业务数据流（Service Data Flow),业务数据流是多个IP流组成 的集合。而在一个PDP context中可以承载多个不同的分组业务，因此FBC
4粒度可以小于基于PDP context的计费粒度，从而能够提供更为丰富的计费 手段。
在3GPP的TS23.125中对FBC的系统结构、功能要求以及消息流程等 方面进行了描述。其中支持在线计费的FBC系统结构如图1所示；支持离 线计费的FBC系统结构如图2所示。图1和图2中所示的各个功能实体作 用分别为：
传输面功能实体（TPF, Traffic Plane Function) , TPF是承载分组数才居 流的功能实体，其可区分属于不同业务数据流中的分组包，用于离线计费信 息收集和执行在线信用控制。当承载的分组数据流发生变化时，例如承载分 组凄t据流的建立、修改或删除过程，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, Application Function)信息以及在线计费系统（OCS, Online Charging System)信息作 为输入，用于选取适当的计费规则，在TPF请求或者有特定事件触发的时 候将选取的计费规则发送给TPF。
一个CRF可以对应多个TPF。AF, AF代表所有和应用相关的功能实体，AF向CRF提供相应的信息 使得CRF可以选择或配置相应的计费规则，AF提供的信息包括：业务数据 流的标识信息，可以设置为通配，计费规则选4奪的信息，应用/业务标识， 应用/业务计费规则触发时间，流类型，可以选择为视频或音频，流速率。
一个AF可以对应于多个CRF 。 AF可以根据用户的标识信息选择CRF 进行交互。
OCS, OCS作为在线计费系统由业务控制点（SCP, Service Control Point) 和信用控制功能（CCF, Credit Control Function)两个功能实体组成，其中 CCF对在线计费时的用户信用进行管理。当用户使用业务时，CCF对该用 户信用池中的信用进行授权，并向TPF下发用户可以使用的信用。通过Ry 接口 ， OCS可以向CRF提供计费规则选择的输入信息。
计费网关实体/计费收集实体（CCF/CGF , Charging Gateway Function/Charging Collection Function),这两个功能实体是用于离线计费系 统的，可以沿用现有的GPRS网络计费中的实现。
如果承载网络是GPRS网络，则TPF位于GGSN处，AF为PDN中的
一个业务网关，或是业务服务器。当IP多媒体子系统（IMS)承载在GPRS
网络之上时AF就是P-CSCF, CRF为新增的逻辑实体。这种计费机制也可
以应用于3GPP2和无线局域网（WLAN)的网络结构中。
图3为现有技术在承载网络中用FBC系统实现业务计费的流程图，其 具体步骤为：
步骤300、用户设备（UE )向TPF发送承载建立请求消息（Establish Bearer Serv Req );当承载网络是GPRS时，就是UE向GGSN发送激活PDP上下 文请求消息；
步骤301 、 TPF向CRF发送计费规则请求（Request Charging Rules)的 消息，消息中携带决定CRF选择计费规则的输入信息；
步骤302、 CRF根据得到消息携带的输入信息来选择相应的计费规则
6(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向CRP请求计费规则的 情况，除了在承载最初建立的时候TPF需要向CRF上报一些承载相关信息 用于选择计费规则之外，在承载修改或者承载删除等涉及到承载使用变化的 情况，也会导致相应的计费规则变化，这时TPF也需要向CRF发起计费规 则请求消息，由CRF根据来自TPF、 AF和OCS的信息进行选择，决定是 否实施新的计费规则。
在图3所述的步骤302中，和TPF向CRF请求计费规则的过程相独立 的，AF和OCS也可以向CRF提供选择计费规则的输入信息，其中AF提供 的信息和应用层业务相关，OCS提供的信息则和在线计费中业务的信用相 关，CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费 规则。
图4为现有技术中AF和CRF之间的交互流程图，其具体步骤为： 步骤400、 AF向CRF发送应用/业务数据流计费信息（Send application/Service Data FLOW Charging Information); 步骤401、 CRF向AF确认收到该信息。在图4中，通过Rx接口 ， AF向CRF提供application/Service Data FLOW Charging Information, CRF根据该信息，选择和构造适当的计费规则发送绐、 TPF。 AF决定什么时候发送该信息给CRF, CRF从收到该信息的那一刻开 始在计费规则的选择和决定上将application/Service Data FLOW Charging Information考虑在内。
图5为现有技术中OCS和CRF之间的交互流程图，其具体步骤为：
步骤500、 OCS向CRF发送与在线计费相关的计费信息（Send OCS related Charging Information );
步骤501、 CRF确认收到该信息。
在图5中，通过Ry接口， OCS向CRF提供与在线计费相关的计费信 息，CRF根据该信息，选择和构造适当的计费规则发送给TPF。 OCS决定 什么时候发送该信息给CRF, CRF从收到该信息的那一刻开始在计费规则 的选择和决定上将与在线计费相关的信息（OCS related Charging Information )考虑在内。
从图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使用业务时在应用层面或在线计费业务的一个中间节点，在后续业 务执行过程中会收到很多应用/业务相关的消息，这些消息都是针对当前业 务进行的各种操作。这些操作会修改应用/业务的参数等信息，而这些参凄t 又可能导致用户应用的计费规则改变，但是并不是所有的参数变化都会导致 计费规则的改变，具体哪些参数的变化会导致CRF应该下发新的计费规则 给TPF,只有CRF才能知道，AF上不保存任何与计费规则相关的信息，那 么AF/OCS或者在每次有业务参数改变的时候就通知CRF，或者预先配置一 些触发点，在满足触发条件的参数发生变化时才通知CRF。
但是，这样的实现很不灵活，每当参数改变就通知CRF的做法会增加 Rx/Ry接口的负荷，而下发的信息很多都是没有意义的。预先配置触发点的 方法只能应付筒单的情况，配置的触发点都是静态的，如果运营商希望结合 业务的使用提供灵活多样的计费策略，这种方法就无法满足了。更何况 AF/OCS和CRF不一定位于同一个运营商网络，而不同运营商网络中对基于 业务数据流计费的策略是不同的，同样的业务，在一个运营商的计费策略中， 一个参数的修改需要改变当前的计费规则，但是在另一个运营商的计费策略 中可能就不需要对正在实施计费规则做任何改变。因此，这种在业务执行过 程中始终由AF/OCS决定计费输入信息下发的方法不利于基于业务数据流 计费的开展和实施。
当前通用分组无线业务（GPRS)网络结构，针对数据流只能识别到接 入点名称（APN)和激活分组数据协议内容（PDP Context)这一级别。而 现实中，并行的多个业务数据流很可能使用同一个PDPContext承载，而不 同业务数据流可能采用不通的计费方式，当前GPRS网络就无法满足这一需 求。为了对不同类型的业务数据流采用不同的计费解决方案，需要对当前 GPRS提出一种新的承载计费结构，采用一种通用的基于业务数据流的计费 机制。
PDP，是分组数据包以离散形式传送的各种协议的通称，如IP协议和 X.25协议，可以用于外部数据网与核心网的交互，以及核心网络功能实体 之间的交互。PDP上下文是在移动台（MS)和GPRS支持节点（GSN)内， 为一个会话保存的信息集合。APN是标识终端要接入的网络或者业务的一 个标识，采用类似域名的格式。
目前3GPP提出了如何实现基于网际协议（IP)流的计费（FBC， Flow Based Charging)，对于一个分组业务来说，用户在使用该项业务所消耗的 数据量称为业务数据流（Service Data Flow),业务数据流是多个IP流组成 的集合。而在一个PDP context中可以承载多个不同的分组业务，因此FBC
4粒度可以小于基于PDP context的计费粒度，从而能够提供更为丰富的计费 手段。
在3GPP的TS23.125中对FBC的系统结构、功能要求以及消息流程等 方面进行了描述。其中支持在线计费的FBC系统结构如图1所示；支持离 线计费的FBC系统结构如图2所示。图1和图2中所示的各个功能实体作 用分别为：
传输面功能实体（TPF, Traffic Plane Function) , TPF是承载分组数才居 流的功能实体，其可区分属于不同业务数据流中的分组包，用于离线计费信 息收集和执行在线信用控制。当承载的分组数据流发生变化时，例如承载分 组凄t据流的建立、修改或删除过程，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, Application Function)信息以及在线计费系统（OCS, Online Charging System)信息作 为输入，用于选取适当的计费规则，在TPF请求或者有特定事件触发的时 候将选取的计费规则发送给TPF。
一个CRF可以对应多个TPF。AF, AF代表所有和应用相关的功能实体，AF向CRF提供相应的信息 使得CRF可以选择或配置相应的计费规则，AF提供的信息包括：业务数据 流的标识信息，可以设置为通配，计费规则选4奪的信息，应用/业务标识， 应用/业务计费规则触发时间，流类型，可以选择为视频或音频，流速率。
一个AF可以对应于多个CRF 。 AF可以根据用户的标识信息选择CRF 进行交互。
OCS, OCS作为在线计费系统由业务控制点（SCP, Service Control Point) 和信用控制功能（CCF, Credit Control Function)两个功能实体组成，其中 CCF对在线计费时的用户信用进行管理。当用户使用业务时，CCF对该用 户信用池中的信用进行授权，并向TPF下发用户可以使用的信用。通过Ry 接口 ， OCS可以向CRF提供计费规则选择的输入信息。
计费网关实体/计费收集实体（CCF/CGF , Charging Gateway Function/Charging Collection Function),这两个功能实体是用于离线计费系 统的，可以沿用现有的GPRS网络计费中的实现。
如果承载网络是GPRS网络，则TPF位于GGSN处，AF为PDN中的
一个业务网关，或是业务服务器。当IP多媒体子系统（IMS)承载在GPRS
网络之上时AF就是P-CSCF, CRF为新增的逻辑实体。这种计费机制也可
以应用于3GPP2和无线局域网（WLAN)的网络结构中。
图3为现有技术在承载网络中用FBC系统实现业务计费的流程图，其 具体步骤为：
步骤300、用户设备（UE )向TPF发送承载建立请求消息（Establish Bearer Serv Req );当承载网络是GPRS时，就是UE向GGSN发送激活PDP上下 文请求消息；
步骤301 、 TPF向CRF发送计费规则请求（Request Charging Rules)的 消息，消息中携带决定CRF选择计费规则的输入信息；
步骤302、 CRF根据得到消息携带的输入信息来选择相应的计费规则
6(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向CRP请求计费规则的 情况，除了在承载最初建立的时候TPF需要向CRF上报一些承载相关信息 用于选择计费规则之外，在承载修改或者承载删除等涉及到承载使用变化的 情况，也会导致相应的计费规则变化，这时TPF也需要向CRF发起计费规 则请求消息，由CRF根据来自TPF、 AF和OCS的信息进行选择，决定是 否实施新的计费规则。
在图3所述的步骤302中，和TPF向CRF请求计费规则的过程相独立 的，AF和OCS也可以向CRF提供选择计费规则的输入信息，其中AF提供 的信息和应用层业务相关，OCS提供的信息则和在线计费中业务的信用相 关，CRF根据可用的信息综合选择某个业务数据流承载计费应该实施的计费 规则。
图4为现有技术中AF和CRF之间的交互流程图，其具体步骤为： 步骤400、 AF向CRF发送应用/业务数据流计费信息（Send application/Service Data FLOW Charging Information); 步骤401、 CRF向AF确认收到该信息。在图4中，通过Rx接口 ， AF向CRF提供application/Service Data FLOW Charging Information, CRF根据该信息，选择和构造适当的计费规则发送绐、 TPF。 AF决定什么时候发送该信息给CRF, CRF从收到该信息的那一刻开 始在计费规则的选择和决定上将application/Service Data FLOW Charging Information考虑在内。
图5为现有技术中OCS和CRF之间的交互流程图，其具体步骤为：
步骤500、 OCS向CRF发送与在线计费相关的计费信息（Send OCS related Charging Information );
步骤501、 CRF确认收到该信息。
在图5中，通过Ry接口， OCS向CRF提供与在线计费相关的计费信 息，CRF根据该信息，选择和构造适当的计费规则发送给TPF。 OCS决定 什么时候发送该信息给CRF, CRF从收到该信息的那一刻开始在计费规则 的选择和决定上将与在线计费相关的信息（OCS related Charging Information )考虑在内。
从图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使用业务时在应用层面或在线计费业务的一个中间节点，在后续业 务执行过程中会收到很多应用/业务相关的消息，这些消息都是针对当前业 务进行的各种操作。这些操作会修改应用/业务的参数等信息，而这些参凄t 又可能导致用户应用的计费规则改变，但是并不是所有的参数变化都会导致 计费规则的改变，具体哪些参数的变化会导致CRF应该下发新的计费规则 给TPF,只有CRF才能知道，AF上不保存任何与计费规则相关的信息，那 么AF/OCS或者在每次有业务参数改变的时候就通知CRF，或者预先配置一 些触发点，在满足触发条件的参数发生变化时才通知CRF。
但是，这样的实现很不灵活，每当参数改变就通知CRF的做法会增加 Rx/Ry接口的负荷，而下发的信息很多都是没有意义的。预先配置触发点的 方法只能应付筒单的情况，配置的触发点都是静态的，如果运营商希望结合 业务的使用提供灵活多样的计费策略，这种方法就无法满足了。更何况 AF/OCS和CRF不一定位于同一个运营商网络，而不同运营商网络中对基于 业务数据流计费的策略是不同的，同样的业务，在一个运营商的计费策略中， 一个参数的修改需要改变当前的计费规则，但是在另一个运营商的计费策略 中可能就不需要对正在实施计费规则做任何改变。因此，这种在业务执行过 程中始终由AF/OCS决定计费输入信息下发的方法不利于基于业务数据流 计费的开展和实施。
发明内容
有鉴于此，本发明的主要目的在于提供一种基于移动分组数据业务流计 费中信息传送的交互方法，该方法能够避免下发无效信息给CRF，减轻了 Rx/Ry接口的负担，便于FBC计费的实施；该方法还可以通过修改CRF中 的计费策略来影响AF/OCS实体的选4奪，而且在制定计费策略的时候不会受 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系统的承载网络实施业务时的在线计费流程图。
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每当收到应
12用层会话消息，就进行触发点的匹配，如果匹配成功的话，再次向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收到确认信息后，查看该确认消息中是否带有触发点4言 息，如果有，保存并根据触发点信息配置相应的触发点；否则，继续后续的 会话处理。
图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;要删除旧的触发点，也会包括在该消息中，AF/P-CSCF重新保存并根据触发 点信息重新配置相应的触发点；
步骤708、 CRF根据AF/P-CSCF的输入信息选择计费规则或配置计费 规则中的参数，下发计费规则给TPF，和TPF之间进行提供计费规则的过程；
步骤709、 TPF根据计费规则，执行离线计费报告或者在线计费请求等 过程，将执行的过程上报给Charging。
在上述步骤705中，可以配置的触发点消息^f艮多，如在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为本发明基于F B C系统的承载网络实施业务时的在线计费流程图， 其具体过程为：
步骤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使用。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内所做的任何修改、等同替换和改进等，均应包含在本 发明的保护范围之内。
由于AF和CRF通过Rx接口进行信息交互的过程，与OCS和CRF通 过Ry接口进行信息交互的过程相同，只不过功能实体和接口不同而已，所 以本发明用AF和CRF通过Rx接口进行信息交互的过程来详细说明怎样对 业务数据流进行计费。
在实现Rx接口的时候，CRF会保存一些和应用/业务相关的信息，用于 收到AF的计费输入信息之后决定如何使用这些输入。因此，虽然AF上使 用的应用协议可能是多种多样的，但是CRF在收到AF第 一 次的计费输入信 息之后，就可以根据其中的输入信息确定和这个AF的业务关系。根据CRF 上保存的应用/业务相关信息，CRF就可以得知和这种类型业务有关的计费 策略是什么，哪些应用层的参数变化会导致计费规则的修改或重选。CRF 根据这些信息确定一些触发点信息，放在CRF返回给AF的确认消息中返回。 AF收到确认信息之后，查看是否有触发点信息返回，如果有，保存并根据 触发点信息设置这些触发点。在该业务的实际实施过程中，AF每当收到应
12用层会话消息，就进行触发点的匹配，如果匹配成功的话，再次向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收到确认信息后，查看该确认消息中是否带有触发点4言 息，如果有，保存并根据触发点信息配置相应的触发点；否则，继续后续的 会话处理。
图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;要删除旧的触发点，也会包括在该消息中，AF/P-CSCF重新保存并根据触发 点信息重新配置相应的触发点；
步骤708、 CRF根据AF/P-CSCF的输入信息选择计费规则或配置计费 规则中的参数，下发计费规则给TPF，和TPF之间进行提供计费规则的过程；
步骤709、 TPF根据计费规则，执行离线计费报告或者在线计费请求等 过程，将执行的过程上报给Charging。
在上述步骤705中，可以配置的触发点消息^f艮多，如在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为本发明基于F B C系统的承载网络实施业务时的在线计费流程图， 其具体过程为：
步骤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使用。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内所做的任何修改、等同替换和改进等，均应包含在本 发明的保护范围之内。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 对基于商业群组的消息传送计费 | 2020-05-11 | 324 |
| 一种利用近距离感应器，启动收费和支付数据传送的方法 | 2020-05-12 | 583 |
| 移动通信设备的消息传送应用中的费用估计 | 2020-05-12 | 731 |
| 传送广告和娱乐内容以及收集消费者信息的方法和系统 | 2020-05-12 | 160 |
| 通过数据传送提高智能网边界漫游计费准确性的方法 | 2020-05-12 | 798 |
| 传送单元、传送装置及传送方法 | 2020-05-13 | 753 |
| 用于通过可穿戴装置传送控制信息来控制移动及消费型电子装置的方法及设备 | 2020-05-12 | 597 |
| 传送计费信息的方法、系统和设备 | 2020-05-11 | 910 |
| 基于互联网的短消息传送系统的计费方法 | 2020-05-12 | 442 |
| 收费设备与收费方法 | 2020-05-13 | 188 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
传送费热门专利
QQ群二维码
意见反馈
意见反馈