CN102437964A - 业务下发方法、装置及通信系统 - Google Patents

Abstract

本发明涉及通信技术领域，公开了业务下发方法、装置及通信系统，其中业务下发方法包括：接收边缘网络节点上报的用户设备的地址与所述边缘网络节点的地址的绑定关系，接收来自CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，根据所述绑定关系将所述边缘网络节点的地址发送给所述CDN节点，以使CDN节点根据所述边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向用户设备发送重定位请求，该重定位请求包括边缘网络节点对应的CDN缓存的地址，以使用户设备从所述边缘网络节点对应的CDN缓存获取业务。使用本发明，可以由用户设备所在的本地侧缓存对用户设备进行业务下发。

Description

业务下发方法、装置及通信系统

本申请是基于申请日为2010年11月17日、申请号为201010547950.8以及发明名称为业务下发方法、装置及通信系统的专利申请的分案申请。

技术领域

本发明涉及通信技术领域，具体涉及业务下发方法、装置及通信系统。

背景技术

Web缓存位于Web服务器和UE之间，Web缓存会根据进来的请求保存输出内容的副本，例如html页面，图片，文件等，然后，当下一个请求来到的时候：如果是相同的URL，Web缓存直接使用副本响应访问请求，而不是向Web服务器再次发送请求。

超文本传输协议(HTTP：hypertext transfer protocol)是Web协议簇中的重要协议，是从客户机/服务器模型发展起来的。客户机与服务器连接时，首先向服务器提出请求，服务器根据客户的请求，完成处理并给出响应。HTTP早期版本的一个重要特点是限制每次连接只处理1个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。其过程也就是：建立连接，发出1个请求信息，发出1个响应信息，关闭连接。HTTP/1.1于1999年6月作为RFC出现，改变了早期版本的基本模式，不再是每次连接只处理1个请求了，而是使用持久连接。即：一旦客户打开了和特定服务器的连接，客户就让该连接在多个请求和响应的过程中一直存在。当客户或服务器准备关闭连接时，则通知另一端，然后关闭该连接。这个过程是：建立连接，发出n个请求信息，发出n个响应信息，关闭连接；其中，还使用了流水线技术，也就是在逐个地发送n个请求信息时，不必等待响应。

内容分发网络(CDN：Content Delivery Network)的目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户设备的网络″边缘″，使用户设备可以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户设备访问网站的响应速度。CDN采用重定向方式实现业务缓存和响应，基于用户设备的网络地址找到用户设备所在的本地Cache位置。

CDN中的HTTP重定向方案，是通过全局负载均衡交换机的HTTP重定向技术，将用户设备的访问请求重定向到最优的服务器。该技术方案需做的先期工作是在DNS服务器中将网站对应的域名解析记录指向到全局负载均衡交换机的IP地址。用户设备访问的基本流程如下：

(l)当有客户机访问加入CDN服务的网站的内容时，所有访问请求都被发送到全局负载均衡交换机上。

(2)全局负载均衡交换机与分布在CDN各节点的本地负载均衡设备通信，根据一定策略选出一个最佳CDN节点。

(3)全局负载均衡交换机向客户机发回一个HTTP重定向指令(HTTP302)，同时将重定向主机(选出的最佳CDN节点)的IP地址发送给用户设备。

(4)客户机收到重定向指令后，与选定的最佳CDN节点建立连接，请求响应网站的内容。

(5)该最佳CDN节点中的服务器响应客户机的请求，为客户机提供所需的内容。

现有的CDN网络采用重定向方式实现业务缓存和响应，主要是基于用户设备IP地址找到用户设备所在的本地侧边缘Cache节点位置，核心节点将用户设备请求重定向到用户设备所在的本地侧Cache节点，但是在移动网络中，移动网络的用户设备的网络地址与用户设备的物理位置是不一致的，表现在RAN侧Cache需要耦合RAN网络，提供RAN网络覆盖用户的业务，但CDN网络核心节点不知道用户设备所在RAN网络的信息，因此很难将用户设备重定向到本地RAN侧的Cache节点，导致重定向后的Cache节点并不是用户设备所在的本地侧Cache节点。

发明内容

本发明实施例提供了业务下发方法、装置及通信系统，可以由用户设备所在的本地侧缓存对用户设备进行业务下发。

本发明实施例提供了一种业务下发方法，包括：

接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从所述业务请求中解析得到；

如果所述报文请求所请求的业务保存在本地缓存，向所述UE发送第一报文响应，所述第一报文响应包括所述报文请求所请求的业务。

本发明实施例还提供了一种业务下发方法，包括：

接收边缘网络节点上报的用户设备的地址与所述边缘网络节点的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；

接收来自CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由业务平台接收到业务请求后发送；

根据所述绑定关系将所述边缘网络节点的地址发送给所述CDN节点，以使所述CDN节点根据所述边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

本发明实施例还提供了一种业务下发方法，包括：

接收边缘网络节点上报的用户设备的地址与所述边缘网络节点对应的CDN缓存的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；

接收CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

根据所述绑定关系将所述边缘网络节点对应的CDN缓存的地址发送给所述CDN节点，以使所述CDN节点向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

本发明实施例还提供了一种业务下发装置，包括：

接收单元，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从所述业务请求中解析得到；

判断单元，用于判断所述接收单元接收的报文请求所请求的业务保存在本地缓存；

发送单元，用于在所述判断单元判断所述报文请求所请求的业务保存在本地缓存时，向所述UE发送第一报文响应，所述第一报文响应包括所述报文请求所请求的业务。

本发明实施例还提供了一种业务下发装置，包括：

接收单元，用于接收边缘网络节点上报的用户设备的地址与所述边缘网络节点的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；接收来自CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

发送单元，用于根据所述绑定关系将所述边缘网络节点的地址发送给所述CDN节点，以使所述CDN节点根据所述边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

接收单元，用于接收边缘网络节点上报的用户设备的地址与所述边缘网络节点对应的CDN缓存的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；接收CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

本发明实施例还提供了一种业务下发装置，包括：

发送单元，用于根据所述绑定关系将所述边缘网络节点对应的CDN缓存的地址发送给所述CDN节点，以使所述CDN节点向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

本发明实施例还提供了一种通信系统，包括本发明实施例提供的业务下发装置。

从本发明实施例提供的以上技术方案可以看出，由于本发明实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。

附图说明

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

图1为本发明一个实施例提供的业务下发方法的流程图；

图2为本发明另一个实施例提供的业务下发方法的信令流程图；

图3为本发明另一个实施例提供的业务下发方法的信令流程图；

图4为本发明另一个实施例提供的业务下发方法的信令流程图；

图5为本发明另一个实施例提供的业务下发方法的流程图；

图6为本发明另一个实施例提供的业务下发方法的信令流程图；

图7为本发明一个实施例提供的业务下发装置的结构图；

图8为本发明另一个实施例提供的业务下发装置的结构图；

图9为本发明另一个实施例提供的业务下发装置的结构图；

图10为本发明另一个实施例提供的业务下发装置的结构图；

图11为本发明另一个实施例提供的业务下发装置的结构图；

图12为本发明另一个实施例提供的业务下发装置的结构图。

具体实施方式

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

本发明实施例提供的方法和装置可以应用于所有的移动通信系统，如通用移动通信系统(UMTS：Universal Mobile Telecommunications System)、长期演进(LTE：Long Term Evolution)移动通信系统、全球移动通讯系统(GSM：Global System for Mobile Communications)、全球微波互联接入(WiMAX：Worldwide Interoperability for Microwave Access)移动通信系统、码分多址(CDMA2000：Code Division Multiple Access 2000)移动通信系统等，也可以应用于非移动通信系统。本发明实施例在网络侧构建缓存，可以是一级或二级以上，例如可以在基站、和/或基站控制器、和/或网关构建缓存，每个缓存都设置有对应的内容分析单元。如果在网络侧构建一级缓存，该一级缓存可以是基站缓存、或基站控制器缓存、或网关缓存。如果在网络侧构建二级缓存，该二级缓存可以是基站缓存和基站控制器缓存、或基站缓存和网关缓存、或基站控制器缓存和网关缓存。其中，基站缓存在不同的移动通信系统中的名称可能不同，例如在UMTS系统中可以称为基站缓存(NodeB Cache)，在LTE系统中可以称为演进基站缓存(eNodeB Cache)；同样，网关缓存在不同的网络系统中的名称也可能不同，例如在UMTS系统中可以称为网关通用分组无线服务支持节点缓存(GGSN Cache)，在LTE系统中可以称为分组数据网关(PGW Cache)等。

先介绍本发明实施例提供的业务下发方法，图1描述了本发明一个实施例提供的业务下发方法的流程，该实施例描述的是缓存的处理流程，该实施例包括：

101、接收报文请求，该报文请求由内容分析单元接收到UE发送的业务请求后，根据缓存策略从报文请求中解析得到。

接收的报文请求可以由缓存对应的内容分析单元发送，该内容分析单元即为从业务请求中解析的到报文请求的内容分析单元，该内容分析单元可以是与基站对应的内容分析单元、或与基站控制器对应的内容分析单元、或与网关对应的内容分析单元。

接收的报文请求也可以由缓存对应的下一级缓存发送；例如，在该缓存为基站控制器缓存时，基站控制器缓存的下一级缓存为基站缓存；在该缓存为网关缓存时，网关缓存的下一级缓存可以是基站控制器缓存或基站缓存。

其中，报文请求可以是请求HTTP业务的HTTP报文请求，也可以是请求非HTTP业务的非HTTP报文请求。

102、判断报文请求所请求的业务是否保存在本地缓存；如果是，进入103；如果否，进入104。

103、向UE发送第一报文响应，该第一报文响应包括报文请求所请求的业务。结束流程。

其中，如果接收的报文请求由内容分析单元发送，则可以直接向UE发送第一报文响应；如果接收的报文请求由下一级缓存发送，则通过该下一级缓存向UE发送第一报文响应，即先将第一报文响应发送给该下一级缓存，再由该下一级缓存将第一报文响应发送给UE。

104、建立与上一级缓存的第一连接。

具体地，建立的连接可以是传输控制协议(TCP：Transmission ControlProtocol)连接，用户数据包协议(UDP：User Datagram Protocol)连接等。

例如，在缓存是基站缓存时，对应的上一级缓存可以是基站控制器缓存或网关缓存；在缓存时基站控制器缓存时，对应的上一级缓存可以是网关缓存。

在本发明的另一个实施例中，缓存没有对应的上一级缓存，则此时缓存可以建立与业务提供商的第二连接，此时缓存可以是基站缓存、或基站控制器缓存、或网关缓存。

105、通过第一连接向上一级缓存转发报文请求。

具体地，在向上一级缓存转发报文请求时，将源地址修改为缓存的地址，从而使该缓存可以接收到相应的报文响应；同时，将目的地址修改为上一级缓存的地址，使上一级缓存可以处理该报文请求，而不是丢弃该报文请求。

在本发明的另一个实施例中，由于缓存没有对应的上一级缓存，则可以通过第二连接向业务提供商转发报文请求。

106、接收上一级缓存通过第一连接返回的第二报文响应，该第二报文响应包括报文请求所请求的业务，向UE转发第二报文响应。

在本发明的另一个实施例中，是通过第二连接向业务提供商转发报文请求，则缓存接收到的可以是业务提供商通过第二连接返回的第三报文响应，该第三报文响应包括报文请求所请求的业务，此时缓存可以向UE转发第三报文响应。

在本发明的另一个实施例中，缓存是最顶级的缓存，如果报文请求所请求的业务保存在本地缓存，则可以进一步根据报文请求进行热度分析，如果热度分析的结果达到保存条件，该最顶级的缓存可以将报文请求所请求的业务发送给下级缓存，以使下级缓存保存报文请求所请求的业务。

在本发明的另一个实施例中，缓存是最顶级的缓存，如果报文请求所请求的业务没有保存在本地缓存，则在从服务提供商获得了报文请求所请求的业务后，可以根据报文请求进行热度分析，如果热度分析的结果达到保存条件，该最顶级的缓存可以将报文请求所请求的业务保存在本地缓存；进一步的，在本发明的另一个实施例中，该最顶级的缓存还可以将报文请求所请求的业务发送给下级缓存，以使下级缓存保存报文请求所请求的业务。

其中，最顶级的缓存时相对而言的，例如在网络侧设置了网关缓存、以及基站缓存和/或基站控制缓存时，最顶级的缓存时网关缓存，下级缓存是基站缓存和/或基站控制器缓存。在网络侧设置了基站控制器缓存和基站缓存时，最顶级的缓存是基站控制器缓存，下级缓存是基站缓存。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，在本发明的一个实施例中，如果本地没有保存报文请求所请求的业务，缓存可以向上一级缓存或SP请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。进一步，在本发明的一个实施例中，最顶级缓存可以将用户设备请求较多的(热度较高)业务发送到下级缓存，使下级缓存就可以在用户设备请求该业务时直接下发给用户设备，提高用户设备获取业务的速度。

如下介绍本发明实施例提供的业务下发方法在不同的网络系统中的应用，先介绍本发明实施例在UMTS中的应用。

本发明一个实施例在UMTS构建三级缓存，分别是设置在NodeB节点的NodeB Cache，以及设置在基站控制器(RNC)节点的RNC Cache，以及设置在GGSN的GGSN Cache；每一级缓存都有其对应的内容分析单元。其中，NodeB Cache进行业务缓存，以及响应基站下用户设备在本地缓存的业务请求。RNC Cache实现不是由NodeB进行响应，在RNC Cache有缓存的用户业务请求。GGSN Cache实现不是由RAN侧(包括NodeB和RNC)响应，在GGSN Cache有缓存的用户业务请求，直接返回用户请求的业务，对于在GGSN Cache没有存储的业务，GGSN可以代理用户设备向业务提供商(SP)请求业务。同时，所有用户设备发起的业务请求，都在GGSN Cache进行业务热度统计，并根据业务热度，确定NodeB Cache，RNC Cache中需要保存的业务。

图2描述了本发明一个实施例提供的业务下发方法的信令流程，该实施例中UMTS设置有NodeB缓存、RNC缓存和GGSN缓存，该实施例描述的是UMTS中网元的处理流程，该实施例包括：

201、用户设备向NodeB发起业务请求，业务请求可以请求HTTP业务和/或非HTTP业务，本实施例用业务请求所请求的业务是HTTP业务进行描述。

202、NodeB把用户设备的业务请求转发给NodeB内容分析单元。

203、NodeB内容分析单元进行本地Cache策略管理，根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到NodeB缓存。

本实施例中假设本地Cache策略是“解析80端口的HTTP报文请求。

其中NodeB内容分析单元的功能实现可以使用深度包解析(DPI)等方式。

其中，在本发明的一个实施例中，NodeB内容分析单元可以进一步将解析得到的HTTP报文请求发送到GGSN缓存，使GGSN缓存可以根据该HTTP报文请求进行热度分析。

204、NodeB缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入205；如果没有保存在本地缓存，进入206。

205、NodeB缓存向用户设备发送第一报文响应，第一报文响应包括HTTP报文请求所请求的业务。结束流程。

206、NodeB缓存建立到RNC缓存的第一连接，通过第一连接向RNC缓存转发HTTP报文请求。

207、NodeB缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入208；如果没有保存在本地缓存，进入210。

208、RNC缓存向NodeB缓存发送第二报文响应，第二报文响应包括HTTP报文请求所请求的业务。

209、NodeB缓存向用户设备转发第二报文响应。结束流程。

210、RNC缓存建立到GGSN缓存的第二连接，通过第二连接向GGSN缓存转发HTTP报文请求。

211、GGSN缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入212；如果没有保存在本地缓存，进入215。

212、GGSN缓存向RNC缓存发送第三报文响应，第三报文响应包括HTTP报文请求所请求的业务。

213、RNC缓存向NodeB缓存转发第三报文响应。

214、NodeB缓存向用户设备转发第三报文响应。结束流程。

215、GGSN缓存建立到SP的第三连接，通过第三连接向SP转发HTTP报文请求。

216、GGSN缓存接收来自SP的第四报文响应，第四报文响应包括HTTP报文请求所请求的业务。

217、GGSN缓存向RNC缓存转发第四报文响应。

218、RNC缓存向NodeB缓存转发第四报文响应。

219、NodeB缓存向用户设备转发第四报文响应。结束流程。

220、NodeB将业务请求转发给RNC。

221、RNC将业务请求转发给GGSN。

222、GGSN将业务请求转发给GGSN内容分析单元。

223、GGSN内容分析单元根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到GGSN缓存。其中，如果解析得到的是非HTTP报文请求，则可以将非HTTP报文请求转发到相应的服务器或网关。

224、GGSN缓存根据HTTP报文请求进行热度分析，并判断热度分析的结果是否达到保存条件。

保存条件是需要设置的，如果热度分析的结果达到保存条件，则说明请求该HTTP报文请求对应的业务的用户设备比较多，可以将HTTP报文请求所请求的业务注入到RNC缓存和NodeB缓存。

225、GGSN缓存将HTTP报文请求所请求的业务发送给RNC缓存和NodeB缓存。

在本发明的另一个实施例中，GGSN缓存将HTTP报文请求所请求的业务发送给RNC缓存；然后由RNC缓存进行热度分析，确定是否将HTTP报文请求所请求的业务发送给NodeB缓存。

需要说明的是，本实施例中202和220是同时执行的，相应的202～219与220～225是可以并行执行的，本实施例中202和220仅仅是为了描述方便，并不是限定执行上的先后顺序。

从上可知，本实施例中NodeB缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，如果本地没有保存报文请求所请求的业务，NodeB缓存可以向RNC缓存请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。进一步，GGSN缓存可以将用户设备请求较多的(热度较高)业务发送到RNC缓存和/或NodeB缓存，使RNC缓存和NodeB就可以在用户设备请求该业务时直接下发给用户设备，提高用户设备获取业务的速度。

在本发明的一个实施例中，UE可能从属于同一个RNC的NodeB1切换到NodeB2，此时如果UE切换前在NodeB1请求的业务在NodeB1缓存有保存，在切换前会由NodeB1缓存响应用户设备的报文请求。则在切换后，UE会与NodeB2建立连接，则UE新的业务请求会由NodeB2缓存进行处理，NodeB2的处理过程参照204～206。而如果UE切换前在NodeB1请求的业务没有在NodeB1缓存保存，则切换前已经由RNC缓存响应用户设备的报文请求，则在切换后，可以仍然由RNC缓存对用户设备的报文请求进行响应。

在本发明的一个实施例中，UE可能从属于RNC1的NodeB1切换到从属于RNC2的NodeB2，此时如果UE切换前在NodeB1请求的业务在NodeB1缓存或RNC1缓存有保存，在切换前会由NodeB1缓存或RNC1缓存响应用户设备的报文请求。则在切换后，UE会与NodeB2建立连接，则UE新的业务请求会由NodeB2缓存进行处理，NodeB2的处理过程参照204～206。而如果UE切换前在NodeB1请求的业务没有在NodeB1缓存和RNC1缓存保存，则切换前已经由GGSN缓存响应用户设备的报文请求，则在切换后，可以仍然由GGSN缓存对用户设备的报文请求进行响应。

图3描述了本发明一个实施例提供的业务下发方法的信令流程，该实施例中UMTS设置有RNC缓存和GGSN缓存，该实施例描述的是UMTS中网元的处理流程，该实施例包括：

301、用户设备向NodeB发起业务请求，业务请求可以请求HTTP业务和/或非HTTP业务，本实施例用业务请求所请求的业务是HTTP业务进行描述。

302、NodeB将用户设备的业务请求转发给RNC。

303、RNC将用户设备的业务请求转发给RNC内容分析单元。

304、RNC内容分析单元进行本地Cache策略管理，根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到RNC缓存。

其中，在本发明的一个实施例中，RNC内容分析单元可以进一步将解析得到的HTTP报文请求发送到GGSN缓存，使GGSN缓存可以根据该HTTP报文请求进行热度分析。

305、RNC缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入306；如果没有保存在本地缓存，进入307。

306、RNC缓存向用户设备发送第一报文响应，第一报文响应包括HTTP报文请求所请求的业务。结束流程。

307、RNC缓存建立到GGSN缓存的第一连接，通过第一连接向GGSN缓存转发HTTP报文请求。

308、GGSN缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入309；如果没有保存在本地缓存，进入311。

309、GGSN缓存向RNC缓存发送第二报文响应，第二报文响应包括HTTP报文请求所请求的业务。

310、RNC缓存向用户设备转发第二报文响应。结束流程。

311、GGSN缓存建立到SP的第二连接，通过第二连接向SP转发HTTP报文请求。

312、接收来自SP的第三报文响应，第三报文响应包括HTTP报文请求所请求的业务。

313、GGSN缓存向RNC缓存转发第三报文响应。

314、RNC缓存向用户设备转发第三报文响应。结束流程。

315、RNC将业务请求转发给GGSN。

316、GGSN将业务请求转发给GGSN内容分析单元。

317、GGSN内容分析单元根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到GGSN缓存。其中，如果解析得到的是非HTTP报文请求，则可以将非HTTP报文请求转发到相应的服务器或网关。

318、GGSN缓存根据HTTP报文请求进行热度分析，并判断热度分析的结果是否达到保存条件。

319、GGSN缓存将HTTP报文请求所请求的业务发送给RNC缓存。

需要说明的是，本实施例中303和315是同时执行的，相应的303～314与315～319是可以并行执行的，本实施例中303和315仅仅是为了描述方便，并不是限定执行上的先后顺序。

从上可知，本实施例中RNC缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，如果本地没有保存报文请求所请求的业务，RNC缓存可以向GGSN缓存请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。进一步，GGSN缓存可以将用户设备请求较多的(热度较高)业务发送到RNC缓存，使RNC缓存可以在用户设备请求该业务时直接下发给用户设备，提高用户设备获取业务的速度。

再介绍本发明实施例在LTE移动通信系统中的应用。

本发明一个实施例在LTE移动通信系统中构建二级缓存，分别是设置在eNodeB节点的eNodeB Cache，以及设置在PGW的PGW Cache；每一级缓存都有其对应的内容分析单元。其中，eNodeB Cache进行业务缓存，以及响应基站下用户设备在本地缓存的业务请求。PGW Cache实现不是由RAN侧响应，在PGW Cache有缓存的用户设备业务请求，直接返回用户设备请求的业务，对于在PGW Cache没有存储的业务，PGW可以代理用户设备向SP请求业务。同时，所有用户设备发起的业务请求，都在PGW Cache进行业务热度统计，并根据业务热度，确定eNodeB Cache中需要保存的业务。

图4描述了本发明一个实施例提供的业务下发方法的信令流程，该实施例中LTE移动通信系统设置有eNodeB缓存和PGW缓存，该实施例描述的是LTE移动通信系统中网元的处理流程，该实施例包括：

401、用户设备向eNodeB发起业务请求，业务请求可以请求HTTP业务和/或非HTTP业务，本实施例用业务请求所请求的业务是HTTP业务进行描述。

402、eNodeB把用户设备的业务请求转发给eNodeB内容分析单元。

403、eNodeB内容分析单元进行本地Cache策略管理，根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到eNodeB缓存。

其中，在本发明的一个实施例中，eNodeB内容分析单元可以进一步将解析得到的HTTP报文请求发送到PGW缓存，使PGW缓存可以根据该HTTP报文请求进行热度分析。

404、eNodeB缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入405；如果没有保存在本地缓存，进入406。

405、eNodeB缓存向用户设备发送第一报文响应，第一报文响应包括HTTP报文请求所请求的业务。结束流程。

406、NodeB缓存建立到PGW缓存的第一连接，通过第一连接向PGW缓存转发HTTP报文请求。

407、PGW缓存判断HTTP报文请求所请求的业务是否保存在本地缓存。如果保存在本地缓存，进入408；如果没有保存在本地缓存，进入410。

408、PGW缓存向eNodeB缓存发送第二报文响应，第二报文响应包括HTTP报文请求所请求的业务。

409、eNodeB缓存向用户设备转发第二报文响应。结束流程。

410、PGW缓存建立到SP的第二连接，通过第二连接向SP转发HTTP报文请求。

411、PGW缓存接收来自SP的第三报文响应，第三报文响应包括HTTP报文请求所请求的业务。

412、PGW缓存向eNodeB缓存转发第三报文响应。

413、eNodeB缓存向用户设备转发第三报文响应。结束流程。

414、eNodeB将业务请求转发给服务网关(SGW)。

415、SGW将业务请求转发给PGW。

416、PGW将业务请求转发给PGW内容分析单元。

417、PGW内容分析单元根据本地Cache策略处理业务请求，将解析得到的HTTP报文请求发送到PGW缓存。其中，如果解析得到的是非HTTP报文请求，则可以将非HTTP报文请求转发到相应的服务器或网关。

418、PGW缓存根据HTTP报文请求进行热度分析，并判断热度分析的结果是否达到保存条件。

419、PGW缓存将HTTP报文请求所请求的业务发送给eNodeB缓存。

需要说明的是，本实施例中402和414是同时执行的，相应的402～413与415～419是可以并行执行的，本实施例中402和414仅仅是为了描述方便，并不是限定执行上的先后顺序。

从上可知，本实施例中eNodeB缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，如果本地没有保存报文请求所请求的业务，eNodeB缓存可以向PGW缓存请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。进一步，PGW缓存可以将用户设备请求较多的(热度较高)业务发送到eNodeB缓存，使eNodeB可以在用户设备请求该业务时直接下发给用户设备，提高用户设备获取业务的速度。

在无线网络中，由于终端的移动，用户设备与边缘CDN Cache节点的关系无法确定，造成了重定向的难度，本发明一个实施例建立用户设备网络地址与边缘CDN Cache网络地址的动态绑定关系，从而实现CDN模式下的重定向功能，该边缘CDN Cache包可以是NodeB Cache、RNC Cache、eNodeBCache等。

图5描述了本发明另一个实施例提供的业务下发方法的流程，本实施例描述的是PCRF的处理流程，该实施例包括：

501、接收边缘网络节点上报的用户设备的地址与该边缘网络节点的地址的绑定关系，该用户设备的地址与该边缘网络节点的地址的绑定关系由该边缘网络节点在该用户设备成功附着到该边缘网络节点后发送。

其中，边缘网络节点可以是NodeB、RNC、eNodeB等。其中，绑定的具体可以是用户设备的网络地址与边缘网络节点的网络地址。

在本发明的另一个实施例中，网络节点上报的用户设备的地址与该边缘网络节点对应的CDN缓存的地址的绑定关系。

502、接收来自CDN节点的边缘网络节点位置查询请求，该边缘网络节点位置查询请求包括用户设备的地址，边缘网络节点位置查询请求由CDN节点接收到来自业务平台的重定向请求后发送，重定向请求由业务平台接收到业务请求后发送。

503、根据用户设备的地址与边缘网络节点的地址的绑定关系将查找到的边缘网络节点的地址发送给CDN节点，以使CDN节点根据边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向用户设备发送重定位请求，重定位请求包括边缘网络节点对应的CDN缓存的地址，以使用户设备从边缘网络节点对应的CDN缓存获取业务。

如果网络节点上报的用户设备的地址与该边缘网络节点对应的CDN缓存的地址的绑定关系，则可以直接根据该绑定关系将边缘网络节点对应的CDN缓存的地址发送给CDN节点，使CDN节点可以直接向用户设备发送包括边缘网络节点对应的CDN缓存的地址重定位请求。

从上可知，本实施例中边缘网络节点在用户设备附着到网络后，可以将用户设备与边缘网络节点的绑定关系发送给PCRF，从而在CDN重定向时，可以根据用户设备与边缘网络节点的绑定关系将用户设备所在的本地侧边缘网络节点缓存的地址发送给用户设备，使用户设备可以直接向所在的本地侧边缘网络节点缓存请求业务，从而由用户设备所在的本地侧缓存对用户设备进行业务下发，提高用户的用户体验。

图6描述了本发明另一个实施例提供的业务下发方法的信令流程，该实施例描述的是UMTS网络中网元的处理流程(在其他网络中网元的处理流程与UMTS网络中网元的处理流程类似，不再赘述)，该实施例以边缘网络节点是RNC为例进行说明，该实施例包括：

600、CDN节点预先将部分热门内容推送给RNC缓存。

601、UE通过RNC与SGSN/GGSN发起附着和PDP激活流程。

本实施例假设UE的认证通过，允许UE使用业务，即UE成功附着到RNC。

602、RNC向PCRF上报UE与该RNC的绑定关系；具体可以绑定UE的IP地址与RNC的IP地址。

603、UE启动UE软件后，向业务平台上报UE的信息，UE的信息包括终端类型、操作系统和软件版本等。

604、业务平台向策略与计费规则功能(PCRF：Policy and Charging RulesFunction)实体上报UE的信息。

605、PCRF接收到UE的信息后，生成UE策略，向RNC缓存发送UE策略。

606、UE向RNC发起业务请求。

607、RNC在确定业务请求所请求的业务不是由本地处理后，向业务平台转发业务请求。

608、业务平台判断业务请求所请求的业务是否是CDN可缓存内容；如果否，进入609；如果是，进入611。

609、业务平台向SP转发业务请求。

610、SP向UE发送业务响应，该业务响应包括业务请求所请求的业务。结束流程。

611、业务平台将业务请求重定向到CDN节点。

612、CDN节点从PCRF查询到RNC的地址，从而确定RNC缓存的地址。

具体地，PCRF可以根据业务请求的源地址确定UE的地址，进而根据UE的地址查询到RNC的地址。

613、CDN节点向UE发送重定向请求，重定向请求包括RNC缓存的地址。

614、UE根据RNC缓存的地址向RNC缓存发送业务请求。

615、RNC判断业务请求所请求的业务是否保存在本地缓存；如果否，进入616；如果是，进入617。

616、从SP获取业务请求所请求的业务。

617、RNC缓存向UE发送业务响应，该业务响应包括业务请求所请求的业务。

从上可知，本实施例中RNC在用户设备附着到网络后，可以将用户设备与RNC的绑定关系发送给PCRF，从而在CDN重定向时，可以根据用户设备与RNC的绑定关系将用户设备所在的RNC缓存的地址发送给用户设备，使用户设备可以直接向RNC缓存请求业务，从而由用户设备所在的本地侧缓存对用户设备进行业务下发，提高用户的用户体验。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

再介绍本发明实施例提供的业务下发装置，图7描述了本发明一个实施例提供的业务下发装置的结构，包括：

接收单元701，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从业务请求中解析得到。

判断单元702，用于判断接收单元701接收的报文请求所请求的业务保存在本地缓存。

发送单元703，用于在判断单元702判断报文请求所请求的业务保存在本地缓存时，向UE发送第一报文响应，第一报文响应包括报文请求所请求的业务。

本实施例提供的业务下发装置可以作为缓存使用。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。

图8描述了本发明另一个实施例提供的业务下发装置的结构，包括接收单元801、判断单元802、发送单元803和连接建立单元804，其中：

接收单元801，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从业务请求中解析得到。接收上一级缓存通过连接建立单元804建立的第一连接返回的第二报文响应，该第二报文响应包括报文请求所请求的业务。

判断单元802，用于判断接收单元801接收的报文请求所请求的业务保存在本地缓存。

发送单元803，用于在判断单元802判断报文请求所请求的业务保存在本地缓存时，向UE发送第一报文响应，第一报文响应包括报文请求所请求的业务。通过连接建立单元804建立的第一连接向上一级缓存转发报文请求。向UE转发接收单元801接收的第二报文响应。

连接建立单元804，用于在判断单元802判断报文请求所请求的业务没有保存在本地缓存时，建立与上一级缓存的第一连接。

本实施例提供的业务下发装置可以作为缓存使用。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，在本发明的一个实施例中，如果本地没有保存报文请求所请求的业务，缓存可以向上一级缓存请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。

图9描述了本发明另一个实施例提供的业务下发装置的结构，包括接收单元901、判断单元902、发送单元903和连接建立单元904，其中：

接收单元901，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从业务请求中解析得到。接收业务提供商通过连接建立单元904建立的第一连接返回的第二报文响应，该第二报文响应包括报文请求所请求的业务。

判断单元902，用于判断接收单元901接收的报文请求所请求的业务保存在本地缓存。

发送单元903，用于在判断单元902判断报文请求所请求的业务保存在本地缓存时，向UE发送第一报文响应，第一报文响应包括报文请求所请求的业务。通过连接建立单元904建立的第一连接向业务提供商转发报文请求。向UE转发接收单元901接收的第二报文响应。

连接建立单元904，用于在判断单元902判断报文请求所请求的业务没有保存在本地缓存时，建立与业务提供商的第一连接。

本实施例提供的业务下发装置可以作为缓存使用。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，在本发明的一个实施例中，如果本地没有保存报文请求所请求的业务，缓存可以向SP请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。

图10描述了本发明另一个实施例提供的业务下发装置的结构，包括接收单元1001、判断单元1002、发送单元1003、连接建立单元1004、分析单元1005和保存单元1006，其中：

接收单元1001，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从业务请求中解析得到。接收业务提供商通过连接建立单元1004建立的第一连接返回的第二报文响应，该第二报文响应包括报文请求所请求的业务。

判断单元1002，用于判断接收单元1001接收的报文请求所请求的业务保存在本地缓存。判断分析单元1005进行热度分析的结果是否达到保存条件。

发送单元1003，用于在判断单元1002判断报文请求所请求的业务保存在本地缓存时，向UE发送第一报文响应，第一报文响应包括报文请求所请求的业务。通过连接建立单元1004建立的第一连接向业务提供商转发报文请求。向UE转发接收单元1001接收的第二报文响应。

在本发明的另一个实施例中，发送单元1003还可以用于将保存单元1006保存的报文请求所请求的业务发送给下级缓存，使下级缓存保存所述报文请求所请求的业务。

连接建立单元1004，用于在判断单元1002判断报文请求所请求的业务没有保存在本地缓存时，建立与业务提供商的第一连接。

分析单元1005，用于根据接收单元1001接收的报文请求进行热度分析。

保存单元1006，用于在判断单元1002判断热度分析的结果达到保存条件时，将接收单元1001接收的报文请求所请求的业务保存在本地缓存。

本实施例提供的业务下发装置可以作为缓存使用。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，在本发明的一个实施例中，如果本地没有保存报文请求所请求的业务，缓存可以向SP请求报文请求所请求的业务，从而确保向用户设备发送报文请求所请求的业务，进一步提高用户的用户体验。进一步，在本发明的一个实施例中，业务下发装置的本实施例可以将用户设备请求较多的(热度较高)业务保存在本地缓存，从而在后续的业务下发过程中可以直接将业务进行下发，提高用户设备获取业务的速度。进一步，在本发明的一个实施例中，业务下发装置的本实施例在保存了业务后，还可以将业务发送到下级缓存，使下级缓存就可以在用户设备请求该业务时直接下发给用户设备，进一步提高用户设备获取业务的速度。

图11描述了本发明另一个实施例提供的业务下发装置的结构，包括：

接收单元1101，用于接收报文请求，该报文请求由所述内容分析单元接收到UE发送的业务请求后，根据缓存策略从业务请求中解析得到。

分析单元1102，用于根据接收单元1101接收的报文请求进行热度分析。

判断单元1103，用于判断接收单元1101接收的报文请求所请求的业务保存在本地缓存。判断分析单元1102进行热度分析的结果是否达到保存条件。

发送单元1104，用于在判断单元1103判断报文请求所请求的业务保存在本地缓存时，向UE发送第一报文响应，第一报文响应包括报文请求所请求的业务。在判断单元1103判断热度分析的结果达到保存条件时，将报文请求所请求的业务发送给下级缓存，使下级缓存保存报文请求所请求的业务。

本实施例提供的业务下发装置可以作为缓存使用。

从上可知，本实施例中缓存在接收到报文请求后，在本地保存有报文请求所请求的业务时，可以直接将报文请求所请求的业务发送给用户设备，从而不需要将用户设备发送的业务请求进行重定向即可完成对用户设备的业务的下发，从而避免了CDN架构对HTTP1.1的支持不够好的缺陷，同时也可以确保由用户设备所在的本地侧缓存对用户设备进行业务下发，提高了用户的用户体验。进一步，在本发明的一个实施例中，最顶级缓存可以将用户设备请求较多的(热度较高)业务发送到下级缓存，使下级缓存就可以在用户设备请求该业务时直接下发给用户设备，提高用户设备获取业务的速度。

图12描述了本发明另一个实施例提供的业务下发装置的结构，包括：

接收单元1201，用于接收边缘网络节点上报的用户设备的地址与边缘网络节点的地址的绑定关系，绑定关系由边缘网络节点在用户设备成功附着到边缘网络节点后发送；接收来自CDN节点的边缘网络节点位置查询请求，边缘网络节点位置查询请求包括用户设备的地址，边缘网络节点位置查询请求由CDN节点接收到来自业务平台的重定向请求后发送，重定向请求由业务平台接收到业务请求后发送。

发送单元1202，用于根据接收单元1201接收的绑定关系将边缘网络节点的地址发送给CDN节点，以使CDN节点根据边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向用户设备发送重定位请求，重定位请求包括边缘网络节点对应的CDN缓存的地址，以使用户设备从边缘网络节点对应的CDN缓存获取业务。

本实施例提供的业务下发装置可以作为PCRF使用。

从上可知，本实施例中边缘网络节点在用户设备附着到网络后，可以将用户设备的地址与边缘网络节点的地址的绑定关系发送给PCRF，从而在CDN重定向时，可以根据绑定关系查找到与用户设备的地址绑定的边缘网络节点的地址，从而查找到边缘网络节点对应的CDN缓存(即用户设备所在的本地侧边缘网络节点缓存)的地址，再将用户设备所在的本地侧边缘网络节点缓存的地址发送给用户设备，使用户设备可以直接向所在的本地侧边缘网络节点缓存请求业务，从而由用户设备所在的本地侧缓存对用户设备进行业务下发，提高用户的用户体验。

本发明另一个实施例提供的业务下发装置的结构也如图12所示，包括：

接收单元1201，用于接收边缘网络节点上报的用户设备的地址与边缘网络节点对应的CDN缓存的地址的绑定关系，绑定关系由边缘网络节点在用户设备成功附着到边缘网络节点后发送；接收CDN节点的边缘网络节点位置查询请求，边缘网络节点位置查询请求包括用户设备的地址，边缘网络节点位置查询请求由CDN节点接收到来自业务平台的重定向请求后发送，重定向请求由业务平台接收到业务请求后发送；

发送单元1202，用于根据接收单元1201接收的绑定关系将边缘网络节点对应的CDN缓存的地址发送给CDN节点，以使CDN节点向用户设备发送重定位请求，重定位请求包括边缘网络节点对应的CDN缓存的地址，以使用户设备从边缘网络节点对应的CDN缓存获取业务。

本实施例提供的业务下发装置可以作为PCRF使用。

从上可知，本实施例中边缘网络节点在用户设备附着到网络后，可以将用户设备的地址与边缘网络节点对应的CDN缓存的地址的绑定关系发送给PCRF，从而在CDN重定向时，可以根据绑定关系查找到与用户设备的地址绑定的边缘网络节点对应的CDN缓存(即用户设备所在的本地侧边缘网络节点缓存)的地址，再将用户设备所在的本地侧边缘网络节点缓存的地址发送给用户设备，使用户设备可以直接向所在的本地侧边缘网络节点缓存请求业务，从而由用户设备所在的本地侧缓存对用户设备进行业务下发，提高用户的用户体验。

本发明实施例还提供了通信系统，该通信系统包括本发明实施例提供的业务下发装置。

上述装置和系统内的各模块之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(ROM：Read-Only Memory)或随机存储记忆体(RAM：Random Access Memory)等。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (5)

1.一种业务下发方法，其特征在于，包括：

接收边缘网络节点上报的用户设备的地址与所述边缘网络节点的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；

接收来自CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由业务平台接收到业务请求后发送；

根据所述绑定关系将所述边缘网络节点的地址发送给所述CDN节点，以使所述CDN节点根据所述边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

2.一种业务下发方法，其特征在于，包括：

接收边缘网络节点上报的用户设备的地址与所述边缘网络节点对应的CDN缓存的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；

接收CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

根据所述绑定关系将所述边缘网络节点对应的CDN缓存的地址发送给所述CDN节点，以使所述CDN节点向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

3.一种业务下发装置，其特征在于，包括：

接收单元，用于接收边缘网络节点上报的用户设备的地址与所述边缘网络节点的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；接收来自CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

发送单元，用于根据所述绑定关系将所述边缘网络节点的地址发送给所述CDN节点，以使所述CDN节点根据所述边缘网络节点的地址确定边缘网络节点对应的CDN缓存的地址，并向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

4.一种业务下发装置，其特征在于，包括：

接收单元，用于接收边缘网络节点上报的用户设备的地址与所述边缘网络节点对应的CDN缓存的地址的绑定关系，所述绑定关系由所述边缘网络节点在所述用户设备成功附着到所述边缘网络节点后发送；接收CDN节点的边缘网络节点位置查询请求，所述边缘网络节点位置查询请求包括所述用户设备的地址，所述边缘网络节点位置查询请求由所述CDN节点接收到来自业务平台的重定向请求后发送，所述重定向请求由所述业务平台接收到业务请求后发送；

发送单元，用于根据所述绑定关系将所述边缘网络节点对应的CDN缓存的地址发送给所述CDN节点，以使所述CDN节点向所述用户设备发送重定位请求，所述重定位请求包括所述边缘网络节点对应的CDN缓存的地址，以使所述用户设备从所述边缘网络节点对应的CDN缓存获取业务。

5.一种通信系统，其特征在于，包括如权利要求3或4所述的业务下发装置。

Images