CN103391529A - 业务推送方法及装置 - Google Patents

Abstract

本发明实施例提供了一种业务推送方法及装置，该方法包括：PCRF接收来自应用服务器或者AF发送的业务有效时间；PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略。本发明实施例根据业务有效时间和承载网络的拥塞情况对业务的推送策略进行决策，从而可以避免网络拥塞情况下向用户推送该业务，达到合理利用承载网络资源、提高用户体验的目的。

Description

业务推送方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种业务推送方法及装置。

背景技术

目前，第三代合作伙伴计划（3rd Generation Partnership Project，简称为3GPP）定义的策略和计费控制架构（Policy and Charging Control，简称为PCC）获得了广泛应用。图1是根据相关技术的PCC架构的示意图，如图1所示，包括应用功能（Application Function，简称为AF）、策略和计费规则功能（Policy and Charging Rules Function，简称为PCRF）、用户签约数据库（Subscription Profile Repository，简称为SPR）、策略和计费执行功能（Policyand Charging Enforcement Function，简称为PCEF）、承载绑定和事件上报功能（BearerBinding and Event Report Function，简称为BBERF）、在线计费系统（Online ChargingSystem，简称为OCS）和离线计费系统（Offline Charging System，简称为OFCS），下面分别对其进行描述。

AF用于提供为业务制定控制策略所需的业务信息，例如业务开展所使用的互联网协议（Internet Protocol，简称为IP）地址、端口号，业务开展所需要的带宽、服务质量（Qualityof Service）等信息。

PCRF为业务使用承载网络资源进行QoS和计费策略的制订。PCRF制定所述控制策略需要结合从AF接收的业务信息，从SPR接收的用户签约信息，运营商配置的策略等。PCRF将为业务制定的控制策略下发给PCEF或者BBERF执行。同时PCRF可以向PCEF和/或BBERF订阅承载层相关事件，以便当承载层发生所述事件时及时感知，并更改控制策略。

PCEF用于执行PCRF下发的或者PCEF上预配置的PCC规则，并将所述规则绑定到与之匹配的承载上。PCEF根据PCC规则中包含五元组信息对承载网络上传输的IP报文进行检测，当IP报文和某一个规则的五元组匹配的时候，则按照规则对所述IP报文进行相应的QoS和计费控制。同时如果当PCRF向PCEF订阅了相关承载层事件，并且当所述事件发生后，PCEF需要向PCRF及时上报所述事件。

当承载网络采用代理移动性IP（Proxy Mobility Internet Protocol，简称为PMIP）协议或者双栈移动性IP（Dual Stack Mobility Internet Protocol，简称为DSMIP）协议的时候，承载网络需要配置BBERF功能。BBERF主要接收PCRF下发的QoS规则，并将所述规则绑定到与之匹配的承载上。BBERF根据规则中包含的五元组信息对承载网络上传输的IP报文进行检测，当IP报文与五元组匹配的时候，对所述IP报文执行规则定义的QoS控制策略。同时如果当PCRF向BBERF订阅了相关承载层事件，并且当所述事件发生后，BBERF需要向PCRF及时上报所述事件。

SPR用于保存用户签约信息，为PCRF制订PCC规则提供必须的用户签约信息。

OCS和OFCS分别用于离线和在线计费。

PCRF分别通过Gx、Gxa接口实现和PCEF、BBERF的交互。

PCC架构对承载网络上传输的业务实施策略控制的原理如下：

首先，PCRF在用户正式开展具体业务之前，需要和BBERF、PCEF之间分别建立网关控制会话、I P-CAN会话，并要建立网关控制会话和I P-CAN会话关联，以保证针对特定业务数据流在BBERF和PCEF上实施控制策略的一致性。

然后，在业务开展过程中，由PCRF根据应用层协商业务信息、用户签约信息、运营商策略等为业务包含的业务数据流制订相应的策略，包含标识流的五元组信息、授权带宽等信息。并将策略以QoS规则形式下发给BBERF，以PCC规则形式下发给PCEF。当IP报文到达PCEF、BBERF时，首先根据规则中的五元组信息匹配IP报文，并将匹配上的IP报文使用对应的承载进行传输，并进行相应的计费，以实现对业务的有效控制。另外当业务开展过程中，发生业务信息的更改，例如终止了某一业务数据流，通过PCC也可以实时的释放业务所占的承载网络资源，达到对业务进行动态QoS控制的目的。

随着承载网络的发展和业务的丰富，出现了推送业务，这类业务由业务提供商主动发送给用户终端，或者在用户订阅所述业务之后，由业务提供商定期推送给用户。例如广告业务、新闻服务等，业务提供商可以将这类业务以文本消息、视频或者多媒体彩信等形式推送给用户。这类业务开展的时间由业务提供商控制，比如在每天一个特定的时间点发送给用户。另外，某些推送业务具有一定的时效性，例如在中午12点之前有效的电子优惠券，或者用于通知用户在20点整享受超低优惠购买指定商品的秒杀广告，业务提供商必须在业务有效时间内，将之推送给用户。在运营过程中，业务提供商仅会按照预定的时间点或时间段将所述业务推送用户，而一旦在这个推送过程中，网络发生拥塞，则不仅会导致用户对该业务的体验受到影响（例如所述业务为视频业务，则可能导致画面不流畅的情况），而且所述业务也会挤占其他正在开展的业务的资源使用，从而影响到其他业务的传输。

发明内容

本发明实施例提供了一种业务推送方法及装置，以至少解决因业务提供商无法感知承载网络拥塞情况而导致非实时业务的推送引发网络拥塞和影响用户体验的问题。

本发明实施例提供了一种业务推送方法，包括：PCRF接收来自应用服务器或者AF发送的业务有效时间；PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略。

优选地，在PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略之前，还包括：PCRF通过向承载网络网元订阅承载网络的拥塞状态变化事件获取承载网络的拥塞情况，当拥塞状态变化事件发生时，承载网络网元向PCRF上报拥塞状态变化事件；或者PCRF从用于统计网络拥塞情况的网元获取承载网络的拥塞情况。

优选地，PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略包括：PCRF判断业务有效且承载网络处于非拥塞状态；PCRF为业务决策的推送策略为：为业务产生QoS和计费策略并下发给策略执行网元；PCRF向应用服务器/应用功能通知资源分配成功。

优选地，在PCRF向应用服务器/应用功能通知资源分配成功之后，还包括：应用服务器/应用功能开展业务。

优选地，PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略包括：PCRF判断业务有效且承载网络处于拥塞状态；PCRF为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；PCRF向应用服务器/应用功能通知授权失败，并说明失败原因是网络拥塞。

优选地，在PCRF向应用服务器/应用功能通知授权失败之后，还包括：应用服务器/应用功能延迟开展业务。

优选地，PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略包括：PCRF判断业务失效；PCRF为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；PCRF向应用服务器/应用功能通知授权失败，并说明失败原因是业务失效。

优选地，在PCRF向应用服务器/应用功能通知授权失败之后，还包括：应用服务器/应用功能终止和PCRF之间的会话。

优选地，承载网络网元包括以下之一：BBERF、PCEF。

优选的，承载网络拥塞状态包括以下至少之一：无线承载网络的承载网络拥塞状态、核心承载网络的承载网络拥塞状态。

本发明实施例提供了一种业务推送装置，应用于PCRF，包括：接收模块，用于接收来自应用服务器或者AF发送的业务有效时间；决策模块，用于根据业务有效时间和承载网络的拥塞情况为业务决策推送策略。

优选地，上述装置还包括：订阅模块，用于通过向承载网络网元订阅承载网络的拥塞状态变化事件获取承载网络的拥塞情况，当拥塞状态变化事件发生时，承载网络网元向PCRF上报拥塞状态变化事件；获取模块，用于从用于统计网络拥塞情况的网元获取承载网络的拥塞情况。

优选地，决策模块包括：第一判断子模块，用于判断业务有效且承载网络处于非拥塞状态；第一决策子模块，用于为业务决策的推送策略为：为业务产生QoS和计费策略并下发给策略执行网元；第一通知子模块，用于向应用服务器/应用功能通知资源分配成功。

优选地，决策模块包括：第二判断子模块，用于判断业务有效且承载网络处于拥塞状态；第二决策子模块，用于为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；第二通知子模块，用于向应用服务器/应用功能通知授权失败，并说明失败原因是网络拥塞。

优选地，决策模块包括：第三判断子模块，用于判断业务失效；第三决策子模块，用于为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；第三通知子模块，用于向应用服务器/应用功能通知授权失败，并说明失败原因是业务失效。

本发明实施例在PCRF根据业务有效时间和承载网络的拥塞情况决定推送策略之后，通知应用服务器/应用功能，应用服务器/应用功能据此确定是否向用户推送所述业务，从而可以实现合理利用承载网络资源、提高用户体验。

附图说明

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

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

图2是根据本发明实施例的业务推送方法的流程图；

图3是根据本发明优选实施例一的业务推送方法的交互流程图；

图4是根据本发明优选实施例二的业务推送方法的交互流程图；

图5是根据本发明优选实施例三的业务推送方法的交互流程图；

图6是根据本发明优选实施例四的业务推送方法的交互流程图；

图7是根据本发明实施例的业务推送装置的结构框图；

图8是根据本发明优选实施例的业务推送装置的结构框图一；

图9是根据本发明优选实施例的业务推送装置的结构框图二；

图10是根据本发明优选实施例的业务推送装置的结构框图三；

图11是根据本发明优选实施例的业务推送装置的结构框图四。

具体实施方式

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

以下实施例中的重复数据处理方法可以应用在服务器上，该服务器可以专用于进行重复数据的处理，当然也可以应用于一组服务器上。或者也可以作为服务器中的一个模块与执行其他功能的服务器公用。

本发明提供了一种业务推送方法。图2是根据本发明实施例的业务推送方法的流程图，如图2所示，包括如下的步骤S202至步骤S204。

步骤S202，PCRF接收来自应用服务器或者AF发送的业务有效时间。

步骤S204，PCRF根据业务有效时间和承载网络的拥塞情况为业务决策推送策略。

相关技术中，因业务提供商无法感知承载网络拥塞情况而导致非实时业务的推送引发网络拥塞和影响用户体验。本发明实施例中，根据业务有效时间和承载网络的拥塞情况对业务的推送策略进行决策，从而可以避免网络拥塞情况下向用户推送该业务，达到合理利用承载网络资源、提高用户体验的目的。需要说明的是，该有效时间可以是PCRF从接收的来自应用服务器/应用功能的业务信息中获得的，同时，该业务信息中还包括但不限于该业务的带宽要求和/或该业务的QoS要求。

为了更加清楚的说明上述根据业务有效时间和承载网络的拥塞情况对业务的推送策略进行决策，本发明实施例还提供三种具体实例，下面分别对其进行详细描述。

实例1：如果业务有效且承载网络处于非拥塞状态，则PCRF对业务进行QoS授权成功并通知应用服务器/应用功能开展业务。

实例2：如果业务有效且承载网络处于拥塞状态，则PCRF对业务进行QoS授权失败并通知应用服务器/应用功能延迟开展业务。

进而，为了保证该业务尽可能成功推送，本发明实施例中，PCRF还检查承载网络是否由拥塞状态变为非拥塞状态。如果PCRF获知该承载网络由拥塞状态变为非拥塞状态，则PCRF通知应用服务器/应用功能开展业务。

具体地，PCRF可以通过预先向承载网络网元订阅的承载网络的拥塞情况获知承载网络由拥塞变为非拥塞，或者PCRF还可以通过网络管理中心上报的承载网络的拥塞情况获知承载网络由拥塞变为非拥塞。其中，承载网络网元包括以下之一：BBERF、PCEF。

实例3：如果业务失效，则PCRF对业务进行QoS授权失败并通知应用服务器/应用功能终止和自身之间的会话。

优选地，承载网络拥塞状态包括以下至少之一：无线承载网络的承载网络拥塞状态、核心承载网络的承载网络拥塞状态。

优选地，在PCRF检查到当前时间超过业务有效时间之前，还包括：PCRF接收到来自应用服务器/应用功能的业务信息，其中业务信息包括以下至少之一：业务的带宽要求、业务的QoS要求、业务有效时间。

下面将结合实例对本发明实施例的实现过程进行详细描述。

优选实施例一

本优选实施例一描述的是应用服务器/应用功能将业务有效时间下发给PCRF，以便PCRF根据承载网络拥塞情况和业务有效时间来决定是否为业务进行授权。图3是根据本发明优选实施例一的业务推送方法的交互流程图，如图3所示，包括如下的步骤S302至步骤S314。

步骤S302，当用户终端附着到承载网络的时候，承载网络网元与PCRF建立策略控制会话，例如，BBERF和PCRF建立网关控制会话，或者PCEF和PCRF建立IP-CAN会话。同时，PCRF向承载网络网元订阅承载网络拥塞情况，要求当承载网络拥塞情况发生变化的时候向PCRF上报，例如，PCRF通过下发Event trigger进行承载网络拥塞情况的订阅：Eventtrigger-1=“承载网络从非拥塞变为拥塞”，Event trigger-2=“承载网络从拥塞变为非拥塞”。

步骤S304，当应用服务器决定向用户推送非实时业务（例如广告视频）的时候，应用服务器/应用功能向PCRF下发业务信息，例如业务对带宽、QoS的要求。同时指示该业务有效时间。

步骤S306，本步骤是在步骤S302PCRF向承载网络网元订阅的承载网络拥塞情况之后，一旦承载网络拥塞状态发生了变化，例如此前承载网络是处于拥塞状态的，当承载网络转换成非拥塞的时候，承载网络网元向PCRF上报“承载网络从拥塞转换成非拥塞”的事件，PCRF就能感知承载网络处于非拥塞状态。需要说明的是，本步骤为可选，即如果承载网络拥塞状态没有发生变化，就不会发生该步骤。本步骤与步骤S304不存在时序关系，可以在之前发生，也可以在之后发生。

步骤S308，PCRF感知到承载网络处于非拥塞状态，可以结合步骤S304下发的业务信息对业务进行QoS授权。PCRF检查当前时间是否已经超出了业务有效时间，如果没有，则PCRF根据步骤S304下发的业务信息为业务进行控制策略决策；如果当前时间超出了业务有效时间，则PCRF授权失败应该向应用服务器/应用功能返回授权失败，并说明业务失效。

步骤S310，PCRF将控制策略下发给承载网络网元。

步骤S312，当给业务成功分配QoS资源之后，PCRF向应用服务器/应用功能返回资源分配成功的通知，说明应用服务器可以启动向用户推送业务。

步骤S314，据此，应用服务器/应用功能向用户推送业务，承载网络网元按照控制策略为业务提供相应的QoS保证。

优选实施例二

本优选实施例二描述的场景是应用服务器/应用功能向PCRF下发业务信息的时候，承载网络正处于拥塞状态，此时需要延迟为业务进行授权。图4是根据本发明优选实施例二的业务推送方法的交互流程图，如图4所示，包括如下的步骤S402至步骤S420。

步骤S402，当用户终端附着到承载网络的时候，承载网络网元与PCRF建立策略控制会话，例如BBERF和PCRF建立网关控制会话，或者PCEF和PCRF建立IP-CAN会话。同时PCRF向承载网络网元订阅承载网络拥塞情况，要求当承载网络拥塞情况发生变化的时候向PCRF上报，例如，PCRF通过下发Event trigger进行承载网络拥塞情况的订阅：Eventtrigger-1=“承载网络从非拥塞变为拥塞”；Event trigger-2=“承载网络从拥塞变为非拥塞”。

步骤S404，当应用服务器决定向用户推送非实时业务（例如广告视频）的时候，应用服务器/应用功能向PCRF下发业务信息，例如业务对带宽、QoS的要求。同时下发业务有效时间。

步骤S406，该步骤是在步骤S402PCRF向承载网络网元订阅的承载网络拥塞情况之后，一旦承载网络拥塞状态发生了变化，例如此前承载网络是处于非拥塞状态的，当承载网络转换成拥塞的时候，承载网络网元向PCRF上报“承载网络从非拥塞转换成拥塞”的事件，PCRF就能感知承载网络处于拥塞状态。需要说明的是，本步骤为可选，即如果承载网络拥塞状态没有发生变化，就不会发生本步骤。本步骤与步骤S404不存在时序关系，可以在之前发生，也可以在之后发生。

步骤S408，由于承载网络处于拥塞状态，此时PCRF从应用服务器/应用功能收到业务信息之后无法为业务进行授权。

步骤S410，PCRF向应用服务器/应用功能返回授权失败，说明授权失败的原因是此时承载网络处于拥塞状态。此时应用服务器/应用功能感知到授权失败的原因是承载网络拥塞，但业务还有效，因此应用服务器/应用功能并不会终止和PCRF之间建立的会话。

步骤S412，此后一旦承载网络从拥塞变为非拥塞状态，则承载网络网元向PCRF上报“承载网络从拥塞转换成非拥塞”事件。

步骤S414，PCRF结合承载网络拥塞状态、业务有效时间、业务对QoS的需求进行策略决策。此时PCRF感知到承载网络处于非拥塞状态，且当前时间，业务仍然有效，则PCRF根据业务对QoS的要求，为业务进行QoS授权。

步骤S416，PCRF将包含授权QoS的控制策略下发给承载网络网元。

步骤S418，PCRF向应用服务器/应用功能通知资源分配成功的通知，说明应用服务器可以启动向用户推送业务。

步骤S420，据此，应用服务器向用户推送业务，承载网络网元按照控制策略对业务提供QoS保证。

优选实施例三

本优选实施例三描述的场景是应用服务器/应用功能向PCRF下发业务信息的时候，承载网络正处于拥塞状态，需要延迟为业务进行授权，且在业务有效时间内，承载网络拥塞状态没有改变，授权失败。图5是根据本发明优选实施例三的业务推送方法的交互流程图，如图5所示，包括如下的步骤S502至步骤S518。

步骤S502，当用户终端附着到承载网络的时候，承载网络网元与PCRF建立策略控制会话，例如BBERF和PCRF建立网关控制会话，或者PCEF和PCRF建立IP-CAN会话。同时PCRF向承载网络网元订阅承载网络拥塞情况，要求当承载网络拥塞情况发生变化的时候向PCRF上报，例如，PCRF通过下发Event trigger进行承载网络拥塞情况的订阅：Eventtrigger-1=“承载网络从非拥塞变为拥塞”；Event trigger-2=“承载网络从拥塞变为非拥塞”。

步骤S504，当应用服务器决定向用户推送非实时业务（例如广告视频）的时候，应用服务器/应用功能向PCRF下发业务信息，例如业务对带宽、QoS的要求。同时下发业务有效时间。

步骤S506，本步骤是在步骤S502PCRF向承载网络网元订阅的承载网络拥塞情况之后，一旦承载网络拥塞状态发生了变化，例如此前承载网络是处于非拥塞状态的，当承载网络转换成拥塞的时候，承载网络网元向PCRF上报“承载网络从非拥塞转换成拥塞”的事件，PCRF就能感知承载网络处于拥塞状态。需要说明的是，本步骤为可选，即如果承载网络拥塞状态没有发生变化，就不会发生本步骤。本步骤与步骤S504不存在时序关系，可以在之前发生，也可以在之后发生。

步骤S508，由于承载网络处于拥塞状态，此时PCRF从应用服务器/应用功能收到业务信息之后无法为业务进行授权。

步骤S510，PCRF向应用服务器/应用功能返回授权失败，说明授权失败的原因是此时承载网络处于拥塞状态。此时应用服务器/应用功能感知到授权失败的原因是承载网络拥塞，但业务还有效，因此应用服务器/应用功能并不会终止和PCRF之间建立的会话。

步骤S512，当到达某个时间，PCRF判断业务失效，此时PCRF还没有收到来在承载网络的“承载网络从拥塞转换成非拥塞”事件的上报，则PCRF对此业务授权失败。

步骤S514，PCRF向应用服务器/应用功能返回授权失败，并说明失败的原因是授权失败，业务失效。

步骤S516，应用服务器/应用功能收到授权失败的原因后，感知到业务失效，则向PCRF发起会话终止。

步骤S518，对应的，PCRF向承载网络网元发起策略控制会话的修改或终止。

优选实施例四

与上述优选实施例一至优选实施例三中PCRF从承载网络网元获取承载网络拥塞情况的技术方案不同，本优选实施例四描述的是PCRF从承载网络管理中心获取承载网络拥塞情况，并结合业务有效时间决策是否为业务的开展下发控制策略。其中承载网络管理中心用于统计承载网络的流量信息，并能分析承载网络的拥塞情况。图6是根据本发明优选实施例四的业务推送方法的交互流程图，如图6所示，包括如下的步骤S602至步骤S620。

步骤S602，当用户终端附着到承载网络的时候，承载网络网元与PCRF建立策略控制会话，例如BBERF和PCRF建立网关控制会话，或者PCEF和PCRF建立IP-CAN会话。

步骤S604，当应用服务器决定向用户推送非实时业务的时候，应用服务器/应用功能向PCRF下发业务信息，例如业务对带宽、QoS的要求。同时下发业务有效时间。

步骤S606，PCRF收到业务时间的时候，从承载网络管理中心获取承载网络拥塞情况，感知此时承载网络拥塞。需要说明的是，PCRF从承载网络管理中心获取承载网络拥塞情况可以有多种实现，例如可以设置承载网络管理中心定时向PCRF上报承载网络拥塞情况，或者应PCRF请求向PCRF上报承载网络拥塞情况，或者设置某一拥塞阈值，当承载网络流量达到拥塞阈值就指定为承载网络拥塞，从而承载网络管理中心向PCRF上报。

步骤S608，根据步骤S604获取的业务信息，步骤S606获取的承载网络拥塞情况以及用户签约信息，运营商策略等，PCRF为业务进行策略决策。由于此时承载网络处于拥塞状态，无法为业务分配QoS资源，因此PCRF授权失败。

步骤S610，PCRF向应用服务器/应用功能返回授权失败的通知，并说明由于承载网络拥塞导致授权失败。

步骤S612，当承载网络处于非拥塞状态之后，网关中心将信息传递给PCRF。关于PCRF获取信息的过程如步骤S606步描述。

步骤S614，由于承载网络处于非拥塞状态，且PCRF根据业务有效时间判断此时业务仍然有效，并对其进行策略决策。

步骤S616，针对业务，PCRF向承载网络网元下发授权策略。

步骤S618，PCRF向应用服务器/应用功能返回资源分配成功的响应。

步骤S620，当应用服务器/应用功能收到响应之后，向用户推送业务。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本发明实施例提供了一种业务推送装置，该业务推送装置可以应用于PCRF，并用于实现上述业务推送方法。图7是根据本发明实施例的业务推送装置的结构框图，如图7所示，包括接收模块72和决策模块74，下面对其结构进行详细描述。

接收模块72，用于接收来自应用服务器或者AF的业务有效时间；决策模块74，连接至接收模块72，用于根据接收模块72接收的业务有效时间和承载网络的拥塞情况为业务决策推送策略。

图8是根据本发明优选实施例的业务推送装置的结构框图一，如图8所示，上述装置还包括订阅模块76和获取模块78，下面对其结构进行详细描述。

订阅模块76，用于通过向承载网络网元订阅承载网络的拥塞状态变化事件获取承载网络的拥塞情况，当拥塞状态变化事件发生时，承载网络网元向PCRF上报拥塞状态变化事件；获取模块78，用于从用于统计网络拥塞情况的网元获取承载网络的拥塞情况。

图9是根据本发明优选实施例的业务推送装置的结构框图二，如图9所示，决策模块74包括：第一判断子模块741，用于判断业务有效且承载网络处于非拥塞状态；第一决策子模块742，用于为业务决策的推送策略为：为业务产生QoS和计费策略并下发给策略执行网元；第一通知子模块743，用于向应用服务器/应用功能通知资源分配成功。

图10是根据本发明优选实施例的业务推送装置的结构框图三，如图10所示，决策模块74包括：第二判断子模块744，用于判断业务有效且承载网络处于拥塞状态；第二决策子模块745，用于为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；第二通知子模块746，用于向应用服务器/应用功能通知授权失败，并说明失败原因是网络拥塞。

图11是根据本发明优选实施例的业务推送装置的结构框图四，如图11所示，决策模块74包括：第三判断子模块747，用于判断业务失效；第三决策子模块748，用于为业务决策的推送策略为：为业务进行QoS和计费策略授权失败；第三通知子模块749，用于向应用服务器/应用功能通知授权失败，并说明失败原因是业务失效。

需要说明的是，装置实施例中描述的业务推送装置对应于上述的方法实施例，其具体的实现过程在方法实施例中已经进行过详细说明，在此不再赘述。

综上所述，根据本发明的上述实施例，提供了一种业务推送方法及装置。本发明实施例根据业务有效时间和承载网络的拥塞情况对业务的推送策略进行决策，从而可以避免网络拥塞情况下向用户推送该业务，达到合理利用承载网络资源、提高用户体验的目的。

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

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

Claims (15)

1.一种业务推送方法，其特征在于包括：

策略和计费规则功能PCRF接收来自应用服务器或者应用功能AF发送的业务有效时间；

所述PCRF根据所述业务有效时间和承载网络的拥塞情况为所述业务决策推送策略。

2.根据权利要求1所述的方法，其特征在于，在所述PCRF根据业务有效时间和承载网络的拥塞情况为所述业务决策推送策略之前，还包括：

所述PCRF通过向承载网络网元订阅所述承载网络的拥塞状态变化事件获取所述承载网络的拥塞情况，当所述拥塞状态变化事件发生时，所述承载网络网元向所述PCRF上报所述拥塞状态变化事件；或者

所述PCRF从用于统计网络拥塞情况的网元获取所述承载网络的拥塞情况。

3.根据权利要求1所述的方法，其特征在于，所述PCRF根据业务有效时间和承载网络的拥塞情况为所述业务决策推送策略包括：

所述PCRF判断所述业务有效且所述承载网络处于非拥塞状态；

所述PCRF为所述业务决策的所述推送策略为：为所述业务产生QoS和计费策略并下发给策略执行网元；

所述PCRF向应用服务器/应用功能通知资源分配成功。

4.根据权利要求3所述的方法，其特征在于，在所述PCRF向应用服务器/应用功能通知资源分配成功之后，还包括：所述应用服务器/应用功能开展所述业务。

5.根据权利要求1所述的方法，其特征在于，所述PCRF根据业务有效时间和承载网络的拥塞情况为所述业务决策推送策略包括：

所述PCRF判断所述业务有效且所述承载网络处于拥塞状态；

所述PCRF为所述业务决策的所述推送策略为：为所述业务进行QoS和计费策略授权失败；

所述PCRF向应用服务器/应用功能通知所述授权失败，并说明失败原因是网络拥塞。

6.根据权利要求5所述的方法，其特征在于，在所述PCRF向应用服务器/应用功能通知所述授权失败之后，还包括：所述应用服务器/应用功能延迟开展所述业务。

7.根据权利要求1所述的方法，其特征在于，所述PCRF根据业务有效时间和承载网络的拥塞情况为所述业务决策推送策略包括：

所述PCRF判断所述业务失效；

所述PCRF为所述业务决策的推送策略为：为所述业务进行QoS和计费策略授权失败；

所述PCRF向应用服务器/应用功能通知所述授权失败，并说明失败原因是业务失效。

8.根据权利要求7所述的方法，其特征在于，在所述PCRF向应用服务器/应用功能通知所述授权失败之后，还包括：所述应用服务器/应用功能终止和所述PCRF之间的会话。

9.根据权利要求1至8中任一项所述的方法，其特征在于，所述承载网络网元包括以下之一：承载绑定和事件上报功能BBERF、策略和计费执行功能PCEF。

10.根据权利要求1至8中任一项所述的方法，其特征在于，所述承载网络拥塞状态包括以下至少之一：无线承载网络的承载网络拥塞状态、核心承载网络的承载网络拥塞状态。

11.一种业务推送装置，应用于策略和计费规则功能PCRF，其特征在于包括：

接收模块，用于接收来自应用服务器或者应用功能AF发送的业务有效时间；

决策模块，用于根据所述业务有效时间和承载网络的拥塞情况为所述业务决策推送策略。

12.根据权利要求11所述的装置，其特征在于，还包括：

订阅模块，用于通过向承载网络网元订阅所述承载网络的拥塞状态变化事件获取所述承载网络的拥塞情况，当所述拥塞状态变化事件发生时，所述承载网络网元向所述PCRF上报所述拥塞状态变化事件；

获取模块，用于从用于统计网络拥塞情况的网元获取所述承载网络的拥塞情况。

13.根据权利要求11所述的装置，其特征在于，所述决策模块包括：

第一判断子模块，用于判断所述业务有效且所述承载网络处于非拥塞状态；

第一决策子模块，用于为所述业务决策的所述推送策略为：为所述业务产生QoS和计费策略并下发给策略执行网元；

第一通知子模块，用于向应用服务器/应用功能通知资源分配成功。

14.根据权利要求11所述的装置，其特征在于，所述决策模块包括：

第二判断子模块，用于判断所述业务有效且所述承载网络处于拥塞状态；

第二决策子模块，用于为所述业务决策的所述推送策略为：为所述业务进行QoS和计费策略授权失败；

第二通知子模块，用于向应用服务器/应用功能通知所述授权失败，并说明失败原因是网络拥塞。

15.根据权利要求11所述的装置，其特征在于，所述决策模块包括：

第三判断子模块，用于判断所述业务失效；

第三决策子模块，用于为所述业务决策的推送策略为：为所述业务进行QoS和计费策略授权失败；

第三通知子模块，用于向应用服务器/应用功能通知所述授权失败，并说明失败原因是业务失效。

Images