网络节点中的配额的聚集处理的制作方法

本发明涉及由管理在线计费的网络节点执行的方法以及执行所述方法的网络节点。

背景技术：

在当今的移动通信网络（诸如包括全球移动通信系统（gsm）、通用移动通信业务（umts）或长期演进（lte）的第三代合作伙伴项目（3gpp）通信网络）中，每个用户（即订户）服从针对单独的网络资源使用的计费和记账。

gsm/umts/lte网络提供实现针对以例如某个持续时间的语音呼叫、某个容量的数据的传送、某个大小的多媒体消息传送服务的提交等的形式的用户的网络资源使用的离线和/或在线计费机制的功能。

在离线和在线计费两者中，针对网络资源使用的计费信息与那个资源使用同时被收集。

然而，在离线计费中，出于订户记账的目的，在资源使用已经发生之后从网络报告资源使用。因此，离线计费是其中计费信息不会实时影响所提供的服务的机制。

相反地，在在线计费中，在准许使用一个或多个请求的网络资源之前，询问位于在线计费系统中的订户账户。因此，在实际资源使用发生之前，必须通过网络获得对于网络资源使用的授权。根据来自网络的请求而由所谓的在线计费系统（ocs）来准许这个授权并且可将这个授权限制在范围（例如数据的容量或持续时间）内，因此只要用户的网络资源使用持续，就可能不得不时时更新授权。

图1说明了3gpp网络的在线计费体系结构。正如所说明的，在三个级别上实现离线和在线计费机制：（1）核心网络（cn）域中的承载级别，例如在lte中的演进的分组核心（epc）中；（2）服务级别，例如如mms；以及（3）子系统级别，例如在因特网协议多媒体系统（ims）中。

计费触发功能（ctf）10基于用户的网络资源使用的观测来生成计费事件并且将计费事件转发到在线计费系统（ocs）12的在线计费功能（ocf）11以便获得对于由用户请求的网络资源使用/可计费事件的授权。

由ocf11返回到ctf10的授权包括所谓的配额，即允许被用户消耗的网络资源的量的分配。因此，实际上，ocf11储备来自订户账户的信用并且将相应的配额（例如指定可供请求的服务之用的分钟或字节的数量的单位）返回到ctf10，ctf10按照它的顺序使用所提供的配额来监督实际网络资源消耗。

如果先前由ocf11命令这样做的话，当配额被用完时，ctf10或者发布请求要被分配的另外的单位的另一计费事件或者终止与配额相关联的会话（例如语音呼叫、ims会话或ip连通性接入网络（ipcan）会话）（或者请求别的网络元件来终止会话）。一旦终止了会话，将消耗的单位与最终的计费事件一起报告回给ocf11。然后终止信用控制会话，并且ocf11将任何未使用的配额的值（正如由ctf10报告的）返回到订户的账户。

图1进一步说明了ocs12包括用于为ocf11确定在由ocf11从网络接收到的计费事件中描述的网络资源使用的值的评定功能（rf）13。在所说明的逻辑计费功能之间的通常被称为参考点的各种接口被表示为ro/cap、rc和re。

ocs12进一步包括账户平衡管理功能（abmf）14，所述账户平衡管理功能（abmf）14是订户的账户平衡位于ocs12内的地方。

使第三方支付用户的账单也是可能的，例如所谓的过顶（ott）服务提供商，诸如netflix、spotify、facebook等。这通常被称为赞助的数据连通性，其中第三方（亦被称为赞助者）与网络运营商具有商业关系并且就用户的到由赞助者提供的服务的数据连通性偿付运营商（或者备选地，用户负担与和网络中的订户的正常计费是分开的事务的连通性的费用）。

在赞助的数据连通性的情况下，ctf10报告网络资源的赞助的使用连同离线计费服务的订户的使用。ocs12将因此不得不聚集所有订户离线计费数据上的赞助的使用以用于与赞助者的清算，这是繁琐的过程。

现有解决方案中的另外的问题是可在ctf10处从单独的用户接收到大量的对于赞助的服务的使用的请求以及ocs12将会从ctf10接收到相应数量的对于授权的请求以使用赞助的服务，从而在网络中生成大量的业务。

技术实现要素：

本发明的目的是解决或者至少减轻本领域中的这个问题并且因此提供管理在线计费的改进的方法。

在本发明的第一方面中通过由管理赞助的数据连通性的在线计费的网络节点执行的方法来达到这个目的。所述方法包括接收对于与赞助的数据连通性有关的服务的用户请求、估计预计使用所述服务的用户的数量以及从授权使用赞助的数据连通性的在线计费系统获取对于估计的数量的预计使用所述服务的用户的授权。所述方法进一步包括准许用户利用与来自所述在线计费系统（17）的授权一起被接收的配额来使用请求的服务，所述配额在指定的时间段是有效的，并且（6）进一步准许请求所述服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务直到已经分配了由在线计费系统（17）授权的用于估计的数量的用户的总配额为止。

在本发明的第二方面中通过被配置为管理赞助的数据连通性的在线计费的网络节点来达到这个目的，所述网络节点包括处理单元和存储器，所述存储器包含可由所述处理单元执行的指令，借此所述网络节点操作用来接收对于与赞助的数据连通性有关的服务的用户请求、估计预计使用所述服务的用户的数量、从授权使用赞助的数据连通性的在线计费系统获取对于估计的数量的预计使用所述服务的用户的授权，并且操作用来准许用户利用与来自所述在线计费系统的授权一起被接收的配额来使用请求的服务，所述配额在指定的时间段是有效的，以及进一步操作用来准许请求所述服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务直到已经分配了由在线计费系统授权的用于估计的数量的用户的总配额为止。

在本发明的第三方面中通过由管理被一组用户共同使用的账户的在线计费的网络节点执行的方法来达到这个目的，所述方法包括接收对于要被记账到共同账户的服务的用户请求、估计预计提交对于要被记账到共同账户的服务的请求的用户的数量、从授权服务访问的在线计费系统获取对于估计的数量的预计提交对于要被记账到共同账户的服务的请求的用户的授权以及准许用户利用与来自所述在线计费系统的授权一起被接收的配额来使用请求的服务，所述配额在指定的时间段是有效的，并且进一步准许请求要被记账到共同账户的服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务直到已经分配了由在线计费系统授权的用于估计的数量的用户的总配额为止。

在本发明的第四方面中通过被配置为管理被一组用户共同使用的账户的在线计费的网络节点来达到这个目的，所述网络节点包括处理单元和存储器，所述存储器包含可由所述处理单元执行的指令，借此所述网络节点操作用来接收对于要被记账到共同账户的服务的用户请求、估计预计提交对于要被记账到共同账户的服务的请求的用户的数量、从授权服务访问的在线计费系统获取对于估计的数量的预计提交对于要被记账到共同账户的服务的请求的用户的授权，并且操作用来准许用户利用与来自所述在线计费系统的授权一起被接收的配额来使用请求的服务，所述配额在指定的时间段是有效的，以及进一步操作用来准许请求要被记账到共同账户的服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务直到已经分配了由在线计费系统授权的用于估计的数量的用户的总配额为止。因此，在实施例中，配备有用于管理赞助的数据连通性的ctf功能性的以例如网关（诸如pgw）的形式的网络节点接收对于与赞助的数据连通性有关的服务的用户请求。注意到用于管理赞助的数据连通性的ctf可与管理“正常”订户在线计费的ctf一起被布置在pgw中，并且注意到这两个ctf被通信耦合至彼此以用于交换与计费有关的数据。

在注册用户请求使用与赞助的数据连通性有关的服务时，网络节点基于用户的网络资源使用的观测来生成计费事件并且将计费事件转发到授权使用赞助的数据连通性的ocs。

有利地，在将计费事件转发到赞助者的ocs之前，网络节点估计预计使用请求的服务的用户的数量。估计可例如基于历史使用数据。

此后，网络节点基于估计来提交计费事件并且因此从授权使用赞助的数据连通性的赞助者的ocs获取对于估计的数量的预计使用请求的服务的用户的授权。

与从赞助者ocs接收的授权一起，配额被包括，所述配额指定对于估计的数量的用户而言允许被消耗的网络资源的量。

网络节点将准许用户利用与来自所述在线计费系统的授权一起被接收的配额来使用请求的服务，该配额在指定的时间段是有效的。配额可例如指定可以供请求的服务之用的分钟或字节的数量。

此外，网络节点准许请求服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务。每个用户可被分配它的单独的配额。然而，还可以设想，请求用户被分配大小相等的配额，这将会有利地简化网络节点处的配额的管理，尤其是在其中大量的用户请求使用服务的场景中。

可通过在线计费系统或者网络节点来指定在此期间配额是有效的时间段。

请求使用服务的另外的用户被分配配额直到已经将由赞助者ocs授权的用于估计的数量的用户的总配额分配给请求用户或者针对配额的指定的时间段已经期满。

有利地，即使数以百计、数以千计或者乃至数以百万计的用户/装置（尤其是随着物联网（iot）和机器类型通信（mtc）装置的出现）请求使用赞助的服务，从而创建相应数量的对于网络资源利用的请求给可包含“正常”ctf和赞助者ctf两者的网络节点，但是只有对于授权使用服务的单个请求需要被提交给授权使用赞助的服务的ocs。

响应于此，授权使用赞助的服务的ocs仅被要求将带有用于如由网络节点估计的所述数量的用户的允许的配额的授权发送到网络节点。这将会极大地减少朝向赞助者ocs的在线计费会话的量以及在包括ctf的网络节点和赞助者ocs之间的网络中生成的业务的量。

应当注意到上面的方法可适用于其中一组用户正在请求要从共同账户在线收取费用的一个或多个服务的场景。在这样的场景中，授权使用赞助的服务的ocs宁可被表示为“授权使用从共同账户收取费用的服务的ocs”。

在实施例中，当已经分配了由在线计费系统授权的用于估计的数量的用户的总配额时或者当针对配额的指定的时间段已经期满时，网络节点向授权使用赞助的数据连通性的在线计费系统报告已经被请求服务的用户消耗的总配额。

在另一个实施例中，网络节点估计预计使用服务的用户的新的数量并且从在线计费系统获取对于新的估计的数量的预计使用所述服务的用户的授权。

在另外的实施例中，网络节点记录分配给请求服务的每个用户的配额。

在还有的实施例中，网络节点向每个用户提交询问以报告它的消耗的配额。

在还有的另一实施例中，网络节点从每个用户接收指示所述每个用户的消耗的配额的报告。

在仍有的实施例中，网络节点从已经消耗了分配的配额的或者具有过期的配额的用户接收对于服务的请求并且准许用户利用新分配的配额来使用请求的服务。

在仍有的另一实施例中，网络节点准许用户利用超过由在线计费系统授权的用于估计的数量的用户的总配额的配额来使用请求的服务。

有利地，对于其中用户缓慢地消耗配额的服务，为了进一步减少网络节点和赞助者ocs之间交互的数量，网络节点可应用因子（1＜因子）以允许网络节点将另外的配额分配给客户，诸如由赞助者ocs最初准许了用于分配两倍之多的配额的2的因子。这具有以下两种影响：（a）避免了来自ocs的对于可能从未被用户完全消耗的配额的请求以及（b）减少了对于正在被ocs准许的不必要的大配额的需要。

在仍有的另一实施例中，网络节点在所述在线计费系统没有授权使用的情况下拒绝用户使用请求的服务的准许、从已经使用了服务的每个用户获取最终服务使用报告以及向所述在线计费系统报告正如在相应的最终服务使用报告中定义的被每个用户使用的配额。

进一步提供了一种包括计算机可执行指令的计算机程序，所述计算机可执行指令用于当所述计算机可执行指令在包括在节点中的处理单元上被执行时促使网络节点执行根据本发明的方法的实施例的步骤。

进一步提供了一种包括计算机可读介质的计算机程序产品，所述计算机可读介质具有包含在其上的节点的计算机程序。

通常，除非本文中另有明确定义，权利要求书中使用的所有术语要按照它们在技术领域中的通常含义来解释。除非另有明确说明，所有提及“元件、设备、组件、部件、步骤等/所述元件、设备、组件、部件、步骤等”要被开放式地解释为指元件、设备、组件、部件、步骤等的至少一个实例。除非明确说明，不必以公开的精确顺序来执行本文中公开的任何方法的步骤。

附图说明

现在参考附图，通过示例的方式来描述本发明，其中：

图1说明了3gpp网络的现有技术在线计费体系结构；

图2说明了根据实施例的用于管理赞助的数据连通性的在线计费的网络节点；

图3说明了根据实施例的由被配置为管理赞助的数据连通性的在线计费的网络节点执行的方法的序列图；

图4说明了根据另外的实施例的由被配置为管理赞助的数据连通性的在线计费的网络节点执行的方法的序列图；

图5说明了根据还有的另外的实施例的由被配置为管理赞助的数据连通性的在线计费的网络节点执行的方法的序列图；

图6说明了根据实施例的网络节点；以及

图7说明了根据另一实施例的网络节点。

具体实施方式

现在将参考附图在下文中更充分地描述本发明，在附图中示出了本发明的某些实施例。然而，可以以许多不同的形式来体现本发明并且本发明不应当被解释为限于本文中阐述的实施例；相反，通过示例的方式来提供这些实施例使得本公开将会是透彻和完整的，并且这些实施例将会充分地将本发明的范围传达给本领域技术人员。贯穿本描述，相同的附图标记指相同的元件。

图1说明了3gpp网络的现有技术在线计费体系结构，先前已经讨论了现有技术在线计费体系结构的一般原理。

图2说明了根据实施例的用于管理赞助的数据连通性的在线计费的网络节点15。

借助于用户设备（ue）15a-d（例如智能电话、平板、智能手表、游戏控制台、膝上型电脑等）说明的用户经由基站16（例如在lte中被称为enodeb）连接到通信网络，形成无线接入网（ran），并且再向前连接到所谓的核心网络17。作为示例，在lte中，核心网络被称为epc并且包括功能实体，诸如移动性管理实体（mme）、服务网关（sgw）、归属订户服务器（hss）等（图2中未示出）。

此外，包括了分组数据网络网关（pgw）18以用于通过是相对于分组数据网络（pdn）的针对ue的业务的出口和入口的点来提供到ue15a-15d到外部pdn19的连通性。ue可具有与不止一个pgw的同时连通性以用于接入多个pdn或者可具有到单个pgw的多个连接以用于接入多个pdn。

正如参考图1已经讨论的，在在线计费中，在准许使用请求的网络资源之前，询问位于ocs12中的订户账户。因此，在实际资源使用发生之前，必须通过网络获得对于网络资源使用的授权。根据来自网络的请求而由ocs12来准许这个授权。

正如与图1有关地进一步讨论过的，ctf10被布置在pgw18中以用于基于用户的网络资源使用的观测来生成计费事件并且将计费事件转发到ocs12以便于获得对于由用户请求的网络资源使用/可计费事件的授权。处理正常的订户在线计费的ctf10和ocs12在下面分别被称为ctf/用户10和ocs/用户12。

在图2中进一步说明的是负责赞助的数据连通性的在线计费的ocs20，所述ocs20在下面将被称为ocs/赞助者20。

在这个实施例中，引入了被称为ctf/赞助者21的另外的功能实体，所述ctf/赞助者21被通信耦合至ctf/用户10和ocs/赞助者20两者。

因此，ctf/用户10一接收到对于与赞助的数据连通性有关的服务的用户请求，ctf/用户10就将会把用户请求引向负责获取由用户15a请求的来自ocs/赞助者20的授权的ctf/赞助者21。

注意到用户请求通常包括指定特定赞助者的标识符，即为此作出请求的赞助者id，使得当多个赞助者通常存在于网络中（所有赞助者通过pgw18是可寻址的）时，pgw18可转向正确的ocs/赞助者20。

进一步设想实施例中的ctf/用户10和ctf/赞助者21在例如在3gpp规范ts23.682中描述的所谓的机器类型通信互通功能（mtc-iwf）中被实现以用于处理mtc装置的服务请求，在这种情况下“ctf/赞助者”相反将会被称为“ctf/mtc”以用于处理请求要被记账到共同账户的服务的一大组mtc装置。

图3说明了根据实施例的由被配置为管理赞助的数据连通性的在线计费的网络节点执行的方法的序列图，其中网络节点被例示为通过pgw18来体现。

正如已经讨论过的，pgw18包括功能实体ctf/用户10和ctf/赞助者21，其中由ctf/用户10来接收任何用户请求。如果用户请求与正常的在线计费有关，则ctf/用户10从ctf/用户12获取授权；而如果用户请求与赞助的数据连通性有关，则用户请求被路由到ctf/赞助者21，ctf/赞助者21按照它的顺序从ocs/赞助者20获取授权。

然而，在图3的序列图中，从pgw18的角度而不是从相应的功能实体ctf/用户10和ctf/赞助者21的角度来查看通信。

在第一步骤s101中，由pgw18从第一ue15a接收对于与赞助的数据连通性有关的服务的用户请求，该请求包括赞助者id。

当从第一ue15a接收到用户请求时，pgw18在步骤s102中例如通过分析历史数据来估计预计使用请求的服务的用户的数量。

作为示例，预计在特定时间段期间使用服务的用户的估计的数量等于100，其中时间段被设置为例如接下来的10分钟。

因此，pgw18在步骤s103中转向利用赞助者id指示的ocs/赞助者20以用于获取对于估计的数量的预计使用请求的服务的用户的授权。

作为示例，假设与授权一起被接收的总配额是100x1gb，其中请求的服务例如可以是观看youtube视频。因此，一百个用户将会被准许各自1gb的流播的youtube视频，配额在接下来的10分钟期间是有效的。可通过ocs/赞助者20或者通过pgw18来设置有效时间段。

在步骤s104中，第一用户15a因此被准许利用与来自ocs/赞助者20的授权一起被接收的配额（即在接下来的10分钟期间的1gb）来使用请求的服务。

现在，当接收到对于服务的另外的请求时，正如利用估计所预计的，在步骤s101b中通过请求服务的第二ue15b所例示的，pgw18有利地将不会转向ocs/赞助者20以用于获取授权，而是将会在步骤s104b中准许第二ue15b利用与来自ocs/赞助者20的授权一起被接收的配额（即在接下来的10分钟期间的1gb）来使用请求的服务。

注意到在第一场景中，每个分配的配额在所设置的特定时间段是有效的，即，每个配额在自分配的实例起的接下来的10分钟是有效的。在这样的场景中，pgw18通常将会负责设置指定分配的配额的有效性的时间段。在第二场景中，每个配额在自当ocs/赞助者20实际上授权请求时的实例起计算的指定的时间段是有效的。因此，如果第二ue15b将在第一ue15a之后的恰好一分钟作出它的请求的话，有效时间段将会等于10-1=9分钟。在这样的场景中，ocs/赞助者20可负责设置指定分配的配额的有效性的时间段。pgw18通常保持分配给每个用户的配额的记录。

因此，在这个例示实施例中，可向pgw18作出一百个用户服务请求并且一百个用户服务请求将会与分配的配额一起被准许，而pgw18向ocs/赞助者20只作出对于授权的一个单个请求，这有利地将会极大地减少pgw18和ocs/赞助者20之间的业务的量。

注意到由pgw18接收到的对于服务的请求不必来自先前尚未作出服务请求的用户。例如，在第二ue15b已经作出它的请求之后，第一ue15a可再次提交服务请求；第一ue15a可能已经用完了分配的配额（或者具有过期的配额），在这种情况下pgw18将会再次把配额分配给第一ue15a，除非被ocs/赞助者20授权的总配额已经被分配或者是过期的。

在另外的实施例中，设想pgw18准许用户利用超过被ocs/赞助者20授权的用于估计的数量的用户的总配额的配额来使用请求的服务。

假设pgw18已经分配了在步骤s103中最初被ocs/赞助者20授权用于估计的数量的用户的总的100x1gb的配额并且假设对于服务的另外的请求被pgw18接收到，pgw18将在这个特定的实施例中准许另外的请求并且将额外的配额分配给请求用户。例如，pgw18可确定另外的50x1gb要被准许，从而允许150x1gb的总配额。

有利地，这进一步减少了pgw18和ocs/赞助者20之间交互的数量，因为如果例如请求服务的实际用户数量超过了估计的用户数量则不需要由pgw18从ocs/赞助者20获得额外的配额。

图4示出了是图3中示出的序列图的继续的序列图，其中说明了另外的实施例。

在这个实施例中，在已经消耗了在步骤s103中被ocs/赞助者20授权用于估计的数量的用户的总配额之后或者在针对配额的指定的时间段已经期满之后，pgw18在步骤s105中报告已经被请求服务的用户消耗的总配额，使得与ocs/赞助者20相关联的赞助者可以例如通过就用户的到由赞助者提供的服务的数据连通性偿付网络运营商来有利地清算与赞助的数据连通性有关的任何账单。进一步有利的是在一个时机而不是重复使用针对单独的用户的零星报告来报告请求服务的所有用户的资源使用。

因此，与先前的示例一致，可以设想（1）报告100x1gb的总配额已经被消耗，或者可以设想（2）在已经期满的10分钟中，更少的配额已经被消耗，该更少的消耗的配额因此被报告。因此，或者所有分配的配额已经被消耗，或者分配的配额的子集已经被消耗。无论哪种方式，向ocs/赞助者20报告消耗的配额。

在一个场景中，pgw18假设确实已经消耗了分配给用户的配额。

在备选的场景中，pgw18将从相应的用户获取关于用户事实上是否已经消耗了它的分配的配额的信息。

为此，pgw18记录分配的配额并且随后例如在分配的配额期满时向用户提交分配的配额事实上是否已经被用户消耗的询问。备选地，pgw18从每个用户接收指示配额实际上是否已经被消耗的消息。

图5示出了说明还有的另外的实施例的另外的序列图。

在pgw18在步骤s105中已经向ocs/赞助者20报告了消耗的配额之后，pgw18在步骤s106中估计预计使用服务的用户的新的数量。

此后，在步骤s107中，pgw18在步骤s107中从ocs/赞助者20获取对于新的估计的数量的预计使用服务的用户的授权，并且利用分配新配额来重复所述过程。

因此，pgw18甚至在没有接收到对于服务的任何另外的用户请求的情况下可有利地向ocs/赞助者20请求另外的配额。设想pgw18可例如通过分析网络业务来获取指示，设想另外的用户预计使用为此获取授权和配额的服务。

在仍有的实施例中，如果pgw18在还没有执行步骤s105中的报告已经被消耗的配额的情况下将向ocs/赞助者20请求额外的配额，并且被ocs/赞助者20拒绝授权，则pgw18因此拒绝任何另外的用户使用请求的服务的准许、从已经使用了服务的每个用户获取最终服务使用报告并且向ocs/赞助者20报告如在相应的最终服务使用报告中定义的被每个用户消耗的配额。

再次参见图2和图3，正如先前已经提及的，上面的方法可适用于其中一组用户正在请求要从共同账户在线收取费用的一个或多个服务的场景。在这样的场景中，授权使用赞助的服务的ocs/赞助者20宁可被称为“授权使用从共同账户收取费用的服务的ocs”并且被表示为ocs/共同20。

因此，再次参见图3的序列图，在第一步骤s101中，由pgw18从第一ue15a接收对于要被记账到共同账户的服务的用户请求，该请求包括服务id或共同账户id。

在从第一ue15a接收到用户请求时，pgw18在步骤s102中例如通过分析历史数据来估计预计请求要被记账到共同账户的服务的用户的数量。注意到不同的服务可与相同的共同账户相关联。

再次作为示例，预计在特定时间段期间使用与共同账户相关联的一个或多个服务的用户的估计的数量等于100，其中时间段被设置为例如接下来的10分钟。

因此，pgw18在步骤s103中转向利用服务或账户id指示的ocs/共同20以用于获取对于估计的数量的预计使用与共同账户相关联的一个或多个请求的服务的用户的授权。

作为示例，假设与授权一起被接收的总配额是100x1分钟，其中请求的服务例如可以是与多个合作的电话运营商中的一个打电话，那些呼叫要被记账到共同账户。因此，一百个用户将会被准许1分钟的电话呼叫，配额取决于应用在或者自其中作出配额的每个分配的时间的实例起的或者备选地自其中ocs/共同授权使用请求的服务的时间的实例起的接下来的10分钟期间是有效的。

在步骤s104中，第一ue15a因此被准许利用与来自ocs/共同20的授权一起被接收的配额（即在接下来的10分钟期间的1分钟）来使用请求的服务。

现在，当接收到对于服务的另外的请求时，正如利用估计所预计的，在步骤s101b中通过请求服务的第二ue15b所例示的，pgw18有利地将不会转向ocs/共同20以用于获取授权，而是将会在步骤s104b中准许第二ue15b利用与来自ocs/共同20的授权一起被接收的配额（即在接下来的10分钟期间的1分钟电话呼叫）来使用请求的服务。

因此，在这个例示实施例中，可向pgw18作出对于与共同账户相关联的服务的一百个用户请求并且一百个用户请求将会与分配的配额一起被准许，而pgw18向ocs/共同20只作出对于授权的一个单个请求，这有利地将会极大地减少pgw18和ocs/共同20之间的业务的量。

参见图6，实际上由以布置成执行计算机程序31的一个或多个微处理器的形式体现的处理单元30来执行由根据实施例的网络节点18执行的方法的步骤，所述计算机程序31被下载到与微处理器相关联的适合的存储介质32，诸如随机存取存储器（ram）、闪速存储器或硬盘驱动器。处理单元30被布置成当包括计算机可执行指令的适当的计算机程序31被下载到存储介质32并且被处理单元30执行时促使网络节点18执行根据实施例的方法。存储介质32还可以是包括计算机程序31的计算机程序产品。

备选地，可借助于适合的计算机程序产品（诸如数字通用盘（dvd）或记忆棒）而将计算机程序31移至存储介质32。作为另外的备选，可通过网络将计算机程序31下载到存储介质32。可备选地以下列形式体现处理单元30：数字信号处理器（dsp）、专用集成电路（asic）、现场可编程门阵列（fpga）、复杂可编程逻辑器件（cpld）等。

图7说明了根据实施例被配置为管理赞助的数据连通性的在线计费的网络节点18。

网络节点18包括适于接收对于与赞助的数据连通性有关的服务的用户请求的接收部件40、适于估计预计使用服务的用户的数量的估计部件41以及适于从授权使用赞助的数据连通性的在线计费系统获取对于估计的数量的预计使用服务的用户的授权的获取部件42。网络节点18进一步包括准许部件43，所述准许部件43适于准许用户利用与来自在线计费系统的授权一起被接收的配额来使用请求的服务，该配额在指定的时间段是有效的，并且准许部件43进一步适于准许请求服务的任何另外的用户利用与授权一起被接收的配额来使用请求的服务直到已经分配了由在线计费系统授权的用于估计的数量的用户的总配额为止。

部件40-43可包括用于接收和提供信息的通信接口并且进一步包括用于存储数据的本地存储设备，并且可以（与先前讨论的类比）通过以布置成执行计算机程序的一个或多个微处理器的形式体现的处理器来实现部件40-43，所述计算机程序被下载到与微处理器相关联的适合的存储介质，诸如ram、闪速存储器或硬盘驱动器。

上面已经参考一些实施例来主要描述了本发明。然而，正如本领域技术人员容易意识到的，正如由所附的专利权利要求所限定的，除了上面公开的实施例以外的其它实施例同样可能在本发明的范围内。