CN105682014A - 通信方法与系统，以及接入网设备与应用服务器 - Google Patents

Abstract

本发明实施例提供通信方法与系统，以及接入网设备与应用服务器，所述通信方法包括：接入网设备接收业务报文；所述接入网设备根据策略向应用服务器发送所接收的业务报文，所述应用服务器设置于接入网侧，独立于所述接入网设备或设置于所述接入网设备之内，且所述应用服务器支持至少一种业务运行。可见，其在接入网侧引入可以支持第三方应用运行的应用服务器，如此，UE可以直接与接入网侧进行业务交互，大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，从而使用户体验更佳。

Description

通信方法与系统，以及接入网设备与应用服务器

技术领域

本发明实施例涉及移动通信技术领域，尤其涉及一种通信方法与系统，以及接入网设备与应用服务器。

背景技术

在移动通信技术领域，用户设备(UserEquipment，UE)需要通过无线网络与外部网络(例如，因特网(Internet))建立连接，进而通过外部网络或远端服务器，享受第三方应用业务的服务。

如图1所示，无线网络主要包括接入网110和核心网(CoreNetwork，CN)120，其中对无线资源的管理功能主要集中在接入网110完成，而与业务和应用相关功能主要集中在核心网120完成。可见，接入网110是连接UE130和核心网120的桥梁。UE130与外部网络的业务交互需基于UE、接入网与核心网之间的连接，并最终通过核心网侧的网关121实现。由于远端服务器140位于核心网的网关121之后，远离UE130，会引起业务时延拉长且业务服务质量(QualityofService，QoS)较低等问题，从而影响用户体验。

发明内容

本发明实施例提供通信方法与系统，以及接入网设备与应用服务器，以解决业务时延拉长、业务QoS较低等问题，从而提高用户体验。

一方面，本发明实施例提供一种通信方法，包括：接入网设备接收业务报文；所述接入网设备根据策略向应用服务器发送所接收的业务报文，所述应用服务器设置于接入网侧，独立于所述接入网设备或设置于所述接入网设备之内，且所述应用服务器支持至少一种业务运行。

另一方面，本发明实施例提供一种通信方法，包括：应用服务器接收接入网设备发送的业务报文，所述应用服务器设置于接入网侧，独立于所述接入网设备或设置于所述接入网设备之内，且所述应用服务器支持至少一种业务运行；所述应用服务器处理所述业务报文。

另一方面，本发明实施例提供一种接入网设备，包括：用于与用户设备进行通信的第一接口单元；用于与核心网进行通信的第二接口单元；用于与应用服务器进行通信的第三接口单元，其中所述应用服务器设置于接入网侧，且独立于所述接入网设备或设置于所述接入网设备之内，所述应用服务器支持至少一种业务运行；处理器，分别与所述第一接口单元、第二接口单元和第三接口单元连接，且所述处理器用于通过所述第一接口单元或第二接口单元接收业务报文，且通过第三接口单元，根据策略向所述应用服务器发送所接收的业务报文。

另一方面，本发明实施例提供一种应用服务器，支持至少一种业务运行，所述应用服务器位于接入网侧，且独立于接入网设备或设置于所述接入网设备之内，所述应用服务器包括：用于与接入网设备进行通信的接口单元；存储单元，用于存储所述应用服务器所支持业务的业务数据；处理单元，分别与所述接口单元和所述存储单元连接，所述处理单元用于通过所述接口单元接收所述接入网设备发送的业务报文，并处理所述业务报文。

另一方面，本发明实施例提供一种通信系统，其接入网侧设置有如上所述的接入网设备与如上所述的应用服务器。

可见，本发明实施例在接入网侧引入可以支持第三方应用运行的应用服务器，如此，UE可以直接与接入网侧进行业务交互，大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，从而使用户体验更佳。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为现有的一种通信系统的结构示意图；

图2为本发明实施例所提供的一种通信系统的结构示意图；

图3为本发明实施例所提供的一种接入网设备的结构示意图；

图4为本发明实施例所提供的一种应用服务器的结构示意图；

图5为本发明实施例所提供的一种应用服务器处理业务报文的流程示意图；

图6为本发明实施例所提供的另一种应用服务器处理业务报文的流程示意图；

图7为本发明实施例所提供一种应用与无线网络接口协议的结构示意图；

图8为本发明实施例所提供的一种应用服务器的软件架构图；

图9为本发明实施例所提供的一种通信方法的流程图；

图10为本发明实施例所提供的另一种通信方法的流程图；

图11为本发明实施例所提供的又一种通信方法的示意图；

图12为本发明实施例所提供的一种LTE通信系统的结构示意图；

图13为本发明实施例所提供的一种LTE通信系统的用户面数据流示意图；

图14为本发明实施例所提供的一种LTE通信系统的用户面接口示意图；

图15为本发明实施例所提供的一种LTE通信系统中控制面数据流示意图。

具体实施方式

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

本发明实施例充分考虑到现有第三方应用业务交互过程中所存在的问题，在接入网侧引入可以支持第三方应用运行的逻辑网元，如此，UE可以直接与接入网侧进行业务交互，大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，从而使用户体验更佳。下面结合附图进行详细的描述。

请参考图2，其为本发明实施例所提供的一种通信系统的结构示意图。参照图1可以看出，本发明实施例在接入网210侧引入的逻辑网元为应用服务器212，该应用服务器212支持至少一种业务的运行。且物理上，应用服务器212可以是位于接入网设备211之外的独立设备，也可以集成在接入网设备211之中，本实施例不做任何限制。

接入网设备211除完成原有的功能外，需要增加报文旁路功能，将来自UE230或核心网220的业务报文旁路到应用服务器212上进行处理。接入网设备211的原有功能包括无线资源的管理、空口数据的转发、UE状态维护等，其为本领域技术人员所熟知，在此不再赘述。

需要说明的是，接入网设备211是一种将UE接入到无线网络的设备,包括但不限于：基站(NodeB)、演进型基站(evolvedNodeB，eNB)、家庭基站(HomeNodeB，HNB)/(HomeeNodeB，HeNB)、无线网络控制器(radionetworkcontroller，RNC)、基站控制器(BaseStationController，BSC)、基站收发台(BaseTransceiverStation，BTS)。

此外，本实施例所述的第三方应用包括但不限于网页(Web)类的缓存(Cache)加速、视频转码、机对机(Machine-to-Machine，M2M)握手信令终结，内容存储发布等，其可以由第三方提供，本实施例不做任何约束。另外，应用服务器212可以是开放式的应用服务器，其为第三方应用服务商提供一个开放的平台，支持各种第三方应用的扩展，如此，有利于用户体验的进一步提高。

下面结合附图对接入网设备211和应用服务器212进行更加详细的描述。

请参考图3，其为本发明实施例所提供的一种接入网设备的结构示意图。如图所示，该接入网设备211包括：第一接口单元310、第二接口单元320、第三接口单元330和分别与所述第一接口单元310、第二接口单元320和第三接口单元330连接的处理器340。其中第一接口单元310用于与UE230进行通信；第二接口单元320用于与核心网220进行通信；第三接口单元330用于与应用服务器212进行通信；处理器340用于通过所述第一接口单元310或第二接口单元320接收业务报文，且通过第三接口单元330，根据策略向所述应用服务器212发送所接收的业务报文。其中，所述应用服务器212同以上描述，支持至少一种业务运行，且设置于接入网侧，可以独立于所述接入网设备211，也可以设置于所述接入网设备211之内。

接入网设备211向应用服务器212发送业务报文的策略包括：将接入网设备211所接收的业务报文全部发送给应用服务器212；或利用识别信息标识业务报文是否可以发送给应用服务器212，且将可以发送给应用服务器212的业务报文发送给应用服务器212，将不可以发送给应用服务器212的业务报文发送给核心网220。其中，识别信息可以是现有业务报文所携带的一些标识信息，包括但不限于：用户文件标识(SubscriberProfileID，SPID)信息、业务质量等级标识(QoSclassidentifier，QCI)信息、简单报文解析(StatefulPacketInspection，SPI)信息、或深度报文解析(DeepPacketInspection，DPI)。其中对于识别信息与业务报文是否可以发送给应用服务器212的对应关系可以由运营商定义，本实施例不做任何限制。

以根据SPID将部分业务报文发送到应用服务器212上进行处理为例：其中SPID为运营商定义的用户标识，当前取值范围为1～256，具体含义可以由运营商进行定义(当前只定义了一些数值用于驻留优先级以及异频/异系统切换优先级)。运营商可以预定义一些SPID表征可以将此用户的哪些承载或者哪些类业务报文发送到应用服务器212上进行处理，从而接入网设备211在接收到业务报文后，便可以根据用户的SPID判断是否将所接收的业务报文发送给应用服务器212。

以根据QCI将部分业务报文发送到应用服务器212上进行处理为例：其中QCI包括9个等级，运营商可以预先定义这9个等级中哪个或哪几个等级的业务需要发送到应用服务器212上进行处理，从而接入网设备211在接收到业务报文后，便可以根据业务报文的QCI判断是否将所接收的业务报文发送给应用服务器212。

再以根据SPI或DPI将部分业务报文发送到应用服务器212上进行处理为例：运营商可以预定义一些业务报文转发到应用服务器212的规则，比如根据报文的5元组(源IP、目的IP、源端口、目的端口、协议类型)进行转发，从而接入网设备211在接收到业务报文后，便可以根据转发规格对业务报文进行判断是否将所接收的业务报文发送给应用服务器212。

请参考图4，其为本发明实施例所提供的一种应用服务器的结构示意图。如图所示，该应用服务器212同以上所述，支持至少一种业务运行，且位于接入网侧，可以独立于接入网设备，也可以设置于所述接入网设备之内。所述应用服务器212包括接口单元410、存储单元420和分别与接口单元410和存储单元420连接的处理单元430。其中接口单元410用于与接入网设备211进行通信；存储单元420用于存储应用服务器212所支持业务的业务数据；处理单元430用于通过接口单元410接收接入网设备211发送的业务报文，并处理所述业务报文。

需要说明的是，处理单元430可以是处理器，存储单元420可以是存储器。如果应用服务器212集成于所述接入网设备211，则其处理单元430的功能可以在接入网设备211的处理器340实现，即与接入网设备211共有处理器。

处理单元430对应业务报文的处理过程随其所接收的业务报文的变化而变化。包括但不限于以下情况：

在预设接入网设备211向应用服务器212发送业务报文的策略时，即根据应用服务器212当前可以支持的业务类型而制定，仅将应用服务器212所支持业务的业务报文发送给应用服务器212。如此应用服务器212无需对所接收的业务报文做出其是否支持的判断。那么，处理单元430处理所述业务报文的过程如图5所示，包括：

步骤S510：解析业务报文，此过程为剥离其它协议层信息，获得应用层数据的过程。

步骤S520：根据解析后的业务报文，运行所述业务报文对应的业务；

步骤S530：将运行结果反馈给接入网设备。

如果在预设接入网设备211向应用服务器212发送业务报文的策略时，不以应用服务器当前所支持的业务类型为依据，那么处理单元430处理所述业务报文的过程如图6所示，包括：

S610：解析业务报文，同步骤S510，在此不再详述；

S620：根据解析后的业务报文，判断所述处理单元是否支持所述业务报文对应的业务的运行。若支持，执行步骤S630；若不支持，执行步骤步骤S640、S650或S660。

即若解析结果显示所述处理单元支持所述业务报文对应的业务的运行，根据解析后的业务报文，运行所述业务报文对应的业务，将运行结果反馈给所述接入网设备(步骤S630)；若解析结果显示所述处理单元不支持所述业务报文对应的业务的运行，将所述业务报文回传给所述接入网设备(步骤S640)，以使得接入网设备按照传统的通道将业务报文发送出去；或向核心网发送所述业务报文(步骤S650)，此时需要应用服务器到核心网有直接的通道；或向所述接入网设备发送指示信令(步骤S660)，所述指示信令用于指示所述接入网设备向核心网发送所述业务报文。由于接入网设备之前已经接收到该业务报文，只要对该业务报文进行缓存，便可以根据该指示信息按照传统的通道将业务报文发送出去。在应用服务器无法提供服务时，提供以上步骤S640、S650或S660，可以保证按照传统的方式为UE提供服务，保证服务不间断。

另外，如果解析后的业务报文包括所述处理单元支持的业务的更新数据，将所述更新数据存储至存储单元。

考虑到业务报文的在接入网设备211与应用服务器212之间的传递，需要在接入网设备211与应用服务器212之间建立用户面通道。一种方式是：预先将用户面通道设置好，此时只需要定义用户面协议，以通过该用户面协议在预先设置好的用户面通道上传递业务报文。另一种方式是，配置好接入网设备211第三接口单元330的协议以及与之交互的应用服务器212的接口单元410的协议，从而通过配置好的协议，在需要时在接入网设备211与应用服务器212之间建立用户面通道，以通过用户面通道传送业务报文。

第三接口单元330的协议和接口单元410的协议均为应用与无线网络接口协议，以便通过该应用与无线网络接口协议，在接入网设备211与应用服务器212之间建立用户面通道。

请参考图7，其为应用与无线网络接口协议的结构示意图。如图所示，应用与无线网络接口协议包括控制面协议710和用户面协议720，所述用户面协议720用于用户面通道上的信息传输，控制面协议710用于用户面通道的建立，且用户面通道的建立包括：通过控制面协议，在接入网设备与应用服务器之间建立控制面链路；通过控制面链路承载的控制信息，在接入网设备与应用服务器之间建立用户面通道。

控制面协议710包括业务网络层协议和传输网络层协议，其业务网络层协议包括控制信息；其传输网络层协议包括物理层协议、数据链路层协议、网络层协议和传输层协议。所述用户面协议包括业务网络层协议和传输网络层协议，其中业务网络层协议同现有的用于UE与远端服务器之间业务报文传递的业务网络层协议，接入网对这部分协议不做处理，只进行透传，其为本领域技术人员所熟知，本实施例在此不再赘述；传输网络层协议用于实现业务报文的传递，其传输网络层协议同样包括物理层协议、数据链路层协议、网络层协议和传输层协议。

其中，控制面协议的传输网络层协议中，网络层协议可以是互联网协议(InternetProtocol，IP)；传输层协议可以是流控制传输协议(StreamControlTransmissionProtocol，SCTP)、传输控制协议(TransmissionControlProtocol，TCP)或用户数据报协议(UserDatagramProtocol，UDP)。用户面协议的传输网络层协议中，网络层协议可以是IP；传输层协议可以包括UDP和GPRS通道协议用户面部分(GPRSTunnelingProtocol-Userplane，GTP-U)，其中，GTP-U可以替换成UDP通道协议、IP通道协议、或数据链路层通道协议。此处仅为举例，并非用以限制本发明。

以上控制信息包括但不限于复位消息、开放API接口设置请求消息、基站配置更新消息等，其以长期演进(LongTermEvolution，LTE)接入技术为例，关于其它接入技术，例如通用移动通讯系统(UniversalMobileTelecommunicationsSystem，UMTS)等与之类似，在此不再赘述。

较佳的，控制信息包括状态信息订阅请求消息，所述状态信息订阅请求消息用于指示接入网设备向应用服务器发送无线网络的状态信息。如此，第三方应用便可以根据状态信息，灵活调整其对业务报文的处理。例如，若状态信息显示空口拥塞，而便可以将高清的视频资源调整为普通视频资源发送给UE。再如，当大部分业务报文所涉及的业务为点对点(P2P)通信，只有少数涉及视频业务，则可以调用更多无线资源保证视频质量。

较佳的，控制信息包括策略修改请求消息，所述策略修改请求消息用于指示接入网设备向应用服务器发送业务报文的策略。如此，运营商便可以根据第三方应用的需求灵活调整接入网设备向应用服务器发送业务报文的策略。

可见，接入网设备211的处理器340还用于通过第三接口单元330，在接入网设备211与应用服务器212之间建立用户面通道，应用服务器212的处理单元430还用于通过接口单元410在接入网设备211与应用服务器212之间建立用户面通道。

需要说明的是，由于业务报文可以来自UE，也可以来自核心网侧，因此可以在上、下行方向分别建立一个用户面通道。当然也可以建立一个独立的用户面通道，此时为了区分业务报文是UE侧的数据，还是核心网侧的数据，需要在业务报文中增加方向标识字段，以标识业务报文的源方向。

另外，考虑到应用服务器支持的业务通常不止一个，在只考虑一个方向(上行方向或下行方向)上的用户通道时，如果所有业务共享一个用户面通道，则需要在业务报文增加标识，用以标识转发目的地，即标识该业务报文需要提供给哪个业务运行；如果不增加字段，则需要应用服务器对业务报文进行识别分发。

以上为应用服务器的硬件结构介绍，下面结合附图介绍其软件结构。服务器的处理单元正是通过以下软件结构管理应用服务器其它单元，并实现整个应用服务器的功能。请参考图8，其为本发明实施例所提供的应用服务器的软件架构。如图所示，处理单元430为中央处理器(CentralProcessingUnit，CPU)，其上通过板级支持包(boardsupportpackage，BSP)运行操作系统(OperatingSystem，OS)。从而在OS所提供的平台上运行控制面处理程序、用户面处理程序、第三方应用程序，操作管理(OperationManager，OM)程序。其中：

控制面处理程序：用于处理应用服务器与接入网设备之间的控制面消息，主要存在三种基本类型的控制过程：基本管理过程，业务承载管理过程，开放信息获取过程。基本管理过程用于应用服务器与接入网设备间的控制面链路建立和维护；业务承载管理过程用于应用服务器与接入网设备间的用户面通道的建立和维护；开放信息获取过程用于应用服务器订阅无线网络的状态信息(包括接入网设备侧空口或接入网设备自身的状态信息)，以及这些状态信息从接入网设备的上报。

用户面处理程序：提供应用服务器到接入网设备间的用户面通道处理，用于业务报文在接入网设备和应用服务器间的交互。

第三方应用程序：根据具体的应用对用户的应用层数据进行终结或转发，或提供具体的业务。

OM程序：用于协调和管理用户面处理、控制面处理以及第三方应用，至少包括log/test/版本管理功能。

从以上描述可以看出，接入网设备除完成原有的功能外，需要增加的功能包括：

第一、向应用服务器发送业务报文处理：如果到每个第三方应用建立一个独立的用户面通道，则只将报文转发到对应的用户面通道上(如果上下行分别建立一个用户面通道，则每个通道表征一个方向，否则需要使用方向标识字段，标识是UE方向的数据还是核心网方向的数据)。如果第三方应用共享一个用户面通道，则需要给报文增加一个标识(用于标识发送的目的地)，然后进行发送；如果不增加标识，则需要在接收端对报文进行识别分发(如果上下行分别建一个通道，则每个通道表征一个方向，否则需要使用方向标识字段)；

第二、从应用服务器接收报文后的转发：如果每个第三方应用建立一个独立的用户面通道，则将报文根据方向发送到UE或者核心网即可(如果上下行分别建一个通道，则每个通道表征一个方向，否则需要使用方向标识字段)。如果第三方应用共享一个用户面通道，则需要根据策略进行报文转发，可选的策略包括但不限于：根据DPI进行转发；根据标识(用于标识发送目的地——具体的承载)进行识别转发(如果UE方向和核心网方向分别建一个通道，则每个通道表征一个方向，否则还需要使用方向标识字段。

第三、用户面通道的建立。

应用服务器的功能包括：

第一、解析接入网设备发送的业务报文。

第二、用户面通道的建立。

第三、第三方应用的执行。

第四、从接入网设备接收报文处理以及业务报文转发到具体的第三方应用：如果每个第三方应用建立一个独立的用户面通道，则只将对应通道上的报文转发到对应的第三方应用上(如果上下行分别建一个通道，则每个通道表征一个方向，否则需要使用方向标识字段)；如果第三方应用共享一个用户面通道，则需要根据一定策略进行报文转发，可选的策略包括但不限于：根据DPI进行转发；根据转发标识进行识别转发(如果上下行分别建一个通道，则每个通道表征一个方向，否则还需要使用方向标识字段)。

第五、向接入网设备发送报文处理，即第三方应用的用户面报文到用户面通道的转发：如果每个第三方应用建立一个独立的用户面通道，则只将报文转发到对应的通道上即可(如果上下行分别建一个通道，则每个通道表征一个方向，否则需要使用方向标识字段)；如果第三方应用共享一个用户面通道，则需要给报文增加一个标识(用于标识转发目的地)，然后进行转发(如果不增加标识，则需要在接收端对报文进行识别分发，如果上下行分别建一个通道则每个通道表征一个方向，否则需要使用方向标识字段)。

相应于以上接入网设备，本发明实施例还提供一种通信方法，如图9所示，包括如下步骤：

S910：接入网设备接收业务报文；

S920：接入网设备根据策略向应用服务器发送所接收的业务报文。

所述应用服务器同以上论述，设置于接入网侧，独立于接入网设备或设置于接入网设备之内，且支持至少一种业务运行。

可见，UE侧的业务报文可以经由接入网设备转发至应用服务器，而由应用服务器进行处理。如此，在接入网侧便可以完成对UE侧业务报文的响应，从而大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，使用户体验更佳。

同以上实施例，在步骤S910中，接入网设备接收的业务报文可以来自UE侧，也可以来自核心网侧。

同以上实施例，在步骤S920中，接入网设备向应用服务器发送业务报文的策略包括但不限于：将所述接入网设备所接收的业务报文全部发送给所述应用服务器；或利用识别信息标识所述业务报文是否可以发送给所述应用服务器，且将可以发送给所述应用服务器的业务报文发送给所述应用服务器，将不可以发送给所述应用服务器的业务报文发送给核心网。其中关于识别信息的设置同以上实施例，在此不再赘述。

相应于以上应用服务器，本发明实施例还提供另一种通信方法，如图10所示，包括如下步骤：

S101：应用服务器接收接入网设备发送的业务报文，其中，应用服务器设置于接入网侧，独立于接入网设备或设置于接入网设备之内，且该应用服务器支持至少一种业务运行；

S102：应用服务器处理所述业务报文。

可见，将支持业务运行的应用服务器设置于接入网侧，且从接入网设备接收并处理业务报文。如此，在接入网侧便可以完成对UE侧业务报文的响应，从而大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，使用户体验更佳。

以上步骤S102对应业务报文的处理过程随应用服务器所接收的业务报文的变化而变化。包括但不限于图5和图6所示过程。

另外，如果解析后的业务报文包括所述处理单元支持的业务的更新数据，将所述更新数据存储至存储单元。

在接入网设备向应用服务器发送业务报文以及应用服务器从接入网设备接收业务报文之前，需要在接入网设备和应用服务器之间建立用户面通道。关于用户面通道的建立方式同以上描述，在此不再赘述。

相应于以上通信系统，本发明实施例还提供一种通信方法，如图11所示，包括：

S111：接入网设备接收UE或核心网发送的业务报文。

S112：接入网设备根据策略向应用服务器发送所接收的业务报文。

在步骤S112之前，需要在接入网设备与应用服务器之间建立用户面通道。

如上所述，用户面通道可以是预先设置好的，接入网设备和应用服务器上电后，用户面通道即可以承载用户面信息。也可以通过接入网设备和应用服务器之间的接口协议，在接入网设备和应用服务器上电后或者接入网设备接收到需要转发给应用服务器的业务报文后，再建立用户面通道。

另外，建立用户面通道的数量可以是一个，也可以是多个。例如考虑到上、下行业务数据的传输，可以分别在上下行上各建立一个用户面通道；也可以只建立一个用户面通道，并在业务报文中增加方向标识字段。再如，考虑到应用服务器上运行第三方应用的数据，可以为每个第三方应用建立一个用户面通道；也只建立一个由所有第三方应用共用的用户面通道，此时需要接收端对接收到业务报文进行识别分发，或在业务报文中增加标识目的地的标识字段。

S113：应用服务器处理业务报文。

如果业务报文来自UE，通常其包括UE的业务请求，如果应用服务器具有UE所请求的业务资源，则应用服务器将业务资源发送给接入网设备(S114)。如果应用服务器没有UE所请求的业务资源，则应用服务器将业务报文回传给接入网设备，以使得接入网设备按照传统的通道将业务报文发送出去(S115)；或将业务报文直接发送给核心网，此时需要应用服务器到核心网有直接的通道(S116)；或向接入网设备发送指示信令(S117)，所述指示信令用于指示接入网设备向核心网发送业务报文，由于在步骤S111中，接入网设备已经接收到该业务报文，只要对该业务报文进行缓存，便可以根据该指示信息按照传统的通道将业务报文发送出去；以在应用服务器无法提供服务时，按照传统的方式为UE提供服务。

当接入网设备接收到UE所请求的业务资源时，向UE发送所述业务资源(S118)。当接入网设备接收到回传的业务报文或指示信令时，将业务报文继续发送到核心网(S119)。

需要说明的是，如果应用服务器支持UE所请求的业务，但是没有UE所请求的业务资源，由于业务请求可以继续通过核心网发往外网。进而通过外网获得所请求的业务资源。且当所请求的业务资源经过核心网发送到接入网设备时，接入网设备将其转发至应用服务器，则应用服务器在以上步骤S113中，存储该业务资源，以更新其内的业务资源。当然，这个更新也可以由外网定期或实时经核心网、接入网设备发送给应用服务器。

可见，当接入网设备接收到UE的业务请求时，其将业务请求发送给应用服务器；应用服务器如果具有UE所请求的业务资源，则可以直接为UE提供服务，极大的缩短了业务交互路径，且业务交互所涉及的网元也减少了，因此，业务时延得以降低，业务QoS得以提高，用户体验更佳。即使应用服务器不支持UE所请求的业务或者没有业务资源，也可以继续将业务请求通过核心网发送给远端服务器，从而不影响用户业务的使用。那么，从整个系统来看，通常每个接入网设备可以接入多个UE，且每个UE通常会有多种业务需求，因此，必然会有应用服务器可以提供支持的业务，从而从整体上减少业务时延，提高业务QoS。尤其是对于多个UE相同的业务请求，以上方法还可以节约回程(Backhaul)资源。例如，应用服务器支持Web类的Cache加速，对于热点视频、微博等，许多用户都有下载或访问需求，此时，由应用服务器直接提供此类服务，将极大节省Backhaul资源，且避免了因为资源不足导致部分用户无法访问，且降低了下载与访问时延，极大的提高了用户体验。

再如，在以上步骤S111中，接入网设备接收到的是UE的M2M握手请求，且其所请求的目的UE也接入该接入网设备。在传统流程中，该业务请求需经过核心网，由接入网设备反馈给目的UE。而利用本实施例所提供的方法，只要应用服务器支持M2M握手业务，则该业务请求无需再经过核心网，降低了业务时延，且节省了Backhaul资源。

下面以长期演进(LongTermEvolution，LTE)通信系统为例，说明以上实施例所提供的通信方法、接入网设备、应用服务器与通信系统的特征与优点，且其它通信系统(例如通用移动通讯系统(UniversalMobileTelecommunicationsSystem，UMTS)、全球移动通信系统(GlobalSystemforMobileCommunications，GSM))与之类似，以下实施例将不再赘述。

请参考图12，其为本发明实施例所提供的一种LTE通信系统的结构示意图。如图所示，接入网侧设置有eNB121和应用服务器122，其中应用服务器122用于运行第三方应用服务，eNB121需要将接收到的业务报文旁路到应用服务器122上进行处理。旁路的业务报文可以是从空口(UU)上来的业务报文(即UE发送的业务报文)，也可以是从S1-U接口上来的承载在GTP-U中的业务报文。核心网侧设置有业务网关(servinggateway，S-GW)123、分组数据网网关(PacketDataNetwork(PDN)gateway，P-GW)124和移动性管理实体(MobilityManagementEntity，MME)125。其中P-GW124用于不同网络间业务数据流的检测、策略执行和基于流的计费，是3GPP接入网络和非3GPP接入网络之间的用户面锚点，是核心网分组交换域与外部PDN连接的接口。同时可做为策略和计费执行功能(PolicyandChargingEnforcementFunction，PCEF)实体通过Gx接口与策略和计费规则功能(PolicyandChargingRulesFunction，PCRF)实体126相连。S-GW123用于建立eNB121与P-GW之间的用户面隧道。MME125的职责包括：终止非接入层信令(例如，移动性管理、会话管理等)、网关的选择、UE的认证等。

需要说明的是，对HNB/HeNB场景由于站点覆盖太小，为节约成本，应用服务器可以部署在HNB/HeNB网关(GW)；对UMTS、GSM，应用服务器可以部署在RNC/BSC中或附近；HNB/HeNBGW或RNC/BSC需要将接收的业务报文旁路到应用服务器上进行处理，旁路报文根据制式/接口模式的不同而不同，对UMTS为空口方向报文和Iu-PS口方向报文，GSM为空口方向报文和A/Iu-PS口方向报文。请参考图13，其为图12所示通信系统的用户面数据流示意图。其中，实线①表示应用服务器可以终结的用户面数据流，即如果能终结，则第三方应用可以直接生成下行报文利用已经建立的GTP-U。虚线②表示应用服务器无法终结的用户面数据流。在本发明实施例中，可以根据应用服务器所支持的第三方应用，优先选择实线①所示的用户面数据流，相对于传统仅存在虚线②所示的用户面数据流的情况，降低了业务时延，提高了业务QoS，从而使用户体验更佳。

请继续参考图14，为了方便eNB121与应用服务器122之间的报文传递，本实施例在上、下行方向上均建立用户面通道，分别承载空口方向的业务报文和S1方向的业务报文。且为了清楚起见，图14将eNB分开显示，但实际上图中两个eNB在物理上是一个实体。另外，空口方向和S1方向的通道可以相同，也可以不同，且用户面通道与S1通道不相同，需要eNB进行转换。

应用与无线网络接口协议同以上描述，在此给出其控制面协议中的控制信息的列表(如表1和表2，其中表1中的过程是需要应答的过程；表2的过程是无需应答的过程)。

表1

表2

需要说明的是，UMTS和GSM可以复用表中的消息类型，但名称和含义需要修改，比如eNB相关字样都要修改为具体的网元名称(例如，UMTS中的RNC)，其他含义上没有变化，只是具体信元的不同。

下面根据以上控制信息并结合图15，描述建立用户面通道的详细过程。如图15所示：

当eNB和应用服务器上电后，在eNB与应用服务器之间建立控制面链路。具体，eNB发起SCTP链路的建立过程，当SCTP链路建立成功后，发起开放应用程序编程接口(OpenAPIInterface)建立过程，当开放API接口建立成功后，控制面链路的建立完成。

在eNB与应用服务器之间建立用户面通道。当有UE的专用承载建立时，如果eNB收到MME发来的业务承载建立请求，eNB触发至应用服务器的业务承载建立过程，完成用户面通道的建立过程。其中，可以针对空口方向和S1方向建立两条用户面通道，也可以只建立一条用户面通道。如果只建立一条用户面通道，需要标识通道或业务报文是空口方向还是S1方向。无论此过程是否成功，S1隧道(即eNB与核心网之间的隧道)都会被建立。但是如果用户面通道建立不成功，则eNB将无法将业务报文转发到应用服务器。另外，业务承载建立过程是否成功，都需要向MME发送业务承载建立响应，以通知用户面通道是否建立。关于业务承载、会话管理和无线资源分配，为本领域技术人员所熟知，在此不再赘述。

如果eNB收到MME发来的承载更新请求，则eNB判断是否需要更新应用服务器的承载信息，如果需要，则发起承载更新，否则不发起。此过程未在图15中体现；

如果eNB自身或收到MME发起的消息触发承载释放，则需要通知应用服务器释放业务承载。而后，向MME发送业务承载释放响应，将业务承载释放的情况通知MME。

另外，如果应用服务器希望订阅eNB的状态信息，可以发起状态信息订阅过程；如果订阅成功，则eNB需要以周期或事件方式上报订阅的状态信息。

综上所述，本发明实施例在接入网侧引入可以支持第三方应用运行的应用服务器，如此，UE可以直接与接入网侧进行业务交互，大大提高了用户请求的响应时间，降低了业务时延，提高了业务QoS，从而使用户体验更佳。那么，在接入网侧增加营养服务器的可行性组网方案包括但不限于单站点的网络组网结构和云(Cloud)网络场景下的组网结构。具体描述如下：

单站点组网方案：在接入网侧直接增加独立于接入网设备的应用服务器。或应用服务器作为接入网设备的一个组成单元，例如，类似于基带板的形式直接嵌入到基带单元(BaseBandUnit，BBU)中；此时，应用服务器单元应符合单板设计标准，嵌入在BBU中，通过背板提供链接通道。

基于Cloud网络场景下的组网方案：在云基站(CloudBB)机柜中嵌入应用服务器作为CloudBB的一个标准单元，提供第三方应用业务。

目前，在现有技术中，为了缩短远端服务器至UE的距离，进而减少业务时延，提出了一种将网关下移的解决方案，例如下移到S-GW或接入网侧等，这种解决方案虽然可以解决业务时间较长业务QoS较低等问题，但却在移动性、合法监听、计费和节省带宽等方面无法做好权衡。尤其是对移动性的处理上，一旦UE移动，并从其它接入网设备接入时，网关后的第三方服务将无法感知到此变化，从而无法保证业务的连续性。

而本发明实施例结合具体的第三方应用便可以解决移动性以及合法监听、计费和节省带宽等方面的问题。举例如下：

移动性处理

本发明实施例所提供的架构下，eNB和应用服务器可以完成UE在移动过程中用户通道的建立和维护，在第三方业务的配合下，保证业务的连续性。举例说明如下：

比如对于Web类业务，应用服务器上部署此类业务的本地Cache，在核心网的SGi后之后部署此类业务的远端Cache以及业务连续性控制功能实体，在P-GW和S-GW之间部署业务终结功能实体；应用服务器上本地Cache中的内容在远端Cache中可以有也可以没有相应的副本，但远端业务连续性控制功能实体保存有所有本地Cache的索引，即远端Cache功能实体可以通过计算获知本地Cache是否命中。

应用服务器在收到HTTP请求时，无论本地是否命中都将此HTTP信令通过S1-U的隧道转发到核心网，远端业务连续性控制功能实体转发此请求到远端服务器，远端服务器收到请求后对UE进行数据发送，经过业务连续性控制功能实体时由此实体进行判决，如果Cache未命中，则进行缓存，并生成Cache指针(Index)，不管是否被命中，内容都将继续向UE转发，同时通过TCP扩展头定义私有的随路信息指示此内容是否被应用服务器上的Cache命中。当内容通过P-GW到达业务终结功能实体后，由此实体检查随路信息，如果指示内容被应用服务器命中，则将内容丢弃，否则继续向UE进行转发。如果内容继续经由S-GW和eNB转发到应用服务器后，原先未被本地Cache命中的内容将被缓存，并生成CacheIndex，如果已经Cache命中则替换原有内容(容错处理)。

本地应用服务器在转发HTTP请求时，会在承载应用报文的GTP-U报文中增加一个私有的扩展头，指示本地应用标识，如果内容被命中还要携带CacheIndex；此信息经过业务终结功能实体时可以转换由私有的TCP扩展头承载，当报文经过业务连续性控制功能实体时，它记录此请求对应的应用服务器以及CacheIndex等TCP扩展头中的信息。当UE从一个eNB移动到另一个eNB时，如果应用服务器发生变化，由于UE的请求信息都会通过应用服务器，且都会通过GTP-U的扩展头携带本地应用标识和CacheIndex，因此远端业务连续性控制功能实体知道应用服务器发生了变化，且知道新的应用服务器中内容是否被缓存在本地应用服务器，因此业务可以持续进行传送；从有应用服务器的区域移动到无应用服务器的区域或者反向移动时，由于UE的控制信息不在本地终结，因此远端业务连续性控制功能能感知到此变化，并能知晓是否需要进行内容转发，由此业务连续性也得以保证。

计费合法监听处理，有两种解决方案：

第一、在核心网部署应用服务器网关，完成与计费网关，合法监听网关的配合，对计费由应用服务器产生话单，并上报到应用服务器网关，由它汇总并上报到计费网关；对合法监听，启动后，由应用服务器复制报文，然后上报到应用服务器网关，由应用服务器网关汇总上报合法监听网关。

第二、对特定业务，诸如在移动性处理的描述中提到的业务，由于应用层的控制信息持续不断的发往应用服务器，且应用服务器的报文都要经过P-GW，因此计费和合法监听可以采用原有的3GPP的标准方案，有P-GW完成，对现有网元冲击很小。

本领域普通技术人员可以理解实现以上方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读介质中，所述可读介质，如：ROM/RAM、磁碟、光盘等。

例如，本发明实施例提供的一种计算机程序产品，包括计算机可读介质，该可读介质包括一组程序代码，用于执行以上实施例所描述的任一种通信方法。

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

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (29)

1.一种通信方法，由接入网侧的接入网设备执行，应用服务器设置于所述接入网侧，独立于所述接入网设备或设置于所述接入网设备之内，且所述应用服务器支持至少一种业务运行，该方法包括：

接收业务报文；

确定所述业务报文是否可以发送给应用服务器；

当所述业务报文可以发送给应用服务器时，将所述业务报文发送给所述应用服务器；

当所述业务报文不可以发送给应用服务器时，将所述业务报文发送给核心网。

2.根据权利要求1所述的方法，其特征在于，确定所述业务报文是否可以发送给应用服务器，包括：

确定所述业务报文的业务类型是否为所述应用服务器支持的业务类型，其中，所述应用服务器支持的业务类型的业务报文可以发送给应用服务器。

3.根据权利要求1所述的方法，其特征在于，所述业务报文包括标识信息，用于标识所述业务报文是否可以发送给所述应用服务器。

4.根据权利要求3所述的方法，其特征在于，所述标识信息包括：用户文件标识SPID信息、业务质量等级标识QCI信息、简单报文解析SPI信息、或深度报文解析DPI信息。

5.根据权利要求1所述的方法，还包括：

在所述接入网设备与所述应用服务器之间建立用户面通道，以通过所述用户面通道发送所述业务报文。

6.根据权利要求5所述的方法，通过应用与无线网络接口协议，建立所述用户面通道，其中所述应用与无线网络接口协议包括控制面协议和用户面协议，所述用户面协议用于所述用户面通道上的信息传输，所述控制面协议用于所述用户面通道的建立，且所述用户面通道的建立包括：

通过所述控制面协议，在所述接入网设备与所述应用服务器之间建立控制面链路；

通过所述控制面链路承载的控制信息，在所述接入网设备与所述应用服务器之间建立所述用户面通道。

7.根据权利要求6所述的方法，其特征在于，所述控制信息包括状态信息订阅请求消息，所述状态信息订阅请求消息用于指示所述接入网设备向所述应用服务器发送无线网络的状态信息；和/或

所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

8.一种通信方法，由应用服务器执行，该应用服务器支持至少一种业务运行，且设置于所述接入网侧，独立于所述接入网侧的接入网设备或设置于所述接入网设备之内，该方法包括：

当所述接入网设备接收到的业务报文可以发送给所述应用服务器时，所述应用服务器接收所述接入网设备发送的业务报文；

所述应用服务器处理所述业务报文。

9.根据权利要求8所述的方法，其特征在于，当所述业务报文的业务类型为所述应用服务器支持的业务类型时，所述业务报文可以发送给应用服务器。

10.根据权利要求8所述的方法，还包括：

在所述接入网设备与所述应用服务器之间建立用户面通道，以通过所述用户面通道接收所述业务报文。

11.根据权利要求10所述的方法，通过应用与无线网络接口协议，建立所述用户面通道，其中所述应用与无线网络接口协议包括控制面协议和用户面协议，所述用户面协议用于所述用户面通道上的信息传输，所述控制面协议用于所述用户面通道的建立，且所述用户面通道的建立包括：

通过所述控制面协议，在所述接入网设备与所述应用服务器之间建立控制面链路；

通过所述控制面链路承载的控制信息，在所述接入网设备与所述应用服务器之间建立所述用户面通道。

12.根据权利要求11所述的方法，其特征在于，所述控制信息包括状态信息订阅请求消息，所述状态信息订阅请求消息用于指示所述接入网设备向所述应用服务器发送无线网络的状态信息；和/或

所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

13.根据权利要求8至12任一项所述的方法，所述处理所述业务报文，包括：

解析所述业务报文；

根据解析后的业务报文，运行所述业务报文对应的业务；

将运行结果反馈给所述接入网设备。

14.根据权利要求8至12任一项所述的方法，所述处理所述业务报文，包括：

解析所述业务报文；

当解析结果显示所述业务报文包括所述应用服务器支持的业务的更新数据，存储所述更新数据。

15.一种接入网设备，包括：

用于与用户设备进行通信的第一接口单元；

用于与核心网进行通信的第二接口单元；

用于与应用服务器进行通信的第三接口单元，其中所述应用服务器设置于接入网侧，且独立于所述接入网设备或设置于所述接入网设备之内，所述应用服务器支持至少一种业务运行；

处理器，分别与所述第一接口单元、第二接口单元和第三接口单元连接，且所述处理器用于：

通过所述第一接口单元接收业务报文；

确定所述业务报文是否可以发送给应用服务器；

当所述业务报文可以发送给应用服务器时，通过所述第三接口单元将所述业务报文发送给所述应用服务器；

当所述业务报文不可以发送给应用服务器时，通过所述第二接口单元将所述业务报文发送给核心网。

16.根据权利要求15所述的设备，其特征在于，所述处理器用于执行以下操作以确定所述业务报文是否可以发送给应用服务器：

确定所述业务报文的业务类型是否为所述应用服务器支持的业务类型，其中，所述应用服务器支持的业务类型的业务报文可以发送给应用服务器。

17.根据权利要求16所述的设备，其特征在于，所述业务报文包括标识信息，用于标识所述业务报文是否可以发送给所述应用服务器。

18.根据权利要求17所述的方法，其特征在于，所述标识信息包括：用户文件标识SPID信息、业务质量等级标识QCI信息、简单报文解析SPI信息、或深度报文解析DPI信息。

19.根据权利要求15所述的接入网设备，所述处理器还用于通过所述第三接口单元在所述接入网设备与所述应用服务器之间建立用户面通道，以通过所述用户面通道发送所述业务报文。

20.根据权利要求19所述的接入网设备，所述第三接口单元协议为应用与无线网络接口协议，所述处理器通过所述应用与无线网络接口协议，建立所述用户面通道，其中所述应用与无线网络接口协议包括控制面协议和用户面协议，所述用户面协议用于所述用户面通道上的信息传输，所述控制面协议用于所述用户面通道的建立，且所述用户面通道的建立包括：

通过所述控制面协议，在所述接入网设备与所述应用服务器之间建立控制面链路；

通过所述控制面链路承载的控制信息，在所述接入网设备与所述应用服务器之间建立所述用户面通道。

21.根据权利要求20所述的接入网设备，其特征在于，所述控制信息包括状态信息订阅请求消息，所述状态信息订阅请求消息用于指示所述接入网设备向所述应用服务器发送无线网络的状态信息；和/或

所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

22.一种应用服务器，支持至少一种业务运行，所述应用服务器位于接入网侧，且独立于接入网设备或设置于所述接入网设备之内，所述应用服务器包括：

用于与接入网设备进行通信的接口单元；

存储单元，用于存储所述应用服务器所支持业务的业务数据；

处理单元，分别与所述接口单元和所述存储单元连接，所述处理单元用于当所述接入网设备接收到的业务报文可以发送给所述应用服务器时通过所述接口单元接收所述接入网设备发送的业务报文，并处理所述业务报文。

23.根据权利要求22所述的应用服务器，其特征在于，当所述业务报文的业务类型为所述应用服务器支持的业务类型时，所述业务报文可以发送给应用服务器。

24.根据权利要求22所述的应用服务器，所述处理单元还用于通过所述接口单元在所述接入网设备与所述应用服务器之间建立用户面通道，以通过所述用户面通道接收所述业务报文。

25.根据权利要求24所述的应用服务器，所述接口单元协议为应用与无线网络接口协议，所述处理单元通过所述应用与无线网络接口协议，建立所述用户面通道，其中所述应用与无线网络接口协议包括控制面协议和用户面协议，所述用户面协议用于所述用户面通道上的信息传输，所述控制面协议用于所述用户面通道的建立，且所述用户面通道的建立包括：

通过所述控制面协议，在所述接入网设备与所述应用服务器之间建立控制面链路；

通过所述控制面链路承载的控制信息，在所述接入网设备与所述应用服务器之间建立所述用户面通道。

26.根据权利要求25所述的应用服务器，其特征在于，所述控制信息包括状态信息订阅请求消息，所述状态信息订阅请求消息用于指示所述接入网设备向所述应用服务器发送无线网络的状态信息；和/或

所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

27.根据权利要求22至26任一项所述的应用服务器，所述处理单元处理所述业务报文，包括：

解析所述业务报文；

根据解析后的业务报文，运行所述业务报文对应的业务；

将运行结果反馈给所述接入网设备。

28.根据权利要求22至26任一项所述的应用服务器，所述处理单元处理所述业务报文，包括：

解析所述业务报文；

当解析结果显示所述业务报文包括所述处理单元支持的业务的更新数据，将所述更新数据存储至存储单元。

29.一种通信系统，其接入网侧设置有如权利要求17至23任一项所述的接入网设备与如权利要求24至32任一项所述的应用服务器。