对超文本传输协议(HTTP)请求实现弹性响应时间的方法、服务器及介质与流程

本申请要求享有2012年12月28日提交的、标题为“Device Timing Adjustments and Method for Supporting DASH Over Broadcast”的美国临时专利申请No.61/747,188的优先权，故以引用方式将其全部内容并入本文。

背景技术：

当前，超文本传输协议(HTTP)流是互联网上最流行的用于传送内容的方法。对于实时事件而言，通过不断的持续时间分段而使内容逐渐可用。这种沿着时间轴的分段可用性，指示每一个连续的分段何时在HTTP服务器处变得可用。

基于超文本传输协议的动态自适应流(DASH)是一种实现HTTP流的标准。DASH在媒体呈现描述(MPD)中通告分段可用性。MPD是用于通告分段、分段可用的时间以及这些分段的大小的分段可用时间轴。

在当前系统中，经由空中下载(OTA)传送来向接收机设备提供MPD。在所提供的MPD中，分段可用时间可以对应于生成这些分段的网络侧编码器的编码器输出时间。由于分段可用时间可以对应于编码器输出时间，因此对于在接收机设备上运行的DASH客户端来说，这些可用时间可能并没有说明与实际的分段可用的差别(例如，传送路径延迟、接收机设备处理延迟、或者接收机设备时钟漂移)。因此，在当前MPD中所通告的可用时间，可能并不对应于分段可用于DASH客户端的实际时间。

当通过内容传送网络(CDN)来传输DASH内容时，发生类似的问题。 DASH内容在源编码器处产生，但是，在不同的CDN服务点处，远程CDN 服务器处的分段的可用时间是不同的。

技术实现要素：

各个实施例的系统、方法和设备实现了服务器对于文件请求的弹性响应时间。用此方式，当文件临时不可用时，以及由于发生网络延迟时，服务器可以在对象/分段可用性中考虑不可预知的延迟，并减少响应于文件请求而返回错误消息(例如，404错误消息)的频率。

附图说明

被并入本文并且构成本说明书一部分的附图，描绘了本发明的示例性实施例，并且连同上面给出的概括描述以及下面给出的详细描述一起来解释本发明的特征。

图1是适合于结合各种实施例使用的网络的通信系统框图。

图2是用于示出根据一个实施例的接收机设备的体系结构的框图。

图3示出了根据另一个实施例的分段可用时间。

图4是描绘用于对HTTP请求的响应进行延迟的实施例方法的处理流程图。

图5根据一个实施例，示出了分段缓冲区随时间的状态。

图6是适合于结合各种实施例使用的示例性移动设备的组件图。

图7是适合于结合各种实施例使用的示例性服务器的组件图。

具体实施方式

现在参照附图来详细地描述各个实施例。只要可能，贯穿附图使用相同的附图标记来指代相同或者类似的部件。对于特定示例和实现的引用只是用于说明目的，而不是旨在限制本发明或者权利要求的保护范围。

本文所使用的“示例性的”一词意味着“用作例子、示例或说明”。本文中描述为“示例性”的任何实现不应被解释为比其它实现更优选或更具优势。

如本文所使用的，本文互换地使用术语“移动设备”和“接收机设备”，以指代以下各项中的任何一项或者全部：蜂窝电话、智能电话、个人或移动多媒体播放器、个人数据助理(PDA)、膝上型计算机、平板计算机、智能本、掌上计算机、无线电子邮件接收机、具备多媒体互联网功能的蜂窝电话、无线游戏控制器、以及类似的个人电子设备，其中这些个人电子设备包括可编程处理器和存储器，以及用于接收文件和向请求的应用/客户端(例如，请求的DASH客户端)提供文件的电路。

如本文所使用的，本文互换地使用术语“分段”、“对象”和“文件”，以指代可以从服务器请求的任何一个或者所有的数据结构或数据单元。

基于超文本传输协议的动态自适应流(DASH)是一种实现HTTP流的标准。DASH在媒体呈现描述(MPD)中通告分段可用性。MPD是用于通告分段、分段可用的时间以及分段的大小的分段可用性时间轴。在当前系统中，经由空中下载(OTA)传送来向接收机设备提供MPD。第三代合作伙伴计划(3GPP)将下载传输上的DASH标准化成用于在长期演进(LTE) 上使用广播来提供HTTP流的方法(即，演进的多媒体广播多播服务 (eMBMS))。

本文讨论了不同的应用/客户端、中间件、分段可用时间轴、无线电技术和传输协议的各个示例，特别是DASH客户端、多播服务设备客户端、MPD、eMBMS和HTTP。对于DASH客户端、多播服务设备客户端、MPD、eMBMS和HTTP的讨论，只是提供为用于更好地说明各个实施例的方面的例子，而不是旨在以任何方式来限制各个实施例。其它的应用/客户端、中间件、分段可用时间轴、无线电技术和传输协议也可以结合各个实施例来使用，并且在不脱离本发明的精神或保护范围的基础上，可以在各个例子中替换其它的应用/客户端、中间件、分段可用时间轴、无线电技术和传输协议。

各个实施例使接收机设备能够在用于该接收机设备的数据流中的数据分段的可用性(“分段可用性”)中考虑延迟。在一个实施例中，服务器(例如，接收机设备上向请求的应用/客户端(例如，请求的DASH客户端)提供分段的本地HTTP服务器)可以响应于分段请求，以用于服务分段的弹性响应时间进行操作。用此方式，服务器可以在分段可用性中考虑不可预测的延迟。

在一个实施例中，可以在用于描述发送给接收机设备的分段可用性时间轴(例如，MPD)的媒体描述片段中，提供网络抖动估计。在另一个实施例中，可以在接收机设备上预先提供网络抖动(例如，在接收机设备制造时，将其存储在该接收机设备的非易失性存储器中)。在其它实施例中，可以在任何消息(例如，服务通告)中向接收机设备传输网络抖动估计量。如本文所使用的，“抖动”将分段的最早和最晚可能到达时间之间的差值，指代成该分段的可用性时间轴中的差值。

如本文所使用的，“网络抖动”指代分段在接收机设备处的最早和最晚相对到达时间之间的最大差值。相对到达时间指代：绝对到达时间和根据传输时间轴的预期到达时间之间的差值。在一个实施例中，传输时间轴可以提供分段列表(其中这些分段携带服务的媒体)中的每一个分段的预期到达时间，可以对传输时间轴进行规定，使得基于所提供的第一分段的绝对可用时间，下一个分段可用时间是前一分段可用时间加上前一分段的持续时间。在另一个实施例中，对于连续的分段来说，可以将可用时间提供成绝对值。在另一个实施例中，可以将可用时间提供成具有周期的周期可用性。在另外的实施例中，可以将可用时间提供成一些机制的组合，例如，绝对值和周期可用性的组合。网络抖动可能与以下各项有关：分段大小的变化、调度周期粒度(例如，关于分段到达的1秒周期，320ms变化量的多播信道(MCH)调度周期粒度)、网络设备延迟(例如，带宽、传输延迟、处理延迟、缓冲器延迟等等)。网络抖动可以是依赖于环境的。例如，视频分段大小的变化可能造成网络抖动估计在该视频分段的平均大小的70％和 130％之间变化。

如本文所使用的，“接收机设备抖动”指代分段的到达时间和该分段可用于在该接收机设备上运行的请求应用/客户端的时间之间的最大差值。接收机设备抖动可能与下面各项有关：分段大小的变化、调度周期粒度(例如，关于分段到达的1秒周期，320ms变化量的MCH调度周期粒度)、接收机设备上的处理延迟(例如，前向纠错(FEC)处理、解码时间等等)和接收机设备时钟漂移。

在分段可用性时间轴(例如，MPD)中传输网络抖动估计量，可以使接收机设备服务器(例如，接收机设备上的本地HTTP服务器)能更佳地估计缓冲需求，实现时间轴调整的改进(当接收机设备时钟没有同步到服务器时钟时)，和/或在无需时间轴计算情况下进行操作的弹性服务器响应时间算法(例如，弹性HTTP服务器响应时间算法)。

在当前系统中，可以对提供给设备的MPD中的可用时间进行设置，使得在分段变得可用于该设备上的本地HTTP服务器之后，才进行针对分段的所有请求。但是，这种在所提供的MPD中进行的内置调整，在将分段服务于消费该服务的用户时会产生延迟，直到保证该分段在本地HTTP服务器上可用为止。举例而言，在当前系统中，如果抖动很大，延迟很小(除了统计性离群值之外)，或者在设备处存在时钟漂移，则针对最坏情形时钟漂移(例如，一秒、两秒、几秒等等)，对所提供的MPD中的可用时间进行预先调整。结果，与分段在接收机设备处实际可用的时间相比，针对这些分段的请求可能更晚，这是由于每一个分段的可用时间都针对最坏情形时钟漂移进行了调整(无论是否发生了最坏情形延迟)。延迟的请求直接增加了传输路径上的时延以及信道切换和初始捕获延迟。

各个实施例的系统、方法和设备实现了服务器对于文件请求的弹性响应时间。用此方式，当文件临时不可用时，以及由于发生网络延迟时，服务器可以在分段可用性中考虑不可预知的延迟，并减少响应于文件请求而返回错误消息(例如，404错误消息)的频率。在各个实施例中，服务器对于文件请求的弹性响应时间可以使时延和延迟得到减小，并在实际接收到分段时使分段可用。在一个实施例中，可以对MPD中的可用时间进行设置，以在不考虑时钟漂移的情况下，考虑正常延迟(例如，百分之90的延迟)。在一个实施例中，与所接收的MPD中列出的时间相比，可以使DASH客户端能够更早地进行针对分段的请求，可以基于服务器对于文件请求的弹性响应时间，来立即被提供这些分段，或者一旦该分段变得可用就被提供分段。

图1示出了适合于结合各个实施例使用的蜂窝网络系统100。蜂窝网络系统100可以包括多个设备，例如，接收机设备102、一个或多个蜂窝塔或基站104、以及连接到互联网110的服务器108和112。接收机设备102可以通过一个或多个蜂窝连接106(包括CDMA、TDMA、GSM、PCS、3G、 4G、LTE或任何其它类型的连接)，与蜂窝塔或基站104交换数据。蜂窝塔或基站104可以与路由器进行通信，其中路由器可以连接到互联网110。用此方式，通过与蜂窝塔或基站104和/或互联网110的连接，可以在接收机设备102和服务器108和112之间交换数据。在一个实施例中，服务器108 可以是提供用于通过DASH客户端来输出的MPD和分段的内容提供商服务器或编码器。在一个实施例中，服务器112可以是能从编码器接收MPD和分段输出，并控制这些MPD和分段向接收机设备102的OTA传输的广播多媒体服务中心(BMSC)服务器。当然，虽然本文所描述的接收机设备的特征是参照OTA传输来描述的，但这些特征也可以结合有线传输、无线传输或者有线传输和无线传输的组合来使用。因此，并不是必须进行OTA传输。

图2示出了根据一个实施例的简化接收机设备202的架构。接收机设备202可以包括调制解调器层208，后者管理接收机设备202的所有无线电方面，例如，捕获、切换、链路维持等等。调制解调器层208可以对接收的eMBMS承载信号进行解码，将互联网协议(IP)分组传送给多播服务设备客户端(MSDC)206。多播服务设备客户端206可以是接收机设备202 的服务层，其从传送的IP分组中恢复分段，并使分段可用于应用/客户端(例如，应用/DASH客户端204)。此外，多播服务设备客户端206还可以从传送的IP分组中恢复MPD。多播服务设备客户端206可以将接收的分段存储在该接收机设备的存储器中。在一个实施例中，多播服务设备客户端206 可以操作成用于接收机设备202的本地超文本传输协议(HTTP)服务器，其向诸如应用/DASH客户端204之类的应用/客户端提供分段。在另一个实施例中，多播服务设备客户端206可以结合接收机设备202上的单独的本地超文本传输协议(HTTP)服务器进行操作，以向诸如应用/DASH客户端 204之类的应用/客户端提供分段。应用/DASH客户端204可以是具备DASH 能力的应用和/或用于发起DASH客户端以呈现媒体(直接呈现和/或通过诸如媒体播放器之类的另一个应用进行呈现)的应用。应用/DASH客户端204 可以从多播服务设备客户端206获得MPD位置(例如，统一资源定位符 (URL))，从多播服务设备客户端206请求和接收MPD，并可以根据该 MPD中的可用性时间轴来从多播服务设备客户端206请求分段。应用 /DASH客户端204可以从多播服务设备客户端206接收所请求的分段，并可以呈现分段内容(直接呈现和/或通过诸如媒体播放器之类的另一个应用进行呈现)。

图3示出了流路径上的各种延迟，以及接收机设备(例如eMBMS接收机设备)所经历的这些延迟在时间上对于分段可用性的影响。编码器可以生成分段，并通过诸如LTE广播网络之类的广播网络进行广播。接收机设备可以接收这些广播分段，并存储在本地HTTP服务器中，使其可被该接收机设备上运行的DASH客户端进行消费。DASH客户端可以根据与分段相关联的服务的MPD中所列出的分段可用时间来请求分段。当被接收机设备在MPD中所列出的可用时间之外接收时，该分段是不可用的。在图3 所示的实施例中，可以使接收机设备上的本地主机HTTP服务器能够保持针对不可用分段的请求。用此方式，如果分段到达时迟到，则由于将针对该分段的请求保持到该分段可用为止，因此可以适应这种迟到的到达。

在一个实施例中，编码器可以将实时记录的原始媒体源分割成一些分段(例如，图3中所示的0、1、2、3、4、5、6)。编码器可以根据网络时间协议(NTP)时间来同步这些分段的边界，这些分段0、1、2、3、4、5、 6可以在编码延迟后从编码器中输出。在一个实施例中，编码器可以生成可用时间轴(例如，编码器生成的MPD)，其将分段0、1、2、3、4、5、6 的可用时间列成为编码器输出时间的。编码器可以向BMSC发送分段0、1、 2、3、4、5、6和MPD，分段0、1、2、3、4、5、6向BMSC的传输可能进一步延迟分段0、1、2、3、4、5、6。BMSC可以处理这些分段，以将这些分段分割成媒体分段分组(MSP)，使这些MSP同步，并调度这些MSP 进行OTA传输。每一个MSP可以被分配一个设定的MSP持续时间(例如， 1秒)。可以将MSP广播OTA给接收机设备，在接收机设备处接收到分段的MSP时，设备就可以接收到该分段。在一个实施例中，原始媒体源分段记录时间和接收机设备处接收到与该分段相对应的MSP之间的时间，可以是网络抖动。在一个实施例中，BMSC还可以向接收机设备发送MPD。当在接收机设备处接收到与分段相对应的MSP时，在该接收机设备可用该分段之前，可能需要进行另外的处理。另外的处理可以包括：根据分段0、1、 2、3、4、5、6各自的MSP，对分段0、1、2、3、4、5、6进行拆包和重组，应用FEC，对这些分段进行解码等等。接收机设备处的最差情况处理延迟，可能进一步延迟这些分段0、1、2、3、4、5、6的可用性。除了最差情况处理延迟之外，接收机时钟漂移也可能进一步影响分段0、1、2、3、 4、5、6在该接收机设备处的可用时间。

在一个实施例中，当分段(例如，0、1、2、3、4、5、6)到达接收机时，处理操作可能会延迟分段的可用性，时钟漂移可能导致应用/DASH客户端对于分段的过早请求。在图3所示的实施例中，可以将MPD中的通告时间设置成该设备上的最早可用时间。当设备时钟漂移、处理延迟和/或传输抖动导致针对分段的过早请求时(即，在分段可用之前进行针对该分段的请求)，本地HTTP服务器可以将这些请求保持在存储器中(即，并不立即执行这些请求)，以便考虑设备时钟漂移、处理延迟和/或传输抖动，并在该分段变得可用时，以请求的分段进行响应。用此方式，可以解决时钟漂移和分段处理中的变化性。

在一个实施例中，使可用性时间轴过分地太早，可能导致应用/DASH 客户端在启动时间没有请求所有必需的分段，这是由于分段可用性时间轴中所列出的分段可能具有早于该应用/DASH客户端的启动时间的相应可用时间。在一个实施例中，可以使应用/DASH客户端能够针对下面的分段进行分段请求：根据可用性时间轴而列出为当前可用的分段和更早可用的分段(例如，根据MPD中的时间轴，其可用时间在当前可用的分段之前的一个、两个或更多分段)。在一个实施例中，应用/DASH客户端可以在该应用的启动时间，请求所有接收的分段。在一个实施例中，将可以请求的过去分段的数量确定成：延迟抖动值除以分段持续时间。举例而言，如果抖动值是三秒，分段持续时间是一秒，该服务在8:00:00启动，根据MPD，在 8:00:00时，索引100的分段是可用的，结果，应用/DASH客户端可以确定应当请求三个分段(即，三秒的抖动值除以一秒的分段持续时间)，并在启动时发出针对分段98、99和100的请求。

在一个实施例中，使HTTP服务器能够保持请求，从而具有对HTTP 请求的弹性响应时间，其可以减少启动、端到端和切换延迟，以及只要接收到第一分段就启动媒体播放器。只要接收到第一分段就启动媒体播放器的缺点可能在于：如果下一个分段的可用时间发生延迟时，可能发生重新缓冲事件。另外，在存在慢漂移时钟的情形下，如果一旦接收到第一分段就启动媒体播放器，可能会造成按照周期的较长时间间隔发生重新缓冲事件。

图4示出了用于对HTTP请求的响应进行延迟的实施例方法400。虽然结合本地主机服务器延迟向DASH客户端提供分段的响应来进行讨论，但方法400的操作可以由任何HTTP服务器执行，以延迟针对文件请求的响应。在方框402中，HTTP服务器可以接收HTTP Get()请求。在一个实施例中，HTTP Get()请求可以是来自DASH客户端的针对分段的请求。在方框 404中，HTTP服务器可以针对该请求，启动保持时钟。在方框406中，HTTP 服务器可以判断所请求的分段是否是可用的。如果该分段是可用的(即，判断框406＝“是”)，则在方框418中，HTTP服务器可以向请求方(例如， DASH客户端)发送该分段，在方框420中，可以对保持时钟进行重置。在方框402中，HTTP服务器可以返回到方框402以等待下一个HTTP Get() 请求。

如果该分段是不可用的(即，判断框406＝“否”)，则在方框408中， HTTP服务器可以保持该HTTP Get()请求。在方框410中，HTTP服务器可以判断序列中的下一个分段是否是可用的。在一个实施例中，如果MPD中列出的下一个分段已经是可用的，则可能不需要该遗漏的分段。如果下一个分段是可用的(即，判断框410＝“是”)，则在方框414中，HTTP服务器可以向请求方(例如，DASH客户端)发送诸如HTTP 400系列响应(例如，404或410)之类的错误指示。在方框416中，HTTP服务器可以对保持时钟进行重置。在方框402中，HTTP服务器可以返回到方框402以等待下一个HTTP Get()请求。

如果下一个分段是不可用的(即，判断框410＝“否”)，则在判断框412 中，HTTP服务器可以判断是否超过了保持时间门限。在一个实施例中，该保持时间门限可以是延迟抖动值加上分段持续时间再加上当前时间。在一个实施例中，该保持时间门限可以是至少部分地基于所请求的分段到HTTP 服务器的预期传输时间。在另外的实施例中，该保持时间门限还可以包括用于考虑传输延迟或者处理延迟的安全边缘。在另一个实施例中，该保持时间门限可以是分段可用性时间轴中的分段的可用时间。举例而言，该保持时间门限可以是至少部分地基于：用于描述所请求的DASH分段的MPD 中所列出的传输时间。

当保持时钟上的时间大于保持时间门限时，就可能超过了该保持时间门限。如果超过了该保持时间门限(即，判断框412＝“是”)，则在方框414 中，HTTP服务器可以向请求方(例如，DASH客户端)发送诸如HTTP 400 系列响应(例如，404或410)之类的错误指示。在方框416中，HTTP服务器可以对保持时钟进行重置。在方框402中，HTTP服务器可以返回到方框402以等待下一个HTTP Get()请求。如果没有超过该保持时间门限(即，判断框412＝“否”)，则在方框406中，HTTP服务器可以判断该分段是否变得可用。用此方式，可以对该HTTP Get()请求可以保持，直到该分段可用、下一个分段可用、或者超过该保持时间门限为止。

图5根据一个实施例，示出了分段缓冲区随时间的状态，该实施例可以用于确定针对弹性服务器的保持时间门限。在一个实施例中，在接收到分段N之后，接收机设备抖动延迟可能导致分段N不能立即在本地HTTP 服务器处可用。一旦分段N可用，分段持续时间加上MPD@时间偏移缓冲深度(MPD@TimeShiftBufferDepth)就可以规定该分段的缓冲区存活时间，在该时间之后，将从缓冲区中删除该分段。在一个实施例中，为了考虑接收机设备抖动延迟和分段的存活时间，可以将针对不可用分段的、用于保持HTTP Get()请求的保持时间门限设置成：接收机设备抖动延迟加上分段持续时间再加上MPD@TimeShiftBufferDepth。

在另一个实施例中，保持时间门限可以是可变的。如上面参照图3所描述的，在分段在接收机设备上变得可用之前，应用/DASH客户端可以请求该分段。在一个实施例中，可以使HTTP服务器能够保持HTTP Get()请求，直到实际接收到该分段的时间为止。用此方式，只要分段变得可用于 HTTP服务器，就可以向进行请求的应用/DASH客户端提供保持了Get()请求的分段。

各种实施例可以在各种各样的移动设备(即，接收机设备)中的任何一种之中实现，图6描绘了其一种例子。例如，移动设备600可以包括耦合到内部存储器604和610的处理器602。内部存储器604和610可以是易失性存储器或非易失性存储器，还可以是安全和/或加密存储器，或者非安全和/或非加密存储器、或者其任意组合。此外，处理器602还可以耦合到触摸屏显示器606，例如，电阻式感应触摸屏、电容感应触摸屏、红外线感测触摸屏等等。另外，移动设备600的显示器不需要具有触摸屏能力。另外，移动设备600可以具有用于发送和接收电磁辐射的一付或多付天线608，后者可以连接到与处理器602相耦合的一个或多个网络收发机616，例如，无线数据链路和/或蜂窝(例如，CDMA、TDMA、GSM、PCS、3G、4G、LTE、或者任何其它类型)收发机。此外，移动设备600还可以包括用于接收用户输入的物理按键612a和612b。此外，移动设备600还可以包括用于打开和关闭移动设备600的电源键618。

本文的各个实施例可以用各种各样的商业可获得的服务器设备中的任何一种(例如，图7中所示出的服务器700)来实现。通常，这种服务器 700包括耦合到易失性存储器702和大容量非易失性存储器(例如，硬盘驱动器704)的处理器701。此外，服务器700还可以包括耦合到处理器701 的软盘驱动器、激光光盘(CD)或DCD光盘驱动器706。此外，服务器 700还可以包括耦合到处理器701的一个或多个网络收发机703(例如，网络接入端口)，以便与通信网络707(例如，耦合到其它通告系统计算机和服务器的局域网、互联网、公众交换电话网和/或蜂窝网络(例如，CDMA、 TDMA、GSM、PCS、3G、4G、LTE或任何其它类型的蜂窝网络))建立网络接口连接。

处理器602和701可以是能通过软件指令(应用)进行配置，以执行多种功能(其包括上面所描述的各种实施例的功能)的任何可编程的微处理器、微计算机或多处理器芯片或芯片集。在一些设备中，可以提供多个处理器，例如，一个处理器专用于无线通信功能，一个处理器专用于运行其它应用。通常，在访问软件应用并将它们装载到处理器602和701之前，可以将这些软件应用存储在内部存储器604、610、702或704中。处理器 602和701可以包括足够用于存储这些应用软件指令的内部存储器。在很多设备中，内部存储器可以是易失性存储器或者非易失性存储器(例如，闪存)、或者二者的混合。为了便于说明目的，对于存储器的引用通常指代：处理器602和701可访问的存储器，其包括内部存储器或者插入在设备之中的可移除存储器、以及处理器602和701自身中的存储器。

上述的方法描述和处理流程图仅仅是用作为说明性例子，而不是旨在要求或者隐含着必须以所给出的顺序来执行各个实施例的步骤。如本领域普通技术人员所应当理解的，可以以任何顺序来执行上述的实施例中的步骤顺序。此外，诸如“其后”、“转而”、“接着”等等之类的词语，并不旨在限制这些步骤的顺序；这些词语仅仅只是用于引导读者遍历该方法的描述。此外，任何对权利要求元素的单数引用(例如，使用冠词“一个(a)”、“某个(an)”或者“该(the)”)，不应被解释为将该元素限制为单数形式。

结合本文所公开的实施例描述的各种示例性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或二者的组合。为了清楚地表示硬件和软件之间的这种可交换性，上面对各种示例性的部件、框、模块、电路和步骤均围绕其功能进行了总体描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本发明的保护范围。

用于执行本文所述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件部件或者其任意组合，可以用来实现或执行结合本文所公开的方面描述的用于实现各种示例性的逻辑、逻辑框、模块和电路的硬件。通用处理器可以是微处理器，或者，该处理器也可以是任何常规的处理器、控制器、微控制器或者状态机。处理器也可以实现为计算设备的组合，例如，DSP和微处理器的组合、若干微处理器、一个或多个微处理器与DSP内核的结合，或者任何其它此种结构。替代地，一些步骤或方法可以由特定于给定的功能的电路来执行。

在一个或多个示例性方面，本文所述功能可以用硬件、软件、固件或它们任意组合的方式来实现。当在软件中实现时，可以将这些功能存储成非临时性计算机可读介质或者非临时性处理器可读介质上的一个或多个指令或代码。本文所公开的方法或算法的步骤，可以体现在处理器可执行软件模块中，后者可以位于非临时性计算机可读或者处理器可读存储介质上。非临时性服务器可读、计算机可读或者处理器可读存储介质可以是计算机或处理器能够存取的任何存储介质。举例而言，但非做出限制，这种非临时性服务器可读、计算机可读或处理器可读介质可以包括RAM、ROM、 EEPROM、闪存、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。如本文所使用的，磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字通用光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上述的组合也应当包括在非临时性服务器可读、计算机可读和处理器可读介质的保护范围之内。另外，一种方法或算法的操作可以作为一个代码和/ 或指令集或者其任意组合，位于非临时性服务器可读介质、处理器可读介质和/或计算机可读介质上，其中该非临时性服务器可读介质、处理器可读介质和/或计算机可读介质可以并入到计算机程序产品中。

为使本领域任何普通技术人员能够实现或者使用本发明，上面围绕所公开的实施例进行了描述。对于本领域普通技术人员来说，对这些实施例的各种修改是显而易见的，并且，本文定义的总体原理也可以在不脱离本发明的精神或保护范围的基础上应用于其它实施例。因此，本发明并不限于本文所示出的实施例，而是与所附权利要求书和本文公开的原理和新颖性特征的最广范围相一致。