CN103490908B - 策略和计费规则功能的选择方法、装置及*** - Google Patents

Abstract

本发明公开了一种策略和计费规则功能（PCRF）的选择方法、装置及***，该方法包括以下步骤：Diameter路由代理（DRA）接收为用户组中第一用户服务的PCRF发送的该用户组的用户组信息；DRA根据该用户组信息和上述PCRF的地址信息，为该用户组内的其他用户选择上述PCRF。通过本发明，解决了相关技术中用量监控机制无法实现家庭用户组的用量监控需求的问题，保证了为用户组内的用户选择一个统一的PCRF来管理用户组的用量，提高了***的可操作性。

Description

策略和计费规则功能的选择方法、装置及***

技术领域

本发明涉及通信领域，具体而言，涉及一种策略和计费规则功能（Policy andCharging Rules Function，简称为PCRF）的选择方法、装置及***。

背景技术

第三代合作伙伴计划（3rd Generation Partnership Project，简称为3GPP）定义了针对移动网络的策略和计费控制（Policy and Charging Control，简称为PCC）架构，图1是根据相关技术的3GPP PCC架构示意图，如图1所示，各功能如下描述：

PCRF，用于业务包含的业务数据流在传输过程中使用网络资源制定资源控制策略，包括服务质量（Quality of Service，简称为QoS）控制策略和计费控制策略。

策略和计费执行功能（Policy and Charging Enforcement Function，简称为PCEF），用于执行PCRF下发的或者PCEF上预配置的PCC规则，对网络上传输的IP报文进行检测，识别该IP报文隶属的业务数据流，并对业务数据流提供QoS和计费控制。

承载绑定和事件上报功能（Bearer Binding and Event Report Function，简称为BBERF），主要用于对网络上传输的网络协议（Internet Protocol，简称为IP）报文进行检测，并将IP报文按照规则映射到对应的承载通道上。BBERF还执行承载相关事件的上报，例如，当承载丢失，或者发生接入网络切换的时候，都需要将相应的事件上报给PCRF，请求PCRF进行相应的决策。

用户签约数据库（Subscription Profile Repository，简称为SPR），用于保存用户签约的业务信息，为PCRF制订PCC规则提供必要的用户签约信息。

在线计费***（Online Charging System，简称为OCS）和离线计费***（OfflineCharging System，简称为OFCS），分别用于离线和在线计费。

在用户开展业务过程中，PCC按照如下原理为业务（由若干业务数据流组成）在传输过程中动态提供QoS保证：

首先，业务包含的每个业务数据流都对应一个具体的PCC规则，PCC规则中定义了该业务数据流传输时需要使用的QoS资源。在业务数据流在承载网络中传输之前，PCRF需要根据各种信息为业务数据流决策并制定PCC规则。PCRF决策并制定PCC规则所依据的信息包括：

（1）从AF接收的业务协商信息。该业务协商信息就是用户开展业务时和通信对端协商的开展所述业务的信息，例如，开展所述业务对QoS的要求、通信双方使用的IP地址、端口号、所使用的协议等信息。

（2）从SPR接收的用户签约信息。例如，用户签约信息中包含用户和运营商签约的QoS信息；用户开展业务时，业务对QoS的要求不能超过用户签约信息所规定的用户可以使用的QoS信息。

（3）PCRF自身存储的运营商自定义策略。例如运营商对漫游用户和非漫游用户开展业务需要区分控制，这种运营商自行定义的区分控制策略可以配置在PCRF上。

（4）从PCEF或者BBERF上接收的接入相关信息。例如，用户附着到网络时，PCRF需要通过PCEF或者BBERF获取用户接入网络的信息，以供PCRF为用户开展业务进行策略决策。

（5）从OCS获取用户的信用信息。例如，一旦用户的信用用完或者不够时，PCRF就无法授权所述用户开展业务。

其次，PCRF根据上述信息对业务数据流决策制定PCC规则，并将PCC规则下发给PCEF（如果网络中存在BBERF，则PCRF还需要制定QoS规则，并下发给BBERF）。PCEF需要根据PCC规则的QoS要求建立相应的承载，并将PCC规则绑定到对应的承载上（如果网络中存在BBERF，则由BBERF根据QoS规则建立承载）。如果网络中已经有和PCC规则或者QoS规则指示的QoS相匹配的承载，则将所述PCC规则或者QoS规则绑定到已有的承载上。

此后，当用户开展业务，业务数据流在承载网络上传输的时候，终端和网络设备可以根据五元组（由源IP地址、源端口号、目的IP地址、目的端口号、协议组成）将组成该业务数据流的IP报文匹配到相应的PCC规则/QoS规则，根据PCC规则/QoS规则和承载的绑定关系，就可以将所述业务数据流匹配到相应的承载上，从而为业务数据流在承载网络上的传输提供QoS保证。当用户开展的业务结束的时候，相应的PCC规则需要从承载网络上删除，即释放分配给所述业务使用的QoS资源。通过上述PCC机制一方面可以按照业务对QoS的需求分配相应的QoS资源，另一方面实现了需要QoS资源时就可以分配，不需要QoS资源时，就可以及时释放，因此通过PCC机制可以达到提升用户业务体验，提高网络资源使用效率的目的。

为了提高网络营运的灵活性，例如，对于某种业务，运营商希望前10M是供用户***的，当用户的用量超出10M之后，就需要收取费用；再比如，运营商希望给用户在10M的流量之内提供一种带宽，当流量超出10M之后需要对该用户的带宽进行限制。对于上述场景，要求在用户开展业务时，PCRF向PCEF下发针对业务的控制策略的同时，还需要下发用量监控，要求PCEF对所述业务的流量进行监控。当所述业务的流量达到监控所要求的阈值时，PCEF需要向PCRF上报用量监控结果，以便PCRF根据用量监控结果重新对所述业务进行策略决策，产生新的控制策略。

图2是根据相关技术的用量监控实现流程的示意图，如图2所示，用量监控的实现过程的流程如下：

步骤A1-A3，为PCRF向PCEF下发用量监控的过程。其中，业务由一个或者多个业务数据流构成，PCRF需要为每个业务数据流制定控制策略（PCC规则）并下发给PCEF，PCEF按照PCC规则对业务数据流实施QoS和计费控制。如果需要对该业务实施用量监控，则PCRF在下发PCC规则时，同时下发用量监控，所述用量监控由一个监控关键字（monitoring key）和阈值（threshold）组成，其中，需要对哪些业务数据流实施用量监控，就在描述业务数据流的PCC规则中包含所述monitoring key。PCRF将上述信息下发给PCEF，PCEF收到所述信息后对所述业务数据流实施用量监控。

例如，流程中需要实施用量监控的业务包含了业务数据流-1和业务数据流-2，则PCRF向PCEF下发用量监控的过程如步骤A1-A2描述：

步骤A1.PCRF为所述业务进行策略决策，产生控制策略（PCC规则），同时需要为所述业务实施用量监控，则PCRF分配监控关键字monitoring key，并包含在PCC规则-1和PCC规则-2中，同时为所述monitoring key根据用户的签约用量分配阈值threshold，并将所述monitoring key和threshold包含在用量监控信息（Usage Monitoring Information）中。

步骤A2.PCRF向PCEF下发控制策略，包含PCC规则-1、PCC规则-2和用量监控信息。

步骤B，当PCEF收到PCRF下发的控制策略后，安装PCC规则，并按照用量监控信息，对PCC规则对应的业务数据流（即业务数据流1和业务数据流2）实施用量监控。

步骤C，用量监控上报。当PCEF对该Monitoring Key监控的累计用量达到对应的所述阈值时，或者PCRF要求上报用量监控时，PCEF上报用量监控。上报的用量监控信息（UsageMonitoring Information）中包含所述Monitoring Key以及累计使用用量。

步骤D，根据用量监控上报结果，PCRF对所述业务数据流重新制定控制策略。例如，累计流量已经超出规定的流量，PCRF需要对所述业务的使用带宽进行降低。同时，如果还需要对所述业务继续执行用量监控，则PCRF需要为所述monitoring key根据用户签约用量重新分配阈值。当所述用户的累计用量已经到达所述签约用量时，就无法对所述用户继续实施用量监控。

步骤E，PCRF向PCEF下发针对该业务的新的控制策略。如果需要继续对所述业务实施用量控制，则下发的所述信息中还需要包含用量监控信息。

上述流程描述的是对单个业务实施用量监控。如果需要对用户开展的多个或者所有业务实施用量监控，则需要在对应业务数据流的PCC规则中包含监控关键字monitoringkey即可。

可见，现有技术描述的签约用量针对单个用户，即仅能实现对单个用户实施用量监控。然而，在实际运营过程中，还会出现多个用户共享签约用量的需求，例如，一个家庭签约一个用量套餐500M，该家庭签约用量被家庭所有成员所共享。对于如上述家庭用户组的用量监控需求，利用现有用量监控机制无法实现。

针对相关技术中用户监控机制无法实现家庭用户组的用量监控需求的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种PCRF的选择方案，以至少解决上述相关技术中用户监控机制无法实现家庭用户组的用量监控需求的问题。

根据本发明的一个方面，提供了一种PCRF的选择方法，包括以下步骤：DRA接收为用户组中第一用户服务的PCRF发送的该用户组的用户组信息；DRA根据该用户组信息和上述PCRF的地址信息，为该用户组内的其他用户选择上述PCRF。

优选地，DRA接收PCRF发送的上述用户组信息之前，该方法还包括：PCRF将上述用户组信息直接发送给DRA，或者PCRF将上述用户组信息发送给PCEF，由该PCEF将上述用户组信息发送给DRA，其中，上述用户组信息包括用户组标识和用户组中所有成员的用户标识。

优选地，PCRF将上述用户组信息发送给DRA之前，该方法还包括：PCRF根据第一用户的用户标识从SPR获取该用户组的用户组信息。

优选地，DRA为该用户组内的其他用户选择上述PCRF之前，该方法还包括：DRA接收PCRF发送的自身的地址信息。

优选地，DRA接收PCRF发送的该用户组的用户组信息之后，该方法还包括：DRA建立该用户组信息和上述PCRF的地址信息的对应关系。

优选地，上述第一用户为DRA首次建立上述对应关系时，PCRF所服务的用户。

优选地，DRA为该用户组内的其他用户选择PCRF包括：DRA判断为上述第一用户选择的PCRF与为上述第一用户所属用户组内其他用户选择的PCRF是否相同；如果不相同，则DRA通知PCEF重新为该用户组内的其他用户进行PCRF选择，其中，重新选择的PCRF是为上述第一用户服务的PCRF，该通知中包括为上述第一用户服务的PCRF的地址信息。

优选地，DRA通知PCEF重新为该用户组内的其他用户进行PCRF选择之后，该方法还包括：PCEF终止与原PCRF的IP-CAN会话，并建立与服务上述第一用户的PCRF之间的IP-CAN会话。

优选地，DRA为该用户组内的其他用户选择PCRF之后，该方法还包括：PCRF根据该用户组的签约用量信息为该用户组内的用户开展业务进行用量监控决策，并向PCEF下发用户监控。

根据本发明的另一方面，提供了一种PCRF的选择装置，位于DRA，该装置包括：接收模块，用于接收为用户组中第一用户服务的PCRF发送的该用户组的用户组信息；以及选择模块，用于根据接收模块接收到的该用户组信息和上述PCRF的地址信息，为该用户组内的其他用户选择上述PCRF。

优选地，该装置还包括：建立模块，用于建立上述用户组信息和上述PCRF的地址信息的对应关系。

优选地，该装置还包括：判断模块，用于判断为上述第一用户选择的PCRF与为该用户组内其他用户选择的PCRF是否相同；以及处理模块，用于在判断模块判断为上述第一用户选择的PCRF与为上述第一用户所属用户组内其他用户选择的PCRF不相同的情况下，通知PCEF重新为该用户组内的其他用户进行PCRF选择，其中，重新选择的PCRF是为上述第一用户服务的PCRF，该通知中包括为上述第一用户服务的PCRF的地址信息。

根据本发明的再一方面，还提供了一种PCRF的选择***，包括PCRF、SPR和上述PCRF的选择装置位于的DRA，其中，PCRF包括：获取转发模块，用于从SPR获取第一用户所属的用户组的用户组信息，并将该用户组信息发送给DRA；SPR包括：查询下发模块，用于根据PCRF的指令查询并下发该用户组信息。

通过本发明，采用DRA为归属于同一用户组的用户选择相同的PCRF的方式，解决了相关技术中用量监控机制无法实现家庭用户组的用量监控需求的问题，保证了为用户组内的用户选择一个统一的PCRF来管理用户组的用量，提高了***的可操作性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术的3GPP PCC架构示意图；

图2是根据相关技术的用量监控实现流程的示意图；

图3是根据本发明实施例的PCRF的选择方法的流程图；

图4是根据本发明实施例的PCRF的选择装置的结构示意图；

图5是根据本发明优选实施例的PCRF的选择装置的结构示意图；

图6是根据本发明实施例的PCRF的选择***的结构示意图；

图7是本发明实施例二的选择PCRF的流程示意图；

图8是本发明实施例二的用户签约信息的示意图；

图9是本发明实施例二的用户组签约信息的示意图；

图10是本发明实施例三的选择PCRF的流程示意图；

图11是本发明实施例四的选择PCRF的流程示意图；

图12是本发明实施例五的PCRF对用户组进行用量监控的流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

根据本发明实施例，提供了一种PCRF的选择方法。图3是根据本发明实施例的PCRF的选择方法的流程图，如图3所示，该方法包括以下步骤：

步骤S302，DRA接收为用户组中第一用户服务的PCRF发送的该用户组的用户组信息；

步骤S304，DRA根据该用户组信息和上述PCRF的地址信息，为该用户组内的其他用户选择服务第一用户的PCRF。

通过上述步骤，采用DRA为归属于同一用户组的用户选择相同的PCRF的方式，解决了相关技术中用量监控机制无法实现家庭用户组的用量监控需求的问题，保证了为用户组内的用户选择一个统一的PCRF来管理用户组的用量，提高了***的可操作性。

例如，在DRA接收到用户的IP连接访问网络（IP-Connectivity Access Network，简称为IP-CAN）会话建立请求时，DRA需要选择一个PCRF进行服务。在实施过程中，方式一、DRA可以获取该用户所在的用户组信息，确定该用户所在的用户组中已有成员选择了PCRF，则DRA选择该PCRF发送该用户的IP-CAN会话建立请求；方式二、用户组中首次选择PCRF的用户在选择PCRF之后，在DRA中建立了该用户组和该PCRF的对应关系，则DRA根据该对应关系为该用户组内其他用户选择与该用户组对应的PCRF。即，DRA为归属于同一用户组的用户选择相同的PCRF。该方法可以保证DRA在收到同一用户组的用户的IP-CAN会话建立请求时，为同一用户组的用户选择同一PCRF，使PCRF对用户组的用量监控成为可能。

在实施过程中，DRA可以通过为用户组中第一用户服务的PCRF从SPR中获取第一用户所属的用户组标识。具体地，还可以有两种方法：（1）该PCRF从SPR中获取第一用户所属的用户组标识后，将用户组标识指示的用户组信息直接发送给DRA；（2）该PCRF从SPR中获取第一用户所属的用户组标识后，将用户组标识指示的用户组信息发送给与第一用户对应的PCEF，由该PCEF将该用户组信息转送给DRA。其中，上述用户组信息可以包括用户组标识和该用户组中所有成员的用户标识。

优选地，PCRF将用户组信息发送给DRA之前，PCRF根据第一用户的用户标识从SPR获取用户组的用户组信息。例如，DRA向与第一用户对应的PCEF返回为第一用户选择的PCRF的地址信息；PCEF接收PCRF的地址信息后，通过PCRF的地址信息指示的PCRF从SPR中获取第一用户所属的用户组信息，并将用户组信息发送给DRA。

优选地，步骤S302之后，DRA建立用户组信息和PCRF地址信息的对应关系。实施过程中，上述第一用户为DRA首次建立该对应关系时，PCRF所服务的用户。例如，用户组标识和PCRF地址的对应关系，其中，用户组中所有成员均对应同一PCRF。

优选地，在步骤S304之前，DRA接收到PCRF发送的用户组信息之外，还接收到PCRF发送的自身的地址信息。

此外，在步骤S304中，DRA还可以判断为第一用户选择的PRCF与为归属于同一用户组的第二用户选择的PRCF是否相同；如果不相同，则DRA通知PCEF重新为第二用户选择与第一用户相同的PCRF，在该通知中包括为第一用户服务的PCRF的地址信息。例如，DRA为第一用户服务的PCRF为PCRF1，则DRA为与第一用户归属相同用户组的第二用户也选择PCRF1进行服务。如果在判断之前，PCEF为第二用户选择PCRF2，则在判断不同之后，PCEF终止与原PCRF（PCRF2）的IP-CAN会话，并建立与PCRF1之间的IP-CAN会话。这样可以进一步地保证DRA为归属于同一用户组的用户选择相同的PCRF进行服务。

优选地，在步骤S304之后，PCRF根据用户组的签约用量信息为用户组内的用户开展业务进行用量监控决策，并向PCEF下发用户监控。通过本优选实施例，PCRF可以管理用户组的签约用量，从而实现了对用户组的用量监控需求。

对应于上述方法，本发明实施例还提供了一种PCRF的选择装置。图4是根据本发明实施例的PCRF的选择装置的结构示意图，如图4所示，该装置位于DRA，包括：接收模块42，用于接收为用户组中第一用户服务的PCRF发送的该用户组的用户组信息；以及选择模块44，耦合至接收模块42，用于根据接收模块42接收到的该用户组信息和上述PCRF的地址信息，为该用户组内的其他用户选择上述PCRF进行服务。

通过上述装置，选择模块44为归属于同一用户组的用户选择相同的PCRF，解决了相关技术中用量监控机制无法实现家庭用户组的用量监控需求的问题，保证了为用户组内的用户选择一个统一的PCRF来管理用户组的用量，提高了***的可操作性。

图5是根据本发明优选实施例的PCRF的选择装置的结构示意图，如图5所示，该装置还包括：建立模块52，用于建立第一用户所属用户组信息和上述PCRF的地址信息的对应关系。也即，在用户组中第一用户确定其选择的PCRF后，DRA建立为第一用户所属用户组与第一用户所选PCRF的对应关系，以便该用户组中其他用户选择与第一用户相同的PCRF进行服务。

优选地，该装置还包括：判断模块54，耦合至建立模块52，用于判断为第一用户选择的PCRF与为用户组内其他用户选择的PCRF是否相同；以及处理模块56，耦合至判断模块54和选择模块44，用于在判断模块54判断为第一用户选择的PCRF与为用户组内其他用户选择的PCRF不相同的情况下，通知PCEF重新为用户组内的其他用户进行PCRF选择，其中，重新选择的PCRF是为第一用户服务的PCRF，该通知中包括为第一用户服务的PCRF的地址信息。

根据本发明实施例，还提供了一种PCRF的选择***。图6是根据本发明实施例的PCRF的选择***的结构示意图，如图6所示，该***包括PCRF62、SPR64和上述PCRF的选择装置所处的DRA66，其中，PCRF62包括：获取转发模块622，耦合至接收模块42和选择模块44，用于从SPR64获取第一用户所属的用户组的用户组信息，并将该用户组信息发送给DRA66；SPR64包括：查询下发模块642，耦合至获取转发模块622，用于根据PCRF62的指令查询并下发该用户组信息。

下面结合优选实施例和附图对上述实施例的实现过程进行详细说明。

实施例一

由于用量监控决策在PCRF上实现，要实现对用户组的用量监控，需要由PCRF管理用户组的签约用量。然而，DRA根据用户标识等选择为用户接入服务的PCRF时，不同的用户接入网络，可能会选择不同的PCRF为其服务，这样无法利用现有用量监控机制实现对上述用户组的用量监控需求。所以，为了对共享签约用量的用户组的用量监控需求，本实施例给出了一种PCRF选择方法，以实现用户组用量监控的问题。

在实施过程中，本实施例的PCEF选择方法可以包括如下步骤：

步骤1，为用户组中第一用户接入服务的PCRF向Diameter路由代理（DiameterRouting Agent，简称为DRA)发送该用户所属的用户组信息。其中，这里的第一用户为DRA首次建立用户组信息和PCRF信息对应关系时，PCRF所服务的用户。

其中，用户组信息至少包括：用户组标识，以及用户组所包含的所有用户的用户标识。用户组信息可以由PCRF直接发送给DRA，或者PCRF通过PCEF发送给DRA。

优选地，在步骤1之前，DRA建立所述第一用户的用户标识和PCRF地址的对应关系。以及在步骤1之前，PCRF还从SPR获取所述第一用户对应的用户组签约信息，该用户组签约信息包括用户组信息之外，至少还包括用户组签约用量。PCRF向DRA发送用户组信息之外，可选的还包括所述PCRF向DRA发送所述PCRF的地址信息。

优选地，在步骤1之后，DRA上建立用户组信息和PCRF地址信息的对应关系。

步骤2，根据所述用户组信息和PCRF地址的对应关系，DRA为用户组内的其他用户的接入选择PCRF。

在步骤2之后，PCRF根据用户组签约用量为用户组内的用户开展业务进行用量监控决策。

实施例二

本实施例中的用户组由用户-1和用户-2构成，且共享用户组签约用量。在本实施例中，给出了当用户-1和用户-2接入到网络或者发起建立PDN连接时，如何为用户-1和用户-2，通过proxy DRA（代理DRA）选择到相同的PCRF的过程。

图7是本发明实施例二的选择PCRF的流程示意图，如图7所示，该流程包括如下步骤：

步骤S701，用户组内的用户-1附着到网络或者发起PDN连接建立请求，假设根据请求消息中包含的信息（例如，APN）选择到PCEF-1，用户-1向PCEF-1发起所述请求。

步骤S702，PCEF-1接收到所述请求之后，向DRA发送IP-CAN会话建立请求，该请求消息中包含用户-1的标识（subscriber-1id）。

步骤S703，DRA根据subscriber-1id选择为该用户接入服务的PCRF。DRA建立subscriber-1 id和PCRF信息（例如，PCRF的地址）的对应关系。

步骤S704，DRA将所述IP-CAN会话建立请求消息转发给PCRF。

步骤S705，PCRF根据请求消息中的subscriber-1 id从SPR中获取用户-1的签约信息，同时SPR根据subscriber-1 id判断用户-1存在于用户组中，SPR将对应的用户组签约信息一并返回给PCRF。

图8是本发明实施例二的用户签约信息的示意图，如图8所示，用户签约信息至少包括用户标识（subscriber id）以及用户组标识（group id）。图9是本发明实施例二的用户组签约信息的示意图，如图9所示，用户组签约信息至少包括用户组标识（group id）、用户组成员标识（subscriber id）以及签约用量等。

PCRF为用户-1建立IP-CAN会话，并返回IP-CAN会话建立成功的响应，该响应消息中将包括用户组信息（用户组标识group id和用户组成员标识，例如，用户-1标识subscirber-1 id和用户-2标识subscriber-2 id），所述信息将反馈给DRA，以便DRA保证为所述用户组的后续用户选择到相同的PCRF，可通过如下两种过程（case-1和case-2）实现：

（1）情况一（Case-1）过程：

步骤S706a，PCRF为用户-1建立IP-CAN会话，并返回IP-CAN会话建立成功的响应消息，该响应消息中包括用户组信息，其中，用户组信息至少包括用户组标识（group id）和用户组成员标识（包括用户-1标识subscriber-1 id和用户-2标识subscriber-2 id）。

步骤S707a，上述IP-CAN会话建立响应消息经过DRA，DRA获取用户组信息（groupid，subscriber-1id，subscriber-2id），由于步骤S703已经建立subscriber-1和PCRF信息的对应关系，因此，这里DRA结合这两部分的信息建立用户组信息（group id,subscriber-1id,subscriber-2id）和PCRF信息的对应关系。

需要说明的是，上述步骤S706a和步骤S707a也可以为：在步骤S706a中，PCRF在返回的IP-CAN会话建立响应消息中，直接包括步骤S706中的用户组信息和PCRF信息（例如，PCRF地址）；在步骤S707a中，DRA直接建立并保存用户组信息和PCRF信息的对应关系。

步骤S708a，DRA将上述IP-CAN会话建立响应消息返回给PCEF-1。用户-1完成网络附着或者PDN连接的过程。

（2）情况二（Case-2）过程

步骤S706b，PCRF向PCEF-1返回IP-CAN会话建立响应消息，该响应消息中包括用户组信息（group id,subscriber-1id,subscriber-2id）。可选的，响应消息中可以包括PCRF信息。

步骤S707b，PCEF-1接收所述IP-CAN会话建立响应消息后，将上述用户组信息发送给DRA。如果步骤S706b有PCRF信息，则PCEF-1将PCRF信息也发送给DRA。

步骤S708b，根据步骤S703中subsriber-1id和PCRF信息的对应关系，以及步骤S707b接收的用户组信息，DRA建立用户组信息（group id,subscriber-1 id,subscriber-2id）和PCRF信息的对应关系。如果步骤S707b还发送了PCRF信息，则DRA直接建立用户组信息和PCRF信息的对应关系。

步骤S709－S715，为所述用户组内的用户-2附着到网络或者发起PDN连接建立的过程：

步骤S709，用户-2接入网络，选择PCEF-2发起附着请求或者PDN连接建立请求，该请求消息中包括用户-2标识（subscriber-2 id）。

步骤S710，PCEF-2向DRA发送IP-CAN会话-2建立请求，该请求消息中包括subscriber-2id。

步骤S711，DRA根据subscriber-2 id和步骤S707a或者步骤S708b建立的用户组信息和PCRF信息的对应关系，为用户-2选择所述PCRF。

步骤S712，DRA向PCRF发起IP-CAN会话-2建立请求。

步骤S713，PCRF根据subscriber-2 id从SPR获取用户-2的签约信息。PCRF或者SPR根据subscriber-2 id以及步骤S705步传送过的用户组信息，判断subscriber-2 id对应的用户-2属于所述用户组，但用户组信息已经发送给了PCRF，因此，在该步骤中可以不用再发送所述用户组信息。

步骤S714，PCRF为用户-2建立IP-CAN会话-2，并向PCEF-2返回IP-CAN会话-2建立响应。

需要说明的是，如果步骤S713中SPR还将所述用户组信息发送给PCRF，则PCRF也可以将步骤S706a或步骤S706b中的所述用户组信息发送给DRA，或者通过PCEF-2发送给DRA（如步骤S715所示），其发送过程参考用户-1接入网络时对应的发送过程（case-1或case-2描述的过程）。如果步骤S713没有将所述用户组信息发送给PCRF，则向DRA再次更新用户组信息的过程可省略。

实施例三

实施例三描述的场景和实施例二基本相同，区别在于通过redirect DRA(重定向DRA)为用户-1和用户-2选择到相同的PCRF。图10是本发明实施例三的选择PCRF的流程示意图，如图10所示，该流程包括如下步骤：

步骤S1001，用户组内的用户-1附着到网络或者发起PDN连接建立请求。假设根据请求消息中包括的信息（例如，APN）选择到PCEF-1，用户-1向PCEF-1发起所述请求。

步骤S1002，PCEF-1接收到所述请求之后，向DRA发送IP-CAN会话建立请求，该请求消息中包括用户-1的标识（subscriber-1 id）。

步骤S1003，DRA根据subscriber-1 id选择为所述用户接入服务的PCRF。DRA建立subscriber-1 id和PCRF信息（例如，PCRF的地址）的对应关系。

步骤S1004，DRA向PCEF-1返回所述PCRF地址信息。

步骤S1005，PCEF-1根据DRA返回的PCRF地址信息，向PCRF发送IP-CAN会话建立请求，该请求消息中包括subscriber-1 id。

步骤S1006，PCRF根据请求消息中的subscriber-1 id从SPR中获取用户-1的签约信息，同时SPR根据subscriber-1 id判断用户-1存在于用户组中，SPR将对应的用户组签约信息一并返回给所述PCRF。其中，用户签约信息如图8所示，至少包括用户标识（subscriberid）以及用户组标识（group id）；用户组签约信息至少包括用户组标识（group id）、用户组成员标识（subscriber id）以及签约用量等。

步骤S1007，PCRF为用户-1建立IP-CAN会话，并返回IP-CAN会话建立成功的响应消息，该响应消息中包括用户组信息，至少包括用户组标识（group id）和用户组成员标识（包括用户-1标识subscriber-1 id和用户-2标识subscriber-2 id）。可选的，用户组信息还包括PCRF地址信息。

步骤S1008，PCEF-1接收所述IP-CAN会话建立响应消息后，将所述用户组信息发送给DRA，如果步骤S1007中有PCRF信息，则PCEF-1将该PCRF信息也发送给DRA。

步骤S1009，根据步骤S503中subsriber-1 id和PCRF信息的对应关系，以及步骤S1008接收的用户组信息，DRA建立用户组信息（group id,subscriber-1id,subscriber-2id）和PCRF信息的对应关系，如果步骤S1008还发送了PCRF信息，则DRA直接建立用户组信息和PCRF信息的对应关系。

步骤S1010－S1016为用户组内的用户-2附着到网络或者发起PDN连接建立的过程：

步骤S1010，用户-2接入网络，选择PCEF-2发起附着请求或者PDN连接建立请求，该请求消息中包括用户-2标识（subscriber-2id）。

步骤S1011，PCEF-2向DRA发送IP-CAN会话-2建立请求，该请求消息中包括subscriber-2id。

步骤S1012，DRA根据subscriber-2id和步骤S1009建立的用户组信息和PCRF信息的对应关系，为用户-2选择所述PCRF。

步骤S1013，DRA将为用户-2选择的PCRF地址信息返回给PCEF-2。

步骤S1014，PCEF-2根据PCRF地址信息向PCRF发送IP-CAN会话-2建立请求，该请求消息中包含subscriber-2 id。

步骤S1015，PCRF根据subscriber-2 id从SPR获取用户-2的签约信息。PCRF或者SPR根据subscriber-2 id以及步骤S1006传送过的用户组信息，判断subscriber-2 id对应的用户-2属于所述用户组，但用户组信息已经发送给了所述PCRF，因此在该步骤中可以不用再发送所述用户组信息。

步骤S1016，PCRF为用户-2建立IP-CAN会话-2，并向PCEF-2返回IP-CAN会话-2建立响应。

需要说明的是，如果步骤S1015中SPR还将所述用户组信息发送给所述PCRF，则PCRF也可以将步骤S1007中用户组信息通过PCEF-2发送给DRA（如步骤S1017所示），其发送过程参考用户-1接入网络时对应的发送过程（步骤S1007和步骤S1008描述的过程）。如果步骤S1015没有将所述用户组信息发送给PCRF，则向DRA再次更新用户组信息的过程可省略。

实施例四

实施例四描述的场景和实施例二基本相同，区别在用户-1接入网络的流程中，如果DRA还没有建立用户组信息和PCRF信息的对应关系，此时用户组内的用户-2已经发起接入网络的流程，此时，如何保证为用户-1和用户-2选择到同一个PCRF的过程。

图11是本发明实施例四的选择PCRF的流程示意图，如图11所示，该流程包括如下步骤：

步骤S1101-S1105的过程与实施例二中的步骤S701-S705相同这里不再重复描述。

步骤S1106-S1111为所述用户组内的用户-2接入网络的流程，其流程发生过程中，DRA还没有建立用户组和PCRF-1地址的对应关系，即Case-1或者Case-2描述的过程还没有完成。

步骤S1106，用户-2向PCEF-2发起网络附着或者PDN连接请求。

步骤S1107，PCEF-2向DRA发起IP-CAN会话-2建立请求，该请求消息中包括subscriber-2id。

步骤S1108，由于此时DRA上没有subscriber-2 id对应的用户组信息和PCRF地址的对应关系，此时，DRA根据subscriber-2 id为用户-2选择到PCRF-2，建立subscriber-2id和PCRF-2地址的对应关系。

步骤S1109，DRA将所述IP-CAN会话-2建立请求消息发送给PCRF-2。

步骤S1110，根据步骤S1109中PCRF-2获取的subscriber-2 id，向SPR获取用户-2的签约信息，以及用户组签约信息。

步骤S1111，PCRF-2向PCEF-2返回IP-CAN会话-2建立成功的响应。

Case-1和Case-2描述的过程和步骤S1104对应，为PCRF-1返回IP-CAN会话-1建立响应，并向DRA上更新用户组信息（group id,subscriber-1id,subscriber-2id）的过程，其过程参考实施例二中对应的过程。

步骤S1115，根据步骤S1113a或步骤S1114b收到的用户组信息建立的和PCRF的对应关系，即（group id,subscriber-1id,subscriber-2id）和PCRF-1地址的对应关系，以及步骤S1108建立的subscriber-2 id和PCRF-2地址的对应关系，DRA判断为group-id下的用户-2选择的是PCRF-2，并没有选择到group id对应的PCRF-1中，DRA重新为subscriber-2对应的用户-2选择PCRF-1。

步骤S1116，DRA向PCEF-2返回PCRF-1的地址，要求PCEF-2终止此前为用户-2接入网络建立的IP-CAN会话-2，重新建立IP-CAN会话。

步骤S1117，收到所述消息之后，PCEF-2发起到PCRF-2的IP-CAN会话-2的终止。

步骤S1118，PCEF-2根据PCRF-1的地址重新发起到PCRF-1的IP-CAN会话-2’的建立过程。

实施例五

本实施例是对用户组进行用量监控的过程，以前面的实施例描述的流程为基础。前面的实施例描述的流程实现了对于用户组内的所有用户接入网络的时候，都选择相同的PCRF为其接入服务，本实施例由PCRF管理用户组的签约用量，为所述用户组进行用量监控。

图12是本发明实施例五的PCRF对用户组进行用量监控的流程示意图，如图12所示，该流程包括如下步骤：

步骤S1201，用户-1开展业务

步骤S1202，AF将业务协商信息下发给PCRF。

步骤S1203，根据该业务协商信息以及其他信息（例如，运营商策略等），PCRF为所述业务进行策略决策，包括产生QoS和计费控制策略。同时根据前面实施例描述的PCRF从SPR中获取的用户组签约信息（包括签约用量）PCRF为所述用户开展的所述业务进行用量监控决策，包括为所述业务流分配monitoring key，并根据用户组可用签约用量为所述monitoring key分配阈值（threshold-1）。

步骤S1204，PCRF将控制策略和用量监控下发给PCEF-1。

步骤S1205，根据PCRF下发的信息，PCEF-1启动用量监控。

步骤S1206，当累计用量达到PCRF分配的threshold-1时，PCEF-1上报累计用量，PCRF可以根据上报结果重新分配新的阈值继续实施监控，或者终止用量监控。

步骤S1207，用户组内的用户-2开展业务。

步骤S1208，AF将业务协商信息下发给PCRF。

步骤S1209，PCRF进行策略决策，同时进行用量监控决策，即为所述业务分配monitoring key-2，同时根据用户组的可用签约用量为所述monitoring key分配阈值（threshold-2）。

步骤S1210，PCRF将控制策略和用量监控下发给PCEF-2

步骤S1211，PCEF-2按照下发的信息对用户-2开展的所述业务启动用量监控。

步骤S1212，当累计用量达到threshold-2时，PCEF-2执行用量监控上报，PCRF据此进行用量在分配，或者终止用量监控。有关用量监控决策、下发和上报的过程完全可以参照现有的用量监控实现机制，不再详细赘述。

综上所述，本发明实施例提供了一种PCRF的选择方案，采用DRA为归属于同一用户组的用户的IP-CAN会话建立请求选择相同的PCRF的方式，保证了为用户组内的用户选择到同一个PCRF，实现了对用户组用量监控的需求。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种策略和计费规则功能PCRF的选择方法，其特征在于，包括以下步骤：

Diameter路由代理DRA接收为用户组中第一用户服务的PCRF发送的所述用户组的用户组信息，其中，所述用户组信息至少包括：用户组标识，以及用户组所包含的所有用户的用户标识；

所述DRA根据所述用户组信息和所述PCRF的地址信息，为所述用户组内的其他用户选择所述PCRF；

其中，所述DRA为所述用户组内的其他用户选择所述PCRF包括：

所述DRA判断为所述第一用户选择的PCRF与为所述用户组内其他用户选择的PCRF是否相同；

如果不相同，则所述DRA通知策略和计费执行功能PCEF重新为所述用户组内的其他用户进行PCRF选择，其中，重新选择的PCRF是为所述第一用户服务的PCRF，所述通知中包括为所述第一用户服务的PCRF的地址信息。

2.根据权利要求1所述的方法，其特征在于，所述DRA接收所述PCRF发送的所述用户组信息之前，还包括：

所述PCRF将所述用户组信息直接发送给所述DRA，或者所述PCRF将所述用户组信息发送给策略和计费执行功能PCEF，由该PCEF将所述用户组信息发送给所述DRA。

3.根据权利要求2所述的方法，其特征在于，所述PCRF将所述用户组信息发送给所述DRA之前，还包括：

所述PCRF根据所述第一用户的用户标识从用户签约数据库SPR获取所述用户组的用户组信息。

4.根据权利要求1所述的方法，其特征在于，所述DRA为所述用户组内的其他用户选择所述PCRF之前，还包括：

所述DRA接收所述PCRF发送的所述PCRF的地址信息。

5.根据权利要求1所述的方法，其特征在于，所述DRA接收所述PCRF发送的所述用户组的用户组信息之后，还包括：

所述DRA建立所述用户组信息和所述PCRF的地址信息的对应关系。

6.根据权利要求5所述的方法，其特征在于，所述第一用户为所述DRA首次建立所述对应关系时，所述PCRF所服务的用户。

7.根据权利要求1所述的方法，其特征在于，所述DRA通知所述PCEF重新为所述用户组内的其他用户进行PCRF选择之后，还包括：

所述PCEF终止与原PCRF的IP连接访问网络IP-CAN会话，并建立与服务所述第一用户的PCRF之间的IP-CAN会话。

8.根据权利要求1所述的方法，其特征在于，所述DRA为所述用户组内的其他用户选择所述PCRF之后，还包括：

所述PCRF根据所述用户组的签约用量信息为所述用户组内的用户开展业务进行用量监控决策，并向策略和计费执行功能PCEF下发用户监控。

9.一种策略和计费规则功能PCRF的选择装置，位于Diameter路由代理DRA，其特征在于，包括：

接收模块，用于接收为用户组中第一用户服务的PCRF发送的所述用户组的用户组信息，其中，所述用户组信息至少包括：用户组标识，以及用户组所包含的所有用户的用户标识；以及

选择模块，用于根据所述接收模块接收到的所述用户组信息和所述PCRF的地址信息，为所述用户组内的其他用户选择所述PCRF；

判断模块，用于判断为所述第一用户选择的PCRF与为所述用户组内其他用户选择的PCRF是否相同；以及

处理模块，用于在所述判断模块判断为所述第一用户选择的PCRF与为所述用户组内其他用户选择的PCRF不相同的情况下，通知策略和计费执行功能PCEF重新为所述用户组内的其他用户进行PCRF选择，其中，重新选择的PCRF是为所述第一用户服务的PCRF，所述通知中包括为所述第一用户服务的PCRF的地址信息。

10.根据权利要求9所述的选择装置，其特征在于，还包括：

建立模块，用于建立所述用户组信息和所述PCRF的地址信息的对应关系。

11.一种策略和计费规则功能PCRF的选择***，其特征在于，包括PCRF、用户签约数据库SPR和权利要求9至10中任一项所述的DRA，其中，

所述PCRF包括：获取转发模块，用于从所述SPR获取所述第一用户所属的用户组的用户组信息，并将所述用户组信息发送给所述DRA；

所述SPR包括：查询下发模块，用于根据所述PCRF的指令查询并下发所述用户组信息。