CN103329471A - 为容量优化的流数据提供前向纠错 - Google Patents

Abstract

在示例实施例中，这里描述了一种方法，其中用于数据流的前向纠错（FEC）数据被分布到多个FEC子流中。数据流的预订者指示所述多个FEC子流中的哪些FEC子流应当被提供给预订者。FEC子流的分配被限制到被预订的FEC子流。没有预订者的FEC子流不被转发到诸如接入点（AP）之类的分布点以外。

Description

为容量优化的流数据提供前向纠错

相关申请的交叉引用

本申请要求2011年1月28日提交的美国专利申请No.13/016,117的优先权。

技术领域

本公开总地涉及提供诸如多播视频数据之类的流数据。

背景技术

在诸如体育场和音乐厅之类的体育和娱乐会场中，存在一种日益增长的市场，即将事件专用的流视频内容（例如重放、替换相机角度、替换游戏等）发布到会场内的屏幕上。还可能希望将流视频内容提供给会场内的移动设备，这样体育或娱乐的爱好者们就可以在他们的座位上、在餐饮大厅里等等的同时观看视频内容。

附图说明

这里所包括的构成说明书的一部分的附图图示了示例实施例。

图1是图示了用于提供流数据的装置的示例的框图。

图2是图示了接收具有关联的前向纠错数据的数据流并转发具有合适量的前向纠错的数据流的装置的示例的框图。

图3是图示了用于提供流数据的网络的示例的框图。

图4是图示了具有重叠覆盖区域的无线网络的示例的框图。

图5是图示了可以在其上实现示例实施例的计算机系统的示例的框图。

图6是图示了用于向与源耦接的多个设备提供前向纠错的方法的示例的框图。

图7是图示了用于动态地调节被提供用于数据流的前向纠错的总量的方法的示例的框图。

图8是图示了用于动态地调节属于一组前向纠错流的各个前向纠错流所提供的前向纠错的量的方法的示例的框图。

具体实施方式

示例实施例的概览

下面提出示例实施例的简单概览以提供对示例实施例的一些方面的基本理解。该概览不是对示例实施例的全面概览。既不希望标识示例实施例的关键或重要元件，也不希望勾画所附权利要求的范围。该概览的唯一目的是作为后面要呈现的更详细描述的前言以简化的形式呈现示例实施例的一些概念。

根据示例实施例，这里公开了一种装置，该装置包括被配置为与多个设备通信的接口以及与所述接口耦接的控制逻辑。所述控制逻辑经由所述接口广告数据流和与所述数据流相关联的多个前向纠错流的可用性。所述控制逻辑经由所述接口接收代表针对请求所述数据流的所述多个设备中的每个设备的关联前向纠错流的数据。所述控制逻辑选择性地将经由所述接口对所述关联的前向纠错流的转发限制到被请求的前向纠错流。

根据示例实施例，这里公开了一种方法，该方法包括广告多播视频流和与所述多播视频流相关联的多个前向纠错流的可用性。针对请求所述数据流的多个设备中的每个设备的代表前向纠错的数据被获得。向请求所述多播视频流的所述多个设备中的每个设备提供足够的前向纠错的最少数目的前向纠错流被确定。所述多播视频流和所述最少数目的前向纠错流被选择性地提供给请求所述多播视频流的多个设备。

根据示例实施例，这里公开了一种被编码在至少一个非暂时性计算机可读介质中以供处理器执行的逻辑。该逻辑在被处理器执行时可操作用于广告数据流和与所述数据流相关联的多个前向纠错流的可用性。该逻辑在被处理器执行时还可以操作用于获得针对请求所述数据流的多个设备中的每个设备的代表前向纠错的数据，并且确定在为请求所述数据流的所述多个设备中的每个设备提供足够的前向纠错数据的同时可以被提供给所述多个设备的最少数目的前向纠错流。该逻辑在被执行时选择性地提供所述最少数目的前向纠错流。

对示例实施例的描述

该描述提供示例，而不是意欲限制所附权利要求的范围。附图总地指示示例的特征，其中要理解和明白相似的标号被用来指代相似的元件。说明书中所提到的“一个实施例”或“实施例”或“示例实施例”是指所描述的特定特征、结构或特性被包括在这里所描述的至少一个实施例中，而不意味着该特征、结构或特性出现在这里所描述的所有实施例中。

在示例实施例中，会场为在网络上被多播的一个或多个UDP/IP（用户数据报协议/互联网协议）视频流提供通过诸如WiFi网络之类的无线介质到移动设备的最后一跳分布。任何适当的编码都可以被使用。例如，视频编码专家组（VCEG）H.264可兼容的编码器是适当编码器的一个示例。

为了补偿WiFi多播链路上的丢失的分组，前向纠错（FEC）数据分组根据相关联的一组源分组被生成，然后与原始源流分组一起被发送。在视频被分布在可能有损失的网络上之前，这些FEC分组通过传输层的应用（例如作为对UDP的鲁棒性补充）被添加在例如分布前端中。或者，修复分组可以在链路层（也被称为层2）被添加，例如作为对WiFi链路层2的补充。在传输层使用这种类型的应用层FEC提供了端到端的通信鲁棒性，而链路层的FEC提供了在特定通信链路上的通信鲁棒性。在示例实施例中，FEC机制提供例如由里德所罗门（Reed Solomon）和速龙（Raptor）实现的擦除保护。

客户端所接收到的源流和FEC修复流可以利用被用于区分这两种流的不同端口被发送到相同的多播地址。或者，源和FEC修复流可以在不同的多播地址上被发送。

实现可靠性所需要的FEC分组的数目取决于客户端所经历的分组丢失率（PLR）和丢失的突发尺寸。由于FEC修复数据的传输降低了可用于传送其它数据的容量，所以在示例实施例中，理想情况下仅仅够用的FEC分组被发送以补偿丢失的分组。由于每个客户端有不同的视频（RF）链路，每个客户端将可能经历不同的PLR和丢失的突发尺寸。因此，一些客户端将需要较多的FEC，而其它客户端将基于他们各自的链路需要较少的FEC。

为了在考虑分组丢失可变性的情况下优化FEC修复数据所需要的射频带宽，视频流可以作为基本流结合一个或多个（例如2-4个）FEC修复流而被广告。任何适当的广告机制都可以被使用，例如会话通告协议（SAP）。基本流和每个FEC修复流可以具有作为广告的一部分的不同的多播地址。对于多个FEC修复流的情况，每个FEC流可以在不同的多播地址上被发送。

例如，第一修复流（修复流1）具有特定量的修复分组（例如基本流的10%），而第二修复流（修复流2）具有附加量的修复分组（例如另外10%）。针对每个修复流的百分比也被广告。每个客户端预订针对其链路状况修复所有源分组擦除所需要的最少数目的修复流。根据之前的示例，如果客户端需要20%的FEC来恢复分组擦除，则该客户端要预订修复流1和2。对于IP多播，客户端可以利用IGMP（互联网组管理协议）来预订修复流。

一些WLAN（无线局域网）系统使用IGMP窥探，使得当接入点（AP）上的一个或多个客户端被预订到流时，接入点只发送多播流。利用这个特征，只有与AP相关联的客户端所需要的修复流被AP发送。通过利用空中接口来发送最少数目的FEC流，系统的整体无线容量被提高并且同信道干扰被减少。另一个改进是针对AP丢弃被指定且可配置的百分比的修复分组，使得每个AP发送最少数目的FEC分组以满足针对其覆盖区域内的客户端的特定服务级别。要丢弃的FEC分组的百分比量可以随时间被修改以补偿动态的环境状况。

针对所有修复流的总FEC：

在示例实施例中，可用FEC的总量（即所有修复流的总和）是固定的（或者管理上被配置的）。例如，FEC的总量可以被设置为原始源流的40%。在另一实现方式中，客户端将关于PLR和块丢失的统计信息报告回中央服务器。服务器随后动态地调节FEC的总量以适应最坏的客户端状况。最大截止值可以被设置以防止具有非常差性能的一些客户端驱动系统。例如，最大截止值可以被设置为50%的FEC。

针对每个修复流的FEC的量：

在示例实施例中，每个修复流中的FEC的量可以通过将总的FEC率除以修复流的数目而被固定。例如，如果总的FEC为40%且存在4个修复流，则每个修复流将包含10%的FEC数据。在示例实施例中，客户端将报告各自的PLR和突发丢失。系统随后将调节每个修复流中的FEC的量以使得相同数目的客户端针对所需要的流数目最终按照每个直方图桶（histogram bucket）的形式分布。例如，如果有4个修复流，则每个流中的FEC的量将被选择以使得在客户端分配中，25%的客户端将与第一修复流（修复流1）协作，50%的客户端将与第一和第二修复流（修复流1＋修复流2）协作，75%的客户端将与三个修复流（例如修复流1+2+3）协作，并且100%的客户端将与全部四个修复流协作。按照这种方式，客户端被平均散布在这些情形中以使得每个附加修复流的影响/价值最大化。

作为以上方法的变形，除了报告PLR和突发丢失以外，客户端将报告他们与哪个AP相关联。然后，平均分布可以在AP层实现，而不是在各个客户端层实现（在AP层，AP上的最差客户端决定在空中“OTA”必须被发送的流的数目）。每个修复流中的FEC的量可以被调节以使得同样数目的AP按照每个直方图桶的形式来分布。根据以上的前述示例，100%的AP最终将发送第一修复流，75%的AP将发送第一和第二修复流，50%的AP将发送第一、第二和第三修复流，且25%的AP将发送全部四个修复流。

在特定实施例中，客户端将报告PLR、突发丢失和他们当前与哪个AP相关联。但是并不应用简单的直方图方法来设置每个修复流中的FEC的量，而是针对总体OTA流量使用（针对FEC）计算出的函数将全局地被优化。关于该方法的更详细的描述在这里被描述如下。针对各个修复流的一组值被限制以使得这些值的总和是所需要的总FEC。

换言之：

Rate-n=修复流N的FEC率；并且

Sum(Rate-n)=所需要的总FEC

利用成本函数对一组可能值的搜索被执行。成本函数实质上计算由于对各个修复流的值的选择而产生的总的OTA流量。为了计算成本函数，需要得到针对每个AP的客户端统计信息，并且在给定当前的一组值的情况下基于针对AP的最差客户端来判定多少个修复流应当被提供给每个个体AP。针对该AP的成本是针对被提供的流的数目的Rate-n的总和。针对所有AP的成本的总和是总的系统成本。

很多个已知的搜索算法可以被使用。例如，如果计算上成本不太高的话，穷举式搜索可以被执行，或者作为替代，梯度搜索算法可以被使用。

流捆绑：

一种用于提高FEC修复流有效性的方法是将FEC修复流应用于由两个或更多个源流构成的群组，通常被称为流捆绑。与利用其自己的FEC修复流来保护每个流相比，利用共同的FEC流来保护两个或更多个流提高了被丢失分组可以被恢复的可能性。利用捆绑，客户端接收到源和修复流束，恢复源分组擦除，然后丢弃除用户所请求的视频流以外的流。这里所描述的原理同样很好地适用于被捆绑的流。针对捆绑的修复分组被分开在两个或更多个多播地址上，如上所述。

粘性（sticky）客户端：

因为在AP上被发送的多播FEC数据的量取决于该AP上的最差客户端，所以一个考虑是确保客户端与最佳的可能的AP相关联。在大多数当前的WiFi实现方式中，关于在很多个AP可见（例如在体育场环境中）时选择哪个AP的决定会受在客户端的控制。客户端可能是“粘性的”，就是说一旦客户端在AP上工作，即使该客户端正在环境中移动（例如球迷从其座位上站起去买热狗）并且可以被另一AP更好地服务，该客户端也就不会再期待漫游到另一AP，直到该客户端不能够与其当前的AP通信为止。

为了进行补偿，该架构可以首先检测何时存在粘性客户端。这可以通过测量来自客户端的上行链路分组（探测分组或其它分组）的信号强度并比较该区域内的各个AP所观察到的信号强度来实现。当从周围AP中的一个AP观察到的信号的强度高于从客户端所关联的AP观察到的信号强度时，确定粘性客户端存在。为了补救，粘性客户端与其当前AP解除关联。当客户端在探测新的AP时，只有之前接收到最高信号强度的AP对客户端的探测做出响应。或者，在解除关联时，该架构可以明确地为客户端提供关于其应当重新关联到的AP的信息，例如利用与所提出的（电气电子工程协会）IEEE802.11v标准中所描述的技术类似的方式。或者，客户端上的软件可以检测多播流的分组丢失表现何时恶化并且因而迫使客户端探测更好的AP。

弱客户端填塞：

在示例实施例中，客户端可能在覆盖区域的边缘处操作，在该覆盖区域的边缘处来自所有AP的信号都很弱。在这种情况下，客户端将需要最大量的多播FEC数据来补偿很弱的链路。如果第二客户端在相同的区域内操作，则该第二客户端可以从一组很弱的信号中选择不同的AP。由于在AP上被发送的多播FEC数据的量取决于该AP上的最差客户端，所以从系统容量的角度来看确保两个弱客户端与相同的AP相关联是有益的。这可以被称为弱客户端填塞，其中弱客户端在可能的情况下被放置（或“填塞”）在相同的AP上。

在示例实施例中，弱客户端检测通过测量来自客户端的上行链路分组（探测分组或其它分组）的信号强度并比较该区域内的各个AP所观察到的信号强度来实现。当*所有*AP所观察到的信号强度都很弱时，确定弱客户端存在。对在相同或相邻AP上的其它弱客户端进行搜索。如果其它弱客户端被发现散布在不同的AP上，则利用这里之前所描述的用于将粘性客户端从一个AP移到另一AP的技术中的一种技术（例如通过利用802.11v可兼容机制来控制探测响应或显式请求），某些客户端可以与他们的当前AP脱离关联，并且他们可以被引至共同的AP。

图1是图示了用于提供流数据的装置100的示例的框图。流数据可以适当地为任何类型的数据流，例如视频流、音频流、其它类型的数据（例如股票行情或者在体育会场的情况下的更新比分）或者前述数据流的任意组合。装置100包括被配置为与多个设备通信的接口102。这些设备可以是诸如无线客户端（未被示出，参加例如图2）之类的端点和/或诸如交换机、路由器和接入点（AP）（未被示出，参见例如图2）之类的位于网络上的其它设备。控制器104与接口102耦接并且可以经由接口102发送数据和/或从外部设备接收数据。控制器104适当地包括用于执行这里所描述的功能的控制逻辑。这里所使用的“逻辑”包括但不限于硬件、固件、软件和/或他们的组合，以用于执行功能或动作和/或引发另一组件的功能或动作。例如，基于所希望的应用或需要，逻辑可以包括软件控制的微处理器、诸如专用集成电路（ASIC）、可编程/被编程的逻辑设备、包含指令的存储器设备等之类的离散逻辑或者在硬件中实现的组合逻辑。逻辑也可以完全被实现为存储在非暂时性有形介质上的软件，该软件在被处理器执行时执行所描述的功能。逻辑可以适当地包括被配置为执行一个或多个功能的一个或多个模块。

在继续参考图1的同时参考图2，图示了包括接口102、控制器104和第二接口202的装置200。其中装置可以适用于提供流的设备，装置200可以被利用以实现在流的源和目的地之间的设备。例如，装置200可以被利用以实现接入点或交换机。在被图示的示例中，装置200接收带有FEC的输入流。控制器104中的控制逻辑确定在接口202处所接收的FEC中的多少FEC应当经由接口102被转发。在示例实施例中，控制器104确定满足与接口102通信的多个设备的要求的要经由接口102转发的最少（合适）量的FEC。设备经由接口102转发合适量的FEC并丢弃任何余下的FEC数据。

在示例实施例中，控制器104经由接口102广告数据流和与数据流相关联的多个前向纠错流的可用性。控制器104经由接口102接收代表针对请求数据流的多个设备中的每个设备的前向纠错的数据。在示例实施例中，代表前向纠错的数据可以由设备请求。在另一示例实施例中，设备可以请求一定量的前向纠错（FEC）并且控制器104确定哪些流要提供给设备。控制器104选择性地将经由接口102对相关联的前向纠错流的转发限制到被请求的前向纠错流。例如，如果控制器104正在提供四个FEC流而具有最高FEC的设备只需要这些FEC流中的三个流，则仅仅这三个流经由接口102被提供。第四个流不被传送。例如，如果接收三个FEC流的设备漫游到另一接入点（AP），则控制器确定用于余下设备的最少量的FEC（例如1个或2个流）并且选择性地提供这些流以提供新的最少量的FEC。

在示例实施例中，数据流和多个前向纠错流具有相同的多播地址但是具有不同的端口地址。广告可以适当地包括代表FEC流的多播地址和合适的端口地址的数据。

在另一示例实施例中，数据流和多个前向纠错流具有不同的多播地址。广告适当地包括代表FEC流的多播地址的数据。

在示例实施例中，控制器104根据经由接口从多个设备中的每个设备接收的对属于多个前向纠错流的流的预订请求，来确定针对多个设备中的每个设备的前向纠错的量。例如，在请求数据流的同时，设备也可以请求FEC流。该请求可以包括FEC流的多播和在特定实施例中的FEC流的端口。在示例实施例中，控制器104通过窥探经由接口102接收到的互联网组管理协议（IGMP）确定多个设备中的每个设备请求了哪些流。

在示例实施例中，多个前向纠错流中可用的前向纠错的总量被控制器104动态地设置。例如，控制器104可以将这个量设置为需要最多FEC的设备所需要的量。可选地，最大截止值可以被指定以使得FEC的量不会超过特定量，这将防止具有特别差性能的一些客户端驱动系统。例如FEC的最大量可以被封顶在50%。

在示例实施例中，多个接入点与接口102进行数据通信，所述多个接入点中的每个接入点具有请求数据流和多个前向纠错流中的至少一个前向纠错流的至少一个客户端。控制器104调节多个前向纠错流中的前向纠错的量以使得多个前向纠错流被平均分布在多个接入点上。

例如，在继续参考图1和图2的同时参考图3，网络300被图示，该网络300包括经由网络304被耦接到AP306和交换机控制器312的视频服务器302，其中交换机控制器312与AP308耦接，控制器104的功能可以由视频服务器302（该视频服务器在该示例中将提供视频流）、交换机控制器312和/或AP306,308,310中的任意AP中的任一个中的逻辑来实现。例如，如果30%的FEC正在被提供并且控制逻辑104在视频服务器302中被实现，则针对每个流的FEC的量（在这里也被称为“断点”）在三个AP306,308,310之间被划分，或者AP306,308,310中的一个AP将接收10%的FEC，而AP306,308,310中的第二个AP将接收20%的FEC，并且AP306,308,310中的的第三个AP将接收30%的FEC；而当控制器104在交换机/控制器312中被实现时，FEC将在两个AP308,310之间被分配，所以对于30%的FEC而言，AP308,310中的一个AP将提供15%的FEC，并且AP308,310中的第二个AP将提供30%的FEC。

在示例实施例中，每个流中可用的前向纠错的量通过将前向纠错的总数除以被提供的前向纠错流的数目来确定。例如，如果被提供的FEC的总量为40%并且四个FEC修复流被提供，则每个流将拥有10%的FEC（40/10）。

在示例实施例中，每个流中可用的FEC的量通过调节均匀分布在多个设备上的多个前向纠错流中的前向纠错的量来确定。例如，在继续参考图1的同时参考图4，图示了具有三个基本服务集（或小区）402,404,406以及六个无线客户端（WC）422,424,426,442,444,464的网络400。在该示例中，控制逻辑104将划分总的FEC以使得FEC的量在客户端之间被划分。例如，如果总的FEC为30%，则WC422,424可以接收到10%的FEC，同时WC426,442接收到20%的FEC，且WC444,464接收到30%的FEC。

在示例实施例中，其中多个接入点与接口102进行数据通信，所述多个接入点中的每个接入点具有请求数据流和多个前向纠错流中的至少一个前向纠错流的至少一个客户端，控制器104的控制逻辑调节多个前向纠错流中的前向纠错的量以最小化由多个接入点提供的前向纠错流的量。例如，在继续参考图1的同时再次参考图4，如果对于AP412的较差的情形是客户端使用15%的FEC，而对于AP414的较差的情形是客户端使用20%的FEC，且对于AP416的较差的情形是客户端使用35%的FEC，则总的FEC被设置为35%并且FEC修复流的FEC的量（断点）被调节以使得AP412提供15%的FEC，AP414提供20%的FEC，且AP416提供35%的FEC。

在示例实施例中，其中多个接入点与接口102进行数据通信，所述多个接入点中的每个接入点具有请求数据流和多个前向纠错流中的至少一个前向纠错流的至少一个客户端，控制器104为针对多个前向纠错流中的每个前向纠错流的一组可能值中的每个可能值确定针对所述一组可能值所产生的流量的量。控制器104从所述一组可能值中选择使诸如所产生的流量的量之类的成本函数最小化的一组值。例如，如果存在N个修复流，则FEC值针对每个流n被选择，以使得流n的总和=N。成本函数被用来确定针对FEC的每个可能值的带宽量（或者在无线网络的情况下是在空中“OTA”的时间量）。利用成本函数执行对所述一组可能值的搜索。成本函数实质上计算由于对各个修复流的值的选择而产生的总OTA流量。为了计算成本函数，需要得到针对每个AP的客户端统计信息，并且在给定当前的一组值的情况下基于针对AP的最差客户端，判定多少个修复流应当被提供给每个个体AP。针对该AP的成本是针对被提供的流的数目的Rate-n的总和。针对所有AP的成本的总和是总的系统成本。

很多个已知的搜索算法可以被使用。例如，如果计算上成本不太高的话，穷举式搜索可以被执行，或者作为替代，梯度搜索算法可以被使用。

在示例实施例中，控制器104可以搜索“粘性”客户端。因为在AP上被发送的多播FEC数据的量取决于该AP上的最差客户端，所以一个考虑是确保客户端与最佳的可能的AP相关联。在WiFi实现方式中，关于在很多个AP可见（例如在体育场环境中）时选择哪个AP的决定会受客户端软件的控制。客户端可能是“粘性的”，就是说一旦客户端在AP上工作，即使该客户端正在环境中移动（例如球迷从其座位上站起去买热狗），在信号完全丢失之前该客户端也不会去寻找另一AP。控制器104可以从与接口102通信的AP接收信号强度数据。

为了进行补偿，控制器104可以检测何时存在粘性客户端。这可以通过测量来自客户端的上行链路分组（探测分组或其它分组）的信号强度并比较该区域内的各个AP所观察到的信号强度来实现。当从周围AP中的一个AP观察到的信号的强度高于从客户端所关联的AP观察到的信号强度时，确定粘性客户端存在。为了补救，粘性客户端与其当前AP解除关联。当客户端在探测新的AP时，只有之前观察客户端的具有最高信号强度的AP对探测做出响应。或者，在解除关联时，该架构可以明确地为客户端提供关于其应当重新关联到的AP的信息，例如利用与被提议的IEEE802.11v标准中所描述的技术类似的方式。或者，客户端上的软件可以检测多播流的分组丢失表现何时恶化并且因而迫使客户端探测更好的AP。

例如，在继续参考图1和图2的同时再次参考图4，假设WC444与AP416相关联。与AP416相比，WC444实际上更靠近AP414；因此WC444与AP414之间的通信链路可能比当前的WC444与AP416之间的链路更好。如果WC444是与AP416相关联的较差的客户端，即其使用最多的FEC，则AP416可以被引导与WC444解除关联，迫使WC444漫游。由于WC444靠近AP414，所以它将与AP414关联。在特定实施例中，在存在与AP414的更好的连接的情况下，即使WC444不是与AP416相关联的性能较差的客户端，WC444也可以被迫漫游。

在示例实施例中，其中多个接入点与接口102进行数据通信，控制器104可以从多个接入点中选择一个接入点以将数据流提供给弱客户端（即使当前不存在与所选择的接入点相关联的客户端）。控制器104检测到至少一个弱客户端（所使用的FEC的量大于预定量的客户端）与被选择接入点或者邻近被选择接入点的接入点相关联。控制器104引导所述至少一个弱客户端漫游到被选择接入点。

例如，在继续参考图1和图2的同时再次参考图4，假设WC424和426都在小区402的边缘附近且都是与AP412相关联的最弱的客户端，并且WC444是与AP416相关联的最弱的客户端。控制器104可以选择AP414，该AP414可以与WC424,426,444通信以便为弱客户端提供服务。因而，WC424,426,444可以被引导漫游到AP414。因此，这会减小AP412和416所提供的FEC的最大量。

图5是图示了可以在其上实现示例实施例的计算机系统500的示例的框图。计算机系统500适合于实现这里针对控制器104（图1和图2）、视频服务器302（图3）、AP306,308,310（图3）和/或AP412,414,416（图4）中的任一个所描述的功能。

计算机系统500包括用于传送信息的总线502或其它通信机制以及用于处理信息的与总线502耦接的处理器504。计算机系统500还包括被耦接到总线502以用于存储要由处理器504执行的信息和指令的主存储器506，例如随机访问存储器（RAM）或其它动态存储设备。主存储器506也可以被用于在执行要由处理器504执行的指令期间存储临时变量或其它中间信息。计算机系统500还包括被耦接到总线502以用于存储用于处理器504的静态信息和指令的只读存储器（ROM）508或其它静态存储设备。诸如磁盘或光盘之类的存储设备510被提供并耦接到总线502以用于存储信息和指令。

示例实施例的一个方面涉及利用计算机系统500为容量优化的流数据提供前向纠错。根据示例实施例，为容量优化的流数据提供前向纠错由计算机系统500响应于处理器504执行主存储器506中所包含的具有一个或多个指令的一个或多个序列来实现。这些指令可以从诸如存储设备510之类的另一计算机可读介质被读取到主存储器506中。对主存储器506中所包含的指令序列的执行使得处理器504执行这里所描述的处理步骤。多处理布置中的一个或多个处理器也可以被用来执行主存储器506中所包含的指令序列。在替代实施例中，硬接线的电路可以被用来代替软件指令或者与软件指令组合以实现示例实施例。因而，这里所描述的实施例不局限于任何特定的硬件电路和软件的组合。

这里所使用的术语“计算机可读介质”指参与向处理器504提供指令以便执行的任何介质。这种介质可以采用很多形式，包括但不限于非易失性介质和易失性介质。非易失性介质包括例如光盘或磁盘，例如存储设备510。易失性介质包括诸如主存储器506之类的动态存储器。如这里所使用的，有形介质可以包括易失性和非易失性介质。常见的计算机可读介质的形式包括例如软盘、柔性盘、硬盘、磁卡、纸带、具有带孔的图案的任何其它物理介质、RAM、PROM、EPROM、FLASHPROM、CD、DVD或任何其它存储器芯片或盒式磁带、或者计算机可读取的任何其它介质。

计算机系统500还包括被耦接到总线502的通信接口518。通信接口518提供将计算机系统500耦接到通信链路520的双向数据通信，所述通信链路520使得计算机系统500能够获得来自外部设备的数据。例如，对于流数据和前向纠错流的请求可以经由通信链路520被通信接口518接收。此外，对外部设备的广告可以经由通信接口518被发送到通信链路520上。

例如，通信接口518可以包括局域网（LAN）卡以提供到可兼容的LAN的数据通信连接。作为另一示例，通信接口518可以是综合业务数字网（ISDN）卡或调制解调器以提供到相应类型的电话线的数据通信连接。无线链路也可以被实现。在任何这样的实现方式中，通信接口518发送和接收承载代表各种类型的信息的数字数据流的电、电磁或光信号。

计算机系统500可以通过网络、网络链路520和通信接口518发送消息并接收包括程序代码在内的数据。在互联网示例中，服务器430可以通过互联网528、ISP526、本地网络522和通信接口518发送针对应用程序的被请求代码。根据示例实施例，一个这样的被下载的应用实现如这里所描述的为容量优化的流数据提供前向纠错。

考虑到以上所描述的前述结构和功能特征，根据示例实施例的方法将参考图6-8被更好地理解。虽然为了简化说明的目的，图6-8的方法被显示和描述为顺序执行的，但是要理解和明白示例实施例不受所图示的顺序的限制，因为一些方面可以按与这里所显示和描述的顺序不同的顺序和/或与其它方面同时发生。此外，不是所有被图示的特征都需要实现这里所描述的方法。这里所描述的方法被适当地适配以在硬件、软件或它们的组合中被实现，例如在执行软件的处理器中被实现。

图6是图示了用于向与源流耦接的多个设备提供前向纠错的方法600的框图。方法600可以由控制器104（图1和图2）或者由被包括在视频服务器302（图3）、AP306,308,310（图3）、AP412,414,416（图4）和/或处理器504（图5）中的逻辑实现。

在602处，广告数据流和相关联的前向纠错流的可用性的广告被发送。广告可以利用任何合适的协议被发送。例如，在示例实施例中，广告可以被提供在SAP通告中。

在604处，针对请求数据流的多个设备中的每个设备的代表前向纠错的数据被获得。该数据可以经由预订请求（例如设备可以预订数据流并且预订FEC流）或者其它方式被接收。例如，每个设备可以指示它需要多少FEC并且适当的FEC流被确定。在示例实施例中，被请求的FEC的量通过窥探针对FEC修复流的IGMP请求而被得到。

在606处，可以向所有设备提供足够的FEC的最少量的FEC被确定。该最少量的FEC是可被提供的对于较差情形而言足够的量。例如，如果四个流可用并且一个设备需要第一个流并且第二个设备需要第一、第二和第三个流，则最少量的FEC将是第一、第二和第三个FEC修复流。在示例实施例中，如这里所描述的，最大被提供的FEC和/或FEC流的断点可以被调节。例如，最大FEC可以被调节以适应较差的客户端状况。作为另一示例，断点可以被调节为均匀的量（例如线性地调节，例如对于四个流，每个流增加25%的FEC），或者动态地被调节以将FEC流均匀地分布在客户端和/或AP之间。在示例实施例中，FEC和/或断点的总量被动态地调节以使得被发送给多个设备的数据量最小化。

在608处，用于通过所有设备处理流的最少有效量的FEC被选择性地提供。这个量可以因为环境的变化和/或设备的漫游或者解除关联而变化。

图7是图示了用于动态地调节被提供给数据流的前向纠错的总量的方法700的示例的框图。方法700可以由控制器104（图1和图2）或者由被包括在视频服务器302（图3）、AP306,308,310（图3）、AP412,414,416（图4）和/或处理器504（图5）中的逻辑实现。

在702处，针对请求数据流的多个设备中的每个设备的代表前向纠错的数据被获得。该数据可以经由预订请求（例如设备可以预订数据流并且预订FEC流）或者其它方式被接收。例如，每个设备可以指示它需要多少FEC并且适当的FEC流被确定。在示例实施例中，被请求的FEC的量通过窥探针对FEC修复流的IGMP请求而被得到。

在704处，较差的情形被确定。较差的情形对应于针对多个设备中的任意成员的最大量的FEC。例如，如果第一个设备利用10%的FEC且第二个设备利用35%的FEC，则FEC的最大量是35%。

可选地，在706处，确定最大量的FEC是否超过了预定义的最大值。例如，最大量的可用FEC可以被限制以防止具有非常差的信号质量的属于所述多个设备的少量设备驱动被提供的FEC的量。如果在706处，FEC的量超过最大值（是），则在708处，可用FEC的总量被设置为预定义的最大量。然而，如果在706处，FEC的总量小于预定义的最大值（否），或者如果不存在预先设置的最大量，则在710处，FEC的总量被设置为较差情形。

图8是图示了用于动态地调节由属于一组前向纠错流的各个前向纠错流提供的前向纠错的量的方法800的示例的框图。方法800可以由控制器104（图1和图2）或者由被包括在视频服务器302（图3）、AP306,308,310（图3）、AP412,414,416（图4）和/或处理器504（图5）中的逻辑实现。

在802处，针对请求数据流的多个设备中的每个设备的代表前向纠错的数据被获得。该数据可以经由预订请求（例如设备可以预订数据流并且预订FEC流）或者其它方式被接收。例如，每个设备可以指示它需要多少FEC并且适当的FEC流被确定。在示例实施例中，被请求的FEC的量通过窥探针对FEC修复流的IGMP请求而被得到。

在804处，FEC流被调节。在示例实施例中，针对所有修复流的总FEC（或者总和）被调节。例如，如果在802处，客户端将关于PLR和块丢失的统计信息报告回中央服务器，则可用FEC的总量被调节。服务器可以动态地调节FEC的总量以适应最差的客户端状况。最大截止值可以被设置以防止具有非常差性能的一些客户端驱动系统。例如，最大截止值可以被设置为50%的FEC。

在示例实施例中，针对每个修复流的FEC的量被调节。在示例实施例中，每个修复流中的FEC的量可以通过将总的FEC率除以修复流的数目而被固定。例如，如果总的FEC为40%且存在4个修复流，则每个修复流将包含10%的FEC数据。每个流中的FEC的量将随着总FEC的改变而改变。在示例实施例中，客户端将报告各自的PLR和突发丢失。系统调节每个修复流中的FEC的量以使得相同数目的客户端针对所需要的流数目最终按照每个直方图桶的形式分布。例如，如果有4个修复流，则每个流中的FEC的量将被选择以使得在客户端分配中，25%的客户端将与第一修复流（修复流1）协作，50%的客户端将与第一和第二修复流（修复流1＋修复流2）协作，75%的客户端将与三个修复流（例如修复流1+2+3）协作，并且100%的客户端将与全部四个修复流协作。按照这种方式，客户端被平均散布在这些情形中以使得每个附加修复流的影响/价值最大化。

在示例实施例中，除了报告PLR和突发丢失以外，客户端将报告他们与哪个AP相关联。然后，平均分布可以在AP层实现，而不是在各个客户端层实现（在AP层，AP上的最差客户端决定在空中“OTA”必须被发送的流的数目）。每个修复流中的FEC的量可以被调节以使得同样数目的AP按照每个直方图桶的形式来分布。根据以上的前述示例，100%的AP最终将发送第一修复流，75%的AP将发送第一和第二修复流，50%的AP将发送第一、第二和第三修复流，且25%的AP将发送全部四个修复流。

在特定实施例中，客户端将报告PLR、突发丢失以及他们当前与哪个AP相关联。但是并不是应用简单的直方图方法来设置每个修复流中的FEC的量，而是针对总体OTA流量使用（针对FEC）计算出的函数将全局地被优化。关于该方法的更详细的描述在这里被描述如下。针对各个修复流的一组值被限制以使得这些值的总和是所需要的总FEC。

换言之：

Rate-n=修复流N的FEC率；并且

Sum(Rate-n)=所需要的总FEC

利用成本函数对一组可能值的搜索被执行。成本函数实质上计算由于对各个修复流的值的选择而产生的总OTA流量。为了计算成本函数，需要得到针对每个AP的客户端统计信息，并且在给定当前的一组值的情况下基于针对AP的最差客户端，判定多少个修复流应当被提供给每个个体AP。针对该AP的成本是针对被提供的流的数目的Rate-n的总和。针对所有AP的成本的总和是总的系统成本。

很多个已知的搜索算法可以被使用。例如，如果计算上成本不太高的话，穷举式搜索可以被执行，或者作为替代，梯度搜索算法可以被使用。

虽然这里的描述针对于无线介质上的多播视频流，但是本领域技术人员应当很容易地明白这里所描述的示例实施例只是为了便于说明的目的而被选择的并且这里所描述的原理可适当地适配以用于其它操作环境。例如，这里所描述的原理可适配用于有线环境并且也可以被用在单播流被提供给多个接收方的环境中。因此，这里所描述的原理不应当被理解为局限于所图示的示例实施例。

以上所描述的是示例实施例。当然不可能描述每个可构想的组件或方法的组合，但是本领域普通技术人员将意识到示例实施例的很多其它组合和排列也是可能的。因此，本申请意图包括落在所附权利要求的精神和范围内的所有这样的替换、修改和变化，所附权利要求的精神和范围根据它们公平、合法且公正地有权享有的范围来解释。

Claims (22)

1.一种装置，该装置包括

被配置为与多个设备通信的接口；

与所述接口耦接的控制逻辑；

其中所述控制逻辑经由所述接口广告数据流和与所述数据流相关联的多个前向纠错流的可用性；

其中所述控制逻辑经由所述接口接收代表针对请求所述数据流的所述多个设备中的每个设备的前向纠错的数据；并且

其中所述控制逻辑选择性地将经由所述接口对所述相关联的前向纠错流的转发限制到使全部所述多个设备能够处理所述数据流的最少量的前向纠错流。

2.如权利要求1所述的装置，其中所述数据流是多播流。

3.如权利要求1所述的装置，其中所述数据流是多播视频流。

4.如权利要求1所述的装置，其中所述数据流和所述多个前向纠错流具有相同的多播地址；并且

其中所述数据流和所述多个前向纠错流具有不同的端口地址。

5.如权利要求1所述的装置，其中所述数据流和所述多个前向纠错流具有不同的多播地址。

6.如权利要求1所述的装置，其中所述数据流和所述多个前向纠错流的广告还包括针对每个流的单独的多播地址。

7.如权利要求1所述的装置，其中所述控制逻辑根据经由所述接口从所述多个设备中的每个设备接收的对于属于所述多个前向纠错流的流的预订请求来确定针对所述多个设备中的每个设备的前向纠错的量。

8.如权利要求7所述的装置，其中所述控制逻辑通过窥探经由所述接口接收的互联网组管理协议分组确定所述多个设备中的每个设备请求了哪些流。

9.如权利要求1所述的装置，其中所述多个前向纠错流中可用的前向纠错的总量被动态地设置。

10.如权利要求1所述的装置，其中每个流中可用的前向纠错的量通过将前向纠错的总数目除以所提供的前向纠错流的数目而被确定。

11.如权利要求1所述的装置，其中每个流中可用的前向纠错的量通过以下方式被确定，所述方式即调节所述多个前向纠错流中的前向纠错的量以使得所述多个前向纠错流被平均分布在所述多个设备上。

12.如权利要求1所述的装置，其中多个接入点与所述接口进行数据通信，所述多个接入点中的每个接入点具有请求所述数据流和所述多个前向纠错流中的至少一个前向纠错流的至少一个客户端；并且

其中所述控制逻辑调节所述多个前向纠错流中的前向纠错的量以使得所述多个前向纠错流被平均分布在所述多个接入点上。

13.如权利要求1所述的装置，其中多个接入点与所述接口进行数据通信，所述多个接入点中的每个接入点具有请求所述数据流和所述多个前向纠错流中的至少一个前向纠错流的至少一个客户端；并且

其中所述控制逻辑调节所述多个前向纠错流中的前向纠错的量以使得由所述多个接入点提供的前向纠错流的量最小化。

14.如权利要求1所述的装置，其中多个接入点与所述接口进行数据通信，所述多个接入点中的每个接入点具有请求所述数据流和所述多个前向纠错流中的至少一个前向纠错流的至少一个客户端；并且

其中所述控制逻辑为针对所述多个前向纠错流中的每个前向纠错流的一组可能值中的每个可能值确定针对所述一组可能值所产生的流量的量；并且

其中所述控制逻辑从所述一组可能值中选择使得所产生的流量的量最小化的一组值。

15.如权利要求1所述的装置，其中第一接入点和第二接入点经由所述接口与所述控制逻辑进行数据通信；

其中所述控制逻辑确定与所述第一接入点耦接的请求所述数据流的被选择设备是否正在接收来自所述第二接入点的更好的信号；并且

其中所述控制逻辑响应于确定所述被选择设备正在接收来自所述第二设备的更好的信号，而解除与所述被选择设备的关联。

16.如权利要求1所述的装置，其中分别与请求所述数据流的至少一个客户端相关联的多个接入点与所述接口进行数据通信；

其中所述控制逻辑从所述多个接入点中选择一个接入点以将所述数据流提供给弱客户端；

其中所述控制逻辑检测到至少一个弱客户端与由所述被选择的接入点、与所述被选择的接入点相邻的接入点、以及所述被选择的接入点和与所述被选择的接入点相邻的接入点的组合构成的组中的一个相关联；并且

其中所述控制逻辑引导所述至少一个弱客户端漫游到所述被选择的接入点。

17.如权利要求1所述的装置，其中所述控制逻辑丢弃被指定且可配置的百分比的前向纠错修复分组，以使得最少数目的前向纠错修复分组经由所述接口被转发以满足针对全部所述多个设备的特定服务级别。

18.如权利要求17所述的装置，其中所述被指定且可配置的百分比的前向纠错修复分组随时间而被修改以补偿动态环境状况。

19.一种方法，该方法包括：

广告多播视频流和与所述多播视频流相关联的多个前向纠错流的可用性；

获得针对请求所述数据流的多个设备中的每个设备的代表前向纠错的数据；

由处理器根据所述代表前向纠错的数据确定在向请求所述多播视频流的所述多个设备中的每个设备提供足够的前向纠错的同时能够被提供给所述多个设备的最少数目的前向纠错流；并且

选择性地提供所述多播视频流和所述最少数目的前向纠错流。

20.如权利要求19所述的方法，其中确定所述最少数目的前向纠错流还包括根据经由所述接口从所述多个设备中的每个设备接收的对于属于所述多个前向纠错流的流的预订请求来得到用于所述多个设备中的每个设备的前向纠错的量。

21.如权利要求19所述的方法，该方法还包括动态地调节所述多个前向纠错流中的每个前向纠错流所提供的前向纠错的量以最小化被发送给所述多个设备的数据量。

22.被编码在至少一个非暂时性计算机可读介质中的逻辑，该逻辑供处理器执行并且当被所述处理器执行时可操作用于：

广告数据流和与所述数据流相关联的多个前向纠错流的可用性；

获得针对请求所述数据流的多个设备中的每个设备的代表前向纠错的数据；

确定在为请求所述数据流的所述多个设备中的每个设备提供足够的前向纠错数据的同时能够被提供给所述多个设备的最少数目的前向纠错流；并且

选择性地提供所述最少数目的前向纠错流。

Images