CN104253739A - 一种永远在线业务的实现方法、系统和设备 - Google Patents
一种永远在线业务的实现方法、系统和设备 Download PDFInfo
- Publication number
- CN104253739A CN104253739A CN201310269578.2A CN201310269578A CN104253739A CN 104253739 A CN104253739 A CN 104253739A CN 201310269578 A CN201310269578 A CN 201310269578A CN 104253739 A CN104253739 A CN 104253739A
- Authority
- CN
- China
- Prior art keywords
- aoi
- middleware
- link
- service
- customer end
- 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
Landscapes
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种永远在线业务的实现方法、系统和设备，终端设备上部署有AOI中间件，移动核心网部署有AOI服务器，AOI中间件与AOI服务器之间建立有公共通知链路，该方法包括：在终端设备的业务客户端与业务平台之间保活了业务链路后，AOI中间件监控业务客户端的应用状态；当监控到业务客户端的应用状态为异常状态时，AOI中间件通过公共通知链路将业务客户端出现异常状态的信息通知给AOI服务器；由AOI服务器将业务客户端出现异常状态的信息通知给业务平台，通知PCRF关闭业务客户端与业务平台之间的业务链路的长连接，由PCRF通知GGSN/防火墙去保活业务客户端与业务平台之间的业务链路。本发明实施例中，可以降低网络资源消耗。
Description
技术领域
本发明涉及通信技术领域，尤其是涉及一种永远在线业务的实现方法、系统和设备。
背景技术
当智能手机和移动电脑被广泛应用后，出现了永远在线业务的需求，如即时聊天业务、社交网络业务、邮件推送业务等，永远在线业务为了体现出用户与服务器的操作性，减少网络在用户使用业务时对用户的影响，提高用户体验，需要获知用户是否还连接在服务器上。永远在线类业务的服务器获知用户与服务器间连接状态的方法为：服务器接收来自用户的保持在线状态信息（即心跳包（keep alive）消息），当服务器收到用户的心跳包时，证明用户连接在服务器上，确定用户在线的状态，从而实现永远在线的特征。
用户在使用永远在线业务时不希望受到由于网络状况或者服务器状况而产生的延迟，在高突发性数据发生时，要求永远在线业务可以做出快速响应。为此，数据推送技术是一种服务器主动将信息发送给客户端的技术；通过Push（推送）技术，可将重要的信息主动及时地推送到移动终端上，使用户能够随时随地接收信息，为用户提供了极大方便。其中，现有的Push方式包括：短信EMN（电子邮件通知）Push方式；通过建立IP长连接，发送心跳包维持连接的方式；通过运营商核心网设备保活用户的IP-CAN（Connectivity AccessNetwork，连接访问网络）连接，从而使业务无需发送心跳包机制来维护状态。
在实现本发明的过程中，发明人发现现有技术中至少存在以下问题：
服务器获知用户是否还连接在服务器上时，现有无线网络机制按照用户使用间断、大数量的应用来设计，当用户静默一段时间后，网络侧会释放资源，不再提供永远在线能力，当永远在线业务承载在无线网络时，需要通过心跳包机制来维护在线能力，而心跳包往往比较短，数据量小，只包含用户部分信息，且发送间隔时间较长；因此会导致大量信令消耗，占用网络资源。
采用EMN Push方式时，所有Push类通知消息只能通过短信网关进行下发，但短信的时间延迟长，且容易导致消息无法及时通知客户端。另外，Push短信通知业务下载数据的方式，在Push短信中无法直接携带相关业务数据，Push短信仅仅起到通知作用，每次Push短信都需要唤醒业务应用去下载相关数据，导致一次业务数据获取流程较长，而频繁的业务交互容易导致短信网关负载较大以及应用频繁的去进行网络连接，都是对移动网络资源的不必要浪费。
在通过建立IP长连接的Push方式中，需要与网络建立一个长时间的连接，通过IP长连接方式处理信息和信息交互，在用户不需要使用业务时该连接也将保持，从而增加了不必要的数据流量和费用，并且会导致终端耗电量大。
运营商核心网保活用户IP-CAN连接的Push方式中，无法处理网络的各种异常情况，造成核心网资源的浪费；移动终端异常下线时，应用状态不一致。
发明内容
本发明实施例提供一种永远在线业务的实现方法和设备，以降低网络资源消耗，解决现有业务心跳包策略导致移动网络资源滥用的问题。
为达到上述目的，本发明实施例提供一种永远在线业务的实现方法，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，该方法包括以下步骤：
在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，所述AOI中间件监控所述业务客户端的应用状态；
当监控到所述业务客户端的应用状态为异常状态时，所述AOI中间件通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；由所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
本发明实施例提供一种永远在线业务的实现方法，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，该方法包括以下步骤：
在终端设备的业务客户端与业务平台之间保活了业务链路之后，如果所述AOI中间件监控到业务客户端的异常状态，则所述AOI服务器通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息；
所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
本发明实施例提供一种永远在线业务的实现系统，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，其中：
所述AOI中间件，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；并当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；
所述AOI服务器，用于通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息，将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
本发明实施例提供一种终端设备上部署的永远在线基础实施AOI中间件，所述AOI中间件与AOI服务器之间建立有公共通知链路，且所述AOI服务器部署在移动核心网，所述AOI中间件具体包括：
处理模块，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；
通信模块，用于当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；由所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
本发明实施例提供一种移动核心网侧部署的永远在线基础实施AOI服务器，AOI中间件与所述AOI服务器之间建立有公共通知链路，且所述AOI中间件部署在终端设备上，所述AOI服务器具体包括：
接收模块，用于在终端设备的业务客户端与业务平台之间保活了业务链路之后，如果所述AOI中间件监控到业务客户端的异常状态，则通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息；
发送模块，用于将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
与现有技术相比，本发明实施例至少具有以下优点：本发明实施例中，通过在AOI（Always Online Infrastructure，永远在线基础实施）中间件和AOI服务器之间建立公共通知链路，并取消心跳的永远在线方法，从而解决现有业务心跳包策略导致移动网络资源滥用的问题，为移动应用提供一整套端到端的永远在线解决方案，降低网络资源消耗。进一步的，通过在应用侧将所有业务的Push通道及小数据量消息传输通道进行了归并，减少了终端设备和网络之间的数据链接，同时可以将小数据包进行合并传输，减少了网络中小包的传输。通过网络侧对需要长期保持的链路进行保活，取消或者延长了心跳消息报文的间隔时长，可以大量减少网络中传输的心跳消息。收敛应用的长连接可以减少网络侧需要保活的连接数量，减少核心网中的资源消耗。
附图说明
为了更清楚地说明本发明的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1是本发明实施例一提供的一种永远在线业务的实现方法流程示意图；
图2是本发明实施例二提供的一种永远在线业务的实现方法流程示意图；
图3是本发明实施例三提供的一种永远在线业务的实现方法流程示意图；
图4是本发明实施例四提供的一种永远在线业务的实现方法流程示意图；
图5是本发明实施例五提供的一种永远在线业务的实现方法流程示意图；
图6是本发明实施例六提供的一种永远在线业务的实现方法流程示意图；
图7是本发明实施例七提供的一种永远在线业务的实现方法流程示意图；
图8是本发明实施例八提供的一种永远在线业务的实现方法流程示意图；
图9是本发明实施例十提供的一种AOI中间件的结构示意图；
图10是本发明实施例十一提供的一种AOI服务器的结构示意图。
具体实施方式
下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
根据现有技术中对永远在线心跳原因的分析，心跳主要是由于需要保持移动网络中的防火墙/NAT（Network Address Translation，网络地址转换）设备的映射关系和PDP（Packet Data Protocol，分组数据协议）资源而产生的。而移动运营商在网络侧具有能力根据应用的需求为应用提供永远在线服务，维持PDP资源和公网IP地址，替换原有应用中依靠心跳包维持永远在线的能力，同时协调应用协同取消心跳，通过网络侧来保证长连接的可靠链路。
但是，通过网络侧来保证长连接的可靠链路时，并没有规定何时释放长连接的相关技术方案，从而导致长连接资源的浪费。
实施例一
针对现有技术中存在的问题，本发明实施例一提供一种永远在线业务的实现方法，通过对永远在线的应用和离线Push需求进行整合，在终端设备上部署AOI中间件，在移动核心网部署AOI服务器，并通过在AOI中间件和AOI服务器之间建立公共通知链路，以通过该公共通知链路收敛所有永远在线需求应用、Push和部分消息传输通道，并结合运营商的优势，在网络侧通过PCRF（Policy and Charging Rules Function，策略与计费规则功能）的策略控制，保活公共通知链路。此外，针对一些业务需要大量传输数据的通道，通过建立业务的长连接，并建立业务链路，以通过PCRF维持业务通道。
本发明实施例中，在终端设备侧部署一个AOI中间件，AOI中间件具有注册管理和消息分发功能，并收敛终端设备侧所有注册业务网络连接，此AOI中间件可以预置在终端设备中，可进行后期安装和升级操作，其主要功能如下：（1）注册：注册管理模块主要负责终端设备的业务注册到AOI中间件，并通过AOI中间件向AOI服务器注册永远在线能力；（2）收敛链路：AOI中间件与AOI服务器建立统一永远在线连接（即公共通知链路），并监听从AOI服务器下发的各种消息；同时AOI中间件与AOI服务器进行定期的状态信息交互，维持业务链路的状态，实现定期检测业务链路状态；（3）上传业务消息：AOI中间件负责接收从业务客户端上发的业务消息，并通过公共通知链路转发给AOI服务器，并由AOI服务器发给业务平台；（4）接收并分发消息：AOI中间件负责接收AOI服务器推送来的业务数据，并唤醒对应注册的业务客户端，将业务数据传递给业务客户端；（5）Push短信接收并分发：AOI中间件负责监听短信网关的Push的携带业务数据的短消息，并唤醒对应注册的业务客户端（即业务数据对应的业务客户端），将业务数据传递给业务客户端；（6）业务状态维护及异常处理：AOI中间件与业务客户端进行状态交互，如发现业务客户端的异常状况，通过公共通知链路将业务客户端的异常状态信息发送给AOI服务器，由AOI服务器将异常状态信息转发给业务平台。
PCRF是PCC（Policy and Charging Control，策略与计费控制）架构的核心，主要负责策略决策和计费规则的制定，本发明实施例中，需要对PCRF进行改造，通过PCRF通知GGSN和防火墙保持状态，业务无需在此链路上再发送心跳包数据进行链路的维持，链路维持由核心网提供能力，并要求PCRF实现如下功能：（1）接收保活或去保活请求：PCRF负责接收AOI服务器发来的链路保活请求和链路去保活请求，并处理由AOI服务器发来的链路保活请求和链路去保活请求；（2）执行保活或去保活处理：PCRF根据AOI服务器发来的链路保活请求或链路去保活请求，通知GGSN和防火墙/NAT进行相关链路的保活处理或者去保活处理；具体的，PCRF在收到来自AOI服务器的链路保活请求后，通知GGSN和防火墙/NAT设备进行链路保活处理，且在链路保活处理之后，业务客户端在相应链路上不需要发送心跳包数据进行链路的维持；PCRF在收到来自AOI服务器的链路去保活请求之后，通知GGSN和防火墙/NAT设备进行链路去保活处理，且在链路去保活处理后，业务客户端在相应链路上需要发送心跳包数据进行链路的维持；（3）分配信道资源：根据永远在线业务的种类，进行通信信道的合理分配。
本发明实施例中，在移动核心网部署AOI服务器，该AOI服务器负责维护和管理业务的永远在线能力，其主要功能如下：（1）公共通知链路：与AOI中间件之间建立和维护统一的公共通知链路；（2）业务注册：负责对永远在线类业务的相关能力进行管理，包括注册注销和能力识别等；（3）业务消息推送：与业务平台接口，负责在业务平台和AOI中间件之间传递消息；（4）业务链路维护：与业务平台接口，负责将业务的业务链路保活请求，传递给核心网PCRF；（5）异常处理：负责通过公共通知链路接收AOI中间件上报的业务客户端异常状况，并在发现业务客户端出现异常时，将状态信息上报给业务平台，并根据情况通知核心网PCRF释放业务客户端对应的保活链路。
综上所述，针对永远在线需求，在应用层设计AOI中间件和AOI服务器，并在AOI中间件和AOI服务器之间建立公共通知链路，网络侧为各应用维护其永远在线通道，当多个永远在线类应用并存时，AOI中间件可对注册的永远在线类应用客户端状态进行监听，并通过AOI服务器反馈给业务平台，实现只维护一条公共通知链路，并通过异常检测机制保证连接可靠性，避免网络侧维护多条GGSN和防火墙/NAT的长连接数。进一步的，通过对业务的类型识别，还可基于PCC架构实现对永远在线类应用其它小数据包的无线资源调度优化，进一步降低对无线网络的影响。进一步的，公共通知链路根据注册的永远在线类业务需求进行合理的开启和关闭，在公用链路未被建立时，AOI服务器可通过下发短信通知AOI中间件进行公用链路的建立。
本发明实施例中，需要在终端设备的业务客户端与业务平台之间建立业务链路，并保活业务客户端与业务平台之间的业务链路。基于此：业务平台通知AOI服务器保活业务客户端与业务平台之间的业务链路，AOI服务器在收到保活业务客户端与业务平台之间的业务链路的通知后，通知PCRF维持业务客户端与业务平台之间的业务链路的长连接，并由PCRF通知GGSN（Gateway GPRS Support Node，网关GPRS支持节点）/防火墙（即GGSN和/或防火墙，且防火墙可以为防火墙和NAT设备的集成）保活业务客户端与业务平台之间的业务链路，以在业务客户端与业务平台之间保活业务链路。
本发明实施例中，需要在AOI中间件与AOI服务器之间建立公共通知链路，并保活AOI中间件与AOI服务器之间的公共通知链路。基于此：AOI中间件在收到来自业务客户端的注册请求后，判断AOI中间件与AOI服务器之间的公共通知链路是否已经建立；如果未建立，则AOI中间件向AOI服务器发送用于建立公共通知链路的请求；AOI服务器在收到用于建立公共通知链路的请求后，通知PCRF维持AOI中间件与AOI服务器之间的公共通知链路的长连接，并由PCRF通知GGSN/防火墙保活AOI中间件与AOI服务器之间的公共通知链路，以建立AOI中间件与AOI服务器之间的公共通知链路。
基于上述业务客户端与业务平台之间的业务链路（业务如果有大量数据传输，则可以建立业务链路用于业务消息的传递）、以及AOI中间件与AOI服务器之间的公共通知链路（用于离线消息的推送，以及部分业务小消息的发送和接收），如图1所示，在终端设备的业务客户端与业务平台之间保活了业务链路之后，该永远在线业务的实现方法包括以下步骤：
步骤101，AOI中间件监控业务客户端的应用状态。
步骤102，当监控到业务客户端的应用状态为异常状态时，AOI中间件通过公共通知链路将业务客户端出现异常状态的信息通知给AOI服务器。
步骤103，AOI服务器通过公共通知链路接收来自AOI中间件的业务客户端出现异常状态的信息，并将业务客户端出现异常状态的信息通知给业务平台，并通知PCRF关闭业务客户端与业务平台之间的业务链路的长连接。
步骤104，PCRF通知GGSN/防火墙（即GGSN和/或防火墙/NAT设备）去保活业务客户端与业务平台之间的业务链路。
本发明实施例中，基于AOI中间件与AOI服务器之间的公共通知链路，AOI服务器接收来自业务平台的业务数据，并当AOI中间件与AOI服务器之间的公共通知链路建立时，AOI服务器通过公共通知链路将业务数据转发给AOI中间件；AOI中间件通过公共通知链路接收来自AOI服务器的业务数据，并唤醒业务数据对应的业务客户端，将业务数据转发给业务客户端。和/或，AOI中间件接收来自业务客户端的业务数据，并通过公共通知链路将业务数据转发给AOI服务器；AOI服务器通过公共通知链路接收来自AOI中间件的业务数据，并将业务数据转发给业务客户端对应的业务平台。
本发明实施例中，基于AOI中间件与AOI服务器之间的公共通知链路，AOI服务器接收来自业务平台的业务数据，当AOI中间件与AOI服务器之间的公共通知链路未建立时，AOI服务器向短信网关发送携带业务数据的短消息，短信网关将携带业务数据的短消息发送给AOI中间件；AOI中间件接收来自短信网关的携带业务数据（发送给业务客户端的业务数据）的短消息，唤醒业务数据对应的业务客户端，将携带业务数据的短消息发给业务客户端。
本发明实施例中，基于业务客户端与业务平台之间的业务链路，在业务客户端与业务平台之间保活了业务链路之后，当业务客户端注销下线时，AOI服务器接收来自业务平台的关闭业务客户端与业务平台之间的业务链路的通知，并通知PCRF关闭业务客户端与业务平台之间的业务链路的长连接，并由PCRF通知GGSN/防火墙去保活业务客户端与业务平台之间的业务链路。
本发明实施例中，基于AOI中间件与AOI服务器之间的公共通知链路，当终端设备上所有业务客户端均注销永远在线能力时，AOI中间件向AOI服务器发送用于拆除公共通知链路的请求；AOI服务器在收到用于拆除公共通知链路的请求后，通知PCRF关闭AOI中间件与AOI服务器之间的公共通知链路的长连接，PCRF通知GGSN/防火墙去保活AOI中间件与AOI服务器之间的公共通知链路，以拆除AOI中间件与AOI服务器之间的公共通知链路。
综上所述，本发明实施例中，通过在AOI中间件和AOI服务器之间建立公共通知链路，并取消心跳的永远在线方法，从而解决现有业务心跳包策略导致移动网络资源滥用的问题，为移动应用提供一整套端到端的永远在线解决方案，降低网络资源消耗。进一步的，通过在应用侧将所有业务的Push通道及小数据量消息传输通道进行了归并，减少了终端设备和网络之间的数据链接，同时可以将小数据包进行合并传输，减少了网络中小包的传输。通过网络侧对需要长期保持的链路进行保活，取消或者延长了心跳消息报文的间隔时长，可以大量减少网络中传输的心跳消息。收敛应用的长连接可以减少网络侧需要保活的连接数量，减少核心网中的资源消耗。
以下结合具体实施例对本发明提供的永远在线业务的实现进行说明。
实施例二
本实施例为永远在线业务登记开通流程。其中，业务提供方（第三方业务提供方）在接入永远在线方案前，需要到永远在线业务接入平台进行业务开通和登记，永远在线业务登记开通流程如图2所示，该流程包括以下步骤：
步骤1，业务提供方在永远在线申请portal提交永远在线业务信息，包括在永远在线申请portal填写业务名称，类型，应用平台IP地址等相关信息。
步骤2，永远在线申请portal审核业务提供方提交的永远在线业务信息，如果审核通过，则永远在线申请portal为业务提供方分配业务ID及业务密钥。
步骤3，永远在线申请portal将永远在线业务的相关信息（如业务ID及业务密钥）登记到AOI服务器，并为该永远在线业务开通使用永远在线能力。
步骤4，永远在线申请portal将永远在线业务的业务ID及业务密钥提供给业务提供方，供业务提供方研发永远在线业务使用。
实施例三
本实施例为公共通知链路以及业务链路的建立流程。其中，如果业务客户端期望使用永远在线能力，则在登录业务平台之前，需要注册业务能力到终端设备的AOI中间件，以在AOI中间件和AOI服务器之间建立公共通知链路。进一步的，为了在AOI中间件和AOI服务器之间建立公共通知链路，需要先进行永远在线业务登记开通流程（即上述实施例二），使得AOI服务器能够识别此永远在线业务，并上报PCRF进行链路维护及传递消息到业务平台。
在AOI中间件和AOI服务器之间建立公共通知链路，以及在业务客户端与业务平台之间保活业务链路的流程如图3所示，该流程包括以下步骤：
步骤1，业务客户端注册业务能力到终端设备的AOI中间件，AOI中间件接收来自业务客户端的注册请求，并在通过认证后，确认业务能力需求为永远在线能力，并判断AOI中间件和AOI服务器之间的公共通知链路是否已经建立，若没有建立，则发起建立公共通知链路的流程，即执行步骤2。
步骤2，AOI中间件向AOI服务器发送用于建立公共通知链路的请求，以为相应的业务客户端注册业务永远在线能力。
步骤3，AOI服务器根据来自AOI中间件的用于建立公共通知链路的请求中携带的业务ID判断此业务是否具有使用永远在线能力；并在具有使用永远在线能力时，将用户注册信息上传到业务平台，由业务平台对用户进行业务身份认证。当业务身份认成功时，业务平台保存AOI服务器的相关身份标识信息，并将业务鉴权成功的信息返回给AOI服务器。
步骤4，AOI服务器收到业务鉴权成功的信息后，通知PCRF为公共通知链路（AOI中间件与AOI服务器之间的公共通知链路）维持长连接。其中，AOI服务器需要将为公共通知链路维持长连接的通知消息转换为标准的Rx接口信令，并进行路由寻址及管理，将保活连接的需求通知到对应的PCRF。
步骤5，PCRF通知GGSN/防火墙保活AOI中间件与AOI服务器之间的公共通知链路。具体的，PCRF通知GGSN具体的永远在线类业务承载状态管理方法，通知消息中携带永远在线类业务承载能力请求、用户IP-CAN会话信息，之后由GGSN将对应IP-CAN会话变更为永远在线类业务承载，并为该IP-CAN会话保持永远在线能力，包括通知防火墙/NAT不释放映射、保持该IP-CAN会话不释放，为公共通知链路进行保活处理等。
基于上述处理，AOI中间件与AOI服务器之间的公共通知链路建立完成，AOI中间件与AOI服务器通过异常检测机制监听链路状态。具体的，AOI中间件与AOI服务器之间的公共通知链路被保活后，AOI中间件与AOI服务器协商，定时进行应用状态更新，以确保业务层面及时感知业务客户端的状态。
步骤6，业务客户端在业务平台登录在线后，如果业务客户端与业务平台之间存在大量的数据定期交互，则需要在业务客户端与业务平台之间直接建立业务链路，以在业务客户端与业务平台之间进行业务信息的直接交互。
步骤7，业务平台在收到使用永远在线业务的业务客户端发送来的登录请求后，通知AOI服务器保活业务客户端与业务平台之间的业务链路。
步骤8，AOI服务器在收到保活业务客户端与业务平台之间的业务链路的通知（即长连接保活请求）后，对业务平台的长连接保活请求进行鉴权，判断此登录业务是否有保活业务链路的能力。若鉴权通过，则执行步骤9。
步骤9，AOI服务器通知PCRF维持业务链路的长连接。其中，该业务链路为业务客户端与业务平台之间的业务链路。
步骤10，PCRF通知GGSN/防火墙保活业务客户端与业务平台之间的业务链路，从而在业务客户端与业务平台之间保活业务链路。
其中，在业务链路被保活长连接之后，业务客户端不再需要频繁发送心跳包来维持此业务链路，业务数据可以直接在业务链路上进行传输。
实施例四
本实施例为通过公共通知链路发送业务数据的处理流程。其中，业务客户端在完成永远在线业务的注册后，当业务平台需要Push数据到业务客户端时，如果AOI中间件和AOI服务器之间的公共通知链路已经建立，则业务平台可以通过公共通知链路推送业务数据给业务客户端，通过公共通知链路推送业务数据给业务客户端的流程如图4所示，该流程包括以下步骤：
步骤1，业务平台需要向业务客户端推送业务数据时，将需要推送的业务数据以及相应的用户ID发送到AOI服务器，由AOI服务器进行处理。
步骤2，AOI服务器通过收到的用户ID查看对应的AOI中间件与AOI服务器之间的公共通知链路是否已经建立。
步骤3，如果AOI中间件与AOI服务器之间的公共通知链路已经建立，则AOI服务器通过该公共通知链路Push业务数据给AOI中间件。
步骤4，AOI中间件通过公共通知链路接收来自AOI服务器的业务数据，通过业务ID找到并唤醒注册的业务客户端，将业务数据发送给业务客户端。
步骤5，业务客户端接收并解析业务数据，判断是否与业务平台建立数据传输连接，并在与业务平台建立数据传输连接时，和业务平台进行数据交互。
步骤6，业务客户端与业务平台进行数据交互，并在业务数据的交互完成后，业务客户端断开和业务平台的数据传输连接，结束此次数据传输。
实施例五
本实施例为通过短信网关发送业务数据的处理流程。其中，业务客户端在完成永远在线业务的注册后，当业务平台需要Push数据到业务客户端时，如果AOI中间件和AOI服务器之间的公共通知链路不存在（即没有建立），则业务平台可以通过短信网关（短消息网关）推送业务数据给AOI中间件，并由AOI中间件唤醒对应的业务客户端并进行业务数据交互，即业务平台通过短信网关推送业务数据给业务客户端，通过短信网关链路推送业务数据给业务客户端的流程如图5所示，该流程包括以下步骤：
步骤1，业务平台需要向业务客户端推送业务数据时，将需要推送的业务数据以及相应的用户ID发送到AOI服务器，由AOI服务器进行处理。
步骤2，AOI服务器通过收到的用户ID查看对应的AOI中间件与AOI服务器之间的公共通知链路是否已经建立。
步骤3，如果AOI中间件与AOI服务器之间的公共通知链路未建立，则AOI服务器查找此业务对应的手机号码，并向对应的短信网关Push短消息，该短消息中携带了业务平台需要发送给业务客户端的业务数据。
步骤4，短信网关在收到短消息后，向对应的AOI中间件Push短消息，该短消息中携带业务平台需要发送给业务客户端的业务数据。
步骤5，AOI中间件监听到AOI服务器通过短信网关下发的短消息后，解析该短消息以查找到对应的注册业务，唤醒对应的业务客户端，并将短消息传递给此业务客户端，该短消息中携带需要发送给业务客户端的业务数据。
步骤6，业务客户端接收并解析短消息中携带的业务数据，判断是否与业务平台建立数据传输连接，在建立数据传输连接时和业务平台进行数据交互。
步骤7，业务客户端与业务平台进行数据交互，并在业务数据的交互完成后，业务客户端断开和业务平台的数据传输连接，结束此次数据传输。
实施例六
本实施例为永远在线业务状态维护及纠错处理流程。其中，对于业务平台与业务客户端之间的业务链路，由于业务客户端和业务平台之间可以长时间不通信，导致业务客户端发生的一些异常情况，业务平台无法感知到，继而导致不良的用户体验，因此需要实现业务状态纠错处理机制，永远在线业务状态维护及纠错处理流程如图6所示，该流程包括以下步骤：
步骤1，使用永远在线能力的业务客户端注册到AOI中间件。
步骤2，AOI中间件与AOI服务器之间建立公共通知链路，且AOI中间件与AOI服务器通过异常检测机制监听链路的相关状态。
步骤3，业务客户端登录到业务平台。
步骤4，业务客户端与业务平台之间建立业务链路，并保活此业务链路，业务客户端不再发送心跳包维持业务客户端与业务平台之间的业务链路。
具体的，业务平台通过AOI服务器告知PCRF维持业务客户端与业务平台之间的业务链路的长连接，PCRF通知GGSN和防火墙/NAT保活此业务链路，且业务客户端和业务平台均不需要发送心跳包来维持此业务链路，但没有心跳包交互后，业务客户端的状态无法及时通知到业务平台。
步骤5，业务客户端登录业务平台后，需要业务客户端与AOI中间件建立一个定期状态反馈机制，以确保AOI中间件能够监听到业务客户端的状态。
步骤6，AOI中间件在监控业务客户端的应用状态时，如果AOI中间件没有接收到业务客户端的定期状态反馈，则认为业务客户端的应用状态为异常状态，为了释放网络资源，AOI中间件通过公共通知链路将业务客户端出现异常状态的信息通知给AOI服务器，以请求AOI服务器关闭此业务链路。
步骤7，AOI服务器通知PCRF关闭业务客户端与业务平台之间的业务链路的长连接，并通知业务平台，业务客户端的相关应用已经下线。
步骤8、PCRF通知GGSN及防火墙/NAT释放业务链路的保活。
实施例七
本实施例为业务客户端永远在线业务下线流程。其中，为了使业务客户端在下线时能够及时释放网络侧为业务链路保持的长连接，需要实现永远在线类业务客户端的下线机制，以减少网络的资源消耗，节省网络资源。业务客户端永远在线业务下线流程如图7所示，该流程包括以下步骤：
步骤1，使用永远在线能力的业务客户端注册到AOI中间件。
步骤2，AOI中间件与AOI服务器之间建立公共通知链路，且AOI中间件与AOI服务器通过异常检测机制监听链路的相关状态。
步骤3，业务客户端登录到业务平台。
步骤4，业务客户端与业务平台之间建立业务链路，并保活此业务链路，业务客户端不再发送心跳包维持业务客户端与业务平台之间的业务链路。
具体的，业务平台通过AOI服务器告知PCRF维持业务客户端与业务平台之间的业务链路的长连接，PCRF通知GGSN和防火墙/NAT保活此业务链路，且业务客户端和业务平台均不需要发送心跳包来维持此业务链路，但没有心跳包交互后，业务客户端的状态无法及时通知到业务平台。
步骤5，业务客户端需要注销下线时，向业务平台发起业务下线通知。
步骤6，业务平台接收到业务客户端的下线通知后，为了释放网络资源，业务平台通知AOI服务器去保活此业务链路的资源。
步骤7，AOI服务器接收来自业务平台的请求，通知PCRF关闭业务客户端与业务平台之间的业务链路的长连接，并释放相关网络资源。
步骤8，PCRF通知GGSN及防火墙/NAT释放业务链路的保活。
步骤9，业务客户端释放业务链路，完成业务下线。
实施例八
本实施例为业务客户端注销永远在线能力流程。其中，当业务客户端注销永远在线能力时，需要向AOI中间件发起取消永远在线能力请求，当AOI中间件检测到所有的永远在线应用取消了业务Push需求时，需要拆除公共通知链路，释放AOI中间件，AOI服务器，GGSN以及防火墙/NAT的资源。业务客户端注销永远在线能力流程如图8所示，该流程包括以下步骤：
步骤1，当有业务客户端使用永远在线能力时，在AOI中间件与AOI服务器之间建立公共通知链路，并通过该公共通知链路进行相关信息的传输。
步骤2，当业务客户端注销永远在线能力时，业务客户端向AOI中间件发起取消永远在线能力的请求，以业务客户端的注销永远在线能力。
步骤3，AOI中间件接收到取消永远在线能力的请求后，向AOI服务器发送该业务客户端的取消永远在线能力的请求。
步骤4，AOI服务器将取消永远在线能力的请求发送到业务平台，业务平台完成永远在线能力的注销，返回注销永远在线能力完成消息给AOI中间件。
步骤5，AOI中间件通知业务平台取消此业务客户端应用的Push通道的注册，并检测当前是否没有注册永远在线需求的应用；如果已经没有注册永远在线需求的应用，则通知AOI服务器拆除公共通知链路。
步骤6，AOI服务器接收到来自AOI中间件的拆除公共通知链路的请求后，向PCRF发送取消公共通知链路的保活，以通知PCRF关闭AOI服务器与AOI中间件之间的公共通知链路的长连接。
步骤7，PCRF通知GGSN及防火墙/NAT去保活AOI服务器与AOI中间件之间的公共通知链路，并释放网络资源。
步骤8，AOI服务器通知AOI中间件拆除公共通知链路，AOI中间件断开和AOI服务器的TCP（Transmission Control Protocol，传输控制协议）连接。
步骤9，AOI中间件和AOI服务器释放资源，以最终拆除公共通知链路。
基于本发明的上述各实施例，通过在AOI中间件和AOI服务器之间建立公共通知链路，并取消心跳的永远在线方法，从而解决现有业务心跳包策略导致移动网络资源滥用的问题，为移动应用提供一整套端到端的永远在线解决方案，将各种Push类业务的需求收敛到一个公用通道，大大减少防火墙和NAT的保持路数，降低网络资源消耗。进一步的，通过网络侧和应用侧相结合的永远在线解决方案，通过在应用侧将所有业务的Push通道及小数据量消息传输通道进行了归并，减少了终端和网络之间的数据链接，同时可以将小数据包进行合并传输，减少了网络中小包的传输。通过网络侧对需要长期保持的链路进行保活，取消或者延长了心跳消息报文的间隔时长，可以大量减少网络中传输的心跳消息。收敛应用的长连接可以减少网络侧需要保活的连接数量，减少核心网中GGSN，防火墙/NAT资源消耗。此外，在网络层通过对核心网策略控制设备的改造，通过PCRF通知GGSN和防火墙/NAT维持业务应用的普通业务数据链路长连接状态的方式，替代当前业务客户端和平台通过心跳包模式进行链路维持的方法，避免了由于频繁心跳包数据的发送所导致移动网络资源被滥用的情况，此外，终端中间件对IM类应用进行统一的业务状态管理，并将客户端应用运行状态的改变通过公共通知链路告知AOI服务器并转交到业务平台，避免由于普通业务链路中由于心跳包的缺失，导致无法及时获取终端业务客户端状态和无法及时释放网络资源的问题。
进一步的，假设在终端设备上有N个永远在线业务，这些永远在线业务具有以下特性：心跳消息平均为每2分钟发送一次；有20%的业务需要维持业务长连接，业务长连接的心跳消息也为2分钟。假设应用本发明实施例的技术方案时，将所有的心跳进行收敛并保持10分钟的一次状态更新消息，在这些业务后台运行状态下（不进行业务实际业务数据交互）。则：如果不采用本发明实施例的技术方案，在假设的T分钟时长内将产生（N+20%N）*（T/2）个心跳消息。在采用本发明实施例的技术方案后，由于将所有的永远在线链路收敛到一条，在假设的T分钟时长内将产生（T/10）个心跳消息，而业务链路由PCRF保活，不再需要心跳保活。因此，可以得出对网络资源降低的比例为公式为：((N+20%N)T/2–T/10)/((N+20%N)*T/2)=1-1/（6*N）。
通过推论可以看出，采用本发明实施例的技术方案时，在只有一个业务需要心跳的情况下，也能大幅降低业务心跳对于空口和网络资源的影响，分析其原因是由于通过GGSN和防火墙/NAT对长连接进行保活，可以大大降低心跳的时长，减少了心跳占用空口和网络资源。同时在不采用本发明实施例的技术方案时，网络GGSN和防火墙/NAT资源需要消耗N+20%N的状态维护，而采用本发明实施例的技术方案后网络只需要维护1+20%N。
因此，可以得出对网络资源降低的比例公式为：（（N+20%N）-（1+20%N））/（N+20%N）=(N-1)/1.2N=1-5/（6*N）。
实施例九
基于与上述方法同样的发明构思，本发明实施例中还提供了一种永远在线业务的实现系统，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，其中：所述AOI中间件，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；并当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；
所述AOI服务器，用于通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息，将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
所述AOI中间件，还用于在收到来自所述业务客户端的注册请求后，判断所述AOI中间件与所述AOI服务器之间的公共通知链路是否已经建立；如果未建立，则向所述AOI服务器发送用于建立公共通知链路的请求；
所述AOI服务器，还用于接收来自所述AOI中间件的用于建立公共通知链路的请求，并在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
实施例十
基于与上述方法同样的发明构思，本发明实施例中还提供了一种终端设备上部署的永远在线基础实施AOI中间件，所述AOI中间件与AOI服务器之间建立有公共通知链路，且所述AOI服务器部署在移动核心网，如图9所示，所述AOI中间件具体包括：
处理模块11，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；
通信模块12，用于当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；由所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
所述处理模块11，还用于在收到来自所述业务客户端的注册请求后，判断所述AOI中间件与所述AOI服务器之间的公共通知链路是否已经建立；
所述通信模块12，还用于当所述AOI中间件与所述AOI服务器之间的公共通知链路未建立时，向所述AOI服务器发送用于建立公共通知链路的请求；由所述AOI服务器在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
所述通信模块12，还用于通过所述公共通知链路接收来自所述AOI服务器的业务数据，并唤醒所述业务数据对应的业务客户端，将所述业务数据转发给所述业务客户端；和/或，接收来自所述业务客户端的业务数据，并通过所述公共通知链路将所述业务数据转发给所述AOI服务器，并由所述AOI服务器将所述业务数据转发给所述业务客户端对应的业务平台。
所述通信模块12，还用于接收来自短信网关的短消息，所述短消息为所述AOI服务器发送给短信网关的，且短消息中携带需要发送给业务客户端的业务数据；以及，唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
所述通信模块12，还用于当所述终端设备上所有的业务客户端均注销永远在线能力时，向所述AOI服务器发送用于拆除公共通知链路的请求；由所述AOI服务器在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与所述AOI服务器之间的公共通知链路。
其中，本发明装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。
实施例十一
基于与上述方法同样的发明构思，本发明实施例中还提供了一种移动核心网侧部署的永远在线基础实施AOI服务器，AOI中间件与所述AOI服务器之间建立有公共通知链路，且所述AOI中间件部署在终端设备上，如图10所示，所述AOI服务器具体包括：
接收模块21，用于在终端设备的业务客户端与业务平台之间保活了业务链路之后，如果所述AOI中间件监控到业务客户端的异常状态，则通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息；
发送模块22，用于将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
所述接收模块21，还用于在所述AOI中间件与AOI服务器之间的公共通知链路未建立时，接收来自所述AOI中间件的用于建立公共通知链路的请求；
所述发送模块22，还用于在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
所述接收模块21，还用于接收来自业务平台的业务数据；
所述发送模块22，还用于当AOI中间件与AOI服务器之间的公共通知链路建立时，通过所述公共通知链路将所述业务数据转发给AOI中间件，由AOI中间件唤醒业务数据对应的业务客户端，将所述业务数据转发给业务客户端；
和/或，
所述接收模块21，还用于通过所述公共通知链路接收来自所述AOI中间件的业务数据；
所述发送模块22，还用于将业务数据转发给业务客户端对应的业务平台。
所述接收模块21，还用于接收来自业务平台的业务数据；
所述发送模块22，还用于当AOI中间件与AOI服务器之间的公共通知链路未建立时，向短信网关发送携带业务数据的短消息，由短信网关将携带所述业务数据的短消息发送给AOI中间件，由AOI中间件唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
所述发送模块22，还用于在收到来自业务平台的保活业务客户端与业务平台之间的业务链路的通知后，通知PCRF维持所述业务客户端与业务平台之间的业务链路的长连接，由PCRF通知GGSN/防火墙保活所述业务客户端与业务平台之间的业务链路，以在业务客户端与业务平台之间保活业务链路。
所述接收模块21，还用于在所述业务客户端与业务平台之间保活了业务链路之后，当所述业务客户端注销下线时，接收来自所述业务平台的关闭所述业务客户端与业务平台之间的业务链路的通知；
所述发送模块22，还用于通知所述PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知所述GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
所述接收模块21，还用于当所述终端设备上所有的业务客户端均注销永远在线能力时，接收来自所述AOI中间件的用于拆除公共通知链路的请求；
所述发送模块22，还用于在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，由PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与AOI服务器之间的公共通知链路。
其中，本发明装置的各个模块可以集成于一体，也可以分离部署。上述模块可以合并为一个模块，也可以进一步拆分成多个子模块。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (26)
1.一种永远在线业务的实现方法，其特征在于，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，该方法包括以下步骤：
在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，所述AOI中间件监控所述业务客户端的应用状态；
当监控到所述业务客户端的应用状态为异常状态时，所述AOI中间件通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；由所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
2.如权利要求1所述的方法，其特征在于，所述AOI中间件与所述AOI服务器之间建立公共通知链路的过程，具体包括：
所述AOI中间件在收到来自所述业务客户端的注册请求后，判断所述AOI中间件与所述AOI服务器之间的公共通知链路是否已经建立；如果未建立，则所述AOI中间件向所述AOI服务器发送用于建立公共通知链路的请求；由所述AOI服务器在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
3.如权利要求1或2所述的方法，其特征在于，所述方法还包括：
所述AOI中间件通过所述公共通知链路接收来自所述AOI服务器的业务数据，并唤醒所述业务数据对应的业务客户端，将所述业务数据转发给所述业务客户端；和/或，所述AOI中间件接收来自所述业务客户端的业务数据，并通过所述公共通知链路将所述业务数据转发给所述AOI服务器，并由所述AOI服务器将所述业务数据转发给所述业务客户端对应的业务平台。
4.如权利要求1或2所述的方法，其特征在于，所述方法还包括：
所述AOI中间件接收来自短信网关的短消息，所述短消息为所述AOI服务器发送给短信网关的，且短消息中携带需要发送给业务客户端的业务数据；
所述AOI中间件唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
5.如权利要求1或2所述的方法，其特征在于，所述方法还包括：
当所述终端设备上所有的业务客户端均注销永远在线能力时，所述AOI中间件向所述AOI服务器发送用于拆除公共通知链路的请求；由所述AOI服务器在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与所述AOI服务器之间的公共通知链路。
6.一种永远在线业务的实现方法，其特征在于，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，该方法包括以下步骤：
在终端设备的业务客户端与业务平台之间保活了业务链路之后，如果所述AOI中间件监控到业务客户端的异常状态，则所述AOI服务器通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息；
所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
7.如权利要求6所述的方法，其特征在于，所述AOI中间件与所述AOI服务器之间建立公共通知链路的过程，具体包括：
在所述AOI中间件与所述AOI服务器之间的公共通知链路未建立时，所述AOI服务器接收来自所述AOI中间件的用于建立公共通知链路的请求；
所述AOI服务器在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
8.如权利要求6或7所述的方法，其特征在于，所述方法还包括：
所述AOI服务器接收来自业务平台的业务数据，并当所述AOI中间件与所述AOI服务器之间的公共通知链路建立时，所述AOI服务器通过所述公共通知链路将所述业务数据转发给所述AOI中间件，由所述AOI中间件唤醒所述业务数据对应的业务客户端，将所述业务数据转发给所述业务客户端；和/或，所述AOI服务器通过所述公共通知链路接收来自所述AOI中间件的业务数据，并将所述业务数据转发给所述业务客户端对应的业务平台。
9.如权利要求6或7所述的方法，其特征在于，所述方法还包括：
所述AOI服务器接收来自业务平台的业务数据，并当所述AOI中间件与所述AOI服务器之间的公共通知链路未建立时，所述AOI服务器向短信网关发送携带所述业务数据的短消息，由所述短信网关将携带所述业务数据的短消息发送给所述AOI中间件，并由所述AOI中间件唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
10.如权利要求6所述的方法，其特征在于，所述方法还包括：
所述AOI服务器在收到来自业务平台的保活业务客户端与业务平台之间的业务链路的通知后，通知PCRF维持所述业务客户端与业务平台之间的业务链路的长连接，由所述PCRF通知GGSN/防火墙保活所述业务客户端与业务平台之间的业务链路，以在所述业务客户端与业务平台之间保活业务链路。
11.如权利要求6或10所述的方法，其特征在于，所述方法还包括：
在所述业务客户端与业务平台之间保活了业务链路之后，当所述业务客户端注销下线时，所述AOI服务器接收来自所述业务平台的关闭所述业务客户端与业务平台之间的业务链路的通知，并通知所述PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知所述GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
12.如权利要求6或7所述的方法，其特征在于，所述方法还包括：
当所述终端设备上所有的业务客户端均注销永远在线能力时，所述AOI服务器接收来自所述AOI中间件的用于拆除公共通知链路的请求；
所述AOI服务器在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，由所述PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与所述AOI服务器之间的公共通知链路。
13.一种永远在线业务的实现系统，其特征在于，终端设备上部署有永远在线基础实施AOI中间件，移动核心网部署有AOI服务器，所述AOI中间件与所述AOI服务器之间建立有公共通知链路，其中：
所述AOI中间件，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；并当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；
所述AOI服务器，用于通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息，将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
14.如权利要求13所述的系统，其特征在于，
所述AOI中间件，还用于在收到来自所述业务客户端的注册请求后，判断所述AOI中间件与所述AOI服务器之间的公共通知链路是否已经建立；如果未建立，则向所述AOI服务器发送用于建立公共通知链路的请求；
所述AOI服务器，还用于接收来自所述AOI中间件的用于建立公共通知链路的请求，并在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
15.一种终端设备上部署的永远在线基础实施AOI中间件，其特征在于，所述AOI中间件与AOI服务器之间建立有公共通知链路，且所述AOI服务器部署在移动核心网，所述AOI中间件具体包括：
处理模块，用于在所述终端设备的业务客户端与业务平台之间保活了业务链路之后，监控所述业务客户端的应用状态；
通信模块，用于当监控到所述业务客户端的应用状态为异常状态时，通过所述公共通知链路将所述业务客户端出现异常状态的信息通知给所述AOI服务器；由所述AOI服务器将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
16.如权利要求15所述的AOI中间件，其特征在于，
所述处理模块，还用于在收到来自所述业务客户端的注册请求后，判断所述AOI中间件与所述AOI服务器之间的公共通知链路是否已经建立；
所述通信模块，还用于当所述AOI中间件与所述AOI服务器之间的公共通知链路未建立时，向所述AOI服务器发送用于建立公共通知链路的请求；由所述AOI服务器在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
17.如权利要求15或16所述的AOI中间件，其特征在于，
所述通信模块，还用于通过所述公共通知链路接收来自所述AOI服务器的业务数据，并唤醒所述业务数据对应的业务客户端，将所述业务数据转发给所述业务客户端；和/或，接收来自所述业务客户端的业务数据，并通过所述公共通知链路将所述业务数据转发给所述AOI服务器，并由所述AOI服务器将所述业务数据转发给所述业务客户端对应的业务平台。
18.如权利要求15或16所述的AOI中间件，其特征在于，
所述通信模块，还用于接收来自短信网关的短消息，所述短消息为所述AOI服务器发送给短信网关的，且短消息中携带需要发送给业务客户端的业务数据；以及，唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
19.如权利要求15或16所述的AOI中间件，其特征在于，
所述通信模块，还用于当所述终端设备上所有的业务客户端均注销永远在线能力时，向所述AOI服务器发送用于拆除公共通知链路的请求；由所述AOI服务器在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与所述AOI服务器之间的公共通知链路。
20.一种移动核心网侧部署的永远在线基础实施AOI服务器，其特征在于，AOI中间件与所述AOI服务器之间建立有公共通知链路，且所述AOI中间件部署在终端设备上，所述AOI服务器具体包括：
接收模块，用于在终端设备的业务客户端与业务平台之间保活了业务链路之后，如果所述AOI中间件监控到业务客户端的异常状态，则通过所述公共通知链路接收来自所述AOI中间件的业务客户端出现异常状态的信息；
发送模块，用于将所述业务客户端出现异常状态的信息通知给所述业务平台，并通知策略与计费规则功能PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知网关GPRS支持节点GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
21.如权利要求20所述的AOI服务器，其特征在于，
所述接收模块，还用于在所述AOI中间件与AOI服务器之间的公共通知链路未建立时，接收来自所述AOI中间件的用于建立公共通知链路的请求；
所述发送模块，还用于在收到用于建立公共通知链路的请求后，通知PCRF维持所述AOI中间件与AOI服务器之间的公共通知链路的长连接，并由所述PCRF通知GGSN/防火墙保活所述AOI中间件与AOI服务器之间的公共通知链路，以建立所述AOI中间件与所述AOI服务器之间的公共通知链路。
22.如权利要求20或21所述的AOI服务器，其特征在于，
所述接收模块，还用于接收来自业务平台的业务数据；
所述发送模块，还用于当AOI中间件与AOI服务器之间的公共通知链路建立时，通过所述公共通知链路将所述业务数据转发给AOI中间件，由AOI中间件唤醒业务数据对应的业务客户端，将所述业务数据转发给业务客户端；
和/或，
所述接收模块，还用于通过所述公共通知链路接收来自所述AOI中间件的业务数据；
所述发送模块，还用于将该业务数据转发给业务客户端对应的业务平台。
23.如权利要求20或21所述的AOI服务器，其特征在于，
所述接收模块，还用于接收来自业务平台的业务数据；
所述发送模块，还用于当AOI中间件与AOI服务器之间的公共通知链路未建立时，向短信网关发送携带业务数据的短消息，由短信网关将携带所述业务数据的短消息发送给AOI中间件，由AOI中间件唤醒所述业务数据对应的业务客户端，并将携带所述业务数据的短消息转发给所述业务客户端。
24.如权利要求20所述的AOI服务器，其特征在于，
所述发送模块，还用于在收到来自业务平台的保活业务客户端与业务平台之间的业务链路的通知后，通知PCRF维持所述业务客户端与业务平台之间的业务链路的长连接，由PCRF通知GGSN/防火墙保活所述业务客户端与业务平台之间的业务链路，以在业务客户端与业务平台之间保活业务链路。
25.如权利要求20或21所述的AOI服务器，其特征在于，
所述接收模块，还用于在所述业务客户端与业务平台之间保活了业务链路之后，当所述业务客户端注销下线时，接收来自所述业务平台的关闭所述业务客户端与业务平台之间的业务链路的通知；
所述发送模块，还用于通知所述PCRF关闭所述业务客户端与业务平台之间的业务链路的长连接，并由所述PCRF通知所述GGSN/防火墙去保活所述业务客户端与业务平台之间的业务链路。
26.如权利要求20或21所述的AOI服务器，其特征在于，
所述接收模块，还用于当所述终端设备上所有的业务客户端均注销永远在线能力时，接收来自所述AOI中间件的用于拆除公共通知链路的请求；
所述发送模块，还用于在收到用于拆除公共通知链路的请求后，通知PCRF关闭所述AOI中间件与所述AOI服务器之间的公共通知链路的长连接，由PCRF通知GGSN/防火墙去保活所述AOI中间件与所述AOI服务器之间的公共通知链路，以拆除所述AOI中间件与AOI服务器之间的公共通知链路。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310269578.2A CN104253739B (zh) | 2013-06-28 | 2013-06-28 | 一种永远在线业务的实现方法、系统和设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310269578.2A CN104253739B (zh) | 2013-06-28 | 2013-06-28 | 一种永远在线业务的实现方法、系统和设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104253739A true CN104253739A (zh) | 2014-12-31 |
| CN104253739B CN104253739B (zh) | 2018-08-10 |
Family
ID=52188298
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310269578.2A Active CN104253739B (zh) | 2013-06-28 | 2013-06-28 | 一种永远在线业务的实现方法、系统和设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104253739B (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107783844A (zh) * | 2017-10-13 | 2018-03-09 | 锐捷网络股份有限公司 | 一种计算机程序运行异常检测方法、装置和介质 |
| CN108055346A (zh) * | 2017-12-26 | 2018-05-18 | 广东睿江云计算股份有限公司 | 一种优化邮件终端链接的方法 |
| CN109115780A (zh) * | 2017-06-23 | 2019-01-01 | 大陆泰密克汽车系统（上海）有限公司 | 用于监控多个自动光学检测设备的方法及其装置 |
| CN109639795A (zh) * | 2018-12-11 | 2019-04-16 | 广东亿迅科技有限公司 | 一种基于AcitveMQ消息队列的服务管理方法与装置 |
| CN109711152A (zh) * | 2018-12-25 | 2019-05-03 | 北京潘达互娱科技有限公司 | 一种应用保活方法、计算设备及存储介质 |
| CN110381130A (zh) * | 2019-07-12 | 2019-10-25 | 湖南新云网科技有限公司 | 保活长连接方法、装置、通信终端及存储介质 |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070140449A1 (en) * | 2004-09-13 | 2007-06-21 | Andrew Whitfield | "Always-on" telemetry system and method |
| US20110134784A1 (en) * | 2002-08-01 | 2011-06-09 | Research In Motion Limited | Always-on wireless internet protocol communication |
| CN102469124A (zh) * | 2010-11-09 | 2012-05-23 | 中兴通讯股份有限公司 | 基于aog的移动互联网业务的实现方法、网关、代理及系统 |
| CN102752722A (zh) * | 2011-04-19 | 2012-10-24 | 中国移动通信集团公司 | 一种永远在线能力的提供方法、系统和设备 |
| CN102761574A (zh) * | 2011-04-28 | 2012-10-31 | 中兴通讯股份有限公司 | 一种通过永远在线平台实现点对点业务的方法及系统 |
| CN102769603A (zh) * | 2011-05-03 | 2012-11-07 | 中国移动通信集团公司 | 一种数据传输的方法、系统及设备 |
| CN102891877A (zh) * | 2011-07-22 | 2013-01-23 | 中兴通讯股份有限公司 | 实现终端应用的在线处理系统及方法 |
| CN103139818A (zh) * | 2011-12-02 | 2013-06-05 | 中兴通讯股份有限公司 | 一种aos中保持长连接的方法、系统、aoe、aog及终端 |
| CN103152374A (zh) * | 2011-12-07 | 2013-06-12 | 华为终端有限公司 | 获知终端在线状态的方法与装置 |
-
2013
- 2013-06-28 CN CN201310269578.2A patent/CN104253739B/zh active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110134784A1 (en) * | 2002-08-01 | 2011-06-09 | Research In Motion Limited | Always-on wireless internet protocol communication |
| US20070140449A1 (en) * | 2004-09-13 | 2007-06-21 | Andrew Whitfield | "Always-on" telemetry system and method |
| CN102469124A (zh) * | 2010-11-09 | 2012-05-23 | 中兴通讯股份有限公司 | 基于aog的移动互联网业务的实现方法、网关、代理及系统 |
| CN102752722A (zh) * | 2011-04-19 | 2012-10-24 | 中国移动通信集团公司 | 一种永远在线能力的提供方法、系统和设备 |
| CN102761574A (zh) * | 2011-04-28 | 2012-10-31 | 中兴通讯股份有限公司 | 一种通过永远在线平台实现点对点业务的方法及系统 |
| CN102769603A (zh) * | 2011-05-03 | 2012-11-07 | 中国移动通信集团公司 | 一种数据传输的方法、系统及设备 |
| CN102891877A (zh) * | 2011-07-22 | 2013-01-23 | 中兴通讯股份有限公司 | 实现终端应用的在线处理系统及方法 |
| CN103139818A (zh) * | 2011-12-02 | 2013-06-05 | 中兴通讯股份有限公司 | 一种aos中保持长连接的方法、系统、aoe、aog及终端 |
| CN103152374A (zh) * | 2011-12-07 | 2013-06-12 | 华为终端有限公司 | 获知终端在线状态的方法与装置 |
Non-Patent Citations (1)
| Title |
|---|
| 刘志军等: "《基于IP+PUSH实现移动互联网应用的永远在线》", 《现代电信科技》 * |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109115780A (zh) * | 2017-06-23 | 2019-01-01 | 大陆泰密克汽车系统（上海）有限公司 | 用于监控多个自动光学检测设备的方法及其装置 |
| CN107783844A (zh) * | 2017-10-13 | 2018-03-09 | 锐捷网络股份有限公司 | 一种计算机程序运行异常检测方法、装置和介质 |
| CN108055346A (zh) * | 2017-12-26 | 2018-05-18 | 广东睿江云计算股份有限公司 | 一种优化邮件终端链接的方法 |
| CN108055346B (zh) * | 2017-12-26 | 2020-12-22 | 广东睿江云计算股份有限公司 | 一种优化邮件终端链接的方法 |
| CN109639795A (zh) * | 2018-12-11 | 2019-04-16 | 广东亿迅科技有限公司 | 一种基于AcitveMQ消息队列的服务管理方法与装置 |
| CN109639795B (zh) * | 2018-12-11 | 2021-12-24 | 广东亿迅科技有限公司 | 一种基于AcitveMQ消息队列的服务管理方法与装置 |
| CN109711152A (zh) * | 2018-12-25 | 2019-05-03 | 北京潘达互娱科技有限公司 | 一种应用保活方法、计算设备及存储介质 |
| CN110381130A (zh) * | 2019-07-12 | 2019-10-25 | 湖南新云网科技有限公司 | 保活长连接方法、装置、通信终端及存储介质 |
| CN110381130B (zh) * | 2019-07-12 | 2020-05-29 | 湖南新云网科技有限公司 | 保活长连接方法、装置、通信终端及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104253739B (zh) | 2018-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104253739A (zh) | 一种永远在线业务的实现方法、系统和设备 | |
| CN103188653B (zh) | 接收数据的方法、发送数据的方法、移动终端和服务器 | |
| CN103297470B (zh) | 永远在线业务的处理方法、应用服务器、用户终端和系统 | |
| CN101094187B (zh) | 一种学习介质访问控制地址的方法和装置、业务板 | |
| CN103404102B (zh) | 一种承载创建方法、装置和系统 | |
| US11233694B2 (en) | Method and device for processing communication path | |
| CN103312528B (zh) | 一种心跳消息发送方法及用户终端 | |
| CN109831548B (zh) | 虚拟内容分发网络vCDN节点建立方法及服务器 | |
| CN105049495B (zh) | 设备发现方法、装置及系统 | |
| CN103916275A (zh) | 一种bfd检测装置和方法 | |
| CN104144124B (zh) | 数据转发方法、装置及系统 | |
| CN102624566A (zh) | 唤醒呼叫类终端的方法、装置及系统 | |
| CN102984784A (zh) | 通过多个网络发送数据 | |
| CN112203261A (zh) | 充电桩的管理方法、管理装置、电子设备及可读存储介质 | |
| CN112437153A (zh) | 一种设备联动处理方法及装置 | |
| CN103069751A (zh) | 网络信息处理系统、网络信息处理设备和信息处理方法 | |
| CN104618491B (zh) | 一种代理服务器及数据转发方法 | |
| CN101695049A (zh) | 一种监控系统中的业务处理方法及装置 | |
| CN105791023B (zh) | 光网络单元onu管理的方法、装置以及系统 | |
| CN102316086A (zh) | 业务数据的中继方法及中继节点系统 | |
| US20190036793A1 (en) | Network service implementation method, service controller, and communications system | |
| CN104219783B (zh) | 一种会话重定向方法和设备 | |
| CN105376174A (zh) | 执行lte/epc中基于服务链的策略的方法与设备 | |
| CN105577433B (zh) | 一种acs集群管理方法、装置和系统 | |
| KR20190113200A (ko) | 메시지 서버 및 이를 포함하는 메시지 처리 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |