WO2013152472A1

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

Info

Publication number: WO2013152472A1
Application number: PCT/CN2012/073666
Authority: WO
Inventors: 吕欣岩; 邢峰
Original assignee: 华为技术有限公司
Priority date: 2012-04-09
Filing date: 2012-04-09
Publication date: 2013-10-17
Also published as: EP2717538A4; US20170094557A1; KR20140023435A; JP2014531838A; KR101521954B1; EP2717538B1; US9532238B2; EP2717538A1; CN103548314A; CN103548314B; US20130265917A1; JP5873179B2; US9860787B2

Abstract

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

Description

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

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

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

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

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

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

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

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

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

另一方面，本发明实施例提供一种计算机可读存储介质，包括：用于执行如权利要求 1~7任一项所述的方法的程序。

另一方面，本发明实施例提供一种计算机可读存储介质，包括：用于执行如权利要求 8~16任一项所述的方法的程序。

可见，本发明实施例在接入网侧引入可以支持第三方应用运行的应用服务器，如此， 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接入到无线网络的设备, 包括但不限于：基站（Node B )、演进型基站（evolved Node B , eNB )、家庭基站（ Home Node B , HNB ) I ( Home eNode B , HeNB )、无线网络控制器 ( radio network controller, RNC )、基站控制器 ( Base Station Controller, BSC ), 基站发台（Base Transceiver Station, 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。其中，识别信息可以是现有业务报文所携带的一些标识信息，包括但不限于：用户文件标识（ Subscriber Profile ID , SPID ) 信息、业务质量等级标识（QoS class identifier, QCI )信息、筒单报文解析 ( Stateful Packet Inspection , SPI )信息、或深度报文解析（Deep Packet Inspection, 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的规则，比如根据4艮文的 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与远端服务器之间业务报文传递的业务网络层协议，接入网对这部分协议不做处理，只进行透传，其为本领域技术人员所熟知，本实施例在此不再赘述；传输网络层协议用于实现业务报文的传递，其传输网络层协议同样包括物理层协议、数据链路层协议、网络层协议和传输层协议。

其中，控制面协议的传输网络层协议中，网络层协议可以是互联网协议（ Internet Protocol, IP );传输层协议可以是流控制传输协议（ Stream Control Transmission Protocol, SCTP )、传输控制十办议 ( Transmission Control Protocol, TCP )或用户数据报协议（User Datagram Protocol, UDP )。用户面协议的传输网络层协议中，网络层协议可以是 IP; 传输层协议可以包括 UDP和 GPRS通道协议用户面部分（ GPRS Tunneling Protocol-User plane, GTP-U ), 其中， GTP-U可以替换成 UDP通道协议、 IP通道协议、或数据链路层通道协议。此处仅为举例，并非用以限制本发明。

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

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

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

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

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

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

以上为应用服务器的硬件结构介绍，下面结合附图介绍其软件结构。现整个应用服务器的功能。请参考图 8, 其为本发明实施例所提供的应用服务器的软件架构。如图所示，处理单元 430为中央处理器（ Central Processing Unit, CPU ), 其上通过板级支持包（board support package, BSP )运行操作系统（ Operating System, OS )。从而在 OS所提供的平台上运行控制面处理程序、用户面处理程序、第三方应用程序，操作管理（Operation Manager, 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或核心网发送的业务报文。

S 112: 接入网设备根据策略向应用服务器发送所接收的业务报文。在步骤 S 112之前，需要在接入网设备与应用服务器之间建立用户面通道。

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

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

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资源。

下面以长期演进 ( Long Term Evolution , LTE )通信系统为例，说明以上实施例所提供的通信方法、接入网设备、应用服务器与通信系统的特征与优点，且其它通信系统（例如通用移动通讯系统（ Universal Mobile Telecommunications System, UMTS )、全球移动通信系统（ Global System for Mobile Communications, GSM ) )与之类似，以下实施例将不再赞述。

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

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

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

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

表 2

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

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

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

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

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

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

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

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

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

目前，在现有技术中，为了缩短远端服务器至 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命中的内容将被緩存，并生成 Cache Index, 如果已经 Cache命中则替换原有内容（容错处理）。

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

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

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

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

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

例如，本发明实施例提供的一种计算机程序产品，包括计算机可读介质，该可读介质包括一组程序代码，用于执行以上实施例所描述的任一种通信方法。本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的单元或流程并不一定是实施本发明所必须的。

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

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

Claims

权利要求

1、一种通信方法，包括：

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

所述接入网设备根据策略向应用服务器发送所接收的业务报文，所述应用服务器设置于接入网侧，独立于所述接入网设备或设置于所述接入网设备之内，且所述应用服务器支持至少一种业务运行。

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

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

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

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

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

4、根据权利要求 3所述的方法，所述控制面协议包括业务网络层协议和传输网络层协议，所述业务网络层协议包括所述控制信息；所述传输网络层协议包括物理层协议、数据链路层协议、网络层协议和传输层协议。

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

6、根据权利要求 4或 5所述的方法，其特征在于，所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

7、据权利要求 1所述的方法，所述策略包括：

将所述接入网设备所接收的业务报文全部发送给所述应用服务器；或利用识别信息标识所述业务报文是否可以发送给所述应用服务器，且将可以发送给所述应用服务器的业务报文发送给所述应用服务器，将不可以发送给所述应用服务器的业务报文发送给核心网。

8、一种通信方法，包括：

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

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

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

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

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

11、根据权利要求 10所述的方法，所述控制面协议包括业务网络层协议和传输网络层协议，所述业务网络层协议包括所述控制信息；所述传输网络层协议包括物理层协议、数据链路层协议、网络层协议和传输层协议。

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

13、根据权利要求 11或 12所述的方法，其特征在于，所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

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

所述应用服务器解析所述业务报文；

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

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

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

所述应用服务器解析所述业务报文；

若解析结果显示所述应用服务器支持所述业务报文对应的业务的运行，根据解析后的业务报文，运行所述业务报文对应的业务，将运行结果反馈给所述接入网设备；

若解析结果显示所述应用服务器不支持所述业务报文对应的业务的运行，将所述业务报文回传给所述接入网设备，或向核心网发送所述业务报文，或向所述接入网设备发送指示信令，所述指示信令用于指示所述接入网设备向核心网发送所述业务报文。

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

所述应用服务器解析所述业务报文；

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

17、一种接入网设备，包括：

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

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

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

处理器，分别与所述第一接口单元、第二接口单元和第三接口单元连接，且所述处理器用于通过所述第一接口单元或第二接口单元接收业务报文，且通过第三接口单元，根据策略向所述应用服务器发送所接收的业务报文。

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

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

20、根据权利要求 19所述的接入网设备，所述控制面协议包括业务网络层协议和传输网络层协议，所述业务网络层协议包括所述控制信息；所述传输网络层协议包括物理层协议、数据链路层协议、网络层协议和传输层协议。

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

22、根据权利要求 20或 21所述的接入网设备，其特征在于，所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

23、据权利要求 17所述的接入网设备，所述策略包括：

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

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

存储单元，用于存储所述应用服务器所支持业务的业务数据；处理单元，分别与所述接口单元和所述存储单元连接，所述处理单元用于通过所述接口单元接收所述接入网设备发送的业务报文，并处理所述业务报文。

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

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

27、根据权利要求 26所述的应用服务器，所述控制面协议包括业务网络层协议和传输网络层协议，所述业务网络层协议包括所述控制信息；所述传输网络层协议包括物理层协议、数据链路层协议、网络层协议和传输层协议。

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

29、根据权利要求 27或 28所述的应用服务器，其特征在于，所述控制信息包括策略修改请求消息，所述策略修改请求消息用于指示所述接入网设备向所述应用服务器发送业务报文的策略。

30、根据权利要求 24至 29任一项所述的应用服务器，所述处理单元处理所述业务文，包括：

解析所述业务报文；

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

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

31、根据权利要求 24至 29任一项所述的应用服务器，所述处理单元处理所述业务文，包括：

解析所述业务报文；若解析结果显示所述处理单元支持所述业务报文对应的业务的运行，根据解析后的业务报文，运行所述业务报文对应的业务，将运行结果反馈给所述接入网设备；

若解析结果显示所述处理单元不支持所述业务报文对应的业务的运行，将所述业务报文回传给所述接入网设备，或向核心网发送所述业务报文，或向所述接入网设备发送指示信令，所述指示信令用于指示所述接入网设备向核心网发送所述业务报文。

32、根据权利要求 24至 29任一项所述的应用服务器，所述处理单元处理所述业务文，包括：

解析所述业务报文；

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

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

34、一种计算机可读存储介质，包括：用于执行如权利要求 1~7任一项所述的方法的程序。

35、一种计算机可读存储介质，包括：用于执行如权利要求 8~16任一项所述的方法的程序。