CN103297470A - 永远在线业务的处理方法、应用服务器、用户终端和系统 - Google Patents

Abstract

本发明公开了一种永远在线业务的处理方法、应用服务器、用户终端和系统，包括：应用服务器接收用户终端发送的永远在线业务注册请求，该永远在线业务注册请求中携带该用户终端的终端标识；并基于该终端标识，向核心网设备发送第一链路保活指示消息，用于指示核心网设备维持该应用服务器与该终端标识对应的该用户终端之间建立的公用链路的长连接状态，其中，该公用链路用于各业务服务器通过该应用服务器向该用户终端上对应的业务客户端推送业务数据。采用本发明实施例提供的方案，减少了向用户终端推送业务数据时网络资源的消耗。

Description

永远在线业务的处理方法、应用服务器、用户终端和系统

技术领域

本发明涉及通信技术领域，尤其涉及一种永远在线业务的处理方法、应用服务器、用户终端和系统。

背景技术

随着移动互联网的大力发展，各种有着良好用户体验的移动应用业务也得到了广泛的发展，其中，消息推送push类业务为比较突出的一种应用业务，例如，可以进行邮件即时推送的手机邮箱业务。

如图1所示，现有技术中，通过push类业务向用户推送业务数据的方式如下：

当业务服务器确定需要向用户终端上安装的业务客户端推送数据时，首先通过短信网关向用户终端发送数据接收通知短信，用户终端的使用者在查看到该数据接收通知短信后，通过移动网络连接业务服务器，并从业务服务器获取业务数据，以及回复业务数据。

以手机邮箱中的邮件推送服务为例，电子邮件到达客户邮件服务器后，可以由邮件推送平台通过短信网关发送邮件到达通知短信给用户终端，用户终端中的手机邮箱客户端监听到此条邮件到达通知短信后，通过移动网络连接邮件代理网关，通过邮件代理网关随时随地的接收、回复、转发和撰写电子邮件。

在上述push类业务中，通常都采用发送push短信到用户终端，唤醒用户终端上的业务客户端，再去连接对应的业务服务器，进行相关业务数据下载，从而实现业务数据的push业务。由于采用此种短信唤醒进行数据下载的方式，所有的push通知消息只能通过短信网关进行下发，但短信发送的延迟容易导致消息无法即时通知到客户端；并且，在push短信中也无法直接携带相关业务数据，push短信只是起到通知的作用，每次push短信都需要唤醒业务客户端去下载相关业务数据，导致一次业务数据获取流程较长；并且，采用push短信通知下载业务数据的方式，频繁的信息交互容易导致短信网关负载较大，且每次数据下载均需要用户终端与网络进行一次网络连接，使得对网络资源消耗较大。

发明内容

本发明实施例提供一种永远在线业务的处理方法、应用服务器、用户终端和系统，用以解决现有技术中存在的向用户终端推送业务数据时网络资源消耗较大的问题。

本发明实施例提供一种永远在线业务的处理方法，包括：

应用服务器接收用户终端发送的永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

基于所述终端标识，向核心网设备发送第一链路保活指示消息，用于指示所述核心网设备维持所述应用服务器与所述终端标识对应的所述用户终端之间建立的公用链路的长连接状态，其中，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

本发明实施例还提供一种永远在线业务的处理方法，包括：

用户终端上的中间件生成永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

向所述应用服务器发送永远在线业务注册请求，用于请求维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

本发明实施例还提供一种应用服务器，包括：

第一交互单元，用于接收用户终端发送的永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

第二交互单元，用于基于所述终端标识，向核心网设备发送第一链路保活指示消息，用于指示所述核心网设备维持所述应用服务器与所述终端标识对应的所述用户终端之间建立的公用链路的长连接状态，其中，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

本发明实施例还提供一种用户终端，包括：中间件和业务客户端，其中：

所述中间件，用于生成永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；并向所述应用服务器发送永远在线业务注册请求，用于请求维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

本发明实施例还提供一种永远在线业务的处理系统，包括：

上述应用服务器和上述核心网设备。

本发明有益效果包括：

本发明实施例提供的方法中，应用服务器基于接收的用户终端发送的永远在线业务注册请求，并基于该请求中携带的终端标识，向核心网设备发送第一链路保活指示消息，用于指示核心网设备维持该应用服务器与该用户终端之间建立的公用链路的长连接状态，且该公用链路用于各业务服务器通过该应用服务器向该用户终端上对应的业务客户端推送业务数据。由于针对用户终端上的各业务客户端，均可以通过用户终端与该应用服务器之间建立的处于长连接状态的公用链路，接收对应的业务服务器推送的业务数据，所以，当用户终端上存在多个业务客户端时，相比现有技术，减少了用户终端与各业务服务器之间建立的链路的数量，即减少了网络链路资源的消耗；并且，由于该公用链路持续处于长连接状态，可以避免每次交互业务数据时均进行一次网络连接，即减少了网络连接过程中对网络资源的消耗；并且，可以直接向用户终端上的业务客户端推送业务数据，不需要先通过短信网关发送通知短信，即减少了对短信网关的负载，节省了短信网关短信发送资源的消耗，并且提高了业务数据推送的效率。

附图说明

图1为现有技术中通过push类业务向用户推送业务数据的示意图；

图2为本发明实施例中提供的永远在线业务的处理方法的流程图；

图3为本发明实施例1中提供的注册永远在线业务的处理流程图之一；

图4为本发明实施例1中提供的注册永远在线业务的处理流程图之二；

图5为本发明实施例2中提供的通过公用链路向用户终端上的业务客户端推送业务数据的处理流程图；

图6为现有技术中IM类业务维持业务客户端处于长在线状态的示意图；

图7为本发明实施例3中提供的永远在线业务处理方法的流程图；

图8为本发明实施例4中提供的业务客户端注销下线后关闭业务链路的处理流程图；

图9为本发明实施例5中提供的业务客户端异常后关闭业务链路的处理流程图；

图10为本发明实施例6中提供的应用服务器的结构示意图；

图11为本发明实施例7中提供的用户终端的结构示意图；

图12为本发明实施例8中提供的永远在线业务处理系统的结构示意图。

具体实施方式

为了给出减少向用户终端推送业务数据时网络资源的消耗的实现方案，本发明实施例提供了一种永远在线业务的处理方法、应用服务器、用户终端和系统，以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本发明实施例提供一种永远在线业务的处理方法，如图2所示，包括：

步骤201、应用服务器接收用户终端发送的永远在线业务注册请求，该永远在线业务注册请求中携带该用户终端的终端标识。

步骤202、基于该终端标识，向核心网设备发送第一链路保活指示消息，用于指示核心网设备维持该应用服务器与该终端标识对应的该用户终端之间建立的公用链路的长连接状态，其中，该公用链路用于各业务服务器通过该应用服务器向该用户终端上对应的业务客户端推送业务数据。

在维持该应用服务器与该用户终端之间建立的公用链路的长连接状态后，可以随时使用该公用链路向用户终端上的业务客户端推送业务数据，相当于该用户终端上的业务客户端是永远处于在线状态，即为该用户终端上的业务客户端提供了永远在线能力。该永远在线业务也可以称作永远在线机制(AlwaysOnline Infrastructure，AOI)，相应的，该应用服务器，可以称作AOI应用服务器。

较佳的，还可以包括：

当该用户终端上的业务客户端登录对应的业务服务器后，应用服务器接收该业务服务器发送的链路保活请求；

向核心网设备发送第二链路保活指示消息，用于指示核心网设备维持该业务服务器与该用户终端之间建立的业务链路的长连接状态。从而避免该业务服务器与该用户终端之间通过交互心跳数据包维持业务链路的长连接状态，进而减少了交互心跳数据包引起的网络资源的消耗。

上述步骤202中，向核心网设备发送第一链路保活指示消息，基于现有技术中的PCC(Policy and Charging Control，策略和计费控制)架构，具体可以为：向PCRF(Policy and Charging Rules Function，策略与计费规则功能)发送第一链路保活指示消息，并由PCRF向GGSN(Gateway GPRS Support Node，网关GPRS支持节点)发送链路保活策略消息，所述链路保活策略消息中携带用于指示GGSN维持该应用服务器与该用户终端之间建立的公用链路的长连接状态的策略信息。

较佳的，本发明实施例中，在用户终端上，可以通过设置中间件实现上述永远在线业务的处理方法，并通过中间件接收应用服务器转发的来自业务服务器的业务数据，并将接收的业务数据转发给对应的业务客户端；以及还可以通过与业务客户端之间信息交互，监测业务客户端的工作状态，并在监测到业务客户端的工作状态异常时，向应用服务器发送链路关闭请求，请求关闭对应业务服务器与该用户终端之间建立的业务链路，释放网络资源。

下面结合附图，用具体实施例对本发明提供的方法进行详细描述。

实施例1：

本发明实施例1中，对用户终端向AOI应用服务器注册永远在线业务的处理流程进行详细描述，如图3所示，具体包括如下处理步骤：

步骤301、用户终端上的业务客户端向该用户终端上的中间件发送业务注册消息，该业务注册消息中携带该业务客户端对应业务的业务标识。

进一步的，该业务注册消息中，还可以携带用户使用该业务客户端对应业务时注册的用户信息，例如用户名，可用于由AOI应用服务器确定应该将来自业务服务器的业务数据转发给哪个用户终端，详见后续描述。

本步骤具体可以是在用户终端上安装了业务客户端后，如果该业务客户端已被授权享有永远在线业务，则可以自动触发向中间件发送业务注册消息，也可以在提示用户并受到用户的确认操作后，向中间件发送业务注册消息。

步骤302、用户终端的该中间件接收到该业务客户端发送的业务注册消息后，检测该用户终端与处理永远在线业务的AOI应用服务器之间是否已建立了处于长连接状态的公用链路。

步骤303、如果已建立该公用链路，可以取消后续向AOI应用服务器发送永远在线业务注册请求；如果该业务注册消息中携带用户使用该业务客户端对应业务时注册的用户信息，还可以向AOI应用服务器发送业务信息通知消息，其中携带该用户终端的终端标识，该业务客户端对应业务的业务标识，以及该用户信息。

如果未建立该公用链路，向AOI应用服务器发送永远在线业务注册请求，该永远在线业务注册请求中携带该用户终端的终端标识；

进一步的，该永远在线业务注册请求中，还可以携带该业务客户端对应业务的业务标识，用于AOI应用服务器对该业务标识对应的业务是否享有该永远在线业务的权利进行鉴权处理。

步骤304、AOI应用服务器在接收到业务信息通知消息后，从中获取携带的业务标识，并基于该业务标识和保存的已授权享有该永远在线业务的业务标识，对该业务标识对应业务是否享有该永远在线业务的权利进行鉴权。

AOI应用服务器在接收到永远在线业务注册请求后，从中获取携带的业务标识，并基于该业务标识和保存的已授权享有该永远在线业务的业务标识，对该业务标识对应业务是否享有该永远在线业务的权利进行鉴权。

本步骤为可选步骤。

步骤305、针对接收的业务信息通知消息，如果鉴权通过，可以从业务信息通知消息中获取携带的终端标识和用户信息，并对应保存该终端标识、该业务标识和该用户信息；如果鉴权未通过，向用户终端上的中间件返回鉴权失败通知消息。

针对接收的永远在线业务注册请求，如果鉴权通过，可以从永远在线业务注册请求中获取携带的终端标识，并基于该终端标识，向核心网设备发送第一链路保活指示消息，用于指示核心网设备维持AOI应用服务器与该终端标识对应的该用户终端之间建立的公用链路的长连接状态，其中，该公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据；

该第一链路保活指示消息中携带表征该公用链路的链路信息，例如，可以携带该终端标识和该AOI应用服务器的设备标识，用于表征该用户终端与该AOI应用服务器之间建立的公用链路。

基于现有技术中的PCC(Policy and Charging Control，策略和计费控制)架构，向核心网设备发送第一链路保活指示消息，具体可以为：向PCRF(Policyand Charging Rules Function，策略与计费规则功能)发送第一链路保活指示消息，并由PCRF向GGSN(Gateway GPRS Support Node，网关GPRS支持节点)发送链路保活策略消息，该链路保活策略消息中携带用于指示GGSN维持该应用服务器与该用户终端之间建立的公用链路的长连接状态的策略信息；

具体的，该AOI应用服务器发送的第一链路保活指示消息可以采用Rx接口信令格式，并通过路由寻址，将该第一链路保活指示消息发送给PCRF。

步骤306、核心网设备接收到该第一链路保活指示消息后，从中获取携带的表征该公用链路的链路信息，并维持该公用链路的长连接状态，即为该用户终端提供永远在线能力。

具体的，基于不同的网络制式，核心网设备维持链路的长连接状态的处理过程不同，下面以PCC架构为例，对这一处理过程进行描述：

PCRF在接收到该第一链路保活指示消息后，基于其中携带的该公用链路的链路信息，确定与该公用链路对应的IP-CAN(IP-Connectivity AccessNetwork，IP连接访问网络)会话信息，向GGSN发送链路保活策略消息，该链路保活策略消息中携带用于指示GGSN维持该公用链路的长连接状态的策略信息，例如，携带该公用链路对应的IP-CAN会话信息，以及携带指示保持该IP-CAN会话不释放的指示信息；

GGSN接收到该链路保活策略消息后，将其中携带的IP-CAN会话信息对应的IP-CAN会话变更为永远在线类业务承载，并为该IP-CAN会话保持永远在线能力，具体为通知NAT(Network Address Translation，网络地址转换)功能实体不释放该IP-CAN会话对应的公网地址，保持该IP-CAN会话不释放，从而实现维持该公用链路的长连接状态。

步骤307、核心网设备在维持该公用链路的长连接状态后，向AOI应用服务器返回第一链路保活成功响应，用于告知AOI应用服务器该公用链路已经被维持长连接状态。

步骤308、AOI应用服务器在接收到核心网设备返回的第一链路保活成功响应后，可对应该用户终端的该终端标识保存表征该公用链路已保活的信息，用于后续需要使用该公用链路传输业务数据时，确定该用户终端与AOI应用服务器之间已建立处于长连接状态的公用链路。

步骤309、进一步的，该用户终端上的中间件还可以与AOI应用服务器通过信息交互，监测该公用链路是否处于正常工作状态，以便及时发现该公用链路的异常，避免因公用链路异常导致业务数据传输失败和不及时。

在完成用户终端向AOI应用服务器注册永远在线业务的处理流程，即核心网设备维持AOI应用服务器与用户终端之间建立的公用链路的长连接状态后，可以随时使用该公用链路向用户终端上的业务客户端推送业务数据，相当于该用户终端上的业务客户端是永远处于在线状态，即为该用户终端上的业务客户端提供了永远在线能力。

上述图3所示的用户终端向AOI应用服务器注册永远在线业务的处理流程，是由用户终端上的业务客户端触发的，除此触发机制外，还可以由AOI应用服务器基于业务服务器发送的业务数据推送请求，触发注册永远在线业务的处理流程，如图4所示，具体包括如下处理步骤：

步骤401、用户终端上的业务客户端向该用户终端上的中间件发送业务注册消息，该业务注册消息中携带该业务客户端对应业务的业务标识。

进一步的，该业务注册消息中，还可以携带用户使用该业务客户端对应业务时注册的用户信息，例如用户名，可用于由AOI应用服务器确定应该将来自业务服务器的业务数据转发给哪个用户终端，详见后续描述。

本步骤具体可以是在用户终端上安装了业务客户端后，如果该业务客户端已被授权享有永远在线业务，则可以自动触发向中间件发送业务注册消息，也可以在提示用户并受到用户的确认操作后，向中间件发送业务注册消息。

步骤402、用户终端上的中间件接收到该业务注册消息后，从中获取携带的该业务标识，确定该业务标识对应的业务客户端请求注册永远在线业务，保存该业务标识；进一步的，还可以从中获取携带的该用户信息，并保存，用于后续向AOI应用服务器注册永远在线业务使用。

步骤403、业务服务器向AOI应用服务器发送业务数据推送请求，用于请求通过AOI应用服务器向用户终端推送数据，具体的，该业务数据推送请求中可以携带本次业务数据推送对应的用户终端的终端标识。

进一步的，在该业务数据推送请求中，还可以携带该业务服务器对应业务的业务标识，用于AOI应用服务器对该业务标识对应的业务是否享有该永远在线业务的权利进行鉴权处理。

步骤404、AOI应用服务器在接收到业务数据推送请求后，从中获取携带的业务标识，并基于该业务标识和保存的已授权享有该永远在线业务的业务标识，对该业务标识对应业务是否享有该永远在线业务的权利进行鉴权。

本步骤为可选步骤。

步骤405、如果鉴权通过，可以根据其中携带的终端标识确定本次业务数据推送对应的用户终端，并检测该用户终端与自身之间是否建立处于长连接状态的公用链路，如果未建立，进入步骤406。

步骤406、AOI应用服务器向该终端标识对应的该用户终端发送链路建立通知消息。

步骤407、该用户终端接收到该链路建立通知消息后，通过中间件向AOI应用服务器发送永远在线业务注册请求，该永远在线业务注册请求中携带该用户终端的终端标识；

进一步的，该永远在线业务注册请求中，还可以携带该业务客户端对应业务的业务标识，用于AOI应用服务器对该业务标识对应的业务是否享有该永远在线业务的权利进行鉴权处理。

步骤408、AOI应用服务器接收到该永远在线业务注册请求后，通过与核心网设备的信息交互，进行相关的注册处理操作，具体可参见上述图3中的步骤304-步骤308，在此不再进行详细描述。

实施例2：

本发明实施例2中，对通过处于长连接状态的该公用链路，向用户终端上的业务客户端推送业务数据进行详细描述，如图5所示，具体包括如下处理步骤：

步骤501、业务服务器向AOI应用服务器发送业务数据推送请求，用于请求通过AOI应用服务器向用户终端推送数据，具体的，该业务数据推送请求中可以携带本次业务数据推送对应的用户终端的终端标识。

进一步的，在该业务数据推送请求中，还可以携带该业务服务器对应业务的业务标识，用于AOI应用服务器对该业务标识对应的业务是否享有该永远在线业务的权利进行鉴权处理。

步骤502、AOI应用服务器在接收到业务数据推送请求后，从中获取携带的业务标识，并基于该业务标识和保存的已授权享有该永远在线业务的业务标识，对该业务标识对应业务是否享有该永远在线业务的权利进行鉴权。

本步骤为可选步骤。

步骤503、如果鉴权通过，可以根据其中携带的终端标识确定本次业务数据推送对应的用户终端，并检测该用户终端与自身之间是否建立处于长连接状态的公用链路，如果已建立，进入步骤504。

步骤504、AOI应用服务器向该业务服务器返回业务数据推送请求响应，用于通知该业务服务器可以传输需要推送的业务数据。

本步骤也可以在上述步骤408之后触发执行。

步骤505、该业务服务器在接收到该业务数据推送请求响应后，向AOI应用服务器发送需要向该用户终端推送的业务数据，该业务数据中可以携带本次业务数据推送对应的该用户终端的终端标识，或者，也可以携带该业务服务器对应业务的业务标识，以及本次业务数据推送对应的用户信息。

步骤506、AOI应用服务器在接收到该业务数据后，可以根据其中携带的终端标识，通过该公用链路，将该业务数据发送给该终端标识对应的该用户终端；

也可以基于对应保存的业务标识、用户信息和终端标识，根据其中携带的业务标识和用户信息，确定出对应的终端标识，并通过该公用链路，将该业务数据发送给该终端标识对应的该用户终端。

步骤507、该用户终端接收AOI应用服务器发送的业务数据，具体为用户终端上的中间件接收到该业务数据，从中获取该业务数据对应业务的业务标识，确定出对应的业务客户端，然后通过与该业务客户端的信息交互，唤醒该业务客户端，将该业务数据转发给该业务客户端。

通过上述图5所示的处理流程，完成了业务服务器通过AOI应用服务器，利用AOI应用服务器与用户终端之间处于长连接状态的公用链路，将业务数据推送给该用户终端上对应的业务客户端。

由于针对用户终端上的各业务客户端，均可以通过该公用链路，由业务服务器向对应的业务客户端推送业务数据，所以，当用户终端上存在多个业务客户端时，相比现有技术，减少了用户终端与各业务服务器之间建立的链路的数量，即减少了网络链路资源的消耗；并且，由于该公用链路持续处于长连接状态，可以避免每次交互业务数据时均进行一次网络连接，即减少了网络连接过程中对网络资源的消耗；并且，可以直接向用户终端上的业务客户端推送业务数据，不需要先通过短信网关发送通知短信，即减少了对短信网关的负载，节省了短信网关短信发送资源的消耗，并且提高了业务数据推送的效率。

实施例3：

目前，在移动应用业务中，基于长在线技术的IM(Instant Messenger，即时通讯)类业务也是一种较常见的应用业务，例如，QQ。

如图6所示，现有技术中，IM类业务维持业务客户端处于长在线状态的方式如下：

用户在使用IM类业务的业务客户端时，需要首先与业务服务器之间建立一个TCP连接，登录该业务服务器后才能进行即时消息的发送和接收。现有移动核心网技术中，GGSN和防火墙针对一条已建立的TCP链路，如果该TCP链路在3分钟左右内没有任何数据传输，则会关闭该TCP链路，所以IM类业务应用为了使自身处于长在线状态，从而保持网络链路通畅，进行消息的即时传递，以及业务客户端与业务服务器之间的相互状态监控，采用了心跳包方式维持该TCP链路的长连接状态，具体如下：

在建立TCP连接后，每隔3分钟左右，由业务客户端发送一个心跳数据包到业务服务器，业务服务器在接收到该心跳数据包后，向业务客户端返回心跳响应，从而实现保持该TCP链路的长连接状态。

如果业务客户端在规定的一定时间间隔内，没有收到业务服务器的心跳响应答复，会认为网络链路不通或业务服务器出错，会进行重新连接登录；而业务服务器如果在规定的一定时间间隔内，没有收到业务客户端发送的心跳数据包，则会关闭此TCP链路，释放服务器资源；在用户注销退出业务客户端后，该TCP链路也会被关闭，用户无法再接收到消息。

然而，采用上述心跳包方式维持TCP链路的长连接状态，在每次发送心跳数据包时，均需要占用移动网络控制层面的信令资源，例如，在现网分组域网络架构中，能够支持为每个业务流提供基于业务的PCC策略，但此策略仅包括流规则、授权的QoS(Quality of Service，服务质量)等，由接受此策略的PCEF(Policy and Charging Enforcement Function，策略及计费执行功能)执行对业务流的QoS保证。在有分组业务承载时，当用户有业务请求时，才会激活IP-CAN，用户可以在此IP-CAN所包含的承载中实现业务。为了节约资源，在用户静默期一段时间之后，网络侧会释放IP-CAN(核心网内IP不可达)，同时，由于NAT(Network Address Translation，网络地址转换)穿透机制，在PDN(Public Data Network，公用数据网)侧网络资源(如公网地址)也会释放。

基于上述情况，移动网络不能感知IM类业务的存在，因此不能针对IM类业务特性进行维护，导致IM类业务上线后需要靠心跳包来维持连接状态，占用大量移动网络控制层面的信令资源，而每个心跳包的数据量又很小，导致数据传输层面的资源利用率较低，从而影响其它业务的正常运行，并降低了移动网络的网络服务质量。

为解决上述问题，基于本发明实施例提出的上述永远在线业务的处理方法，进一步的，还提出如下永远在线业务的处理方案，如图7所示，具体包括如下处理步骤：

步骤701、用户终端上的业务客户端通过与对应业务服务器之间的信息交互，登录该业务服务器。

业务客户端登录业务服务器之后，该用户终端与该业务服务器之间即建立了业务链路，用于传输业务数据。

步骤702、业务服务器在该业务客户端登录后，向AOI应用服务器发送链路保活请求，用于请求维持该业务服务器与该用户终端之间建立的该业务链路的长连接状态。

具体的，该链路保活请求中可以携带该用户终端的标识，进一步的，还可以携带该业务服务器对应业务的业务标识；

或者，可以携带用户使用该业务客户端对应业务时注册的用户信息，以及该业务服务器对应业务的业务标识。

步骤703、AOI应用服务器在接收到链路保活请求后，从中获取携带的业务标识，并基于该业务标识和保存的已授权享有该永远在线业务的业务标识，对该业务标识对应业务是否享有该永远在线业务的权利进行鉴权。

本步骤为可选步骤。

步骤704、如果鉴权通过，可以从链路保活请求中获取携带的终端标识，或者，可以基于对应保存的业务标识、用户信息和终端标识，确定与链路保活请求中携带的业务标识和用户信息，对应的终端标识。

基于该终端标识，向核心网设备发送第二链路保活指示消息，用于指示核心网设备维持该业务服务器与该终端标识对应的该用户终端之间建立的业务链路的长连接状态，其中，该业务链路用于传输该用户终端上的各业务客户端与各自对应的业务服务器之间的业务数据；

该第二链路保活指示消息中携带表征该业务链路的链路信息，例如，可以携带该终端标识和该业务服务器的设备标识，用于表征该用户终端与该业务服务器之间建立的业务链路。

基于现有技术中的PCC架构，向核心网设备发送第二链路保活指示消息，具体可以为：向PCRF发送第二链路保活指示消息，并由PCRF向GGSN发送链路保活策略消息，该链路保活策略消息中携带用于指示GGSN维持该业务服务器与该用户终端之间建立的业务链路的长连接状态的策略信息；

具体的，该AOI应用服务器发送的第二链路保活指示消息可以采用Rx接口信令格式，并通过路由寻址，将该第二链路保活指示消息发送给PCRF。

步骤705、核心网设备接收到该第二链路保活指示消息后，从中获取携带的表征该业务链路的链路信息，并维持该业务链路的长连接状态，即为该用户终端上的该业务客户端提供永远在线能力。

具体的，基于不同的网络制式，核心网设备维持链路的长连接状态的处理过程不同，下面以PCC架构为例，对这一处理过程进行描述：

PCRF在接收到该第二链路保活指示消息后，基于其中携带的该业务链路的链路信息，确定与该业务链路对应的IP-CAN会话信息，向GGSN发送链路保活策略消息，该链路保活策略消息中携带用于指示GGSN维持该业务链路的长连接状态的策略信息，例如，携带该业务链路对应的IP-CAN会话信息，以及携带指示保持该IP-CAN会话不释放的指示信息；

GGSN接收到该链路保活策略消息后，将其中携带的IP-CAN会话信息对应的IP-CAN会话变更为永远在线类业务承载，并为该IP-CAN会话保持永远在线能力，具体为通知NAT功能实体不释放该IP-CAN会话对应的公网地址，保持该IP-CAN会话不释放，从而实现维持该业务链路的长连接状态。

步骤706、核心网设备在维持该业务链路的长连接状态后，向AOI应用服务器返回第二链路保活成功响应，用于告知AOI应用服务器该业务链路已经被维持长连接状态。

步骤707、AOI应用服务器在接收到核心网设备返回的第二链路保活成功响应后，可对应该用户终端的该终端标识和该业务服务器的设备标识，保存表征该业务链路已保活的信息。

在通过核心网设备维持业务服务器与用户终端之间建立的业务链路的长连接状态后，该用户终端上的该业务客户端与对应业务服务器之间，可以随时使用该业务链路交互业务数据，相当于该用户终端上的业务客户端是永远处于在线状态，即为该用户终端上的业务客户端提供了永远在线能力，且不需要再通过心跳包方式维持该业务链路的长连接状态，从而减少了发送心跳包所占用网络资源的消耗，进而减少了对其它业务的影响，提高了网络服务质量。

实施例4：

在用户终端上已登录的业务客户端下线后，该业务客户端与对应业务服务器之间不需要再即时的传输业务数据，所以可以关闭该用户终端与该业务服务器之间的业务链路，释放网络链路资源。

本发明实施例4中，对业务客户端下线后，关闭用户终端与业务服务器之间处于长连接状态的业务链路的处理流程，如图8所示，具体包括如下步骤：

步骤801、用户终端上已登录的业务客户端，通过与对应业务服务器之间的信息交互，从该业务服务器注销。

步骤802、业务服务器在该业务客户端注销后，向AOI应用服务器发送链路关闭请求，用于请求关闭该业务服务器与该用户终端之间建立的该业务链路。

具体的，该链路关闭请求中可以携带该用户终端的标识；

或者，可以携带用户使用该业务客户端对应业务时注册的用户信息，以及该业务服务器对应业务的业务标识。

步骤803、AOI应用服务器接收到该链路关闭请求后，可以从中获取携带的终端标识，或者，可以基于对应保存的业务标识、用户信息和终端标识，确定与链路关闭请求中携带的业务标识和用户信息，对应的终端标识。

基于该终端标识，向核心网设备发送第二链路关闭指示消息，用于指示核心网设备关闭该业务服务器与该终端标识对应的该用户终端之间建立的业务链路；

该第二链路关闭指示消息中携带表征该业务链路的链路信息，例如，可以携带该终端标识和该业务服务器的设备标识，用于表征该用户终端与该业务服务器之间建立的业务链路。

基于现有技术中的PCC架构，向核心网设备发送第二链路关闭指示消息，具体可以为：向PCRF发送第二链路关闭指示消息，并由PCRF向GGSN发送链路关闭策略消息，该链路关闭策略消息中携带用于指示GGSN关闭该业务服务器与该用户终端之间建立的业务链路的策略信息；

具体的，该AOI应用服务器发送的第二链路关闭指示消息可以采用Rx接口信令格式，并通过路由寻址，将该第二链路关闭指示消息发送给PCRF。

步骤804、核心网设备接收到该第二链路关闭指示消息后，从中获取携带的表征该业务链路的链路信息，并关闭该业务链路，释放网络链路资源。

具体的，基于不同的网络制式，核心网设备关闭链路的处理过程不同，下面以PCC架构为例，对这一处理过程进行描述：

PCRF在接收到该第二链路关闭指示消息后，基于其中携带的该业务链路的链路信息，确定与该业务链路对应的IP-CAN会话信息，向GGSN发送链路关闭策略消息，该链路关闭策略消息中携带用于指示GGSN关闭该业务链路的策略信息，例如，携带该业务链路对应的IP-CAN会话信息，以及携带指示释放该IP-CAN会话的指示信息；

GGSN接收到该链路关闭策略消息后，取消为该IP-CAN会话保持永远在线能力，具体为通知NAT功能实体释放该IP-CAN会话对应的公网地址，释放该IP-CAN会话，从而实现关闭该业务链路。

步骤805、核心网设备在关闭该业务链路后，向AOI应用服务器返回第二链路关闭成功响应，用于告知AOI应用服务器该业务链路已经被关闭。

实施例5：

在用户终端上的业务客户端登录对应的业务服务器，并由核心网设备维持该用户终端与该业务服务器之间的业务链路的长连接状态后，用户终端上的中间件可以通过与该业务客户端之间的信息交互，监测该业务客户端的工作状态，并在监测到业务客户端的工作状态异常时，向应用服务器发送链路关闭请求，请求关闭对应业务服务器与该用户终端之间建立的业务链路，释放网络资源。

本发明实施例5中，对这一处理流程进行描述，如图9所示，具体包括如下步骤：

步骤901、用户终端上的中间件，通过与该用户终端上已登录的业务客户端之间的信息交互，监测该业务客户端的工作状态。

步骤902、当监测到该业务客户端的工作状态异常时，向AOI应用服务器发送链路关闭请求，用于请求关闭该业务客户端对应的业务服务器与该用户终端之间建立的业务链路。

具体的，该链路关闭请求中可以携带该用户终端的标识；

或者，可以携带用户使用该业务客户端对应业务时注册的用户信息，以及该业务服务器对应业务的业务标识。

步骤903、AOI应用服务器接收到该链路关闭请求后，可以从中获取携带的终端标识，或者，可以基于对应保存的业务标识、用户信息和终端标识，确定与链路关闭请求中携带的业务标识和用户信息，对应的终端标识。

进行关闭该业务链路的处理操作，基于该终端标识，通过与核心网设备的信息交互，完成关闭该用户终端与该业务服务器之间的业务链路，具体可参见上述步骤803-步骤805中公开的内容，在此不再进行详细描述。

实施例6：

基于同一发明构思，根据本发明上述实施例提供的永远在线业务的处理方法，相应地，本发明实施例6还提供了一种应用服务器，其结构示意图如图10所示，具体包括：

第一交互单元1001，用于接收用户终端发送的永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

第二交互单元1002，用于基于所述终端标识，向核心网设备发送第一链路保活指示消息，用于指示所述核心网设备维持所述应用服务器与所述终端标识对应的所述用户终端之间建立的公用链路的长连接状态，其中，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

进一步的，上述应用服务器，还包括：

第三交互单元1003，用于在第一交互单元1001接收用户终端发送的永远在线业务注册请求之前，接收所述业务服务器发送的业务数据推送请求，所述业务数据推送请求用于请求通过所述应用服务器向所述用户终端推送数据；

第一交互单元1001，还用于当确定所述应用服务器与所述用户终端之间未建立处于长连接状态的所述公用链路后，向所述用户终端发送链路建立通知消息。

进一步的，所述永远在线业务注册请求中携带所述用户终端上的业务客户端对应业务的业务标识；

上述应用服务器，还包括：

处理单元1004，用于在所述第二交互单元1002向核心网设备发送第一链路保活指示消息之前，获取所述永远在线业务注册请求中携带的所述业务标识；并基于所述业务标识，确定已授权所述业务客户端对应的业务享有永远在线业务。

进一步的，第二交互单元1002，具体用于向PCRF发送第一链路保活指示消息，并由所述PCRF向GGSN发送链路保活策略消息，所述链路保活策略消息中携带用于指示所述GGSN维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态的策略信息。

进一步的，第三交互单元1003，用于接收所述业务服务器发送的业务数据，所述业务数据为将要推送给所述用户终端上的与所述业务服务器对应的业务客户端的业务数据；

第一交互单元1001，还用于通过所述公用链路，将所述业务数据发送给所述用户终端。

进一步的，第三交互单元1003，用于当所述用户终端上的所述业务客户端登录对应的所述业务服务器后，所述应用服务器接收所述业务服务器发送的链路保活请求；

第二交互单元1002，还用于向所述核心网设备发送第二链路保活指示消息，用于指示所述核心网设备维持所述业务服务器与所述用户终端之间建立的业务链路的长连接状态。

进一步的，第一交互单元1001，还用于在所述第二交互单元1002向所述核心网设备发送第二链路保活指示消息后，接收所述用户终端通过所述公用链路发送的链路关闭请求；或者

第三交互单元1003，还用于在所述第二交互单元1002向所述核心网设备发送第二链路保活指示消息后，接收所述业务服务器发送的链路关闭请求；

所述第二交互单元1002，还用于向所述核心网设备发送第二链路关闭指示消息，用于指示所述核心网设备关闭所述业务服务器与所述用户终端之间建立的所述业务链路。

实施例7：

基于同一发明构思，根据本发明上述实施例提供的永远在线业务的处理方法，相应地，本发明实施例7还提供了一种用户终端，其结构示意图如图11所示，具体包括：中间件1101和业务客户端1102，其中：

中间件1101，用于生成永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；并向所述应用服务器发送永远在线业务注册请求，用于请求维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端1102推送业务数据。

进一步的，中间件1101，还用于在向所述应用服务器发送永远在线业务注册请求后，通过所述公用链路接收所述应用服务器发送的业务数据，所述业务数据为业务服务器发送的将要推送给所述用户终端上的与所述业务服务器对应的业务客户端1102的业务数据；并将所述业务数据转发给所述用户终端上的所述业务客户端1102；

业务客户端1102，用于接收所述业务数据。

进一步的，中间件1101，还用于与所述业务客户端1102通过信息交互，监测所述业务客户端1102的工作状态；并当监测到所述业务客户端1102的工作状态异常时，向所述应用服务器发送链路关闭请求，用于请求关闭所述业务服务器与所述用户终端之间建立的所述业务链路；

业务客户端1102，还用于与中间件1101通过信息交互，由中间件1101监测自身的工作状态。

实施例8：

基于同一发明构思，根据本发明上述实施例提供的永远在线业务的处理方法，相应地，本发明实施例8还提供了一种永远在线业务的处理系统，其结构示意图如图12所示，具体包括：

上述实施例6中的应用服务器1201和核心网设备1202。

有关应用服务器1201和核心网设备1202所执行的步骤和处理操作，可详见上述实施例1-6中的描述，在此不再进行详细描述。

综上所述，本发明实施例提供的方案，包括：应用服务器接收用户终端发送的永远在线业务注册请求，该永远在线业务注册请求中携带该用户终端的终端标识；并基于该终端标识，向核心网设备发送第一链路保活指示消息，用于指示核心网设备维持该应用服务器与该终端标识对应的该用户终端之间建立的公用链路的长连接状态，其中，该公用链路用于各业务服务器通过该应用服务器向该用户终端上对应的业务客户端推送业务数据。采用本发明实施例提供的方案，减少了向用户终端推送业务数据时网络资源的消耗。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (19)

1.一种永远在线业务的处理方法，其特征在于，包括：

应用服务器接收用户终端发送的永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

基于所述终端标识，向核心网设备发送第一链路保活指示消息，用于指示所述核心网设备维持所述应用服务器与所述终端标识对应的所述用户终端之间建立的公用链路的长连接状态，其中，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

2.如权利要求1所述的方法，其特征在于，在接收用户终端发送的永远在线业务注册请求之前，还包括：

所述应用服务器接收所述业务服务器发送的业务数据推送请求，所述业务数据推送请求用于请求通过所述应用服务器向所述用户终端推送数据；

当确定所述应用服务器与所述用户终端之间未建立处于长连接状态的所述公用链路后，向所述用户终端发送链路建立通知消息。

3.如权利要求1所述的方法，其特征在于，向核心网设备发送第一链路保活指示消息，具体为：

向PCRF发送第一链路保活指示消息，并由所述PCRF向GGSN发送链路保活策略消息，所述链路保活策略消息中携带用于指示所述GGSN维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态的策略信息。

4.如权利要求1所述的方法，其特征在于，还包括：

接收所述业务服务器发送的业务数据，所述业务数据为将要推送给所述用户终端上的与所述业务服务器对应的业务客户端的业务数据；

通过所述公用链路，将所述业务数据发送给所述用户终端。

5.如权利要求1所述的方法，其特征在于，还包括：

当所述用户终端上的所述业务客户端登录对应的所述业务服务器后，所述应用服务器接收所述业务服务器发送的链路保活请求；

向所述核心网设备发送第二链路保活指示消息，用于指示所述核心网设备维持所述业务服务器与所述用户终端之间建立的业务链路的长连接状态。

6.如权利要求5所述的方法，其特征在于，在向所述核心网设备发送第二链路保活指示消息后，还包括：

所述应用服务器接收所述用户终端通过所述公用链路发送的链路关闭请求，或者，接收所述业务服务器发送的链路关闭请求；

向所述核心网设备发送第二链路关闭指示消息，用于指示所述核心网设备关闭所述业务服务器与所述用户终端之间建立的所述业务链路。

7.一种永远在线业务的处理方法，其特征在于，包括：

用户终端上的中间件生成永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

向所述应用服务器发送永远在线业务注册请求，用于请求维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

8.如权利要求7所述的方法，其特征在于，在向所述应用服务器发送永远在线业务注册请求后，还包括：

所述用户终端上的中间件通过所述公用链路接收所述应用服务器发送的业务数据，所述业务数据为业务服务器发送的将要推送给所述用户终端上的与所述业务服务器对应的业务客户端的业务数据；

所述中间件将所述业务数据转发给所述用户终端上的所述业务客户端。

9.如权利要求7或8所述的方法，其特征在于，还包括：

所述中间件与所述用户终端上的业务客户端通过信息交互，监测所述业务客户端的工作状态；

当监测到所述业务客户端的工作状态异常时，向所述应用服务器发送链路关闭请求，用于请求关闭所述业务服务器与所述用户终端之间建立的所述业务链路。

10.一种应用服务器，其特征在于，包括：

第一交互单元，用于接收用户终端发送的永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；

第二交互单元，用于基于所述终端标识，向核心网设备发送第一链路保活指示消息，用于指示所述核心网设备维持所述应用服务器与所述终端标识对应的所述用户终端之间建立的公用链路的长连接状态，其中，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

11.如权利要求10所述的应用服务器，其特征在于，还包括：

第三交互单元，用于在所述第一交互单元接收用户终端发送的永远在线业务注册请求之前，接收所述业务服务器发送的业务数据推送请求，所述业务数据推送请求用于请求通过所述应用服务器向所述用户终端推送数据；

所述第一交互单元，还用于当确定所述应用服务器与所述用户终端之间未建立处于长连接状态的所述公用链路后，向所述用户终端发送链路建立通知消息。

12.如权利要求10所述的应用服务器，其特征在于，所述第二交互单元，具体用于向PCRF发送第一链路保活指示消息，并由所述PCRF向GGSN发送链路保活策略消息，所述链路保活策略消息中携带用于指示所述GGSN维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态的策略信息。

13.如权利要求10所述的应用服务器，其特征在于，还包括：

第三交互单元，用于接收所述业务服务器发送的业务数据，所述业务数据为将要推送给所述用户终端上的与所述业务服务器对应的业务客户端的业务数据；

所述第一交互单元，还用于通过所述公用链路，将所述业务数据发送给所述用户终端。

14.如权利要求10所述的应用服务器，其特征在于，还包括：

第三交互单元，用于当所述用户终端上的所述业务客户端登录对应的所述业务服务器后，所述应用服务器接收所述业务服务器发送的链路保活请求；

所述第二交互单元，还用于向所述核心网设备发送第二链路保活指示消息，用于指示所述核心网设备维持所述业务服务器与所述用户终端之间建立的业务链路的长连接状态。

15.如权利要求14所述的应用服务器，其特征在于，所述第一交互单元，还用于在所述第二交互单元向所述核心网设备发送第二链路保活指示消息后，接收所述用户终端通过所述公用链路发送的链路关闭请求；或者

所述第三交互单元，还用于在所述第二交互单元向所述核心网设备发送第二链路保活指示消息后，接收所述业务服务器发送的链路关闭请求；

所述第二交互单元，还用于向所述核心网设备发送第二链路关闭指示消息，用于指示所述核心网设备关闭所述业务服务器与所述用户终端之间建立的所述业务链路。

16.一种用户终端，其特征在于，包括：中间件和业务客户端，其中：

所述中间件，用于生成永远在线业务注册请求，所述永远在线业务注册请求中携带所述用户终端的终端标识；并向所述应用服务器发送永远在线业务注册请求，用于请求维持所述应用服务器与所述用户终端之间建立的公用链路的长连接状态，所述公用链路用于各业务服务器通过所述应用服务器向所述用户终端上对应的业务客户端推送业务数据。

17.如权利要求16所述的用户终端，其特征在于，所述中间件，还用于在向所述应用服务器发送永远在线业务注册请求后，通过所述公用链路接收所述应用服务器发送的业务数据，所述业务数据为业务服务器发送的将要推送给所述用户终端上的与所述业务服务器对应的业务客户端的业务数据；并将所述业务数据转发给所述用户终端上的所述业务客户端；

所述业务客户端，用于接收所述业务数据。

18.如权利要求16或17所述的用户终端，其特征在于，所述中间件，还用于与所述业务客户端通过信息交互，监测所述业务客户端的工作状态；并当监测到所述业务客户端的工作状态异常时，向所述应用服务器发送链路关闭请求，用于请求关闭所述业务服务器与所述用户终端之间建立的所述业务链路；

所述业务客户端，还用于与所述中间件通过信息交互，由所述中间件监测自身的工作状态。

19.一种永远在线业务的处理系统，其特征在于，包括：

如权利要求10-15中的所述应用服务器和所述核心网设备。

Images