计费的方法及系统和计费设备、关联决策设备和网络设备

摘要

本发明公开了计费的方法及系统和计费设备、关联决策设备和网络设备。计费系统收到网元为用户提供子业务的计费请求时，通过分析用户的业务配置，计算出为所述用户提供业务的其他关联网元分配的服务配额，并对所述用户的账户进行统一预留，当所述统一预留失败，不会向所述用户提供业务。避免了现有技术中，网元针对自身提供的业务孤立的计费，一些网元为用户提供子业务，用户账户预留成功之后，有其他网元请求为所述用于提供子业务时用户账户预留失败，导致服务交付的整体失败并且造成资源浪费；并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，对复杂业务计费的过程更加合理。

说明书

技术领域

本发明涉及通信技术领域，具体涉及计费的方法及系统和计费设备、关联决策设备和网络设备。

背景技术

随着电信网络上的业务种类的不断丰富，业务的提供也变得也来越复杂。当前的业务往往都是融合了各种业务能力的复杂业务，计费已经不再像使用单一业务能力的“语音呼叫、短消息”那么简单，其中的每一种业务能力都需要由一个或者多个网元来提供。整个计费过程通常是在多个计费点上分散进行。尤其当前以及未来的网络都是采取分层的架构，使用一项服务，必定涉及到不同层次的网元，这些网元在服务递交的过程中，都需要从自身的角度对服务分别进行计费。

例如，彩信业务(MMS)在业务层采用按次计费。而当用户发送彩信时，同时也在网络承载层实体上产生了流量计费信息，承载计费功能单元(BearerCharging Function，BCF)通过从网关GPRS支持节点(GPRS Gateway SupportNode，GGSN)中采集到的该MMS实际发生的流量信息进行流量的计费。

现有技术中，为用户提供复杂业务的多点计费流程如下，具体包括：

101，网元1在接收到用户的业务请求后，发送信用控制请求(CreditControl Request，CCR)到在线计费系统(Online Charging System，OCS)。

网元(Network element，NE)是向用户提供各种业务的网络实体，针对提供的业务不同可以是不同的网络实体，如：网关GPRS支持节点(GPRSGateway Support Node，GGSN)，Web网关、彩信中心、视频服务器等。在本流程中网元1和网元2分别指一个网元与另外一个网元，两个网元互相配合提供复杂业务，两个网元各自向用户提供复杂业务的子业务。

OCS，用于对服务的使用执行在线计费，实时影响服务的提供。

102，OCS对用户进行账户余额预留。

103、OCS向网元1返回信用控制应答(Credit Control Answer，CCA)，其中包含授予的配额。

104，网元1向用户进行子业务的交付。

105，网元2在接收到所述用户服务请求后，发送CCR到OCS。

106，OCS对用户进行账户余额预留。

107，OCS向网元2返回CCA，其中包含授予的配额。

108，网元2向用户进行子业务的交付。

上述网元1和网元2都同意向用户提供子业务后，用户则可以使用此复杂业务，本流程图中仅用两个网元来代表多个网元，实际情况可能是更多个网元共同完成对用户提供一项复杂业务。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

多个网元共同提供一项复杂业务时，多个网元孤立地在线计费，若计费系统为其中一个网元提供子业务时用户账户预留失败，则会导致复杂业务交付的整体失败，而其他网元即使已经预留成功，也是无效的计费操作无法完成该复杂业务的提供，造成资源的浪费，并且由于涉及的多个网元独立完成计费操作，一旦业务失败进行计费清理的过程占用的网络资源也较大，加大了网络负荷。

发明内容

本发明实施例解决的技术问题是提供计费的方法及系统和计费设备、关联决策设备和网络设备，可以实现对复杂业务的统一计费，使计费的过程更加合理。

本发明实施例提供的一种计费的方法，包括：

计费系统接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述计费系统查找所述关联标识对应的关联数据；若未查找到对应的关联数据，则所述计费系统根据所述定购关系标识和所述全局业务标识查找所述用户定购的全局业务下的所有子业务；

所述计费系统为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留。

本发明实施例提供的一种计费的方法，包括：

计费系统接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述计费系统查找所述关联标识对应的关联数据；若未查找到对应的关联数据，则所述计费系统根据所述定购关系标识和所述全局业务标识查找所述用户定购的全局业务下的所有子业务；

所述计费系统为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留。

本发明实施例提供的一种在线计费设备，包括：计费请求接收单元，关联数据查找单元、计费处理单元、关联数据存储单元、和计费应答单元；

所述计费请求接收单元，用于接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述关联数据查找单元，用于在所述关联数据存储单元中查找所述关联标识对应的关联数据，若未查找到所述关联标识对应的关联数据，则请求计费处理单元进行计费处理；

计费处理单元，用于接收所述关联数据查找单元的通知，向关联决策设备发送计费关联请求；在收到关联决策设备返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留。

本发明实施例提供的一种关联决策设备，包括：计费关联请求接收单元、子业务查找单元；

计费关联请求接收单元，用于接收所述在线计费设备的计费关联请求；

子业务查找单元，用于根据所述计费关联请求中的定购关系标识和所述全局业务标识在业务配置库中查找所述用户定购的全局业务下的所有子业务；并通过计费关联请求响应并将所述查找到的所有子业务信息返回给在线计费设备。

本发明实施例提供的一种网络设备，包括：业务请求接收单元和计费触发功能单元；

业务请求接收单元，用于接收用户的业务请求；

所述计费触发功能单元，用于在所述业务请求接收单元收到用户的业务请求后，生成包含关联标识、全局业务标识和所述用户的定购关系标识的计费请求消息并发送到计费系统。

本发明实施例提供的一种计费系统，包括：在线计费设备、关联决策设备给和业务配置库；

在线计费设备，用于接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；查找所述关联标识对应的关联数据，若未查找到所述关联标识对应的关联数据，则向关联决策设备发送计费关联请求；在收到关联决策设备返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；

所述关联决策设备，用于接收所述在线计费设备的计费关联请求，并根据用户的定购关系标识和所述全局业务标识在业务配置库中查找所述用户定购的全局业务下的所有子业务；并通过计费关联响应将所述查找到的所有子业务信息返回。

所述业务配置库，用于存储用户定购的全局业务和子业务之间的对应关系。

本发明实施例提供的一种计费系统，包括：在线计费设备、关联决策设备和业务配置库；

所述在线计费设备，用于接收网元发送的为用户提供全局业务的初始计费请求，所述初始计费请求包括全局业务标识和所述用户的定购关系标识；向关联决策设备发送计费关联请求；在收到关联决策设备返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；

所述关联决策设备，用于接收所述在线计费设备的计费关联请求，并根据用户的定购关系标识和所述全局业务标识在业务配置库中查找所述用户定购的全局业务下的所有子业务；并通过计费关联响应将所述查找到的所有子业务信息返回。

所述业务配置库，用于存储用户定购的全局业务和子业务之间的对应关系。

采用上述技术方案，本发明实施例有益的技术效果在于：

本发明实施例通过计费系统收到网元为用户提供子业务的计费请求时，计费系统通过分析用户的业务配置，计算出提供业务的其他关联网元分配的服务配额，并对所述用户的账户进行统一预留，相对于现有技术中，为用户提供复杂业务的子业务的各个网元针对自身提供的业务孤立的计费，避免了在计费的过程中，一些网元为用户提供子业务，用户账户预留成功之后，有网元请求为所述用于提供子业务时用户账户预留失败，则导致服务交付的整体失败的情况，造成资源浪费的情况；并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，使对复杂业务计费的过程更加合理。

附图说明

图1是现有技术为用户提供复杂业务的多点计费的流程图；

图2是本发明实施例一计费的方法的流程图；

图3是本发明实施例二计费的方法的流程图；

图4是本发明实施例三计费的方法的流程图；

图5是本发明实施例四计费的方法的流程图；

图6是本发明实施例五在线计费设备的结构示意图；

图7是本发明实施例六在线计费设备的结构示意图；

图8是本发明实施例七关联决策设备的结构示意图；

图9是本发明实施例八网络设备的结构示意图；

图10是本发明实施例九计费系统的结构示意图；

图11是本发明实施例十计费系统的结构示意图。

具体实施方式

本发明实施例提供了计费的方法及系统和计费设备、关联决策设备和网络设备，应用于通信技术领域，下面对本发明提供的计费的方法及系统和计费设备、关联决策设备和网络设备进行详细描述。

实施例一，一种计费的方法，流程图如图2所示，包括：

201，计费系统接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识(Correlation ID)、全局业务标识(Global ServiceID)和所述用户的定购关系标识(Subscription ID)；

所述初始计费请求消息可以是信用控制请求消息(Credit Control Request，CCR)，还可以是其他可以承载计费请求的消息，具体的消息格式和消息类型不构成对本发明的限制。

本实施例中，所述全局业务标识可以是高层业务计费请求中的Service ID也可以是业务数据流相关的高层业务标识(Related Service ID)，在业务配置库中，全局业务标识唯一标识一个全局业务，该全局业务下的各子业务配合为用户提供复杂业务。

可以理解的是，本实施例中，所述初始计费请求还包括请求为用户提供的子业务标识(service ID)和质量参数(Qos)等常规参数；子业务标识用于标识所述网元请求为所述用户提供的子业务。

202，所述计费系统查找所述关联标识对应的关联数据；若查找，则继续步骤203，若未查找到，则继续步骤204；

所述关联标识是在用户使用业务时，信令经过的第一网元会产生一个专门用于计费关联的关联标识，在后续的为用户提供服务的各个网元进行控制信令传输过程中，此关联标识被传输到为用户提供业务的其他网元。本实施例中，计费系统可以通过这个关联标识判断来自网元的计费请求的子业务是否属于同一个为用户提供的全局业务。

203，在关联数据中查找该网元为所述用户提供的子业务对应的服务配额并将查找到的服务配额向该网元下发。

各个子业务对应的服务配额可以以表格的形式存储也可以以数组的形式存储，具体的存储形式不构成对本发明的限制。

204，所述计费系统根据所述定购关系标识和所述全局业务标识查找所述用户定购的全局业务下的所有子业务；

本实施例中，所述查找用户定购的全局业务下的子业务可以通过列表的形式查找，并且本发明提供业务配置库对用户的定购关系标识、全局服务标识子服务标识的对应关系进行存储。

请参阅表1是本发明实施例定购关系标识、全局业务标识和子业务的对应列表的一个举例：

表1

可以理解的是，上述列表还可以添加每个子业务所需的服务质量(QoS)参数。

205，所述计费系统为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若预留成功则继续步骤206；若预留失败，则继续步骤208。

本步骤，所述计费系统为所述全局业务下的所有子业务分配服务配额可以根据现有的常规方式进行分配，可以理解的是，所述业务配置库中可以保存各个子业务对应的服务质量(QoS)参数，所述计费系统可以根据所述服务质量参数进行配额的分配。

206，计费系统将所述为各个子业务分配的服务配额保存为所述关联标识的关联数据。

本实施例中，所述关联标识与为各个子业务分配的服务配额的对应关系参见表2。

表2

  Correlation ID

  Session ID 1  ServiceID 1  RSU1  Service ID 2  RSU2  Service ID 3  RSU3

表2中，请求的服务单元(Requested Service Units，RSU1)表示为ServiceID 1分配的配额、RSU2表示为Service ID 2分配的配额、RSU3表示为Service ID 3分配的配额，Session ID 1标识所述网元与计费系统之间的信控会话。

207，所述计费系统向所述网元发送计费应答，所述计费应答中包含所述网元为所述用户提供的子业务对应的分配的服务配额。

本实施例，步骤206与步骤207并无绝对顺序，也可以先执行步骤207再执行步骤206。

208，计费系统通知所述网元计费失败。

本实施例中，在步骤208之后可以包括：若计费系统收到为所述用户提供子业务服务的所有网元反馈的包含计费成功标识的计费终结消息；则计费系统对所述用户账户执行扣费。

所述计费系统可以向所述网元返回信用控制应答(Credit ControlAnswer，CCA)消息，所述CCA消息中包含指示计费失败的标识。可以理解的是，所述计费系统还可以向所述网元返回其他消息指示计费失败，具体的消息格式和消息类型不构成对本发明的限制。

本发明实施例一通过计费系统收到网元为用户提供子业务的计费请求时，计费系统通过分析用户的业务配置，计算出提供业务的其他网元分配的服务配额，并对所述用户的账户进行统一预留。相对于现有技术中，为用户提供复杂业务的子业务的各个网元针对自身提供的业务孤立的计费，避免了在计费的过程中，一些网元为用户提供子业务时，用户账户预留成功之后，有网元请求为所述用于提供子业务时用户账户预留失败，则导致服务交付的整体失败的情况，造成资源浪费的情况，并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，使对复杂业务计费的过程更加合理。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

计费系统接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述计费系统查找所述关联标识对应的关联数据；若未查找到对应的关联数据，则所述计费系统根据所述定购关系标识和所述全局业务标识查找所述用户定购的全局业务下的所有子业务；

所述计费系统为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；

若预留成功，则计费系统将所述为各个子业务分配的服务配额保存为所述关联标识的关联数据。

若预留失败，则计费系统通知所述网元计费失败。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

实施例二，一种计费的方法，流程图如图3所示，包括：

的步骤301至步骤304和实施例一的步骤201至步骤204相同，不再赘述。

305，判断所述用户定购的全局业务下的子业务是否大于一项；若是，则继续步骤307，若否，则继续步骤306。

若所述全局业务下的子业务只有一项，则很容易理解，本次用户请求的业务只有一个网元为所述用户提供，那么采用常规的孤立计费的方式即可。

306，直接对所述网元的请求的为所述用户提供的子业务进行普通计费处理。

本实施例，对所述网元请求的为所述用户提供子业务采用常规的普通计费方式，具体的方式本发明不再赘述。

步骤307至步骤310与实施例一步骤205至步骤208相同。

本实施例中，在步骤310之后可以包括：若计费系统若计费系统收到为所述用户提供子业务服务的所有网元反馈的包含计费成功标识的计费终结消息；则计费系统对所述用户账户执行扣费。

实施例二与实施例一的区别在于，对于全局业务下的子业务项数进行判断，若所述全局业务下的子业务仅有一项，则可以采取现有的普通计费方式进行计费处理。

本发明实施例一步骤205与实施例二步骤307中，计费系统为所述全局业务下的所有子业务分配服务配额是根据为所述用户提供的所述全局业务所需各子业务的服务配额的比例关系进行分配。因为一项全局业务对该全局业务下为用户提供子业务的服务配额之间有一定的比例约束关系，根据为所述用户提供的所述全局业务所需各子业务的服务配额的比例关系进行分配，与现有技术相比，由于现有技术中多网元分别在线计费，预留的配额之间没有相互约束，导致不同网元预留的配额有效性不一致；很可能给一个网元的分配的配额已经用完，而给另一个网元的分配的配额还剩余很多，因此根据各个子业务所需的服务配额按相互的比例关系分配可以提高用户帐户预留的有效性。

下面进行举例说明：

一、对于事件型全局业务：

因为流量通过承载层网元时，经过七层过滤，能够识别出业务类型以及内容；承载层请求的的RSU直接由承载层网元在向计费系统发送的CCR中给出，如：以时间计算，则是用户发送数据所用的时间；如以流量计算，则是用户发送的数据量；计费系统根据所述CCR中的全局业务标识，找到对应的业务配置，如果业务配置中显示需要对业务计费，则根据业务需要，预留业务层的配额Y(单位：条，次等)；如果业务配置中显示需要对内容计费，则预留内容层的配额Z(单位：条，次等)；

需预留的配额RSU_Total＝RSU_内容层+RSU_业务层+RSU_承载；

以表1中的全局业务标识为普通业务为例，用户发送一条消息，在经过GGSN时，基于流的计费技术中，“流量平面功能”使用计费策略对之过滤，识别出此数据流是一条消息，且整个消息造成的数据流量为1M，则需要在承载层预留1M数据流量的配额，同时需要在业务层预留“1条消息”的配额。

即，该全局业务，业务层预留1条消息的配额，则需要承载层预留1M数据流量的配额，或者承载层预留1M数据流量的配额，则需要业务层预留一条消息的配额。

二、对于会话型全局业务：

使用会话型服务之前，必须先建立一个会话。会话建立的过程中，协商各种业务相关的参数，包括媒体类型、QoS等，并根据这些参数建立会话。然后业务层的网元向OCS发送计费请求。

(1)OCS找出业务配置中高层(内容层/业务层)的子服务，根据OCS中的配置，计算高层业务需要预留的配额。

(2)OCS找出业务配置中低层(承载层)的子服务，根据媒体类型、QoS的参数与高层子业务的预留量，计算承载层子业务所述配额；

RSU_承载＝RSU_{内容层/业务层}*(Rate_media1+Rate_media2+Rate_meddia3+……)

公式中，Rate_media1、Rate_media2、Rate_media3等是业务层或内容层业务所需各种媒体的流量速率。

需预留的配额RSUTotal＝RSU内容层+RSU业务层+RSU承载

以表1中的全局业务为多媒体会话为例，用户A与另外一个用户之间开始了一个会话，其中的媒体流包括一个音频流与一个视频流，假如在业务层预留了12秒的配额，那么参照在承载层预留资源的媒体类型以及QoS参数，也必须预留相对应的流量：为音频预留的资源为40kb/s，需要预留0.04*120＝4.8M；为视频预留的资源为120kb/s，需要预留0.12*120＝14.4M。

依据上述的举例，所述计费系统为所述全局业务下的所有子业务分配服务配额后，则根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；

计费系统内的批价单元对为所述子业务分配的配额(RSU1，RSU2...)进行分别批价，并且计算出此次服务的整体费用。

以表1中的全局业务为普通消息为例，承载的费用1*0.1＝0.1元，业务层的费用为1*0.5＝0.5元。预留总金额：0.1+0.5＝0.6元

以表1中的全局业务为多媒体会话为例，业务层费用为0.2*2＝0.4元，音频的承载费用为0.08*4.8＝0.384元，视频的承载费用为0.05*14.4＝0.72元。预留总金额：0.2*2+0.08*4.8+0.05*14.4＝1.5元。

可以理解的是，如果账户余额不能满足以上预留，计费系统还可以缩小预留的服务单元数，对预留的配额进行调整，调整的原则是：

RSU_内容层*T_内容层+RSU_业务层*T_业务层+RSU_承载*T_承载＜＝B

RSU表示预留的服务单元数，T表示费率，B代表账户余额。

可以理解的是，计费系统对用户账户进行统一账户余额预留控制，具体的预留方式还可以采用现有的多种常规方式，并且根据实际的计费情况和应用环境该面，上述分配配额和账户预留的方式不构成对本发明的限制。

实施例三，是在实施例一或实施例二的基础上的计费更新流程，流程图如图4所示，在上述实施例一和实施例二的基础上，可以进一步包括：

步骤401，将为用户提供子业务的各个网元与计费系统之间的信控会话标识建立关联；所述建立信控会话的关联可以直接将各个信控会话的标识建立在关联标识的关联数据表中，如表3所示：

表3

  Correlation Id 1  Session Id 1  Session Id 2  Service Id 1  RSU1  ServiceId2  RSU2  Service Id3  RSU3

上述的Session1和Session2分别为信控会话标识，通过表3可以得到与一个信控会话标识相关联的其他信控会话标识。可以理解的是，所述信控会话标识的关联关系也可以单独保存。

本实施例中信控会话标识是用于标识计费系统和网元之间的会话，通过信控会话标识可以很容易找到与计费系统建立会话的网元。

402，某一个所述用户提供子业务服务的网元向计费系统请求计费更新；所述计费更新请求包括已经使用的服务配额。

本实施例中，所述网元可以向计费系统发送CCR消息，所述CCR消息包含更新(Update)标识，指示本消息是请求更新的。

403，计费系统获取与所述请求计费更新的网元之间的信控会话标识相关联的其他信控会话标识；可以理解的是，本实施例的计费更新请求还可以通过其他消息承载，具体的消息格式和消息类型不构成对本发明的限制。

404，计费系统通知所述相关联的其他信控会话标识对应的网元要对其重新授权。

本实施例中，所述通知网元进行重新授权可以是计费系统向所述各个网元发送重授权请求(Re-authorization Request，RAR)消息，可以理解的是，本实施例的重授权请求还可以通过其他消息承载，具体的消息格式和消息类型不构成对本发明的限制。

405，所述其他信控会话标识对应的网元向所述计费系统请求计费更新请求；所述计费更新请求中包括已经使用的服务配额；

406，所述计费系统对为所述用户提供的子业务重新分配服务配额，并对所述用户的账户重新预留；若所述重新预留成功，则继续步骤407，若所述重新预留失败，则继续步骤408。

407，所述计费系统所述保存的关联数据中所述各个子业务对应的为该子业务重新分配的服务配额；并将所述为各个子业务重新分配的服务配额下发给所述为用户提供对应子业务的网元。

408，向请求计费更新的各个网元返回计费失败的结果。

本发明实施例三，在实施例一和实施例二的基础上，实现对为所述用户提供子业务网元的统一计费更新，相对于现有技术的各个网元孤立的计费更新，避免了在计费更新的过程中，一些网元为用户提供子业务更新成功后，有网元请求为所述用户提供的子业务的计费更新失败，导致全局业务交付失败的情况，造成资源浪费，并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，使对复杂业务计费的过程更加合理，使本发明实施例提供的计费方法更加完整。

实施例四，一种计费的方法，流程图如图5所示，包括：

501，计费系统接收网元发送的为用户提供全局业务的初始计费请求，所述初始计费请求包括关联标识、全局业务标识和所述用户的定购关系标识；

502，所述计费系统根据所述定购关系标识和所述全局业务标识查找所述用户定购的全局业务下的所有子业务；

503，所述计费系统为所述全局业务下的所有子业务分配服务配额；

所述计费系统为所述全局业务下的所有子业务分配服务配额是根据为所述用户提供的所述全局业务所需各子业务的服务配额的比例关系进行分配。

504，所述计费系统根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若预留失败则继续步骤505，若预留成功，则继续步骤506。

505，则通知所述网元计费失败，拒绝向所述用户提供所述全局业务。

506，保存所述全局业务标识对应的各个子业务与为该子业务分配的服务配额作为所述关联标识的关联数据保存。

507，若所述计费系统收到网元发送的为用户提供子业务的初始计费请求，所述计费请求中包含所述关联标识；则在所述关联标识对应的关联数据中查找所述网元为所述用户提供的子业务对应的服务配额，并向该网元下发所述服务配额。

可以理解的是，在步骤502之后可以进一步判断所述用户定购的全局业务下的所述子业务是否大于一项；若是，则继续步骤503，若否，则直接对所述网元的请求的为所述用户提供的子业务进行计费处理。

本发明实施例四与实施例一的区别在于，本实施例中，网元直接向计费系统请求全局业务计费，若计费成功，则计费系统保存为用户提供子业务的对应分配的配额，当计费系统收到为用户提供子业务的网元的计费请求时，则将对应的子业务分配的配额下发。

实施例五，一种在线计费设备600，结构示意图如图6所示，包括：

计费请求接收单元610，关联数据查找单元620、计费处理单元630、关联数据存储单元640和计费应答单元650；

所述计费请求接收单元610，用于接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述关联数据查找单元620，用于在所述关联数据存储单元640中查找所述关联标识对应的关联数据，若查找到所述关联标识对应的关联数据，则在所述关联数据中查找所述网元为用户提供的子业务对应的服务配额并通知计费应答单元650将所述查找到的服务配额通过下发给所述网元；若未查找到所述关联标识对应的关联数据，则请求计费处理单元630进行计费处理；

计费处理单元630，用于接收所述关联数据查找单元620的通知，向关联决策设备发送计费关联请求；在收到关联决策设备返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若预留成功，则将所述为各个子业务分配的服务配额作为为所述关联标识的关联数据保存在关联数据存储单元640并通知计费应答单元650将所述网元为所述用户提供的子业务对应的分配的服务配额下发给所述网元；若预留失败，则通知计费应答单元650向所述网元下发计费失败的结果；

关联数据存储单元640，用于存储关联标识对应的关联数据；

所述计费应答单元650，用于向所述网元下发计费应答。

实施例六，一种在线计费设备700，结构示意图如图7所示，包括：

计费请求接收单元710，关联数据查找单元720、计费处理单元730、关联数据存储单元740和计费应答单元750；会话关联建立单元760，会话关联存储单元770，计费更新单元780；

所述计费请求接收单元710，用于接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；

所述关联数据查找单元720，用于在所述关联数据存储单元740中查找所述关联标识对应的关联数据，若查找到所述关联标识对应的关联数据，则在所述关联数据中查找所述网元为用户提供的子业务对应的服务配额并通知计费应答单元750将所述查找到的服务配额通过下发给所述网元；若未查找到所述关联标识对应的关联数据，则请求计费处理单元730进行计费处理；

计费处理单元730，用于接收所述关联数据查找单元720的通知，向关联决策设备发送计费关联请求；在收到关联决策设备返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若预留成功，则将所述为各个子业务分配的服务配额作为为所述关联标识的关联数据保存在关联数据存储单元740并通知计费应答单元750将所述网元为所述用户提供的子业务对应的分配的服务配额下发给所述网元；若预留失败，则通知计费应答单元750向所述网元下发计费失败的结果；

可以理解的是，所述计费处理单元还可以在收到关联决策设备返回的进行普通计费的通知后，对所述网元发送的为所述用户提供子业务进行普通计费。

关联数据存储单元740，用于存储关联标识对应的关联数据；

所述计费应答单元750，用于向所述网元下发计费应答

所述会话关联建立单元760，用于将为用户提供子业务服务的各个网元与计费系统之间的信控会话标识建立关联；

所述会话关联存储单元770，用于存储所述信控会话标识的之间关联关系；

计费更新单元780；用于在计费请求接收单元收到某一个为所述用户服务的网元的计费更新请求时，在所述会话关联存储单元760中查找计费系统与所述网元之间的信控会话标识相关联的其他信控会话标识；并通知所述计费处理单元730，对所述网元为用户提供的子业务和所述查找到的信控会话标识对应的各个网元为用户提供的子业务重新分配服务配额，并对所述用户的账户进行统一预留。

实施例七，一种关联决策设备800，结构示意图如图8所示，包括：计费关联请求接收单元810、子业务查找单元820；

计费关联请求接收单元810，用于接收所述在线计费设备的计费关联请求；

子业务查找单元820，用于根据所述计费关联请求中的定购关系标识和所述全局业务标识在业务配置库中查找所述用户定购的全局业务下的所有子业务；并通过计费关联响应将所述查找到的所有子业务信息返回给在线计费设备。

可以理解的是，该设备还可以包括：关联判断单元，用于判断所述用户的业务定购关系中所述全局业务下是否只对应一项子业务，若是，则通过计费关联响应通知所述在线计费设备对所述网元的计费请求进行普通计费；若否则通知所述子业务查找单元将所述查找到的所有子业务信息返回给在线计费设备。

实施例八，一种网络设备900，结构示意图如图9所示，包括：业务请求接收单元910和计费触发功能单元920；

业务请求接收单元910，用于接收用户的业务请求；

所述计费触发功能单元920，用于在所述业务请求接收单元收到用户的业务请求后，生成包含关联标识、全局业务标识和所述用户的定购关系标识的计费请求消息并发送到计费系统。

实施例九，一种计费系统1000，系统结构示意图如图10所示，包括：在线计费设备1010、关联决策设备1020给和业务配置库1030；

在线计费设备1010，用于接收网元发送的为用户提供子业务的初始计费请求；所述初始计费请求包含关联标识、全局业务标识和所述用户的定购关系标识；查找所述关联标识对应的关联数据，若查找到所述关联标识对应的关联数据，则在所述关联数据中查找所述网元为用户提供的子业务对应的服务配额并将所述查找到的服务配额下发给该网元；若未查找到所述关联标识对应的关联数据，则向关联决策设备1020发送计费关联请求；在收到关联决策设备1020返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；并根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若预留成功，则将所述为各个子业务分配的服务配额保存为所述关联标识的关联数据；若所述预留失败，则通知所述网元计费失败；

所述关联决策设备1020，用于接收所述在线计费设备1010的计费关联请求，并根据用户的定购关系标识和所述全局业务标识在业务配置库1030中查找所述用户定购的全局业务下的所有子业务；并通过计费关联响应将所述查找到的所有子业务信息返回。

所述业务配置库1030，用于存储用户定购的全局业务和子业务之间的对应关系。

实施例十，一种计费系统1100，系统结构示意图如图11所示，包括：在线计费设备1110、关联决策设备1120和业务配置库1130；

所述在线计费设备1110，用于接收网元发送的为用户提供全局业务的初始计费请求，所述初始计费请求包括全局业务标识和所述用户的定购关系标识；向关联决策设备1120发送计费关联请求；在收到关联决策设备1120返回的包含所有子业务信息的计费关联响应后，为所述全局业务下的所有子业务分配服务配额；根据所述为各个子业务分配的配额对所述用户的账户进行统一预留；若所述预留失败，则通知所述网元计费失败，若所述预留成功，则通知所述网元计费成功；并将所述为各个子业务分配的服务配额保存为所述关联标识的关联数据；当收到网元发送的为用户提供子业务的初始计费请求，则在所述关联数据中查找所述网元为所述用户提供的子业务对应的服务配额，并向该网元下发所述服务配额。

所述关联决策设备1120，用于接收所述在线计费设备1110的计费关联请求，并根据用户的定购关系标识和所述全局业务标识在业务配置库1130中查找所述用户定购的全局业务下的所有子业务；并通过计费关联响应将所述查找到的所有子业务信息返回。

所述业务配置库1130，用于存储用户定购的全局业务和子业务之间的对应关系。

以上对本发明所提供的一种计费的方法及系统和计费设备、关联决策设备和网络设备进行了详细介绍，在线统一计费是非常重要的一种计费能力，能为运营商开展更加个性化的业务提供计费能力的支持：

首先，本发明实施例通过计费系统收到网元为用户提供子业务的计费请求时，计费系统通过分析用户的业务配置，计算出提供业务的其他网元分配的服务配额，并对所述用户的账户进行统一预留，当所述统一预留失败，不会向所述用户提供业务。相对于现有技术中，为用户提供复杂业务的子业务的各个网元针对自身提供的业务孤立的计费，避免了在计费的过程中，一些网元为用户提供子业务时，用户账户预留成功之后，有网元请求为所述用于提供子业务时用户账户预留失败，则导致服务交付的整体失败的情况，造成资源浪费的情况，并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，使对复杂业务计费的过程更加合理。

其次，本发明实施例计费系统为所述全局业务下的所有子业务分配服务配额是根据为所述用户提供的所述全局业务所需各子业务的服务配额的比例关系进行分配。因为一项全局业务对该全局业务下为用户提供子业务的服务配额之间有一定的比例约束关系，根据为所述用户提供的所述全局业务所需各子业务的服务配额的比例关系进行分配，与现有技术相比，由于现有技术中多网元分别在线计费，预留的配额之间没有相互约束，导致不同网元预留的配额有效性不一致；很可能给一个网元的分配的配额已经用完，而给另一个网元的分配的配额还剩余很多，因此根据各个子业务所需的服务配额按相互的比例关系分配可以提高用户帐户预留的有效性。

并且，本发明实施例在统一计费的基础上实现对为用户提供子业务网元的统一计费更新，相对于现有技术的各个网元孤立的计费更新，避免了在计费更新的过程中，一些网元为用户提供子业务更新成功后，有网元请求为所述用户提供的子业务的计费更新失败，导致全局业务交付失败的情况，造成资源浪费，并且有效的减少了现有技术中由于一旦业务失败造成的计费清理操作，节省了对网络资源的占用，降低了网络负荷，使对复杂业务计费的过程更加合理，使本发明实施例提供的计费方法更加完整。

而且，本发明实施例中，网元直接向计费系统请求全局业务计费，若计费成功，则计费系统保存为用户提供子业务的对应分配的配额，当计费系统收到为用户提供子业务的网元的计费请求时，则将对应的子业务分配的配额下发。

对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。