媒体服务方法及系统

1.一种媒体服务方法，其特征在于，包括：
边缘节点接收来自用户设备的媒体服务请求，其中，所述媒体服务请求用于请求媒体资源，移动流媒体用户根据用户设备编号归属到某个所述边缘节点；
所述边缘节点判断其能否为所述用户设备提供所述媒体资源；
所述边缘节点在判断结果为否的情况下，向中心节点发送请求消息；
所述边缘节点接收来自所述中心节点响应于所述请求消息的所述媒体资源，并将所述媒体资源发送给所述用户设备；
其中，所述边缘节点向所述中心节点发送所述请求消息包括：
所述边缘节点向所述用户设备发送携带有所述边缘节点的媒体服务器地址的URL，其中，所述URL中携带有所述边缘节点不能提供所述媒体资源的指示标识；
所述用户设备根据所述URL向所述URL对应的所述媒体服务器发起媒体服务请求；
所述URL对应的媒体服务器接收到来自所述用户设备的服务请求之后，向所述中心节点发送所述请求消息。
2.根据权利要求1所述的方法，其特征在于，所述边缘节点接收来自所述中心节点响应于所述请求消息的所述媒体资源包括：
所述中心节点向所述边缘节点发送携带有用于提供所述媒体资源的媒体服务器地址的URL；
所述边缘节点根据所述URL向所述URL对应的媒体服务器发起媒体服务请求，并接收来自所述URL对应的媒体服务器的所述媒体资源。
3.根据权利要求1至2中任一项所述的方法，其特征在于，在所述判断结果为是的情况下，所述边缘节点将所述媒体资源发送给所述用户设备。
4.根据权利要求1所述的方法，其特征在于，在所述边缘节点接收到来自所述用户设备的所述媒体服务请求之前，所述方法还包括：
所述边缘节点根据预定策略保存媒体资源。
5.一种媒体服务系统，包括边缘节点和中心节点，其特征在于，所述边缘节点包括：
第一接收模块，用于接收来自用户设备的媒体服务请求，其中，所述媒体服务请求用于请求媒体资源，移动流媒体用户根据用户设备编号归属到某个所述边缘节点；
判断模块，用于判断所述边缘节点能够为所述用户设备提供所述媒体资源；
第一发送模块，用于在所述判断模块的判断结果为否的情况下，向中心节点发送请求消息；
第二接收模块，所述边缘节点接收来自所述中心节点响应于所述请求消息的所述媒体资源；
第二发送模块，用于将所述媒体资源发送给所述用户设备；
其中，所述第一发送模块包括：
第一发送子模块，用于向所述用户设备发送携带有所述边缘节点的媒体服务器地址的URL，其中，所述URL中携带有所述边缘节点不能提供所述媒体资源的指示标识，以便于所述用户设备根据所述URL向所述URL对应的所述媒体服务器发起媒体服务请求；
第二发送子模块，用于在接收到来自所述用户设备的服务请求之后，向所述中心节点发送所述请求消息。
6.根据权利要求5所述的系统，其特征在于，所述第二接收模块包括：
第一接收子模块，用于接收来自所述中心节点的携带有用于提供所述媒体资源的媒体服务器地址的URL；
发起子模块，用于根据所述URL向所述URL对应的媒体服务器发起媒体服务请求；
第二接收子模块，用于接收来自所述URL对应的媒体服务器的所述媒体资源。
7.根据权利要求6所述的系统，其特征在于，所述边缘节点还包括：
保存模块，用于根据预定策略保存媒体资源。
8.根据权利要求5至7中任一项所述的系统，其特征在于，所述中心节点包括：
第三接收模块，用于接收来自所述边缘节点请求消息，其中，请求消息用于请求媒体资源：
第三发送模块，用于将所述媒体资源发送给所述边缘节点。

媒体服务方法及系统\n技术领域\n[0001] 本发明涉及通信领域，具体而言，涉及一种媒体服务方法及系统。\n背景技术\n[0002] 移动流媒体技术是把连续的声音和影像信息经过采集、压缩处理后存储到网络服务器上，使移动终端用户能够一边下载一边收听、观看，而不需要等到整个多媒体文件下载完成就可以即时观看的技术。\n[0003] 在提供移动流媒体业务时，一般是根据用户归属的物理区域分别架设服务器节点，由该节点为本区域内的用户提供媒体服务。当系统中的媒体文件越来越多时，会给节点的存储造成很大压力，同时对于一些较生僻的冷门内容，每个节点都保存一份会造成存储资源的浪费，但是，如果为了减轻存储压力使每个节点有选择性地保存部分媒体文件，当用户请求节点上不存在的媒体文件时，系统无法提供服务，影响用户体验。\n发明内容\n[0004] 针对相关技术中的服务器分节点在存储资源时产生的存储资源浪费以及资源不存在时系统无法提供服务的问题而提出本发明，为此，本发明的主要目的在于提供一种改进的媒体服务方案，以解决上述问题至少之一。\n[0005] 为了实现上述目的，根据本发明的一个方面，提供了一种媒体服务方法。\n[0006] 根据本发明的媒体服务方法包括：边缘节点接收来自用户设备的媒体服务请求，其中，媒体服务请求用于请求媒体资源；边缘节点判断其能否为用户设备提供媒体资源；\n边缘节点在判断结果为否的情况下，向中心节点发送请求消息；边缘节点接收来自中心节点响应于请求消息的媒体资源，并将媒体资源发送给用户设备。\n[0007] 优选地，边缘节点接收来自中心节点响应于请求消息的媒体资源包括：中心节点向边缘节点发送携带有用于提供媒体资源的媒体服务器地址的URL；边缘节点根据URL向URL对应的媒体服务器发起媒体服务请求，并接收来自URL对应的媒体服务器的媒体资源。\n[0008] 优选地，边缘节点向中心节点发送请求消息包括：边缘节点向用户设备发送携带有边缘节点的媒体服务器地址的URL，其中，URL中携带有边缘节点不能提供媒体资源的指示标识；用户设备根据URL向URL对应的媒体服务器发起媒体服务请求；URL对应的媒体服务器接收到来自用户设备的服务请求之后，向中心节点发送请求消息。\n[0009] 优选地，在判断结果为是的情况下，边缘节点将媒体资源发送给用户设备。\n[0010] 优选地，在边缘节点接收到来自用户设备的媒体服务请求之前，方法还包括：边缘节点根据预定策略保存媒体资源。\n[0011] 为了实现上述目的，根据本发明的另一方面，提供了一种媒体服务系统。\n[0012] 根据本发明的媒体服务系统包括边缘节点和中心节点，其中，边缘节点包括：第一接收模块，用于接收来自用户设备的媒体服务请求，其中，媒体服务请求用于请求媒体资源；判断模块，用于判断边缘节点能够为用户设备提供媒体资源；第一发送模块，用于在判断模块的判断结果为否的情况下，向中心节点发送请求消息；第二接收模块，边缘节点接收来自中心节点响应于请求消息的媒体资源；第二发送模块，用于将媒体资源发送给用户设备。\n[0013] 优选地，第二接收模块包括：第一接收子模块，用于接收来自中心节点的携带有用于提供媒体资源的媒体服务器地址的URL；发起子模块，用于根据URL向URL对应的媒体服务器发起媒体服务请求；第二接收子模块，用于接收来自URL对应的媒体服务器的媒体资源。\n[0014] 优选地，第一发送模块包括：第一发送子模块，用于向用户设备发送携带有边缘节点的媒体服务器地址的URL，其中，URL中携带有边缘节点不能提供媒体资源的指示标识，以便于用户设备根据URL向URL对应的媒体服务器发起媒体服务请求；第二发送子模块，用于在接收到来自用户设备的服务请求之后，向中心节点发送请求消息。\n[0015] 优选地，边缘节点还包括：保存模块，用于根据预定策略保存媒体资源。\n[0016] 优选地，中心节点包括：第三接收模块，用于接收来自边缘节点请求消息，其中，请求消息用于请求媒体资源：第三发送模块，用于将媒体资源发送给边缘节点。\n[0017] 通过本发明，采用了根据策略在分节点(即，边缘节点)上保存媒体资源，当用户终端请求的媒体资源在分节点上不存在时，该分节点从中心节点获取该媒体资源，解决了的服务器分节点在存储资源时产生的存储资源浪费以及资源不存在时系统无法提供服务的问题，进而达到了优化系统的资源共享能力以及提高用户体验的效果。\n附图说明\n[0018] 此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：\n[0019] 图1是根据本发明实施例的媒体服务方法的流程图；\n[0020] 图2是根据本发明实施例的移动流媒体系统组网的结构示意图；\n[0021] 图3是根据本发明实施例的服务中继方法的流程图；\n[0022] 图4是根据本发明实施例的以非中继形式提供点播服务的流程图；\n[0023] 图5是根据本发明实施例的以中继形式提供点播服务的流程图；\n[0024] 图6是根据本发明实施例的媒体服务系统的结构框图；\n[0025] 图7是根据本发明实施例的媒体服务系统具体的结构框图。\n具体实施方式\n[0026] 功能概述\n[0027] 相关技术中的服务器分节点在存储资源时产生的存储资源浪费以及资源不存在时系统无法提供服务的问题，本发明实施例提供了一种媒体服务方案，该方案的处理原则如下：边缘节点接收来自用户设备的媒体服务请求，其中，媒体服务请求用于请求媒体资源；边缘节点确定在其不能为用户设备提供媒体资源的情况下，向中心节点发送请求消息；\n边缘节点接收来自中心节点响应于请求消息的媒体资源，并将媒体资源发送给用户设备。\n[0028] 需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。\n[0029] 在以下实施例中，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。\n[0030] 方法实施例\n[0031] 根据本发明的实施例，提供了一种媒体服务方法，图1是根据本发明是实施例的媒体服务方法的流程图，如图1所示，该方法包括如下的步骤S102至步骤S106：\n[0032] 步骤S102，边缘节点接收来自用户设备的媒体服务请求，其中，媒体服务请求用于请求媒体资源。\n[0033] 步骤S104，边缘节点判断该边缘节点能否为用户设备提供请求的媒体资源，并在确定在其不能为用户设备提供媒体资源的情况下，向中心节点发送请求消息；在边缘节点确定其能为用户设备提供媒体资源的情况下，边缘节点将媒体资源发送给用户设备。\n[0034] 步骤S106，边缘节点接收来自中心节点响应于请求消息的媒体资源，并将媒体资源发送给用户设备。\n[0035] 边缘节点不能为用户设备提供媒体资源的原因可以是该边缘节点不存在该媒体资源，但原因并不限于此，例如，该原因还可以是因为边缘节点的负载过大等。\n[0036] 需要说明的是，边缘节点不需要保存所有的媒体资源，可以根据预定策略保存媒体资源，例如，可以根据该媒体资源点播的次数，该媒体资源的创建时间等。\n[0037] 其中，在步骤S106中的边缘节点接收来自中心节点响应于请求消息的媒体资源包括如下步骤：\n[0038] 步骤A，中心节点向边缘节点发送携带有用于提供媒体资源的媒体服务器地址的统一资源定位符(Uniform Resource Locator，简称为URL)。\n[0039] 步骤B，边缘节点根据URL向URL对应的媒体服务器发起媒体服务请求，并接收来自URL对应的媒体服务器的媒体资源。\n[0040] 在步骤S104中，边缘节点向中心节点发送请求消息包括如下步骤：\n[0041] 步骤C，边缘节点向用户设备发送携带有边缘节点的媒体服务器地址的URL，其中，URL中携带有边缘节点不存在媒体资源的指示标识。\n[0042] 步骤D，用户设备根据URL向URL对应的媒体服务器发起媒体服务请求。\n[0043] 步骤E，URL对应的媒体服务器接收到来自用户设备的服务请求之后，向中心节点发送请求消息。\n[0044] 下面结合具体的网络对上述步骤102至步骤S106，图2是根据本发明实施例的移动流媒体系统组网的结构示意图，如图2所示，在该移动流媒体系统中采用总部-省分二级架构的方式进行部署，在总部设置一个中心节点(也称为总部节点)；在各省设置一个边缘节点(也称为省分节点或本地节点)，其中，在省分节点的媒体服务器上配置总部节点的业务引擎地址信息，在此节点是指一个业务引擎设备和多台媒体服务器设备的组合。\n[0045] 业务引擎用来管理媒体服务器设备和各媒体服务器设备上存放的文件信息(即，媒体资源)，其中，省分业务引擎还负责处理与用户设备(User Equipment，简称为UE)的交互。业务引擎接收到来自用户设备的媒体服务请求后，先从数据库中检索出有哪些媒体服务器设备包含用户请求的媒体文件(即，媒体资源)，然后，综合该省分节点内各媒体服务器的硬件性能和/或并发流数选择一个最合适的服务器，最终组装出用于提供媒体服务的URL提供给用户，用户使用此URL进行媒体服务请求。\n[0046] 媒体服务器上可以为用户提供点播、直播和下载等媒体服务，可以由多台媒体服务器设备共同组成集群，媒体服务器使用大容量磁阵保存节点上媒体文件的实体内容。\n[0047] 总部节点中的音视频无线接入协议(Wireless Access Protocol，简称为WAP)门户负责展现移动流媒体系统中的媒体文件，用户设备通过访问WAP门户浏览系统中的媒体文件列表。\n[0048] 总部节点的媒体服务器上保存所有的媒体文件，每个省分节点根据一定的策略只存储部分实体文件，例如，可以根据系统实际运营情况只保存热门内容或者新上线的内容并定期动态调整。所有的移动流媒体用户都可以根据其终端编号(例如，手机号码)归属到某个边缘节点。当一个用户设备请求媒体服务时，由无线网络或有线固定网络负责将请求发送到其归属的省分节点的省分业务引擎，该省分业务引擎根据本节点数据库中保存的媒体文件记录进行查询，如果在省分媒体服务器上存在用户请求的媒体文件，则直接由该节点的本地媒体服务器为用户提供服务；如果省分媒体服务器上不存在对应媒体文件，则触发服务中继流程，经由省分媒体服务器、总部业务引擎和总部媒体服务器等网元通过一系列交互后选择一个最优的可用总部媒体服务器设备，由其负责向省分媒体服务器提供用户请求内容的媒体服务。下面对该中继流程进行详细的介绍。\n[0049] 该中继流程为：当用户设备请求服务时若自身归属节点不具备服务条件，先由归属节点内的省分媒体服务器向总部业务引擎发起重定向请求(需要说明的是，重定向是指根据系统中媒体文件的分布信息和各媒体设备的运行情况，选取一台媒体服务器为用户提供服务)，总部业务引擎生成一个包括总部媒体服务器地址的服务URL返回给省分媒体服务器，省分媒体服务器使用此URL向总部媒体服务器请求服务，总部媒体服务器向省分媒体服务器发送媒体码流，省分媒体服务器将媒体码流转发给用户设备，完成媒体交互流程。其中提供总部媒体服务器与省分媒体服务器之间、省分媒体服务器与用户设备之间时的数据传输形式跟服务类型相关，一般的流媒体数据传输是通过实时传输协议(Real-time Transport Protocol，简称为RTP)和实时传输控制协议(Real-time Transport ControlProtocol，简称为RTCP)配合完成。图3是根据本发明实施例的服务中继方法的流程图，如图3所示，该流程包括如下步骤：\n[0050] 步骤S301，用户设备向归属节点的省分业务引擎发起媒体服务请求。\n[0051] 步骤S302，省分业务引擎接收到该媒体服务请求后，在数据库中查找用户请求的内容在本地节点的媒体服务设备上是否存在。\n[0052] 步骤S303，根据步骤S302中的查找结果，并结合省分节点中媒体服务设备的硬件性能和并发流数等情况确定省分节点是否可以提供服务。\n[0053] 步骤S304，如果省分节点可以为用户提供服务，直接由省分媒体服务器向用户设备发送媒体码流，开始服务流程。\n[0054] 步骤S305，如果省分节点无法提供服务，需要触发中继流程。此时，由省分业务引擎生成一个临时的服务URL返回给用户设备，URL中的服务设备网路协议(Internet Protocol，简称为IP)地址填写本节点中任意一个媒体服务器的地址，同时，在URL中通过一个标识参数表示本次服务需要走中继流程。\n[0055] 步骤S306，用户设备使用步骤S305中返回的URL向省分媒体服务器发起请求，省分媒体服务器取出请求URL中的中继标识参数，向总部业务引擎发起重定向请求。\n[0056] 步骤S307，总部业务引擎在总部节点内进行重定向，生成一个含有总部媒体服务器地址的可用URL，然后，将URL封装在某种格式的响应消息中将结果返回给发出请求的省分媒体服务器。\n[0057] 步骤S308，省分媒体服务器使用接收到的新URL向总部媒体服务器请求服务，总部媒体服务器向省分媒体服务器发送所请求内容的码流数据。\n[0058] 步骤S309，省分媒体服务器将接收到的码流数据转发给用户设备，开始媒体服务流程。\n[0059] 下面将结合实例对本发明实施例的实现过程进行详细描述。\n[0060] 下面以用户设备请求视频文件点播服务为例，分别说明当用户归属的省分节点上存在用户请求的内容和不存在用户请求的内容两种情况下，本实施例的流程。\n[0061] 图4是根据本发明实施例的以非中继形式提供点播服务的流程图，如图4所示，在该流程中由省分流媒体服务器直接为用户提供服务，UE一般指移动手机终端；WAP是指音视频WAP门户，门户上提供节目入口列表，实际应用中用户设备先访问WAP门户，在页面上选择一个感兴趣的内容进行访问触发点播流程；本地流媒体服务器(Local Streaming Server，简称为LSS)部署在网络边缘节点，负责某个省的用户本地接入，提供流媒体的点播、直播、下载等服务的媒体服务器；本地业务引擎(Local Service Engine，简称为LSE)与本地流媒体服务器组成省分节点，共同为用户提供移动流媒体服务。如图4所示，该流程包括如下步骤：\n[0062] 步骤S401，用户设备通过无线网络访问移动流媒体系统的WAP门户。\n[0063] 步骤S402，WAP门户将移动流媒体系统中的音视频媒体文件以列表的方式展现在页面上，返回给用户设备。\n[0064] 步骤S403，用户选择感兴趣的媒体文件进行点播，向自身节点的LSE发送点播服务请求，该消息是一个超文本传输协议(HyperText Transfer Protocol，简称为HTTP)格式的GET请求。\n[0065] 步骤S404，LSE在自身节点数据库的内容记录表中检索，查找用户请求的内容在本地流媒体服务器上是否存在，如果存在用户请求的内容流媒体服务器运行正常，则将结果消息以HTTP包的形式返回，HTTP消息头中结果码是200，HTTP消息体中包含了LSE生成的结果URL，URL中设置proxy参数为0表示该内容在省分节点存在，不需要走服务中继流程。\n[0066] 步骤S405，用户设备收到LSE的响应后，取出响应消息中的URL，以实时流协议(Real-time Streaming Protocol，简称为RTSP)消息向LSS发起服务请求。\n[0067] 步骤S406，LSS收到用户设备RTSP请求后，判断发现其请求URL中proxy参数为\n0，在服务器的磁阵上定位到用户请求的文件所在位置，开始向用户设备发送码流数据，提供点播服务。\n[0068] 图5是根据本发明实施例的以中继形式提供点播服务的流程图如图5所示，当用户设备请求点播时，省分业务引擎向用户设备返回的消息中通知用户设备需要触发中继流程，然后通过省分流媒体服务器、总部业务引擎和总部流媒体服务器之间进行交互完成点播中继流程。全局流媒体服务器(Global Streaming Server，简称为GSS)，部署在移动流媒体系统的总部节点，通过中继的方式分担各省分节点的服务压力；全局业务引擎(Golbal Service Engine，简称为GSE)当收到LSS的重定向请求时在总部节点的流媒体服务器器中选择一个最优的可用设备，将该服务器的信息传回给LSS。该流程包括如下步骤：\n[0069] 步骤S501，用户设备访问移动流媒体系统的WAP门户。\n[0070] 步骤S502，WAP门户将系统中的音视频媒体文件以列表的方式展现在页面上，返回给用户设备。\n[0071] 步骤S503，用户选择感兴趣的媒体文件进行点播，向自身节点的LSE发送点播服务请求。\n[0072] 步骤S504，LSE在节点数据库的内容记录表中检索，查找用户请求的内容在本地流媒体服务器上是否存在，如果不存在则生成一个临时的服务URL，URL中的流媒体服务器地址填写本地节点中任一流媒体服务器IP，同时通过将URL中的标识参数proxy设置为1表示本地无此内容，后续需要触发中继流程，响应消息也以HTTP包的形式返回，HTTP消息头中结果码是200，HTTP消息体中包含了LSE生成的结果URL。\n[0073] 步骤S505，用户设备收到LSE的响应后，取出响应消息体中的URL，以RTSP格式向LSS发起服务请求。\n[0074] 步骤S506，LSS收到用户设备请求后，判断发现其请求URL中proxy参数为1，向GSE发起重定向请求，请求获取一个可以服务的点播URL。\n[0075] 步骤S507，GSE检索总部节点数据库的内容记录表，查找哪些流媒体设备包含用户请求的媒体文件，同时根据各设备的运行情况选择一个流媒体服务器，最终生成一个可以给LSS提供中继服务的可用URL，格式形如：\n[0076] rtsp://:/vod.3gp ？ userid ＝\n8618807880000&subcontentid＝9013100020090514012300...，\n[0077] 其中，GSS-IP是总部节点中一个可以服务的流媒体服务器的地址，GSS-Port是该流媒体服务器提供视频流媒体服务的端口号，然后GSE封装一个RTSP响应消息，消息中结果码填为302(MovedTemporarily，重定向，表示要完成请求必须进行进一步操作)，同时将新生成的URL填入响应包头(response-header)中的位置(Location)参数域中，然后返回给省分流媒体服务器。\n[0078] 步骤S508，LSS收到结果码为302的RTSP响应后，从响应消息包里response-header的Location域中取出新的URL发起中继请求。\n[0079] 步骤S509，GSS收到LSS的服务请求后定位到所请求的实体文件，开始向LSS发送码流数据。\n[0080] 步骤S510，LSS将收到的码流数据转发给用户设备，开始给用户提供点播服务。\n[0081] 在本实施例中以点播服务为例进行说明，同理，也可以扩展到直播和下载等媒体服务领域。以上所述仅为本发明的一种较好的实施方式，但本发明的保护范围并不局限于此，所有基于本发明的实质进行的各种替换和修改，均应属于本发明的权利保护范围。\n[0082] 装置实施例\n[0083] 根据本发明的实施例，提供了一种媒体服务系统，图6是根据本发明实施例的媒体服务系统的结构框图，如图6所示，中心节点可以连接一个或多个边缘节点，边缘节点包括：第一接收模块62、第一发送模块64、第二接收模块66、第二发送模块68，下面对该边缘节点进行详细的介绍。\n[0084] 第一接收模块62，用于接收来自用户设备的媒体服务请求，其中，媒体服务请求用于请求媒体资源；判断模块60连接至第一接收模块62和第一发送模块64，该模块用于判断边缘节点能否为用户设备提供媒体资源；第一发送模块64连接至第一接收模块62，用于在确定边缘节点不能为用户设备提供媒体资源的情况下，向中心节点发送请求消息；第二接收模块66连接至第一发送模块64，边缘节点接收来自中心节点响应于请求消息的媒体资源；第二发送模块68连接至第二接收模块66，用于将媒体资源发送给用户设备。\n[0085] 图7是根据本发明实施例的媒体服务系统具体的结构框图，如图7所示，第二接收模块66包括：第一接收子模块662、发起子模块664、第二接收子模块666，下面对此进行详细描述。\n[0086] 第一接收子模块662，用于接收来自中心节点的携带有用于提供媒体资源的媒体服务器地址的URL；发起子模块664连接至第一接收子模块662，用于根据URL向URL对应的媒体服务器发起媒体服务请求；第二接收子模块666，连接至发起子模块664用于接收来自URL对应的媒体服务器的媒体资源。\n[0087] 如图7所示，第一发送模块64包括：第一发送子模块642和第二发送子模块644，其中，第一发送子模块642，用于向用户设备发送携带有边缘节点的媒体服务器地址的URL，其中，URL中携带有边缘节点不能提供媒体资源的指示标识，以便于用户设备根据URL向URL对应的媒体服务器发起媒体服务请求；第二发送子模块644，用于在接收到来自用户设备的服务请求之后，向中心节点发送请求消息。\n[0088] 如图7所示，该边缘节点还包括：保存模块74，该模块用于根据预定策略保存媒体资源。\n[0089] 如图7所示，该中心节点包括：第三接收模块76、第三发送模块78，下面对该中心节点进行详细的介绍。\n[0090] 第三接收模块76，用于接收来自边缘节点请求消息，其中，请求消息用于请求媒体资源：第三发送模块78连接至第三接收模块76，用于将媒体资源发送给边缘节点。\n[0091] 可以看出，通过本发明描述的方法使各省分节点按照一定的策略保存系统中的部分内容资源，同时对于本地节点不存在的内容可以通过中继的方式提供服务，能有效地解决节点内容存储和提供稳定服务之间的矛盾，较好地优化了系统的资源共享能力。\n[0092] 显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。\n[0093] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。