CN103096293A - 应用数据处理方法及装置 - Google Patents

Abstract

本发明公开了应用数据处理方法及装置，该方法包括：接收用户设备通过控制面信令发送的应用数据；在接收到应用数据之后，将该应用数据通过IP数据包发送给应用服务器。通过本发明解决了相关技术中终端和应用服务器保活对网络带来的不利影响的问题，达到了降低由于频繁保活对系统带来资源消耗的效果。

Description

应用数据处理方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种应用数据处理方法及装置。

背景技术

在移动通信中，用户设备(User Equipment，简称UE)(或者也称为终端、或用户终端)经常需要和应用服务器(Application Server，简称为AS)之间通过保活消息来保持IP连接。如果UE长时间不发送保活消息给AS，AS很可能会认为UE当前已经非正常退出或移动到无信号区域导致无法和AS通讯，从而会主动注销UE的注册，从而UE和AS之间的IP连接、应用层注册关系都会设备释放。

一般而言，UE发往AS的保活消息通常都比较小，UE通常会间隔一个固定的时间给AS发送保活消息，比如：60秒。UE在发送两次保活消息中间，可能没有任何其他消息发往AS，因为用户可能在这段时间内没有任何操作。

图1是根据相关技术下UE接入到分组(Packet Service，PS)域的架构示意图，如图1所示，该结构涉及到了：UE、UMTS陆地无线接入网(UMTS Terrestrial Radio Access Network，简称为UTRAN)、演进的陆地无线接入网(Evolved UMTS简称为E-UTRAN)、服务GPRS支持节点(Serving GPRS Supporting Node，简称为SGSN)、移动性管理实体(MobileManagemeen Entity，简称MME)、归属位置寄存器(Home Location Register，简称为HLR)/归属用户服务器(Home Subscriber Server，简称为HSS)、S-GW、分组数据网络网关(PacketData Network Gateway，简称为P-GW)、网关GPRS支持节点(Gateway GPRS Supporting Node，简称为GGSN)、AS。

UE可通过UMTS、E-UTRAN接入到核心网，实现和AS的IP互连互通。在UE发送保活消息前，UE必须已经附着到核心网，并且已经注册到AS。在核心网已经为UE建立了合适的IP连接，UE也已经被分配了IP地址。UE向AS发送的IP数据包，必须经过公共数据网网关实体(在EUTRAN中是PGW，在GERAN/UTRAN中是GGSN)。在正常情况下，如果UE在一段时间内没有任何数据和信令通过基站发往核心网，基站将释放UE的无线侧连接，包括用于传输信令的无线信令承载、用于传输数据的无线数据承载。基站释放UE的无线侧连接的同时，可能会导致基站(如eNodeB)释放基站和核心网用户面实体(如SGW/PGW)间的连接，并进一步导致核心网将UE的状态从连接态(CONNECTED)转到空闲态(IDLE)。

基于这种原因，当UE发起IP层的保活消息时，无线侧可能已释放UE的无线侧连接，在核心网UE也可能已经进入空闲态。在这种情况下，当UE需要发起IP数据(IP层的保活消息)时，UE必须请求创建无线侧连接，核心网也被要求做出相应的一些处理。这些处理过程通常会耗费很多步骤，然而UE发送完该保活消息后，可能又不会有任何其他的数据发送，因而网络将会释放UE的无线侧连接、促使UE进入空闲态，而稍后UE可能再次发起IP保活。

上述情况，对于网络资源而言，造成了极大的浪费，尤其是对无线而言，基站频繁地为UE创建、释放无线侧连接，仅仅是为了传输很小的IP数据包。如果在一个基站下大量UE具有这类相似的行为，将过多地消耗基站的资源，严重限制了基站的并发服务能力。

图2是根据相关技术中UE接入到分组域后和AS实现保活的流程图，该图是以UE接入到E-UTRAN为例进行说明，如图2所示，该流程包括如下步骤：

步骤S201，UE附着到网络，网络为UE建立IP连接，分配IP地址；

步骤S202，UE向AS发起注册，其后，UE根据业务需要和AS通过交互消息传递数据；

步骤S203，UE和AS间无消息交互或数据传输，一段时间后，网络将UE从连接态转入空闲态，无线侧释放UE的无线连接和承载，并释放基站(例如，eNodeB)和用户面实体(例例如，SGW/PGW)间的连接；

步骤S204，UE的保活时间到达后，UE决定向AS发起保活消息；

步骤S205，UE向基站发起RRC连接请求，并向核心网发起服务请求(Service Request)；

UE发起RRC连接请求是为了创建无线承载，UE发起服务请求是要求核心网为UE准备好合适的资源。

步骤S206，基站将UE的服务请求转给SGSN/MME；

步骤S207，SGSN/MME根据需要，对UE执行鉴权；

步骤S208，SGSN/MME要求基站为UE创建上下文；

步骤S209，基站为UE创建无线承载，并通知UE；

步骤S210，UE在基站为UE创建好无线承载后，通过用户面向AS发送IP保活消息；

步骤S211，UE向AS发送完IP保活消息后，如果UE在一定时间内不再发送IP数据，则基站释放UE的无线连接和承载，同时释放基站到用户面实体的连接。核心网也可能将UE从连接态转入空闲态。

基站对UE的无线连接的释放，基于判断在一定时间内UE没有上任何上下行数据。当基站和核心网用户面实体(SGW/PGW、GGSN)间的连接被释放时，将促使UE从连接态变成空闲态。

仔细分析上述流程可以看出，如果UE和AS间的保活定时器时间比较长，大于基站所设置的释放UE的无线承载的定时器，则在UE向AS发送IP保活消息后，如果UE后续没有任何消息发往AS，或者AS不发送任何消息给UE，则基站会在定时器到达时候释放UE的无线承载。则等到下次UE再想发起IP保活的时候，必须要和基站建立无线连接，要求基站创建无线承载，要求核心网将UE激活成连接态并设置相关上下文。然而，这一系列的步骤仅仅是为了实现UE向AS发送一条非常简单的IP保活消息。

当存在大量UE进行保活时，对核心网也构成了一定的影响，核心网需要频繁地将UE在连接态和空闲态进行转换，并设置相应的上下文。

针对相关技术中终端和应用服务器之间的保活(以上以保活为例进行了说明，对于其他应用数据也有可能存在相似的问题)对网络带来不利影响的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中终端和应用服务器之间的保活对网络带来不利影响的问题，本发明提供了一种应用数据处理方法及装置，以至少解决上述问题。

根据本发明的一个方面，提供了一种应用数据处理方法，包括：接收用户设备通过控制面信令发送的应用数据；在接收到所述应用数据之后，将所述应用数据通过IP数据包发送给应用服务器。

优选地，接收所述用户设备通过控制面信令发送的IP数据包，其中，所述应用数据封装成所述IP数据包；在接收到所述IP数据包之后，将所述IP数据包发送给所述应用服务器。

优选地，所述应用数据包括：用于保护的保活信息。

优选地，公共数据网网关接收所述用户设备通过控制面信令发送的所述保活信息；所述公共数据网网关向所述应用服务器发送用于对所述用户设备进行保活的保活数据包。

优选地，在所述公共数据网网关接收所述用户设备通过控制面信令发送的用于保活的所述保活信息之前，所述方法还包括：移动性管理网元接收所述用户设备通过控制面信令发送的所述保活信息；所述移动性管理网元向所述公共数据网网关发送承载控制消息，其中，所述承载控制消息中携带有所述保活信息。

优选地，所述移动性管理网元接收所述用户设备发送的NAS消息，其中，所述NAS消息中携带有所述保活信息。

优选地，所述移动性管理网元接收所述用户设备发送的协议配置选项(ProtocolConfiguration Option，简称为PCO)信元，并通过所述承载控制消息将所述PCO信元发送给所述公共数据网网关，其中，所述PCO信元中携带有所述保活信息。

优选地，保活代理接收所述用户设备通过控制面信令发送的所述保活信息；所述保活代理向所述应用服务器发送所述保活数据包，其中，所述保活代理作为功能实体独立部署。

优选地，所述保活代理接收移动性管理网元或公共数据网网关发送的所述保活信息。

优选地，所述保活信息携带在非接入层(Non Access Stratum，简称为NAS)消息中，或者，所述保活信息携带在PCO信元中。

优选地，所述公共数据网网关直接接收来自所述用户设备的携带有所述保活信息的PCO信元，并将所述PCO信元发送给所述保活代理。

优选地，所述公共数据网网关包括：网关通用分组无线业务支持节点(Gateway GeneralPacket Radio Service Supporting Node，简称为GGSN)和/或PGW；和/或，所述移动性管理网元包括：服务GPRS支持节点SGSN和/或移动性管理实体MME。

优选地，接入网接收来自所述用户设备的保活信息，并将所述保活信息携带在NAS消息或PCO信元中发送给的所述移动性管理网元。

优选地，所述用户设备通过以下方式至少之一向所述接入网发送所述保活信息：将所述保活信息携带在NAS消息中、将所述保活信息携带在PCO信元中、将所述保活信息携带在RRC信令。

优选地，所述RRC信令包括以下至少之一：RRC连接建立请求、RRC连接完成。

优选地，所述方法还包括：所述用户设备在RRC连接建立请求中携带连接指示信息，其中，所述连接指示信息用于指示接入网不为所述用户设备创建用户面承载。

优选地，所述方法还包括：所述连接指示信息包括：RRC连接请求的原因设置为始发的信令。

优选地，所述保活信息包括以下至少之一：保活信元、保活数据包，其中，所述保活信元用于构建保活数据包。

优选地，所述保活信息包括：标识信息，其中，所述标识信息用于标识与所述用户设备对应的保活信元或者保活数据包；接收到的标识信息之后，查找与所述标识对应的保活信元或保活数据包，并向所述应用服务器发送根据所述保活信元构建的保活数据包或查找到的保活数据包。

优选地，在接收到所述保活信息之后向所述应用服务器发送用于对所述用户设备进行保活的保活数据包包括：向所述应用服务器发送所述保活数据包的网元，代替所述用户设备周期性地向所述应用服务器发送所述保活数据包，并且，所述用户设备抑制本地的保活流程。

优选地，在向所述应用服务器发送所述保活数据包的网元代替所述用户设备周期性地向所述应用服务器发送所述保活数据包的情况下，所述网元接收用户设备通过控制面信令发送的所述保活信息，或者接收所述用户设备通过与所述网元建立IP承载发送的所述保活信息。

优选地，所述网元代替所述用户设备周期性地向所述应用服务器发送所述保活数据包包括：所述网元获取所述用户设备的状态，在所述用户设备的状态需要进行保活的情况下，代替所述用户设备周期性地向所述应用服务器发送所述保活数据包。

根据本发明的另一个方面，还提供了一种应用数据处理装置，包括：接收模块，用于接收用户设备通过控制面信令发送的应用数据；发送模块，用于在接收到所述应用数据之后，通过IP数据包向应用服务器发送所述应用数据。

优选地，所述装置位于公共数据网网关上。

优选地，所述装置作为功能实体独立部署。

优选地，所述应用数据包括：用于保活的保活信息。

优选地，接收模块，用于接收所述用户设备通过控制面信令发送的IP数据包，其中，所述应用数据封装成所述IP数据包；发送模块，用于在接收到所述IP数据包之后，将所述IP数据包发送给所述应用服务器。

通过本发明，采用接收用户设备通过控制面信令发送的应用数据；在接收到所述应用数据之后，将所述应用数据通过IP数据包发送给应用服务器。解决了相关技术中终端和应用服务器保活对网络带来的不利影响的问题，达到了降低由于频繁保活对系统带来资源消耗的效果。

附图说明

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

图1是根据相关技术下UE接入到分组域的架构示意图；

图2是根据相关技术中UE接入到分组域后和AS实现保活的流程图；

图3是根据本发明实施例的保活方法的流程图；

图4是根据本发明实施例的应用数据处理装置的结构框图；

图5是根据本发明实施例一的流程图；

图6是根据本发明实施例一的优选实施方式一，UE通过RRC信令方式将保活信元发送给GGSN/PGW的流程图一；

图7是根据本发明实施例一的优选实施方式一，UE在RRC连接建立完成时将保活信元发送给GGSN/PGW的流程图二；

图8是根据本发明实施例一的优选实施方式二，UE通过NAS信令方式将保活信元发送给GGSN/PGW的流程图；

图9是根据本发明实施例一的优选实施方式三，UE通过PCO参数将保活信元发送给GGSN/PGW的流程图；

图10是根据本发明实施例二的架构示意图；

图11是根据本发明实施例二的优选实施方式一，UE将保活信元发送给KAP，KAP根据保活信元向AS发送IP保活数据包的流程图；

图12是根据本发明实施例二的优选实施方式二，UE先将保活信元发送给KAP，KAP保存保活信元，其后，UE指示KAP向AS发送IP保活数据包的流程图；

图13是根据本发明实施例三，KAP代替UE周期性地向AS发起IP保活的流程图；

图14是根据本发明实施例的应用数据处理的流程图。

具体实施方式

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

在以下实施例中描述了UE和应用服务器间通讯的方式：UE将原本要通过IP数据流发往应用服务器的应用数据，承载在控制面信令中发送到网络中的中继节点(例如，在以下实施例中提到的保活代理、GGSN/PGW等)，由中继节点代替UE将应用数据封装成IP数据包发送给应用服务器。对于保活信息而言，其可以认为是应用数据的一种。但是，应用数据并不限于保活信息这一种。

图14是根据本发明实施例的应用数据处理方法的流程图，如图14所示，该流程包括如下步骤：

步骤S1402，接收用户设备通过控制面信令发送的应用数据；

步骤S1404，在接收到应用数据之后，将应用数据通过IP数据包发送给应用服务器。

通过上述步骤，将原来需要通过IP数据流发送的应用数据通过控制面信令承载，从而不在需要建立用户面的承载，从而可以解决问题。上述步骤不仅仅能够解决背景技术中所提到的保活信息发送所存在的问题，而且还能够解决其他类型应用数据发送时的问题。在以下实施例中，以保活信息的处理为例进行说明，但是并不限于此，其他类型的应用数据也同样可以适用以下的实施例。

优选地，用户设备可以直接发送应用数据，然后由接收到该应用数据的网元和/或功能实体将该应用数据封装成IP数据包发送给应用服务器。当然，也可以由用户设备将应用数据封装在IP数据包中，接收到该IP数据包的网元和/或功能实体将接收到IP数据包发送给应用服务器。

在以下实施例中涉及到移动性管理网元、公共数据网网关，对于移动性管理网元而言，能过起到移动性管理功能的实体均可以认为是移动性管理网元，例如，SGSN、MME等。同样，对于公共数据网关而言，能够起到同数据网络连接并起到网关作用的功能实体均可以认为是公共数据网关，例如，GGSN、PGW等。

在以下实施例中，以应用数据为保活信息为例，提供了一种保活方法，图3是根据本发明实施例的保活方法的流程图，如图3所示，该方法包括以下步骤：

步骤S302，接收用户设备通过控制面信令发送的用于保活的保活信息；

步骤S304，在接收到保活信息之后向应用服务器发送用于对用户设备进行保活的保活数据包。

通过以上步骤，通过上述步骤，用户设备不再通过用户面来发送保活信息，而是通过控制面信令来发送用于保活的保活信息，这样无论对于接入网还是核心网而言均不再需要建立用户面实体的连接，从而起到了降低保活对网络资源影响的效果，解决了相关技术中用户设备和应用服务器间进行保活而带来的对网络带来的不利影响的问题。

执行上述步骤的可以是公共数据网网关，例如，GGSN、和/或PGW，也可以是为了实现保活而单独设置的功能实体，在以下实施例中将该功能实体称为保活代理，保活代理可以是一个或多个服务器的组合，也可以是一个功能模块，该功能模块可以位于现有的执行其他功能的功能实体上，例如，可以位于GGSN/PGW上(即相当于是GGSN/PGW执行上述步骤)。保活代理的如何设置可以根据实际的网络状况和应用状况来选择。以下以保活代理位于GGSN/PGW以及保活代理独立设置为例进行说明。以下的说明仅仅是举例说明，并不限于此。

优选示例一，保活代理位于GGSN/PGW上。保活代理位于GGSN/PGW上时，即GGSN/PGW接收用户设备通过控制面信令发送的保活信息；GGSN/PGW向应用服务器发送保活数据包。这种方式不需要对现有的网络架构进行任何的改变，只需要在GGSN/PGW上增加保活代理的功能即可。

移动性管理网元(例如，SGSN、MME)可以通过控制面信令的消息，例如承载控制消息，来携带保活信息并发送给GGSN/PGW。移动性管理网元接收到的保活信息可以携带在NAS消息中，也可以携带在PCO信元中，如果是携带在PCO信元中可以直接通过承载控制消息将该PCO信元发送给GGSN/PGW。

优选示例二，保活代理独立设置。这种方式，需要对现有的网络架构进行改变，由于方式一需要GGSN/PGW承担更多的功能，因此，这种方式可以降低对GGSN/PGW的要求。

对于这种方式，保活代理可以接收移动性管理网元或GGSN/PGW发送的保活信息。保活信息可以携带在NAS消息中，当然也可以携带在PCO信元中。如果用户设备将保活信息信贷在PCO信元中，那么，GGSN/PGW可以直接接收来自用户设备的携带有保活信息的PCO信元，然后将PCO信元发送给保活代理，这样可以实现用户设备和GGSN/PGW直接交互。

无论是上述优选示例一还是优选示例二，接入网和终端之间的保活信息的传输均可以使用如下的优选实施方式。

对于接入网(包括基站)而言，也可以选择控制面信令的消息或传输方式来传输(包括发送和接收)保活信息，例如，对于接入网发送保活信息而言，一个较优的实施方式是接入网接收来自用户设备的保活信息，可以将保活信息携带在NAS消息或PCO信元中发送给的移动性管理网元。又例如，对于用户设备向接入网发送保活信息而言，用户设备可以通过以下方式至少之一向接入网发送保活信息：将保活信息携带在NAS消息中、将保活信息携带在PCO信元中、将保活信息携带在RRC信令。其中，RRC信令包括以下至少之一：RRC连接建立请求、RRC连接完成。

优选地，为了防止接入网建立用户面承载，用户设备可以在RRC连接建立请求中携带连接指示信息(例如，RRC连接请求的原因设置为始发的信令)，其中，连接指示信息用于指示接入网不为用户设备创建用户面承载。

上述实施例中使用了保活信息，在实际应用的过程中，可以使用不同的保活信息来进行保活，例如，保活信息可以包括以下至少之一：保活信元、保活数据包，其中，保活信元用于构建保活数据包。

作为一个较优的保活信息的实施方式，保活信息包括：标识信息，其中，标识信息用于标识与用户设备对应的保活信元或者保活数据包；接收到的标识信息之后，查找与标识对应的保活信元或保活数据包，并向应用服务器发送根据保活信元构建的保活数据包或查找到的保活数据包。该优选实施方式，用户设备和保活代理之间不再需要发送保活信元，而直接发送相应的标识，从而减低了用户设备和保活代理之间传输的数据量。

作为一个更优的实施例，保活代理可以代替用户设备来进行保活处理，即保活代理代替用户设备周期性地向应用服务器发送保活数据包，并且，用户设备抑制本地的保活流程。通过这样的方式，用户设备不再需要保活，可以进一步地减少网络流量，并且，这种处理方式更加有效地解决了保活过程中所带来的问题。在保活代理替代用户设备进行保活处理的情况下，保活代理可以预先通过控制面信令或者与用户设备之间的IP承载来获取保活信息。

对应于上述方法，本实施例还提供了一种保活装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图4是根据本发明实施例的应用数据处理装置的结构框图，如图4所示，该装置包括：接收模块42和发送模块44，下面对该结构进行说明。

接收模块42，用于接收用户设备通过控制面信令发送的应用数据；发送模块44，用于在接收到应用数据之后，通过IP数据包向应用服务器发送应用数据。

优选地，发送模块用于将应用数据封装成IP数据包发送给应用服务器。

优选地，接收模块，用于接收用户设备通过控制面信令发送的IP数据包，其中，应用数据封装成IP数据包；发送模块，用于在接收到IP数据包之后，将IP数据包发送给应用服务器。

所述应用数据可以包括：用于保活的保活信息。此时，接收模块42，用于接收用户设备通过控制面信令发送的用于保活的保活信息；发送模块44，连接至接收模块42，用于在接收到保活信息之后向应用服务器发送用于对用户设备进行保活的保活数据包。

优选地，上述装置可以位于公共数据网网关上(例如，位于GGSN/PGW上)，或者，上述装置作为功能实体独立部署。

下面结合优选实施例和附图进行说明，以下优选实施例结合了上述实施例及优选实施方式。

实施例一

图5是根据本发明实施例一的流程图，如图5所示，UE将保活信元传递给GGSN/PGW，进而发送给AS，该流程包括如下步骤：

步骤S502，UE通过控制面信令将保活信元传递给GGSN/PGW；

步骤S504，当GGSN/PGW收到保活信元后，构造发往AS的IP保活数据包，或者利用UE所提供的IP保活数据包，通过发送IP数据包的方式向AS发送IP保活消息。

具体地，在本实施例中，UE所发送的保活信元可以是如下格式：

格式一，用以构造IP包含数据包的若干保活参数的组合，这些参数可以指示GGSN/PGW如何构造(或利用)IP保活数据包，该IP保活数据包用以向AS发送IP保活消息；比如：IP保活参数中，规定了IP保活消息发送端(即UE)的IP地址、发送端口、接收端(即AS)的IP地址、端口。另外，UE可以指定执行IP保活所采用的协议，根据该协议可以构造IP包含数据包的具体内容。或者UE可以明确地指明IP保活数据包的内容。

格式二，一个具体的IP保活数据包，这时IP数据包的内容是发往AS的IP保活消息，GGSN/PGW可直接向AS发送该IP保活数据包；

在本实施例中，UE通过控制面信令将保活信元传递给GGSN/PGW，可以采用如下几种方法：

方法一，如图6、7，UE在RRC信令中携带保活信元，基站将保活信元通过NAS消息发送给SGSN/MME，SGSN/MME通过承载控制消息将保活信元传递给GGSN/PGW；

方法二，如图8，UE在NAS信令中携带保活信元，发送给SGSN/MME，SGSN/MME通过承载控制消息将保活信元传递给GGSN/PGW；

方法三，如图9，UE在PCO参数中携带保活信元，发送给GGSN/PGW；

具体实施方式1

图6是根据本发明实施例一的优选实施方式一，UE通过RRC信令方式将保活信元发送给GGSN/PGW的流程图一。如图6所示，UE通过RRC信令将保活信元发送到基站，基站通过NAS消息将保活信元发送给SGSN/MME，SGSN/MME通过承载控制消息将保活信元发送给GGSN/PGW。GGSN/PGW根据保活信元，构造/生成IP保活消息，发送给AS。

步骤S602，UE向接入网(简称为RAN)(例如，基站)发起RRC连接请求，携带保活信元；

由于UE在希望发起IP保活前，UE和基站的无线连接是断开的，所以UE需要先向基站发起RRC连接请求，请求基站为其建立RRC连接。在该RRC连接请求消息中，可以携带保活信元。

为了避免基站为UE创建无线用户面承载(Radio Data Bearer，简称RDB)，UE可以将RRC连接请求的原因值设定为“始发的信令”(MO Signaling)。基站识别“始发的信令”后，不再为UE创建无线用户面承载。

步骤S604，基站收到UE的RRC连接请求后，取出保活信元，封装到NAS消息中，发送给SGSN/MME；

具体的NAS消息，可以是一条新定义的NAS保活消息，或者在其他合适的NAS消息里面携带保活信元。

步骤S606，SGSN/MME收到NAS消息后，取出保活信元，通过承载控制消息将保活信元发送给GGSN/PGW；

步骤S608，GGSN/PGW收到承载控制消息后，获得其中携带的保活信元。根据该保活信元的内容，GGSN/PGW向应用服务器AS发送IP保活消息，AS收到IP保活消息后，可能会返回合适的消息/IP数据包；

GGSN/PGW收到的保活信元可能是：

用以构造IP包含数据包的若干保活参数的组合。根据这些参数，GGSN/PGW构造发往AS的IP保活数据包；比如，保活信元中包含若干的保活参数，根据这些参数，GGSN/PGW可以构造一个发往AS的IP保活数据包，源地址为UE的IP地址，源端口为UE的端口，目标地址为AS的IP地址，目标端口为AS的端口，IP数据包的内容根据保活协议生成，或者根据指定的消息内容。或者是，一个具体的IP保活数据包。GGSN/PGW将这个IP保活数据包直接发给AS。

步骤S610，GGSN/PGW向SSGN/MME返回承载控制响应。其中，响应中可能携带合适的IP保活响应值；

如果GGSN/PGW将IP保活消息成功发往AS，则GGSN/PGW可以设置IP保活响应值的取值为“成功”，否则设置为“失败”。

步骤S612，SGSN/MME向基站返回NAS响应。其中，NAS响应中可能携带合适的IP保活响应值，说明IP保活消息有没有成功发出；

步骤S614，基站向UE返回RRC连接设置消息，要求UE自身准备RRC连接资源。其中，RRC连接响应中可能携带合适的IP保活响应值；

步骤S616，UE准备好RRC连接资源后，向基站返回RRC连接完成消息；

步骤S618，后续其他步骤。

在本实施例中，需要指出的是，当SGSN/MME收到UE发送的保活信元后，如果当前UE为空闲态，SGSN/MME可以不将UE触发成激活态，这样将避免UE的状态频繁地被改变，降低状态改变所带来的资源消耗。

在图6所示的优选实施方式中，UE在RRC连接请求中携带保活信元。然而，这种方式具有一定的局限性，因为RRC连接请求通常长度受到限制，发送超过其限制长度的数据可能会由于无线自身机制导致数据发送的不稳定。因此，可以考虑在RRC连接建立完成时，UE在向基站发送RRC连接完成消息时携带保活信元。

图7是根据本发明实施例一的优选实施方式一，UE通过RRC信令方式将保活信元发送给GGSN/PGW的流程图二。图7描述了的方式和图6方式的不同包括：

步骤S702～S706，UE先通过步骤S702～S704请求基站创建无线资源，然后在步骤S706的RRC连接完成消息中携带保活信元。

步骤S718，基站收到SGSN/MME发送的NAS响应消息后，向UE发送下行RRC信令，携带响应值。

图8是根据本发明实施例一的优选实施方式二，UE通过NAS信令方式将保活信元发送给GGSN/PGW的流程图。如图8所示，UE通过NAS信令将保活信元发送到送给SGSN/MME，SGSN/MME通过承载控制消息将保活信元发送给GGSN/PGW。GGSN/PGW根据保活信元，构造/生成IP保活消息，发送给AS。

和图6、7所示的优选实施方式不同之处在于，UE在NAS层消息中携带保活信元，而SGSN/MME和GGSN/PGW的交互、GGSN/PGW和AS间的交互则和图6、7所示的优选实施方式相同。

步骤S802，UE向SGSN/MME发送NAS消息，携带保活信元；

具体的NAS消息，可以是一条新定义的NAS保活消息，或者在其他合适的NAS消息里面携带保活信元。

步骤S804～步骤S808，SGSN/MME将保活信元通过承载控制消息将保活信元发送给GGSN/PGW，GGSN/PGW根据保活信元内容向AS发送IP保活消息；

步骤S810，SGSN/MME向UE返回NAS响应。其中，NAS响应中可能携带合适的IP保活响应值，说明IP保活消息有没有成功发出。

同样地，由于UE在发送IP保活信元前并没有建立无线承载，所以UE仍然需要向基站发起RRC连接建立过程。为了避免建立无线用户面承载，UE可以设置RRC连接原因值为MO Signaling。

同样地，对SGSN/MME而言，在收到保活信元时，SGSN/MME可以不触发UE的状态变迁过程，这样可避免频繁切换UE的状态所导致的低效率和资源消耗。

图9是根据本发明实施例一的优选实施方式三，UE通过PCO参数将保活信元发送给GGSN/PGW的流程图。如图9所示，UE通过承载创建/变更消息，在PCO信元中携带保活信元SGSN/MME，SGSN/MME将PCO信元透传给GGSN/PGW。GGSN/PGW根据保活信元，构造/生成IP保活消息，发送给AS。

和图8所示的实施方式的不同之处在于，在步骤S902中，UE在PCO信元中携带保活信元，而SGSN/MME在步骤S904中透传该PCO信元。

同样地，由于UE在发送IP保活信元前并没有建立无线承载，所以UE仍然需要向基站发起RRC连接建立过程。为了避免建立无线用户面承载，UE可以设置RRC连接原因值为MOSignaling。

同样地，对SGSN/MME而言，在收到保活信元时，SGSN/MME可以不触发UE的状态变迁过程，这样可避免频繁切换UE的状态所导致的低效率和资源消耗。

实施例二

在实施例一中，UE通过控制面信令将保活信元携带到GGSN/PGW，由GGSN/PGW构造或生成IP数据包发送IP保活消息给AS。这种方式要求GGSN/PGW充当保活代理(Keep-AliveProxy，简称KAP)，并且这种保活代理可能需要理解特殊的保活协议格式，因而这种方式对GGSN/PGW未必是最合适的。

一种改进的方式，是将按保活信元构造IP保活数据包(即IP保活消息)的功能隔离出来，由单独的保活代理来执行。KAP的部署，可以由运营商控制，KAP到其他网元的接口，可以基于内部接口。

图10是根据本发明实施例二的架构示意图。如图10所示，SGSN/MME、GGSN/PGW和KAP间可以通过内部接口传递保活信元。另外，在UE上可以独立配置KAP，UE通过IP连接向KAP提出保活要求。

引入保活代理KAP后，UE可以通过如下方式将保活信元传递给KAP：

方式一，UE通过NAS信令将保活信元传递给SGSN/MME，SGSN/MME向KAP发送保活消息，携带保活信元；

方式二，UE通过PCO方式，将保活信元传递给GGSN/PGW，GGSN/PGW向KAP发送保活消息，携带保活信元；

方式三，UE通过用户面方式将保活信元发送给KAP。保活信元被包含在UE发往KAP的消息中。

图11是根据本发明实施例二的优选实施方式一，UE将保活信元发送给KAP，KAP根据保活信元向AS发送IP保活数据包的流程图。如图11所示，该流程包括如下步骤：

步骤S1102，UE通过如下方式将保活信元发送给KAP：

方式1，步骤S1102a1～步骤S1102a2，UE通过RRC方式、NAS方式，将保活信元包含在RRC信令、NAS信令中，发送给SGSN/MME。SGSN/MME收到保活信元后，向KAP发送保活消息，携带保活信元；

方式2，步骤S1102b1～步骤S1102b2，UE通过PCO方式，将保活信元保活在PCO信元中，直接发送到GGSN/PGW。GGSN/PGW收到保活信元后，向KAP发送保活消息，携带保活信元；

方式3，步骤S1102c，UE向KAP直接发送保活消息，携带保活信元；

步骤S1104，KAP收到保活消息后，根据保活信元的指示，构造/生成IP保活数据包，向AS发送IP保活消息；

步骤S1106，后续保活响应的返回过程，和前面实施方式相同。

在图11所描述的优选实施方式中，UE每次都需要将完整的保活信元发送给KAP，KAP根据该保活信元来构成/生成发往AS的IP保活数据包。这很显然造成了一定的浪费，因为UE和特定AS之间的IP保活形式基本是固定的。

图12是根据本发明实施例二的优选实施方式二，UE先将保活信元发送给KAP，KAP保存保活信元，其后，UE指示KAP向AS发送IP保活数据包的流程图。，如图12所示，对上述方式进行了改进，通过UE首次将保活信元发送给KAP，其后，UE只需要通知KAP根据特定的保活信元来发送IP保活消息给AS。通过这一改进过程，可以降低后续UE发起保活过程中的信息传递量，尤其对无线资源而言，UE可以实现在RRC连接请求消息中携带保活请求指示，而基站可以不为UE创建无线数据面承载、甚至是无线信令面承载，通过对无线信令的这一改进，可以极大地节省无线资源。

如图12所示，该流程包括如下步骤：

步骤S1202，UE附着到网络；

步骤S1204，UE通过网络向KAP发送保活信元；

本步骤中，UE向基站发送RRC信令，在RRC信令中携带保活信元。基站收到保活信元后，在NAS信令中携带保活信元，发送给SGSN/MME。SGSN/MME接到NAS消息后，在承载控制消息中携带保活信元，发送给GGSN/PGW。GGSN/PGW向KAP发送保活消息，携带保活信元。

当然，根据前述实施例，UE通过网络向KAP发送保活信元还可以有其他方式，比如，UE通过PCO方式将保活信元发送给GGSN/PGW。

步骤S1206，KAP收到保活信元后，在本地保存保活信元。根据需要，KAP可能构造IP保活数据包发往AS；

步骤S1208，一定时间后，基站释放UE的无线连接，UE进入空闲态；

步骤S1210，其后，UE由于应用程序的需要，需要向AS发起IP保活；

步骤S1216，UE发起RRC信令，在RRC信令中携带保活指示；

该保活指示，可以标识UE先前发送到保活代理KAP的保活信元。而KAP通过该保活指示，也可以查找到具体的保活信元。

该保活指示，UE可以直接携带在RRC信令中，后续由基站从RRC信令中提取出来，经过NAS消息转发给SGSN/MME。或者，UE可以在RRC信令中携带NAS消息，并在NAS消息中携带该保活指示，则基站不解析NAS内容，直接将NAS消息转发给SGSN/MME。

步骤S1214，基站向SGSN/MME发送NAS消息，携带UE发送的保活指示；

步骤S1216～步骤S1218，SGSN/MME经过GGSN/PGW向KAP发送保活消息，携带所述保活指示；

当然，如前述实施例和实施方式所述，SGSN/MME也可能通过内部接口向KAP直接发送保活消息，携带所述保活指示。

步骤S1220，当KAP收到UE发送的保活指示后，根据保活指示所对应的保活上下文，构造/生成IP保活数据包，发往AS；

步骤S1222～步骤S1228，根据配置策略，如果KAP向AS发送IP保活消息成功/失败，KAP需要将保活响应发送给UE。保活响应被携带在网络发往UE的消息中，具体地如前述实施例所描述。

如前述实施例和实施方式所述，在本流程过程中，核心网不触发UE的状态转换，即如果当前UE在空闲态，将不会触发UE的状态变成连接态。

实施例三

考虑到实施例二所描述的流程(图12)中，UE仍然需要在每次保活时主动发起信令连接，对网络也是一个不小的开销。如果考虑UE通知保活代理KAP，代替UE周期性发起保活，则可以极大地降低信令开销。为了避免当UE移出位置区域、失去信号等异常情况时KAP仍然持续地为UE保活，可以让KAP周期性地从网络检查UE的状态。

图13是根据本发明的实施例三，KAP代替UE周期性地向AS发起IP保活的流程图。如图13所示，该流程包括如下步骤：

步骤S1302～步骤S1306，UE附着到网络，经过网络向KAP发送保活信元，具体细节如前述实施方式；

在本实施例的流程中，UE在发往KAP的保活信元中，添加了IP保活周期的参数，要求KAP根据该IP保活周期，周期性地向AS发送IP保活数据包。

步骤S1308，一定时间后，基站释放UE的无线连接，UE进入空闲态；

步骤S1310，KAP根据UE发送的保活信元，计算保活周期，当保活周期到达时，决定代替UE发起IP保活；

步骤S1312，可选地，KAP在代替UE发起IP保活前，向网络查询UE当前的状态。可以采用如下方式：

方式一，如步骤S1312a，KAP向GGSN/PGW查询UE的状态：响应于KAP的查询请求，如果GGSN/PGW上有UE的IP上下文，可以认为UE当前处于活动状态，则GGSN/PGW返回UE当前的状态为活动(或者“在线”)。

方式二，如步骤S1312b，KAP向SGSN/MME查询UE的状态：响应于KAP的查询请求，如果SGSN/MME上有UE的上下文，并且UE未从网络注销，可以认为UE当前处于活动状态，则SGSN/MME返回UE当前的状态为活动(或者“在线”)。

根据从网络查询到的UE的当前状态，KAP根据策略决定是否继续发起IP保活。典型地，如果UE当前“活动”则KAP代替UE发起IP保活，如果UE当前“不活动”，可能KAP取消发起IP保活。

步骤S1314，KAP向AS发送IP保活消息包。其后，KAP周期性地向AS发送IP保活消息包。

在本实施例中，当UE要求KAP代替UE发送IP保活消息给AS后，UE需要自行抑制自身发起的IP保活流程。

另外，UE向KAP发送保活信元的过程，可以使用用户面的方式，即UE通过IP承载直接向KAP发送保活消息，携带保活信元，该过程不需要经过控制面节点(如SGSN/MME)。

在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。

在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。

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

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

Claims (26)

1.一种应用数据处理方法，其特征在于包括：

接收用户设备通过控制面信令发送的应用数据；

在接收到所述应用数据之后，将所述应用数据通过IP数据包发送给应用服务器。

2.根据权利要求1所述的方法，其特征在于，

接收所述用户设备通过控制面信令发送的IP数据包，其中，所述应用数据封装成所述IP数据包；

在接收到所述IP数据包之后，将所述IP数据包发送给所述应用服务器。

3.根据权利要求1所述的方法，其特征在于，所述应用数据包括：用于保护的保活信息。

4.根据权利要求3所述的方法，其特征在于，

公共数据网网关接收所述用户设备通过控制面信令发送的所述保活信息；

所述公共数据网网关向所述应用服务器用于对所述用户设备进行保活的保活数据包。

5.根据权利要求4所述的方法，其特征在于，在所述公共数据网网关接收所述用户设备通过控制面信令发送的用于保活的所述保活信息之前，所述方法还包括：

移动性管理网元接收所述用户设备通过控制面信令发送的所述保活信息；

所述移动性管理网元向所述公共数据网网关发送承载控制消息，其中，所述承载控制消息中携带有所述保活信息。

6.根据权利要求5所述的方法，其特征在于，所述移动性管理网元接收所述用户设备发送的非接入层NAS消息，其中，所述NAS消息中携带有所述保活信息。

7.根据权利要求5所述的方法，其特征在于，所述移动性管理网元接收所述用户设备发送的协议配置选项PCO信元，并通过所述承载控制消息将所述PCO信元发送给所述公共数据网网关，其中，所述PCO信元中携带有所述保活信息。

8.根据权利要求3所述的方法，其特征在于，

保活代理接收所述用户设备通过控制面信令发送的所述保活信息；

所述保活代理向所述应用服务器发送所述保活数据包，其中，所述保活代理作为功能实体独立部署。

9.根据权利要求8所述的方法，其特征在于，所述保活代理接收移动性管理网元或公共数据网网关发送的所述保活信息。

10.根据权利要求7所述的方法，其特征在于，所述保活信息携带在NAS消息中，或者，所述保活信息携带在PCO信元中。

11.根据权利要求10所述的方法，其特征在于，所述公共数据网网关直接接收来自所述用户设备的携带有所述保活信息的PCO信元，并将所述PCO信元发送给所述保活代理。

12.根据权利要求5至7、9至10中任一项所述的方法，其特征在于，

接入网接收来自所述用户设备的保活信息，并将所述保活信息携带在NAS消息或PCO信元中发送给的所述移动性管理网元。

13.根据权利要求4至11中任一项所述的方法，其特征在于，

所述公共数据网网关包括：网关通用分组无线业务支持节点GGSN和/或分组数据网络网关PGW；和/或

所述移动性管理网元包括：服务GPRS支持节点SGSN和/或移动性管理实体MME。

14.根据权利要求12所述的方法，其特征在于，所述用户设备通过以下方式至少之一向所述接入网发送所述保活信息：

将所述保活信息携带在NAS消息中、将所述保活信息携带在PCO信元中、将所述保活信息携带在RRC信令。

15.根据权利要求14所述的方法，其特征在于，所述RRC信令包括以下至少之一：RRC连接建立请求、RRC连接完成。

16.根据权利要求14所述的方法，其特征在于，还包括：所述用户设备在RRC连接建立请求中携带连接指示信息，其中，所述连接指示信息用于指示接入网不为所述用户设备创建用户面承载。

17.根据权利要求16所述的方法，其特征在于，还包括：所述连接指示信息包括：RRC连接请求的原因设置为始发的信令。

18.根据权利要求3所述的方法，其特征在于，所述保活信息包括以下至少之一：保活信元、保活数据包，其中，所述保活信元用于构建保活数据包。

19.根据权利要求3所述的方法，其特征在于，所述保活信息包括：标识信息，其中，所述标识信息用于标识与所述用户设备对应的保活信元或者保活数据包；接收到的标识信息之后，查找与所述标识对应的保活信元或保活数据包，并向所述应用服务器发送根据所述保活信元构建的保活数据包或查找到的保活数据包。

20.根据权利要求3、4、8、18或19所述的方法，其特征在于，在接收到所述保活信息之后向所述应用服务器发送用于对所述用户设备进行保活的保活数据包包括：

向所述应用服务器发送所述保活数据包的网元，代替所述用户设备周期性地向所述应用服务器发送所述保活数据包，并且，所述用户设备抑制本地的保活流程。

21.根据权利要求20所述的方法，其特征在于，在向所述应用服务器发送所述保活数据包的网元代替所述用户设备周期性地向所述应用服务器发送所述保活数据包的情况下，所述网元接收用户设备通过控制面信令发送的所述保活信息，或者接收所述用户设备通过与所述网元建立IP承载发送的所述保活信息。

22.根据权利要求20所述的方法，其特征在于，所述网元代替所述用户设备周期性地向所述应用服务器发送所述保活数据包包括：

所述网元获取所述用户设备的状态，在所述用户设备的状态需要进行保活的情况下，代替所述用户设备周期性地向所述应用服务器发送所述保活数据包。

23.一种应用数据处理装置，其特征在于包括：

接收模块，用于接收用户设备通过控制面信令发送的应用数据；

发送模块，用于在接收到所述应用数据之后，通过IP数据包向应用服务器发送所述应用数据。

24.根据权利要求23所述的装置，其特征在于，所述装置位于公共数据网网关上，或者，所述装置作为功能实体独立部署。

25.根据权利要求23或24所述的装置，其特征在于，所述应用数据包括：用于保活的保活信息。

26.根据权利要求23或24所述的装置，其特征在于，

接收模块，用于接收所述用户设备通过控制面信令发送的IP数据包，其中，所述应用数据封装成所述IP数据包；

发送模块，用于在接收到所述IP数据包之后，将所述IP数据包发送给所述应用服务器。

Images