AF设置为提供为业务制定控制策略所需的业� ��信息，例如业务开展所使用的互联 网协议 （Internet Protocol, 简称为 IP) 地址、 端口号， 业务开展所需要的带宽、 服务 质量 （Quality of 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规贝 U， 并将所述规则绑定到与之匹配的承载上。 BBERF根据规则中包含的五元组信息对承载 网络上传输的 IP报文进行检测， 当 IP报文与五元组匹配的时候， 对所述 IP报文执行 规则定义的 QoS控制策略。 同时如果当 PCRF向 BBERF订阅了相关承载层事件， 并 且当所述事件发生后， BBERF需要向 PCRF及时上报所述事件。

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

OCS和 OFCS分别设置为离线和在线计费。

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

PCC架构对承载网络上传输的业务实施策略控 制的原理如下： 首先， PCRF在用户正式开展具体业务之前， 需要和 BBERF、 PCEF之间分别建 立网关控制会话、 IP-CAN会话， 并要建立网关控制会话和 IP-CAN会话关联， 以保证 针对特定业务数据流在 BBERF和 PCEF上实施控制策略的一致性。 然后， 在业务开展过程中， 由 PCRF根据应用层协商业务信息、 用户签约信息、 运营商策略等为业务包含的业务数据流制订相 应的策略， 包含标识流的五元组信息、 授权带宽等信息。 并将策略以 QoS规则形式下发给 BBERF, 以 PCC规则形式下发给 PCEFo当 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进行承载网络拥 塞情况的订阅： Event trigger- 1 ="承载网络从非拥塞变为拥塞"， Event trigger-2 ="承载 网络从拥塞变为非拥塞"。 步骤 S304, 当应用服务器决定向用户推送非实时业务 （例如广告视频） 的时候， 应用服务器 /应用功能向 PCRF下发业务信息， 例如业务对带宽、 QoS的要求。 同时指 示该业务有效时间。 步骤 S306,本步骤是在步骤 S302 PCRF向承载网络网元订阅的承载网络拥塞情况 之后， 一旦承载网络拥塞状态发生了变化， 例如此前承载网络是处于拥塞状态的， 当 承载网络转换成非拥塞的时候，承载网络网元 向 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进行承载网络拥塞 情况的订阅： Event trigger- 1 ="承载网络从非拥塞变为拥塞"； Event trigger-2 ="承载网 络从拥塞变为非拥塞"。 步骤 S404, 当应用服务器决定向用户推送非实时业务 （例如广告视频） 的时候， 应用服务器 /应用功能向 PCRF下发业务信息， 例如业务对带宽、 QoS的要求。 同时下 发业务有效时间。 步骤 S406,该步骤是在步骤 S402 PCRF向承载网络网元订阅的承载网络拥塞情况 之后， 一旦承载网络拥塞状态发生了变化， 例如此前承载网络是处于非拥塞状态的， 当承载网络转换成拥塞的时候，承载网络网元 向 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进行承载网络拥塞 情况的订阅： Event trigger-1 ="承载网络从非拥塞变为拥塞"； Event trigger-2 ="承载网 络从拥塞变为非拥塞"。 步骤 S504, 当应用服务器决定向用户推送非实时业务 （例如广告视频） 的时候， 应用服务器 /应用功能向 PCRF下发业务信息， 例如业务对带宽、 QoS的要求。 同时下 发业务有效时间。 步骤 S506,本步骤是在步骤 S502 PCRF向承载网络网元订阅的承载网络拥塞情况 之后， 一旦承载网络拥塞状态发生了变化， 例如此前承载网络是处于非拥塞状态的， 当承载网络转换成拥塞的时候，承载网络网元 向 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，耦合至决策模块 74， 设置为通过向承载网络网元订阅承载网络的拥 塞状态变化事件获取承载网络的拥塞情况， 当拥塞状态变化事件发生时， 承载网络网 元向 PCRF上报拥塞状态变化事件； 获取模块 78， 耦合至决策模块 74， 设置为从用于 统计网络拥塞情况的网元获取承载网络的拥塞 情况。 图 9是根据本发明优选实施例的业务推送装置的� �构框图二， 如图 9所示， 决策 模块 74包括：第一判断子模块 741，设置为判断业务有效且承载网络处于非拥 塞状态; 第一决策子模块 742，耦合至第一判断子模块 741，设置为为业务决策推送策略，其中， 决策的推送策略为： 为业务产生 QoS和计费策略并下发给策略执行网元； 第一通知子 模块 743， 耦合至第一决策子模块 742， 设置为向应用服务器 /应用功能通知资源分配 成功。 图 10是根据本发明优选实施例的业务推送装置的� ��构框图三， 如图 10所示， 决 策模块 74包括：第二判断子模块 744，设置为判断业务有效且承载网络处于拥塞 状态; 第二决策子模块 745，耦合至第二判断子模块 744，设置为为业务决策推送策略，其中， 决策的推送策略为： 为业务进行 QoS和计费策略授权失败； 第二通知子模块 746， 耦 合至第二决策子模块 745， 设置为向应用服务器 /应用功能通知授权失败， 并说明失败 原因是网络拥塞。 图 11是根据本发明优选实施例的业务推送装置的� ��构框图四， 如图 11所示， 决 策模块 74包括： 第三判断子模块 747， 设置为判断业务失效； 第三决策子模块 748， 耦合至第三判断子模块 747， 设置为为业务决策推送策略， 其中， 决策的推送策略为： 为业务进行 QoS和计费策略授权失败； 第三通知子模块 749， 耦合至第三决策子模块 748， 设置为向应用服务器 /应用功能通知授权失败， 并说明失败原因是业务失效。 需要说明的是， 装置实施例中描述的业务推送装置对应于上述 的方法实施例， 其 具体的实现过程在方法实施例中已经进行过详 细说明， 在此不再赘述。 综上所述， 根据本发明的上述实施例， 提供了一种业务推送方法及装置。 本发明 实施例根据业务有效时间和承载网络的拥塞情 况对业务的推送策略进行决策， 从而可 以避免网络拥塞情况下向用户推送该业务， 达到合理利用承载网络资源、 提高用户体 验的目的。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的承载网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现 ， 从而， 可以将它们存储在存储装置中由计算装置来执 行， 或者将它们分别制作成各个集成电 路模块， 或者将它们中的多个模块或步骤制作成单个集 成电路模块来实现。 这样， 本 发明不限制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。