本申请是申请日为2014年2月27日、申请号为201480006026.5、题为“链路感知流传输自适应”的发明专利申请的分案申请。
背景技术：
包括流传输服务和对话服务在内的多媒体服务的增长是向新的移动宽带技术和标准演进的一个关键驱动。移动设备中正越来越多地消费数字视频内容。在日常生活中存在许多在移动设备上广泛使用的视频应用。例如，在线视频流传输包括诸如youtube和hulu之类的流行服务。视频记录和视频会议包括诸如skype和googlehangout之类的服务。在2011年，youtube具有超过1万亿的全球观看量。这些观看中的百分之十是通过移动设备或平板访问的。随着更多的智能电话、平板、和其它移动计算设备被购买，它们对于视频记录和视频会议的使用将剧烈增加。随着对于多媒体服务的如此高的消费需求加上媒体压缩和无线网络基础架构的发展，增强未来的蜂窝和移动宽带系统的多媒体服务性能、以及向消费者递送较高的体验质量(qoe)从而确保用任何设备和技术在任何时候从任何位置对视频内容和服务的无所不在的访问是令人感兴趣的。
技术实现要素：
根据本申请的一方面，公开了一种可操作以接收超文本传输协议(http)自适应流传输(has)的移动设备，该移动设备具有计算机电路，该计算机电路被配置为：从节点接收针对http自适应流的清单文件；确定移动设备与节点的物理层有效吞吐量；以及至少部分地基于物理层有效吞吐量，选择清单文件中用于选定时段的表示。
根据本申请的一方面，公开了一种用于在移动设备处接收超文本传输协议(http)自适应流传输的方法，包括：从节点接收针对http自适应流(has)的清单文件；确定移动设备与节点的物理层有效吞吐量；以及至少部分地基于物理层有效吞吐量，确定请求has的比特率、或者提供has的期望质量等级。
根据本申请的一方面，公开了至少一种非暂态机器可读存储介质，包括被适用于被执行以实现上述用于在移动设备处接收超文本传输协议(http)自适应流传输的方法的多个指令。
根据本申请的一方面，公开了一种可操作以执行链路感知流传输自适应的用户设备(ue)，该ue具有计算机电路，该计算机电路被配置为：确定ue与web服务器的数据链路的物理层有效吞吐量和更高层吞吐量估计；从web服务器接收针对http自适应流(has)的清单文件；基于数据链路的无线电链路条件，确定是使用物理层有效吞吐量还是使用更高层吞吐量估计；以及基于所选择的物理层有效吞吐量或者更高层吞吐量估计来选择用于has的表示等级和帧数目，其中ni和qi分别表示所请求的帧数目和表示等级。
附图说明
本公开的特征和优点将从随后结合附图的详细描述中变得清楚，该附图通过示例的方式一起示出了本公开的特征；并且其中：
图1示出了根据示例的媒体呈现描述(mpd)元数据文件配置的框图；
图2示出了根据示例的超文本传输协议(http)流传输的框图；
图3示出了根据示例的用于基于超文本传输协议的(基于http的)链路感知自适应流传输的无线电接入网络(ran)架构的框图；
图4示出了根据示例的由客户端用于计算帧数目和表示等级的帧等级的图示；
图5示出了根据示例的链路感知自适应流传输客户端播放器状态的图示；
图6示出了根据示例的链路感知速率自适应流程图；
图7示出了根据示例的延迟受限的质量优化启动流程图；
图8示出了根据示例的可操作以接收超文本传输协议(http)自适应流传输(has)的移动设备的计算机电路的功能；
图9示出了根据示例的用于接收超文本传输协议(http)自适应流传输的方法的流程图；
图10示出了根据示例的可操作以执行链路感知流传输自适应的用户设备(ue)的计算机电路的功能；以及
图11示出了根据示例的无线设备(例如，ue)的图示。
现在将参照所示出的示例性实施例，并且本文将使用具体语言来描述相同内容。然而，应该理解的是不旨在限制本发明的范围。
详细描述
在本发明被公开和描述之前，应该理解的是本发明不限于这里公开的特定结构、处理步骤、或材料，而是被扩展至将被相关领域的普通技术人员认识到的其等同形式。还应该理解的是，这里所采用的术语仅被用于描述特定示例的目的并且不旨在是限制性的。不同附图中的相同标号表示相同的元件。流程图和过程中所提供的标号被提供用于清楚说明步骤和操作并且不一定指示特定的次序或顺序。
示例实施例
下面提供了技术实施例的初步概述，然后将进一步详细描述具体的技术实施例。该初步的概述旨在帮助读者更快速地理解技术，而不是旨在标识技术的关键特征或必要特征，也不旨在限制所要求保护的主题的范围。
超文本传输协议(http)自适应流传输(has)可被用作互联网视频的多媒体递送的一种形式。基于http的递送由于广泛采用了http和http的底层协议(包括传输控制协议(tcp)/互联网协议(tp))二者)，可提供可靠性和部署简易性。基于http的递送可通过避免网络地址转换(nat)和防火墙穿越问题来使能容易和不费力气的流传输服务。基于http的递送或流传输还可提供使用标准http服务器和缓存而不使用专用的流传输服务器的能力。由于服务器侧的最少或缩减的状态信息，基于http的递送可提供服务器侧上的可扩展性。
当使用has来递送互联网多媒体内容时，在移动设备上运行的视频客户端可以被配置为通过从视频服务器选取并请求适当视频显现等级来在速率自适应(adaptation)中起主要作用，该视频服务器使用httpget或部分get命令来从指定资源(例如，多媒体服务器)取回数据。视频客户端最初在开始播放流传输的多媒体内容(例如，音频或视频)之前，将缓冲器累积到某一等级。此阶段被称作启动阶段。此后，客户端开始播放缓存的多媒体内容。
在客户端设备处播放的多媒体的质量和分辨率取决于可用的链路带宽。视频客户端通常仅仅基于更高层吞吐量估计(例如，http级视频流传输吞吐量、或传输控制协议(tcp)吞吐量)来估计可用链路带宽。这样的方式在跟踪无线网络中发生的信道条件的快速变化时具有局限性。在跟踪变化时的这些局限性会限制速率自适应算法适应链路条件变化的能力。此外，使用更高层吞吐量估计来估计可用链路带宽在接收到前几个视频帧之前是不可用的。
根据本发明的一个实施例，通过针对has系统(例如，被配置为使用http动态自适应流传输(dash)标准的系统)使用物理层感知视频自适应方法，可以为无线网络中的has提供对可用带宽的更好估计。这一方法特别适合于其特性随时间波动(取决于物理环境以及系统上的负荷)的无线链路。
在一个实施例中，作为对传输层或应用层的更高层估计的补充，可以基于物理层吞吐量信息来估计可用链路带宽信息。在蜂窝场景中，这样的信息由用户设备(ue)的无线电组件提供至has客户端的视频自适应模块。
链路带宽信息的使用可以被用作has中的可选特征，其中仅当关于链路条件、缓冲状态、或其它期望标准的某些条件满足时，物理层吞吐量可以被用于视频速率自适应。例如，当对更高层吞吐量的良好估计不可用时，可使用物理层吞吐量。更高层吞吐量估计在流传输会话开始时的精度有限。另外，物理层吞吐量可以在无线信道条件正相对快速地变化时被使用。可以设定阈值来确定无线信道条件的变化量，其使得物理层有效吞吐量(goodput)测量可以被用来替代更高层吞吐量估计。阈值等级可以基于系统设计和用途而改变。在一个实施例中，如果更高层吞吐量估计将使has的多个视频帧的实际吞吐量降低超过选定的百分比(相对于物理层有效吞吐量的使用)，则可以使用物理层有效吞吐量。阈值可从诸如0.1％之类的小百分比变化到诸如20％之类的相对高的百分比，这取决于无线设备在其中运行的系统的类型。
当信道条件频繁改变时(例如，当无线设备正在移动时)，更高层吞吐量估计对无线链路条件改变的跟随是延迟的。快速的无线信道变化可以通过观察物理层吞吐量随时间的趋势来进行推断。使用物理层吞吐量估计的能力使得多媒体播放器能够随机地适应信道波动并通过处置用户视频质量和重缓冲百分比的关键性能度量来提升用户的体验质量(qoe)。
在一个实施例中，基于物理层链路条件和缓冲状态随机地适应视频速率的视频速率自适应算法的使用可被用于在可容忍的启动延迟下提升启动视频质量并且减少视频播放期间的重缓冲。因此，用户的qoe可以被显著地提升。这将在后续段落中进一步描述。
无线多媒体标准
已经开发出了多种多媒体标准，以使得多媒体能够被传送至移动计算设备、从移动计算设备被传送、或者在移动计算设备之间传送。例如，在流传输视频方面，第三代合作伙伴计划(3gpp)已经开发了技术规范(ts)26.234(例如，11.0.0版本)，该技术规范描述了基于用于按需内容或直播内容的单播流传输的实时流传输协议(rtsp)的分组交换流传输服务(pss)。此外，在3gppts26.247(例如，11.0.0版本)中描述了基于超文本传输协议(http)的流传输服务，其包括渐进式下载(progressivedownload)和http动态自适应流传输(dash)。基于3gpp的多媒体广播多播服务(mbms)规范ts26.346(例如，11.0.0版本)规定了针对多播/广播内容分发的流传输和下载技术。这样，基于dash/pss/mbms的移动计算设备(例如，用户设备(ue))在ue设备处解码并显现被流传输的视频。对3gppts26.244中3gp文件格式的支持在所有这些规范中都是强制的，以支持文件下载和基于http的流传输使用情形。
用于诸如视频会议之类的对话视频通信的标准的一个示例被提供于3gppts26.114(例如，11.0.0)中。该标准描述了ims多媒体电话服务(mtsi)，其允许通过基于互联网协议(ip)多媒体子系统(ims)的网络来递送高级多媒体对话服务和内容。ims在3gppts26.140(例如，11.0.0版本)中被标准化。基于mtsi的发射机ue终端可以捕获并记录视频，然后通过3gpp网络将视频转送至基于mtsi的接收机ue终端。接收机ue终端然后可以解码并显现视频。3gppts26.140还使能使用多媒体共享服务(mms)的视频共享，其中提供了对3gp文件格式的支持。
上文所述的标准是作为可被用于将多媒体文件传送至多媒体设备、从多媒体设备传送多媒体文件、和/或在多媒体设备之间传送多媒体文件的无线多媒体标准的示例而提供的。这些示例并不意图是限制性的。其它标准可被用于提供流传输视频、对话视频、或视频共享。
流传输媒体标准
这里结合本发明的实施例的上下文提供了对http流传输(以及更具体地，dash标准)的更详细描述。详细描述并不意图是限制性的。如在后续段落中进一步所述的那样，本发明的实施例可以被用于：通过使得移动设备或者与移动设备通信的服务器选择和/或传送具有期望能量表征的多媒体，高效地将多媒体传送至移动设备、从移动设备传送多媒体、和/或在移动设备之间传送多媒体。可使用标准化的或者非标准化的通信方案来传送多媒体。
超文本传输协议(http)流传输可被用作互联网视频的多媒体递送的一种形式。在http流传输中，多媒体文件可被划分为一个或多个片段(segment)并被使用http协议递送至客户端。基于http的递送由于http和http的底层协议(包括传输控制协议(tcp)/互联网协议(tp))二者被广泛采用，可提供可靠性和部署简易性。基于http的递送可通过避免网络地址转换(nat)和防火墙穿越问题来使能容易和不费力气的流传输服务。基于http的递送或流传输还可提供使用标准http服务器和缓存而不是专用的流传输服务器的能力。由于服务器侧的最少或缩减的状态信息，基于http的递送可提供服务器侧上的可扩展性。http流传输技术的示例可包括microsoftiis平滑流传输、applehttp实时流传输、以及adobehttp动态流传输。
dash是标准化的http流传输协议。如图1中所示，dash可以规定媒体呈现描述(mediapresentationdescription，mpd)元数据文件102的不同格式，其中该媒体呈现描述元数据文件102提供关于服务器中存储的媒体内容表示的结构和不同版本、以及片段格式的信息。mpd元数据文件包含关于媒体播放器的初始化和媒体片段的信息(例如，媒体播放器可查看初始化片段以确定容器格式和媒体定时信息)，以确保将片段映射到媒体呈现时间轴中用于与其他表示进行切换或者与其他表示的同步呈现。dash技术还通过其它组织(例如，运动图像专家组(mpeg)、开放iptv论坛(oipf)、以及混合广播宽带tv(hbbtv))被标准化。
dash客户端可通过经由一系列http请求-响应处理下载片段来接收多媒体内容。dash可提供随着到移动设备的可用带宽改变而在媒体内容的不同比特率的表示之间动态切换的能力。因此，dash可允许对变化的网络和无线链路条件、用户偏好、和设备功能(例如，显示器分辨率、所采用的中央处理单元(cpu)的类型、或可用的存储器资源等)的快速适应。相比其他流传输协议，dash的动态适应能够为用户提供更高的体验质量(qoe)以及更短的启动延迟和更少的重缓冲事件。
在dash中，媒体呈现描述(mpd)元数据102可提供关于存储于如图2中所示的web/媒体服务器212中的媒体内容表示的结构和不同版本的信息。在图1中所示的示例中，mpd元数据被暂时划分为具有预定长度的时段，例如在此示例中为60秒。每个时段可包括多个适应集(adaptionset)104。每个适应集可提供关于具有多个经编码的替代物的一个或多个媒体组件的信息。例如，此示例中的适应集0可包括各种不同的经编码的音频替代物，例如不同的比特率、单声道、立体声、环绕声等。除了在时段id上为多媒体呈现提供不同质量的音频外，适应集还可包括不同语言的音频。适应集中所提供的不同替代物被称为表示106。
在图1中，适应集1被示出为以不同的比特率(例如，5兆比特每秒(mbps)、2mbps、500千比特每秒(kbps)、或特技模式)提供视频。特技模式可被用于多媒体流传输文件中的位置的寻找、快进、倒退、或其它改变。此外，视频还可在不同的格式(例如，二维(2d)或三维(3d)视频)下可用。每个表示106可包括片段信息108。片段信息可包括初始化信息110和实际媒体片段数据112。在此示例中，mpeg-4(mp4)文件被从服务器流传输到移动设备。虽然在此示例中使用了mp4，但可以使用各种不同的编解码器，如前所述。
适应集中的多媒体还可被划分为更小的片段。在图1的示例中，适应集1的60秒的视频片段被进一步划分为四个子片段112，每个子片段为15秒。这些示例并不意图是限制性的。适应集和每个媒体片段或子片段的实际长度取决于媒体的类型、系统需求、可能的干扰类型等。实际媒体片段或子片段可具有不到一秒至数分钟长的长度。
如图2中所示，mpd元数据信息可被传送至诸如移动设备之类的客户端220。移动设备可以是被配置为接收和显示流传输媒体的无线设备。在一个实施例中，移动设备仅可执行一部分此功能，例如接收流传输媒体然后将它传送至另一设备或显示设备进行显现。移动设备可被配置为运行客户端220。客户端可使用httpget(http获得)240消息或一系列部分get消息来请求片段。客户端能够控制流传输会话(例如，管理片段序列的按时请求和平滑播出，或者可能地调整比特率或其他属性)来对无线链路、设备状态、或用户偏好的改变做出反应。
图2示出了基于dash的流传输框架。web/媒体服务器212中的媒体编码器214可以将来自音频/视频输入210的输入媒体编码为用于存储或流传输的格式。媒体分段器216可被用于将输入媒体划分为一系列片段232，该一系列片段可被提供给web服务器218。客户端220可以使用被发送至web服务器(例如，http服务器)的httpget消息234来请求片段中的新数据。
例如，客户端220的web浏览器222可以使用httpget消息240来请求多媒体内容。web服务器218可以向客户端提供用于多媒体内容的mpd242。mpd可被用于载送每个片段的索引和片段的相应位置，如相关联的元数据信息252中所示。如236中所示，web浏览器可以根据mpd242从服务器逐片段地拉取媒体。例如，web浏览器可以使用httpgeturl(frag1req)244来请求第一片段。统一资源定位符(url)或全球资源定位符可被用于告知服务器客户端要请求哪些片段254。web服务器可以提供第一分段(即，片段1246)。对于随后的片段，web浏览器可以使用httpgeturl(fragireq)248来请求片段i，其中i是片段的整数索引。结果，web服务器可以提供片段i250。片段可经由媒体解码器/播放器224被呈现给客户端。
图3示出了向在诸如ue336之类的移动设备上运行的3gpp客户端338提供多媒体内容的http服务器310之间的多媒体内容312的流。http服务器可以与公共或私有网络322(或者互联网)接口，该公共或私有网络322与无线广域网(wwan)的核心网络324通信。在一个实施例中，wwan可以是基于3gpplte的网络、或基于ieee802.16的网络(即，802.16-2009)。核心网络可以经由无线电接入网络(ran)332访问诸如演进分组系统(eps)之类的无线网络330。ran可经由节点(例如，演进节点b(enb)334)向在ue上运行的客户端提供多媒体内容。
链路感知流传输自适应(streamingadaption)
根据一个实施例，公开了具有由基站服务的多个无线视频用户的系统。尽管系统包含多个视频客户端，但每个客户端都能够独立于其他客户端进行动作。由代表客户端请求的视频的不同表示可以使用字母k来进行索引。可设定值k＝1来表示最低比特率表示等级(representationlevel)且k＝n可表示最高表示等级。变量bk可表示表示等级k的经编码视频的比特率，其中b1≤b2≤b3≤…≤bn。
mpd中的不同视频表示等级的速率可由服务器在mpd中传送给客户端。这发生于多媒体的流传输开始之前。播出处理和速率自适应可以视频帧持续时间τ的时间粒度发生。视频帧持续时间τ是视频帧速率fr的倒数，即τ＝1/fr。某一视频帧持续时间被称作帧时隙(frameslot)。每个帧时隙可使用字母i来索引。
物理层有效吞吐量
为了使得视频速率自适应算法能够随机地适应无线电链路吞吐量的波动，对物理层有效吞吐量的估计可以被执行并被用于视频速率自适应。有效吞吐量是应用层吞吐量。吞吐量是在每单位时间由网络递送至某一目的地(例如，ue)的有用信息比特的数目。吞吐量数据不包括协议开销比特、以及重传的数据分组。
如果xi是在第i个视频帧时隙中成功接收的比特的数目，那么第i个帧时隙中的物理层有效吞吐量由下式给出：
第i个帧时隙中的平均物理有效吞吐量是过去的t个帧时隙上的物理层有效吞吐量的平均，即：
平均物理层有效吞吐量的估计可使用与无线电链路的物理层的协作来确定在每个帧时隙中成功下载的比特的数目。由于仅成功接收的比特被用于确定物理层有效吞吐量，所以混合自动重传请求(harq)和tcp层重传对吞吐量估计的影响在物理层有效吞吐量估计中被考虑。另外，帧时隙中的物理层有效吞吐量与服务器缓冲和视频客户端的演进紧密相关。
使用更高层进行吞吐量测量
传统上，tcp层或应用层的更高层吞吐量估计已经被用于估计可用链路带宽以用于has中的视频速率自适应。更高层吞吐量估计的示例在后续段落中提供。
平均视频分段吞吐量
平均视频分段(fragment)是在下载视频分段时经历的平均吞吐量，如下式所示：
其中
tcp吞吐量
另一更高层的方法是使用对可用链路带宽的tcp估计，其由下式给出：
其中cwnd是所谓的tcp拥塞窗口，且rtt是信号的估计往返时间(roundtriptime)。变量cwnd是tcp对可用链路带宽的当前估计。通常，cwnd在接收到确认(ack)时增加(因为其是网络能够支持更高带宽的指示)，并且它在觉察到丢包时(通过超时或重复的ack来觉察)减小(因为它假设丢包是由于拥塞导致的)。存在缓启动阶段，在此阶段中cwnd随确认的接收成指数增加；并且存在拥塞避免阶段，在此阶段中它随确认线性增加。
然而，tcp被设计用于有线网络、以及持续地发送数据的大型应用(bulkapplications)。它既不被设计用于无线网络也不被设计用于应用速率受限的应用(例如，http自适应流传输)。使用tcp估计吞吐量至少具有两个问题。第一，tcp估计的使用假设无线丢失也是拥塞。此假设不必要地降低了窗口大小，即使在实际吞吐量不要求降低时。第二，tcp估计不必要地增大了cwnd，即使在应用速率受限的情形期间。因此，cwnd带宽估计会变得比应用在rtt时段内发送的tcp分组的数目高得多。当应用发送比cwnd带宽估计所允许的分组更少的分组时，tcp不能够正确地探知可用网络带宽。因此，cwnd带宽估计不再反映当前的可用网络带宽。因此，基于tcp的带宽估计的使用并不是十分适合用于无线场景上的has中的速率自适应。
链路层有效吞吐量的优点
根据一个实施例，链路层有效吞吐量可被用作对更高层估计的补充。链路层有效吞吐量能够跟踪链路有效吞吐量随时间的变化，从而提供更高范围的随机视频速率自适应和累积用于提升用户的qoe的缓冲。链路层的使用表示由用户获得的实际当前有效吞吐量，而非过时的更高层估计。链路层有效吞吐量可以在相对较短的时间段内剧烈地变化。然而，链路层有效吞吐量能够进行时间平均以呈现平滑的估计，从而避免剧烈的变化，同时仍然捕获无线链路的总体趋势。另外，链路层有效吞吐量的使用避免了基于tcp的带宽估计具有的对于无线信道上的速率受限的应用的一些缺点。另外，链路层有效吞吐量可从流传输会话的第一视频片段获得，而非在前几个视频片段的下载之后才可获得。
因此，链路层有效吞吐量可以提供对于http自适应流中的实际吞吐量的更快、更准确的认知。该认知然后可以被用于在附加带宽由于无线链路中的改变可用时主动地下载附加帧来构建缓冲。此外，在has会话开始时对有效吞吐量的准确认知使能更快的启动和更好的显示分辨率。
所选择的吞吐量
在一个实施例中，平均链路层有效吞吐量可以与像视频分段吞吐量之类的更高层吞吐量结合使用。被选择用于视频速率自适应的吞吐量可基于无线链路条件中的改变的演进、以及has客户端的缓冲等级。在帧时隙i中由代表用户所选择的用于速率自适应的吞吐量可由
其中常数β防止了链路条件中的短期变化改变速率自适应。该保守方法可被用于稳定状态，因为phy有效吞吐量通常快速地响应无线链路变化，而片段吞吐量更加缓慢地响应链路变化。
在has会话的启动阶段，关系
缓冲演进和跟踪
为了请求适当的表示等级，客户端可保持对所请求、接收、缓冲、和播放的帧的跟踪。图3示出了由ue客户端进行的帧跟踪。ni和qi分别表示在帧时隙i中请求的帧数目和表示等级，即在每个帧时隙i结束时，客户端向服务器请求由速率自适应算法所确定的表示等级qi处的ni个帧。客户端基于物理层有效吞吐量、以及各种帧等级来决定ni和qi。
图4提供了对视频帧跟踪的示例描述。变量ai、bi、ci、和ei表示客户端在计算ni和qi时使用的各种帧等级。变量ai表示在客户端于帧时隙i中做出它的请求之前由客户端接收的视频帧的总数目。变量bi表示客户端缓冲器中可用于播放的帧的数目，并且ci表示由客户端请求的帧的数目：
变量ei表示由客户端请求、但尚未被客户端接收的视频帧的数目。客户端可基于所请求的全部帧和所接收的全部帧来估计ei。例如：
ei＝ci-ai
缓冲演进与用户所体验的phy有效吞吐量紧密相关。使bi,k表示在帧时隙i中下载的视频表示等级的速率。那么在帧时隙i中进入客户端缓冲器的帧的数目为：
其中βi是链路层的有效吞吐量与视频表示等级的速率的比率。它表示客户端缓冲器被填充的速率。
客户端状态
1.http自适应流传输(has)的中央智能驻留于客户端而非服务器中。将下载的视频片段的自适应等级是由客户端确定的并在自适应流传输会话内被周期性地传送至服务器。基于帧等级，我们的链路感知自适应流传输框架中的客户端播放器的操作能够被表征为四个模式或状态，如图5中所示：i)启动；ii)过渡状态；iii)稳定状态；或者iv)重缓冲状态。
2.启动模式表示初始缓冲模式，在该模式期间客户端在开始播放由has递送的视频或音频之前将视频帧缓冲至某一界限。稳定状态表示ue缓冲等级高于某一阈值的状态。过渡状态是ue缓冲等级在开始播放之后落至某一界限之下的状态。重缓冲状态是客户端在开始播放之后缓冲等级变为零时进入的状态，并且它保留在此状态中直到它将它的缓冲等级重建至满意的等级以再次开始播放为止。应当注意，只有在启动和重缓冲模式期间，客户端不播放多媒体。
3.状态变量si可被用于标示在第i个帧时隙中确定的客户端的状态。被分配给si的值对应于不同的状态，如下所示：
4.针对启动状态，si＝-1
针对重缓冲状态，si＝0
针对过渡状态，si＝1
针对稳定状态，si＝2
5.在一个实施例中，可以通过使用如下算法，依据所接收的帧的数目ai和ue缓冲器中可用于播放的帧的数目bi来设置客户端状态：
对这些不同状态的定义允许速率自适应被设计为不仅基于物理层有效吞吐量还基于用户客户端的状态。
mbr/gbr信令
网络还可以在服务质量(qos)承载在qos感知网络(例如，3gpplte)中被建立或修改时将最大比特率(mbr)和保证比特率(gbr)形式的qos参数用信号发送至ue。has客户端可结合不同的吞吐量估计使用此信息，以用于选取客户端从has服务器请求的视频片段的表示等级。mbr可被has客户端用于限制它能够选取的最大视频表示等级，gbr可被has客户端用于至少选取以下表示等级，该表示等级的媒体比特率大于由网络用信号发送的gbr。基于所选择的吞吐量和用信号发送的mbr/gbr，最佳视频表示被选择如下：
使得
链路感知速率自适应框架
根据一个实施例，在无线设备上运行的客户端可以确定每个帧时隙i中的帧数目ni和视频表示等级qi。链路感知速率自适应算法的一个示例被示出于图6的流程图中。
链路感知速率自适应框架：针对每个帧时隙i
1)除了可用的任何更高层估计之外，基于跨层协作来确定帧时隙i中的平均phy有效吞吐量
2)帧等级ai、bi、ci、和ei被更新。
3)基于视频分段吞吐量、估计的phy层有效吞吐量、和信号发送的mbr/gbr将可能的最佳视频表示等级
使得
4)然后基于监控帧等级来确定客户端的状态si。
5)基于在特定客户端状态中使用的特定算法来确定表示帧数目ni和表示等级qi的(ni，qi)对。
启动速率自适应
启动模式表示初始缓冲模式，在该模式中客户端在播放开始之前将帧缓冲至播放时间的某一阈值。启动模式在mpd阶段之后流传输会话开始时开始，并继续到所接收的帧的总数目超过某一阈值(即，直到满足如下条件)为止：
在链路未感知选项中，一直以最低表示等级请求第一视频片段，从而使得客户端可以取得对下一帧时隙的物理层有效吞吐量的快速估计(即，n1＝sseg，且q1＝1)。如果客户端在开始has会话之前具有对物理层有效吞吐量的估计，那么该要求可被释放，从而允许多媒体在启动时以更高的质量被显示。
随后是用于启动模式中的链路自适应的数个实施例。启动模式是直到has中的选定数目的视频帧被接收到为止的模式。实际值可取决于系统设计、网络操作、或者其他期望参数。
基本/传统启动速率自适应
在此实施例中，可以在每个帧时隙的末尾处请求固定数目的sseg个帧(相当于1个片段)：
质量优化的启动(质量优化)
在此实施例中，如果链路条件允许，则视频的质量被优化。可使用增量质量方法，其中如果足够的带宽可用于支持这样的速率，那么就选取下一可用视频自适应速率。为此，比例δi被定义如下：
此比例表示平均估计物理层吞吐量与可能的下一视频表示等级的比例。对于此选项的(ni，qi)对然后被选择如下：
延迟优化的启动
在此实施例中，在将视频质量保持在最低表示等级的同时启动延迟被最小化：
延迟受限的质量优化
在此选项中，根据对延迟的约束，对视频质量进行优化。目标时间
延迟受限的质量优化：在每个帧时隙i中
1.确定最小所需帧下载速率：
其中bi是就视频帧而言的当前缓冲等级，并且
2.计算当前链路条件下针对所有视频表示等级的帧下载速率。针对速率为bk的视频表示等级的帧下载速率由下式给出：
注意，表示等级的帧下载与phy有效吞吐量成正比，并且与视频表示等级的速率成反比例。
3.选择使得
ni＝1
图7提供了示出延迟受限的质量优化启动的流程图。针对每个帧时隙，可以确定满足延迟约束的最小所需帧速率。然后，可以基于链路条件确定每个表示等级的帧下载速率。可选取满足最小阈值的最佳表示等级。阈值
稳定状态速率自适应(链路感知)
基本/传统的稳定状态速率自适应
在稳定状态模式中，客户端处的缓冲等级在某一等级之上。在传统的稳定状态算法中，目标是在不损害视频质量的情况下维持缓冲等级。这通常是通过针对稳定状态的每个片段持续时间周期性地请求价值一个片段的帧实现的。为此，状态变量tsteady被维护，该状态变量指示就自从上一次片段传输以来当前稳定状态调用中的帧时隙的数目方面的稳定状态的时间。当从任何其他状态进入稳定状态时，状态变量tsteady在第一帧时隙中被初始化为零。状态变量tsteady随后在稳定状态的后续帧时隙中按下式增加：
tsteady＝mod(tsteady+1，sseg)，
其中sseg是视频片段中的帧数目，并且还表示片段持续时间中的帧时隙的数目。
在基本的稳定状态算法中，帧时隙i的(ni，qi)对被确定如下：
如果tsteady＝0，ni＝sseg
如果tsteady≠0，ni＝0
链路感知稳定状态
根据一个实施例，公开了链路感知稳定状态模式，在该模式中客户端探测寻找附加带宽以在不损害质量的情况下更快地下载视频帧的链路。可用的附加带宽由平均物理层吞吐量
如果附加链路带宽可用，则可在每个片段持续时间期间请求一个以上片段，从而使得可累积缓冲以避免将来的重缓冲。为了实现此目的，γi可被设定为超出某一阈值，即：
γi≥1+α
其中round(γi)表示以当前的自适应速率和链路条件在下一帧时隙中可被下载的片段的可能数目。同时，如果请求更大数目的片段并且无线链路条件变差，则视频速率自适应是多余的。因此，可设定用于在稳定状态期间请求附加视频片段的附加条件。首先，可确定链路吞吐量处于增大阶段而非减小阶段：
第二，可提供选项来施加对所请求的、尚未接收到的视频帧的总数目的限制，即我们可限制ei从而使得我们在未接收到很多视频片段的情况下不请求太多的视频片段，即：
ni+ei≤emax
其中emax表示对ei设定的上限。
在链路感知稳定状态中，在帧时隙i的末尾处请求的(ni，qi)对可被确定如下：
链路感知稳定状态算法
链路感知过渡状态和重缓冲状态中的自适应
过渡状态和重缓冲状态表示客户端缓冲等级较低的状态。旨在构建缓冲等级，直到客户端在稳定状态中操作为止。从而，用于启动速率自适应的相同概念可被使用，这些概念在帧等级和延迟要求上有不同的阈值以实现期望的过渡状态和重缓冲状态。物理层有效吞吐量信息的使用可使得从移动设备到web服务器的针对视频片段的更准确的请求。相比于可能仅具有更高层吞吐量信息的情况，由物理层有效吞吐量信息提供的实际链路等级吞吐量的更高准确性可使得客户端缓冲器能够更加快速地被填充到期望的等级。
http自适应流传输设备
1.另一示例提供了可操作以接收超文本传输协议(http)自适应流传输(has)的移动设备的计算机电路的功能800，如图8中的流程图所示。该功能可被实现为方法，或者该功能可作为指令在机器上被执行，其中，这些指令被包括在至少一个计算机可读介质或一个非暂态机器可读存储介质上。计算机电路可被配置为从节点接收针对http自适应流的清单文件(manifestfile)，如在块810中。计算机电路还可被进一步配置为确定移动设备与节点的物理层有效吞吐量，如在块820中。计算机电路还可被配置为至少部分地基于物理层有效吞吐量，选择清单文件中用于选定时段的表示，如在块830中。依据信道条件、缓冲条件、或所测量的其他条件，可基于物理层有效吞吐量或者更高层吞吐量估计来选择清单文件中的表示。例如，在has启动时或者当信道条件相对快速地变化时，使用移动设备和节点之间的无线电链路的物理层有效吞吐量估计是有益的。在启动之后，当信道条件相对稳定时或者当缓冲器基本是满的时，更高层吞吐量估计可替代物理层有效吞吐量被使用，如前所述。
2.在一个实施例中，移动设备的计算机电路还可被配置为至少部分地基于物理层有效吞吐量从节点请求表示中的选定数目的片段。计算机电路可以至少部分地基于物理层有效吞吐量、或来自传输层的吞吐量估计、或来自应用层的吞吐量估计中的一者来选择针对选定时段的表示。计算机电路可以被配置为确定选定数目的先前接收的帧时隙上的平均物理层有效吞吐量；并基于平均物理层有效吞吐量请求将在预定时段内从节点下载的选定数目的片段。
3.移动设备的计算机电路还可被配置为从节点接收包括最大比特率(mbr)和保证比特率(gbr)在内的服务质量(qos)参数；并至少部分地基于物理层有效吞吐量、mbr、gbr来从节点请求选定数目的片段。
4.在另一实施例中，移动设备的计算机电路还可被配置为在http自适应流启动时：至少部分地基于物理层有效吞吐量选择在移动设备处对流进行操作之前将填充缓冲器的预定数目的片段；至少部分地基于平均物理层有效吞吐量选择针对选定时段的表示和预定数目的片段，以在移动设备处提供期望质量的http自适应流；至少部分地基于平均物理层有效吞吐量选择针对选定时段的表示和预定数目的片段，以在移动设备处提供最小启动延迟；或者至少部分地基于平均物理层有效吞吐量选择针对选定时段的表示和预定数目的片段，以在移动设备处提供延迟受限的质量优化。
5.在另一实施例中，移动设备的计算机电路还可被配置为通过以下操作在http自适应流的稳定状态播放期间选择表示并请求选定数目的片段：确定物理层有效吞吐量的平均与选定表示的比率；以及至少部分地基于平均物理层有效吞吐量，当附加链路带宽在稳定状态播放期间可用时，在每个片段持续时间期间请求一个以上片段以在移动设备的缓冲器中累积多个片段。
6.计算机电路还可被配置为：在请求将在每个片段持续时间期间被递送的一个以上片段之前，确定平均物理层有效吞吐量正在增加；以及选择在稳定状态播放期间将在每个片段持续时间期间递送的片段数目的限制。
7.http自适应流的清单文件可以是http动态自适应流传输(dash)适应集的媒体呈现描述；或者3gp文件格式中嵌入的元数据。
8.用于接收http自适应流传输的方法
另一示例提供了用于在移动设备处接收超文本传输协议(http)自适应流传输的方法900，如图9中的流程图所示。该方法可作为指令在机器、计算机电路、或移动设备(例如，ue)的处理器上被执行，其中这些指令被包括在至少一个计算机可读介质或一个非暂态机器可读存储介质上。该方法包括从节点接收针对http自适应流(has)的清单文件的操作，如在块910中。该方法的附加操作是确定移动设备与节点的物理层有效吞吐量，如在块920中。可在移动设备用于接收http自适应流传输的一个或多个无线电链路上测量物理层有效吞吐量。通常，单个无线电链路可被使用。此外，可使用载波聚合，其中两个或更多个无线电链路可被聚合以提供用于http自适应流的附加带宽。在载波聚合的情形中，两个或更多个无线电链路的有效吞吐量可被聚合。该方法的进一步操作是至少部分地基于物理层有效吞吐量确定请求has的比特率或者提供has的期望质量等级，如在块930中。
方法900中的确定比特率的操作还可包括：至少部分地基于物理层有效吞吐量选择清单文件中针对选定时段的表示；或者至少部分地基于物理层有效吞吐量从节点请求表示中的选定数目的片段。从节点请求选定数目的片段的操作还可包括从移动设备向web服务器发送http获得请求，其中http获得请求的频率是至少部分地基于物理层有效吞吐量来选择的。
方法900还可包括：确定选定数目的先前接收的帧时隙上的平均物理层有效吞吐量；并当平均物理层有效吞吐量正在增加时，请求将在每个片段持续时间期间向移动设备递送的附加数目的片段，以在移动设备的缓冲器中累积多个片段。
在另一实施例中，方法900还包括：使用传输层或应用层吞吐量信息替代物理层有效吞吐量，来基于移动设备和节点之间的无线电链路的链路条件、节点的网络拥塞等级、客户端状态、或者移动设备的缓冲器被填充以has的速率来确定请求has的比特率或者提供has的期望质量等级。
如前所述，诸如传输层或应用层吞吐量信息之类的更高层吞吐量信息可在启动之后并且在无线电链路相当稳定时被使用。网络可基于网络拥塞等级设定qos参数mbr/gbr。可在移动设备处接收到的片段的数目相对于使用更高层吞吐量信息增加了阈值数量时，使用物理层有效吞吐量信息。
在一个实施例中，可在移动设备上运行的客户端处从与移动设备的无线电组件的应用程序接口(api)周期性地接收物理层有效吞吐量信息。
在另一实施例中，方法900还可包括：从节点接收包括最大比特率(mbr)和保证比特率(gbr)在内的服务质量(qos)参数；以及至少部分地基于物理层有效吞吐量、mbr、gbr来从节点请求选定数目的片段。
方法900可以在至少一个非暂态机器可读存储介质中实现，该介质包括被适用于被执行以实现此方法的多个指令。
另一示例提供了可操作以执行链路感知流传输自适应的用户设备(ue)的计算机电路的功能1000，如图10中的流程图所示。功能可被实现为方法或者功能可作为指令在机器上被执行，其中这些指令被包括在至少一个计算机可读介质或一个非暂态机器可读存储介质上。计算机电路可被配置为确定ue与web服务器的数据链路的物理层有效吞吐量和更高层吞吐量估计，如在块1010中。计算机电路还可被配置为从web服务器接收针对http自适应流(has)的清单文件，如在块1020中。计算机电路还可被配置为基于数据链路的无线电链路条件确定是使用物理层有效吞吐量还是使用更高层吞吐量估计，如在块1030中。计算机电路还可被配置为基于所选择的物理层有效吞吐量或者更高层吞吐量估计来选择has的表示等级和帧数目，其中ni和qi分别表示所请求的帧数目和表示等级，如在块1040中。
图10的计算机电路还可被配置为基于物理层有效吞吐量通过在足够的带宽可用时选择下一可用视频自适应速率来执行质量优化的启动。在一个实施例中，计算机电路可被配置为通过使用下式选择帧数目ni和表示等级qi来优化启动时的has的质量：
其中
图10的计算机电路还可被配置为使用下式来选择帧数目qi和表示等级ni以限制启动时针对选定质量等级的has的延迟：
ni＝1
其中bk是has的表示k的比特率，
图11提供了无线设备(例如，用户设备(ue)、移动台(ms)、移动无线设备、移动通信设备、平板电脑、手持机、或其他类型的无线设备)的示例图示。无线设备可包括一个或多个天线，该一个或多个天线被配置为与节点或发射站(例如，基站(bs)、演进节点b(enb)、基带单元(bbu)、远程射频头(rrh)、远程射频设备(rre)、中继站(rs)、无线电设备(re)、远程射频单元(rru)、中央处理模块(cpm)、或其它类型的无线广域网(wwan)接入点)通信。无线设备可被配置为使用至少一个无线通信标准进行通信，该无线通信标准包括3gpplte、wimax、高速分组接入(hspa)、蓝牙、和wifi。无线设备可以使用用于每个无线通信标准的不同天线进行通信，也可以使用用于多个无线通信标准的共享天线进行通信。无线设备可在无线局域网(wlan)、无线个人域网(wpan)、和/或wwan中进行通信。
图11还提供了可被用于无线设备的音频输入和输出的麦克风和一个或多个扬声器的图示。显示器屏幕可以是液晶显示器(lcd)屏幕或其它类型的显示器屏幕(例如，有机发光二极管(oled)显示器)。显示器屏幕可被配置为触摸屏。触摸屏可使用电容、电阻、或其他类型的触摸屏技术。应用处理器和图形处理器可被耦接到内部存储器，以提供处理和显示功能。非易失性存储器端口也可被用于向用户提供数据输入/输出选项。非易失性存储器端口还可被用于扩展无线设备的存储器能力。键盘可与无线设备集成或被无线连接到无线设备以提供额外的用户输入。虚拟键盘也可使用触摸屏来提供。
各种技术或其某些方面或部分可采用在有形介质(例如，软盘、只读光盘存储器(cd-rom)、硬盘驱动、非暂态计算机可读存储介质、或任意其它机器可读存储介质)中实现的程序代码的形式(即，指令)，其中，当程序代码被加载到机器(例如，计算机)中并被机器执行吋，机器变为用于实施各种技术的装置。电路可包括硬件、固件、程序代码、可执行代码、计算机指令、和/或软件。非暂态计算机可读存储介质可以是不包括信号的计算机可读存储介质。在可编程计算机执行程序代码的情况下，计算设备可包括处理器、可被处理器读取的存储介质(包括易失和非易失存储器和/或存储元件)、至少一个输入设备、以及至少一个输出设备。易失和非易失存储器和/或存储元件可以是随机存取存储器(ram)、可擦除可编程只读存储器(eprom)、闪速驱动、光盘驱动、磁硬盘驱动、固态驱动、或用于存储电子数据的其他介质。节点和无线设备还可包括收发机模块(即，收发机)、计数器模块(即，计数器)、处理模块(即，处理器)、和/或时钟模块(即，时钟)或定时器模块(即，定时器)。可实现或使用这里所述的各种技术的一个或多个程序可使用应用程序接口(api)、可重用控件等。这些程序可用高级程序语言或面向对象的编程语言来实现以与计算机系统通信。然而，必要吋，(一个或多个)程序可用汇编语言或机器语言来实现。在任何情况下，语言可以是编译语言或解释性语言，并且可与硬件实现相结合。
应当理解的是，为了更具体地强调本说明书中所描述的很多功能单元的实现独立性，这些单元已被标记为模块。例如，模块可被实现为硬件电路，该硬件电路包括定制超大规模集成(vlsi)电路或门阵列、现成半导体(例如，逻辑芯片、晶体管、或其它分离组件)。模块还可在可编程硬件设备(例如，现场可编程门阵列、可编程阵列逻辑、可编程逻辑器件等)中实现。
模块还可在软件中实现，以被各种类型的处理器执行。所标识的可执行代码的模块例如可以包括计算机指令的一个或多个物理或逻辑块，这些块例如可以被组织为对象、程序、或功能。然而，所标识的模块的可执行代码不必在物理上位于一起，而是可以包括存储在不同位置的不同指令，当这些指令在逻辑上结合在一起时，组成了该模块并实现该模块的所述目的。
事实上，可执行代码的模块可以是单个指令，也可以是很多指令，甚至可以被分布在若干不同的代码段上、在不同的程序间并跨越若干存储器设备。类似地，操作数据在本申请中可在模块内被标识和说明，并且可以以任意适当的形式被实现并在任意适当类型的数据结构内被组织。操作数据可被收集为单个数据集，或者可被分布在不同位置上(包括分布在不同存储设备上)，并且可至少部分只作为系统或网络上的电子信号存在。这些模块可以是无源的或有源的，包括可操作为执行所希望的功能的代理。
本说明书中对“示例”或“示例性”的引用意味着结合示例所描述的具体特征、结构、或特性被包括在本发明的至少一个实施例中。因此，在本说明书的各个地方出现的短语“在示例中”或词语“示例性”不一定全部指代相同的实施例。
如这里所使用的，多个项目、结构元件、组成元件、和/或材料可被呈现在共同列表中以便使用。然而，这些列表应被解释为仿佛列表的每个部件被独立地标识为单独且唯一的部件。因此，该列表的独立部件不应仅基于它们呈现在共同的组中而没有相反指示就被解释为相同列表的任意其它部件的实质等同形式。此外，本发明的各种实施例和示例在本申请中可与其各种组件的替换选择一起被参考。应当理解的是，这些实施例、示例、和替换选择不应被解释为彼此的实质等同形式，而应被解释为本发明的分离且自治的表示。
此外，所述特征、结构、或特性可以任意适当的方式在一个或多个实施例中被组合。在以下描述中提供了很多具体细节(例如，布局示例、距离、网络示例等)以提供对本发明的实施例的全面理解。然而，相关领域技术人员将认识到，本发明可在没有一个或多个具体细节的情况下被实现，或者用其他方法、组件、布局等来实现。在其它实例中，熟知的结构、材料、或操作未被示出或详细描述以避免使本发明的方面模糊。
虽然以上示例在一个或多个具体应用中对本发明的原理进行了说明，但是对于本领域普通技术人员而言，在没有发明人员的帮助下可对实现方式的形式、用途、和细节做出很多修改而不背离本发明的原理和概念。因此，本发明不意图被限制，除了被所附权利要求限制。