一种永远在线能力的提供方法、系统和设备

摘要

本发明实施例公开了一种永远在线能力的提供方法、系统和设备，该方法包括：接收来自业务服务器的永远在线业务请求信息，所述请求信息中携带永远在线业务对应的用户信息；通知核心网设备为所述用户信息对应的IP-CAN会话保持永远在线能力。本发明实施例中，针对PCC架构实现永远在线业务，无需使用心跳包机制来维护永远在线状态，降低了网络信令负荷，减少了网络在用户使用业务时对用户的影响，提高了用户体验。

说明书

技术领域

本发明涉及通信技术领域，特别是涉及一种永远在线能力的提供方法、系 统和设备。

背景技术

随着通信技术的快速发展，网络日趋开放，在竞争日趋激烈的情况下，网 络是否安全可靠直接关系到企业的产品竞争力，从而决定了企业的市场地位和 竞争力，只有网络安全可靠，才能保障企业客户的业务永远在线，继而保证企 业持续长远发展。

当智能手机和移动电脑被广泛应用后，出现了永远在线业务的需求，如即 时聊天业务、社交网络业务、邮件推送业务等，上述永远在线业务为了体现出 用户与服务器之间的操作性，减少网络在用户使用业务时对用户的影响，提高 用户体验，则需要获知用户是否还连接在服务器上。进一步的，用户在使用永 远在线业务时不希望感受到由于网络状况或服务器状况而产生的延迟，在高突 发性数据发生时，要求永远在线业务可以做出快速响应。

现有技术中，永远在线类业务的服务器获知用户与服务器间的连接状态的 方法为：服务器接收来自用户的保持在线状态信息(即心跳包(keep alive)消 息)，当服务器接收到用户的心跳包时，证明用户依然连接在服务器上，确定 用户在线的状态，从而实现了永远在线的特征。

在实现本发明的过程中，发明人发现现有技术中至少存在以下问题：

现有的无线网络机制是按照用户使用间断、大数据量的应用来设计架构 的，当用户静默一段时间后，网络侧会释放资源，不再提供永远在线能力，当 永远在线业务承载在无线网络时，需要通过心跳包机制来维护在线能力，而心 跳包往往比较简短，数据量小，只包含用户部分信息，且发送间隔时间较长； 因此会导致大量的信令消耗，占用网络资源。

发明内容

本发明实施例提供一种永远在线能力的提供方法、系统和设备，以实现永 远在线业务，充分利用网络资源。

为了达到上述目的，本发明实施例提供一种永远在线能力的提供方法，包 括以下步骤：接收来自业务服务器的永远在线业务请求信息，所述请求信息中 携带永远在线业务对应的用户信息；通知核心网设备为所述用户信息对应的 IP-CAN会话保持永远在线能力。

本发明实施例提供一种永远在线能力的提供方法，包括以下步骤：接收来 自PCRF的永远在线业务的请求通知，所述请求通知中携带永远在线业务信息、 请求为永远在线业务的IP-CAN会话保持永远在线能力的信息；为所述永远在 线业务的IP-CAN会话保持永远在线能力。

本发明实施例提供一种策略与计费规则功能实体PCRF，包括：接收模块， 用于接收来自业务服务器的永远在线业务请求信息，所述请求信息中携带永远 在线业务对应的用户信息；通知模块，用于通知核心网设备为所述用户信息对 应的IP-CAN会话保持永远在线能力。

本发明实施例提供一种核心网设备，包括：接收模块，用于接收来自PCRF 的永远在线业务的请求通知，所述请求通知中携带永远在线业务信息、请求为 永远在线业务的IP-CAN会话保持永远在线能力的信息；能力保持模块，用于 为所述永远在线业务的IP-CAN会话保持永远在线能力。

本发明实施例提供一种永远在线能力的提供系统，包括上述的策略与计费 规则功能实体PCRF、以及上述的核心网设备。

与现有技术相比，本发明实施例所提出的技术方案具有以下优点：

针对PCC架构实现永远在线业务，无需使用心跳包机制来维护永远在线 状态，降低了网络信令负荷，减少了网络在用户使用业务时对用户的影响，提 高了用户体验。

附图说明

图1为现有技术中PCC架构示意图；

图2为现有技术中心跳包示意图；

图3为本发明各实施例的应用场景示意图；

图4为本发明实施例一提供的永远在线业务的上线流程示意图；

图5为本发明实施例二提供的永远在线业务的IP-CAN会话释放流程示意 图；

图6为本发明实施例三提供的永远在线业务下线流程示意图；

图7为本发明实施例四提供的PCRF的结构示意图；

图8为本发明实施例五提供的核心网设备的结构示意图。

具体实施方式

如图1所示的PCC(Policy and Charging Control，策略和计费控制)架构 示意图，为了支持对业务流的QoS(Quality of Service，服务质量)控制、计 费控制和门限控制，定义了PCC架构，PCC架构能够支持为每个业务流提供 基于业务的PCC策略，包括将流规则、授权的QoS等给PCEF，由PCEF(Policy  and Charging Enforcement Function，策略及计费执行功能)执行对业务流的QoS 保证。其中，业务流的QoS授权可以基于业务类型、用户签约数据、PCRF(Policy  and Charging Rules Function，策略与计费规则功能)上预设的策略等因素生成， 能够支持基于业务流的事件上报的能力。在PCC架构中，主要网元包括：PCRF、 PCEF、SPR(Subscription Profile Repository，用户签约数据库)、AF(Application  Function，应用功能)等，其中：

(1)PCRF，为PCC的核心，负责策略决策和计费规则的制定。PCRF根 据从AF获取与业务相关的信息，从SPR获取用户的策略和计费控制签约信息， 从PCEF/BBERF(Bearing Binding and Event Report Function，承载绑定及事件 报告功能)获取与承载相关的网络信息(如IP-CAN(IP-Connectivity Access  Network，IP连接访问网络)类型、用户的位置信息)，以及PCRF自身预配置 的信息制定策略和计费规则。其中，上述策略和计费控制主要包括业务数据流 的检测，门控，QoS控制，基于数据流的计费规则等。

(2)PCEF，为策略和计费执行功能逻辑实体，位于网关内。PCEF按照 PCRF下发的PCC规则中的业务数据流过滤器对业务数据流进行检测，执行策 略、门控预计基于流的计费。

(3)SPR，是存放所有用户签约信息的逻辑节点，签约信息可以被PCRF 用来进行基于签约的策略控制和IP CAN承载层的PCC策略控制。其中，SPR 中可以为每个PDN(Public DataNetwork，公用数据网络)提供如下签约信息： 用户签约的服务、每种签约的服务的抢占优先级、用户签约的QoS(如保证的 带宽QoS)、用户的计费相关信息(如和计费相关的位置信息)、用户类别。

(4)AF，如IMS(IP Multimedia Subsystem，IP多媒体系统)网络的P-CSCF (Proxy Call Session Control Function，代理呼叫会话控制功能)，是提供业务并 要求IP CAN为该业务提供动态的策略控制节点。AF通过和PCRF通信下发动 态的会话信息给PCRF进行策略控制决策，AF也接受PCRF上报的IP CAN的 相关信息和事件通知。

另外，对于分组网络承载管理机制，在无线网络中，网络的资源相对有限， 因此为节省网络资源，提高网络资源利用率，现有网络资源管理机制是：仅当 用户有业务需求时，才会进行承载建立(如PDP激活)，以及相应的无线资源承 载建立，同时当用户静默一定时间段后，即当用户一段时间内没有业务发生时， 网络侧会主动删除承载(如去激活PDP)，以节省网络资源。

基于上述PCC架构，PCC相关技术目前已完成基本的业务流资源保障以 及流计费策略，可在一定程度上为用户提供差异化的服务。主要包括：承载建 立时的策略协商、决定和执行，策略的修改，以及承载释放时的策略取消等。 上述流程能够处理会话相关和会话无关两种类型业务的承载的策略管理，可以 由承载建立请求触发、或PCEF触发、或对用户的签约信息的改变触发、或 AF发来的业务请求触发。对PCRF来说，只是被动的接受建立、修改、终止 的请求，之后根据业务信息制定或终止相应的策略。而针对具体业务(如永远 在线特性的业务)的承载维护，目前为止没有相关解决方案。

基于现有永远在线业务的需求，现有的无线网络机制所采用的PCC架构 中至少存在以下问题：

(1)现有网络不维护永远在线业务的状态。其中，分组域网络不会针对 业务去提供对应承载的状况管理，不具有对业务提供永远在线的能力。

具体的，在分组域网络架构中，能够支持为每个业务流提供基于业务的 PCC策略，但PCC策略仅包括流规则、授权的QoS等，由接受此PCC策略的 PCEF执行对业务流的QoS保证；当用户有业务请求时才激活IP-CAN，用户 在此IP-CAN所包含的承载中实现业务；在用户静默期一段时间后，网络侧会 释放IP-CAN(核心网内IP不可达)；由于NAT(Network Address Translation， 网络地址转换)穿透机制，在PDN侧网络资源(如公网地址)也会释放。

基于上述情况，网络不能感知永远在线业务的存在，因此不能针对永远在 线业务特性进行维护，导致永远在线业务上线后需要靠心跳包来维持连接状 态，占用大量网络资源，影响其他业务的正常运作，并降低运营商网络服务质 量和客户体验度。

(2)业务的大量信令。其中，由于现有网络不维护永远在线业务的状态， 永远在线业务消息依赖于心跳包机制，心跳包的时间间隔会超出IP-CAN释放 或无线侧资源重分配的时长，从而使得永远在线业务发送心跳包时重新激活 PDP或重分配无线侧资源。进一步的，重新分配无线侧资源会造成终端与核心 网网元交换信令，并且由于心跳包的特性，终端的状态会快速改变。

如图2所示，为现有技术中心跳包示意图，当终端发送心跳包时，由于系 统对资源的控制粒度较小，在类似于冲击的心跳包间隔时间内快速的释放资 源，而当心跳包发送时又会重新分配资源，期间会产生大量信令，从而对RRC (Radio Resource Control，无线资源控制协议)控制等功能造成冲击。

另外，PS(分组域)RAB(Radio Access Bear，无线接入承载)建立请求 的增加会造成RNC(Radio Network Controller，无线网络控制器)信令处理模 块负荷的显著增加，同时整体的用户分组业务数据及信令流量显著增加，进一 步负荷超载时甚至会影响到用户电路域业务的正常使用。

针对上述问题，本发明实施例提供一种永远在线能力的提供方法、系统和 设备，在PCC架构中引入了永远在线业务策略和网络提供能力，当永远在线 类应用上线后，可由永远在线业务服务器通过永远在线业务AF向PCRF上报 永远在线类应用状态，PCRF根据上报的永远在线业务状态及其他业务、会话 信息进行灵活准确的决策，并在网络侧为用户开通永远在线能力，取消业务侧 的心跳包，从而降低永远在线业务的心跳包对网络的冲击(如延长永远在线业 务的PDP上下文释放时间、延长永远在线业务的公网地址释放时间、在永远 在线业务所在承载意外去激活时保活承载)，从而使得业务无需使用心跳包确 认即可感受到用户的在线状态。

下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整的描 述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。 基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下 所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

本发明实施例一提供一种永远在线能力的提供方法，该方法应用于基于 PCC架构的2G/3G系统或者LTE系统，在2G/3G系统中，本实施例中的核心 网设备包括GGSN(Gateway GPRS Support Node，网关GPRS支持节点)，在 LTE系统中，本实施例中的核心网设备包括PDN GW(Public Data Network  Gateway，公共数据网网关)，以LTE系统为例，本实施例的应用场景为图3 所示的具有永远在线业务能力的网络架构示意图。PCC架构中的AF实体可单 独部署、可集成在业务服务器上，可集成在PCRF上、也可集成在其他设备上。

如图4所示，基于上述应用场景示意图，永远在线业务的上线流程包括以 下步骤：

步骤401，当用户设备通过已有承载激活永远在线业务时，业务服务器为 该用户设备提供永远在线业务。其中，该业务服务器为永远在线业务的应用服 务器，如QQ、MSN等永远在线业务的应用服务器。

步骤402，业务服务器通过永远在线业务对应的AF向PCRF发送永远在 线业务请求信息。其中，当永远在线业务对应的AF部署在业务服务器上时， 则由业务服务器直接向PCRF发送永远在线业务请求信息。

具体的，当永远在线业务上线时，该业务服务器可通过AF向PCRF发送 永远在线业务请求信息，以通知PCRF激活对应的永远在线业务。其中，该请 求信息中至少携带永远在线业务对应的永远在线业务标识和用户信息(如用户 设备IP地址)。

步骤403，PCRF接收到来自业务服务器的永远在线业务请求信息后，通 知核心网设备为用户信息对应的IP-CAN会话保持永远在线能力。

方式一：通过查询预先维护的业务标记信息确定用户信息对应的IP-CAN 会话承载永远在线能力是否已激活，如果用户信息对应的IP-CAN会话承载永 远在线能力已激活(用户信息对应的IP-CAN会话承载永远在线能力可对应用 户设备的多种类型的永远在线业务，该IP-CAN会话承载永远在线能力激活状 态可为其他永远在线业务的请求过程中被设置为激活状态)，则通知核心网设 备采用第一类方式(由核心网设备通知NAT功能实体不释放永远在线业务对 应公网地址)为用户信息对应的IP-CAN会话保持永远在线能力(基于第一类 方式的请求通知中携带永远在线业务信息、以及采用第一类方式进行处理的标 记)；如果用户信息对应的IP-CAN承载永远在线能力没有激活，则通知核心 网设备采用第二类方式(由核心网设备通知NAT功能实体不释放永远在线业 务对应公网地址、且保持对应的IP-CAN会话不释放)为用户信息对应的 IP-CAN会话保持永远在线能力(基于第二类方式的请求通知中携带永远在线 业务信息、IP-CAN会话信息、以及采用第二类方式进行处理的标记)。

具体的，在PCRF上存储(如以表格方式存储)并维护了业务标记信息， 该业务标记信息中记录了永远在线业务对应的用户信息(即用户属性信息，如 IP地址等)、IP-CAN会话信息、IP-CAN会话承载激活或者未激活永远在线能 力的状态信息、永远在线业务承载激活状态(即承载处于激活状态或者承载处 于未激活状态)、以及业务服务器归属(可由永远在线业务标识确定)的对应 关系。

基于该业务标记信息中记录的对应关系，则根据永远在线业务请求信息中 携带的用户信息，可在业务标记信息中查询到该用户信息对应的IP-CAN会话 承载永远在线能力是否已激活，如业务标记信息中没有用户信息对应的 IP-CAN会话承载永远在线能力时为未激活。

方式二：通过查询预先维护的业务标记信息确定用户信息对应的IP-CAN 会话承载永远在线能力是否已激活时，用户信息对应的IP-CAN会话承载永远 在线能力已激活或者没有激活，PCRF均通知核心网设备为用户信息对应的 IP-CAN会话保持永远在线能力(该通知中携带永远在线业务信息、IP-CAN会 话信息)，由核心网设备来确定采用第一类方式或者第二类方式为用户信息对 应的IP-CAN会话保持永远在线能力。

本发明实施例中，当用户信息对应的IP-CAN会话承载永远在线能力没有 激活时，在通知核心网设备为用户信息对应的IP-CAN会话保持永远在线能力 的过程中，PCRF还需在业务标记信息中将用户信息对应的IP-CAN会话承载 永远在线能力修改为IP-CAN会话承载永远在线能力激活状态；并将永远在线 业务承载修改为永远在线业务承载激活状态。当用户信息对应的IP-CAN会话 承载永远在线能力已激活时，PCRF还需将永远在线业务承载修改为永远在线 业务承载激活状态。

步骤404，核心网设备接收来自PCRF的永远在线业务的请求通知，并为 永远在线业务对应的IP-CAN会话保持永远在线能力。

具体的，在PCRF通知核心网设备为用户信息对应的IP-CAN会话保持永 远在线能力时，核心网设备可接收到永远在线业务的请求通知，该请求通知中 携带请求为永远在线业务的IP-CAN会话保持永远在线能力的信息(即永远在 线业务承载能力请求)，根据该永远在线业务承载能力请求，核心网设备获知 需要为IP-CAN会话保持永远在线能力。另外，针对不同的处理方式，该请求 通知中还可以携带其他信息。

本发明实施例中，针对方式一，如果用户信息对应的IP-CAN会话承载永 远在线能力已激活，则说明核心网设备之前已经为对应该IP-CAN会话的其他 类型的永远在线业务保持了永远在线能力，而由于不同业务对应的公网地址不 同，核心网设备只要通知NAT功能实体不释放永远在线业务对应的公网地址， 即可为当前的永远在线业务的IP-CAN会话保持永远在线能力。

因此，基于第一类通知方式的请求通知中携带永远在线业务信息和采用第 一类方式进行处理的标记，当核心网设备接收到该请求通知后，即可直接通知 NAT功能实体不释放永远在线业务(根据永远在线业务信息获知)对应的公网 地址。

如果用户信息对应的IP-CAN会话承载永远在线能力没有激活，则说明核 心网设备之前并没有为对应该IP-CAN会话的其他类型的永远在线业务保持永 远在线能力，核心网设备需要通知NAT功能实体不释放永远在线业务对应的 公网地址，且保持对应的IP-CAN会话不释放(如不主动发起PDP去活流程)， 从而为当前的永远在线业务的IP-CAN会话保持永远在线能力。

因此，基于第二类通知方式的请求通知中携带永远在线业务信息、IP-CAN 会话信息和采用第二类方式进行处理的标记，当核心网设备接收到该请求通知 后，即可直接通知NAT功能实体不释放永远在线业务(根据永远在线业务信 息获知)对应的公网地址，且保持IP-CAN会话(根据IP-CAN会话信息获知) 不释放。

针对方式二，由核心网设备自身确定为当前的永远在线业务的IP-CAN会 话保持永远在线能力的方式，请求通知中携带永远在线业务信息、IP-CAN会 话信息；而由于请求通知中未携带采用第一、二类方式进行处理的标记，因此， 当接收到为IP-CAN会话保持永远在线能力的请求通知时，核心网设备根据 IP-CAN会话信息确定IP-CAN会话对应的承载永远在线能力已激活或者没有 激活(可通过判断是否已经为IP-CAN会话保持永远在线能力的方式进行判 断)，如果IP-CAN会话对应的承载永远在线能力已激活，核心网设备通知NAT 功能实体不释放永远在线业务对应公网地址，如果IP-CAN会话对应的承载永 远在线能力没有激活，核心网设备通知NAT功能实体不释放永远在线业务对 应公网地址，且保持对应的IP-CAN会话不释放。

综上所述，本步骤中，核心网设备将对应IP-CAN会话为变更为永远在线 业务承载，并为该IP-CAN会话保持永远在线能力(包括通知NAT功能实体不 释放公网地址、和/或，保持对应的IP-CAN会话不释放等)。

步骤405，核心网设备向PCRF返回信息确认当前永远在线业务承载已具 有永远在线业务承载能力。

步骤406，PCRF通知AF已为当前永远在线业务(即上述进行处理的永远 在线业务)开通永远在线能力。

本发明实施例中，当接收到核心网设备返回的确认当前永远在线业务承载 已具有永远在线业务承载能力后，PCRF还需要维护业务标记信息。如果用户 信息对应的IP-CAN会话承载永远在线能力已激活，则业务标记信息中已经记 录了该IP-CAN会话承载永远在线能力的相关信息，PCRF在业务标记信息中 维护当前的永远在线业务的相关信息即可；如果用户信息对应的IP-CAN会话 承载永远在线能力没有激活，业务标记信息中没有记录该IP-CAN会话承载永 远在线能力的相关信息时，PCRF在业务标记信息中记录IP-CAN会话对应的 已激活永远在线业务标记，该标记包括永远在线业务对应的用户信息、永远在 线业务承载激活状态、IP-CAN会话信息、业务服务器归属等信息，并在永远 在线业务承载激活状态上标明激活，从而实现永远在线业务上线的过程。

综上所述，本发明实施例中，在业务服务器(AF)上新增永远在线业务通 知功能，在PCRF上增加业务标记功能，在核心网设备上增加承载的状态管理 功能，核心网侧提供永远在线业务承载NAT公网地址不释放、不主动去激活 IP-CAN会话，从而可有效实现分组域混合组网场景下，为永远在线业务提供 永远在线能力的方法，使得业务无需依赖心跳包来维护用户在线状态，节约信 令开销。因此，本发明实施例对核心网处理永远在线业务方案进行改进，有效 的解决了现有方案中存在的无法提供业务永远在线能力，导致业务侧需要通过 “心跳包”来维护永远在线状态，引起过多信令负荷的问题。

实施例二

如图5所示，基于图3所示的应用场景示意图，永远在线业务的IP-CAN 会话释放流程包括以下步骤：

步骤501，用户设备向核心网设备发起释放IP-CAN会话流程(如PDP上 下文去激活)。

步骤502，核心网设备收到释放IP-CAN请求后，判断该IP-CAN会话承 载是否为永远在线业务承载。

如果该IP-CAN会话承载是永远在线业务承载且用户设备释放IP-CAN请 求的原因为非不可抗拒(如用户设备没电、关机等)原因(即不是用户设备主 动下线导致的释放过程)，执行步骤503；否则，执行步骤504。

步骤503，核心网设备缓存业务服务器发向用户设备的消息。之后，核心 网设备等待永远在线业务承载的保活，并在永远在线业务的承载保活成功后向 用户设备重发缓存的内容；或者，如果永远在线业务承载保活失败或不进行永 远在线业务承载保活，核心网设备可删除对应缓存的内容。

步骤504，核心网设备通知PCRF释放IP-CAN会话。

步骤505，PCRF收到释放IP-CAN会话的请求后，从业务标记信息中判断 该IP-CAN会话的承载是否已经存在永远在线业务，如果是，执行步骤506， 否则，执行现有的释放IP-CAN的流程。

具体的，现有的释放IP-CAN的流程包括：PCRF标识受影响的PCC策略， 核心网设备删除对应的所有策略和计费规则，PCRF向AF告知传输丢失并向 核心网设备确认释放IP-CAN会话，核心网设备响应UE发起的IP-CAN会话 释放请求，释放IP-CAN的流程结束，该过程本发明实施例中不再详加赘述。

步骤506，PCRF选择不执行永远在线业务承载保活的策略或者选择执行 永远在线业务承载保活的策略。

步骤507，PCRF通知核心网设备确认用户设备释放IP-CAN消息，该消息 中包含对步骤504中核心网设备通知PCRF释放IP-CAN会话的确认、以及选 择执行或不执行永远在线业务承载保活的策略。

具体的，PCRF可根据实际需要选择上述两种策略的任意一种，当PCRF 选择不执行永远在线业务承载保活的策略时，核心网设备收到该策略信息后， 只执行释放IP-CAN流程，并执行步骤509；当PCRF选择执行永远在线业务 承载保活的策略时，核心网设备收到该策略信息后，执行释放IP-CAN流程， 并执行重激活永远在线业务IP-CAN会话流程。

其中，释放IP-CAN的流程本发明实施例中不再赘述，对于重激活永远在 线业务IP-CAN会话流程，包括：当PDP上下文去激活流程结束后，核心网设 备发起永远在线业务的IP-CAN会话重激活流程，核心网设备、PCRF等设备 执行永远在线业务的IP-CAN会话重激活流程。

具体的，核心网设备需要通知NAT功能实体不释放永远在线业务对应公 网地址(即不释放永远在线业务所使用的公网地址)，且保持该IP-CAN会话 不释放(如不主动发起PDP去活流程)；PCRF需要在业务标记信息中记录该 IP-CAN会话的相关信息，从而在PCRF和核心网设备上为永远在线业务的 IP-CAN会话信息保持永远在线能力，该过程与实施例一的处理过程类似，在 此不再详加赘述。

步骤508，核心网设备向PCRF返回对策略的确认消息，该确认消息中包 括永远在线业务的IP-CAN会话重激活的执行结果，如IP-CAN会话重激活成 功或失败。

步骤509，当接收到确认消息后，如果IP-CAN会话重激活成功，则结束 流程，如果IP-CAN会话重激活失败，PCRF通知AF该IP-CAN会话对应的永 远在线业务下线，由AF通知对应的业务服务器该永远在线业务下线，并向 PCRF确认永远在线业务下线。

本发明实施例中，PCRF还可以校验更新对应永远在线业务的业务标记信 息，即如果策略为不执行永远在线业务承载保活，则更新对应IP-CAN会话上 业务的业务标记信息中永远在线业务承载激活状态为去激活或者删除对应业 务标记信息。

如果策略为执行永远在线业务承载保活，则根据步骤508中的确认消息更 新对应IP-CAN会话上业务的业务标记信息，即确认消息中携带IP-CAN会话 重激活成功，则流程结束；如果确认消息中携带IP-CAN会话重激活失败，则 删除对应业务标记信息。

综上所述，本发明实施例中，在核心网设备上新增缓存机制，在PCRF上 新建永远在线业务承载的判决机制，在PCRF上新建两种永远在线业务IP-CAN 会话释放处理方法，在AF上新增永远在线业务通知功能，从而可有效实现分 组域混合组网场景下，为永远在线业务提供一种IP-CAN会话释放方式，使得 业务服务器不会感知到用户的异常断线状态，节约了业务服务器重新查找用户 设备以及用户设备重登录的资源浪费。

实施例三

如图6所示，基于图3所示的应用场景示意图，永远在线业务下线流程包 括以下步骤：

步骤601，用户设备去激活永远在线业务，相应业务服务器停止为该用户 设备提供永远在线业务。

步骤602，永远在线业务下线，业务服务器通过永远在线业务对应的AF 向PCRF发送永远在线业务去激活信息。其中，当永远在线业务对应的AF部 署在业务服务器上时，则由业务服务器直接向PCRF发送永远在线业务去激活 信息。该去激活信息中至少携带永远在线业务对应的永远在线业务标识和用户 信息(如用户设备IP地址)。

步骤603，PCRF接收到来自业务服务器的永远在线业务去激活信息后， 通知核心网设备为用户信息对应的IP-CAN会话撤销永远在线能力。

方式一：通过查询预先维护的业务标记信息确定用户信息对应的IP-CAN 会话是否还存在其他永远在线业务(每个IP-CAN会话可对应多个永远在线业 务，例如，用户设备1的IP-CAN会话可对应永远在线业务1和永远在线业务 2，当接收到永远在线业务1的去激活信息后，如果查询到业务标记信息的 IP-CAN会话还对应了永远在线业务2，则说明IP-CAN会话中还存在其他永远 在线业务；如果查询到业务标记信息的IP-CAN会话中没有对应其他永远在线 业务，则说明IP-CAN会话中不存在其他永远在线业务)，如果不存在其他永 远在线业务，PCRF通知核心网设备采用第三类方式(由核心网设备通知NAT 功能实体对永远在线业务启用公网地址管理方式，并将IP-CAN会话修改为数 据业务的IP-CAN会话)撤销IP-CAN会话的永远在线能力(基于第三类方式 的去激活通知中携带永远在线业务信息、永远在线业务对应的IP-CAN会话、 采用第三类方式进行处理的标记)；如果存在其他永远在线业务，PCRF通知核 心网设备采用第四类方式(由核心网设备通知NAT功能实体对永远在线业务 启用公网地址管理方式)撤销IP-CAN会话的永远在线能力(基于第四类方式 的去激活通知中携带永远在线业务信息、采用第四类方式进行处理的标记)。

方式二：通过查询预先维护的业务标记信息确定用户信息对应的IP-CAN 会话存在或不存在其他永远在线业务时，PCRF均通知核心网设备核心网设备 撤销IP-CAN会话的永远在线能力(该通知中携带永远在线业务信息、永远在 线业务对应的IP-CAN会话)，由核心网设备确定采用第三类方式或者第四类 方式撤销IP-CAN会话的永远在线能力。

步骤604，核心网设备接收来自PCRF的永远在线业务的去激活通知，并 撤销永远在线业务对应的IP-CAN会话的永远在线能力。

具体的，在PCRF通知核心网设备撤销永远在线业务对应的IP-CAN会话 的永远在线能力时，核心网设备可接收到去激活通知，该去激活通知消息中携 带请求为永远在线业务的IP-CAN会话撤销永远在线能力的信息(即永远在线 业务承载能力去激活请求)，根据该永远在线业务承载能力去激活请求，核心 网设备获知需要为IP-CAN会话撤销永远在线能力。另外，针对不同的处理方 式，该去激活通知还可以携带其他信息。

本发明实施例中，针对方式一，基于第三类方式的去激活通知中携带永远 在线业务信息、永远在线业务对应的IP-CAN会话、采用第三类方式进行处理 的标记，当接收到来自PCRF的采用第三类方式撤销IP-CAN会话的永远在线 能力的去激活通知时，核心网设备通知NAT功能实体对永远在线业务启用公 网地址管理方式，并将IP-CAN会话修改为数据业务的IP-CAN会话(即将对 应的IP-CAN会话变更为现有数据业务承载方式，如当用户空闲一段时间后， 可以从核心网侧主动发起PDP上下文去激活)。

基于第四类方式的去激活通知中携带永远在线业务信息话、采用第四类方 式进行处理的标记，当接收到来自PCRF的采用第四类方式撤销IP-CAN会话 的永远在线能力的去激活通知时，核心网设备通知NAT功能实体对永远在线 业务启用公网地址管理方式。

针对方式二，由核心网设备自身确定撤销IP-CAN会话的永远在线能力的 方式，去激活通知中携带永远在线业务信息、永远在线业务对应的IP-CAN会 话，当接收到来自PCRF的去激活通知后，核心网设备确定IP-CAN会话是否 还存在其他永远在线业务；如果不存在其他永远在线业务，核心网设备通知 NAT功能实体对永远在线业务启用公网地址管理方式，并将IP-CAN会话修改 为数据业务的IP-CAN会话；如果存在其他永远在线业务，核心网设备通知NAT 功能实体对永远在线业务启用公网地址管理方式。

步骤605，核心网设备向PCRF返回信息确认当前永远在线业务承载能力 去激活，执行现有数据业务策略。

步骤606，PCRF通知AF已为当前永远在线业务(即上述进行处理的永远 在线业务)去激活永远在线能力。

本发明实施例中，PCRF还需要修改IP-CAN会话对应的永远在线业务的 业务标记信息，在对应的永远在线业务承载激活状态上标明去激活，当一个 IP-CAN会话对应的所有业务标记信息中永远在线业务承载激活状态都为去激 活时，可以删除对应业务标记，从而实现永远在线业务下线的过程。

综上所述，本发明实施例中，可有效实现分组域混合组网场景下，为永远 在线业务提供一种下线的处理方式，当不需要为永远在线业务提供永远在线能 力时，可恢复普通业务的IP-CAN会话，节约了网络资源。

实施例四

如图7所示，基于上述方法同样的发明构思，本发明实施例中还提出了一 种策略与计费规则功能实体PCRF，包括：

接收模块11，用于接收来自业务服务器的永远在线业务请求信息，所述请 求信息中携带永远在线业务对应的用户信息；

通知模块12，用于通知核心网设备为所述用户信息对应的IP-CAN会话保 持永远在线能力。

所述通知模块12，具体用于如果所述用户信息对应的IP-CAN会话承载永 远在线能力已激活，通知所述核心网设备采用第一类方式为所述用户信息对应 的IP-CAN会话保持永远在线能力；或者，如果所述用户信息对应的IP-CAN 会话承载永远在线能力没有激活，通知所述核心网设备采用第二类方式为所述 用户信息对应的IP-CAN会话保持永远在线能力；或者，

当所述用户信息对应的IP-CAN会话承载永远在线能力已激活或者没有激 活时，通知所述核心网设备为所述用户信息对应的IP-CAN会话保持永远在线 能力，由所述核心网设备确定采用第一类方式或者第二类方式为所述用户信息 对应的IP-CAN会话保持永远在线能力。

本发明实施例中，还包括：获取模块13，用于获知所述用户信息对应的 IP-CAN会话承载永远在线能力是否激活；其中，根据所述用户信息查询预先 维护的业务标记信息，所述业务标记信息中记录用户信息、IP-CAN会话信息、 IP-CAN会话承载激活或者未激活永远在线能力的状态信息、永远在线业务激 活状态信息的对应关系；并根据查询结果获知所述用户信息对应的IP-CAN会 话承载永远在线能力为激活状态或者未激活状态。

本发明实施例中，还包括：第一处理模块14，用于当从来自核心网设备的 释放IP-CAN会话的请求信息中获知所述IP-CAN会话的承载已经存在永远在 线业务时，选择不执行永远在线业务承载保活的策略，将选择的策略通知给所 述核心网设备，并和所述核心网设备执行释放IP-CAN会话的流程，以及通知 业务服务器所述IP-CAN会话对应的永远在线业务下线。

第二处理模块15，用于当从来自核心网设备的释放IP-CAN会话的请求信 息中获知所述IP-CAN会话的承载已经存在永远在线业务时，选择执行永远在 线业务承载保活的策略，将选择的策略通知给所述核心网设备，并和所述核心 网设备执行释放IP-CAN会话的流程、重激活永远在线业务的IP-CAN会话的 流程；如果永远在线业务的IP-CAN会话重激活失败，通知业务服务器所述 IP-CAN会话对应的永远在线业务下线。

所述接收模块11，还用于接收来自业务服务器的永远在线业务去激活信 息，所述去激活信息中携带永远在线业务对应的用户信息；

所述通知模块12，还用于当所述用户信息对应的IP-CAN会话不存在其他 永远在线业务时，通知核心网设备采用第三类方式撤销所述IP-CAN会话的永 远在线能力；或者，当所述用户信息对应的IP-CAN会话存在其他永远在线业 务时，通知核心网设备采用第四类方式撤销所述IP-CAN会话的永远在线能力 或者，

通知核心网设备撤销所述用户信息对应的IP-CAN会话的永远在线能力； 由所述核心网设备确定采用第三类方式或者第四类方式撤销所述IP-CAN会话 的永远在线能力。

实施例五

基于上述方法同样的发明构思，本发明实施例还提供了一种核心网设备， 如图8所示，该核心网设备包括：

接收模块21，用于接收来自PCRF的永远在线业务的请求通知，所述请求 通知中携带永远在线业务信息、请求为永远在线业务的IP-CAN会话保持永远 在线能力的信息；

能力保持模块22，用于为所述永远在线业务的IP-CAN会话保持永远在线 能力。

所述能力保持模块22，具体用于当接收到采用第一类方式为所述IP-CAN 会话保持永远在线能力的请求通知时，通知NAT功能实体不释放永远在线业 务对应的公网地址；当接收到采用第二类方式为所述IP-CAN会话保持永远在 线能力的携带IP-CAN会话信息的请求通知时，通知NAT功能实体不释放永远 在线业务对应公网地址，且保持所述IP-CAN会话不释放；或者，

当接收到为所述IP-CAN会话保持永远在线能力的携带IP-CAN会话信息 的请求通知时，根据所述IP-CAN会话信息确定IP-CAN会话对应的承载永远 在线能力已激活或者没有激活；当所述IP-CAN会话对应的承载永远在线能力 已激活时，通知NAT功能实体不释放永远在线业务对应公网地址；当所述 IP-CAN会话对应的承载永远在线能力没有激活时，通知NAT功能实体不释放 永远在线业务对应公网地址，且保持所述IP-CAN会话不释放。

本发明实施例中，还包括：第一处理模块23，用于当从来自用户设备的释 放IP-CAN会话的请求信息中获知所述IP-CAN会话的承载为永远在线业务承 载时，缓存业务服务器向所述用户设备发送的内容；当永远在线业务的承载保 活成功后，向所述用户设备发送缓存的内容；或者，当永远在线业务的承载保 活失败或不进行永远在线业务的承载保活时，删除缓存的内容。

本发明实施例，还包括：第二处理模块24，用于当从来自用户设备的释放 IP-CAN会话的请求信息中获知所述IP-CAN会话的承载为永远在线业务承载 时，向PCRF发送释放IP-CAN会话的请求信息；接收来自所述PCRF的不执 行永远在线业务承载保活的策略，并和所述PCRF执行释放IP-CAN会话的流 程；或者，接收来自所述PCRF的执行永远在线业务承载保活的策略，并和所 述PCRF执行释放IP-CAN会话的流程、重激活永远在线业务的IP-CAN会话 的流程。

该设备还包括：能力撤销模块25，用于当接收到来自PCRF的采用第三类 方式撤销IP-CAN会话的永远在线能力的去激活通知时，通知NAT功能实体对 永远在线业务启用公网地址管理方式，并将IP-CAN会话修改为数据业务的 IP-CAN会话；基于第三类方式的去激活通知中携带永远在线业务信息、永远 在线业务对应的IP-CAN会话；或者，当接收到来自PCRF的采用第四类方式 撤销IP-CAN会话的永远在线能力的去激活通知时，通知NAT功能实体对永远 在线业务启用公网地址管理方式，基于第四类方式的去激活通知中携带永远在 线业务信息；或者，

当接收到来自PCRF的携带永远在线业务信息、永远在线业务对应的 IP-CAN会话的去激活通知时，确定所述IP-CAN会话是否还存在其他永远在 线业务；如果不存在其他永远在线业务，通知NAT功能实体对永远在线业务 启用公网地址管理方式，并将IP-CAN会话修改为数据业务的IP-CAN会话； 如果存在其他永远在线业务，通知NAT功能实体对永远在线业务启用公网地 址管理方式。

实施例六

基于上述方法和设备同样的发明构思，本发明实施例中还提供了一种永远 在线能力的提供系统，包括上述实施例四的策略与计费规则功能实体PCRF和 实施例五的核心网设备；此外，该系统还包括：

业务服务器，用于在永远在线业务上线时，向PCRF发送携带永远在线业 务对应的用户信息的永远在线业务请求信息；在永远在线业务下线时，向PCRF 发送携带永远在线业务对应的用户信息的永远在线业务去激活信息。

应用功能实体AF，用于在业务服务器向PCRF发送携带永远在线业务对 应的用户信息的永远在线业务请求信息时，接收来自所述业务服务器的永远在 线业务请求信息，并将永远在线业务请求信息发送给所述PCRF；在业务服务 器向PCRF发送携带永远在线业务对应的用户信息的永远在线业务去激活信息 时，接收来自所述业务服务器的永远在线业务去激活信息，并将永远在线业务 去激活信息发送给所述PCRF。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明 实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实 现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出 来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘， 移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机， 服务器，或网络设备等)执行本发明实施例各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的 模块或流程并不一定是实施本发明实施例所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景 描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场 景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进 一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本发明实施例的几个具体实施场景，但是，本发明实施例 并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明实施例的 业务限制范围。