CN1898706A - 用于在通信网中对业务计费的方法 - Google Patents

Abstract

所述的方法允许无状态的代理或应用代理的运营商简单地向注册的应用业务提供商和注册的客户提供可靠的、在可定义的间隔内准确的且值得信任的计费功能，方式是，在业务提供期间，客户和服务器持续地在后台以规则的间隔通过一独立的第三方(代理)来通知为此所产生的费用，并且也由独立的第三方提供计费功能。

Description

用于在通信网中对业务计费的方法

发明的问题

在面向分组的的通信网中，该通信网具有业务用户(例如SIP客户)、业务提供者(例如应用服务器)和进行交换的应用代理(例如SIP代理)，所述应用代理在位于业务用户设备(客户)和应用服务器之间的业务关系的时延内没有被纳入该关系(也就是说例如不是一种有状态的SIP代理)，对于所述代理而言，不可能对注册的客户(用户和业务提供者)提供可靠的计费功能。

该问题的目前解决方案

-代理在业务关系的时延内保持在通信关系中(有状态的代理)，或者

-在没有引入代理的情况下单独地在应用服务器和客户之间进行计费，也就是说代理的运营商仅仅是接入提供者。对所使用业务的一站式的总结算-如果可能的话-只能利用高的耗费在事后处理中完成->在代理运营商和在应用服务器提供商中的分布式计帐功能。该解决方案一方面需要确保：业务的用户同时也是代理运营商和服务器运营商的客户，而另一方面传输数据给中央帐单编制者。

根据本发明的问题解决方案

本发明讲述了一种方法，即如何在这种情形中能利用客户、代理(＝应用代理，应用交换设备)和应用服务器实现对所有伙伴可靠的计费，这种计费同时对于基本业务的提供商(代理的运营商)表现为一种增值业务。该提供商由此能够一站式地利用不同的伙伴-业务提供商的面向分组的业务给其终端客户提供可靠的帐单。在此，基本业务提供商可能既表现为业务的简单交换者，又表现为具有“标识重建(Rebranding)”的中间人(“标识重建”在这里被理解为：代理的运营商不是以业务原来的名称而是以自己的产品名称来提供伙伴-业务提供商的业务)。

最终，该方法的目的是：

a)针对被请求和使用的业务而向具有存款帐户的注册终端客户(客户)实时地计取使用费，或者

b)针对不同提供商的所有被使用的业务而向注册终端客户有规则地(例如每月)产生统一的总帐单。

利用所述方法确保：

a)客户只对他所使用的付费，以及

b)业务提供者针对他的业务而被付费。

此外，该方法还为以下方面创造了前提条件：已经可以作为选项而在业务使用期间实时地为客户显示增加了业务的哪些费用，或在预付费业务的情况下还存在多少存款。

该解决方案的基础是可靠的计费功能，所有的伙伴部分(客户、代理/应用代理、应用服务器)在业务使用期间被纳入到该计费功能中。

客户：在代理处被鉴权并请求业务。

代理/应用代理：交换业务，并管理关于客户使用该业务的账本。

应用服务器：提供业务，并用票据将它与客户之间的业务关系的发生和过程通知给代理。

图1示出了在本发明的一种实施变型方案中伙伴部分之间的相互关系以及经过业务请求和业务提供一直到计费的客户鉴权的原理过程。

-在客户借助于代理在鉴权-授权-计帐-服务器(AAA服务器)处被鉴权之后(1)/(2)，该客户从代理收到一个计帐参考(p1)连同关于应用服务器位于何处(目标)的信息，所述的计帐参考由代理产生以便对所存在的业务使用执行计费功能(3)。

-客户利用他从代理接收到的信息向应用服务器请求所希望的业务(4)。该应用服务器向客户确认业务请求(5)。由此在客户和应用服务器之间建立业务关系。

-在客户和应用服务器之间的业务关系被建立之后，只要业务被使用，应用服务器就以规则的间隔(例如每分钟一个地)产生票据，该票据被发送到代理上的计费功能(6)。这些票据包含有允许代理有效地访问计费表(计帐表)的参考p1和服务器自己已经产生的参考s1，并且必要时在晚些时候服务器可以在代理反馈信号的情况下利用该参考s1有效地访问其数据和终止现有的业务关系。

-在收到票据之后(6)，代理借助于票据中所含的参考p1求出客户(IP地址C1)，并针对每个接收的票据向该客户请求确认该计费数据(7)。如果在某个时间(例如1秒)之后没有接收到确认，则一次或两次地重复该请求(7)。

-在接收确认请求之后，客户认证该票据，并在必要时向代理发送一个确认(8)。

-在从客户接收确认之后，代理存储该票据以便以后进行帐单编制，并且通知服务器客户已经确认该票据。在预付费客户的情况下，代理上的计费功能更新客户的存款状态。

在本发明的上述实施变型方案中的特殊情况：

-预付费客户：

如果存款低于某个阈值，则代理通知客户存款即将用完。这例如可以利用票据的下一个确认请求来实现(7)。如果存款用完，则代理将清除计帐表中的条目，并且针对该客户不再接受来自于应用服务器的其它票据，并且向服务器否定地确认这些票据，该服务器据此在必要时终止与客户的业务关系。

-向客户请求票据确认被否定地确认：

代理通知应用服务器票据已被否定地确认，其中该代理给应用服务器发回所述的参考s1。借助于该参考s1，服务器随后能够终止与客户的业务关系。

-尽管多次请求但没有收到客户的票据确认：

代理通知应用服务器他针对一个票据没能从客户收到确认，其中该代理给应用服务器发回所述的参考s1。借助于该参考s1，服务器随后能够终止与客户的业务关系。

-计帐表条目的定时器t1到期。

为了确保计帐表条目的有效性，代理监视来自于服务器的票据的进入。一旦出现一个票据(6)，则复位被调整的定时器。在定时器到期时，清除表格中的条目。接下来可能从服务器到来的票据被否定地确认。

注释：

-应注意，该方法不需要服务器和/或客户在业务关系终止时在代理处被注销。因此向客户发送计费票据也总是提前在实际的计费间隔内进行的。由此确保了客户不请求使用付费业务而不为此付费，其方式是，客户在计费间隔到期之前简单地注销业务，以便阻止他在过去的间隔内被计费。

-计帐表内的监视定时器t1必须总是大于计费间隔的长度，该计费间隔在客户和应用服务器之间是被商定的。该计费间隔必须被选得足够大，以便避免丢失的(并因此由服务器重复的)通往代理的票据消息导致该代理将计帐表条目解释为无效的。但t1同时不能被选择得太大，以便避免例如恶意客户的“业务否认攻击”导致计帐表资源的短缺，并最终导致该业务的不可用。t1的明智值是计费间隔长度的23倍。因为各个业务关系(见图1)的计费间隔长度可以是不同的，所以监视定时器t1的长度倍构造为可变的。一旦代理从服务器收到一个票据，则它使用其中所给出的计费间隔长度，并由此确定t1的长度，以便监视针对该业务关系从服务器接收下一个票据。在从服务器接收第一票据之前，为该定时器采用对计帐表统一的固定初始值(例如5秒)。

-在客户和应用服务器之间可能的可信措施：在客户和服务器之间商定业务关系的条件(第一间隔的长度和费用，后续间隔的长度和费用)。通过选择短的第一间隔和对此可能的特殊条件，可以确保：即便在不提供业务的情况下(例如服务器故障、SW故障、客户与服务器软件不兼容)，尽管为业务用户建立了业务关系，但不会产生缺点或只是产生极少的缺点。

-在代理的计费功能故障的情况下，应用服务器可以根据缺乏对票据的确认而在必要时注销与客户的业务关系。

-在客户故障的情况下，客户的计费帐户不会错误地继续由服务器扣帐，因为客户再也不能确认代理的票据确认请求(见特殊情况)。

-在客户方的功能性例如可以被扩充以下方面：

i.存储从代理传输的费用消息，并在终端上显示该费用以便实时地进行费用监视。

ii.终端用户作为可选项人工地拒绝票据的可能性，例如在达到某个自设定的费用限度时。

总之可以说明如下。所述的方法允许无状态的代理或应用代理的运营商简单地向注册的应用业务提供商和注册的客户提供可靠的、在可定义的间隔内准确的且值得信任的计费功能，方式是，在业务提供期间，客户和服务器持续地在后台以规则的间隔通过一独立的第三方(代理)来通知为此所产生的费用，并且也由独立的第三方提供计费功能。

本发明的应用实例

-咨询业务

-视频业务

-电话附加业务，例如经由会议服务器的会议

-邮箱询问

-由开放的因特网控制的网关的匿名计帐

Claims (14)

1.业务交换设备，其

a)从客户接收业务请求，

b)然后执行鉴权，并且在鉴权成功之后向所述客户通知一个对用于执行所请求的业务的应用服务器的参考，

c)接收由所述应用服务器产生的计费票据，其中所述票据包含有关于在业务使用之前或期间所产生的费用的信息，

d)针对所接收的票据分别向所述客户发送一个确认请求，

e)如果所述客户确认所述票据，则为该票据执行一个费用登记动作。

2.如权利要求1所述的业务交换设备，其特征在于：

所述费用登记动作在于，所述业务交换设备更新所述客户的存款状态或费用状态。

3.如权利要求1所述的业务交换设备，其特征在于：

所述费用登记动作在于，所述业务交换设备存储所述的票据以用于以后编制帐单。

4.如权利要求1-3之一所述的业务交换设备，其特征在于：

所述业务交换设备把因该费用登记动作而导致的费用通知给所述客户。

5.应用服务器，其

a)从客户接收业务请求，其中所述业务请求含有对一业务交换设备的参考，

b)针对所述的业务产生计费票据，并且该应用服务器在接受所述业务请求时向所述业务交换设备发送所述计费票据，其中所述票据包含有关于在执行所述业务之前或期间对该客户所产生的费用的信息，

c)从所述业务交换设备接收关于以下方面的通知，即所述票据是否经所述客户确认，

d)只要所述票据由所述客户肯定地确认，则维持所述业务的执行。

6.如权利要求5所述的应用服务器，其特征在于：

如果所述应用服务器从所述业务交换设备接收到通知“所述客户已就票据否定地确认一个确认请求”，则所述应用服务器终止与客户的业务关系。

7.如权利要求5所述的应用服务器，其特征在于：

如果所述应用服务器从所述业务交换设备接收到通知“所述客户就票据根本就没有确认一个确认请求或多个确认请求”，则所述应用服务器终止与客户的业务关系。

8.如权利要求5所述的应用服务器，其特征在于：

如果所述应用服务器从所述业务交换设备根本就没有接收到对它所产生的票据的确认，则所述应用服务器终止与客户的业务关系。

9.如权利要求5所述的应用服务器，其特征在于：

如果所述应用服务器在预付费用户的情况下就一个票据而从所述业务交换设备接收到通知“不再存在足够的存款”，则所述应用服务器终止与客户的业务关系。

10.客户，其

a)向业务交换设备发送业务请求，

b)在所述业务请求的鉴权成功之后，从所述业务交换设备接收一个对所请求的业务的参考，

c)借助于所述的参考向被请求的业务的应用服务器建立业务关系，

d)从所述业务交换设备接收针对该业务所产生的费用的确认请求，

e)相对于所述业务交换设备认证和应答所述的确认请求。

11.如权利要求10所述的客户，其特征在于：

所述客户存储借助于确认请求从所述业务交换设备传输的费用消息，并实时地给终端用户显示该费用以便于费用监视。

12.如权利要求10或11所述的客户，其特征在于：

所述客户允许所述终端用户人工地应答一个费用消息。

13.用于在通信网中对业务计费的方法，据此，

f)从客户向业务交换设备发送业务请求，

g)然后借助于所述业务交换设备执行鉴权，其中在鉴权成功之后从所述业务交换设备向所述客户通知一个对所请求的业务的业务参考，

h)由所述客户借助于所述业务参考向被请求的业务的应用服务器建立业务关系，

i)由所述客户把对所述业务交换设备的参考通知给所述应用服务器，

j)由所述应用服务器产生票据并发送给所述业务交换设备，其中所述票据包含有关于在业务使用之前或期间所产生的费用的信息，

k)由所述业务交换设备针对票据向所述客户发送一个确认请求，

l)如果所述票据被确认，则由所述业务交换设备将该票据用于一个费用登记动作。

14.如权利要求13所述的方法，其特征在于：

a)所述确认请求的结果从所述业务交换设备被续传给所述应用服务器，

b)只要所述票据经所述客户肯定地确认，则维持在所述应用服务器方执行所述的业务。