CN102238645A - 用于分组业务的策略控制方法及分组业务*** - Google Patents
用于分组业务的策略控制方法及分组业务*** Download PDFInfo
- Publication number
- CN102238645A CN102238645A CN2010101736828A CN201010173682A CN102238645A CN 102238645 A CN102238645 A CN 102238645A CN 2010101736828 A CN2010101736828 A CN 2010101736828A CN 201010173682 A CN201010173682 A CN 201010173682A CN 102238645 A CN102238645 A CN 102238645A
- Authority
- CN
- China
- Prior art keywords
- user
- group
- pcrf
- request
- session
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种用于分组业务的策略控制方法及分组业务***,其中,所述方法包括:策略和计费规则实体PCRF接收到一个用户组的一个用户的QoS授权请求;PCRF判断用户的保障带宽需求与已为用户组授权的保障带宽总和未超过用户组的组签约保障带宽GSGB;PCRF为用户授权保障带宽的QoS。通过本发明,避免了同一个MTC Subscriber的多个MTC设备在某一时间段同时进行业务访问时,造成的用户访问受限,提升了用户体验。
Description
技术领域
本发明涉及移动通信***,特别涉及一种用于分组业务的策略控制方法及一种分组业务***。
背景技术
3GPP无线核心网包括通用无线分组业务(General Packet RadioService,简称为GPRS)网络、演进的分组***(Evolved PacketSystem,简称为EPS)网络、通用移动通信***(Universal MobileTelecommunications System,简称为UMTS)。
一种3GPP的网络架构如图1所示,用户设备(User Equipment,简称为UE)通过EPS和UMTS接入机器类型通信(Machine TypeCommunication,简称为MTC)服务器(MTC Server),构成MTC***,实现MTC业务。MTC***是一种典型的分组业务***,在MTC***中,UE也称为MTC设备。在图1中,实线表示信令,虚线表示用户的IP通道。通过UMTS接入时,UE又可称为移动台(Mobile Station,简称为MS)。
MTC***涉及的主要网元包括:EPS网络部分的网元、UMTS网络部分的网元以及MTC Server。其中,EPS网络部分的网元主要包括:增强的无线基站(eNodeB)、移动性管理实体(MobilityManagement Entity,简称为MME),策略和计费规则实体(Policy andCharging Rules Function,简称为PCRF),以及用户面数据路由处理网元(SAE GW)。其中,SAE GW包括分组数据网网关(Packet DataNetwork Gateway,简称为P-GW)和服务网关(Serving GW,简称为S-GW)。PCRF是策略和计费控制(Policy and Charging Control,简称为PCC)架构的重要功能实体,用以控制因特网协议-连接接入网(IP-Connectivity Access Network,简称为IP-CAN)策略和计费规则的获取、装配和下发等。UMTS网络主要由3GPP无线接入网络(GSM EDGE Radio Access Network/UMTS Terrestrial RadioAccess Network,GERAN/UTRAN,统称为RAN)、服务GPRS支持节点(Serving GPRS Support Node,简称为SGSN)、网关GPRS支持节点(Gateway GPRS Support Node,简称为GGSN)构成。
相关技术中,MTC设备(MTC Device,即终端)接入MTC服务器,首先必须先通过EPS或UMTS建立IP-CAN(IP-ConnectivityAccess Network,因特网协议-连接接入网)会话。为了实现对IP-CAN会话的策略和计费控制,EPS或UMTS***中的策略执行实体与PCRF(Policy and Charging Rules Function,策略和计费规则实体)为每一个IP-CAN会话建立Diameter会话。通过Diamete会话,策略执行实体向PCRF上报MTC设备的接入信息,PCRF向策略执行实体下发策略。其中,策略执行实体在EPS***中为位于P-GW中的PCEF(Policy and Charging Enforcement Function,策略和计费执行实体),以及可能在S-GW中的BBERF(Bearer Binding and EventReport Function,承载绑定和事件报告实体)。在UMTS***中,策略执行实体为位于GGSN的PCEF。
自第三代合作伙伴计划阶段7(3GPP Release7)标准体系以来,策略和计费功能由策略和计费控制(PCC,Policy and ChargingControl)框架来实现。PCC架构是一个能够应用于多种接入技术的功能框架,例如,PCC架构可以应用于UMTS以及EPS。
PCC主要实现了策略控制和计费两大功能,图2为现有PCC组成架构示意图。其中,AF用于提供业务应用的接入点,这些业务应用所使用的网络资源需要进行动态的策略控制。在业务面进行参数协商时,AF将相关业务信息传递给PCRF,AF和PCRF之间使用Rx接口。
PCRF是PCC的核心,用于负责策略决策和计费规则的制定。PCRF提供基于业务数据流的网络控制规则,这些网络控制包括业务数据流的检测、门控(Gating Control)、服务质量(QoS,Qualityof Service)控制以及基于数据流的计费规则等。PCRF将其制定的策略和计费规则发送给策略和计费执行实体(PCEF,Policy andControl Enforcement Function)执行;同时,PCRF还需要保证这些规则和用户的签约信息一致。PCRF制定策略和计费规则的依据包括:从AF获得的与业务相关的信息、从用户签约数据库(SPR,Subscription Profile Repository)获得的与与策略控制和计费相关的用户策略计费控制签约信息、以及通过Gx接口从PCEF获得的与承载相关网络的信息。
PCEF通常位于网关(GW,Gate-Way)内,在承载面执行PCRF所制定的策略和计费规则。如果是在线计费,则PCEF需要和在线计费***(OCS,Online Charging System)一起进行信用管理;离线计费时,PCEF和离线计费***(OFCS,Offline Charging System)之间交换相关的计费信息。其中,PCEF与PCRF之间的接口是Gx接口,PCEF与OCS之间的接口是Gy接口,PCEF与OFCS之间的接口是Gz接口。PCEF一般都位于网络的网关上,如EPS的分组数据网络网关(PDN-GW)、通用无线分组业务(GPRS,General PacketRadio Service)中的GPRS网关支持节点(GGSN)以及互联无线网局域网(I-WLAN,Interworking WLAN)中的分组数据网关(PDG,Packet Data Gateway)等。
承载绑定和事件报告实体(BBERF,Bearer Binding and EventReporting Function)通常位于接入网网关(Access Network Gateway)内。如当用户设备通过E-UTRAN接入EPS、服务网关S-GW与P-GW之间采用代理移动互联网协议版本6(PMIPv6,Proxy Mobile InternetProtocol version 6)协议时,S-GW中就存在BBERF。当用户设备通过可信任非3GPP接入网接入时,可信任非3GPP接入网关中也存在BBERF。
用户签约数据库(SPR)中存储有与策略控制和计费相关的用户策略计费控制签约信息。SPR和PCRF之间的使用Sp接口。
在实际使用过程中,MTC设备的数量众多,并且属于同一个MTC Subscriber的MTC设备可能会在某一个时间段内同时进行业务访问。这会导致在这期间,无线运营商的网络资源会被该MTCSubscriber大量占用,而无线运营商缺乏对MTC Subscriber占用的网络资源进行有效的控制的手段,因而造成正常用户的访问受限。
发明内容
本发明的主要目的在于提供一种用于分组业务的策略控制方法及分组业务***,以解决无线运营商无法有效控制MTC Subscriber占用的网络资源,因而造成用户访问受限的问题。
根据本发明的一个方面,提供了一种用于分组业务的策略控制方法,包括:策略和计费规则实体PCRF接收到一个用户组的一个用户的QoS授权请求;PCRF判断用户的保障带宽需求与已为用户组授权的保障带宽总和未超过用户组的组签约保障带宽GSGB;PCRF为用户授权保障带宽的QoS。
根据本发明的另一方面,还提供了一种分组业务***的策略和计费规则实体PCRF装置,包括:接收模块,用于接收一个用户组的一个用户的QoS授权请求;第一判断模块,用于判断用户的保障带宽需求与已为用户组授权的保障带宽总和未超过用户组的组签约保障带宽GSGB;第一分配模块,用于为用户授权保障带宽的QoS。
根据本发明的另一方面,还提供了一种分组业务***的用户签约数据库SPR,包括:设置模块,用于在SPR中设置用户组的组签约保障带宽GSGB;请求接收模块,用于接收策略和计费规则实体PCRF发送的签约文档请求;反馈模块,用于向PCRF反馈签约文档应答,签约文档应答包括所述GSGB。
根据本发明的另一方面,还提供了一种分组业务***,包括上述的PCRF和SPR。
根据本发明的另一方面,还提供了一种分组业务***中策略和计费规则实体PCRF的选择方法,包括:分组业务***的路由代理DRA根据一个用户组的组标识为用户组的所有用户的会话建立请求选择同一个PCRF。
本发明通过分组业务***中的同一个用户组在SPR中签约组签约保障带宽GSGB,使得同一个用户组占用的带宽资源得以控制,解决了无线运营商对同一个用户组如MTC Group占用的资源的控制问题,避免了同一个MTC Subscriber的多个MTC设备在某一时间段同时进行业务访问时,造成的用户访问受限,提升了用户体验。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为相关技术中的一种3GPP网络架构示意图;
图2为相关技术中的一种PCC的架构示意图;
图3为根据本发明实施例的一种用于分组业务的策略控制方法的步骤流程图;
图4为根据本发明实施例的另一种用于分组业务的策略控制方法的步骤流程图;
图5为根据本发明实施例的一种PCEF和PCRF的交互流程图;
图6为根据本发明实施例的一种BBERF、PCEF和PCRF的交互流程图;
图7为基于图5或图6所示实施例的一种PCRF策略控制方法的流程图;
图8为基于图5所示实施例的一种PCRF策略控制方法的流程图;
图9为基于图6所示实施例的一种PCRF策略控制方法的流程图;
图10为根据本发明实施例的一种PCRF选择方法的流程图;
图11为根据本发明实施例的另一种PCRF选择方法的流程图;
图12为根据本发明实施例的一种分组业务***的PCRF的结构框图;
图13为根据本发明实施例的另一种分组业务***的PCRF的结构框图;
图14为根据本发明实施例的一种分组业务***的SPR的结构框图;
图15为根据本发明实施例的一种分组业务***的结构框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
3GPP的网络架构如图1所示,UE通过EPS和UMTS接入MTC服务器,构成MTC***,实现MTC业务。下面介绍本发明的多个实施例,都以该MTC***为基础予以实施。
参照图3,示出了根据本发明实施例的一种用于分组业务的策略控制方法的步骤流程图,包括以下步骤:
步骤S302:PCRF接收到一个用户组的一个用户的QoS授权请求;
例如,以MTC***为例,PCRF接收到一个MTC Group中的一个用户A的IP-CAN会话请求。
步骤S304:PCRF判断该用户的保障带宽需求与已为用户组授权的保障带宽总和未超过用户组的组签约保障带宽GSGB;
例如,MTC***的PCRF判断用户A的IP-CAN会话请求所要求的带宽,与该MTC Group的授权MTC用户如用户B、C、和D所占用的带宽总和还未超过该MTC Group的组签约保障带宽GSGB。
步骤S306:PCRF为该用户授权所述保障带宽的QoS。
例如,PCRF为用户A授权其IP-CAN会话请求所要求的保障带宽的QoS。
相关技术中不对同时访问予以控制,而本实施例有效控制了一个用户组用户占用的带宽资源,解决了相关技术中无线运营商无法有效控制MTC Subscriber占用的网络资源的问题,避免了用户在同一个MTC Subscriber的多个MTC设备在某一时间段同时进行业务访问时,造成的用户访问受限,从而提升了用户体验。
参照图4,示出了根据本发明实施例的另一种用于分组业务的策略控制方法的步骤流程图,包括以下步骤:
步骤S402:PCEF/BBERF向路由代理发送一个用户组的一个用户的会话建立请求;
例如,MTC***的PCEF/BBERF向MTC的Diameter路由代理DRA发送MTC Group1的一个用户A的会话建立请求。该会话建立请求中可以包括用户标识、PDN(Packet Data Network,分组数据网)标识、和所属用户组的组标识等信息。
分组***中不同部分应用的网络协议不同,由PCEF或BBERF发送会话建立请求,最大限度地考虑了目前分组***的网络特点,使本发明实施例具有广泛的应用性。
步骤S404:路由代理检查是否为该用户所属的用户组选择了PCRF,若是,则执行步骤S408,若否,则执行步骤S406;
例如,DRA检查是否为用户A所属的MTC Group1选择了PCRF。本步骤以未选择PCRF为例。
步骤S406:路由代理为该用户所属的用户组选择PCRF;
例如,为用户A所属的MTC Group1选择PCRF1。
因为***中的多个PCRF之间没有交互,因此若不选择同一个PCRF,就无法对一个用户组用户占用的网络资源进行及时、准确地计算。通过为一个用户组的所有用户选择同一个PCRF,可以对该用户组用户占用的资源行集中控制,及时、准确掌握该用户组的网络资源占用情况。
步骤S408:向选择的PCRF发送该用户的会话建立请求;
本步骤中,可以由路由代理可以通过转发会话建立请求的方式向选择的PCRF发送该用户的会话建立请求,或者,通过路由代理向PCEF/BBERF返回携带PCRF信息的重定向消息,再由PCEF/BBERF向选择的PCRF发送该用户的会话建立请求。
路由代理通过转发或重定向方式向选择的PCRF发送用户的会话建立请求,充分利用了现有分组***的技术特点,实现简单,节约成本。
步骤S410:PCRF判断该用户的会话建立请求是否为其所属用户组的首个用户的会话建立请求,若是,则执行步骤S412,若否,则执行步骤S416;
本步骤中,PCRF判断用户A的会话请求为MTC Group1的首个会话建立请求。
步骤S412:PCRF向SPR发送签约文档请求;
该签约文档请求中可以携带有用户标识、PDN标识、和所属用户组的组标识等信息。
需要说明的是,在PCRF判断用户A的会话请求为除MTCGroup1的首个会话建立请求外的其它会话建立请求时,也可以再次向SPR发送签约文档请求。
步骤S414:PCRF接收SPR反馈的签约文档应答,并获取其中的GSGB;
SPR中保存有用户组的组签约保障带宽GSGB信息,SPR通过签约文档应答将该信息发送给PCRF,由PCRF获取用户所属用户组的GSGB。
通过步骤S410-S414,PCRF在一个用户组的用户发送首个会话请求时,即向SPR获取GSGB,可以有效计算该用户组内授权用户占用的带宽,以便对该用户组占用的网络资源进行有效控制。
步骤S416:PCRF判断该会话建立请求要求的保障带宽与已为用户组授权的保障带宽总和是否超过用户组的组签约保障带宽GSGB,若是,则执行步骤S420,若否,则执行步骤S418;
例如,因用户A的会话请求为MTC Group1中的首个会话请求,因此,MTC Group1中尚无其它授权用户,PCRF判断用户A的会话请求要求的带宽是否超过用户组的GSGB。本步骤以未超过为例。
步骤S418:PCRF为该用户的会话建立请求授权保障带宽的QoS,流程结束;
步骤S420:PCRF拒绝该用户的会话建立请求,流程结束。
本步骤中,当带宽不满足需求时,PCRF拒绝该用户的会话建立请求,在实际执行中,PCRF也可以根据***的带宽情况,为用户授权无保障的带宽。
无论是拒绝用户的会话建立请求,还是为用户授权无保障带宽的QoS,都最大限度地保证了其他用户组用户的网络资源使用。
以下图5至图11以MTC***为例,对本发明实施例的用于分组业务的策略控制方法中的PCEF/BBERF和PCRF的交互、PCRF策略控制方法和***中有多个PCRF时的同一PCRF选择方法予以说明。
参照图5,示出了根据本发明实施例的一种PCEF和PCRF的交互流程图。本实施例中描述了属于同一个用户组的用户MTC设备1和MTC设备2在分别建立IP-CAN会话过程中,PCEF和PCRF交互流程。其中MTC设备1和MTC设备2建立的IP-CAN会话都不使用BBERF。本实施例包括以下步骤:
步骤S502:在MTC设备1请求建立IP-CAN会话1的过程中,向PCEF 1所在的网关发送请求建立IP-CAN会话消息,在消息中携带有MTC设备1的用户标识1、PDN标识和MTC设备1属于的用户组的组标识。组标识可以有多种方式实现,如一个独立标识、或与PDN标识结合,即每一个MTC Group用一个PDN标识表示;
步骤S504:PCEF1向PCRF发送IP-CAN会话建立指示消息,在IP-CAN会话建立指示消息中携带有用户标识1、PDN标识、组标识和为MTC设备1分配的IP地址(IP Address1)。该消息建立了PCEF1和PCRF之间的Diameter会话,表示为Gx会话1;
步骤S506:PCRF向SPR发送签约文档请求,在签约文档请求中携带有用户标识1、PDN标识和组标识;
步骤S508:SPR根据组标识和用户标识1返回MTC设备1的签约信息,其中包括MTC设备1所属组的组签约信息、组签约保障带宽GSGB。若除了所有MTC设备都相同的组签约信息还包括各个MTC设备不相同的签约信息,SPR还会返回用户标识1对应的特定签约信息。可选地,SPR还会返回该组中所有MTC设备特定的签约信息给PCRF;
步骤S510:PCRF根据签约信息、接入信息以及网络策略制定策略,包括计费方式(离线或在线),计费模式(流量、时长、流量和时长、或事件)、默认承载的QoS(QCI、ARP)、APN-AMBR和Group-APN-AMBR,以及默认承载的PCC规则1,PCRF将以上策略发送给PCEF1;
步骤S512:PCEF1执行策略,PCEF1所在网关向MTC设备1返回应答建立IP-CAN会话消息,携带有IP Address1;
通过步骤S502~步骤S512后,MTC设备1建立了IP-CAN会话1,并且PCEF1与PCRF建立了Gx会话1,PCRF从SPR获取的组签约保障带宽。PCEF1和PCRF通过Gx会话1进行对IP-CAN会话1的策略计费控制。
步骤S514:在MTC设备2请求建立IP-CAN会话2的过程中,向PCEF2所则网关发送请求建立IP-CAN会话消息,在消息中携带有MTC设备2的用户标识2和PDN标识,以及MTC设备2属于的用户组的组标识。MTC设备1和MTC设备2属于同一个组,因此组标识是相同的。PCEF1和PCEF2可能相同,也可能不相同;
步骤S516:PCEF2向PCRF发送IP-CAN会话建立指示消息,在IP-CAN会话建立指示消息中携带有用户标识2、PDN标识、组标识和为MTC设备2分配的IP地址(IP Address2)。该消息建立了PCEF2和PCRF之间的Diameter会话,表示为Gx会话2;
步骤S518:PCRF根据组标识将Gx会话1和Gx会话2进行关联,即它们属于同一个组。若该组的签约信息没有各个MTC设备特定的签约或SPR已经将组内所有MTC设备特定的签约信息下发,则直接执行步骤S522,否则,PCRF向SPR发送签约文档请求,在签约文档请求中携带有用户标识2、PDN标识和组标识;
步骤S520:SPR根据用户标识2返回MTC设备2特定的签约信息;
步骤S522:PCRF制定策略,其中所有组成员相同的策略与步骤S510中一致,还有为IP-CAN会话2的默认承载的PCC规则2。一般的,PCC规则1和PCC规则2只有业务过滤器模板不同,而其他的策略信息认为是相同的。PCRF将PCC规则2发送给PCEF,其他的策略可以不发送;
步骤S524:PCEF执行PCC规则2和在步骤S510中所有组成员都相同的策略。PCEF所在网关向MTC设备2返回应答建立IP-CAN会话消息,携带有IP Address2。
通过类似上述流程,同一个组的MTC设备都可以建立IP-CAN,并且PCRF可以根据组标识将所有的Gx会话进行关联。
参照图6,示出了根据本发明实施例的一种BBERF、PCEF和PCRF的交互流程图。本实施例中描述了属于同一个用户组的用户MTC设备1和MTC设备2在分别建立IP-CAN会话过程中,BBERF、PCEF和PCRF交互流程。其中MTC设备1和MTC设备2建立的IP-CAN会话都使用BBERF。
步骤S602:在MTC设备1请求建立IP-CAN会话1的过程中,向BBERF 1所在网关发送请求建立IP-CAN会话的消息,请求建立IP-CAN会话1,在消息中携带有MTC设备1的用户标识1和PDN标识,以及MTC设备1属于的用户组的组标识。组标识可以有多种方式实现,如一个独立标识、或与PDN标识结合,即每一个MTCGroup用一个PDN标识表示;
步骤S604:BBERF1向PCRF发送网关控制会话建立消息,在网关控制会话建立消息中携带有用户标识1、PDN标识和组标识。该消息建立了BBERF 1和PCRF之间的Diameter会话(网关控制会话),表示为Gxx会话1;
步骤S606:PCRF向SPR发送签约文档请求,在签约文档请求中携带有用户标识1、PDN标识和组标识;
步骤S608:SPR根据用户标识1及组标识返回MTC设备1的签约信息,其中包括MTC设备1所属组的组策略信息,如组签约保障带宽GSGB。进一步地,SPR可能会将MTC设备1所属组的组用户标识全部下发给PCRF;
步骤S610:PCRF根据签约信息、接入信息以及网络策略制定策略,包括计费方式(离线或在线),计费模式(流量、时长、流量和时长、或事件)、默认承载的QoS(QCI、ARP)、APN-AMBR和Group-APN-AMBR,以及默认承载的PCC规则1和QoS规则1。PCRF将QoS规则1发送给BBERF1;
步骤S612:BBERF1执行QoS规则1。BBERF1所在网关向PCEF1所在网关发送请求建立IP-CAN会话的消息,消息中携带有MTC设备1的用户标识1和PDN标识,以及MTC设备1属于的用户组的组标识;
步骤S614:PCEF1所在网关为MTC设备1分配IP地址IPAddress1。PCEF1向PCRF发送IP-CAN会话建立指示消息,消息中携带有用户标识1、PDN标识和组标识。该消息建立了PCEF1和PCRF之间的Diameter会话,表示为Gx会话1;
步骤S616:PCRF根据用户标识1和PDN标识将Gxx会话1和Gx会话1进行关联。进而将步骤S610执行的策略(除QoS规则1)发送给PCEF1;
步骤S618:PCEF1执行策略。PCEF1所在网关向BBERF1所在网关应答建立IP-CAN会话消息,携带IP Address1;
步骤S620:BBERF1所在网关返回应答建立IP-CAN会话1消息,携带有IP Address1;
通过步骤S602~步骤S620后,MTC设备1建立了IP-CAN会话1,并且BBERF1与PCRF建立了Gxx会话1,PCEF1与PCRF建立了Gx会话1,PCRF从SPR获取的组签约保障带宽。BBERF1、PCEF1和PCRF通过Gxx会话1、Gx会话1进行对IP-CAN会话1的策略计费控制。
步骤S622:在MTC设备2请求建立IP-CAN会话2的过程中,向BBERF2所在网关发送请求建立IP-CAN会话消息,在请求建立IP-CAN会话消息中携带有MTC设备2的用户标识2和PDN标识,以及MTC设备2属于的用户组的组标识。MTC设备1和MTC设备2属于同一个组,因此组标识是相同的;
BBERF1和BBERF2可能相同也可能不同。
步骤S624:BBERF2向PCRF发送网关控制会话建立消息,在网关控制会话建立消息中携带有用户标识2、PDN标识和组标识。该消息建立了BBERF2和PCRF之间的Diameter会话(网关控制会话),表示为Gxx会话2;
步骤S626:PCRF根据组标识将Gxx会话2和Gxx会话1、Gx会话1进行关联,即它们属于同一个组。若该组的签约信息没有各个MTC设备特定的签约或SPR已经将组内所有MTC设备特定的签约信息下发,则直接执行步骤S630,否则,PCRF向SPR发送签约文档请求,在签约文档请求中携带有用户标识2、PDN标识和组标识;
步骤S628:SPR根据用户标识2返回MTC设备2特定的签约信息;
步骤S630:PCRF制定策略,其中包括所有组成员相同的策略,还有为IP-CAN会话2的默认承载制定的PCC规则2和QoS规则2。一般的,PCC规则1/QoS规则1和PCC规则2/QoS规则2只有业务过滤器模板不同,而其他的策略信息也认为是相同的。PCRF将QoS规则2发送给BBERF2;
步骤S632:BBERF2执行QoS规则2。BBERF所在网关向PCEF2所在网关发送请求建立IP-CAN会话2的消息,消息中携带有MTC设备2的用户标识2和PDN标识,以及MTC设备2属于的用户组的组标识;
步骤S634:PCEF2所在网关为MTC设备2分配IP地址(IPAddress2)。PCEF2向PCRF发送IP-CAN会话建立指示消息,在IP-CAN会话建立指示消息中携带有用户标识2、组标识、PDN标识和IP Address2。该消息建立了Diameter会话,表示为Gx会话2;
步骤S636:PCRF根据用户标识、PDN标识将Gxx会话2和Gx会话2进行关联。将步骤S630中制定的策略(除QoS规则2)发送给PCEF2;
步骤S638:PCEF2执行PCC规则2和在步骤S610中所有组成员都相同的策略。PCEF2所在网关向BBERF2所在网关返回应答建立回IP-CAN会话消息,携带有IP Address2。
步骤S640:BBERF2所在网关返回应答建立IP-CAN会话消息,携带有IP Address2。
通过类似上述流程,同一个组的MTC设备都可以建立IP-CAN,并且PCRF可以根据组标识将组内所有IP-CAN会话相关的Gxx、Gx会话进行关联,PCRF也从SPR中获取的组签约保障带宽。
参照图7,示出了基于图5和图6所示实施例的一种PCRF策略控制方法的流程图。本实施例描述的是基于图5或图6所示实施例建立的IP-CAN会话后,由于MTC Group中一个MTC设备进行业务访问,PCRF根据AF提供的业务信息进行QoS授权以及发起资源预留的过程。在这个MTC设备之前,已经有多个MTC设备请求了业务访问,并且PCRF根据AF提供的业务信息进行QoS授权,QoS参数包括保障带宽GBR,最大带宽MBR等,即PCRF为这些业务的访问提供了保障带宽。
步骤S702:AF向PCRF发送业务/应用消息,消息中携带IPAddress。消息中还可以携带业务信息,如媒体类型,QoS信息等,其中QoS部分包括该业务请求的上下行最大带宽;
步骤S704:PCRF保存AF提供的业务信息。PCRF根据IPAddress进行会话绑定,即该业务信息所对应的IP-CAN会话,从而进一步对应到MTC Group。
步骤S706:PCRF根据业务信息等进行策略决策。PCRF根据媒体类型等判断需要为该业务的访问提供保障带宽GBR。此时PCRF将根据组签约保障带宽GSGB进行如下决策:
(1)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和还没有超过GSGB,则PCRF进行QoS授权,QoS参数包括GBR、MBR,即PCRF为该MTC设备访问业务继续提供保障带宽。从而PCRF在制定的PCC规则中含有GBR和MBR。对于图6所示实施例,QoS规则中也含有GBR和MBR;
(2)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和超过GSGB,PCRF可以执行如下决策之一:
(2a)PCRF为该MTC设备的业务访问提供非保障带宽,在PCRF在指定的PCC规则不含GBR。对于图6所示实施例,QoS规则中也不含有GBR和MBR;
(2b)PCRF拒绝AF请求的QoS。
若PCRF的决策为(1)或(2a),则执行步骤S708-S714,若为(2b),则执行步骤S716-S718。
步骤S708:PCRF通过向BBERF发送网关和QoS规则提供消息,携带QoS规则;
步骤S710:BBERF安装QoS规则,BBERF根据QoS规则为IP-CAN会话执行资源预留过程,BBERF向PCRF返回确认消息。
步骤S708、S710针对图6所示实施例执行。
步骤S712:PCRF向PCEF发送策略计费规则提供消息,携带PCC规则;
步骤S714:PCEF安装PCC规则。针对图5所示实施例,PCEF根据PCC规则为IP-CAN会话执行资源预留过程。PCEF向PCRF返回确认消息。
步骤S716:PCRF向AF发送通知消息,通知AF QoS请求被拒绝;
步骤S718:AF返回确认消息。
参照图8,示出了基于图5所示实施例的一种PCRF策略控制方法的流程图。本实施例描述的是基于图5所示实施例建立的IP-CAN会话后,由于MTC Group中一个MTC设备进行业务访问,PCRF根据PCEF提供的MTC设备请求的QoS信息进行QoS授权以及发起资源预留的过程。在这个MTC设备之前,已经有多个MTC设备请求了业务访问,并且PCRF根据PCEF提供的MTC设备请求的QoS信息进行QoS授权,QoS参数包括保障带宽GBR,最大带宽MBR等。即PCRF为这些业务的访问提供了保障带宽。
步骤S802:PCEF收到来自MTC设备的QoS请求消息,消息中携带请求的QoS信息,包括GBR;
步骤S804:PCEF向PCRF发送网关控制和QoS规则请求消息,消息中携带请求的QoS信息,包括GBR;
步骤S806:PCRF进行策略决策。由于MTC设备请求了GBR,因此PCRF将根据组签约保障带宽GSGB进行如下决策:
(1)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和还没有超过GSGB,则PCRF进行QoS授权,QoS参数包括GBR、MBR,即PCRF为该MTC设备访问业务继续提供保障带宽。从而PCRF在制定的PCC规则和QoS规则中含有GBR和MBR;
(2)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和超过GSGB,PCRF可以执行如下决策之一:
(2a)PCRF为该MTC设备的业务访问提供非保障带宽,在PCRF在指定的PCC规则和QoS规则中不含GBR和MBR;
(2b)PCRF拒绝MTC设备请求的QoS。
步骤S808:对于(1)或(2a),PCRF向PCEF发送策略和计费规则提供消息,携带PCC规则;
步骤S810:PCEF执行策略;
步骤S812:对于(1)或(2a),PCEF返回确认消息。
参照图9,示出了基于图6所示实施例的一种PCRF策略控制方法的流程图。本实施例描述的是基于图6所示实施例建立的IP-CAN会话后,由于MTC Group中一个MTC设备进行业务访问,PCRF根据PCEF提供的MTC设备请求的QoS信息进行QoS授权以及发起资源预留的过程。在这个MTC设备之前,已经有多个MTC设备请求了业务访问,并且PCRF根据PCEF提供的MTC设备请求的QoS信息进行QoS授权,QoS参数包括保障带宽GBR,最大带宽MBR等。即PCRF为这些业务的访问提供了保障带宽。
步骤S902:BBERF收到来自MTC设备的QoS请求消息,消息中携带请求的QoS信息,包括GBR;
步骤S904:BBERF向PCRF发送网关控制和QoS规则请求消息,消息中携带请求的QoS信息,包括GBR;
步骤S906:PCRF进行策略决策。由于MTC设备请求了GBR,因此PCRF将根据组签约保障带宽GSGB进行如下决策:
(1)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和还没有超过GSGB,则PCRF进行QoS授权,QoS参数包括GBR、MBR,即PCRF为该MTC设备访问业务继续提供保障带宽。从而PCRF在制定的PCC规则和QoS规则中含有GBR和MBR;
(2)若PCRF已经为该MTC Group的授权MTC设备的授权GBR总和超过GSGB,PCRF可以执行如下决策之一:
(2a)PCRF为该MTC设备的业务访问提供非保障带宽,在PCRF在指定的PCC规则和QoS规则中不含GBR和MBR;
(2b)PCRF拒绝MTC设备请求的QoS。
步骤S908:PCRF向BBERF返回网关控制和QoS规则请求确认消息,对于(1)或(2a),消息中携带QoS规则,对于(2b),消息中携带拒绝QoS请求指示;
步骤S910:对于(1)或(2a),BBERF安装QoS规则并执行;
步骤S912:BBERF所在网关返回确认消息;
步骤S914:对于(1)或(2a),PCRF向PCEF发送策略和计费规则提供消息,携带PCC规则;
步骤S916:对于(1)或(2a),PCEF返回确认消息。
在图5至图9所示的实施例中,MTC Group的所有MTC设备建立的IP-CAN会话都选择了同一个PCRF,这包括两种情况:(1)无线运营商网络的一个PCRF域中只存在一个PCRF,因此MTCGroup的所有的MTC设备建立的IP-CAN会话由这个PCRF进行策略控制;(2)无线运营商网络的一个PCRF域中存在多个PCRF,这时,Diameter路由代理DRA为MTC Group的所有MTC设备建立的IP-CAN会话选择同一个PCRF。
以下对上述第二种情况,即一个PCRF域中存在多个PCRF时的同一PCRF选择方法作以说明。
参照图10,示出了根据本发明实施例的一种PCRF选择方法的流程图。本实施例描述的是MTC设备1和MTC设备2在建立IP-CAN会话过程中,DRA为其选择同一个PCRF的流程。其中,DRA的实现方式为代理(Proxy)。
步骤S1002:BBERF1/PCEF1收到外部触发条件,请求建立Diameter会话。对于图5所示实施例,本步骤即为步骤S502;对于图6所示实施例,本步骤即为步骤S602;
步骤S1004:BBERF1/PCEF1向DRA发送Diameter会话建立请求消息,消息中携带组标识信息。组标识信息的具体实现方式可以是独立的标识参数,也可以用户标识或PDN标识来体现,或者由用户标识和PDN标识的组合来体现;对于图5所示实施例,本步骤即为步骤S504;对于图6所示实施例,本步骤即为步骤S604;
步骤S1006:DRA根据组标识信息检查是否已经为该IP-CAN会话所属的MTC Group选择了PCRF。由于MTC设备1是该MTCGroup第一个建立IP-CAN会话的MTC设备。因此DRA还没有相关记录信息。DRA为该组选择一个PCRF,即PCRF1,并保存相关记录(组标识信息,PCRF1标识);
步骤S1008:DRA向PCRF1转发Diameter会话建立请求消息;
步骤S1010:PCRF1进行策略决策,制定PCC规则,针对图6所示实施例还会制定QoS规则。之后,PCRF1向DRA返回应答消息,消息中携带PCC规则(图5所示实施例)或QoS规则(图6所示实施例);
步骤S1012:DRA向BBERF1/PCEF1返回应答消息;
步骤S1014:BBERF2/PCEF2收到外部触发条件,请求建立Diameter会话。对于图5所示实施一,本步骤即为步骤S514;对于图6所示实施例,本步骤即为步骤S622;
步骤S1016:BBERF2/PCEF2向DRA发送Diameter会话建立请求消息,消息中携带组标识信息。由于MTC设备1和MTC设备2属于同一个MTC Group,因此组标识信息是相同的;对于图5所示实施例,本步骤即为步骤S516;对于图6所示实施例,本步骤即为步骤S624;
步骤S1018:DRA根据组标识信息检查是否已经为该IP-CAN会话所属的MTC Group选择了PCRF。由于在步骤S1006中,DRA已经为该MTC Group选择了PCRF1,因此DRA向PCRF1转发Diameter会话建立请求消息;
步骤S1020:PCRF1进行策略决策,制定PCC规则,针对图6所示实施例还会制定QoS规则。之后,PCRF1向DRA返回应答消息,消息中携带PCC规则(图5所示实施例)或QoS规则(图6所示实施例);
步骤S1022:DRA向BBERF2/PCEF2返回应答消息。
参照图11,示出了根据本发明实施例的另一种PCRF选择方法的流程图。本实施例描述的是MTC设备1和MTC设备2在建立IP-CAN会话过程中,DRA为其选择同一个PCRF的流程。其中,DRA的实现方式为重定向(Redirect)。
步骤S1102:BBERF1/PCEF1收到外部触发条件,请求建立Diameter会话。对于图5所示实施例,本步骤即为步骤S502;对于图6所示实施例,本步骤即为步骤S602;
步骤S1104:BBERF1/PCEF1向DRA发送Diameter会话建立请求消息,消息中携带组标识信息。组标识信息的具体实现方式可以是独立的标识参数,也可以用户标识或PDN标识来体现,或者由用户标识和PDN标识的组合来体现;对于图5所示实施例,本步骤即为步骤S504;对于图6所示实施例,本步骤即为步骤S604;
步骤S1106:DRA根据组标识信息检查是否已经为该IP-CAN会话所属的MTC Group选择了PCRF。由于MTC设备1是该MTCGroup第一个建立IP-CAN会话的MTC设备。因此DRA还没有相关记录信息。DRA为该组选择一个PCRF,即PCRF1,并保存相关记录(组标识信息,PCRF1标识);
步骤S1108:DRA向BBERF1/PCEF1返回重定向消息,消息中携带PCRF1标识;
步骤S1110:BBERF1/PCEF1向PCRF1发送Diameter会话建立请求消息;
步骤S1112:PCRF1进行策略决策,制定PCC规则,针对图6所示实施例还会制定QoS规则。之后,PCRF1向BBERF1/PCEF1返回应答消息,消息中携带PCC规则(图5所示实施例)或QoS规则(图6所示实施例);
步骤S1114:BBERF2/PCEF2收到外部触发条件,请求建立Diameter会话。对于图5所示实施例,本步骤即为步骤S514;对于图6所示实施例,本步骤即为步骤S622;
步骤S1116:BBERF2/PCEF2向DRA发送Diameter会话建立请求消息,消息中携带组标识信息。由于MTC设备1和MTC设备2属于同一个MTC Group,因此组标识信息是相同的;对于图5所示实施例,本步骤即为步骤S516;对于图6所示实施例,本步骤即为步骤S624;
步骤S1118:DRA根据组标识信息检查是否已经为该IP-CAN会话所属的MTC Group选择了PCRF。由于在步骤S1106中,DRA已经为该MTC Group选择了PCRF1,因此DRA向BBERF2/PCEF2返回重定向消息,消息中携带PCRF1标识;
步骤S1120:BBERF2/PCEF2向PCRF1发送Diameter会话建立请求消息;
步骤S1122:PCRF1进行策略决策,制定PCC规则,针对图6所示实施例还会制定QoS规则。之后,PCRF1向BBERF2/PCEF2返回应答消息,消息中携带PCC规则(图5所示实施例)或QoS规则(图6所示实施例)。
需要说明的是,本实施例中的PCRF选择方法不仅用于本发明实施例,同样适用于具有多个PCRF的任何其他分组业务***中,本领域技术人员可以参照上述实施例,在其他分组业务***中实施本发明的PCRF选择方法。
参照图12,示出了根据本发明实施例的一种分组业务***的PCRF的结构框图,包括:
接收模块1202,用于接收一个用户组的一个用户的QoS授权请求;第一判断模块1204,用于判断所述用户的保障带宽需求与已为其所属的用户组授权的保障带宽总和未超过该用户组的组签约保障带宽GSGB;第一分配模块1206,用于为该用户授权所述QoS授权请求要求的保障带宽的QoS。
例如,MTC***中,PCRF的接收模块1202接收到用户组MTCGroup1的用户A的会话请求,第一判断模块1204判断需要为该用户授权的保障带宽与MTC Group1的授权用户占用的带宽总和未超过MTC Group1的组签约保障带宽GSGB,这时,第一分配模块1206为该用户A授权其会话请求要求的保障带宽的QoS。
参照图13,示出了根据本发明实施例的另一种分组业务***的PCRF的结构框图,包括:
会话建立模块1302,用于接受一个用户组用户的会话请求;组信息模块1304,用于向用户签约数据库SPR发送签约文档请求,并接收SPR反馈的签约文档应答,该签约文档应答包括所述用户组的GSGB;获取模块1306,用于获取所述用户组的GSGB;接收模块1308,用于接收所述用户组的一个用户的QoS授权请求;第一判断模块1310,用于判断该用户的保障带宽需求与已为其所属的用户组授权的保障带宽总和未超过该用户组的组签约保障带宽GSGB;第一分配模块1312,用于为该用户授权保障带宽的QoS;第二判断模块1314,用于判断该用户的保障带宽需求与已为所述用户组授权的保障带宽总和超过该用户组的组签约保障带宽GSGB;第二分配模块1316,用于拒绝所述用户的QoS授权请求,或者,为所述用户授权无保障带宽的QoS。
例如,MTC***的PCRF的首会话模块1302接受一个用户组如MTC Group1的一个用户如用户A的会话请求,该会话请求是MTC Group1的首个会话请求。这时,组信息模块1304向用户签约数据库SPR发送签约文档请求,获取模块1306从接收的SPR反馈的签约文档应答中获取MTC Group1的GSGB。接收模块1308接收到MTC Group1的该用户如用户A的会话请求,若第一判断模块1310判断需要为该用户授权的保障带宽与MTC Group1的授权用户占用的带宽总和未超过MTC Group1的组签约保障带宽GSGB,则第一分配模块1312为该用户授权其需求的保障带宽的QoS(如为用户A发送的MTC Group1的首个会话请求时,且该会话请求要求的带宽未超过MTC Group1的GSGB,则第一分配模块1312为用户A授权其需求的保障带宽的QoS);若第二判断模块1314判断该用户的保障带宽需求与MTC Group1的授权用户占用的带宽总和超过MTC Group1的组签约保障带宽GSGB,则第二分配模块1316拒绝该用户的会话请求,或者,为该用户授权无保障带宽的QoS。
当接收模块1308在接收到MTC Group1的一个用户的会话请求不是MTC Group1的首个会话请求时,若第一判断模块1310判断该用户需求的保障带宽与MTC Group1的授权用户占用的带宽总和未超过MTC Group1的组签约保障带宽GSGB,则第一分配模块1312为该用户授权其需求的保障带宽的QoS;若第二判断模块1314判断该用户需求的保障带宽与MTC Group1的授权用户占用的带宽总和超过MTC Group1的组签约保障带宽GSGB,则第二分配模块1316拒绝该用户的会话请求,或者,为该用户授权无保障带宽的QoS(如有用户B,且PCRF已为用户A授权过带宽,且用户B的保障带宽需求与用户A已授权的带宽总和超过MTC Group1的GSGB,则第二分配模块1316拒绝用户B的会话请求,或者,为用户B授权无保障带宽的QoS)。
参照图14,示出了根据本发明实施例的一种分组业务***的SPR的结构框图,包括:
设置模块1402,用于在SPR中设置用户组的组签约保障带宽GSGB;请求接收模块1404,用于接收PCRF发送的签约文档请求;反馈模块1406,用于向PCRF反馈签约文档应答,所述签约文档应答包括组签约保障带宽GSGB。
例如,MTC***中,SPR的设置模块1402首先在SPR中设置一个或多个用户组的GSGB。当请求接收模块1404接收到PCRF发送的携带有一个用户组的一个用户(特别是一个用户组的首个用户)的用户信息的签约文档请求后,反馈模块1406向PCRF反馈包含有该用户组的GSGB的签约文档应答,或者,SPR在未向PCRF反馈过该用户组的GSGB的情况下,反馈模块1406向PCRF一次性反馈该用户组的GSGB。
参照图15,示出了根据本发明实施例的一种分组业务***的结构框图,包括:PCRF1502,SPR1504。优选的,还可以包括路由代理1506,PCEF1508,BBERF1510。
其中,PCRF1502包括:接收模块15022,用于接收一个用户组的一个用户的QoS授权请求;第一判断模块15024,用于判断该用户的保障带宽需求与已为其所属的用户组授权的保障带宽总和未超过该用户组的组签约保障带宽GSGB;第一分配模块15026,用于为该用户授权所述保障带宽的QoS。
PCRF1502可以为一个或多个。当PCRF1502为多个时,路由代理1506为用户组的所有用户的会话请求选择同一个PCRF1502。
其中,SPR1504包括:设置模块15042,用于在SPR中设置用户组的组签约保障带宽GSGB;请求接收模块15044,用于接收PCRF发送的签约文档请求;反馈模块15046,用于向PCRF反馈签约文档应答,所述签约文档应答包括组签约保障带宽GSGB。
优选的,PCRF1502还可以包括:会话建立模块,用于接受一个用户组用户的会话建立请求;组信息模块,用于向用户签约数据库SPR发送签约文档请求,并接收SPR反馈的签约文档应答,该签约文档应答包括所述用户组的GSGB;获取模块,用于获取所述用户组的GSGB;第二判断模块,用于判断所述用户的保障带宽需求与已为所述用户组授权的保障带宽总和超过该用户组的组签约保障带宽GSGB;第二分配模块,用于拒绝所述用户的QoS授权请求,或者,为所述用户授权无保障带宽的QoS。
需要说明的是,本发明的多个实施例以MTC***为例,这是因为MTC***是较为典型的分组***,可以方便地将本发明应用于MTC***中,但本领域技术人员应当理解,其它分组业务***在实现本发明时,可以参照MTC***实施例类似进行,在此不再赘述。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (16)
1.一种用于分组业务的策略控制方法,其特征在于,包括:
策略和计费规则实体PCRF接收到一个用户组的一个用户的QoS授权请求;
所述PCRF判断所述用户的保障带宽需求与已为所述用户组授权的保障带宽总和未超过所述用户组的组签约保障带宽GSGB;
所述PCRF为所述用户授权所述保障带宽的QoS。
2.根据权利要求1所述的方法,其特征在于,所述用户组的GSGB通过以下步骤获得:
所述PCRF接收所述用户组用户的会话建立请求;
所述PCRF向用户签约数据库SPR发送签约文档请求,并接收所述SPR反馈的签约文档应答,所述签约文档应答包括所述用户组的GSGB;
所述PCRF获取所述用户组的GSGB。
3.根据权利要求2所述的方法,其特征在于,所述会话建立请求为所述用户组的首个用户的会话建立请求。
4.根据权利要求2所述的方法,其特征在于,所述PCRF包括多个,在所述PCRF接收所述用户组用户的会话建立请求步骤之前还包括:
路由代理DRA为所述用户组的所有用户的会话建立请求选择同一个PCRF。
5.根据权利要求4所述的方法,其特征在于,所述路由代理DRA为所述用户组的所有用户的会话建立请求选择同一个PCRF的步骤包括:
所述路由代理DRA通过转发或重定向所述会话建立请求到同一个PCRF为所述用户组的所有用户的会话建立请求选择同一个PCRF。
6.根据权利要求1所述的方法,其特征在于,在所述PCRF为所述用户授权所述保障带宽步骤之后,还包括:
所述PCRF判断所述用户的保障带宽需求与已为所述用户组授权的保障带宽总和超过所述用户组的组签约保障带宽GSGB;
所述PCRF为所述用户授权无保障带宽的QoS;或者,拒绝所述用户的QoS授权请求。
7.根据权利要求2所述的方法,其特征在于,所述PCRF接收到用户组用户的会话建立请求的步骤包括:
所述PCRF接收到策略和计费执行实体PCEF发送的一个用户组的一个用户的IP-CAN会话建立请求;
或者,
所述PCRF接收到承载绑定和事件报告实体BBERF发送的一个用户组的一个用户的网关控制会话建立请求。
8.根据权利要求1至7任一项所述的方法,其特征在于,所述用户组为接入机器类型通信MTC用户组。
9.一种分组业务***的策略和计费规则实体PCRF,其特征在于,包括:
接收模块,用于接收一个用户组的一个用户的QoS授权请求;
第一判断模块,用于判断所述用户的保障带宽需求与已为所述用户组授权的保障带宽总和未超过所述用户组的组签约保障带宽GSGB;
第一分配模块,用于为所述用户授权所述保障带宽的QoS。
10.根据权利要求9所述的PCRF,其特征在于,还包括:
会话建立模块,用于接受所述用户组用户的会话建立请求;
组信息模块,用于向用户签约数据库SPR发送签约文档请求,并接收所述SPR反馈的签约文档应答,所述签约文档应答包括所述用户组的GSGB;
获取模块,用于获取所述用户组的GSGB。
11.根据权利要求9所述的PCRF,其特征在于,还包括:
第二判断模块,判断所述用户的保障带宽需求与已为所述用户组授权的保障带宽总和超过所述用户组的组签约保障带宽GSGB;
第二分配模块,用于拒绝所述用户的QoS授权请求,或者,为所述用户授权无保障带宽的QoS。
12.根据权利要求9至11任一项所述的PCRF,其特征在于,所述用户组为接入机器类型通信MTC用户组。
13.一种分组业务***的用户签约数据库SPR,其特征在于,包括:
设置模块,用于在所述SPR中设置用户组的组签约保障带宽GSGB;
请求接收模块,用于接收策略和计费规则实体PCRF发送的签约文档请求;
反馈模块,用于向所述PCRF反馈签约文档应答,所述签约文档应答包括所述GSGB。
14.一种分组业务***,其特征在于,包括:
根据权利要求9至11任一项所述的PCRF;
根据权利要求13所述的SPR。
15.一种分组业务***中策略和计费规则实体PCRF的选择方法,所述分组业务***包括多个PCRF,其特征在于,包括:
所述分组业务***的路由代理DRA根据一个用户组的组标识为所述用户组的所有用户的会话建立请求选择同一个PCRF。
16.根据权利要求15所述的方法,其特征在于,所述分组业务***的路由代理DRA根据一个用户组的组标识为所述用户组的所有用户的会话建立请求选择同一个PCRF的步骤包括:
所述路由代理DRA根据一个用户组的组标识,通过转发或重定向所述会话建立请求到同一个PCRF为所述用户组的所有用户的会话请求选择同一个PCRF。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010173682.8A CN102238645B (zh) | 2010-04-28 | 2010-04-28 | 用于分组业务的策略控制方法及分组业务*** |
PCT/CN2011/071698 WO2011134319A1 (zh) | 2010-04-28 | 2011-03-10 | 用于分组业务的策略控制方法及分组业务*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010173682.8A CN102238645B (zh) | 2010-04-28 | 2010-04-28 | 用于分组业务的策略控制方法及分组业务*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102238645A true CN102238645A (zh) | 2011-11-09 |
CN102238645B CN102238645B (zh) | 2016-04-13 |
Family
ID=44860840
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010173682.8A Expired - Fee Related CN102238645B (zh) | 2010-04-28 | 2010-04-28 | 用于分组业务的策略控制方法及分组业务*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN102238645B (zh) |
WO (1) | WO2011134319A1 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103490908A (zh) * | 2012-06-12 | 2014-01-01 | 中兴通讯股份有限公司 | 策略和计费规则功能的选择方法、装置及*** |
CN103841538A (zh) * | 2012-11-22 | 2014-06-04 | 中兴通讯股份有限公司 | 管理数据流的方法和*** |
WO2016062025A1 (zh) * | 2014-10-20 | 2016-04-28 | 中兴通讯股份有限公司 | 一种策略和计费规则功能的选择方法及装置 |
WO2018032920A1 (zh) * | 2016-08-15 | 2018-02-22 | 华为技术有限公司 | 控制网络切片带宽的方法、装置和*** |
CN110944361A (zh) * | 2018-09-21 | 2020-03-31 | 华为技术有限公司 | 用于负载均衡的方法与网元 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10021038B2 (en) * | 2013-05-17 | 2018-07-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Sharing resource reservation |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1968139A (zh) * | 2006-06-15 | 2007-05-23 | 华为技术有限公司 | 策略与计费控制中用户签约信息的处理方法及装置 |
CN101378328A (zh) * | 2007-08-30 | 2009-03-04 | 华为技术有限公司 | 一种应用控制策略的方法、装置及*** |
CN101394291A (zh) * | 2007-09-17 | 2009-03-25 | 华为技术有限公司 | 一种处理业务的方法、装置及*** |
CN101483826A (zh) * | 2008-01-07 | 2009-07-15 | 华为技术有限公司 | 选择策略和计费规则功能实体的方法和装置 |
-
2010
- 2010-04-28 CN CN201010173682.8A patent/CN102238645B/zh not_active Expired - Fee Related
-
2011
- 2011-03-10 WO PCT/CN2011/071698 patent/WO2011134319A1/zh active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1968139A (zh) * | 2006-06-15 | 2007-05-23 | 华为技术有限公司 | 策略与计费控制中用户签约信息的处理方法及装置 |
CN101378328A (zh) * | 2007-08-30 | 2009-03-04 | 华为技术有限公司 | 一种应用控制策略的方法、装置及*** |
CN101394291A (zh) * | 2007-09-17 | 2009-03-25 | 华为技术有限公司 | 一种处理业务的方法、装置及*** |
CN101483826A (zh) * | 2008-01-07 | 2009-07-15 | 华为技术有限公司 | 选择策略和计费规则功能实体的方法和装置 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103490908A (zh) * | 2012-06-12 | 2014-01-01 | 中兴通讯股份有限公司 | 策略和计费规则功能的选择方法、装置及*** |
CN103490908B (zh) * | 2012-06-12 | 2019-05-31 | 中兴通讯股份有限公司 | 策略和计费规则功能的选择方法、装置及*** |
CN103841538A (zh) * | 2012-11-22 | 2014-06-04 | 中兴通讯股份有限公司 | 管理数据流的方法和*** |
CN103841538B (zh) * | 2012-11-22 | 2019-06-25 | 中兴通讯股份有限公司 | 管理数据流的方法和*** |
WO2016062025A1 (zh) * | 2014-10-20 | 2016-04-28 | 中兴通讯股份有限公司 | 一种策略和计费规则功能的选择方法及装置 |
WO2018032920A1 (zh) * | 2016-08-15 | 2018-02-22 | 华为技术有限公司 | 控制网络切片带宽的方法、装置和*** |
CN107770818A (zh) * | 2016-08-15 | 2018-03-06 | 华为技术有限公司 | 控制网络切片带宽的方法、装置和*** |
CN107770818B (zh) * | 2016-08-15 | 2020-09-11 | 华为技术有限公司 | 控制网络切片带宽的方法、装置和*** |
CN110944361A (zh) * | 2018-09-21 | 2020-03-31 | 华为技术有限公司 | 用于负载均衡的方法与网元 |
US11564115B2 (en) | 2018-09-21 | 2023-01-24 | Huawei Technologies Co., Ltd. | Load balancing method and network element |
Also Published As
Publication number | Publication date |
---|---|
CN102238645B (zh) | 2016-04-13 |
WO2011134319A1 (zh) | 2011-11-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100579302C (zh) | 一种非漫游场景下策略和计费规则功能服务器的选择方法 | |
CN100536401C (zh) | 策略与计费控制中用户签约信息的处理方法及装置 | |
CN100544264C (zh) | 一种在演进网络中管理用户策略计费控制签约信息的方法 | |
CN101374055B (zh) | 计费处理方法和网络***、分组数据网络网关及计费*** | |
EP1309213B1 (en) | A method and system for providing a service | |
CN103444148A (zh) | 控制部署的业务检测功能节点的路由选择或绕过的网络节点和方法 | |
KR20120062804A (ko) | 차징 시스템 및 방법 | |
CN101227391A (zh) | 非漫游场景下策略和计费规则功能实体的选择方法 | |
CN101277541A (zh) | 一种Diameter路由实体转发消息的方法 | |
JP2012509041A (ja) | 制限付きポリシー及び課金制御ケイパビリティの検出及び報告 | |
CN108353251B (zh) | 用于多个存在报告区域的装置和方法 | |
CN104349297A (zh) | 一种网间签约授权的计费策略方法及装置 | |
CN102215469A (zh) | 一种基于网络负荷的策略计费控制方法和*** | |
CN102238645A (zh) | 用于分组业务的策略控制方法及分组业务*** | |
CN104955085A (zh) | 一种漫游场景下的应用检测控制方法及v-pcrf | |
CN102123035B (zh) | 策略和计费规则功能实体的选择方法、装置及*** | |
CN101355806B (zh) | 网络会话释放方法、装置及*** | |
CN101232433A (zh) | 信令承载建立方法和建立信令承载的***及装置 | |
CN102480718B (zh) | 漫游场景支持被赞助数据连接的方法和*** | |
EP2911427A1 (en) | Method and system for differentiating subscriber | |
WO2011098155A1 (en) | Method and apparatus for use with ip connectivity access network | |
CN101355561B (zh) | Dra的会话消息管理方法和*** | |
CN103313431A (zh) | Tdf会话的处理方法及pcrf | |
CN101312561A (zh) | 无线通信***及无线通信方法 | |
CN102791042B (zh) | S9子会话建立方法、***及pcrf |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20160413 Termination date: 20190428 |