一种组用户用量监控方法及系统
技术领域
本发明涉及通信技术领域,尤其涉及一种组用户用量监控方法及系统。
背景技术
第三代合作伙伴计划(3rd Generation Partnership Project,简称为3GPP)定义了针对移动网络的策略和计费控制(Policy and Charging Control,简称为PCC)架构。如图1所示,PCC架构中各实体功能描述如下:
PCRF(Policy and Charging Rules Function,策略和计费规则功能)为业务包含的业务数据流在传输过程中使用网络资源制定资源控制策略,包括QoS(Quality ofService,服务质量)控制策略和计费控制策略。
PCEF(Policy and Charging Enforcement Function,策略和计费执行功能)用于执行PCRF下发的或者PCEF上预配置的PCC规则,对网络上传输的IP报文进行检测,识别该IP报文隶属的业务数据流,并对业务数据流提供QoS和计费控制。
BBERF(Bearer Binding and Event Report Function,承载绑定和事件上报功能)主要用于对网络上传输的IP报文进行检测,并将IP报文按照规则映射到对应的承载通道上。BBERF还执行承载相关事件的上报,例如当承载丢失,或者发生接入网络切换的时候,都需要将相应的事件上报给PCRF,请求PCRF进行相应的决策。
SPR(Subscription Profile Repository,用户签约数据库)用于保存用户签约的业务信息,为PCRF制订PCC规则提供必要的用户签约信息。
OCS(Online Charging System,在线计费系统)和OFCS(Offline ChargingSystem,离线计费系统)分别用于离线和在线计费。
在用户开展业务过程中,PCC按照如下方式为业务(由若干业务数据流组成)在传输过程中动态提供QoS保证:
业务包含的每个业务数据流都对应一个具体的PCC规则,PCC规则中定义了该业务数据流传输时需要使用的QoS资源。在业务数据流在承载网络中传输之前,PCRF需要依据相关信息为业务数据流决策并制定PCC规则。PCRF决策并制定PCC规则所依据的相关信息包括如下信息:
从AF接收的业务协商信息,该业务协商信息就是用户开展业务时和通信对端协商的开展所述业务的信息,例如开展所述业务对QoS的要求,通信双方使用的IP地址、端口号、所使用的协议等信息;
从SPR接收的用户签约信息,例如用户签约信息中包含用户和运营商签约的QoS信息,用户开展业务时,业务对QoS的要求不能超过用户签约信息所规定的用户可以使用的QoS信息;
PCRF自身存储的运营商自定义策略,例如运营商对漫游用户和非漫游用户开展业务需要区分控制,这种运营商自行定义的区分控制策略可以配置在PCRF上;
从PCEF或者BBERF上接收的接入相关信息,例如用户附着到网络时,PCRF需要通过PCEF或者BBERF获取用户接入网络的信息,以供PCRF为用户开展业务进行策略决策;
从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重新对所述业务进行策略决策,产生新的控制策略。
现有技术的用量监控的实现过程如图2所示,该过程主要包括如下步骤:
步骤A1-A3,为PCRF向PCEF下发用量监控的过程。
业务由一个或者多个业务数据流构成,对业务实施策略控制在现实时实际上是针对业务数据流的策略控制,通过PCRF为业务数据流制定控制策略(PCC规则)并下发给PCEF执行,实现针对业务的策略控制。如果需要对该业务实施用量监控,则在PCRF向PCEF下发的PCC规则(charging rule definition)中包含监控键(monitoring key),同时PCRF为该monitoring key分配一个用量监控信息(usage monitoring information)并下发给PCEF。Usage monitoring information中包含所述monitoring key、分配的监控阈值(threshold)以及其他信息。
例如流程中需要实施用量监控的业务包含了业务数据流-1和业务数据流-2,则PCRF向PCEF下发用量监控指示的过程如步骤A1-A3描述:
步骤A1,PCEF向PCRF发送CCR(Credit Control Request,信用控制请求)请求。
步骤A2,PCRF向PCEF下发CCA(Credit Control Answer,信用控制应答)响应,包含PCC规则-1(用charging rule definition-1表示)、PCC规则-2(用charging ruledefinition-2表示)以及usage monitoring information。
其中,PCC规则-1中包含了PCC规则名(用charging rule name-1表示),和monitoring key;
PCC规则-2中包含了PCC规则名(用charging rule name-2表示),和monitoringkey;
Usage monitoring information中包含了上述monitoring key,以及PCRF为其分配的监控阈值(threshold)。
此外,PCRF也可在发送给PCEF的RAR消息中包含上述用量监控信息。
步骤A3,对应PCRF向PCEF下发RAR(Re-Auth-Request,重鉴权请求)消息,则PCEF向PCRF返回RAA(Re-Auth-Answer,重鉴权应答)消息。
步骤B,当PCEF收到PCRF下发的PCC规则后,安装规则,并按照用量监控信息,对PCC规则对应的业务数据流(即业务数据流1和业务数据流2)实施用量监控。
步骤C1-C2为PCEF上报用量监控的过程。
步骤C1,当PCEF对该Monitoring Key监控的累计用量达到步骤A2下发的阈值时,PCEF进行用量监控上报。PCEF向PCRF发送CCR消息,携带Usage Monitoring Information,其中包含上述Monitoring Key以及累计用量(Used Service Unit)。
步骤C2,PCRF向PCEF返回CCA响应。
步骤D,根据上报的用量,PCRF对利用该monitoring key进行用量监控的业务数据流(即业务数据流-1和业务数据流-2)重新制定相应的控制策略。
步骤E1-E2为PCRF重新制定策略下发的过程。
步骤E1,PCRF向PCEF下发RAR消息,为业务数据流1和2重新下发控制策略。
步骤E2,PCEF向PCRF返回响应。
上述流程描述的是对单个业务的用量监控。另外,在实际运营中,还包括针对用户采取用量监控的需求。由于用户可以开展多种业务,对用户的用量监控实际上是针对多个业务进行用量监控。在利用上述用量监控上报机制在实现对用户开展的多个业务实施用量监控时,需要由同一网络设备管理用户的签约用量。由于用户附着时就选择了一个为其服务的PCRF,即用户开展的各种业务都由该PCRF提供策略控制,因此,由该PCRF管理用户的签约用量,同时为用户开展的多个业务分配相同的monitoring key,就可以实现针对用户开展的多个业务实施用量监控。
在实际运营中还存在一种需求,就是需要针对一组用户实施用量监控。例如,运营商开通家庭套餐,签约一定的免费用量,使得每个家庭成员都可以使用该签约免费用量,一旦免费用量超出之后,针对该家庭成员的用量都要计费。再如集团用户套餐,对于集团内用户在体验某一类业务时在签约用量内可以获得较高的业务体验,当超出签约用量时,就无法保证所述业务的体验效果。对于上述家庭用户或集团用户(统称为组用户),虽然组用户内的每个成员可以共享签约用量,但是不能保证组内用户附着到网络的时候都能选择到同一个PCRF,因此,使用现有用量监控机制将无法实现对组用户实施用量监控。另外,组内用户还有可能使用不同的SPR保存签约信息,例如实际运营中运营商选择将PCRF和SPR合设,这样SPR也不适合统一管理组用户的签约用量,并对组用户实施用量监控。因此,针对现有用量监控上报机制,尚无法实现对共享签约用量的组用户实施用量监控。
发明内容
本发明解决的技术问题是提供一种组用户用量监控方法及系统,实现对组用户的用量监控。
为解决上述技术问题,本发明提供了一种组用户用量监控方法,
第一策略控制实体向第二策略控制实体发送用量监控请求;
所述第二策略控制实体收到所述用量监控请求时,根据用户组签约用量进行用量监控决策,并向所述第一策略控制实体下发用量监控信息;
所述第一策略控制实体根据收到的所述用量监控信息,对用户进行用量监控。
进一步地,所述第一策略控制实体通过Diameter路由代理(DRA)发现所述第二策略控制实体,并向所述第二策略控制实体发送所述用量监控请求;
其中所述DRA通过用户的用户组标识发现所述第二策略控制实体。
进一步地,所述第一策略控制实体在获取到针对所述用户进行用量监控的指示时,向所述第二策略控制实体发送所述用量监控请求。
进一步地,所述第二策略控制实体向所述第一策略控制实体下发的所述用量监控信息,包括监控键和监控阈值。
进一步地,所述第一策略控制实体根据收到的所述用量监控信息,对用户进行用量监控,具体包括:
所述第一策略控制实体向策略执行实体下发控制策略和所述用量监控信息,所述控制策略中包含所述监控键,所述用量监控信息中包含所述监控键和监控阈值;
所述策略执行实体执行用量监控;
所述策略执行实体向所述第一策略控制实体上报累计监控用量;
所述第一策略控制实体根据收到的所述累计监控用量决策控制策略、和/或,根据所述累计监控用量决策是否向所述第二策略控制实体发送用量监控请求。
进一步地,所述第一策略控制实体根据所述累计监控用量决策是否向所述第二策略控制实体发送用量监控请求,具体包括:
如果所述累计监控用量达到所述监控阈值,则所述第一策略控制实体决策向所述第二策略控制实体发送用量监控请求;
如果所述累计监控用量没有达到所述监控阈值,则所述第一策略控制实体决策不向所述第二策略控制实体发送用量监控请求。
本发明还提供了一种组用户用量监控系统,所述系统包括:第一策略控制实体,第二策略控制实体,其中:
所述第一策略控制实体用于,向所述第二策略控制实体发送用量监控请求;并根据收到的用量监控信息,对用户进行用量监控;
所述第二策略控制实体用于,收到所述用量监控请求时,根据所述用户的用户组签约用量进行用量监控决策,并向所述第一策略控制实体下发用量监控信息。
进一步地,所述第一策略控制实体用于,所述第一策略控制实体通过DRA发现所述第二策略控制实体,并向所述第二策略控制实体发送所述用量监控请求;
其中所述DRA通过用户的用户组标识发现所述第二策略控制实体。
进一步地,所述第一策略控制实体用于,在获取到针对所述用户进行用量监控的指示时,向所述第二策略控制实体发送所述用量监控请求。
进一步地,所述第二策略控制实体向所述第一策略控制实体下发的所述用量监控信息,包括监控键和监控阈值。
进一步地,所述系统还包括策略执行实体,
所述第一策略控制实体用于,收到所述用量监控信息后,向所述策略执行实体下发控制策略和所述用量监控信息,其中所述控制策略中包含所述监控键,所述用量监控信息中包含所述监控键和监控阈值;以及,根据收到的所述策略执行实体上报的累计监控用量决策控制策略、和/或,根据所述累计监控用量决策是否向所述第二策略控制实体发送用量监控请求;
所述策略执行实体用于,根据收到的控制策略和所述用量监控信息,执行用量监控;以及,向所述第一策略控制实体上报累计监控用量。
进一步地,所述第一策略控制实体根据所述累计监控用量决策是否向所述第二策略控制实体发送用量监控请求,是指:
如果所述累计监控用量达到所述监控阈值,则所述第一策略控制实体决策向所述第二策略控制实体发送用量监控请求;
如果所述累计监控用量没有达到所述监控阈值,则所述第一策略控制实体决策不向所述第二策略控制实体发送用量监控请求。
本发明提供了一种针对组用户的用量监控机制,通过引入专用的策略控制实体,用户组内的每个成员用户附着的策略控制实体,向该专用的策略控制实体请求用量监控,实现对共享签约用量的组用户的用量监控,从而解决了现有用量监控机制的不足。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为现有技术的3GPP PCC R8架构的示意图;
图2为根据现有技术的用量监控实现流程图;
图3为根据本发明实施例一的组用户用量监控的流程图;
图4为根据本发明实施例二的流程图;
图5为根据本发明实施例三的流程图;
图6为根据本发明实施例四的流程图;
图7为根据本发明实施例五的流程图。
具体实施方式
为解决现有技术中存在的问题,本实施方式中,通过引入一个专用策略控制实体(以下称作第二策略控制实体),实现针对组用户的用量监控。
所述的专用策略控制实体可以单独设置,也可以集成在其他策略控制实体中。
所述的专用策略控制实体从其他网元获取组用户签约信息,或者在所述专用策略控制实体上配置组用户签约信息。
所述的组用户签约信息包含了用户组标识、组内用户的标识、用户组签约用量等信息。
本实施方式提供的一种针对组用户实施用量监控的方法,具体采用如下技术方案:
步骤一,第一策略控制实体向第二策略控制实体发送用量监控请求;
具体地,所述第一策略控制实体通过DRA(Diameter Routing Agent,Diameter路由代理)发现所述第二策略控制实体,所述DRA根据用户组标识发现所述第二策略控制实体。
其中,所述第一策略控制实体可采用现有的PCRF,第二策略控制实体则可通过扩展了现有功能的PCRF实现。
步骤二,所述第二策略控制实体根据用户组签约用量进行用量监控决策,并下发用量监控信息给所述第一策略控制实体;
具体地,所述用量监控信息,包括:第二策略控制实体为所述用户分配的监控键(monitoring key)和监控阈值(threshold)。
步骤三,所述第一策略控制实体根据收到的用量监控信息,对用户进行用量监控;
所述的对用户进行用量监控,进一步包括:
所述第一策略控制实体向策略执行实体(如PCEF)下发控制策略(包含所述监控键)和用量监控信息(包含所述监控键和监控阈值);
所述策略执行实体执行用量监控;
所述策略执行实体向所述第一策略控制实体上报累计监控用量;
所述第一策略控制实体根据上报的累计监控用量进行策略决策;
具体地,所述第一策略控制实体根据累计监控用量决策控制策略(即PCC规则),并根据累计监控用量上报结果决策是否向所述第二策略控制实体发送用量监控请求。
为使本发明的目的、技术方案和优点更加清楚明白,下文中将结合附图对本发明的实施例进行详细说明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
实施例一
图3示出了本发明实施例的组用户用量监控方法的流程示意图,如图3所示,本实施例流程主要包括如下实施步骤:
步骤301,第一策略控制实体向第二策略控制实体发送用量监控请求;
具体地,当所述第一策略控制实体获取到为用户进行用量监控的指示时,则向所述第二策略控制实体发送用量监控请求。
所述第一策略控制实体通过DRA发现所述第二策略控制实体,所述DRA根据用户组标识发现所述第二策略控制实体。
步骤302,所述第二策略控制实体根据用户组签约用量进行用量监控决策,为所述用户分配监控键(monitoring key)和监控阈值(threshold)。
步骤303,第二策略控制实体将所述监控键和监控阈值下发给所述第一策略控制实体。
步骤304,第一策略控制实体向第一策略执行实体下发用量监控信息,包含所述监控键和监控阈值。
步骤305,第一策略执行实体执行用量监控。
步骤306(可选),第一策略执行实体收到第一策略控制实体下发的用量监控上报指示。
步骤307,第一策略执行实体向第一策略控制实体上报累计监控用量。
步骤308,第一策略控制实体根据上报的累计监控用量进行策略决策(即PCC规则),并根据累计监控用量上报结果决策是否向第二策略控制实体发送用量监控请求,如果是,则执行步骤309。
步骤309,第一策略控制实体向第二策略控制实体发送用量监控请求。
实施例二
本实施例假设用户组包含了UE-1和UE-2。根据现有UE附着的流程,当UE-1附着到网络时,选择PCEF-1和PCRF-1(即第一策略控制实体)为其接入服务;当UE-2附着到网络时,选择PCEF-2和PCRF-2为其接入服务。SPR-1用于保存UE-1的签约信息,其中包含了UE-1需要执行组用户用量监控的指示。SPR-2用于保存UE-2的签约信息,其中包含了UE-2需要执行组用户用量监控的指示。PCRF-3是专门为组用户提供用量监控的策略控制实体(即第二策略控制实体)。当组用户附着到网络,网络设备根据用量监控指示向PCRF-3请求用量监控,以及PCRF-3下发用量监控的过程如图4所示。该流程描述如下:
步骤401.PCRF-3获取用户组签约信息,包括用户组标识、组内所有用户的标识、用户组签约用量。所述用户组签约信息可以预保存在PCRF-3上,也可以由PCRF-3从保存所述信息的其他网元获取。
步骤402.UE-1附着到网络,选择PCEF-1。PCEF-1根据选择PCRF-1为UE-1接入服务,向PCRF-1发送IP-CAN会话建立请求,携带用户标识。
步骤403.PCRF-1根据用户标识判断还没有UE-1的签约信息,从SPR-1中获取UE-1的签约信息,其中包含要求为UE-1进行用量监控的指示。
步骤404.PCRF-1根据从SPR-1获取的UE-1的签约信息中包含为UE-1进行用量监控的指示,PCRF-1通过DRA根据用户组标识发现所述PCRF-3,PCRF-1向PCRF-3发送对UE-1进行用量监控的请求,包含UE-1标识、用户组标识等信息。
其中,所述用户组标识可以从PCEF-1发送的IP-CAN会话建立请求消息中获取,或者从SPR-1的UE-1签约信息中获取。
步骤405.PCRF-3接收所述请求后,根据用户组签约用量信息进行用量监控决策,为UE-1分配用量监控键(monitoring key),并针对所述monitoring key分配监控阈值(threshold)。
步骤406.PCRF-3向PCRF-1下发用量监控,包含分配给UE-1的monitoring key和threshold。至此,PCRF-1与PCRF-3之间建立策略控制会话。
步骤407.PCRF-1针对IP-CAN会话建立请求进行策略决策,产生控制策略。
步骤408.PCRF-1向PCEF-1返回IP-CAN会话建立成功的响应,包含控制策略,以及用量监控信息(monitoring key,threshold),要求对UE-1实施用量监控。
步骤409.PCEF-1执行策略,并根据PCRF-1的要求,对UE-1执行用量监控。
步骤410.用户组下的UE-2附着到网络的过程,参考UE-1的附着过程。当选择PCRF-2为UE-2接入服务时,PCRF-2根据从SPR-2接收的要求为UE-2执行用量监控的指示之后,根据用户组标识发现PCRF-3并建立策略控制会话,请求为UE-2进行用量监控。PCRF-3根据用户组签约用量信息进行用量监控决策,为UE-2产生用量监控信息并下发给PCRF-2。PCRF-2进一步下发给PCEF-2,启动针对UE-2的用量监控。
实施例三
上述实施例二给出了用户组内的UE-1和UE-2附着到网络的过程。本实施例中给出了UE附着到网络之后,开展业务。PCEF对UE进行用量监控,并进行用量监控上报,以及PCRF根据用量监控上报结果实施策略调整的过程。为简便起见,本实施例仅给出了对UE-1实施用量监控的过程。对UE-2实施用量监控的过程,则可参考针对UE-1实施用量监控的过程。本实施例的用量监控上报以及根据用量监控结果进行策略调整的过程如图5所示,其流程描述如下:
步骤501.UE-1开展业务,PCEF-1对UE-1实施用量监控。
步骤502.PCEF-1从PCRF-1中收到要求上报用量监控的指示。
步骤503.PCEF-1向PCRF-1返回确认消息。
步骤504.PCEF-1将监控的累计用量(该累计监控用量可能没有到达监控阈值threshold)上报给PCRF-1。
步骤505.PCRF-1根据上报的累计监控用量进行策略决策,为UE-1进行策略调整,例如限制UE-1的带宽等。
步骤506.PCRF-1将新的控制策略下发给PCEF-1。
步骤507.根据PCRF-1下发的策略,PCEF-1执行新的控制策略。
实施例四
本实施例和前述实施例三描述的场景相同,同为用量监控上报和根据用量监控上报结果进行策略调整的过程。区别在于实施例三中描述的是累计监控用量没有达到阈值时,PCEF-1应PCRF-1的要求上报用量监控的过程;而本实施例中描述的是当累计监控用量到达阈值时,PCEF-1向PCRF-1主动上报用量监控的过程。其实现如图6所示,流程描述如下:
步骤601.UE-1开展业务,PCEF-1对UE-1实施用量监控。
步骤602.当UE-1使用的用量达到实施例二中步骤408下发的监控阈值时,PCEF-1向PCRF-1上报用量监控,携带monitoring key和累计监控用量。
步骤603.PCRF-1收到用量监控上报后,判断分配给UE-1使用的用量已经被UE-1用完,PCRF-1决策向PCRF-3发送用量监控请求,请求消息中携带monitoring key。
步骤604.PCRF-3收到请求消息,根据用户组签约用量信息进行用量监控决策。如果此时所述用户组的签约用量没有分配完,则为该monitoring key分配新的监控阈值threshold-2;如果所述用户组签约用量已经完全分配给了组内用户,则PCRF-3无法再为所述monitoring key分配新的监控阈值。
步骤605a.如果PCRF-3为UE-1分配了新的监控阈值,则PCRF-3将monitoring key和对应的新的监控阈值threshold-2下发给PCRF-1。
步骤605b.如果PCRF-3没有为UE-1分配新的监控阈值,则PCRF-3向PCRF-1下发停止用量监控的指示(该指示可以通过一个明确的信息表示,也可以通过在下发的消息中不携带任何用量监控相关的信息表示停止用量监控)。
步骤606.根据602步PCEF-1上报的用量监控的结果,PCRF-1执行策略决策,产生新的控制控制策略。
步骤607.PCRF-1将从PCRF-3接收的用量监控信息(monitoring key和threshold-2)连同控制策略下发给PCEF-1。
步骤608.PCEF-1执行控制策略,并对UE-1继续执行用量监控。
实施例五
前述实施例二、三和四描述的是在用户组内的UE附着到网络,建立IP-CAN会话的过程中PCRF-3下发用量监控的过程。而本实施例中描述的是在IP-CAN会话修改过程中下发用量监控的过程,即UE附着到网络之后,在开展业务的过程中,才启动针对组内用户开展业务的用量监控。当然,本实施例也可在前述实施例的基础上进行实施,即,在UE附着到网络的过程,以及,在开展业务的过程中,均进行针对组内用户开展业务的用量监控。其过程如图7所示,具体流程描述如下:
步骤701.UE-1开展业务,和AF之间完成业务协商过程。
步骤702.PCRF-1收到IP-CAN会话修改的触发。其触发可以来自于AF,例如收到AF的业务授权请求,该请求将触发PCRF-1发起IP-CAN会话的修改;或者收到来自PCEF-1的IP-CAN会话修改请求,请求建立/修改IP-CAN承载。
步骤703.根据从SPR-1接收的UE-1的签约信息中包含为UE-1进行用量监控的指示,PCRF-1向PCRF-3发起用量监控请求。如果此时PCRF-1和PCRF-3还没有建立策略控制会话,则PCRF-1通过DRA根据用户组标识发现PCRF-3,并建立策略控制会话。PCRF-1向PCRF-3发起用量监控请求,请求消息中包含用户组标识、UE-1标识。
步骤704.当PCRF-3收到请求消息之后,根据用户组签约用量信息进行用量监控决策,为UE-1分配监控键(monitoring key),并分配相应的监控阈值(threshold)。
步骤705.PCRF-3向PCRF-1下发用量监控,包含上述信息。
步骤706.PCRF-1为UE-1开展的所述业务进行策略决策,产生PCC规则,并在PCC规则中包含所述monitoring key,表示针对UE-1开展的所述业务启动用量监控。
步骤707.PCRF-1向PCEF-1下发控制策略和用量监控信息。
步骤708.PCEF-1执行策略,并启动针对UE-1开展的所述业务的用量监控。
步骤709.当PCEF-1监控的累计用量达到所述监控阈值的时候,PCEF-1向PCRF-1上报用量监控,携带monitoring key和累计监控用量。
步骤710.当PCRF-1接收到所述用量监控上报结果之后,判断分配给UE-1开展所述业务的监控阈值已经到达,PCRF-1决定向PCRF-3请求针对UE-1开展的所述业务继续进行用量监控,请求消息中携带所述monitoring key。
步骤711.PCRF-3接收到所述请求之后,根据用户组的签约用量信息进行用量监控决策,为所述monitoring key分配新的监控阈值threshold-2。
步骤712.PCRF-3向PCRF-1下发用量监控,包含monitoring key和threshold-2。
步骤713.PCRF-1对UE-1开展的所述业务,根据PCEF-1上报的用量监控结果进行策略决策,例如降低UE-1开展所述业务的授权带宽,决策产生新的PCC规则,所述PCC规则中仍然包含所述monitoring key。
步骤714.PCRF-1向PCEF-1下发新的策略,包含所述PCC规则和用量监控信息(monitoring key和threshold-2)
步骤715.PCEF-1执行PCRF-1下发的策略,并继续针对UE-1开展的所述业务启动用量监控。
此外,本发明实施例中还提供了一种组用户用量监控系统,该系统主要包括:第一策略控制实体,第二策略控制实体,其中:
第一策略控制实体用于,向第二策略控制实体发送用量监控请求;并根据收到的用量监控信息,对用户进行用量监控;
第二策略控制实体用于,收到用量监控请求时,根据用户的用户组签约用量进行用量监控决策,并向第一策略控制实体下发用量监控信息。
进一步地,第一策略控制实体用于,第一策略控制实体通过DRA发现第二策略控制实体,并向第二策略控制实体发送用量监控请求;
其中DRA通过用户的用户组标识发现第二策略控制实体。
进一步地,第一策略控制实体用于,在获取到针对用户进行用量监控的指示时,向第二策略控制实体发送用量监控请求。
进一步地,第二策略控制实体向第一策略控制实体下发的用量监控信息,包括监控键和监控阈值。
进一步地,系统还包括策略执行实体,
第一策略控制实体用于,收到用量监控信息后,向策略执行实体下发控制策略和用量监控信息,其中控制策略中包含监控键,用量监控信息中包含监控键和监控阈值;以及,根据收到的策略执行实体上报的累计监控用量决策控制策略、和/或,根据累计监控用量决策是否向第二策略控制实体发送用量监控请求;
策略执行实体用于,根据收到的控制策略和用量监控信息,执行用量监控;以及,向第一策略控制实体上报累计监控用量。
进一步地,第一策略控制实体根据累计监控用量决策是否向第二策略控制实体发送用量监控请求,是指:
如果累计监控用量达到监控阈值,则第一策略控制实体决策向第二策略控制实体发送用量监控请求;
如果累计监控用量没有达到监控阈值,则第一策略控制实体决策不向第二策略控制实体发送用量监控请求。
以上仅为本发明的优选实施案例而已,并不用于限制本发明,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员可根据本发明做出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。