[技术领域]
[0001] 本
发明涉及通信、计算机技术领域，具体地说是一种用于多媒体传送的自适应分块和内容感知同步设备及方法。[背景技术]
[0002] 最受欢迎的网络密集型计算机应用程序的其中一个就是互联网上的视频或多媒体播放。几年以前，人们认为，互联网由于其逐渐陈旧的协议以及缺乏有保障的传输的缘故，无法支持
质量令用户满意的视频播放。然而，如YouTube和Netflix等应用程序已经说明了，高质量的视频播放是能够实现的。
[0003] 创造了各种各样的机制来改善用户体验。例如，在一些
实施例中，拥有媒体播放器的用户在开始播放文件之前，
请求并接收全部的多媒体文件。这保证了，一旦文件开始播放，它能不间断地继续播放下去。尽管在短片的情况下，这种方案可以接受，但是出于多种原因，这种方案却不适用于较长的文件。首先，强迫用户在观看短片的任何部分之前进行等待，直到全部文件下载完毕。这样的等待可能难以容忍。第二，在网络带宽有限的环境中，即使用户只想观看视频中的前几秒，也必须传输全部文件。
[0004] 另一种方法称作渐进下载。在本实施例中，客户端开始从
服务器中下载多媒体文件。当达到一定的
阈值时，例如，已经完成了3秒钟的下载时，客户端上的媒体播放器开始显示视频。采用的阈值可以是固定的，或者也可以是基于文件的
分辨率、平均可用的网络带宽或者其他参数。这种方法比起前一种方法来说有几个优点。第一，用户不必在开始观看视频前进行等待，直到全部文件下载完毕。第二，如果用户选择在视频下载完毕之前离开该视频，那么潜在地节约了带宽。但是，该机制的一个缺点在于，一旦视频已经开始播放，可用的带宽必须保持在最低
水平之上，以保证视频后面的各部分能在需要显示之前下载完成。如果带宽降低了，视频可能变得时断时续，或者可能会停止播放，以在进行缓冲之后，重新播放。
[0005] 渐进下载方法通常以底层传输所支持的最大速率，在播放器缓冲区的限值(即，限制所下载的内容，防止超出TCP确认机制的播放器缓冲区)内下载多媒体内容。这些方法通过降低将内容传送至客户端缓冲区所引起的断断续续，来改善体验质量，从而使得播放器在内容呈现期间停止的可能性降到最低。但是，它的一个缺点在于，当传输网络带宽与
媒体流速率相比较高时，大量的内容被下载至播放器，以及，如果用户通过(例如)移到不同的媒体剪辑来取消当前的呈现，那么就浪费了用于未观看的所下载内容的网络带宽。
[0006] 另一个Adobe系统公司所使用的机制称作实时消息传送协议(RTMP)。该机制通过内容的受控流传输，来控制该内容借助TCP上的RTMP协议的递送。因此，流传输机制相对于当前播放给用户的内容，来维持递送给播放器的内容的一个窗口。因此，通过对递送至相对靠近当前显示
位置的位置的内容进行限制，降低了用户取消活动会话所浪费的带宽。RTMP还能选择将HTTP或者HTTPS用作传输选项。
[0007] 另一个机制是实时流传输协议/实时传输协议(RTSP/RTP)。在本协议中，服务器控制内容递送至呈现速率的速率，而不是以底层传输的最大速率进行递送，例如IP上的TCP或者UDP。
[0008] 此外，几个HTTP流传输协议已经定义来以与多媒体流速率相匹配的受控速率(由服务器确定或者基于客户端与服务器之间的配合来确定)，递送实时的或存储的多媒体内容。
[0009] RTMP以及HTTP流传输方法通过限制内容的递送速率，来对内容递送进行同步。RTMP采用客户端和服务器中的协议组件，而HTTP流传输采用HTTP请求和响应中的另外的标签。
[0010] 在自适应比特率流传输(ABR流传输)中，客户端在多媒体会话启动时监测服务器的带宽并且在多媒体播放期间定期地监测服务器的带宽。客户端直接完成了同一媒体内容的替代分辨率之间的切换。几个应用程序，例如Ankeena TV，在HTTP上采用ABR流传输，以递送实时内容。
[0011] 然而，在本协议中，确定可用带宽的是客户端。因此，在定期加入以及从特定小区中移除设备的无线
访问网络中，客户端对利用全部带宽的认识有限，这可能会影响其及时地且精确地预测适合的编码和屏幕分辨率的能
力。
[0012] 图1示出了传统的3G/UMTS网络，其中包括UE(用户设备)107、NodeB(或者说基站收发台)106、RNC(无线网络
控制器或者基站控制器)105、SGSN(服务GPRS支持
节点)104以及GGSN(网关GPRS支持节点)103。同样地如图1所示的协议用来在这些不同设备之间进行通信。例如，IuB 108是用于NodeB 106与RNC 105之间的协议。同样地，IuPS为用于RNC 105与SGSN 104之间的协议。Gn 110用于SGSN 104与GGSN 103之间。最后，Gi 111是GGSN 103与互联网之间的基于IP的
接口。
[0013] 如果无线访问网络中能够看到总网络流量的组件能够确定具体用户请求多媒体内容的时间，并且基于该总网络流量，能够对该多媒体内容的编码和分辨率进行配置，从而最大程度地改善用户的体验质量，那么这会是有利的。另外，如果通过对多媒体内容进行缓冲以及将该内容及时地递送至终端用户设备，该组件能够将无线RAN流量与核心网络流量分开，那么这也是有益的。[发明内容]
[0014] 本发明克服了先前技术的问题，提供了一种用于多媒体传送的自适应分块和内容感知同步设备及方法。
[0015] 一种网络设备，其适于在RAN网络上运行，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述设备包括：第一和第二接口组件，其适于分别与所述RAN网络中的第一和第二组件进行通信，使得所述接口组件中的其中一个将内容递送至所述RAN网络上的用户设备、存储设备以及控制逻辑，其适于对所述第一与第二组件之间的通信中的多种协议进行解析，以及基于所述通信，适于确定与所述内容的各时间间隔相关联的字节计数，并且基于所述确定的字节计数，控制所述内容递送至所述用户，进而对所述RAN网络的资源进行优化。
[0016] 所述内容在数据包中从内容源递送至所述接口组件中的一个，所述数据包包括所述内容，以及包括有关于所述内容的信息的标头。
[0017] 所述信息包括呈现时间和字节计数。
[0018] 所述控制逻辑适于创建传输调度，其包括有关于时间间隔和相关字节计数的信息。
[0019] 所述数据包采用FLV、MP4、3GP或3G2格式。
[0020] 所述控制逻辑确定了第一参数，其定义了发送至所述用户设备的一次数据量。
[0021] 所述控制逻辑确定了第二参数，其定义了在将所述内容递送至所述用户设备中的等待时间。
[0022] 所述控制逻辑监测所述RAN网络中的活动以及根据所述监测的活动，
修改所述第二参数。
[0023] 一种将内容递送至RAN网络上的用户设备的方法，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述方法包括：采用位于所述用户设备与内容服务器之间的网络设备来监测所述用户设备与所述RAN网络中的其他组件之间的通信，进而确定与所述将要递送的内容的各时间间隔相关联的字节计数，监测所述RAN网络中的活动，基于所述监测的活动，估计将所述内容递送至所述用户设备所需要的时间，确定时间间隔，所述时间间隔定义为在单个区段中传输至所述用户设备的内容量，将所述内容分割为多个区段，各区段包括大量的数据字节，其确定来提供需要消耗所述时间间隔的内容，将所述多个区段中的第一个区段传输至所述用户设备，在将所述多个区段中的第二个区段传输至所述用户设备之前，等待预定的时间，其特征在于，基于所述时间间隔和所述估计的递送所述内容的时间，来计算所述预定时间。
[0024] 在递送至所述用户设备之前，将所述内容存储于所述网络设备中的存储元件中。
[0025] 如果在所述预定时间过期之前，所述用户终止了所述内容的使用，那么不递送所述第二区段。
[0026] 一种对递送至RAN网络上的用户设备的内容进行控制的方法，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述方法包括：采用位于所述用户设备与内容服务器之间的网络设备来监测所述用户设备与所述RAN网络中的其他组件之间的通信，进而确定，所述用户设备正在对所述内容服务器作出针对可用格式列表的请求，将所述请求传输至所述内容服务器，从所述内容服务器接收所述列表，监测所述RAN网络中的活动，基于所述监测的活动，修改所述接收的列表，以及将所述修改的列表传输至所述用户设备。
[0027] 所述列表包括至少两种可用格式，并且所述网络设备在传输至所述用户设备之前，从所述列表中移除所述格式中的一种。
[0028] 一种对递送至RAN网络上的用户设备的内容进行控制的方法，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述方法包括：采用位于所述用户设备与内容服务器之间的网络设备来监测所述用户设备与所述RAN网络中的其他组件之间的通信，进而确定，所述用户设备正在向所述内容服务器作出针对可用格式列表的请求，监测所述RAN网络中的活动，基于所述监测的活动，修改所述请求，将所述修改的请求传输至所述内容服务器，以及从所述内容服务器传输一响应至所述用户设备。
[0029] 所述请求包括一请求高清晰度格式的标志位，并且所述网络设备在传输至所述内容服务器之前，从所述请求中移除所述标志位。
[0030] 一种将内容递送至RAN网络上的用户设备的方法，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述方法包括：采用位于所述用户设备与内容服务器之间的网络设备来监测所述用户设备与所述RAN网络中的其他组件之间的通信，进而确定具有第一分辨率的多媒体文件正从内容服务器递送至所述用户设备，监测所述RAN网络中的活动，从所述内容服务器接收包括有具有所述第一分辨率的所述多媒体文件的数据包，以及采用所述网络设备将所述数据包传输至所述用户设备，基于所述监测的活动，确定所述分辨率应修改至第二分辨率，请求将具有所述第二分辨率的所述多媒体文件从所述内容服务器递送至所述网络设备，以及将具有所述第二分辨率的所述多媒体文件从所述网络设备递送至所述用户设备。
[0031] 所述网络设备将具有所述第二分辨率的所述多媒体文件自动地进行递送。
[0032] 所述网络设备将其所述多媒体文件的递送进行修改，以使得所述用户设备请求具有所述第二分辨率的所述多媒体文件。
[0033] 所述网络设备降低了具有所述第一分辨率的所述多媒体文件的递送速率，从而使得所述用户设备请求具有所述第二分辨率的所述多媒体文件，其特征在于，所述第二分辨率小于所述第一分辨率。
[0034] 所述网络设备增加了具有所述第一分辨率的所述多媒体文件的递送速率，从而使得所述用户设备请求具有所述第二分辨率的所述多媒体文件，其特征在于，所述第二分辨率大于所述第一分辨率。
[0035] 一种将内容递送至RAN网络上的用户设备的方法，其特征在于，所述RAN网络中的组件采用多种协议进行通信，所述方法包括：采用位于所述用户设备与内容服务器之间的网络设备来监测所述用户设备与所述RAN网络中的其他组件之间的通信，进而确定所述用户设备正在向所述内容服务器作出针对内容的请求，监测所述RAN网络中的活动，只有在所述监测的活动低于预定阈值时，才将所述请求的内容传输至所述用户设备。
[0036] 如果所述监测的活动高于所述阈值，那么所述网络设备不会将所述请求转发至所述内容服务器。
[0037] 所述网络设备将所述请求转发至所述内容服务器，并且确定在从所述内容服务器接收所述内容的至少一部分之后，将所述内容传输至所述用户设备。
[0038] 如果所述活动高于所述阈值，那么所述网络设备将出错消息传输至所述用户设备。
[0039] 本发明同现有的技术相比，本发明是一种能够了解终端用户与RAN网络上的核心网络之间的通信的网络设备，该设备能够对控制面和用户面进行解码，这样的话，便能够确定终端用户请求多媒体内容的时间。一旦确定了时间，该设备就能够以几种方式对该内容的递送进行优化。在一个实施例中，该设备从内容服务器(位于核心网络中)请求内容，并且及时地将该内容传输给终端用户。在另一个实施例中，该设备基于整个所监测的网络流量，自动地对客户可用内容的编码和分辨率选项进行改变/限制，或者积极地控制用于特定流的带宽，从而使得终端用户设备启动切换并切换至不同的编码/分辨率。该设备基于整个带宽限制，以独立于终端用户的方式，自动地选择合适的格式和分辨率。[
附图说明]
[0040] 图1示出了示例性的蜂窝通信运营商的3GUMTS网络，其示出了3GPP标准所限定的网络元件以及这些网络元件之间对应的接口；
[0041] 图2示出了示例性的配置，其示出了本发明的实施例部署于3GPP/UMTS网络中的RNC与SGSN之间的IuPS接口上；
[0042] 图3示出了本发明根据一个实施例的方
框图。
[0043] 图4为示出了多媒体文件从内容服务器传输至用户设备的根据一个实施例的图；
[0044] 图5A至图5B示出了根据本发明所使用的调度文件的两个实施例。
[0045] 图中：103为网关GPRS支持节点(GGSN)、104为服务GPRS支持节点(SGSN)、105为无线网络控制器或者基站控制器(RNC)、106为基站收发台(NodeB)、107为用户设备(UE)、108为用于NodeB 106与RNC 105之间的协议(IuB)、109为用于RNC 105与SGSN 104之间的协议(IuPS)、110为用于SGSN 104与GGSN103之间的协议(Gn)、111为GGSN 103与互联网之间的基于IP的接口(Gi)，112为设备、201为接口组件(Interface Module)、202为存储元件(Storage Element)、203为控制逻辑/处理单元(Control Logic/Processing Unit)、204为本地存储元件(Local Storage)、205为缓存(Cache)。
[具体实施方式]
[0046] 图2说明了能够了解RAN网络上的通信的设备112并且示出了设备可插入至3G/UMTS网络中的拦截点。设备112位于RNC 105与SGSN 104之间。本图为3G/UMTS网络中的示例性的部署情况；尽管未示出其他RAN网络中(例如在CDMA网络中)的示例性部署情况，但是此处所述的方法同样也适用于这种网络。另外，设备112可位于3G/UMTS网络中的其他组件之间，例如NodeB 106与RNC 105之间，或者SGSN 104与GGSN 103之间。
[0047] 设备112能够了解UE 107与核心网络之间的通信。在一些实施例中，设备112能够对控制面和用户面进行解码。提交于2009年8月6日的共同待决的
专利申请No.12/536537中描述了这种设备，其全文以引用的方式并入本文。这样便能确定UE 107请求多媒体内容的时间。一旦确定了时间，设备112就能够以几种方式对该内容的递送进行优化。在一个实施例中，设备112从内容服务器(位于核心网络中)请求内容，并且及时地将该内容传输给UE 107。在另一个实施例中，设备112基于整个所监测的网络以及客户端设备的流量，对客户可用的编码/分辨率选项进行改变/限制，和/或为特定多媒体流改变递送速率(带宽)，从而使得客户端设备启动切换并切换至不同的分辨率。如果可用带宽不足以接纳新请求的
视频流，那么设备112可停止发送该视频，或者返回表明资源不可用的出错代码，从而改善网络资源对其他用户的公平分配，并且不会降低已经开始的多媒体流的体验质量。在另一个实施例中，设备112给予整个带宽限制，以独立于UE 107的方式，选择合适的格式和分辨率。
[0048] 图3示出了设备112的代表性方框图。设备112具有两个接口模块201，各模块适于实现选择接口和相关的
软件协议所需要的
硬件信令。本接口协议可以是IuB、IuPS或者Gn，如图2所示。各接口模块201适于在所选择的接口上进行接收和传输。另外，所接收的数据放置于存储元件202中，通常是
半导体存储元件，例如，RAM、DRAM或者等同技术。数据从接口模块传送至
存储器202以及其反向的传送都可采用专用硬件来完成，例如DMA控制器。或者，可以采用专用数据传送处理器来处理数据在设备112中的实际传送。信息一存储于设备112内，就根据RAN规范对该信息进行处理。这可以通过采用专用控制逻辑或者处理单元203来实现。控制逻辑/处理单元203可以具有自己的本地存储元件204，其包含将要执行的指令和本地状态。该存储元件可以是RAM或者DRAM。另外，存储元件204的至少一部分可以是不易挥发的，例如ROM、FLASH ROM、
硬盘、固态硬盘或者其他。控制逻辑/处理单元203采用已知的规范和协议，对所接收的信息进行解析，以了解各协议层的数据包。同样还可包括有大型存储元件205，其适于容纳缓存信息。在一些实施例中，该缓存存储元件可以是半导体存储器，例如RAM或者DRAM。在其他实施例中，该缓存存储元件可以是旋转介质，例如磁盘
驱动器或者其他大型存储设备。控制逻辑/处理单元可在各种技术中以实体形式实现。例如，它可以是通用处理器，执行来自内部存储设备或者外部存储设备的一套指令。
[0049] 在另一个实施例中，具有嵌入式指令的专用硬件设备或者状态机可用于执行所述功能。在本文全部所公开的内容中，术语“控制逻辑”和“处理单元”可交换使用，以
指定一种适于执行所述的一套指令的实体。
[0050] 该设备还包含能够执行本文所述的功能的软件。本软件可以任何合适的编程语言进行写入，并且本发明并不对其语言选择进行限制。另外，所有本文所述的应用程序和软件都是包含于计算机可读介质上的计算机可执行指令。例如，软件和应用程序可存储于
只读存储器、可重写存储器或者嵌入式处理单元中。执行本软件的特殊计算机是依赖于应用程序的，并且不受到本发明的限制。
[0051] 具体地，在一个实施例中，本
软件包括内容感知同步
算法。本算法对在容器文件中递送的文件参数进行监测。基于这些参数和可用的RAN带宽，该同步算法以这种方式将多媒体数据递送至UE 107，从而对播放质量和RAN网络使用进行优化。
[0052] 如上所述，客户端或UE 107可拥有媒体播放器，例如基于Flash的视频播放器。媒体播放器通常在视频开始播放之前，缓冲预定量的数据。但是，一旦媒体播放器开始显示内容，那么播放器所需量的内容就必须在显示之前递送至客户端，从而避免视频的时断时续。因此，设备112，具体地说是内容感知同步算法，采用称为keep_ahead的第一配置参数，其是在很短时间内测量的数据量并且在开始播放视频之前需要。换句话说，视频文件在媒体播放器中进行播放，并且这样的话，显示内容所花费的时间可以确定。因此，当提供了keep_ahead量的数据时，众所周知，该数据量需要keep_ahead秒进行显示。需要注意的是，该数据量是根据时间进行测量的。因此，基于
视频编码和压缩，分别提供keep_ahead数据总量的两个区段可包括不同数量的字节。
[0053] 第二配置参数称为latency_period，其为从UE 107到递送内容的网络设备或服务器的往返时延(RTT)。在内容递送期间，以不同的间隔估计该往返时延，或者该往返时延能够预先进行配置。参数latency_period旨在对网络延迟的变化进行补偿，进而确保递送时避免了时断时续。通常，UE 107中的媒体播放器在开始进行呈现前需要keep_ahead秒的数据，并且在播放期间，需要继续接收该数据量，从而使得播放器在播放期间不会将数据用完。如果网络无法跟上，即无法保持继续填充缓冲，那么就会迫使播放器暂停并且在内容的播放期间时断时续。
[0054] 换句话说，在一个简单的实例中，设备采用10秒的keep_ahead参数和2秒的latency_period。在这种情形下，设备112在10秒分块中将内容发送至UE107。在知道可能要花费2秒钟(即latency_period)将下一个分块传送至UE 107之后，设备112可能会在8秒钟(即keep_ahead-latency_period)之后开始传输下一个分块。为了进行本方案，设备112需要知道所请求的内容确实是多媒体，并且还必须知道各时段所需要的数据量。
[0055] 当前发明的设备和方法采用了存储于容器文件中的描述了视频目标的元数据，并且利用该信息，与预先读取缓冲的预定量一起保证视频的体验质量(QOE)得以保留。在一些实施例中，容器文件称为.flv文件。感兴趣的读者可以参考http://www.adobe.com/devnet/flv/上对FLV文件格式的完整说明。也存在有其他的容器文件格式，并且本发明并不限于本特殊格式。需要注意的是，设备112基于其监测的媒体容器型元数据，构建了递送调度，并且在视频首先进行存取但还未进行缓存时，从输入流进行解码。
[0056] 如上所述，并且在共同待决的专利申请No.12/536537中，设备112拦截所有UE107与核心网络之间的通信。然后，对所有来自UE 107的流量进行解封，以了解正在发生的通信，并且在将流量向上游侧传输至核心网络前，
对流量进行重新封装。类似地，设备112对来自核心网络的流量进行解封，从而了解返回至UE 107的通信。如前所述，该设备还在将数据传输至UE 107之前对其进行解封。在一个实施例中，当UE 107请求下载视频时，设备112可任选地对核心网络中的内容服务器所返回的FLV文件进行解析，从而确定视频的细节。每秒钟将要下载的字节数通过设备112中的内容感知同步算法进行计算。为实现完整性，对FLV文件格式进行了简短的说明。
[0057] FLV文件包含标头和主体。标头包含关于文件的主体中是否有视频/音频内容的信息。文件的主体对流进行了说明并且由一套标签组成。标签包含流类型、数据长度以及数据呈现的时间。例如，标签可能包括，该流为包含应在短片中呈现40秒的99K字节的视频流。标签的类型可以是以下三种：音频、视频或者脚本数据。视频标签对包括有
帧类型、编码
解码器id以及数据的帧进行说明。帧类型可以是下面五个选项中的一种：关键帧、中间帧、仅用于H.263的可随意使用的中间帧、生成的关键帧或者命令帧。进一步地，该标签包含有关于所使用的编码解码器的类型(JPEG、H.263、屏幕视频、AVC等)的信息。内容感知同步算法利用FLV标签中的时间戳和数字大小参数。但是，它能使用其他信息，例如可随意使用的中间帧，来在缓存欠载的情形下将帧丢弃。尽管本文所述的操作采用的是FLV类型的媒体容器，但是当前方法也适用于其他容器类型(例如，MP4、3GP、3G2)，并且不受本发明的限制。
[0058] 内容感知算法对FLV标签进行解析，以获得时间戳和数字大小参数。对于VBR(动态比特率)视频来说，需要播放一秒钟视频的数据量都是变化的。内容感知同步算法基于从FLV文件中解析的信息，创建出传输调度。它计算每秒钟需要从用于帧递送的时间戳递送的数据量以及相关的数据长度。在一些实施例中，本传输调度是在从内容服务器接收到文件时产生的，并且只保持到内容传输至UE 107时。在其他实施例中，传输调度以每秒钟信息的形式存储于调度文件中。本调度文件可存储于设备112的存储元件202中。调度文件包含用于每秒钟将要提供的视频内容量的表项。内容感知同步算法采用该调度文件，与配置的缓冲参数一起实现视频内容及时地递送至终端用户。
[0059] 当前发明的自适应分块内容感知同步算法通过对内容数据大小的下载进行调度而启动，从而满足keep_ahead秒的播放时间。由于底层传输为TCP，因此发送调度分块的实际递送时间取决于客户端实现的链路带宽。下一次数据分块递送发生于(当前_时间+keep_ahead-latency_period)。根据与视频目标相关的调度文件，来确定数据量。假设有5秒钟的keep_ahead和1秒钟的latency_period，那么下一次分块在4秒钟时进行调度。
之后的分块在前一次分块传输后4秒钟进行调度。尽管实例示出了定期间隔的突发调度，但是分块的调度间隔的变化可取决于媒体播放中的当前位置，以及在以前的分块或其他多媒体、网页和文件等传输至相同的客户端设备或者其他共享同一扇区的设备时客户端链路带宽的相对变化。每次突发时会发送最低的keep_ahead数据总量。各数据分块递送发生于底层网络层所支持的最大传送速率下。
[0060] 当视频内容递送至设备112时，视频递送调度逐渐建立起来，并且任选地写入调度文件中，图5A至图5B示出了调度文件的实例。如上所述，在其他实施例中，生成了视频递送调度并且其只保持到内容传输至UE 107时。调度文件包含一每秒钟表项。在图5A中，各表项包含两个字段：1)几秒钟内的播放时间以及2)需要递送至终端用户(数据n)的多th媒体内容的字节累计数。因此，在’n’ 秒内将要递送的数据为(数据n-数据n-1)。一旦完全建立了调度，便停止进行流解析。本调度还能够离线生成，并且保持为具有视频目标的元数据信息，或者如上所说明的那样，它能动态且逐渐地建立。
[0061] 图4示出了详细说明设备112、内容服务器和UE 107之间的通信的图。如上所述，当UE 107从内容服务器请求多媒体文件时，事务开始。设备112对本信息进行解析，以了解事务可以采用内容感知同步算法进行同步。设备112将请求转发至内容服务器。作为响应，内容服务器将数据块返回，其中，各数据块包括标头，如FLV格式，其详细说明了关于数据的特定信息，例如其比特长度和其呈现时间。设备112继续从内容服务器接收该信息并且在其内部存储器或存储元件中对多媒体文件进行缓存。同时，设备112能够开始创建调度文件，例如图5所示的调度文件，其示出了各时段所需的累计字节。在其他实施例中，例如，如图5B所示的实施例中，调度文件存储各时间间隔所需的字节，而不是累计的或者连续的字节计数。
[0062] 由于设备112从多媒体内容接收数据字节，因此它将该数据进行发送，直到已经有keep_ahead字节的数据传输到了UE 107。一旦如此量的数据传输到了UE 107，那么如上所述，设备112便中止下来，直至下一次配置分块递送时间。设备112将其从内容服务器接收的任何字节存储于(例如)缓存205中，以用于以后传输至UE 107。设备112继续从内容服务器接收数据并且继续建立调度文件。在规定时刻，例如前一次传输后的keep_ahead-latency_period秒，设备112将keep_ahead字节的数据的第二数据包发送至UE107。这种情况一直持续，直到完成了该文件的完全传送或者直到用户离开了该视频。通常情况下，后一行为可由设备112通过终止UE 107的TCP连接来检测到。需要注意的是，设备112通常接于一侧(即到/来自内容服务器)上，其通常为有线线路并且由此具有更容易预测的带宽和等待时间特性。设备112也接至UE 107，在此处，无线连接以及变化的设备数量和使用模式对等待时间产生影响。因此，设备112用作将这两个接口进行分离，使得内容服务器在一个速率上递送数据并且将数据以第二速率同步至UE 107。
[0063] 尽管图4示出了设备112从内容服务器接收内容，但是应当注意的是，同步算法可与之前缓存的内容一起使用。在本实施例中，设备112具有所需内容的副本，并且具有之前建立的调度文件。如上所述，采用该信息，同步算法能够将内容传输至UE 107。
[0064] keep_ahead和latency_period参数的确定可以各种方式完成。在一些实施例中，这些值为固定的并且对于所有UE来说都是恒定不变的。在其他实施例中，参数基于网络条件而发生变化。例如，latency_period最明显地与整个网络带宽相关。设备112能够监测实际的RAN带宽并且实时地调节latency_period参数。在其他实施例中，本参数可基于其他特性而发生变化，例如当天的时间。例如，设备112可在晚上的几个小时期间缩短latency_period，这是因为所期待的网络流量较低。在其他实施例中，latency_period可基于之前监测的用于UE 107的带宽。
[0065] 同样地，keep_ahead参数可以多种方式进行修改。keep_ahead参数的最优值的选择是基于平衡两个竞争目标。一方面，较小的keep_ahead值使得视频能够在UE 107上较早地开始播放。如果用户离开该视频，这些较小的值还使得浪费的带宽降到最低。另一方面，较大的keep_ahead值不容易出现网络带宽的突发变化，从而使得中止或断断续续的可能性降到最低。如上所述，所监测的网络带宽、当天的时间、之前观察到的带宽或者其他特征能够用来设置或修改keep_ahead参数。
[0066] 出现缓存欠载是可能的，这时，服务器无法将keep_ahead数据总量在规定的时间间隔内发送出去，在这种情形下，内容感知同步算法将数据以底层传输层支持的任何速率发送出去，并且此处无法看到同步所带来的好处。但是，任选地，关于可随意使用的中间帧的信息可在此处用来在欠载的情形下放弃中间帧。
[0067] 在另一个实施例中，设备112能够基于网络活动来修改和选择视频格式和分辨率。而且，由于设备112能够拦截和解封用户面和控制面，因此它能够确定从UE 107至内容服务器的请求的内容。因此，设备112能够适当地修改这些响应或者针对这些请求的回复。采用这种技术，设备112能够实现网络控制比特率选择。这使得设备112能够设置初始分辨率，而这被称为网络控制比特率选择。
[0068] 在一个实施例中，UE 107从内容服务器，例如YouTuBe，请求视频短片。作为响应，内容服务器可提供其中可获得该视频的不同分辨率的列表。该列表可称为格式地图。通常，该列表传输至UE 107，随后，UE 107选择特定的分辨率。然而，知晓该事务的设备112可基于观察到的网络带宽，对返回至UE 107的格式地图进行修改。例如，客户端可向240至720p请求能以多种格式得到的视频。作为来自客户端的请求的响应，内容提供商提供格式的完全列表。设备112可基于观察到的带宽来确定，在不出现中止或断断续续的前提下，显示该视频的720p版本是不可能的。因此，在将该响应发送回客户端前，设备112对响应进行修改，并且去除任何其要求的带宽超出了当前可用带宽的格式。因此，客户端接收的响应仅包含那些设备112认为能够以可接受的体验质量来显示的格式。
[0069] 在另一个实施例中，来自UE 107的请求可包含标志位，例如“&hd＝1”，表明内容服务器应该包括格式地图中的高清晰度版本的视频。确定了高清晰度视频无法正确地显示的设备112可在请求传输至内容服务器之前，对其进行修改，其修改的方式是通过(例如)移除标志位“&hd＝1”。这样，内容服务器将只返回那些非高清晰度的格式。
[0070] 因此，通过修改到内容服务器的请求或者修改来自内容服务器的响应，设备112能够修改UE 107所接收的格式地图。
[0071] 在另一个实施例中，设备112在传输期间修改视频的分辨率。例如，已知的有HTTP上的平滑流传输或者自适应流传输。在这种机制下，客户端继续监测其感知的网络带宽并且实时地调节正在播放的视频的分辨率和格式。换句话说，客户端可播放720p版本的视频并检测到网络带宽已经大幅减少。作为响应，客户端可在不关闭媒体播放器的情形下请求该视频的较低分辨率的版本，从而改变流间分辨率。Microsoft Silverlight、Netflix播放器以及Adobe OSMF中存在有这项技术的变化。尽管如此，在所有这些实施例中，确定可用带宽的是客户端。因此，客户端通常对带宽的变化(积极地和消极的)产生反应。
[0072] 由于网络中设备的数量以及流量的量能够快速且不可预见地变化，因此RAN网络提出了独特的要求。因此，一个组件，例如设备112，能够对网络活动进行监测并且作出改变视频分辨率的决定，将是有利的。在一个实施例中，设备112将视频数据传输至UE 107。这可以根据以上所述的技术，或者采用其他传统方法来完成。在视频进行传输同时，设备112持续地对网络活动进行监测。如果注意到了网络带宽的变化(积极的或消极的)，那么设备112能够进行适应。
[0073] 在一个实施例中，设备112在确定RAN的带宽发生变化之后，开始向内容服务器请求替代分辨率(如果它未进行缓存)。一旦设备112已经接收了替代分辨率的视频，那么它便自动开始将视频传输至UE 107。设备112可识别出就近的用于该事务的边界点(例如，关键帧或者在GOP帧边界)。本实施例假设UE 107的媒体服务器能够适应设备112单方面作出的分辨率上的变化。
[0074] 在其他实施例中，如果变化是由媒体播放器自身所请求的，那么UE 107的媒体播放器仅能适应分辨率上的变化。在本实施例中，设备112可修改其行为，从而鼓励媒体播放器改变分辨率。例如，假设RAN的带宽大幅度增加。为了使媒体播放器请求高分辨率格式的视频，设备112可
加速将视频数据递送至UE107，从而填充或克服其缓冲。这种针对UE 107的
数据速率的提高可使得媒体播放器请求更高分辨率的格式。相反，设备112可减缓其数据到UE 107的递送，从而使得媒体播放器的缓冲全部消失或者接近全部消失，进一步促使媒体播放器请求更低分辨率的版本。
[0075] 如果这些技术与初始分辨率选择结合来一起使用，那么基于实际监测的流量和拥挤，网络就能够确定并优化整个RAN中的视频分辨率。
[0076] 在另一个实施例中，设备112解析UE 107与核心网络之间的通信，以确定UE 107正在请求多媒体文件。知晓这类多媒体文件所需要的带宽的设备112首先确定RAN的可用带宽。例如，如果仅存在有很少的其他流量，那么设备112将兑现该请求。然而，如果因为大量的设备、大量的数据密集型事务或者这些因素的组合而导致可用带宽较低，那么设备112可拒绝UE 107的请求。在这种情形下，如果可用带宽高于预定阈值，那么设备112可返回出错消息或者简单地不将文件递送至UE 107。在一些实施例中，设备112在数据请求转发至内容服务器之前拒绝该请求。在其他实施例中，设备112决定在从内容服务器接收至少一部分文件之后，但是在将内容递送至UE 107之前，拒绝该请求。
[0077] 本文所采用的术语和表达仅用作说明性术语，并不具有限制性，并且在使用这类术语和表达时，并不意图将已示出和说明的特性的任何等同物(或其部分)加以排除。还应知道的是，各种位于
权利要求书的保护范围之内的修改都是可能的。其他修改、变化和替代也是可能的。因此，前述描述仅通过实例进行体现并且并不旨在具有限制性。
